Subject: disconnect connection

From: "Hong Liao" <[email-masked]>
Date: Sun, 6 May 2001 20:39:58 -0400

Hi David,

I have questions for disconnecting(clear connection).

1.  Suppose LSR received Path message from Ingress router, and LSR sent out
Resv message back.  If the LSR wanted to tear down this session, it will
send out ResvTear to Ingress router, and Ingress router will take out the
Resv state of LSR, and do not response back anything, this session will be
ended. I may wrong.

2.  another way round, if there is LSR and it  forwarded Path message to
Egress router, and Egress router sent back Resv message to LSR, suppose the
LSR wants to tear down this session, it will send out the PathTear to the
Egress router, and Egress router will move the Path state of LSR, do not
response anything, this session is ended. Did I understand correct?

3. If the Ingress router sends out the Path message, but the no Resv
message sent back from LSR, does Ingress router need to send out PathTear
to clear the path state in case that this Path state has already been sent
there.

4.  How about the transit router to try to clear/tear down the session?

Can you help me to understand more of the RSVP protocol.

Thanks in an advance.

Julia

---

From: David Charlap <[email-masked]>
Date: Mon, 07 May 2001 16:03:21 -0400

Hong Liao wrote:
> 1. Suppose LSR received Path message from Ingress router, and LSR
> sent out Resv message back.  If the LSR wanted to tear down this
> session, it will send out ResvTear to Ingress router, and Ingress
> router will take out the Resv state of LSR, and do not response
> back anything, this session will be ended. I may wrong.

First of all, only an egress router should be generating ResvTear
messages, unless there's a failure somewhere.  (In which case, various
PathErr and ResvErr messages should also be generated.)  A transit
router should not arbitrarily go around sending out teardown messages.

As a matter of fact, in the case of MPLS, since LSP creation is driven
by the ingress router, only the ingress router should be doing any kind
of tearing (not counting cleanup after failures.)  The ingress router,
of course, can not generate a ResvTear, because it won't go anywhere. 
It will send a PathTear when it wants to destroy the LSP.

If an egress router sends ResvTear, the reservation will be removed.  If
the ingress router doesn't subsequently tear the Path, however, the Path
state will remain in the network.  This will waste bandwidth due to the
refreshes for the unused state.  It may also result in wasted resources,
since some switches may allocate resources during Path processing.

If a transit router tries to do this, it's even worse.  You end up with
leftover Path state everywhere, and leftover reservations downstream of
that transit router.

In general, ResvTear is not used in MPLS, except possibly in conjunction
with PathErr messages.  There is no reason for a non- ingress router to
tear an LSP except in the face of failures.

> 2. another way round, if there is LSR and it forwarded Path message
> to Egress router, and Egress router sent back Resv message to LSR,
> suppose the LSR wants to tear down this session, it will send out
> the PathTear to the Egress router, and Egress router will move the
> Path state of LSR, do not response anything, this session is ended.
> Did I understand correct?

This is how an ingress router will tear an LSP.

If some router other than ingress does this, however, you will wind up
with leftover Path state in all routers upstream of the LSR.  And until
the Resv state times out, there will be leftover reservations on those
nodes as well.

>    message sent back from LSR, does Ingress router need to send out
>    PathTear to clear the path state in case that this Path state has
>    already been sent there.

Yes.  Path state (and all of the Path refreshing) will remain in place
forever if it is not torn down.

> 4.  How about the transit router to try to clear/tear down the

This should only happen if there is a failure (or perhaps preemption.)

In which case, it should send a PathErr upstream.  The ingress router,
upon receiving this, may then choose to tear the LSP by sending a
PathTear message.

If the failure is a broken link (where the attached router knows that a
PathTear message can't get through to the downstream nodes), the Path
state will timeout (due to lack of refreshes on that interface),
resulting in the eventual transmission of PathTear.

The router should probably choose to immediately send the PathTear as an
optimization (since a link failure will result in the nodes upstream of
the failure tearing the state), but this isn't a hard requirement.

-- David