By Michael Ward, Program Director, Product Management; LVL7 Systems Copyright 2004, LVL7 Systems Inc., All Rights Reserved
Today, with the wide application of distributed network computing devices, network equipment developers are also facing many challenges. They are going to face how to effectively achieve interconnection between equipment between other manufacturers in private and public networks. problem. Also, network technology has developed so quickly, so that today's advanced network equipment may be over time or half a year. As a developer, they must consider this rapid development trend, starting from the perspective of eyes and long-term perspectives, based on interoperability, scalability, and high performance requirements to plan its product development plan. Network device vendors To select a series of system components in product development, such as network chips, CPUs, embedded OS, and racks. At the same time, they have to be confident in their system software architecture, believe it can quickly integrate into new product designs, and use any previously developed applications in similar new devices. Between, the most core problem is how to implement interoperability between all network platforms, regardless of the hardware and operating systems used. In addition, the system designer will also face some of the following issues. For example, today's network equipment must support multiple standards, which also includes any future standards that have emerged and gradually mature. When new technologies are available, the network system must be able to integrate it in, so that suppliers can join their value-added functions to meet some unique customer needs. So how do equipment manufacturers to develop product systems to interconnect with any other similar systems? A method of obtaining a verification is to use an abstract network software framework to extend and apply to any of today's and future standards, or for any hardware device and operating system platform. Such methods allow system designers not only reuse the achievements of internal software development, but also integrate other resource components into the product, whether they are open source or third-party commercial software. Hardware and operating system independently today's network software requires independent of any specific hardware infrastructure. Suppose you have written a specific software for a fixed configuration product, which is based on ASIC chip design, 24 ports, and no system redundancy. Then, for a network processor chip and a complete hardware redundant device, you will not be able to easily transplant your software. You will need to put a lot of time to override the main part of the software. In addition, in order to optimize the cost performance of different levels of products in the product line, many companies use multiple embedded operating system platforms in a series of products. For price-sensitive low-end products, network vendors tend to use Linux that does not require the secondary product as an operating system platform, and for high-end product lines that require complex functions, the commercial RTOS, such as VxWorks, or use VxWorks at the same time And Linux. To avoid overwrite a software interface for each product, you need a software platform that is independent of the operating system and hardware. Embedded Linux has gradually become a popular choice for system designers, which is no longer a business model for its free royalty, more because it supports various CPUs and target boards, and With more and more engineers who are familiar with Linux operating environment. At the same time, Linux communities and commercial Linux providers also expand their kernels, which brought the same level of robustness that users can provide by users of many commercial RTOs. In addition, open source communities and commercial companies have also made Linux a high-cost development environment, and network equipment can use them to complete cross-platform product development. The "hardware and operating system independent" solution is to write system software into reusable components, which uses a series of abstract interfaces to complete detection and seamless integration of specific hardware platforms into any operating system.
When you develop products on different hardware platforms, the software architecture with abstract layers can protect your investment in software application development. This abstraction layer has established a public interface between applications and other programs, because the interface is mainly interacting with control plane units, and their impact on the overall system performance will be small or even ignored. For example, the software can be designed to allow all protocol applications to assume that they interact with a separate network interface, where there must be an abstract layer to translate the submitted database modification request and or to one or a few suitable. The forwarding unit (such as a network processor or ASIC / ASSPS), and the forwarding hardware can even be a network chip located on other devices. By abstract the control distribution function, the application protocol programmer does not need to understand the specific details of the system, you can develop complex software. People can use an interface between application software and network hardware by using a FastPath Device Conversion Layer (DTL) of LVL7, to implement system "Network Hardware Independence". When we use multiple network chips, DTL will determine how to interface with physical ports of a particular network hardware device. Some core services such as increasing routing, deleting routing, port enable, port disabling, access port status, etc. will be mapped through standard APIs to the underlying implementation. Although the DTL layer solves the abstract problem between the specific network interface hardware to the application protocol layer, it does not solve the abstract problem of platform hardware (this problem is processed by the system abstraction layer). System Abstract Layer "System Abstract Layer" (called sysapi in the FastPath software of LVL7) allows you to implement a software that is fully transparent to RTOS, CPU, and running product physical properties, including a board-level support package (BSP (LINUX support package (LSP). With this public universal interface, high-level software can access the underlying service without understanding the underlying hardware characteristics, such as reading and writing of non-volatile memory. Public operating system services, such as task management, memory management, and signal lights, etc., can also be mapped through the RTOS abstraction layer (called OSAPI in the FastPath software of LVL7), so applications can be written based on OSAPI without the need to directly call specific Operating system service. By providing such an abstract layer, people can use numerous business and open source operating systems or an internal operating system to develop products. Here, an important point is that the application must use an abstract call interface instead of the API call of the underlying operating system itself. The service provided by the underlying operating system IP Network Protocol Stack can also be mapped as an operating system service, such as the Socket Calls, can be mapped through the OSAPI layer. As an additional choice, we can also separate the IP protocol stack as a separate entity, which is different from the operating system abstraction interface. Another key point of API independent cross-platform interoperability is "Managing System Abstract Layer" (called cell stack manager database, usmdb in LVL7 companies), which makes users interfaces do not need to understand many physical details, such as physics Where is the location or how type, etc., simply simply treat it as a logical interface, which is responsible for sending the user to the appropriate subsystem without the involvement of the user interface. The management system abstraction provides a single interface between software applications and management entities, which allows multiple user interfaces to control the same underlying application service set, which is not important to the bottom layer is the network processor or ASIC. Each data object that needs to be managed is mapped by managing system layer interfaces, thereby forming a unified access routine.
The abstraction layer is not only suitable for protocols and application data (such as OSPF interface information and L2 bridges), but also for any particular hardware system data (such as physical port counters and serial port speeds, etc.). All user interfaces interact with the lower-level application through a common API, so you can write a single interface set to implement settings and access to configuration parameters or other data. Both SNMP, CLI, Web, TLL, and XML can access this single management interface to get or set data. This has a huge advantage compared to traditional implementation methods. In order to obtain management information, traditional methods should implement a set of their own access routines for each management interface to enter application code or hardware drivers. This traditional approach has brought great questions to the code maintenance upgrade, and people must pay a lot of work to increase or expand a new feature because each management interface must repeat almost the same work. Support multiple network protocol criteria However, hardware and operating systems are independent and cannot fully meet the requirements. The existing broadband communication standards have been complex, and new standards are constantly emerging, so the support of the embedded network platform for multiple protocol standards is imperative. System software must be able to support and compatible with any criteria on network devices that have been deployed, while also taken into account newly needed new standards that need to be supported in the future. This is achieved by an enhanced architecture that first provides an agreement and functional base set, and allows enhanced protocol implementations, and the underlying protocol can serve as a whole functional module. Figure 1 shows the overall frame of the FastPath architecture. Figure 1: FastPath Architecture Overall Framework If we use core network protocols and services as part of the architecture, this will help us integrate new protocols and applications to the entire system. For example, when we design an IP routing subsystem, the proliferation of routing leaks between different routing protocols such as OSPF and RIP will expose some other questions, and if we can solve them correctly, this will make us Adding additional routing protocols make it easier. By providing a unified registration interface for a variety of routing protocols and registers with a single Route Manager (RTM), this creation has established a public point, based on it can need such information to any routing protocol or other may need such information The system module provides new routing information. This protocol framework and registration mechanism based on abstract API, programmers can quickly understand how they should expand software even if they don't understand the underlying system. Many network industry experienced people know that the new protocols and RFCs that the equipment needs to be supported at that moment of product delivery. Many system designers have found that embedded Linux has become a very attractive system operating platform selection due to the large number of network protocol related software existing in Linux and open source communities. However, the integrity and quality of these software are different from components. In many cases, these software can provide product quality-level functions, or at least use in the pre-system prototype phase. However, when we get components from different software issuings, one of these components must be integrated with each other. Although some high-level network applications such as Small File Transfer Protocol (TFTP) and Network Time Protocol (NTP) can be seen as separate applications; however, they still need to integrate a certain degree of integration to provide a suitable unified user interface. In addition, if an Ethernet protocol, including a generated tree protocol, an 802.3AD link aggregation protocol, and a dynamic VLAN registration protocol (GVRP), etc., they must provide a unified management interface. Also closely combined with each other. In these cases, it is to use these minimum integration components from various releases, or use a set of tightly integrated components provided by commercial companies, and system designers must carefully wear the pros and cons.
