RSVP-TE in MPLS is not just a resource reservation protocol, rather in addition it is more importantly used as a label distribution protocol (which is a set of procedures by which one LSR informs another of the label/FEC binding it has made) and to set-up, maintain and tear down LSPs. It is important to note that RSVP-TE supports LSPs without resource reservation, which may be used to carry best effort IP traffic.

The new features that have been added to RSVP-TE are [6]:

1. Label request and distribution (using Label Request Object in Path messages and Label Object in Resv messages).

2. Explicit routing (using Explicit Route Object ERO)

3. Bandwidth reservation for LSPs

4. Rerouting LSPs after failure

5. Tracking of the actual route of an LSP (using Record Route Object RRO)

6. Preemption options (like setup priority, holding priority in Session Attribute Object).

The LSP setup in RSVP-TE is done in exactly the same way, except that the new object are added in the Path and Resv messages. For example, every Path message carries a Label Request Object while every Rev message contains a Label Object. The use of ERO and RRO is optional.

4.3.1 Reroute and Bandwidth Increase Operations:

These operations are at the very heart of traffic engineering, and are handled elegantly by RSVP-TE. Concept called make-before-break is used while rerouting TE Tunnels, which means that while trying to reroute, first a new LSP tunnel is setup and traffic is transferred to it, before tearing down the old LSP tunnel. To support make-before-break the following two things are of primary concern [6]:

1. On links common to both the new and old LSP tunnels, resources used by the old LSP tunnel should not be relinquished before traffic is diverted to the new LSP tunnel.

2. Reservations should not be counted twice.

The above two conditions are taken care, as follows:

1. A new LSP ID (hence a new SENDER_TEMPLATE) is chosen, since the tunnel ingress needs to appear as two different senders to the RSVP session. Then the new ERO is added (the new explicit route). Thereafter the node sends a new Path Message using the original SESSION object, the new SENDER_TEMPLATE and ERO, with its IPv4 address in the Extended_Tunnel_ID.

2. The shared SESSION object and SE style allow the LSP to be established, sharing resources with the old LSP, while the old LSP is still being refreshed and used. Once the ingress node receives a Resv message for the new LSP, traffic can be transferred to it and the old LSP tore down, using PathTear message.

Similar approach is also used for bandwidth increase operation.