The MPLS WG Archive

[Manas Kamal Bhattacharya <manasb@allegronetworks.com>]

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.

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. 

Please read the rest of my comments inline. 

>-----Original Message-----
>From: Suresh Katukam
>Sent: Thursday, February 14, 2002 8:49 AM
>To: Khuzema Pithewan
>Cc: Sandeep B; mpls@UU.NET; Manoj Agiwal
>Subject: RE: Doubt about Refresh reduction
>
>
>
>I think the main reason for all these questions and confusion
>comes from how MESSAGE_ID is used. In many other
>protocols, you have a sequence number to identify ooo
>(out-of-order) messages and a circuit/Call ID to identify
>a Call/LSP.
>
>With Refresh Reduction, We are trying to use MESSAGE_ID
>to identify a state (or a LSP or a call) and also to identify
>ooo messages. This is not necessarily the best mechanism
>and causing lot of issues and I am positive that this will cause
>inter-op issues too. Infact, there were issues when OUNI interop
>tests were conducted. During that, we used only message_id and
>no Srefresh mechanism.
>
>Anyways, to answer your question.. see in line
>
>At 11:57 AM 2/14/2002 +0530, Khuzema Pithewan wrote:
>>How would you make "Out of Order" check on Error Messages...
>>
>>consider following scenario...
>>
>>         L1---------L2--------L3
>>
>>if L2 sends PATH message contains the messageID generated at 
>L2  to L3. In
>>reponse of this message L3 sends a PATH Error message back to L2 which
>>contains the message ID generated at L3. Now at L2 how to 
>check whether this
>>error message  is out of order or not.
>>
>>RFC says....
>>
>>"To determine ordering, the received
>>    Epoch value must match the value previously received from 
>the message
>>    sender.  If the values differ then the receiver MUST NOT treat the
>>    message as out of order.  When the Epoch values match and the
>>    Message_Identifier value is less than the largest value previously
>>    received from the sender, then the receiver SHOULD check the value
>>    previously received for the state associated with the message.  "
>>
>>Assume here messageID received in the error mesage is less 
>than the largest
>>value received from L3 till now and we have not received RESV 
>message from
>>L3 yet .. so how u will determine the "Out of order" message here??
>
>If you received a PATH error from L3 with messageID less than 
>the largest 
>received,
>I would not process this message. The RFC says that if the 
>Epoch values match,
>message_id < previously received value, then check the state. 
>If there is 
>no state,
>then it is certainly out-of-order message. It says "SHOULD 
>check the value
>previously received for the state....". It is not must and it 
>also does not 
>explicitly state
>what happens if there is no corresponding state. It is logical 
>to conclude that
>if there is no state, then it is OOO message.



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

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