7.4. RSVP and RSVP-TE

7.4.1. RSVP

7.4.1.1. BASIC MODEL

RSVP was developed to support integrated services (i.e., packet delivery with Quality of Service (QoS) requirements) in the Internet. It is an IETF standard, described in RFC 2205 [Braden+97]. RSVP, in essence, is a signaling protocol. Using RSVP, a source IP host (sender) sends a message to a unicast or a multicast IP destination indicating the characteristics of the traffic it will generate. This message is processed by routers in the path from the source to the destination(s) (receivers). These routers make note of the reverse path to the sender. Based on the received traffic characteristics, each receiver formulates a reservation request and transmits it to the sender. This request traverses the reverse path maintained by the network routers. Each router along the way processes the reservation request and allocates local resources on the link leading toward the receiver. Thus, unidirectional resource reservation, from the sender to the receiver(s), is established in the network.

RSVP was designed to support both point-to-point and multicast traffic. The adaptation of RSVP, however, for traffic engineering purposes has focused only on the point-to-point application. Thus, in this section, we limit our discussions to the point-to-point case only.

It should be noted that RSVP does not provide route computation functionality. Typically, an IP routing protocol computes forwarding tables, using which RSVP messages are forwarded from the sender to the receiver. RSVP runs directly over IP, with IP protocol number 46. RSVP interactions are between neighboring RSVP-capable entities, called RSVP peers. Under RSVP, unidirectional reservations are made for “sessions,” that is, traffic flow to a specific destination. The RSVP model is shown in Figure 7-11. Here, the RSVP process (called RSVP Daemon) communicates with its peer over IP. This process at each node (host or router) interacts with the packet filtering (denoted as classifier) and the scheduling modules to establish the appropriate QoS treatment to enforce reservations. In addition, the RSVP process at a router interacts with the routing protocol to determine the next hop to forward an RSVP message.

7.4.1.2. RSVP MESSAGES AND OBJECTS

RSVP defines seven messages:

The Path and the Resv messages are used for establishing reservations for a session. The PathTear and ResvTear messages are used to delete the session state (and the reservation). PathErr and ResvErr are error notification messages. Finally, ResvConf is sent to a receiver to confirm a reservation. Before we describe the usage of these messages for establishing and deleting reservations, it is useful to look at the content of these messages. In aid of this, Figure 7-12 illustrates the RSVP message format. It is seen that RSVP messages carry objects, whose format is shown. The value in the Message Type field of the RSVP common header corresponds to the number indicated above for each message. The objects are coded in a hierarchical way; the Class Number identifies a broad class of similar objects and the Class Type identifies a specific object within the class. The Checksum field in the header covers the entire RSVP message, and the SEND_TTL field contains the IP Time To Live value with which the message was sent (see [Braden+97] for the usage of this field).

The key RSVP objects are as follows.

Session

Conceptually, a session is a uniquely identifiable traffic flow. Under RSVP, reservations are made on a session basis. The session identification consists of the receiver's IP address, protocol ID, and port. This is carried as a “session object” in RSVP messages. The format of this object, for an IPv4 destination, is shown in Figure 7-13 (the other possibility is an IPv6 destination, see [Braden+97]). Note that the identity of the sender is not part of the session identification.

Sender Template

The Sender Template identifies the sender of a flow. The format of this object, for a sender with an IPv4 address, is shown in Figure 7-14. The reason this is called a “template” is that the same format is used as a filter to select those packets that receive the QoS treatment (see Filterspec below).

Sender Tspec

The Tspec indicates the traffic characteristics of the flow being generated by a sender. RSVP itself does not interpret or use this object, but it merely carries this object opaquely. The IETF Integrated Services working group has defined Tspec parameters for different service classes to be used with RSVP [Wroclawski97]. The Tspec is carried from the sender to the intermediate routers, and finally to the receiver.

Flowspec

The Flowspec describes the reservation request. This is carried in Resv messages, from the receiver toward the sender. Intermediate routers use the flowspec to make the reservation. As in the case of the Tspec, RSVP does not interpret or use this object, but delivers it to various nodes.

Filterspec

The Filterspec describes the packets that are to receive the QoS treatment in each node along the path from the sender to the receiver in a given session. The Filterspec is used to set up the packet classifier in each node (see Figure 7-11). The format of the Filterspec object is same as that of the Sender Template.

In addition to these objects, RSVP defines several “reservation styles.” A reservation style indicates whether the reservation is dedicated to a flow from a single sender to the receiver, or it is shared among multiple flows from possibly different senders to the same receiver. The typical application in traffic engineering uses dedicated reservation for traffic flows from a single source to a given destination. Hence, we will not consider reservation styles further. The interested reader is referred to [Braden+97].

7.4.1.3. ESTABLISHING A RESERVATION: PATH AND RESV

The manner in which a reservation is established for a session using RSVP is shown in Figure 7-15. Here, a network of two hosts and five routers is shown. The Path message is originated by the sender host. As shown in Figure 7-16,^[4] the Path message contains the identity of the receiver (i.e., Session), the identity of the sender (Sender Template), and the traffic characteristics (Sender Tspec). Recall that RSVP messages are directly carried in IP packets. The IP packet carrying the Path message is addressed directly to the receiver (i.e., receiver's IP address is used as the destination address). This packet follows the normal route to the destination. Each intermediate router that receives the packet, however, creates the Path State for the session in a local database, before forwarding the packet to the next hop. The Path State consists of the received Sender Template, Sender Tspec, and Session information, along with the identity of the previous hop toward the source. This previous hop information is received in the RSVP Hop object, as indicated in Figure 7-16. This object, as shown in Figure 7-17, has two fields: the IP address of the previous router that forwarded the Path message, and the outgoing interface id (called Logical Interface Handle, LIH) at that router. Each router that forwards the Path message must replace the received RSVP Hop object with a new one containing its own IP address and the identity of the interface over which the packet is forwarded. The message finally reaches the receiver, which also must create the local Path state.

^[4] Optional objects in the Path message are not shown.

The receiver utilizes the Tspec information in the Path message to formulate a reservation request. It then sends a Resv message to the previous hop in the path. The IP address and the LIH information gathered from the RSVP Hop object in the Path message allow the receiver to determine which local interface should be used to send the Resv message and to which next node the IP packet (carrying the Resv message) must be addressed. A question may arise as to why the Resv message cannot be addressed directly to the sender as the Path message was addressed to the receiver. The problem is that in IP networks, the route from the sender to the receiver may not be the same as the route from the receiver to the sender. Since the reservation is unidirectional from the sender to the receiver, it is necessary for the Resv messages to progress along the same path in reverse as the Path message. Thus, the Resv message is sent hop by hop from the receiver to the sender using the previous hop information stored in each intermediate node.

The contents of the Resv message are shown in Figure 7-18.^[5] This message has the Session, the Reservation Style, the Filterspec, and the Flowspec objects. Additionally, the RSVP Hop object is used to indicate the node that sent the message. A router that receives the message creates the local Resv State, that is, the received Flow and Filterspec information are noted, along with the RSVP Hop information. Furthermore, the Flowspec is used to configure the local packet scheduler corresponding to the appropriate outgoing link, and the Filterspec is used to configure the packet classifier to enforce the reservation for the indicated session. The router then forwards the Resv message to the previous node in the path from the sender, after replacing the RSVP Hop object with its own information. The Resv message finally reaches the sender, which must also make local resource reservation for the flow.

^[5] Optional objects in the Resv message are not shown.

Once a reservation has been established, the data packets can flow from the sender to the receiver. Because the packet classifier and scheduler have been properly configured on the data plane, the traffic flow will receive the appropriate treatment. A question may arise as to what happens when a routing change occurs in the network. Note that the Path message and the data packets constituting the traffic flow, are routed along a path determined by normal destination-based IP routing. But IP routing is dynamic, that is, a failure in the network can result in new routing table entries corresponding to the receiver's address. If this happens, subsequent data packets from the sender will be routed over a new path that does not have resources reserved.

7.4.1.4. THE SOFT STATE APPROACH

In traditional connection-oriented networks, a disruption in the connection path would result in the reestablishment of the connection along a new path before data flow resumes. An example is the telephone network. If a call is dropped in the middle of a conversation (which happens frequently with cellular telephones), the user must redial the call before carrying on the conversation. This approach is referred to as the hard state approach, that is, the establishment and maintenance of an explicit connection. This is also the approach followed in optical networks. RSVP, however, follows the soft state approach. Under this method, Path and Resv messages are not transmitted reliably, that is, there is no acknowledgment message when a node sends a Path or Resv message to another. Instead, Path and Resv messages are regenerated periodically by each node with “active” Path and Resv states, respectively. This is referred to as refreshing the state, and the regenerated messages are called refresh messages. The state at a node is considered active if it has been refreshed recently. A Path message thus generated is identical to the original Path message, except it is forwarded to the destination using the currently available IP routing information. The refresh Resv message is identical to the one originally generated by the node, and it is forwarded to the previous node as per the RSVP Hop information kept in the corresponding Path state. A node deletes its Path or Resv state if it does not receive a refresh Path or Resv message, respectively, from the appropriate RSVP peer. When the Path state is deleted, the associated Resv state is also deleted, and a PathTear message is generated. When Resv state is deleted, the corresponding Path state is not deleted. A ResvTear message, however, is generated (see below). This soft state approach allows routing changes to be accommoda ted automatically. If the route changes, the next refresh Path message would follow the new route and establish new Path state (and the corresponding Resv state).

The Time Values field in the Path and Resv messages (Figures 7-16 and 7-18) indicates the refresh time period that will be used by the sender of the message. This allows the receiver of the message to set the time-out period to remove the Path or Resv state. The refresh time period is specified in milliseconds as a 32-bit number.

7.4.1.5. DELETING A RESERVATION: PATHTEAR AND RESVTEAR

A reservation at a node can be deleted in one of the two ways: implicitly when the Path or the Resv state is timed out, or explicitly when a PathTear or a ResvTear message is received. A sender (or an intermediate router) can generate a PathTear message (Figure 7-19^[6]) to delete the Path state of a session. As described in the last section, when the Path state is removed at a node, the Resv state is also removed. The PathTear message, like the Path message, is addressed to the receiver of the data flow. An intermediate router that receives the PathTear message removes the local Path and Resv state (it does not generate a ResvTear, however). A PathTear message is not transmitted reliably. If the message is lost, the intended next hop node will eventually time-out and delete its Path and Resv states, as described before.

^[6] Optional objects are not shown.

The receiver (or an intermediate router) can generate a ResvTear (Figure 7-20^[7])to remove the reservation corresponding to a session. The ResvTear, like Resv messages, is transmitted hop by hop. The reception of a ResvTear by a node results in the removal of only the Resv state for the session. The Path state is maintained. Like the PathTear message, ResvTear is not transmitted reliably.

^[7] Optional objects are not shown.

7.4.1.6. PATH AND RESV ERRORS, AND RESERVATION CONFIRMATION

The PathErr and ResvErr messages are used to indicate error conditions. The PathErr message is sent from an intermediate router to the sender using the previous hop information. Other nodes en route do not change their Path state based on this. The ResvErr is sent from an intermediate router to the receiver. Nodes en route may change their Resv state based on this. The PathErr and ResvErr messages contain error codes indicating the problem.

The ResvConf message is sent from the sender or an intermediate router to the receiver to confirm the establishment of the reservation.

These three messages are not central to the discussion that follows. Thus, we do not consider them further. For details on these messages, please refer to [Braden+97].

Finally, although our description so far has focused on the sender and the receiver being hosts, it is possible for the sender and receiver to be routers.

7.4.2. RSVP-TE

RSVP was designed to be a protocol to reserve resources along a preexisting path. With the advent of MPLS-based traffic engineering, there was a desire to reuse the available RSVP implementations to support the creation, maintenance, and deletion of LSPs. The result was RSVP with traffic engineering extensions, or simply, RSVP-TE. These protocol extensions are described in IETF RFC 3209 [Awduche+01b].

The key features of RSVP-TE are:

• The usage of the Path and Resv messages to request and assign labels for LSP establishment

• The ability to specify an explicit route when establishing or rerouting an LSP

• The ability to specify bandwidth and other parameters when establishing an LSP

• The ability to associate related LSPs

• A new Hello protocol for maintaining the adjacency between RSVP peers

The RSVP-TE specification uses the term “LSP tunnel” to denote point-to-point LSPs with or without associated QoS parameters. A number of new objects are introduced in RSVP-TE to support the above features. These are described next, followed by a description of how these objects are used in RSVP-TE to create, maintain and delete LSP tunnels.

7.4.2.1. RSVP-TE OBJECTS

These are as follows:

• Label request

• Label

• Explicit route

• Record route

• LSP tunnel identification in session, sender template, and Filterspec objects

• Session attributes

Label Request

The Label Request object is carried in the Path message. As the name implies, it is used by an upstream node to request a label from the downstream neighbor for the LSP tunnel being established. Under RSVP-TE, three types of labels may be requested: the 20-bit MPLS label, an ATM label within a specified range, or a frame relay label within a specified range. Figure 7-21 illustrates the Label Request object corresponding to the MPLS label. Here, the L3-PID field indicates the type of the layer 3 protocol data units (e.g., IP) that will be carried by the LSP. The other two Label Request object formats are described in [Awduche+01b].

Label

The Label object is carried in Resv messages upstream. This object indicates the label that has been assigned by the downstream neighbor in response to a label request received in the Path message. The format of the Label object is shown in Figure 7-22. The 32-bit label field is wide enough to carry the 20-bit MPLS label, as well as ATM and frame relay labels.

Explicit Route

The Explicit Route Object (ERO) is carried in Path messages during LSP establishment or rerouting. There are basically three kinds of explicit routes:

The format of the ERO is shown in Figure 7-23. It is a sequence of sub-objects, each sub-object being an IPv4 prefix, an IPv6 prefix, or an AS number. The L bit indicates whether a sub-object indicates a loose hop. With this format, an ERO can be strictly one of the above three types, or it can be a mix of these. For instance, part of the ERO can be a strict sequence of nodes, and a part can be loose, some of them being autonomous systems. The format of the IPv4 ERO sub-object is also shown in Figure 7-23. Here, the IPv4 address field could contain an IP address prefix of length less than 32 bits. Such a prefix is possible when the ERO hop is loose. The prefix length field indicates this.

With the ERO being present in Path messages, the forwarding of these messages is now different from the way they were handled under RSVP. Suppose a node receives a Path message with an ERO in which the node is listed in the first sub-object (a strict hop to this node from the previous node). It determines the next node to forward the message as follows:

This description is a simplification of the actual procedures that may be employed in processing an ERO. More details are given in [Awduche+01b].

Record Route

The Record Route Object (RRO) is carried in Path messages. It is used to record the actual sequence of nodes (or interfaces) traversed by an LSP being established. The label assignment on various hops may also be recorded. This object provides a way to monitor the paths of LSPs, as well as to detect loops when loose explicit routing is used to set up LSPs. This object is not central to the discussion that follows, and hence we do not describe it further here. The interested readers can refer to [Awduche+01b].

LSP Tunnel Identification

LSP tunnel identification is treated separately for IPv4 and IPv6 addressing. In the following, we consider only the IPv4 case. The IPv6 formats can be found in [Awduche+01b].

The LSP tunnel is identified as a new sub-object under the session object. The format of this object (denoted as LSP Tunnel IPv4 Session object) is shown in Figure 7-24. Here, the IPv4 tunnel end point address indicates the address of the egress node (destination) at which the LSP tunnel terminates. The tunnel ID is a 16-bit number assigned by the source. The extended tunnel ID is an additional 32-bit field that can be optionally used to expand the tunnel ID field. The typical use is to place the IP address of the source here.

The LSP Tunnel IPv4 Session object can be roughly considered the equivalent of the call identifier described in section 7.2.2.2. This object can be common across multiple related LSPs, thereby providing the LSRs in the network a means to associate these LSPs. This association is useful in certain applications such as non-disruptive modification of LSP bandwidth. This is described further in [Awduche+01b].

The equivalent of the connection identifier described in section 7.2.2.2 is the LSP identifier. This identifier is carried in the Sender Template object as a sub-object. This new sub-object is called LSP Tunnel IPv4 Sender Template object, and its format is shown in Figure 7-25. The LSP identifier is a combination of the IP (v4) address of the source and a 16-bit suffix (denoted as LSP ID) assigned by this source. The same format is used to define the LSP Tunnel IPv4 Filterspec, which is sent in Resv messages to identify the specific LSP to the packet classifier function. Two LSPs between the same source and destination pair may have the same values for the LSP Tunnel IPv4 Session object (the call ID) while having distinct values for the LSP identifiers (the connection IDs).

Session Attributes

The session attributes object is carried in Path messages. It describes further parameters related to the session in addition to the QoS parameters described in the Tspec. There are two formats defined for the session attributes, one of them a superset of the other. This is the format illustra ted in Figure 7-26. Here, the fields have the following meaning:

• Exclude Any: This is a 32-bit field of flags, each bit indicating a specific link “color.” The color parameter groups links according to some administrative criteria (e.g., all low-speed links are assigned color 1). The LSP cannot be routed over any link that has been assigned a color corresponding to a bit set to 1 in the Exclude Any field.

• Include Any: This is a 32-bit field of flags, each indicating a specific link color. The LSP should be routed only over links that have at least one of the indicated colors assigned.

• Include All: This is a 32-bit field of flags, each indicating a specific link color. The LSP should be routed only over links that have all of the indicated colors assigned.

• Setup Priority: This 8-bit field defines the priority of the LSP with respect to other LSPs when obtaining resources. Eight priority levels, from 0 to 7, are defined (with 0 being the highest priority). When establishing an LSP with set-up priority s, another LSP with holding priority > s can be preempted to make room for the former.

• Holding Priority: This 8-bit field defines the priority of the LSP with respect to other LSPs in retaining resources. Eight priority levels, from 0 to 7, are defined (with 0 being the highest priority). An established LSP with a holding priority h can be preempted by another LSP with setup priority < h. The holding priority of an LSP should always be higher than its setup priority, that is, the holding priority value h should be less than the setup priority value s).

• Flags: This is a 8-bit vector of flags. Three flags are defined. Of these, the one that is of interest to us is the “Local Protection Desired” flag, which is activated by setting bit 1 (low order). This flag indicates that an intermediate LSR can reroute an LSP upon a failure regardless of the route specified in the original ERO. Other flags are described in [Awduche+01b].

• Name Length: This is an 8-bit field indicating the length (in bytes) of the Session Name field.

• Session Name: Character string indicating the name of the session.

• Having described these objects, it remains for us to show how these are used in establishing, maintaining, and deleting LSPs. This is our objective in the next section.

7.4.2.2. ESTABLISHING AN LSP TUNNEL

We saw that RSVP-based reservations could be established from host to host. An LSP tunnel, however, is typically created between an ingress LSR and an egress LSR within a network (recall that the application of RSVP-TE is for traffic engineering). The establishment of this tunnel is typically triggered by administrative action, for example, a command from the network management system to the ingress LSR. Based on the available routing information, the required QoS and the session attributes, an ERO is first computed. This computation could be done either in the management system, for example, or by the ingress LSR. The ingress LSR then constructs a Path message addressed to the appropriate IP destination (the egress LSR). This message contains the ERO, a Label Request object, the tunnel identification, session attributes, and, optionally, the RRO. The progress of the Path message further downstream is similar to the way it happens under RSVP (section 7.4.1.3). An LSR that receives the Path message creates the local Path state. This Path state includes the received ERO, session attributes, and so on. The LSR then determines the local resource allocations for the LSP, and determines the next LSR to forward the Path message by examining and perhaps expanding the ERO (see section 7.4.2.1). It sets the RSVP Hop information (and RRO, if required) appropriately and then forwards the Path message to the next LSR. The Path message ultimately reaches the egress LSR.

The Resv message is sent by the egress LSR in response to the Path message received. The progression of this message is similar to the RSVP case (section 7.4.1.3), except that each LSR also sends the label assigned for the LSP in the Resv message. An LSR that receives the Resv message uses the label assigned by the downstream LSR and the label it has assigned to its upstream to set up its MPLS forwarding table appropriately. Furthermore, at this stage, an LSR actually commits the required local resources to the LSP. Finally, the Resv message reaches the ingress LSR and the LSP is established.

Figure 7-27 shows an example of LSP tunnel establishment in a small network of five MPLS LSRs. The LSP is established from LSR R1 to LSR R4, with a bandwidth of 500 Kbps, setup priority of 3, and holding priority of 2. Figure 7-28 shows some of the details of the process. Here, R1–R4 indicates the IP address of the respective LSRs. Furthermore, the LSRs are assumed to be connected by unnumbered point-to-point links whose interface identifiers are marked. LSR R1 computes the ERO, given by <R1, R2, R3, R4>, and each LSR is assumed to choose the local interface to reach the next LSR in the path. The messages show the contents of the significant fields. Not shown in this figure are the Path and the Resv states created at each LSR.

7.4.2.3. RSVP-TE SOFT STATE

RSVP-TE relies on the basic soft state mechanism provided by RSVP. The Path and Resv state must be refreshed periodically as described in section 7.4.1.4. Recall, however, that the LSP establishment was controlled by an explicit route. Thus, an interesting question is, how does this work with soft state refreshes? Note that in the case of RSVP, the refresh messaging adapted to route changes, that is, a Path refresh message is sent to the current next hop toward the destination. Under RSVP-TE, consider the case of an LSR A that has to send a Path refresh message to a downstream LSR B as given by the ERO. Several scenarios are possible:

These scenarios are not spelled out in RFC 3209 [Awduche+01b]. Protocol implementers have some latitude in determining how to handle failure situations using standard messaging.

7.4.2.4. RSVP-TE HELLO PROTOCOL

RSVP-TE introduces a new RSVP message called “Hello.” Each LSR sends a Hello to each of its RSVP-TE peers frequently (default is once every 3 seconds). This message serves as a keep-alive mechanism to rapidly detect node failures. An LSR considers its peer as failed if it does not receive a Hello message from the peer within a certain time period (default is 12 seconds). The details of the Hello protocol are described in [Awduche+01b].

7.4.2.5. REMOVING AN LSP TUNNEL

An LSP tunnel is removed either due to soft state time-out or by explicit action by one of the LSRs in the path. The orderly removal process consists of the ingress LSR sending a PathTear message toward the egress. The format of this message is similar to the RSVP PathTear but with the enhanced session object (with the tunnel identification). The PathTear is forwarded based on the Path state available at each LSR. An LSR receiving the PathTear removes both the Path and the Resv states, after forwarding the PathTear to the next LSR.

A ResvTear can be sent by the egress LSR or any intermediate LSR. This results in only the Resv state being removed in intermediate LSRs.

7.4.2.6. RSVP REFRESH REDUCTION

A problem with the soft state approach is the need to refresh the Path and Resv state corresponding to each LSP independently. Since RSVP messages are not transmitted reliably, the refreshing has to be done fairly frequently to both ensure that LSPs are established quickly and to improve failure response. This frequent refresh activity, multiplied by the number of LSPs, could pose a problem to LSRs. A solution to alleviate this problem is RSVP refresh reduction. This is described in IETF RFC 2961 [Berger+01]. This RFC introduces three capabilities:

The first capability is realized by introducing a new “bundle” message that can carry multiple messages (Path, Resv, etc.) from one LSR to another. The constituent messages in a bundle may pertain to different LSPs. This message is an optimization. The second capability essentially eliminates the RSVP characteristic of unreliable message transmission between peers. This allows the refresh frequency to be reduced. The third capability eliminates the need to send entire Path or Resv message when refreshing. All these capabilities are optional, that is, an RSVP node need not support these capabilities to interact with those that do. Indeed, two RSVP peers invoke these capabilities only if both of them support the capabilities. We refer the interested reader to [Berger+01] for further investigation of the RSVP refresh reduction capabilities.

Now that we seen the essential elements of RSVP and RSVP-TE, we can next look into how these are used in the GMPLS context.