The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

Ajit Ranganathan wrote:
> I had another question regarding fast reroute. Once we have started 
> refreshing the path message through the bypass tunnel for the facility
> backup technique, the RESV messages will be received through another
> interface. So the RESV message will not be received on the same 
> interface on which the PATH was sent out. According the classical
> RSVP, I was under the impression that the RESV has to be received
> on the same interface as PATH - am i missing something?
> ajit.

You probably wanted to post this to the working group - you only sent it 
to me.  I'm responding to the working group.

But the answer to your question is that a RESV may arrive on any 
interface.  And this has always been the case.

This is the primary reason that the LIH was invented in HOP objects. 
Seen RFC 2205 for the processing rules.  You will note that in a Resv 
message, the LIH is not the LIH of the interface specified by the HOP 
object's address, but it is the LIH of the corresponding Path message.

When the upstream node gets the Resv, it should ignore the interface it 
was received on and just look up the LSP using the SESSION and 
FILTERSPEC objects.  If it's a multicast session (where there may be 
multiple next-hops), then the LIH is used to determine which outbound 
Path message this Resv message corresponds to.

With Fast Reroute, it's the same.  The Resv comes back on any interface 
(maybe even one that doesn't have RSVP configured.)  Since RSVP-TE 
doesn't (yet) support multicast sessions, you can simply use the SESSION 
and SENDER_TEMPLATE objects to make it all work together.  If the LSP is 
multicast, then you'll need the LIH as well (meaning you'll need an 
appropriate LIH value in the Path message you send into the bypass.)

-- David