Subject: Ptear

From: Gopalkrishna Panicker <[email-masked]>
Date: Wed, 8 May 2002 10:57:19 -0700 (PDT)

Hello,

I am sure these questions have been discussed here
before. My apologies. I could not find what I was
looking for in the archives.

I am trying to understand how PathTear works.

PathTears can originate at any (ingress or transit)
node. These messages travel downstream towards
the receivers (egress routers). Every node in this
downstream path deletes its path state and in some
cases deletes the resv state. 
I am assuming the above is correct.

What happens to the path states upstream to the
originator of the Path Tear ? How are they aged
out ? 

Another related question, Is there a concept of
graceful shutdown in RSVP? For example if RSVP is
disabled in a transit router what should the router
do ? I guess this is implementation dependent.

Cheers,
Gopal

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

---

From: David Charlap <[email-masked]>
Date: Wed, 08 May 2002 15:27:34 -0400

Gopalkrishna Panicker wrote:
> PathTears can originate at any (ingress or transit) node.

They should only originate at transit nodes if there is a link failure
on the upstream side of that transit node.

> These messages travel downstream towards the receivers (egress
> routers).

Correct.  They should follow the same route as the corresponding Path
message - using the stored ERO, if applicable.

> Every node in this downstream path deletes its path state and in
> some cases deletes the resv state.

In all cases, the Resv state is deleted.  It is meaningless to have an
RSVP reservation that does not correspond to any existing Path state.

> What happens to the path states upstream to the originator of the
> Path Tear ? How are they aged out ?

The only time there will be any Path state upstream of the source of the
tear will be if the link to the upstream node has failed.

The other side of that link failure will generate ResvTear and PathError
messages which will flow towards the ingress node.  If the ingress node
so chooses, it can generate a PathTear in response to the PathError
message.

If it chooses not to, then the Path state will remain inplace.  When the
down link comes back up, the router on the upstream side of that link
will send a Path message out, and the LSP will be reestablished.

> Another related question, Is there a concept of graceful shutdown
> in RSVP? For example if RSVP is disabled in a transit router what
> should the router do ? I guess this is implementation dependent.

I don't know of a specification for this.

If the protocol simply stops sending/receiving RSVP messages, the
neighbors will detect this and will enerate PathTear, ResvTear and
PathErr messages, as appropriate.  If Hellos are being exchanged with
the neighbor, this will happen within a few seconds.  If not, it may
take a few minutes - as the soft-states for the different sessions time
out individually.

If the protocol wants to shut down more gracefully, it may send out
PathTead, ResvTear and PathErr messages before shutting down.  But due
to the soft-state nature of RSVP, messages to establish new state may
arrive while this is happening.  So the protocol would have to be able
to reject new requests while it's sending out the error/tear messaes for
the existing state.  Overall, the effect is pretty much the same as the
abrupt shutdown.

Note that this will be different in a GMPLS scenario, where there is a
right and a wrong way to tear an LSP.  Tearing one the wrong way can set
off loss-of-carrier alarms in an optical network.

-- David