carrier ethernet services - the futureforums.juniper.net/jnet/attachments/jnet/switch... · carrier...
TRANSCRIPT
Carrier Ethernet Services -The Future
Public Multi-VendorInteroperability Test
Berlin, September 2008
2
Carrier Ethernet World Congress 2008 Multi-Vendor Interoperability Test
EDITOR’S NOTE
This year the interoperabilityhot staging test for theCarrier Ethernet WorldCongress took place inparallel to the BeijingOlympics.80 engineers from 28 parti-cipating vendors with over100 systems attended ourtest. According to data fromHeavy Reading, more than
90% of the Carrier Ethernet switch and router marketshare were represented in this test.The participating vendors verified 34 test areas inany-to-any combinations in ten days, trulychallenging the Olympic motto “Faster, Higher,Stronger“. Carrier Ethernet implementations supportmore functions and cover more markets today —ranging from core to microwave to access, E-Lines toE-Trees, triple play to mobile backhaul.It was an outstanding experience to witness themassive testing feast, a unique get-together ofvirtually all leading playerswith one single goal:To improve multi-vendorinteroperability of advancedCarrier Ethernet implementa-tions.An EANTC panel of serviceproviders worldwide includingexperts from COLT, GVTBrazil, PT TELKOM Indonesia,T-Systems and Metanoia Increviewed the test planthoroughly to ensure the event’sscenarios are realistic andsound.Interestingly, market forces areoperating at full strength. Thisyear, we once again testedthree transport technologies inthe test event’s metro/aggre-gation networks: MPLS, PBB-TEand T-MPLS. These threecompete to some extent — atour test, they all proved beingwell suited for the transport of Carrier Ethernetservices.Service OAM support is becoming mandatory foraggregation and CPE devices; the Ethernetmicrowave market flourishes; mobile backhaulpushes support for backwards compatibility (ATMpseudowires, circuit emulation) and new features(clock synchronization, IEEE 1588v2, E-Tree, amongothers).This white paper summarizes in detail themonumental effort that the participating vendors andEANTC team underwent. Enjoy the read.
INTRODUCTION
This year’s interoperability event focused on theFuture of Carrier Ethernet Services. While eachprevious event concentrated on specific topics suchas mobile backhaul or service creation, this eventaimed to congregate the knowledge and experiencethe industry gained in the last four years into a singlemodern, converged network showing all that a tier-one service provider is likely to encounter. Wetherefore tested:
• Converged residential, business and MobileBackhaul services
• Clock synchronization
• Business services realized using E-Line, E-LANand for the first time E-Tree services
• The leading access, transport and aggregationtechnologies
• Microwave access and transport
• Ethernet OAM: Fault management and perfor-mance monitoring
• High availability
• Management and SLA reportingIn order to construct such a large testnetwork and cover all the above testareas a ten day, closed doors hotstaging event was conducted atEANTC’s lab in Berlin, Germany.Since the first Carrier Ethernet WorldCongress in 2005, EANTC hasorganized interoperability test eventswhich are then showcases at thecongress.Our interoperability showcases aredriven by three main goals:Technical – Through participation inthe event, vendors have the oppor-tunity to verify the interoperability oftheir devices and protocol implementa-tions against the majority of theindustry’s leading vendors.Marketing – The participants canshowcase the interoperability of theirlatest solutions on a unique, large-scale platform.
Standards – When fundamental issues are foundduring the hot staging event EANTC reports thediscoveries to the standard bodies. These in turnupdate the standards.EANTC started the preparation for the event byinviting interested vendors to weekly conferencecalls during which the technical and marketing goalsfor the event were discussed and agreed. The testplan, created by EANTC based on the test topicssuggested by the vendors, expanded on theexperience gained from previous events and waslined up with recent IEEE, IETF, ITU-T and MEFstandards.
Carsten RossenhoevelManaging Director
TABLE OF CONTENTS
Participants and Devices ..............3Network Design..........................4Interoperability Test Results ...........4Ethernet Service Types .................4Diverse Access Technologies ........6Diverse Transport ........................7MPLS Core .................................8E-NNI........................................9Mobile Backhaul.......................10Clock Synchronization...............14Ethernet OAM ..........................15Resilience and Fault Detection.....18Management and SLA Reporting.21Acronyms.................................22References ...............................23
3
Participants and Devices
PARTICIPANTS AND DEVICES
Service Provider Test Plan ReviewThe draft test plan was reviewed by a panel ofglobal service providers in July this year. Theirfeedback and comments were reflected in the finalversion of the test plan. EANTC and the partici-pating vendors would like to thank: COLT, GVTBrazil, PT TELKOM Indonesia, T-Systems andMetanoia Inc.
Vendor Participating Devices
Actelis Networks ML658
ADVA OpticalNetworking
FSP 150CC-825
Alcatel-Lucent 1850 TSS-405650 CPAM7450 ESS-67705 SAR7750 SR79500 MPR
Calnex Solutions Paragon Sync
CambridgeBroadband Networks
VectaStar
Ceragon Networks FibeAir IP-MAX2
FibeAir IP-10
Ciena LE-311vLE-3300
Cisco Systems 76067604ME4500Catalyst 3750-MEME-3400-2CSME-3400-12CS
ECI Telecom SR9705
Ericsson Marconi OMS 2400
Foundry Networks NetIron XMR 8000
Harris StratexNetworks
Eclipse (Gigabit) Radio
Huawei Technologies NE5000E Cluster SystemNE40E-4CX600-4
InfoVista VistaInsight for Networks
Ixia XM2 IxNetwork
Juniper Networks M10iMX240MX480
NEC Corporation CX2600PASOLINK NEOPASOLINK NEO TE
Nokia SiemensNetworks
hiD 6650Flexi WCDMA BTSFlexiHybridRACEL
Nortel Metro Ethernet RoutingSwitch (MERS) 8600
RAD DataCommunications
ACE-3205ACE-3200ACE-3400ASMi-54Egate-100ETX-202AETX-202A/MiRICiETX-202A/MiTOPIPMUX-216/24LA-210OP-1551RICi-16RICi-155GE
Redback Networks —an Ericsson Company
SmartEdge 400
Rohde & Schwarz SIT SITLine ETH
SIAEMICROELETTRONICA
ALSALFO
SpirentCommunications
Spirent TestCenter
Symmetricom TimeProvider 5000 PTPGrand MasterTimeCesium 4000
Tejas Networks TJ2030
Telco Systems —a BATM Company
T5C-XGT5C-24FT5C-24GT-Marc-250T-Marc-254T-Marc-340T-Marc-380T-Metro-200
Tellabs 8830 Multiservice Router
Vendor Participating Devices
4
Carrier Ethernet World Congress 2008 Multi-Vendor Interoperability Test
NETWORK DESIGN
As in previous events we set off to construct anetwork that would allow all participating vendors toestablish end-to-end Ethernet services with any of theother vendors. One of the central design consider-ations for the network was to enable any devicepositioned in the access network to reach any otheraccess network device regardless of the otherdevice’s point of attachment to the network. Thisproved to be especially useful for such end-to-endtests as Service OAM or Mobile Backhaul. Thespecifics of these tests can be found in the test casesections.We also aimed to build a network that would lookfamiliar to service providers. It is perhaps unrealisticto expect that service providers will incorporate allcurrent transport technologies into their network.Nevertheless the familiar network domains are likelyto exist: access, aggregation, metro and core,regardless of the chosen transport technology. It isrealistic, however, to expect service providers to useMPLS in the core.Looking at the network from a customer’sperspective, we used the following network areas:
• Access: The devices that normally exist at thecustomer premise or by NodeBs or base stationswere positioned here. We were lucky to see adiverse number of access technologies for trans-porting Ethernet such as microwave links,copper, and fiber. These devices implementedthe UNI-C construct as defined by the MEF.
• Aggregation: The aggregation area of a networkconsisted of a variety of solutions meant toaggregate customer premise devices. Thisincluded Provider Bridges and H-VPLS Multi-Tenant Unit Switches (MTU-s). When applicablethese devices performed the UNI-N role in thenetwork.
• Metro: Three different transport technologieswere used in each of the three metro areanetworks: MPLS, PBB-TE and T-MPLS. Thisallowed each transport technology to test its ownresiliency and Network-to-Network Interface(NNI) solutions.
• Core: As stated above, IP/MPLS was used tosupport connectivity between the different metroarea networks in order to realize end-to-endservices. In addition, MPLS Layer 3 VPNs asdefined in RFC 4364 were tested in the core ofthe network.
The physical network topology presented heredepicts the roles of all the devices and theirrespective placement in the network. Please note thatmany tests required logical connectivity between thedevices, often at an end-to-end nature, which will beshown, where applicable, using logical topologiesin each test section.
INTEROPERABILITY TEST RESULTS
In the next sections of the white paper we describethe test areas and results of the interoperabilityevent. The document generally follows the structureof the test plan.Please note that we use the term »tested« whenreporting on multi-vendor interoperability tests. Theterm »demonstrated« refers to scenarios where aservice or protocol was terminated by equipmentfrom a single vendor on both ends.
ETHERNET SERVICE TYPES
The Metro Ethernet Forum (MEF) has defined threeEthernet service types in order to allow the industryand specifically the customers interested in theservices to have a common language to discuss suchEthernet based services. The three service types aredefined in terms of the Ethernet Virtual Connection(EVC) construct:
• E-Line – Point-to-point EVC
• E-LAN – Multipoint-to-multipoint EVC
• E-Tree – Rooted-multipoint EVCWhile the E-Line service type provides a service toexactly two customer sites, the E-LAN and E-Treeservice types allow the connection of more than twocustomer sites. In contrast to the E-LAN service typewhich allows an any-to-any connectivity betweencustomer sites, E-Tree introduces two different rolesfor customer sites: leaf and root. An E-Tree servicefacilitates communication between leaves and roots,however, leaves can not communicate with eachother directly. An E-Tree service implemented by arooted-multipoint EVC can be used to providemulticast traffic distribution and hub-and-spoketopologies (e.g. DSL customers to BRAS).In the test network we instantiated three specificdefinitions of service types: Ethernet Virtual PrivateLine (EVPL), Ethernet Virtual Private LAN (EVP-LAN),and Ethernet Virtual Private Tree (EVP-Tree). Allservices were configured manually in the network.Due to the increasingly large amount of devices andvendors we had present at the hot staging, thisprocess was time consuming and prone to mistakes.A multi-vendor provisioning tool would have beenideal for the testing and is recommended for anyservice provider planning to deploy Carrier Ethernetservices.The services created in the network were configuredin two ways:
• EVCs that remained within the same metro areanetwork
• EVCs that crossed the network coreThe sections below describe the services in thenetwork in detail.
5
Ethernet Service Types
E-TreeFor the first time at an EANTC interoperability event,an E-Tree service instantiation was established. OneEVP-Tree was configured with one root node withinthe MPLS metro area and leaves throughout allnetwork areas. The MEF defines an E-Tree service tobe a rooted Ethernet service where the roots areable to communicate with all leaves, and all leavesare able to communicate with the roots, but not witheach other.This service utilized each metro technology in aunique way. The MPLS metro used a separate VPLSinstance to create this service, using different splithorizon groups to ensure that leaf UNIs could onlycommunicate with the root UNI, but could notestablish communication between each other. TheCisco ME4500 implemented the root UNI-N andhanded the service off to the Nokia SiemensNetworks hiD 6650 which propagated the tree intothe MPLS metro. The Juniper MX480 configured aleaf using MPLS towards the Cisco 7606 whichtreated this connection as the root for the corenetwork. Three leaves were configured within the
core, two of which provided E-NNI leaf connectivityto the other metros - the Alcatel-Lucent 7750 SR7 toT-MPLS and the ECI SR9705 to PBB-TE. The TejasTJ2030 interpreted this E-NNI connection as the rootconnectivity for the PBB-TE metro, and the EricssonMarconi OMS 2400 did the same for the T-MPLSmetro.The diagram in figure 1 shows all points whereE-Tree traffic was verified. The logical connectionsrepresent something different in each area: Ethernetpseudowires in the MPLS, PBB-TE trunks in thePBB-TE, and TMCs in the T-MPLS networks.
E-LANOne EVP-LAN was configured in the network withcustomer ports in all three metro areas. Theconstruction of the EVP-LAN service used differentmechanisms in each metro area. These mechanismsare described in details in the diverse transportsection.
Cisco ME-3400-2CS
Cisco ME4500
ADVAFSP 150CC-825
Tejas TJ2030ECI
SR9705
Logical Path
EricssonMarconi OMS
Telco Systems
HuaweiCX600-4
JuniperMX480
ECISR9705
Telco SystemsT-Metro-200
MTU-s
Cisco7604
MTU-s
Telco SystemsT-Metro-200
MTU-s
CienaLE-311v
Telco SystemsT-Metro-200MTU-s
Tellabs8830
CeragonFibeAir IP-10
MTU-s
2400
Tejas TJ2030
Propagation
AccessDevice
AggregationDevice
MTUSwitch
Metro/CoreDevice
Root UNI
Root/Leaf
Leaf UNI
E-NNI
T-Marc-340
MPLS
PBB-TET-MPLS
FoundryNetIron XMR 8000
Alcatel-Lucent7750 SR7
EricssonMarconi OMS
2400
EricssonMarconi OMS
2400
RedbackSmartEdge
400
Nokia Siemens Networks
JuniperMX480
Cisco7606
Alcatel-Lucent1850 TSS-40
Figure 1: E-Tree logical connections
CambridgeVectaStar
Harris StratexEclipse
ADVAFSP 150CC-825
Telco SystemsT-Marc-380
CienaLE-3300
NortelMERS 8600
hiD 6650
6
Carrier Ethernet World Congress 2008 Multi-Vendor Interoperability Test
E-LineThe E-Line service type configured in the networkused Virtual LAN (VLAN) IDs to distinguish betweenthe various services. In some cases, much like realworld networks, a switch positioned at the customersite would add a Service VLAN tag (S-VLAN) to theEthernet traffic provided by the customer, therefore,allowing the customer to maintain its private VLANaddressing scheme and separate the customer VLANspace from the provider’s.
Figure 2: E-Line service creation
All vendor devices successfully participated increation of E-Line services. From the number ofcombinations tested, we are confident that an any-to-any combination of endpoints is possible.Three of the E-Line services created between thethree metro clouds were encrypted using Rohde &Schwarz SITLine ETH. The encryption device wassituated between the UNI-C (which was emulated bySpirent TestCenter) and Alcatel-Lucent 7705 SAR,Telco Systems T-Marc-380 and Telco SystemsT-Metro-200 all of which were serving as UNI-Ndevices. Once the encryption connections wereestablished we verified that the EVCs were indeedencrypted and that the connection remained stable.
DIVERSE ACCESS TECHNOLOGIES
The different services in the test network used avariety of access technologies to reach the simulatedlast mile customer access device. Most services usedfiber (multi-mode) and copper based GigabitEthernet. One UNI was implemented over a singlestrand fiber cable using IEEE 802.3ah defined1000BASE-BX10 between the Cisco ME4500 andthe Cisco ME-3400-2CS. Two Actelis ML658devices used G.SHDSL.bis to connect the aggre-gation area to the access. RAD demonstrated a widevariety of access technologies including EFMbonding of four G.SHDSL.bis pairs between theASMi-54 and LA-210. In addition, RAD demon-strated Ethernet over PDH connectivity with theETX-202A with MiRICi E1/T1 over a single E1 linkand the RICi-16 over 16 bonded E1 links, bothaggregated by the Egate-100. The PDH tochannelized STM-1 was performed by the OP-1551.Several Ethernet access links comprised of twoEthernet links with a microwave signal in between.These systems are described in more detail below.
Microwave for Access andTransportIn recent years we have seen an increased interest inour interoperability events from vendors offeringmicrowave connectivity and network solutions.Microwave solutions alleviate the need to roll outphysical wire infrastructure and are especiallyprevalent in such areas as cellular backhaul,emerging markets, large corporation networks,hospitals, and mobile-fixed operators.This event enjoyed the participation of the followingmicrowave products: Alcatel-Lucent 9500 MPR,Cambridge VectaStar, Ceragon FibeAir IP-10 andFibeAir IP-MAX2, Harris Stratex Eclipse, NECPASOLINK NEO, Nokia Siemens Networks Flexi-Hybrid, and SIAE MICROELETTRONICA ALS andALFO. In addition, Cambridge Broadband Networksprovided a point-to-multipoint microwave systemwith which providers can connect either multiplecustomer offices or multiple base stations viaEthernet or E1 lines.Since the radios rely on a signal through the airsome weather events such as rain and heavy fogcan cause the signal to degrade effectivelydecreasing the range or capacity of the link. Radiodevices can recognize the decrease in air-linkcapacity and some solutions can distinguish whichframes should be prioritized and further transportedversus which frames will be dropped. The Alcatel-Lucent 9500 MPR, Cambridge VectaStar, CeragonFibeAir IP-10, Harris Statex Eclipse, and SIAEMICROELETTRONICA ALFO showed this function-ality by decreasing the modulation scheme inQuadrature Amplitude Modulation (QAM) whichcaused traffic loss only to best effort frames and noor minimal loss to prioritized traffic with unaffectedlatency.
MPLS
User Network Interface (UNI)
UNI-N Metro Device
PBB-TE
UNI-N Aggregation Device
UNI-C Access Device
UNI-C Microwave Access Device
T-MPLS
7
Diverse Transport
Services relying on microwave equipment will needto be made aware when the microwave signal is tooweak to transmit traffic. The link state propagationfunction disables the Ethernet link state for all portsassociated with the microwave link. This function-ality was demonstrated by the Ceragon FibeAirIP-10, Harris Stratex Eclipse and the SIAEMICROELETTRONICA ALFO. These devices alsoshowed their capability to propagate an incomingloss of signal on a tributary Ethernet port across themicrowave link and switching off the appropriatephysical port on the other side of the radioconnection.Cambridge Broadband Networks demonstratedtheir ability to share point-to-multipoint link capacitybetween several end stations. In the demonstrationthree end stations were defined to share a 45 Mbpswireless link to a central controller. CambridgeBroadband Networks showed that when capacitybetween one base station and controller was notused, the remaining base stations could use theextra capacity.Over the last few years we have seen an impressiveincrease in the features built into microwavetransport. While historically microwave solutionswere used to provide a virtual wire, we see moreand more intelligence built into the solutions — onseveral products a complete Ethernet switchfunctionality.
DIVERSE TRANSPORT
The Carrier Ethernet architecture specified by theMEF is agnostic to the underlying technology used toprovide Carrier Ethernet services. The creation andsupport of such services is, however, an essentialcomponent of the interoperability test event. Mainlythree technologies compete for Carrier EthernetTransport: MPLS, PBB-TE and T-MPLS. During thisevent we had the opportunity to verify all threetechnologies. The following sections describe testresults for each technology in detail.
MPLSMPLS is defined in a set of protocols standardizedby the Internet Engineering Task Force (IETF) and theIP/MPLS Forum. MPLS is positioned to deliver layer2 and layer 3 services including Ethernet services asdefined by the MEF while being agnostic to theunderlying transport technology.The tests in this area were based on previousexperience gained from EANTC’s Carrier EthernetWorld Congress and MPLS World Congress interop-erability test events and reached a larger number ofparticipants than in previous events, including a totalof 12 vendors testing MPLS implementations. TheMPLS metro domain operated independently fromthe MPLS core network.The MPLS metro network was built solely for thepurpose of Carrier Ethernet services. Multipoint-to-multipoint services were facilitated with the creation
of a single Virtual Private LAN Services (VPLS)instance utilizing both VPLS PEs and H-VPLS MTUswitches established between the following devices:Alcatel-Lucent 7450 ESS-6, Ciena LE-311v, Cisco7604 and Catalyst 3750-ME, ECI SR9705, HuaweiCX600-4, Ixia XM2 IxNetwork, Juniper MX240 andMX480, Nokia Siemens Networks hiD 6650,Redback SmartEdge 400, Tellabs 8830, and TelcoSystems T-Metro-200. This VPLS instance used LDPfor signaling statically configured peers asdescribed in RFC 4762. These devices also estab-lished Ethernet pseudowires using LDP to facilitatepoint-to-point Ethernet services.A separate VPLS instance was used to test BGP-based Auto-Discovery, which was successfully estab-lished between the Cisco 7606 and the ECISR9705. A total of four vendors were interested intesting BGP-based Auto-Discovery, one of whichuncovered an interoperability issue during the testswhere packets captures were taken to be furtherstudied in their labs.In order to test the interoperability of VPLS implemen-tations which use BGP for signaling as described inRFC 4761, another separate VPLS instance wasconfigured. This was tested between the followingdevices with BGP-based Auto-Discovery enabled:Huawei CX600-4 and Huawei NE40E-4, andJuniper MX240 and Juniper MX480. The JuniperMX480 performed an interworking functionbetween this BGP signaled VPLS domain and an LDPsignaled VPLS domain with the Cisco 7604.
Provider Backbone BridgeTraffic Engineering (PBB-TE)One of the potential solutions to delivering MEFdefined services using Ethernet technologies only isthe IEEE defined Provider Backbone Bridge TrafficEngineering (PBB-TE). The technical specification isdefined in 802.1Qay which is working its waythrough the standard process and is in draft version3.0 at the time of the testing. The standard extendsthe functionality of the Provider Backbone Bridges(802.1ah) adding a connection-oriented forwardingmode by creating point-to-point trunks. These trunksdeliver resiliency mechanisms and a configurablelevel of performance.The vendors participating in the PBB-TE transportdomain included Ciena LE-311v2, Ciena LE-3300,Ixia XM2 IxNetwork, Nortel MERS 8600, and TejasTJ2030.In the PBB-TE Metro network we were able to test theestablishment of E-Line, E-LAN, and E-Tree services.The establishment of E-Line services was straight-forward as we tested it in several previous events.E-LAN and E-Tree services creation was tested testedfor the first time within the PBB-TE cloud. For theE-LAN service Ciena LE-3300 and Tejas TJ2030switches established bridging instances per PBB-TEtrunk and C-VLAN/S-VLAN IDs. Every PBB-TE edgedevice established a trunk for each particular UNI toone of the bridges. A few issues related to usage ofdifferent Ethertype values in CFM messages,
8
Carrier Ethernet World Congress 2008 Multi-Vendor Interoperability Test
padding, and different interpretation of CCMintervals were discovered in the initial configurationphase of PBB-TE trunks, however, these issues wereresolved quickly.In addition, the Nortel MERS 8600 and the SpirentTestCenter tested one of the latest additions toEthernet - Provider Link State Bridging (PLSB) – a pre-standard implementation of the IEEE 802.1aq(Shortest Path Bridging) which is in draft version 0.3.The protocol uses the IETF defined IS-IS protocol fordistributing Backbone MAC addresses and ServiceIDs of participating nodes across the network. Oncethe network topology has been learned, IS-IS is usedto establish loop-free multipoint-to-multipoint services.The forwarding plane uses PBB (802.1ah), howeversince the other devices in the PBB-TE network did notsupport PLSB the three Nortel MERS 8600 deviceswere able to use a re-encapsulation of either PBB-TEtrunks or VLAN tags to peer within the PBB-TEnetwork. The Nortel MERS 8600 devices and theSpirent TestCenter emulated nodes successfullylearned the appropriate B-MAC addresses, andforwarded the respective traffic accordingly.Tejas Networks demonstrated a logical Ethernet LANnetwork with an IEEE 802.1ad based Ethernet RingProtection Switching (ERPS). This ring based controlprotocol being standardized under ITU-T G.8032 isa protection mechanism which offers carriers adeterministic sub-50 ms network convergence on afiber failure as opposed to the conventional loop-breaking mechanisms like Rapid Spanning TreeProtocol (RSTP). ERPS convergence time isindependent to the number of nodes in the network,thereby vastly enhancing the scalability of a carriernetwork. We measured failover and restoration ofbelow 35 ms for the demonstrated ERPS.
Transport MPLS (T-MPLS)This test marked the third T-MPLS interoperabilitytesting at EANTC. The following devices successfullyparticipated in the T-MPLS area during the event:Alcatel-Lucent TSS-40, Ericsson Marconi OMS2400, and Ixia XM2 IxNetwork.The T-MPLS standards specify the networking layerfor packet transport networks based on MPLS dataplane and designed for providing SONET/SDH-likeOAM and resiliency for packet transport networks.Alcatel-Lucent and Ericsson successfully tested thecreation of E-Line, E-LAN and E-Tree services, the lastof which was a first at an EANTC interoperabilityevent. Both participants constructed T-MPLS paths(TMP) which are end-to-end tunnels that aggregateT-MPLS channels (TMC) representing the services.The TMPs and TMCs were transported over differentphysical layer types including 1 Gbit Ethernet,10 Gbit Ethernet, ITU-T G.709, and SDH STM-16.The Alcatel-Lucent 7705 SAR was used as a non-T-MPLS switch in the aggregation area, interfacing tothe T-MPLS domain by means of statically configuredMPLS labels.The E-LAN and E-Tree services were configured
using a multipoint architecture similar to VPLS. Onone particular E-Line service, both Alcatel-Lucent1850 TSS-40 and Ericsson Marconi OMS 2400were able to successfully test Quality of Service(QoS) by distinguishing between three differentclasses of service within the same Ethernet serviceand only drop low priority traffic when interfaceswere oversubscribed.Since the T-MPLS standards do not define a controlplane protocol, the T-MPLS connections betweenvendors were manually configured. Ericsson usedtwo proprietary management tools (ENEA andDiToNe) to setup the T-MPLS network configurationon their devices.
MPLS CORE
Since MPLS is used by the majority of serviceproviders as core technology it is only logical thatwhen providers add Carrier Ethernet services to theirproduct offering the MPLS core will be used. Wefollowed this approach and used the MPLS core toconnect between three different Ethernet transportmetro areas. The core area was constructed usingthe following edge devices, all of which successfullyestablished multiple VPLS domains and CVirtualPrivate Wire Services (VPWS) using LDP for variousEthernet services: Alcatel-Lucent 7750 SR7, Cisco7606, ECI SR9705, Foundry NetIron XMR 8000,Huawei NE40E-4, Juniper M10i, and Tellabs 8830.All devices were physically connected to HuaweiNE5000E cluster system P router (P for Provider, asopposed to PE for Provider Edge) through which allservices were tunneled through by default.
T-MPLS to MPLS-TP MigrationFollowing the approval of the first version of theITU recommendations on T-MPLS, the IETF andITU-T jointly agreed to work together to extendMPLS protocols to meet transport networkrequirements in order to ensure a smoothconvergence of MPLS-based packet transporttechnology. A Joint Working Group (JWT) wasformed between the IETF and the ITU to achievemutual alignment of requirements and protocolsand to analyse the different options for T-MPLSstandard progress. On the basis of the JWTactivity, it was agreed that the future standard-ization work will focus on defining a transportprofile of MPLS (named MPLS-TP) within IETFand in parallel aligning the existing T-MPLSRecommendations within ITU-T to the MPLS-TPwork in IETF.At their Dublin meeting in July 2008, the IETFhas initiated the work on MPLS-TP. Due to thefact that IETF MPLS-TP standard or drafts do notexist yet, we tested the implementations basedon the T-MPLS ITU-T Recommendations currentlyin force and its relevant drafts.It is our intention also to include the first imple-mentations of MPLS-TP drafts at our next event.
9
External Network to Network Interface (E-NNI)
In addition to providing transport for Ethernetservices, all edge devices in the core established anIP/MPLS L3VPN service using BGP (based on RFC4364). The Alcatel-Lucent 7750 SR7 and Cisco7606 terminated Ethernet pseudowires into this VPNproviding the potential to offer layer 3 services tocustomers which are not reachable otherwise.
EXTERNAL NETWORK TONETWORK INTERFACE (E-NNI)
Figure 3: E-NNI to the core
As we described above three different technologieswere used in the metro areas. The problem thatevery service provider then faces is to connect themetro area with the existing network core. In our testnetwork, much like in most service providernetworks, the core used MPLS for transport andservices. Therefore, we required mechanisms toallow services originating on one metro area tocross the core and be received on other metroareas.The following subsections describe the specificNetwork to Network Interface (E-NNI) solutions usedin the network.
MPLS Metro Connectivity to the CoreSeveral options exist to allow connectivity betweentwo MPLS areas. The preferred options were MPLSbased, but one option used IEEE 802.1ad ProviderBridging tags, or simply 802.1Q VLAN tags totransport services between the two areas. The LabelEdge Router (LER) in the MPLS core would strip theMPLS header from traffic before it forwarded theEthernet frames to the LER in the MPLS metro. TheS-Tag or VLAN tag would then signal to the MPLSmetro device which pseudowire to forward theframes onto. Devices using VLAN tags were Alcatel-Lucent 7450 ESS-6, ECI SR9705, and FoundryNetIron XMR 8000.The other option used to connect between adminis-tratively separated MPLS core and metros is referredto as pseudowire (PW) stitching. This involves thecreation of two pseudowires, one in each domain,and then interconnecting them either within onedevice, or with a third pseudowire between the twoedge devices. Vendors who took this approachchose the latter. In this case two MPLS labels must besignaled: the inner label (PW label) signaled byLDP, and the transport label (PSN label) signaled byeither eBGP (IPv4+label) or LDP. To facilitate thetransmission of LDP sessions, either a separate OSPFarea was enabled between the two edge devices ora static route was used. Devices taking the PWstitching approach were Cisco 7606, Juniper M10i,Juniper MX480, and Redback SmartEdge 400.
PBB-TE Connectivity to the CoreAs PBB-TE and 802.1ad are both part of the IEEEProvider Bridging domain of technologies, it is notsurprising that Provider Bridging tags weresupported across the board in the PBB-TE metrodomain. All services crossing the core into thePBB-TE cloud used S-Tags (Service Tags) to distin-guish each service between a core edge router anda PBB-TE switch. These devices included CienaLE-3300, ECI SR9705, Nortel MERS 8600, TejasTJ2030, and Tellabs 8830. One PBB-TE trunk wasconfigured between Nortel MERS 8600 and TejasTJ2030 and traversed the MPLS core.
T-MPLS Connectivity to the CoreTwo options were used to establish services over anMPLS core into a T-MPLS network. The first was touse 802.1ad S-Tags, similarly to the MPLS metro.The second option used was pseudowire stitching.The T-MPLS edge device terminated TMCs comingfrom the edges of the network and stitched them toan MPLS Ethernet pseudowire which was estab-lished with the neighboring core edge device. Thiswas done using LDP for both MPLS labels, which ranover a separate OSPF area than the core. Thisoption was tested between Alcatel-Lucent 1850TSS-40 and the Alcatel-Lucent 7750 SR7, which alsohad some services configured over staticallyconfigured MPLS pseudowires.
T-MPLS
Provider Bridging (802.1ad)LDP-based E-NNIeBGP (IPv4+label)-based E-NNIVLAN (802.1Q)
ECI
TejasTJ2030 Ciena
LE-3300
Tellabs 8830
NortelMERS 8600
Alcatel-Lucent7450 ESS-6
ECISR9705
JuniperM10i
Cisco7606
JuniperMX480 Redback
SmartEdge 400
FoundryNetIron XMR 8000
MPLS
PBB-TE
SR9705
HuaweiNE40E-4
EricssonMarconi
OMS 2400
Metro/Core Device
Static MPLS Configuration
Alcatel-Lucent1850 TSS-40
Alcatel-Lucent7750 SR7
10
Carrier Ethernet World Congress 2008 Multi-Vendor Interoperability Test
MOBILE BACKHAUL
Traditionally, the interface between mobile basestations and base station controllers has been basedon a number of parallel TDM circuits (for GSM,CDMA) or ATM connections (for the first versions ofUMTS and CDMA 2000) carried on E1 or T1 links.Several market studies show that the transportnetwork costs account for 20–30% of a mobileoperator’s operational expenditure (OPEX).
Figure 4: Mobile Backhaul scope
With the advent of high-speed data transport (HSPA)in 3G networks, with WiMAX and LTE on thehorizon, the amount of data traffic in mobilenetworks has vastly grown and will continue to doso. Mobile operators are considering mobilebackhaul over Carrier Ethernet networks, as theseprovide enough bandwidth for any predictedincrease in data traffic and are more cost effectivethan the current TDM networks.
The main issue and test focus for Mobile Backhaultransport is the migration path from TDM/ATM toconverged packet based services. Thousands ofbase stations will not be upgraded immediately ornot at all. Migration paths vary widely dependingon the specific service provider environment.In this test event, we verified a number of migrationscenarios, focusing TDM and ATM transport overCarrier Ethernet as well as clock synchronization.The following table provides an overview of thetransport requirements imposed by different mobilenetwork technologies.
Circuit Emulation Services (CES)There is a number of specifications defining circuitemulation services which could be used to supportMobile Backhaul services. During our event wetested implementations and observed demonstrationsof MEF8 and RFC 4553 specification for E1 inter-faces.During the tests and demonstrations the devices wereconnected either back-to-back, back-to-back with animpairment generator of Calnex Paragon Syncemulating a network behavior between the twodevices under test, or over the whole test network.We accepted a test or a demonstration if the twodevices performing circuit emulation were able topass E1 data over the packet based network and thedeviation of the E1 signal received from the networkcompared to its input signal was within 50 parts permillion (ppm) over 10 minutes.As shown in the CES tests back-to-back figure in total5 products from three different vendors passed thetests: Alcatel-Lucent 9500 MPR, NEC CX2600, NECPASOLINK NEO TE, RAD IPMUX-216/24, and RADMiTOP-E1/T1 hosted by the RAD ETX-202A. All testswere performed using MEF8 for encapsulation andadaptive clocking for clock synchronization. The testbetween Alcatel-Lucent 9500 MPR and RADIPMUX-216/24 was performed once with and oncewithout the optional RTP (Real Time Protocol) header.All other tests were performed without RTP. Asdescribed in RFC 4197 section 4.3.3, the usage ofRTP relaxes the tolerance requirement for the internalclocks of the devices performing CES and therefore
MobileBackhaul
CoreNetwork
RNC
BSCMSC
GGSN
SGSN
Radio Access Network
MSC — Mobile Service Switching CenterSGSN — Serving GPRS Support NodeGGSN — Gateway GPRS Support NodeBSC — Base Station ControllerRNC — Radio Network Controller
Mobile NetworkService Types
Carrier EthernetNetworkRequirements
TDM
Circ
uitE
mul
atio
n
ATM
Pseu
dow
ires
E-Lin
esSe
rvic
es
E-LA
NSe
rvic
es
E-Tr
eeSe
rvic
es
Sub
50-m
sRe
silie
ncy
Sub-
seco
ndRe
silie
ncy
Traditional GSM X X
Traditional 3G (UMTSRel. 99 / CDMA2000)
X X
Hybrid 3G offload(ATM-based voice; IPtunneled data)
X X X
Full packet-based 3G a X X
Long-Term Evolution(LTE, 4G)
X X
Mobile WiMAX a X X
a. Can be used as a fallback
11
Mobile Backhaul
decreases the probability of jitter buffer overflow orunderflow.In addition, CES was demonstrated over the wholetest network as shown in the diagram ., and testedback-to-back with the Calnex Peragon Syncimpairment tool, as shown in Figure 6: CES testsacross the network. The Calnex Paragon Syncemulated the jitter of a network path with 10 nodesand 40% traffic utilization for a more realisticscenario.
Figure 5: CES tests back-to-back
A number of microwave solutions participated in thisevent and have demonstrated their ability totransport E1 TDM data over their microwave links,namely Alcatel-Lucent 9500 MPR, Ceragon FibeAirIP-10, and NEC PASOLINK NEO. The Alcatel-Lucent9500 MPR microwave solution performed at thesame time circuit emulation service.RAD Data Communications demonstrated IETF circuitemulation (SAToP, RFC 4553) over MPLS which isvery similar to the MEF8 specification. In one casethe Circuit Emulation Service was demonstratedbetween RAD ACE-3200 and RAD ACE-3205 inMPLS metro network. The Ceragon FibeAir IP-10microwave solution was connected both betweenthe RAD ACE-3200 and E1 source, and alsobetween the RAD ACE-3200 and an MPLS metroedge device. Ceragon Networks and RAD DataCommunications demonstrated a hybrid mobilebackhaul network operation, effectively combiningnative TDM transport and Ethernet encapsulatedCES. In another test case SAToP CES was demon-strated between RAD ACE-3400 and RADACE-3205 in PBB-TE network.
Alcatel-Lucent demonstrated MEF8 CES with differ-ential clocking by using RTP (Real Time Protocol)header between Alcatel-Lucent 9500 MPR andAlcatel-Lucent 9500 MPR devices over T-MPLS metronetwork. In the same demonstration Alcatel-Lucentshowed its proprietary solution to synchronize twomicrowave endpoints over the air by transportingthe clock information from the Alcatel-Lucent 9500MPR performing the CES to another Alcatel-Lucent9500 MPR over the airFigure 6: CES Across theNetwork..
Figure 6: CES tests across the network
ATM Transport over MPLSAs described in the introduction, ATM transportservices over a Packet Switched Network (PSN) isanother key requirement for the migration of MobileBackhaul to packet switched networks. During theevent two implementations of ATM transport overMPLS as specified in RFC 4714 were tested anddemonstrated.Successful interoperability was tested betweenNokia Siemens Networks Flexi WCDMA BTS andRAD ACE-3200. The two devices encapsulated ATMdata into a statically configured MPLS pseudowireand sent the resulting MPLS packets over an IP tunnelacross the PSN. The ATM pseudowire was used totransport an ATM circuit configured between NokiaSiemens Networks RACEL, a Radio NetworkController (RNC) and mobile core network emulator,and Nokia Siemens Networks Flexi WCDMA BTS.In addition, RAD Data Communications demon-strated a statically configured ATM pseudowirebetween the RAD ACE-3205 and RAD ACE-3400devices. This pseudowire was tunneled over thePBB-TE network.
NEC CX2600Alcatel-Lucent
Alcatel-LucentRAD
NEC CX2600RAD
CalnexParagon Sync
NEC PASOLINKAlcatel-Lucent
RADAlcatel-Lucent
RAD ETX202AAlcatel-Lucent
9500 MPR
9500 MPR
9500 MPR
9500 MPR
9500 MPR NEO TE
TDM service
TDM link
Access Device
CalnexParagon Sync
CalnexParagon Syncwith MiTOP E1/T1
IPMUX-216/24
IPMUX-216/24
IPMUX-216/24
Access network
UNI
Metro network
TDM service
TDM link
RAD ACE-3205RAD ACE-3400
RAD ACE-3205RAD ACE-3200
NEC CX2600NEC CX2600
Alcatel-LucentAlcatel-Lucent9500 MPR 9500 MPR
Access Device
12
Carrier Ethernet World Congress 2008 Multi-Vendor Interoperability Test
Telco SystemsT-Marc-254
Nokia Siemens Networks
IXIA XM2IxNetwork
SIAE MICROELETTRONICA ALS
Rohde & Schwarz
NEC PASOLINK NEO
HuaweiNE5000E
Cluster System
Cisco
RADRICi-155GE
T-MPLS Metro
CeragonFibeAir IP-10
RADETX-202A
IXIA XM2IxNetwork
RADRICi-155GE
RADRICi-155GE
Harris StratexEclipse
Telco SystemsT-Marc-250
Telco SystemsT5C-24F
RAIPMUX-
HuaweiCX600-4
SpirentTestCenter
SIAECeragonFibeAir IP-10
Telco SystemsT5C-24G
MICROELETTRONICA ALS
Alcatel-Lucent1850 TSS-40 Tejas
TJ2030
Tellabs8830
RedbackSmartEdge 400
JuniperMX480
Cisco 7604
EricssonMarconi OMS 2400
TejasTJ2030
EricssonMarconi OMS 2400
ECI SRAlcatel-Lucent7750 SR7
HuaweiNE40E-4
JuniperM10i
SpirentTestCenter
MTU-s
Telco SystemsT-Metro 200
CeragonFibeAir IP-10
RADLA-210
I
RADACE-3205
Alcatel-Luc7705 SA
RADASMi-54
JuniperMX480
ADVA FSP150CC-825
ActelisML658
EricssonMarconi OMS 2400
CiscoME3400-12CS
MTU-s
JuniperMX240 NEC
CX2600
Harris StratexEclipse
Alcatel-Lucent7705 SAR
Alcatel-Lucent9500 MPR
RADACE-3200 RAD
IPMUX-216/24
SymmetricomTimeCesium 4000
EC
FlexiHybrid
ADVA FSP150CC-825
Symmetricom TimeProvider5000 PTP Grand Master
RADETX-202A
FounNetIron XM
CambridgeVectaStar
Alcatel-Lucent9500 MPR
ActelisML658
InfoVistaVistaInsight for Networks
Video Client
G
Gaming Client
7606
MPLS Metro
Alcatel-Lucent1850 TSS-40
Alcatel-Lucent5650 CPAM
SITLine ETH
+MiRICi E1/T1
MTU-s
CienaLE-311vSpirent
TestCenter
RADETX-202A
+MiRICi E1/T1
Physical Network Topology
12
Carrier Ethernet World Congress 2008 Multi-Vendor Interoperability Test
13
Mobile Backhaul
PBB-TE Metro
Metro/Core Network Device
Gigabit Ethernet
Access Device
Metro network
Access network
Aggregation Device
Network Areas
Connection Types
UNI
E-NNI
Core network
Fast Ethernet
TDMoNxE1/STM-1
ATMoNxE1/STM-1
Wireless
10 Gbit G709
RAN NC
G.SHDSL.bis
STM-16
10 Gbit Eth
Tester
Device Types
RAN BS
P Router
Aggregation network
Radio Transmission Device
SHDSL
Nokia Siemens Networks
RADETX-202A
RADETX-202A
Telco SystemsT-Marc-254
ADVA FSP150CC-825
NECPASOLINK NEO TE
RADACE-3205
RADRICi-16
RADOP-1551
RADACE-3400
Rohde & Schwarz
IXIA XM2IxNetwork
6/24
Alcatel-Lucent95000 MPR
CambridgeVectaStar
Telco SystemsT5C-XG
NEC PASOLINK NEO
HuaweiCX600-4
IXIA XM2IxNetwork
CiscoME4500
SpirentTestCenter
RADETX-202A
InfoVistaVistaInsight for Networks
Alcatel-Lucent7450 ESS-6
MTU-s
Telco SystemsT-Metro 200
Tellabs8830
NortelMERS 8600
Tejas2030
Tejas2030
Ciena LE-3300
SpirentTestCenter
IXIA XM2IxNetwork
Nokia Siemens Networks
SIAE MICROELETTRONICA ALFO
Telco SystemsT-Marc-340
Nokia Siemens NetworksFlexi WCDMA BTS
NEC PASOLINK NEO
RADEgate-100
05
Rohde & SchwarzA XM2etwork
NECPASOLINK NEO TE
NortelMERS 8600 Ciena LE-311v
NortelMERS 8600
CeragonFibeAir IP-MAX2
MTU-s
CiscoCatalyst 3750-ME
MTU-s
Telco SystemsT-Metro 200
Telco SystemsT-Marc 380
NECCX2600
RADACE-3200
10 MHz Clock
CalnexParagon Sync
SR9705hiD 6650
RACEL
y8000
Harris StratexEclipse
CiscoME-3400-2CS
ADVA FSP150CC-825
Gaming Clients
Video Source
Video Client
ApplicationDemonstrations
Video Source
Video Client
ming Client
Gaming Client
SITLine ETH
SITLine ETH
Cluster System
running onE-Tree}
running onE-LAN}
13
14
Carrier Ethernet World Congress 2008 Multi-Vendor Interoperability Test
Clock Synchronization IntroductionAcross all mobile network technologies, clocksynchronization is a topic of interest and majorconcern today. Base stations within a mobileoperator’s domain require a common clock for threereasons:
• General operation and frequency stability. Basestations need to keep their transmit frequenciesand time slots very stable to avoid interferences.
• Base station hand over. Voice calls shall notdrop when the cell phone is moving from onecell’s coverage area to the next. Clockfrequencies of the two base stations need to besynchronous to ensure that the phone cancontinue sending within its pre-assigned mobilenetwork slots nearly uninterruptedly.
• Common frequency transmission. In some mobiletechnologies, adjacent base stations transmitusing identical frequencies, leading to a largecommon frequency coverage area and allowingthe communication of end systems with multiplebase stations at the same time (MIMO). Thisnetwork service requires phase synchronizationof base station clocks to ensure that their signalsdo not extinguish each other.
The easiest way of providing a common clock is touse GPS. However, mobile operators do not alwaysprefer this solution due to technical or politicalreasons. Sometimes base stations do not havevisibility of the sky (pico cells in buildings, tunnels) orthe GPS receiver installation would be toocumbersome (femtocells at home).
Vendors offer a number of network-based clocksynchronization mechanisms. They can be selecteddepending on the precision requirements. Formobile backhaul, the base station frequency needsto be accurate to below 50 ppb (ITU-T G.812). Thenetwork clock needs to be three times more accurateto reach this goal — 16 ppb (ITU-T G.8261 draft).
Clock Synchronization Test Results
IEEE1588v2. For the first time in a public MobileBackhaul test, we verified interoperability of IEEE1588v2 based clock synchronization implementa-tions at this event. Symmetricom provided a TimePro-vider 5000 PTP Grand Master implementing the
Precision Time Protocol (PTP); Nokia SiemensNetworks’ Flexi WCDMA BTS received the PTPpackets as a slave clock over an E-Line across thebackhaul network. Calnex Solutions connected theirParagon Sync in between the master and slaveclock, witnessing the protocol exchange and inten-tionally dropping packets.
Figure 7: 1588v2 Synchronizationmeasurement
The master and slave clocks interoperated success-fully using the subset of IEEE 1588v2 Precision TimeProtocol required for frequency synchronization —the unidirectional SYNC messages. Via an E1 outputof the base station and using a Symmetricomsoftware, we examined the frequency accuracy ofthe base station. Figure 7 shows the first 85 minutesof a clock deviation measurement of the NokiaSiemens Networks Flexi WCDMA BTS synchronizedvia IEEE 1588v2 to the Symmetricom TimeProvider5000 PTP Grand Master clock. We started themeasurement after the first five minutes of deviceoperation — the amount of time the devices requirefor the initial clock synchronization. As shown in thediagram there is a peak of frequency deviation inthe first two minutes of the measurement, andanother peak at around 20–30 minutes. In any case,the deviation never exceeded 3.6 ppb (parts-per-billion). The deviation was most often measured ataround 0.6 ppb. The measured results demonstratesthe accurate synchronization of the Flexi WCDMABTS, and the test goal to achieve a frequencydeviation of below 16 ppb was fulfilled. Althoughwe did not conduct long term measurements asrequired in ITU standards due to a lack of time at thehot staging; the same test will be conducted live atCEWC for visitors to witness the clock accuracymaintained throughout the conference.For the same reasons, PTP impairments generated bythe Calnex Paragon Sync did not show visibleeffects. The base station has an internal temperature-controlled quartz as a fallback clock when theincoming IEEE 1588v2 signal is lost. This clock isaccurate enough for a couple of days of operation;we lacked the time to wait for it to degrade.
Adaptive Clocking. Another solution for somefrequency synchronization scenarios is adaptiveclocking. In this solution, the clock is regeneratedfrom the frequency of bits arriving on an emulatedTDM circuit. Assuming that the transmitter sendspackets at a known rate and precise intervals, the
Network Type
Freq
uenc
ySy
nchr
oniz
atio
n
Phas
eSy
nchr
oniz
atio
n
GSM X
3G (UMTS, CDMA2000) X
4G (LTE including MBMS) X X
4G (Mobile WiMAX) X X
15
Ethernet OAM
adaptive mode is usually accomplished on slaves byeither measuring packets inter-arrival time ormonitoring a buffer fill level (some adaptive clockrecovery mechanisms may also use timestamps).Adaptive clock works only for constant bit rateservices.As described in the "Circuit Emulation Service"chapter, the Alcatel-Lucent 9500 MPR, NECCX2600, NEC PASOLINK NEO TE, RADIPMUX-216/24, and RAD MiTOP-E1/T1 hosted bythe ETX-202A have successfully demonstrated andtested adaptive clocking.In addition we measured the value of the frequencydeviation as demonstrated between the RADACE-3200 and RAD ACE-3205 over a longmeasurement time. We connected the SymmetricomTimeCesium 4000 Master Clock to the RADACE-3200, and verified that the frequency accuracywas better than 16 ppb.
ETHERNET OAMEANTC interoperability events have integratedEthernet Operations, Administration andManagement (OAM) testing since 2006. Severaldifferent protocols fall under the category of EthernetOAM. In this event we have tested Ethernet in the
First Mile (EFM), and Connectivity FaultManagement (CFM), standardized by the IEEEunder 802.3ah and 802.1ag respectively, Y.1731,standardized by ITU-T, and E-LMI, specified by MEF.Over the past years we have seen a significantincrease in support in this area – in the first eventfour vendors tested their CFM implementations andfive vendors tested their EFM code. At our currentevent 12 vendors tested their EFM and CFM imple-mentations.Our service provider panel placed a high value onboth Ethernet OAM test areas and with the inclusionof both EFM and CFM in the new MEF 20 “UserNetwork Interface (UNI) Type 2 ImplementationAgreement” technical specifications a clearcontinuous need for testing has been established
Link OAMLink OAM is the name used by the Metro EthernetForum (MEF) to refer to clause 57 of the IEEE 802.3standards where OAM is defined for Ethernet in theFirst Mile. The protocol monitors the health andoperations of the UNI’s physical layer. The MEFrequires the usage of Link OAM between the UNI-Nand UNI-C starting from UNI type 2.2 and recom-
Discovery followed by
Dying Gasp Messages
Alcatel-Lucent7450 ESS-6
Telco SystemsT-Marc-380
Tellabs8830
CiscoCatalyst 3750-ME
HuaweiCX600-4
ActelisML658
ADVA FSP150CC-825
Loopback Mode
CeragonFibeAir IP-10
JuniperMX240
MTU-s
Cisco7604 Cisco
ME-3400-12CS
SpirentTestCenter
IXIA XM2IxNetwork
RADLA-210
RADETX-202A
Telco SystemsT-Marc-250
FoundryNetIron
XMR 8000
MTU-s
CienaLE-311v
Telco SystemsT5C-24F
Telco SystemsT-Marc-340
MTU-sRADRICi
155GE
RADRICi 16
JuniperMX480
MTU-sAccessDevice
AggregationDevice
MTUSwitch
Tester
Metro/CoreDevice
Figure 8: Ethernet Link OAM test results
16
Carrier Ethernet World Congress 2008 Multi-Vendor Interoperability Test
mends the use of the protocol starting from UNItype 2.1.The idea behind the protocol is to assist operators inlocalizing last mile physical layer errors. The mostlogical location in the network where the protocolcould be used is between the Provider Edge device(a router or a switch) and the customer premisesdevice. Both devices can identify themselves to eachother and communicate problems with each other.The Provider Edge device can use a palette of toolsto verify that it can reach the customer premisesdevice therefore saving the provider the extreme costof sending engineers to the customer site to verifyphysical link issues.The following products successfully participated inthe Link OAM tests discovering and setting eachother in loopback mode: Actelis ML658, ADVA FSP150CC-825, Alcatel-Lucent 7450 ESS-6, CeragonFibeAir IP-10, Cisco 7604, Cisco Catalyst 3750-MEand Cisco ME-3400-2CS, Ciena LE-311v, FoundryNetIron XMR 8000, Huawei CX600-4, Ixia XM2IxNetwork, Juniper MX240, RAD RICi155GE, RADETX-202A, RAD LA-210 and RAD RICi-16, SpirentTestCenter, Telco Systems T-Marc-250, TelcoSystems T-Marc-380, Telco Systems T-Marc-340,Telco Systems T5C-24F, and Tellabs 8830.We performed an additional test within this areaverifying that a device, usually on the customerpremises is able to notify the Provider Edge device
that the loss of signal is due to the customer premisedevice being shut down. The message carried in theLink OAM frame is aptly called Dying Gasp. Threevendor pairs successfully performed this test: ADVAFSP 150CC-825 and Juniper MX240, Cisco 7604and Juniper MX480 and Ciena LE-311v with TelcoSystems T5C-24F.
Service OAMThe IEEE 802.1ag standard defines end-to-endEthernet based OAM mechanisms which arereferred to by the MEF as Service OAM. The supportfor Service OAM is mandatory starting from UNItype 2.1. In contrast to link OAM the major use ofCFM for service providers and enterprises is to verifyconnectivity across different management domains.A carrier can define a management domain level tobe used internally while allowing their customers toverify end-to-end connectivity over the network usinga different CFM level.Since the 802.1ag standard has been published inDecember 2007 this has been the first interopera-bility event where we could specify a finishedversion of the standards for testing which simplifiedthe testing. From 12 vendors who participated in thetesting, 11 had standards based implementations.For this interoperability event we added a test at therequest of the participating vendors to the Service
Continuity Check, Linktrace, Loopback Tests
Alcatel-Lucent7450 ESS-6
NECPASOLINK
NortelMERS 8600
CiscoCatalyst 3750-ME
ActelisML658
ADVA FSP150CC-825
CeragonFibeAir IP-10
JuniperMX240
MTU-s
ECISR9705 Cisco
ME-3400-12CS
SpirentTestCenter
IXIA XM2IxNetwork
RADLA-210
RADETX-202A
Telco SystemsT-Marc-250
FoundryNetIron
XMR 8000
NECCX2600
Telco SystemsT-Marc-254
Telco SystemsT-Marc-340
MTU-s
RADRICi
155GE
JuniperMX480
NEO TE
Continuity Check, Linktrace, Loopback Tests
Continuity Check, Loopback Tests, RDI
MTU-sAccessDevice
AggregationDevice
MTUSwitch
Metro/CoreDevice
Tester
and Remote Defect Indication (RDI)
Figure 9: Service OAM Test Results
TejasTJ2030
Cisco7604
CiscoME4500
17
Ethernet OAM
OAM area: Ethernet Remote Defect Indication(ETH-RDI). This message type, integrated into theContinuity Check Messages (CCMs), communicatesto a remote Maintenance End Point (MEP) that adefect condition has been encountered. When adefect condition is encountered on a MEP, that MEPwill set the RDI bit in CCMs for all MaintenanceEntity Group (MEG) levels affected. When the defectcondition is repaired or removed, the MEP will resetthe RDI bit in the appropriate CCMs. This messagetype is particularly useful as a way to notify a remoteMEP about MAC layer problems, changes to theconfigurations and such error conditions as suddenunidirectional connectivity.The following vendors successfully tested ServiceOAM’s Continuity Check, Linktrace and Loopbackfeatures as well as Remote Defect Indication: ActelisML658, ADVA FSP 150CC-825, Alcatel-Lucent7450 ESS-6, Ceragon FibeAir IP-10, ECI SR9705,Foundry NetIron XMR 8000, Ixia XM2 IxNetwork,Juniper MX240 and Juniper XM480, NEC CX2600and PASOLINK NEO TE, Nortel MERS 8600, RADRICi155GE, RAD ETX-202A, RAD LA-210, RADRICi-16, Spirent TestCenter, Telco SystemsT-Marc-254, Telco Systems T-Marc-250, TelcoSystems T-Marc-340, and Tellabs 8830.Cisco Systems demonstrated its pre-standard CFMimplementation between its Catalyst 3400-12CS,7604, ME4500, Catalyst 3750-ME, and theME-3400-2CS. All devices were able to use CFM todiscover each other, exchange Continuity CheckMessages, recognize and signal failure conditionsusing Remote Defect Indicator (RDI) and AlarmIndication Signal (AIS) when failure were simulatedin the demonstration topology and use loopbackand linktrace messages.
Performance MonitoringThe ITU-T specification Y.1731 defines two messagetypes for calculating loss and delay between twoEthernet OAM endpoints. Loss MeasurementMessages (LMMs) are sent which should be repliedto on arrival with Loss Measurement Replies (LMRs).The initiating device can make a calculation ofaverage loss by comparing the number of framessent by the initiating end with those received at thefar end. Delay is measured in a similar way, calcu-lating the time it takes for a Delay MeasurementReply (DMR) to come back for each DelayMeasurement Message (DMM). Similar to CFM, thistool helps both customers to learn about the servicethey are receiving, and operators to learn about theservice they are providing.These tests were performed using the Paragon Syncimpairment device provided by Calnex Solutions.First, messages were exchanged without anyimpairment to show a baseline interoperability.Then, loss and delay impairments were made to testthe accuracy of the calculations.The following devices tested their implementations ofthe two protocols: Ciena LE-3300, NEC CX2600,Nortel MERS 8600, RAD ETX-202A, and RAD
LA-210. In all cases LMMs and DMMs were repliedto with LMRs and DMRs. Despite this, many devicesdid not properly calculate frame loss. Delay calcula-tions on the other hand showed a high degree ofaccuracy between the different devices.
Figure 10: Performance Monitoring tests
While Performance Monitoring as specified in ITU-Tstandard Y.1731 has made its way into the test planfor previous EANTC interoperability events, this yearmarked the first set of results. This is underlined bythe amount of issues found in the implementationsunder test.
E-LMIThe current UNI Type 2 Implementation Agreement(MEF 20) states in section 9 that all UNI-C andUNI-N of type 2.2 must support Ethernet LinkManagement Interface (E-LMI). MEF 16 technicalspecification defines procedures and protocols usedfor enabling automatic configuration of the customerequipment to support Metro Ethernet services inaddition to relaying UNI and EVC status informationto the customer equipment.In the test case designed to test interoperabilitybetween E-LMI implementations we incorporated anadditional step in which metro devices willpropagate remote status indication over the EVCsand will use E-LMI to relay the information to the CEdevice. We were able to test the first half of the testcase between Alcatel-Lucent 7450 ESS-6 and Cisco7604 showing that the Alcatel-Lucent router wasable to notify the Cisco router using LDP TLVs aboutits Access Circuit (AC) being down. Due to lack oftime we did not verify the propagation of themessage to the CE device using E-LMI.
Loss Measurement Messages Exchanged
Delay Measurement Messages Exchanged
Impairment Device
Aggregation Device
Access Device
Metro Device
CienaLE-3300
RADETX-202A
NortelMERS 8600
NECCX2600
RADLA-210
CalnexParagon Sync
18
Carrier Ethernet World Congress 2008 Multi-Vendor Interoperability Test
RESILIENCE AND FAULTDETECTION
One of the key aspects of carrier grade transporttechnologies is SONET/SDH-like resiliency mecha-nisms and fault detection. Based on historicalprecedence, SONET/SDH’s 50 ms restorationcapabilities has been used as the measurement stickfor all transport technologies to follow and thesedays, with Voice over IP (VoIP) and Mobile Backhaulwe see a real need for 50 ms restoration time.The sections to follow depict several failover andrestoration tests that were performed during theevent. We tested each transport technology’sresilience protocols interoperability and augmentedthese by native fault detection mechanisms (CFM forPBB-TE and T-MPLS and Bidirectional Fault Detection(BFD) for MPLS). We focused our Link Aggregationtests on the UNI therefore providing a complete end-to-end resilience and fault detection story.
Link AggregationSeveral physical Ethernet ports of Ethernet switchescan be bundled into a single logical Ethernetinterface. This capability is used to increase theamount of bandwidth and/or to provide a linkprotection mechanism. The capability is specified inIEEE 802.3 clause 43, and commonly known as802.3ad or just LAG (Link Aggregation Group). Inorder to create or change the members of a LAGgroup dynamically, Link Aggregation ControlProtocol (LACP) has been standardized and is usedbetween two Ethernet devices providing LAG.The MEF specified LAG as a protection mechanismon the UNI. Devices supporting MEF UNI type 2.2must support LAG and LACP which led us to require,as opposed to previous years, that vendorsparticipating in this test will use LACP and not thestatic configuration of link aggregation groups.In our lab we successfully tested LAG implementa-tions of 10 vendors in total, two of them wereanalyzer vendors. As the test was defined fordevices that implement UNI functionality weseparated the participants into UNI-C and UNI-Ndevices. At the UNI-C were ADVA FSP 150CC-825,Ceragon FibeAir IP-10, Ixia XM2 IxNetwork andSpirent TestCenter, while on the UNI-N Alcatel-Lucent 7450 ESS-6, Ciena LE-3300, ECI SR9705,Nokia Siemens Networks hiD 6650, RedbackSmartEdge 400, Telco Systems T5C-24G, and TelcoSystems T-Metro-200. We first verified that the linkaggregation groups were established between thetwo devices and then measured the failover time bypulling out of the primary link, followed by ameasurement of the restoration time by reconnectingthe primary link. In almost all cases we measuredfailover time below 31 ms, and restoration timebelow 25 ms. In one case we measured failover timeof 550 ms and around two seconds restoration time.Apart from the UNI, Link Aggregation can be used
in the core of the network at the External Network toNetwork Interfaces (E-NNI) or to provided addedlink capacity. In addition to the LAG tests at the UNI,we performed some LAG tests between directlyconnected devices within the metro and core areanetworks. The test pairs included: Alcatel-Lucent7750 SR7 and Ericsson Marconi OMS 2400, CiscoME-3400-12CS and Juniper MX480, NokiaSiemens Networks hiD 6650 and Telco SystemsT-Metro-200, and Spirent TestCenter with FoundryNetIron XMR 8000.
MPLS ProtectionSeveral resilience mechanisms exist in MPLS andmost have been tested in previous EANTC interoper-ability events. MPLS Fast Reroute (FRR) is one suchmechanism that was tested in 2006 and 2007 (thewhite papers are available on EANTC’s web site).MPLS Fast Reroute provides link and node protectionfor Label Switched Paths (LSPs), therefore, protectingthe services running within the LSPs. Since 12vendors participated in the MPLS metro area, someof which for the first time, the event provided themwith the opportunity to test their implementationsagainst others that were not previously tested.
AccessAggregation
Ixia XM2Nokia Siemens
ADVA FSPAlcatel-Lucent
Ixia XM2Ciena LE-3300
SpirentECI SR9705
Ixia XM2Telco Systems
Ixia XM2Telco Systems
Networks hiD 6650 IxNetwork
IxNetwork
7450 ESS-6 150CC-825
TestCenter
IxNetwork
IxNetwork
CeragonRedbackSmartEdge 400
T5C-24G
T-Metro-200
Access Device
Aggregation Device
FibeAir IP-10
LAG Members
Figure 11: LACP test pairs
19
Resilience and Fault Detection
In total 14 different MPLS Fast Reroute tests wereperformed during the interoperability test event. In12 of the combinations the MPLS Fast Reroute wastriggered on the Point of Local Repair (PLR) by a Lossof Signal (LOS) which was simulated by pulling theactive link from the PLR. The following devices partic-ipated in the role of the Point of Local Repair (PLR):Alcatel-Lucent 7450 ESS-6, Alcatel-Lucent 7750SR7, Cisco Catalyst 3750-ME, ECI SR9705,Foundry NetIron XMR 8000, Huawei CX600-4,Huawei NE40E-4, Nokia Siemens Networks hiD6650, Redback SmartEdge 400, and Telco SystemsT-Metro-200. The Merge Point (MP) is the routerwhich merges the backup and primary segments ofan MPLS tunnel. The following devices participatedas MPs: Alcatel-Lucent 7450 ESS-6, Cisco 7604,Huawei CX600-4, Huawei NE40E-4, NokiaSiemens Networks hiD 6650, Redback SmartEdge400, Telco Systems T-Metro-200, and Tellabs 8830.In 8 test combinations we measured failover timesbelow 30 ms. In one test combination we measuredfailover time below 100 ms, and in 3 test combina-tions we measured failover times below 380 ms andabove 100 ms. The importance of the test, however,was the protocol interoperability between the PLRs
and the MPs therefore we spent no time on trying toreconfigure the devices for faster failover times.In two MPLS Fast Reroute test combinations thetunnel failure was recognized by Bidirectional FaultDetection protocol (BFD). BFD allows the routers todetect failures of non-directly attached links andsignal the failure to its neighbors quicker than theIGP used in the network. In both tests the BFD trans-mission interval was configured to 50 ms.In the test combination between Cisco 7604 (actingas PLR) and Juniper MX480 (acting as MP) the BFDfailure detection was bound to the MPLS RSVP-TEtunnels configured for MPLS Fast Reroute. In this testout of service time of 154 ms was achieved.In the test combination between Foundry NetIronXMR 8000 and Tellabs 8830 the BFD failuredetection was bound to the OSPF routing process.The failure triggered by BFD caused the rerouting inOSPF process. This result in rerouting of RSVP-TEmessages and creation of a new segment of MPLStunnel. We measured 207 ms out of service time forthis test.
PLR Mid-Point MP
MPLS Metro/Core
PLR Mid-Point MP
MPLS Metro/Core
Huawei NE40E-4Alcatel-Lucent
7750 SR7
Huawei NE5000E
Tellabs 8830Cisco
Catalyst 3750-ME
Huawei CX600-4Telco SystemsT-Metro-200
NSN hiD 6650
Alcatel-Lucent7450 ESS-6
Telco SystemsT-Metro-200
Alcatel-Lucent
NSN hiD 6650
Alcatel-Lucent
Telco SystemsT-Metro-200NSN hiD 6650
Telco SystemsT-Metro-200
Juniper MX480
Cisco 7604
Telco SystemsT-Metro-200
Tellabs 8830
RedbackSmartEdge 400
7450 ESS-6
7450 ESS-6
MPLS switch Working tunnelProtection tunnel
Telco SystemsT-Metro-200
Redback
Tellabs 8830
Alcatel-Lucent7450 ESS-6
Telco Systems
NSN hiD 6650
Telco SystemsTellabs 8830
Foundry NetIronXMR 8000
Huawei NE5000E
SmartEdge 400
T-Metro-200
T-Metro-200
ECI SR9705
Redback SmartEdge 400
NSN hiD 6650
Huawei CX600-4Redback
SmartEdge 400
Tellabs 8830
Alcatel-Lucent7750 SR7
Huawei NE5000E
Huawei NE40E-4
Alcatel-Lucent7450 ESS-6NSN hiD 6650
Huawei CX600-4
Tellabs 8830
RedbackSmartEdge 400
Figure 12: MPLS Fast Reroute test pairs
20
Carrier Ethernet World Congress 2008 Multi-Vendor Interoperability Test
Figure 13: BFD test participants
Dual Homed MTU-sIn VPLS networks a hierarchical model can beinstalled by using Multi-Tenant Unit Switches (MTU-s)to offload the learning of MAC addresses and cutdown drastically the MAC tables on the VPLS PEs.However, as these spoke MTU-s connections are nota complete part of the MPLS network, inherent MPLSresiliency mechanisms may not be available.Therefore, the VPLS RFC (4762) describes a dualhomed model, which was successfully tested by theCiena LE-311v versus the Cisco 7604 and JuniperMX480 PEs, and by the Telco Systems T-Metro-200versus the ECI SR9705 and Nokia SiemensNetworks hiD 6650 PEs.
PBB-TE ProtectionResiliency in the PBB-TE domain was accomplishedby defining a protection PBB-TE trunk for a workingtrunk. In case of the single homed access devices theworking and protection trunks had the sameendpoints, but different mid-point PBB-TE switches. Incase of the dual homing, a single access device wasconnected to two different PBB-TE switches, so thatone endpoint of the working and protection trunkswas different.In both cases, the detection was done by trunkendpoint switches using CFM (CFM is described inthe Service OAM section). In almost all cases theContinuity Check Messages (CCM) transmissioninterval was configured to 10 milliseconds (ms), andin one case to 3.3 ms.The four vendors participating in the PBB-TE cloudwere able to show PBB-TE protection interoperability,as shown in the figure 14. In most cases the failovertime was below 51 ms, and restoration time below5 ms. In one case the restoration time was 718 ms.The high restoration time was explained by differ-ences between implementations. Some vendorsshutdown traffic on a trunk when they revert over tothe restored primary trunk and drop any traffic stillrunning on the backup trunk. Other vendors continue
to receive traffic on both trunks, but only transmit onone trunk. This ensures that the traffic is still receivedand reaches the destination.
T-MPLS ProtectionMultiple protection mechanisms exist in T-MPLS. BothT-MPLS path (T-MPLS path is equivalent to an MPLStunnel) and T-MPLS channel (a T-MPLS channel isequivalent to an MPLS pseudowire) can beprotected. During this event we demonstrated onlythe per path protection mechanisms.The T-MPLS linear 1:1 and 1+1 path protectionschemes were demonstrated by three EricssonMarconi OMS 2400 devices for 10 GigabitEthernet, STM-16 and 10 Gigabit G.709 interfaces.The protection schemes required two paths to bebuild to the same destination. In the 1:1 protection
Cisco 7604 Juniper MX480
Juniper MX480
PLR Mid-Point MP
Tellabs 8830Foundry NetIron
XMR 8000
Huawei NE5000E
MPLS Metro/Core
MPLS switch Working tunnelProtection tunnelBFD session
Ixia XM2 IxNetworkTejas TJ2030PBB-TE Metro
Working pathProtection path
PBB-TE Switch
Tejas TJ2030Tejas TJ2030
Nortel
Nortel MERS 8600
Ciena LE-311v2MERS 8600
Nortel MERS 8600
Nortel
Ciena LE-3300
MERS 8600Tejas TJ2030
Tejas TJ2030
Ixia XM2 IxNetwork
Nortel
Nortel MERS 8600
Ciena LE-311v2MERS 8600
Ciena LE-3300
Ciena LE-311v2
Tejas TJ2030
Nortel
Ciena LE-311v2
Nortel
Ciena LE-3300
NortelMERS 8600MERS 8600
Ixia XM2 IxNetwork
Ciena LE-311v2
Ciena LE-3300
NortelMERS 8600
MERS 8600
Figure 14: PBB-TE protection results
21
Management and SLA Reporting
one path is declared as active and the other is set inbackup mode. When the active path fails traffic isswitched to the backup path. The second scheme,1+1 protection, replicate all frames across bothactive and backup paths such that when the primarypath fails, the backup path is already carrying thelost frames. In almost all cases Ericsson demon-strated the failover and restoration times below35 ms for 1+1 protection and failover times below30 ms for 1:1 protection. The restoration time for1:1 protection was under 0.5 ms. In one test run wemeasured 76 ms failover time over 10 GigabitEthernet link for 1+1 protection.Alcatel-Lucent demonstrated with the TSS-40 devicesa pre-standard G.8132 T-MPLS ring protectionimplementation over STM-16 interfaces. In itsdemonstration Alcatel-Lucent showed failover timesbelow 30 ms and restoration time below 16 ms. Thetwo vendors already showed T-MPLS protectioninteroperability during EANTC’s Mobile Backhaulevent in January 2008 (report available onEANTC’s web site).The T-MPLS demonstration results are summarized inthe figure above.
MANAGEMENT AND SLAREPORTING
Since the inception of EANTC’s interoperabilityevents, we have been trying to interest managementand Service Level Agreement (SLA) reportingvendors to join the event and to answer thechallenge put forth by many service providers ofmeasuring and reporting on multivendor networkinfrastructure. Especially these days whenconverged networks are meant to support any typeof service, from residential Triple Play to sensitiveMobile Backhaul traffic, we see the need to monitor,measure and report on SLA performance in thenetwork.A customer will always be more impressed andlikely to stay with a provider when, throughproactive monitoring, problems are solved beforethey affect the end customer and SLAs are met.InfoVista, using VistaInsight for Networks, was ableto demonstrate its multivendor SLA monitoring andreporting capabilities by measuring jitter, framedelay, frame delivery ratio, interface utilizationstatistics, and Ethernet OAM measurements on theADVA FSP 150CC-825 for an EVC with another FSP150CC-825, Alcatel-Lucent SAM, and CiscoME-3400-12CS for an EVC with the Cisco Catalyst3750-ME. In addition, VistaInsight for networksidentified and monitored SNMP Management Infor-mation Base (MIB) objects on the participatingdevices from Cisco Systems, ECI Telecom, HuaweiTechnologies, Foundry Networks, Juniper Networks,Nortel, and Tellabs.Alcatel-Lucent demonstrated the 5650 Control PlaneAssurance Manger (CPAM), a vendor agnostic IP/MPLS control plane management solution, whichprovided real-time IGP topology maps, control planeconfiguration, and a look into route advertisementswithin the layer 3 services. The tool was helpfulsince many configurations were being made bymany different operators, helping to quickly identifyconfiguration issues.
EditorsThis document has been edited by Jambi Ganbar,Sergej Kaelberer, Jonathan Morin, Bionda Mueffke,Carsten Rossenhoevel and Gabriele Schrenk.
Alcatel-LucentAlcatel-Lucent
T-MPLS Metro
T-MPLS switch
T-MPLSTSS-40 TSS-40G.8132 draft protection
T-MPLS linear1+1 Protection
10 Gbit G709STM-1610 Gbit Ethernet
Ericsson MarconiOMS 2400
Ericsson MarconiOMS 2400
Ericsson MarconiOMS 2400T-MPLS linear
1+1 ProtectionEricsson Marconi
OMS 2400Ericsson Marconi
OMS 2400
Ericsson MarconiOMS 2400
T-MPLS linear1:1 Protection
Ericsson MarconiOMS 2400
Ericsson MarconiOMS 2400
Ericsson MarconiOMS 2400
Working pathProtection path
Figure 15: T-MPLS protection
19
22
Carrier Ethernet World Congress 2008 Multi-Vendor Interoperability Test
ACRONYMS
Term Definition
AC Access Circuit
AIS Alarm Indication Signal
ATM Asynchronous Transfer Mode
B-MAC Backbone MAC
BFD Bidirectional Fault Detection
BGP Border Gateway Protocol
BRAS Broadband Remote Access Server
BSC Base Station Controller
CCM Continuity Check Message
CDMA Code Division Multiple Access
CE Customer Edge
CE-VLAN
Customer Edge Virtual LAN
CES Circuit Emulation Service
CFM Connectivity Fault Management
CPE Customer Premise Equipment
DMM Delay Measurement Message
DMR Delay Measurement Reply
DSL Digital Subscriber Line
E-LAN A multipoint-to-multipoint Ethernetservice. A LAN extended over a widearea
E-Line Point-to-Point Ethernet Service similarto a leased line ATM PVC or FrameRelay DLCI
E-LMI Ethernet Link Management Interface
E-NNI External Network-to-Network Interface
EFM Ethernet in the First Mile
ERPS Ethernet Ring Protection Switching
EVC Ethernet Virtual Connection
EVPL Ethernet Virtual Private Line
FRR Fast ReRoute
GSM Global System for Mobile
HSPA High-Speed Packet Access
IGP Internal Gateway Protocol
IS-IS Intermediate System to IntermediateSystem
LACP Link Aggregation Control Protocol
LAG Link Aggregation Group
LDP Label Distribution Protocol
LER Label Edge Router
LMM Loss Measurement Message
LOS Loss Of Signal
LSP Label Switched Path
LTE Long-Term Evolution (4th generation3GPP mobile services)
MAC Media Access Control
MBMS Multimedia Broadcast MulticastServices, integral part of LTE
MBMS Multimedia Broadcast MulticastService
MEG Maintenance Entity Group
MEP Maintenance End Point
MIMO Multiple-Input and Multiple-Output
MPLS Multi-Protocol Label Switching
MPLS-TP MPLS Transport Profile
MSC Mobile Switching Center
MTU-s Multi Tenant Unit Switch
OAM Operations, Administration andMaintenance
OPEX OPerating EXpenditure
OSPF Open Shortest Path First
PBB Provider Backbone Bridge
PBB-TE Provider Backbone Bridge TrafficEngineering
PE Provider Edge
PLR Point of Local Repair
PLSB Provider Link State Bridging
ppb parts-per-billion
ppm parts-per-million
PSN Packet Switched Network
PTP Precision Time Protocol
PW PseudoWire
QAM Quadrature Amplitude Modulation
QoS Quality of Service
RDI Remote Defect Indication
RFC Request For Comments
RNC Radio Network Controller
RSTP Rapid Spanning Tree Protocol
RSVP-TE Resource reSerVation Protocol TrafficEngineering
RTP Real Time Protocol
S-Tag Service Tag
SAToP Structure-Agnostic Time Division Multi-plexing (TDM) over Packet
SGSN Serving GPRS Support Node
SLA Service Level Agreement
T-MPLS Transport MPLS
TMC T-MPLS Channel
TMP T-MPLS Path
UMTS Universal Mobile Telecommunica-tions System
UNI User-Network Interface
VLAN Virtual Local Area Network
VoIP Voice over IP
VPLS Virtual Private LAN Service
VPN Virtual Private Network
VPWS Virtual Private Wire Service
Term Definition
23
References
REFERENCES
Ethernet Services Attributes Phase 2 (MEF 10.1)Requirements and Framework for Ethernet Service Protection in Metro Ethernet Networks (MEF 2)Circuit Emulation Service Definitions, Framework and Requirements in Metro Ethernet Networks (MEF 3)Metro Ethernet Network Architecture Framework - Part 1: Generic Frame-work (MEF 4)Ethernet Service Definitions (MEF 6)Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks (MEF 8)Abstract test suite for Ethernet Services at the UNI (MEF 9)User Network Interface (UNI) Requirements and Framework (MEF 11)User Network Interface (UNI) Type 1 Implementation Agreement (MEF 13)Abstract Test Suite for Traffic Management Phase 1 (MEF 14)Ethernet Local Management Interface (E-LMI) (MEF 16)User Network Interface (UNI) Type 2 Implementation Agreement (MEF Ballot)Provider Bridges (IEEE 802.1ad-2005)Provider Backbone Bridges (IEEE 802.1ah, draft 4.2)Provider Backbone Bridges Traffic Engineering (IEEE 802.1qay, draft 3)Shortest Path Bridging (IEEE 802.1aq)Media Access Control (MAC) Bridges (IEEE 802.1D)Media Access Control (MAC) Bridges Amendment 2:Rapid Reconfiguration (IEEE 802.1W)Virtual Bridged Local Area Networks (IEEE 802.1Q)Link Aggregation Control Protocol (IEEE 802.3ad)Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications.Amendment: Media Access Control Parameters, Physical Layers, and Management (IEEE Std 802.3ah-2004)Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management (IEEE 802.1ag-2007)Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) (RFC 4447)Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling (RFC 4761)Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling (RFC 4762)Fast Reroute Extensions to RSVP-TE for LSP Tunnels (RFC 4090)BGP/MPLS IP Virtual Private Networks (VPNs) (RFC 4364)Architecture of Transport MPLS (T-MPLS) Layer Network (ITU-T G.8110.1)Interfaces for the Transport MPLS (T-MPLS) Hierarchy (ITU-T G.8112)Characteristics of Multi Protocol Label Switched (MPLS) Equipment Func-tional Blocks (ITU-T G.8121)Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks (RFC 4717)Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) (RFC 4553)BFD For MPLS LSPs (draft-ietf-bfd-mpls-06.txt)Bidirectional Forwarding Detection (draft-ietf-bfd-base-08.txt)Generic Application of BFD (draft-ietf-bfd-generic-04.txt)BFD for IPv4 and IPv6 (Single Hop) (draft-ietf-bfd-v4v6-1hop-08.txt)Circuit Emulation Services Interoperability Specification, Version 2.0 (ATM Forum af-vtoa-0078.000, January 1997,ftp://ftp.atmforum.com/pub/approved-specs/af-vtoa-0078.000.pdf)Framework for MPLS in Mobile Backhaul Networks (IP/MPLS Forum 2007.102.03)Timing and synchronization aspects in packet networks (ITU-T G.8261/Y.1361)OAM Functions and Mechanisms for Ethernet Based Networks (ITU-T Y.1731)
EANTC AGEuropean Advanced Networking Test Center
IIR Telecoms
Einsteinufer 1710587 Berlin, GermanyTel: +49 30 3180595-0Fax: +49 30 [email protected]
29 Bressenden PlaceLondon SW1E 5DR, UKTel: +44 20 7017 7483Fax: +44 20 7017 [email protected]
This report is copyright © 2008 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 containedherein.All brand names and logos mentioned here are registered trademarks of their respective companies in the UnitedStates and other countries.v1.1