Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Memory/Storage

Abstraction tackles interoperability

Posted: 01 Jun 2002 ?? ?Print Version ?Bookmark and Share

Keywords:network? os? cpu? rtos? vxworks?

Developers of network-based devices for distributed net-centric computing face many challenges in making their products interoperable across a network, whether private or public. Networking technology is evolving so fast that today's advanced networking devices may be obsolete in a year or even in six months. Developers must take that rapid evolution into account and plan their products for interoperability, scalability and high performance.

The most crucial issue is interoperability among all network platforms, regardless of the type of hardware used. A network device vendor must be able to pick a device off the shelf and know that the software architecture can be integrated rapidly with the device and that any previous application development investment can be reused, regardless of the hardware, OS or CPU. An additional issue is that network bandwidth, even at today's high rates, is often stretched beyond its limits.

Designers have a number of other important issues to face. Today's network devices must support multiple standards and be upgradeable to any future standards that emerge. Quality-of-service and bandwidth provisioning are essential to avoid logjams in today's diverse network traffic environment. Network systems must be able to incorporate new technology as it becomes available, allowing the vendor to insert its own value-added functions to accommodate unique customer requirements.

How does a manufacturer deal with all of that and still produce a system that will work with any other system, anywhere? We believe that the best answer is to use a networking software framework based on abstraction as a means to make the system scalable and adaptable not only to any present or future standard but to any hardware device as well.

System independence

Today's networking software needs to be independent of any specific hardware infrastructure. If you write software specifically for a product with a 32-port box, three LEDs and one fan, there is no way you can port that software to a network-processor-based product with a 132-port chassis, 53 LEDs and six fans without having to invest a great deal of time rewriting major portions of your software.

In addition, many companies are producing low-end products where costs are kept low by using ASICs with royalty-free Linux as the OS, while in the high end of their product line, which requires advanced functionality, they may use network processors that require a commercial RTOS such as VxWorks. To avoid having to rewrite the interface for each product, you need software that is OS- and hardware-independent.

The solution to both hardware and OS independence is to write the system software as reusable building blocks using a set of abstractions that will detect the specifics of the hardware platform and that will integrate with any OS. In that way, the software is portable across a range of networking products.

For example, software can be designed to allow all protocol applications to assume that they are talking to a single network device. Underneath that, there should be a layer that unwraps a forwarding database modification request and directs it to one or multiple forwarding elements, as appropriate.

The forwarding hardware can be all of the same type or of varied types and may even be in different boxes. By abstracting this function, a protocol application writer can write a complex piece of software without having to know the specifics of the system.

Hardware independence

Network hardware independence can be achieved by using an abstraction layer to write an interface between application software and network hardware. We call that layer the device transformation layer (DTL) in our approach and have submitted it as a proposed specification to the Network Processor Forum. Where multiple networking chips are used, the DTL resolves the interface to the actual physical port on a given network hardware device.

Such core services as "add route," "delete route," "enable port," "disable port," "get port stats" and the like, are mapped through as APIs. While the DTL interface addresses the abstraction between the application protocol layers and the networking hardware specifics, it does not address platform hardware issues, which are dealt with using a system abstraction later.

Abstraction layer

A system abstraction layer allows you to implement software that is transparent to the RTOS, CPU and physical characteristics of the product on which it runs. The layer contains the board support package, which allows the higher-level software to access such services as non-volatile memory storage using common generic interfaces, without having to know such specifics as the type of non-volatile storage, the serial ports or the CPU type.

Common OS services, such as task management, memory management and semaphores, can be mapped through an RTOS abstraction layer software so that applications can be written to the APIs without making direct calls to a specific OS. By providing such an abstraction layer, one can take advantage of the numerous commercial OSs or utilize an internal OS for development. It is important to require the applications to use the abstraction calls and not the underlying OS's API calls.

Services of the underlying OSs Internet Protocol network stack can be mapped through as if they were OS services. For example, socket calls can be mapped through the abstraction layer software. Another option is to consider the IP stack as a separate entity and not capture it with the OS abstraction interfaces.

A further means to cross-platform interoperability is a management system abstraction layer that allows the user interfaces to see the specific network ports as interfaces without having to know the specific location of the physical port. This layer can route the request to the proper subsystems without involvement from the user interface. The management system abstraction layer provides a single interface between the software applications and the managing entities, allowing multiple user interfaces to control the same underlying set of application services regardless of the network processors or ASICs.

However, hardware and OS independence are not enough. Because of the many broadband communications standards that exist and the emergence of new standards, it is imperative that embedded networking platforms support multiple protocol standards. A few worthy of special mention are the IEEE ForCES Initiative, IEEE 802.16, multi-protocol label switching and the Internet Engineering Task Force's IP Multicast.

The system software must support and interoperate with whatever standards are being used on any given installation on the network and with emerging standards that will need to be supported tomorrow.

? Michael Ward

Product Manager

LVL7 Systems Inc.

? Robert Hines

Director of Software Engineering

LVL7 Systems Inc.

Article Comments - Abstraction tackles interoperability
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top