The MPLS WG Archive

[Sreedhar Reddy <SreedharR@netbrahma.com>]

Hi ,


***************************
Suresh Wrote-->

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 thatif there is no state, then it is OOO 
message.
******************************

   First let us take the underlined statement. If it is
not a Typo then , As per RFC message_id < previously 
received value AND If there is no state the message is
NOT an out of order message. And ALL In Order messages
which are not Refresh messages should be FULLY processed.

I think the algo should be something like this:
( Assuming same Epoch Value):

IF recd_msg_id > larg_msg_id_in_store
    process the message ( I think none of us have 
                          any issues here)
IF recd_msg_id < larg_msg_id_in_store
   Get the state corresponding to this message
   If NO State
      Consider as Inorder message. Process the Massage
   If State Present 
      If STATE_msg_id > recd_msg_id
           out of order message. Ignore.
      else IF recd_msg_id > STATE_msg_id
           You might need to adjust Bandwidth etc for
            this state/Err/Tear message for this state
            STATE_msg_id = recd_msg_id
      else IF recd_msg_id == STATE_msg_id
           Refresh Message
   

Keeping in mind that 

 * ALL In Order messages which are not Refresh messages 
   should be FULLY processed
 * Use message ID only for those messages which are of
   refresh in nature and for other types where 
   reliability is required , use ONLY with
   ack_desired flag set and while retransmitting in case
   of no ack in time, with Message Id which is currently
   being used( next largest available not with the same 
   message_id )

hopefully should solve all these problems

Sreedhar Reddy

PS: If the above guidelines are followed the L1,L2,L3 
  case of Manas/Suresh also can be solved as follows.
  As L3 drops and wont send ack for PathMsg for L2 LSP,
  L2 times out and sends another PathMsg for L2 LSP THIS
  time with the msg_id greater than 101 which is 
  acceptable to L3 

> ----------
> From: 	Manas Kamal Bhattacharya[SMTP:manasb@allegronetworks.com]
> Sent: 	Friday, February 15, 2002 9:04 AM
> To: 	'Suresh Katukam'; Manas Kamal Bhattacharya
> Cc: 	Khuzema Pithewan; Sandeep B; mpls@UU.NET; Manoj Agiwal; 'Ping Pan'
> Subject: 	RE: Doubt about Refresh reduction
> 
> Suresh,
> Please read my comments inline.
> 
> >-----Original Message-----
> >From: Suresh Katukam 
> >Sent: Thursday, February 14, 2002 5:06 PM
> >To: Manas Kamal Bhattacharya
> >Cc: Khuzema Pithewan; Sandeep B; mpls@UU.NET; Manoj Agiwal; 'Ping Pan'
> >Subject: RE: Doubt about Refresh reduction
> >
> >
> >
> >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] This section of the RFC is unclear on the usage of 
> Mesg Id on Tear and Error message. The implementer has the 
> choice of including the mesg id in the Tears and Errors. 
> However if once decides to use Mesg id in outgoing Tears and
> Errors, it should be used ONLY to provide reliability. No 
> performance gain can be achieved and if we use it to detect
> ooo packet, the results cannot be guaranteed to be consistent.
> 
> 
> 
> >
> >
> >>[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.
> 
> 
> [Manas] If sender wants to setup a new LSP but sends a new Path
> with same (session/sender tmpl) then it looks more like an 
> implementation issue. Coming to the receiver even if some of 
> the parameters are changed in the new Path message, it is not 
> necessary that the receiver will always send a Path Err. 
> 
> 
> >
> >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.
> 
> 
> [Manas] I agree that resources will unnecessarily be held up till 
> the lone PSB times out. If we look at the from another side. If the
> Path is dropped and a refresh comes it will also have the same mesg
> id as the previous Path we just dropped. So the LSP will not come up
> until the mesg id in incremented after a cleanup timeout. 
> 
> I am sure we can come up with many such scenerios. But the fact is
> that Mesg Id with Tears and Errors will not give a consistent result 
> in many cases.
> 
> 
> 
> 
> >
> >Best bet is to separate Message ID from Call Reference (Call 
> >ID) and use 
> >two ids
> >for two different purposes.
> 
> 
> [Manas] In RSVP-TE with MPLS we do not use Call Refrence to identify
> any message or state block. 
> 
> Thanks,
> Manas
> 
> >
> >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
> >> > > >
> >> > > >
> >> > >
> >
>