new revenue streams with mpls service differentiation · pdf filenew revenue streams with mpls...

New Revenue Streams WithMPLS Service Differentiation

PUBLIC INTEROPERABILITY EVENTTEST PLAN AND RESULTS

MPLS World Congress 2004 Public Interoperability Event

IntroductionThis interoperability event has been organized bythe MPLS & Frame Relay Alliance and the Euro-pean Advanced Networking Test Center (EANTC),and hosted by Upperside.

The interoperability test scenarios were performedusing a multi-vendor network of real MPLS routers,complemented by emulators. Test methodologieswere checked and improved throughout the testing.The end result was that the network was success-fully constructed. This achievement, along with theadvantages and capabilities of this technology, willbe demonstrated at the MPLS World Congress inParis, February 11–13, 2004. The demo was hot-staged at EANTC labs in Berlin, Germany, inJanuary 2004.

The test scenarios were designed specifically forthis showcase, based upon the experiences ofprevious interoperability test events. They coverednew MPLS capabilities which have not been shownbefore. The focus was on demonstrating differenti-ated services over MPLS and MPLS traffic engineer-ing. Multi-vendor MPLS/BGP VPNs andLayer 2 Ethernet VPNs (Martini and VPLS) wereconfigured to prove that services were traffic engi-neering-enabled and could process differentiatedservices.

To ensure the success of the event, a one week hot-staging event with all the participating vendorswas conducted before the MPLS World Congress. Ittook place at the EANTC (European AdvancedNetworking Test Center) in Berlin, Germany. Thetest plan was defined by the InteroperabilityWorking Group of the MPLS & Frame Relay Alli-ance, including EANTC and UNH IOL (Universityof New Hampshire Interoperability Lab).

Participants and DevicesThe following companies and devices demon-strated their interoperability in the test event:

Hotstaging at EANTC lab(Berlin, Germany)

Agilent Technologies RouterTester

Alcatel 7670 RSP

Avici Systems QSR

Cisco Systems 1240412406

Ixia 1600T

Marconi BXR 48000

Alcatel/Native Networks ISA PR & 1662SMC

Navtel Communications InterWatch 95000

Nortel Networks Shasta 5000 BSN

RAD DataCommunications

IPmux-1IPmux-1000

Riverstone Networks RS8000

Tellabs 8820

2


Test Areas and Test PlanThis time, the interoperability evaluation focusedthe transport of differentiated services a multi-vendor MPLS backbone supporting MPLS trafficengineering.

Based on the guaranteed backbone transport,multi-vendor MPLS virtual private networks (VPNs)were established to demonstrate that VPNs canbenefit from the enhanced backbone services.

The following section describes the test plan indetail. Results are documented on page 5.

MPLS Traffic Engineering AndDifferentiated Services

The MPLS & Frame Relay Alliance test planmpls2003.149.03 was used for this section.

The tests asked to enable OSPF-TE routing and toensure full-mesh exchange of dynamic routes in theMPLS backbone. Based on a network-wide agreedper-hop behavior configured on each device, multi-vendor constraint-based MPLS tunnels should beestablished using the signalling protocol RSVP-TEand the relevant extensions for MPLS Diff-Serv.

Next, transport of emulated application traffic inthe Diff-Serv classes Assured Forwarding (AF),Expedited Forwarding (EF) and Best Effort classesshould be configured at the label edge routers. Amapping between per-hop behaviors and experi-mental bit settings (PHB-EXP mapping) wasrequired; the correct prioritization of the per-hopbehavior at the MPLS layer during congestion atingress, transit, and egress MPLS routers should beensured by sending traffic and creating congestionpoints at ingress and transit MPLS routers.

There are two different options for the creation ofconstraint-based label switched paths: The E-LSPswhere the per-hop behavior is inferred from theexperimental bit setting in each labeled packet,and the L-LSPs where each per-hop behavior groupof traffic uses its own label switched path. The testplan focused both E-LSPs and L-LSPs, depending onvendor support.

The last test cases dealt with real constraint-basedrouting. Since OSPF-TE continuously updates infor-mation about the reserved bandwidth in the MPLSbackbone network, it is possible to calculate bestroutes at the ingress label edge router based on thecurrent network usage. The ability of MPLS routersto explicitly select a route based on traffic classand reserved bandwidth, and to establish a label-switched path using this route, was verified in thissection.

Virtual Private LAN Service (VPLS)and Ethernet Point-to-Point VPNs

The MPLS & Frame Relay Alliance test plansmpls2003.091.00 and mpls2003.092.00 wereused for the tests in this section. They covered:

• Label Binding Distribution via targeted LDPsessions between the provider edge routers

• Data encapsulation of Ethernet and taggedEthernet frames

• Data encapsulation of ATM and Frame Relayframes

MPLS

Dif

fSer

v

Const

rain

t-Base

dRouting

VPLS

L2 V

PN

s

BG

P/M

PLS

VPN

s

TDM

ove

r M

PLS

Agilent Tech. ● ● ● ●

Alcatel ● ● ● ●

Avici Systems ● ●

Cisco Systems ● ● ●

Ixia ● ● ●

Marconi ● ● ●

Alcatel/Native Networks

● ●

Navtel Comm. ● ● ● ●

Nortel Networks ● ●

RAD ●

Riverstone ● ● ●

Tellabs ● ● ● ●

3


• VPLS service establishment by label exchangebetween provider edge routers

• Data forwarding to unknown and known Ether-net addresses

• Path tear down and withdraw between provideredge routers

Since VPLS is basically a multipoint extension ofpoint-to-point Ethernet pseudowire links, the testsfor point-to-point evaluation were used as a prereq-uisite for the VPLS tests.

The test plan requested that the transport tunnelswere established using the signalling protocolRSVP-TE in order to benefit from the traffic engi-neering and Diff-Serv processing in the backbone.

In addition to regular Ethernet traffic, the Ethernetpseudowire tunnels also effectively transportedTDM emulated traffic (data and voice) usingTDMoMPLS technology.

BGP/MPLS VPNs

The MPLS & Frame Relay Alliance test plansmpls2002.049.01 was used for this section.

This test area was aimed at determining the level ofinteroperability that can be achieved betweenRFC2547bis implementations of the variousvendors. First, VPN establishment between PEdevices was tested. The Layer 3 VPN tests, basedon the RFC2547bis draft standard covered:

• Full-mesh Multi Protocol BGP (MP-BGP) peering

• MPLS signalled tunnels between provider edge(PE) routers, using the Label Distribution Protocol(LDP)

• Dynamic backbone routing with OSPF includingtraffic engineering extensions (OSPF-TE)

• Dynamic route propagation using BGP or OSPFbetween customer edge routers (CE) andprovider routers (PE) and also between the PErouters themselves.

Similar to the Ethernet VPN area, the test planrequested that the transport tunnels were estab-lished using the signalling protocol RSVP-TE inorder to benefit from traffic engineering and Diff-Serv processing in the backbone.

Evolution To The JointMulti-Vendor NetworkThree different test areas were tested in parallelduring the hot-staging. Small groups were used tocheck interoperability and scalability. Successfulgroups in this stage were then connected to formlarger groups to build the multi-vendor network.The integration of the groups went forwardsmoothly and at the end of the hot-staging, allparticipants formed a piece of the demonstrationnetwork

Initial interoperability tests were done in groups ofthree devices connected to each other. Later on, alldevices of each scenario were connected to sepa-rate multi-vendor networks for VPNs and the MPLS-DiffServ backbone. Finally, the VPN networks wereattached to the edges of the MPLS-DiffServ networkand thus integrated into one large common infra-structure. Further interop testing and traffic loadgeneration was done at this stage to verify thatVPN traffic benefited from traffic differentiation.

Integrated Multi-VendorPairwise Testing

MPLS DiffServ Node VPLS / L2 VPN Node L3 VPN PE

Growing

LDP RSVP-TEL3/L2 VPN PE

Networkthe Cloud

VPLS

Layer 3VPNs

Layer 2 VPNs

MPLSDiffServ

Evolution of Test Stages

4


Interoperability Test ResultsThe goal of this event was two-fold — first, as fortypical interoperability test events, to verify andimprove the interworking of vendors’ implementa-tions, and secondly, to prove that the Service Provi-ders will be able to deploy VPN services overMPLS networks knowing that the network willprovide the differentiated services requested bycustomers for their business-critical applications.

Today, this means more than just to find bugs andcorrect them to advance the standards compliance.In many cases, implementations rely on draft stan-dards — vendors need to adapt their features tocustomers’ requirements so fast they cannot waituntil the final standard is adopted. Thus, the testevent was another effort to verify clarity of thecurrent standards.

Results: MPLS Diff-Serv Tests

Basic interoperability of RSVP-TE and OSPF-TE wasachieved between all vendors without any signal-ing or routing issues. Problems that had beennoticed in previous events have obviously beencorrected. It was very positive to see that the signal-ing and routing implementations of all participating

manufacturers were easily interoperable.

The test went forward without major issues when allvendors defined the mapping between experimen-tal bits and per-hop behaviors for Assured Forwar-ding (AF), Expedited Forwarding (EF) and BestEffort traffic. Initially, the test plan was unclear

about the drop precedence so we discussed theexpected handling for different AF types in thesame AF class. The IETF standard defines a relativedrop precedence relationship instead of absolutevalues. Some devices were flexible to modify therelative drop precedence while others had fixedrelationships. For example, drop precedence issmaller for AF11 than for AF12. The probability todrop AF11 traffic could be varied from zero up tothe drop precedence of AF12 in some devices; itwas fixed in other devices.

In this multi-vendor test it was of course impossibleto use any management application to configurethe per-hop behavior policies on all switches. Thevendors’ engineers had to configure everythingmanually instead. Naturally, some misconfigurationhappened, leading to incorrect prioritization. Werecommend to use management systems to controlthe distribution of policies within a Diff-Serv/trafficengineering enabled network.

All vendors supported E-LSPs (no matter what physi-cal link type was chosen) and were able to use thefull range of experimental bits. We tested withthree queues which is realistic compared to today’snetwork requirements. A few vendors alsosupported L-LSPs over ATM or PoS interfaces.

Only one vendor implemented the DiffServ objectas per RFC3270 — allother implementationswere designed to acceptlocally configured Diff-Serv mappings only.

When setting up label-switched paths with trafficengineering and DiffServ,a few interoperabilityproblems were observedby the vendors. Most nota-bly, it is important torecognize an RSVP-TEpath as DiffServ-enabledno matter whether the Diff-Serv object is present ornot. Therefore, RFC3270defines a backwardscompatibility mode. Other

interop issues with DiffServ-enabled path messageswere also noted, leading to path rejection. Theparticipants informed us that these issues haveeither already been resolved during the event, orwill be fixed in the following weeks.

MPLS DiffServ TE-EnabledBackbone

Cisco 12406

MarconiBXR-48000

Nortel NetworksShasta 5000 BSN

Avici QSR

Alcatel 7670RSP

Provider (P) Router

Provider Edge (PE) Router

RSVP-TE link

MPLS Diff-Serv/Traffic Engineering Backbone

5


rksSN

telatch0

VPN

VPN

Due to limited time, it was not possible to evaluateconstraint-based routing in detail. However, fivevendors (see table on page 3) confirmed that theyused OSPF-TE constraint-based routing during thewhole session. Based on current OSPF-TE reservedbandwidth information, an ingress router calculatesa suitable end-to-end path that satisfies the tunnelresource requirements — not just based on staticpath cost. One vendor demonstrated briefly thatthe constraint-based routing process works asexpected.

Results VPLS / Ethernet VPN Tests

Point-to-point Ethernet over MPLS tunnels («pseudo-wires») were tested according to the Martini draft.In the hot-staging, almost all tested point-to-pointconnections interoperated as expected. A fewissues were only observed on the transport layer —paths could not be established between theprovider edge routers.

While it was common for all vendors to use LDP asthe transport label distribution protocol last year,this has changed since. Since the use of RSVP-TEhas grown and because it is the only protocol withtraffic engineering support, RSVP-TE is now used bythe majority of vendors for VPN transport labels.Only two participants did not support RSVP-TE forVPLS / Ethernet-VPNs; they mentioned they willimplement RSVP-TE support soon.

Two Ethernet point-to-point VPN domains werecreated, one with LDP and one with RSVP-TE trans-

port. Full-mesh VPLS was established in the RSVP-TEdomain.

E1 traffic (both data and voice) was emulated overEthernet pseudowire using TDMoMPLS gatewayequipment.

Results: BGP/MPLS VPN Tests

BGP/MPLS VPNs have been used in the industryfor a few years already. The test session did notfocus testing this area in detail again; they weremerely used to demonstrate Diff-Serv transport overVPNs. Connectivity was achieved between twogroups of participating vendors; only in one casewe observed issues with a BGP implementation.

After establishing BGP sessions, EF and AF trafficwas generated from two sites destined to one, anda physical link was oversubscribed to test queuing.Correct traffic prioritization was observed.

VPN

VPN


Riverstone

Tellabs 8820

RSVP-TE link

AgilentRouterTester

RS8000

VPN

VPLS/RSVP-TEDomain

VPLS Test Network

VPN

VPN

VPN

VPN

VPN

Ixia 1600TAlcatel/Native Networks


LDP link

Riverstone

Tellabs 8820

RSVP-TE link

AgilentRouterTester

ISA PR & 1662SMC

RS8000

Ethernet Point-to-Point Tunnels

VPN

VPN

VPN

VPN

VPN

VPN

AgilentRouterTester


BGP adjacency

NortelNetwo

Tellabs 8820

Alcatel7670RSP

Shasta 5000 B

BGP/MPLS VPN Test Network

Cisco 12404 NavInterW

9500

VPN

Alcatel7670RSP

6

7

MPLS

World

Congress

2004Public

InteroperabilityEvent

Final In

tegra

ted Test N

etwork

Provider (P) Router and


Customer Edge (CE) Router

LDP link

IP/Ethernet link

IP Traffic Generator

RSVP-TE link

MPLS Emulator

TDMoIP/MPLS Gateway


AgilentuterTester

ltch0

MPLS DiffServ TE-EnabledBackbone

Alcatel/Native NetworksISA PR & 1662SMC

RAD

AgilentRouterTester

NavtelInterWatch 95000

Cisco 12406

RiverstoneRS8000

MarconiBXR-48000

Tellabs 8820

Ixia 1600T

Ixia 1600T

Ixia

Nortel NetworksShasta 5000 BSN

1600T

RouterTesterAgilent

MPLS Diff-Serv/Traffic Engineering

Backbone

VPN/VPLSApplications

DiffServ-Enabled

AviciQSR

IPmux-1000

RAD IPmux-1

Ro

NavteInterWa

9500

Cisco12404Alcatel

7670 RSP


Results Summary

Problems

Key Features Tested Results

DiffServMPLS

Basic Signaling Majority of combinations interworked

Per-Hop Behavior OK

Packet Exchange During Congestion All implementations mastered congestion asexpected; configuration issues solved later

Diff-Serv specific RSVP-TE signaling Only one implementation supported the Diff-Servobject already

L2 VPNs Interoperability LDP, RSVP-TE Majority of combinations interworked

Data Transfer OK

Frame Relay / ATM tunnels Not tested

Traffic Transfer Over RSVP-TE Tunnels OK, prioritization observed as expected

E1 (Data and Voice) Emulated TrafficTransfer

OK

VPLS Full-Mesh Establishment OK


MAC Address Withdraw Not tested

L3 VPNs Interoperability iBGP-MP Almost all implementations interworked seamlessly

Data Transfer OK


Problem AreaDescription of theProblem

Temporary Resolu-tion, if any

Recommendation

RSVP-TE DiffServObject

Tunnels were notestablished

Always define a staticEXP-PHB mapping inaddition unless you areabsolutely sure thenetwork consists only ofrouters with DiffServobject support

Ensure that the backwardcompatibility definition inRFC3270 is implemented

DiffServProvisioning

Traffic was not prioritizedas expected

Verify correctconfiguration using loadgenerators

Use centralized manage-ment applications tocontrol network wideper-hop behavior

LDP ApplicationData Transport

LDP does not supporttraffic engineering

Configure LDP-over-RSVP-TE hierarchical tunnels tocarry LDP data

Substitute LDP transportby RSVP-TE (does notrelate to VC labels!)

8


Conclusion

Today, generally service providers havenot implemented a full range of differenti-ated services within their Virtual PrivateNetworks (VPNs) yet. New revenue toreplace decreasing profit from voice andTDM legacy services has to date not beenrealized. However, competition will grow.There are two main reasons for carriers toimplement differentiated services in MPLS:First, the integration of multiple networksinto one common backbone for voice,leased lines and Internet-style data.Second, the creation of new differentiatedproduct offers which require accurate,application-specific backbone servicelevels.

This event has proven that the participat-ing vendors can now support differenti-ated services over MPLS and provide acommon mapping of services and queues.It gives carriers the confidence thatconverging different networks can stillprovide a common service guaranteeing/SLA network.

As the deployment of new VPN servicesand MPLS applications grows, congestionwill occur. At this point new bandwidthmust be purchased. Traffic engineeringacross multiple networks allows for betterutilization of available bandwidth — there-fore absorbing the growth and delayingthe time before you have to invest more.

Dynamic constraint-based routing opens apath to more flexible and efficient networkusage for operators. Specifically inconjunction with a differentiated servicesoffer, congestion can be avoided moreefficiently. The test event started multi-vendor evaluation of dynamic constraint-based routing and signalling.

The test event also verified that edgeservices are now able to make advantageof traffic engineering and differentiation inthe network across multiple vendors.

This was verified for the full range oftypical applications: Virtual Private LANService (VPLS), Point-to-Point Ethernettunnels, and BGP/MPLS VPNs carrying IPtraffic. It was shown that all these can beeasily enabled to carry differentiatedservices data.

In the past few years, MPLS has grownfrom a VPN service enabler and abackbone traffic engineering tool to atechnology capable of integrating legacyproducts and new service offers, servingthem all according to their specific require-ments. This has been made possible by thepowerful and versatile network featuresdefined in Multi-Protocol Label Switching.

The variety of standard-conformingproducts available from many vendors is aparticular strength of MPLS. The MPLS &Frame Relay Alliance and the supportingtest labs, UNH and EANTC, are proudthat the series of interoperability test eventsconducted since 2001 have been able toimprove interoperability dramatically.

9


10


ReferencesAll IETF drafts mentioned here are work in progress.

• Diff-Serv / Traffic Engineering

mpls2003.149.03 — MPLS & Frame Relay Alliance MPLS DiffServ and IGP-TE Interoperability Test SuiteRFC3270 — MPLS Support of Differentiated ServicesRFC2205 — Resource ReSerVation Protocol (RSVP)RFC3209 — RSVP-TE: Extensions to RSVP for LSP TunnelsRFC2597 — Assured Forwarding PHB GroupRFC3246 — An Expedited Forwarding PHBRFC2474 — Definition of the Differentiated Services Field in the IPv4 and IPv6 HeadersRFC2598 — An expedited forwarding PHB groupRFC3630 — Traffic Engineering (TE) Extensions to OSPF Version 2RFC3140 — Per Hop Behavior Identification CodesRFC3272 — Overview and Principles of Internet Traffic EngineeringRFC2702 — Requirements for Traffic Engineering over MPLS

• Virtual Private LAN Services

mpls2003.092.00 — MPLS Forum VPLS Interoperability Test Suitedraft-ietf-l2vpn-vpls-ldp-01 — Virtual Private LAN Services over MPLS

• MPLS Point-to-Point Ethernet VPNs (Pseudo-Wires)

mpls2003.091.00 — MPLS Forum Layer 2 VPN Interoperability Test Suitedraft-ietf-pwe3-control-protocol-05 — Pseudowire Setup and Maintenance using LDPdraft-ietf-pwe3-ethernet-encap-05 — Encapsulation Methods for Transport of Ethernet Frames over IP/MPLS NetworksIEEE 802.1D — Media Access Control (MAC) BridgesIEEE 802.1Q — Virtual Bridged Local Area Networks

• BGP/MPLS VPNs

mpls2002.094.01 — MPLS Forum BGP/MPLS VPN (RFC-2547bis) Interoperability Test SuiteRFC2547 — BGP/MPLS VPNsdraft-ietf-ppvpn-rfc2547bis-03 — BGP/MPLS VPNs

• Generic

MPLS & Frame Relay Alliance: Super Demo 2002, Test Plan & Results, June 2002MPLS & Frame Relay Alliance: Resilient & Scalable — MPLS World Congress 2003 InteroperabilityDemonstration, Test Plan & Results, February 2003

AcknowledgmentsWe would like to thank Ben Schultz and Ankur V. Chadda from the University of New Hampshire Interope-rability Lab (UNH IOL) for supporting this event.

11

MPLS & Frame RelayAlliance39355 California St.Suite 307Fremont, CA 94538, USA

EANTC AG

Einsteinufer 1710587 BerlinGermany

Upperside

54, rue du FbgSaint-Antoine75012 Paris, France

Tel: +1.510.608.5910Fax: +1.510.608.5917

Tel: +49 30 3180595-0Fax: +49 30 3180595-10

Tel: +33.153.46.63.80Fax: +33.153.46.63.85

www.mplsforum.org [email protected]

[email protected]

This report is copyright © 2004 EANTC AG. While every reasonable effort has been made to ensure accuracy andcompleteness of this publication, EANTC assumes no responsibility for the use of any information contained herein. Alltrademarks are property of their respective owners.

new revenue streams with mpls service differentiation · pdf filenew revenue streams with mpls...

Documents