Table of Contents:

Definition and Overview

1. Introduction

2. MPLS Overview

3. A Technical Discussion of MPLS Traffic-Engineering Initiatives

4. Conclusion

Self-Test

Glossary

PDF of this tutorial

Label Switching

A session or flow is defined as a series of IP datagrams that share a common destination IP address and traffic-engineering characteristics. Both CR–LDP and TE–RSVP provide a mechanism to map these sessions to LSPs traveling through the network. At the ingress point, the LSR assigns a label, corresponding to an LSP, to each IP datagram as it is transmitted toward the destination. Thereafter, at each corresponding hop, the label is used to forward the packet to its next hop. Both CR–LDP and RSVP create LSPs by first sending label requests through the network hop-by-hop to the egress point. At each hop, the MPLS–enabled router uses the label and its corresponding IP header information to program the hardware (or firmware) to switch the frame to its next hop. While the actual algorithms may be different, the end result of both signaling protocols is to establish an internal cross-connect from the ingress interface to the egress interface inside the LSR.

Scalability (Hard versus Soft State)

Today’s routers must receive and process greater and greater numbers of frames. To accomplish this and not cause data bottlenecks, less time must be spent processing each IP frame. As mentioned above, label switching decreases the time required to analyze each IP datagram as it forwards it through the router. Some additional overhead is incurred while creating, maintaining, and destroying the information needed to establish the switched paths. However, this is minimal compared to traditional IP header processing. In networking jargon, the CR–LDP LSP setup is referred to as hard state. This means that all the information is exchanged at the initial setup time, and no additional information is exchanged between routers until the LSP is torn down. When the network management system or other entity determines that the LSP is no longer needed, messages must be exchanged notifying all routers that the resources should be reclaimed. This reclamation process is infrequent and consumes minimal bandwidth and CPU resources.

Conversely, TE–RSVP is referred to as a soft-state protocol. After an initial LSP setup process that is similar to CR–LDP, refresh messages must be periodically exchanged between peers to notify the peers that the connection is still desired. If the refresh messages are not exchanged, a maintenance timer senses the connection is dormant and deletes the state information, returns the label, and reserved bandwidth to the resource pool and notifies the affected peers. The soft-state approach can be viewed as a self-cleaning protocol because eventually all dormant or expired resources are reclaimed. As with CR–LDP, RSVP usually explicitly destroys or tears down LSPs when the network management system decides that the switched path is no longer desired.

Opponents of RSVP point to the soft state refresh overhead as a fundamental weakness in the protocol and therefore not scalable. RFC2208 states that "the resource requirements for running RSVP on a router increase proportionally with the number of RSVP sessions. Supporting numerous small reservations on high-bandwidth links can easily overtax the router and is inadvisable." Contributors to the IETF have taken steps to address this by adding extensions to the RSVP protocol. These extensions combine summarization information with newly defined RSVP objects that are sent inside standard RSVP messages.

To reduce the volume of chatter between two nodes, an RSVP node can group a number of RSVP refresh messages into a single message. This message is sent to the peer router where it is disassembled and each refresh message is processed. This process is referred to as bundling. In addition to bundling messages, the MESSAGE_ID and MESSAGE_ID_ACK objects have also been added to the protocol. These objects are used to hold sequence numbers corresponding to previously sent refresh messages. While the peer router receives a refresh message with a nonchanging Message ID, it assumes that the refresh state is identical to the previous message. Only when the Message ID value changes must the peer router interrogate the actual information inside the message and act accordingly. To further enhance the summarization process, sets of Message IDs can be sent as a group to the peer router in the form of summary messages.

While this strategy will substantially decrease the time spent exchanging information between peer routers, it does not eliminate the computing time required to generate and process the refresh messages themselves. Time must still be spent checking timers and querying the state of each RSVP session. In short, the criticism surrounding the scalability of RSVP has been addressed, although not completely solved.

While CR–LDP appears to have the advantage of hard state for scalability, it is not without its own set of unique challenges. CR–LDP is based on the concept of an LDP entity. Once two LDP peers or entities have discovered each other, a TCP/IP session is established between them. From that point on, all control plane messages used to establish and maintain LSPs must travel through this reliable transport. As currently written, the MPLS specification requires that all LSPs associated with a particular session must be destroyed if the TCP session is torn down or fails. If hundreds or perhaps thousands of LSPs have been previously established between two LSRs, the impact to the network can be substantial. Members of the IETF are working on proposing solutions to this issue. Conversely, because an RSVP tunnel is a separate entity unto itself, any catastrophic change in its session state is local to itself.

Security and Reliability

As mentioned above, one of the benefits of the MPLS architecture is its well-defined separation of the routing decisions and forwarding of the data. Once the path has been established and the data is being forwarded (or switched) in the device’s hardware, the frame is no longer promoted up to the upper layers and visible to the software. There is minimal chance that unauthorized individuals will be able to sniff the data or redirect the flow from its intended destination. Data is only allowed to enter and exit the LSP at locations authorized and configured by the MPLS control software (control plane). This minimizes the possibility of certain types of spoofing and flooding attacks possible in non–MPLS–controlled IP networks. Furthermore, CR–LDP uses a TCP/IP connection, thus offering a reliable and more secure connection between peers. The LDP and TE–RSVP specification also supports the use of MD5 signature password support to further ensure that the TCP/IP session is secure.

The TCP/IP connection capabilities also offer timely error notification if there is a communication failure between peers. This notification can then be quickly reported to the local network management system so that appropriate actions can be initiated. The sensing MPLS router can then initiate LDP withdraw and release messages to peers so that recovery actions can begin in earnest.

RSVP, on the other hand, uses UDP and raw IP datagrams to communicate between peers. This raises two reliability concerns: vulnerability to security attacks and fast recovery. While IPSec and other encryption or authentication schemes can be used to guarantee valid RSVP PATH and RESV messages, spoofing attacks could impair performance of TE–RSVP. Furthermore, connection failure will only be detected after a TE–RSVP neighbor fails to receive a refresh message from one of its peers. Depending on the configured refresh time intervals, the detection could take seconds or possibly minutes before recovery actions can be initiated at the end nodes of the affected LSP.

Data Aggregation—Support for Fine- and Coarse-Grained Flows

From its inception, LDP has been designed to establish switched paths that service a single IP host or an aggregation of thousands. The term used for this capability in the MPLS documents is forward equivalency class (FEC). Each FEC is specified as a set of packets that are mapped to a corresponding LSP. An IP address prefix describing an entire IP subnet can be designated as the destination of the LSP or FEC. As such, all traffic with destination IP host addresses inside that one subnet can travel through a single LSP. CR–LDP combines this addressing flexibility with the concept of differentiated services. At ingress, the LSR can assign a certain set of traffic parameters or constraints to be applied to each packet as it traverses the network. The combined concepts of FECs and differentiated services make it possible to aggregate traffic at the core of carrier backbones.

RSVP on the other hand, was initially designed to offer reserved bandwidth capabilities to a single IP address. RFC2205 describes an RSVP session as defined by its triple: DestAddress, Protocol ID, DestPort. The term microflow is used to describe a session containing a single IP host address as its destination. Clearly, modifications were required to address the needs in the core of the network. Recently a new Internet draft has been submitted to the IETF MPLS Working Group to address this issue of supporting differentiated services in networks using TE–RSVP. More work is expected to follow.

Minor Differences of Interest

There are a number of minor differences between CR–LDP and TE–RSVP that are of interest. They are listed here to give the reader a better understanding of how to determine the best MPLS signaling protocol.

Upon discovering an LDP peer, a TCP/IP session is established for the reliable exchange of control information. Each peer submits its type and range of labels to be used to establish LSPs. The LDP session chooses an intersection of the two ranges. If there is no set of labels that intersect, the session is torn down. With RSVP, there is no negotiation of label space; such space must be configured via network management. If the network is very large or contains a larger number of heterogeneous interfaces, the effort to configure the labels could be considerable.

CR–LDP can specify the source route for an LSP by including an explicit route TLV in the label request message. TE–RSVP also has the ability to supply the same routing information with its explicit route object. Both support the concept of loosely routed paths. These are paths that can pass through a given network where any number of nodes might serve as the transit node. Both TE–RSVP and CR–LDP will respond back to the ingress the success or failure of the setup. Both CR–LDP and TE–RSVP allow route pinning. This term refers to the ability to force an LSP to stay in place after setup and not be rerouted by preemption. In CR–LDP, the act of pinning can only take place at setup time, but RSVP can set up pinning by modifying the PATH messages at any time.

The RSVP record route object can be used to request that the list of nodes actually involved in the path setup be reported back to the ingress. This can assist the network administrator when gathering information on network status and troubleshooting. CR–LDP does not have any way to request the trace route for an established LSP. See Tables 1 and 2 for an explanation of the similarities and differences between TE–RSVP and CR–LDP.