Subject: [mpls] Some question about LDP

From: Leonardo Balliache <[email-masked]>
Date: Fri, 15 Oct 2004 10:33:51 -0400

Hi, all,

Hoping Loa can help me with these questions.

I'm trying to implement LDP in the ns-2 simulator. It has already an 
implementation but I want something closer to the specification. I tell 
this to take for granted that I'm not working in any commercial implementation.

My questions refer to the specification, and are:

** Q1.- Here Propagating is set in independent control but not in ordered 
control; but it is used as parameter in ordered control below.

A.1.1. Receive Label Request

     ...........

       LRq.9   Perform LSR Label Distribution procedure:

             For Downstream Unsolicited Independent Control OR
             For Downstream On Demand Independent Control

                1. Has LSR previously received and retained a label map-
                   ping for FEC from Next Hop?.
                   Is so, set Propagating to IsPropagating.
                   If not, set Propagating to NotPropagating.

                2. Execute procedure Prepare_Label_Map-
                   ping_Attributes(MsgSource, FEC, RAttributes, SAt-
                   tributes, Propagating, StoredHopCount).

                3. Execute procedure Send_Label (MsgSource, FEC, SAt-
                   tributes).

                4. Is LSR egress for FEC? OR
                   Has LSR previously received and retained a label map-
                   ping for FEC from Next Hop?
                   If so, goto LRq.11.
                   If not, goto LRq.10.

             For Downstream Unsolicited Ordered Control OR
             For Downstream On Demand Ordered Control

                1. Is LSR egress for FEC? OR
                   Has LSR previously received and retained a label map-
                   ping for FEC from Next Hop?  (See Note 3.)
                   If not, goto LRq.10.

                2. Execute procedure Prepare_Label_Map-
                   ping_Attributes(MsgSource, FEC, RAttributes, SAt-
                   tributes, IsPropagating, StoredHopCount)

                3. Execute procedure Send_Label (MsgSource, FEC, SAt-
                   tributes).
                   Goto LRq.11.

** Q2.- Here, in PMpA.7, Hop Count in RAttribute is incremented but it is 
used then in PMpA.14. In this (14), Hop Count to be used is the original 
Hop Count in RAttribute or the incremented value in PMpA.7?

A.2.8. Prepare_Label_Mapping_Attributes

     .........

       PMpA.7  Increment RAttributes Hop Count and copy the resulting
               Hop Count to SAttributes.  See Note 2.  Goto PMpA.9.

       PMpA.8  Include Hop Count of unknown (0) in SAttributes.

       PMpA.9  Is Loop Detection configured on LSR?
               If not, goto PMpA.21.

       PMpA.10 Do RAttributes have a Path Vector?
               If so, goto PMpA.19.

       PMpA.11 Is LSR propagating a received Label Mapping?
               If not, goto PMpA.20.

       PMpA.12 Does LSR support merging?
               If not, goto PMpA.14.

       PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer?
               If not, goto PMpA.20.

       PMpA.14 Do RAttributes include a Hop Count?
               If not, goto PMpA.21.

       PMpA.15 Is Hop Count in Rattributes unknown(0)?
               If so, goto PMpA.20.

** Q3.- I've got some problem interpreting the sentences "Install label" as 
below:

     .......

       LRq.12  Perform LSR Label Use procedure.

             For Use Immediate OR
             For Use If Loop Not Detected

                1. Install label sent to MsgSource and label from Next
                   Hop (if LSR is not egress) for forwarding/switching
                   use.

     .......

       LMp.15  Install Label for forwarding/switching use.

     .......

               2. Install label received and label sent to Peer for
                  forwarding/switching use.

       SL.3   Install Label for forwarding/switching use.

     .......

As I understand MPLS we should have three tables: NHLFE, FTN and ILM.

FTN contains fecs and points to NHLFE. Then, it should have the information 
about the incoming interface to have the tuple <fec, incoming_itfc).

ILM contains labels and points to NHLFE too. Then it should have the 
information about the incoming interface to have the tuple <label, 
incoming_itfc).

NHLFE should have the information about the outgoing label (if it is 
required or the null (0) label to indicate that the last label must be 
popped to expose the L3-header), the outgoing interface and the operation 
to be done (push, swap, pop) to have the tuple <label, outgoing_itfc, 
operation).

Then, I'm not very sure how to interpret the sentences above ordering to 
"install label". Could you be a little bit more explicit about this 
information?

Best regards,

Leonardo Balliache

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Eric Gray <[email-masked]>
Date: Sat, 16 Oct 2004 09:04:02 -0400

Leonardo,

    See below...

Leonardo Balliache wrote:

> [.. SNIP ..]
> ** Q1.- Here Propagating is set in independent control but not in 
> ordered control; but it is used as parameter in ordered control below.
>
> [.. SNIP ..]

I am not sure what the question related to in all the steps included, but
the setting of control mode is a "local" phenom and the fact that the local
LSR is operating in independent control does not prevent it from getting
label requests from upstream LSRs, or label mappings from downstream
LSRs that _are_ operating in ordered control mode.

>
>
> ** Q2.- Here, in PMpA.7, Hop Count in RAttribute is incremented but it 
> is used then in PMpA.14. In this (14), Hop Count to be used is the 
> original Hop Count in RAttribute or the incremented value in PMpA.7?
>
> [ .. SNIP ..]

Hop count is incremented and then copied in PMpA.7. That means the value
left in RAttribute is the incremented value.  The wording is quite 
clear, given a
number of other ways it could have been put.

The value is next used in PMpA.18 (not 14) and it should be clear from 
context,
that we are trying to determine if the value we would send (which is 
stored in
SAttribute) is different than the value we have previously sent. 
Consequently, we
are comparing RAttribute->hopCount with prevHopCount, _because_ we know
from step PMpA.7 that the values RAttibute->hopCount=SAttribute->hopCount.

Bear in mind that it is not the intention that this appendix is supposed 
to be treated
as "pseudo-code". It may - in fact - include operations which are more 
or less
intentionally not exactly the same as might appear in a specific 
implementation.

>
> ** Q3.- I've got some problem interpreting the sentences "Install 
> label" as below:
>
>  [.. SNIP ..]
>
> FTN contains fecs and points to NHLFE. Then, it should have the 
> information about the incoming interface to have the tuple <fec, 
> incoming_itfc).
>
> popped to expose the L3-header), the outgoing interface and the 
> operation to be done (push, swap, pop) to have the tuple <label, 
> outgoing_itfc, operation).
>
> Then, I'm not very sure how to interpret the sentences above ordering 
> to "install label". Could you be a little bit more explicit about this 
> information?

Understand that FTN, ILM, NHLFE, etc. are terms used in various MPLS
specifications to describe the internal logical operations as they must 
appear
externally. There are any number of ways that the actual implementation may
be done so that it looks - from outside the box - as if it is done this way.

I believe that "installing the label" is fairly clear, but to make it 
even clearer,
it means the following:

1)    if this LSR is an intermediate LSR with respect to the LSP for 
which this
    label is defined, do whatever it is in your implementation that 
corresponds
    to adding a new (or modifying an existing) ILM to point to an NHLFE that
    includes the corresponding downstream next hop, label, encaps, etc.
2)   if this LSR is an ingress LSR with respect to the LSP for which a 
label is
    being defined, do whatever it is in your implementation that corresponds
    to adding a new (or modifying an existing) FTN to point to an NHLFE that
    includes the corresponding downstream next hop, label, encaps, etc.
3)   if this LSR is an (effective) egress LSR with respect to the LSP 
for which a
    label is being defined, do whatever it is in your implementation 
that corresponds
    to either adding a new (or modifying an existing) ILM to point to an 
NHLFE
    that includes the corresponding downstream next hop, encaps, etc. - 
and no
    label - or an ILM that instructs the receiving hardware to strip the 
label and
    present the remaining packet for further processing (depending on 
whether
    the label stripped was the bottom of the label stack).

In essense, instead of saying "do whatever it is ...", the specification 
says "install
the label".  I believe this is reasonable license.

--
Eric

---

From: Leonardo Balliache <[email-masked]>
Date: Tue, 19 Oct 2004 10:10:08 -0400

Eric,

>LSRs that _are_ operating in ordered control mode.

I think I didn't explain well. Here I copy again the spec and my code. I 
understand that the spec is not a pseudo-code but it is so specific that 
I'm not sure (I'm trying yet to understand well the logic) if this 
observation is important:

The spec:

     ...........

The code:

// FEC.1 LSR label distribution procedure
if ( labeldiscipline() == 0 )  {         // unsolicited
    if ( labelcontrol() == 0 )  {         // independendent control
       for ( LDP2Src* itfc = firstsource(); itfc != NULL; itfc = 
nextsource() )  {   // iterate for each peer              peer = itfc->daddr();
          propagating_ = find_ldp2rec(LDP2_LabelMappingMSG, LDP2_RECEIVED, 
0, nhop, fec, -1);
          prepare_label_mapping_attributes(peer, fec, initatt, satt, 
propagating_, 0);
          send_label(peer, fec, satt);
      }
   }
   else  {                              // ordeder control
      for ( LDP2Src* itfc = firstsource(); itfc != NULL; itfc = 
nextsource() )  {  // iterate for each peer
          peer = itfc->daddr();
          if ( lsr_isegress(fec) ||
               find_ldp2rec(LDP2_LabelMappingMSG, LDP2_RECEIVED, 0, nhop, 
fec, -1) )  {
             recatt = getatt_ldp2rec(LDP2_LabelMappingMSG, LDP2_RECEIVED, 
nhop, fec, -1);
             recatt == 0 ? storedhcount = 0 : storedhcount = 
recatt->hopcount();
             // ### we have here propagating_ not being initialized above
             prepare_label_mapping_attributes(peer, fec, initatt, satt, 
propagating_, storedhcount);
             send_label(peer, fec, satt);
          }
      }
   }
}

As you see, propagating_ is set in the upper side and used in 
prepare_label_mapping_attributes but this function is used too in the lower 
side not being previously set as in the upper side.

>left in RAttribute is the incremented value.  The wording is quite clear, 
>given a
>that we are trying to determine if the value we would send (which is stored in
>as "pseudo-code". It may - in fact - include operations which are more or less

RAttribute->Hop count is used also in 14 (see below). In here (14) is it 
the modified hop count too?

     .........

       PMpA.14 Do RAttributes include a Hop Count?   <<<---- original hop 
count??
               If not, goto PMpA.21.

>specifications to describe the internal logical operations as they must appear
>I believe that "installing the label" is fairly clear, but to make it even 
>clearer,
>it means the following:
>
>1)    if this LSR is an intermediate LSR with respect to the LSP for which 
>this
>3)   if this LSR is an (effective) egress LSR with respect to the LSP for 
>which a
>    label is being defined, do whatever it is in your implementation that 
> corresponds
>    to either adding a new (or modifying an existing) ILM to point to an NHLFE
>    that includes the corresponding downstream next hop, encaps, etc. - and no
>    present the remaining packet for further processing (depending on whether

Ok, very clear. I think I have to advance a little bit more with my code to 
understand this better.

Best regards,

Leonardo Balliache

---

From: Eric Gray <[email-masked]>
Date: Tue, 19 Oct 2004 22:29:57 -0400

Leonardo,

    Let me see if I understand you.  You're asking me to review your code?

    :-)  (-:   :-)  (-:   :-)

    Try breaking this into steps and ask about the steps that aren't 
clear. So
far, you've copied a section out of the appendix (twice) and said that you
don't understand it.  Please be specific as to what it is you don't 
understand. 
Trying to make sense out of your code fragment - which is clearly not 100%
exactly congruent with the procedural steps and is out of context as well -
just gives me a huge headache.

    The reason why the procedure is not meant to be pseudo code is that
it describes what it is that the implementation is supposed to do. There is
no strict ordering or contextual mapping of the things your implementation
has to do to the way in which your implementation does them.  If you take
a broad look at how many ways there are to do the rest of the things that
any label switching implementation might do, you will quickly realize how
pointless it would be to try to cover all the ways in which this particular
set of "steps" might be done.

    As for PMpA.14 - it asks if there _is_ a hop count. For that purpose,
it is irrelevant whether it is the incremented or unincremented value. 
In any
case, I believe you understand the gist of that section.

--
Eric

Leonardo Balliache wrote:

> I think I didn't explain well. Here I copy again the spec and my code. 
> I understand that the spec is not a pseudo-code but it is so specific 
> that I'm not sure (I'm trying yet to understand well the logic) if 
> this observation is important:
>
> The spec:
>
>          propagating_ = find_ldp2rec(LDP2_LabelMappingMSG, 
> LDP2_RECEIVED, 0, nhop, fec, -1);
>               find_ldp2rec(LDP2_LabelMappingMSG, LDP2_RECEIVED, 0, 
> nhop, fec, -1) )  {
>             recatt = getatt_ldp2rec(LDP2_LabelMappingMSG, 
> LDP2_RECEIVED, nhop, fec, -1);
> prepare_label_mapping_attributes but this function is used too in the 
> lower side not being previously set as in the upper side.
>
>> The value is next used in PMpA.18 (not 14) and it should be clear 
>> from context,
>> from step PMpA.7 that the values 
>> RAttibute->hopCount=SAttribute->hopCount.
>>
>> Bear in mind that it is not the intention that this appendix is 
>> supposed to be treated
> RAttribute->Hop count is used also in 14 (see below). In here (14) is 
> it the modified hop count too?
>
>       PMpA.14 Do RAttributes include a Hop Count?   <<<---- original 
> hop count??
>               If not, goto PMpA.21.
>
>> 2)   if this LSR is an ingress LSR with respect to the LSP for which 
>> a label is
>>    label - or an ILM that instructs the receiving hardware to strip 
>> the label and
>> In essense, instead of saying "do whatever it is ...", the 
>> specification says "install
> Ok, very clear. I think I have to advance a little bit more with my 
> code to understand this better.
>
>> -- 
>> Eric
>
>
> Best regards,
>
> Leonardo Balliache
>
>
>
>
>
>

---

From: Leonardo Balliache <[email-masked]>
Date: Thu, 21 Oct 2004 11:16:13 -0400

Eric,

>    Let me see if I understand you.  You're asking me to review your code?

No, absolutely not. I thought the code could help to clear my question, but 
it is evident that it was a very bad idea.

>    Try breaking this into steps and ask about the steps that aren't clear. So
>understand. Trying to make sense out of your code fragment - which is 
>clearly not 100%

Sorry if I've bother you some way.

>set of "steps" might be done.

I agree, but perhaps the specification shouldn't be so specific. Working 
and revising the spec and coding it I have realized that you are right. 
Many questions are answered when one understand better the LDP logic.

Talking about "Recognize New FECs", I insist that:

1.- In "unsolicited independent control" function 
"prepare_label_mapping_attribute" is called. This function requires the 
argument "propagating_" which is set (before calling the function) to true 
if the LSR has received previously a label mapping for fec from nexthop. It 
is set to false otherwise.

2.- In "unsolicited ordered control" the function "prepare_label_mapping" 
is also called. But this time the argument it needs (propagating_) is not 
previously set. Can I suppose that it should be false if the LSR is the 
egress for that fec and true if the LSR has received previously a label 
mapping for fec from nexthop?

>it is irrelevant whether it is the incremented or unincremented value. In any

You are right, this is clear.

Best regards,

Leonardo Balliache

---

From: Eric Gray <[email-masked]>
Date: Fri, 22 Oct 2004 13:07:24 -0400

Leonardo,

    Thanks for being persistent.  :-)

    See below...

--
Eric

Leonardo Balliache wrote:

> ... SNIP ...
> I agree, but perhaps the specification shouldn't be so specific. 
> Working and revising
> the spec and coding it I have realized that you are right. Many 
> questions are answered
> when one understand better the LDP logic.
>
> "prepare_label_mapping_attribute" is
> called. This function requires the argument "propagating_" which is 
> set (before calling
> the function) to true if the LSR has received previously a label 
> mapping for fec from
> nexthop. It is set to false otherwise.
>
> 2.- In "unsolicited ordered control" the function 
> "prepare_label_mapping" is also called.
> But this time the argument it needs (propagating_) is not previously 
> set. Can I suppose
> that it should be false if the LSR is the egress for that fec and true 
> if the LSR has received
> previously a label mapping for fec from nexthop?

Okay, good question. In the Label Request case (LRq.9), careful reading 
will show that the
value passed to a prepare label mapping attributes function is the 
"constant" isPropagating
in the Ordered Control mode (sub-step 2). This step is not reached if  
the local LSR is
not either the egress, or in receipt of a previous label from its next 
hop for the FEC.

The wording difference is subtle, and easy to miss - but once you catch 
the difference,
it is clear.

The same applies in processing a Label Mapping (LMp.20, LMp.24 and 
LMp.29). You
would only reach one of these steps if A) you are currently in the 
process of processing a
Label Mapping (in which case you are - by definition - propagating).

However, in the "Recognize New FEC" case - specifically FEC.1, 
Downstream Unsolicited
Ordered Control, substep 2 - the value of the "variable" Propagating is 
not set (as it was in
Downstream Unsolicited Independent Control).  This is a good catch on 
your part, and may
be an indication that either nobody has run into this mode (as is true 
for me), or they were
able to figure it out (as is the case for you).

In fact, the setting of "Propagating" should not be part of the 
iteration, since the local LSR
has only one next hop for the given FEC, no matter how many upstream 
peers it may have.
That being the case, it is silly to set this "variable" at each 
iteration.  Also, as a result of that
consideration, it is clear that all of the steps in FEC.1, Downstream 
Unsolicited Ordered
Control, should be skipped if the local LSR is neither the egress nor in 
receipt of a Label
Mapping from its next hop.

Ina should fix this either by removing part of this section, or by 
changing it to read -

      FEC.1   Perform LSR Label Distribution procedure:

            For Downstream Unsolicited Independent Control

               1. Has LSR previously received and retained a label
                  mapping for FEC from Next Hop?
                  If so, set Propagating to IsPropagating.
                  If not, set Propagating to NotPropagating.

               2. Iterate through 5 for each Peer.

               3. Execute procedure Prepare_Label_Mapping_Attributes
                  (Peer, FEC, InitAttributes, SAttributes, Propagating,
                  Unknown hop count(0)).

               4. Execute procedure Send_Label (Peer, FEC, SAttributes)

               5. End iteration from 1.
                  Goto FEC.2.

            For Downstream Unsolicited Ordered Control

               1. Has LSR previously received and retained a label
                  mapping for FEC from Next Hop?
                  If so, set Propagating to IsPropagating and Goto 3.
                  If not, set Propagating to NotPropagating.

               2. Is LSR egress for the FEC?
                  If not, Goto 6.

               3. Iterate through 5 for each Peer.

               4. Execute procedure Prepare_Label_Mapping_Attributes
                  (Peer, FEC, InitAttributes, SAttributes, Propagating,
                  StoredHopCount).

               5. Execute procedure Send_Label (Peer, FEC, SAttributes)

               6. End iteration from 1.
                  Goto FEC.2.

            For Downstream On Demand Independent Control OR
            For Downstream On Demand Ordered Control

               1. Goto FEC.2.  (See Note 2.)

> ...  SNIP ...