Virtual Private LAN Service

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 pseudowires 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).[3] However, at the time of writing this, there are no 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. Standardisation 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 signalling.

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.