Establishing a CR-LSP Using RSVP-TE

RSVP-TE is an extension to RSVP. Resource Reservation Protocol (RSVP) is designed for the Integrated Service model and runs on every node of an LSP for resource reservation. RSVP is a control protocol working at the transport layer, but it does not transmit application data. RSVP-TE establishes or tears down CR-LSPs using Traffic Engineering (TE) attributes carried in extended objects.

RSVP-TE has the following characteristics:

Unidirectional.
Receive end-oriented: A receive end initiates a request to reserve resources and maintains resource reservation information.
Uses a soft state mechanism to maintain the resource reservation information.

RSVP-TE Messages

RSVP-TE messages are as follows:

Path message: used to request downstream nodes to distribute labels. A Path message records path information on each node through which the message passes. The path information is used to establish a path state block (PSB) on a node.
Resv message: used to reserve resources at each hop of a path. A Resv message carries the resource reservation information required by a sender. It is sent in the reverse direction of data flows and used by each node on a path to establish a reservation state block (RSB) to record information about distributed labels.
PathErr message: sent upstream by an RSVP node if an error occurs during the processing of a Path message. A PathErr message is forwarded upstream by each transit node until it arrives at the ingress.
ResvErr message: sent downstream by an RSVP node if an error occurs during the processing of a Resv message. After receiving the ResvErr message, the transit node continues to forward the message to the downstream node until the message reaches the egress node.
PathTear message: sent downstream by the ingress to delete information about the local state created on each node of a path.
ResvTear message: sent upstream by the egress to delete the reserved local resources assigned to a path. After receiving the ResvTear message, the ingress sends a PathTear message to the egress.

Process of Establishing an LSP

Figure 1 Process of establishing an LSP

Figure 1 shows the process of establishing an LSP.

After RSVP-TE is configured on the ingress, the ingress creates a PSB and sends a Path message to downstream nodes.
After receiving the Path message, the transit nodes process and forward this message, and create a PSB based on the message.
After receiving the Path message, the egress creates a PSB, generates a Resv message based on the Path message, creates an RSB, and sends the Resv message upstream.
The transit nodes process and forward the Resv message and create an RSB.
After receiving the Resv message, the ingress creates an RSB and confirms that the resources are successfully reserved.

An LSP is then successfully established.

Soft State Mechanism

The soft state mechanism enables RSVP nodes to periodically send Path and Resv messages to synchronize states (including states in the PSB and RSB) between RSVP neighboring nodes or to resend RSVP messages that have been dropped. If an RSVP node does not receive an RSVP matching a specific state within a specified period of time, the RSVP node deletes the state from a state block.

A node can refresh a state in a state block and notifies other nodes of the refreshed state. In the tunnel re-optimization scenario, if a route changes, the ingress is about to establish a new LSP. RSVP nodes along the new path send Path messages downstream to initialize PSBs and receive Resv messages responding to create new RSBs. After the new path is established, the ingress sends a Tear message downstream to delete soft states maintained on nodes of the previous path.

Reservation Styles

A reservation style defines how an RSVP node reserves resource after receiving a request sent by an upstream node. The NetEngine 8000 F supports the following reservation styles:

Fixed filter (FF): creates an exclusive reservation for each sender, which does not share its resource reservation with other senders and is assigned a unique label.
Shared explicit (SE): explicitly specifies the senders in a reservation for receivers. These senders share one reservation but send different labels to a receiver.