|
|
4.7. MPLSMultiprotocol Label Switching (MPLS) is a way of tunneling IP datagrams, usually within and among autonomous systems.
The idea is that a small label is inserted between the interface- and network-layer protocol headers, as shown in Figure 4.56, by the router at the entrance to the tunnel. Downstream routers use the label to make routing decisions, and do not need to consult the network-layer header at all. Thus, like all tunnels, MPLS treats the encapsulated IP datagram as opaque data and does not access it in any way while it's in the tunnel. Figure 4.56. MPLS Label Encapsulation
According to the MPLS Resource Center's FAQ (frequently asked questions) at <http://www.mplsrc.com/faq1.shtml>, MPLS was originally envisioned as a way to perform network-layer routing at the interface layerthat is, at ATM or frame relayspeeds. MPLS is now perceived as a means of providing traffic engineering, including quality of service; ATM-like virtual circuits at the network layer; interface-layer tunnels, such as Ethernet over IP/MPLS; a special type of VPN for enterprises that provides security comparable to that obtained with frame relay or ATM circuits; and a generally simplified network architecture where, for example, many ATM control plane functions are migrated to the network layer. After looking briefly at how MPLS tunnels work, we then see how they can be used to provide a type of VPN. Because MPLS is usually implemented at the network service providerthat is, the autonomous systemlevel, most of us will not come into direct contact with it, but it does provide an interesting example of tunneling and is well worth our study. The MPLS ArchitectureAs we've seen, routing in the Internet is a distributed process. Each router makes an individual decision as to the next hop for an IP datagram, based on network topology information learned from its neighboring routers. Except for the immediately preceding and next hops, routers don't usually know where a packet has been or the path it will follow to its destination. This is a powerful architecture because it is very resilient to changes in the network. If a downstream router fails after a packet has started its journey, the network is usually able to route around the failure by finding an alternative path for the packet. The Internet routing model has shortcomings, however. As line speeds increase into the 10 and 100 gigabit per second range, it becomes more and more difficult for routers to make the forwarding decisions quickly enough to keep the links running at capacity. One of the difficulties is the time it takes to examine the IP header at each hop. Another problem is traffic engineering and quality of service (QoS). Service providers might want to use different paths for different types of traffic. As a trivial example, interactive traffic, such as a telnet or ssh session, would be better routed over low-delay links, whereas ftp or Web page downloads might be better routed over high-speed links even if the average delay is greater. A more complex consideration is QoS: A provider might decide to sell specialized service at a premium. For example, a provider might guarantee a customer a minimum or average dedicated bandwidth through its network at a cost depending on the bandwidth the customer requires. To deliver these types of services, network providers must segregate the IP traffic into distinct classes and treat those classes differently. This exacerbates the problem of examining the IP headers quickly enough to make forwarding decisions at high line speeds, of course, but it also requires information, such as customer identification, that intermediate routers won't have. MPLS addresses these problems by assigning each IP datagram to a forwarding equivalence class (FEC). Class membership can be based on a simple criterion, such as destination network, or a more complex set of criteria involving service-level contracts with a customer, destination, protocol, TCP or UDP port numbers, time of day, and other policy constraints. Each packet in a FEC will follow a predetermined path, called a label switched path (LSP) through a series of MPLS-aware routers. An MPLS-aware router is called a label switching router (LSR). The assignment of an IP datagram to a FEC takes place at the ingress routerthe first LSR in the path that the packet will follow. Subsequent LSRs in the LSP do not need to reclassify the packet; they merely forward it based on the label, as described next. Routing with MPLSA packet is assigned to a particular FEC by the ingress router. Each router has a label associated with each FEC it handles, but these labels are not unique among routers. That is, each LSR will have its own label for a given FEC. This label is purely a local matter except that a router's immediate upstream neighborsrouters that deliver packets directly to the LSR in questionwill also know it. Before describing the routing process, we need one more fact: Packets can carry multiple labels arranged in a stack. Only the label at the top of the stack is used to route the packet. Other labels play no part until the top label is removed (popped) by one of the routers. We'll see how this mechanism is used later, when we discuss MPLS tunnels and VPNs. The label is shown in Figure 4.57. The label comprises a 20-bit label value, an 8-bit TTL that's used to prevent routing loops, just as the TTL value in IP datagrams is, an S bit that, when set, indicates the bottom of the stack, and a 3-bit experimental field. Figure 4.57. The MPLS Label
The encoding of the label and its use in routing is discussed in RFC 3032 [Rosen, Tappan, Fedorkow, Rekhter et al. 2001]. The use and processing of the label's TTL field is discussed in RFC 3443 [Agarwal and Akyol 2003]. When a packet arrives at an LSR, the router retrieves the label and uses it as an index into a local database.
Each entry of the database contains at least a next hop and a label-forwarding action. Possible label actions are:
As an example of a typical routing event, let's suppose that LSR Ri receives a labeled packet. Ri first uses the label at the top of the stack to retrieve the appropriate entry in the label forwarding database. If we further suppose that the label action is to swap labels, Ri will replace the label with a new label specified by Ri+1, the router at the next hop. Ri then forwards the packet to the next hop indicated in the database entryRi+1 in this case. Note that Ri did not have to consult any network-layer headers to make this routing decision; the label determined both its actions and the next hop. These actions are repeated at each hop along the label switched path until the last router in the LSP is reached. The entire process is illustrated in Figure 4.58, where an IP datagram enters the LSP at ingress router LSR1 and is label switched through the LSP until it leaves the tunnel at router LSRn. While the datagram is in the MPLS tunnel, only the label is used for routing; the IP datagram itself is treated as opaque data. Figure 4.58. An IP Datagram Traversing an LSP
When the final router in the LSPthe egress routerreceives the packet, it pops the label from the stack. If there are further labels in the stack, the top label is used to make a routing decision as described in the label-swapping case; if the label stack is now empty and this is not the final destination for the packet, the router examines the network-layer header and makes its forwarding decision in the normal (non-MPLS) way.
Label Distribution ProtocolsIn order for MPLS to operate, LSRs must inform their neighbors of the label/FEC bindings that they are using. That is, before router Ri can forward a packet belonging to FEC F to router Ri+1, it must know what label Ri+1 has assigned to F. The routers exchange label information by means of a label distribution protocol (LDP). Several label distribution protocols have been proposed, including, confusingly enough, one called LDP. Some of these protocols are extensions to existing protocols, such as BGP [Rekhter and Rosen 2001]; others, such as LDP [Andersson, Doolan, Feldman et al. 2001], are new protocols designed specifically for MPLS. There are two methods for distributing labels: unsolicited downstream mode and downstream on demand mode. In unsolicited downstream mode, a router informs its immediate upstream neighbors of its label bindings without being asked. In this mode, the downstream router will send its neighbors label/FEC bindings when a label changes or when it first comes online. In downstream on demand mode, the downstream router does not distribute label information unless it's asked. In this mode, the upstream router will request a label binding for a particular FEC whose packets it wants to forward to the downstream router as the next hop. A router can use either or both modes, depending on circumstances. The MPLS architecture document (RFC 3031 [Rosen, Viswanathan, and Callon 2001]) discusses these modes in detail. If the upstream router has no use for a labelit doesn't use the downstream router as the next hop for the FEC that the label is bound toit may either discard it (conservative label retention mode) or keep it for possible later use (liberal retention mode). Generally, routers that have the necessary memory will use liberal retention mode because it saves requesting the label later if it's needed. Some routers, such as ATM-based LSRs, do not have the necessary memory and use conservative retention mode. MPLS TunnelsWe have been discussing MPLS as another example of tunneling technology, but not all authorities treat MPLS this way. The exercises ask you to justify our treatment of MPLS in terms of tunneling by considering our definition of tunnels and verifying that it applies to MPLS. Aside from the question of whether MPLS itself is an example of tunneling, there is a notion of tunnels in MPLS. As we shall see, these MPLS tunnels certainly satisfy our definition of a tunnel. To motivate the idea of this new type of tunnel, let's consider an example of their use from RFC 3031. Suppose that we have an autonomous system that functions purely as a transit AS. That is, it carries traffic for other autonomous systems, but traffic does not originate or terminate within the AS. Figure 4.59 shows this AS with four border routers B1, . . . , B4 and four internal routers I1, . . . , I4. Figure 4.59. An MPLS Tunnel
Let's suppose that border router B3 is advertising a route for network N and that an IP datagram with N as its destination enters the AS at router B1. As we saw in Chapter 2, the border routers will be running an exterior routing protocolBGP, sayand will be advertising to each other the external routes that they learn from their external BGP peers. The internal routers will be running an interior routing protocol, such as OSPF, and will learn the topology of the autonomous system's network from each other, and the external networks that they can reach from the border routers. In the normal situation as described in Chapter 2, the internal routers will be aware of external as well as internal routing information. Thus, for example, I3 will know that any packets destined for network N should be sent to B3. This means that the forwarding tables of the internal routers must contain all the external routes, even though they will never originate traffic to any of those external networks. Let's see how MPLS can solve this problem. First, it's clear that if the border routers were directly connected, there would be no problem: When the IP datagram destined to network N entered the AS at B1, the router would simply send it to its next hop, B3. Recall that one way of thinking about a tunnel is that it simulates a direct wire between two nodes. This suggests that we set up tunnels between the border routers. If such tunnels were in place, the internal routers wouldn't need to know anything about external networks or routes. They would merely need to know how to carry tunneled traffic among the border routers; the actual traffic, including the fact that the payload is a packet destined for network N, would be opaque to them. The MPLS label stack mechanism makes it easy to establish tunnels between two LSRs. For the rest of this example, let's assume that all the routers in the AS are LSRs. When it learns reachability information for network N from an external peer, router B3 assigns an MPLS label to the route and attaches it as a path attribute (see Chapter 2) to the rest of the routing information about N that it distributes to the other border routers. This process and the attribute formats are specified in RFC 3107 [Rekhter and Rosen 2001]. When B1 receives the IP datagram, it looks up the route for network N and discovers that the BGP next hop is router B3 and that B3 has assigned the label 3, say, to the route. Thus, B1 pushes the label 3 onto the MPLS label stack. Next, B1 again consults its routing table and learns that the next hop for router B3 is internal router I1 with a label of, say, 7. If we assume that the LSP between B1 and B3 is B1 Note how the internal routers don't need to carry any routing information about external networks; they are concerned only with routing packets within the AS. Also note how easy it is to apply traffic engineering or QoS with this topology. Suppose, for example, that the AS manager wants to give traffic from a certain external autonomous system priority. If we again assume that the traffic enters at B1 and is destined for network N, B1 can assign the packet to a different from normal FEC for the tunnel and thus assign it a different label. This other tunnel may take a differentfaster or better in some other waypath to B3. The only thing that changes from our example is that the labels at the top of the stack will be different. The bottom label will still be a 3, indicating to B3 that this packet is ultimately destined for network N. MPLS VPNsIf we generalize the previous tunnel example slightly, we will see how MPLS can provide a special type of VPN that simulates a leased linea frame relay or ATM leased circuitthat has many of the isolation and security features that leased lines do. The idea is to isolate traffic among a customer's various sites by carrying it in MPLS tunnels and to keep routing information for a customer's sites completely separate from any other customer's routing data. Let's assume that we have a service provider with two fictional customers: Acme Widgets and Ajax Gadgets. Acme has offices in New York, Dallas, and Los Angeles; Ajax has offices in New York, Chicago, and Dallas. Both Acme and Ajax wish to connect their various offices with private networks. The traditional way of doing this is with leased lines, but this can be very expensive. Instead, Acme and Ajax arrange to use their provider's MPLS network to obtain an equivalent, but cheaper, solution.
As shown in Figure 4.60, each customer site accesses the provider's network with a customer edge (CE) router that connects to a provider edge (PE) router. The interior topology of the provider's network consists of provider (P) routers. P routers do not connect directly to customer routers. Figure 4.60. MPLS VPNs
The PE routers act as border routers, and as we shall see, run BGP just as the border routers B1, . . . , B4 in Figure 4.59 did. One of the nice features of MPLS VPNs is that customers may number their networks any way they like and may even use the same addresses as another of the provider's customers. For specificity, let's assume that Acme and Ajax have assigned their networks the addresses shown in Figure 4.61.
This example has some features that we should notice. First, the Acme New York site and the Ajax Chicago site have the same network address (10.1.0.0/16), so the provider's network will have to have some way of distinguishing them. Second, all the customers' sites are numbered with nonroutable addresses. Ordinarily, this would require NAT, but just as with our previous IP-in-IP example, the fact that the traffic to and from the sites will be tunneled makes this unnecessary. Finally, although Acme and Ajax do not share a common VPN is this example, it is possible that two or more customers that have a business relationship would require a secure way to exchange information. In that case, the MPLS VPN architecture allows a VPN to be set up among some or all of the separate companies' sites.
In order to understand how an MPLS VPN operates, let's focus on Acme. The goal is to make the three offices appear to be on a common network. The illusion is that customer edge routers CE1, CE3a, and CE4a are connected with a mesh of leased lines, as shown in Figure 4.62. Figure 4.62. The MPLS VPN as Seen by Acme's Sites
One significant aspect of Figure 4.62 is that the Acme network is completely isolated from any other network. Although the traffic in our example is neither encrypted nor authenticated, the isolation ensures that traffic cannot be intercepted and that outsiders cannot inject forged packets into the network. When leased lines are used, the difficulty in breaching the physical security of the provider's network is what provides the security. As we shall see, in the case of MPLS VPNs, it is the isolation of routing data that provides the security. Because attackers do not know how to route to the customer's sites, they cannot interfere with the customer's traffic.
MPLS VPNs are implemented almost entirely in the provider edge routers. To see how this works, let's further narrow our focus to PE3, the New York provider edge router. PE3 is a routing peer with both Acme's CE3a and Ajax's CE3b customer edge routers, so in order to maintain isolation, PE3 has separate routing tables for Acme and Ajax. In our simple example, this routing information consists of a single network, but the network topology behind a customer edge router could be arbitrarily complex, and a provider edge router could learn routing information for several networks from each of its customer edge routing peers. Similarly, a customer may have more than one VPN in service, which would generally result in separate routing tables for each VPN. For clarity, we are ignoring these possibilities in our example. As we indicated earlier, the provider edge routers are BGP speakers that exchange routing and label information among themselves, just as in the MPLS tunnel example of Figure 4.59. As PE3 learns routes from the customer edge routers, it advertises them to its BGP peers: PE1, PE2, and PE4. PE3 augments each route with a 64-bit route distinguisher that is used to distinguish routes from two customers with identically numbered networks. PE3 also adds a VPN target, or route target, that identifies the particular VPN that the route applies to. The VPN target enables PE3's BGP routing peers to assign the route to the correct routing table. PE3 will, of course, also assign a label to the route, just as in the case of MPLS tunnels. Let us assume that PE3 assigns the label 18 for the route to the Acme 10.1.0.0/16 network. The "10.1.0.0" will be augmented to 96 bits by the route discriminator so that the other provider edge routers can distinguish it from the Ajax Chicago network of the same number. Finally, a VPN target will be assigned to the route to indicate that this route is for the Acme VPN. PE3 will advertise this information to the other provider edge routers in the usual BGP way. When the other provider edge routers receive this information, they will use the VPN target attribute to assign it to one of their routing tables. Now suppose that the Dallas Acme office wants to send an IP datagram over the VPN to the New York office10.1.0.15, say. When the packet arrives from the Acme CE router, the Dallas PE router (PE4) looks up the route for 10.1.0.15 in the Acme routing table and determines that the BGP next hop is PE router PE3 and that this packet should be sent through the VPN associated with the label 18. The 18 is pushed onto the label stack, and the next hop for PE3a is determined from a global routing table. The label for this next hop is pushed onto the label stack, just as it was in the case of the MPLS tunnel example. The packet travels through the provider's network until it reaches PE router PE3, which pops the upper label if the previous router has not already done so and uses the label 18 to determine that the packet should be forwarded to CE3a, the Acme CE at New York. In most cases, PE3 can make the final routing decision based on the label alone and need not consult the IP datagram itself. Just as with MPLS tunnels, the internal (P) routers need not know anything about the CE routers, the VPNs, or the routing information associated with them; they need merely know how to route traffic among the PE routers. This is an important advantage for service providers because it helps the network scale to a large number of VPNs. No single routerneither PE nor P routerneed be aware of all the routes used within the system. The P routers need know only the internal network topology, and a PE router need be aware only of the routing information used for VPNs that terminate at that PE router. We have examined only the rudiments of MPLS VPNs. Many more complicated configurations are possible. For example, a company could have one or more VPNs that all its sites take part in and other VPNs that reach only some of its sites. Similarly, two or more companies can arrange to have intercompany VPNs. [Pepelnjak and Guichard 2001] covers all these and other configurations in detail. |
|
|
