MPLS
MPLS resolves the same problem as NHRP but in a different way. MPLS is a new concept (as of this writing), and not all of the standards and mechanisms are fully worked out. This chapter covers an overview of the theory.
Normal Packet Switching
Switching an IP packet normally involves the following procedure:
Looking up the destination IP address in a table that might contain several overlapping matches
Choosing the matching destination network with the longest prefix length
Finding the MAC header for the next hop and copying it onto the front of the packet
The deployment of ATM and Frame Relay brought a new idea to the forefront in switching packets: switching based on a short label that can be swapped hop by hop as a packet moves toward its destination. Figure 9-4 provides a network illustration for demonstrative purposes.
Figure 9-4. Simple Network Illustrating Switching by Tags
Because Router A is advertising a summary, and Router B is a component within that summary, Router C has two entries in its routing table:
10.1.0.0/16 via A
10.1.2.0/24 via B
These two entries are passed to Router D so that it will also have two entries in its table:
10.1.0.0/16 via C
10.1.2.0/24 via C
If Router D receives a packet destined to 10.1.2.1, it first finds that there are two matches for this destination, and it must compare the prefix length of these two matches to determine the best path.
Instead of using the IP address to switch the packet, these routers could assign labels to represent each hop along the path, and then switch based on these labels.
For instance, assume that the following conditions are true:
Router A assigns the label 100 to the destination 10.1.0.0/16, which it is advertising to Router C.
Router B assigns the label 200 to the destination 10.1.1.0/24, which it is advertising to Router C.
Router C assigns the label 300 to 10.1.0.0/16 and advertises this upstream to Router D.
Router C assigns the label 400 to 10.2.0.0/16 and advertises this along to Router D.
Now, when Router D receives a packet destined to 10.1.2.1, it notes that this route corresponds to 10.1.0.0/16, which is labeled 400. So, Router D marks the packet with the label 400 and forwards it to Router C. Instead of looking at the destination address and choosing the next hop based on the longest prefix match from the IP routing table, Router C simply looks up the label, 400, and sees that this belongs 10.1.0.0/16, which is labeled 100. Router C swaps the labels and passes the packet along.
When Router B receives the packet, it sees from the label (200) that this packet is destined to a directly attached subnet. Then, it strips the label off the packet and forwards it as usual.
The preceding example doesn't provide much network savings. You've saved only one router the expense of looking up a longest prefix match. If that one router was really a cloud, however, and the cloud contained numerous routers, the savings could be significant.
When a Label Switching Router (LSR) removes a label from the packet, this is called a pop; when it adds a new label on the packet, this is called a push.
Streams and Label Merging
MPLS doesn't restrict itself to one label for each destination. It uses a label to designate a stream, or a flow, of traffic instead—a Forwarding Equivalence Class (FEC). Abstracting individual packets into an FEC allows MPLS routers (LSRs) to merge a large number of streams that require the same handling (Class of Service, next hop, and so on) into one FEC and use the same label to identify all of them.
To understand this better, look at the example in Figure 9-5.
If you were using normal IP routing, you couldn't summarize the two routes advertised by Router D—10.1.1.0/24 and 172.16.1.0/24. Assume Router D is advertising label 100 for 10.1.1.0/24 and label 200 for 172.16.1.0/24 toward Router C. If Router C is capable of merging these FECs advertised by Router D, it can advertise a single label toward Routers A and B for both streams, which effectively summarizes them into one FEC, one label, and one advertisement.
This capability to merge streams, regardless of the destination addresses, greatly improves the scalability of MPLS by cutting down on the amount of routing information the LSRs must store and work with.
Figure 9-5. Merging Streams
Label Granularity
Until now, you've worked only with labels that are bound to a destination network. (Unless they are merged; in which case, a single label can represent a number of destination networks.) In reality, labels can bound at different granularities to a flow of traffic. The following are a few common label assignment possibilities:
Host pair— Each source and destination address pair is assigned a label; all packets from 10.1.1.1 to 172.16.1.1 are placed in one FEC.
Port quadruple— Each source address:port to destination address:port pair is assigned a label; all packets from 10.1.2.1:1024 to 172.16.1.1:23 are placed in one FEC.
Port quadruple with Type of Service (ToS)— Each source address:port to destination address:port pair with a given ToS is assigned a label; all packets from 10.1.2.1:1024 to 172.16.1.1:23 ToS 3 are placed in one FEC.
Network pair— Each source/destination network pair is assigned a label; all packets from 10.1.2.0/24 to 172.16.1.0/24 are placed in one FEC.
Network pairs with ToS— Each source/destination network pair within a given ToS is assigned a label; all packets from 10.1.2.0/24 to 172.16.1.0/24 marked for ToS 3 are placed in one FEC.
Destination network— All packets travelling to a given destination network are assigned a label (which is what you've seen in the examples so far).
Egress router— All packets exiting the MPLS cloud at a given egress LSR are assigned the same label.
Next hop BGP autonomous system (AS)— Each source AS is assigned a label, and that label is used to reach any destination within, or through, that AS.
Destination BGP AS— This is similar to assigning labels based on the next hop AS mentioned in the preceding item, but only destinations sourced within a given AS use a label associated with that AS.
Multicast source/group pair— For multicast, a given source/group pair can be assigned a label through the multicast distribution tree.
Multicast */group pair (any source for this group)— Rather than assigning a label per source, this scheme assigns only a label per multicast group.
Assigning Labels
How are labels assigned to streams or flows of traffic? There are two aspects of this question that MPLS must answer:
What device assigns them?
What drives label assignment? (What causes a label to be assigned?)
The control component is the device that assigns a label to a new flow presented while arriving at the edge of the MPLS cloud. This will most likely be an MPLS-capable router (an LSR) running BGP with the other edge routers connected to this cloud. The egress router assigns labels based on requests from upstream neighbors.
There are two ways to determine if a label needs to be assigned:
When the first packet in a new flow reaches an edge router on the MPLS cloud, the edge router can cause the label assignment process to begin.
As edge routers receive updates to their routing tables, they can drive the assignment of labels through the cloud based on the information in the routing table.
The first way of driving label assignment is data driven; the labels are assigned in response to data traffic. The second is control driven; the labels are assigned in response to control traffic.
Source Routing
Because a single label pushed onto the packet at the ingress to the MPLS cloud defines the entire path through the cloud, MPLS can be considered a type of source routing. It is more scalable than traditional source routing, though, because the current hop information needs to be carried only in the packet—not the entire path.
Strict source routing provides many capabilities over traditional hop-by-hop routing (which are currently implemented by IP). For example, traffic engineering is easier because the entire path of a given stream of data is known. It's easier to size links and determine what capacity is needed where when the path of any given stream can be known (and in fact, administratively chosen, when the packet enters the network).
Tunneling and Label Stacks
Packets aren't limited to one label; labels can be stacked on top of one another with the current LSR acting on the "top" label of the stack. Figure 9-6 demonstrates how this can be used for tunneling.
Figure 9-6. Tunneling and Label Stacks
If ws1 wants to communicate with ws2 without users (or hackers) attached to LSR C or LSR D being able to see the traffic, then the edge Router E can negotiate a label with LSR A to represent this traffic and push this label onto the stack. (LSR A is also called the ingress LSR because it is where the traffic enters the MPLS network.)
Router E can also look in its routing table and find the label for traffic going to LSR A. Then, it can push this label onto the stack ahead of the first label.
Following is an example:
Routers A and E negotiate the label 900 for the tunneled (hidden) traffic.
The label for traffic destined to LSR A through LSR D is 100.
The label for traffic destined to LSR A through LSR C is 200.
LSR E will first push 900 onto the label stack, followed by 100, and pass the packet onto LSR D. When LSR D receives this packet, it will act on the label on the top of the stack, which indicates the traffic is destined to egress at LSR A. It pops the top label, which is 100, and replaces it with the label for the next hop in the path, which is 200.
Now, LSR C receives the packet and sees that the label indicates this traffic is destined for LSR A. Seeing the next hop is the egress LSR (the edge of the MPLS network where the traffic will be leaving), LSR C simply pops the label and passes the traffic to LSR A.
When LSR A receives the packet, there will be only one label (900), which indicates that this traffic is for ws2. LSR A will pop the final label and forward the packet. Figure 9-7 shows this series of label pushes and pops.
Figure 9-7. A Label Stack through a Short Tunnel
The preceding example shows that LSR C would pop the label before the packet actually leaves the tunnel (which terminates at LSR A). The next to the last LSR along a path (either through a tunnel or through an MPLS cloud), also known as the penultimate LSR, should pop the label before passing it on to the egress node.
Time to Live
The way IP guarantees that a packet will not be passed back and forth between two routers in a routing loop is the Time To Live (TTL) field in the packet header. Each router that the packet passes through will subtract one from the TTL until it reaches zero; when the TTL reaches zero, the packet will be discarded.
Because MPLS allows LSRs to switch packets based only on the label, the IP header is never touched. Therefore, the TTL on IP packets passing through an MPLS cloud may never be decreased.
For this reason, MPLS suggests that the ingress router on an MPLS cloud decrease the TTL in the IP header by the number of hops the packet will travel through the cloud. If the packet's TTL is low enough that it will reach zero before reaching the egress LSR, then the packet should be discarded before entering the MPLS network.
Other MPLS References
This short overview doesn't cover many details of how MPLS works; refer to the draft and standards documents of the IETF for a complete explanation of the mechanisms used to prevent loops, distribute labels, and encapsulate traffic through MPLS networks.