The MPLS WG Archive

[Suresh Katukam <skatukam@cisco.com>]

Manas,

At
  02:11 PM 2/14/2002 -0800, Manas Kamal Bhattacharya wrote:
>The MesgId & Srefresh extensions are useful for reducing the refresh
>overhead for rsvp states. The use of Mesg Id in Path and Resv gives
>significant improvement in reducing protocol processing load. If a trigger
>Path/Resv message arrives you got to do full protocol processing for the
>packet, but all subsequent refreshes for this state will come with the new
>Mesg Id. In Path and Resv messages use of Mesg Id will also help in
>detecting out of order messages. The implementer has the option of using
>mesg Id along with Ack to provide reliability.

This is correct.

>Coming to mesg id in the Tears and Errors. The only reason why an
>implementer MAY choose to use include Mesg Id in outgoing Tears and errors
>is to provide some reliability using the ack mechanism. One cannot use Mesg
>Id in the Tear/Error messages to reduce protocol processing load or even to
>detect ooo packets, if some implementation does this there may be interop
>issues.  This becomes apparent from Section 4.5 in RFC2961.

I agree that is what the RFC says. But I am not sure whether this is correct.


>[Manas] Suresh, you cannot assume that the packet is ooo, if a matching
>state block is not found and the new mesg id is less then the mesg id
>previously received from the neighbor. There is also another possibility
>that the mesg id has wrapped around. Also what about this case:
>You have one  LSP, L1 and you want to setup a new LSP L2. So you send a Path
>For L2(with mesg id 100), now for some reason you are tearing L1, so you
>send PTear for L1(with Mesg Id101). The PTear for L1(mesg id 101) somehow
>arrives before the Path for L2(mesg id 100). So 101 is the last received
>mesg id from the neighbor. Now when the Path(L2,mesgid 100) arrives, we do
>not have a matching PSB( as this is the first Path for the LSP L2) and the
>last received message id is 101.  You cannot drop this Path for L2 message.

Here is another scenario: source wants to send a Full PATH message as
a refresh, and then send a PATH TEAR . But at the other end, PATH TEAR
was received. So PATH STATE and everything is removed. Now, the refresh
PATH message is received. So the other end considers that this is for a new
LSP and tries to create one. This takes up resources everywhere along the path.
This is wrong to since Source is not going to send a PATH again for this. 
The worst
thing is that, if Source wants to send another PATH with different 
parameters (but
same session/sender template), then the other end sends a PATH error.

This would cause more problems than dropping a PATH message for L2 in
your example. In your example, if I drop PATH, Source will atleast retry. 
In the
case I described, you will waste resources and will not be able to set up 
new circuits.

Best bet is to separate Message ID from Call Reference (Call ID) and use 
two ids
for two different purposes.

Thanks,
suresh


>I agree with Ping that is may not be a good idea to use mesg id in Tear and
>error message. However if we receive a Tear or Error with Mesg Id( with ack
>desired) we should be able to send an Ack message. Mesg Id in Path/Resv and
>also Srefresh are pretty good optimizations to reduce protocol processing
>load.
>
>Thanks,
>Manas
>
> >
> >Thanks,
> >Suresh
> >
> >
> >>Khuzema.
> >>
> >>
> >> > ----------
> >> > From:         Suresh Katukam[SMTP:skatukam@cisco.com]
> >> > Sent:         Thursday, February 14, 2002 7:40 AM
> >> > To:   Sandeep B
> >> > Cc:   mpls@UU.NET
> >> > Subject:      Re: Doubt about Refresh reduction
> >> >
> >> >
> >> > I think it is useful to have Message IDs for all messages. Even for
> >> > optical/SONET links too.
> >> > If you have OF/OB, or IF/IB control channels, it is quite
> >possible that
> >> > you
> >> > wanted to send
> >> > a refresh PATH message and then send a PATH TEAR. If you do not use
> >> > message
> >> > ids,
> >> > it is quite possible that PATH TEAR may come first and
> >then the PATH
> >> > message at the
> >> > other end. This would tear down and create the circuit at
> >the other end of
> >> >
> >> > the link.
> >> >
> >> > In effect, to find out of order messages.
> >> >
> >> > -- Suresh
> >> >
> >> > At 03:48 PM 2/13/2002 -0800, Ping Pan wrote:
> >> > >If I recall correctly, at one point, we were worried
> >about the noisy
> >> > >links, where without some sort of ack, RSVP messages may
> >get dropped. In
> >> > >this case, having msgids for teardown and error would be
> >nice. Depending
> >> > >on where you want to apply refresh reduction, you have
> >the option where
> >> > to
> >> > >apply msgid's. On SONET/optial links, I am not sure it's
> >useful to use
> >> > >msgid for error and teardown messages.
> >> > >
> >> > >2 cents,
> >> > >
> >> > >- Ping
> >> > >
> >> > >
> >> > >Sandeep B wrote:
> >> > >
> >> > >>I have a more basic question.
> >> > >>Ping -
> >> > >>Why do we need to send PATHTEAR, RESVTEAR, PATHERR,
> >RESVERR with Msgids.
> >> >
> >> > >>These are all triggered messages and what purpose do
> >they solve when we
> >> > >>send these packets with msgid.
> >> > >>-Sandeep
> >> > >>
> >> > >>_________________________________________________________________
> >> > >>Send and receive Hotmail on your mobile device:
>http://mobile.msn.com
> > > >
> > > >
> > >