Virtual Private LAN Service (VPLS) is a way to provide Ethernet based multipoint to multipoint communication over IP/MPLS networks. It allows geographically dispersed sites to share an Ethernet broadcast domain by connecting sites through pseudo-wires. The technologies that can be used as pseudo-wire can be Ethernet over MPLS, L2TPv3 or even GRE. There are two IETF standards track RFCs (RFC 4761 and RFC 4762) describing VPLS establishment.
VPLS is a virtual private network (VPN) technology. In contrast to L2TPv3, which allows only point-to-point layer 2 tunnels, VPLS allows any-to-any (multipoint) connectivity.
In a VPLS, the local area network (LAN) at each site is extended to the edge of the provider network. The provider network then emulates a switch or bridge to connect all of the customer LANs to create a single bridged LAN.
VPLS is designed for applications that require multipoint or broadcast access
Contents |
Since VPLS emulates a LAN, full mesh connectivity is required. There are two methods for full mesh establishment for VPLS: using BGP and using Label Distribution Protocol (LDP). The "control plane" is the means by which provider edge (PE) routers communicate for auto-discovery and signaling. Auto-discovery refers to the process of finding other PE routers participating in the same VPN or VPLS. Signaling is the process of establishing pseudo-wires (PW). The PWs constitute the "data plane", whereby PEs send customer VPN/VPLS traffic to other PEs.
With BGP, one has auto-discovery as well as signaling. The mechanisms used are very similar to those used in establishing Layer-3 MPLS VPNs. Each PE is configured to participate in a given VPLS. The PE, through the use of BGP, simultaneously discovers all other PEs in the same VPLS, and establishes a full mesh of pseudo-wires to those PEs.
With LDP, each PE router must be configured to participate in a given VPLS, and, in addition, be given the addresses of other PEs participating in the same VPLS. A full mesh of LDP sessions is then established between these PEs. LDP is then used to create an equivalent mesh of PWs between those PEs.
An advantage to using PWs as the underlying technology for the data plane is that in case of failure, traffic will automatically be routed along available backup paths in the service provider's network. Failover will be much faster than could be achieved with e.g. Spanning Tree Protocol (STP). VPLS is thus a more reliable solution for linking together Ethernet networks in different locations than simply connecting a WAN link to Ethernet switches in both locations.
VPLS has significant advantages for both service providers and customers. Service providers benefit because they can generate additional revenues by offering a new Ethernet service with flexible bandwidth and sophisticated service level agreements (SLAs). VPLS is also simpler and more cost effective to operate than a traditional service. Customers benefit because they can connect all of their sites to an Ethernet VPN that provides a secure, high speed and homogenous network. Moreover, VPLS provides a logical next step in the continuing evolution of Ethernet from a 10 Mbit/s shared LAN protocol to a multi-Gbps global service.
VPLS MPLS packets have a two-label stack. The outer label is used for normal MPLS forwarding in the service provider's network. If BGP is used to establish the VPLS, the inner label is allocated by a PE as part of a label block. If LDP is used, the inner label is a virtual circuit ID assigned by LDP when it first established a mesh between the participating PEs. Every PE keeps track of assigned inner label, and associates these with the VPLS instance.
PEs participating in a VPLS-based VPN must appear as an Ethernet bridge to connected customer edge (CE) devices. Received Ethernet frames must be treated in such a way as to ensure CEs can be simple Ethernet devices.
When a PE receives a frame from a CE, it inspects the frame and learns the CE's MAC address, storing it locally along with LSP routing information. It then checks the frame's destination MAC address. If it is a broadcast frame, or the MAC address is not known to the PE, it floods the frame to all PEs in the mesh.
Ethernet does not have a time to live (TTL) field in its frame header, so loop avoidance must be arranged by other means. In regular Ethernet deployments, Spanning Tree Protocol is used for this. In VPLS, loop avoidance is arranged by the following rule: A PE never forwards a frame received from a PE, to another PE. The use of a full mesh combined with split horizon forwarding guarantees a loop-free broadcast domain.
VPLS is typically used to link a large number of sites together. Scalability is therefore an important issue that needs addressing.
VPLS requires a full mesh in both the control and data planes; this can be difficult to scale. For BGP, the control plane scaling issue has long been addressed, through the use of route reflectors (RRs). RRs are extensively used in the context of Internet routing, as well as for several types of VPNs. To scale the data plane for multicast and broadcast traffic, there is work in progress to use point-to-multipoint LSPs as the underlying transport.
For LDP, a method of subdividing a VPLS VPN into two or three tiered hierarchical networks was developed. Called hierarchical VPLS (HVPLS), it introduces a new type of MPLS device: the multi-tenant unit (MTU) switch. This switch aggregates multiple customers into a single PE, which in turn needs only one control and data plane connection into the mesh. This can significantly reduce the number of LDP sessions and LSPs, and thus unburden the core network, by concentrating customers in edge devices.
HVPLS (LDP) may also be used to join two VPLS mesh structures together. Without using HVPLS, every node in each VPLS mesh must become meshed with all nodes in the other VPLS mesh. However, with HVPLS, the two meshes can essentially be joined together at certain locations. Techniques such as redundant pseudo-wires can provide resiliency in case of failures at the interconnection points.
Since VPLS links multiple Ethernet broadcast domains together, it effectively creates a much larger broadcast domain. Since every PE must keep track of all MAC addresses and associated LSP routing information, this can potentially result in a large amount of memory being needed in every PE in the mesh.
To counter this problem, sites may use a router as the CE device. This hides all MAC addresses on that site behind the CE's MAC address.
PE devices may also be equipped with content-addressable memory (CAM), similar to high-end Ethernet switches.
An alternative mechanism is using MAT (MAC Address Translation). However, at the time of writing this, there aren't vendors providing MAT functionality.
In a VPLS-based VPN with a large number of sites, manually configuring every participating PE does not scale well. If a new PE is taken into service, every existing PE needs to have its configuration adjusted to establish an LDP session with the new PE. Standardization work is in progress to enable auto-discovery of participating PEs. Three implementations are being worked on:
The LDP method of PE auto-discovery is based on that used by the Label Distribution Protocol to distribute labels across P and PE routers within a single autonomous system.
The BGP method of PE auto-discovery is based on that used by Layer-3 MPLS VPNs to distribute VPN routes among PEs participating in a VPN. The BGP4 Multi-Protocol (BGP-MP) extensions are used to distribute VPN IDs and VPN-specific reachability information. Since IBGP requires either a full mesh of BGP sessions or the use of a route reflector, enabling the VPN ID in a participating PEs existing BGP configuration provides it with a list of all PEs in that VPN. Note that this method is for auto-discovery alone; LDP is still used for signaling. The method of establishing VPLS with BGP described above accomplishes both auto-discovery and signaling.
This method requires ALL PEs to be configured with one or more RADIUS servers to use. When the first CE router in a particular VPLS VPN connects to the PE, it uses the CE's identification to request authentication from the RADIUS server. This identification may be provided by the CE, or may be configured into the PE for that particular CE. In addition to a username and password, the identification string also contains a VPN name, and an optional provider name.
The RADIUS server keeps track of all PEs that requested authentication for a particular VPN, and returns a list of them to the PE requesting authentication. The PE then establishes LDP sessions to every PE in the list.