One of the most compelling drivers for MPLS in service provider networks is its support for Virtual Private Networks (VPNs), in which the provider’s customers can connect geographically diverse sites across the provider’s network.
There are three kinds of MPLS-based VPN:
- Layer 3 VPNs: With L3 VPNs the service provider participates in the customer’s Layer 3 routing. The customer’s CE router at each of his sites speaks a routing protocol such as BGP or OSPF to the provider’s PE router, and the IP prefixes advertised at each customer site are carried across the provider network. L3 VPNs are attractive to customers who want to leverage the service provider’s technical expertise to insure efficient site-to-site routing.
- Layer 2 VPNs: The provider interconnects the customer sites via the Layer 2 technology – usually ATM, Frame Relay, or Ethernet – of the customer’s choosing. The customer implements whatever Layer 3 protocol he wants to run, with no participation by the service provider at that level. L2 VPNs are attractive to customers who want complete control of their own routing; they are attractive to service providers because they can serve up whatever connectivity the customer wants simply by adding the appropriate interface in the PE router.
- Virtual Private LAN Service: VPLS makes the service provider’s network look like a single Ethernet switch from the customer’s viewpoint. The attraction of VPLS to customers is that they can make their WAN look just like their local campus- or building-scope networks, using a single technology (Ethernet) that is cheap and well understood. Unlike traditional Metro Ethernet services built around actual Ethernet switches, service providers can connect VPLS customers from regional all the way up to global scales. So a customer with sites in London, Dubai, Bangalore, Hong Kong, Los Angeles, and New York can connect all his sites with what appears to be a single Ethernet switch.
The “Virtual” in VPN is that the individual services have the appearance of being distinct, but are in fact built on a single shared infrastructure – the MPLS network. The advantage to the service provider is that he can build a portfolio of services to attract a range of customers, without significantly increasing his capital investment or operational expenses.
But it’s the “Private” part of VPN that I want to discuss. Not only must services remain distinct even though they are supported over a single MPLS network, but individual customer’s networks must remain securely separated from each other:
- Customer A and customer B, both using L3 VPNs, must not see each other’s IP prefixes. In fact their respective address spaces can overlap; for instance, both can address their networks using the same 10.0.0.0 addresses, and the service provider network keeps the customer’s prefixes separate.
- Customer C and customer D, using L2 VPNs, must not see each other’s Layer 2 addresses or any sort of connection other than to their own sites.
- VPLS customers E and F, while both “seeing” the provider’s network as a single Ethernet switch, must not have the appearance of being connected to the same Ethernet switch. That is, the virtual Ethernet switch interconnecting customer E’s sites must not be the same virtual Ethernet switch interconnecting customer F’s sites.
Figure 1 (click here to view Figure 1) shows the key elements for creating privacy between VPNs: Individual information tables for each customer and each customer site, interconnected by individual MPLS LSPs (MPLS virtual circuits). What the information table contains depends on the type of VPN the table supports:
- The information tables for L3 VPNs contain IP prefixes and are called Virtual Routing and Forwarding Tables (VRF). VRFs are simply dedicated routing tables.
- The information tables for L2 VPNs, called Virtual Forwarding Tables (VFT), contain the Layer 2 addresses of whatever L2 technology it supports; Frame Relay DLCIs, for example.
- The information tables for VPLS contain Ethernet MAC addresses and, if VLANS are being used, VLAN IDs, mapped either to local ports or to LSPs leading to other sites. These tables serve the same role as the MAC tables in Ethernet switches.
The VPN network of Figure 1 is simplistic; it only depicts three customers with two or three sites each. A production MPLS VPN network is likely to have at least hundreds of customers and thousands of information tables. Keeping a basic LSP structure like the one in Figure 1 would quickly lead to scaling limitations.
So rather than switch each table-specific LSP individually in the MPLS core network, LSPs are created between each of the PEs, and shown in Figure 2 (click here to view Figure 2). The table-specific LSPs are then tunneled within these PE-to-PE LSPs, permitting much better scaling in the core; switching only must occur among these much fewer tunnel LSPs.
And that is the reason for emphasizing label stacking in the last post: It is an essential function for MPLS VPN scaling. When a PE receives an IP packet or a Layer 2 frame from a locally connected CE, it does a lookup in the local information table. If the destination of the packet or frame is to a CE at another site, it is encapsulated behind an MPLS header with the correct label for the LSP connecting to the remote information table. The resulting MPLS packet is then encapsulated behind another MPLS header, with the outgoing label of the tunnel LSP connecting to the remote PE in which the remote information table resides.
At the remote PE the outer header is popped, and the label of the inner header is examined. That label tells the PE what local information table to consult. The inner header can then be popped, and the decapsulated packet or frame can be forwarded to the locally connected CE as specified by the correct information table.
That gives you the basics of how forwarding is accomplished for MPLS VPNs. In Part II, I’ll discuss how the reachability information contained in the various information tables is signaled across the MPLS core to remote PEs.