Hybrid traffic management processing needed for diverse telecom/net systems

In networks at the core and edge, service level agreements (SLAs) that offer premium services lead to new ways of revenue generation. Implementing differentiated services requires sophisticated traffic management schemes, which can only be implemented by a combination of hardware and software.

Quality of Service (QoS) is a set of specifications that allow a telecom service provider, a business enterprise, and an individual telecom consumer to receive predictable service levels, which are measured in bandwidth (throughput), delay (latency), and delay variation (jitter). Traffic management is a critical component of QoS and communications network equipment efficiency.

But, not all types of traffic are created equal. While voice traffic is less bandwidth intensive and less sensitive to random drops, it is very sensitive to delay and jitter. On the other hand, File Transport Protocol (FTP) traffic is very bandwidth intensive, very sensitive to random drop, and less sensitive to jitter and delay. To maximize network efficiency, packets are classified and grouped into flows and delivered with differentiated services according to Service Level Agreements (SLAs).

SLAs offer a mechanism to assign policies to classes or flows. For example, a service provider may offer three classes of service: platinum, gold, and silver. Platinum service offers guaranteed bandwidth and latency. Gold guarantees delivery. And silver offers best effort service with no guaranteed bandwidth. During congestion, packets coded as silver get dropped while platinum receives highest priority service. Implementations of such SLAs require efficient traffic management functions such as queue scheduling techniques and link fragment interleave mechanisms-all at wire speed.

And, although most markets impose common requirements on traffic management, networks on the edge, in particular, have their own unique requirements. For example, they impose stringent size and power constraints due to space constraints imposed by wiring closets.

This is forcing network processor vendors to integrate more traffic management functions with traditional network processing functions such as classification.

Integrating traffic management into network processors also has the advantage of reducing total system cost due to reduced board space and power. Lower power consumption means low heat dissipation, which lowers cooling costs and increases system reliability. This allows switches/routers on the edge to be cost effective without compromising performance.

There are basically three approaches to implementing the traffic management component of traffic processors: completely in software, completely in hardware, or a hybrid solution. Each of these approaches trade off in performance (speed), ease of programming, scalability and cost.

In a software only approach, all of the algorithms are implemented in software. The processor provides some basic primitives such as lock/unlock and mutexes. In this approach, the network equipment system designer implements in software the algorithms and all the associated resource blocks such as queues and tables. Although this type of architecture appears to be flexible, in reality queuing disciplines implemented only in software are suitable only in the lowest speed routers where low traffic volumes do not stress the software implementation.

Because traffic management involves simultaneously examining the status of thousands of queues and their related parameters, it can be effectively implemented only in hardware. Software implementation dictates successive inspecting of thousands of individual queues resulting in poor performance, complex programming, and inaccurate provisioning of QoS.

On the other end of the spectrum, pure hardware solutions implement queuing algorithms in hardware. Typically, these types of solutions are configurable but not programmable. Although a hardware only solution is suitable for a segment of the application, it is not suitable for a multi-service network involving both IP and ATM. In large IP networks, service providers constantly innovate queuing disciplines to differentiate them from the competition and seek new ways to generate revenue by creatively allocating and managing bandwidth.

Best of both

Hybrid solutions, on the other hand, allow software programmability while maintaining the speed advantage of ASIC solutions by implementing certain blocks in hardware. In this type of architecture, key functional blocks are implemented in hardware. Hardware primitives that aid traffic management include a 16- and 32-bit CRC unit (for ATM segmentation and re-assembly), timer support for Differential Services (DiffServ) metering, policing and rate shaping, a math unit (for QoS block policing and congestion management), and schedulers, queue managers, and hierarchical port managers to implement shaping algorithms.

Packets arriving at an ingress interface are first classified into flows. Flow classification can be based on several criteria such as protocol type, source address, source and destination ports, and organization type. All packets belonging to the same flow receive the same contracted traffic treatment. The queuing logic is hardware primitive that manages queuing resource blocks such as linked lists, head and tail pointers.

In such hybrid architecture, congestion management function is implemented using the buffer manager, which interacts with the queuing logic to either en-queue a packet or drop it. Packet discard algorithms such as RED or WRED can be implemented in software, which executes on the buffer manager compute engine and produces an outcome that dictates whether a packet gets queued or dropped.

In this type of configuration, the scheduler engine implements the hardware primitive that assists queue scheduling. The very nature of large multi-service networks at the edge and the core requires switch/router vendors to offer a combination of queuing approaches to allow them to accurately arbitrate output bandwidth during periods of congestion. A scheduling architecture should seek the right balance between performance, flexibility, and ease of programming.

Designing a hierarchical scheduling mechanism is one possible architectural choice for a scheduler engine that allows flexible bandwidth management while still meeting the performance requirements. In such a scheme, a large pipe is successively subdivided into smaller pipes, each with its own scheduling policies. This allows a router designer to implement very granular flow-level scheduling control and implement a combination of queuing functions.

In this kind of scheme, a router designer can implement a scheduling decision tree in hardware while allowing software to implement the policy of how the next branch in the tree is traversed. At each stage of a multilevel hierarchical scheduling tree, there is a many-to-one mapping to the next stage. For example, multiple queues are associated with a scheduler; multiple logical ports are associated with a port manager, and so on. The selection process starts at an output interface scheduled to transmit a packet. A scheduling policy is then applied to the selected output port to select a port manager. Because several logical ports could map to a port manager, a scheduling policy is applied to select which logical port gets to transmit a packet. This process is continued until a queue is selected for transmission.

Optimal efficiency

One advantage of this hybrid approach is that a combination of queuing policies can be implemented to achieve optimal bandwidth efficiency. For example, a rate controlled PRR scheme can be combined with a DWRR scheme to ensure high priority queues are serviced before low priority queues, as long as the high priority queues do not exceed their allocated bandwidth.

A key consideration in designing hybrid traffic management systems is the architecture of the programming model. The programming model must ensure the right "dials and knobs" are available to the router designer while maintaining ease of programming. There are two aspects to the programming model architecture: language issues in programming the wire speed path and the control plane programming interface.

To reduce the software complexity of programming the wire speed path, most network processor vendors support high-level languages. Micro-code instructions are another option. Using a high-level language such as an optimized C, for example, allows much better expression of problems and eases code maintainability. The goal behind the design of such languages is to abstract the hardware implementation, meaning hide the details of the hardware as much as possible, yet allow programmability. Hiding the hardware details minimizes application software porting efforts as new generations of hardware are introduced.

Dynamic service provisioning also means the traffic management solution should be capable of being configured programmatically by the control plane software. For example, as new service categories are created, new flows need to be created on the fly. Application programming interfaces (API) must be defined to allow the creation of functional structures such as queues and schedulers while abstracting the hardware architecture of the network processor from the control plane software. This allows switch/router vendors to retain their software investment while the hardware evolves over time.

See related chart