LDP. Ordered Label Distribution Control explained

Major network vendors (except Cisco) default to the following modes of Label Distribution Protocol (LDP) operation (as per RFC 5036 LDP Specification):

  • Label Distribution (Advertisement): Downstream Unsolicited (section 2.6.3)
  • Label Control: Ordered (section 2.6.1)
  • Label Retention: Liberal (section 2.6.2)

This topic focuses on Ordered Label Distribution Control procedure to help you better understand when LSR actually assigns labels and initiates transmission of a label mapping.

Both RFC 3031 Multiprotocol Label Switching Architecture and RFC 5036 LDP Specification give definition for Ordered Label Distribution Control mode:

RFC 3031: In Ordered LSP Control, an LSR only binds a label to a particular FEC if it is the egress LSR for that FEC, or if it has already received a label binding for that FEC from its next hop for that FEC.

RFC 5036: When using LSP Ordered Control, an LSR may initiate the transmission of a label mapping only for a FEC for which it has a label mapping for the FEC next hop, or for which the LSR is the egress. For each FEC for which the LSR is not the egress and no mapping exists, the LSR MUST wait until a label from a downstream LSR is received before mapping the FEC and passing corresponding labels to upstream LSRs.

Lets break this definition into distinct sentences:

  1. In case LSR is the egress router for a FEC then LSR maps label to FEC X and transmits this label mapping to its LDP peers;
  2. In case LSR is not the egress router for a FEC X then in order to map a label for this FEC and to propagate this label mapping to its peers, it has to wait until it receives a label mapping for this particular FEC X from its downstream LDP peer.

In this manner the entire LSP is established before MPLS begins to map data onto the LSP, preventing early data mapping from occurring on the first LSR in the path.

Let’s take a look at this simple topology to illustrate these steps.

Routers R1-R2-R3 have OSPF enabled on their interfaces and announce their loopback (or system, as long as we’re using with Alcatel-Lucent routers in this example) IP addresses. So every router has a route to other router’s loopback address.

To investigate label mappings creation and propagation processes lets dive into step-by-step LDP operation for the particular Forward Equivalence Class (FEC) 10.10.10.1/32 – which is the loopback address of the router R1.

 

Everything starts with R1 which is an Egress router for the FEC 10.10.10.1/32. According to abovementioned Ordered Distribution Control mode definition R1 (again, as an Egress router) has a right to create a binding for the FEC 10.10.10.1/32. Such bindings, created for the FECs which are local to a router often called “Local bindings”.

Let’s check that R1 actually has this local label mapping in its Label Information Base:

Yep, there it is –  R1 tells us that he assigned a local label 131071 for the FEC 10.10.10.1/32. Local bindings appear in the “IngLbl” column. Ingress label 131071 means that R1 expects its LDP peers to send their MPLS packets destined to the FEC 10.10.10.1/32 equipped with the label 131071 on top of MPLS label stack.

Another benefit for being an Egress router for the FEC 10.10.10.1/32 is that R1 could send his locally created binding to its peers right away. Therefore, R1 sends this mapping to its LDP peer 10.10.10.2:0 (R2).

 

When R2 receives this label mapping message from R1 regarding the FEC 10.10.10.1, it follows this logic: I have received the label mapping for the FEC 10.10.10.1 sent from R1. Thanks to Liberal Retention mode I place this label binding into my LIB under “EgrLbl” column without further investigation. Such label mapping is often called remote label mapping since it came from the remote LDP peer.

But in order to be able to make its own label mapping for the 10.10.10.1/32 Ordered Label Distribution Control procedure demands R2 to check if remote binding was received from a downstream router for this particular FEC. Yes, it is, R1 is downstream router regarding data flow destined to the FEC 10.10.10.1/32.

Good, R2 recognized R1 as a downstream router and therefore allowed to make its own label mapping (recall ordered control mode definition) for this FEC and propagate its mapping update to R3.

R2 did not send this update to R1, because R1 is the owner of 10.10.10.1/32 and will never be a transit label switching router for this FEC.

 

Lets see R2’s LIB:

Take a look at the highlighted strings, R2 chose a label value of 131070 for the FEC and sent this binding to LDP peer with identifier 10.10.10.3:0 (which is R3). We will cover the reason behind existence of the label 131070 in “EgrLbl” for peer 10.10.10.3:0 a bit later.

Ok, R2 sent his mapping for 10.10.10.1/32 to R3, what happens next?

R3 follows the same logic as R2 did when it receives label mapping message from R2. In the same manner R3 installs remote label binding from R2, checks that R2 positioned downstream regarding data flow to address 10.10.10.1/32 and assigns local label binding for this FEC. But one thing is different with R3 – since R2 is not an owner for the FEC 10.10.10.1 then R3 can send label mapping message backward to R2 – see timestamp E.

 

Lets take a look at R3’s LIB:

When R2 receives this label mapping message from R3 regarding FEC 10.10.10.1, it follows the same logic: I have received the label mapping for the FEC 10.10.10.1. I will place this label binding into my LIB no matter what. This explains the egress label value 131070 in R2’s LIB (see Listing #4) from peer 10.10.10.3:0.

Although R3 installed a label, it will not take any actions regarding this update since it came from R3, which is not a downstream router for the FEC 10.10.10.1/32.

This completes label propagation for the FEC 10.10.10.1/32.

Downstream or not?

You may have already noticed that the key in making a decision to create a label mapping for a FEC is if the label mapping came from a downstream router? But how does a router decide if its peer is downstream router or upstream? Let’s think about it…

Rewind to Timestamp B. R2 receives a label mapping message from R1 and needs to decide if R1 is a downstream router regarding FEC 10.10.10.1/32? It looks into Forwarding Information Base for this prefix and sees the next-hop address for it is 10.1.2.1:

So what? We have a next-hop, but how do we know if IP address 10.1.2.1 belongs to R1? To asnswer this question we need to open RFC 5036 LDP Specification once again. Navigate to section 2.7  LDP Identifiers and Next Hop Addresses:

To enable LSRs to map between a peer LDP Identifier and the peer’s addresses, LSRs advertise their addresses using LDP Address and Withdraw Address messages.

Well, it seems LDP peers share LDP Address messages where they communicate all of their configured IP addresses, let’s see under the hood:

That is the answer. LDP speaker should tell its peers about the addresses it has configured. This info communicated via Address Messages and helps remote peers to map LDP indentifier to an IP address.

With this information provided R2 now can tell for sure that next-hop address it has in its Forwarding Information Base belongs to R1. And that is how R2 can tell that R1 is a downstream router – by matching its next-hop address from FIB with an IP addresses provided in an Address Message from R1.

And this is all for this time. If you have any questions regarding this topic – do not hesitate, I will gladly address them.
noshut# exit all

Roman Dodin

Network engineer at Nokia
Eagerness to learn multiplied by passion to share.
You can reach me at LinkedIn
  • http://dmitryfigol.blogspot.com/ Dmitry Figol

    Thanks, Roman, great article. Previously I didn’t know that R3 will send label mapping back to R2.
    I have a question though.
    What is the algorithm for choosing the label value used by Alcatel-Lucent devices?
    And why does the router choose the same label for the particular FEC? I think that this behavior complicates a bit further troubleshooting

    • http://hellt.ru/ Roman Dodin

      Hi, Dmitry.
      Actually labels allocation is quite a simple process. ALU routers start to bind the labels from the highest possible value to the lowest. Thats why every router in this article started allocation from #131071 (max label value).
      And this process is FEC-unaware.

      Sadly, ALU’s Service Router OS does not have mechanisms to manually restrict label space (like Cisco does) for ease of tshooting.

      • http://dmitryfigol.blogspot.com/ Dmitry Figol

        Thanks, I get used to cisco label assignment, which is ascending, so the values are quite low. Thought that maybe ALU uses some “hashing” algorithm to choose label value. It seems not, just descending order.

  • Alexander Okonnikov

    Cool, Roman :-) Only comment is that it is not mandatory to include all IP addresses of LSR in its Address Message. It is recommended (SHOULD per standard), but is not required. In SR-OS we have special option – “adv-adj-addr-only” – to omit unneeded addresses from Address TLV. Also it was noted that with this option enabled upstream LSR reflects Label Mapping received from adjacent egress LSR (probably due to absence of /32 address of FEC Address TLV). Not advertising Label Mapping back to egress LSR seems like some SR-OS implementation intelligence on top of standard. Standard doesn’t prescribes some split-horizon mechanism for propagating Label Mappings. For example, Cisco IOS reflects mapping back.

    • http://hellt.ru/ Roman Dodin

      Thanks for your remark, @alexanderokonnikov:disqus! Absolutely right, I will remove mandatory statement.

      Indeed this “split-horizon” behaviour was a bit unclear for me. Something similar is described on page 107 (https://tools.ietf.org/html/rfc5036#page-107) item 13 regarding “Receive Label Mapping” procedure though I am not sure that this is the same thing.

      As to Cisco LDP operation, I ran into some interesting comment describing why would Cisco use Independent control mode and the bottom line was “a long time ago label switching was fasted than IP lookups so every FEC wanted to get a label as fast as possible”. Dont know if its true, though =)

      • Alexander Okonnikov

        Yes, independent control is valid only for label switching of IPv4 traffic. For other types of traffic (IPv6, VPNs) it is dangerous.