RSVP-TE Messages
Nodes on an MPLS TE network send RSVP-TE messages to exchange information.
RSVP Message Format
Each type of RSVP messages contains a common header, followed by multiple objects with variable lengths and types. Figure 1 shows the format of RSVP messages.
Table 1 describes each field in an RSVP message.
Field |
Length |
Description |
|---|---|---|
Version |
4 bits |
Indicates the RSVP version number. Currently, the value is 1. |
Flags |
4 bits |
Indicates the message flag. Generally, the value is 0. RFC 2961 extends this field to identify whether Summary Refresh (Srefresh) is supported. If Srefresh is supported, the value of the Flags field is 0x01. |
Message Type |
8 bits |
Indicates RSVP messages type. For example, the value 1 indicates a Path message, and the value 2 indicates a Resv message. |
RSVP Checksum |
16 bits |
Indicates the RSVP checksum. The value 0 indicates that the checksum of messages is not checked during transmission. |
Send_TTL |
8 bits |
Indicates the TTL of an RSVP message. When a node receives an RSVP message, it compares the Send_TTL and the TTL in the IP header to calculate the number of hops that the message has passed in a non-RSVP area. |
Reserved |
8 bits |
Indicates that the field is reserved. |
RSVP Length |
16 bits |
Indicates the total length of an RSVP message, in bytes. |
Objects |
Variable |
Indicates the objects in an RSVP message. Each RSVP message contains multiple objects. The carried objects vary in different types of messages. |
Length |
16 bits |
Indicates the total length of an object, in bytes. The value must be a multiple of 4, and the smallest value is 4. |
Class_Number |
8 bits |
Identifies an object class. Each object class has a name, such as SESSION, SENDER_TEMPLATE, or TIME_VALUE. |
C-Type |
8 bits |
Indicates an object type. Class-Number and C-Type together identify an object. |
Object Content |
Variable |
Indicates the content of an object. |
Path Message
RSVP-TE uses Path messages to create RSVP sessions and to maintain path states. A Path message is sent from the ingress node to the egress node. A path state block (PSB) is created on each node the Path message passes.
The source IP address of a Path message is the LSR ID of the ingress node and the destination IP address is the LSR ID of the egress node.
Table 2 lists some of the objects carried in a Path message.
Object |
Class_Number |
C-Type |
Object Content |
|---|---|---|---|
SESSION |
1 |
1 |
Carries RSVP session information, such as the destination address, tunnel ID, and extend tunnel ID. |
RSVP_HOP |
3 |
1 |
Carries the IP address and index of the outbound interface on the previous hop that sends the Path message. |
TIME_VALUE |
5 |
1 |
Carries the refresh interval. |
SENDER_TEMPLATE |
11 |
1 |
Carries the sender IP address and LSP ID. |
SENDER_TSPEC |
12 |
2 |
Specifies the traffic characteristics of a data flow. |
LABEL_REQUEST |
19 |
1 |
Indicates that label binding is requested for the path. This object is carried only in Path messages. |
ADSPEC |
13 |
2 |
Collects QoS parameters of a path, such as estimated path bandwidth, minimal path delay, and path MTU. |
EXPLICIT_ROUTE |
20 |
1 |
Specifies the path through which an LSP passes. The path can be a strict or loose explicit path. Path messages are then forwarded along the specified Explicit Route Object (ERO). Path message transmission is not restricted by IGP shortest path. |
RECORD_ROUTE |
21 |
1 |
Lists the label switching routers (LSRs) that the Path message passes. The Record Route Object (RRO) can be used to collect path information and discover routing loops. It can also be copied to the next Path message to implement Route pinning. |
SESSION_ATTRIBUTE |
207 |
|
Specifies the setup priority, holding priority, reservation style, affinity, and other attributes. |
Resv Message
After receiving a Path message, the egress node returns a Resv message. The Resv message carries resource reservation information and is sent hop-by-hop to the ingress node. Each intermediate node creates and maintains a reservation state block (RSB) and allocates a label. When the Resv message reaches the ingress node, an LSP is set up successfully.
Table 3 describes objects in a Resv message.
Object |
Class_Number |
C-Type |
Object Content |
|---|---|---|---|
INTEGRITY |
4 |
1 |
Carries the authentication key of the RSVP message. |
SESSION |
1 |
1 |
Carries RSVP session information, such as the destination address, tunnel ID, and extend tunnel ID. |
RSVP_HOP |
3 |
1 |
Carries the IP address and the index of the outbound interface that sends the Resv message. |
TIME_VALUE |
5 |
1 |
Carries the refresh interval. The default value is 30s. |
STYLE |
8 |
1 |
Carries the resource reservation style, which is specified on the ingress node. |
FLOW_SPEC |
9 |
|
Specifies QoS characteristics of a data flow. |
FILTER_SPEC |
10 |
1 |
Carries the sender IP address and LSP ID. |
RECORD_ROUTE |
21 |
1 |
Collects the inbound interface IP address, LSR-ID, and outbound interface IP address of each node along the path. |
LABEL |
16 |
1 |
Carries the assigned label. |
RESV_CONFIRM |
15 |
1 |
Indicates a confirmation of the resource reservation request. This object carries the IP address of the node that requests resource reservation confirmation. |
Reservation Styles
A reservation style is the method that an RSVP node uses to reserve resources after receiving a resource reservation request from the upstream node. The following reservation styles are supported:
Fixed Filter (FF) style: creates an exclusive reservation for each sender. A sender does not share its resource reservation with other senders, and each CR-LSP on a link has a separate resource reservation.
Shared Explicit (SE) style: creates a single reservation for a series of selected upstream senders. CR-LSPs on a link share the same resource reservation.