Let’s take a look at some of the things that we can do with MPLS. As we know, one of those things is Layer-3 MPLS VPNs, a peer-to-peer VPN scheme in which the PE and CE devices are both routers. In this scheme, a PE has a VRF for each customer to which it is attached, and we run MP-BGP to advertise the customer routes and associated VPN labels from one PE to another. From the customer’s perspective, the WAN provider’s MPLS cloud appears as a router, as shown in Figure 1:
Now let’s imagine that a customer has only two sites which they’d like to connect using a WAN service provider. The way this was done in the past would typically be with a leased line. This works, but it requires the customer to have a CE router at each site that converts between the LAN encapsulation (typically Ethernet) and the WAN encapsulation (HDLC, PPP, Frame Relay or whatever).
Wouldn’t it be nice if the customer could just run Ethernet to the PE? If so, they wouldn’t need the CE router. Instead of setting up a VRF for this customer on the PE, let’s go into the interface on the PE to which the customer is attached, and assign a unique “CID” (Circuit ID). On the PE on the far side, we’ll do the same thing, using the same value for the CID. Then, instead of MP-BGP, we’ll use TLDP (Targeted LDP) to connect the interfaces on the two PE’s. From the customer’s perspective, the provider’s MPLS cloud appears as a LAN repeater, as in Figure 2:
This arrangement, which is effectively a Layer-1 VPN, is referred to as “Pseudo Wire” (RFC 3916), and it’s very popular with both customers are providers. You might also see it called “VLL” (Virtual Leased Line), “VPWS” (Virtual Private Wire Service), “TLS” (Transparent LAN Service) or “EoMPLS” (Ethernet over MPLS). Whatever it’s called, it acts like a private point-to-point link between the two customer sites.
What if the customer has more than two sites? The legacy solution might be Frame Relay, but again, this requires a router at each customer site to handle the encapsulations. Instead, we could either start run multiple Pseudo Wires (anything from a hub-and-spoke up to a full mesh), or we could have the provider’s MPLS cloud emulate a LAN switch, as shown in Figure 3:
Since the MPLS cloud is now functioning as an Ethernet switch, while keeping customer traffic separated, it’s effectively a Layer-2 VPN. This is commonly referred to “VPLS” (Virtual Private LAN Service). With VPLS, the CIDs can be advertised using either MP-BGP or TLDP. By the way, Cisco refers to this Layer-1 and Layer-2 MPLS VPN stuff as “AToM” (Any Transport over MPLS).
What about customers that are using other Layer-3 protocols, such as IPv6, IPX, AppleTalk, and so forth? Since the P routers are doing only label switching, they never care about any customer’s routed protocols. The PE routers would need to understand the customer’s routed protocols for Layer-3 VPNs, but no equipment vendors (including Cisco) have implemented VRFs for anything but IPv4 and IPv6. How then to handle the other routed protocols?
The answer is to use Pseudo Wire (VPWS) or VPLS, for which the PEs don’t care about the customers’ routed protocols. Likewise, multicasting can also be supported by making the provider’s MPLS could appear as a Layer-1 or Layer-2 service.
From the provider perspective, MPLS is attractive because all of these services (Layer-1, Layer-2 and Layer-3 VPNs) can all be carried simultaneously over the same infrastructure, with only the PE routers requiring configuration on a per-customer basis.
Well, that’s it for MPLS … for now, anyway!
