Future Layer 2 Services

Several enhancements to the current Layer 2 VPNs are being discussed for MPLS networks. The following sections discuss some examples that can shape the future of Layer 2 VPN deployments.

ATM-MPLS Interworking

The migration of Layer 2 VPNs from current ATM networks to new MPLS-based Layer 2 VPNs has its own set of challenges in terms of provisioning, management, and cutover. Flash cutovers from an old network to a new network are not an option. This means that during the migration phase, some nodes must be on the old network and others on the new network. The migration process might be much simpler if the two networks spoke to the same control plane. Given the fact that an ATM network uses ATM UNI/PNNI signaling to set up SVCs and SPVCs and an MPLS control plane uses LDP to set up pseudowires, you need to interwork the two control planes to be able to set up Layer 2 connections and VCs across the ATM and MPLS networks. This requires a control plane interworking function at the edge; the interworking function translates the ATM UNI/PNNI signaling to the MPLS LDP pseudowire that is set up dynamically. More intelligence can be added to the interworking point to set up TE tunnels or to perform admission control for VCs to provide the correct QoS behavior. For more details, please refer to the ATM Forum Specifications.

Layer 2 VPNs Across Multiple Provider Networks

The setup of Layer 2 VPNs across multiple ASes and providers is not obvious when it comes to building pseudowires. Some proposals include building two segment provisioning systems, where each provider builds its own pseudowire segment for the Layer 2 connection and there is either a native handoff of Layer 2 frames or these pseudowires are stitched together at the boundary. Having a stitching model helps each provider maintain control of its network without disclosing the network loopback addresses. More redundancy options can be added by allowing setup of backup pseudowires where traffic is mapped when primary pseudowires fail due to either a path or PE failure.

VPLS Service Across a NonEthernet Last Mile

VPLS requires an Ethernet end point as it bridges LANs together. However, remote sites might need to be connected to this VPLS network. These remote sites might have only FR or ATM connectivity. Having the ability to do VPLS forwarding at this remote node over a Frame Relay circuit allows a flexible connectivity option that easily extends the Ethernet service to any attached end point. Therefore, you do not need to have an Ethernet connection between PE and CE to offer a VPLS service to CEs.