TERP: IBM PowerNP Traffic Engineering Reference Platform

This project highlights how the Network Processor (NP) is used in the context of Traffic Engineering (TE), from both the data plane and the control plane point of view. Our implementation of TE relies on RSVP-TE (Resource reSerVation Protocol, Traffic Engineering extensions) to set up MPLS (Multi-Protocol Label Switching) paths (or LSP, for Label-Switched Path) through the network and on DiffServ to provide Quality of Service (QoS). An OSPF (Open Shortest Path First) routing mechanism with specific TE extensions is used to collect QoS-usage information throughout the network. Our own Route Server component computes paths on request from RSVP. TE permits ISPs (Internet Service Providers) to start offering value-added commercial-grade services. Each MPLS node is composed of one or more NPs, interconnected with a switching fabric and attached to a Control Point (CP): these NPs and the CP together act as a single MPLS node.

In the data plane, TE nodes perform traffic classification, policing, shaping, marking, dropping, and forwarding. The logical components are configured by the CP using a Label and Resource Manager (LRM) process: Ingress MPLS nodes perform traffic classification, policing, and DiffServ marking, whereas transit nodes perform MPLS forwarding (MPLS label swapping), and egress MPLS nodes perform IP forwarding. All nodes can be configured to use WRED or BAT AQM to perform bandwidth allocation.

In the control plane, the CP runs the RSVP signaling, OSPF routing, and possibly the Router Server processes. Each NP Ethernet port (eth1 to eth39) is mirrored in the Linux-based CP as a normal interface (reth1 to reth39): CP processes can therefore send and receive packets (protocol messages) as if the MPLS node were built as a centralized software-based router. In addition, the CP kernel's IP routing table is mirrored automatically into the NPs. OSPF routing therefore operates completely transparently from the underlying NP architecture; it uses the Linux Netlink API to insert routes into the table. These route updates are reported to the CP-APIs-wrapper process that creates the appropriate control messages to automatically insert these routes into the NP. RSVP interfaces with the LRM to perform resource reservation, i.e., to reserve, commit, and release resources as needed in each node. The LRM performs CP APIs calls that are then translated into control messages destined for the NP.

All these features allow a seamless integration of off-the-shelf control-plane software into the CP.

As part of this project, we also looked at active queue management (AQM) and routing issues.

Publications