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:
- 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.
- 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).
- 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.Refer to RSVP Refresh Reduction for additional information. Msg Type (8 bits) The type of RSVP message being sent. One of: 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.
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.
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.
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:
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.
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:
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.
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:
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.
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.
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_AckorMessage_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 |