LDP Label Distribution Modes and Label Spaces

LDP Label Distribution Modes and Label Spaces

RFC 5036 defines three pairs of choices for how LDP behaves: when to advertise a label, how much of what is received to keep, and in what order to advertise upstream. Only one of the three is selectable in real implementations; the others are fixed. This article explains the three pairs and the idea of a label space, then confirms what can be confirmed in an IOS XR (XRd) lab. The basics of LDP are covered in What Is LDP.

The three pairs

All three share the same premise: the downstream LSR chooses the label and hands it upstream. In MPLS the receiving side picks the label, so the LSR nearer the destination is the one that says “use this label when you send to me”.

Label advertisement: DU and DoD

Downstream Unsolicited sends one Label Mapping for every prefix it holds as soon as the session comes up, without considering whether the peer will use them. Downstream on Demand waits for a Label Request from upstream and answers with the Label Mapping for that FEC.

DoD exists for environments such as ATM where label resources are scarce. On the Ethernet-based routers of today labels do not run out, so the default is DU.

On IOS XR, session downstream-on-demand with <ACL> under mpls ldp names the peers to use DoD with. Both routers must be configured or the session stays DU.

Label retention: liberal and conservative

LDP receives Label Mappings from every peer it has a session with. Only those from the next hop chosen by the IGP are actually used.

liberal keeps the rest as well. It costs memory, but when routing changes and the next hop swaps, the label it already holds can be used immediately. conservative keeps only the next hop’s and has to ask again when routing changes. It saves resources at the cost of convergence time.

Label distribution control: independent and ordered

independent allows an LSR to advertise its own label upstream before it has received one from downstream. ordered does not advertise upstream until a label has arrived from downstream, the egress LSR being the exception because it is the destination itself.

Ordered means labels are only advertised once the LSP is complete end to end, which avoids traffic entering an LSP that breaks partway. Independent gives up that guarantee in exchange for faster convergence.

What implementations actually let you choose

Only label advertisement is selectable. The other two are fixed per implementation.

All three use liberal retention. Label distribution control is the opposite between Cisco and Juniper. Juniper’s documentation (Supported LDP Standards) states plainly, “Ordered mode is supported, but not Independent mode.” and “Liberal mode is supported, but not Conservative mode.”

IOS XE has mpls ldp atm control-mode which accepts ordered and independent, but it applies only to LC-ATM interfaces, not to Ethernet. The RFC offers two choices because it had to cover ATM as well; router implementations have settled on liberal plus independent, or liberal plus ordered.

When control mode differs across a mixed network, the LDP message exchange itself is unchanged. Only the order in which the LSP completes differs.

This lab confirms only label advertisement and label retention. Label distribution control cannot be configured, so it was not observed.

Label spaces

A label space is the scope in which an LSR manages label values (RFC 5036 section 2.2.1).

Which one is in use shows in the last two octets of the LDP Identifier (section 2.2.2). For per-platform they are always zero, so 3.3.3.3:0 means per-platform.

With per-platform, a packet arriving on any link resolves to the same forwarding entry for the same label value. That is why a single LDP session suffices even with several links to the same peer.

Lab verification

Lab setup

CE1, PE1, P1, P2, PE2, and CE2 are connected in a row, with a detour through P3 between P1 and PE2. PE1 / P1 / P2 / P3 / PE2 in AS 65001 form the MPLS network, with OSPF (area 0, every link network point-to-point) distributing routes and LDP distributing labels. CE1 and CE2 peer with the PEs over eBGP, and PE1 and PE2 peer over iBGP between their Loopback0 addresses (next-hop-self). Every router is XRd.

The detour (P1 - P3 - PE2) carries an OSPF cost of 50, so the initial path runs through P2.

The dynamic label range is split per device. With the defaults, P2 and P3 can hand out the same value, and it would be impossible to tell whose label is in use when the path changes.

The subject is 6.6.6.6/32 (PE2’s Loopback0) as seen from P1. Captures were taken per STEP on three segments: PE1 - P1, P1 - P2 and P1 - P3.

Verification steps

Labels go to every peer with a session

P1 holds sessions with three peers.

RP/0/RP0/CPU0:P1#show mpls ldp neighbor brief
Mon Sep 28 05:03:04.612 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
2.2.2.2:0          N   N    00:07:51    1     0     3     0     11     0
4.4.4.4:0          N   N    00:07:40    1     0     3     0     10     0
5.5.5.5:0          N   N    00:07:37    1     0     3     0     10     0

The binding for 6.6.6.6/32 holds a label from all three of them. With the ranges split per device, the value itself says who advertised it.

RP/0/RP0/CPU0:P1#show mpls ldp bindings 6.6.6.6/32
Mon Sep 28 05:03:07.257 UTC
6.6.6.6/32, rev 20
	Local binding: label: 40005
	Remote bindings: (3 peers)
	    Peer                Label
	    -----------------   ---------
	    2.2.2.2:0           30006
	    4.4.4.4:0           50006
	    5.5.5.5:0           60006

Under Downstream Unsolicited the labels are sent whether or not the peer will use them. PE1 (2.2.2.2) sits upstream of P1 and is never on the way to 6.6.6.6/32, yet its label arrives all the same.

RP/0/RP0/CPU0:P1#show mpls ldp neighbor detail
Mon Sep 28 05:03:04.968 UTC

Peer LDP Identifier: 2.2.2.2:0
  TCP connection: 2.2.2.2:646 - 3.3.3.3:34682
  Graceful Restart: No
  Session Holdtime: 180 sec
  State: Oper; Msgs sent/rcvd: 21/23; Downstream-Unsolicited

Unused labels are kept (liberal)

Only the label received from the next hop chosen by the IGP is actually used for forwarding. P1’s next hop for 6.6.6.6/32 is P2 (10.3.4.4).

RP/0/RP0/CPU0:P1#show route 6.6.6.6/32
Mon Sep 28 05:03:07.697 UTC

Routing entry for 6.6.6.6/32
  Known via "ospf 1", distance 110, metric 3, type intra area
  Installed Sep 28 04:55:32.577 for 00:07:35
  Routing Descriptor Blocks
    10.3.4.4, from 6.6.6.6, via GigabitEthernet0/0/0/1
      Route metric is 3
  No advertising protos.

In the forwarding table, only 50006 advertised by P2 appears as the outgoing label.

RP/0/RP0/CPU0:P1#show mpls forwarding prefix 6.6.6.6/32
Mon Sep 28 05:03:09.123 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
40005  50006       6.6.6.6/32         Gi0/0/0/1    10.3.4.4        23798

The labels from PE1 and P3 nevertheless stay in the bindings (shown above). That is liberal retention. A conservative LSR would keep only the one from the next hop and discard the rest.

When the path changes, the held label takes over

The cost of P1 - P2 is raised to 100 at both ends.

RP/0/RP0/CPU0:P1#show configuration commit changes last 1
Mon Sep 28 05:05:32.668 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 area 0
  interface GigabitEthernet0/0/0/1
   cost 100
  !
 !
!
end

RP/0/RP0/CPU0:P2#show configuration commit changes last 1
Mon Sep 28 05:05:39.694 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 area 0
  interface GigabitEthernet0/0/0/0
   cost 100
  !
 !
!
end

The path moves to the detour through P3.

RP/0/RP0/CPU0:P1#show route 6.6.6.6/32
Mon Sep 28 05:10:14.118 UTC

Routing entry for 6.6.6.6/32
  Known via "ospf 1", distance 110, metric 101, type intra area
  Installed Sep 28 05:05:32.044 for 00:04:42
  Routing Descriptor Blocks
    10.3.5.5, from 6.6.6.6, via GigabitEthernet0/0/0/2
      Route metric is 101
  No advertising protos.

The outgoing label in the forwarding table changes from P2’s 50006 to P3’s 60006. The incoming label (40005) does not change.

RP/0/RP0/CPU0:P1#show mpls forwarding prefix 6.6.6.6/32
Mon Sep 28 05:03:09.123 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
40005  50006       6.6.6.6/32         Gi0/0/0/1    10.3.4.4        23798

RP/0/RP0/CPU0:P1#show mpls forwarding prefix 6.6.6.6/32
Mon Sep 28 05:10:15.561 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
40005  60006       6.6.6.6/32         Gi0/0/0/2    10.3.5.5        23798

RP/0/RP0/CPU0:P1#show mpls forwarding prefix 6.6.6.6/32
Mon Sep 28 05:17:21.757 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
40005  50006       6.6.6.6/32         Gi0/0/0/1    10.3.4.4        23798

The bindings are unchanged from STEP 0. The label was already in hand, so LDP does nothing at the switchover: the capture of the detour (P1 - P3) carries only KeepAlives.

$ tshark -r - -Y 'ldp && tcp' -T fields -e frame.number -e frame.time_relative -e _ws.col.info \
    < mpls-ldp-modes-step1-p1p3.pcap
7	8.061757000	Keep Alive Message
77	15.590830000	Keep Alive Message
160	57.677007000	Keep Alive Message
169	69.295474000	Keep Alive Message

A traceroute from CE1 shows the label changing from the second hop onwards, and all 50 pings still succeed.

RP/0/RP0/CPU0:CE1#traceroute 192.168.2.1 source 192.168.1.1 timeout 1 probe 2 maxttl 7
Mon Sep 28 05:01:09.909 UTC

Type escape sequence to abort.
Tracing the route to 192.168.2.1

 1  10.1.2.2 7 msec  4 msec
 2  10.2.3.3 [MPLS: Label 40005 Exp 0] 11 msec  10 msec
 3  10.3.4.4 [MPLS: Label 50006 Exp 0] 10 msec  9 msec
 4  10.4.6.6 20 msec  11 msec
 5  10.6.7.7 14 msec  *

RP/0/RP0/CPU0:CE1#traceroute 192.168.2.1 source 192.168.1.1 timeout 1 probe 2 maxttl 7
Mon Sep 28 05:08:16.288 UTC

Type escape sequence to abort.
Tracing the route to 192.168.2.1

 1  10.1.2.2 6 msec  5 msec
 2  10.2.3.3 [MPLS: Label 40005 Exp 0] 67 msec  12 msec
 3  10.3.5.5 [MPLS: Label 60006 Exp 0] 16 msec  13 msec
 4  10.5.6.6 17 msec  14 msec
 5  10.6.7.7 20 msec  *

This is what liberal retention buys. A conservative LSR would have to request a label after the path changed, which takes longer.

Downstream on Demand: one side alone changes nothing

PE1 alone gets an ACL naming the peer and session downstream-on-demand.

RP/0/RP0/CPU0:PE1#show configuration commit changes last 1
Mon Sep 28 05:19:45.396 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
ipv4 access-list DOD-PEERS
 10 permit ipv4 host 3.3.3.3 any
!
mpls ldp
 session downstream-on-demand with DOD-PEERS
!
end

The session is re-established, but the mode stays Downstream-Unsolicited.

RP/0/RP0/CPU0:PE1#show mpls ldp neighbor detail
Mon Sep 28 05:23:11.375 UTC

Peer LDP Identifier: 3.3.3.3:0
  TCP connection: 3.3.3.3:59177 - 2.2.2.2:646
  Graceful Restart: No
  Session Holdtime: 180 sec
  State: Oper; Msgs sent/rcvd: 17/17; Downstream-Unsolicited

With both ends set, Label Requests flow

The same configuration goes on P1.

RP/0/RP0/CPU0:P1#show configuration commit changes last 1
Mon Sep 28 05:26:54.620 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
ipv4 access-list DOD-PEERS
 10 permit ipv4 host 2.2.2.2 any
!
mpls ldp
 session downstream-on-demand with DOD-PEERS
!
end

PE1 now reports Downstream-on-Demand.

RP/0/RP0/CPU0:PE1#show mpls ldp neighbor detail
Mon Sep 28 05:30:21.354 UTC

Peer LDP Identifier: 3.3.3.3:0
  TCP connection: 3.3.3.3:26491 - 2.2.2.2:646
  Graceful Restart: No
  Session Holdtime: 180 sec
  State: Oper; Msgs sent/rcvd: 15/15; Downstream-on-Demand

The advertisement mode is per session. P1 uses DoD with PE1 while staying at DU with P2 and P3. In show mpls ldp neighbor brief, only the label count from PE1 (2.2.2.2) has dropped, because nothing is sent that was not requested.

RP/0/RP0/CPU0:P1#show mpls ldp neighbor brief
Mon Sep 28 05:31:38.657 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
4.4.4.4:0          N   N    00:36:14    1     0     3     0     10     0
5.5.5.5:0          N   N    00:36:11    1     0     3     0     10     0
2.2.2.2:0          N   N    00:04:38    1     0     3     0     1      0

The capture now carries Label Request messages, which never appear under DU. They come after Initialization, KeepAlive and Address, and Label Mapping answers them.

$ tshark -r - -Y 'ldp && tcp' -T fields -e frame.number -e frame.time_relative -e ip.src -e _ws.col.info \
    < mpls-ldp-modes-step4-pe1p1.pcap
1	0.000000000	3.3.3.3	Keep Alive Message
159	11.189700000	3.3.3.3	Initialization Message
171	15.830506000	3.3.3.3	Initialization Message
172	15.850426000	2.2.2.2	Initialization Message Keep Alive Message
173	15.854649000	3.3.3.3	Keep Alive Message
174	15.858092000	2.2.2.2	Address Message
175	15.860655000	3.3.3.3	Address Message
179	16.494015000	3.3.3.3	Label Request Message [Malformed Packet]
180	16.497699000	2.2.2.2	Label Mapping Message

No.179 is a Label Request that P1 sent to PE1, naming the FEC it wants a label for as a Prefix FEC.

Label Distribution Protocol
    Version: 1
    PDU Length: 26
    LSR ID: 3.3.3.3
    Label Space ID: 0
    Label Request Message
        0... .... = U bit: Unknown bit not set
        Message Type: Label Request Message (0x401)
        Message Length: 16
        Message ID: 0x000000a4
        FEC
            00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x0)
            TLV Type: FEC (0x100)
            TLV Length: 8

tshark marks this packet [Malformed Packet], but its contents follow RFC 5036 with nothing missing. The FEC TLV (0x0100) has length 8, and the following 8 bytes are the Prefix FEC element (type 02, address family 0001, prefix length 20 = 32, value 02 02 02 02 = 2.2.2.2).

0040  04 01 00 10 00 00 00 a4 01 00 00 08 02 00 01 20   ...............
0050  02 02 02 02                                       ....

It is Wireshark that cannot finish dissecting a Label Request; the router processes it correctly and answers with a Label Mapping (No.28 above).

The label space is per-platform

The :0 at the end of the LDP Identifier means one label space for the whole device. P1’s parameters likewise draw no distinction per label space.

RP/0/RP0/CPU0:P1#show mpls ldp parameters
Mon Sep 28 05:03:03.796 UTC

LDP Parameters:
  Role: Active
  Protocol Version: 1
  Router ID: 3.3.3.3
  Null Label:
    IPv4: Implicit
  Session:

Per-interface label spaces belong to setups such as LC-ATM, where the link owns the label resource; they cannot be selected in an Ethernet lab. Only the per-platform side is visible here.

Reachability

Whatever the advertisement mode or the path, traffic from CE1 to CE2 keeps flowing in every STEP.

RP/0/RP0/CPU0:CE1#ping 192.168.2.1 source 192.168.1.1 count 50 timeout 1
Mon Sep 28 05:01:08.111 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.2.1 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 13/16/36 ms

Packets lost while the path switched

The reachability above was measured after each change had converged. How many packets were lost during the switch itself comes from a ping started before the change and left running across it (count 150 interval 100 timeout 1).

Verification config and show output

For every STEP the following files were collected from all seven routers, one file per router. The verification config is the ..._run.txt (the final state is the one from STEP 5). Each STEP was collected in the order “clear the counters, ping, then show”.

STEP 0: Initial state

STEP 1: Raise the P1 - P2 cost to 100

STEP 2: Restore the cost

STEP 3: Configure DoD on PE1 only

STEP 4: Configure it on P1 as well

STEP 5: Remove DoD (final state)

Packet captures were taken per STEP on the three segments.

References

The implementation table draws on Supported LDP Standards (Juniper Networks) (checked 2026-09-23).

Book: Luc De Ghein, MPLS Fundamentals (Cisco Press, 2006), Chapters 2 and 4

Related articles

• What Is MPLS
• MPLS Labels and the Label Stack
• MPLS Label Operations (push / swap / pop) and PHP
• MPLS TTL Processing and MTU
• What Is LDP
• LDP Label Distribution Modes and Label Spaces
• LDP-IGP Synchronization and LDP Session Protection
• LDP label advertisement control (filtering)
• LDP session authentication (TCP MD5)
• MPLS OAM (LSP ping and LSP traceroute)
• What Is MPLS TE (RSVP-TE)
• MPLS TE CSPF and Path Constraints (Bandwidth, Affinity, TE Metric)
• Steering Traffic into MPLS TE Tunnels
• MPLS TE Fast Reroute (Link and Node Protection)
• MPLS TE Fast Reroute (Auto-Tunnel Backup and SRLG)
• MPLS QoS (EXP and Uniform / Pipe / Short-Pipe)
• MPLS QoS Rate Control and Queuing (policer / shaper / priority)