Step 2: Reroute an LSP Tunnel

When the ingress router attempts to reroute an exiting LSP tunnel to increase the bandwidth or change the path, it transmits a new Path message. During the reroute operation, the ingress router must appear as two different senders to the RSVP session. This is achieved by including a new LSP ID in the Sender Template object and the Filter Spec object. The ingress and egress routers perform the following actions:

1. The ingress router includes the following in the new Path message:

• An Explicit Route object (ERO) for the new LSP tunnel.
• The existing LSP Tunnel IPv4 Session object to identify the LSP that will be rerouted.
• A new LSP ID and a new Sender Template object, ensuring that the ingress router appears as a different sender to the RSVP session.

2. The ingress router transmits the new Path message toward the egress router, continuing to use the old LSP tunnel to forward traffic and continuing to refresh the original PATH message (make-before-break).
3. The egress router responds to the new Path message with a Resv message that contains a number of RSVP objects, including:

• A Label object to support the upstream on-demand label distribution process
• An SE reservation Style object
  

  NOTE: On links that are not shared by the old and new LSP tunnels, the new Path/Resv message pair is treated as a new conventional LSP. However, on links that are traversed by both the old and new LSP tunnels, the LSP Tunnel IPv4 Session object and SE reservation style allow the new LSP tunnel to establish so that it shares resources with the old LSP tunnel, eliminating the double-counting problem on shared links.

  
  

4. The ingress router begins to use the new LSP tunnel after it receives the new Resv message.
5. The ingress router sends a Path Tear message to remove the old LSP tunnel from intermediate routers.