The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

oops, meant to send to the list...

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

---

• From: Eric Gray <eric.gray@sandburst.com>
• Date: Fri, 18 Jan 2002 13:53:18 -0500

John.Brennen@marconi.com wrote:

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

No.  Router B has done a BAD THING.

Label Requests are used as transaction IDs.  In this case,  Router B has abused the
transaction ID concept by using Label 1 (which was received in a Label Mapping
that was not a response to an earlier Label Request - it contains no label request
message ID) as a response to a label request.  It is theoretically possible to do
this, but the router that decides to do this MUST be smart enough to figure out
how to recover from this and other scenarios.  In this scenario, for example, it
is possible for Router B to simply start using Label 2 when it receives it and
release Label 1 at that time.  For Router B to decide to use an unsolicited Label
Mapping as a response for a Label Request is a MYBAD that it has to know
how to fix.

Also, it is most often the case that downstream on demand is used only with
ordered control.  This is because labels received with an unknown hop count
may not be useful since using them may mean that packets are dropped at the
point where the LSP setup is not yet complete.  With ordered control mode,
this scenario is simply not going to come up all that often.

There is always a 'robustness' behavior that is well understood, if not exactly
specified.  If Router A is getting labels it does not know how to handle (it
has no corresponding ILM for these labels), it is a simple matter of software
to realize that it should send a Label Release for those labels to the LSR that
is sending them.

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

---