MPLS Study. Project: Competence Center for ATM Components - DFN ComAC-

Transcription

1 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

2 $XWKRU=#5XGROI#5RWK/#-HQV#7LHPDQQ/#/XW]#0DUN 9HUVLRQ=#413/##4913<14<<< 3DJH#5

3 7DEOH#RI#&RQWHQWV 4,QWURGXFWLRQ ,QWHUQHW#%DFNERQH#1HWZRUNV RXWHU#EDVHG#,3#&RUH#1HWZRUNV ZLWFKHG#,3#&RUH#1HWZRUNV XOWLSURWRFRO#/DEHO#6ZLWFKLQJ /DEHO#6ZLWFKHG#3DFNHW#)RUZDUGLQJ#DQG#03/6#1HWZRUNV SHUDWLRQ#RI#D#/DEHO#6ZLWFK#5RXWHU $SSOLFDWLRQ#6FHQDULRV#IRU#03/6#LQ#WKH#%DFNERQH UDIILF#(QJLQHHULQJ#LQ#03/6#1HWZRUNV UDIILF#(QJLQHHULQJ#LQ#WKH#,QWHUQHW $#)UDPHZRUN#IRU#7UDIILF#(QJLQHHULQJ#RYHU#03/ HQGRU#6ROXWLRQV ; $VFHQG ; &,6& < )25( < 716 'HVLJQ#RI#D#03/6#EDFNERQH WDWXV#RI#03/6#6WDQGDUGL]DWLRQ ,3#4XDOLW\#RI#6HUYLFH#7HVWLQJ $UFKLWHFWXUHV#IRU#,3#4R HVW#0HWKRGV HVW#$SSOLFDWLRQV : 917 7HVW#(QWLWLHV#DQG#,3#4R6#3DUDPHWHUV < 918 6:2+:#5HTXLUHPHQWV#IRU#7HVWLQJ#,3#4R UDFWLFDO#0HDVXUHPHQWV : 5HIHUHQFHV :14 9HQGRUV :15 /LWHUDWXUH ; $QQH[=#)XUWKHU#/LWHUDWXUH#DQG#5HVRXUFHV#RQ#03/ ;14 7XWRULDOV#DQG#,QWURGXFWLRQ#WR#03/6= ;15 0DJD]LQH#)HDWXUH#$UWLFOHV ;16,QWHUQHW#UHVRXUFHV : ;17 9HQGRUV#RI#03/6#7HFKQRORJ\#DQG#5HIHUHQFHV#WR#3URGXFW#5HVRXUFHV : < $QQH[=#&XUUHQW#ZRUNLQJ#GUDIWV#RI#WKH#,(7)#03/6#:* < 3DJH#6

4 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

5 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 RXWHU#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

6 BR IR IR BR BR BR BR BR BR IR IR BR BR IR IR BR IR IR BR IR IR BR BR BR IR IR ER Intra-domain Router Border Router Intradomain Routing e.g. OSFP 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 overutilized links while others remain under-utilized ZLWFKHG#,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

7 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 ER ER Layer 3 Logical Toplogy 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#:

8 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(n 2 ). 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#;

9 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#<

10 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

11 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 LQIRUPDWLRQ H[FKDQJH FRUH /65 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 SHUDWLRQ#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

12 (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 = 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,QFRPLQJ ILM 2XWJRLQJ 5 ODEHO## # ODEHO# # RXWODEHO #3;48,QWHUIDFH #7 6 7 ODEHO# #3;48 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

13 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 UDIILF#(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 UDIILF#(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

14 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

15 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 $#)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

16 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

17 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 noncompliant, 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:

18 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 coexist 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 HQGRU#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 $VFHQG Describes their viewpoint of powerful IP networks in the white papers "Building tomorrow s Internet 3DJH#4;

19 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 &,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 )25( For service providers FORE identifies (in the white paper Building an IP Service Network ) the 3DJH#4<

20 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

21 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 BGP LSR edge LSR core Internet/ISP BGP LSR edge LSR core LSR core ATM Backbone MPLS Cloud OSPF area ATM link LSR edge LSR edge LSR edge LSR edge LSR edge Figure 5: General Setup of an MPLS network 3DJH#54

22 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

23 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! &RPSDULVRQ#RI#03/6#/$1#(QFDSVXODWLRQ#3URSRVDOV?GUDIW0URVHQ0PSOV0ODQ0HQFDSV0FRPSDU0331W[W! 03/60916#,QWHUZRUNLQJ?GUDIW0MDPRXVVL0PSOV0YQV0331W[W! 9&#3RRO?GUDIW0GHPL]X0PSOV0YFSRRO0331W[W! +QHZ#:*#GRF, 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

24 ([WHQVLRQV#WR#5693#IRU#/63#7XQQHOV?GUDIW0LHWI0PSOV0UVYS0OVS0WXQQHO0351W[W! 8VH#RI#/DEHO#6ZLWFKLQJ#:LWK#5693?GUDIW0LHWI0PSOV0UVYS0331W[W! #+VWDWXV=#H[SHFWHG#:*#ODVW#FDOO, 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

25 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! 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<<<, +QHZ#:*#GRF#0!#WR#7(#:*, 3DJH#58

26 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 HVW#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

27 03/6#6WXG\ Sender System under Test Receiver 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. Generato r Sender System under Test Receiver Monitor Figure 7: Generic scenario for active generation of test traffic HVW#$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:

28 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;

29 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<

30 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

31 03/6#6WXG\ CSR Router System under Test Load M1 Switch M2 Gen erator IP Flo w IP Flo w Monitor Monitor 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 Switched Routed 3000 occurences time/micro sec As it was expected the variation of the interarrival times in the routed mode is much higher. 3DJH#64

32 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 3000 AAL5 PDU occurences 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 AAL5 PDU occurences time/micro sec Figure 10: Transfer delay (routed) 3DJH#65

33 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 send receive MBit/s 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

34 : 5HIHUHQFHV :14 9HQGRUV Ascend White Paper: Building Tomorrow s Internet Backbone (1997) Ascend white paper: Building Tomorrow s Internet Backbone The paper starts with a description of internet phases (routed, switched, MPLS) and concentrates 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 switching). 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 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 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 3DJH#67

35 FORE White Paper: Building an IP Service Network 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] [Fer98] [Gin96] ATM Forum: ATM User Network Interface Specification Version 3.1, af-uni , September Paul Ferguson, Geoff Huston: Quality of Service - Delivering QoS on the Internet and in Corporate Networks, Wiley Computer Publishing, New York, USA, David Ginsburg: ATM Solutions for Enterprise Internetworking, Addison- Wesley, Harlow, England, [RFC1242] S. Bradner: Benchmarking Terminology for Network Interconnect Devices, Request for Comments 1242, July [ATMF96] ATM Forum: Performance Testing Specification, Version 1.0, [Buc96] Robert W. Buchanan, Jr.: The Art of Testing Network Systems, Wiley Computer Publishing, New York, USA, [RFC1944] S. Bradner, J. McQuaid: Benchmarking Methodology for Network Interconnect Devices, Request for Comments 1944, May DJH#68

36 ; $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

37 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 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 IP Navigator MPLS Family Cisco Tag Switching Technology Ericsson MPLS Page FORE Building an IP Service Network General DataComm What is MPLS? IBM Networking Integrated Switch Router (ISR) Technology Lucent MPLS page Newbridge Carrier Switched Routing Solutions NORTEL Networks (former Bay Networks) 3DJH#6:

38 Terabit Switch Router New Start-up Companies with innovative products for MPLS Abatis (founded by former Newbridge engineers focusing on packet classifications) Argon Networks Inc. (Littleton, Mass.) GigaPacket Node (GPN) Avici Systems, Inc Terabit Switch Router Data Sheet WP: Delivering Internet Quality of Service Ennovate Multilayer Switching Technology Vision Juniper, Networks M40 Internet backbone router 03/6#6WXG\ NexaBit Networks Marlborough, MA NX64000 Multi-Terabit Switch/Router WP: The Multiservice IP Carrier Network 3DJH#6;

39 < $QQH[=#&XUUHQW#ZRUNLQJ#GUDIWV#RI#WKH#,(7)#03/6#:* "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 QoSsensitive 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<

40 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

41 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

42 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