Since there's been data networking, there's been a debate between switched and routed architectures-stated in OSI terms, between performing functions at Layer 2 or Layer 3. As technologies change, the argument never really goes away, but simply assumes new forms. Today, we see it surfacing as network architects consider the design of virtual private networks (VPNs) that take advantage of multiprotocol label switching (MPLS). The question is, when are MPLS VPNs better implemented at Layer 3, using Border Gateway Protocol (BGP)-based VPNs, and when are they better at Layer 2, using MPLS tunneling technologies?
To consider the issue in purely competitive terms is to oversimplify. Layer 3 MPLS VPNs will remain most appealing to those Internet service providers (ISPs) that already use BGP extensively and have already deployed high-end Internet Protocol/MPLS routing equipment at the edge. However, for carriers with existing Layer 2 VPN deployments or those accustomed to delivering transport services, the "overlay" model of Layer 2 MPLS could prove more attractive. Such carriers are unlikely to be interested in the degree of IP routing and (more to the point) the high-end IP-equipment expenditures that Layer 3 VPNs call for. In addition, where direct interoperability with existing Layer 2 VPN deployments is important, Layer 2 VPNs have the advantage.
Private networks
It's easy to lose sight of the purpose of MPLS VPN technology. The goal is simple: build a network that, as much as possible, acts like an extension of the private corporate network on a service provider's shared-network infrastructure. Ideally, the result is a fast and efficient means of making scattered places seem just like local sites, from workers' homes to branch offices. MPLS, designed to scale IP networks, is a natural choice for virtual private networks. Supporting multiple private networks on a shared infrastructure suggests scaling problems for both Layer 3 and Layer 2 networks. For each of these, MPLS can help.
The Layer 3 VPN MPLS implementation is an early leader. The BGP model is based on an IETF Request for Comments (RFC) 2547, and these "2547 VPNs" have already been implemented in several major carrier networks, including parts of the IP/MPLS backbones of AT&T, Bell Canada and Global Crossing.
How does a 2547 VPN work? As the RFC explains, "MPLS is used for forwarding packets over the backbone, and BGP is used to distribute routes over the backbone." Each 2547 VPN is really a private IP network, with modified private IP addresses for each of the provider edge (PE) routers immediately connected to the customer site.
The route to each of the sites on the private network is distributed using the familiar BGP routing protocol.
The relationship between the PE router and the customer edge (CE) router is the truly distinctive aspect of 2547 VPNs. The CE router becomes a peer of the PE router (but is not a peer to the other CE routers). The CE router provides the PE router with route information for the private network. The PE router, in turn, must be capable of storing multiple private routing tables-one for each customer connection-along with the usual public Internet forwarding information.
MPLS handles the forwarding between the nodes on a 2547 network (in this respect, Layer 2 and 3 VPN approaches are identical). This MPLS forwarding role is crucial because it means the routers in the core of the network ("P" routers) need know nothing about the routes connecting the 2547 private network. A 2547 network uses a two-level label stack-the ingress PE router pushes both a next-hop BGP header (for the private network) and a next-hop Interior Gateway Protocol (IGP) header (for the shared infrastructure) onto the packet.
After reaching the egress PE router, via one or more MPLS label-switched paths, the PE pops the MPLS headers and delivers a normal IP packet to the customer. The RFC 2547 approach has great potential. It takes advantage of the ubiquity of IP networks and, like IP, runs over multiple transport networks. It also has strong automatic route discovery, which is important for dynamic VPNs.
On the other hand, this approach can be very demanding of provider edge routers. Today, only the most expensive routers can maintain multiple private routing tables. While not all 2547 deployments will necessarily require anything but a number of static routes, the potential for overburdening the network exists. Some, like AT&T's Randy Bush, therefore believe that RFC 2547 can threaten the integrity of an entire network.
A different philosophy underlies Layer 2 MPLS virtual private networks, also known as transparent local-area network services or virtual private LAN services. The goal is the extension, rather than replacement, of existing Layer 2 VPN services. Instead of building a separate, private IP network and running traffic across it, Layer 2 VPNs take existing Layer 2 traffic and send it through point-to-point tunnels on the MPLS network backbone.
Both Layer 2 and Layer 3 MPLS VPNs rely on MPLS transport through the core. The principal difference lies in how PE-CE router relations are handled. In a Layer 2 MPLS VPN, the PE router is not a peer to the CE router and does not maintain separate routing tables. Rather, it simply maps incoming Layer 2 traffic onto the appropriate point-to-point tunnel. The result is best described as an overlay model, as opposed to the Layer 3 peer model.
Analogies are tricky, but we might think of the wide-area network as a mountain that must be traversed. A 2547 VPN is more like a separate railway system that must be boarded to traverse a network of mountain tunnels. The Layer 2 approach better resembles a series of simple car tunnels that go straight through the mountain without the transition to rail. As this comparison suggests, there might be different reasons to want each.
Point-to-point tunnels
Crucial to the Layer 2 VPN model is a method for establishing simple point-to-point tunnels on an MPLS network that can handle various forms of Layer 2 traffic. Today, the industry is standardizing on the Martini drafts (named after Luca Martini from Layer 3 Communications), which define a point-to-point encapsulation mechanism for Ethernet, frame relay, asynchronous transfer mode (ATM), time-division multiplexed and PPP/HDLC traffic. Still other Internet drafts are building on the Martini draft encapsulations to define frame relay and ATM operation and to define Ethernet-transparent LAN services.
The Layer 3 approach, as stated above, is ideally suited to "classic" ISP networks with existing core-router deployments. It is a good fit for carriers serving large VPNs with changing locations. The Layer 2 approach, on the other hand, is the preferred approach for service providers who want to extend and scale legacy Layer 2 VPN deployments, or any situation with few VPN sites and static routes. Many carriers may already be providing Layer 2 VPN services over frame relay or metro Ethernet, and are interested in scaling such services.
RSS
RSS| 
Digital| 
Mobile
