Subject: A question regarding rsvp-te

From: "Xiaoning He" <[email-masked]>
Date: Wed, 29 Jan 2003 10:52:36 -0800

Hi all

Some parts of my research require some knowledge of RSVP-TE and MPLS. I
have a simple question and I appreciate if you can give me some idea or
link so that I can read the right draft or RFC.

My questions is

If there is an existing LSP established by RSVP-TE. Now, some segments
of the link have to be changed as shown as follows:

a---> b--->c to a--->b--->d

my question is that is there anyway we don't have to tear down the old
path, I mean the label from a-->b doesn't have to be changed? Is that
something allowed in RSVP-TE? 

Thank you very much,

Xiaoning He, Ph.D
Research Engineer
 
NTT-DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110
 
Email: [email-masked]
Phone: +1 (408) 451-4737
Fax:   +1 (408) 573-1090

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 29 Jan 2003 12:21:47 -0800 (PST)

> something allowed in RSVP-TE? 

Yes it is. If explicit routes are being used, B will start forwarding
PATH messages to D as the new explicit route willl start pointing in
that direction. D will reply with a RESV message with its label. B will
stasrt using that as the outgoing label and leave the label it sent out to
A the same..

---

From: David Charlap <[email-masked]>
Date: Wed, 29 Jan 2003 17:00:45 -0500

Xiaoning He wrote:
> a--->b--->c to a--->b--->d
> 

If there are no explicit routes involved, then the LSP follows the 
routing table.  When the route change propagates to router B, it will 
send a PathTear to C and a Path to D.  When the Resv comes back from D, 
router B does not have to propagate it further upstream.

If there is an explicit route, then the ERO must be changed by the 
ingress node (A).  It can choose to do this in one of three ways.

The preferable way is make-before-break.  In this, A signals a new LSP 
along the new ERO.  When the new LSP comes up, A redirects data-plane 
traffic from the old LSP to the new LSP.  Then it tears down the 
original LSP.  If the two LSPs belong to the same session and SE-style 
is used for the reservation, then this can be done without wasting 
bandwidth on the links that are shared between the two LSPs.

A less preferable way is break-before-make.  A tears the original LSP, 
and then establishes a new one with the new ERO.  This obviously has the 
problem of disrupting data-plane traffic.

A third way (which I also don't like) is for A to simple change the ERO 
in a Path refresh.  When B gets the updated Path message, it will send a 
PathTear to C and a Path to D, and the LSP will reroute.

The problem with changing the ERO is not obvious from your topology, 
since you also changed the destination router (which changes the session 
address, BTW).  Most of the time, however, a reroute like this is 
expected to preserve traffic flow to the same destination.  For example, 
you might have a topology like this:

         /---C-------D---\
A-----B<                 >F-----G
         \-------E-------/

Now, suppose we have an ERO sending traffic along the path A-B-E-F-G. 
Now we want to reroute it to A-B-C-D-F-G.

If we use the make-before-break method, there's no problem.  We briefly 
have two LSPs - one using eath ERO.  If SE-style is used, Bandwidth is 
shared between them on the links that are in common (A-B and F-G).  The 
traffic reroutes when A makes the switchover.

If we use break-before-make, obviously, there's an interruption.

But observe what happens if we just change the ERO in-line:

B receives a Path message where the ERO specifies a new next-hop.  B 
sends a Path message to C and a PathTear to E.  C propagates the Path 
message to D, and then to F.  Meanwhile, E propagates a PathTear to F.

If the PathTear reaches F before the Path message, F will tear the 
connection and propagate the PathTear to G.  Then the Path arrives at F, 
which sends it to G.  G sends back a Resv, which propagates back to F, 
then to D, C and B.  The data-plane is broken for the time interval 
between when the PathTear reaches F and when the Resv makes its way back 
to B.

If the Path reaches F before the PathTear message, it may or may not be 
better.  F will receive the Path message and see that the previous-hop 
router for the LSP has changed.  It will then generate a Resv message to 
send back to D, propagating to C and B.  When the Resv reaches B, the 
data-plane traffic will start following the new Path.

But then the PathTear arrives at F.  F might ignore the PathTear, since 
it is arriving on a different interface from the (new) PHOP, but I think 
it's also legal for it to process that PathTear.  This causes the Path 
from F to G to be torn.  When D sends its next refresh, it will then be 
re-established, but this might not happen for a long time - especially 
if features like RSVP-Hello and refresh reduction are operating between 
D and F.

In other words, if A simply changes the ERO, there is a very real 
possibility that the data-plane will be broken for at least a short 
time, and possibly for a long time.

IMO, make-before-break is the only good way to change the route of an 
LSP with an ERO.

-- David