idnits 2.17.1 draft-ietf-mpls-traffic-eng-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 85 has weird spacing: '...bels to packe...' == Line 215 has weird spacing: '...dopting load ...' == Line 393 has weird spacing: '..., d) be the i...' == Line 494 has weird spacing: '...eful to simul...' == Line 578 has weird spacing: '... trunks which...' == (4 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 1186, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 2430 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2105 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 2386 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Daniel O. Awduche 3 Internet Draft Joe Malcolm 4 Expiration Date: April, 1999 Johnson Agogbua 5 Mike O'Dell 6 Jim McManus 7 UUNET-Worldcom 8 October, 1998 10 Requirements for Traffic Engineering Over MPLS 12 draft-ietf-mpls-traffic-eng-00.txt 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To view the entire list of current Internet-Drafts, please check 27 the "1id-abstracts.txt" listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 29 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 30 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 31 (US West Coast). 33 Abstract 35 This document presents a set of requirements for Traffic 36 Engineering over Multiprotocol Label Switching (MPLS). It 37 identifies the functional capabilities required to implement 38 policies that facilitate efficient and reliable network operations 39 in an MPLS domain. These capabilities can be used to optimize the 40 utilization of network resources, and enhance traffic oriented 41 performance characteristics. 43 Table of Contents 45 1.0 Introduction .................................... 3 46 2.0 Traffic Engineering ...................................... 4 47 2.1 Traffic Engineering Performance Objectives ............... 4 48 2.2 Traffic and Resource Control ............................. 6 49 2.3 Limitations of Current IGP Control Mechanisms ............ 6 50 3.0 MPLS and Traffic Engineering ............................. 7 51 3.1 Induced MPLS Graph ....................................... 8 52 3.2 The Fundamental Problem of Traffic Engineering Over MPLS . 9 53 4.0 Augmented Capabilities for Traffic Engineering Over MPLS . 10 54 5.0 Traffic Trunk Attributes and Characteristics ........... 10 55 5.1 Bidirectional Traffic Trunks ............................. 11 56 5.2 Basic Operations on Traffic Trunks ....................... 12 57 5.3 Accounting and Performance Monitoring .................... 12 58 5.4 Basic Attributes of Traffic Trunks ....................... 13 59 5.5 Traffic Parameter Attributes ............................ 13 60 5.6 Generic Path Selection and Management Attributes ......... 14 61 5.6.1 Administratively Specified Explicit Paths ................ 15 62 5.6.2 Hierarchy of Preference Rules for Multi-paths ............ 15 63 5.6.3 Resource Class Affinity Attributes ....................... 16 64 5.6.4 Adaptivity Attribute ..................................... 16 65 5.6.5 Load Distribution Across Parallel Traffic Trunks ......... 18 66 5.7 Priority Attribute ....................................... 18 67 5.8 Preemption Attribute ..................................... 18 68 5.9 Resilience Attribute ..................................... 19 69 5.10 Policing Attribute ...................................... 20 70 6.0 Resource Attributes ...................................... 21 71 6.1 Maximum Allocation Multiplier ............................ 21 72 6.2 Resource Class Attribute ................................ 22 73 7.0 Constraint Based Routing ................................ 22 74 7.1 Basic Features of Constraint Based Routing ............... 23 75 7.2 Implementation Considerations ............................ 24 76 8.0 Conclusions ............................................. 25 77 9.0 References ............................................. 26 78 10.0 Acknowledgments .......................................... 27 79 11.0 Author's Address ......................................... 27 81 1.0 Introduction 83 Multiprotocol Label Switching (MPLS) [1,2] integrates a label 84 swapping framework with network layer routing. The basic idea 85 consists in assigning short fixed length labels to packets at 86 the ingress to an MPLS cloud, based on the concept of forwarding 87 equivalence classes [1,2]. Throughout the interior of the MPLS 88 domain, the labels attached to packets are used to make forwarding 89 decisions; usually without recourse to the original packet headers. 91 From this relatively simple paradigm, a set of powerful constructs 92 can be devised that address a number of critical issues in the 93 emerging differentiated services Internet. One of the most 94 significant initial applications of MPLS will be in Traffic 95 Engineering. This aspect is already well recognized (see [1,2,3,9]). 97 This manuscript focuses exclusively on the Traffic Engineering 98 applications of MPLS. Specifically, the goal of this document is to 99 highlight the issues and requirements for Traffic Engineering in a 100 large Internet backbone, in the expectation that the MPLS 101 specifications, or implementations derived therefrom, will address 102 the realization of these objectives. A description of the basic 103 capabilities and functionality required of an MPLS implementation to 104 accommodate the requirements is also presented. 106 It should be noted that even though we focus on Internet backbones, 107 the capabilities described here are equally applicable to Traffic 108 Engineering in enterprise networks; in short to any label switched 109 network under a single technical administration in which at least 110 two paths exist between two nodes. 112 There has been a number of recent manuscripts that focus on 113 considerations pertaining to Traffic Engineering and Traffic 114 management under MPLS; notably the works of Li and Rekhter [3], and 115 Vaananen and Ravikanth [9]. In [3], an architecture is proposed 116 which employs MPLS and RSVP to provide scalable differentiated 117 services and Traffic Engineering in the Internet. In [9], a 118 general framework is described that introduces traffic management 119 capabilities into MPLS. The present manuscript complements the 120 aforementioned efforts, and reflects the authors' operational 121 experience in managing a large Internet backbone. 123 Throughout, the reader is assumed to be familiar with the MPLS 124 terminology as defined in [1]. 126 The remainder of this document is organized as follows: Section 2 127 discusses the basic functions of Traffic Engineering in the 128 Internet. Section 3, gives an overview of the traffic Engineering 129 potentials of MPLS. Sections 1 to 3 can be regarded as background 130 material. Section 4 presents an overview of the fundamental 131 requirements for Traffic Engineering over MPLS. Section 5 describes 132 the desirable attributes and characteristics of traffic trunks 133 which are pertinent to Traffic Engineering. Section 6 presents a 134 set of attributes which can be associated with resources to constrain 135 the routability of traffic trunks and LSPs through them. Section 7 136 argues in favor of the introduction of a "constraint based routing" 137 framework in MPLS domains. Finally, Section 8 contains our 138 concluding remarks. 140 2.0 Traffic Engineering 142 This section describes the basic functions of Traffic Engineering in 143 an Autonomous System in the contemporary Internet. The limitations 144 of current IGPs with respect to traffic and resource control are 145 highlighted. This section serves as motivation for the requirements 146 on MPLS. 148 Traffic Engineering (TE) is concerned with performance optimization of 149 operational networks. Specifically, the goal of Traffic Engineering 150 is to facilitate efficient and reliable network operations, and at 151 the same time optimize the utilization of network resources. Traffic 152 Engineering is becoming an indispensable function in many large 153 Autonomous Systems because of the high cost of network assets, and 154 the commercial and competitive nature of the Internet. These factors 155 emphasize the need for maximal operational efficiency. 157 2.1 Traffic Engineering Performance Objectives 159 The key performance objectives associated with traffic engineering 160 can be classified as either: 162 1. traffic oriented or 164 2. resource oriented. 166 Traffic oriented performance objectives include those aspects that 167 enhance the QoS of traffic streams. In a single class, best effort 168 Internet service model, the key traffic oriented performance 169 objectives include: minimization of packet loss, minimization of 170 delay, maximization of throughput, and enforcement of service level 171 agreements. Under a single class best effort Internet service 172 model, minimization of packet loss is one of the most important 173 traffic oriented performance objectives. Statistically bounded 174 traffic oriented performance objectives (such as peak to peak packet 175 delay variation, loss ratio, and maximum packet transfer delay) might 176 become useful in the forthcoming differentiated services Internet. 178 Resource oriented performance objectives include those aspects 179 that pertain to the optimization of resource utilization. Efficient 180 management of network resources is the vehicle for the attainment 181 of resource oriented performance objectives. In particular, it is 182 generally desirable to ensure that subsets of network resources 183 do not become over utilized and congested, while other subsets 184 along alternate feasible paths remain underutilized. Bandwidth 185 is a crucial and scarce resource in contemporary networks. 186 Therefor, a central function of Traffic Engineering is 187 efficient management of bandwidth resources. 189 Minimizing congestion is a major traffic and resource oriented 190 performance objective. The interest here is not on transient 191 congestion resulting from instantaneous bursts, but rather on 192 congestion problems that are more prolonged. Congestion typically 193 manifests under two scenarios: 195 1. When network resources are insufficient or inadequate to 196 accommodate offered load. 198 2. When traffic streams are inefficiently mapped onto available 199 resources; causing subsets of network resources to become 200 over-utilized while others remain underutilized. 202 The first type of congestion problem can be addressed through: (i) 203 capacity expansion and (ii) classical congestion control techniques 204 which attempt to regulate the demand, such that it fits onto 205 available resources. Classical techniques for congestion control 206 include: rate limiting, window flow control, router queue 207 management, schedule-based control, and others; (see [8] and the 208 references therein). 210 The second type of congestion problems, namely those resulting from 211 inefficient resource allocation, can usually be addressed through 212 Traffic Engineering. 214 In general, congestion resulting from inefficient resource 215 allocation can be reduced by adopting load balancing 216 policies. The objective of such strategies is to minimize maximum 217 congestion or alternatively to minimize maximum resource utilization, 218 through efficient resource allocation. When congestion is 219 minimized through efficient resource allocation, packet loss 220 decreases, and aggregate throughput increases. Thereby, the 221 perception of network service quality experienced by end users 222 becomes significantly enhanced. 224 Even-though load balancing is an important network performance 225 optimization policy, the capabilities provided for Traffic 226 Engineering should be flexible enough, so that network 227 administrators can implement other policies which take account of 228 the prevailing cost structure, and the utility or revenue model. 230 2.2 Traffic and Resource Control 232 Performance optimization of operational networks is fundamentally a 233 control problem. The Traffic Engineer acts as the controller 234 in an adaptive feedback control system, which includes a set of 235 interconnected network elements, a network performance monitoring 236 system, and a set of network configuration management tools. The 237 Traffic Engineer formulates a control policy, observes the state of 238 the network through the monitoring system, characterizes the 239 traffic, and applies control actions to drive the network to a 240 desired state, in accordance with the control policy. This can be 241 done reactively by taking action in response to the current state of 242 the network, or pro-actively by using forecasting techniques to 243 anticipate future trends and applying action to obviate predicted 244 undesirable future states. 246 Ideally, control actions should involve: 248 1. modifying traffic management parameters, 250 2. modifying parameters associated with routing, and 252 3. modifying attributes and constraints associated with resources. 254 To the extent possible, it is desirable to minimize the level of 255 manual intervention involved in the traffic engineering process. 256 This can be accomplished by automating aspects of the control 257 actions described above, in a distributed and scalable fashion. 259 2.3 Limitations of Current IGP Control Mechanisms 261 This subsection reviews some of the well known limitations of 262 current IGPs with regard to Traffic Engineering. 264 The control capabilities offered by existing Internet interior 265 gateway protocols are quite inadequate for Traffic Engineering. 266 This makes it difficult to actualize effective policies that address 267 network performance problems. Indeed, IGPs based on shortest path 268 algorithms contribute significantly to congestion problems in 269 Autonomous Systems within the Internet. SPF algorithms generally 270 optimize based on a simple additive metric. Because these protocols 271 are topology driven, bandwidth availability and traffic 272 characteristics are not taken into account in making routing 273 decisions. Consequently, congestion frequently occurs when: 275 1. the shortest paths of multiple streams converge on specific 276 links or router interfaces, or 278 2. a given traffic stream is routed through a link or router 279 interface which does not have enough bandwidth to accommodate 280 it. 282 These scenarios manifest even when feasible alternate paths with 283 excess capacity exist. It is this aspect of congestion problems 284 (-- a symptom of suboptimal resource allocation) that Traffic 285 Engineering aims to vigorously obviate. Equal cost path load 286 sharing can be used to address case (2) with some degree of success, 287 but generally not case (1), especially in large networks with dense 288 topology. 290 A popular means of circumventing the inadequacies 291 of current IGPs is through an overlay model, using IP over 292 ATM or IP over frame relay. The overlay model extends the design 293 space by enabling arbitrary virtual topologies to be provisioned 294 atop the network's physical topology. The virtual topology is 295 constructed from virtual circuits which appear as physical links to 296 IGP routing protocols. The overlay model also provides many 297 important services which support traffic and resource control, 298 including: (1) constraint based routing at the VC level, (2) support 299 for administratively configurable explicit VC paths, (3) path 300 compression, (4) call admission control functions, (5) traffic 301 shaping and traffic policing functions, and (6) survivability of 302 VCs. These capabilities enable the actualization of a variety of 303 Traffic Engineering policies. For example, virtual circuits can 304 easily be rerouted to move traffic from over-utilized resources onto 305 relatively underutilized ones. 307 For Traffic Engineering in large dense networks, it is desirable to 308 equip MPLS with a level of functionality at least commensurate with 309 current overlay models. Fortunately, this can be done in a fairly 310 straight forward manner. 312 3.0 MPLS and Traffic Engineering 314 This section provides an overview of the applicability of MPLS to 315 Traffic Engineering. Subsequent sections elaborate on the set of 316 capabilities required to meet the Traffic Engineering requirements. 318 MPLS is strategically significant for Traffic Engineering because 319 it can potentially provide most of the functionality available from 320 the overlay model, in an integrated manner, and at lower cost than 321 competing alternatives. Equally importantly, MPLS offers the 322 possibility to automate aspects of the Traffic Engineering 323 function. This later consideration is left for further study and is 324 beyond the scope of this manuscript. 326 A note on terminology: The concept of MPLS traffic trunks is used 327 extensively in the remainder of this document. According to Li and 328 Rekhter [3], a traffic trunk is an aggregation of traffic flows of 329 the same class which are placed inside a Label Switched Path. It is 330 useful to view traffic trunks as atomic objects which can be 331 routed; that is, the path through which a traffic trunk traverses 332 can be changed. In this respect, traffic trunks are similar to 333 virtual circuits in ATM and Frame Relay networks. It is important 334 to emphasize that there is a fundamental distinction between a 335 traffic trunk and the LSP through which it traverses. Additional 336 characteristics of traffic trunks as used in this manuscript worth 337 noting are summarized in section 5.0. 339 The attractiveness of MPLS for Traffic Engineering can be 340 attributed to the following factors: (1) explicit label switched 341 paths which are not constrained by the destination based forwarding 342 paradigm can be easily created through manual administrative action 343 or through automated action by the underlying protocols, (2) LSPs can 344 potentially be efficiently maintained, (3) traffic trunks can be 345 instantiated and mapped onto LSPs, (4) a set of attributes can 346 be associated with traffic trunks which modulate their behavioral 347 characteristics, (5) a set of attributes can be associated with 348 resources which constrain the placement of LSPs and traffic trunks 349 across them, (6) MPLS allows for both traffic aggregation and 350 disaggregation whereas classical destination only based IP 351 forwarding permits only aggregation, (7) it is relatively easy to 352 integrate a "constraint based routing" framework with MPLS, (8) a 353 good implementation of MPLS can offer significantly lower overhead 354 than competing alternatives for Traffic Engineering. Furthermore, 355 through explicit routes, MPLS permits a quasi circuit switching 356 capability to be superimposed on the current Internet routing model. 358 Many of the existing proposals for Traffic Engineering over MPLS 359 focus only on the potential to create explicit LSPs. Although this 360 capability is fundamental for Traffic Engineering, it is not really 361 sufficient. Additional augmentations are required to foster the 362 actualization of policies that lead to performance optimization of 363 large operational networks. Some of the necessary augmentations are 364 described in this manuscript. 366 3.1 Induced MPLS Graph 368 This subsection introduces the concept of an "induced MPLS graph" 369 which is central to Traffic Engineering in MPLS domains. An induced 370 MPLS graph is analogous to a virtual topology in an overlay model, 371 and is logically mapped onto the physical network through the 372 selection of LSPs for traffic trunks. 374 An induced MPLS graph consists of a set of LSRs which comprise the 375 nodes of the graph and a set of LSPs which provide logical point to 376 point connectivity between the LSRs, and hence serve 377 as the links of the induced graph. Using the concept of label stacks 378 (see [1]), it may be possible to construct hierarchical induced MPLS 379 graphs. 381 Induced MPLS graphs are important because the basic problem of 382 bandwidth management in an MPLS domain concerns how to efficiently 383 map an induced MPLS graph onto the physical network topology. The 384 induced MPLS graph abstraction is formalized below. 386 Let G = (V, E, c) be a capacitated graph depicting the physical 387 topology of the network. Here, V is the set of nodes in the network 388 and E is the set of links; that is, for v and w in V, the object 389 (v,w) is in E if v and w are directly connected under G. The 390 parameter "c" is a set of capacity and other constraints associated 391 with E and V. We will refer to G as the "base" network topology. 393 Let H = (U, F, d) be the induced MPLS graph, where U is a subset of 394 V representing the set of LSRs in the network, or more precisely 395 the set of LSRs that are the endpoints of at least one LSP. Here, F 396 is the set of LSPs, so that for x and y in U, the object (x, y) is 397 in F if there is an LSP with x and y as endpoints. The parameter "d" 398 is the set of demands and restrictions associated with F. Evidently, 399 H is a directed graph. It can be seen that H depends on the 400 transitivity characteristics of G. 402 3.2 The Fundamental Problem of Traffic Engineering Over MPLS 404 There are basically three fundamental problems that relate to 405 Traffic Engineering over MPLS. 407 - The first problem concerns how to map packets onto forwarding 408 equivalence classes. 410 - The second problem concerns how to map forwarding equivalence 411 classes onto traffic trunks. 413 - The third problem concerns how to map traffic trunks onto the 414 physical network topology through label switched paths. 416 Here, we do not concern ourselves with the first two aspects of 417 the problem (even-though they are quite important). Instead, the 418 remainder of this manuscript will focus on capabilities that 419 permit the third mapping function to be performed in a manner that 420 results in efficient and reliable network operations. This is really 421 the problem of mapping an induced MPLS graph (H) onto the "base" 422 network topology (G). 424 4.0 Augmented Capabilities for Traffic Engineering Over MPLS 426 The previous sections reviewed the basic functions of Traffic 427 Engineering in the contemporary Internet. The applicability of 428 MPLS to that activity was also discussed. The remaining sections of 429 this manuscript describe the functional capabilities required 430 to fully support Traffic Engineering over MPLS in large networks. 432 The proposed capabilities consist of: 434 1. A set of attributes associated with traffic trunks which 435 collectively specify their behavioral characteristics. 436 Some of these attributes have already been suggested in 437 [9] within the context of traffic management for MPLS. 439 2. A set of attributes associated with resources which constrain 440 the placement of traffic trunks through them. These can also be 441 viewed as topology attribute constraints. 443 3. A "constraint based routing" (QoS routing) framework which is 444 used to select paths for traffic trunks subject to constraints 445 imposed by items 1) and 2) above. The constraint based routing 446 framework need not be part of MPLS. However, the two need to be 447 tightly integrated together. 449 The attributes associated with traffic trunks and resources, as well 450 as parameters associated with routing, collectively represent the 451 control variables which can be modified either through administrative 452 action or automatically to drive the network to a desired state. 454 In an operational network, it is highly desirable that these 455 attributes can be dynamically modified online by an operator 456 without adversely disrupting network operations. 458 5.0 Traffic Trunk Attributes and Characteristics 460 This section describes the desirable attributes which can be 461 associated with traffic trunks to influence their behavioral 462 characteristics. 464 First, the basic properties of traffic trunks as used in this 465 manuscript are summarized below: 467 - A traffic trunk is an *aggregate* of traffic flows belonging 468 to the same class. 470 - In a single class service model, such as the current Internet, 471 a traffic trunk could encapsulate all the traffic between an 472 ingress LSR and an egress LSR, or subsets thereof. 474 - Traffic trunks are routable objects (similar to ATM VCs) 476 - A traffic trunk is distinct from the LSP through which it 477 traverses. In operational contexts, a traffic trunk can be 478 moved from one path onto another. 480 - A traffic trunk is unidirectional. 482 In practice, a traffic trunk can be characterized by its ingress 483 and egress LSRs, the forwarding equivalence class which is 484 mapped onto it, and a set of attributes which determine its 485 behavioral characteristics. 487 Two basic issues are of particular significance: (1) parameterization 488 of traffic trunks and (2) path placement and maintenance rules for 489 traffic trunks. 491 5.1 Bidirectional Traffic Trunks 493 Although traffic trunks are conceptually unidirectional, in many 494 practical contexts, it is useful to simultaneously instantiate 495 two traffic trunks with the same endpoints, but which carry packets 496 in opposite directions. The two traffic trunks are logically coupled 497 together. That is, one trunk, called the forward trunk, carries 498 traffic from an originating node to a destination node, while the 499 other trunk, called the backward trunk, carries traffic from the 500 destination node to the originating node. We refer to the 501 amalgamation of two such traffic trunks as one bidirectional traffic 502 trunk (BTT) if the following two conditions hold: 504 - Both traffic trunks are instantiated through an atomic action at 505 one LSR, called the originator node. 507 - Neither of the composite traffic trunks can exist without the 508 other. That is, both are instantiated and destroyed together. 510 It is also useful to consider the topological properties of BTTs. A 511 BTT can be topologically symmetric or topologically asymmetric. 512 A BTT is said to be "topologically symmetric" if its constituent 513 traffic trunks are routed through the same physical path, even-though 514 they operate in opposite directions. Otherwise, if the component 515 traffic trunks are routed through different physical paths, then the 516 BTT is said to be "topologically asymmetric." 518 It should be noted that bidirectional traffic trunks are merely an 519 administrative convenience. In practice, most of the traffic 520 engineering functions can be implemented using only unidirectional 521 traffic trunks. 523 5.2 Basic Operations on Traffic Trunks 525 In the following, we summarize the basic operations on traffic 526 trunks which are significant for Traffic Engineering purposes. 528 - Establish: Create an instance of a traffic trunk. 530 - Activate: Cause a traffic trunk to start passing traffic. The 531 establishment and activation of a traffic trunk are logically 532 separate events. Although, in practice they can be implemented 533 or invoked as one atomic action. 535 - Deactivate: Cause a traffic trunk to stop passing traffic. 537 - Modify Attributes: Cause the attributes of a traffic trunk 538 to be modified. 540 - Reroute: Cause a traffic trunk to change its route. This can be 541 done through administrative action or automatically by the 542 underlying protocols. 544 - Destroy: Remove an instance of a traffic trunk from the network 545 and reclaim all resources allocated to it. Such resources 546 include label space, and possibly available bandwidth. 548 The above are considered the basic operations on traffic trunks. 549 Additional operations are also possible such as policing, traffic 550 shaping, and so forth. 552 5.3 Accounting and Performance Monitoring 554 Accounting capabilities are very important for purposes of billing 555 and traffic characterization. The billing aspect of accounting was 556 discussed in [9]. From a Traffic Engineering perspective, 557 performance statistics obtained from an accounting system can be 558 used for traffic characterization, performance optimization, and 559 capacity planning. 561 The capability to obtain statistics at the traffic trunk level is so 562 important that it should be considered an essential requirement for 563 Traffic Engineering over MPLS. 565 5.4 Basic Traffic Engineering Attributes of Traffic Trunks 567 An attribute of a traffic trunk is a parameter assigned to it 568 which influences its behavioral characteristics. 570 Attributes can be explicitly assigned to traffic trunks through 571 administration action or implicitly assigned by the underlying 572 protocols when packets are classified and mapped into equivalence 573 classes at the ingress to an MPLS domain. Regardless of how the 574 attributes were originally assigned, for Traffic Engineering 575 purposes, it should be possible to administratively modify such 576 attributes. 578 The basic attributes of traffic trunks which are significant for 579 Traffic Engineering are itemized below. Some, of these attributes 580 have already been included under the traffic management framework 581 document [9]. 583 - Traffic parameter attributes 585 - Generic Path selection and maintenance attributes 587 - Priority attribute 589 - Preemption attribute 591 - Resilience attribute 593 - Policing attribute 595 The combination of traffic parameters and policing attributes is 596 analogous to usage parameter control in ATM networks. Also, most 597 of the above attributes have analogs in well established 598 technologies. Consequently, it should be relatively straight 599 forward to map the traffic trunk attributes onto many existing 600 switching and routing architectures. 602 Priority and preemption can be regarded as relational attributes 603 because they express certain binary relations between traffic 604 trunks. Conceptually, these binary relations determine the manner in 605 which traffic trunks interact with each other as they compete for 606 network resources during path establishment and path maintenance. 608 5.5 Traffic parameter attributes 610 Traffic parameters can be used to capture the characteristics of 611 the traffic streams (or more precisely the forwarding equivalence 612 class) which are to be transported through the traffic trunk. Such 613 characteristics might include peak rates, average rates, permissible 614 burst size, etc. From a traffic engineering perspective, the 615 traffic parameters are significant because they indicate the 616 resource requirements of the traffic trunk. This is useful for 617 resource allocation and congestion avoidance through anticipatory 618 policies. 620 For purposes of bandwidth allocation, a single canonical value of 621 bandwidth requirements can be computed from a traffic trunk's 622 traffic parameters. Techniques for performing such computations 623 are already well known; for example the theory of effective 624 bandwidth, and such like. 626 5.6 Generic Path Selection and Management Attributes 628 Generic path selection and management attributes define the rules 629 for selecting the route taken by a traffic trunk, and the rules for 630 maintenance of paths that are already established. 632 Paths can either be computed automatically by the underlying 633 routing protocols or defined administratively by a network 634 operator. If no resource requirements or restrictions are associated 635 with a traffic trunk, then a topology driven protocol can be used to 636 select its path. However, if there are resource requirements or 637 policy restrictions, then a constraint based routing scheme must be 638 used for path selection. 640 In Section 7, we describe a constraint based routing framework which 641 can automatically compute paths subject to a set of constraints. 642 Issues that pertain to explicit paths instantiated through 643 administrative action are discussed in Section 5.6.1 below. 645 Path management concerns all aspects that pertain to the maintenance 646 of paths traversed by traffic trunks. In some operational contexts, 647 it is desirable that an MPLS implementation should be able to 648 dynamically reconfigure itself, to adapt to some notion of change in 649 "system state." Adaptivity and resilience are aspects of dynamic 650 path management. 652 To guide the path selection and management process, a set of 653 attributes are required. In the remainder of this sub-section, 654 we describe the basic attributes and behavioral characteristics 655 associated with traffic trunk path selection and management. 657 5.6.1 Administratively Specified Explicit Paths 659 An administratively specified explicit path for a traffic trunk 660 is one which is configured through operator action. An 661 administratively specified path can be completely specified or 662 partially specified. A path is completely specified if all 663 required hops between the endpoints are indicated. A path is 664 partially specified if only a subset of intermediate hops are 665 indicated. In this case, the underlying protocols are required to 666 complete the path. Due to operator errors, an administratively 667 specified path can be inconsistent or illogical. The underlying 668 protocols should be able to detect such inconsistencies and provide 669 appropriate feedback. 671 A "path preference rule" attribute should be associated with 672 administratively specified explicit paths. A path preference rule 673 attribute is a binary variable which indicates whether the 674 administratively configured explicit path is "mandatory" or 675 "non-mandatory." 677 If an administratively specified explicit path is selected with a 678 "mandatory attribute, then that path (and only that path) must be 679 used. If a mandatory path is topological infeasible (e.g. the two 680 endpoints are topologically partitioned), or the path cannot be 681 instantiated because available resources are inadequate, then the 682 path setup process fails. In other words, if a path is specified 683 as mandatory, then an alternate path cannot be used whatsoever; 684 regardless of prevailing circumstance. A mandatory path which is 685 successfully instantiated is also implicitly pinned. Once the path is 686 instantiated it cannot be changed except through deletion and 687 instantiation of a new path. 689 On the other hand, if an administratively specified explicit path is 690 selected with a "non-mandatory" preference rule attribute value, 691 then the path should be used if feasible. Otherwise, an alternate 692 path can be chosen instead by the underlying protocols. 694 5.6.2 Hierarchy of Preference Rules For Multi-Paths 696 In some practical contexts, it is useful to be able to 697 administratively specify a set of candidate explicit paths for a 698 given traffic trunk and define a hierarchy of preference relations 699 on the paths. During path establishment, the preference rules are 700 applied to select a suitable path from the candidate list. Also, 701 under failure scenarios the preference rules are applied to select 702 an alternate path from the candidate list. 704 5.6.3 Resource Class Affinity Attributes 706 Resource class affinity attributes associated with a traffic trunk 707 can be used to specify the class of resources (see Section 6) which 708 are to be explicitly included or excluded from the path of the 709 traffic trunk. These are policy attributes which can be used to 710 impose additional constraints on the path traversed by a given 711 traffic trunk. Resource class affinity attributes for a traffic can 712 be specified as a sequence of tuples: 714 ; ; .. 716 The resource-class parameter identifies a resource class for which 717 an affinity relationship is defined with respect to the traffic 718 trunk. The affinity parameter indicates the affinity relationship; 719 that is, whether members of the resource class are to be included or 720 excluded from the path of the traffic trunk. Specifically, the 721 affinity parameter is a binary variable which takes one 722 of the following values: (1) explicit inclusion, and (2) explicit 723 exclusion. 725 Since the affinity attribute is a binary variable, it is also 726 possible to use Boolean expressions to specify the resource class 727 affinities associated with a given traffic trunk. 729 If no resource class affinity attributes are specified, then a "don't 730 care" affinity relationship is assumed to hold between the 731 traffic trunk and all resources. That is, there is no requirement to 732 explicitly include or exclude any resources from the traffic trunk's 733 path. This should be the default in practice. 735 Resource class affinity attributes are very useful and powerful 736 constructs because they can be used to implement a variety of 737 policies. For example, they can be used to contain certain 738 traffic trunks within specific topological regions of the network. 740 A "constraint based routing" framework (see section 7.0) can be used 741 to compute an explicit path for a traffic trunk subject to resource 742 class affinity constraints in the following manner: 744 1. For explicit inclusion, prune all resources which do not belong 745 to the specified classes prior to performing path computation. 747 2. For explicit exclusion, prune all resources which belong to the 748 specified classes before performing path placement computations. 750 5.6.4 Adaptivity Attribute 751 Network characteristics and state change over time. For example, new 752 resources become available, failed resources become reactivated, 753 allocated resources become deallocated; in general sometimes more 754 efficient paths become available. Therefor, from a Traffic 755 Engineering perspective, it is necessary to have administrative 756 control parameters that can be used to specify how traffic trunks 757 respond to this dynamism. In some scenarios, it might be desirable 758 to dynamically change the paths of some traffic trunks in response 759 to changes in network state. This process is called re-optimization. 760 In many other scenarios, re-optimization might be highly 761 undesirable. 763 An Adaptivity attribute is a part of the path maintenance parameters 764 associated with traffic trunks. The adaptivity attribute associated 765 with a traffic trunk indicates whether the trunk is subject to 766 re-optimization. That is, an adaptivity attribute is a binary 767 variable which takes one of the following values: (1) permit 768 re-optimization and (2) disable re-optimization. 770 If re-optimization is enabled, then a traffic trunk can be rerouted 771 through different paths by the underlying protocols in response to 772 changes in network state (primarily changes in resource 773 availability). Conversely, if re-optimization is disabled, then the 774 traffic trunk is "pinned" to its established path and cannot be 775 rerouted in response to changes in network state. 777 Stability is a major concern when re-optimization is permitted. To 778 promote stability, an MPLS implementation should not be too reactive 779 to the evolutionary dynamics of the network. At the same time, it 780 must adapt fast enough so that optimal use can be made of network 781 assets. This necessarily implies that the frequency of 782 re-optimization should be administratively configurable to allow for 783 tuning. 785 It is to be noted that re-optimization is distinct from 786 resilience. A different attribute is used to specify the 787 resilience characteristics of a traffic trunk (see section 5.9). 788 In practice, it would seem reasonable to expect traffic trunks which 789 are subject to re-optimization to be implicitly resilient to failures 790 along their paths. However, a traffic trunk which is not subject to 791 re-optimization and whose path is not administratively specified 792 with a "mandatory" attribute can also be required to be resilient to 793 link and node failures along its established path 795 Formally, it can be stated that adaptivity to state evolution 796 through re-optimization implies resilience to failures, whereas 797 resilience to failures does not imply general adaptivity 798 through re-optimization to state changes. 800 5.6.5 Load Distribution Across Parallel Traffic Trunks 802 Load distribution across multiple parallel traffic trunks between 803 two nodes is an important consideration. In many practical 804 contexts, the aggregate traffic between two nodes might be 805 such that no single link (hence no single path) can carry the 806 load. However, the aggregate flow might be less than the maximum 807 permissible flow across a "min-cut" that partitions the two 808 nodes. In this case, the only feasible solution is to appropriately 809 divide the aggregate traffic into sub-streams and route the 810 sub-streams through multiple paths between the two nodes. 812 In an MPLS domain, this problem can be addressed by instantiating 813 multiple traffic trunks between the two nodes, such that each traffic 814 trunk carries a proportion of the aggregate traffic. Therefor, a 815 flexible means of load assignment to multiple parallel traffic 816 trunks carrying traffic of the same class between a pair of nodes is 817 required. 819 Specifically, from an operational perspective, in situations where 820 parallel traffic trunks are warranted, it would be useful 821 to have some attribute that can be used to indicate the relative 822 proportion of traffic to be carried by each traffic trunk. The 823 underlying protocols will then map the load onto the traffic 824 trunks according to the specified proportions. It is also, generally 825 desirable to maintain packet ordering between packets belong to the 826 same micro-flow (same source address, destination address, and port 827 number). 829 5.7 Priority attribute 831 The priority attribute defines the relative importance of traffic 832 trunks. If a constraint based routing framework is used with MPLS, 833 then priorities become very important because they can be used to 834 determine the order in which path selection is done for traffic 835 trunks at connection establishment and under fault scenarios. 837 Priorities are also important in implementations that permit 838 preemption, because they can be used to impose a partial order 839 on the set of traffic trunks according to which preemptive policies 840 can be actualized. 842 5.8 Preemption attribute 844 The preemption attribute determines whether a traffic trunk can 845 preempt another traffic trunk from a given path, and whether another 846 traffic trunk can preempt a specific traffic trunk. Preemption is 847 useful for both traffic oriented and resource oriented performance 848 objectives. Within a differentiated services environment, preemption 849 can used to assure that high priority traffic trunks can always be 850 routed through relatively favorable paths. 852 Preemption can also be used to implement various prioritized 853 restoration policies following fault events. 855 The preemption attribute can be used to specify four preempt modes 856 for a traffic trunk: (1) preemptor enabled, (2) non-preemptor, 857 (3) preemptable, and (4) non-preemptable. A preemptor 858 enabled traffic trunk can preempt lower priority traffic trunks 859 which are designated as preemptable. A traffic trunk which is 860 specified as non-preemptable cannot be preempted by any other 861 trunks, regardless of relative priorities. A traffic trunk which is 862 designated as preemptable can be preempted by higher priority trunks 863 which are preemptor enabled. 865 It is trivial to see that some of the preempt modes are mutually 866 exclusive. Using the numbering scheme depicted above, the feasible 867 preempt mode combinations for a given traffic trunk are as 868 follows: (1, 3), (1, 4), (2, 3), and (2, 4). The (2, 4) combination 869 should be the default. 871 A traffic trunk, say "A", can preempt another traffic trunk, say 872 "B", only if *all* the following five conditions hold: (i) "A" has 873 a relatively higher priority than "B", (ii) "A" contends for a 874 resource utilized by "B", (iii) the resource cannot concurrently 875 accommodate "A" and "B" based on some decision criteria, (iv) "A" is 876 preemptor enabled, and (v) "B" is preemptable. 878 Although useful, preemption is not considered a mandatory attribute 879 under the current best effort Internet service model. However, in 880 a differentiated services scenario, the need for preemption becomes 881 more compelling. Moreover, in the emerging optical internetworking 882 architectures, where some protection and restoration functions 883 might be migrated from the optical layer to data network elements 884 (such as gigabit and terabit label switching routers) to reduce 885 costs, preemption can be used to reduce the restoration time for 886 high priority traffic trunks under fault conditions. 888 5.9 Resilience Attribute 890 The resilience attribute determines the behavior of a traffic trunk 891 under fault conditions. That is, when a fault occurs along the path 892 through which the traffic trunk traverses. The following are the 893 basic problems that need to be addressed under such circumstances: 894 (1) fault detection, (2) failure notification, (3) recovery and 895 service restoration. Obviously, an MPLS implementation will have 896 to incorporate mechanisms to address these issues. 898 Many recovery policies can be specified for traffic trunks 899 whose established paths are impacted by faults. The following are a 900 few examples of feasible schemes: 902 1. Do not reroute the traffic trunk. For example, a survivability 903 scheme might already be in place, provisioned through an 904 alternate mechanism, which guarantees service continuity 905 under failure scenarios without the need to reroute traffic 906 trunks. An example of such an alternate scheme (certainly there 907 are many others), is a situation whereby multiple parallel 908 label switched paths are provisioned between two nodes, and 909 function in a manner such that failure of one LSP causes the 910 traffic trunk placed on it to be dispersed between the 911 remaining LSPs. 913 2. Reroute through a feasible path with enough resources. If none 914 exists, then do not reroute. 916 3. Reroute through any available path regardless of resource 917 constraints. 919 4. Many other schemes are possible; some of which might be 920 combinations of the above. 922 A "basic" resilience attribute indicates the recovery procedure 923 to be applied to traffic trunks whose paths are impacted by faults. 924 Specifically, a "basic" resilience attribute is a binary variable 925 which determines whether the target traffic trunk is to be rerouted 926 when segments of its path fail. "Extended" resilience attributes can 927 be used to specify detailed actions be taken under fault scenarios. 928 For example, an extended resilience attribute might specify a set of 929 alternate paths to use under fault conditions, and the rules that 930 govern the relative preference of each specified path. 932 Resilience attributes mandate close interaction between MPLS 933 and routing. 935 5.10 Policing attribute 937 The policing attribute determine the actions that should be taken 938 by the underlying protocols when a traffic trunk becomes 939 non-compliant. That is, when a traffic trunk exceeds its contract 940 as specified in the traffic parameters. In general, policing 941 attributes can indicate whether a non-conformant traffic trunk is to 942 be rate limited, tagged, or simply forwarded without any policing 943 action. This aspect is discussed in the MPLS traffic management 944 draft [9]. If policing is used, then adaptations of established 945 algorithms such as the ATM Forum's GCRA [11] can be used to perform 946 this function. 948 Policing is necessary in many operational scenarios, but is quite 949 undesirable in many others. In general, it is usually desirable to 950 police at the ingress to a network (to enforce compliance with 951 service level agreements) and to minimize policing within the core, 952 except when capacity constraints dictate otherwise. 954 Therefor, from a Traffic Engineering perspective, it is necessary to 955 be able to administratively enable or disable traffic policing for 956 each traffic trunk. 958 6.0 Resource Attributes 960 Resource attributes are part of the topology state parameters, which 961 are used to constrain the routing of traffic trunks through specific 962 resources. 964 6.1 Maximum Allocation Multiplier 966 The maximum allocation multiplier (MAM) of a resource is an 967 administratively configurable attribute which determines the 968 proportion of the resource that is available for allocation to 969 traffic trunks. This attribute is mostly applicable to link 970 bandwidth. However, in general, it can also be applied to buffer 971 resources on LSRs. The concept of MAM is analogous to the concepts 972 of subscription and booking factors in frame relay and ATM networks. 974 It is possible to choose values of the MAM such that a resource can 975 be under-allocated or over-allocated. A resource is said to be 976 under-allocated if the aggregate demands of all traffic trunks (as 977 expressed in the trunk traffic parameters) that can be allocated to 978 it is always less than the capacity of the resource. A resource is 979 said to be over-allocated if the aggregate demands of traffic trunks 980 allocated to it can exceed the capacity of the resource. 982 Under-allocation can be used to bound the utilization of resources. 983 However,the situation under MPLS is more complex than in circuit 984 switched schemes because under MPLS, some flows can be routed via 985 conventional hop by hop protocols (also via explicit paths) 986 without consideration for resource constraints. 988 Over-allocation can be used to take advantage of the statistical 989 characteristics of traffic in order to implement more efficient 990 resource allocation policies. In particular, over-allocation 991 can be used in situations where the peak demands of traffic trunks 992 do not coincide in time. 994 6.2 Resource Class Attribute 996 Resource class attributes are administratively assigned parameters 997 which express some notion of "class" for resources. Resource class 998 attributes can be viewed as "colors" which are assigned to 999 resources, such that the set of resources with the same "color" 1000 conceptually belong to the same class. Resource class 1001 attributes can be used to implement a variety of policies. The key 1002 resources of interest here are links. When applied to links, the 1003 resource class attribute effectively becomes become an aspect of 1004 the "link state" parameters. 1006 From a Traffic Engineering perspective, the concept of resource 1007 class attributes is a powerful abstraction, which can be used to 1008 implement a lot of policies with regard to both traffic and 1009 resource oriented performance optimization. Specifically, resource 1010 class attributes can be used to: 1012 1. Apply uniform policies to a set of resources which need 1013 not be in the same topological region. 1015 2. Specify the relative preference of sets of resources for 1016 path placement of traffic trunks. 1018 3. Explicitly restrict the placement of traffic trunks 1019 to specific subsets of resources. 1021 4. Implement generalized inclusion / exclusion policies. 1023 5. Enforce traffic locality containment policies. That is policies 1024 that seek to contain local traffic within specific topological 1025 regions of the network. 1027 In general, a resource can be assigned more than one resource class 1028 attribute. For example, all the OC-48 links in a given network 1029 might be assigned a distinguished resource class attribute, and 1030 subsets of OC-48 links might be assigned additional resource class 1031 attributes in order to implement specific containment policies, or 1032 to architect the network in a certain manner. 1034 7.0 Constraint Based Routing 1036 This section discusses the issues that pertain to constraint based 1037 routing in MPLS domains. In contemporary terminology, constraint 1038 based routing is often referred to as "QoS Routing" see [5,6,7,10]. 1039 However, we prefer the term "constraint based routing," as it more 1040 aptly captures the envisaged functionality; which in general 1041 encompasses QoS routing as a subset. 1043 Constraint based routing enables a demand driven, resource 1044 reservation aware, routing paradigm to co-exist with current 1045 topology driven hop by hop Internet interior gateway protocols. 1047 A constraint based routing framework uses the following as input: 1049 - The attributes associated with traffic trunks. 1051 - The attributes associated with resources. 1053 - Other topology state information. 1055 Based on this information, a constraint based routing process 1056 on each node automatically computes explicit routes for each 1057 traffic trunk that originates from the node. In this case, an 1058 explicit route for each traffic trunk is a specification of a label 1059 switched path that satisfies the demand requirements expressed in 1060 the trunk's attributes, subject to constraints imposed by resource 1061 availability and other topology state information. 1063 A constraint based routing framework can greatly reduce the level 1064 of manual configuration required to actualize Traffic Engineering 1065 policies. 1067 In practice, the Traffic Engineer or an operator will 1068 administratively specify the endpoints of a traffic trunk and assign 1069 a set of attributes to the trunk which encapsulate the performance 1070 expectations and behavioral characteristics of the trunk. The 1071 constraint based routing framework is then expected to find a 1072 feasible path that satisfies the expectations. If necessary, the 1073 traffic engineer can then use manually configured explicit routes to 1074 perform fine grained optimization. 1076 7.1 Basic Features of Constraint Based Routing 1078 A constraint based routing framework should be able to at least 1079 automatically obtain a basic feasible solution to the traffic trunk 1080 path placement problem. 1082 In general, the constraint based routing problem is known to be 1083 intractable. However, in practice, a very simple well known 1084 heuristic (see e.g. [10]) can be used to find a feasible path if 1085 one exists: 1087 - First prune resources that do not satisfy the requirements of 1088 the traffic trunk attributes. 1090 - Next, run a shortest path algorithm on the residual graph. 1092 It is easy to see that if a feasible path exists, then the above 1093 simple procedure will find it. Additional rules can be specified 1094 to break ties, and perform further optimizations. 1096 7.2 Implementation Considerations 1098 Many commercial implementations of frame relay and ATM switches 1099 already support some notion of constraint based routing. For such 1100 devices, or novel MPLS centric contraptions devised therefrom, it 1101 should be relatively easy to extend the current constraint based 1102 routing implementations to accommodate the peculiar requirements of 1103 MPLS. 1105 For routers that use topology driven hop by hop IGPs, constraint 1106 based routing can be incorporated in at least one of two ways: 1108 1. Extend current IGP protocols such as OSPF and IS-IS to support 1109 constraint based routing. Effort is already underway to provide 1110 such extensions to OSPF (see [5,7]). 1112 2. Add a constraint based routing process to each router which 1113 can co-exist with current IGPs. This scenario is depicted 1114 in Figure 1. 1116 ------------------------------------------ 1117 | Management Interface | 1118 ------------------------------------------ 1119 | | | 1120 ------------ ------------------ -------------- 1121 | MPLS |<->| Constraint Based | | Conventional | 1122 | | | Routing Process | | IGP Process | 1123 ------------ ------------------ -------------- 1124 | | 1125 ----------------------- -------------- 1126 | Resource Attribute | | Link State | 1127 | Availability Database | | Database | 1128 ----------------------- -------------- 1130 Figure 1. Constraint Based Routing Process on Layer 3 LSR 1132 There are many important details associated with implementing 1133 constraint based routing on Layer 3 devices which we do not discuss 1134 here. These include the following: 1136 - Mechanisms for exchange of topology state information (resource 1137 availability information, link state information, resource 1138 attribute information) between constraint based routing 1139 processes. 1141 - Mechanisms for maintenance of topology state information. 1143 - Interaction between constraint based routing processes and 1144 conventional IGP processes. 1146 - Mechanisms to accommodate the adaptivity requirements of traffic 1147 trunks. 1149 - Mechanisms to accommodate the resilience and survivability 1150 requirements of traffic trunks. 1152 In summary, constraint based routing assists in performance 1153 optimization of operational networks by automatically finding 1154 feasible paths that satisfy a set of constraints for traffic trunks. 1155 It can drastically reduce the amount of manual explicit path 1156 configurations required to achieve Traffic Engineering objectives. 1158 8.0 Conclusion 1160 This manuscript presented a set of requirements for Traffic 1161 Engineering over MPLS. A number of capabilities were described 1162 aimed at enhancing the applicability of MPLS to Traffic Engineering 1163 in the Internet. 1165 It should be noted that some of the issues described here can be 1166 addressed by incorporating a minimal set of building blocks into MPLS, 1167 and then using a network management superstructure to extend the 1168 functionality in order to realize the requirements. Also, the 1169 constraint based routing framework need not be part of the core MPLS 1170 specifications. However, MPLS does require some interaction with a 1171 constraint based routing framework in order to meet the requirements. 1173 9.0 References 1175 [1] E. Rosen, A. Viswanathan, R. Callon, "A Proposed Architecture 1176 for MPLS", Work in Progress. 1178 [2] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, 1179 A. Viswanathan, "A Framework for Multiprotocol Label 1180 Switching", Work in Progress. 1182 [3] T. Li and Y. Rekhter, "Provider Architecture for Differentiated 1183 Services and Traffic Engineering (PASTE)," RFC 2430, 1184 October 1998. 1186 [4] Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow, "Cisco 1187 Systems' Tag Switching Architecture - Overview", RFC 2105, 1188 February 1997. 1190 [5] Z. Zhang, C. Sanchez, B. Salkewicz, E. Crawley "Quality of 1191 Service Extensions to OSPF", Work in Progress. 1193 [6] E. Crawley, R. Nair, B. Rajagopalan, H. Sandick, "A framework 1194 for QoS Based Routing in the Internet," RFC 2386, August 1998 1196 [7] R. Guerin, S. Kamat, A. Orda, T. Przygienda, D. Williams, 1197 "QoS Routing Mechanisms and OSPF Extensions," Work in Progress. 1199 [8] C. Yang and A. Reddy, "A Taxonomy for Congestion Control 1200 Algorithms in Packet Switching Networks," IEEE Network 1201 Magazine, Volume 9, Number 5, July/August 1995, 1203 [9] P. Vaananen and R. Ravikanth, "A Framework for Traffic 1204 Management in MPLS Networks," Work in Progress. 1206 [10] W. Lee, M. Hluchyi, and P. Humblet, "Routing Subject to 1207 Quality of Service Constraints in Integrated Communication 1208 Networks," IEEE Network, July 1995, pp 46-55. 1210 [11] ATM Forum, "Traffic Management Specification: Version 4.0" 1211 April 1996. 1213 10.0 Acknowledgments 1215 The authors would like to thank Yakov Rekhter for his review of an 1216 earlier draft of this document. The authors would also like to thank 1217 Louis Mamakos and Bill Barns for their helpful suggestions, and 1218 Curtis Villamizar for providing some useful feedback. 1220 11.0 AUTHORS' ADDRESSES 1222 Daniel O. Awduche Joe Malcolm Johnson Agogbua 1223 UUNET Worldcom UUNET Worldcom UUNET Worldcom 1224 3060 Williams Drive 3060 Williams Drive 3060 Williams Drive 1225 Fairfax, VA 22031 Fairfax, VA 22031 Fairfax, VA 22031 1226 awduche@uu.net jmalcolm@uu.net ja@uu.net 1227 703-208-5277 703-206-5895 703-206-5794 1229 Mike O'Dell Jim McManus 1230 UUNET Worldcom UUNET Worldcom 1231 3060 Williams Drive 3060 Williams Drive 1232 Fairfax, VA 22031 Fairfax, VA 22031 1233 mo@uu.net jmcmanus@uu.net 1234 703-206-5890 703-206-5607