03/6#6WXG\

MPLS Study

Project:

Competence Center for ATM Components

- DFN ComAC-

*0'#)2.86
5HVHDUFK#,QVWLWXWH#IRU#2SHQ#&RPPXQLFDWLRQ#6\VWHPV
#.DLVHULQ0$XJXVWD0$OOHH#64
'0438;<#%HUOLQ
*HUPDQ\

3DJH#4
 03/6#6WXG\

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

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

3DJH#5
03/6#6WXG\

7DEOH#RI#&RQWHQWV
4 ,QWURGXFWLRQ 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111117
5 ,QWHUQHW#%DFNERQH#1HWZRUNV111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111118
514 5RXWHU#EDVHG#,3#&RUH#1HWZRUNV 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111118
515 6ZLWFKHG#,3#&RUH#1HWZRUNV 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111119
6 0XOWLSURWRFRO#/DEHO#6ZLWFKLQJ 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111143
614 /DEHO#6ZLWFKHG#3DFNHW#)RUZDUGLQJ#DQG#03/6#1HWZRUNV11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111143
615 2SHUDWLRQ#RI#D#/DEHO#6ZLWFK#5RXWHU 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111144
7 $SSOLFDWLRQ#6FHQDULRV#IRU#03/6#LQ#WKH#%DFNERQH111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111146
714 7UDIILF#(QJLQHHULQJ#LQ#03/6#1HWZRUNV 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111146
71414 7UDIILF#(QJLQHHULQJ#LQ#WKH#,QWHUQHW 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111146
71415 $#)UDPHZRUN#IRU#7UDIILF#(QJLQHHULQJ#RYHU#03/61111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111148
715 9HQGRU#6ROXWLRQV111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111114;
71514 $VFHQG 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111114;
71515 &,6&2 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111114<
71516 )25( 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111114<
716 'HVLJQ#RI#D#03/6#EDFNERQH 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111153
8 6WDWXV#RI#03/6#6WDQGDUGL]DWLRQ 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111155
9 ,3#4XDOLW\#RI#6HUYLFH#7HVWLQJ11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111159
914 $UFKLWHFWXUHV#IRU#,3#4R6 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111159
915 7HVW#0HWKRGV 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111159
916 7HVW#$SSOLFDWLRQV111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111115:
917 7HVW#(QWLWLHV#DQG#,3#4R6#3DUDPHWHUV 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111115<
918 6:2+:#5HTXLUHPHQWV#IRU#7HVWLQJ#,3#4R6 111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111163
919 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#UHVRXUFHV1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111116:
;17 9HQGRUV#RI#03/6#7HFKQRORJ\#DQG#5HIHUHQFHV#WR#3URGXFW#5HVRXUFHV 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111116:
< $QQH[=#&XUUHQW#ZRUNLQJ#GUDIWV#RI#WKH#,(7)#03/6#:*1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111116<

3DJH#6
 03/6#6WXG\

4 ,QWURGXFWLRQ

MPLS (multiprotocol label switching) is a new WAN technology currently being standardized by
IETF that addresses key requirements of Internet Service Providers (ISP). ISPs can use MPLS
mechanisms 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 service
classes.

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

The basic idea for MPLS is to add short fixed length labels to IP packets that can be used by the
forwarding engines in the network to simplify packet forwarding. This provides a convenient means to
base 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 the
IP backbone networks are discussed. An overview on the current status of the IETF standardization
work is given together with a survey on available and announced products by major vendors; it
examines opportunities that MPLS can offer and identifies the open issues that still require further
research.

3DJH#7
03/6#6WXG\

5 ,QWHUQHW#%DFNERQH#1HWZRUNV

Historically, MPLS resulted from the effort to leverage benefits of ATM high speed switches for IP
core networks. People were unsatisfied with the MPOA (multiprotocol over ATM) approach of the
ATM Forum which seemed to become too complex and costly to implement, and progress in
standardization was too slow to fulfill pressing market needs. Therefore alternative proposals found
great resonance as, for instance, Ipsilon’s IP switch, which was to be followed soon by a number of
other 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 contrast
to the other proposals WAN solutions directed to core backbone. These approaches formed the starting
point for an IETF initiative to create a standardized approach towards label switching, which was now
termed multiprotocol label switching (MPLS).

For a better understanding of the benefits of MPLS technology it is helpful to look first at the present
approaches 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 approach
has its particular benefits and limitations.

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

The IP protocol provides a packet-based connectionless communication service. An IP based network

can be depicted as a mesh of linked host nodes with end-systems acting as packet source and
destination, and routers as intermediate nodes. IP packets are forwarded independently of each other
hop by hop from source to destination along a forwarding path, which may change over time due to
routing updates. The Internet is organized as a set of interconnected networks belonging to different
administrative domains which are also referred to as autonomous systems. The task of the IP network
layer is two-fold: it comprises the packet forwarding performed at each network node, and the control
of the forwarding process. For this purpose the router nodes run routing protocols. The routing
protocols handle the exchange of reachability information and, hence, enable each router to set up its
routing table.

In general, one distinguishes between two types of routing: the routing between administrative
domains and the routing within a single routing domain. Interdomain routing is mainly based on policy
decisions. The routing policy defines which traffic a ISP will allow to transit the routing domain and
depends on mutual peering agreements between adjacent providers. The intradomain routing
constructs routing paths to either end-nodes for traffic terminating within the domain or paths to an
egress router for transit traffic. The main objective of intradomain routing is to construct paths that use
network 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 1
illustrates the basic elements of an IP network.

3DJH#8
 03/6#6WXG\

BR
IR IR
BR

BR BR
BR BR

BR BR IR
IR IR
BR IR
IR BR
IR
IR IR BR
BR IR
BR
BR

IR Intra-domain Router Intradomain Routing

e.g. OSFP
ER Border Router
Interdomain Routing
e.g. BGP-4

Figure 1: Internet Autonomous Systems

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

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

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

• Intradomain routing protocols showed deficiencies as networks become more densely connected
leading to an inefficient use of network resources. The destination based routing approach would
tend to aggregate all traffic directed to the same destination. Instead of balancing the load more
evenly 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 a
switched core. Cell switching technology offered then a faster and simpler forwarding, with better

3DJH#9
03/6#6WXG\

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

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

Physical Toplogy Layer 3 Logical Toplogy

ER ER ER ER

ER ER
ER ER

ER ER
ER ER

ER ER

ATM Switch

ER edge IP Router

ATM Link

ATM SVC

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 logical
network topology on top of the physical ATM network topology. Figure 2 illustrates these different
network perspectives. The routers see only the point-to-point links without further knowledge whether
two links share common physical resources or not.

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

3DJH#:
 03/6#6WXG\

The edge routers connected by the ATM core form routing peer relationships among each other, for
this purpose they run an IGP (i.e. intradomain routing) protocol to exchange routing information. The
routing metric will reflect the PVC capacity and preferences, e.g. preferring the primary PVC over a
secondary backup, so routers will use the secondary PVC only in case of a primary link failure and
will 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 network
traffic creating more deterministic and stable network behavior. In contrast to former metric
manipulation, it became easier to perform traffic engineering through explicit routing of the PVC over
the ATM infrastructure, thus making it possible to distribute traffic more evenly across network
resources. This better network utilization translates at once into less congestion and better network
service at lower operational cost, and hence better competitiveness for network operators. ATM
switches also provide advanced network statistics and traffic monitoring facilities. Combined with the
flexibility and scalability of PVC bandwidth provides an efficient means for a rational network
evolution planning.

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

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

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

ATM switched cores duplicate the effort for network operation and management: a network operator
must administer two networks the physical ATM switched infrastructure and the logical IP network
topology. Each layer using its own addressing scheme and routing protocols. Additional devices for
integration of the technology such as address resolution servers become necessary. Events on layer
may 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 each
direction if secondary backup routes should be available to handle link failures. This strongly limits the
scalability of network size as the number of PVCs grows at the order of O(n2). Already adding a new
router or shutting down an operational edge node will create enormous signaling load on the network if
a certain size is surpassed thus creating risks for network stability and robustness.

3DJH#;
03/6#6WXG\

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

When traffic engineering is performed at the ATM layer possibilities will be constraint in the case of
mixed 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 independently
of the underlying media.

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

3DJH#<
 03/6#6WXG\

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 a
connectionless packet based network. The routing information established through the interworking of
intra-domain and inter-domain routing protocols partitions the packet forwarding space. A FEC
comprises the set of all packets, that traverse a domain in a similar way: the packets are forwarded
along the same path of routing hops and they receive the same treatment at routers that apply
differentiated 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. It
is 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 the
routing table, the forwarding information is then obtained through a look up under the matching subnet
mask. With the support of differentiated services in a network even more information in the header has
to be processed to find the correct entry such as TOS (type of service) field or use of hints from the
higher layer protocols.

In packet based networks the packets are forwarded at each hop independently of each other. Therefore
the analysis of the packet header has to be repeated at each hop; each router has to perform the costly
operation of processing IP header information and perhaps also additional higher layer protocol
headers in order to derive the FEC to which a packet belongs, then the router has to apply the correct
processing 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 repeating
the same processing of header information at each hop it is only performed at the ingress node, which
encodes the FEC information into a small fixed length label that is added to the IP packet, such that
subsequent nodes can base their forwarding decision on the packet label only without further need for
complex header analysis.

The strategy used for encoding the FEC class information is to assign identifiers of local significance
to FECs, this means that each node uses its own mapping of label to FECs and packet forwarding
requires 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 a
forwarding trunk from the ingress router to the egress router analogous to the ATM VCCs set up in an
ATM switched network core and indeed an ATM infrastructure can be used to realize MPLS. The
fundamental difference to the previous ATM overlay model however is not the forwarding mechanism
used in the network nodes but the innovative control of the switches.

3DJH#43
03/6#6WXG\

Figure 3 depicts a typical subnetwork applying MPLS technology. It consists of LSRs (label switch
router) 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 are
forwarded outside the label switching subnetwork. Adjacent LSRs or LERs form routing peer
relationships and run a routing protocol for the exchange of IP routing information. Additionally, they
need to run a label distribution protocol to exchange label bindings between adjacent nodes.

ODEHO FRUH
LQIRUPDWLRQ /65
H[FKDQJH

ODEHO
HGJH
URXWHU#+/(5,

Figure 3: Label Switching Network (LER and LSR)

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

Label switching offers flexibility on the granularity that labels are assigned, ranging from fine
application flows to coarse traffic aggregations, and allowing to balance between the need of fine
grained control and efficiency and switching resources. In principle, a FEC could be formed from the
source/destination address and port-number pair, effectively creating end-to-end switching, which
would 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 all
traffic to the same egress router of the operator domain.

Label switching basically allows for three strategies of label assignment. Label assignment can be
driven by topology, thus is triggered on routing update event; by data traffic, such that a new label
switch path is established when data packets are received by the LSR; or they may be driven by
explicit 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

3DJH#44
 03/6#6WXG\

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

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

/DEHO#6ZLWFK#5RXWHU

ILM
,QFRPLQJ 2XWJRLQJ 5

ODEHO## #4444
111 111
4 6
ODEHO# #4444 RXWODEHO #3;48
,QWHUIDFH #7
ODEHO# #3;48
7

ILM incoming label map

Figure 4: Forwarding by Label Swapping

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

3DJH#45
03/6#6WXG\

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

This chapter will show directions towards an operational IP network utilizing MPLS. In the first
section we will explain the main feature of traffic engineering of such a network, based on explanation
of the previous chapters of this document. The second part analyses MPLS solution form major vendor
based on their white papers. This is concluded by a comparism of these concepts. Finally this chapter
describes 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 improved
capabilities for Traffic Engineering that become feasible with MPLS. The MPLS working group has
already started work on Traffic Engineering and a first document out of a set of planned RFCs is
currently finalized, which identifies the requirements for Traffic Engineering over MPLS. It describes
the basic functions of Traffic Engineering in the Internet and derives the necessary functional
capabilities 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 MPLS
enabled Traffic Engineering as an important strategic step forward and expects major improvements in
network operation and scalability from the introduction of MPLS technology. UUNET Worldcom also
hosted 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 leading
to improved reliability and efficiency. Through actions of traffic engineering an optimized utilization
of network resources is guaranteed. Hence, TE becomes an indispensable tool for network operators to
respond 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 QoS
of individual traffic streams (e.g. minimizing packet loss or delay, maximizing throughput, or targeting
statistical parameters like delay variation, loss ratio, etc). And there are resource oriented performance
objectives which pertain to the optimization of the overall resource utilization. The goal is to ensure
that no subsets of network resources become over-utilized and congested, while there are still other
resources along alternate feasible paths that remain underutilized.

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

3DJH#46
 03/6#6WXG\

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

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

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

With MPLS on the other hand, Traffic Engineering functionality becomes available that is at least
comparable to overlay capabilities, but additional is able to scale also to dense core networks of large
size. As additional bonus MPLS provides these benefits at lower cost in an integrated manner, and
offers the prospect to automate much of the Traffic Engineering task. What makes MPLS particularly
attractive for network operators is that it opens up possibilities towards a more rational engineering
approach in network operation.

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

• MPLS allows for both traffic aggregation and disaggregation. Classical destination only based IP
routing permits only aggregation. With MPLS however, edge routers can map flows to the same
egress router to several LSPs which follow different routes over the MPLS core, thus creating an
disaggregation 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 provisioning
approach, where a switched physical network core underlies a fully mesh virtual IP network that is

3DJH#47
03/6#6WXG\

unaware of the topology below. With the integration of the two layers many of the traffic
engineering 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 overlay
approach is the lack of a satisfactory model for network operation and in particular inner-domain
routing. Network operators currently need to perform low level operations such as metrics
manipulation and VC set-up, which more often than not are performed in form of try-and-error rather
than 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 WG
document on 'Requirements for Traffic Engineering Over MPLS'. The key notion for Traffic
Engineering in MPLS networks is the concept of a traffic trunk. A traffic trunk is an object that
represents the aggregation of unidirectional traffic flows of the same class that will be placed inside a
Label Switched Path. The traffic trunk, however, is distinct from the LSP through which it traverses, as
a traffic trunk can be moved from one path onto another when needed e.g. in case of failure or
preemption of resources from higher priority traffic.

A traffic trunk is characterized by its ingress and egress LSRs, the forwarding equivalence classes
which are mapped onto it, and a set of attributes which determine its behavioral characteristics. As an
example, in the single class service model of the current Internet, a traffic trunk could be formed to
encapsulate 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 of
traffic 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 derive
the relevant information such as destination network, service class or routing options etc. It is done by
the edge router and is controlled through configuration of its classification engine. The second task of
generating a traffic trunk for the FEC means that behavioral properties for a FEC have to be
determined that describe the traffic requirements for this class of packets, which in general is mainly
determined and controlled from policy decisions. The third task requires that the traffic requirements
expressed by the traffic trunk are met by adequate network resources. This task requires elaborate
intra-domain routing capabilities in the network.

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

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

3DJH#48
 03/6#6WXG\

characteristics.

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

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

The attributes associated with traffic trunks and resources, as well as parameters associated with
routing, collectively represent the control variables which can be modified either through
administrative action or automatically to drive the network to a desired state; and in an operational
network, it must be possible that these attributes are dynamically modified online by an operator
without 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 be
created, routed and mapped onto network resources in order to provide the network services. The basic
operations 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 the
attributes 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). The
basic attributes associated with traffic trunks comprise parameters specifying traffic, path selection and
maintenance, priority, preemption, resilience and policing.

Traffic parameters capture the characteristics of the traffic streams that should be transported through
the traffic trunk, such as peak rates, average rates, permissible burst size, etc. The traffic parameters
specify the resource requirements of the traffic trunk, that must be available in a network node or link
in 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 newly
created traffic trunk and for maintenance of already established paths. Paths can be computed
automatically by the underlying routing protocols or set up administratively by a network operator. For
trunks with resource requirements or policy restrictions a constraint based routing scheme must be
applied 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 through
operator action. The path can be completely specified or partially specified. In a completely specified
path all required hops between the endpoints are indicated. In a partially specified path only a subset
of intermediate hops is indicated and the underlying protocols are required to construct a compliant
complete path. It is useful to be able to specify a set of candidate explicit paths together with a
preference 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 or
exclude resources from the path selection. These policy are used to impose additional constraints. They
powerful constructs that can implement a variety of policies. For example, they can be used to contain
a traffic trunk within specific topological regions of the network. Constraint based routing uses these

3DJH#49
03/6#6WXG\

attributes to compute an path by pruning all resources which do not belong to the included resource
classes 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 change
the paths of traffic trunks in response to changes in network state. The adaptivity attribute associated
with a traffic trunk indicates whether the trunk is subject to such re-optimization. If enabled, then a
traffic trunk can be rerouted through different paths by the underlying protocols in response to changes
in 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 to
smooth traffic distribution across the network and improve the overall resource utilization. In an
MPLS domain, this can be addressed by instantiating multiple traffic trunks between two nodes, such
that each traffic trunk carries a proportion of the aggregate traffic. It is useful to have some attribute
that indicates the relative proportion of traffic to be carried by each traffic trunk. Underlying protocols
will then distribute the load according to the specified proportions. However, packet ordering between
packets belonging to the same micro-flow (same source/destination address and port number) should
be 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 to
determine the order in which path selection is done at connection establishment and under fault
scenarios. With preemption a traffic trunk can even claim resources from another already established
traffic trunk of lower priority. In a differentiated services environment, preemption can be used to
assure that high priority traffic trunks are always routed through relatively favorable paths. It can also
be used to implement various prioritized restoration policies following fault events.

Resilience determines the behavior of a traffic trunk under fault conditions. Basic problems that need
to 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 may
indicate whether a non-conformant traffic trunk is to be rate limited, tagged, or simply forwarded
without any policing action.

5HVRXUFH#DWWULEXWHV

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

3DJH#4:
 03/6#6WXG\

resources like link bandwidth and buffer length: it is an administratively configurable attribute which
determines 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 a
variety of policies. For example they can be used to consistently apply a uniform policy to a set of
resources or to express the relative preference of sets of resources for path placement or to explicitly
restrict 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, the
attributes associated with resources and other topology state information. Based on this information, a
constraint based routing process on each node automatically computes explicit routes for each traffic
trunk that originates from the node. In this case, an explicit route for each traffic trunk is a
specification of a label switched path that satisfies the demand requirements expressed in the trunk's
attributes, 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 to
actualize Traffic Engineering policies. In full generality, the constraint based routing problem is
intractable. However, a simple well-known heuristic can be used in practice to find a feasible path if
one 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 of
frame relay and ATM switches already support some notion of constraint based routing. With the
upgrade of such devices to MPLS, it should be relatively easy to extend their implementation to
accommodate 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 are
already available and will be available in future (a detailed overview can be found in chapter 5, MPLS
Market Overview). Reading this papers one learn about the focus of the companies viewpoint and one
can estimate future work. We decided to focus on big players on the market, it is not intended to
describe 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 backbone
networks) will be recommended by the companies. They offer MPLS as a technology for ISPs who
already invested in ATM backbones. But in direct comparison (e.g. at Ascend) the solutions for
switched 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

3DJH#4;
03/6#6WXG\

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 is
clearly named. Ascend offers two families in this range, the GRF family of IP switches (for set-up of
routed networks) and the IP navigator (for set-up of switched networks). While discussion different
areas of deployment of these systems the interoperability of the systems is not completely clear. A
group labelled as "largest national ISP" is identified using a "pragmatic" approach, using mixed or
hybrid backbones.
One possible hybrid solution is the usage of switched systems in the area of high density access and in
parts of the core network. The routed systems are used for POP concentration and internet
connectivity. 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 Executive
Overview, a more recent paper from October 98). While describing features of MPLS, Ascend
highlights 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 multicast
support. Coming from the routing side and routing protocols, the introduction of MPLS is seen as a
mechanism to offer advanced services, based on features of ATM or Frame Relay. Advanced services
are 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 backbone
networks, to profit form their investment while offering IP services. There is a discussion of MPLS
terms and show examples of the forwarding mechanism in MPLS with label switched paths. New
services like QoS support and VPN are described as features of the introduced label and treated on IP
level of the network. QoS is an outcome of implementing well known CISCO queuing and scheduling
mechanism (e.g. WRED and CBWFQ). Basis for delivering customers QoS is the class of service
approach, it is more scalable then a approach on per-flow basis. With this approach bandwidth
management is completely done in the edge devices. Routing is done via with traditional IP routing
protocols, a strength of CISCO. The document also describes how to build VPNs with the help of a
smart use of routing protocols like BGP. For multiservice network CISCO's concept of a virtual switch
interface is described, an architecture to enable service providers offer ATM, frame relay and voice in
the same switched network.

71516 )25(

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

3DJH#4<
 03/6#6WXG\

demand for high capacity core switching, bandwidth guarantees and a scalable infrastructure. Possible
backbone technologies include ATM switching, non-connection oriented Terabit routers, Packet Over
SONET and Dense Wavelength Multiplexing (DWDM). For today’s business IP routing over ATM
switching is available. The next technology step will be unified routing and switching with MPLS, it
bridges the gap between ATM connections and IP services. FORE points out that MPLS is a standard
and not an available product, but claims to offer two important advances promised by MPLS: capacity
optimisation and traffic engineering. The layered architecture behind this approach is SDH on
transmission layer, ATM on switching layer and IP on service layer. Examples for traffic engineering
are given. FORE introduces two mechanism to support the network management: Directed Soft PVCs
for 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 the
communication 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 and
implement new IP services, like VPN or QoS support. Naturally the focus on MPLS differs form
company 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 switch
manufacturer) will utilise extended ATM functionality (e.g. with PNNI for routing) to offer IP
transport. This leads to tasks like following the ongoing standardisation of MPLS and to test
interoperability of available equipment. Even after first published standards of MPLS there are several
topics 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. The
network provides connected customers a means to communicate with each other an have an access to
locations outside the providers network. If there are more than one gateway to foreign networks you
have to reckon that the network is used as a transit network. Important aspects of network planning
are:
• resilience/redundancy,
• alternative paths,
• traffic engineering,
• scalability

3DJH#53
03/6#6WXG\

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 LSR
functionality. They are connected over the ATM backbone. The number of connections between the
backbone routers depends on the special network topology. If there are only few core routers, you can
build a full mesh. Customers have access to the core network via an access router (LSR edge) which
are routers with LSR functionality. The edge router is the last router before the packets reach the WAN
which looks into the IP header to make a routing decision. Within the MPLS cloud packet forwarding
is based on label switching.

Internet/ISP
LSR
BGP edge

LSR
core

LSR
BGP edge ATM Backbone
MPLS Cloud
LSR LSR OSPF area
core core
Internet/ISP

ATM link

LSR LSR LSR LSR LSR

edge edge edge edge edge

Figure 5: General Setup of an MPLS network

3DJH#54
 03/6#6WXG\

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

Work within IETF on the standardization of label switching started in March 1997 when the MPLS
working 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 reached
the final stages of group consensus and are about to become issued as RFCs. This includes the general
architecture of MPLS, the specification of label encodings and the LDP protocol together with
standards for operation over ATM and Frame Relay based switches. Based on this core set of
standards 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 during
the last year, MPLS has attracted much attention from major vendors. The working group has
expanded its scope since then, and there are currently about 18 accepted MPLS drafts for further
development. Additionally, there have submitted by now about 40 individual draft contributions that
are under discussion in the group. These include at least 5 proposals that will be accepted as group
drafts during the next meeting. Others are still at a too early stage to be adopted now, but they are
expected to gain official recognition as new working items in the next future. Since MPLS has
received such enormous expansion of activities, it is planned to split the working group and to set up a
separate group that will be devoted explicitly to the topic of traffic engineering, which is felt to be of
particular importance.

In the following overview on current MPLS WG working documents, it is attempted to classify the
broad range of standardization activities along a small set of topics, which however can only provide a
rough categorization, as there is overlap and interdependencies between the issues. As main working
areas there can be identified documents of an explanatory, more informational character defining the
general outline of MPLS; there are standard track documents for the new protocol and packet formats
defined 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; further
extended 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, and
they 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 distribution
protocol, work covers also standardization of management support for MPLS components

3DJH#55
03/6#6WXG\

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 the
development, however, is currently placed on solutions for ATM and Frame Relay. The standards
related to FR and ATM VC service are already in their final call, while work on ATM VP service just
started. Additionally, there are individual proposals for applying MPLS in a LAN environment,

working drafts include:

• 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.

working drafts include:

3DJH#56
 03/6#6WXG\

• ([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#6LJQDOLQJ
IRU#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 turned
out MPLS opens up further possibilities to introduce advanced features into the network including
constraint-based routing, QoS support and multicasting.

working drafts include:

• 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!

3DJH#57
03/6#6WXG\

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

$SSOLFDWLRQV#RI#03/6

MPLS improves network management of core IP networks and enables the introduction of new
services. Main emphasis is here on the possibilities of constructing IP VPNs using MPLS technology
and benefits gained for enhanced traffic management of the network. The general outline documents
on Requirements for Traffic Engineering is already in an advanced stage, while it is expected that
further development of working documents will be handed over to a new standardization group
concentrating 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<<<,

3DJH#58
 03/6#6WXG\

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 new
demand for testing not only the availability but also the Quality of Service. This chapter describes an
approach for Quality of Service testing within MPLS networks. Although the main focus is MPLS this
can 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, IP
networks 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 signalling

protocols (e.g. RSVP, ATM SVC). It is used with the Integrated Service (IntServ) model. The
IntServ scheme provide per-flow classification and guaranteed delays to support also real-time
traffic.

• Configured QoS: This approach mainly represents a bandwidth-management scheme for IP

networks. 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 packet
requires.

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 on
network 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 demand
by 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 observation
and checks the results against the traffic contract or specification. This can be done in combination
with an observation of resource reservation/signalling messages (RSVP), if required. Another
possibility 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 sequence
number errors.

3DJH#59
03/6#6WXG\

Sender Receiver
System under Test

Monitor

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 at
dedicated points of observation. The QoS parameters are detected by a comparator check of traffic
streams at the measurement point(s) and a reference point. This scenario can be extended in
combination with artificial load or real traffic in the background.

G e n e ra to r

S en d e r R e c e i ve r
Sy s te m u n d e r T e st

M o n i to 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, taking
three 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.

3DJH#5:
 03/6#6WXG\

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

2. Testing specific QoS mechanisms (e.g. queuing or traffic shaping) in a system of one or more
networking devices (e. g. network nodes). In this case e.g. the relation of low and high priority
traffic to congestion or the mechanism of Token Bucket Traffic Shaping can be examined by also
measuring the performance parameters. This scenario is dedicated to manufacturers and
service/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 of
test data at the ingress of a specific network device (SUT). The forwarded packet flows are observed at
the egress. For simulating different load conditions additional background traffic is used.

3DJH#5;
03/6#6WXG\

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

For testing IP QoS parameters, several test entities are necessary (see Test Methods). The
sender introduces the test traffic which can either be caused by a network application or a
special 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 at
dedicated points of observation (PCOs) for further analysis. A generator can be applied to
adjust certain load conditions. A pre-condition for these examinations is, that the clocks of the
measurement 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 following
parameters which influence the quality of data transfers: throughput, delay, loss, jitter. Their
definition [RFC1242] and the requirements to determine these values will be discussed
shortly.

Throughput

The maximum data transfer rate at which none of the offered frames are dropped between
measurement point A and measurement point B in a network. For this purpose the transfer
rate is calculated according to the timestamps of packets captured at any measurement point
and throughput is determined. The given definition [RFC1242] of throughput corresponds
with lossless throughput of the ATM Forum [ATMF96], where basically three different types
are 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 case
time counts when the first bit has left A until it arrives at B. PDU transfer delay is determined
by subtracting the timestamps of identical packets captured at two measurement points. To
avoid failures caused by permutations and misinsertion of IP packets, one have to correlate
same packets at the two measuarement points. For this purpose you need a unique packet
identification (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 constant
load. Jitter is determined by calculating transfer delay for packets captured at two
measurement points. To avoid failures caused by misinsertion, the SNR of the frames has to
be checked (see also Delay).

Loss

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

3DJH#5<
 03/6#6WXG\

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 between
two 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 load
generator hardware. For example the SmartBits from NetCom Systems or the TANYA
board 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 IP
packtets with special IP header and payload data.
• For transfer delay measurements the traffic genarator should be able to timestamp
outgoing 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 carried
out with the TANYA ATM test interface and the extended FAST ATM Tool Set. The tests
were performed in the MPLS test bed of GMD FOKUS. The test bed consists of Cell Switch
Router (CSR) equipment from Toshiba (three core routers and two edge devices). The Cell
Switch Routers use the FANP protocol from Toshiba to negotiate ATM shortcuts between
two adjacent CSR nodes. FANP was developed before the MPLS working group was
founded. To be MPLS compliant the CSRs are also capable to use the lable distriburtion
protocol (LDP) e.g. to communicate with CISCO’s TAG switching equipment. The aim of the
experiment was to demonstrate and to verify the above QoS testing approach.

The following figure shows the test configuration.

3DJH#63
03/6#6WXG\

CSR

R o ut e r Sys tem unde r Te st

M1 S w itc h M2
Lo ad
G en er a tor

IP Flo w IP F lo w
M o nit or M o nit or

Figure 8: Test configuration

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

TCP/IP PDU interarrival time variations

For the measurement of interarrival time variations a TCP/IP stream with constant bandwidth
of 2 MBit/s was generated.
PDU Interarrival Time Variation
4500

Switched
4000
Routed
3500

3000

2500
occurences

2000

1500

1000

500

0
2650 2700 2750 2800 2850
time/micro sec

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

3DJH#64
 03/6#6WXG\

Transfer delay measurements

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

transfer delay distribution

3500

AAL5 PDU
3000

2500

2000
occurences

1500

1000

500

0
14 15 16 17 18 19 20 21 22 23
time/micro sec

Figure 9: Transfer delay (switched)

The minimum routing delay of AAL 5 PDUs is about 210 µs. There are two maximums at
225 µs and 295 µs and there is a high variance.
transfer delay distribution
80
AAL5 PDU

70

60

50
occurences

40

30

20

10

0
200 220 240 260 280 300 320 340
time/micro sec

Figure 10: Transfer delay (routed)

3DJH#65
03/6#6WXG\

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 was
sent with increasing bandwidth. The MTU size was 1500 bytes. The results show the
following figure.

TCP/IP throughput
70
send
receive
60

50

40
MBit/s

30

20

10

0
0 2 4 6 8
time/s

Figure 11: IP throughput over default connection

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

3DJH#66
 03/6#6WXG\

: 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 IP
switches (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 and
for 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 and
effects on switching and routing technology. After discussing the advantages of MPLS
(starting with performance and multicast support) an overview on IP Navigator MPLS is
given. Ascend claims to offer a multivendor, multiservice, multiprotocol and open strategy,
using the Virtual Network Navigator (routing including feature for managing ATM and
Frame 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 mechanisms
on IP packet level. It is the same for VPN service, it is discussed as an example for routing
protocols.

ERICSSON

White Paper: MPLS - the future of IP backbone technology

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

3DJH#67
03/6#6WXG\

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 features
of PNNI). This is seen as a major building block for offering MPLS mechanism, providing an
IP service network. FORE addresses topics like traffic engineering, network failure recovery
and 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 the
Internet 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, Wiley
Computer Publishing, New York, USA, 1996.

[RFC1944] S. Bradner, J. McQuaid: Benchmarking Methodology for Network Interconnect

Devices, Request for Comments 1944, May 1996.

3DJH#68
 03/6#6WXG\

; $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:6
D#JRRG#LQWURGXFWLRQ#WR#03/6#ZULWWHQ#E\#PDLQ#FRQWULEXWRUV#WR#WKH#,(7)#03/6#:*/#FRYHUV#WKH#PDLQ#WRSLFV#DGGUHVVHG#LQ
WKH#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#,3
1DYLJDWRU1
• 1H[W0*HQHUDWLRQ#5RXWLQJ#IRU#,63V=#&DVFDGH¶V#,3#1DYLJDWRU#DQG#&LVFR¶V#7DJ#6ZLWFKLQJ#E\#&1#6HPHULD
6&20#1HWZRUNLQJ#6ROXWLRQV#:KLWH#3DSHU#4<<:
KWWS=22ZZZ16FRP1FRP2QVF283464:1KWPO
FRPSDULVRQ#RI#WKH#WZR#DSSURDFKHV/#WKDW#ZHUH#KLJKO\#LQIOXHQWLDO#RQ#WKH#GHYHORSPHQW#RI#03/6/#LQFOXGLQJ#D#FRPSUHKHQVLYH
UHIHUHQFH#VHFWLRQ>#D#FRPSDQLRQ#ZKLWH#SDSHU#FRYHUV#/$1#DQG#HQWHUSULVH#VROXWLRQV#VXFK#DV#6&20#)DVW#,3/#,SVLORQ#,3
VZLWFKLQJ/#&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#WKH
DSSURDFK#WDNHQ#E\#-XQLSHU#1HWZRUNV/#ZKLFK#IROORZV#D#5693#FHQWHUHG#ODEHO#GLVWULEXWLRQ#VWUDWHJ\
• 0XOWLSURWRFRO#/DEHO#6ZLWFKLQJ#+03/6,#7KH#7HFKQRORJ\#*XLGH#6HULHV#WHFKJXLGH1FRP
VSRQVRUHG#E\#(QQRYDWH#1HWZRUNV/#,QF
KWWS=22ZZZ1WHFKJXLGH1FRP2FRPP2VHFBKWPO2PSOV1VKWPO
JHQHUDO#LQWURGXFWLRQ/#GLVFXVVLQJ#DSSOLFDWLRQ#RI#03/6#IRU#,3#RYHU#$70/#7UDIILF#HQJLQHHULQJ#DQG#931#VHUYLFHV/#IHDWXULQJ
WKH#(QQRYDWH#(QYR\#4933#ODEHO#HGJH#URXWHU
• $VFHQG#,3#1DYLJDWRU#03/6/#$UFKLWHFWXUH#*XLGH
$VFHQG#&RPPXQLFDWLRQV/#,QF1#4<<<
KWWS=22ZZZ1DVFHQG1FRP2GRFV2WHFKGRFV2LSQYPSDJ1SGI
SURYLGHV#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<;2DUW82DUW81KWPO
DQRWKHU#ZHOO#ZULWWHQ#LQWURGXFWLRQ#WR#03/6#EDVLFV/#LQFOXGLQJ#D#ODUJHU#VHFWLRQ#GHVFULELQJ#(ULFVVRQ¶V#$;'#634#$70#VZLWFK
ZLWK#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#%XVKDXV
7HOH1&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

3DJH#69
03/6#6WXG\

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

Service providers already have begun testing implementations of the emerging standards in labs and
live networks. @Home Corp. (Redwood City, Calif.); MCI Communications Corp.; UUNet
Technologies 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's
DiffServe and Tag Switching software for several months. In May, Qwest Communications
International Inc. (Denver) agreed to test Avici's MPLS-capable Terabit Switch Router. Williams
Communications Groups (Tulsa, Okla.) is testing Argon Networks' switch router, and last month Net-1
Singapore 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=22LQIRQHW1DLVW0QDUD1DF1MS2PHPEHU2QRUL0G2POU2
9HU\#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#GFQ1VRRQJVLO1DF1NU
KWWS=22GFQ1VRRQJVLO1DF1NU2aMLQVXK2KRPH0PSOV1KWPO
VLPLODU#PDWHULDO#DV#SDJH#DERYH

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

• Ascend http://www.ascend.com
IP 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) Technology
http://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 Solutions
http://prodweb.newbridge.com:80/resources/solution_sheets/html/csr/index.html

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

3DJH#6:
 03/6#6WXG\

Terabit Switch Router

http://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.html

Terabit Switch Router Data Sheet http://www.avici.com/pdfs/Avici_TSR.pdf
WP: Delivering Internet Quality of Service http://www.avici.com/pdfs/QoS.pdf

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

• Juniper, http://www.juniper.net/
Networks M40 Internet backbone router
http://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.html
WP: The Multiservice IP Carrier Network
http://www.netreference.com/PublishedArchive/WhitePapers/WPIndex.html

3DJH#6;
03/6#6WXG\

< $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 Generic
Identifier 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

3DJH#6<
 03/6#6WXG\

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 Distribution
Protocol (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, Y
Rekhter, 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.

3DJH#73
03/6#6WXG\

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, Lou
Berger, 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

3DJH#74
 03/6#6WXG\

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.

3DJH#75