Ongoing interest from the investment community, an accelerating pace of mergers and acquisitions and large numbers of networking platforms based on network processors all indicate that network-processor fever is gripping the network-equipment industry. Such processors are winning designs in all sorts of applications, networked multimedia and otherwise. There's little doubt that network-equipment designers are defecting in droves from their traditional development paradigm and adopting network-processing platforms. The established methods used by network equipment vendors-ASICs and general-purpose RISC processors-appear to have fallen short of the requirements imposed by the new networking landscape.
This new environment, driven by the emergence of the Internet as a critical business tool, is characterized by the need to provide futureproofing and feature flexibility to service providers. At the same time those service providers are clamoring to provide new data services over an infrastructure where bandwidth capacity is exploding, thanks to optical networking. The time-to-market pressures of an increasingly competitive marketplace compound the challenges imposed by this potent combination of flexibility and performance.
General-purpose RISC processors provide flexibility without addressing the performance chasm caused by the rate of increase in network speeds running way ahead of Moore's law. New and evolving feature sets pose unsolvable problems for ASIC designers, who must hardwire functionality 18 months in advance of product shipment.
Network processors, on the other hand, are optimized for the specific requirements of networking applications. Software programmability provides the future-proofing necessary to avoid obsolescence, while networking optimizations avoid the performance issues associated with general-purpose CPUs.
How, then, can network-processing platforms specifically address packet classification and quality-of-service (QoS), the primary challenges posed in designing equipment for multimedia networks? And how can they address one of the major risks involved in adopting a network-processing platform-integrating network-processing components from disparate sources?
Packet classification involves identifying and tagging packets into multiple categories prior to forwarding them into the network. Those categories include destination, association with other packets in the case of a virtual private network, QoS attributes and security attributes. Various schemes are used to identify packets. The most common uses what is known as a quintuple of fields from the received packet header: source and destination IP addresses, source and destination TCP port numbers and the application type. In Web switching, also known as content switching, it is even necessary to delve into the packet payload and examine the URL to determine the appropriate destination server.
Tagging schemes that indicate the QoS attributes of the packet also vary according to the network environment. The simplest is defined in IEEE802.1p and involves marking priority bits in the packet header. More complex schemes such as multiprotocol label switching and differentiated services require more sophisticated modification of the packet header.
If further proof were needed that accommodating the myriad packet-classification schemes was beyond the scope of the most ambitious hardwired ASIC program, more classification procedures are on the way as the industry begins the process of standardizing the transport of IP packets over optical networks.
After classification and tagging, the received multimedia packets are then scheduled for transmission into the network with the appropriate quality of service. In a multimedia application it is critical to be able to isolate delay-sensitive traffic. Otherwise, nontime-critical flows will cause interference, resulting in either unacceptable jitter or a loss of synchronization of time-sensitive data. On a high-speed link, OC-48c (2.48 Gbits/second) for example, there may be hundreds of thousands of unique flows to be sorted according to their tolerance of delay. This scale requires highly sophisticated queuing and scheduling engines in the network-processing platform.
The network processor (NPU) is a software-programmable processor that has been optimized for the unique requirements of networking applications. The programmable NPU provides full flexibility in classifying and tagging received packets.
The traffic-management engine and switch fabric are responsible for the transport of data from input to output port with the appropriate delay characteristics, or QoS. As discussed above, it is necessary to isolate received flows from one another, resulting in the requirement to support a very high number of individual queues. For that reason the traffic-management engine and switch fabric are often implemented in hardware. Management of such a large number of queues in software is simply not feasible. In the MMC case, shown above, the traffic-management function supports up to 256,000 separate queues using technology known as per-flow queuing (PFQ).
In systems up to an aggregate bandwidth of 40 Gbits/s, the traffic-management engine is often integrated into the fabric. In larger systems (> 40 Gbits/s up to terabits of throughput) it is common for the traffic-management engine to be a separate module and to be implemented on line cards along with the NPUs. The switch fabric in this case is implemented on a separate card in the modular chassis.
The other components in the system handle the interface to the physical connection (increasingly fiber) and the framing of data into whatever scheme is used as transport packets across the network.
The most common framing technology in use today is Sonet. In the future, service providers may adopt alternatives such as 10-Gbit Ethernet.
One risk factor that is not commonly recognized in adopting network-processing platforms is the integration of such complex technology elements from disparate sources. Ensuring that the classification of packets is compatible with the queuing discipline of the traffic management function can be a time-consuming process. It is clearly advantageous if all elements of the platform have been designed for compatible operation from the ground up.
Classification of packets into their appropriate QoS categories is one of the most critical functions implemented in the network processor.
The variety of commonly used classification schemes mandates that the NPU have programmable access to the complete received packet in order to access the appropriate fields to use as the search key for the classification engine. The classification engine may be internal or external to the NPU and is typically implemented as a networking-optimized Ternary CAM. In MMC NPUs an internal module known as the policy engine supports the classification function.
The policy engine supports single-instruction, single clock cycle and simultaneous lookup of the quintuple header components described earlier. The search database is soft-configurable enabling search keys of up to 512 bits wide. Wild cards can be used on any bit in the search key to isolate specific sources, destinations or applications, while conserving space in the database. A patented Weight Array enables multiple results from the same key.
This allows the NPU to select a QoS or security result, as appropriate. A typical application of the policy engine is supporting the dynamic port assignment required in VOIP applications.
Following the classification function, the NPU sorts through the results, in the case where more than one match is found for a single key. It determines the appropriate tag to apply, marking the packet for the QoS function implemented in the traffic management engine.
The various tagging schemes in common use mandate that the tag function also be completely software-programmable.
Clearly a large number of queues are required to implement the guaranteed QoS required by multimedia applications. An example of a queuing scheme designed to support such sophisticated QoS is PFQ technology. Queing on a per-flow basis enables the scheduling function to provide each flow with the exact QoS attributes defined by the classification function in the NPU.
It is not possible for data from a lower priority, nontime-sensitive flow to interfere for scheduler time slots with delay-sensitive traffic. The schedulers have visibility across each flow in the system. As shown, MMC's PFQ technology supports two separate scheduling functions.
In typical multimedia applications, it is necessary to schedule some packets at a guaranteed rate. TDM voice is an example of this type of traffic and an accurate time-based scheduler handles these flows. Video traffic, on the other hand, can sustain some variation in transmission rate, provided a guaranteed minimum rate is sustained. To support this traffic type, the flows are associated with both the time-based and the class-based schedulers. The time scheduler provides the guaranteed minimum rate, with the remainder of the video traffic being handled by the class scheduler. Nondelay-sensitive flows are also handled by the class scheduler and are given appropriate access to network resources by a Weighted Fair Queuing (WFQ) scheme.
See related chart