Typically in an Internet Protocol (IP) network router, incoming packets are classified into forwarding equivalence classes (FECs) based upon a maximum match prefix look-up with the destination IP address. The FEC is a set of IP packets that are forwarded in the same manner. The routing function consists of assigning packets to an FEC and determining the next hop of that FEC. In an IP network, this routing function is performed at each hop.

With MPLS, the classification of packets into an FEC and the assigning of a label based on the FEC is done only at the entry into the domain. This occurs at the ingress MPLS label switching router (LSR) with the labels distributed using protocols such as LDP, RSVP-TE, CR-LDP. At subsequent routers no packet classification needs to be done; the packet is switched using label swapping with the label used as an index into a table containing {incoming IF, label}½ {outgoing IF, label} entries (where IF stands for interface). The incoming label is replaced with the outgoing label and the packet is forwarded to the next hop. Finally, in the egress router the MPLS header is removed and the packet is delivered from the MPLS domain where it may be routed to an IP network.

This MPLS label swapping effectively superimposes connections, or label switched paths (LSPs), on the connectionless IP network, resulting in efficient, high-speed switching of the IP packets through the MPLS domain. In essence, the label switched paths in MPLS networks serve as surrogate circuits and deliver all the advantages that connection-oriented networks confer, such as the ability to provision for traffic, do source-based routing, provide different service qualities and provide path protection.

An important benefit of using MPLS is that it enables traffic engineering without having to use an overlay ATM network. MPLS traffic engineering uses traffic-engineered LSPs to forward traffic aggregates on different paths through a network. It provides explicit control over the network resources, with the ultimate goal of maximizing efficient use of available bandwidth, providing predictable differentiated service levels to customers and ensuring network stability. The traffic engineering protocol mechanisms and algorithms enable fault recovery, path prioritization, load balancing and path provisioning services to accomplish this goal.

In a network with MPLS traffic engineering (MPLS TE) , three classes of services can be provided, and each has a primary path through the network, as well as a backup path in case the primary path fails. Each traffic-engineered LSP (also referred to as TE tunnel) has a set of attributes associated with it, with an attribute defined as a feature or a property of the TE tunnel. Examples of an attribute are the explicit path through the network, which may be loosely or strictly specified; the bandwidth, which specifies the amount of bandwidth reserved for the LSP on each link in the path; and the setup and holding priorities, which determine the priority of a path in pre-empting other paths or being pre-empted by them.

In setting up a TE tunnel, in addition to the LSP attributes, the MPLS TE considers the network resource attributes. These attributes include network link characteristics such as the link capacity, maximum reservable bandwidth and the available bandwidth, as well the administrative policies. The protocol components that enable these features comprise Interior Gateway Protocol extensions such as OSPF-TE or ISIS-TE, (for the distribution of network resource attributes), signaling protocols (for LSP setup and provisioning), and extensions to MPLS for DiffServ support. The ingress router classifies incoming traffic according to predefined policy rules that may consider DiffServ code points (DSCP), MPLS labels, source or destination addresses, port numbers or other packet characteristics in order to determine to which TE tunnel to forward the packets.

Since, as with ATM, MPLS most likely will not be deployed at the desktop, there must be an interoperability of edge Quality- of-Service (between the desktop and the edge aggregation routers) with core QoS, (in the MPLS domain) to support end-to-end QoS. Thus an end-to-end path can be segmented into two parts: the path between the end users and the service provider's edge router, and the path across the network core between the ingress and the egress edge routers. To maintain end-to-end QoS, provisioning is required in each segment of the end-to-end path. We describe QoS provisioning in each part separately and then discuss how the two parts can be combined to support end-to-end QoS for applications. The subsequent discussion refers to the network.

In the access network there are several options for implementing a Layer 2 configuration to support QoS. One option is the provisioning of PVCs (permanent virtual circuits) with point-to-point protocol (PPP) over ATM. In this case, IP applications run over PPP. Another option is routed (or bridged) encapsulation over PVCs, which results in IP-over- ATM. In both of these cases packets are marked based on the application by the host sender or the customer edge router and the required bandwidth is provisioned. This segment of the path is often small and the resulting delay and delay jitter is not significant in comparison to the required end-to-end delay and delay jitter.

MPLS and DiffServ make scalable QoS support in the core possible. ATM virtual circuits, Frame Relay circuits and virtual LANs are mapped at the ingress LSR at the edge of the MPLS domain. When necessary, the ingress LSR classifies the packets and marks them with DSCPs that match the QoS requirements of the application. The packets are then forwarded along LSPs that meet the DiffServ class of service requirements. Two methods have been proposed for aggregating DiffServ marked packets into MPLS tunnels.

One option, called label-inferred LSPs, or L-LSPs, associates a specific MPLS label with the DiffServ code point in the IP header. The ingress LSR examines the DiffServ code points in the IP packet header and selects a label switched path that has been provisioned for that QoS level. Each LSR on that path will then determine the QoS treatment for the packets from their incoming labels (DSCP is inferred from the label). The LSRs then implement packet scheduling consistent with the inferred DSCP as defined in the DiffServ architecture.

An alternative approach is to use the experimental (EXP) bits in the MPLS shim header to convey the QoS requirements of the packets to the label switching routers. This is called the E-LSP approach to QoS support in MPLS. There are three bits in the EXP part of the shim header, which can be used to encode up to eight DiffServe code points. The mapping between the DSCP and the EXP bits is made at the ingress router. Packets marked with the EXP bits receive per-hop forwarding treatment for each hop of the E-LSP tunnel as in the case of DiffServ scheduling in non-MPLS IP routers.

To enable QoS support across the core, the core LSRs must perform a number of functions. The ingress LSR must police the incoming streams per PHB per destination. The reason for the latter requirement is to protect downstream interfaces from becoming congested by re-marking or dropping packets that violate their traffic contract. Re-marking allows the out-of-contract traffic stream to use the unused network resources. In addition, the egress LSR must perform per-PHB shaping. If guaranteed bandwidth is to be provisioned for each label switched path, then per-LSP scheduling would be required in each label switching router. Finally, the mapping between the EXP and DSCP can be global across the domain, and can be signaled or preconfigured.

Network reliability can be achieved in many layers in the communication protocol stack: in the physical layer using automatic protection switching strategies of the Sonet link or path switching; in the IP layer through routing protocols, or in the MPLS layer. Sonet protection has no visibility into the higher layers. Thus, while it can support link restorations, it cannot easily provide protection against node failures. Current IP networks rely on routing protocols to maintain network connectivity, which despite being robust and survivable, are slow to recover from failures. After a failure, routing tables may take anywhere from several seconds to minutes to converge, resulting in the possible disruption of services in the interim.

MPLS traffic engineering paths can be explicitly routed so that a predetermined path is specified for the LSP across the service provider's network. In this way a recovery path for a protected path can be "pinned" so that, after the failure, it will not be subject to the fluctuations and transient behavior of the routing protocols. The key idea in MPLS-based path protection is based on the utilization of a backup or recovery path to carry the traffic of the failed primary path. Path-protection methods generally fall under two categories: protection switching and fast reroute.

Protection switching is a prenegotiated recovery mechanism, whereby for each primary path a backup path is pre-established (usually from the ingress LSR). The backup LSP may be provisioned and ready. In this case, the resources on the backup LSP are fully reserved and signaled. Upon the failure of the primary path, traffic is moved over to the backup path.

Path protection switching may not be fast enough for real-time applications such as Voice-over-IP (VoIP). In many implementations, the notification messages are triggered by the soft-state mechanism of RSVP, which relies on a time-out mechanism and may take several seconds. Moreover, the notification messages must travel from the point of failure to ingress and egress LSRs, which may be several hops away.

The fast reroute recovery mechanism does not require the notification of the ingress LSR. In fact no signaling is required at the time that the failure is detected. The node that detects the failure is also the node performing the repair. In addition, as in protection switching, the backup paths are presignaled and the required resources are prereserved.