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
$XWKRU=#5XGROI#5RWK/#-HQV#7LHPDQQ/#/XW]#0DUN 9HUVLRQ=#413/##4913<14<<< 3DJH#5
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#5RXWHU11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111144 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]DWLRQ11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111155 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#3DUDPHWHUV1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111115< 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/611111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111169 ;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
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,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
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. 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
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#:
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#;
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#<
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
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. 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
(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,QFRPLQJ ILM 2XWJRLQJ 5 ODEHO## #4444 4 ODEHO# #4444 111 111 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
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
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
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
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
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:
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. 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;
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<
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