01-01 MPLS Basics
01-01 MPLS Basics
1 MPLS Basics
MPLS is based on Internet Protocol version 4 (IPv4). The core MPLS technology
can be extended to multiple network protocols, such as Internet Protocol version 6
(IPv6), Internet Packet Exchange (IPX), and Connectionless Network Protocol
(CLNP). "Multiprotocol" in MPLS means that multiple network protocols are
supported.
MPLS is used for tunneling but not a service or an application. MPLS supports
multiple protocols and services. Moreover, it ensures security of data transmission.
Purpose
IP-based routing serves well on the Internet in the mid 90s, but IP technology can
be inefficient at forwarding packets because software must search for routes using
the longest match algorithm. As a result, the forwarding capability of IP
technology can act as a bottleneck.
MPLS was created to increase forwarding rates. Unlike IP routing and forwarding,
MPLS analyzes a packet header only on the edge of the network and not at each
hop. MPLS therefore reduces packet processing time.
When IP packets reach an MPLS network, the ingress LER analyzes the packets
and then adds appropriate labels to them. All LSRs on the MPLS network forward
packets based on labels. When IP packets leave the MPLS network, the egress LER
pops the labels.
MPLS Architecture
Figure 1-2 shows the MPLS architecture, which consists of a control plane and a
forwarding plane.
Label
A label is a short, fixed-length (4 bytes) identifier that is only locally significant. A
label identifies an FEC to which a packet belongs. In some cases, such as load
balancing, a FEC can be mapped to multiple incoming labels. Each label, however,
represents only one FEC on a device.
Compared with an IP packet, an MPLS packet has the additional 4-byte MPLS
label. The MPLS label is between the link layer header and the network layer
header, and allows use of any link layer protocol. Figure 1-3 shows position of an
MPLS label and fields in the MPLS label.
to the Layer 3 header is the bottom of the label stack (inner MPLS label). An
MPLS label stack can contain an unlimited number of labels. Currently, MPLS label
stacks can be applied to MPLS VPN and Traffic Engineering Fast ReRoute (TE
FRR).
The label stack organizes labels according to the rule of Last-In, First-Out. The
labels are processed from the top of the stack.
Label Space
The label space is the value range of the label, and the space is organized in the
following ranges:
● 0 to 15: special labels. For details about special labels, see Table 1-1.
● 16 to 1023: label space shared by static LSPs and static constraint-based
routed LSPs (CR-LSPs).
● 1024 or above: label space for dynamic signaling protocols, such as Label
Distribution Protocol (LDP), Resource Reservation Protocol-Traffic Engineering
(RSVP-TE), and MultiProtocol Border Gateway Protocol (MP-BGP).
0 IPv4 Explicit The label must be popped out (removed), and the
NULL Label packets must be forwarded based on IPv4. If the
egress node allocates a label with the value of 0
to the penultimate hop LSR, the penultimate hop
LSR pushes label 0 to the top of the label stack
and forwards the packet to the egress node.
When the egress node detects that the label of
the packet is 0, the egress node pops the label
out.
2 IPv6 Explicit The label must be popped out, and the packets
NULL Label must be forwarded based on IPv6. If the egress
node allocates a label with the value of 2 to the
LSR at the penultimate hop, the LSR pushes label
2 to the top of the label stack and forwards the
packet to the egress node. When the egress node
recognizes that the value of the label carried in
the packet is 2, the egress node immediately pops
it out.
4 to 13 Reserved None.
15 Reserved None.
● LDP
The Label Distribution Protocol (LDP) is designed for distributing labels. It sets
up an LSP hop by hop according to Interior Gateway Protocol (IGP) and
Border Gateway Protocol (BGP) routing information.
For details about LDP implementation, see Understanding MPLS LDP in the 3
MPLS LDP Configuration.
● RSVP-TE
Resource Reservation Protocol Traffic Engineering (RSVP-TE) is an extension
of RSVP and is used to set up a constraint-based routed LSP (CR-LSP). In
contrast to LDP LSPs, RSVP-TE tunnels are characterized by bandwidth
reservation requests, bandwidth constraints, link "colors" (designating
administrative groups), and explicit paths.
For details about RSVP-TE implementation, see Understanding MPLS TE in the
5 MPLS TE Configuration.
● MP-BGP
MP-BGP is an extension to BGP and allocates labels to MPLS VPN routes and
inter-AS VPN routes.
For details about MP-BGP implementation, see BGP Configuration in the
S2720, S5700, and S6700 V200R019C00 Configuration Guide - IP Unicast
Routing.
Procedure for Establishing Dynamic LSPs
MPLS labels are distributed from downstream LSRs to upstream LSRs. As shown in
Figure 1-5, a downstream LSR identifies FECs based on the IP routing table,
allocates a label to each FEC, and records the mapping between labels and FECs.
The downstream LSR then encapsulates the mapping into a message and sends
the message to the upstream LSR. As this process proceeds on all the LSRs, the
LSRs create a label forwarding table and establish an LSP.
● Push: When an IP packet enters an MPLS domain, the ingress node adds a
new label to the packet between the Layer 2 header and the IP header.
Alternatively, an LSR adds a new label to the top of the label stack.
● Swap: When a packet is transferred within the MPLS domain, a local node
swaps the label at the top of the label stack in the MPLS packet for the label
allocated by the next hop according to the label forwarding table.
● Pop: When a packet leaves the MPLS domain, the label is popped out of
(removed from) the MPLS packet.
A label is invalid at the last hop of an MPLS domain. The penultimate hop
popping (PHP) feature applies. On the penultimate node, the label is popped
out of the packet to reduce the size of the packet that is forwarded to the last
hop. Then, the last hop directly forwards the IP packet or forwards the packet
by using the second label.
By default, PHP is configured on the egress node. The egress node supporting
PHP allocates the label with the value of 3 to the penultimate hop.
LSPs that support PHP are used in the following example to describe how MPLS
packets are forwarded.
As shown in Figure 1-6, the LSRs have distributed MPLS labels and set up an LSP
with the destination address of 4.4.4.2/32. MPLS packets are forwarded as follows:
1. The ingress node receives an IP packet destined for 4.4.4.2. Then, the ingress
node adds Label Z to the packet and forwards it.
2. When the downstream transit node receives the labeled packet, the node
replaces Label Z by Label Y.
3. When the transit node at the penultimate hop receives the packet with Label
Y, the node pops out Label Y because the label value is 3. The transit node
then forwards the packet to the egress node as an IP packet.
4. The egress node receives the IP packet and forwards it to 4.4.4.2/32.
For details on how the ingress node processes the EXP field and TTL field, see
Understanding MPLS QoS in the 4 MPLS QoS Configuration and Processing
MPLS TTL.
● A transit node processes MPLS packets as follows:
a. Finds the ILM matching the MPLS label to obtain the Tunnel ID.
b. Finds the NHLFE matching the Tunnel ID in the ILM.
c. Checks the NHLFE to obtain the outbound interface, next hop, outgoing
label, and label operation.
d. Processes the MPLS packets according to the label value:
▪ If the label value is greater than or equal to 16, the transit node
replaces the label with a new label replaces and processes the EXP
field and TTL field. After that, the transit node forwards the MPLS
packet with the new label to the next hop.
▪ If the label value is 3, the transit node pops out the label and
processes the EXP field and TTL field. After that, the transit node
forwards the packets through an IP route or based on the next layer
label.
● The egress node forwards MPLS packets based on the ILM and forwards IP
packets based on the routing table
– When the egress node receives IP packets, it checks the FIB and performs
IP forwarding.
– When the egress node receives MPLS packets, it checks the ILM for the
label operation and processes the EXP field and TTL field.
▪ When the S flag in the label is 1, the label is at the bottom of the
label stack, and the packet is directly forwarded through an IP route.
▪ When the S field in the label is 0, a next-layer label exists, and the
packet is forwarded based on the next layer label.
● Pipe mode
As shown in Figure 1-9, the ingress node decreases the IP TTL by one and the
MPLS TTL remains constant. The TTL field in MPLS packets is processed in
standard mode. The egress node decreases the IP TTL by one. In Pipe mode,
the IP TTL only decreases by one on the ingress node and one on the egress
node when packets travel across an MPLS network.
MPLS ping is used to check network connectivity. MPLS tracert is used to check
the network connectivity, and to locate network faults. Similar to IP ping and
tracert, MPLS ping and tracert use MPLS echo request packets and MPLS echo
reply packets to check LSP availability. MPLS echo request packets and echo reply
packets are both encapsulated into User Datagram Protocol (UDP) packets. The
UDP port number of the MPLS echo request packet is 3503, which can be
identified only by MPLS-enabled devices.
An MPLS echo request packet carries FEC information to be detected, and is sent
along the same LSP as other packets with the same FEC. In this manner, the
connectivity of the LSP is checked. MPLS echo request packets are forwarded to
the destination end using MPLS, while MPLS echo reply packets are forwarded to
the source end using IP. Routers set the destination address in the IP header of the
MPLS echo request packets to 127.0.0.1/8 (local loopback address) and the TTL
value is 1. In this way, MPLS echo request packets are not forwarded using IP
forwarding when the LSP fails so that the failure of the LPS can be detected.
MPLS Ping
As shown in Figure 1-10, LSR_1 establishes an LSP to LSR_4. LSR_1 performs MPLS
ping on the LSP by performing the following steps:
1. LSR_1 checks whether the LSP exists. (On a TE tunnel, the router checks
whether the tunnel interface exists and the CR-LSP has been established.) If
the LSP does not exist, an error message is displayed and the MPLS ping
stops. If the LSP exists, LSR_1 performs the following operations.
2. LSR_1 creates an MPLS echo request packet and adds 4.4.4.4 to the
destination FEC in the packet. In the IP header of the MPLS echo request
packet, the destination address is 127.0.0.1/8 and the TTL value is 1. LSR_1
searches for the corresponding LSP, adds the LSP label to the MPLS echo
request packet, and sends the packet to LSR_2.
3. Transit nodes LSR_2 and LSR_3 forward the MPLS echo request packet based
on MPLS. If MPLS forwarding on a transit node fails, the transit node returns
an MPLS echo reply packet carrying the error code to LSR_1.
4. If no fault exists along the MPLS forwarding path, the MPLS echo request
packet reaches the LSP egress node LSR_4. LSR_4 returns a correct MPLS echo
reply packet after verifying that the destination IP address 4.4.4.4 is the
loopback interface address. MPLS ping is complete.
MPLS Tracert
As shown in Figure 1-10, LSR_1 performs MPLS tracert on LSR_4 (4.4.4.4/32) by
performing the following steps:
1. LSR_1 checks whether an LSP exists to LSR_4. (On a TE tunnel, the router
checks whether the tunnel interface exists and the CR-LSP has been
established.) If the LSP does not exist, an error message is displayed and the
tracert stops. If the LSP exists, LSR_1 performs the following operations.
2. LSR_1 creates an MPLS echo request packet and adds 4.4.4.4 to the
destination FEC in the packet. In the IP header of the MPLS echo request
packet, the destination address is 127.0.0.1/8. Then LSR_1 adds the LSP label
to the packet, sets the MPLS TTL value to 1, and sends the packet to LSR_2.
The MPLS echo request packet contains a downstream mapping type-length-
value (TLV) that carries downstream information about the LSP at the current
node, such as next-hop address and outgoing label.
3. Upon receiving the MPLS echo request packet, LSR_2 decreases the MPLS TTL
by one and finds that TTL times out. LSR_2 then checks whether the LSP
exists and the next-hop address and whether the outgoing label of the
downstream mapping TLV in the packet is correct. If so, LSR_2 returns a
correct MPLS echo reply packet that carries the downstream mapping TLV of
LSR_2. If not, LSR_2 returns an incorrect MPLS echo reply packet.
4. After receiving the correct MPLS echo reply packet, LSR_1 resends the MPLS
echo request packet that is encapsulated in the same way as step 2 and sets
the MPLS TTL value to 2. The downstream mapping TLV of this MPLS echo
request packet is replicated from the MPLS echo reply packet. LSR_2 performs
common MPLS forwarding on this MPLS echo request packet. If TTL times out
when LSR_3 receives the MPLS echo request packet, LSR_3 processes the
MPLS echo request packet and returns an MPLS echo reply packet in the same
way as step 3.
5. After receiving a correct MPLS echo reply packet, LSR_1 repeats step 4, sets
the MPLS TTL value to 3, replicates the downstream mapping TLV in the
MPLS echo reply packet, and sends the MPLS echo request packet. LSR_2 and
LSR_3 perform common MPLS forwarding on this MPLS echo request packet.
Upon receiving the MPLS echo request packet, LSR_4 repeats step 3 and
verifies that the destination IP address 4.4.4.4 is the loopback interface
address. LSR_4 returns an MPLS echo reply packet that does not carry the
downstream mapping TLV. MPLS tracert is complete.
When routers return the MPLS echo reply packet that carries the downstream
mapping TLV, LSR_1 obtains information about each node along the LSP.
MPLS VPN can build a private network with security similar to a Frame Relay (FR)
network. On MPLS VPN networks, customer devices do not need to set up tunnels
such as GRE and L2TP tunnels, so the network delay is minimized.
As shown in Figure 1-11, the MPLS VPN connects private network branches
through LSPs to form a unified network. The MPLS VPN also controls the
interconnection between VPNs. Figure 1-11 shows the devices on an MPLS VPN
network.
● A customer edge (CE) is deployed on the edge of a customer network. It can
be a router, a switch, or a host.
● A provider edge (PE) is deployed on the edge of an IP/MPLS backbone
network.
● A provider (P) device on an IP/MPLS backbone network is not directly
connected to CEs. The provider device only needs to provide basic MPLS
forwarding capabilities and does not maintain VPN information.
1.3.2 MPLS TE
On traditional IP networks, routers select the shortest path as the route regardless
of other factors such as bandwidth. Traffic on a path is not switched to other
paths even if the path is congested. As a result, the shortest path first rule can
cause severe problems on networks.
Traffic engineering (TE) monitors network traffic and the load of network
components and then adjusts parameters such as traffic management, routing,
and resource restraint parameters in real time. These adjustments help prevent
network congestion caused by unbalanced traffic distribution.
IPv4 backbone networks. In this way, CEs on IPv6 islands can communicate with
each other through IPv4 PEs.
On an MPLS 6PE network shown in Figure 1-13:
● 6PE routers exchange IPv6 routing information with CEs using IPv6 routing
protocols.
● 6PE routers exchange IPv6 routing information with each other using
Multiprotocol Border Gateway Protocol (MP-BGP) and allocate MPLS labels to
IPv6 prefixes.
● 6PE routers exchange IPv4 routing information with Ps using IPv4 routing
protocols and establish LSPs between 6PE routers and Ps using MPLS.
Figure 1-13 shows the IPv6 packet forwarding process on an MPLS 6PE network.
IPv6 packets must carry outer and inner labels when being forwarded on the IPv4
backbone network. The inner label (L2) maps the IPv6 prefix, while the outer label
(L1) maps the LSP between 6PEs.
The MPLS 6PE technology allows ISPs to connect existing IPv4/MPLS networks to
IPv6 networks by simply upgrading PEs. To Internet service providers (ISPs), the
MPLS 6PE technology is an efficient solution for transition to IPv6.