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

Pseudowire Emulation Overview

Pseudowire emulation is essentially a mechanism that re-creates the characteristics of a Layer 1 or Layer 2 circuit service, such as time-division multiplexing (TDM) or Frame Relay, over a packet-switched network (PSN). Pseudowires are emulated circuits that carry service-specific protocol data units (PDU) from one customer device to another through the service provider network. To end customers and their devices, it is transparent that the circuit service is provided through pseudowire emulation. In other words, if the transit network is migrated from a circuit-based legacy network to a packet-based IP/MPLS network, end customers do not perceive any change in services offered by the service provider.

The motivation for pseudowire emulation comes from the desire to have a converged network that delivers multiple services that are currently provided by parallel or overlay networks. Each of these parallel networks offers a specific service. Parallel networks are not only expensive in terms of capital expense and operational costs, but they also make it difficult to expand and maintain network infrastructure and services.

Because IP traffic has increasingly become the majority of the overall network communication, many service providers realize the benefit of investing in packet-based core networks either by expanding the existing PSNs or migrating from their legacy circuit-based networks. Although aiming at providing new packet-based services such as voice over IP (VoIP) and video on demand with this new network infrastructure, service providers also look for ways to migrate the existing services to the new infrastructure to maximize the return on capital and operational investment without impact to the existing revenue streams. Pseudowire emulation makes it possible to achieve this objective.

The next sections describe the fundamental concepts of pseudowire emulation and the processes involved in its deployment, as follows:

Network reference model

Protocol layer and system architecture

Transporting over PSNs

Pseudowire setup

Network Reference Model

Despite different Layer 2 VPN solutions and deployment models, a common network reference model can be applied to illustrate the general properties of pseudowire and other network components in the pseudowire emulation architecture, as shown in Figure 2-1.

A provider edge (PE) device is in the service provider administrative domain. It provides pseudowire emulation service to a customer edge (CE) device that belongs to the administrative domain of the customer.

One or more attachment circuits are used to connect a CE to the PE. An attachment circuit can be an Ethernet port, an Ethernet VLAN, a PPP session, a High-Level Data Link Control (HDLC) link, a Frame Relay data-link connection identifier (DLCI), an ATM virtual path identifier (VPI)/virtual connection identifier (VCI), and so on.

A pseudowire is a virtual circuit between two PE devices that interconnects two attachment circuits. You can set it up through manual configuration or automatic signaling. After you establish a pseudowire between two PE devices, native frames received from an attachment circuit are encapsulated into pseudowire PDUs and sent over pseudowire to the peering PE. When pseudowire PDUs arrive at the receiving PE device, they are changed back into the native form and forwarded to the corresponding attachment circuit.

Provider (P) devices form the packet-switched core network and are transparent to CE devices. They are unaware of pseudowires and pseudowire traffic, which PE devices manage. This kind of transparency alleviates the design complexity of the core network. Therefore, you can optimize the core network for core routing and packet forwarding performance without being constrained by the complexity of edge services. This transparency also helps to scale the number of emulated circuits. You need to provision only the edge devices for new circuits; you can leave the core devices alone.

Protocol Layer and System Architecture

Pseudowire emulation involves three protocol layers:

PSN layer

Pseudowire encapsulation layer

Payload layer

The PSN layer specifies the network addressing information of PE devices, which can be IPv4 addresses, IPv6 addresses, or MPLS labels. Network devices use the PSN layer to determine the forwarding path of pseudowire packets. You can think of this path as a packet-switched tunnel that carries pseudowire packets.

The pseudowire encapsulation layer consists of a pseudowire demultiplexing sublayer and an encapsulation sublayer. The pseudowire demultiplexing sublayer provides a means to carry multiple pseudowires over a single packet-switched tunnel. Each pseudowire has a demultiplexing value that is unique within a tunnel. The encapsulation sublayer carries payload encapsulation information that is removed at the ingress PE device so that the receiving PE device can reconstruct the payload into its native form before sending it to the attached CE device. For example, when the sublayer is transporting Frame Relay traffic over MPLS networks, it removes the Frame Relay header. Payload encapsulation information, such as the backward explicit congestion notification (BECN) bit and discard eligible (DE) bit, must be placed in the encapsulation sublayer. If necessary, this sublayer also carries sequence numbers that are used for in-order packet delivery.

The payload layer carries the pseudowire payload in various forms. For example, it can be Frame Relay packets in the native form or simplified form, ATM AAL5 packets, ATM cells, Ethernet packets, and so on.

Figure 2-2 illustrates the interaction of pseudowire protocol layers that reside on two peering PE devices. Each layer on one PE communicates with the same layer on the other PE through the lower layers, and the lower layers provide services to the upper layers.

PE devices play the key role in pseudowire emulation. In fact, the conversion between native circuits and emulated circuits is performed mostly inside PE devices. Therefore, you can benefit from having a high-level understanding of the system architecture of a PE device. Figure 2-3 shows an example of the general system architecture.

The PE device system architecture is divided into the control plane and the data plane. The data plane components include the following:

Physical interfaces Convert bits into electronic signals back and forth on the physical media.

Device drivers Serve as the intermediate layer that constructs media-specific framing for the physical interface and provides a media-independent interface to the upper layer.

Native service processor and pseudowire encapsulation System modules that deal with the data packet manipulation, which is discussed in detail in the following sections.

Network forwarding engine When a data packet is passed to the network forwarding engine from the pseudowire encapsulation module, a destination network address is also provided. Depending on the type of the PSN that carries the pseudowire traffic, the network forwarding engine looks up the address in the IPv4, IPv6, or MPLS forwarding tables. If it finds an outgoing interface, it encapsulates the packet with the appropriate link encapsulation and sends the packet out of the output interface. Otherwise, it discards the data packet.

The control plane components include the following:

Link layer protocol controller Performs line protocol signaling, such as Frame Relay Local Management Interface (LMI) and ATM Integrated Local Management Interface (ILMI), which is needed for setting up attachment circuits.

Pseudowire protocol processor and network protocol processor Perform pseudowire and routing protocol signaling procedures respectively. PE devices use these procedures to establish pseudowires and packet forwarding paths, as illustrated in Figure 2-2. The forwarding information that is obtained through the signaling procedures is distributed to the data plane so that the forwarding table can be populated.

Native Service Processing

In some deployment scenarios, data packets that arrive from attachment circuits are forwarded into pseudowires in their native form. In other cases, you must process native packets before applying the pseudowire encapsulation.

Often, different types of attachment circuits require different native service processing procedures. Furthermore, attachment circuits of the same type might require slightly different processing depending on the configuration that is associated with each attachment circuit. Native service processing occurs on a per-attachment circuit basis.

The native service processor (NSP) can manipulate packets in whichever way is necessary as the packets pass through it. For example, when a PPP packet arrives from a PPP attachment circuit that uses HDLC framing, the NSP removes the HDLC header so that the remaining PPP payload can be in a media-independent format. When the pseudowire encapsulated PPP payload arrives at the far-end PE device, the payload is passed to the NSP after the pseudowire encapsulation is removed. Then the NSP associated with the outgoing attachment circuit determines whether media-specific framing needs to be applied to the PPP payload.

When Ethernet VLAN tags are used as service delimiter, they usually have only local significance. The role of NSP is to remove the service-delimiting VLAN tag when receiving a packet from the VLAN attachment circuit and to add a local service-delimiting VLAN tag when it receives a packet from the pseudowire.

The NSP also normalizes certain control information in different native packet encapsulation into a unified representation for pseudowire operation. For example, besides the Ethernet native frame format, Ethernet packets from CE devices can arrive in other native encapsulations, such as Frame Relay or ATM bridged encapsulations. By normalizing the different forms of native packets into a single Ethernet frame format, you reduce the complexity of pseudowire processing.

Pseudowire Encapsulation Processing

After going through native service processing, the payload is ready for pseudowire encapsulation processing. The NSP might gather some payload-specific control information and pass it to the pseudowire encapsulation processor (PEP), typically through an out-of-band mechanism. The rationale behind the out-of-band mechanism is that in this way, the PEP can treat the payload as an opaque data object; therefore it is relieved from payload-protocolspecific operation.

The payload control information is used for per-packet signaling that is necessary for certain services. Besides this information, the pseudowire encapsulation might include timing for real-time traffic or sequencing for out-of-order detection.

For point-to-point pseudowire emulation, a one-to-one relationship exists between attachment circuits and pseudowires. In other words, given an attachment circuit, the PEP has a corresponding pseudowire and vice versa. A pseudowire consists of a transmitting and a receiving demultiplexer. The transmitting demultiplexer is applied to the payload along with other control information and sent to the network forwarding engine for the remote PE device to identify the pseudowire. When the network forwarding engine passes a pseudowire packet to the PEP, the PEP uses the receiving demultiplexer in the packet header to determine to which attachment circuit and NSP it needs to redirect after removing the pseudowire encapsulation.

Transporting over the PSN

Depending on the PSN infrastructure, you can use either IP or MPLS to transport pseudowire traffic. The PSN infrastructure not only determines the network layer encapsulation for pseudowire packets, but it also usually determines the format of the pseudowire demultiplexer. For instance, if you use IP as the underlying transport, the demultiplexer can be some kind of IP tunnel protocol field that provides demultiplexing capability. If you are using MPLS, you can employ an MPLS label in the label stack for such a purpose.

Some might argue that the pseudowire demultiplexer is not part of the pseudowire encapsulation because of its association with PSN tunneling protocols. This book categorizes pseudowire demultiplexer as part of the pseudowire encapsulation based on its functionality for pseudowires, not how it is implemented in a tunneling protocol. Moreover, the type of pseudowire demultiplexer can differ from the type of the underlying PSN. For example, in some deployment scenarios, it is necessary to carry pseudowire payload over MPLS and then over IP. That is usually because of the existence of a hybrid IP and MPLS network infrastructure for administrative or migration purposes. In this case, pseudowires use MPLS labels as the demulitplexer but IP as the PSN. The protocol details of transporting pseudowire over IP and MPLS are discussed in Chapter 3, "Layer 2 VPN Architectures."

Setting Up a Pseudowire

Prior to establishing an emulated service, you need to set up a pseudowire between two PE devices. You can trigger this setup through one of the following methods:

Manual configuration

Dynamic protocol signaling

An autodiscovery mechanism

The manual setup process is much like provisioning ATM permanent virtual circuits (PVC) in traditional ATM-based Layer 2 VPNs. Essentially, network operators determine all parameters that are needed to set up pseudowires. Then they configure them on the PE devices manually or through network management tools. This can be a labor-intensive process.

Dynamic protocol signaling relieves network operators from many of the operations that are required in the manual setup by exchanging pseudowire information and negotiating the parameters automatically. Some initial provisioning has to be done manually even with dynamic protocol signaling, such as addresses of peering PE devices and identification of remote attachment circuits.

An auto-discovery mechanism utilizes an existing network distribution scheme that is designed for large-scale network operation and management, such as a distributed directory database or an interdomain routing protocol like BGP, to advertise the emulated services. When PE devices learn about the emulated services from each other, they automatically establish pseudowires among them accordingly. Ideally, an auto-discovery mechanism has the minimal amount of manual involvement for pseudowire setup. Although auto-discovery definitely helps in some situations, especially during service migration, the nature of Layer 2 services always incurs a fair amount of manual provisioning compared to Layer 3 services.

Pseudowire setup often requires creating new protocols or extending existing protocols to signal pseudowire information. Creating and extending pseudowire emulation protocols is a hotly debated area in the networking industry and standardization bodies, as described in the next section.