PDF of this tutorialSimply put, MPLS provides the ability to support any type of traffic on a large IP network without having to subordinate the design to the limitations of different routing protocols, transport layers, and addressing schemes. The design objective of the Internet Engineering Task Force’s (IETF’s) MPLS effort was to increase efficiency of data throughput by optimizing packet-processing overhead in the IP network.
In addition to the developments in routing, significant strides are being made in optimizing hardware as well. Increased processing capabilities, lower production costs, and more sophisticated, application-specific integrated circuits (ASICs) make it possible to mass-produce hardware that is capable of forwarding datagrams at wireline speed. Until recently, routing protocols and noncompatible physical layers have been a limitation.
This increase in processing capability and decreased cost, in combination with routing improvements, has made it possible to create a very large and reliable Internet infrastructure and switched paths through this faster and more robust network.
Service Level Agreements (SLAs) and MPLS
In less than 10 years, the public Internet has evolved from a government-funded experiment to a commercial juggernaut. There is a fundamental need to support mission-critical networks using IP routing and enhanced signaling protocols. QoS and CoS have become the watchwords of a converged network.
QoS is defined as those mechanisms that give network administrators the ability to manage traffic’s bandwidth, delay, and congestion throughout the network. To realize true QoS, its architecture must be applied end to end, not just at the edge or at select network devices. The solution must provide a wide variety of technologies that can interoperate in such a way as to deliver scalable, feature-rich services throughout the network. The services must provide efficient use of resources by providing the aggregation of large numbers of IP flows where needed while providing simultaneous, fine-tuned granularity to those premium services defined by service-level agreements (SLAs). The architecture must provide the devices and capabilities to monitor, analyze, and report detailed network status. Armed with this knowledge, network administrators or network-monitoring software can react quickly to changing conditions, ensuring the enforcement of QoS guarantees. Finally, the architecture must also provide mechanisms to defend against the possibility of theft, prevent denial of service, and anticipate equipment failure.
As an example, virtual private networks (VPNs) are fueling availability and reliability demands with their requirement for dedicated tunnels across the Internet. At present, VPNs are mainly implemented in a site-to-site scenario, requiring a dedicated connection. Service providers, such as GTE Internetworking and UUNET, offer outsourced VPN services and must therefore have a way to deliver predictable and reliable service to their customers. The ability of a VPN to establish and maintain a tunnel will be greatly enhanced by MPLS’s ability to establish and guarantee CoS and QoS for a label-switched path (LSP). This will benefit VPN service offerings by allowing predictable connections and the ability to quantify this reliability in an SLA.
Why MPLS?
Two fundamental features make MPLS possible across very large routed IP networks. First, MPLS makes it possible to switch traffic through IP routers that, historically, had to interrogate each IP header before forwarding to the next hop. This is accomplished by applying a Layer-2 label to the IP frame as it enters the edge of the MPLS–aware network. This label corresponds to an established (configured/signaled) path through the network, also known as an LSP.
Second, at the time a label is applied to the flow, predefined traffic-engineering parameters can be programmed into the forwarding hardware to guarantee levels of traffic bandwidth, delay variation, and congestion control. Once the data begins to flow, the network device must be able to monitor and report the actual level of resources being consumed at each interface.
MPLS Traffic Engineering
Two different approaches, TE–RSVP and CR–LDP are currently under development by the IETF MPLS Working Group. They characterize the signaling piece of traffic engineering within MPLS. There are two ways to implement an LSP within an MPLS network: control-driven (hop by hop) using LDP and explicitly routed LSP (ER–LSP).
Both TE–RSVP and CR–LDP represent the latter approach. What this implies is that, by having the ability to engineer the route using predetermined CoS and QoS parameters, the optimal LSP for a specific traffic type can be ensured. Further flexibility allows for the definition of loose and strict ER–LSPs. The strict ER–LSP follows a list of nodes using the actual addresses of each node to traverse, while the loose ER–LSP is more adaptive and allows groups of nodes, specified as an autonomous system number, to act as one of the abstract nodes to traverse.
TE–RSVP
MPLS traffic engineering by means of TE–RSVP proposes using extensions to the existing RSVP protocol, request for comment (RFC) 2205. Using TE–RSVP does not mean that a full implementation of RSVP is required to be run on each label edge router (LER) or label switch router (LSR) within an MPLS–aware network. An LER or LSR only requires that the extensions be able to support MPLS–explicit routing. TE–RSVP is a soft-state protocol and uses user datagram protocol (UDP) or IP datagrams as the signaling mechanism for LSP setup communications, including peer discovery, label requests, and mapping and management (see Figure 1).
Figure 1. Example of a Loose Explicitly Routed TE–RSVP LSP
In this example, having used BGP to discover the appropriate egress LER to route the traffic to another autonomous system (AS), the ingress LER initiates a PATH message to egress LER through each downstream LSR along the path. Each node receives a PATH message to remember this flow is passing and thus a path state or session is created. The egress LER uses the RESV message to reserve resources with traffic and QoS parameters on each upstream LSR along the path session. Upon receipt at the ingress LER, a RESVConf message is returned to the egress LER confirming the LSP setup. After the loose ER–LSP has been established, refresh messaging is passed between LERs and LSR to maintain path and reservation states. It should be noted that none of the downstream, upstream, or refresh messaging between LER and LSRs is considered to be reliable, because UDP or raw IP datagrams are used as the communication mechanism.
TE–RSVP feature set is robust and provides significant capabilities to provide traffic-engineering services to MPLS.
- QoS and traffic parameters—These are passed as opaque data to traffic management.
- failure notification—Upon failure to establish an LSP, an existing LSP will send failure message, but relies on timers for refresh messages.
- failure recovery—This is the “make before break” when rerouting.
- loop detection—This is required for loosely routed LSPs only, also supported for repathing.
- multiprotocol support—This supports any type of protocol.
- management—LSP ID identifies each LSP, thereby allowing ease of management to discrete LSPs.
- record route objects—These provide the ability to describe the actual setup path to interested parties.
- path preemption—This is the ability to bump or discontinue an existing path so that a higher priority tunnel may be established.
CR–LDP
CR–LDP builds upon LDP, which is already part of MPLS. Although it is not as mature as RSVP, it does not require the implementation of an additional protocol. It uses existing message structures and only extends as necessary to implement traffic engineering. As with TE–RSVP, CR–LDP supports strict and loose explicitly routed LSPs. UDP is used for discovering MPLS peers and TCP is used for control, management, label requests, and mapping.
Figure 2. Example of a Strict Explicitly Routed CR–LDP LSP
In Figure 2, a strict CR–LDP LSP has been established between ingress and egress LERs in a service provider network. The path has been predetermined for both ingress and egress and is limited to two specific LSRs. The label requests have been passed down to each downstream device in a hop-by-hop fashion to the egress LER, and mapping has been passed upstream in similar fashion to the ingress LER. As shown in Figure 2, the explicit routed path can be so precise as to stipulate the specific LER and LSR IP addresses to be used. This is advantageous, as a particular traffic type (such as voice or VPN) can be matched to the optimal path to leverage bandwidth and prioritization.
CR–LDP traffic-engineering extensions to the LDP feature set are comprehensive and fairly well defined.
- QoS and traffic parameters—These offer the ability to define edge rules and per-hop behaviors based on data rates, link bandwidth, and weighting given to those parameters.
- path preemption—This is the ability to set prioritization to allow or not allow preemption by another LSP.
- path reoptimization—This offers the capability to repath loosely routed LSPs based on traffic pattern changes and includes the option to use route pinning.
- failure notification—Upon failure to establish an LSP, this is the notification provided on TCP with supporting failure codes.
- failure recovery—These are mapping policies for automatic failure recovery at each device supporting an LSP.
- loop detection—This is required for loosely routed LSPs only; LDP already supports loop detection.
- multiprotocol support—This supports any type of protocol.
- management—LSP ID identifies each LSP, thereby allowing ease of management to discrete LSPs.
