Networking software key to PICMG 2.16 optimization

Software that enables Layers 2/3 switching and routing, traffic engineering, and management for switches, routers and access devices is also the key to flexibility, fault tolerance, reliability, and high availability for PICMG 2.16 systems. For market sectors other than telecom it offers a basis on which to provide applications for systems that manipulate and present large amounts of data in a real-time environment.

However, this software is extremely complex, and successfully integrating all the necessary components presents a significant challenge to the designer. The base operating system and other core system services, including file systems and timer management, must be integrated and ported to the specific NPU subsystem being used. Then, the software must be integrated with the networking hardware subsystems. This involves developing and testing of low-level device driver code to interface the networking hardware with the high-level software components.

At this stage the high-level software must also be integrated with the system support components of the device. In parallel, various control plane protocols and applications that are to be provided by the device must be developed and integrated. The key problem with this development model is that many design issues do not become apparent until the hardware and software integration phase-whi ch may seriously delay time to market and significantly increase development cost.

Whether the software is developed in-house or purchased from a vendor, the most important criteria for the software for PICMG 2.16 switching fabric and node cards include: a flexible system architecture, modularity, RTOS and silicon independence, common APIs, fault tolerance and redundancy. In particular, the networking software should provide a complete framework for the instrumentation of a low-level network device driver to interface with various networking devices such as network processors, ASICs, ASSPs, and even FPGAs.

To achieve hardware and software independence, system software must be written with sets of abstractions that will detect the specifics of the hardware platform and integrate with any OS.

Common OS services, including task management, memory management, and semaphores, can be mapped through an RTOS abstraction layer. Applications can then be written to the abstraction layer AP Is without making direct calls to a specific OS. An architecture with abstraction layers provides a common interface between applications and has little to no impact on system performance because the abstraction interfaces connect primarily with control plane elements.

Additionally, an abstraction layer should be used to resolve the interface to the actual physical port on a given network hardware device, which is important for design scalability when using multiple networking chips. Vendors can use a commercial RTOS or internally develop their own. In the latter case, software engineers must design the applications to utilize the abstraction calls and not the underlying APIs of the operating system.

Common APIs
In the fast-paced and hyper-competitive telecom and datacom environments, new applications and protocols continuously become available. To gain a competitive edge, most vendors integrate value-added proprietary technologies with their systems. Vendors who purchase co mmercial software must require the software supplier to support application evolution without disclosing proprietary technology.

This can be accomplished by providing common APIs to the standard networking software and the management module provided by the merchant software vendor. To assure system integrity, there should be a common API communicating to the management module. If a system configuration is changed through a management entity such a Simple Network Management Protocol (SNMP), the change becomes visible through all other management entities such as Command Line Interface (CLI) and Web Interface.

To enable system vendors to add their own technologies, including Phy management functions or power and system management, they should insist on tools that facilitate development choices. These include tools to create new Management Information Bases (MIBs) for S NMP management or Web compiler tools. To assure quick and simple development, all the APIs and tools should have well-documented code and clearly written customer documentation.

The Five-Nines requirement is a universally observed rule that telecom equipment must be functional 99.999% of the time, allowing for about five minutes of downtime per year. Satisfying this requirement largely depends on hardware, but networking software plays a critical role by providing redundancy and fault tolerance. Two networking protocols play vital roles in this protection: the RFC 2338 Virtual Router Redundancy Protocol (VRRP) and IEEE 802.1w Rapid Reconfiguration of Spanning Tree.

The VRRP protocol enables multiple physical routers to appear as a single entity to the hosts on the network thereby maintaining network availability in case of a router failure or disaster. The master/slave configuration of the fabric switch cards at the networking layer allows a slave switch card to spoof both the MAC addr ess and the default gateway IP address of a failed active card. To minimize network disruption, the slave card immediately takes over. Although much of this activity is managed by firmware and the RTOS, important functions are also handled by networking software.

Rapid Spanning Tree protocol 802.1W is implemented in routers, bridges and switches to provide a loop-free network topology. The protocol offers a mechanism for network devices to learn the topology, elect a root bridge, and selectively block ports to form a loop-free spanning tree. Its principal value is that it reconfigures the bridge topology within a split second if one of the nodes fails completely-much faster than the older version (IEEE 802.1D), which could take up to a full minute to reconfigure.

Alarm and event reporting is another important element in fault tolerance and is primarily managed by software. A user interface brings a faulty state to the attention of a technician or the automatic recovery subsystem. For a technician to react, system information must be clearly displayed on a Network Management System (NMS) interface driven by the underlying SNMP protocol, a CLI alarm message, or by an HTTP-driven Graphical User Interface (GUI).

In the PICMG 2.16 environment, the management module of networking software is even important in guarding against issues such as cable failures-not a trivial concern, because studies show that cables fail three times more often than systems. The latest silicon devices incorporate cable testing utilities for detecting cable failure, shorting and out-of-phase errors. The software reports the incident through the various user interfaces.

Software plays a critical role in logging the information and reporting it to the NMS or technician. Regardless of the type of failure, automatic reconfiguration can be triggered by a failure. Technicians can pre-design configuration and reconfiguration scripts using a concise scripting language developed as part of the CLI comm ands, or through SNMP commands for NMS reconfiguration. In either case, the software-driven management subsystem is responsible for this level of fault tolerance.

Expandability options
Software is the most important component of an expandable architecture. Features can be added or upgraded using IP Quality of Service (QoS) and IP Multicasting protocols to prioritize voice over data and multicast video and streaming media.

Network expandability is provided by distributed software architectures capable of handling data stacking. Stacking allows the chassis to grow by replacing cards. Nodes can be added through any stacking topology such as daisy chaining or star topology.

A distributed software architecture improves load-sharing performance, allowing multiple cards to utilize all of the available power of the distributed processors for maximum data throughput. All these capabilities are made possible by advances in the networking software arena, both within the PICMG 2.16 architecture and through new protocols for QoS and Multicast.