Layer 2 Vpn Architectures [Electronic resources] نسخه متنی

Layer 2 Tunnel Protocol Version 3 Overview

Although AToM can provide Layer 2 VPN services with advanced network features, you might need an alternative to provide Layer 2 VPN services if your network is not MPLS enabled or you do not want to deploy MPLS technologies. Like many other networking problems, you have multiple options. Depending on your short-term and long-term goals, you can choose the appropriate solution for your needs.

For example, if your goal is to move toward an MPLS-enabled network eventually but you need a time-to-market solution to provide Layer 2 VPN services on top of the existing IP infrastructure, you might choose AToM for Layer 2 VPN services, but you have to overlay AToM pseudowires over IP tunnels, such as generic touting encapsulation (GRE) tunnels. In this way, you can deploy MPLS-based Layer 2 VPN services in a relatively short period of time without being forced to migrate the entire core infrastructure to MPLS immediately. However, if the goal is to ultimately provide Layer 2 VPN services with a pure IP infrastructure, you have the option of choosing an IP-based Layer 2 VPN solution: L2TPv3.

L2TPv2 was originally designed for remote access solutions, and it only supports one type of Layer 2 frames: PPP. Retaining many protocol specifications of version 2, L2TPv3 enhances the control protocol and optimizes the header encapsulation for tunneling multiple types of Layer 2 frames over a packet-based network. L2TPv3 and its supplementary specifications, such as the Ethernet and Frame Relay extensions, describe the requirements and architectures that are applicable to pseudowire emulation using L2TPv3.

L2TPv3 consists of a control plane that uses an in-band and reliable signaling protocol to manage the control and data connections between L2TP endpoints, and a data plane that is responsible for pseudowire encapsulation and provides a best-effort data-forwarding service. In the L2TPv3 network reference models, L2TPv3 is implemented and deployed between a pair of L2TP Control Connection Endpoints (LCCEs). Figure 3-6 illustrates the network components of L2TPv3. The LCCEs are the equivalent of the PE routers in the generic Layer 2 VPN network reference model. For the sake of consistency, this book uses PE router in place of "LCCE" in the context of L2TPv3.

Because an L2TPv3 session is inherently bidirectional, an L2TPv3 pseudowire is essentially an L2TPv3 session carrying a particular type of Layer 2 frame. In other words, a one-to-one mapping exists between sessions and pseudowires. During the process of L2TPv3 session establishment, the peering PE routers exchange session IDs. An L2TPv3 session ID is equivalent to an AToM pseudowire label. A session or pseudowire consists of two session IDs. Fundamentally, L2TPv3 pseudowires and AToM pseudowires are set up in a similar fashion. The difference is that the baseline L2TPv3 protocol specification is responsible for constructing such a bidirectional pseudowire, whereas AToM relies on an application-level mechanism that is built on top of the LDP protocol specification for the same function. From the end user's point of view, this difference is insignificant.

Note

In certain deployment scenarios such as interworking between different Layer 2 protocols, AToM and L2TPv3 might carry Layer 3 packets directly. However, because the forwarding decision is still based upon Layer 2 information, such cases belong to the general Layer 2 VPN framework.

Besides using the L2TPv3 control messages to set up pseudowires dynamically, you can use manual configuration to provision the necessary session parameters. When you use manual configuration, you do not need to establish control connection between PE routers.

The next sections give an overview of L2TPv3 from the following aspects:

L2TPv3 operations

Supported Layer 2 protocols

Decision factors whether to use L2TPv3 in your network, such as installation base, advanced features, and complexity

L2TPv3 Operations

Even though L2TP is labeled as an IP-based technology, it is in fact a transport-independent protocol. L2TPv2, which is mostly deployed for remote access applications, specifies mechanisms to tunnel Layer 2 frames over UDP, ATM AAL5, and Frame Relay. L2TPv3 defines the specifications to tunnel Layer 2 frames over IP and UDP.

The tunneling mechanism is essentially accomplished by inserting an L2TP header between the IP or UDP header and the Layer 2 payload. A well-known IP protocol number or UDP port number differentiates L2TP packets from other types of IP traffic. The destination IP address of an L2TP packet is an address of the PE router on the other side of the tunnel. Sessions that are destined to the same PE router are multiplexed by session IDs into a common IP or UDP header.

L2TP control packets are transmitted in-band along with data packets. Therefore, the tunnel endpoints need to have a deterministic way to distinguish one type from the other. For L2TP over UDP, the first bit in the L2TP header indicates whether it is a control packet or a data packet. However, L2TP over IP has a different L2TP header that does not have a field for such indication. Instead, the L2TP header uses the reserved session ID value zero for control packets and nonzero session IDs for data packets.

The discrepancy of the two L2TP header formats is a result of optimization weighted toward different deployment models. The UDP transport mode is friendlier for the cases that require using IPsec to protect L2TP traffic, or traversing Network Address Translation (NAT) and firewalls. The IP transport mode is more tailored for implementing L2TP packet processing and forwarding in high-speed hardware architectures. Figure 3-7 shows an overview of the two formats of an L2TPv3 packet.

L2TP implements a low-overhead reliable delivery mechanism for control packets at the underlying transport layerthat is, IP or UDP. The upper-level functions of L2TP do not have to deal with retransmission or ordering of control packets. L2TP also uses a sliding window scheme for control packet transmission to avoid overwhelming the receiver. In addition, it provides an optional message digest-based authentication to guarantee control packet integrity, and an optional keepalive mechanism to ensure connectivity between tunnel endpoints.

Layer 2 Protocols Supported by L2TPv3

L2TPv3 supports the same set of Layer 2 protocols that AToM does, including PPP, HDLC, Ethernet, Frame Relay, and ATM.

PPP over L2TPv3 mostly operates in the transparent mode, in which case CE routers are the only PPP speakers that process the PPP frames through the PPP protocol stack, and PE routers merely forward PPP frames between the peering CE routers transparently.

HDLC over L2TPv3 is similar to PPP over L2TPv3. It allows transportation of Cisco HDLC frames over an IP network in the transparent mode, which is the only mode it supports.

Two types of Ethernet encapsulation are supported in Ethernet over L2TPv3:

Untagged Ethernet frame

IEEE 802.1q tagged Ethernet VLAN frame

PE routers classify Ethernet frames that are received from the CE routers into different pseudowires using the receiving interface or the VLAN tag. Bridging protocol support varies depending on the deployment model. Chapter 11, "LAN Protocols over L2TPv3 Case Studies," discusses the details of running bridging protocols over the IP network.

With Frame Relay over L2TPv3, PE routers forward Frame Relay frames to different pseudowires based on the receiving interface and the DLCI number. PE routers also provide LMI signaling to CE routers as if they are Frame Relay switches. Unlike Frame Relay over MPLS, the Frame Relay header is kept intact at the ingress PE router with Frame Relay over L2TPv3; therefore, the egress PE router does not need to reconstruct the Frame Relay header before forwarding the packets to the CE router.

ATM over L2TPv3 also supports ATM AAL5 and ATM Cell services. With ATM AAL5, PE routers receive ATM AAL5 packets or reassemble ATM cells into ATM AAL5 packets from CE routers and forward them to different pseudowires based on the receiving interface and the VPI or VCI numbers. The ATM flags, such as EFCI and CLP, are carried in the L2TPv3 ATM-specific sublayer, which serves a similar purpose to the AToM control word. ATM Cell over L2TPv3 can encapsulate a single ATM cell at a time or pack multiple ATM cells into one L2TPv3 packet. Both ATM services can be offered in VC mode, VP mode, or port mode. These modes determine the granularity of how ATM packets and cells should be classified and mapped to pseudowires.

Deciding Whether to Use L2TPv3

For organizations and companies that decide to stay with their existing IP-based network infrastructures for the long term and do not intend to migrate to MPLS-enabled networks, choosing L2TPv3 to provide Layer 2 VPN services is obvious. For those who have not decided which technology to choose, consider the following factors to gauge the feasibility and applicability of using L2TPv3 for Layer 2 VPN services.

Existing Network Installation Base

For service providers that do not have parallel legacy networks and those that traditionally provide only Layer 3 services, the problem of maintaining separate networks does not apply to them directly because they do not have the problem to start with. They have little incentive to invest in a new technology unless it brings new revenue opportunities.

As telecommunication deregulation has taken place, these service providers have started eyeing lucrative Layer 2 VPN services. The fastest and least expensive way to provide Layer 2 VPN services in an IP-based infrastructure is to use L2TPv3. AToM relies on a ubiquitous MPLS presence throughout the network infrastructure. If the network is not already MPLS enabled, it has to be migrated to MPLS first. L2TPv3 imposes minimal impactif anyon the core network infrastructure. It only requires the PE routers that provision Layer 2 VPN services to be aware of L2TPv3. In some cases, existing edge routers can readily provide Layer 2 VPN services with proper software upgrades. This is particularly attractive to service providers that are interested in creating new revenue streams with minimal initial investment.

Without L2TPv3, enterprises rely on service providers to provision and manage their Layer 2 network connections among geographically dispersed locations. Not only is the Layer 2 service expensive, but interprovider Layer 2 circuits must also be provisioned when these locations are not covered by a single service provider. The feasibility of provisioning interprovider Layer 2 circuit is constrained by whether these providers have such an interprovider Layer 2 connectivity agreement.

L2TPv3 can be an attractive cost-cutting and easy-to-manage alternative. Instead of getting expensive Layer 2 circuits from service providers, each site can purchase the best and least expensive IP service from a local service provider without worrying about the interprovider agreement issue because IP connectivity always exists among service providers. Each site then enables L2TPv3 on a CPE router and provisions Layer 2 connections to other sites without involving service providers.

Advanced Network Services

Because L2TPv3 uses IP or UDP as its transport layer, integrating with advanced IP-based network services, such as IPSec, is easy. If service providers manage Layer 2 VPN services for their customers, the strong security guarantee that is provided within the service provider network can be sold as a value-added feature. If enterprises manage Layer 2 VPN services, this combination gives them not only site-to-site Layer 2 connectivity but data integrity and privacy when transporting sensitive information across public or shared network infrastructures. With AToM, Layer 2 frames are encapsulated with an MPLS label stack, and there is no IP header in the resulting packet. Therefore, it is quite difficult to apply IPSec features to AToM packets.

Whenever possible, you should set the MTU of both attachment circuits that are connected through a pseudowire to the same value, and set the network MTU to accommodate the resulting L2TPencapsulated packets that carry the Layer 2 payload. If this is not possible, the Cisco IOS L2TPv3 implementation also supports Path MTU discovery and fragmentation options. These make use of the Don't Fragment (DF) bit in the IP header and ICMP messages to discover appropriate MTU settings for pseudowires. When the resulting L2TP packets exceed the pseudowire MTU, users can either choose to drop or fragment the packets.

Plain IP routing and forwarding do not provide advanced network features such as traffic engineering and fast reroute. By deploying IP differentiated services (diffserv), classifying different types of traffic diligently, overprovisioning network bandwidth strategically, and other fine-tunings on routing, you can achieve a fairly high level of service guarantees for Layer 2 VPN services.

Interoperability

L2TPv2 is a widely deployed and highly interoperable protocol, especially in remote access, wholesale dial and broadband networks. It has a large vendor support base.

L2TPv3 evolved from L2TPv2 and has kept many of the major characteristics and specifications of L2TPv2. The control plane procedures are almost identical in both versions. One of the main differences lies in the L2TP header format, which has more impact on the data plane. Another significant change is that the baseline protocol no longer defines the actions for each Layer 2 protocol that is carried in L2TP. Furthermore, it is up to each Layer 2 application to specify the appropriate actions. Because of these differences, the two versions of L2TP implementation are not interoperable.

Network Operation Complexity

L2TPv3 is a relatively simple network protocol as compared to the more sophisticated routing protocols and MPLS protocols. It requires little change to an existing IP-based network and is relatively easy to manage and troubleshoot.

As described in the previous sections, AToM uses LDP as the out-of-band signaling protocol, which means the control packets might take a different path from the data packets. Thus, the control plane connectivity cannot provide a reliable indication for the data plane connectivity. L2TPv3 uses an in-band TCP-like reliable control connection to set up and tear down data connections. That is why its liveliness serves as a good indication for that of the data plane.