Overview of RSVP
Originally, RSVP was designed as a protocol to install resource reservation states for individual data flows along a destination-based routed path (that is, along an IGP path).[1][2] An RSVP session is defined by its destination IP address, IP protocol ID, and optionally by its destination TCP/UDP port. A data flow is a single instance of the application-to-application flow of packets identified by source/destination IP address and port.
Path Message
When a sender application intends to reserve resources for a data flow, it invokes the RSVP module in the source node (a host or router) to originate a Path message toward the downstream node.
The Path message is sent with the same source and destination IP address as the data packets and traverses the same path as the data packets. RSVP messages are encapsulated in IP packets and are routed using destination IP address. An RSVP Path message contains several parameters, such as the following:
• SESSION object (which defines the RSVP session)
• RSVP_HOP object (which contains the IP address of the upstream node sending this message and the logical interface handle LIH of the outgoing interface)
• SENDER_TEMPLATE object (which contains the source IP address and the TCP/UDP port)
• SENDER_TSPEC object (which specifies the traffic parameters such as peak data rate, token-bucket rate, and token burst size)
Path State Block
When an RSVP-capable router receives an initial Path message, it creates a path state block (PSB) for that particular session (see Figure 9-1). Each PSB consists of parameters derived from the received Path message such as SESSION, SENDER_TEMPLATE, SENDER_TSPEC, RSVP_HOP objects, and the outgoing interface provided by the IGP routing. When an RSVP-capable router forwards a Path message, it inserts the IP address of the outgoing interface in the RSVP_HOP object. When the RSVP-capable downstream next-hop router receives the initial Path message, it also creates a PSB, inserts the IP address of the outgoing interface in the RSVP_HOP object, and in turn forwards the Path message to the next-hop downstream router. This process repeats until the Path message arrives at the target receiver. During processing of the Path message, if any errors are encountered on a node along the way, from that node a path error (PathErr) message is generated upstream toward the sender.
Figure 9-1. RSVP Path and Resv Messages and PSB/RSB State Creation
[View full size image]
Upon receipt of an initial Path message, the receiver uses information carried in the Path message (such as traffic parameters carried in the SENDER_TSPEC object) to select the resource reservation parameters.
Resv Message
The receiver initiates a Resv message to request a reservation for a data flow. The Resv message is routed upstream toward the sender along the route taken by the Path message.
The IP source address of a Resv message is the address of the node (a host or router) that originates the message. On the other hand, the IP destination address corresponds to the address of the upstream node from which the associated Path message was received previously. Before forwarding the Resv message upstream, each RSVP-capable node modifies the IP destination address of the received Resv message. The IP destination address is modified to become the address stored in the RSVP_HOP object of the associated PSB. In this fashion, the Resv message is steered upstream along the route that was taken by the corresponding Path message in the downstream direction.
A Resv message carries a SESSION object, a RSVP_HOP object, flow descriptor objects, and a few other objects. Briefly, a RSVP flow descriptor consists of FLOWSPEC and FILTER_SPEC objects. The FLOWSPEC object carries TSPEC (traffic parameters) and RSPEC (requested resource such as bandwidth and delay) parameters. Traffic management procedures (such as connection admission control [CAC] and traffic scheduling) use the TSPEC and RSPEC parameters in nodes along the way to provide the requested quality of service (QoS). The FILTER_SPEC object specifies filters such as IP source address, source port, or other fields in the packet headers to select a subset of packets in a session that are to receive the requested QoS. The FILTER_SPEC is typically used to set parameters in the packet classifier in a node.
Reservation State Block
As a Resv message travels upstream toward the sender, it creates a reservation state block (RSB) in each RSVP-capable node along the way (see Figure 9-1). Each RSB stores information derived from objects in the received Resv message, such as the following:
• SESSION object
• RSVP_HOP object (the IP address of the interface through which the Resv was sent and the LIH on which the reservation is needed)
• FLOWSPEC object
• FILTERSPEC object
• STYLE object (which specifies reservation styles, such as whether the reservation is intended for an individual sender or shared by several senders)
During processing of the Resv message, if any errors are encountered along the way, a reservation error (ResvErr) message is generated and forwarded downstream toward the receiver. The successful propagation of the Resv message to the sender, results in the creation of a reservation state along the IGP routed path of the data flow from the receiver to the sender. RSVP reservation requests are for unidirectional data flows. Because bidirectional flows can travel separate paths in each direction, bidirectional data flows require two separate reservation requests.
Soft State
RSVP uses a soft state model. This means that to maintain the state created by the initial Path and Resv messages, each RSVP-capable node along the path must send Path and Resv refresh messages periodically. The refresh period value is derived from the TIME_VALUES object, which is carried in Path and Resv messages. If a particular node does not receive Path and Resv refresh messages within an associated cleanup time (the lifetime of the state), the node removes the corresponding PSB and RSB state. The RSVP periodic refresh mechanism allows maintaining the soft state and handling the occasional loss of messages caused by the inherently unreliable IP service, as discussed later in the section titled "Lifetime of RSVP-TE State."
Using RSVP in MPLS-TE
The actual use of RSVP in MPLS-TE is quite different from the use that was envisioned at design:
• RSVP in MPLS-TE is used to create a reservation state for a collection of flows (as opposed to individual data flows) that share a common forwarding path and have a common pool of reserved resources.
• RSVP in MPLS-TE not only creates a resource reservation state for an LSP, but also installs its forwarding state.
• The path along which this state is created is no longer restricted to a destination-based routing path; instead, it can be specified explicitly.
• An RSVP session in MPLS-TE is not confined to being used between a pair of hosts, but can also be used for a traffic trunk between a pair of label-switching routers (LSRs).
Using RSVP in MPLS-TE involves exercising mainly existing procedures for resource reservation and extending these procedures for establishing LSPs along explicit paths. The enhanced RSVP protocol, referred to as RSVP-TE, enables a new set of capabilities such as the following:
• Downstream on-demand label distribution
• Establishment of explicitly routed LSPs
• Reservation of resources along the explicit paths
• Rerouting of established LSPs using the make-before-break approach
• Preemption of a lower-priority LSP by a higher-priority LSP
The RSVP-TE specification[4] defines several new objects such as the LABEL_REQUEST object for requesting a label from the downstream LSR, the LABEL object for distributing an MPLS label to the upstream LSR, the EXPLICIT_ROUTE object (ERO) for specifying the explicit path, and the RECORD_ROUTE object (RRO) for recording detailed path information.
Generalization of the Flow Concept
A distinct aspect of RSVP-TE usage involves generalization of the notion of a flow as defined in the original RSVP specification. In RSVP-TE, a session can have an arbitrary aggregation of traffic flows (a traffic trunk) between the originating and terminating LSRs of the LSP. More precisely, the original RSVP specification defines a session as a data flow with a particular destination IP address and TCP/UDP port. In contrast, an RSVP-TE session is implicitly defined as a group of packets that are assigned the same label at the originating LSR of an LSP. The labels-to-packets mappings may be based on local policy (for example, using filters based on a packet header) and may include a subset of packets or even all packets between the LSP endpoints.
LSP Tunnel
The set of packets assigned the same label at the ingress LSR of an LSP is said to belong to the same forwarding equivalency class (FEC), and the label is said to define an RSVP-TE flow through the LSP. When a traffic trunk is mapped onto an LSP in this manner, it is called an LSP tunnel or just a tunnel. As depicted in Figure 9-2, MPLS-TE LSP tunnel is unidirectional, originates at the ingress LSR (known as the head end), passes through one or more transit LSRs (known as the midpoint), and terminates at the egress LSR (known as the tail end). A tunnel is characterized in terms of its ingress and egress LSRs, the FEC that is mapped onto it, and a set of attributes (such as traffic parameters, path selection, preemption, and re-optimization) that determine the tunnel's behavioral characteristics.
Figure 9-2. Tunnel Head End, Midpoint, and Tail End
[View full size image]
LSP_TUNNEL Objects
To support the aforementioned LSP tunnel features, the RSVP-TE specification has defined several new RSVP objects, including the SESSION object, the SENDER_TEMPLATE object, and the FILTER_SPEC object. The new objects are collectively referred to as LSP_TUNNEL objects. The SESSION object contains the following:
• A tunnel endpoint IP address (tunnel's egress LSR).
• A 16-bit tunnel ID that remains constant over the life of the tunnel.
• A 32-bit extended tunnel ID that is normally set to zero. However, the ingress LSR might set the ID to its IP address to narrow the scope of a session to the ingress-egress LSR pair.
In MPLS-TE applications, it is often desirable (as during LSP rerouting, for example) to associate multiple LSPs with the same tunnel endpoints (see Figure 9-2). In this case, the SESSION object together with the SENDER_TEMPLATE (or equivalently FILTER_SPEC) object uniquely identifies an LSP tunnel. The SENDER_TEMPLATE object contains the tunnel sender node's IP address and a 16-bit LSP ID that can be dynamically changed to allow a sender to share reservation resources for a new LSP with its older instance (for example, during LSP re-optimization using make-before-break). In short, five-tuples including tunnel endpoint address, tunnel ID, extended tunnel ID, sender node address, and LSP ID uniquely identify an LSP tunnel.
SESSION_ATTRIBUTE Object
To specify tunnel preemption priority and other attributes, the RSVP_TE specification has defined a new object class known as SESSION_ATTRIBUTE. Briefly, this object contains tunnel resource affinity filters (such as exclude-any, include-any, include-all) for including or excluding a link during path selection, tunnel setup, and holding priority. The object also contains the following types of flags:
• Local protection desired To protect an LSP against a link or node that uses a backup tunnel.
• Label recording desired To have LSRs along the LSP path record their labels in the RRO.
• SE style desired A shared explicit (SE) reservation style allows a receiver to explicitly specify the list of senders that can share the same reservation pool.
Because each sender is explicitly specified in the Resv message, even though different labels may be assigned to different senders to create separate LSPs, there is a single reservation for all senders on any common link. This is an extremely useful feature for LSP rerouting because it avoids double counting of the reservations on links that are common to the old and new LSPs. In addition to the new objects, RSVP_TE specification has also defined new error messages to signal notification of exception conditions, such as "Bad ERO object," "MPLS label allocation failure," "Tunnel locally repaired," and so forth.
To establish an explicitly routed LSP tunnel, the head-end LSR originates a Path message with the ERO to steer the Path message along the desired path. The head-end LSR also inserts the LABEL_REQUEST object in the message to solicit label mapping for the RSVP-TE session from the LSRs along the path. The head-end LSR builds an ERO based on a user-specified path or computes it automatically using an enhanced TE topology database. For further information on distinct aspects of MPLS-TE application such as TE topology database construction, path calculation, LSP re-optimization, and local protection.
Specifying ERO
An ERO can be specified strictly or loosely. A strict ERO specifies all nodes along the path, whereas a loose ERO specifies only a few nodes. The loose ERO object is typically used when the head-end LSR does not have the complete path information (as, for example, in the case of inter-autonomous system TE.
When a downstream LSR receives an initial Path message, it creates a PSB, stores the ERO in the PSB, and forwards the message to the next-hop LSR indicated by the ERO. If an LSR receives a loose ERO that needs to be expanded, the LSR stores both the loose as well as the expanded ERO in the PSB. As the Path message travels along the explicit path, it creates a PSB in each LSR along the way. When the Path message with a LABEL_REQUEST arrives at the tail-end LSR, it creates an RSB, assigns a label for the session and stores it in the RSB, installs it as the incoming label in the associated LSP forwarding state, inserts the assigned label in the LABEL object, and responds with a Resv message upstream.
When an upstream LSR receives an initial Resv message containing a LABEL object, it performs the following functions:
• Creates an RSB and stores the received label in the RSB
• Installs the received label as the outgoing label for the LSP
• Allocates a new label and inserts it in the LABEL object and stores it in the RSB
• Installs the allocated label as the incoming label for the LSP
• Sends the Resv message upstream
As the Resv message propagates upstream along the explicit path, it creates the RSVP and LSP forwarding state in each LSR along way. Moreover, as the Resv message propagates upstream, each LSR along the path performs a connection admission control (CAC) check (for example, to check whether the requested bandwidth is available) and reserves the requested amount of bandwidth. Each LSR manages its local outgoing link resources by maintaining available bandwidth pools at multiple priority levels. An LSP tunnel is said to be established when the associated Resv message arrives at the head-end LSR.
RECORD_ROUTE Object
RSVP-TE uses the RECORD_ROUTE object (RRO) to detect Layer 3 routing loops and forwarding loops inherent to the explicit path. By including RRO in the Path message and setting the appropriate flags in the SESSION_ATTRIBUTE object, a head-end LSR can discover detailed path information such as nodes that are being traversed, labels that are being used by nodes along the path, and whether local link/node protection is available along the path.
Initially, at the source node, RRO contains only one subobject that records the sender node's IP address. As the Path message propagates downstream, each node stores a copy of RRO in the PSB, records its IP address, attaches a new subobject to the RRO, and forwards the Path message to the next node. When the Path message finally arrives at the tunnel endpoint, the egress LSR adds the RRO to the Resv message and forwards it upstream. The RRO in the Resv message records the path in the reverse direction. If the Label Recording Desired flag is set in the SESSION_ATTRIBUTE object, each node also inserts its label in the RRO. As the Resv message travels upstream, each LSR stores a copy of the RRO in the RSB. In this manner, each LSR has the complete LSP path information from head to tailhead end to itself by means of the RRO received in the Path message and tail end to itself by means of the RRO received in the Resv message.
RSVP-TE Soft State
Similar to the original RSVP protocol, the RSVP-TE state must also be refreshed periodically. In the RSVP-TE, with the exception of LABEL_REQUEST and LABEL objects, all other new objects are optional. Therefore, in addition to the mandatory objects as defined in the original RSVP specification, the RSVP-TE Path refresh message must also contain the LABEL_REQUEST object. The RSVP-TE Path refresh message may also contain additional optional objects such as ERO and RRO, as appropriate. Similarly, an RSVP-TE Resv refresh message must contain the LABEL object and other optional objects, as appropriate.
Lifetime of RSVP-TE State
RSVP messages are transmitted using unreliable IP datagram transport. Each RSVP node periodically transmits Path and Resv messages to handle occasional loss of RSVP messages. The Path and Resv messages contain a TIME_VALUES object that specifies the value for the refresh period (R) used by the sender of the message. When a node receives initial Path and Resv messages and creates an RSVP state, the node uses the value of R to determine the value for the lifetime (L) of the state (the maximum time period for which the node will retain the RSVP state if no refresh messages are received from the neighbor). Therefore, depending on the duration of the lifetime, a node can tolerate the loss of periodic refresh messages. For example, if the effective lifetime is set to K times, and the refresh timeout period to R, RSVP can tolerate (K 1) successive RSVP packet losses without falsely deleting state. To avoid premature loss of RSVP state due to loss of (K 1) successive refresh messages, RFC 2205 recommends that L be set to at least (K + 0.5) * 1.5 * R. For example, if a node selects a value of 3 for K and receives a value of 30 seconds for R from a neighbor, that node should be able to retain the RSVP state for at least 52.2 seconds without receiving refresh messages from the neighbor.
On the one hand, a longer lifetime value allows a node to tolerate loss of a greater number of RSVP messages. On the other hand, it increases the time to detect a neighbor failure. For example, if the absence of refresh messages were not caused by the loss of messages but was actually caused by a neighbor failure, it would take a long time (in the order of minutes) for the node to detect the neighbor's failure and remove its RSVP state. This means that data traffic destined for the failing neighbor will be black holed for a long time. The prolonged packet loss is generally not acceptable for many applications (such as Voice over IP) that typically require packet loss to be limited to tens of milliseconds.
The necessity to refresh soft state means that depending on the number of established LSPs, a large number of refresh messages must be generated, transmitted, and processed. The RSVP refresh reduction extensions, however, address most of concerns about RSVP state refresh overhead and unreliable message delivery.[3] For example, these extensions define a new MESSAGE_ACK object for detecting a message loss and a new message (called SUMMARY REFRESH message) for reducing the overhead of transmitting and processing state refresh messages. However, this does not address the issue of detecting node failure quickly.
The following section describes a mechanism by which a node can detect RSVP failures rapidly and yet still allow use of relatively large values for the refresh period to reduce the frequency of refresh messages.
Detecting RSVP-TE Failures
RSVP-TE specification also defines a new Hello message for rapid detection of node and RSVP control-channel failures. Node failures differ from control-channel failures as follows:
• Node failure A failure in which a node loses its control plane (or a component of the control plane such as the RSVP-TE component), but its forwarding plane continues to function as normal
• Control-channel failure A failure in which a node loses its control channel (when an RSVP communication link goes down, for example) to a neighbor, but the node otherwise continues to function correctly (for example, the node's control plane and forwarding plane remain unaffected)
The RSVP-TE Hello extension consists of a Hello message, a HELLO_REQUEST object, and a HELLO_ACK object. The HELLO_REQUEST and HELLO_ACK objects contain source instance (Src_Instance) and destination instance (Dst_Instance) fields. Src_Instance is a 32-bit field in which a sender advertises a unique instance value to an RSVP neighbor. A separate (unique) instance value is maintained for each RSVP neighbor. After a sender has advertised a nonzero source instance value to a neighbor, the node must not change this value unless it has restarted or its RSVP communication to the neighbor has been lost.
Dst_Instance is a 32-bit field in which a node reflects the last received Src_Instance value from a neighbor. If a node has not received any Src_Instance value from a neighbor, it sets the Dst_Instance field to 0. To detect a neighbor's control-plane or control-channel failure, a node collects and stores the Src_Instance value received from the neighbor and monitors its own Src_Instance values reflected back by the neighbor in the Dst_Instance field.
To monitor the status of a neighbor, a node periodically (at every Hello interval) sends Hello messages with request objects to the neighbor. Another mechanism, known as bidirectional forwarding detection (BFD). BFD can be used to detect failures on the forwarding-plane path. The neighbor is expected to respond with a HELLO_ACK object. On receipt of the HELLO_ACK object from the neighbor, the requesting node compares the new received Src_Instance value with the previous value. The requesting node presumes that the neighbor has failed if any of the following conditions apply:
• The newly received Src_Instance (a nonzero value) differs from the previous value.
• The neighbor is not reflecting back the correct requesting node's Src_Instance value.
• The requesting node does not receive any response from a neighbor within a configured period (by default, 3.5 Hello intervals). For example, if the Hello interval is set to 50 milliseconds, the node can detect a neighbor failure within roughly 175 milliseconds.
For further details on the Hello mechanism, refer to the RSVP-TE specification.[4]
