Dear friend,
A couple of years ago I thought that MPLS is almost identical to LDP meaning that labels must be distributes by this protocols. I knew that there was BGP as well, but its solely task, which was related to MPLS, was to distribute VPN routes and labels. Now I understand, how far from reality I was. That’s why I want to share with you solid structure, what MPLS label is and how it can be distributed.

Divide and conquer

What is MPLS label actually? It can mean virtually everything in reality, that’s why there are a lot of applications built on top of MPLS technology. In order not to get lost in these jungles, we can split MPLS labels into two big categories, which are called “transport labels” and “service labels”. The first one is about how to send the packet from one point in the network (ingress PE router in MPLS case) to another one (egress PE router). In this article we deal with this type of labels. The “service labels” usually maps traffic that is transported over transport labels to a certain service (L2 or L3 VPN) at egress PE router. This explanation may be quite rough but it shows the essence of MPLS.

Transport labels

As I’ve just mentioned, transport labels are used to deliver traffic from ingress PE to egress PE. So in general we can say that the transport labels relate to the egress PEs. Let’s take a step from MPLS aside and take a look at normal IP packet forwarding. Usually we have destination-based packet forwarding, where each router on the way to destination looks into packet’s IP header for destination IP address, then it looks for the best route in its own routing table and send the packet further.

Usually user traffic isn’t destined to the network devices themselves. For sure there are a lot of traffic that is sent or terminated at network devices, but it is mostly management (ssh, telnet, snmp) or control (routing/switching protocols and so on) traffic. Instead of it the user traffic is passing by through the network (let’s call it SP core). In this SP core the transport label point to the egress PE, which is actually the point, where the customer traffic leaves the SP core. So basically the transport labels are labeled to IP addresses of the egress devices. Which IP address? Almost in all cases it’s the IP address that is used in iBGP as a next-hop, what is usually some kind of loopback IP. Such mapping is necessary, because in modern networks BGP is used for all services:
• L3 IPv4/IPv6 global Internet transit (BGP free core)
• L2 point-to-point VPN (AToM, E-LINE, PW, PWE3 and so on)
• L2 multipoint VPN (VPLS, EVPN, PBB)
• L3 IPv4/IPv6 unicast VPN (all types of BGP)
• L3 IPv4/IPv6 multicast VPN (mVPN + BGP AD + BGP PIM signaling)
• IPv4 BGP labeled unicast (BGP-LU, IGP free network)

BGP isn’t the only protocol that is used in SP core right now, because many of described services were done by other protocols like mGRE (multicast) or LDP (L2 point-to-point and multipoint VPNs) for decades. But nowadays it really can replace all other protocols for service labels distribution. Let’s take a quick look on packet life in MPLS

The logic is pretty straightforward:
1) At ingress PE we add service label (labels) provided by egress PE to the traffic
2) Then we add transport label (labels) that points to that egress PE
3) Ingress PE sends the packet to the SP core
4) The routers in the SP core (they are called P routers) don’t speak BGP at all. They just swap the transport label pushing the packet to the egress PE and that’s it
5) The packet comes to the egress PE
6) The egress PE looks for the service label and sends the packet further accordingly.

I always use word “egress”, because MPLS labels are unidirectional. It means that they are allocated per prefix (usually), and returning traffic will use another set of labels. We also can imagine that the router, which has acted as ingress PE for Client->Server traffic flow, will act as egress PE for returning flow.

As a short summary, transport labels are used to transmit traffic from PE to PE through SP core.

Option 1: LDP

The first and the easiest way to configure MPLS forwarding is to use LDP (label distribution protocol). You need just 1 command at Cisco IOS or Cisco IOS XR router to activate it, if you use OSPF or is-is as routing protocol, what is strongly preferred.
Cisco IOS Cisco IOS XR

For sure you can configure a lot of other features besides this command to fine tune LDP or add certain additional capabilities, but this command is essential as it just launches the allocation and distribution of labels at both routers. What this command makes by default is that it allocates labels (local labels) to all the prefix in the router’s routing table and then send to the neighbors this mapping information. The adjacent routers make the same process independently. After the routers exchanged the mapping information, they add to the forwarding base the labels that correspond to the routes in routing table.

Option 2: Segment routing (SPRING)

It’s the most recent technology that can be used for label distribution. The actual date in RFC that describes this technology is 1 February 2016 (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-04). This technology helps to significantly reduce the number of transport labels used in the network on the one hand and make some labels are global significant on another hand. Not going into details, each router in the network generate label mapped to IP address of its loopback that is used by all routers in the network in order get that router. Along the path to the specific router each PE or P router swap the label (normal MPLS operation) to the same one. This is done due to the fact that actually routers don’t send actual labels, rather their IDs and base label block that are used to calculate labels. This information is distributed by routing protocol (OSPF or is-is) itself without any additional protocol.

In addition to the “global” label routing protocols also distribute information about local labels, which can be used to influence, which actual egress interface from SPRING router must be used.

Option 3: BGP-LU (labeled unicast)

BGP can distribute MPLS labels without specific address family (vpnv4/vpnv6 unicast/multicast: 1/128, 1/129, 2/128, 2/129), which are used for L3 VPNS. You can distribute labels within normal ipv4 unicast address family (1/1 without labels and 1/4 with label) sessions. There are two quite common use cases, where such configuration is used:
• BGP free Data center
• Unified MPLS (seamless MPLS) in SP Core

The configuration is also not complex:

The most important options here is to set next-hop (NH) to self, as by default at iBGP sessions the NH isn’t changed. What is also good is that comparing to all other protocols, you can distribute MPLS labels between different AS providing possibility to build smooth LSP across many different networks or logically separated parts of network.

Option 4: RSVP

It’s the most complex option from the configuration point of view, though it provides almost richest feature set for LSP (Label Switched Path – unidirectional MPLS tunnel) across the network. The main its advantage is the possibility to utilize traffic engineering, which provide your full control over the traffic transmission in your network. In simple words the path establishment is done from ingress PE to egress PE, but the label distribution is done from the egress PE to ingress PE, pretty like with service labels.

It’s configuration even in the easiest case is quite big that’s why I don’t provide it here.

Lessons learned

As I’ve said in the beginning of the article, I was mistaken thinking about LDP as only transport plane mechanism of MPLS. So learning is a key for real understanding of what’s going on. Fantastic explanation can be found in the book “MPLS in the SDN Era” by Antonio Sánchez-Monge & Krzysztof Grzegorz Szarkowicz

Conclusion

This article is just an entry part, which provides you a brief overview about MPLS label distributions protocols and techniques. For sure you have a variety of probable mechanisms, which of them has its pros and cons. In further articles we’ll cover these topics in a much more details.

Support us

Support new interop and automation articles at karneliuk.com
EUR

I want to support with:
9.99 EUR4.99 EUR24.99 EUR49.99 EUR99.99 EUR199.99 EUR

Best regards,
Anton Karneliuk