In the past few years, there has been significant interest in using open platforms for building communication devices. Linux and open source platforms are being used in various devices on the network - end systems such as mobile phones and client devices, and access and edge routers for forwarding data packets and server platforms.

There are several advantages to using open platforms to build communications devices: flexibility and scalability, standard interfaces, and leveraging the open source community. This article discusses the building of routers using open software platforms and components via leveraging these advantages.

Open Platforms for Communications
Simply put, a platform is a base on which applications can be built. It allows extensibility in that you can provide new applications to be added to existing applications for the specific environment targeted. Open source platforms such as Linux are strong candidates for communication platforms for various reasons:

• Standard interfaces and APIs allow the building of new applications and mixing and matching of applications.
• Platform scalability and flexibility - depending on the communication applications, you can use the appropriate distribution, e.g., Carrier Grade Linux.
• The open source community helps with the extension and optimization of platforms, for example, with the scheduler in Linux 2.6.

Router Implementation
There are two popular form factors for routers - a "pizza box" and a "chassis." A pizza box router is a single board system (usually laid out horizontally) that has a fixed configuration for the number of ports. There might be a small number of "option cards" that are PCBs for specific options, for example, DS1, DS3 interface, and so on. These boxes are usually single CPU systems in which both the performance and the configuration are fixed. Forwarding might be done in software or use acceleration provided by the specialized hardware, such as switching chipsets, network processors, or ASICs.

The chassis system ("big iron") consists of a chassis or a shelf on a rack with multiple hardware PCBs in a vertical or horizontal configuration. The most common architecture for chassis-based routers is the centralized architecture in which there is a central route processor and switch fabric (see Figure 1). The remainder of the system consists of line cards that provide the interfaces (ports) for the system connectivity. The line cards might contain their own CPUs running software or rely completely on the central route processor CPU. Depending on the architecture, the forwarding of packets between the ports on a single line card could be done on the line card or via the centralized switch fabric.

Router products are often segmented by the market they address - the common ones being the enterprise and the service provider markets. The routers used in the latter are often called carrier grade routers, where the stability of the routing software is even more important due to the effect on the large number of end customers.

Router Software
Most commercial routers ran on internally developed or commercial real-time operating system (RTOS) platforms. Often, the same RTOS with some minor tweaks ran on all the router products - low end, mid-range and high end routers. It was quite common for the router software to run as a monolithic piece of software with no memory protection among the individual processes/tasks. The failure of one process could cause the entire router software to crash, disrupting network connectivity.

Newer routers, especially carrier grade routers, are prone to using platforms with memory protection among processes. To fulfill this, these routers have required a major upgrade to the platforms on which the routers are built. In some cases, the router manufacturers have used open source operating systems such as Linux or NetBSD as the base platform. On carrier grade routers, the memory protection and isolation among processes provided by these platforms has another benefit - upgrades. Consider a routing process that has a bug that has been fixed in a newer release. Without affecting the forwarding or other processes, the older routing process can be shut down and restarted with a newer image.

Plane Facts
Networking function implementation is often separated into three distinct planes (see Figure 2): the control plane that is responsible for routing updates and setting up tables for forwarding, the data or forwarding plane that does the grunt work of forwarding packets based on the destination address in the packet header, and the management plane that provides for configuration and control of the router. The control and management plane are usually implemented in software while the data plane may be implemented in hardware or software.

Building an open router with a standard platform such as Linux fits in very well with plane separation. The individual functions can be architected and designed in a modular fashion using well-defined interfaces between the constituents of the planes. For example, a routing protocol process like OSPF (Open Shortest Path First) can be implemented as a Linux process while the IP forwarding function can be present in the kernel. The tables that the kernel uses for forwarding can be configured by the OSPF process. Similarly, you could have an HTTP server process along with an SNMP process for management functionality (see Figure 3).

Standards
Routers and other networking devices need to conform to standards. The popular joke is that the good thing about standards is that "there are so many of them and if you don't conform to one today, you only have to wait for the next one." On a more serious note, the issue with standards is that they are a moving target. There is a need to keep track of and conform to standards for the individual components in the router. For example, the IETF (Internet Engineering Task Force) is working on enhancements to OSPF in the OSPF Working Group. Depending on the applicability of the enhancements, the router software can incorporate them into the next revision.

Standardization of components does not just involve protocols. It can incorporate APIs and middleware functionality too. For example, the Service Availability Forum (SAF) has specified two sets of APIs - the Hardware Platform Interface (HPI) and the Application Interface Specification (AIS) - that need to be provided in the middleware functionality on a highly available system. Similarly, the Network Processing Forum (NPF) has specified APIs for IPv4 and IPv6 forwarding, IPSec, and so on. It's easier to mix and match components from different sources if they conform to these standards-based APIs.

Embrace and Extend
A common theory about the English language is that it has thrived because of its openness; it has integrated words from other languages and been extended with newer words. An open router using Linux or an open source platform is very similar to this. Using the best-of-breed components from various quarters, we can build an extensible and powerful router. This is not a new phenomenon; several router vendors build their systems using a combination of internally developed software and external components, either from the open source or licensed from third-party software component providers. These licensed components are then ported to the router software subsystem to provide the desired functionality.

Consider the hypothetical example of an equipment vendor that desires to build a carrier grade chassis router from scratch. For the software, the vendor can use Carrier Grade Linux (CGL) from multiple vendors such as MontaVista and SuSE. The routing protocols could come from multiple third-party protocol stack vendors such as Data Connection, FutureSoft, IP Infusion, and NextHop. The management protocol stacks could be licensed from vendors like SNMP Research or Adventnet. The Carrier Grade Middleware (compliant to the Service Availability Forum specifications) and infrastructure platform software can originate from companies such as Clovis or GoAhead software. Secure Management can be implemented from open source using OpenSSH and OpenSSL. The key takeaway from this example is the use of "best-of-breed" components so that you can build a more powerful and open router platform with multiple constituents that have been well tested and deployed.

Advantages of Linux
Linux is an excellent candidate for the emerging open router platform. The large community of open source developers and the work being done at bodies like the OSDL are only two of the reasons. The real-time kernel enhancements in Linux 2.6 can be leveraged by those routers that need to provide software-based forwarding - typically pizza box routers. Tailored baselines like Carrier Grade Linux from various Linux vendors provide features such as high-resolution timers, a runtime application patcher, and field-safe application debuggers. These features help with the networking functionality implementation as well as easier maintenance and debugging of the equipment in the field.

In addition, several Linux distributions have a plethora of applications that are useful in networking devices. These include a network time protocol (NTP) daemon, FTP clients and servers, NFS, SSH and SSL, and so on. New applications on Linux can leverage these applications via standard interfaces, a distinct advantage over proprietary platforms. Thus, it is no surprise that Linux is being used in pizza box and chassis-based routers. In the latter, it's being used on the control card and also, in cases where an OS is needed, on the line card.

Conclusion
In the networking industry today, there is a growing trend toward using open platforms such as Linux to build routing software and networking applications. While building carrier grade routers is not rocket science, it's not trivial either. The use of open and stable platforms that provide extensibility and flexibility allows networking vendors to build robust systems - without compromising their ability to innovate.

Unlike monolithic and single source architectures, open routers can be built using a flexible base platform with components from multiple vendors. The individual components can be designed to be conformant with various standards while providing and using standard interfaces. These components could themselves be licensed from third-party vendors or obtained from open source.

References

• Sridhar, T. "Open Routers: Carrier Grade Routing Software over Linux." OSDL Carrier Summit, Beijing, October 2005.
• Service Availability Forum (SAF) Hardware Platform Interface (HPI) and Application Interface Specification (AIS), available for download from www.saforum.org.
• Comer, D. (2003). Network Systems Design using Network Processors. Prentice Hall.
• Carrier Grade Linux (CGL): www.osdl.org/lab_activities/carrier_grade_linux/
• Network Processor Forum (NPF) specifications available for download from www.npforum.org
• MontaVista Linux Professional Edition Networking Support: www.mvista.com/products/pro/networking.html
• Internet Engineering Task Force (IETF) OSPF Working Group charter: www.ietf.org/html.charters/ospf-charter.html.
• Sridhar, T. (2003). Designing Embedded Communications Software. CMP Books.