Pseudowire Emulation StandardizationWhenever a major new technology emerges, many companies and organizations get involved in the standardization process and try to push the proposals that are favorable to their business interests. Pseudowire emulation is no exception. Organizations such as Internet Engineering Task Force (IETF), IEEE, International Telecommunication Union (ITU), ATM Forum, and MPLS Forum have produced many technical proposals and documents on pseudowire emulation. Because the majority of vendor and operator support and activity of pseudowire emulation happen in the IETF, this section focuses on the standard process of the IETF. IETF Working GroupsThe IETF is the predominant organization that standardizes protocols and solutions based on the Internet architecture. The technical work of the IETF is divided by topic into several areas, such as internet, routing, and transport. Under each technical area are several working groups where the actual work is done. Working groups form as the result of popular interests of solving a particular problem from the networking community and disband when the problem is resolved. Sometimes the charter of a working group changes when a new problem arises or the original problem evolves. Prior to becoming a working group, an informal discussion group, known as Birds of a Feather (BOF), is formed to measure the scope of the problem and the level of interests in finding the solutions. In the IETF, the following working groups are discussing proposals that are related to pseudowire emulation:
Pseudowire Emulation Edge-to-Edge (PWE3) working group The goal of this working group is to develop standards for the encapsulation and service emulation of pseudowires. That is, the goal is to encapsulate service-specific PDUs received on one ingress port and carry them across a tunnel, and to emulate the behaviors and characteristics of the service as closely as possible. The two most debated proposals on pseudowire emulation"draft-martini" and "draft-kompella"first surfaced in this PWE3 BOF session. Both drafts are discussed later in this chapter.
Layer 2 VPN working group This working group is responsible for three major Layer 2 VPN solutions or architectures: Virtual Private LAN Service (VPLS), Virtual Private Wire Service (VPWS), and IP-only Layer 2 VPNs. The working group focuses on Layer 2 VPN signaling and provisioning rather than Layer 2 native service emulation, which is the responsibility of the PWE3 working group.
Layer 2 Tunneling Protocol working group This working group is responsible for protocol extensions that support carrying multiple Layer 2 services over IP networks. Layer 2 VPN Architectures on Pseudowire EmulationDuring the Circuit Emulation over Transport BOF (later renamed to PWE3) at the 49th IETF meeting in 2000, two Internet drafts made their debut and stirred up waves of commotion and heated debates. They were known as "draft-martini" and "draft-kompella." Both drafts addressed the question of how to achieve pseudowire emulation over packet-based networks, but the solutions that each proposed were vastly different. The two drafts were focused on achieving pseudowire emulation over MPLS-based packet networks, and each solution had its advantages and disadvantages. Members of the networking community quickly divided themselves into two camps based on the different design philosophies that were embedded in the two drafts. Note The terms draft-martini and draft-kompella have become synonyms for the two different network architectures that they represent. The actual drafts do not exist in IETF anymore, but the ideas behind them are making their ways toward becoming standards. However, these informal names are still widely used in the networking community to identify the doctrine of each vendor implementation. This section lists the pros and cons of each architecture and does not intend to advertise one method over the other. draft-martiniFigure 2-1 as reference, the draft describes how to establish a pseudowire between two attachment circuits that are located on two peering PE devices. It also specifies the encapsulation methods for each Layer 2 service. The Label Distribution Protocol (LDP) distributes MPLS labels for various MPLS applications, including pseudowire emulation. The architecture is concerned with creating and managing individual point-to-point pseudowires, which have no correlation to one another. Before initiating a pseudowire to a remote PE, you need to provision the local PE with a virtual circuit (VC) ID or pseudowire ID shared by both the local and remote attachment circuit, and an IP address of the remote PE. Because the baseline LDP does not readily have the necessary protocol element for pseudowire signaling, the draft defines a pseudowire extension for LDP. A pseudowire is considered established when the peering PE devices exchange label information for the pseudowire. Using LDP terminology, this means that each PE device sends and receives a label mapping message for a given pseudowire. Network operators can provision pseudowires by using the architecture that is defined in draft-martini manually or through some sort of network management system. It is much like provisioning traditional Frame Relay or ATM PVCbased Layer 2 VPNs. However, someone could perceive this as either a good attribute or a bad one. Some like the architecture because this is a familiar business, and much of the experience and tools developed in the traditional Layer 2 VPNs can be leveraged. Others think the architecture suffers the same set of problems, such as scalability, as those of the traditional Layer 2 VPNs. This Layer 2 VPN architecture supports point-to-point Layer 2 services, including Frame Relay, ATM AAL5, ATM Cell, Ethernet, Ethernet VLAN, PPP, and HDLC, in addition to Layer 1 service, such as TDM. draft-kompella
The architecture that is proposed in draft-kompella does not resemble that of the draft-martini or the traditional Layer 2 VPNs. To a certain degree, it shares some characteristics of Layer 3 dynamic routing. Unlike draft-martini, it involves complex signaling procedures and algorithms, and the provisioning scheme, which is somewhat tricky, works better with some Layer 2 services than others. One major objective of draft-kompella is to tackle the inherent scalability problem of the traditional Layer 2 VPNs. As shown earlier in Figure 2-1, a pseudowire is needed to connect two CE devices that attach to two different PE devices. To have full connectivity among the CE devices when the number of CE devices increases, the number of pseudowires that needs to be established and managed grows exponentially. In addition, every time you add a new CE device or move an existing CE device to attach to a different PE device, you must reconfigure all the PE devices that are participating in this VPN to maintain the full-mesh connectivity. This can become a dauntingly labor-intensive task for network operators. The draft attempts to solve the scaling problem by over-provisioning the number of attachment circuits needed for current CE devices so that the existing CE and its PE devices do not need to be reconfigured when adding a new CE to a VPN. The basic premise for over-provisioning is that the attachment circuits between CE and PE devices are relatively cheap. To provision a Layer 2 VPN using the architecture that is defined in draft-kompella, each CE that belongs to the VPN is given a CE ID, and each CE is configured with a maximum number of CE devices that it can connect to. This is also known as the CE range. Each attachment circuit between a CE and a PE is given an index value, which corresponds to a particular remote CE ID in this VPN. By such an arrangement, each CE can derive which attachment circuit connects to which remote CE. Each PE is then configured with the VPNs in which it participates. Each VPN is denoted by a VPN ID. The PE is provisioned with a list of CE devices that are members of a given VPN. The PE also knows the CE ID, CE range, and the index values for the attachment circuits of each CE. When a PE is configured with all the necessary information for a CE, it allocates a contiguous range of MPLS labels that corresponds to the CE range. The smallest value in this label range is called the label base. For each CE, the PE then advertises its own router ID, VPN ID, CE range, and label base through BGP update messages, which are broadcast to all other PE devices. Even though some PE devices might not be part of the VPN, they can receive and keep this information just in case a CE that is connected to the PE joins the VPN in the future. Because the baseline BGP does not readily have the necessary protocol element for pseudowire signaling, the draft defines a pseudowire extension for BGP. This architecture solves the scaling problem by making the provisioning task of adding a new CE device a local matter. That is, whenever a new CE device is added, only the CE and the PE to which it is attached need to be configured. Remote CE and PE devices do not need reconfiguration because they can calculate which spare attachment circuit should be used to communicate with the new CE. Remote PE devices can also learn about the new CE through BGP update messages. The broadcast nature of BGP makes it easy to automatically discover PE devices that are participating in Layer 2 VPNs, which further reduces the configuration on PE devices. The weakness of this architecture comes from the validity of the assumptions it is based on. For example, the low cost of attachment circuits is valid when the CE and PE are directly connected through virtual circuits such as Frame Relay and ATM PVCs, but not when they are connected through a switched Frame Relay or ATM network, or the attachment circuits are individual physical links and ports, such as PPP and HDLC links. In the latter case in which the cost of individual attachment circuits is expensive, over-provisioning becomes impractical. Also, the typical Layer 2 VPNs deployed today are rarely fully meshed because having a fully meshed flat network creates scaling problems for Layer 3 routing, where hierarchy is desired. If a Layer 2 VPN consists only of sparse point-to-point connections, advertising the information of a CE to all other PE devices and keeping it on these PE devices waste network resources because such information is only interesting to a single remote PE. Not exhaustively, Table 2-1 compares the most noticeable characteristics of the two Layer 2 VPN architectures that are defined by draft-martini and draft-kompella.
Even though draft-martini has made a lot of progress in standardization and deployment, its primitivenesssuch as the lack of support in Layer 2 VPN autodiscoveryis recognized. New solutions have since been worked on to overcome the issues found throughout product development and network deployment. To find out more about the latest development in the standardization process, refer to the IETF web site at http://www.ietf.org. Other Layer 2 VPN ArchitecturesThe Layer 2 VPN architectures on pseudowire emulation generally define the procedures for setting up individual pseudowires and encapsulation methods for different Layer 2 services. They are the foundation and building blocks for other types of Layer 2 VPN architectures. VPWS is directly derived from pseudowire emulation. A VPWS is essentially a network of point-to-point pseudowires that interconnect CE devices of a Layer 2 VPN. Besides the basic pseudowire emulation service, VPWS defines the specifications for point-to-point Layer 2 VPN service in broader terms, such as quality of service (QoS), security, redundancy, VPN membership discovery, and so on. VPWS in some way is designed as a replacement for the traditional Frame Relay or ATM-based Layer 2 VPN. VPLS also uses the basic pseudowire emulation service, but it is a very different architecture from VPWS. The objective of VPLS is to emulate Transparent LAN Service (TLS) in a packet-based network, which is typically seen in Layer 2 switched Ethernet networks. Instead of acting as a point-to-point cross-connect between the attachment circuit and pseudowire, a VPLS PE functions as an Ethernet bridge. When receiving an Ethernet frame from a CE, the PE looks up the destination MAC address of the frame in its bridging table. If it finds a match, it forwards the frame to the output interface that is specified in the bridging table. Otherwise, it learns and stores the source MAC address in the bridging table, and it floods the Ethernet frame to all output interfaces in the same broadcast domain. Whereas VPWS requires one dedicated attachment circuit for each remote CE device, VPLS allows a single attachment circuit to transmit frames from one CE to multiple remote CE devices. In this respect, VPLS resembles the characteristics of Layer 3 VPN more than VPWS. IP-only LAN Service (IPLS) is similar to VPLS, but it is tailored and simplified for carrying IP traffic only. In IPLS, a CE device can be a host or a router but not a switch, whereas VPLS has no such a restriction.
|