Subject: Re: disconnect connection

From: "Hong Liao" <[email-masked]>
Date: Wed, 9 May 2001 13:32:00 -0400

David,

Hope I understand correctly.

1.  If Ingress sends out Path, and Egress sends back Resv, the LSP is
established.  If Ingress wants to tear down the connection, Ingress sends
out PathTear to tear down connection.

2.  If Egress sends out Path message, but no Resv back from Egress router,
the Egress should send out PathTear to clear the path state.

3.  If Egress or LSR find there is failure, they will send out ResvErr, and
Ingress send out PathTear to tear down the connection(basically clear the
path and resv state).

Anyway Ingress is the one which will tear down the connection if there is
one.  If the connection has not set up yet, for example, there is no Resv
back after Path message was sent out, Ingress still need to send out
PathTear to clear the Path state.

Thanks,

Julia

David Charlap <[email-masked]> on 05/07/2001 04:03:21 PM

To:   [email-masked]
cc:    (bcc: Hong Liao/Telcordia)
Subject:  Re: disconnect connection

Hong Liao wrote:
>
> 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.

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.

> 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.

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
> session?

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

---

From: Shankar <[email-masked]>
Date: Wed, 9 May 2001 18:43:39 +0100 (BST)

--- Hong Liao <[email-masked]> wrote: > 
> out PathTear to tear down connection.
Correct.
> the Egress should send out PathTear to clear the
Is it "Ingress sends out Path message" .....
"Egress should send out PathTear" ..?

> PathTear to clear the Path state.

Here, you have it right.
shankar 
> the failure tearing the state), but this isn't a

____________________________________________________________
Do You Yahoo!?
For regular News updates go to http://in.news.yahoo.com

---

From: Eric Gray <[email-masked]>
Date: Wed, 09 May 2001 14:31:54 -0400

Julia/Shankar,

> > out PathTear to tear down connection.

Not quite.  When the Ingress sends Path and receives Resv,
the LSP is established.

The Ingress may tear down the LSP by sending PathTear
because this forcibly removes Path state associated with
the LSP.  Alternatively, the ingress may simply not send
further Path messages for this LSP - but, while this will
work, it is a substantially suboptimal approach.

> "Egress should send out PathTear" ..?

At some point, the ingress may become disinterested in
using an LSP should it ever be setup.  At that point the
ingress will stop trying to set it up and should forcibly
remove Path state downstream.  This frees up resources
for the next LSR that wants to wait for an LSP to be
established.

> > PathTear to clear the Path state.

Except that the term 'need' is not consisten with the
the use of the word SHOULD.  The ingress can cease
to exist and the LSP will still be torn down and Path
state will still be removed.