The MPLS WG Archive

[Suresh Katukam <skatukam@cisco.com>]

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.

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