Subject: RSVP Hello Protocol extension

From: "Charles Smith" <[email-masked]>
Date: Tue, 13 Mar 2001 15:27:55 -0000

MPLS community -

I would like to obtain a clarification regarding the functionality of the 
RSVP Hello Protocol extension.

The Hello Protocol is intended for use between adjacent neighbors. Let's 
assume we have the following simple topology:

ingress <LER X>-----<LSR A>-----<LSR B>--hello---<LSR C>-----<LSR 
D>-----<LER Y> egress

Now let's assume LSR C fails. Obviously LSR B would realize the failure. 
Very straightforward I know.

What does LSR B do next? Does this node initiate a PathErr message toward 
LER X?

Any clarification would be appreciated.

chas
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

---

From: David Charlap <[email-masked]>
Date: Tue, 13 Mar 2001 11:12:16 -0500

Charles Smith wrote:
> 
> I would like to obtain a clarification regarding the functionality of
> the RSVP Hello Protocol extension.
> 
> The Hello Protocol is intended for use between adjacent neighbors.
> Let's assume we have the following simple topology:
> 
> ingress <LER X>-----<LSR A>-----<LSR B>--hello---<LSR C>-----<LSR D>-----<LER Y> egress
> 
> Now let's assume LSR C fails. Obviously LSR B would realize the
> failure.  Very straightforward I know.
> 
> What does LSR B do next? Does this node initiate a PathErr message
> toward LER X?

One valid way is to handle this in the exact same way it would detect
other kinds of failures - like loss of carrier on the fiber or loss of
state refreshes.

This would involve purging all RSVP state from the B-C interface and
sending out appropriate messages.  This would probably involve some
combination of PathTear (for any paths going from Y to X), ResvTear (for
any reservations going from Y to X), and PathErr (for any paths going
from X to Y).

This is a draconian approach which will definitely work under all
circumstances.  But under some circumstances, it may be possible to use
an approach with less overhead.

For instance, suppose the instance ID sent by C changes.  B knows that C
has rebooted (or otherwise reset RSVP state), and has not failed.  B
knows that C no longer has any state, but may still be capable of
supporting all of the LSPs that were previously signalled.

In this case, B doesn't have to tear down everything.  It can instead
send out ResvTear messages (since its upstream no longer has a
reservation) and immediately refresh all Path state - to re-establish
this state on C.

If B and C are using refresh reduction, B must also purge all shared
message IDs and re-generate them during the next refresh, of course.

Of course, this kind of handling would not be appropriate if Hello
messages are timing out.  In that case, we don't know that C is still
operational, and we must act as if it has failed - and tear down all
state involving LSR C.

-- David