test report - eantc · 5620 sam 1850 tss-40 cisco systems crs-1 12000 series foundry networks...

Test ReportMulti-Vendor MPLS

Interoperability Event

Paris, February 2007

MPLS World Congress 2007 Public Interoperability Event

Editor’s NoteMulti-Protocol Label Switching (MPLS) has “crossed thechasm” between early adoption and significant deploy-ment. Service providers today are using MPLS todeliver point-to-point services over interconnected back-bone networks, for example, while placing increasinglycomplex demands and ever-larger economies of scaleupon these networks. Carrier-grade network operatorsnow rely on MPLS to facilitate inter-carrier connectivity,mobile backhaul strategies, and multicast VPNs, toname only three common uses. And yet, misconfigura-tions and points of needed clarification persist. Clearlynot all aspects of interoperability have been tested, andnot all ambiguities in the standard have been resolved.EANTC has followed the development of the MPLSprotocol family for its entire duration. Over the courseof the last seven years and throughmany interoperability events, wehave seen a lot of MPLS servicesmature, perform and interoperateflawlessly. A few examples includesignaling, routing, traffic engineer-ing and VPN services. Buzzwordscome and go, but MPLS has proveditself the most robust, interoperableand scalable carrier-class technol-ogy available for packet networkstoday.This year’s MPLS World Congressinteroperability event focused onmultiple areas of recent MPLSadvances. The results further demonstrated that multi-vendor MPLS networks actually do work. Both returningvendors and first-time participating companies broughtmature implementations to the test. There were a fewissues as always (see the problem section for details),but there were no serious showstoppers.To summarize our findings, inter-carrier connectivityfunctioned well between all participating vendors — atleast one of the three options works for any combina-tion. Basic multicast VPN (»Rosen draft«) implementa-tions interworked seamlessly in most cases (althoughnot across inter-area boundaries, there is no standardyet). End-to-end interoperability was verified using newmobile backhaul (SAToP) and encrypted pseudowireservices.The hot-stage event at EANTC resulted in a substantialamount of technical data, summarized in this whitepaper. We hope you’ll find it useful.

Carsten Rossenhoevel

IntroductionEANTC’s interoperability tests share two targets. Thefirst target is device and equipment manufacturers. Ourevents allow network device and equipment vendors arare opportunity to test implementations against thoseof other vendors and to verify implementations of newtechnologies in accordance with standards. Vendorsgather information about the nature of any problemsand in many cases receive new code updates fromdevelopers during the event. Interoperable vendors usethe results to expand their footprints in new marketsand display their level of technological readiness.Our second target is network operators. The EANTCinteroperability events provide carriers and serviceproviders with a realistic picture of available technicalsolutions, potential deployment issues, and best prac-

tices network design.Carriers’ involvement inthe interoperability eventshas grown steadily inrecent years.A resulting effect of theinteroperability event isfeedback to technicalcommittees and standardsbodies, including opportu-nities to improve the stan-dards’ readiness for realworld deployment.EANTC and UNH-IOL

(University of New Hampshire Interoperability Lab)developed the test plan between October and Decem-ber 2006. The test areas were finalized after extensivereview with participating vendors and service provid-ers.

Based on EANTC’s experience in organizing andexecuting multi-vendor interoperability events an eightdays, closed doors, hot-staging event was conducted inEANTC’s lab in Berlin, Germany. The results arepresented in this White Paper.

Document Structure

Participants ➔ Page 3Network Design ➔ Page 3Test Areas ➔ Page 4Interoperability Results ➔ Page 5Topology Diagram ➔ Page 10Problem Summary ➔ Page 11References ➔ Page 11

Figure 1: Hot-staging at EANTC, Berlin

2


Participants and Devices

Carrier Involvement

Engineers from the German service providers T-Systemsand Versatel provided detailed comments to the testplan and participated for the duration of the whole hot-staging event. T-Systems engineers were responsible forcarrying out the service verification tests; Versatel coor-dinated the inter-area tests.

Network DesignThe interoperability test infrastructure resembled twonext-generation carrier networks designed to supportend-to-end residential IPTV, Triple Play, businessservices and cellular backhaul.

Given a total of 13 participating vendors, we created amulti-vendor network with many interoperability testopportunities. This amount of vendors would be quiteunusual in a real service provider network; carriersoften use heterogeneous MPLS networks from a fewvendors — typically two vendors for the core, aggrega-tion and CPEs.

Figure 2 illustrates the five logical parts of the networkthat were the focus of the tests:

1. Inter-carrier domain. Extending existing VPNtechnologies to cross the traditional carrier domaincan provide more service offerings to the customer,and institute new business models into the serviceprovider's portfolio. Several inter-AS VPNs weredemonstrated, supporting both Layer 2 and Layer 3applications across the boundary. L2VPNs includedboth single-segment and multi-segment pseudowiresend-to-end, as well as a full mesh VPLS domain.L3VPNs featured the three options (known sepa-rately as Option A, Option B, and Option C)described in IETF RFC 4364.

2. Service provider domains. Within each of thetwo carrier networks, VPLS and MPLS/BGP VPNwere created among the participants. In addition,Fast Reroute provided each backbone with carriergrade Resilience and Protection.

3. Aggregation. Several distinct solutions to imple-ment aggregation and access networks were veri-fied during the test. In particular, H-VPLS MTUs,and TDM and ATM pseudowire access switcheswere evaluated.The Resilience and Protection for the aggregationpart of the network was covered by Dual-HomedMTU and MPLS BFD.

4. Access. In this area encrypted end-to-end ATM andTDM connections as well as end-to-end Ethernetpath redundancy were tested.

5. Network Services Area. Triple play applica-tions such as VoIP and IPTV (IP-Multicast based)servers were positioned in this area.

Alcatel-Lucent 7710 SRc-127250 SAS7750 SR17750 SR75620 SAM1850 TSS-40

Cisco Systems CRS-112000 Series

Foundry Networks Netiron XMR 16000

Huawei Technologies CX600ME60NE40NE40E

IXIA Optixia X16

MRV Communications OS9024M-210GxOSM207

RAD DataCommunications

ACE 3100ETX-202Gmux-2000

Redback Networks SmartEdge 400

Rohde & Schwarz SIT SITLinkR&S SITLine ATM

Siemens SURPASS HiD 6650

Spirent TestCenter

Telco Systems,a BATM Company

T-Metro-100T-Metro-200T-Marc-250T-Marc-254

ZTE Corporation ZXR10 T128

3


Test Areas and Test PlanThe variety of test cases in our interoperability eventscontinues to grow annually as MPLS becomes applica-ble to more types of products and network environ-ments. The following test areas have been defined incooperation with the participants who attended thehotstaging event:

• MPLS based services. The basic premise of thetest network relied on an underlying MPLS infrastruc-ture. Participants were only allowed to partake intesting if their device supported at least one of theaforementioned MPLS services. Specific interopera-bility problems inherent to MPLS have beenaddressed in previous events. Hence, in this year’sevent, the MPLS services were simply used to facili-tate testing of advanced functionalities.

• Resilience and Protection. To date, disruptionprevention and downtime minimization have been atop priority for service providers in every generationof telecom networks. As networks become depart-mentalized, failure restoration capabilities must alsobe installed towards the edge (e.g. aggregation), inaddition to the service provider's backbone wheresub-50ms restoration traditionally has been. In thisevent, aggregation and access protection were veri-fied via Dual Homed MTUs and VPLS based Ether-net Path Protection.

• Fault Monitoring. Persistent fault monitoring isessential to the delivery of high quality services toboth residential and business customers. During thehotstaging event, various fault monitoring tools weretested among the participants, including MPLS ping,MPLS traceroute and MPLS BFD.

• Inter-carrier L3VPN. Several solutions exist toenable an L3VPN to cross different administrativedomains. In particular, the IETF defined threeoptions where MPLS/BGP VPNs can be supportedacross an AS boundary using readily availableprotocols. To the customers, implementation of thethree options are transparent. To the service provid-ers, each option requires a different level of trustrelationship at the boundary. Option A is thesimplest of the three, as each service provider viewsthe other as a customer. Option B overcomes somedrawbacks of Option A as a result of its simplicity,but a higher level of trust must exist between the twoproviders. Option C is the most integrated method,in which the two provider networks must function asone, forming one single large VPN domain end-to-end. Each option has its pros and cons, as well asits value proposition. All three options were tested.

• Inter-carrier L2VPN. Similar to inter-carrierL3VPN, a number of options to extend L2VPNs overAS borders exist. The options available to L2VPNuse the IETF defined multi-segment pseudowire (MS-PW). MS-PW allows for the termination of a

pseudowire in one AS, andcontinuation of the same serviceusing another pseudowire in thenext AS. The available optionsdiffer in the way the pseudowiresare stitched together. Popularprocedures include the use ofVLANs, manual stitching ofpseudowires, LSP tunnels stitch-ing and dynamic extensions ofpseudowires. All four optionswere tested.

• ATM and TDM Support. ATMand TDM application support isstill an important issue in next-generation packet network.These applications are timetested and provide a steadysource of revenue for manyservice provide. TDM andencrypted ATM traffic wascarried over Ethernet Pseudow-ires in addition to a demonstra-tion from ATM circuit encryptiondevices.

Aggregation

Busi

nes

s/Res

iden

tialA

pplic

ations

Customers

Backbone (P) Router

Backbone (PE) Router

Aggregation Router

Customer Edge Router (CPE)

Business VPN

Set-top Box

VoIP Phone

Aggregation

Inter-carrier domain

Service provider domains

Figure 2: Schematic Network Design

Busin

ess/Resid

entia

lApplica

tions

Access

Customers

4


Interoperability Test ResultsAfter eight intense days of hot-stage testing wecollected a substantial amount of results. The resultsprovide a detailed insight into the current state of MPLSsolutions. The following sections summarize ourfindings.

We evaluated VPLS/H-VPLS and L3VPN services in theMPLS backbone. VPLS was based on LDP signallingusing FEC 128 while the L3VPN services were basedon RFC 4364 (2547bis). Additionally, the ability toprovide a point-to-point service for TDM and ATMnative traffic was tested.

As a first step, two MPLS backbone networks wereconfigured resembling a typical service provider infra-structures. Both backbones included access and CPEcomponents. They were interconnected via redundantconnections as shown in Figure 2.

Results: Inter-Carrier Connectivity

The inter-connection between the two mock carriernetworks was tested using all variations defined in RFC4364. This specification provides three options forinter-AS connectivity for different network scenarios(see the Test Plan section for a detailed discussion.)

Autonomous System Border Routers (ASBRs) wereconnected in as many combinations as possible —many more than are shown in the final networkdiagram. Four VPN service types were verified acrossthe inter-area links: IP-based VPNs, Ethernet-basedmultipoint VPNs (VPLS), single-segment pseudowiresand multi-segment (»stitched«) pseudowires.

Signaling and Routing. The original test plan hadcalled for RSVP-TE signaling to create transport tunnels.Instead, we decided to use LDP at the hot-staging event.LDP (in downstream unsolicited mode) simplifies theconfiguration of the border routers, because the signal-ing protocol automatically creates a label for eachroute — RSVP-TE would have required manual tunnelsetup. This decision was taken purely for convenience;RSVP-TE would have been a working option for allparticipating vendors.

For the exchange of pseudowire VPN labels, targetedLDP sessions were established between the provideredge routers as usual (required by the specification).

Inside the MPLS domain of each autonomous system,OSPFv2 was used as the interior gateway protocol(IGP). Exterior BGP (eBGP) was configured on the inter-area links. In addition, vendors used the interior BGP(iBGP) protocol to exchange VPN labels for the IP-based VPNs as specified in the standard (RFC 4364).

iBGP was not used to exchange transport labels insidethe autonomous systems.

Inter-Area Connections were configured on theborder routers Alcatel-Lucent 7750 SR7, Cisco 12000,Cisco CRS-1, Foundry Netiron XMR 16000, HuaweiNE40E, Huawei CX600, Redback SE400 andZTE ZXR T128. See figure 3 for a diagram of allsuccessfully evaluated combinations. Due to limitedtime, not all possible connections were verified; for thesame reason, routers were not relocated to the otherautonomous system (AS) to allow for more combina-tions.

Figure 3: Inter-Area L3VPN Connections

The Option A links (marked in red) were quicklyestablished and did not show any issues betweenparticipating vendors. Option A is similar to normal PE-CE connections. The inter-area link is simply a routedunicast IPv4 link where multiple VRFs are differentiatedon layer 2, in our case by VLAN IDs.

The major part of the testing focused on Option Bwhich was supported by Alcatel-Lucent 7750 SR7,Cisco 12000, Cisco CRS-1, Huawei NE40E, HuaweiCX600, Redback SE400 and ZTE ZXR10 T128. Eightconnections in total were tested successfully.

During the Option B tests, we encountered eBGPconfiguration issues which caused loops when multipleOption B links were active simultaneously for resilience.In some cases, the redistribution of eBGP inter-arearoutes into an interior gateway protocol (OSPF) in bothautonomous systems led to loops. These were purelyconfiguration issues which were resolved during the testby proper filtering.

Option A (VRF to VRF)Option B (eBGP)Option C (eBGP plus label)

Alcatel-Lucent7750 SR7-1

Huawei NE40E ZTE ZXR10T128

FoundryNetiron

XMR 16000

CiscoRedbackSE400

AS

10

0

AS

20

0

12000

Huawei CX600Cisco CRS-1

5


Finally, several vendors worked on Option C links.Option C was supported by Cisco 12000,Cisco CRS-1, Huawei CX600 and Redback SE400.

No multi-vendor interoperability was achieved due to amapping issue: Once the border routers haveexchanged labeled eBGP routes on the inter-area link,the labels needed to be mapped inside each of theattached networks.

End-to-end label-switched paths can only be created iflabeled paths towards the inter-AS links exist at theprovider edge routers. Some implementationssupported mapping the eBGP routes to iBGP only —not to LDP. While these implementations did implementthe inter-area link properly, we were unable to verifylabel exchange inside the area (label switched pathsbetween the Option C link and the provider edgerouters) because the implementations did not support it.

To our knowledge, mapping procedures are not speci-fied by the IETF, because they are internal to a router. Itwould be good to provide some guidance to vendors,for example by means of an application note.

As a backup (because Option C links were required forother test areas), a single-vendor Option C connectionwas configured.

BGP/MPLS VPNs. Based on the inter-area linkscreated above, IP VPN services were establishedbetween the provider edge routers (PEs) Alcatel-Lucent7710 and 7750 routers, Cisco 12000 and CRS-1,Foundry Netiron XMR 16000, Huawei CX600 / NE40/ NE40E / ME60, Redback SE400 and ZTE ZXR10T128. Notice that the border routers were also config-ured as PEs in the hot-stage lab environment.

No route reflectors were used in the test. Inside eachcarrier network, full-mesh peers were established toincrease the number of test combinations.

The inter-carrier connections were established over twoOption B links in parallel. No load-sharing methodswere employed; failover was enabled by use of theregular BGP routing update mechanisms.

For this and all further test areas, one physical port ateach router was configured for a PE-CE link andconnected to the Ixia X16 and Spirent TestCenteremulators. Using these test links for traffic generationand analysis, we verified full-mesh connectivitybetween all provider edge routers for the MPLS/BGPVPN service.

IP VPN intra-area and inter-area connectivity wasachieved successfully between all participants withoutany issues:

VPLS Multipoint Ethernet Service. Virtual PrivateLAN Services (VPLS) were established betweenprovider edge routers inside and across the two carriernetworks.

All MPLS-enabled devices participated in this test.

In the hierarchical VPLS domain, the Alcatel-Lucent1850-TSS40, Alcatel-Lucent 7250SAS, MRVOS9024M-210Gx and Telco Systems T-Metro wereconfigured as multi-tenant units (MTUs) with one or tworedundant uplinks to a PE-RS router. All other systemswere configured as PE-RS routers, connecting to eachother in a near full-mesh logical configuration as shownin Figure 5.

We configured one common VPLS domain on all partic-ipating devices so that the Ixia X16 and Spirent Test-Center systems were able to verify full-mesh connectiv-ity.

As far as vendors could spare the time, full-mesh combi-nations were configured and successfully verified toforward end-to-end traffic. Only two interoperabilityissues occurred of which one could be resolved duringthe event.

Quite a few configuration issues delayed the creationof the VPLS domain. We have seen similar delays inprevious EANTC multi-vendor interoperability tests:

• Choice of pseudowire type. Both the »raw Ethernet«and the »VLAN« pseudowire types can be chosenfor VPLS links — independent of whether the Ether-net frames are to be delivered on VLANs at theedge or not. Some vendors were able to configureboth alternatives; some could even choose differentencapsulation types for different links within the

Alcatel-Lucent7750 SR7

Cisco CRS-1

Huawei

RedbackSE400

ZTE ZXR10T128

Huawei CX600

FoundryNetiron

XMR 16000

HuaweiNE40


HuaweiME60

Alcatel-Lucent7710SRc-12


NE40E

Cisco12000

Provider Edge Router Intra-AreaProvider Edge RouterAnd ASBR

Figure 4: MPLS/BGP VPN Logical Diagram

6


2

same VPLS domain; two vendors supported only the»raw Ethernet« option.

• Maximum Transmission Unit (MTU) is a commonsource of misconfiguration within Ethernet-basedMPLS networks. The MTU has to be increased onMPLS transport links so that labeled Ethernet frameswith 1500 bytes service payload can be carried.

• LDP interoperability was delayed due to addressconfiguration issues and label ranges.Newcomers were still confused by thequestion whether interface or loopbackaddresses should be used for LDPsessions. In one case, the large labelrange sent by a peer router confusedthe implementation of the receiver.

These issues should be taken seriously.Experience shows that they do not disap-pear over time. Why do multiple optionsof limited use still exist in MPLS standards?Two pseudowire types for the samepurpose and MTU sizes that are too smallto work in any reasonable MPLS configu-ration are potential sources of misconfigu-ration. We hope the IETF will considerclarifying their use, reducing the amountof options and avoid similar situations infuture specifications (similar trouble isahead in the Ethernet multicast over MPLSarea).

End-to-End Pseudowires. In additionto multipoint services, point-to-point tunnelswere created as in a real MPLS service providernetwork.

We did not aim to create a fullymeshed pseudowire end-to-endscenario because this task wascompleted as part of the VPLS tests,so we were certain all participantswould interoperate.

Instead we focused on inter-areapseudowires as well as interopera-bility issues. There are two optionsfor inter-area pseudowires to beestablished. From the point of viewof the provider edge router, creatingend-to-end LSPs is easiest, where theborder router maps labels appropri-ately over the inter-carrier links. Anend-to-end pseudowire can be estab-lished just like an intra-areapseudowire. No special configura-tion or protocol support is requiredat the provider edge router.

TDM pseudowires were established dynamically (e.g.using LDP) with the following encapsulation options:

• SAToP (RFC4553)

• TDM over Ethernet (MEF 8)

In addition, end-to-end ATM pseudowires (according toRFC 4717) were established between RAD ACE-3100and Alcatel-Lucent 7750.

Please see the application section for more details.

All pseudowires were established without any issuesafter the inter-area connections were established.


MRVOS9024M-210Gx

Telco SystemsT-Metro

H-VPLSMTUs

H-VPLSMTUs



Alcatel-Lucent1850-TSS40

Alcatel-Lucent7250 ES

Alcatel-Lucent1850-TSS40

ZTEZXR10 T128

HuaweiNE40E

HuaweiNE40

RedbackSE400


SiemensSURPASS HiD6650

Cisco12000

FoundryXMR 16000

HuaweiCX600


HuaweiME60

MRVOSM207


Figure 5: VPLS Connections

RAD ACE3100

RAD GMUX-2000

Provider Edge Router

Alcatel-LucentAlcatel-Lucent

RAD GMUX-2000

Telco Systems

Alcatel-Lucent

RAD ETX202 RAD ETX20

Customer Edge Equipment (CPE)

Alcatel-Lucent

MRV OSM207

Alcatel-Lucent

ATM Pseudowire

Ethernet Pseudowires (VPLS)

TDM E1 over Ethernet Pseudowires

TDM Pseudowires

Ethernet Pseudowires

7750 SR7

7750 SR7

7250 SAS

1850 TSS40

T-Metro


7750 SR7

Rohde & SchwarzSITLinkRohde & Schwarz

SITLink

E1

Figure 6: End-to-End Pseudowires

LDP VPLS(full-mesh connected)



E1

7


Multi-Segment Pseudowires. Multi-segmentPseudowires (MS-PW) are an important solution toenable inter-area point-to-point layer 2 services. In thetest event, MS-PWs were used solely for EthernetPseudowires.

Multi-segment Pseudowires are created of multiplepseudowires that are »stitched« together at intermedi-ate MPLS routers. Each segment can be staticallydefined by using LDP on each segment. Pseudowirestitching was performed by Cisco 12000, HuaweiNE40E and ZTE ZXR10 T128.

In addition, VLAN stitching of pseudowires was testedbetween the ZTE ZXR10 T128 and Huawei NE40E/NE40/CX600. In this case label-switched paths fromone carrier network were terminated by a border routerand reconnected to label-switched paths in the secondcarrier network by using VLAN tags. This is a staticsolution that is simple, but requires manual configura-tion.

Figure 7: Multi-Segment Pseudowires

Results: MPLS Protection

The following vendors were scheduled to participate inFast Reroute testing: Alcatel-Lucent 7710 and 7750routers, Cisco 12000 and CRS-1, Foundry NetironXMR 16000, Huawei CX600/NE40/NE40E/ME60,Redback SE400, Siemens SURPASS HiD 6650,Telco Systems T-Metro and ZTE ZXR10 T128.

Given the limited time, we prioritized the inter-carrierrelated test areas because they were tested for the firsttime. Fast Rerouting has been evaluated for multi-vendor interoperability in several EANTC events in thepast.

Fast Rerouting could not be evaluated across the inter-carrier connections. There is an IETF draft describing apotential solution, but it is in its early stages. Partici-

pants were not yet ready for multi-vendor interop test-ing.

There was only one case of Fast Rerouting testsbetween Telco Systems T-Metro and Alcatel-Lucent7750 SR7 and 7710. The rerouting was verified towork in under 50 ms.

Dual Homing MTUs. Dual homing MTUs to two PEsprovides resiliency for the MTU-PE connection andhence significantly increases the service availability tothe customer. In order to verify Dual Homing interopera-bility three MTUs were connected to two upstream PEs.

One Telco Systems T-Metro MTU was connected to theRedback SE400 and the Alcatel-Lucent 7750 SR7 utiliz-ing local link failure detection in order to switch fromthe primary link to the secondary when the primary linkwas disconnected. A second link Telco Systems T-MetroMTU was connected to Huawei NE40E and Alcatel-Lucent 7750 SR7. On the primary connection BFD wasconfigured to detect OSPF adjacency loss and automat-ically switch to the secondary connection. The MRVOS9024M was the third MTU used in this test. It wasconnected to the Redback SE400 and the Alcatel 7750SR7. This combination also showed no interoperabilityproblems in using a secondary connection when theprimary was down.

Figure 8: Dual Homing MTU Tests

Results: Fault Monitoring and OAM

LSP ping tests were carried out in the MPLS backbonewith a total of 15 implementations. We did not investmuch time in configuring and troubleshooting the LSPping protocol; it was expected that it should just work,being a troubleshooting protocol itself.

We discovered a total of 10 inconclusive results; thiscalculates to a 57 % success rate for the LSP ping faultdetection. It seems LSP ping is still not a commodityservice that works reliably in multi-vendor environ-ments.

Furthermore, MPLS traceroute was tested in severalcombinations. Most problems were related to the imple-

Carrier 1

Static multi-segment Pseudowire

Telco SystemsCisco 12000

ZTE

Huawei NE40E

Siemens SURPASS

Alcatel-Lucent

HuaweiHuawei

PW with native VLAN across AS boundary


Border Router

Carrier 2T-Metro

ME60

7750 SR1


ZXR10 T128HiD 6650



NE40

Performing Stitching

MPLS Core


Traffic GeneratorTraffic Generator


Traffic Generator

RedbackSmart Edge 400

Alcatel7750 SR7

Alcatel7750 SR7

HuaweiNE40E

MRVOS9024M

Link with primary PWLink with secondary PW

MTU

MTU MTU

8


mentation of different protocol versions. Some vendorsimplemented draft versions while others alreadysupported the final RFC 4379 — which is incompatiblewith its predecessor drafts. In general, interop prob-lems were more visible in MPLS traceroute than in LSPping since the former uses two additional TLVs (“Down-stream-Mapping” and “Interface and Label Stack”) thatwere changed during the evolution of the drafts.

Results: End-to-end Ethernet Path Protec-tion

Two RAD ETX-202 Ethernet demarcation devices,located at both ends of the Ethernet path across theVPLS core, exchanged Ethernet loopback OAM tocontrol end-to-end path integrity. In case of a pathbreak in the core, the ETX-202 units stopped receivingOAM, indicating a failure, and automatically switchedthe user traffic (emulated by IXIA) to a backup VLAN.The backup VLAN was recognized by PE (Alcatel7750) that re-established the backbone Ethernetpseudowire connection by switching over to thebackup VPLS path.

Results: Multicast VPN Service

Multicast in Layer 3 VPNs was tested in accordance tothe L3VPN IETF working group Internet draft known asthe »Rosen draft«.

In each of the two carrier networks a separate multicasttopology was defined. In the respective network back-bones, PIM-SM (protocol independent multicast) wasused to create multicast distribution trees. All participat-ing provider edge routers joined a single group.Generic routing encapsulation (GRE) tunnels were usedin accordance with the »Rosen draft« specification totransport multicast traffic within the network.

We created a customer VPN dedicated to multicastinside each of the two carrier backbones. Spirent's Test-Center was used to emulate customer edge routersagainst every participating provider edge router. Inorder to facilitate multicast traffic distribution in thecustomer domain, PIM-SM was configured on all linkstowards customer edge routers (in addition to OSPFrouting). A multicast group was sourced behind oneemulated customer edge router and joined by receiversattached to all other endpoints within the multicast VRF.

In one of the carrier networks, Alcatel 7750 SR7,Redback SE400 and Huawei NE40E constructed amulticast domain within L3VPN. All devices were ableto construct data distribution trees and deliver multicastto receivers.

In the second autonomous system, Huawei ME60,Cisco 12000, Alcatel 7710SRc-12 and Alcatel 7750SR1 constructed the multi-vendor multicast topology.After having fixed configuration issues all vendorsshowed no problems interoperating with each other.

Participating vendors discussed the potential of inter-connecting the two multicast domains across the inter-area connections. There is no specific standard yet. Theonly option would have been to interconnect thedomains using Option A (see above), but for thispurpose multiple virtual multicast routing instanceswould have been required on each of the borderrouters — one instance per customer domain. Partici-pants were not ready for multi-vendor interoperabilitytesting in this area yet.

Results: TDM and ATM Pseudowires

RAD Gmux-2000 gateways were used to dynamicallyestablish single-segment TDM pseudowires across thebackbone using LDP signaling. The encrypted E1 TDMtraffic was encapsulated according to RFC4553(SAToP). To demonstrate the transport of the TDM traf-fic, two applications were run over E1 TDM interfaces:voice and transparent E1 TDM traffic from theRohde & Schwarz SITLink encryption system.

A RAD ACE-3100 access gateway and Alcatel-Lucent7750 PE were used to establish single-segment ATMpseudowires across the backbone. The ATM traffic wasencapsulated according to RFC 4717, N-to-one modewithout control word. To demonstrate the transport ofthe encrypted ATM traffic, Rohde & SchwarzR&S SITLine ATM encryption systems were connectedvia STM-1 ATM UNI interfaces.


Huawei

RedbackSE400

ZTE ZXR10T128

Huawei CX600

HuaweiNE40


HuaweiME60



NE40E

Cisco12000

Border Router



SiemensSURPASS HiD 6650

MRV

Cisco CRS-1

LSP Ping TestCombination

OS9024M-210Gx

Figure 9: LSP Ping Tests

9


Final Integrated Test Network

Carr

ier

2

Ixia

Optix

iaX

16

Spir

ent

Test

Cen

ter

Carr

ier

1O

ption A

Huaw

ei

Huaw

eiM

E60

RA

D

Telc

oSy

stem

sM

TUTe

lco

Syst

ems

MTU

Telc

oSy

stem

sM

TU

Alc

ate

l-Lu

cent

77

10

SRc-

12

Alc

ate

l-Lu

cent

77

50

SR1

MRV

OSM

20

7

Siem

ens

SURPA

SSH

iD6

65

0

Huaw

eiN

E40

Telc

oSy

stem

s

Telc

oSy

stem

sM

TUTe

lco

Syst

ems

MRV

OS9

02

4M

-21

0G

x

MTU

RA

D

Alc

ate

l-Lu

cent

MTU

Alc

ate

l-Lu

cent

T-M

etro

Red

back

SE4

00

T-M

arc T-M

etro

Cis

coCRS-

1

Alc

ate

l-Lu

cent

77

50

SR7

ETX

20

2

NE4

0E

18

50

-TSS

40

18

50

-TSS

40

Gm

ux

-20

00

T-M

etro T-M

etro

T-M

arc

Foundry

Net

iron

XM

R1

60

00

Huaw

eiCX

60

0

Option B

Option B

Option B

Optio

n C ZTE

ZX

R1

0T1

28

Spir

ent

Test

Cen

ter

Ixia

Optix

ia X

16

Spir

ent

Test

Cen

ter

Ixia

Optix

ia X

16

Rohde

&Sc

hw

arz

SITL

ine

ATM

RA

DA

lcate

l-Lu

cent

MTU

72

50

SAS

Cis

co1

20

00

Inte

r-Carr

ier

Connec

tion

RA

D

10G

ig E

ther

net

ATM

/ T

DM

P/PE

Rout

er

Prov

ider

Edge

(PE)

Rout

erG

igabit E

ther

net

Cust

omer

Edge

(CE)

MTU

Mul

ti Te

nant

Uni

t(M

TU)

Fast

Ether

net

Agg

rega

tion

devi

ce

Test

er

Aggre

gation

Are

aBack

bone/

Pro

vider

Edge

CPE

Are

a

Legen

d

Rohde

&Sc

hw

arz

SITL

ink

ACE3

10

0

Rohde

&Sc

hw

arz

SITL

ine

ATM

Alc

ate

l-Lu

cent

77

50

SR7

ETX

20

2

Rohde

&Sc

hw

arz

SITL

ink

RA

DG

mux

-20

00

10


Problem Summary

AcknowledgmentsWe would like to thank Ralf-Peter Braun, Manuel Paul, and Sabine Szuppa from T-Systems and Reiner Rommelfrom Versatel for the extensive support during the hot-staging event, guidance during test plan developmentand network design. This document has been edited by Carsten Rossenhoevel, Jambi Ganbar, SergejKaelberer (EANTC); Henry He, Kyle Price, Chris Volpe (UNH-IOL).

References• LDP Specification (RFC 3036)• Fast Reroute Extensions to RSVP-TE for LSP Tunnels (RFC 4090)• OSPF Version 2 (RFC 2328)• Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) (RFC 4447)• Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures (RFC 4379 )• BFD For MPLS LSPs (draft-ietf-bfd-mpls-03.txt)• Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) (draft-ietf-pwe3-vccv-12.txt)• Bidirectional Forwarding Detection (BFD) (draft-ietf-bfd-base-05.txt)• BGP/MPLS IP Virtual Private Networks (VPNs) (RFC 4364)• Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling (RFC 4762)• Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks (RFC 4448)• Segmented Pseudo Wire (draft-ietf-pwe3-segmented-pw-03.txt)• Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (RFC 4601)• Multicast in MPLS/BGP IP VPNs, Work in progress (draft-ietf-l3vpn-2547bis-mcast-03.txt)• Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) (RFC 4553)• Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks (RFC 4717)• Implementation Agreement for the Emulation of PDH circuits over Metro Ethernet Networks (MEF8)

ProblemArea Description

TemporarySolution, if any Recommendation

L3VPN Inter-Area withOption C

No label allocation via LDP forroutes that were imported from eBGPinto OSPF

Use a different Inter-area option for L3VPN

None

No label allocation via eBGP ifeBGP+label was enabled

None

LDP SessionEstablishment

LDP Hello messages were sent to aunicast address sourced on the inter-face address

The LDP session wasestablished through anintermediate hop

Correct the implementation to transmit LDPhellos to multicast address with the correctsource IP

MPLS Traceroute Traceroute stops at intermediatehops

None Implementations must be updated in accor-dance to the final RFC

Static LSP Estab-lishment

LSPs could not be established due tolabel range incompatabilities

None The maximum label range values thatrouters must accept in incoming messagesshould be specified in the RFC

Multi-SegmentPseudowires

Some vendors implement the stitch-ing based on the LDP label, some onthe VCID label

None Increase flexibility of implementations orspecify more clearly in the RFC whichlabel should be used for stitching

11

EANTC AGEuropean Advanced Networking Test Center

University of New HampshireInterOperability Laboratory

Tel: +49 30 3180595-0Fax: +49 30 [email protected]

Tel: +1.603.862.4212Fax: [email protected] (Henry He)www.iol.unh.edu

Upper Side

Tel: +33 1 53 46 63 80Fax: +33 1 53 46 63 85www.upperside.fr

This report is copyright © 2007 EANTC AG. While every reasonable effort has been made to ensure accuracy andcompleteness of this publication, the authors assume no responsibility for the use of any information contained herein.

All brand names and logos mentioned here are registered trademarks of their respective companies in the UnitedStates and other countries. (v1.1)

test report - eantc · 5620 sam 1850 tss-40 cisco systems crs-1 12000 series foundry networks...

Documents