CS-LSP Setup
CR-LSP Setup Overview
The device can use RSVP-TE to dynamically set up CR-LSPs.
Introduction to RSVP-TE
The Resource Reservation Protocol (RSVP) is designed for the integrated services model, and reserves resources for nodes along a path. This bandwidth reservation capability makes RSVP-TE a suitable signaling protocol for establishing MPLS TE paths.
RSVP-TE adds Label Request objects to Path messages to request labels and adds Label objects to Resv messages to allocate labels.
An extended RSVP message can carry path constraints in addition to label binding information.
The extended objects carry MPLS TE bandwidth constraints to implement resource reservation.
RSVP Message Types
RSVP defines the following types of messages:
Path message: is sent downstream by the sender and saves path information on the nodes it passes through.
Resv message: is sent upstream by the receiver to respond to the Path message and to request resource reservation.
PathErr message: is sent by an RSVP node to its upstream node if an error occurs while this node is processing a Path message.
ResvErr message: is sent by an RSVP node to its downstream node if an error occurs while this node is processing a Resv message.
PathTear message: is sent to delete path information and functions in the opposite way to a Path message.
ResvTear message: is sent to delete the resource reservation state and functions in the opposite way to a Resv message.
ResvConf message: is sent downstream from the sender hop by hop to confirm a resource reservation request. This message is sent only when the Resv message contains the RESV_CONFIRM object.
Srefresh message: is used to update the RSVP state.
RSVP-TE Implementation
Function |
Description |
|---|---|
A CR-LSP is set up according to the CSPF calculation result or an explicit path. CR-LSP setup is triggered on the ingress node. |
|
|
Setup of Dynamic CR-LSPs
To establish a dynamic CR-LSP from an ingress node to an egress node, the ingress node sends Path messages to the egress node and the egress node sends Resv messages back to the ingress node. Path messages are sent to create Resource Reservation Protocol (RSVP) sessions and associate the path status. Every node that receives a path message creates a path state block (PSB). A Resv message carries resource reservation information. Every node that receives a Resv message creates a reservation state block (RSB) and allocates a label.
Figure 4-16 shows how RSVP-TE sets up a CR-LSP.
PE1 uses CSPF to calculate a path from PE1 to PE2, on which the IP address of every hop is specified. PE1 generates an explicit route object (ERO) with the IP address of each hop and adds the ERO in a Path message. PE1 then creates a PSB and sends the Path message to P1 according to information in the ERO. Table 4-5 describes objects carried in the Path message.
After P1 receives the Path message, it parses the message and creates a PSB according to information in the message. Then P1 updates the message and sends it to P2 according to the ERO. Table 4-6 describes objects in the Path message.
The RSVP_HOP object specifies the IP address of the outbound interface through which a Path message is sent. Therefore, PE1 sets the RSVP_HOP object to the IP address of the outbound interface toward P1, and P1 sets the RSVP_HOP field to the IP address of the outbound interface toward P2.
P1 deletes the local LSR ID and IP addresses of the inbound and outbound interfaces from the ERO field in the Path message.
After receiving the Path message, P2 creates a PSB according to information in the message, updates the message, and then sends it to PE2 according to the ERO field. Table 4-7 describes objects in the Path message.
After PE2 receives the Path message, PE2 knows that it is the egress of the CR-LSP to be set up according to the Destination field in the Session object. PE2 then allocates a label and reserves bandwidth, and generates a Resv message based on the local PSB. The Resv message carries the label allocated by PE2 and is sent to P2.
PE2 uses the address carried in the RSVP_HOP field of the received Path message as the destination IP address of the Resv message. The Resv message does not carry the ERO field because it is forwarded along the reverse path. Table 4-8 describes objects in the Resv message.If a Resv message carries the RESV_CONFIRM object, the receiver needs to send a ResvConf message to the sender to confirm the resource reservation request.
When P2 receives the Resv message, P2 creates an RSB according to information in the message, allocates a new label, updates the message, and then sends it to P1. Table 4-9 describes objects in the Resv message.
After receiving the Resv message, P1 creates an RSB according to information in the message, updates the message, and then sends it to PE1. Table 4-10 describes objects in the Resv message.
PE1 obtains the label allocated by P1 from the received Resv message. Resources are successfully reserved and a CR-LSP is set up.
Maintenance of Dynamic CR-LSPs
Path Status Maintenance
The Resource Reservation Protocol (RSVP) is a soft-state protocol. RSVP-TE periodically updates RSVP messages to maintain the resource reservation states on nodes.
Resource reservation states include the path state and the reservation state. RSVP nodes along an established CR-LSP periodically send Path and Resv messages (collectively called RSVP Refresh messages) to maintain the path and reservation states. RSVP Refresh messages are used to synchronize path state block (PSB) and reservation state block (RSB) between RSVP nodes. If an RSVP node does not receive any Refresh message within a specified period, it deletes the path or reservation state.
RSVP Refresh
RSVP sends its messages as IP datagrams, which cannot ensure a reliable delivery. After a CR-LSP is set up, the soft state mechanism synchronizes the PSB and RSB between RSVP neighbors. Each node periodically sends RSVP Refresh messages to its upstream and downstream nodes.
Refresh messages carry information that has already been advertised. The Time Value field in Refresh messages specifies the refresh interval.
If a node does not receive any Refresh message about a certain state block after the specified refreshing intervals elapses, it deletes the state.
A node can send Path and Resv messages to its neighbors in any sequence.
RSVP Srefresh
In addition to state synchronization, RSVP Refresh messages can also be used to detect reachability between RSVP neighbors and maintain RSVP neighbor relationships. Because Path and Resv messages are large, sending many RSVP Refresh messages to establish a large number of CR-LSPs consumes excess network resources. RSVP Summary Refresh (Srefresh) can address this problem.
Message_ID extension and retransmission
The Message_ID extension extends objects carried in RSVP messages. Among the objects, the Message_ID and Message_ID_ACK objects acknowledge received RSVP messages to ensure reliable RSVP message delivery.
The Message_ID object can also provide the RSVP retransmission mechanism. A node resets the retransmission timer (Rf seconds) after sending an RSVP message carrying the Message_ID object. If the node receives no ACK message within Rf seconds, the node retransmits an RSVP message after (1 + Delta) x Rf seconds. The Delta value depends on rate at which the sender increases the retransmission interval. The node keeps retransmitting the message until it receives an ACK message or the retransmission count reaches the threshold (retransmission multiplier).
Srefresh messages transmission
Srefresh messages can be sent instead of standard Path or Resv messages to update RSVP states. These messages reduce the amount of information that must be transmitted and processed for maintaining RSVP states. When Srefresh messages are sent to update the RSVP states, standard Refresh messages are suppressed.
Each Srefresh message carries a Message_ID object, which contains multiple message IDs to identify the Path and Resv states to update. Srefresh implementation depends on the Message_ID extension. Srefresh messages can only update the states that have been advertised in Path and Resv messages containing Message_ID objects.
When a node receives a Srefresh message, the node compares the Message_ID in the message with that saved in the local PSB or RSB. If the two Message_IDs match, the node updates the local state block, just like it receives a standard Path or Resv message. If they do not match, the node sends a Srefresh NACK message to the sender. Later, the node updates the Message_ID and the state block based on the received Path or Resv message.
A Message_ID object contains a message identifier. When a CR-LSP changes, the message identifier increases. A node compares the message identifier in the received Path message with the message identifier saved in the local state block. If they are the same, the node does not update the state block. If the received message identifier is larger than the local message identifier, the node updates the state block.
Error Signaling
PathErr message: is sent by an RSVP node to its upstream node if an error occurs while this node is processing a Path message. The message is forwarded upstream by intermediate nodes and finally reaches the ingress node.
ResvErr message: is sent by an RSVP node to its downstream node if an error occurs while this node is processing a Resv message. The message is forwarded downstream by intermediate nodes and finally reaches the egress node.
Path Teardown
After the ingress node receives a ResvErr message or an instruction to delete a CR-LSP, it immediately sends a PathTear message downstream. After receiving this message, the downstream nodes tear down the CR-LSP and reply with a ResvTear message.
PathTear message: is sent to delete path information and functions in the opposite way to a Path message.
ResvTear message: is sent to delete the resource reservation state and functions in the opposite way to a Resv message.
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 4-17 shows the format of RSVP messages.
Table 4-11 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, This field to identifies 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 4-12 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. |
SESSION_ATTRIBUTE |
207 |
|
Specifies the setup priority, holding priority, reservation style, 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 4-13 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: