RSVP - TE

The RSVP - TE protocol described in the RFC3209 is a extended version of the RSVP protocol to better serve LSP tunnels requirements.

A request to bind a label to a LSP tunnel is emitted by an ingress node (upstream router at the border of the MPLS network). Therefore the RSVP path message is expand with the addition of the LABEL_REQUEST object.

Labels are allocated downstream and distributed upstream via the RSVP Resv message which is, for this purpose, extended with  LABEL object.

The EXPLICIT_ROUTE object is also implemented in Path messages of the RSVP extended version. This object enables the pre definition of specific hops that must be comprised in the LSP. The explicit route can be determined manually by the network administrator, or automatically by an entity responsible for managing QoS requirements and policies where the current state of the network is taken into account.

One of the possible uses of the EXPLICIT_ROUTE object is to implement Traffic Engineering techniques. Through the selection of explicit routes the utilization of a network resources can be optimized.

The use of RSVP in establishing LSP tunnels is the possibility of the reservation of resources throughout the path. This reservation, though is not mandatory, an LSP can be assigned without the reservation of the resources, which can be used to transport best effort traffic for instance.

traffic Engineering capabilities require that a established TE tunnel may be re-routed. The circumstances in which this re-routing takes place are determined according to network policies and may be necessary when:

• A more optimal route becomes available.
• Failure of a resource along the determined path. 
• Return the TE tunnel to original route when the necessary resource becomes available again.