Switches, Routers, Bridges and LANs/Routers/MPLS

MPLS stands for Multi-Protocol Label Switching, and is a protocol that was originally developed out of work by Cisco but was formalised into an IEEE standard. It’s a protocol that is used to provide transparent access over a backbone network to data that uses other protocols.

MPLS is sometimes characterised as “layer 2.5”. This is most obvious in the way the packets are wrapped (the MPLS data goes between the Ethernet frame header and the IP packet in IP-over-Ethernet, for example), but it’s also a description of the bigger picture of the protocol. MPLS doesn’t provide routing, and makes use of another interior routing protocol (iBGP, IS-IS, OSPF or others) to route packets. But neither is it fully a layer-2 protocol, since it relies on existing layer 2 to do the framing of the data and provide communication between nodes. MPLS can deterministically control where data goes in a way that layer 2 switching can’t.

Switching performance

One of the factors driving MPLS early on was that the switching of packets under MPLS could be implemented efficiently in hardware, which IP routing couldn’t (at the time). This is no longer true. In this sense, MPLS is just a way of “baking down” the routing tables into a high-performance switching infrastructure. Though this played a part in driving the development of MPLS initially, it’s no longer relevant.

Actual advantages of MPLS

Backbone infrastructure for heterogeneous networks

MPLS can switch any layer 3 protocol over any layer 2 protocol. It’s thus useful for providing the backbone on a network where many different protocols (including future protocols yet to be specified) may want to travel over the backbone. Previously this kind of thing was only possible with Frame Relay or ATM.

MPLS can also carry layer 2 packets over the backbone, since the contents are ignored. This means that any layer 2 protocol can be carried over MPLS, known as AToM (any transport over MPLS)

IP over ATM

ATM was originally viewed as a potential replacement for IP as an end-to-end network, but it never happened. However, ATM is still widely used as a WAN network. Now that IP dominates the internet, it’s necessary to transport IP over these existing ATM networks. There are several specific solutions for implementing IP over ATM, but they’re all complicated to implement and MPLS can replace all of these.

Traffic management

BGP (for example) provides ways to customise which way data goes by using route maps and communities and such. But this is fiddly and opaque to implement. MPLS can allow different streams of data to be switched in different routes through the network very flexibly and with very direct control.

Tunnels and VPNs

MPLS has a layered structure that allows packets to be wrapped up in an unlimited number of additional containers. Only the outer label plays any role in routing the packet through the network at any time, so you can use this to tunnel traffic through parts of the network while ignoring what’s inside the packet.

The contents of the packet inside the label are ignored entirely by MPLS. This means you can encapsulate a full ethernet frame inside an MPLS label (with a further layer 2 frame outside of that) and pass the entire ethernet frame around the network unchanged, simulating a wire in a layer 2 broadcast domain that spans long distances and many routing hops.

Types of VPNs

There are two types of VPNs:

• overlay
• peer-to-peer

In the overlay model, the service provider sets up links between customer’s routers across the network. The customer’s routers peer with each other directly across these links, and don’t peer with the service provider’s routers.

In the peer-to-peer model, the service provider’s routers peer with the customer’s routers. This requires more work on the part of the service provider, since the provider edge routers need to be updated in response to changes in the customer network.

The overlay model used to be the most common way of providing VPNs, but MPLS made it simpler to provide peer-to-peer VPNs.

LDP

LDP is the protocol used to distribute labels in an MPLS network (RSVP and MP-BGP can also distribute labels). It’s based on TDP, a Cisco proprietary protocol. LDP is similar enough that it has entirely superseded TDP.

LDP doesn’t choose the routes, it merely distributes labels for routes that have been determined some other way. For the case of IP over MPLS, the routes that are labelled using LDP will have been determined using a standard IP routing protocol. This most simple form is mostly an anachronism (though a surprisingly young one); at a time when routers couldn’t do wire-speed IP routing, replacing a route with a label improved performance. Nowadays, the more interesting cases are where “routes” other than standard IP routes are being switched using MPLS, e.g. VPNs or traffic engineering. This will involve another protocol making the decisions and then using LDP to coordinate labels.

Label distribution modes

There are two major modes for distributing the labels: Downstream Unsolicited and Downstream on Demand. The on-demand form saves memory on the routers because only the labels that are needed are transferred. However, the DU form converges faster. The DU form is more common now that routers tend to have more than enough memory (Cisco uses DoD for LC-ATM, but DU for everything else).

Label Retention modes

In Conservative Label Retention mode, the router stores only those bindings that are associated with the next-hop for a particular FEC. That is, for each FEC there is only one label held at a time (the label that’s programmed in the LFIB). In Liberal Label Retention mode, the router stores any bindings that it receives.

LSP control modes

There are two control modes: ordered, and independent. In independent control mode the LSRs exchange labels for any routes that are in their routing table. This is simple to understand and reason about, but it has the disadvantage that it means that different parts of the LSP will come up at different times. It may be that traffic can make it part way across the network to a router that doesn’t have a label binding set up, at which point the router can’t take the right action with the packets. This may cause the router to fall back to slower IPv4 routing (e.g. in software). Ordered control mode causes labels only to be assigned for routes that are directly connected or that already have labels established with the next hop router.

FECs

LDP is based on the idea of a Forwarding Equivalence Class (FEC). A FEC is defined by a class of traffic that will all be treated in the same way. An obvious example would be all IP packets with a destination address in a certain prefix, but it could be anything else that can be defined in a way that both LDP speakers agree on. A pseudowire between two LSRs would act as a FEC.

LDP peerings

LDP routers discover each other by sending HELLO messages as UDP multicast packets to the “all routers on the subnet” multicast address, so it isn’t necessary to explicitly set up the addresses of peer routers. When a HELLO message is received, the receiving router retains the address the packet came from. The HELLO packet contains a hold time, which is the length of time between HELLO messages. If this is exceeded, the peering is regarded as having failed.

Each LSR has an LDP ID, which is 4 bytes identifying the router and 2 bytes for the label space in use. The 4 byte router ID is in practice an IPv4 address, though it isn’t used for messaging; the only requirement is that it’s unique. Zero for the label space indicates the platform-wide label space, while a non-zero value indicates a per-interface label space.

In Cisco IOS, the router ID is actually treated as an IP address and the router checks that the address is in the routing table.