mpls study - gwdgwebdoc.gwdg.de/ebook/ah/dfn/mpls-study.pdf · mpls is a flexible tool that enables...

03/6#6WXG\

3DJH#4

MPLS Study

Project:

Competence Center for ATM Components- DFN ComAC-

*0'#)2.865HVHDUFK#,QVWLWXWH#IRU#2SHQ#&RPPXQLFDWLRQ#6\VWHPV

#.DLVHULQ0$XJXVWD0$OOHH#64'0438;<#%HUOLQ

*HUPDQ\

03/6#6WXG\

3DJH#5

$XWKRU=#5XGROI#5RWK/#-HQV#7LHPDQQ/#/XW]#0DUN

9HUVLRQ=#413/##4913<14<<<

03/6#6WXG\

3DJH#6

7DEOH#RI#&RQWHQWV4 ,QWURGXFWLRQ 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111175 ,QWHUQHW#%DFNERQH#1HWZRUNV111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111118

514 5RXWHU#EDVHG#,3#&RUH#1HWZRUNV 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111118515 6ZLWFKHG#,3#&RUH#1HWZRUNV 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111119

6 0XOWLSURWRFRO#/DEHO#6ZLWFKLQJ 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111143614 /DEHO#6ZLWFKHG#3DFNHW#)RUZDUGLQJ#DQG#03/6#1HWZRUNV 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111143615 2SHUDWLRQ#RI#D#/DEHO#6ZLWFK#5RXWHU 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111144

7 $SSOLFDWLRQ#6FHQDULRV#IRU#03/6#LQ#WKH#%DFNERQH111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111146714 7UDIILF#(QJLQHHULQJ#LQ#03/6#1HWZRUNV 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111146

71414 7UDIILF#(QJLQHHULQJ#LQ#WKH#,QWHUQHW 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111114671415 $#)UDPHZRUN#IRU#7UDIILF#(QJLQHHULQJ#RYHU#03/6 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111148

715 9HQGRU#6ROXWLRQV111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111114;71514 $VFHQG 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111114;71515 &,6&2 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111114<71516 )25( 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111114<

716 'HVLJQ#RI#D#03/6#EDFNERQH 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111538 6WDWXV#RI#03/6#6WDQGDUGL]DWLRQ 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111559 ,3#4XDOLW\#RI#6HUYLFH#7HVWLQJ11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111159

914 $UFKLWHFWXUHV#IRU#,3#4R6 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111159915 7HVW#0HWKRGV 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111159916 7HVW#$SSOLFDWLRQV111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111115:917 7HVW#(QWLWLHV#DQG#,3#4R6#3DUDPHWHUV 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111115<918 6:2+:#5HTXLUHPHQWV#IRU#7HVWLQJ#,3#4R6 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111163919 3UDFWLFDO#0HDVXUHPHQWV 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111163

: 5HIHUHQFHV11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111167:14 9HQGRUV111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111167:15 /LWHUDWXUH1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111168

; $QQH[=#)XUWKHU#/LWHUDWXUH#DQG#5HVRXUFHV#RQ#03/6 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111169;14 7XWRULDOV#DQG#,QWURGXFWLRQ#WR#03/6=11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111169;15 0DJD]LQH#)HDWXUH#$UWLFOHV 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111169;16 ,QWHUQHW#UHVRXUFHV 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111116:;17 9HQGRUV#RI#03/6#7HFKQRORJ\#DQG#5HIHUHQFHV#WR#3URGXFW#5HVRXUFHV 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111116:

< $QQH[=#&XUUHQW#ZRUNLQJ#GUDIWV#RI#WKH#,(7)#03/6#:*1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111116<

03/6#6WXG\

3DJH#7

4 ,QWURGXFWLRQ

MPLS (multiprotocol label switching) is a new WAN technology currently being standardized byIETF that addresses key requirements of Internet Service Providers (ISP). ISPs can use MPLSmechanisms for improved traffic engineering and load balancing in their core Internet backbone.MPLS is a flexible tool that enables advanced services such as IP based VPNs or differentiated serviceclasses.

Historically, MPLS evolved from pragmatic approaches for IP/ATM integration that aim at animprovement of router forwarding performance. MPLS, however, is independent of the underlyinglink layer technology and can be operated on any transport media. And even if advances in Giga-routertechnology have successfully addressed the problem of router performance since then, MPLS has stillremained highly interesting as a standardized approach for solving key requirements in large scalebackbone IP networks. In some publication MPLS is even announced as one of the most importantnetwork developments of the 90s’.

The basic idea for MPLS is to add short fixed length labels to IP packets that can be used by theforwarding engines in the network to simplify packet forwarding. This provides a convenient means tobase packet forwarding on other criteria besides the destination only of traditional IP networks.

In this report, the basic features of MPLS are introduced and scenarios for potential applications in theIP backbone networks are discussed. An overview on the current status of the IETF standardizationwork is given together with a survey on available and announced products by major vendors; itexamines opportunities that MPLS can offer and identifies the open issues that still require furtherresearch.

03/6#6WXG\

3DJH#8

5 ,QWHUQHW#%DFNERQH#1HWZRUNV

Historically, MPLS resulted from the effort to leverage benefits of ATM high speed switches for IPcore networks. People were unsatisfied with the MPOA (multiprotocol over ATM) approach of theATM Forum which seemed to become too complex and costly to implement, and progress instandardization was too slow to fulfill pressing market needs. Therefore alternative proposals foundgreat resonance as, for instance, Ipsilon’s IP switch, which was to be followed soon by a number ofother schemes. As the most relevant emerged Tag Switching Architecture from Cisco, IBM’s ARIS(Aggregate Route-based IP Switching) and Ascend’s IP Navigator technology, which were in contrastto the other proposals WAN solutions directed to core backbone. These approaches formed the startingpoint for an IETF initiative to create a standardized approach towards label switching, which was nowtermed multiprotocol label switching (MPLS).

For a better understanding of the benefits of MPLS technology it is helpful to look first at the presentapproaches for building core IP networks. Currently, there are two ways to set up an IP core network:the traditional router based network core, and the IP overlay network approach over a switched core,which is created with connection-oriented technologies of Frame Relay and ATM; but each approachhas its particular benefits and limitations.

514 5RXWHU#EDVHG#,3#&RUH#1HWZRUNV

The IP protocol provides a packet-based connectionless communication service. An IP based networkcan be depicted as a mesh of linked host nodes with end-systems acting as packet source anddestination, and routers as intermediate nodes. IP packets are forwarded independently of each otherhop by hop from source to destination along a forwarding path, which may change over time due torouting updates. The Internet is organized as a set of interconnected networks belonging to differentadministrative domains which are also referred to as autonomous systems. The task of the IP networklayer is two-fold: it comprises the packet forwarding performed at each network node, and the controlof the forwarding process. For this purpose the router nodes run routing protocols. The routingprotocols handle the exchange of reachability information and, hence, enable each router to set up itsrouting table.

In general, one distinguishes between two types of routing: the routing between administrativedomains and the routing within a single routing domain. Interdomain routing is mainly based on policydecisions. The routing policy defines which traffic a ISP will allow to transit the routing domain anddepends on mutual peering agreements between adjacent providers. The intradomain routingconstructs routing paths to either end-nodes for traffic terminating within the domain or paths to anegress router for transit traffic. The main objective of intradomain routing is to construct paths that usenetwork resources efficiently. An ISP sets up a metric for each node and link reflecting preferences,capacity, costs etc. and the network will calculate shortest paths based on the selected metric. Figure 1illustrates the basic elements of an IP network.

03/6#6WXG\

3DJH#9

IR

ER

Intra-domain Router

Border Router

Intradomain Routinge.g. OSFP

Interdomain Routinge.g. BGP-4

BRBR

BR

BR

BR

BR

BR

IR IRIR

IR

IR IRBR

BR

BR

IR

IR

IR

BR

BR

BR

BR IRIR

Figure 1: Internet Autonomous Systems

The early ISP networks were constructed by leased lines where T1 (1.5 Mbps) and T3 (45 Mbps) linksconnected the routers. With the continued growth of the Internet multiple links were used to providethe necessary capacity. But soon this strategy run up to a limit as routers were not able to keep up withthe required performance for the backbone, and in the mid 90´s router-based cores had to face majorscalability problems:

• Progress in router technology did not speed up fast enough to keep pace with the growth in trafficand bandwidth demand. Routing became a potential bottleneck as software-based routers hadnarrow limits in packet processing capabilities and available router interface cards could notprovide sufficient traffic aggregation.

• Metric manipulation as a means for traffic engineering was no longer scalable as networkcontinued to grow. Metric adjustment at on part of the network could result in unforeseeableeffects on other parts of the network therefore more deterministic approaches to traffic engineeringwere needed.

• Intradomain routing protocols showed deficiencies as networks become more densely connectedleading to an inefficient use of network resources. The destination based routing approach wouldtend to aggregate all traffic directed to the same destination. Instead of balancing the load moreevenly on available network resources it can create a traffic magnet effect with some heavily over-utilized links while others remain under-utilized.

515 6ZLWFKHG#,3#&RUH#1HWZRUNV

With the availability of fast ATM switches it became possible to replace the router-based core by aswitched core. Cell switching technology offered then a faster and simpler forwarding, with better

03/6#6WXG\

3DJH#:

aggregation capabilities. The fixed size cells could be handled in hardware leading to a speed up inforwarding by several dimensions. The connection-oriented forwarding algorithm of ATM added tothis performance gain; it is based on short fix length connection identifiers, which is less complex thanthe longest prefix match needed for IP packet forwarding.

Traffic in the network core shows higher aggregation as compared to the edge regions. The dominatingevaluation criteria for technology here is foremost high performance at low costs. ISPs were thereforeable to gain in cost savings and upgrade to higher bandwidth by eliminating routers and replacing themby ATM switches. The transition to an overlay network allowed to connect edge routers via OC-3 (155Mbps) SAR interfaces to a switched core operating at OC-12 (622 Mbps)

ERER

ER

ER

ER

ER

ER

ER

ATM Switch

edge IP Router

ERER

ER

ER

ER

ER

ER

ATM Link

ATM SVC

Physical Toplogy Layer 3 Logical Toplogy

Figure 2: ATM Overlay Network

Figure 2 illustrates the ATM overlay approach: edge routers are connected to an ATM network cloud.Pairwise virtual connections provide connectivity between routers building a fully meshed logicalnetwork topology on top of the physical ATM network topology. Figure 2 illustrates these differentnetwork perspectives. The routers see only the point-to-point links without further knowledge whethertwo links share common physical resources or not.

Network configuration is typically calculated offline by network planning tools and then downloadedto the network switches, although some vendors already offer proprietary schemes with some built-inon-line traffic engineering capabilities. Network planning tools calculate an globally optimizeddimensioning of the PVCs on the basis of available link capacity and monitored traffic patterns. Forhigher network robustness redundancy can be introduced by establishing secondary back-up PVCs toprovide fault tolerance in case of link or switch failures. The mapping between IP network and theATM switched core is performed by the edge router, that relate the next hop router with thecorresponding PVC connecting to that hop.

03/6#6WXG\

3DJH#;

The edge routers connected by the ATM core form routing peer relationships among each other, forthis purpose they run an IGP (i.e. intradomain routing) protocol to exchange routing information. Therouting metric will reflect the PVC capacity and preferences, e.g. preferring the primary PVC over asecondary backup, so routers will use the secondary PVC only in case of a primary link failure andwill automatically return traffic to the primary path as soon as it becomes available again.

By the mid-90’s ATM switched cores provided a significant improvement in performance.Additionally, the flexibility for scaling PVC bandwidth offered a tool for precise control of networktraffic creating more deterministic and stable network behavior. In contrast to former metricmanipulation, it became easier to perform traffic engineering through explicit routing of the PVC overthe ATM infrastructure, thus making it possible to distribute traffic more evenly across networkresources. This better network utilization translates at once into less congestion and better networkservice at lower operational cost, and hence better competitiveness for network operators. ATMswitches also provide advanced network statistics and traffic monitoring facilities. Combined with theflexibility and scalability of PVC bandwidth provides an efficient means for a rational networkevolution planning.

/LPLWDWLRQV#RI#WKH#2YHUOD\#$SSURDFK

The main argument for a migration to an ATM switch core had been the unique high speedperformance. In the meantime, however, progress in router technology has made this argumentobsolete and may even reverse the balance. The introduction of ASICs technology into routers hasproven that IP packets can be forwarded at wire-speed and ATM router interfaces have even fallenbehind with the latest increases in optical network technologies. Today’s fastest ATM SAR interfacesoffer OC-12 whereas OC-48 interfaces for packet-over-SONET/SDH are already available and it is notclear when comparable ATM interfaces will appear. An upgrade to OC-192 can be expected for thevery next future and it is doubtful whether ATM based router interfaces will ever be able to scale tothese speeds due to complexity and costs. Given these perspectives the former advantages of an ATMbased switched network core need a critical re-evaluation and limitations of the approach become moreevident:

ATM introduces a ‘cell-tax’ of ca. 20% overhead due to packet encapsulation, ATM headers and cellpadding. With the continuing drop of bandwidth costs one could dismiss this as a lesser disadvantagebut there are even more severe arguments against the ATM switched core.

ATM switched cores duplicate the effort for network operation and management: a network operatormust administer two networks the physical ATM switched infrastructure and the logical IP networktopology. Each layer using its own addressing scheme and routing protocols. Additional devices forintegration of the technology such as address resolution servers become necessary. Events on layermay be difficult to relate to the other, thus make error tracing and failure recovery more difficult.

The ‘n-squared’ problem of the fully meshed overlay network: it requires to set up at least two(unidirectional) PVCs for each pair of edge routers and there must be at least two PVC in eachdirection if secondary backup routes should be available to handle link failures. This strongly limits thescalability of network size as the number of PVCs grows at the order of O(n2). Already adding a newrouter or shutting down an operational edge node will create enormous signaling load on the network ifa certain size is surpassed thus creating risks for network stability and robustness.

03/6#6WXG\

3DJH#<

IGP stress: intradomain routing protocols were not conceived for the fully meshed topology of theoverlay approach. With the high number of routing peers the IGP are driven to their limits: too muchrouting information has to be exchange between the peers causing substantial additional networktraffic and too many routing updates have to be processed by the routers requiring large router CPUresources.

When traffic engineering is performed at the ATM layer possibilities will be constraint in the case ofmixed media networks where different technologies are used for different portions of the network.Instead traffic engineering should be carried out the IP layer working transparently and independentlyof the underlying media.

These arguments show clearly that the current ATM based core approach will soon reach its limits, areturn to the former routed core however is also not practical because of its deficiencies related todestination based routing and its lack of efficient traffic engineering. Here MPLS can offer solutionsthat create a synthesis of the advantages from both of these worlds.

03/6#6WXG\

3DJH#43

6 0XOWLSURWRFRO#/DEHO#6ZLWFKLQJ

614 /DEHO#6ZLWFKHG#3DFNHW#)RUZDUGLQJ#DQG#03/6#1HWZRUNV

A FEC (forwarding equivalence class) is a useful concept for the description of packet forwarding in aconnectionless packet based network. The routing information established through the interworking ofintra-domain and inter-domain routing protocols partitions the packet forwarding space. A FECcomprises the set of all packets, that traverse a domain in a similar way: the packets are forwardedalong the same path of routing hops and they receive the same treatment at routers that applydifferentiated traffic policies such as weighted output queuing.

The task of packet forwarding in a router can then be described as a two step procedure:

• Identify the FEC to which an incoming packet belongs to

• Look up the routing information for that FEC to derive the next hop and policing information

In traditional IP router-based networks the identification of the FEC is a relative complex procedure. Itis derived from an analysis of the IP header in order to determine the appropriate destination subnet.The algorithm involves a longest prefix match of the destination IP address on the set of entries in therouting table, the forwarding information is then obtained through a look up under the matching subnetmask. With the support of differentiated services in a network even more information in the header hasto be processed to find the correct entry such as TOS (type of service) field or use of hints from thehigher layer protocols.

In packet based networks the packets are forwarded at each hop independently of each other. Thereforethe analysis of the packet header has to be repeated at each hop; each router has to perform the costlyoperation of processing IP header information and perhaps also additional higher layer protocolheaders in order to derive the FEC to which a packet belongs, then the router has to apply the correctprocessing policy and finally send the packet to its appropriate output port.

The basic idea of label switching is to optimize the process of FEC identification. Instead of repeatingthe same processing of header information at each hop it is only performed at the ingress node, whichencodes the FEC information into a small fixed length label that is added to the IP packet, such thatsubsequent nodes can base their forwarding decision on the packet label only without further need forcomplex header analysis.

The strategy used for encoding the FEC class information is to assign identifiers of local significanceto FECs, this means that each node uses its own mapping of label to FECs and packet forwardingrequires that the label of an incoming packet is replaced with the appropriate new outgoing label.

In this way effectively an virtual connection is established for each FEC into the domain creating aforwarding trunk from the ingress router to the egress router analogous to the ATM VCCs set up in anATM switched network core and indeed an ATM infrastructure can be used to realize MPLS. Thefundamental difference to the previous ATM overlay model however is not the forwarding mechanismused in the network nodes but the innovative control of the switches.

03/6#6WXG\

3DJH#44

Figure 3 depicts a typical subnetwork applying MPLS technology. It consists of LSRs (label switchrouter) at the network core forwarding IP packets based on the attached label information, and LERs(label edge router) which append to ingress packets their label and strip off labels from packets that areforwarded outside the label switching subnetwork. Adjacent LSRs or LERs form routing peerrelationships and run a routing protocol for the exchange of IP routing information. Additionally, theyneed to run a label distribution protocol to exchange label bindings between adjacent nodes.

ODEHOLQIRUPDWLRQH[FKDQJH

FRUH/65

HGJHURXWHU#+/(5,

ODEHO

Figure 3: Label Switching Network (LER and LSR)

LSR are full routing peers, in this way former problems resulting from the high number of routingadjacencies in the overlay approach disappear. The physical network topology is no longer hiddenfrom the IP layer, which implies better stability, robustness, and faster and more efficient reactions tolink failure.

Label switching offers flexibility on the granularity that labels are assigned, ranging from fineapplication flows to coarse traffic aggregations, and allowing to balance between the need of finegrained control and efficiency and switching resources. In principle, a FEC could be formed from thesource/destination address and port-number pair, effectively creating end-to-end switching, whichwould rather suit to enterprise environment. For application in the core network granularities, however,rather range on the level of destination subnetworks or even on the other extreme aggregating alltraffic to the same egress router of the operator domain.

Label switching basically allows for three strategies of label assignment. Label assignment can bedriven by topology, thus is triggered on routing update event; by data traffic, such that a new labelswitch path is established when data packets are received by the LSR; or they may be driven byexplicit request through the application of a signaling protocol e.g. RSVP.

615 2SHUDWLRQ#RI#D#/DEHO#6ZLWFK#5RXWHU

When a labeled packet arrives, the LSR uses the incoming label as an index in its incoming label map

03/6#6WXG\

3DJH#45

(ILM) in order to derive the corresponding Next Hop Label Forwarding Entry (NHLFE). For unicasttraffic, the forwarding information contains the outgoing label and the outgoing interface. Formulticast traffic, the forwarding information will contain one NHLFE for each outgoing branch of themulticast tree..

Figure 4 illustrates the case where a packet is received by the LSR with a label = 1111. The LSR usesthe NHLFE entry for 1111, to swap the incoming label with the new outgoing label = 0815, then itforwards the packet over the corresponding interface 4. Since the forwarding algorithm is based onexact tag matches it is more efficient than the standard longest match algorithm employed intraditional IP routing table traversals; and enables a higher packet throughput. Moreover, labelswapping can be implemented in hardware in a straightforward manner with ASIC forwarding enginesresulting in an further boost of forwarding performance.

/DEHO#6ZLWFK#5RXWHU

ODEHO## #4444

ODEHO# #3;48

4

7

6

5ILM

RXWODEHO #3;48,QWHUIDFH #7

2XWJRLQJ

ODEHO# #4444

,QFRPLQJ

111 111

ILM incoming label map

Figure 4: Forwarding by Label Swapping

The forwarding algorithm is independent of the label granularity. Therefore a label may represent asingle unicast route, an aggregate of multiple routes or a multicast route. The ingress edge LSR canassign labels based on a destination IP address prefix for traffic that needs rapid Layer 3 forwardingacross the network. An ingress edge LSR can also assign labels on a finer granularity of an applicationflow (e.g. source IP address, destination IP address, port numbers, or other administrative policy) tomaintain a given QoS across the network for an RSVP supported flow; it can also support coarsergranularity aggregating traffic to be tunneled through a transit IP routing domain.

03/6#6WXG\

3DJH#46

7 $SSOLFDWLRQ#6FHQDULRV#IRU#03/6#LQ#WKH#%DFNERQH

This chapter will show directions towards an operational IP network utilizing MPLS. In the firstsection we will explain the main feature of traffic engineering of such a network, based on explanationof the previous chapters of this document. The second part analyses MPLS solution form major vendorbased on their white papers. This is concluded by a comparism of these concepts. Finally this chapterdescribes a typical design of a MPLS backbone.

714 7UDIILF#(QJLQHHULQJ#LQ#03/6#1HWZRUNV

The most significant driving factors for the deployment of MPLS technologies are the improvedcapabilities for Traffic Engineering that become feasible with MPLS. The MPLS working group hasalready started work on Traffic Engineering and a first document out of a set of planned RFCs iscurrently finalized, which identifies the requirements for Traffic Engineering over MPLS. It describesthe basic functions of Traffic Engineering in the Internet and derives the necessary functionalcapabilities required in MPLS networks to support the implementation of network policies.

A prominent promoter of the IETF activities in MPLS is UUNET Worldcom, which sees MPLSenabled Traffic Engineering as an important strategic step forward and expects major improvements innetwork operation and scalability from the introduction of MPLS technology. UUNET Worldcom alsohosted the 1st International Workshop on MPLS in Nov. 1998.

71414 7UDIILF#(QJLQHHULQJ#LQ#WKH#,QWHUQHW

The goal of Traffic Engineering (TE) is the performance optimization of operational networks leadingto improved reliability and efficiency. Through actions of traffic engineering an optimized utilizationof network resources is guaranteed. Hence, TE becomes an indispensable tool for network operators torespond to the pressure of a commercial and competitive market environment.

There are two aspects to traffic engineering. It includes actions that aim at the enhancement of the QoSof individual traffic streams (e.g. minimizing packet loss or delay, maximizing throughput, or targetingstatistical parameters like delay variation, loss ratio, etc). And there are resource oriented performanceobjectives which pertain to the optimization of the overall resource utilization. The goal is to ensurethat no subsets of network resources become over-utilized and congested, while there are still otherresources along alternate feasible paths that remain underutilized.

Avoidance of congestion is one of the major performance objectives. Congestion occurs when networkresources are insufficient or inadequate to accommodate the offered load, but it can also result whentraffic is mapped inefficiently onto available network resources. While the first congestion problem ishandled through network capacity planning and congestion control techniques, it is the second type ofcongestion problems that is addressed by Traffic Engineering. Load balancing policies can prevent thesecond type of congestion. Efficient resource allocation minimizes the overall maximum of localresource utilization and as a result decreases total packet loss. This enhances significantly the generalperception of network service quality by end users. However, TE capabilities need to be flexibleenough, to also allow other more complex policies such as taking into account the cost structure, orrevenue model.

03/6#6WXG\

3DJH#47

Traffic Engineering is formulated as a control problem in an adaptive feedback system. The state ofthe network is monitored and control actions are applied that aim at driving the network to a desiredstate that is in accordance with the chosen control policy. It consists in actions done reactively inresponse to monitored events, or pro-actively by using forecasting techniques to foresee trends andacting on prevention of undesirable anticipated states. Control actions include modification ofparameters related to traffic management, routing and constraints associated with resources. Ideally,traffic engineering should require only minimal manual intervention, and the necessary actions shouldbe initiated automatically in a distributed and scalable fashion.

Improved methods for Traffic Engineering rate high on the agenda of network operators given theinadequate control capabilities offered by current Internet interior gateway protocols. IGPs based onshortest path algorithms are topology driven and do not yet consider dynamic aspects such asbandwidth availability and traffic characteristics when making routing decisions. They may even tendto induce situations that aggravate congestion problems, which happens when the shortest path ofmultiple streams converge on the same links or router interfaces, as all flows directed to the sameegress node will follow the same path, once they have met at a common intermediate hop even thoughvarious feasible alternate paths with excess capacity exist. Especially in large networks with a densetopology the problem becomes particularly pronounced.

As explained already in the previous section the overlay model can circumvent some of thoseinadequacies by construction of a virtual topology with suitable link capacities on top of the network'sphysical topology. The ATM overlay model provides important features for traffic and resourcecontrol, such as constraint based routing at the VC level, administratively configurable explicit VCpaths, call admission control, traffic shaping and policing, and fault recovery. These capabilities enablethe actualization of a variety of Traffic Engineering policies. For example, virtual circuits can easily bererouted to move traffic from over-utilized network nodes onto less utilized ones. These improved TEcapabilities however come at the price of high administrative and management costs and show limitsin scalability.

With MPLS on the other hand, Traffic Engineering functionality becomes available that is at leastcomparable to overlay capabilities, but additional is able to scale also to dense core networks of largesize. As additional bonus MPLS provides these benefits at lower cost in an integrated manner, andoffers the prospect to automate much of the Traffic Engineering task. What makes MPLS particularlyattractive for network operators is that it opens up possibilities towards a more rational engineeringapproach in network operation.

• MPLS overcomes the limits of traditional routed cores as it introduces more flexibility than theformer destination based forwarding paradigm. Explicit label switched paths can be easily createdthrough manual administrative action or through automated action of the underlying protocols. ALSP is not constraint to follow the same path as calculated by the destination based routingalgorithm for hop by hop forwarding.

• MPLS allows for both traffic aggregation and disaggregation. Classical destination only based IProuting permits only aggregation. With MPLS however, edge routers can map flows to the sameegress router to several LSPs which follow different routes over the MPLS core, thus creating andisaggregation of the packet stream with improved load balancing in the network.

• MPLS overcomes the limits of the overlay approach as it eliminates the two stage provisioningapproach, where a switched physical network core underlies a fully mesh virtual IP network that is

03/6#6WXG\

3DJH#48

unaware of the topology below. With the integration of the two layers many of the trafficengineering tasks that had to be performed manually can become automated

71415 $#)UDPHZRUN#IRU#7UDIILF#(QJLQHHULQJ#RYHU#03/6

The deeper issue that becomes apparent in the inadequateness of both the routed core and the overlayapproach is the lack of a satisfactory model for network operation and in particular inner-domainrouting. Network operators currently need to perform low level operations such as metricsmanipulation and VC set-up, which more often than not are performed in form of try-and-error ratherthan true engineering in the attempt of generating a desired effects.

With MPLS there comes a more abstract model of network operation, as described in the MPLS WGdocument on 'Requirements for Traffic Engineering Over MPLS'. The key notion for TrafficEngineering in MPLS networks is the concept of a traffic trunk. A traffic trunk is an object thatrepresents the aggregation of unidirectional traffic flows of the same class that will be placed inside aLabel Switched Path. The traffic trunk, however, is distinct from the LSP through which it traverses, asa traffic trunk can be moved from one path onto another when needed e.g. in case of failure orpreemption of resources from higher priority traffic.

A traffic trunk is characterized by its ingress and egress LSRs, the forwarding equivalence classeswhich are mapped onto it, and a set of attributes which determine its behavioral characteristics. As anexample, in the single class service model of the current Internet, a traffic trunk could be formed toencapsulate all the traffic between an certain ingress LSR and an egress LSR.

The fundamental problems for operating an MPLS network can then be re-formulated in terms oftraffic trunks as follows:

• how to map packets onto forwarding equivalence classes.

• how to map forwarding equivalence classes onto traffic trunks.

• how to map traffic trunks onto the physical network topology through label switched paths.

The first task of deducing the FEC for an IP packet requires the analysis of the packet header to derivethe relevant information such as destination network, service class or routing options etc. It is done bythe edge router and is controlled through configuration of its classification engine. The second task ofgenerating a traffic trunk for the FEC means that behavioral properties for a FEC have to bedetermined that describe the traffic requirements for this class of packets, which in general is mainlydetermined and controlled from policy decisions. The third task requires that the traffic requirementsexpressed by the traffic trunk are met by adequate network resources. This task requires elaborateintra-domain routing capabilities in the network.

In order to specify the traffic requirements and resource constraints in the MPLS network and toaccomplish the proper mapping there needs to be:

1. A set of attributes associated with traffic trunks which collectively specify behavioral

03/6#6WXG\

3DJH#49

characteristics.

2. A set of attributes associated with resources which constrain the placement of traffic trunks throughthem.

3. A "constraint based routing" (QoS routing) framework which is used to select paths for traffic trunkssubject to constraints imposed by items 1) and 2) above.

The attributes associated with traffic trunks and resources, as well as parameters associated withrouting, collectively represent the control variables which can be modified either throughadministrative action or automatically to drive the network to a desired state; and in an operationalnetwork, it must be possible that these attributes are dynamically modified online by an operatorwithout adversely disrupting network operations.

3URSHUWLHV#DQG#$WWULEXWHV#RI#7UDIILF#7UXQNV

Traffic trunks are the basic objects that a network operator has to manipulate. Traffic trunks must becreated, routed and mapped onto network resources in order to provide the network services. The basicoperations on traffic trunks comprise Establish (Create an instance of a traffic trunk);Activate/Deactivate (Cause a traffic trunk to start/stop passing traffic), Modify Attributes (Cause theattributes of a traffic trunk to be modified) Reroute (Cause a traffic trunk to change its route), Destroy(Remove an instance of a traffic trunk from the network and reclaim all resources allocated to it). Thebasic attributes associated with traffic trunks comprise parameters specifying traffic, path selection andmaintenance, priority, preemption, resilience and policing.

Traffic parameters capture the characteristics of the traffic streams that should be transported throughthe traffic trunk, such as peak rates, average rates, permissible burst size, etc. The traffic parametersspecify the resource requirements of the traffic trunk, that must be available in a network node or linkin order that a traffic trunk can be routed through this resource.

Path selection and management attributes define the rules for selecting the route taken by a newlycreated traffic trunk and for maintenance of already established paths. Paths can be computedautomatically by the underlying routing protocols or set up administratively by a network operator. Fortrunks with resource requirements or policy restrictions a constraint based routing scheme must beapplied for path selection, else a topology driven protocol will be sufficient.

An administratively specified explicit path for a traffic trunk is a path that is configured throughoperator action. The path can be completely specified or partially specified. In a completely specifiedpath all required hops between the endpoints are indicated. In a partially specified path only a subsetof intermediate hops is indicated and the underlying protocols are required to construct a compliantcomplete path. It is useful to be able to specify a set of candidate explicit paths together with apreference relation for a given traffic trunk. On path establishment, the preferred path is then selected,and when path failure occurs there are still the alternate paths on the candidate list that can be chosen.

Resource class affinity attributes associated with a traffic trunk are used to explicitly include orexclude resources from the path selection. These policy are used to impose additional constraints. Theypowerful constructs that can implement a variety of policies. For example, they can be used to containa traffic trunk within specific topological regions of the network. Constraint based routing uses these

03/6#6WXG\

3DJH#4:

attributes to compute an path by pruning all resources which do not belong to the included resourceclasses and those that belong to the excluded classes before performing path placement computations.

Network characteristics and state change over time. For example, new resources become available,failed resources become reactivated. In some scenarios, it might be desirable to dynamically changethe paths of traffic trunks in response to changes in network state. The adaptivity attribute associatedwith a traffic trunk indicates whether the trunk is subject to such re-optimization. If enabled, then atraffic trunk can be rerouted through different paths by the underlying protocols in response to changesin network state, otherwise the traffic trunk remains "pinned" to its established path.

Load distribution across multiple parallel traffic trunks between two nodes is an important tool tosmooth traffic distribution across the network and improve the overall resource utilization. In anMPLS domain, this can be addressed by instantiating multiple traffic trunks between two nodes, suchthat each traffic trunk carries a proportion of the aggregate traffic. It is useful to have some attributethat indicates the relative proportion of traffic to be carried by each traffic trunk. Underlying protocolswill then distribute the load according to the specified proportions. However, packet ordering betweenpackets belonging to the same micro-flow (same source/destination address and port number) shouldbe maintained, thus all packets in a micro-flow should be mapped onto the same traffic trunk.

In a constraint based routing framework used with MPLS, priorities become important and are used todetermine the order in which path selection is done at connection establishment and under faultscenarios. With preemption a traffic trunk can even claim resources from another already establishedtraffic trunk of lower priority. In a differentiated services environment, preemption can be used toassure that high priority traffic trunks are always routed through relatively favorable paths. It can alsobe used to implement various prioritized restoration policies following fault events.

Resilience determines the behavior of a traffic trunk under fault conditions. Basic problems that needto be addressed include fault detection, failure notification, and recovery & service restoration.Example recovery policies for traffic trunks used by a network operator could be

- Do not reroute a traffic trunk. For example, when another survivability scheme is already in place,such as multiple parallel LSPs that can accomodate the additional traffic of the failed link.

- Reroute through a feasible path with enough resources. If none exists, then do not reroute.

- Reroute through any available path regardless of resource constraints.

The policing attribute determine the actions that should be taken when a traffic trunk becomes non-compliant, i.e. exceeds its contract as specified in the traffic parameters. Policing attributes mayindicate whether a non-conformant traffic trunk is to be rate limited, tagged, or simply forwardedwithout any policing action.

5HVRXUFH#DWWULEXWHV

Resource attributes are part of the topology state parameters, which are used to constrain the routing oftraffic trunks through specific resources. For instance, the maximum allocation multiplier (MAM) for

03/6#6WXG\

3DJH#4;

resources like link bandwidth and buffer length: it is an administratively configurable attribute whichdetermines the proportion of the resource that is available for allocation to traffic trunks. For example,over-allocation can be used to exploit the statistical characteristics of the traffic.

Resource class attributes express some notion of "class" for resource and are used to implement avariety of policies. For example they can be used to consistently apply a uniform policy to a set ofresources or to express the relative preference of sets of resources for path placement or to explicitlyrestrict the placement of traffic trunks to specific subsets of resources and so on.

Constraint based routing enables a demand driven, resource reservation aware, routing paradigm to co-exist with current topology driven hop by hop Internet interior gateway protocols.

&RQVWUDLQW0EDVHG#5RXWLQJ

A constraint based routing framework uses as input the attributes associated with traffic trunks, theattributes associated with resources and other topology state information. Based on this information, aconstraint based routing process on each node automatically computes explicit routes for each traffictrunk that originates from the node. In this case, an explicit route for each traffic trunk is aspecification of a label switched path that satisfies the demand requirements expressed in the trunk'sattributes, subject to constraints imposed by resource availability and other topology state information.

A constraint based routing framework can greatly reduce the level of manual configuration required toactualize Traffic Engineering policies. In full generality, the constraint based routing problem isintractable. However, a simple well-known heuristic can be used in practice to find a feasible path ifone exists: First prune all resources that do not satisfy the requirements of the traffic trunk attributes,and then run a shortest path algorithm on the residual graph. Many commercial implementations offrame relay and ATM switches already support some notion of constraint based routing. With theupgrade of such devices to MPLS, it should be relatively easy to extend their implementation toaccommodate the peculiar requirements of MPLS traffic engineering.

715 9HQGRU#6ROXWLRQV

This section introduces white papers from major vendors concerning set-up of IP networks and MPLS.It is intended as an overview on trends in networking and market-aware solutions. Not all parts arealready available and will be available in future (a detailed overview can be found in chapter 5, MPLSMarket Overview). Reading this papers one learn about the focus of the companies viewpoint and onecan estimate future work. We decided to focus on big players on the market, it is not intended todescribe interesting technical solutions from small start-up, but reliable large scale concepts.

In general there are no statements what kind of lower layer technologies (routed vs. switched backbonenetworks) will be recommended by the companies. They offer MPLS as a technology for ISPs whoalready invested in ATM backbones. But in direct comparison (e.g. at Ascend) the solutions forswitched backbones are mentioned together with interesting features like QoS and VPN services.

71514 $VFHQG

Describes their viewpoint of powerful IP networks in the white papers "Building tomorrow’s Internet

03/6#6WXG\

3DJH#4<

Backbone" and "IP Navigator MPLS Executive Overview")

Ascend starts in their description for building IP networks with the phases of the IP backbone growth:Starting with routed backbones the ISP changed in the early nineties to switched backbones(mentioned advantages are bandwidth management, offering multiple service and supporting QoS).The future (in a document from 1997) is seen in a combination of switching and routing and MPLS isclearly named. Ascend offers two families in this range, the GRF family of IP switches (for set-up ofrouted networks) and the IP navigator (for set-up of switched networks). While discussion differentareas of deployment of these systems the interoperability of the systems is not completely clear. Agroup labelled as "largest national ISP" is identified using a "pragmatic" approach, using mixed orhybrid backbones.

One possible hybrid solution is the usage of switched systems in the area of high density access and inparts of the core network. The routed systems are used for POP concentration and internetconnectivity. Advantages are outlined as:

• scalability (using routers for server farms, switches for high-density access

• multiple services (offering IP, ATM and FR on one line in different VCs)

• QoS (first step: provisioned QoS, later: dynamically QoS on detection of flows)

This later points are picked up in the document about MPLS (IP Navigator MPLS ExecutiveOverview, a more recent paper from October 98). While describing features of MPLS, Ascendhighlights the advantages of the Label Switched Paths (LSP) and focuses on routing in this paper.Switching is seen as high-performance forwarding mechanism, also deployed for native multicastsupport. Coming from the routing side and routing protocols, the introduction of MPLS is seen as amechanism to offer advanced services, based on features of ATM or Frame Relay. Advanced servicesare identified and described in VPNs, QoS and multicast applications.

71515 &,6&2

CISCO starts in the white paper “Enabling Business IP Services with Multiprotocol Label Switching”with the view on internet business and the need for carriers who invested in switched backbonenetworks, to profit form their investment while offering IP services. There is a discussion of MPLSterms and show examples of the forwarding mechanism in MPLS with label switched paths. Newservices like QoS support and VPN are described as features of the introduced label and treated on IPlevel of the network. QoS is an outcome of implementing well known CISCO queuing and schedulingmechanism (e.g. WRED and CBWFQ). Basis for delivering customers QoS is the class of serviceapproach, it is more scalable then a approach on per-flow basis. With this approach bandwidthmanagement is completely done in the edge devices. Routing is done via with traditional IP routingprotocols, a strength of CISCO. The document also describes how to build VPNs with the help of asmart use of routing protocols like BGP. For multiservice network CISCO's concept of a virtual switchinterface is described, an architecture to enable service providers offer ATM, frame relay and voice inthe same switched network.

71516 )25(

For service providers FORE identifies (in the white paper “Building an IP Service Network”) the

03/6#6WXG\

3DJH#53

demand for high capacity core switching, bandwidth guarantees and a scalable infrastructure. Possiblebackbone technologies include ATM switching, non-connection oriented Terabit routers, Packet OverSONET and Dense Wavelength Multiplexing (DWDM). For today’s business IP routing over ATMswitching is available. The next technology step will be unified routing and switching with MPLS, itbridges the gap between ATM connections and IP services. FORE points out that MPLS is a standardand not an available product, but claims to offer two important advances promised by MPLS: capacityoptimisation and traffic engineering. The layered architecture behind this approach is SDH ontransmission layer, ATM on switching layer and IP on service layer. Examples for traffic engineeringare given. FORE introduces two mechanism to support the network management: Directed Soft PVCsfor control of complete paths including fast recovery by switching and Capacity Aware Routing,FORE implementation of PNNI for routing with respect to the network state. MPLS will provide thecommunication between IP service and switching, running IP over non-congested ATM connections.Also PNNI is the basis for network resiliency and failure recovery.

Conclusion

The statements of different vendors of MPLS enabled systems, as discussed in the previous sections,show that MPLS is a very important mechanism to extend carriers existing ATM networks andimplement new IP services, like VPN or QoS support. Naturally the focus on MPLS differs formcompany to company: CISCO (strong in routing technology) see ATM as an transport mechanism,doing most QoS and VPN features on the IP layer. As an opposite FORE (know as ATM switchmanufacturer) will utilise extended ATM functionality (e.g. with PNNI for routing) to offer IPtransport. This leads to tasks like following the ongoing standardisation of MPLS and to testinteroperability of available equipment. Even after first published standards of MPLS there are severaltopics of possible interworking problems:

• Interworking of Routing on ATM and IP layer

• Interworking of different IP clouds and on ATM/IP layer

• Interfaces between different MPLS networks

• Mapping of QoS mechanisms

Besides the integration of IP in ATM backbones no other transport mechanism besides ATM is ready,only CISCO mentioned the independence of the label mechanism form the lower layer technology.

716 'HVLJQ#RI#D#03/6#EDFNERQH

This chapter designs a network topology to provide an IP service on the top of an ATM backbone. Thenetwork provides connected customers a means to communicate with each other an have an access tolocations outside the providers network. If there are more than one gateway to foreign networks youhave to reckon that the network is used as a transit network. Important aspects of network planningare:

• resilience/redundancy,

• alternative paths,

• traffic engineering,

• scalability

03/6#6WXG\

3DJH#54

The following sections design a network infrastructure using the MPLS technology.

MPLS network structure

The core of the network is build by LSR routers (LSR core) which are ATM switches with LSRfunctionality. They are connected over the ATM backbone. The number of connections between thebackbone routers depends on the special network topology. If there are only few core routers, you canbuild a full mesh. Customers have access to the core network via an access router (LSR edge) whichare routers with LSR functionality. The edge router is the last router before the packets reach the WANwhich looks into the IP header to make a routing decision. Within the MPLS cloud packet forwardingis based on label switching.

ATM BackboneMPLS Cloud

Internet/ISP

ATM link

BGPLSRedge

LSRedge

LSRedge

LSRedge

LSRedge

LSRedge

LSRcore

LSRcore

LSRcore

LSRedgeBGP

Internet/ISP

OSPF area

Figure 5: General Setup of an MPLS network

03/6#6WXG\

3DJH#55

8 6WDWXV#RI#03/6#6WDQGDUGL]DWLRQ

Work within IETF on the standardization of label switching started in March 1997 when the MPLSworking group was formed. The laid out schedule set a timeframe till April 1999 for standardization.This plan will be roughly met for core standard documents: About 8 documents have already reachedthe final stages of group consensus and are about to become issued as RFCs. This includes the generalarchitecture of MPLS, the specification of label encodings and the LDP protocol together withstandards for operation over ATM and Frame Relay based switches. Based on this core set ofstandards vendors are in a position to offer interoperable products for MPLS based IP networks.

But during that period the working group has gained much in momentum and size. Especially duringthe last year, MPLS has attracted much attention from major vendors. The working group hasexpanded its scope since then, and there are currently about 18 accepted MPLS drafts for furtherdevelopment. Additionally, there have submitted by now about 40 individual draft contributions thatare under discussion in the group. These include at least 5 proposals that will be accepted as groupdrafts during the next meeting. Others are still at a too early stage to be adopted now, but they areexpected to gain official recognition as new working items in the next future. Since MPLS hasreceived such enormous expansion of activities, it is planned to split the working group and to set up aseparate group that will be devoted explicitly to the topic of traffic engineering, which is felt to be ofparticular importance.

In the following overview on current MPLS WG working documents, it is attempted to classify thebroad range of standardization activities along a small set of topics, which however can only provide arough categorization, as there is overlap and interdependencies between the issues. As main workingareas there can be identified documents of an explanatory, more informational character defining thegeneral outline of MPLS; there are standard track documents for the new protocol and packet formatsdefined by MPLS; specifications of mapping MPLS onto specific data link layer technologies,specifications of required extensions to signaling and control protocols to handle LSP set-up; furtherextended features of MPLS, and possibilities for the application of MPLS in core networks.

03/6#RXWOLQH#GRFXPHQWV

These documents have a more informational character. They define key concepts and terminology, andthey identify requirements for conformance of MPLS technologies.

working drafts include:

• $#)UDPHZRUN#IRU#0XOWLSURWRFRO#/DEHO#6ZLWFKLQJ?GUDIW0LHWI0PSOV0IUDPHZRUN0351W[W!+VWDWXV=#FXUUHQWO\#EHKLQG#VFKHGXOH/#ILQDOL]LQJ#ZRUN#WR#EHJLQ#DIWHU#QH[W#PHHWLQJ,

• 0XOWLSURWRFRO#/DEHO#6ZLWFKLQJ#$UFKLWHFWXUH?GUDIW0LHWI0PSOV0DUFK0371W[W!#+VWDWXV=#,(6*#ODVW#FDOO,

03/6#FRUH#VWDQGDUGV

core standards define the MPLS label format and specify the MPLS specific label distributionprotocol, work covers also standardization of management support for MPLS components

03/6#6WXG\

3DJH#56

working drafts comprise:

• 03/6#/DEHO#6WDFN#(QFRGLQJ?GUDIW0LHWI0PSOV0ODEHO0HQFDSV0361W[W!#+VWDWXV=#,(6*#ODVW#FDOO,

• /'3#6SHFLILFDWLRQ?GUDIW0LHWI0PSOV0OGS0361W[W!##+VWDWXV=#:*#ODVW#FDOO,

• /'3#6WDWH#0DFKLQH?GUDIW0LHWI0PSOV0OGS0VWDWH0331W[W!

• 'HILQLWLRQV#RI#0DQDJHG#2EMHFWV#IRU#WKH#0XOWLSURWRFRO#/DEHO#6ZLWFKLQJ/#/DEHO#'LVWULEXWLRQ#3URWRFRO?GUDIW0LHWI0PSOV0OGS0PLE0331W[W!

03/6#RYHU#YDULRXV#OLQN#OD\HU#WHFKQRORJLHV

MPLS is independent of the underlying data link layer technology. Highest priority in thedevelopment, however, is currently placed on solutions for ATM and Frame Relay. The standardsrelated to FR and ATM VC service are already in their final call, while work on ATM VP service juststarted. Additionally, there are individual proposals for applying MPLS in a LAN environment,


• 8VH#RI#/DEHO#6ZLWFKLQJ#RQ#)UDPH#5HOD\#1HWZRUNV#6SHFLILFDWLRQ?GUDIW0LHWI0PSOV0IU0361W[W!##+,(6*#ODVW#FDOO,

• 9&,'#1RWLILFDWLRQ#RYHU#$70#OLQN?GUDIW0LHWI0PSOV0YFLG0DWP0361W[W!##+,(6*#ODVW#FDOO,

• 03/6#XVLQJ#$70#9&#6ZLWFKLQJ?GUDIW0LHWI0PSOV0DWP0341W[W!

• /D\HU#7ZR#7XQQHOLQJ#3URWRFRO#%/573%#0XOWL03URWRFRO#/DEHO#6ZLWFKLQJ#([WHQVLRQ?GUDIW0LHWI0SSSH[W0O5WS0PSOV0351W[W!

individual submissions under discussion include:

• 03/6#XVLQJ#$70#93#6ZLWFKLQJ?GUDIW0IHOGPDQ0PSOV0DWPYS0331W[W! +QHZ#:*#GRF,

• &RPSDULVRQ#RI#03/6#/$1#(QFDSVXODWLRQ#3URSRVDOV?GUDIW0URVHQ0PSOV0ODQ0HQFDSV0FRPSDU0331W[W!

• 03/60916#,QWHUZRUNLQJ?GUDIW0MDPRXVVL0PSOV0YQV0331W[W!

• 9&#3RRO?GUDIW0GHPL]X0PSOV0YFSRRO0331W[W!

03/6#FRQWURO#DQG#LQWHUZRUNLQJ#ZLWK#URXWLQJ#DQG#VLJQDOLQJ

Label information can be negotiated between adjacent nodes using the LDP protocol. Additionally,label information can be passed by piggy-backing with signaling and routing protocols.


03/6#6WXG\

3DJH#57

• ([WHQVLRQV#WR#5693#IRU#/63#7XQQHOV?GUDIW0LHWI0PSOV0UVYS0OVS0WXQQHO0351W[W! #+VWDWXV=#H[SHFWHG#:*#ODVW#FDOO,

• 8VH#RI#/DEHO#6ZLWFKLQJ#:LWK#5693?GUDIW0LHWI0PSOV0UVYS0331W[W!

• 7KH#$VVLJQPHQW#RI#WKH#,QIRUPDWLRQ#)LHOG#DQG#3URWRFRO#,GHQWLILHU#LQ#WKH#415<74#*HQHULF#,GHQWLILHU#DQG#415<8:#8VHU0WR0XVHU#6LJQDOLQJIRU#WKH#,QWHUQHW#3URWRFRO?GUDIW0LHWI0PSOV0JLW0XXV0351W[W!

• &DUU\LQJ#/DEHO#,QIRUPDWLRQ#LQ#%*307?GUDIW0LHWI0PSOV0EJS70PSOV0351W[W!

• 81,7(=#$Q#$UFKLWHFWXUH#IRU#/LJKWZHLJKW#6LJQDOLQJ?GUDIW0UDPDNULVKQDQ0PSOV0XQLWH0331W[W!

$GYDQFHG#)HDWXUHV#RI#03/6

MPLS had been developed originally for enhanced packet forwarding performance. But as it turnedout MPLS opens up further possibilities to introduce advanced features into the network includingconstraint-based routing, QoS support and multicasting.


• 03/6#&DSDELOLW\#VHW?GUDIW0ORD0PSOV0FDS0VHW0331W[W!# +DFFHSWHG#DV#QHZ#JURXS#GUDIW,

MPLS routing support:

• &RQVWUDLQW0%DVHG#/63#6HWXS#XVLQJ#/'3?GUDIW0LHWI0PSOV0FU0OGS0341W[W! #+VWDWXV=#H[SHFWHG#:*#ODVW#FDOO,

• ([SOLFLW#7UHH#5RXWLQJ?GUDIW0KXPPHO0PSOV0H[SOLFLW0WUHH0331W[W!#+DFFHSWHG#DV#QHZ#JURXS#GUDIW,

• 03/6#5RXWLQJ#'\QDPLFV?GUDIW0EKDQL0PSOV0WH0DQDO0331W[W!

• ([SOLFLW#5RXWH#6XSSRUW#LQ#03/6?GUDIW0GDYLH0PSOV0H[SOLFLW0URXWHV0331W[W!

QoS support

• 03/6#6XSSRUW#RI#'LIIHUHQWLDWHG#6HUYLFHV#E\#$70#/65V#DQG#)UDPH#5HOD\#/65V?GUDIW0LHWI0PSOV0GLII0H[W0331W[W!# +QHZ#:*#GRF,

Multicasting:

• ,3#0XOWLFDVW#6XSSRUW#LQ#03/6#1HWZRUNV?GUDIW0DFKDU\D0LSVRIDFWR0PSOV0PFDVW0331W[W!

• ,3#0XOWLFDVW#6XSSRUW#LQ#03/6#1HWZRUNV?GUDIW0DFKDU\D0LSVRIDFWR0PSOV0PFDVW0331W[W!

• ,&03#([WHQVLRQV#IRU#0XOWL3URWRFRO#/DEHO#6ZLWFKLQJ?GUDIW0ERQLFD0LFPS0PSOV0331W[W!# +H[SHFWHG#QHZ#:*#GUDIW,

• )UDPHZRUN#IRU#,3#0XOWLFDVW#LQ#03/6?GUDIW0RRPV0PSOV0PXOWLFDVW0341W[W!

03/6#6WXG\

3DJH#58

• 03/6#IRU#3,0060?GUDIW0RRPV0PSOV0SLPVP0331W[W!

$SSOLFDWLRQV#RI#03/6

MPLS improves network management of core IP networks and enables the introduction of newservices. Main emphasis is here on the possibilities of constructing IP VPNs using MPLS technologyand benefits gained for enhanced traffic management of the network. The general outline documentson Requirements for Traffic Engineering is already in an advanced stage, while it is expected thatfurther development of working documents will be handed over to a new standardization groupconcentrating on the issue.

Traffic Engineering related documents:

• 5HTXLUHPHQWV#IRU#7UDIILF#(QJLQHHULQJ#2YHU#03/6?GUDIW0LHWI0PSOV0WUDIILF0HQJ0331W[W!# +VWDWXV=#:*#ODVW#FDOO,

• 03/6#7UDIILF#(QJLQHHULQJ#0DQDJHPHQW#,QIRUPDWLRQ#%DVH#8VLQJ#60,Y5?GUDIW0LHWI0PSOV0WH0PLE0331W[W!

• 4XDOLW\#RI#6HUYLFH#XVLQJ#7UDIILF#(QJLQHHULQJ#RYHU#03/6=#$Q#$QDO\VLV?GUDIW0EKDQL0PSOV0WH0DQDO0331W[W!

• ,*3#5HTXLUHPHQWV#IRU#7UDIILF#(QJLQHHULQJ#ZLWK#03/6?GUDIW0OL0PSOV0LJS0WH0331W[W1=!# +QHZ#:*#GRF#0!#WR#7(#:*,

• )UDPHZRUN#IRU#7UDIILF#0DQDJHPHQW#LQ#03/6#1HWZRUNV?GUDIW0YDDQDQHQ0PSOV0WP0IUDPHZRUN0331W[W!

• 03/6#2SWLPL]HG#0XOWLSDWK#+03/600203,?GUDIW0YLOODPL]DU0PSOV0RPS0341SV! +QHZ#:*#GRF#0!#WR#7(#:*,

• 0$7(=#03/6#$GDSWLYH#7UDIILF#(QJLQHHULQJ?GUDIW0ZLGMDMD0PSOV0PDWH0331W[W!

• 3HUIRUPDQFH#,VVXHV#LQ#9&00HUJH#&DSDEOH#$70#/65V?GUDIW0ZLGMDMD0PSOV0YF0PHUJH0341W[W!

• ([WHQVLRQV#WR#5693#IRU#7UDIILF#(QJLQHHULQJ?GUDIW0VZDOORZ0PSOV0UVYS0WUDIHQJ0331W[W!

submissions regarding VPN service:

• ,3#931#5HDOL]DWLRQ#XVLQJ#03/6#7XQQHOV?GUDIW0FDVH\0YSQ0PSOV0331W[W!

• 03/6#0DSSLQJV#RI#*HQHULF#931#0HFKDQLVPV?GUDIW0KHLQDQHQ0JHQHULF0YSQ0PSOV0331W[W!

• 931#VXSSRUW#ZLWK#03/6?GUDIW0KHLQDQHQ0PSOV0YSQ0341W[W!

• 03/6#931#$UFKLWHFWXUH?GUDIW0MDPLHVRQ0PSOV0YSQ0331W[W!

• &3(#EDVHG#931V#XVLQJ#03/6?GUDIW0OL0PSOV0YSQ0331W[W!

• %*3203/6#931V#+5)&#587:/#,QIRUPDWLRQDO/#0DUFK#4<<<,

03/6#6WXG\

3DJH#59

9 ,3#4XDOLW\#RI#6HUYLFH#7HVWLQJ

One of the advantages of MPLS is that it offers methods for Quality of Service support in IP networks.The introduction of different traffic classes lead to more complex network architectures. This is a newdemand for testing not only the availability but also the Quality of Service. This chapter describes anapproach for Quality of Service testing within MPLS networks. Although the main focus is MPLS thiscan be a general approach of QoS testing within all kinds of IP networks.

914 $UFKLWHFWXUHV#IRU#,3#4R6

The delivery of good-quality audio or video streams typically requires QoS capabilities. Therefore, IPnetworks have to provide some guarantee of performance such as connectivity, speed and reliability[Ferg98]. The two different approaches to support IP QoS are:

• Signalled QoS: This approach is based on dynamic establishment of connections by signallingprotocols (e.g. RSVP, ATM SVC). It is used with the Integrated Service (IntServ) model. TheIntServ scheme provide per-flow classification and guaranteed delays to support also real-timetraffic.

• Configured QoS: This approach mainly represents a bandwidth-management scheme for IPnetworks. It is used with the Differentiated Services (DiffServ) model. The existing Type-of-Service (ToS) byte in every IP packet header marks the priority or service level that a packetrequires.

A possible way to provide QoS in IP networks is to use ATM as a transport mechanism [Fer98][Gin96]. Such a network is able to offer QoS mechanisms on data link layer (ATM) as well as onnetwork layer (IP). In ATM core networks, the IP data streams are transported over virtual circuits.This can be accomplished by using PVCs, set up by the network operator, or SVCs set up on demandby end systems or routers.

915 7HVW#0HWKRGV

An overview on different methods to test QoS in IP networks will be presented [Buc96] [RFC1944].The basic configurations for this measurements are:

1. Passive monitoring of real data flows; a nonintrusive method.

Here the monitoring tool determines the profile of the traffic streams at dedicated points of observationand checks the results against the traffic contract or specification. This can be done in combinationwith an observation of resource reservation/signalling messages (RSVP), if required. Anotherpossibility is to request the traffic contract settings from a router (e.g. via SNMP). On TCP flows,packet loss can be detected by observing the number of retransmissions and by checking sequencenumber errors.

03/6#6WXG\

3DJH#5:

Sender Receiver

Monitor

System under Test

Figure 6: Generic scenario for passive flow monitoring.

2. Active generation of test data flows with subsequent analysis of the flows; an intrusive method.

Here test traffic is generated and the monitoring tool determines the profile of these traffic streams atdedicated points of observation. The QoS parameters are detected by a comparator check of trafficstreams at the measurement point(s) and a reference point. This scenario can be extended incombination with artificial load or real traffic in the background.

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�� M o nito r

Sy s te m u nde r T e st

��

��

��

��

��

�� G e n e ra to r

��

��

��

��

��

��

��

��

��

S en de r R e c e ive r

Figure 7: Generic scenario for active generation of test traffic.

916 7HVW#$SSOLFDWLRQV

The general testing configurations have to be applied when considering IP QoS measurements, takingthree main target groups into account:

• service/network providers have to assure a certain quality to their customers,

• users of network services want to be sure to get what they have paid for,

• manufacturers and developers have to check their algorithms and complex systems.

For this purpose, two different types of test applications can be identified:

1. Testing the end-to-end QoS from either the users or the service/network providers perspective, e.g.

03/6#6WXG\

3DJH#5;

when running an real-time application over a network cloud. In this scenario the user is interestedin performance parameters like throughput, delay, jitter and loss on packet level, which theservice/network provider has to guarantee.

2. Testing specific QoS mechanisms (e.g. queuing or traffic shaping) in a system of one or morenetworking devices (e. g. network nodes). In this case e.g. the relation of low and high prioritytraffic to congestion or the mechanism of Token Bucket Traffic Shaping can be examined by alsomeasuring the performance parameters. This scenario is dedicated to manufacturers andservice/network providers, where the assurance of certain quality levels has to be evaluated.

In the first approach the testing of end-to-end QoS is done by monitoring a single flow of test data(network application or foreground traffic) at the edges of the IP network (system under test - SUT).Testing of QoS mechanisms is a superset of the first approach by generating multiple different flows oftest data at the ingress of a specific network device (SUT). The forwarded packet flows are observed atthe egress. For simulating different load conditions additional background traffic is used.

03/6#6WXG\

3DJH#5<

917 7HVW#(QWLWLHV#DQG#,3#4R6#3DUDPHWHUV

For testing IP QoS parameters, several test entities are necessary (see Test Methods). Thesender introduces the test traffic which can either be caused by a network application or aspecial test traffic generator. The receiver consumes the test traffic and responds if necessary.This entity is realized by corresponding network applications (e.g. video conferencing), hosts(e.g. ping, netperf) or can even be dropped in some cases. The monitor captures data flows atdedicated points of observation (PCOs) for further analysis. A generator can be applied toadjust certain load conditions. A pre-condition for these examinations is, that the clocks of themeasurement devices capturing the data flows at different PCOs must be synchronized.

As stated earlier, this approach to test IP QoS is based on the measurement of the followingparameters which influence the quality of data transfers: throughput, delay, loss, jitter. Theirdefinition [RFC1242] and the requirements to determine these values will be discussedshortly.

Throughput

The maximum data transfer rate at which none of the offered frames are dropped betweenmeasurement point A and measurement point B in a network. For this purpose the transferrate is calculated according to the timestamps of packets captured at any measurement pointand throughput is determined. The given definition [RFC1242] of throughput correspondswith lossless throughput of the ATM Forum [ATMF96], where basically three different typesare distinguished: lossless throughput, peak throughput and full-load throughput.

Delay

The time needed to send a packet from a point A to another point B over a link. In this casetime counts when the first bit has left A until it arrives at B. PDU transfer delay is determinedby subtracting the timestamps of identical packets captured at two measurement points. Toavoid failures caused by permutations and misinsertion of IP packets, one have to correlatesame packets at the two measuarement points. For this purpose you need a unique packetidentification (eg. the sequence number of a TCP/IP PDU).

Jitter

The variation of the delay between point A and another point B in a network under constantload. Jitter is determined by calculating transfer delay for packets captured at twomeasurement points. To avoid failures caused by misinsertion, the SNR of the frames has tobe checked (see also Delay).

Loss

Percentage of frames that should have been forwarded from point A to point B in a networkunder determined load condition, but were not forwarded due to lack of resources ormisbehavior. Loss is determined by comparing packets captured at two measurement points.

03/6#6WXG\

3DJH#63

918 6:2+:#5HTXLUHPHQWV#IRU#7HVWLQJ#,3#4R6

For testing IP QoS parameters, several test entities are necessary (see Testing Methods).

Load Generators

For different test configuration one need different types of load generators.

1. Test traffic caused by a common network application (e.g. a video conference betweentwo workstations).

2. Test traffic generated on a workstation by a special test application.

3. To generate precise traffic streams with full link rates one have to use special loadgenerator hardware. For example the SmartBits from NetCom Systems or the TANYAboard of GMD FOKUS.

The load generator should have to following functions:

• To generate foreground and background traffic the load generator must be able to send IPpacktets with special IP header and payload data.

• For transfer delay measurements the traffic genarator should be able to timestampoutgoing IP packets.

• Traffic generation with different traffic profiles (constant load, bursts, poission, ...)

Monitor/Capture Units

The monitor points should have the following capabilities:

• Large capture buffer or the ability to store captured traffic in real time.

• High resolution timestamping of captured PDUs.

• Clock synchronisation between multiple monitor points.

• Protocol decoder for PDUs at different layers (ATM signaling, TCP/IP, IP Routing,MPLS protocols, ... )

919 3UDFWLFDO#0HDVXUHPHQWV

The IP QoS measurements described in this section represent practical experiments carriedout with the TANYA ATM test interface and the extended FAST ATM Tool Set. The testswere performed in the MPLS test bed of GMD FOKUS. The test bed consists of Cell SwitchRouter (CSR) equipment from Toshiba (three core routers and two edge devices). The CellSwitch Routers use the FANP protocol from Toshiba to negotiate ATM shortcuts betweentwo adjacent CSR nodes. FANP was developed before the MPLS working group wasfounded. To be MPLS compliant the CSRs are also capable to use the lable distriburtionprotocol (LDP) e.g. to communicate with CISCO’s TAG switching equipment. The aim of theexperiment was to demonstrate and to verify the above QoS testing approach.

The following figure shows the test configuration.

03/6#6WXG\

3DJH#64

��

��

��

��

��

��

��

S w itc h ��

��

��

��

��

��

��

��

��

��

��

��

Lo ad

G en er a to r

��

��

��

IP F lo w

M o n it o r

��

��

��

��

��

��

��

��

��

��R o ut e r

M 2M1

Sys tem unde r Te s t

CSR

��

��

��

IP F lo w

M o n it o r

Figure 8: Test configuration

As SUT a single CSR was used. The ATM-Tester generates IP traffic with differentbandwidth. At the same time the traffic will be captured at two points: Point M1 before thetraffic reaches the CSR and point M2 after the traffic has passed the CSR. The evaluation ofthe captured traffic determines the performance parameters cell loss, cell transfer delay andcell delay variation.

TCP/IP PDU interarrival time variations

For the measurement of interarrival time variations a TCP/IP stream with constant bandwidthof 2 MBit/s was generated.

��

��

��

��0

�� 500

�� 1000

�� 1500

�� 2000

�� 2500

�� 3000

�� 3500

�� 4000

�� 4500

��

��

2650

��

��

2700

��

��

2750

��

��

2800

��

��

2850

��

��

��

��

��

occ

ure

nce

s

t ime/micro sec

PDU Interarrival Time Variation

Switched��

��

��

��

Routed��

��

��

��

��

��

��

��

��

��

��

��

��

��

As it was expected the variation of the interarrival times in the routed mode is much higher.

03/6#6WXG\

3DJH#65

Transfer delay measurements

The average switching delay of AAL 5 PDUs is about 17.5 µs and as expected the variance isvery low (see the next figure).

��

��

��

��0

�� 500

�� 1000

�� 1500

�� 2000

�� 2500

�� 3000

�� 3500

��

��

14

��

��

15

��

��

16

��

��

17

��

��

18

��

��

19

��

��

20

��

��

21

��

��

22

��

��

23

��

��

��

��

��

occu

renc

es

t ime/micro sec

transfer delay distribution

AAL5 PDU��

��

��

��

Figure 9: Transfer delay (switched)

The minimum routing delay of AAL 5 PDUs is about 210 µs. There are two maximums at225 µs and 295 µs and there is a high variance.

��

��

��

��0

��

��10

�� 20

��

��30

��

��40

��

��50

�� 60

�� 70

�� 80

��

��

200

��

��

220

��

��

240

��

��

260

��

��

280

��

��

300

��

��

320

��

��

340

��

��

��

��

��

occ

ure

nce

s

t ime/micro sec

transfer delay distribution

AAL5 PDU��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Figure 10: Transfer delay (routed)

03/6#6WXG\

3DJH#66

Throughput measurements

a) On cut through connections maximum throughput is the linkrate. There was no cell loss.

b) To measure the throughput over a default connection a constant stream of IP packets wassent with increasing bandwidth. The MTU size was 1500 bytes. The results show thefollowing figure.

��

�� 0

�� 10

�� 20

�� 30

�� 40

�� 50

�� 60

�� 70

��

��

0

��

��

2

��

��

4

��

��

6

��

��

8

��

��

��

��

��

��

��

MB

it/s

time/s

TCP/IP throughput

send��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

receive

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Figure 11: IP throughput over default connection

In this test configuration the CSR routes about 5000 packets/s without loss. The maximumrate is about 7000 packets/s.

03/6#6WXG\

3DJH#67

: 5HIHUHQFHV

:14 9HQGRUV

Ascend

White Paper: Building Tomorrow’s Internet Backbone (1997)

http://www.ascend.com/3681.html

Ascend white paper: Building Tomorrow´s Internet Backbone

The paper starts with a description of internet phases (routed, switched, MPLS) and concen-trates on deployment of ASCEND products. There are two families, the GRF family of IPswitches (based on backbone routing approach) and IP navigator (based on backbone switch-ing). The later sections compare these families for usage’s in different sized IP networks andfor offering services.

White Paper: IP Navigator MPLS Executive Overview

http://www.ascend.com/3681.html

Basic overview on MPLS with the focus on Label Switched Path (LSP) mechanisms andeffects on switching and routing technology. After discussing the advantages of MPLS(starting with performance and multicast support) an overview on IP Navigator MPLS isgiven. Ascend claims to offer a multivendor, multiservice, multiprotocol and open strategy,using the Virtual Network Navigator (routing including feature for managing ATM andFrame Relay) in the core.

CISCO

White Paper: Enabling Business IP Services with Multiprotocol Label Switching

http://www.cisco.com/warp/public/790/ipatm/mpls_wp.htm

The paper includes definition of MPLS terms and examples of MPLS mechanism operation,such as packet forwarding through MPLS. For QoS the paper discussed several mechanismson IP packet level. It is the same for VPN service, it is discussed as an example for routingprotocols.

ERICSSON

White Paper: MPLS - the future of IP backbone technology

http://www.ericsson.se/datacom/technology/mpls/mpls2.shtml

03/6#6WXG\

3DJH#68

FORE

White Paper: Building an IP Service Network

http://www.fore.com/products/wp/index.html

FORE starts from ATM point of view, explaining extended features of ATM (mostly featuresof PNNI). This is seen as a major building block for offering MPLS mechanism, providing anIP service network. FORE addresses topics like traffic engineering, network failure recoveryand router scalability from the ATM side.

:15 /LWHUDWXUH

[UNI3.1] ATM Forum: ATM User Network Interface Specification Version 3.1, af-uni-0010.002, September 1994.

[Fer98] Paul Ferguson, Geoff Huston: Quality of Service - Delivering QoS on theInternet and in Corporate Networks, Wiley Computer Publishing, New York,USA, 1998.

[Gin96] David Ginsburg: ATM Solutions for Enterprise Internetworking, Addison-Wesley, Harlow, England, 1996.

[RFC1242] S. Bradner: Benchmarking Terminology for Network Interconnect Devices,Request for Comments 1242, July 1991.

[ATMF96] ATM Forum: Performance Testing Specification, Version 1.0, 1996.

[Buc96] Robert W. Buchanan, Jr.: The Art of Testing Network Systems, WileyComputer Publishing, New York, USA, 1996.

[RFC1944] S. Bradner, J. McQuaid: Benchmarking Methodology for Network InterconnectDevices, Request for Comments 1944, May 1996.

03/6#6WXG\

3DJH#69

; $QQH[=#)XUWKHU#/LWHUDWXUH#DQG#5HVRXUFHV#RQ#03/6

;14 7XWRULDOV#DQG#,QWURGXFWLRQ#WR#03/6=• (YROXWLRQ#RI#0XOWLSURWRFRO#/DEHO#6ZLWFKLQJ/#$1#9LVZDQDWKDQ/#11#)HOGPDQQ/#=K1#:DQJ/#51#&DOORQ

,(((#&RPPXQLFDWLRQ#0DJD]LQH/#9RO1#69/#1R1#8#0D\#4<<;/#SS1#49804:6D#JRRG#LQWURGXFWLRQ#WR#03/6#ZULWWHQ#E\#PDLQ#FRQWULEXWRUV#WR#WKH#,(7)#03/6#:*/#FRYHUV#WKH#PDLQ#WRSLFV#DGGUHVVHG#LQWKH#ZRUNLQJ#JURXS/#LW#LQFOXGHV#DV#EDFNJURXQG#LQIRUPDWLRQ#DQ#RYHUYLHZ#RQ#SULRU#ZRUN#RQ#,3#RYHU#$70#OLNH#$70$53/1+53#DQG#/$1(/#DQG#SURSULHWDU\#SURSRVDOV#WKDW#LQIOXHQFHG#03/6#VWDQGDUGL]DWLRQ#VXFK#DV#7DJ#6ZLWFKLQJ/#$5,6#DQG#,31DYLJDWRU1

• 1H[W0*HQHUDWLRQ#5RXWLQJ#IRU#,63V=#&DVFDGH¶V#,3#1DYLJDWRU#DQG#&LVFR¶V#7DJ#6ZLWFKLQJ#E\#&1#6HPHULD6&20#1HWZRUNLQJ#6ROXWLRQV#:KLWH#3DSHU#4<<:KWWS=22ZZZ16FRP1FRP2QVF283464:1KWPOFRPSDULVRQ#RI#WKH#WZR#DSSURDFKHV/#WKDW#ZHUH#KLJKO\#LQIOXHQWLDO#RQ#WKH#GHYHORSPHQW#RI#03/6/#LQFOXGLQJ#D#FRPSUHKHQVLYHUHIHUHQFH#VHFWLRQ>#D#FRPSDQLRQ#ZKLWH#SDSHU#FRYHUV#/$1#DQG#HQWHUSULVH#VROXWLRQV#VXFK#DV#6&20#)DVW#,3/#,SVLORQ#,3VZLWFKLQJ/#&DEOHWURQ¶V#6HFXUH)DVW

• 7UDIILF#(QJLQHHULQJ#IRU#WKH#1HZ#3XEOLF#1HWZRUN/#&KXFN#6HPHULD/##-XQLSHU#1HWZRUNV/#-DQ#4<<<KWWS=22ZZZ1MXQLSHU1QHW2OHDGLQJHGJH2ZKLWHSDSHUV27(B1311KWPO([WHQVLYH#GLVFXVVLRQ#RI#SUREOHPV#UHODWHG#WR#WUDIILF#HQJLQHHULQJ/#DQG#URXWHU#DUFKLWHFWXUH/#DQG#SUHVHQWDWLRQ#RI#WKHDSSURDFK#WDNHQ#E\#-XQLSHU#1HWZRUNV/#ZKLFK#IROORZV#D#5693#FHQWHUHG#ODEHO#GLVWULEXWLRQ#VWUDWHJ\

• 0XOWLSURWRFRO#/DEHO#6ZLWFKLQJ#+03/6,#7KH#7HFKQRORJ\#*XLGH#6HULHV#WHFKJXLGH1FRPVSRQVRUHG#E\#(QQRYDWH#1HWZRUNV/#,QFKWWS=22ZZZ1WHFKJXLGH1FRP2FRPP2VHFBKWPO2PSOV1VKWPOJHQHUDO#LQWURGXFWLRQ/#GLVFXVVLQJ#DSSOLFDWLRQ#RI#03/6#IRU#,3#RYHU#$70/#7UDIILF#HQJLQHHULQJ#DQG#931#VHUYLFHV/#IHDWXULQJWKH#(QQRYDWH#(QYR\#4933#ODEHO#HGJH#URXWHU

• $VFHQG#,3#1DYLJDWRU#03/6/#$UFKLWHFWXUH#*XLGH$VFHQG#&RPPXQLFDWLRQV/#,QF1#4<<<KWWS=22ZZZ1DVFHQG1FRP2GRFV2WHFKGRFV2LSQYPSDJ1SGISURYLGHV#GHWDLOV#WR#$VFHQG¶V#DSSURDFK#WRZDUGV#03/6/#LQ#SDUWLFXODU#9&#PHUJLQJ#DQG#PXOWLSRLQW0WR0SRLQW#/63V

• 0XOWLSURWRFRO#ODEHO#VZLWFKLQJ#LQ#$70#QHWZRUNV/#*1#+DDJDDUG/#01#:ROI(5,&6621#5HYLHZ#-RXUQDO#1R14#4<<;>KWWS=22ZZZ1HULFVVRQ1VH25HYLHZ2HU4B<;2DUW82DUW81KWPODQRWKHU#ZHOO#ZULWWHQ#LQWURGXFWLRQ#WR#03/6#EDVLFV/#LQFOXGLQJ#D#ODUJHU#VHFWLRQ#GHVFULELQJ#(ULFVVRQ¶V#$;'#634#$70#VZLWFKZLWK#03/6#IXQFWLRQDOLW\

;15 0DJD]LQH#)HDWXUH#$UWLFOHV

• 'LIIVHUY#DQG#03/6=#$#4XDOLW\#&KRLFH#7HFK#7XWRULDO##%\#$VKOH\#6WHSKHQVRQ'DWD&RPPXQLFDWLRQV#1RYHPEHU#54/#4<<;GLVFXVVHV#'LII6HUY#DQG#03/6#DV#WZR#DSSURDFKHV#WR#DGGUHVV#4R6#LQ#,3#EDFNERQH#QHWZRUNV

• 8SJUDGLQJ#WR#)LUVW#&ODVV#E\#3HWHU#/DPEHUW#DQG#'DZQ#%XVKDXV7HOH1&RP#-XO\#34/#4<<;/#,VVXH=#63;GLVFXVVHV#'LII6HUY#DQG#03/6#DV#HQDEOLQJ#WHFKQRORJLHV#IRU#FODVV0EDVHG#VHUYLFHV#DQG#VFDODEOH#WUDIILF#PDQDJHPHQW/UHSRUWV#RQ#ILUVW#HYDOXDWLRQ#RI#WHFKQRORJ\#E\#ODUJHU#VHUYLFH#SURYLGHUV=

.. As of June, Alcatel Telecom, Argon Networks Inc. (Littleton, Mass.), Ascend, Avici Systems Inc.(Chelmsford, Mass.), Bay Networks Inc., Ericsson Inc. (Richardson, Texas), General DataComm Inc.(Middlebury, Conn.), IBM Corp., Juniper Networks, Lucent, NetCore Systems Inc. (Wilmington,Mass.), Nexabit Networks Inc. (Westborough, Mass.), and Ennovate/Toshiba America Information

03/6#6WXG\

3DJH#6:

Systems Inc. (Boxborough, Mass./Irvine, Calif.) had joined Cisco in announcing availability ofprestandard MPLS implementations in their carrier-class routers and multiservice switches,...

Service providers already have begun testing implementations of the emerging standards in labs andlive networks. @Home Corp. (Redwood City, Calif.); MCI Communications Corp.; UUNetTechnologies Inc. (Fairfax, Va.), a subsidiary of WorldCom Inc.; and Verio Inc. (Englewood, Colo.)began testing Juniper's Junos software last January. UUNet and others have been testing Cisco'sDiffServe and Tag Switching software for several months. In May, Qwest CommunicationsInternational Inc. (Denver) agreed to test Avici's MPLS-capable Terabit Switch Router. WilliamsCommunications Groups (Tulsa, Okla.) is testing Argon Networks' switch router, and last month Net-1Singapore Pte Ltd. began testing Alcatel's IP@ATM platform over a live national ATM network.

;16 ,QWHUQHW#UHVRXUFHV• 0XOWL#/D\HU#5RXWLQJ##SDJH#PDLQWDLQHG#E\#1RULWRVKL#'HPL]X

KWWS=22LQIRQHW1DLVW0QDUD1DF1MS2PHPEHU2QRUL0G2POU29HU\#FRPSUHKHQVLYH#VHOHFWLRQ#RI#OLQNV#WR#03/6#UHODWHG#GRFXPHQWV/#D#JRRG#VRXUFH#HVSHFLDOO\#IRU#ROGHU/#DOUHDG\#H[SLUHG,QWHUQHW#'UDIWV#WKDW#KDG#EHHQ#VXEPLWWHG#E\#LQGLYLGXDOV/#DQG#ZKLFK#DUH#QR#ORQJHU#DYDLODEOH#IURP#,(7)#VHUYHU1

• 0XOWLSURWRFRO#/DEHO#6ZLWFKLQJ#0DLQWDLQHG#E\#MLQVXK#GFQ1VRRQJVLO1DF1NUKWWS=22GFQ1VRRQJVLO1DF1NU2aMLQVXK2KRPH0PSOV1KWPOVLPLODU#PDWHULDO#DV#SDJH#DERYH

;17 9HQGRUV#RI#03/6#7HFKQRORJ\#DQG#5HIHUHQFHV#WR#3URGXFW#5HVRXUFHV

• Ascend http://www.ascend.comIP Navigator MPLS Family http://www.ascend.com/3663.html

• Cisco http://www.cisco.com/Tag Switching Technology http://www.cisco.com/warp/public/732/tag/

• Ericsson http://www.ericsson.se/MPLS Page http://www.ericsson.se/datacom/mpls.htm

• FORE http://www.fore.com/Building an IP Service Network http://www.fore.com/products/wp/index.html

• General DataComm http://www.gdc.com/What is MPLS ? http://www.gdc.com/corporate_news/9809/mpls.html

• IBM Networking http://www.networking.ibm.com/Integrated Switch Router (ISR) Technologyhttp://www.networking.ibm.com/isr/isrhome.html

• Lucent http://www.lucent.com/MPLS page http://www.bell-labs.com/user/zhwang/mpls/

• Newbridge http://www.newbridge.com/Carrier Switched Routing Solutionshttp://prodweb.newbridge.com:80/resources/solution_sheets/html/csr/index.html

• NORTEL Networks (former Bay Networks) http://www.nortelnetworks.com/

03/6#6WXG\

3DJH#6;

Terabit Switch Routerhttp://www1.nortelnetworks.com/broadband/Carrier_Data_Networks/terabit.html

New Start-up Companies with innovative products for MPLS

• Abatis (founded by former Newbridge engineers focusing on packet classifications)

• Argon Networks Inc. (Littleton, Mass.) http://www.Argon.com/GigaPacket Node (GPN) http://www.Argon.com/product/index.htm

• Avici Systems, Inc http://www.avici.com/main.htmlTerabit Switch Router Data Sheet http://www.avici.com/pdfs/Avici_TSR.pdfWP: Delivering Internet Quality of Service http://www.avici.com/pdfs/QoS.pdf

• Ennovate http://www.ennovatenetworks.com/Multilayer Switching Technology Visionhttp://www.ennovatenetworks.com/tech/index.htm

• Juniper, http://www.juniper.net/Networks M40 Internet backbone routerhttp://www.juniper.net/leadingedge/whitepapers/backbone-routers.fm.html

• NexaBit Networks Marlborough, MA http://www.nexabit.com/NX64000 Multi-Terabit Switch/Router http://www.nexabit.com/products.htmlWP: The Multiservice IP Carrier Networkhttp://www.netreference.com/PublishedArchive/WhitePapers/WPIndex.html

03/6#6WXG\

3DJH#6<

< $QQH[=#&XUUHQW#ZRUNLQJ#GUDIWV#RI#WKH#,(7)#03/6#:*http://www.ietf.org/ids.by.wg/mpls.html

"A Framework for Multiprotocol Label Switching", Ross Callon, George Swallow, N.Feldman, A. Viswanathan, P. Doolan, A. Fredette, 11/26/1997 This document discusses technical issues and requirements for the Multiprotocol Label Switching working group. It is an initial draft document to produce a coherent description of all significant approaches being considered by the working group.

"Use of Label Switching With RSVP", Bruce Davie, Y Rekhter, A. Viswanathan, S. Blake,Vijay Srinivasan, E. Rosen, 03/12/1998 Multiprotocol Label Switching (MPLS) allows labels to be bound to various granularities of forwarding information, including application flows. This document presents a specification for allocating and binding labels to RSVP flows, and to distributing the appropriate binding information using RSVP messages.

"Multiprotocol Label Switching Architecture", Ross Callon, A. Viswanathan, E. Rosen,02/19/1999 specifies the architecture for Multiprotocol Label Switching (MPLS).

"MPLS Label Stack Encoding", D. Farinacci, Tony Li, A. Conta, Y Rekhter, Dan Tappan, E.Rosen, G. Fedorkow, 09/25/1998 This document specifies the encoding to be used by an LSR in order to transmit labeled packets on PPP data links, on LAN data links, and possibly on other data links. This document also specifies rules and procedures for processing the various fields of the label stack encoding

"The Assignment of the Information Field and Protocol Identifier in the Q.2941 GenericIdentifier and Q.2957 User-to-user Signaling for the Internet Protocol", M. Suzuki,12/16/1998 The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. The assignment, that is specified in section 4 of this document, is designed for advanced B-ISDN signaling support of the Internet protocol, especially the B-ISDN signaling support for the connection that corresponds to the session in the Internet protocol which is clarified in section 2. This specification provides an indispensable framework for the implementation of long-lived session and QoS- sensitive session transfers over ATM.

"Use of Label Switching on Frame Relay Networks Specification", Andy Malis, A. Conta, P.Doolan, 11/20/1998 This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. Furthermore, it extends and clarifies portions of the Multiprotocol Label Switching Architecture described in [ARCH] and the Label Distribution Protocol (LDP) described in [LDP] relative to Frame Relay Networks. MPLS enables the use of Frame Relay Switches as Label Switching Routers (LSRs).

"VCID Notification over ATM link", Noritoshi Demizu, Y. Katsube, Hiroshi Esaki, K.Nagami, P. Doolan, 12/23/1998

03/6#6WXG\

3DJH#73

The ATM Label Switching Router (ATM-LSR) is one of the major applications of label switching. Because the ATM layer labels (VPI and VCI) associated with a VC rewritten with new value at every ATM switch nodes, it is not possible to use them to identify a VC in label mapping messages. The concept of Virtual Connection Identifier (VCID) is introduced to solve this problem. VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property.

"Carrying Label Information in BGP-4", Y Rekhter, E. Rosen, 02/17/1999. (7930 bytes) When a pair of Label Switch Routers (LSRs) that maintain BGP peering with each other exchange routes, the LSRs also need to exchange label mapping information for these routes. The exchange is accomplished by piggybacking the label mapping information for a route in the same BGP Update message that is used to exchange the route. This document specifies the way in which this is done.

"Requirements for Traffic Engineering Over MPLS", Michael O'Dell, Joseph Malcolm,Johnson Agogbua, Daniel Awduche, Jim McManus, 08/28/1998 This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. These capabilities can be used to optimize the utilization of network resources, and enhance traffic oriented performance characteristics.

"LDP Specification", Bob Thomas, N. Feldman, P. Doolan, Loa Andersson, A. Fredette,02/01/1999 A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using the Label Distribution Protocol (LDP).

"Definitions of Managed Objects for the Multiprotocol Label Switching, Label DistributionProtocol (LDP)", Joan Cucchiara, J. Luciani, Hans Sjostrand, 08/31/1998 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) as defined in [17]. This memo does not specify a standard for the Internet community.

"MPLS using ATM VC Switching", Keith McCloghrie, Bruce Davie, George Swallow, YRekhter, E. Rosen, P. Doolan, Jeremy Lawrence, 11/18/1998. The MPLS Architecture [1] discusses a way in which ATM switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs.

"LDP State Machine", Eric Gray, Liwen Wu, Pierrick Cheval, Christophe Boscher,02/23/1999 In the current LDP draft [Ref5], there is no state machine specified for processing the LDP messages. We think that defining a common state machine is very important for interoperability between different ldp implementations. This draft provides state machine tables for ATM switch LSRs. We begin in section 2 by defining a list of terminologies.

03/6#6WXG\

3DJH#74

Then in section 3, we propose two sets of state machine tables for ATM switch LSRs, one for non-vc merge ATM LSRs and one for the vc merge ATM LSRs. Finally, in section 4, we outline the possible future working items. Even though the state machines in this document are specific for ATM-LSR, they can be easily adapted for other types of LSRs.

"Constraint-Based LSP Setup using LDP", Bilel Jamoussi, 03/01/1999 Label Distribution Protocol (LDP) is defined in [LDP] for distribution of labels inside one MPLS domain. One of the most important services that may be offered using MPLS in general and LDP in particular is support for constraint-based routing of traffic across the routed network. Constraint-based routing offers the opportunity to extend the information used to setup paths beyond what is available for the routing protocol. For instance, an LSP can be setup based on explicit route constraints, QoS constraints, and others. Constraint-based routing (CR) is a mechanism used to meet Traffic Engineering requirements that have been proposed by [FRAME], [ARCH] and [TER]. These requirements may be met by extending LDP for support of constraint-based routed label switched paths (CRLSPs). Other uses exist for CRLSPs as well ([VPN1], [VPN2] and [VPN3]). This draft specifies mechanisms and TLVs for support of CRLSPs using LDP. The Explicit Route object and procedures are extracted from [ER].

"Extensions to RSVP for LSP Tunnels", Der-Hwa Gan, Tony Li, George Swallow, LouBerger, Vijay Srinivasan, Daniel Awduche, 02/26/1999 This document describes the use of RSVP, including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS. Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in [3]. We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks. Finally, we propose a number of mechanisms to reduce the refresh overhead of RSVP. The extensions can be used to reduce processing requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP message is lost and, when desired, eliminate the generation of refresh messages. An extension to support detection of when an RSVP neighbor resets its state is also presented. These extension present no backwards compatibility issues.

"MPLS Traffic Engineering Management Information Base Using SMIv2", A. Viswanathan,Cheenu Srinivasan, 02/22/1999 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling an Multi-Protocol Label Switching (MPLS) [MPLSArch, MPLSFW] Labeled Switched Router (LSR) and for MPLS based traffic engineering.

"MPLS Capability set ", Loa Andersson, Tom Worster, Bilel Jamoussi, Muckai Girish,02/23/1999 Several protocols might be used for Label Distribution in an MPLS network, e.g. Label Distribution Protocol (LDP), including the part of LDP described in Constraint-Based LSP Setup using LDP, the BGP-4 and RSVP. The functionality defined in those protocols are to some extent overlapping, but also complementary. This document

03/6#6WXG\

3DJH#75

specifies a number of MPLS Capability sets that can be used to define what is needed from an MPLS implementation in order to interwork with other implementations. The number of Capability sets might change in the future.

"Explicit Tree Routing", Heinrich Hummel, Swee Loke, 02/26/1999 This draft proposes the TREE ROUTE TLV that encodes a tree structured route which can be used to carry explicit routing information. It also specifies the progression of the TLV from the root of the tree to the leaf nodes. Every node that the TLV traversed has to decode/process the TLV in such a way that the correct child link/ nodes are determined as well as the respective subtree route information. Individual Information targetted for any specific node can also be packed into this TREE ROUTE TLV. The draft also presents the benefits of using TREE ROUTE TLV in MPLS. The applications include constrain based routing, traffic engineering, VPN installations and static multicast tree. The capability of carrying targetted information for individual node in the tree is very powerful in MPLS. This allows different nodes in the tree route to use the same tree route for different FECs. The application of this TLV is not mpls-specific. Other Working Groups may consider the proposed TLV as well.

mpls study - gwdgwebdoc.gwdg.de/ebook/ah/dfn/mpls-study.pdf · mpls is a flexible tool that enables...

Documents