19531 Resilient HVPLS An

Application Note

Resilient Inter-Metro Hierarchical VPLS

TABLE OF CONTENTS

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

An Application of Hierarchical VPLS . . . . . . . . . . . . . . . . . . . 1

Spoke Redundancy Using VPLS-RSTP . . . . . . . . . . . . . . . . . . 2

Multi-City Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Multi-City Interconnection over Non-M-VPLS Transit Networks . . . . . . . 4

Multi-City Interconnection over M-VPLS Enabled Transit Networks . . . . . 5

Network Planning Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Management VPLS Configuration and Monitoring . . . . . . . . 6

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Introduction

One of the most active areas of innovation in telecom-munications over the last several years has been thedevelopment of new solutions for delivering virtualprivate network (VPN) services over a shared networkinfrastructure. VPN services have been successfullydeployed in carrier networks using TDM, frame relay,ATM and more recently MPLS. One of the new MPLS-based VPNs being deployed is called virtual private LANservice (VPLS). VPLS is a multipoint Layer 2 VPN tech-nology that uses MPLS tunnels to interconnect theprovider edge (PE) devices.

With VPLS, a Layer 2 VPN can be built over a serviceprovider’s network that interconnects a customer’s sitesas if they were connected to the same LAN. A full meshof MPLS label switched paths (LSPs) is establishedbetween the PE devices within the service provider’snetwork, carrying the pseudowires that interconnect the VPLS service instances on each of the PE devices.Once a VPLS service has been configured, traffic can be sent over the service as is done in a standard LANenvironment: broadcast, multicast and unknown MACaddress traffic is simply flooded on every pseudowireassociated with the VPLS service.

Since VPLS is based on MPLS LSPs, it inherits theresiliency and traffic engineering capabilities of MPLS.When combined in the network with a platform that hasa service-oriented architecture, such as the Alcatel 7450Ethernet Service Switch (ESS), the service provider cancreate superior VPLS-based Layer 2 VPN services for its

customers. The customer receives a service that is highlyreliable and consistently meets the desired service levels.The service provider’s network is cost-optimized bothfrom a capital and operational perspective; is highlyscalable, able to support thousands of customer servicesinstances; and it provides the network operator with thequality of service and service assurance tools necessaryto meet the customer’s service level agreement (SLA).

An Application of Hierarchical VPLS

Since its initial definition, VPLS has been enhanced withextensions that improve its scalability. These extensionsprovide mechanisms to create hierarchy within a VPLSservice instance. The extended solution is called hierar-chical VPLS (H-VPLS). H-VPLS introduces a new type of pseudowire known as a spoke pseudowire. Theseenhancements simplify deployment of a VPLS service by significantly reducing the degree of pseudowire meshrequired. They also distribute the replication of broad-cast, multicast and flooded packets over the PE devicesin the network.

H-VPLS extensions have created opportunities forinteresting applications. One of these applications is to interconnect geographically dispersed VPLS servicedomains belonging to the same customer (see Figure 1).In this scenario, a single customer has several officeslocated in two or more cities and would like to intercon-nect all sites together with a single Layer 2 VPN.


A L C AT E L > 1

MTU Device

Spoke

MPLS Transit Network

Full Mesh

IP/MPLS Metro

Network

IP/MPLS Metro

Network

Full Mesh

Figure 1 - H-VPLS Interconnection of Two Geographically Separated Networks

Connectivity could have been achieved without H-VPLS,but this would have required a large number of meshpseudowires in order to create the required mesh. H-VPLSsimplifies the network significantly. The multitenant unit(MTU) devices are connected to the Alcatel 7450 ESS(PE) nodes via H-VPLS spoke pseudowires. By using H-VPLS for these MTU-PE connections, there is only one pseudowire per MTU-7450 ESS.

The Alcatel 7450 ESS nodes interconnecting the two metro networks over the transit network are alsoconnected via spoke pseudowires. Again, using H-VPLSfor these connections means that only one pseudowire is needed between the nodes forming the inter-metroconnection.

However, while connectivity has been achievedbetween the VPLS instances in the two cities, there isobviously a single point of failure in this network. Toresolve this, a second spoke pseudowire can be added to the network as shown in Figure 2.

Due to the packet forwarding behavior defined forspoke pseudowires and the fact that VPLS is fundamen-tally a Layer 2 technology, this creates an unbroken loopin the customer’s VPN. Alcatel has developed an innova-tive approach to solve this problem using an enhancedversion of the rapid spanning tree protocol — VPLS-RSTP. The implementation of VPLS-RSTP on the 7450ESS has been optimized in an interoperable fashion toimprove the convergence times of the protocol in thisapplication.

Spoke Redundancy Using VPLS-RSTP

Consider Figure 3 below. VPLS-RSTP runs on a set ofmanagement VPLS (M-VPLS) instances located on thePE devices that are at the endpoints of the loop. Thiscollection of M-VPLS instances is known as a manage-ment VPLS domain (nodes A, B, C and D in Figure 3).The sole purpose of the M-VPLS instances is to removethe loop in the network caused by the spoke pseudowires— the M-VPLS instances do not carry customer traffic.Shown in the figure are four M-VPLS entities, each withan associated VPLS-RSTP instance. The four M-VPLSinstances are interconnected in a loop that is identical intopology to the loop between the customer VPLS instances.

VPLS-RSTP is run among the M-VPLS instanceslocated on the four Alcatel 7450 ESS nodes. VPLS-RSTPwill detect a loop in the M-VPLS domain and, based onthe priority of the M-VPLS spoke pseudowires (whichlook to RSTP like interfaces), put the M-VPLS and all ofthe customer spoke pseudowires that traverse the sametransit tunnel LSP between the PE devices into a blockingstate, thus breaking the loop as shown in Figure 4. Theforwarding databases of the affected customer VPLSinstances are flushed in order to facilitate transition of the traffic to the available pseudowires.


2 < A L C AT E L

MTU Device

Spoke

MPLS Transit Network

Full Mesh

IP/MPLS Metro

Network

IP/MPLS Metro

Network

Full Mesh

C

A

D

B

Figure 2 - Redundant H-VPLS Interconnection of Two Geographically Separated Networks


A L C AT E L > 3

Customer VPLS Instance

7450 ESS - C

RSTP

7450 ESS - A

RSTP

7450 ESS - B

RSTP

7450 ESS - D

RSTP

M-VPLS Domain

M-VPLS

M-VPLS

M-VPLS

M-VPLS

U-VPLS

U-VPLS

U-VPLS

U-VPLS

U-VPLS

U-VPLS

Transit Tunnel 1

Transit Tunnel 2

Figure 3 - Management VPLS for H-VPLS Spoke Redundancy

Customer VPLS Instance

7450 ESS - C

RSTP

7450 ESS - A

RSTP

7450 ESS - B

RSTP

7450 ESS - D

RSTP

M-VPLS Domain

M-VPLS

M-VPLS

M-VPLS

M-VPLS

U-VPLS

U-VPLS

U-VPLS

U-VPLS

U-VPLS

U-VPLS

Transit Tunnel 1

Transit Tunnel 2

Figure 4 - Layer 2 Topology Loop Removed by VPLS-RSTP

VPLS-RSTP will continue to monitor the state of theconnections between the four M-VPLS instances andshould a failure involving transit tunnel 2 occur, thecustomer spoke pseudowires (on transit tunnel 1) wouldbe re-enabled and the protected services would continueto operate normally. Because VPLS-RSTP is used to enableresiliency in these spokes and the topology is simple, the switchover time in the event of a failure would besimilar in magnitude to SONET/SDH automatic protectionswitching (APS) switchover times.

Another important characteristic of M-VPLS instancesis that they do not interact with customer VPLS instances.This means that it is safe to run spanning tree protocolinstances in the customer domain to detect loops causedby back paths in the customer network since there is nointeraction with the spanning tree instance running inthe M-VPLS domain.

Multi-City Interconnection

To this point, the discussion has focused on the use ofspoke pseudowires and management VPLS domains torobustly interconnect two separate VPLS service domainsbelonging to a single customer. The solution described

above is generalized to allow the interconnection of anarbitrary number of VPLS service domains belonging to the same customer over a transit network. There aretwo different approaches that can be taken to implementredundant connectivity for these service domains; whichapproach is used is driven by whether the transit networkis M-VPLS enabled. Both solutions are explained below.For the purposes of illustration, the solution descriptionsthat follow assume that there are three customer VPLSdomains to be interconnected (as shown in Figure 5) butthe solution can be extended to any number of domains.

MULTI-CITY INTERCONNECTION OVER NON-M-VPLS TRANSIT NETWORKSInterconnection of the customer domains over a non-M-VPLS-enabled transit network is accomplished bycreating a full mesh of paired spoke pseudowires amongthe Alcatel 7450 ESS nodes that form the border betweenthe individual service domains and the transit network(nodes labeled A-F in Figure 5). For the same reasonsdescribed earlier in the two-domain scenario, thisconnectivity model, while resilient, introduces a Layer 2loop in the customer’s VPLS service.

M-VPLS, in combination with VPLS-RSTP, is used toresolve the Layer 2 loops in the same fashion as described


4 < A L C AT E L

MTU Device

Paired SpokePseudowires

MeshPseudowireRemoved MPLS Transit

NetworkIP/MPLS Metro

Network

IP/MPLS Metro

Network

IP/MPLS Metro

Network

C

A

D

E F

B

Figure 5 - VPLS Domain Interconnection via a Non-M-VPLS Transit Network

and illustrated in Figures 3 and 4. This is accomplishedby creating three different M-VPLS domains as follows:> M-VPLS:1 – consisting of nodes A, B C and D> M-VPLS:2 – consisting of nodes A, B, E and F> M-VPLS:3 – consisting of nodes C, D, E and F

In each of these individual M-VPLS domains, VPLS-RSTPwill detect a loop within its domain and put all thecustomer spoke pseudowires traversing the same transittunnel LSP as the lowest priority M-VPLS spoke pseudowirein a blocking state. This resolves the loops within each of the individual M-VPLS domains, but because each M-VPLS domain operates independently from its peers it does not necessarily completely resolve the issue. In order to guarantee loop-free connectivity, the meshpseudowire normally present between the two bordernodes within each customer VPLS domain (nodes A and B in Figure 5) must not be present.

MULTI-CITY INTERCONNECTION OVER M-VPLS ENABLED TRANSIT NETWORKSWhen the customer VPLS domains in multiple cities areinterconnected by an M-VPLS-enabled transit network, a more scalable solution is possible. In this configurationthe individual VPLS domains are redundantly connected

to a VPLS full mesh that is situated in the transit network,thus creating hierarchy. Consider Figure 6. As with theprevious redundant connection scenarios, this inter-connection model results in a Layer 2 loop among thenodes at the edge of the customer’s service domain andthe nodes in the transit network to which the edge nodesare connected (for example, nodes A, B, C-1 and C-4 inFigure 6). As with previous scenarios, M-VPLS domainsare used to resolve these loops. The primary differencewith this approach is that the number of M-VPLS domainsand spoke connections grows linearly with the number ofVPLS clouds being interconnected over the transit network.

Placement of the M-VPLS instances in thisconfiguration is as follows:> M-VPLS:1 – consisting of nodes A, B, C-1 and C-4> M-VPLS:2 – consisting of nodes E, F, C-3 and C-4> M-VPLS:3 – consisting of nodes C, D, C-2 and C-3

As in previous configurations the individual M-VPLSdomains will detect the loop within its domain and put all the customer spoke pseudowires traversing the sametransit tunnel LSP as the lowest priority M-VPLS spokepseudowire in a blocking state, resolving the loops withineach of the individual M-VPLS domains.


A L C AT E L > 5

MTU Device

Full MeshVPLS in Transit

Network

Spoke VCs

M-VPLS EnabledTransit Network

IP/MPLS Metro

Network

IP/MPLS Metro

Network

IP/MPLS Metro

Network

C

C-3C-4

C-2C-1A

D

E F

B

Figure 6 - VPLS Domain Interconnection via an M-VPLS Transit Network

Network Planning Notes

There are a number of different network planningconsiderations that must be taken into account whendeploying H-VPLS in this fashion. These include:> The number of management VPLS domains and

instances required> Placement of pseudowires used to redundantly inter-

connect customer VPLS instances over transit tunnels> Placement of pseudowires related to singly connected

VPLS instances> Load balancing of customer traffic over the links

interconnecting the VPLS domains

A single management VPLS domain provides redundantconnectivity for any number of individual customer VPLS instances that are connected by redundant spokepseudowires. Because each transit tunnel carriespseudowires belonging to many different customer VPLS instances, a single M-VPLS domain removes theloop present in each customer VPLS service. There are a number of positive side effects to this behavior:> Only one M-VPLS instance needs to be configured

and monitored on each Alcatel 7450 ESS to removethe redundancy in multiple customer VPLS services.

> Failure recovery times are very short for each customerservice instance because only one M-VPLS instancehas to reconverge after a failure.

The resources consumed by M-VPLS (link bandwidth and switch resources) are minimal.

When configuring an Alcatel 7450 ESS-based network

that contains a physical loop, it is important to carefullyplan where the pseudowires for the various services in the network will be placed. Through configuration, the network operator has complete control over the setof customer spoke pseudowires that will be disabled.Pseudowires that belong to redundantly connectedcustomer VPLS instances must traverse the same set of transit tunnels that carry the M-VPLS domain spokes.If the services are not deployed this way, one or more ofthe customer VPLS domains will contain a Layer 2 loop,which will have a very negative effect on the network asa whole.

If there are customer VPLS instances present in thenetwork that are interconnected across a transit area in a non-redundant fashion, it is important that they usedifferent transit tunnels in order to prevent them frombeing unintentionally blocked. If this design principle is not followed, services will be disabled until theirpseudowires can be moved to the appropriate spoke.

Load sharing of customer traffic over the links thatprovide the interconnection between the customer H-VPLS domains can also be accomplished. To achievethis, an additional set of M-VPLS domains are added tothe nodes involved in connecting the separated VPLSclouds. For example, in Figure 6 an additional M-VPLSdomain can be created over the set of nodes A, B, C-1and C-4 (call the two domains M-VPLS-1a and M-VPLS-1b).Through configuration, the operator forces the M-VPLSinstances to disable different spokes. In M-VPLS-1a thecustomer spokes between nodes A and C-1 are disabled;similarly in M-VPLS-1b, the customer spokes between B and C-4 are disabled, resulting in load sharing over the interconnecting links.


6 < A L C AT E L

Management VPLS Configuration and Monitoring

Configuration of a management VPLS instance is a straightforward process. On each Alcatel 7450 ESS node deployedat the boundary of the transit network (devices A, B, C and D in Figure 2) a management VPLS instance is created asshown in the example below.

nodeA> configure servicenodeA>config>service# vpls 100 customer 1 m-vpls create /* creates the m-vplsnodeA>config>service# vpls 100nodeA>config>service>vpls# spoke-sdp 100:100 create /* creates a spoke VCnodeA>config>service>vpls# mesh-sdp 300:100 create /* creates a mesh VC

Repeating these commands on the remaining three nodes (B, C and D) completes the configuration of the M-VPLS.Rapid spanning tree will automatically detect the loop in the M-VPLS domain and block the appropriate set ofcustomer spoke pseudowires. (Note that in the CLI examples below a spoke pseudowire is referred to as a “spoke-SDP”.)

To view the configuration, enter the following command:

nodeA>config>service# info

The output is shown below:

vpls 100 customer 1 m-vpls createstp

no shutdownexitspoke-sdp 100:100 createexitmesh-sdp 300:100 createexitno shutdown

exit

The output of the show command displayed below provides the operator with a complete view on a per-node basis of the customer spoke pseudowires that have been blocked by the VPLS-RSTP instance associated with themanagement VPLS instance.

node A# show service id 100 stp____________________________________________________________________________________________________

Rstp Info, Service 100____________________________________________________________________________________________________

Bridge Id : 80:00.22:72:ff:00:00:01 Top. Change Count : 3Root Bridge : 80:00.22:6f:ff:00:00:01 Rstp Oper State : UpPrimary Bridge : 80:00.22:71:ff:00:00:01 Topology Change : InactiveMode : Rstp Last Top. Change : 0d 02:57:00Vcp Active Prot. : Rstp Root Port : Vcp____________________________________________________________________________________________________

Rstp port info____________________________________________________________________________________________________

Sap/Spoke Id Oper- Port- Port- Port- Oper- Link- ActiveState Role State Num Edge Type Prot.

____________________________________________________________________________________________________

100:100 Up Pruned Discarding 2048 False Pt-pt Rstp____________________________________________________________________________________________________


A L C AT E L > 7

Summary

The solution proposed in this paper solves the problem ofresiliency in the connections between customer sites thatspan multiple metro Ethernet networks. The solutionrelies on H-VPLS spoke redundancy. The recovery timesassociated with the solution are on the same order asthose commonly associated with SONET/SDH APSrecovery times. When using this solution it is importantto take into consideration the network planning notesdiscussed above.

ABBREVIATIONSAPS automatic protection switchingATM asynchronous transfer modeCLI command line interfaceESS Ethernet Service SwitchH-VPLS hierarchical VPLSLSP label switched pathMAC media access controlMPLS multiprotocol label switchingMTU multi-tenant unitM-VPLS management VPLSPE provider edgeRSTP rapid spanning tree protocolSDH synchronous digital hierarchySLA service level agreement SONET synchronous optical networkTDM time division multiplexingU-VPLS user VPLSVPLS virtual private LAN serviceVPLS-RSTP Alcatel’s enhanced implementation

of rapid spanning tree protocolVPN virtual private network


8 < A L C AT E L

www.alcatel.comAlcatel and the Alcatel logo are registered trademarks of Alcatel.All other trademarks are the property of their respective owners.

Alcatel assumes no responsibility for the accuracy of the information presented, which is subject to change without notice.

© 09 2005 Alcatel. All rights reserved. 3CL 00469 0719 TQZZA Ed.02 19531

Documents

19531 Resilient HVPLS An