Many enterprises are fundamentally changing their business processes using advanced IT applications to achieve enhanced productivity and operational efficiencies. Examples of such strategic advanced applications include: Enterprise Resource Planning (ERP), voice over IP (VoIP), instant messaging, and network-based meeting and presentation tools. These advanced applications tend to place increasing importance on peer-to-peer data communications, as compared to traditional client-server data communications. As a result, the underlying network architecture to support these applications is also evolving to better accommodate this new model.
The performance of peer-to-peer applications benefits from being implemented over service provider networks that support multipoint network services. The definition of a multipoint network service is one that allows each customer edge (CE) end point or node to communicate directly and independently to all other CE nodes. The multipoint network service contrasts with the hub-and-spoke network service, where the end customer designates one CE node to be the hub that multiplexes multiple point-to-point services over a single User-Network Interface (UNI) to reach multiple "spoke" CE nodes. This means that each spoke can reach any other spoke only by communicating through the hub.
The requirement for reliable peer-to-peer communication is relatively easy to support within Ethernet switched campus networks, which is inherently a multipoint service architecture. However, this requirement is more difficult to support in traditional WAN networks, such as Frame Relay or ATM, which are based on a hub-and-spoke service architecture. Furthermore, these traditional WAN technologies tend to impose bandwidth limitations that constrain the future growth of these peer-to-peer applications. For example, Frame Relay is typically available at speeds of T-1 (E-1), and ATM is rarely available at speeds above OC-3 (STM-1).
To address the emerging network requirements of their enterprise customers, service providers are evaluating network technologies and architectures that can support multipoint services. In doing so, service providers have evaluated Ethernet technologies in the context of a WAN transport because of the success that Ethernet technology has achieved in supporting multipoint architectures for enterprise networks. Additionally, both service providers and enterprises alike recognize that Ethernet technology offers many benefits as a UNI including:
These attributes and the inherent connectivity and performance of Ethernet help ensure that the performance of enterprise applications, especially peer-to-peer applications, benefit from being implemented over service provider networks that support multipoint network services.
In attempting to deliver Ethernet-based multipoint services, service providers are evaluating and deploying two types of multipoint architectures: Layer 3 Virtual Private Networks (L3 VPNs) or Layer 2 VPNs (L2 VPNs).
The most common L3 VPN technology is MPLS L3 VPN, which delivers multipoint services in the context of a Layer 3 service over a Layer 3 network architecture. MPLS L3 VPNs offer many attractive characteristics for delivery of multipoint services, including:
- The use of a variety of UNIs including Frame Relay, ATM, and Ethernet.
- The scalability of MPLS for wide-area service deployments.
- The ability to access multiple L3 VPNs from the same UNI.
- The ability for the end customer to add new CE nodes without having to reconfigure the existing CE nodes.
- Robust quality of service (QoS) implementation allows differentiated packet forwarding according to application characteristics.
- The ability to support stringent service-level agreements (SLAs) for availability.
However, MPLS Layer 3 VPNs do impose certain provisioning requirements on both service provider and enterprise customers that are sometimes unacceptable to one or the other party. Some enterprises are reluctant to relinquish control of their network to their service provider. Similarly, some service providers are uncomfortable with provisioning and managing services based on Layer 3 network parameters, as is required with MPLS L3 VPNs.
For multipoint L2 VPN services, service providers have frequently deployed Ethernet switching technology using techniques such as 802.1Q Tunneling (also referred to as Tag Stacking or Q-in-Q) as the foundation for their Metro Ethernet network architecture.
Ethernet switching technology has a long and proven track record in enterprise LANs for delivering high bandwidth at affordable prices. With the introduction of 10-Gbps Ethernet switching, the outstanding price/performance of Ethernet is offering even greater price/performance advantages for both enterprise and service provider networks. The multipoint services supported by these switched Ethernet service provider networks, sometimes referred to as "transparent LAN services," are good examples of Layer 2 VPN services supported over a Layer 2 network architecture.
These switched Ethernet network architectures have proven to be successful in delivering high-performance, low-cost L2 VPN multipoint services by numerous service providers in many countries. However, as the size of these switched Ethernet networks has continued to grow, the limitations on the scalability of this architecture has become increasingly apparent. These limitations include:
To address the limitations of both MPLS L3 VPNs and Ethernet switching, innovations in network technology for delivering multipoint connectivity services have led to the development of a new technology, which is known as Virtual Private LAN Service or VPLS.
VPLS is a multipoint L2 VPN technology that allows multiple sites to be connected over a simulated Ethernet broadcast domain that is supported across a provider provisioned IP/MPLS network. In other words, VPLS delivers multipoint Layer 2 connectivity over a Layer 3 network architecture. VPLS evolved as a logical extension of Ethernet over MPLS (EoMPLS), which was developed to enable point-to-point Ethernet-based L2 VPN services.
At a basic level, VPLS can be defined as a group of Virtual Switch Instances (VSIs) that are interconnected using EoMPLS circuits in a full mesh topology to form a single, logical bridge. In concept, a VSI is similar to the bridging function found in IEEE 802.1q bridges in that a frame is switched based upon the destination MAC and membership in a Layer 2 VPN (a virtual LAN or VLAN). If the destination address is unknown, or is a broadcast or multicast address, the frame is flooded to all ports associated with the VSI, where a port, in the context of VPLS, is an EoMPLS VC pseudowire.
With VPLS, all CE devices participating in a single VPLS instance appear to be on the same LAN and, therefore, can each communicate directly with one another in a multipoint topology, without requiring a full mesh of point-to-point circuits at the CE device. In a VPLS network, CE devices and provider edge (PE) devices are not routing peers, so there is no need for service providers to provision customer IP routers, a significant advantage over MPLS L3 VPN services. Compared to traditional LAN switching technologies, VPLS is also more flexible in its geographic scaling, so that CE sites may be within the same metropolitan domain, or may be geographically dispersed on a regional or national basis.
The increasing availability of Ethernet-based multipoint service architectures from service providers, for both L2 VPN and L3 VPN services, is resulting in a growing number of enterprises transitioning their WANs to these multipoint services. VPLS will play an increasingly important role in this transition.
VPLS technology began in mid-2001, when various service providers that were evaluating the possibility of deploying Metro Ethernet services identified concerns about the deployment of basic Ethernet switching architectures. They correctly noted that Ethernet switching technologies developed up to that point were deficient in providing network services that could support the SLA characteristics comparable to existing traditional WAN services, such as Frame Relay, T-1/E-1 and ATM.
These service providers sought a technology that could support multipoint data services (transparent LAN services) over an infrastructure that provided traffic engineering, high availability, and OAM characteristics similar to their existing services. The obvious technology direction to investigate was MPLS, and specifically EoMPLS.
EoMPLS had been previously defined in the IETF specification originally referred to as the Martini Draft, and was posted to the IETF draft site toward the end of 2000. This document explained the format for point-to-point L2 VPN services using Ethernet frames transported over an MPLS pseudowire, with LDP specified as the signaling and OAM mechanism for this point-to-point service.
This EoMPLS draft specification supported most of the service characteristics that many of the service providers were seeking, except that it did not support a multipoint service architecture, only a point-to-point or hub-and-spoke service architecture. However, the basic encapsulation and signaling mechanisms of EoMPLS would prove to be a reasonable basis for defining a multipoint service architecture.
In mid-2001, several drafts that described VPLS were submitted to the IETF by various authors and sponsors. By the end of that year, there were at least five different VPLS drafts submitted to the IETF. For VPLS to be seriously adopted, it would be necessary for these different drafts to be consolidated and distilled into a single draft. The next 12 months resulted in intense efforts between the different VPLS draft authors to find common ground for a single draft. In July 2002, a unified draft was submitted to IETF that consolidated most, but not all, of the VPLS IETF drafts.
Significant progress has been made over the past two years in the development of VPLS standards. Evidence of this progress is that independent testing labs have conducted several interoperability demonstrations of VPLS. Isocore (http://www.isocore.com/), which is an independent testing lab for advanced networking technologies, conducted the most recent test in September 2003. The press release for this VPLS interoperability testing is available at:
Finally, it is important to remember that VPLS is still a new technology. The use of L2 VPN services based on VPLS technology is still in its infancy. The VPLS functionality from all vendors, including Cisco, are based on implementations using network processors, not application-specific integrated circuits (ASICs), because the draft standards have only evolved in a period of time that would be less than the development window for an ASIC implementation.
Furthermore, most service providers are only performing early evaluations of the VPLS technology. Nevertheless, the interest level for VPLS is strong on a worldwide basis. Looking toward 2004, there will be many service providers in all regions of the world that will offer their first services based on VPLS technology.
The future success of Metro Ethernet services very much depends on the design and deployment of a Metro Ethernet architecture that delivers on the outstanding price/performance of Ethernet, while supporting the scalability and reliability required in a service provider network. Scalability in the Metro Ethernet service architecture will need to be defined in terms of both number of end users supported and geographic reach. It will not be sufficient to support only localized Metro Ethernet services. End customers, particularly the large enterprise users, will expect to be able to connect their Metro Ethernet services on an inter-region and even nationwide basis.
VPLS is expected to play a very significant role in these Metro Ethernet architectures. However, Cisco expects that VPLS will not be the sole technology required to support Metro Ethernet services, but will be used in conjunction with Ethernet switching technology to create a hierarchical architecture for delivering multipoint L2 VPN services. Ethernet switching will be used for the local Metro Ethernet service domain; VPLS will be used for interconnecting multiple local domains for large metro and inter-region services. The combination of these two technologies will provide an economically efficient and scalable solution.
The complementary relationship between these two technologies for constructing a hierarchical, hybrid architecture is important to understand. VPLS can be used to overcome some of the inherent weaknesses of Ethernet switching. For example, the ability of VPLS to translate VLAN service identifiers on the Ethernet frame from one side of the VPLS core network to the other enables the overall Metro Ethernet service deployment to scale beyond 4000 L2 VPNs, which is the limit of the IEEE 802.1q VLAN address space in a switched Ethernet network.
The primary shortcoming of VPLS is the broadcast replication that it must perform whenever it is transmitting an Ethernet packet with either a multicast MAC address or an unknown MAC address. In both cases, the Ethernet packet must be broadcast throughout the VPLS. However, the VSI associated with a VPLS instance is a logical bridge entity that connects to all other VSIs in the VPLS using EoMPLS pseudowires. Therefore, the Ethernet packet to be broadcast must be replicated on all EoMPLS pseudowires that are associated with a particular VSI. This replication is usually not as efficient as the mechanism for transmitting broadcast traffic with Ethernet switching technology, because broadcast traffic need only be transmitted once per physical interface with Ethernet switching technology, but may need to be replicated multiple times over the same physical interface with VPLS technology. Furthermore, the amount of VPLS replication that must be performed increases exponentially as the number of end points in the VSI increases.
The relative inefficiency of the broadcast replication mechanism in VPLS is improved within hierarchical VPLS architectures that combine VPLS with Ethernet switching technology, as the amount of VPLS replication required can be confined to broadcasts between Ethernet switching domains, instead of to all the end points in the L2 VPN multipoint service.
A great deal of publicity has surrounded VPLS since its inception in 2001. VPLS will be an important technology, but most service providers will need to offer a complete portfolio of commercial services, where multipoint L2 VPNs based on VPLS technology are only one element. The majority of service providers will offer Ethernet access to deliver both multipoint and point-to-point L2 VPN, as well as L3 VPN services. Their customers will request all these types of services, and will also continue to use the traditional point-to-point services, such as Frame Relay and ATM.
The strategic differentiator for service providers will be how easily they allow their customers to integrate this full portfolio of services. For example, can all network services be accessed from the same Ethernet UNI. The service provider that can deliver the universal Ethernet access port will have a significant advantage in the market for commercial data communication services.
Cisco has played a central role in the standardization and development of VPLS technology since its inception. Cisco has been involved in the development of VPLS standards in all the critical standards bodies including IETF, IEEE, MEF (Metro Ethernet Forum), and ITU.
More than being committed to the standardization of VPLS, Cisco is committed to delivering a comprehensive Metro Ethernet solution strategy that supports the broadest range of service offerings. To achieve this, Cisco is involved in a wide range of technical activities including:
Finally, and perhaps most importantly, Cisco is delivering its first implementation of VPLS in Q1 2004. This implementation will be delivered on the Cisco 7600 Series Router, which has been widely deployed in Metro Ethernet architectures by service providers worldwide. The initial implementation of VPLS on the 7600 Series will support PE connections to the VPLS core using Gigabit Ethernet, POS OC-12 or POS-OC48 interfaces. Future implementations of VPLS on the Cisco 7600 Series will support 10-GB Ethernet interfaces.
The Cisco 7600 Series VPLS implementation is based on the Sajassi/Lasserre draft. Cisco will update this implementation to be conformant with the converged VPLS standard when that standard is completed.
The Cisco 7600 Series VPLS functionality has been tested in several major service provider organizations and will be used to support multipoint L2 VPN services beginning in 2004. Cisco is willing to work with other service provider organizations to support their testing of the Cisco 7600 Series VPLS functionality.