RSVP-TE

RSVP-TE Protocol Messages

---

NOTE: Refer to the Ixia Reference Manual, Theory of Operation: Protocols chapter for additional information about the RSVP-TE protocol.

Version 1 of the Resource ReSerVation Protocol (RSVP) is defined in RFC 2205. Two principal RSVP message types are used to establish a Label Switched Path (LSP): a PATH message, and a RESV message.

PATH Message

A PATH message is generated by the ingress router and sent toward the egress router. This is termed the downstream direction. The PATH message is a request by the sending LSR to the egress router, asking for the establishment of an LSP. Each LSR in the path to the destination router processes the PATH message and does one of three things:

1. If the LSR cannot accommodate the request, it rejects the request by sending a PATH_ERR message back to the ingress router, indicating the nature of the error.
2. If the LSR IS NOT the egress router, it sends a PATH message to the next LSR on the path toward the destination router (the downstream LSR).
3. If the LSR IS the egress router, it responds by sending a RESV message toward the ingress router. The first hop on the reverse path is the upstream neighbor of the egress router.

RESV Message

A RESV message is generated by the egress router and sent over the reverse of the path that the PATH messages were sent on. This is termed the upstream direction.

The most important information passed in the RESV messages sent upstream from the egress to the ingress router is a set of MPLS labels. A label request is sent from an LSR to its upstream neighbor telling the upstream router which label to use when later transmitting MPLS-encapsulated traffic downstream over the LSP.

Hello Message

An additional HELLO message is used between neighbor LSRs to ensure that LSRs are alive. This allows for quick tunnel replacement in the case of link or router failure.

RSVP-TE Message Formats

An RSVP message contains a common header, and a body which contains a variable number of typed "objects" of variable-length. The format of the RSVP common header is shown in Figure 8-32.

Figure 8-32. RSVP Message Common Header Format

The fields in the RSVP common header format are described in Table 8-24.

Table 8-24. RSVP Common Header Fields

Field	Description
Vers	(4 bits) The RSVP protocol version number. Version 1 is the current version.
Flags	(4 bits) Only one value has been defined for the flags so far - for the Refresh Reduction feature. If this feature is not supported by this node, the flags should be set to zero upon transmission and ignored upon receipt. 0x01 - Refresh (overhead) reduction capable bit, per RFC 2961. Refer to RSVP Refresh Reduction for additional information.
Msg Type	(8 bits) The type of RSVP message being sent. One of: 1 = Path 2 = Resv 3 = PathErr 4 = ResvErr 5 = PathTear 6 = ResvTear 7 = ResvConf 12 = Bundle (per RFC 2961) 15 = Srefresh (per RFC 2961)
RSVP Checksum	(16 bits) The one's complement of the one's complement sum of the message, with the checksum field replaced by zero for computing the checksum. An all-zero value indicates that no checksum was transmitted.
Send_TTL	(8 bits) The IP TTL which was sent with the message. RSVP compares this value with the IP TTL in a received message to detect a non-RSVP hop.
(Reserved)	(8 bits) Reserved for future use.
RSVP Length	(16 bits) The total length of the RSVP message (in bytes), including the common headers and all variable-length objects that follow.

RSVP Object Formats

Each RSVP object contains a one-word header, followed by the contents of the object, as shown in Figure 8-33.

Figure 8-33. RSVP Object Header Format

The RSVP object header contains the following fields, as shown in Table 8-25.

Table 8-25. RSVP-Object Header Fields

Field	Description
Length	The total object length in bytes, always a multiple of 4 and at least 4 bytes long. (16-bits)
Class-Num	Identifies the object class. The following classes must be recognized by an RSVP implementation. (8 bits) One of: NULL SESSION RSVP_HOP TIME_VALUES STYLE FLOWSPEC FILTER_SPEC SENDER_TEMPLATE SENDER_TSPEC ADSPEC ERROR_SPEC POLICY_DATA INTEGRITY SCOPE RESV_CONFIRM FAST_REROUTE DETOUR
C-Type	The Object type, unique within Class-Num. (8 bits)
Object Contents	The variable length objects which are included in the RSVP message.
Send_TTL	The IP TTL which was sent with the message. (8 bits)

PATH Messages

PATH messages contain a number of objects which define the tunnel to be established. The format of a PATH message is shown in Figure 8-34.

Figure 8-34. RSVP - PATH Message Format

The PATH message objects are shown in Table 8-26. Additional, optional objects are included in this table.

Table 8-26. RSVP PATH Message Objects

Object	Contents	Description
RSVP Message Header		As shown in Figure 8-32.
SESSION		Describes the destination router and associates a tunnel ID with the session.
	tunnel endpoint	The destination router's IP address.
	tunnel ID	A unique tunnel ID.
RSVP_HOP		Describes the immediate upstream router's address to the downstream router.
TIME_VALUES		Timing values related to the refresh of tunnel information.
	refresh interval	The interval between messages.
EXPLICIT_ROUTE (optional)		Allows the sender to request that the LSP tunnel follow a specific path from ingress to egress router. Refer to Explicit_Route for additional information.
LABEL_REQUEST		Asks all the LSRs to send back label values via RESV messages.
SESSION_ATTRIBUTE (optional)		Other attributes associated with the session: Tunnel establishment priorities, session name and optionally resource affinity.
POLICY_DATA (optional)		Not generated by the Protocol Server.
SENDER_TEMPLATE		The description of the sender.
	tunnel sender address	The sender router's IP address.
	LSP ID	A unique LSP tunnel ID.
SENDER_TSPEC and ADSPEC		Both of these objects deal with bandwidth and other QoS requirements for the path. Refer to RSVP-TE Traffic Specification (TSpec) for additional information on SENDER_TSPEC.
RECORD_ROUTE (optional)		If requested, the complete route from the destination back to the source. The contents of this object include the IP addresses in either v4 or v6 format of all the LSRs encountered in the formation of the LSP, and optionally, the labels used at each step. Each LSR on the downstream path prepends its own address information.
FAST_REROUTE (optional)		(Per IETF DRAFT draft-ietf-mpls-rsvp-lsp-fastreroute-02) Used to provide backup LSP tunnels for local repair of LSP tunnels, in the event of failure of a node or link. Contains the control attributes for the backup LSP tunnel.
DETOUR (optional)		(Per IETF DRAFT draft-ietf-mpls-rsvp-lsp-fastreroute-02) Used to provide backup LSP tunnels for local repair of LSP tunnels, in the event of failure of a node or link. Contains the specifics of the detour LSPs: nodes to use, and nodes to avoid.

RSVP-TE Fast Reroute/Detour

IETF DRAFT-ietf-mpls-rsvp-lsp-fastreroute-03 defines extensions to RSVP for providing local repair of explicitly-routed LSPs ONLY - during network failures. There are two methods for protecting LSPs: detour LSPs that provide a one-to-one backup, and facility backup bypass tunnels that protect potential failure points. Facility backups can even protect a set of protected LSPs that share a common path, through the use of MPLS label stacking.

The Fast Reroute object specified by draft-ietf-mpls-rsvp-lsp-fastreroute-03 is shown at the top of the figure in Figure 8-35. Existing implementations support a slightly different object, shown at the bottom of the figure in Figure 8-35. The Detour object is shown in Figure 8-36.

Figure 8-35. RSVP-TE Fast Reroute Object

The fields in the Fast Reroute Object are described in Table 8-27.

Table 8-27. RSVP-TE Fast Reroute Object Fields

Field	Description
Length (bytes)	The total object length in bytes, always a multiple of 4 and at least 4 bytes long. (16-bits)
Class-Num	The two high-order bits ("11") indicate that this object should be ignored and passed forward by nodes that do not recognize this object.
C-Type	The C-Type for the Fast Reroute object is 7.
Setup Priority	Priority in taking resources. Range is 0 to 7, with 0 the highest priority.
Hold Priority	Priority in holding onto resources. Range is 0 to 7, with 0 the highest priority.
Hop-limit	The maximum number of additional hops allowed for the backup path - from the current PLR node to a Merge Point node (MP). (The PLR and MP are not counted.)
Flags	Specifies the type of backup desired: 0x01 = One to One backup 0x02 = Facility backup
Bandwidth	The estimated bandwidth necessary for this backup path, in bytes per second. (32-bit IEEE floating point integer)
Include-any	(32-bit vector) It represents a set of attribute filters for this backup path. A link is considered acceptable, and passes, if it has ANY of the defined attributes. If all bits are set to zero (a null set), this set of attribute filters automatically passes.
Exclude-any	(32-bit vector) It represents a set of attribute filters for this backup path. A link is considered unacceptable, and does not pass, if it has ANY of the defined attributes.
Include-all	(Not available for C-Type = 7) (32-bit vector) It represents a set of attribute filters for this backup path. A link is considered acceptable, and passes, only if it has ALL of the defined attributes. If all bits are set to zero (a null set), this set of attribute filters automatically passes.

The format of the RSVP-TE Detour object is shown in Figure 8-36.

Figure 8-36. RSVP-TE Detour Object Format

The fields in the Detour object are described in Table 8-28.

Table 8-28. RSVP-TE Detour Object Fields

Field	Description
Length (bytes)	The total object length in bytes, always a multiple of 4 and at least 4 bytes long. (16-bits)
Class-Num	The high-order bit is zero, indicating to downstream LSRs that do not support DETOUR objects that they MUST reject the Path message with this object, and send a PathErr message to the PLR.
C-Type	The C-Type = 7.
PLR ID (1 through n)	A local IPv4 address identifying the PLR node at the starting point of a detour.
Avoid Node (1 through n)	An IPv4 address identifying the immediate node downstream of the detour starting-point PLR - the node to be avoided. The address is preferably the Router ID.

Explicit_Route

An explicit route is a particular path in the network topology. Typically, the explicit route is determined by a node with the intent of directing traffic along that path. An explicit route is described as a list of groups of nodes along the explicit route. In addition to having the ability to identify specific nodes along the path, an explicit route can identify a group of nodes that must be traversed along the path. Each group of nodes is called an abstract node. Thus, an explicit route is a specification of a set of abstract nodes to be traversed.

There are three types of objects that can be included in an explicit route:

1.  
   • IPv4 prefix
   • IPv6 prefix (not used in this release)
   • Autonomous system number

Each node has a loose bit associated with it. If the bit is not set, the node is considered strict. The path between a strict node and its preceding node may only include network nodes from the strict node and its preceding abstract node. The path between a loose node and its preceding node may include other network nodes that are not part of the strict node or its preceding abstract node.

RSVP-TE Traffic Specification (TSpec)

A new type of Traffic Specification (TSpec) has been proposed for use with MPLS, allowing bandwidth requirements to be signaled for two new types of LSPs: E-LSP and L-LSP. The MPLS Sender_Tspec can specify bandwidth requirements for different traffic classes within an E-LSP - for different ordered aggregates (OAs) - for one flow or for multiple flows. Rate control is handled at the sender's transmitting interface by using a Token Bucket algorithm. The IETF draft proposes that the new Sender_TSpec include Traffic Profile Styles. Of the two Styles defined so far, one is for use with RSVP-TE, and is shown in Figure 8-37.

Figure 8-37. RSVP-TE Sender_TSpec Style Object Format

The fields in the RSVP-TE Sender_TSpec Style object are described in Table 8-29.

Table 8-29. RSVP-TE Sender_TSpec Style Object Fields

Field	Description
Token Bucket Rate (r)	The rate of transfer for data in a flow. In this application, it is used with a traffic policing mechanism. The data "tokens" enter the "bucket," filling the bucket. The data from a number of tokens is combined to form and send a packet. The goal is to determine a rate which will not overflow the specified token bucket size, and cause new data (tokens) to be rejected/discarded.
Token Bucket Size (b)	The maximum capacity (in bytes) the token "bucket" can hold, and above which newly received tokens cannot be processed and are discarded.
Peak Data Rate (p)	The maximum traffic rate that can be maintained. The policing mechanism allows some burstiness, but restricts it so the overall packet transmission rate is less than the rate at which tokens
Minimum Policed Unit (m)	32-bit integer. The minimum allowable size for a policed unit.
Maximum Packet Size (M)	32-bit integer. The maximum number of bytes allowed to cross the interface in a transmitted packet.

Traffic Policing

This type of traffic control is termed traffic policing. When policing is used, actions are implemented immediately - no buffering is used, as is done in traffic shaping. With policing, three types of actions may be taken:

1.  
   • If the conditions are within specs, a data packet will be transmitted.
   • If conditions exceed specs, a packet will be discarded or assigned a lower QoS priority.
   • A lower QoS priority, during congestion, may also cause the packet to be discarded.

RESV Message

The RESV message contains objects that indicate the success of the PATH request and the details of the assigned tunnel. The format of an RESV message is shown in Figure 8-38.

Figure 8-38. RSVP-TE RESV Message Format

The RSVP-TE RESV Message objects are shown in Table 8-30. Additional, optional objects are included in the list.

Table 8-30. RSVP-TE RESV Message Objects

Object	Description
RSVP Message Header	As shown in Figure 8-32.
SESSION	Indicates which session is being responded to.
RSVP_HOP	Describes the immediate upstream router's address to the downstream router.
TIME_VALUES	As in the PATH message but from the downstream LSR to the upstream LSR.
RESV_CONF (Optional)	If present, it indicates that the ingress router should send a RESV_CONF message in response to the destination to indicate that the tunnel has been completely established. Not generated or interpreted by the Protocol Server.
POLICY_DATA (Optional)	Not generated by the Protocol Server.
STYLE	The type of reservation assigned by the egress router. This relates to whether individual tunnels are requested for each sender-destination connection or whether some connections may use the same tunnel.
FLOW_SPEC	Not generated by the Protocol Server.
FILTER_SPEC	The sender router's IP address and the LSP ID.
LABEL	The label assigned by the downstream router for use by the upstream router.
RECORD_ROUTE (Optional)	If requested, the complete route from the destination back to the source. The contents of this object include the IP addresses in either v4 or v6 format of all the LSRs encountered in the formation of the LSP, and optionally the labels used at each step. Each LSR on the upstream path prepends its own address information.

Additional RSVP-TE Messages

Several additional messages are used in RSVP-TE, as described in Table 8-31.

Table 8-31. Additional RSVP-TE Messages

Message	Description
PATH_ERR	Any LSR may determine that it cannot accommodate the tunnel requested in a PATH message. In this case, it sends a PATH_ERR message back to the sender.
PATH_TEAR	When a sender router determines that it wants to tear down a tunnel, it sends a PATH_TEAR message to the destination router.
RESV_ERR	If a router cannot handle a reservation, it sends a RESV_ERR back to the destination router.
RESV_TEAR	When a destination router determines that it wants to tear down a tunnel, it sends a RESV_TEAR message upstream to the source router.
RESV_CONF	When requested, a sender router will respond to the destination router with a RESV_CONF message to indicate that a complete tunnel has been successfully established.

RSVP Refresh Reduction

RSVP Refresh Reduction, specified in RFC 2961 - RSVP Refresh Overhead Reduction Extensions, is a means of reducing the amount of traffic required to maintain RSVP state, thereby reducing processing requirements for routers. The Refresh (overhead) Reduction capable bit must be set in RSVP message headers by nodes that support this feature, and both nodes on a link must support the feature for it to be used.

The two principal methods are Srefresh Messages and Bundle messages. Srefresh Messages allow aggregation of Path and Resv refresh messages, where RSVP state is unchanged, and require that a Message ID object is included within the original Path and Resv messages. In this way, entire standard Refresh messages are not always required to maintain state - just the Message ID can be referenced, unless state and/or routing has changed. The Message ID pertains only to a single hop between neighbor nodes. Srefresh messages are described in Srefresh Messages.

Bundle Messages allow multiple standard RSVP messages to be sent between nodes within a single message PDU, up to the maximum allowable packet length (MTU). (The sending of Bundle messages is not supported in the current IxOS release.)

RSVP Refresh Reduction packet formats are described in the following sections:

1.  
   • Refresh Reduction Capable Bit
   • Message IDs and Message Acks/Nacks
   • Srefresh Messages

Refresh Reduction Capable Bit

The location of the Refresh (overhead) Reduction Capable bit in the RSVP-TE message header is shown in Figure 8-39.

Figure 8-39. RSVP-TE Message Header with Refresh Reduction Capable Bit

Message IDs and Message Acks/Nacks

The format of the Message_ID object, plus the formats of the Message Ack and Message Nack objects, are shown in Figure 8-40. These objects are used in standard RSVP messages to support RSVP-TE Refresh Reduction.

Figure 8-40. Message IDs/Acks/Nacks

The fields in these objects are described in Table 8-32.

Table 8-32. Message Object Formats

Message Object	Field	Description
Message_ID		This object can be sent in Path, Resv, and Srefresh messages.
	Flags	(8 bits) The ACK_Desired flag is defined by RFC 2961. When set to 0x01, indicates the sender is requesting an acknowledgment from the receiver for this message.
	Epoch	(24 bits) This value is randomly generated each time the node reboots, or when the RSVP protocol is restarted.
	Message_ Identifier	(32 bits) This value is randomly generated by the node. When combined with the node's IP address, it serves as a unique identifier for a message.
Message_ID_Ack		A Message Acknowledgment should only be sent in response to received messages that contain a Message_ID object with the ACK_Desired bit set. A Message ID Ack indicates that the receiving node found installed matching RSVP Path or Resv state, based on the received Epoch and Message_Identifier values. This object can be sent for Path and Resv, as well as other RSVP messages. It can be received in any RSVP message.
	Flags	(8 bits) No flags currently defined. Must be transmitted as zero, and ignored upon receipt.
	Epoch	(24 bits) This Epoch field is copied from the message being acknowledged.
	Message_ Identifier	(32 bits) This Message_Identifier field is copied from the message being acknowledged.
Message_ID_Nack		A Message Acknowledgment should only be sent in response to received messages that contain a Message_ID object with the ACK_Desired bit set. A Message ID Nack indicates that the receiving node found no matching installed RSVP Path or Resv state, based on the received Epoch and Message_Identifier values. This object can be sent for Path and Resv, as well as other RSVP messages. It can be received in any RSVP message.
	Flags	(8 bits) No flags currently defined. Must be transmitted as zero, and ignored upon receipt.
	Epoch	(24 bits) This Epoch field is copied from the message being acknowledged.
	Message_ Identifier	(32 bits) This Message_Identifier field is copied from the message being acknowledged.

Srefresh Messages

RSVP-TE Summary Refresh (Srefresh) messages are used, to maintain previously advertised Resv and Path state for nodes that support Refresh Reduction, per RFC 2961. The Message ID specified in the original Path or Resv message is used as "shorthand" to represent the earlier message which established state, without having to send a new, separate message to refresh the state. In this manner, many messages may be referenced - via their Message IDs - within a single Srefresh message. For unicast sessions, a new object, the MESSAGE_ID LIST, includes the Message_Identifier fields corresponding to the original Path and Resv messages. The Message Id List object format is shown in Figure 8-41.

Figure 8-41. RSVP-TE Message_ID_List Object Format

The fields in the RSVP-TE Message_ID_List Object are described in Table 8-33.

Table 8-33. RSVP-TE Message_ID_List Object Fields

Field	Description
Flags	(8 bits) No flags currently defined. Must be transmitted as zero, and ignored upon receipt.
Epoch	(24 bits) This Epoch field is copied from the MESSAGE_ID object for the trigger message that first advertised the RSVP state being refreshed.
Message_Identifier	(32 bits) The Message_Identifier field is copied from the MESSAGE_ID object for the trigger message that first advertised the RSVP state being refreshed. A single or multiple Message_Identifiers maybe contained in the Message_ID_List object.

The RSVP-TE Srefresh message format for unicast sessions is shown in Figure 8-42.

Figure 8-42. RSVP-TE Srefresh Message Format

The fields in the RSVP-TE Srefresh Message for unicast sessions are described in Table 8-34.

Table 8-34. RSVP-TE Srefresh Message Format

Field	Description
Common Header	The common RSVP message header, as shown in Figure 8-32. The Msg Type field must be set to 15.
Integrity	(Optional) RSVP Integrity object.
Message_ID_Ack or Message_ID_Nack	(Optional) Refer to Table 8-32 for additional information.
srefresh list	This is the Message_ID List. Refer to Table 8-33 for additional information. An Srefresh message may carry more than one Message_ID List object.

---

Ixia http://www.ixiacom.com Voice: (818) 871-1800 Fax: (818) 871-1805 support@ixiacom.com sales@ixiacom.com