Understanding MPLS Label Distribution

I’ve written several posts on different aspects of MPLS: How the FEC is key to the separation of control and forwarding functions in MPLS, the difference between implicit and explicit null labels, how label stacking works, the VPN forwarding plane, and the VPN control plane.

In almost all of those posts I’ve discussed label switching in one context or another. The Label Switched Path (LSP) is comprised of a set of entries in MPLS switching tables in the Label Switching Routers (LSRs) along the path from the LSP’s ingress to its egress, as shown here:

Each LSR along the path adds (pushes) or changes (swaps) the label to a different label that has meaning to the next downstream LSR along the path; the last LSR removes (pops) the label.

Figure 2 shows a switching table in one LSR. No push/swap/pop actions are shown in this simplified table; all actions are assumed to be a swap.

A packet arrives at Interface 2 with a label of 1434. The label is looked up in the switching table, which indicates that the packet is to be forwarded out Interface 4 with a label of 112463.

A significant detail to notice in the example of Figure 2 is that the incoming labels in the MPLS switching table are not associated with any interface. A packet with label 1434 could arrive on any interface, and it would be forwarded out Interface 4 with a label of 112463.

The significance is that the incoming labels have meaning only to that local switching table. When the LSR needs to switch packets for an LSP, it allocates (binds) an incoming label value to the LSP out of a local pool of available label values. Correct switching can occur only if the upstream LSR sends MPLS packets to this router with the correct label. The same upstream LSR attached to Interface 2 might also send MPLS packets with labels of 18 or 105, for example, and those packets would be switched differently than the packets with a label of 1434.

The usual way of describing this usage of label values – in which the incoming label value has meaning only to the local LSR – is to say that the label is locally significant. So some other LSR could see the same incoming label value and switch it differently.

I’ve tried to illustrate that concept a bit in Figure 2. Notice that an incoming label of 105 is switched out Interface 3 with a value of 16, while an incoming label of 100034 is switched out Interface 6, also with a label of 16. Presumably Interfaces 3 and 6 connect to different downstream LSRs; the label 16 has separate local meanings to those two downstream LSRs.

At the same time, notice that an incoming label of 9295 is switched out Interface 5 with a label of 88, while an incoming label of 26312 is switched out the same interface but with a label of 17. Presumably Interface 5 connects to a single downstream LSR, but the two label values will be switched differently by that one LSR.

Finally, notice that an incoming label of 22 is switched out Interface 2, with the same label value of 22. But even though the value is the same, it’s not the same label; the incoming label 22 has meaning only to the local LSR in Figure 2; the outgoing label 22 has meaning only to the downstream LSR connected to Interface 2.

And that brings us to the point of this post. If label values have meaning only to the local LSR, how does an upstream LSR know what label to use in its outgoing MPLS packets? We could of course statically configure the switching tables at each LSR, but that is impractical in a network of any reasonable size.

Instead, we need a means by which a downstream LSR can tell a directly connected upstream LSR what label to use (Figure 3).

In the example of Figure 2, the downstream LSR connected to the depicted LSR’s Interface 4 told it to use label 112463 for packets sent to it belonging to some given LSP. The depicted LSR, in turn, somehow knew that the next hop on the path toward the ingress of that LSP is connected to its Interface 2, allocated the local label value 1434 to the LSP, and told the upstream router to use that label in packets belonging to the LSP.

There are two functions in this basic description:

* Signaling is the means by which LSRs all along the path know that they are a part of a given LSP. In our example, it is a signaling function by which the LSR knows that the internal transit path for the LSP depicted goes from Interface 2 to Interface 4.

* Label distribution is the means by which an LSR tells an upstream LSR what label value to use for a particular LSP.

In the next post I’ll begin what will likely be a short series on MPLS LSP signaling, but in this post I want to describe the label distribution function.

There are four protocols that can perform the label distribution function:

* Label Distribution Protocol (LDP)

* Resource Reservation Protocol with Traffic Engineering Extensions (RSVP-TE)

* Constraint-Based Routed LDP (CR-LDP)

* Multiprotocol BGP

LDP and RSVP-TE are the two most commonly used label distribution protocols; I’ve mentioned them in a past post in relation to relative scaling characteristics, and will go into them at more depth in subsequent posts.

CR-LDP is an extension of LDP that adds signaling capabilities almost identical to those of RSVP-TE. It isn’t in common use – not because there’s anything wrong with the protocol, but simply because the two MPLS vendors dominating the market, Cisco and Juniper, chose to support RSVP-TE exclusively. I won’t write more about CR-LDP unless it comes back into vogue, which is highly unlikely.

Multiprotocol BGP supports label distribution through the IPv4 and IPv6 labeled unicast address families. This is a specialized function in support of Layer 3 MPLS VPNs; I’ll probably discuss it in more detail in one or more later posts on Inter-AS VPNs, but no promises.

For now, let’s get back to LDP and RSVP-TE.

These two protocols tend to be a source of confusion for people who are new to MPLS. I often hear from people who ask me to help them understand “the difference between LDP LSPs and RSVP-TE LSPs.” Fundamentally, an LSP is just an LSP; LDP and RSVP-TE are merely two different means of telling neighboring routers what label to use. However, saying it that way trivializes what are in fact distinct differences.

Using its signaling element, RSVP-TE sets up an LSP end-to-end (ingress-to-egress). So label distribution is coordinated among all the LSRs along a path. LDP, on the other hand, has no signaling element. It sets up LSPs hop-by-hop, and labels can be distributed between neighbors independently of what other LSRs along the path are doing.

Because it has no signaling element, LDP depends on the network’s IGP to determine the path an LSP must take, whereas RSVP-TE can set up paths independently of what the IGP determines to be the optimal path to a destination – hence the Traffic Engineering part of the protocol.

Personally, I find RSVP-TE easier to understand than LDP. So over the next couple of posts I’ll describe how RSVP-TE sets up an LSP, and how it determines what path to use for the LSP. I’ll then go into how LDP works.

See you soon.

Rocky Mountain IPv6 Summit

The Rocky Mountain IPv6 Task Force will be holding its first Rocky Mountain IPv6 Summit in Denver on April 9^th. We’re lining up a good group of speakers and a very informative agenda; if you’re in the Colorado-Wyoming-New Mexico region and want to know more about IPv6, I hope to see you there!

You can get more information, and sign up, at:

https://www.rmv6tf.org/SpringEvent.htm