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:
- In case LSR is the egress router for a FEC X then LSR maps label to FEC X and transmits this label mapping to its LDP peers;
- 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.
A:R1# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.1.2.0/24 Local Local 00h08m36s 0
toR2 0
10.2.3.0/24 Remote OSPF 00h04m20s 10
10.1.2.2 200
10.10.10.1/32 Local Local 00h08m36s 0
system 0
10.10.10.2/32 Remote OSPF 00h08m05s 10
10.1.2.2 100
10.10.10.3/32 Remote OSPF 00h01m22s 10
10.1.2.2 200
-------------------------------------------------------------------------------
No. of Routes: 5
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
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:
A:R1# show router ldp bindings
===============================================================================
LDP Bindings (IPv4 LSR ID 10.10.10.1:0)
(IPv6 LSR ID ::[0])
===============================================================================
LDP IPv4 Prefix Bindings
===============================================================================
Prefix IngLbl EgrLbl
Peer EgrIntf/LspId
EgrNextHop
-------------------------------------------------------------------------------
10.10.10.1/32 131071U --
10.10.10.2:0 --
--
<-- omitted -->
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.
*A:R2# show router ldp bindings prefixes prefix 10.10.10.1/32
===============================================================================
LDP Bindings (IPv4 LSR ID 10.10.10.2:0)
(IPv6 LSR ID ::[0])
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
===============================================================================
LDP IPv4 Prefix Bindings
===============================================================================
Prefix IngLbl EgrLbl
Peer EgrIntf/LspId
EgrNextHop
-------------------------------------------------------------------------------
10.10.10.1/32 -- 131071
10.10.10.1:0 1/1/1
10.1.2.1
< omitted >
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:
*A:R2# show router ldp bindings prefixes prefix 10.10.10.1/32
===============================================================================
LDP Bindings (IPv4 LSR ID 10.10.10.2:0)
(IPv6 LSR ID ::[0])
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
===============================================================================
LDP IPv4 Prefix Bindings
===============================================================================
Prefix IngLbl EgrLbl
Peer EgrIntf/LspId
EgrNextHop
-------------------------------------------------------------------------------
10.10.10.1/32 -- 131071
10.10.10.1:0 1/1/1
10.1.2.1
10.10.10.1/32 131070U 131070
10.10.10.3:0 --
--
-------------------------------------------------------------------------------
No. of IPv4 Prefix Bindings: 2
===============================================================================
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:
A:R3# show router ldp bindings prefixes prefix 10.10.10.1/32
===============================================================================
LDP Bindings (IPv4 LSR ID 10.10.10.3:0)
(IPv6 LSR ID ::[0])
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
===============================================================================
LDP IPv4 Prefix Bindings
===============================================================================
Prefix IngLbl EgrLbl
Peer EgrIntf/LspId
EgrNextHop
-------------------------------------------------------------------------------
10.10.10.1/32 131070N 131070
10.10.10.2:0 1/1/2
10.2.3.2
-------------------------------------------------------------------------------
No. of IPv4 Prefix Bindings: 1
===============================================================================
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:
*A:R2# show router fib 1 10.10.10.1/32
===============================================================================
FIB Display
===============================================================================
Prefix [Flags] Protocol
NextHop
-------------------------------------------------------------------------------
10.10.10.1/32 OSPF
10.1.2.1 (toR1)
-------------------------------------------------------------------------------
Total Entries : 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.