The MPLS WG Archive

["Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>]

It is common for set up and release to be a 3 way handshake in many
signalling protocols. If Rel is always triggered by a withdraw then its not
a problem but in situations were it is not don't u think the release needs
to be ACKed.All u need is a Rel ACK status in the notification messages.
This could clear up this and a similar problem in CR LDP. It would also
offer a lot of flexibilty in the Label distribution, control and retention
modes.

Please consider this  and correct me if I am wrong

Regards,
Vijay 

-----Original Message-----
From: Eric Gray [mailto:eric.gray@sandburst.com]
Sent: Saturday, January 19, 2002 12:26 AM
To: Vijayanand C - CTD, Chennai.
Cc: MPLS Mailing List
Subject: Re: LDP protocol problem?


Vijay,

    I can't support the notion that the Release message needs an ACK.
Recall
that the Release message is itself an ACK to the Withdraw message.  We don't
want to get in the middle of an ACK war...


You wrote:

> I think the problem is - the release message has no ACK. If the Upstream
> waits for a Rel-ACK(in Notification or otherwise) before issuing a new
> request for the same FEC to the same downstream and the Upstream when
> receiving the mapping 'update' drops it if it were waiting for the Rel-ACK
> then the problem would have been avoided.
>
> A related  problem occurs in CR LDP local repair(ref
> :http://cell.onecall.net/mhonarc/mpls/2001-Dec/msg00156.html) when the
> request arrives earlier than the release.
>
> Please correct me if I am wrong
>
> Regards,
> Vijay
>
> -----Original Message-----
> From: John.Brennen@marconi.com [mailto:John.Brennen@marconi.com]
> Sent: Friday, January 18, 2002 12:47 PM
> To: mpls@UU.NET
> Subject: Re: LDP protocol problem?
>
> Vijay wrote:
> >I faced a similar problem some time back
> >
> >I think the problem comes because of the configuration of the LDP label
> >distribution mode, control mode and Request mode.
> >
> >Particularly here the request node is REQUEST_NEVER though the
distribution
> >mode is DuS. If router B were 'Request When Needed' then it would have
> >requested A for a label when A becomes its next Hop then the problem
would
> >have been overcome by A sending the mapping again after receiving the
> >request. I wonder if DuS Ind control with 'Request Never' is not a good
> >configuration choice
> >
> >Please correct me if I am wrong.
>
> The problem also manifests itself if the session is
> "Request-when-Needed" and "Downstream-on-Demand."  Example:
>
>   Router A                          Router B
>   --------                          --------
>
>                                     Router A becomes the next hop
>                                     Sends Label Request
>   Receives Label Request
>   Sends Label Mapping (Label 1)
>                                     Router A becomes NOT the next hop
>                                     Sends Label Abort Request
>   Receives Label Abort Request
>    (which is ignored)
>                                     Receives Label Mapping (Label 1)
>                                     Sends Label Release (Label 1)
>                                      (because Router A is not the next
hop)
>   Sends Label Mapping (Label 1)
>    (because the hop count changed)
>                                     Router A becomes the next hop
>                                     Sends Label Request
>   Receives Label Release (Label 1)
>                                     Receives Label Mapping (Label 1)
>   Receives Label Request
>   Sends Label Mapping (Label 2)
>                                     Receives Label Mapping (Label 2)
>                                     Sends Label Release (Label 2)
>   Receives Label Release (Label 2)
>
> The final outcome is the same.  Router B believes that a
> Label Mapping exists; Router A believes that no Label Mapping exists.
>
> The problem seems independent of distribution, control, or retention
> modes.  The crux of the problem is that when Router A sends a
> Label Mapping message which is an "update" message (the same FEC
> and Label as a previous message, usually sent to change the
> hop count and/or path vector) and then subsequently receives a
> Label Release message for that FEC and Label, one of two
> situations can exist:
>
>   * If Router B sent the Label Release after receiving the
>     "update" message, then Router B is not keeping the label
>
>   * If Router B sent the Label Release before receiving the
>     "update" message, then Router B may in fact keep the
>     label if his situation changed between sending the
>     Label Release and receiving the "update" message.
>     (The most likely reason for the situation to change
>     would be Router A becoming the next hop for the FEC.)
>
> Router A simply cannot reliably determine which of these
> two situations exists on Router B.

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray