Proposed standard simplifies VPLS

Implementing VPLS requires creating a complex matrix of services and locations in the edge routers at each site that quickly becomes difficult to configure and maintain. To address this complexity, the IETF Layer 2 VPN Working Group has proposed a standard to automate the setup and maintenance of VPLS mesh networks. The simplicity of the as-yet-unnamed VPLS auto-configuration standard has the potential to fulfill the promise of VPLS technology as the key enabler of enterprise-wide convergence.

Virtual Private LAN Service is an emerging technology that lets corporations and carriers segment voice, video and data traffic across a Multi-protocol Label Switching-based backbone network. For corporations, VPLS allows for multi-point VPNs that provide QoS for any traffic type. And carriers can use VPLS to build private IP segments for a corporation across a common MPLS backbone.

However, implementing VPLS requires creating a complex matrix of services and locations in the edge routers at each site that quickly becomes difficult to configure and maintain. To address this complexity, the IETF Layer 2 VPN Working Group has proposed a standard to automate the setup and maintenance of VPLS mesh networks. The simplicity of the as-yet-unnamed VPLS auto-configuration standard has the potential to fulfill the promise of VPLS technology as the key enabler of enterprise-wide convergence.

VPLS is implemented in edge routers and provides Layer 2 bridge-like services, which lets corporations with dispersed locations work in a switched LAN network over an MPLS backbone. The service’s multi-point pseudo wire connections emulate physical connections. This is done with a VPLS service ID label given to each service that defines the traffic type and QoS parameters.

In the example shown in the graphic, a three-location network supports a video transport service between locations A and B, VoIP services between location B and C, and a LAN segment for a large workgroup between A and C.

To implement these services, network managers create a VPLS mesh network that includes the service IDs and the locations that participate in these services. Network managers at each location must manually enter the service IDs and locations of each of the services into each VPLS edge router.

Scaling the network or deploying it across a multi-vendor network increases the risk of configuration errors, which could shut down the network, because all the edge routers must be updated with new mesh configurations every time a service is added, dropped or changed. The proposed standard is designed to configure the topology and location of each service. The service-location matrix is established automatically through a node-discovery process in which each router advertises its VPLS-enabled status and capabilities to all other routers. Each edge router discovers the location of all other VPLS edge routers. The edge router then builds and maintains a list of those routers.

Next comes the service-discovery phase, in which each VPLS router communicates its service IDs and builds a table of the service IDs of the relevant routers on the network. These routers then can build tunnels or virtual circuits to each remote router to support the relevant services.

VPLS auto configuration already has been implemented in products from many vendors, but the VPN Working Group still must define a protocol that can be used in multi-vendor implementations.

The group is reviewing several proposals that use various protocols to accomplish the node-discovery and service-discovery processes. It is considering these proposals but has not determined a schedule for issuing an Internet draft or RFC.

VPLS is the key to successful support of multi-point transparent VPNs in MPLS networks. The new auto-configuration standard will spur adoption by dramatically simplifying the process of building and maintaining VPLS networks.

Bergman is a research and development project leader at MRV Communications. He can be reached at obergman@mrv.com.