What is MPLS?

MPLS is a different forwarding method based on labels

Mainly used in service provider networks (e.g. in iBGP)

In a usual scenario, every iBGP node makes routing decision based on the IP header
With MPLS, the packet header is used to determine the MPLS label to add tot he packet
All subsequent routing decisions are made based on that label, rather than the packets original header

With MPLS, we route by label database, instead of IP routes
100K IPv4 routes could use the same exit node, and get the same label
Greatly reduced table sizes

History

Predecessors
"IP switching"
"Tag switching"
Mapping IP packets to ATM circuits
Cisco introduced "Tag Switching"
Similar to IP switching, but not limited to ATM
IP flows are associated wit a tag
Tag was eventually renamed to Label
Done because:
Traffic growing faster than router vendors could keep up with
Existing equipment was expensive
More performance in conventional packet processing was not enough

Called Multi-Protocol since it can be applied to any network layer protocol
Encapsulate different services and transport them over MPLS enabled backbones
E.g.: IPv4/6, Ethernet Frames, Pseudo Wires (PW), IP VPNs

Adding Labels

In IP packets, an MPLS header is added between the L2 Ethernet header, and the L3 IP header

Same label -> follow the same path
Fixed-length label lookup is faster than longest-prefix match lookups
Forwarding of packets decided based on label
Routing information still exchanged with protocols like OSPF/IS-IS

Forwarding

LER = Label Edge Router
a.k.a. PE = Provider Edge Router
LSR = Label Switching Router
a.k.a. P = Provider Router
LSP = Label Switched Path
Unidirectional path between ingress and egress LERs
a.k.a. "Virtual circuit" or "MPLS tunnel"
FEC = Forwarding Equivalence Class
A set of packets that a router:
Forwards to the same next-hop
Out the same interface
With the same treatment
With traditional routing, FEC determined at every hop
With MPLS, FEC only determined once - at ingress LER

1. Ingress LER PUSHes label
2. Any intermediate LSRs can SWAP (or PUSH/POP) labels
3. Egress LER POPs labels and forwards outside the network

Assignment & Use of Labels

1. PE creates label $1$ for it's address $X$, advertises it to peers
2. Peers check if that PE is the shortest known way to reach $X$
   1. If yes, install forwarding state that swaps label $2$ (new) for $1$
      Then, advertise this label $2$ to peers
   2. If not, then ignore the advertisement
3. All LSR/P will follow the above, until we reach another PE
4. Then, when the ingress gets a packet, it will PUSH (e.g.) label $4$
5. Intermediate LSR/P will SWAP labels, based on learned paths (LSPs)
6. Egress PE will POP the label and forward

Label Allocation

Labels are chosen by receivers, advertised to senders
LERs expect to receive packets with labels they created themselves
There is no rule in place that labels have to be unique
When duplicates occur, criteria are used to drop one

Labels are uintin range $0-1048575$
$0-15$ have special meaning
Packets with unrecognised labels are dropped
Packets can have more than 1 label (label stack)
Decisions made on the topmost label
Stack is used for thins like hierarchical routing

Label Information Base (LIB)

Labels are stored in the LIB
Populated by static entries or dynamic label distribution protocols
Determine mapping from:
Previous hop (incoming port, label) -> FEC
FEC -> Next hop (outgoing port, label)

Label Forwarding Information Base (LFIB): Table matching label -> outgoing interface
Each router has a LIB and uses that to build the LFIB
Aggregate FECs, use hash tables, ...
Similar to RIB and FIB

Label Distribution

Static configuration:
Manual config of label bindings and LSPs
Not scalable & error prone
Dynamic: config
LDP: new protocol, just label distribution
RSVP-TE: Extension to RSVP: carry labels, provision LSPs
BGP: Extension to BGP: carry labels, provision LSPs

Multiple can be used at the same time, but:
Depends on the topology
Depends on the desired services
Increases complexity
Requires extra config

Label Distribution Protocol (LDP)

Works between directly connected peers
Peers auto-discovered once configured (per interface)
Builds a full mesh of LSPs that follow the IGP best path (all routing choices made by IGP)

Initialization: exchange information regarding features and modes supported
Next: establish TCP connection (LDP session)
Start: exchanging label mappings that associate FECs with MPLS labels;
Keep: sessions up by sending keep-alive messages (heart beat mechanism)

IGP protocol (OSPF/IS-IS) must be configured on all LSRs
New IGP routes (prefixes in routing table) lead to new label bindings
Labels can be withdrawn when IGP routes are no longer valid
Hard-state - expected to work until explicitly torn down

Example:

Consider two LSRs, R1 and R2, connected by a link:

• FEC: The IP prefix 192.168.1.0/24
• R1 (Incoming): Assigns label '10' to the FEC 192.168.1.0/24, destined for R2.
• R2 (Outgoing): Assigns label '20’ to the same FEC, destined for a downstream router.

LDP would then work as follows:

1. Discovery: R1 and R2 discover each other using UDP multicast messages.
2. Session Establishment: They establish TCP sessions with each other.
3. Label Distribution (DU): R1, acting as an upstream LSR, sends a label mapping advertisement to R2: "For FEC 192.168.1.0/24, use label 10."
4. R2 Receives Advertisement: R2 receives the advertisement and stores this information in its LIB (Label Information Base). It then creates an entry in its LFIB saying that when a packet arrives with label '10', it should swap it for label '20' and forward it to the next hop.
5. Downstream Advertisement: R2, acting as a downstream LSR, might also advertise this mapping to its own downstream neighbours (if any).

Resource ReserVation Protocol (RSVP)

Developed before MPLS
Made for bandwidth reservation for individual traffic flows
Does not scale due to the work for each flow, so hardly used

RSVP Traffic Engineering (RSVP-TE) is an extension
Create/maintain LSPs
Reserve bandwidth per LSP (means it can actually scale)
Does NOT necessarily follow IGP shortest path

Ingress router initiates by sending an RSVP PATH message
to signal out the path of LSP to the egress router
the Explicit Route Object (ERO) lists the nodes/links the LSP must pass
Aside from explicitly listed nodes/links, shortest path routing is used
Egress node defined beforehand to determine forwarding destination
Egress router sends back an RSVP RESV message
to confirm establishment of LSP and reserve resources
follows the reverse path back to ingress
includes the allocated label
the Record Route Object (ERO) to confirm the path
Transit routers receiving the RESV message
allocate new local label
relay message upstream
install entry in LIB

Multiprotocol Extensions to BGP (MP-BGP)

With extensions, BGP can advertise anything
Can be used inter-domain, since BGP is often already used between ASes
Used for L3 VPNs between sites connected by MPLS backbone
Each VPN has its own Virtual Routing and Forwarding (VRF) instance
MPLS forwarding uses stacked labels
Outer label: LSP forwarding: "Transport"
Inner label: differentiate between diff. VPNs

Route Distinguisher: 64-bit number attached to customer IP prefixes to make them unique
Prepended to routes in VRF to make them unique in the whole BGP provider network
Created VPNv4 routes, e.g. ("green", 10.0.0.0/24) and ("yellow", 10.0.0.0/24)

Virtual Private Lan Service (VPLS)

L2 VPN
Emulates the full functionality of an ethernet-based LAN
Private: devices belonging to different VPLSs cannot interact
Virtual: multiple VPLSs can be offered over a common network
Broadcast/unknown dest. frames are flooded to all ports
Responsibility of service provider to make loop-free network

MP-BGP can be used to establish VPLS

Latest New Protocols

Ethernet Virtual Private Network (EVPN)

Solve VPLS limitations: redundancy, multicast, multihoming, provisioning simplicity
EPVN is L2 over IP/MPLS (or PBB or VXLAN)
Control plane is MP-BGP
Another new address family
Allows L2 MAC addresses to be treated as routes in BGP tables

Segment Routing (SR)

New forwarding paradigm that provides Source Routing

SR-MPLS re-uses MPLS data plane
Segments encoded as MPLS labels
Segment list is in the label stack
Labels are distributed in IGP, no separate protocol needed