LDP-BGP VPLS Interworking

WHITE PAPER

Copyright © 2010, Juniper Networks, Inc.

LDP-BGP VPLS InterworkInG

ii Copyright © 2010, Juniper Networks, Inc.

wHIte PAPer - LDP-BGP VPLS Interworking

Table of Contentsexecutive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

How to Use this White Paper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

VPLS overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

VPLS Control Plane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

BGP-VPLS Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

LDP-VPLS Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Forwarding Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Scaling Characteristics of LDP VPLS and BGP VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Full-Mesh Connectivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Provisioning VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Flooding and Broadcasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Exchanging Pseudowire Signaling State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Inter–Autonomous System Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Scaling Beyond a Single Metro Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Comparison of LDP-VPLS and BGP-VPLS Control Plane Scaling Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Business Drivers for LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Scaling the VPLS Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Extending the VPLS Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Scaling an LDP-VPLS network Using BGP VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Basic LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Pros and Cons of Basic LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Scalable LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Redundancy in Scalable LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Pros and Cons of Scalable, Redundant LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Interconnecting LDP- and BGP-VPLS Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Basic Interdomain LDP-BGP VPLS Interworking Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Interconnecting and Extending VPLS for Multiple LDP-VPLS Domains Using BGP VPLS . . . . . . . . . . . . . . . . . . . 17

Redundancy in Interdomain LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Simultaneously Providing LDP-BGP VPLS Interworking and PE Router Functionality . . . . . . . . . . . . . . . . . . . . . 19

Pros and Cons of Interdomain LDP-BGP Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

operational Details: LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Operational Details: Basic LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Operational Details: Scalable LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Control Plane Operation of the Interworking PE Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Forwarding Plane Operation of the Interworking PE Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Example of VPLS Forwarding Between LDP-VPLS and BGP-VPLS Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Redundancy in Scalable LDP-BGP VPLS Interworking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

BGP-VPLS Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Interworking PE Router Redundancy for the LDP-VPLS Groups Using BGP-VPLS Multihoming . . . . . . . . . 27

Operational Details: Basic Interdomain LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Reachability Between PE Routers and the Interworking Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Copyright © 2010, Juniper Networks, Inc. iii


Table of FiguresFigure 1: LDP VPLS requires a full mesh of LDP sessions to be established when a new Pe router Is added . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Figure 2: BGP sessions need to be set up only between the new Pe router and the route reflector . . . . . . . . . . . . . . . 5

Figure 3: In LDP VPLS, adding a new site requires manual configuration on all existing member Pe routers to create a full mesh of pseudowires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Figure 4: BGP autodiscovery automates the member Pe router discovery and requires provisioning only on the Pe router to which the site is added . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Figure 5: resource-intensive flooding operation using ingress replication in which an ingress Pe router (Pe1) makes multiple copies of an incoming multicast packet to send it to each egress Pe router . . . . . . . . . . . . . . . 7

Figure 6: efficient flooding operation using P2MP LSP in which ingress Pe router (Pe1) forwards the multicast packet on P2MP LSP and may require replication at a router . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 7: LDP-VPLS network reference topology for scaling methods using BGP-VPLS signaling . . . . . . . . . . . . . . 10

Figure 8: Scaling an existing LDP-VPLS network using the BGP-VPLS control plane . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 9: LDP-BGP VPLS interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 10: Multiple interworking Pe routers placed in the VPLS network to cap the LDP-VPLS deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 11: redundancy in scalable LDP-BGP VPLS interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 12: Basic interdomain LDP-BGP VPLS interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figure 13: extending the reach of the LDP-VPLS metro domain to the wAn using the BGP-VPLS control plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 14: Interconnecting multiple LDP domains on a single ASBr and extending their reach to the wAn using the BGP-VPLS control plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 15: redundancy in interdomain LDP-BGP VPLS interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figure 16: Ce device attached to border router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figure 17: Mapping the group of LDP-VPLS Pe fouters to BGP-VPLS signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 18: Mapping the BGP-VPLS group in LDP-VPLS signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Figure 19: Mapping of fully meshed BGP-VPLS and LDP-VPLS groups to a different mesh group on the interworking Pe router forwarding plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 20: example of VPLS forwarding between LDP and BGP groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figure 21: Common MAC table state on interworking Pe router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Figure 22: BGP-VPLS signaling providing multihoming to the attached Ce device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 23: BGP-VPLS Signaling multihoming procedure providing redundancy to the LDP-VPLS group . . . . . . . . . 27

Figure 24: Designated interworking Pe router becoming unreachable to the LDP-VPLS group . . . . . . . . . . . . . . . . . 28

Figure 25: reachability between the interworking router and all Pe routers of all LDP-VPLS domains . . . . . . . . . . 29

Figure 26: Interconnecting multiple LDP-VPLS domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Figure 27: Multihoming multiple LDP-VPLS domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Operational Details: Multiple LDP-VPLS Domains Interconnected Using BGP VPLS . . . . . . . . . . . . . . . . . . . . . . . 29

Control Plane Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Forwarding Plane Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Multihoming Multiple LDP-VPLS Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

About Juniper networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Copyright © 2010, Juniper Networks, Inc. 1


Executive SummaryVirtual private LAN service (VPLS) has emerged as one of the dominant MPLS applications today. Growing demand for VPLS requires the VPLS network to scale to support many VPLS customers with multiple sites spread across geographically dispersed regions. Key to scaling the VPLS network is how well the underlying VPLS control plane scales. There are two widely deployed VPLS control planes, both standardized by the Internet Engineering Task Force (IETF): one using BGP and the other using LDP. The scaling characteristics of both these control planes differ vastly. BGP VPLS signaling offers numerous advantages over LDP VPLS. Additionally, the BGP-VPLS autodiscovery feature offers substantial operational benefits that have already been proven in production networks.

This white paper presents various interworking mechanisms that leverage BGP VPLS to scale VPLS implementations and augment existing LDP VPLS networks. The LDP-BGP VPLS interworking mechanism does not require any changes to the existing LDP-VPLS provider-edge (PE) routers; rather, these methods allow for VPLS deployments to scale by leveraging both BGP VPLS and LDP-BGP VPLS interworking mechanisms.

This white paper also discusses the use of BGP VPLS to extend the reach of VPLS from a single LDP-VPLS metro domain into the intermetro WAN. This scheme allows service providers to offer regional and/or national VPLS in a scalable and transparent way.

How to Use this White Paper This white paper is organized so that you can go from a high-level overview down into the operation details of LDP-BGP VPLS interworking.

OVERVIEWSSECTION SECTION CONTENTSVPLS overview Overview of the BGP-VPLS and LDP-VPLS control planes, as well as VPLS

forwarding plane operations.

Scaling Characteristics of LDP VPLS and BGP VPLS

Overview of the following points:

• Full-mesh connectivity

• Provisioning VPLS

• Flooding and broadcasting

• Exchanging pseudowire signaling state

• Scaling beyond a single metro area

• Comparison of LDP-VPLS and BGP-VPLS control plane scaling characteristics

Business Drivers for LDP-BGP VPLS Interworking

Overview of the need to be able to scale and extend LDP-BGP VPLS networks

Scaling an LDP-VPLS network Using BGP VPLS

Overview and comparison of basic LDP-BGP VPLS interworking and scalable LDP-BGP VPLS interworking, including adding redundancy in the scalable solution

Interconnecting LDP- and BGP-VPLS Domains

Overview of the following points:

• Basic interdomain LDP-BGP VPLS interworking scheme

• Interconnecting and extending VPLS for multiple LDP-VPLS domains using BGP VPLS

• Redundancy in interdomain LDP-BGP VPLS interworking

• Simultaneously providing LDP-BGP VPLS interworking and PE router functionality, including the pros and cons

• Pros and cons of interdomain LDP-BGP VPLS interworking

2 Copyright © 2010, Juniper Networks, Inc.


OPERATIONAL DETAILSSECTION SECTION CONTENTSoperational Details: Basic LDP-BGP VPLS Interworking

Operational details of the basic LDP-BGP VPLS interworking scheme

operational Details: Scalable LDP-BGP VPLS Interworking

Operational details of the following points:

• Control plane operation of the interworking PE router

• Mapping the group of LDP-VPLS PE routers to BGP-VPLS signaling

• Mapping the group of BGP-VPLS PE routers to LDP-VPLS signaling

• Forwarding plane operation of the interworking PE router

• Example of VPLS forwarding between LDP-VPLS and BGP-VPLS groups

• Redundancy in scalable LDP-BGP VPLS interworking

• BGP-VPLS multihoming

operational Details: Basic Interdomain LDP-BGP VPLS Interworking

Operational details of basic interdomain LDP-BGP VPLS interworking, including details on reachability between PE routers and the interworking router

operational Details: Multiple LDP-VPLS Domains Interconnected Using BGP VPLS

Operational details of the following points:

• Control plane enhancements

• Forwarding plane enhancements

• Multihoming multiple LDP-VPLS domains

IntroductionVarious implementations of VPLS enable the delivery of multipoint Ethernet services. VPLS is not only being used by service providers to offer transparent LAN service to enterprise customers, but with the emergence of metro Ethernet networks, VPLS is also being used as an infrastructure technology. Service providers are showing significant interest as measured by their VPLS deployments; many are now offering inter-provider services. This interest is further evidenced by the substantial growth of MPLS VPNs, which have a compound annual growth rate (CAGR) of 12.8% to $6.4 billion in 2011.1 This growth has been fueled by the fact major multiple service operators (MSOs) and large service providers are increasingly targeting small- and medium-sized businesses (SMB), as well as large enterprises. Consequently, the growing demand for VPLS requires the underlying enabling infrastructure to scale to support larger numbers of concurrent VPLS instances with multiple sites spread across geographically dispersed regions.

This document specifies in detail the very mechanisms that allow the scalable rollout of VPLS, as well as the enabling mechanisms that allow the interworking of LDP- and BGP-based VPLS.

VPLS OverviewA VPLS network is a Layer 2 multipoint VPN that emulates LAN services across a WAN. VPLS enables service providers to interconnect several customer sites (each being a LAN segment) over a packet-switched network, effectively making all the customer LAN segments behave as one single LAN. With VPLS, no routing interaction occurs between the customer and service provider, and the customer can run any type of Layer 3 protocol between sites.

The IETF Layer 2 VPN Working Group has produced two separate VPLS standards, documented in RFC 4761 and RFC 4762 (see Kompella and Rekhter, Jan. 2007, and Lasserre and Kompella, Jan. 2007). These two RFCs define almost identical approaches with respect to the VPLS data plane, but specify significantly different approaches to implementing the VPLS control planes.



VPLS Control PlaneThe VPLS control plane has two primary functions: autodiscovery and signaling.

Discovery refers to the process of finding all PE routers that participate in a given VPLS instance. A PE router can be configured with the identities of all the other PE routers in a given VPLS instance, or the PE router can use a protocol to discover the other PE routers. The latter method is called autodiscovery.

After discovery occurs, each pair of PE routers in a VPLS network must be able to establish pseudowires to each other, and in the event of membership change, the PE router must be able to tear down the established pseudowires. This process is known as signaling. Signaling is also used to transmit certain characteristics of the pseudowire that a PE router sets up for a given VPLS.

BGP-VPLS Control PlaneThe BGP-VPLS control plane, as defined by RFC 4761, is similar to that for Layer 2 and Layer 3 (see Kompella, Jan. 2006, and Rosen and Rekhter, Feb. 2006). It defines a means for a PE router to discover which remote PE routers are members of a given VPLS (autodiscovery), and for a PE router to know which pseudowire label a given remote PE router will use when sending the data to the local PE router (signaling). With the BGP-VPLS control plane, BGP carries enough information to provide the autodiscovery and signaling functions simultaneously.

As in the BGP scheme for Layer 2 and Layer 3 VPNs, a route target is configured on each PE router for each VPLS present on the PE router. The route target is the same for a particular VPLS across all PE routers and is used to identify the VPLS instance to which an incoming BGP message pertains.

For each VPLS on each PE router, an identifier is configured, known as a site identifier. Each PE router involved in a particular VPLS must be configured with a unique site identifier. The site identifier is same as the Virtual Edge Identifier (VEID) referred to in RFC 4761.

A label block is a set of demultiplexor labels used to reach a given VPLS site within a set of remote sites. The PE router uses a label block to send a single common update message to establish a pseudowire with multiple PE routers, instead of having to send an individual message to each PE router.

LDP-VPLS Control PlaneIn contrast to the BGP-VPLS control plane, the LDP-VPLS control plane provides only signaling, but not autodiscovery. In this control plane, LDP is used to signal the pseudowires that are used to interconnect the VPLS instances of a given customer on the PE routers. The LDP signaling scheme for VPLS is similar to the LDP scheme for point-to-point Layer 2 connections (see Martini et al., Apr. 2006). In the absence of an autodiscovery mechanism, the identities of all the remote PE routers that are part of a VPLS instance must be configured on each PE router.

The virtual circuit identifier (VCID), which is in the point-to-point Layer 2 connection used to identify a specific pseudowire, is configured to be the same for a particular VPLS instance on all PE routers. Hence, the VCID enables a PE router to identify the VPLS instance to which the LDP message refers.

LDP VPLS defines the hierarchical VPLS (H-VPLS) scheme in which, instead of all PE routers being fully meshed with LDP sessions, a two-level hierarchy is created involving hub PE routers and spoke PE routers. The hub PE routers are fully meshed with LDP sessions, whereas a spoke PE router has a pseudowire only to a single hub PE router or to multiple hub PE routers for redundancy. Spoke pseudowires can be implemented using any Layer 2 tunneling technology.

Forwarding PlaneForwarding plane procedures, at least for unicast and to some extent for multicast, are the same for both BGP VPLS and LDP VPLS. For each VPLS, a PE VPLS data plane functions as a learning bridge and supports all the standard bridge operations, such as MAC address learning, aging, and flooding. All the pseudowires established by BGP or LDP signaling and the local customer edge (CE) router ports of a VPLS instance constitute the logical ports of a bridge domain.

A MAC forwarding table is created for each VPLS instance on a PE router. This table is populated using a source MAC address learning function and is used to forward unicast VPLS traffic based on the destination MAC address of the received frame.



VPLS packets received over a pseudowire are not forwarded to any other pseudowire, but rather are forwarded only on the attached CE router circuit. This behavior has been called split-horizon forwarding and is a consequence of the PE routers being logically fully meshed in the data plane for each VPLS instance. The use of a full mesh combined with split-horizon forwarding avoids Layer 2 loops and is the VPLS alternative to Spanning Tree Protocol (STP) within the service provider network.

Scaling Characteristics of LDP VPLS and BGP VPLS There are two distinct VPLS control planes: LDP based and BGP based, both of which have been standardized by the IETF. This section compares the scaling aspects of the signaling and discovery mechanisms of these two control planes.

Full-Mesh ConnectivityTo enable VPLS, all PE routers connected to common VPLS customers must be able to exchange VPLS signaling information amongst themselves. As the number of PE routers in the network increases, scaling this signaling component of the VPLS control plane becomes essential.

For LDP-VPLS signaling, the exchange of VPLS signaling information is accomplished by setting up a full mesh of targeted LDP sessions between each pair of PE routers that have at least one VPLS in common (Figure 1). As the size of the VPLS network grows, the number of LDP targeted sessions increases exponentially on the order of O(N^2), where N is the number of LDP-VPLS PE routers in the network.

Maintenance of all these LDP sessions creates an additional load on the control plane of PE routers in the VPLS network. The operational challenge resulting from the O(N^2) increase in LDP sessions becomes even more noticeable when a service provider authenticates the sessions using Message Digest 5 (MD5) because MD5 keys must be configured on each end of every LDP session. Adding a new PE router or deleting an existing one becomes a cumbersome task because the configuration on each of the PE routers in the network must be modified.

Figure 1: LDP VPLS requires a full mesh of LDP sessions to be established when a new Pe router Is added

Unlike in LDP VPLS, the exchange of VPLS signaling information in BGP VPLS does not require a full mesh of control sessions among all PE routers. Instead, the BGP-VPLS control plane, including its signaling component, can use a route reflector (RR) hierarchy, in which only the route reflectors are fully meshed (Figure 2). Each BGP router then establishes a BGP session to one or more route reflectors. Using route reflectors also makes the provisioning task of adding or deleting a PE router simpler because only the BGP peering with the route reflector needs to be changed.

PE1 PE4

PE5PE2

PE3 PE6

PE7

New PE added

Existing LDP session

New LDP session



Figure 2: BGP sessions need to be set up only between the new Pe router and the route reflector

Route reflectors are a proven technology that is used extensively in networks in which BGP is deployed for Internet routing or for other types of VPNs. Furthermore, BGP-VPLS route reflectors can be placed anywhere in the network; that is, they do not need to be on the data path of the VPLS domains they host. This arrangement offers flexibility in deploying new route reflectors when needed for even greater scaling.

LDP VPLS signaling has no mechanism similar to the route reflector hierarchy that can eliminate the full mesh of targeted LDP sessions. H-VPLS tries, to some extent, to mitigate the full-mesh requirement by creating a two-level hierarchy of hub and spoke devices. However, this attempt to scale the control plane changes the data plane behavior and has a significant negative impact on the data plane. In contrast, because the BGP-VPLS route reflector technique is purely a control plane technique, it does not change the forwarding path of VPLS traffic in any way, and thus has no impact on the data plane.

Provisioning VPLS For each customer attached to a VPLS network, a given PE router needs to know the identity of all the other PE routers that attach to the customer’s other sites to create a full mesh of pseudowires. The PE router can learn about other sites either from manual configuration (or provisioning) or by using a protocol to automatically discover the identity of the other PE routers. In a large-scale network deployment, such an autodiscovery approach is particularly efficient.

The LDP-VPLS control plane does not have inherent support of autodiscovery. Therefore, LDP-VPLS signaling relies either on manual configuration to identify all PE routers to which customer sites are attached or on the use of BGP for autodiscovery (Figure 3). In a large-scale deployment, the task of manual configuration is operationally inefficient and subject to human error. Equally problematic, moving this task to a provisioning system adds considerable complexity and expense. Moreover, any addition or removal of a VPLS customer site requires a configuration change not only on the PE router to which the site is being added or deleted, but also on all the member PE routers of that VPLS customer. Finally, the use of BGP for VPLS autodiscovery and LDP for VPLS signaling adds complexity to the overall solution, both from the protocol perspective and from an operational and troubleshooting point of view.

PE1 PE4

PE5PE2

PE3 PE6

PE7

RR

New PE added

Existing BGP session

New BGP session



Figure 3: In LDP VPLS, adding a new site requires manual configuration on all existing member Pe routers to create a full mesh of pseudowires

In contrast, the BGP-VPLS control plane supports automatic discovery of all PE routers to which a customer’s sites are attached; the signaling component relies on this autodiscovery. Any addition or removal of a VPLS customer site requires configuration changes only on the PE router to which the site is added or from which it is deleted. The autodiscovery provided by BGP eliminates the need for any changes on other member PE routers of that VPLS customer (Figure 4).

PE1 PE4

PE5PE2

PE3 PE6

A6A3

A5A2

A4A1

PE7

A7

Manual configurationon all the member PEs

of VPLS Customer A

New site added Psuedowire



Figure 4: BGP autodiscovery automates the member Pe router discovery and requires provisioning only on the Pe router to which the site is added

Adding a new PE router in LDP VPLS requires a full mesh of targeted LDP sessions to be provisioned with all the other PE routers in the network. In contrast, the task of provisioning a new PE router in BGP VPLS is simplified using a route reflector hierarchy because only the BGP sessions with route reflectors need to be provisioned.

Flooding and BroadcastingFlooding and broadcasting operations using ingress replication in a large VPLS topology can be both resource intensive and bandwidth inefficient. These drawbacks are especially apparent on the first hop link from the PE router, which may have to bear the full burden of the replication (Figure 5).

Figure 5: resource-intensive flooding operation using ingress replication in which an ingress Pe router (Pe1) makes multiple copies of an incoming multicast packet to send it to each egress Pe router

Only PE7 needs configuring; all the member PEs of VPLS

Customer A are autodiscovered

PE1 PE4

PE5PE2

PE3 PE6

A6A3

A5A2

A4A1

PE7

A7New site added

To flood, multiple copies are made and forwarded to each member PE: PE1, PE2, PE3

Broadcast/Multicast Packet

PE2 A2

PE3P

To PE2

To PE2To PE3To PE4

To PE3

To PE4

PE1A1A3

PE4 A4



Point-to-multipoint (P2MP) label-switched paths (LSPs) introduce multicast to MPLS and enable several new services, such as the distribution of IP-based television (IPTV). Enhancements in BGP VPLS enable the use of a P2MP LSP VPLS-multicast (see Aggarwal, Kamite, and Fang, ND) for efficient and scalable flooding and broadcasting of VPLS traffic (Figure 6). Juniper Networks® Junos® operating system supports this functionality using RSVP-TE P2MP LSP, starting with Release 8.3.

While in principle LDP VPLS can also use P2MP LSP to scale the data plane, in practice no vendor has yet integrated these two technologies.

Figure 6: efficient flooding operation using P2MP LSP in which ingress Pe router (Pe1) forwards the multicast packet on P2MP LSP and may require replication at a router

Exchanging Pseudowire Signaling StateIn both LDP VPLS and BGP VPLS, for each VPLS customer, signaling updates are exchanged between each pair of member PE routers to create full-mesh connectivity in the data plane. The amount of signaling state that each PE router needs to maintain and to exchange with other PE routers increases as VPLS expands, both in terms of the number of VPLS customers and the number of member PE routers for each VPLS customer.

A single LDP-VPLS signaling update establishes only one pseudowire with one other PE router. In contrast, a single BGP-VPLS signaling update establishes pseudowires with multiple PE router peers. Consequently, in large VPLS networks, BGP VPLS requires far fewer signaling updates and therefore many fewer control plane messages than LDP VPLS to establish a full mesh of pseudowires between pairs of PE routers. Having fewer control plane messages reduces the control plane overhead on each PE router.

Inter–Autonomous System OperationsService providers are seeking mechanisms to extend VPLS beyond a single autonomous system (AS). In some cases, a service provider has multiple ASs because of acquisitions and mergers; in other cases, inter-AS operation is a consequence of inter-provider VPLS.

LDP VPLS faces the following challenges in providing VPLS across multiple ASs.

• LDP VPLS requires one of two setups. One is the setup of LDP sessions between PE routers that are in different ASs and therefore belong to different administrative entities, and possibly different providers. The other potential setup is the use of multisegment pseudowires, which has its own complexities.

• The globally significant 32-bit VCID used by LDP signaling requires operationally intensive manual coordination between ASs.

In contrast, in BGP VPLS the exchange of control traffic between ASs is localized to autonomous system border routers (the so-called option B) or route reflectors (option C), thus fostering tight control over the information exchanged and other factors, such as peer authentication. In addition, the use of the BGP route target constraint further simplifies the task of determining which VPLS networks cross the AS boundary (and to which peer AS) and which VPLS networks remain within the AS, thus facilitating exchange of control information across the AS boundaries. Though BGP VPLS also requires site identifier coordination between ASs, the challenges of this coordination can be mitigated using an autosite identifier.

To flood, packet forwarded over P2MP LSP

Broadcast/Multicast Packet

P2MP LSP created by PE1for VPLS Customer A

PE2 A2

PE3P

To PE2

To (PE2, PE3, PE4)

To PE4

To PE5

PE1A1A3

PE4 A4



Scaling Beyond a Single Metro AreaMany VPLS deployments are limited to a single metro area, primarily for fear of scaling to “MPLS in the large.” The concern is in dealing with a large number of PE routers and provider routers in a single domain and making these PE routers work together to offer VPLS. One potential challenge of scaling the overall network includes organizing the interior gateway protocol (IGP) and partitioning the control and administrative domains. Other challenges include the lack of adequate policy mechanisms to control which VPLS networks remain within a metro network and which should be intermetro networks.

One useful approach to connecting multiple metro networks and a wide-area backbone in a scalable fashion is to consider each metro network as a separate AS and the backbone as yet another AS. This approach enables independent management of each metro network and the backbone, while enabling the inter-AS control plane (BGP) to work seamlessly. This design also provides intermetro connectivity and intermetro VPLS. In this case, the techniques described in this document can be used to scale a VPLS network beyond a single metro network to connect a customer’s sites across the WAN. (Note, the process of connecting multiple metro networks and a wide-area backbone in a scalable fashion is outside the scope of this paper.)

Comparison of LDP-VPLS and BGP-VPLS Control Plane Scaling CharacteristicsThe signaling component of the BGP-VPLS control plane provides superior scaling characteristics in comparison with the LDP-VPLS signaling component. Moreover, the BGP-VPLS control plane inherently supports autodiscovery and uses route reflectors, both of which provide automation in deployment of

large-scale services, thereby reducing operating costs. Table 1 summarizes the LDP-VPLS and BGP-VPLS control plane scaling characteristics.

Table 1: Comparison of LDP-VPLS and BGP-VPLS Control Plane Scaling CharacteristicsCHARACTERISTIC LDP VPLS BGP VPLSFull-mesh requirement Alleviated only somewhat by

H-VPLS, though at the expense of introducing changes and additional overhead in the data plane

Solved by the use of BGP route reflector hierarchy

Provisioning task of adding or removing Pe router

Only somewhat simplified by H-VPLS

Highly simplified by use of route reflector

Provisioning task of adding or changing VPLS customer sites

Manual or through provisioning Automated by BGP’s autodiscovery

VPLS with P2MP LSP integration to scale forwarding and data planes

Currently not supported in any commercial implementation

Supported in standards and currently implemented

Signaling overhead Increases in proportion to the total number of pseudowires in the network

Minimal because each signaling update can be used to establish multiple pseudowires

Business Drivers for LDP-BGP VPLS InterworkingCurrently, both LDP VPLS and BGP VPLS are widely deployed in service provider networks. Two key business drivers for LDP-BGP VPLS interworking are the need to scale and to extend the VPLS networks.

Scaling the VPLS Network LDP VPLS works well for small-scale deployments. However, as the VPLS network expands, the LDP-VPLS control plane does not scale well. In comparison, the BGP-VPLS control plane more easily enables the VPLS network to scale to support new VPLS customers and to include more sites for existing VPLS customers.

One option for scaling the VPLS network when there is an existing LDP-VPLS deployment is to abandon the LDP-VPLS control plane entirely and transition the VPLS network to the BGP-VPLS control plane. However, this approach may not be feasible for a number of reasons, including the following two constraints.

• Legacy PE routers may not support a BGP signaling mechanism. To protect the current investment, replacing the existing PE routers may not be a viable option.

• Operating overhead and possible disruption to the VPLS network for existing customers may undermine a transition from the LDP-VPLS control plane to BGP VPLS.



Another option for scaling VPLS when there is an existing LDP-VPLS deployment is to cap the existing LDP-VPLS deployment and to expand the VPLS network using the BGP control plane. With this approach, both LDP- and BGP-VPLS control planes, including the signaling mechanisms, must coexist in the network, and there must be interworking between the two control plane mechanisms.

Extending the VPLS Network To be able to offer a regional or national VPLS network, service providers are seeking scalable ways to extend the reach of VPLS beyond a single LDP-VPLS metro domain. One mechanism is the use of BGP VPLS in the WAN to interconnect multiple LDP-VPLS metro domains. This approach requires a new interdomain technique because the currently defined solutions for multiple ASs require that all domains be running the same signaling protocol.

One of the critical requirements for such a deployment model is ensuring that the existing PE routers in the metro domains that are running the LDP-VPLS control plane do not require any changes or upgrades. A second requirement is the extension of VPLS without significant additional load on the control plane of the LDP-VPLS PE routers in the metro network.

The solution proposed in this paper meets the above requirements and enables service providers to use a single protocol, BGP, in the WAN to offer multiple MPLS VPN services, including VPLS and Layer 2 and Layer 3 VPNs. Moreover, because only a single protocol is used, provisioning the system can provide operating efficiency.

Scaling an LDP-VPLS Network Using BGP VPLSService providers can scale an LDP VPLS network by capping the existing LDP-VPLS deployment and expanding the VPLS network with a BGP-VPLS control plane. Figure 7 shows the reference topology used in the discussion of these mechanisms.

Figure 7: LDP-VPLS network reference topology for scaling methods using BGP-VPLS signaling

The following are deployment methods for scaling a LDP-VPLS network using a BGP-VPLS control plane:

• Basic LDP-BGP VPLS interworking

• Scalable LDP-BGP VPLS interworking wherein service providers can add redundancy to minimize VPLS network disruptions

PE1 (LDP)

PE2 (LDP)

A1

PE3 (LDP)

B2 A2

LDP session

B1



Basic LDP-BGP VPLS InterworkingWith basic LDP-BGP VPLS interworking, newly added PE routers in the network support both the LDP and BGP control planes, including the corresponding signaling mechanisms. These newly added PE routers use the BGP-VPLS control plane when communicating with each other, and use the LDP-VPLS control plane to communicate with the existing PE routers running LDP VPLS.

The topology in Figure 8 illustrates how to expand the LDP-VPLS network shown in Figure 7 using BGP signaling. The PE routers PE1, PE2, and PE3 are existing LDP-VPLS PE routers and communicate with the newly added PE routers using the LDP control plane. The newly added PE routers (PE4, PE5, and PE6) support both LDP and BGP control planes.

Figure 8: Scaling an existing LDP-VPLS network using the BGP-VPLS control plane

This deployment model facilitates expansion of existing VPLS customer sites, enabling a service provider to add new sites to BGP-VPLS PE routers while keeping the existing sites unchanged on the LDP-VPLS PE routers. For example, in Figure 8, VPLS Customer A’s new sites A3 and A4 are attached to the newly added PE routers PE4 and PE5, respectively, and the customer’s existing sites continue to be attached to the already deployed LDP-VPLS PE routers PE1 and PE3.

A key feature of this interworking mechanism is that no changes are made to the currently defined LDP-VPLS control plane (RFC 4762; see Lasserre and Kompella, Jan. 2007). The PE1, PE2, and PE3 routers continue to communicate using the LDP-VPLS control plane. From their perspective, the newly added BGP-VPLS PE routers (PE4, PE5, and PE6) are simply LDP-VPLS PE routers. The PE4, PE5, and PE6 routers, on the other hand, use both the BGP-VPLS and LDP-VPLS control planes. They use the BGP-VPLS control plane between them for autodiscovery and for signaling, establishing an internal BGP (IBGP) session between themselves. They also use LDP-VPLS signaling to communicate with the PE1, PE2, and PE3 routers, establishing LDP sessions with the existing PE routers.

For all VPLS customers that have sites only on either the existing LDP-VPLS PE routers or the newly added BGP-VPLS PE routers, VPLS is set up using only a single control plane and a single signaling protocol. For example, in Figure 8, VPLS for Customer B is set up using only the LDP-VPLS control plane and signaling, and VPLS for Customer C is set up using only the BGP-VPLS control plane and signaling.

LDP session

BGP session

PE1 (LDP)

PE2 (LDP)

PE3 (LDP)PE6 (BGP LDP)

PE5 (BGP LDP)

PE4 (BGP LDP)

RR

A2

B2C2

B1

A4

C1

A1A3



Pros and Cons of Basic LDP-BGP VPLS Interworking Table 2 is a summary of the pros and cons of this basic LDP-BGP VPLS interworking deployment model.

Table 2: Pros and Cons of Basic LDP-BGP VPLS Interworking Deployment ModelPROS CONS• No changes are required on existing LDP-VPLS PE

routers when the BGP-VPLS control plane is deployed to scale the VPLS network, thus protecting the current investment in existing LDP-VPLS PE routers.

• Existing VPLS customer service is not disrupted when the BGP VPLS is rolled out in the network.

• Each newly added PE router may need to be configured with a full mesh of targeted LDP-VPLS sessions to the existing LDP-VPLS PE routers. Hence, LDP-VPLS deployment is not completely capped because each new PE router that supports the BGP-VPLS control plane may also need to be set up for the LDP-VPLS control plane.

• Potentially increases the provisioning overhead because newly added PE routers need to be configured for two control planes instead of just one.

• For VPLS networks that span both LDP-VPLS PE routers and BGP-VPLS PE routers, each newly added BGP-VPLS PE router results in additional control plane load on the LDP-VPLS PE routers.

Scalable LDP-BGP VPLS Interworking Shortcomings of the previous method, which fails to cap the LDP-BGP VPLS deployment entirely, can be eliminated using a more scalable LDP-BGP VPLS interworking model. Such a model employs two groups of PE routers. All PE routers in the first group run only the LDP-VPLS control plane among themselves, whereas all PE routers in the second group run only the BGP-VPLS control plane among themselves. These two groups are interconnected through a single PE router, referred to as the interworking PE router, which runs both LDP-VPLS and BGP-VPLS control planes. Figure 9 illustrates how the LDP-VPLS network shown in Figure 7 is expanded using the BGP control plane in a scalable model.

Figure 9: LDP-BGP VPLS interworking

LDP session

BGP session

PE1 (LDP)Interworking

PE

PE2 (LDP)

PE3 (LDP)PE6 (BGP)

PE5 (BGP) PE7 (BGP LDP)

PE4 (BGP)

RR

A2

B2

C3

C2

B1

A4

C1

A1A3



In Figure 9, the PE1, PE2, and PE3 routers are existing PE routers supporting only the LDP-VPLS control plane. The newly added PE routers (PE4, PE5, and PE6) support the BGP control plane. The PE7 router is the interworking PE router, supporting both LDP and BGP control planes and the interworking between these two distinct control planes.

The existing LDP-VPLS PE routers and the newly added BGP-VPLS PE routers are isolated into two groups. The PE7 router is part of both groups and plays the vital role of interconnecting them. For example, VPLS Customer A has multiple sites in both the LDP- and BGP-VPLS groups. Customer A’s Site A1 and A2 are connected to the LDP PE routers, and Sites A3 and A4 are connected to the BGP PE routers. PE7 router provides the LDP-BGP VPLS interworking function and stitches the pseudowires created by the signaling components of the two different control planes.

• PE routers in the BGP-VPLS group are provisioned only for the BGP-VPLS control plane. From their perspective, the interworking PE router (PE7) is a standard BGP-VPLS peer, and they are unaware of the existence of the PE routers that are part of the LDP-VPLS group behind the interworking PE router.

• Legacy PE routers in the LDP-VPLS group are provisioned only for the LDP-VPLS control plane. From their perspective, the interworking PE router (PE7) is a standard LDP-VPLS peer, and they are unaware of the existence of the PE routers that are part of the BGP-VPLS group behind the router PE7.

Containing all the existing LDP-VPLS PE routers in a single group caps the LDP-VPLS deployment and allows network expansion to occur in the BGP-VPLS group without creating additional control plane or data plane overhead on existing LDP-VPLS PE routers. Moreover, this method eliminates a fundamental problem with the previous method: the requirement that all BGP-VPLS PE routers also operate in the LDP-VPLS control plane.

In some network designs, containing all the LDP-VPLS PE routers in a single group may not be feasible because of geographical limitations or other administrative reasons. In such environments, multiple groups of PE routers can be running the LDP-VPLS control plane and a single group of PE routers can be running the BGP-VPLS control plane, which interconnects all the LDP-VPLS control plane groups through multiple interworking PE routers as shown in Figure 10.

Figure 10: Multiple interworking Pe routers placed in the VPLS network to cap the LDP-VPLS deployment

LDP session

BGP session

PE1 (LDP)PE7 and PE8 areinterworking PEs

PE2 (LDP)

PE3 (LDP)PE6 (BGP)

PE5 (BGP)

PE4 (BGP)

PE9(BGP)

PE7(BGP LDP)

PE8 (BGP LDP)

RR

A2

B2

C3

C2

B1

A4

C1

A1

A5

A3



Redundancy in Scalable LDP-BGP VPLS Interworking This scalable model in which the BGP-VPLS signaling is added to an existing LDP-VPLS network provides scaling characteristics similar to those of a pure BGP-VPLS deployment, but suffers from lack of redundancy. Because only a single PE router connects the two groups of LDP-VPLS PE routers and BGP-VPLS PE routers, this router is a single point of failure, and any problem with this router can adversely affect service for many customers. To alleviate this problem, service providers can place redundant interworking PE routers in the network to avoid the problem of a single point of failure that could disrupt the VPLS network.

Figure 11 illustrates a redundancy scheme in the scalable deployment model. This topology shows two interworking PE routers (PE7 and PE8). At any given time, only one interworking PE router is designated to interconnect the LDP and BGP groups. For example, if router PE7 is elected to be a designated interworking PE router, PE8 is in a standby state. If any failures occur on router PE7, PE8 takes over as the designated interworking PE router.

Figure 11: redundancy in scalable LDP-BGP VPLS interworking

Note that no new mechanisms are needed to provide the redundancy for this scheme. The BGP-VPLS control plane defines the multihoming procedure for providing redundancy when a CE router is attached to multiple PE routers (see Kompella and Kothari, Nov. 2007). This same multihoming procedure is used to provide redundancy for scalable LDP-BGP VPLS interworking.

A key feature of this redundancy scheme is that no changes are required on the existing PE routers belonging to the LDP-VPLS group. From their point of view, the PE7 and PE8 routers are standard LDP-VPLS peers, and the existing PE routers are not aware of the redundancy provided by these two routers.

Designated interworking PE election is performed for each VPLS customer whose sites span the LDP and BGP-VPLS groups. The results of the election can be influenced by the configuration on the interworking PE routers so that VPLS customers can be load balanced across the redundant interworking PE routers.

LDP session

BGP session

PE1 (LDP)

PE8(BGP LDP)

PE7(BGP LDP)

PE2 (LDP)

PE3 (LDP)PE6 (BGP)

PE5 (BGP)

PE4 (BGP)

RR

A2

B2C2

B1

A4

C1

A1

C3

A3



Pros and Cons of Scalable, Redundant LDP-BGP VPLS InterworkingTable 3 is a summary of the pros and cons of the scalable LDP-BGP VPLS interworking model.

Table 3: Pros and Cons of Scalable, Redundant LDP-BGP VPLS Interworking Deployment ModelPROS CONS• No changes are required on existing LDP-VPLS PE

routers when the VPLS network is scaled using the BGP-VPLS control plane. Thus, the existing investment in existing LDP-VPLS PE routers is protected.

• For VPLS networks that span both LDP-VPLS PE routers and BGP-VPLS PE routers, each newly added BGP-VPLS PE router does not result in additional control plane load on the LDP-VPLS PE routers.

• PE routers in the BGP-VPLS group are configured to run only a single BGP-VPLS control plane. Thus, the scaling characteristics of such a deployment model approximate those of a pure BGP-VPLS deployment.

• PE routers in the BGP-VPLS group can use P2MP LSP technology for efficient flooding and broadcasting, whereas PE routers in the LDP-VPLS group continue to use ingress replication to deliver the traffic.

• Placing redundant interworking PE routers in the network creates a robust solution. No new protocols are required to affect the redundancy because the existing BGP-VPLS multihoming mechanism is used.

• Redundant interworking PE routers provide both load balancing and resiliency.

At any given time, only one interworking PE router carries the traffic from LDP VPLS to BGP VPLS, thus creating a choke point. One way to alleviate congestion at the choke point is to use different interworking PE routers for different VPLS. Then each VPLS uses only one interworking PE router, and not all VPLS use the same interworking PE router.

Interconnecting LDP- and BGP-VPLS DomainsThe term domain refers to an AS running a particular VPLS control plane technology. Each metro network is considered a separate AS.

Previous sections described various LDP-BGP VPLS interworking deployment models within a single metro network or AS with LDP-VPLS and BGP-VPLS control plane technologies both deployed. Service providers can, however, set up interdomain VPLS networks in which each domain is running a different VPLS control plane technology. The main application of such an interdomain scheme is expansion of the VPLS network beyond a single LDP-VPLS metro domain in the WAN. This deployment model, implemented using BGP VPLS, enables service providers to offer regional or national VPLS in a scalable fashion.

Two interdomains LDP-BGP VPLS interworking deployment schemes are as follows:

• Basic LDP-BGP VPLS interworking between two domains, where one domain uses LDP signaling and the other uses BGP signaling

• Interconnection of multiple LDP-VPLS domains using BGP-VPLS signaling



Basic Interdomain LDP-BGP VPLS Interworking SchemeFigure 12 shows the reference topology used in the discussion of interdomain LDP-BGP VPLS interworking. In this topology, Domain X is an LDP VPLS domain, and Domain Y is a BGP-VPLS domain. Two VPLS customers, A and B, have sites in both domains.

Figure 12: Basic interdomain LDP-BGP VPLS interworking

Domain Y’s AS border router (ASBR2) performs the LDP-BGP VPLS interworking to interconnect the two domains running different VPLS control planes. This border router is configured to run both control planes. ASBR2 is the only router in the topology that is aware that VPLS Customers A and B have sites in both domains.

This interdomain scheme is analogous to the single-domain scalable LDP-BGP VPLS interworking scheme previously discussed. ASBR2 is the equivalent of the interworking PE router, and the LDP- and BGP-VPLS domains are equivalent to the two groups containing the LDP-VPLS and BGP-VPLS PE routers.

The PE routers in BGP-VPLS Domain Y are provisioned only for the BGP-VPLS control plane. From their perspective, ASBR2 is a standard BGP-VPLS peer. The PE routers are not aware of the existence of LDP-VPLS Domain X behind ASBR2.

The PE routers in LDP-VPLS Domain X are provisioned only for the LDP-VPLS control plane and require minimal configuration changes to provision additional LDP sessions with ASBR2. From their perspective, ASBR2 is a standard LDP-VPLS peer. The PE routers are not aware of the existence of BGP-VPLS Domain Y behind ASBR2.

C-PE1

C-PE3

B2

A4

A1

L-PE1

C-PE2

L-PE2

RRASBR2

ASBR1

DOMAIN Y(BGP VPLS)

DOMAIN X(LDP VPLS)

A2B1

B3A3

Interdomain LDP-BGP VPLS interworking

LDP session

BGP session

C-PE = Core PE Router

L-PE = LDP-VPLS PE Router



Interconnecting and Extending VPLS for Multiple LDP-VPLS Domains Using BGP VPLS Interconnecting multiple metro networks using BGP VPLS is the most efficient and scalable way to extend VPLS beyond the metro network.

Figure 13 shows how basic interdomain LDP-BGP VPLS interworking techniques can be expanded to interconnect multiple LDP-VPLS domains using the BGP-VPLS control plane in the WAN. The existing PE routers in domains Metro X and Metro Y are not aware that the border routers C-ASBR1 and C-ASBR2 are extending their domain reach using the BGP-VPLS control plane in the WAN.

Figure 13: extending the reach of the LDP-VPLS metro domain to the wAn using the BGP-VPLS control plane

A single autonomous system border router (ASBR) can also be used to aggregate and interconnect several LDP-VPLS metro domains, thus extending the reach of all the domains in the WAN. In other words, a single ASBR can be used to extend the reach of multiple metro domains. Figure 14 illustrates such a scenario. In this topology, C-ASBR1 interconnects three VPLS domains: Metro X, Metro Y, and WAN. In addition, this ASBR extends the reach of all the domains to the WAN core by using BGP VPLS. This method provides seamless VPLS to Customer A, which has sites in domains Metro X, Metro Y, and WAN.

Figure 14: Interconnecting multiple LDP domains on a single ASBr and extending their reach to the wAn using the BGP-VPLS control plane

A4 A1B2

C-PE1

RR

C-ASBR2

M-PE2

B3

C-PE2

C-ASBR1

M-PE1

A3 A2B1

M-PE4

M-ASBR2 M-ASBR1

M-PE3

A5B4



METRO Y(BGP VPLS) METRO X

(LDP VPLS)WAN(BGP VPLS)

LDP sessionBGP session

METRO Y(BGP VPLS)

METRO X(LDP VPLS)

METRO Z(LDP VPLS)CORE

(BGP VPLS)

LDP sessionBGP session

A1A3

A5

A7

A6

A8

C-PE1

RR

C-ASBR1

M-PE6C-PE2

C-ASBR2

M-PE5

A4 A2M-PE4

M-ASBR2

M-ASBR1

M-ASBR3M-PE3M-PE2

M-PE1



C-ASBR1 forwards all VPLS traffic between Metro X and Metro Y.

The PE routers in the LDP-VPLS domains Metro X and Metro Y are provisioned for LDP VPLS, and no software upgrades are required on these routers. Only one configuration change is necessary to provision an additional LDP session with C-ASBR1. From the perspective of the PE routers in the LDP-VPLS domain, C-ASBR1 is a standard LDP-VPLS peer, and the PE routers are not aware that it directly or indirectly is interconnecting the local metro domain with other metro domains. No additional control plane or data plane overhead is placed on the existing PE routers, so this solution allows VPLS to scale across multiple geographical locations.

The PE routers in the BGP-VPLS domain (WAN) are provisioned only for BGP VPLS. From their perspective, C-ASBR1 is a standard BGP-VPLS peer, and the PE routers are not aware of the existence of either of the LDP-VPLS domains behind the ASBR.

In the WAN domain, multiple ASBRs can be used to directly or indirectly interconnect multiple geographically dispersed metro domains, thus facilitating a regional or national VPLS network. Metro domains can be set up using either the LDP-VPLS or the BGP-VPLS control planes. For BGP-VPLS metro domains, the multi-AS interdomain options suggested by RFC 4761 can be used (see Kompella and Rekhter, Jan. 2007). For LDP-VPLS metro domains, the LDP-BGP VPLS interworking scheme discussed in this section must be used.

The border router, which provides interworking between the LDP- and BGP-VPLS control planes, is the most critical element for providing an interdomain VPLS network for many customers. Any failure on the border router can constrain the scope of the VPLS network to a single domain, and thus can severely affect the interdomain VPLS network for many customers. To provide redundancy, multiple border routers can be placed in the network.

Redundancy in Interdomain LDP-BGP VPLS InterworkingFigure 15 illustrates the redundancy mechanism for interdomain LDP-BGP VPLS interworking. This redundancy scheme is the same as discussed for the scalable, redundant LDP-BGP VPLS interworking deployment.

Figure 15: redundancy in interdomain LDP-BGP VPLS interworking

CORE(BGP VPLS)

METRO X(LDP VPLS)

C-PE1

C-PE3

B2

A4

A1

M-PE1

C-PE2

M-PE2

RR

C-ASBR2

M-ASBR1

C-ASBR1

A2B1

B3A3

LDP-BGP VPLS Interworking

LDP session

BGP session



Following are the important points to note about the topology shown in Figure 15:

• The redundant ASBRs (C-ASBR1 and C-ASBR2) are placed in the network to ensure that VPLS is not affected if one of the ASBRs fails.

• Each LDP-VPLS domain is multihomed to both the redundant routers.

• Existing BGP-VPLS multihoming procedures provide the redundancy. At any time, only one ASBR is elected by the BGP-VPLS multihoming procedure as an interworking PE router for each VPLS customer that is part of an LDP-VPLS domain. The other ASBR is in a standby state.

• If the designated interworking PE router fails or disconnects from the LDP-VPLS domain, the standby ASBR becomes the designated interworking PE router.

This solution allows load balancing to occur between the redundant C-ASBR routers. Load balancing can be enabled so that different primary designated interworking PE routers are selected for different VPLS customers that have sites in multiple domains.

Simultaneously Providing LDP-BGP VPLS Interworking and PE Router Functionality One advantage of the interdomain interworking schemes discussed in this section is that they enable an ASBR to provide PE router functionality (that is, CE router attachment) at the same time that the ASBR is performing the LDP-BGP VPLS interworking task. Figure 16 illustrates the dual functionality. In this topology, Site B3 of VPLS Customer B is attached to the border router C-ASBR1 itself. The same VPLS customer also has Sites B1 and B2 in the LDP and BGP domains, respectively. Thus, for VPLS Customer B, C-ASBR1 simultaneously enables interdomain VPLS across the LDP and BGP domains and plays the role of PE router.

Figure 16: Ce device attached to border router

CORE(BGP VPLS)

METRO X(LDP VPLS)

C-PE1

C-PE3

B2

B3

A4

A1

M-PE1

C-PE2

M-PE2

RRM-ASBR1

C-ASBR1

A2B1

B3A3

[LDP-BGP VPLS Interworking + PE]

LDP session

BGP session



Pros and Cons of Interdomain LDP-BGP Interworking Table 4 is a summary of the pros and cons of the interdomain LDP-BGP VPLS interworking model.

Table 4: Pros and Cons of Interdomain LDP-BGP VPLS InterworkingPROS CONS• LDP-BGP VPLS interworking is achieved with just

localized changes on the ASBR. A single ASBR can be used to extend the VPLS network for multiple LDP-VPLS domains.

• Legacy PE routers in the LDP-VPLS domain require no changes except the addition of an LDP session to the ASBR.

• The number of LDP sessions and the pseudowire state in each LDP-VPLS domain remain approximately the same as when the VPLS network was limited to a single domain. Therefore, the control and data planes of the existing LDP-VPLS PE routers are unaffected when the VPLS network is expanded outside the domain.

When the WAN and metro domains are owned by different providers, ASBR ownership may be anissue because the C-ASBR router placed in the WAN is performing the critical task of LDP-BGP VPLS interworking. A possible solution is to have a metro ASBR perform the task of LDP-BGP VPLS interworking. This solution makes use of BGP-VPLS inter-AS options between the metro ASBR and WAN ASBR. (Details of such a solution are not discussed in this paper.)

Operational Details: LDP-BGP VPLS Interworking This section discusses the operation details for each of the previously described LDP-BGP VPLS interworking methods:

• Basic LDP-BGP VPLS interworking

• Scalable LDP-BGP VPLS interworking

• Basic interdomain LDP-BGP VPLS interworking

• Multiple LDP-VPLS domains interconnected using BGP VPLS

Operational Details: Basic LDP-BGP VPLS Interworking The basic LDP-BGP VPLS interworking method requires minimal configuration changes on the existing LDP-VPLS PE routers. However, new PE routers that are being added as part of the network expansion must support both LDP VPLS and BGP VPLS. The support on the new PE routers is the essence of what is needed for basic LDP-BGP VPLS interworking to succeed. Because the new PE routers support both LDP VPLS and BGP VPLS, they can establish pseudowires using both the LDP and BGP signaling mechanisms. These pseudowires can be created for VPLS customers with sites attached to both existing LDP-VPLS routers and the newly added BGP-VPLS routers.

A full mesh of pseudowires is created between the existing LDP-VPLS PE routers and the newly added BGP-VPLS PE router. As a result, data plane operations on all PE routers adhere to the split-horizon forwarding rule, and the VPLS traffic is not switched between pseudowires. Additionally, no changes are required to the existing LDP or BGP control plane procedures themselves.

Figure 8 illustrates the operation of the basic LDP-BGP VPLS interworking method. For the control plane on router PE4, both BGP VPLS and LDP VPLS are enabled for VPLS Customer A. For BGP VPLS, a unique route target (RT) is assigned for the customer that enables PE4 to autodiscover router PE5 and subsequently to establish a pseudowire with PE5 for Customer A. For LDP VPLS, on PE4 the identities of all the remote PE routers (PE1 and PE3) attached to the same customer must be configured. As a result, PE4 establishes LDP-VPLS pseudowires with PE1 and PE3. No changes are required in the VPLS forwarding plane operations on router PE4.

Operational Details: Scalable LDP-BGP VPLS Interworking Scalable LDP-BGP VPLS interworking entails dividing all PE routers of a VPLS network into two groups so that one group contains all the LDP-VPLS PE routers and the other group contains all the BGP-VPLS PE routers. One PE router, referred to as the interworking PE router, is part of both groups. All other PE routers can be part of only one group.

This method requires that only the interworking PE router supports and operates both the LDP-VPLS and BGP-VPLS control planes. All other PE routers support and operate only either the LDP-VPLS or BGP-VPLS control plane, depending on the group to which they belong.



Note that all PE routers in each group are fully meshed in the data plane using either the LDP- or BGP-based VPLS control plane. The interworking PE router interconnects the two fully meshed LDP-VPLS and BGP-VPLS groups to ensure that the VPLS network appears and functions the same as if all PE routers in the entire VPLS network were fully meshed.

For each VPLS customer with sites that span both the LDP-VPLS and BGP-VPLS groups, the interworking PE router creates LDP-VPLS pseudowires using LDP signaling in the LDP group, and it creates BGP-VPLS pseudowires using BGP-VPLS signaling in the BGP group. Then this router stitches the pseudowires created by LDP VPLS and BGP VPLS to provide seamless VPLS. (Note that if all sites of a VPLS customer are contained within a single group, an interworking function is not needed.)

Control Plane Operation of the Interworking PE RouterThis section describes the interworking mechanisms across signaling domains.

Mapping the Group of LDP-VPLS Pe routers to BGP-VPLS Signaling Figure 17 illustrates how an interworking PE router and other PE routers that are part of a BGP-VPLS group view an LDP-VPLS group attached to the interworking PE router. Conceptually, the interworking PE router and all the other PE routers in the BGP-VPLS group that are running BGP signaling view the LDP-VPLS group as a VPLS site with a single CE router.

Figure 17: Mapping the group of LDP-VPLS Pe fouters to BGP-VPLS signaling

On the interworking PE router, from the BGP-VPLS perspective, the LDP-VPLS group is analogous to a VPLS site with a single CE router. The LDP-VPLS group is mapped in BGP-VPLS signaling by assigning it a unique site identifier in that VPLS domain. The BGP-VPLS control plane uses this site identifier to create and advertise the VPLS network layer reachability information (NLRI) to all the other remote PE routers in the BGP-VPLS group. Each remote PE router uses this NLRI for both the autodiscovery and the signaling that set up the pseudowire between each PE router and the interworking PE router. The remote PE router treats the interworking PE router as a regular PE router and is not aware that the pseudowire set up with the interworking PE router connects the remote PE router to the LDP-VPLS groups. Therefore, this method does not require a full mesh of pseudowires between the PE routers in both the BGP-VPLS and LDP-VPLS groups. Furthermore, no changes in the BGP-VPLS control plane procedure defined by RFC 4761 are required.

PE1

PE2

A3 A1

PE5

PE4

A4 A2

PE3

Advertised BGPsignaling route

(Interworking PE)

LDP VPLS group appears as attached CE site from BGP signaling perspective

<Local site:1, Offset:1, Label base:800>

BGP VPLS LDP VPLS

BGP SITE ID:2

BGP SITE ID:1

BGP SITE ID:3

Attached CE device

BGP-VPLS pseudowire

LDP-VPLS pseudowire



The BGP-VPLS control plane defines the Layer 2 information extended community to communicate the operating status (active or inactive) of the attached CE router site to the remote BGP-VPLS peers. Because the LDP-VPLS group is equivalent to a CE router site, the BGP-VPLS control plane can also communicate the operating status of the LDP-VPLS group the same way it communicates the operating status of the attached CE router site. The interworking PE router computes the operating status of the LDP-VPLS group by examining the operating status of each LDP-VPLS pseudowire in the group.

Mapping the Group of BGP-VPLS Pe routers to LDP-VPLS SignalingFigure 18 illustrates how an interworking PE router and other PE routers in the LDP-VPLS group view the BGP-VPLS group attached to the interworking PE router. Conceptually, the interworking PE router and all the other PE routers in the LDP-VPLS group that are running LDP signaling view the BGP-VPLS group as a VPLS site with a single CE router.

Figure 18: Mapping the BGP-VPLS group in LDP-VPLS signaling

On the interworking PE router, from the LDP-VPLS perspective, the BGP-VPLS group is analogous to a CE device. Remote PE routers in the LDP-VPLS group view the interworking PE router as a standard LDP-VPLS PE router with an attached CE device. Therefore, for the entire BGP-VPLS group, only a single LDP session is required between the interworking PE router and each of the other LDP-VPLS routers in the LDP-VPLS group. For each VPLS customer with sites in the BGP-VPLS group, a single pseudowire is created between the interworking PE router and the LDP-VPLS routers in the LDP-VPLS group.

Viewing the BGP-VPLS group as an attached CE device is a key concept in allowing the VPLS network to scale without increasing the number of LDP sessions or pseudowires in the network. This view results in no changes in the LDP-VPLS signaling procedure defined in RFC 4762. Therefore, existing LDP-VPLS PE routers do not need to be upgraded when deploying such an interworking scheme.

Forwarding Plane Operation of the Interworking PE RouterFrom the control plane perspective, the BGP and LDP PE routers view each other as CE devices attached to the interworking PE router. Both routers establish both LDP and BGP pseudowires for each VPLS customer having sites in both the LDP- and BGP-VPLS groups.

For each VPLS customer with sites in both groups, the forwarding plane of the interworking PE router maintains a common MAC table. This table is critical because it is used for stitching pseudowires between the LDP- and BGP-VPLS groups. This common MAC table is populated by learning the source MAC addresses from the frames arriving on LDP- and BGP-VPLS pseudowires. The interworking PE router performs a destination MAC address lookup on each frame arriving over a pseudowire to determine the pseudowire on which to forward the frame. However, forwarding across pseudowires requires the following forwarding plane changes on the interworking PE router.

PE1

PE2

A3 A1

PE5

PE4

A4

A2

PE3

(Interworking PE)

LDP VPLS group appears as attached CE site from LDP-VPLS signaling perspective

BGP VPLS LDP VPLS

Attached CE device

BGP-VPLS pseudowire

LDP-VPLS pseudowire



In plain VPLS, forwarding traffic across pseudowires is prohibited by the split-horizon forwarding rule because of the assumption that all PE routers in the VPLS network are fully meshed in both the control and data planes. This assumption, however, is no longer correct in this LDP-BGP VPLS interworking scheme because LDP-VPLS PE routers and BGP-VPLS PE routers are not fully meshed in the control and data planes. In the entire VPLS network, only the interworking PE router is fully meshed with all other PE routers. Therefore, to connect the LDP-VPLS and BGP-VPLS groups, the interworking PE router allows VPLS traffic to be forwarded across pseudowires.

Because all PE routers of the LDP- and BGP-VPLS groups are fully meshed within their respective sets and interworking PE router, the interworking PE router needs to ensure that frames received over the pseudowire are not forwarded back to the same group from which they were received. To achieve this forwarding plane behavior, the concept of a mesh group is introduced on interworking PE routers. In the context of the VPLS forwarding plane, a mesh group is a collection of all the fully meshed pseudowires. Multiple mesh groups can be created on the interworking PE router: one for each fully meshed LDP or BGP group of pseudowires connected to it.

The split-horizon forwarding rule is modified so that it applies to each mesh group rather than to each of the individual pseudowires. The interworking PE router uses the MAC table to perform a destination MAC address lookup for each incoming frame and determines the pseudowire on which the frame should be forwarded. When the pseudowire is determined, the forwarding plane applies the mesh group split-horizon forwarding rule to ensure that packets are not forwarded back to the same group from which they were received.

In the topology in Figure 19, the interworking PE router (PE3) interconnects the LDP- and BGP-VPLS groups. All the routers in the BGP-VPLS group (PE3, PE4, and PE5) can exchange signaling information with each other through the route reflector hierarchy, and they are fully meshed in the data planes. Similarly, all routers in the LDP-VPLS group (PE1, PE2, and PE3) are fully meshed in the control and data planes. The forwarding plane of the interworking PE router maintains a MAC table to connect the two groups. Two mesh groups are created in the forwarding plane of the interworking PE router (PE3): one containing pseudowires of the BGP-VPLS group (with routers PE4 and PE5) and the other one containing pseudowires of the LDP-VPLS group (with routers PE1 and PE2).

The following example shows the application of the split-horizon rule for a mesh group. A frame received on PE3 over the LDP-VPLS pseudowire from PE1 will not be forwarded to PE2 LDP-VPLS pseudowire because the pseudowires to both the PE1 and PE2 routers are in the same mesh group. However, this frame can be forwarded on BGP-VPLS pseudowires to routers PE4 and PE5 if the destination MAC address is unknown or has been learned from one of the BGP-VPLS pseudowires.

Figure 19: Mapping of fully meshed BGP-VPLS and LDP-VPLS groups to a different mesh group on the interworking Pe router forwarding plane

PE1

PE2

A3 A1

PE5

PE4

A4

A2

PE3(Interworking PE)

BGP VPLS LDP VPLS

BGP-VPLS pseudowire

LDP-VPLS pseudowire

BGP-VPLS pseudowires (PE4, PE5) LDP-VPLS pseudowires (PE1, PE2)

BGP-VPLSmesh group

LDP-VPLSmesh group

Common MAC table



Following is a summary of forwarding plane operation on an interworking PE router:

• A MAC table is maintained to switch the traffic between the LDP- and BGP-VPLS groups.

• The VPLS split-horizon forwarding rule is relaxed to allow forwarding across pseudowires.

• The concept of a mesh group is introduced to group fully meshed pseudowires and to apply the split-horizon forwarding rule to each mesh group.

• The MAC address learning operation remains unchanged.

Note that these forwarding plane changes are localized to just the interworking PE router. All other PE routers in the BGP- and LDP-VPLS groups do not require changes to their forwarding plane operations.

Example of VPLS Forwarding Between LDP-VPLS and BGP-VPLS GroupsFigure 20 illustrates VPLS forwarding between an LDP-VPLS group and a BGP-VPLS group. In this topology, Customer A’s sites A1 and A2 are in the LDP-VPLS group and are attached to routers PE1 and PE2, respectively. Sites A3 and A4 are in the BGP-VPLS group, attached to routers PE4 and PE5, respectively.

Figure 20: example of VPLS forwarding between LDP and BGP groups

Looking at the interworking PE router, consider the control plane operation that creates the LDP- and BGP-VPLS pseudowires in the LDP and BGP groups. Suppose that routers PE1 and PE2 have an LDP session between them and establish a pseudowire with each other for Customer A, and suppose that routers PE4 and PE5 have a BGP session between them and establish a pseudowire with each other for the same Customer A. Because VPLS Customer A is part of both the LDP- and BGP-VPLS groups, the interworking PE router (PE3) is configured to establish an LDP VPLS pseudowire with PE1 and PE2. As well, the BGP-VPLS control plane of the interworking PE router autodiscovers that PE4 and PE5 are part of VPLS Customer A and establishes a BGP VPLS pseudowire with PE4 and PE5. The result is that the interworking PE router joins the fully meshed LDP and BGP groups for Customer A. Moreover, in the data plane, PE3 creates two mesh groups for VPLS Customer A. One mesh group contains the pseudowires for all BGP-VPLS PE routers (routers PE4 and PE5), and the other mesh group contains the pseudowires for all LDP-VPLS PE routers (PE1 and PE2).

PE4

PE5

PE1

PE3(Interworking PE)

BGP-VPLS pseudowires (PE4, PE5) LDP-VPLS pseudowires (PE1, PE2)

PE2

A3

BGP-VPLSmesh group

BGP VPLS LDP VPLS

A4

A1

A2

BGP-VPLS pseudowire

LDP-VPLS pseudowire

Path of flooded frame originated from site A1

Path of unicast frame originated from site A3

and destined to A1

LDP-VPLSmesh group



Now look at the interworking PE router data plane operation that connects the pseudowires of the LDP and BGP groups that have been established by the control plane. Suppose that Site A1 sends a frame whose destination MAC address is in Site A3, but none of the PE routers have learned that MAC address yet. As far as PE1 is concerned, the other sites of VPLS Customer A are connected to PE2 and PE3, so it floods the frame to these two routers. When PE3 receives the packet from Site A1, it floods the packet to PE4 and PE5 but not to PE2, in accordance with the mesh group split-horizon rule. Remember, this rule states that packets are not forwarded back to the same mesh group from which a packet is received. When PE4 and PE5 receive the frame forwarded by the interworking PE router, they forward it to Sites A3 and A4.

As a result of this process, each PE router that forwards the frame learns that the source MAC address carried in the frame is in Site A1 and updates its MAC table accordingly. If Site A3 subsequently sends a frame to that MAC address, the frame is forwarded as follows.

• PE4 performs a MAC lookup and forwards the frame on the pseudowire to PE3.


• PE1 performs a MAC lookup and forwards the frame on the attached CE router interface to A1.

Figure 21 shows the state of the MAC table on the interworking PE router after the VPLS frames have been exchanged between Sites A1 and A3.

Figure 21: Common MAC table state on interworking Pe router

Redundancy in Scalable LDP-BGP VPLS InterworkingThis section discusses how the currently defined BGP-VPLS multihoming procedure is used to provide resiliency in the scalable LDP-BGP VPLS interworking method. This procedure places multiple redundant PE routers in the network and configures redundancy for those VPLS customers desiring this service. Thereafter, the BGP-VPLS multihoming procedure ensures the following:

• No loops occur in the network and no duplicate packets are forwarded. For each VPLS customer, a single designated interworking PE router is elected to interconnect the two groups. The second redundant interworking PE router acts as a backup and does not participate in the VPLS forwarding.

• If the designated interworking PE router fails in any way, the backup interworking PE router is elected as the designated interworking PE router.

Note that a designated interworking PE router is elected for each VPLS customer and that the election can be influenced by the configuration. This flexibility enables BGP-VPLS multihoming procedures to provide load balancing along with much needed resiliency.

BGP-VPLS Multihoming In BGP VPLS, a CE device can be multihomed to multiple PE routers. Traffic to and from the CE device is forwarded only by the single PE router that has been elected as the designated forwarder (DF). All other PE routers that are connected to the multihomed CE router are marked as being in standby mode and do not participate in the traffic forwarding. Figure 22 illustrates a multihoming scenario in which the site containing router CE1 is multihomed to routers PE1 and PE2 for redundancy.

MAC AddressMAC (A1)

MAC (A3)

Next HopPseudowire (PE1)

Pseudowire (PE4)



Figure 22: BGP-VPLS signaling providing multihoming to the attached Ce device

The key to enabling multihoming is mapping the multihomed CE device to a BGP site using the same site identifier for all PE routers to which the CE device is connected. When the site identifier is the same, the PE routers all originate the same VPLS NLRI, and as a result all PE routers in the VPLS domain learn that the specific site is multihomed. For example, in Figure 22 CE1 is mapped to the site identifier 1 on both PE1 and PE2. Consequently, all PE routers that have that VPLS (PE1, PE2, and PE3) learn that a site with site identifier 1 is multihomed to PE1 and PE2. The next step is for all PE routers that have that VPLS to elect a single designated forwarder for the multihomed site, which is assigned a site identifier of 1.

For all PE routers in the network to elect the same PE router as a designated forwarder, they must use the same path selection procedure, as specified by the BGP-VPLS multihoming draft (see Kompella and Kothari, Nov. 2007) for each multihomed site. Moreover, if one wants to elect a particular PE router as the designated forwarder, the election mechanism can be influenced by assigning a higher local preference to the BGP-VPLS route originated for a multihomed site by that PE router.

In Figure 22, PE1 is configured with a higher local preference value (200), and is thus elected as the designated forwarder by all PE routers. To ensure that the VPLS domain has no loops, only PE1 handles traffic between the attached CE1 interface and the rest of the VPLS domain. Router PE2 marks the attached CE1 interface as administratively inactive and does not participate in forwarding for CE1.

If PE1 fails for any reason, the VPLS route advertised by PE1 is withdrawn, and PE2 is elected as the designated forwarder by all PE routers that have sites of that VPLS, thus providing redundancy. To speed up the process of re-election of a designated forwarder after such a failure, each PE router uses a distinct route distinguisher (RD) rather than using the same RD for all PE routers of a given VPLS. To be precise, any of the following failures in the topology just described cause a switchover.

• Access interface between CE1 and PE1 fails. If this occurs, BGP VPLS on PE1 advertises the operating status of the attached CE device as inactive and triggers the election of a new designated forwarder for the multihomed site.

• PE1 fails. This failure brings down the BGP session, which results in the withdrawal of all the VPLS routes advertised by PE1 and triggers the election of a new designated forwarder for the multihomed site.

Local preference:200PE1

DF for Site 1

<Local site:1, Offset:1, Label base:800, UP>


PE3CE2

PE2Local preference:100

CE1

BGP-VPLS pseudowirePath of VPLS traffic originating from CE1

Path of VPLS traffic destined for CE1

Link to CE1 marked Administrative Down

Backup for Site 1

BGP SITE ID:1



Interworking PE Router Redundancy for the LDP-VPLS Groups Using BGP-VPLS MultihomingIn the scalable interworking method, from the perspective of BGP VPLS, the LDP-VPLS group is equivalent to a CE device. In Figure 22, the CE device can be replaced with an LDP-VPLS group, and the routers PE1 and PE2 can be replaced with the redundant interworking PE routers, enabling redundancy in LDP-BGP VPLS interworking. This scenario results in the topology shown in Figure 23.

Figure 23: BGP-VPLS Signaling multihoming procedure providing redundancy to the LDP-VPLS group

The following requirements must be met to enable BGP-VPLS multihoming in LDP-BGP VPLS interworking scenarios:

• The LDP-VPLS group must be multihomed to redundant interworking PE routers. Thus, all PE routers that are part of the LDP-VPLS group must have LDP sessions with both the interworking PE routers. They must also establish pseudowires with both the interworking PE routers for each VPLS customer that has sites in both the LDP and BGP groups and that desires redundancy. For example, in Figure 23, for VPLS Customer A, PE4 establishes a pseudowire with both redundant interworking routers (PE1 and PE2).

• Each LDP-VPLS group must be associated with the same BGP-VPLS site identifier on all interworking PE routers. Different LDP-VPLS groups must have their own BGP-VPLS site identifiers on all the interworking PE routers. This step is essential because it enables the interworking PE router to notify all BGP-VPLS peers that the particular site, mapped to the LDP-VPLS group, is being multihomed. Consequently, a single designated interworking PE router is elected for each such site. For example, in Figure 23, for VPLS Customer A, the pseudowire that PE4 establishes with the redundant interworking routers PE1 and PE2 is mapped in BGP-VPLS signaling using the same site identifier, 1.

Figure 23 serves as a reference topology to demonstrate VPLS packet forwarding with redundant interworking PE routers. Suppose that PE1 is elected as the designated interworking PE router because a higher local preference value is assigned to the site to which the LDP-VPLS group is mapped. Also suppose that Site A1 sends a frame whose destination MAC address is in Site A2, but none of the PE routers have learned that MAC address yet. As far as PE4 is concerned, the only other sites of VPLS Customer A are connected to PE1 and PE2, so it floods the frame to these two routers. PE2 drops the frame because it is not a designated interworking PE router for the LDP-VPLS group for that customer. On the other hand, PE1, which is marked as a designated interworking PE router, floods the frame to both PE2 and PE3, as well as to the locally attached CE router site, A3. PE3, in turn, floods the frame to A2. Note that PE2 also floods the frame received from PE1 to its locally attached CE router site (A4). As a result


DF for Site 1<Local site:1, Offset:1, Label base:800, UP>


PE3A2

A3


PE4

BGP-VPLS pseudowire

LDP-VPLS pseudowire

Path of VPLS traffic originating from A1

Path of VPLS traffic destined for A1

Pseudowire to PE4 marked Administrative Down

Backup for Site 1

A1

A4

BGP SITE ID:1

BGP SITE ID:3

BGP SITE ID:4

BGP SITE ID:2

BGP VPLS LDP VPLS



of this process, each PE router that forwards the frame learns that the source MAC address in the frame is in Site A1 and updates its MAC table accordingly. If Site A2 subsequently sends a frame destined for that MAC address, it is forwarded as follows:



• PE4 performs a MAC lookup and forwards the frame on the attached interface to A1.

If any failures occur that disconnect PE1 from the LDP-VPLS group, PE2 advertises the LDP-VPLS group mapped site status as inactive, which causes all the BGP-VPLS peers to elect PE2 as a new designated interworking PE router. Figure 24 illustrates one such failure in which PE1 loses connectivity to all PE routers in the LDP-VPLS group. As a result, PE2 is elected as the new designated interworking PE router and handles the forwarding of traffic between A1 and A2.

Figure 24: Designated interworking Pe router becoming unreachable to the LDP-VPLS group

Operational Details: Basic Interdomain LDP-BGP VPLS InterworkingThe basic interdomain LDP-BGP VPLS interworking scheme is analogous to the scalable LDP-BGP VPLS interworking scheme. An ASBR in the BGP-VPLS group plays the role of the interworking device, and each LDP and BGP domain is the equivalent of separate groups of LDP- and BGP-VPLS PE routers in a single domain.

The operation details of basic interdomain LDP-BGP VPLS interworking are the same as discussed for scalable LDP-BGP VPLS interworking. To summarize, an ASBR between BGP-VPLS domains supports both the LDP- and BGP-VPLS signaling mechanisms and uses a common MAC table to stitch the pseudowire created between the domains. Multiple redundant ASBRs can be used for resiliency.

Reachability Between PE Routers and the Interworking RouterOne important aspect of network design for interdomain LDP-BGP VPLS interworking is ensuring that an interworking router can reach all PE routers in all parts of all domains. PE routers that belong to only a single domain must be able to reach all other PE routers and the interworking router.

Interworking router reachability to all PE routers in all domains can be achieved in numerous ways. Figure 25 depicts one approach, which protects each domain from the IGP churn in other domains. In this topology, for both scaling and administrative independence, the WAN and Metro X domains each have their own IGP instances, referred


Failure causing Site 1 to be unreachable<Local site:1, Offset:1, Label base:800, DOWN>


PE3A2

A3


PE4

BGP-VPLS pseudowire

LDP-VPLS pseudowire

Path of VPLS traffic originating from A1

Path of VPLS traffic destined for A1

New designated forwarder for Site 1

A1

A4

BGP SITE ID:1

BGP SITE ID:3

BGP SITE ID:4

BGP SITE ID:2

BGP VPLS LDP VPLS



to as IGP1 and IGP2, respectively. A third IGP instance, IGP3, is introduced between each metro domain and the WAN, thus creating a demilitarized zone (DMZ). The loopback addresses of the C-ASBR and the metro-PE (M-PE) routers must be leaked into and out of IGP3. BGP can be used in the DMZ.

Figure 25: reachability between the interworking router and all Pe routers of all LDP-VPLS domains

The C-ASBR must also establish transport tunnels with all PE routers in the Metro X domain and the WAN core. On the C-ASBR, a different transport tunnel technology can be used for different domains: for example, RSVP-TE in the WAN core and LDP in the metro domains.

Operational Details: Multiple LDP-VPLS Domains Interconnected Using BGP VPLS The methods discussed thus far require LDP and BGP interworking between only two islands, where each island can be a set of fully meshed PE routers or a separate domain. In contrast, the approach of interconnecting multiple LDP-VPLS domains using BGP VPLS allows an interworking router to interconnect a single BGP-VPLS domain and multiple LDP-VPLS domains. Therefore, the interworking router stitches not only LDP and BGP pseudowires, but also LDP pseudowires across multiple LDP-VPLS domains. This method requires subtle enhancements in the control and forwarding plane procedure defined for the scalable model.

Control Plane Enhancements Fundamentally, the control plane mechanism is the same as defined in the section “Control Plane Operation of the Interworking PE Router.” In essence, BGP VPLS and LDP VPLS each view each other as a logical CE device. However, this method has multiple fully meshed LDP-VPLS domains that are connected to the interworking router, unlike the scalable and basic interdomain methods that have only one fully meshed LDP-VPLS domain connected to the interworking router. Hence, on the interworking router, all the fully meshed domains need to be mapped to BGP-VPLS signaling. LDP-VPLS signaling also needs to map the BGP-VPLS domain and all other LDP-VPLS domains.

Multiple LDP-VPLS domains can be mapped to BGP-VPLS signaling in three ways:

• Consider all LDP-VPLS domains as a single logical CE device and then map all these domains to a single BGP site, which is assigned a single site identifier. This option is the most basic and is used when multihoming is not enabled.

• Consider each LDP-VPLS domain as a distinct logical CE device and then map each domain to a separate BGP site, with each site assigned a separate site identifier. This option is used when multihoming needs to be enabled for all LDP-VPLS domains.

• Use a combination of the above two options, with some LDP-VPLS domains grouped and mapped to a single site, and other LDP-VPLS domains treated as a separate logical CE device. This option allows multihoming to be enabled selectively only for some domains.

Having multiple options provides multihoming functionality at the granularity of a single LDP-VPLS domain. This behavior is consistent with the way BGP VPLS allows the mapping of multiple real CE devices.

C-PE1

C-PE2

M-PE1

M-PE2

A3

A4

A1

A2

BGP-VPLS pseudowire

C-ASBR loopback address

M-PE loopback address

DMZ (IGP3)

IGP1

IGP2

METRO X(LDP VPLS)

CORE(BGP VPLS)

No leaking needed

LDP-VPLS pseudowire

C-ASBR M-ASBR



Forwarding Plane EnhancementsFor interconnection of multiple LDP-VPLS domains using BGP VPLS, the key aspects of the forwarding plane on the interworking device remain the same: a common MAC table is used, and mesh groups are used for split-horizon forwarding. However, unlike the scalable and basic interdomain LDP-BGP VPLS interworking methods, in which two mesh groups are sufficient, for this method the interworking router supports multiple mesh groups. Each LDP-VPLS and BGP-VPLS domain is mapped to a unique mesh group because each domain is fully meshed. This mesh group provides a mechanism for grouping fully meshed pseudowires and enforcing the split-horizon forwarding rule within a single domain.

Figure 26 shows the forwarding plane behavior. Suppose that Site A1 sends a frame whose destination MAC address is Site A5, but none of the PE routers have yet learned that MAC address. As far as M-PE1 is concerned, the other sites of Customer A’s VPLS are connected to M-PE2 and C-ASBR1, so M-PE1 floods the frame to M-PE2 and C-ASBR1. C-ASBR1 floods the frame to M-PE3, M-PE4, and C-ASBR2 because they are all in different mesh groups from M-PE1, but it does not forward the frame to M-PE2 because both M-PE1 and M-PE2 are in same mesh group. C-ASBR2 subsequently forwards the frame to M-PE5 and M-PE6. When M-PE5 receives the frame, it forwards it to Site A5.

Figure 26: Interconnecting multiple LDP-VPLS domains

As a result of this process, each PE router that forwards the frame learns that the source MAC address of the frame is in Site A1 and updates its MAC table accordingly. If Site A5 subsequently sends a frame to that MAC address, the frame is forwarded as follows:

• M-PE5 performs a MAC lookup and forwards the frame on the pseudowire to C-ASBR2.

• C-ASBR2 performs a MAC lookup and forwards the frame on the pseudowire to C-ASBR1.

• C-ASBR1 performs a MAC lookup and forwards the frame on the pseudowire to M-PE1.

• M-PE1 performs a MAC lookup and forwards the frame on the attached interface to A1.

The following forwarding path is taken for the frames originating from Site A4 and destined to Site A1. Sites A4 and A1 are located in adjacent LDP-VPLS domains interconnected by C-ASBR1.

A4 → M-PE4 → C-ASBR1 → M-PE1 → A1

M-PE5

M-PE6

M-PE1

C-ASBR2 C-ASBR1

A5

A6

A1

M-PE2

A2

Path of flooded frame originating from A1

Path of unicast frame from A5 to A1

Path of unicast frame from A4 to A1

BGP-VPLS pseudowire

LDP-VPLS pseudowire

MG = Mesh group



METRO Z

METRO X

BGP SITE ID:1

BGP SITE ID:2

WAN

METRO Y

M-PE3 A3

M-PE4

A4

MG: Metro A

MG: Metro B

MG: Metro C



Multihoming Multiple LDP-VPLS DomainsFigure 27 shows two LDP-VPLS domains (Metro X and Metro Y), both multihomed to routers C-ASBR1 and C-ASBR2.

Figure 27: Multihoming multiple LDP-VPLS domains

One simple but powerful aspect of BGP-VPLS signaling that enables multihoming for each LDP-VPLS domain is the capability to map each LDP-VPLS domain to a separate site that is assigned a unique site identifier. This process results in generation of a unique VPLS signaling route for each such LDP-VPLS domain. The process is repeated on each PE router to which the multihomed site is attached. Therefore, all the peers in the BGP-VPLS domain learn about each multihomed site and elect a single designated interworking border router, which is responsible for forwarding traffic to and from the multihomed site mapped in that LDP-VPLS domain.

In the topology in Figure 27, the LDP-VPLS domains Metro X and Metro Y are multihomed to C-ASBR1 and C-ASBR2. On C-ASBR1 and C-ASBR2, for VPLS Customer A, these two LDP-VPLS domains are mapped to BGP-VPLS signaling using the same site identifiers, 1 and 2, respectively. C-ASBR1 and C-ASBR2 advertise the same VPLS routes for each of the two site identifiers. Because C-ASBR1 is configured with a higher local preference value for LDP-VPLS domain Metro X, it is elected as the designated interworking border router for LDP-VPLS domain Metro X. Because C-ASBR2 is configured with a higher local preference for LDP-VPLS domain Metro Y, it is elected as the designated interworking border router for LDP-VPLS domain Metro Y.

One question that arises is how does interdomain forwarding between Metro X and Metro Y occur when Metro X and Metro Y have different designated interworking borders routers, C-ASBR1 and C-ASBR2, respectively. The answer is that forwarding between the two LDP-VPLS domains occurs using the BGP-VPLS pseudowire in the WAN that is set up between the two border routers.

Suppose that Site A1 sends a frame whose destination MAC address is in Site A4, but none of the PE routers have yet learned that MAC address. As far as M-PE1 is concerned, the other sites of VPLS Customer A are connected to M-PE2, C-ASBR1, and C-ASBR2, so M-PE1 floods the frame to M-PE2, C-ASBR1, and C-ASBR2.

C-ASBR2 drops the received frame because it is not the designated interworking border router for the LDP-VPLS domain Metro X. C-ASBR1 floods the frame to C-ASBR2 and C-ASBR3 because they are all in different mesh groups than M-PE1. However, C-ASBR1 does not forward the frame to M-PE3 and M-PE4 because C-ASBR1 is not a designated forwarder for Metro Y. C-ASBR2 subsequently forwards the frame to M-PE3 and M-PE4. When M-PE4 receives the frame, it forwards it to A4.

C-ASBR2 (Designated: Site ID 2)

(Designated: Site ID 1)C-ASBR1

Local preference: Site 1:100, Site 2:200

Local preference: Site 1:200, Site 2:100

M-PE5

M-PE6

M-PE1

C-ASBR2

A5

A6

A1

M-PE2

A2

Path of flooded traffic originating from A1

Path of unicast VPLS traffic from A5 to A1

Path of unicast VPLS traffic from A4 to A1

BGP-VPLS pseudowire

LDP-VPLS pseudowire

METRO Z

METRO XBGP SITE ID:3

WAN

METRO Y

M-PE3 A3

M-PE4

A4

BGP SITE ID:1

BGP SITE ID:2


2000282-002-EN Oct 2010

Copyright 2010 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

EMEA Headquarters

Juniper Networks Ireland

Airside Business Park

Swords, County Dublin, Ireland

Phone: 35.31.8903.600

EMEA Sales: 00800.4586.4737

Fax: 35.31.8903.601

APAC Headquarters

Juniper Networks (Hong Kong)

26/F, Cityplaza One

1111 King’s Road

Taikoo Shing, Hong Kong

Phone: 852.2332.3636

Fax: 852.2574.7803

Corporate and Sales Headquarters

Juniper Networks, Inc.

1194 North Mathilda Avenue

Sunnyvale, CA 94089 USA

Phone: 888.JUNIPER (888.586.4737)

or 408.745.2000

Fax: 408.745.2100

www.juniper.net

Printed on recycled paper

To purchase Juniper Networks solutions, please contact your Juniper Networks representative at 1-866-298-6428 or authorized reseller.

As a result of this process, each PE router that forwards the frame learns that the source MAC address of the frame is A1 and updates its MAC table accordingly. The following forwarding path is taken for the subsequent frames sent from A4 to that MAC address.

A4 → M-PE4 → C-ASBR2 → C-ASBR1 → M-PE1 → A1

By using the third option, mapping LDP-VPLS domains in BGP VPLS, a network design is feasible in which some LDP-VPLS domains are multihomed while others are single homed. When multihoming LDP-VPLS domains, the local preference value is used for load balancing VPLS customers across multiple, redundant border routers. For a multihomed VPLS customer with sites in multiple LDP-VPLS domains, the local preference value is used for load balancing LDP-VPLS domains across multiple border routers. This multihoming solution can be scaled to interconnect multiple LDP-VPLS domains.

ConclusionJuniper Networks is committed to VPLS development so that service providers can interoperate and interwork with other VPLS implementations through simpler VPLS configurations that are less error prone. The Juniper Networks® LDP-BGP VPLS interworking solutions allow large enterprises, telcos, and cable companies to roll out and scale managed VPLS networks. These solutions offer minimal disruption, maximum scalability and cost efficiency, and extended reach across metro areas, regionally, nationally, and internationally. For further information, refer to other documents on www.juniper.net.

References

R. Aggarwal, Y. Kamite, and L. Fang. Multicast in VPLS. draft-ietf-l2vpn-vpls-mcast-03.txt. ND.

K. Kompella. Layer 2 VPNs over Tunnels (work in progress). Jan. 2006.

K. Kompella and B. Kothari. Multihoming in BGP Virtual Private LAN Service (work in progress). Nov. 2007.

K. Kompella and Y. Rekhter. Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling, RFC 4761. Jan. 2007.

M. Lasserre and V. Kompella. Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, RFC 4762. Jan. 2007.

L. Martini, E. Rosen, N. El-Aawar, T. Smith, and G. Heron. Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP), RFC 4447. Apr. 2006.

E. Rosen and Y. Rekhter. BGP/MPLS IP Virtual Private Networks (VPNs), RFC 4364. Feb. 2006.

About Juniper NetworksJuniper Networks, Inc. is the leader in high-performance networking. Juniper offers a high-performance network infrastructure that creates a responsive and trusted environment for accelerating the deployment of services and applications over a single network. This fuels high-performance businesses. Additional information can be found at www .juniper .net.

Documents

LDP-BGP VPLS Interworking