idnits 2.17.1 draft-ietf-mpls-traffic-eng-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 91 has weird spacing: '...bels to packe...' == Line 115 has weird spacing: '...ies can be ap...' == Line 417 has weird spacing: '..., d) be the i...' == Line 519 has weird spacing: '...eful to simul...' == Line 604 has weird spacing: '... trunks parti...' == (8 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: Informational ---------------------------------------------------------------------------- == Unused Reference: '4' is defined on line 1218, but no explicit reference was found in the text Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 INTERNET-DRAFT 3 MPLS Working Group Daniel O. Awduche 4 Category: Informational Joe Malcolm 5 Expiration Date: December 1999 Johnson Agogbua 6 Mike O'Dell 7 Jim McManus 8 UUNET (MCI Worldcom) 9 June, 1999 11 Requirements for Traffic Engineering Over MPLS 13 draft-ietf-mpls-traffic-eng-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document presents a set of requirements for Traffic Engineering 39 over Multiprotocol Label Switching (MPLS). It identifies the 40 functional capabilities required to implement policies that 41 facilitate efficient and reliable network operations in an MPLS 42 domain. These capabilities can be used to optimize the utilization of 43 network resources and to enhance traffic oriented performance 44 characteristics. 46 Table of Contents 48 1.0 Introduction .................................... 3 49 1.1 Terminology .................................... 4 50 1.2 Document Organization .................................... 4 51 2.0 Traffic Engineering ...................................... 4 52 2.1 Traffic Engineering Performance Objectives ............... 5 53 2.2 Traffic and Resource Control ............................. 6 54 2.3 Limitations of Current IGP Control Mechanisms ............ 7 55 3.0 MPLS and Traffic Engineering ............................. 8 56 3.1 Induced MPLS Graph ....................................... 9 57 3.2 The Fundamental Problem of Traffic Engineering Over MPLS . 10 58 4.0 Augmented Capabilities for Traffic Engineering Over MPLS . 10 59 5.0 Traffic Trunk Attributes and Characteristics ........... 11 60 5.1 Bidirectional Traffic Trunks ............................. 12 61 5.2 Basic Operations on Traffic Trunks ....................... 13 62 5.3 Accounting and Performance Monitoring .................... 13 63 5.4 Basic Attributes of Traffic Trunks ....................... 13 64 5.5 Traffic Parameter Attributes ............................ 14 65 5.6 Generic Path Selection and Management Attributes ......... 15 66 5.6.1 Administratively Specified Explicit Paths ................ 15 67 5.6.2 Hierarchy of Preference Rules for Multi-paths ............ 16 68 5.6.3 Resource Class Affinity Attributes ....................... 16 69 5.6.4 Adaptivity Attribute ..................................... 17 70 5.6.5 Load Distribution Across Parallel Traffic Trunks ......... 18 71 5.7 Priority Attribute ....................................... 19 72 5.8 Preemption Attribute ..................................... 19 73 5.9 Resilience Attribute ..................................... 20 74 5.10 Policing Attribute ...................................... 21 75 6.0 Resource Attributes ...................................... 22 76 6.1 Maximum Allocation Multiplier ............................ 22 77 6.2 Resource Class Attribute ................................ 22 78 7.0 Constraint-Based Routing ................................ 23 79 7.1 Basic Features of Constraint-Based Routing ............... 24 80 7.2 Implementation Considerations ............................ 25 81 8.0 Conclusion ............................................. 26 82 9.0 Security Considerations .................................. 27 83 10.0 References ............................................. 27 84 11.0 Acknowledgments .......................................... 28 85 12.0 Author's Address ......................................... 28 87 1.0 Introduction 89 Multiprotocol Label Switching (MPLS) [1,2] integrates a label 90 swapping framework with network layer routing. The basic idea 91 involves assigning short fixed length labels to packets at the 92 ingress to an MPLS cloud (based on the concept of forwarding 93 equivalence classes [1,2]). Throughout the interior of the MPLS 94 domain, the labels attached to packets are used to make forwarding 95 decisions (usually without recourse to the original packet headers). 97 A set of powerful constructs to address many critical issues in the 98 emerging differentiated services Internet can be devised from this 99 relatively simple paradigm. One of the most significant initial 100 applications of MPLS will be in Traffic Engineering. The importance 101 of this application is already well-recognized (see [1,2,3]). 103 This manuscript is exclusively focused on the Traffic Engineering 104 applications of MPLS. Specifically, the goal of this document is to 105 highlight the issues and requirements for Traffic Engineering in a 106 large Internet backbone. The expectation is that the MPLS 107 specifications, or implementations derived therefrom, will address 108 the realization of these objectives. A description of the basic 109 capabilities and functionality required of an MPLS implementation to 110 accommodate the requirements is also presented. 112 It should be noted that even though the focus is on Internet 113 backbones, the capabilities described in this document are equally 114 applicable to Traffic Engineering in enterprise networks. In general, 115 the capabilities can be applied to any label switched network under 116 a single technical administration in which at least two paths exist 117 between two nodes. 119 Some recent manuscripts have focused on the considerations pertaining 120 to Traffic Engineering and Traffic management under MPLS, most 121 notably the works of Li and Rekhter [3], and others. In [3], an 122 architecture is proposed which employs MPLS and RSVP to provide 123 scalable differentiated services and Traffic Engineering in the 124 Internet. The present manuscript complements the aforementioned and 125 similar efforts. It reflects the authors' operational experience in 126 managing a large Internet backbone. 128 1.1 Terminology 130 The reader is assumed to be familiar with the MPLS terminology as 131 defined in [1]. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [11]. 137 1.2 Document Organization 139 The remainder of this document is organized as follows: Section 2 140 discusses the basic functions of Traffic Engineering in the Internet. 141 Section 3, provides an overview of the traffic Engineering potentials 142 of MPLS. Sections 1 to 3 are essentially background material. Section 143 4 presents an overview of the fundamental requirements for Traffic 144 Engineering over MPLS. Section 5 describes the desirable attributes 145 and characteristics of traffic trunks which are pertinent to Traffic 146 Engineering. Section 6 presents a set of attributes which can be 147 associated with resources to constrain the routability of traffic 148 trunks and LSPs through them. Section 7 advocates 149 the introduction of a "constraint-based routing" framework in MPLS 150 domains. Finally, Section 8 contains concluding remarks. 152 2.0 Traffic Engineering 154 This section describes the basic functions of Traffic Engineering in 155 an Autonomous System in the contemporary Internet. The limitations of 156 current IGPs with respect to traffic and resource control are 157 highlighted. This section serves as motivation for the requirements 158 on MPLS. 160 Traffic Engineering (TE) is concerned with performance optimization 161 of operational networks. In general, it encompasses the application 162 of technology and scientific principles to the measurement, modeling, 163 characterization, and control of Internet traffic, and the 164 application of such knowledge and techniques to achieve specific 165 performance objectives. The aspects of Traffic Engineering that are 166 of interest concerning MPLS are measurement and control. 168 A major goal of Internet Traffic Engineering is to facilitate 169 efficient and reliable network operations while simultaneously 170 optimizing network resource utilization and traffic performance. 171 Traffic Engineering has become an indispensable function in many 172 large Autonomous Systems because of the high cost of network assets 173 and the commercial and competitive nature of the Internet. These 174 factors emphasize the need for maximal operational efficiency. 176 2.1 Traffic Engineering Performance Objectives 178 The key performance objectives associated with traffic engineering 179 can be classified as being either: 181 1. traffic oriented or 183 2. resource oriented. 185 Traffic oriented performance objectives include the aspects that 186 enhance the QoS of traffic streams. In a single class, best effort 187 Internet service model, the key traffic oriented performance 188 objectives include: minimization of packet loss, minimization of 189 delay, maximization of throughput, and enforcement of service level 190 agreements. Under a single class best effort Internet service model, 191 minimization of packet loss is one of the most important traffic 192 oriented performance objectives. Statistically bounded traffic 193 oriented performance objectives (such as peak to peak packet delay 194 variation, loss ratio, and maximum packet transfer delay) might 195 become useful in the forthcoming differentiated services Internet. 197 Resource oriented performance objectives include the aspects 198 pertaining to the optimization of resource utilization. Efficient 199 management of network resources is the vehicle for the attainment of 200 resource oriented performance objectives. In particular, it is 201 generally desirable to ensure that subsets of network resources do 202 not become over utilized and congested while other subsets along 203 alternate feasible paths remain underutilized. Bandwidth is a crucial 204 resource in contemporary networks. Therefore, a central function of 205 Traffic Engineering is to efficiently manage bandwidth resources. 207 Minimizing congestion is a primary traffic and resource oriented 208 performance objective. The interest here is on congestion problems 209 that are prolonged rather than on transient congestion resulting from 210 instantaneous bursts. Congestion typically manifests under two 211 scenarios: 213 1. When network resources are insufficient or inadequate to 214 accommodate offered load. 216 2. When traffic streams are inefficiently mapped onto available 217 resources; causing subsets of network resources to become 218 over-utilized while others remain underutilized. 220 The first type of congestion problem can be addressed by either: (i) 221 expansion of capacity, or (ii) application of classical congestion 222 control techniques, or (iii) both. Classical congestion control 223 techniques attempt to regulate the demand so that the traffic fits 224 onto available resources. Classical techniques for congestion control 225 include: rate limiting, window flow control, router queue management, 226 schedule-based control, and others; (see [8] and the references 227 therein). 229 The second type of congestion problems, namely those resulting from 230 inefficient resource allocation, can usually be addressed through 231 Traffic Engineering. 233 In general, congestion resulting from inefficient resource allocation 234 can be reduced by adopting load balancing policies. The objective of 235 such strategies is to minimize maximum congestion or alternatively to 236 minimize maximum resource utilization, through efficient resource 237 allocation. When congestion is minimized through efficient resource 238 allocation, packet loss decreases, transit delay decreases, and 239 aggregate throughput increases. Thereby, the perception of network 240 service quality experienced by end users becomes significantly 241 enhanced. 243 Clearly, load balancing is an important network performance 244 optimization policy. Nevertheless, the capabilities provided for 245 Traffic Engineering should be flexible enough so that network 246 administrators can implement other policies which take into account 247 the prevailing cost structure and the utility or revenue model. 249 2.2 Traffic and Resource Control 251 Performance optimization of operational networks is fundamentally a 252 control problem. In the traffic engineering process model, the 253 Traffic Engineer, or a suitable automaton, acts as the controller in 254 an adaptive feedback control system. This system includes a set of 255 interconnected network elements, a network performance monitoring 256 system, and a set of network configuration management tools. The 257 Traffic Engineer formulates a control policy, observes the state of 258 the network through the monitoring system, characterizes the traffic, 259 and applies control actions to drive the network to a desired state, 260 in accordance with the control policy. This can be accomplished 261 reactively by taking action in response to the current state of the 262 network, or pro-actively by using forecasting techniques to 263 anticipate future trends and applying action to obviate the predicted 264 undesirable future states. 266 Ideally, control actions should involve: 268 1. Modification of traffic management parameters, 270 2. Modification of parameters associated with routing, and 272 3. Modification of attributes and constraints associated with 273 resources. 275 The level of manual intervention involved in the traffic engineering 276 process should be minimized whenever possible. This can be 277 accomplished by automating aspects of the control actions described 278 above, in a distributed and scalable fashion. 280 2.3 Limitations of Current IGP Control Mechanisms 282 This subsection reviews some of the well known limitations of current 283 IGPs with regard to Traffic Engineering. 285 The control capabilities offered by existing Internet interior 286 gateway protocols are not adequate for Traffic Engineering. This 287 makes it difficult to actualize effective policies to address network 288 performance problems. Indeed, IGPs based on shortest path algorithms 289 contribute significantly to congestion problems in Autonomous Systems 290 within the Internet. SPF algorithms generally optimize based on a 291 simple additive metric. These protocols are topology driven, so 292 bandwidth availability and traffic characteristics are not factors 293 considered in routing decisions. Consequently, congestion frequently 294 occurs when: 296 1. the shortest paths of multiple traffic streams converge on 297 specific links or router interfaces, or 299 2. a given traffic stream is routed through a link or router 300 interface which does not have enough bandwidth to accommodate 301 it. 303 These scenarios manifest even when feasible alternate paths with 304 excess capacity exist. It is this aspect of congestion problems (-- a 305 symptom of suboptimal resource allocation) that Traffic Engineering 306 aims to vigorously obviate. Equal cost path load sharing can be used 307 to address the second cause for congestion listed above with some 308 degree of success, however it is generally not helpful in alleviating 309 congestion due to the first cause listed above and particularly not 310 in large networks with dense topology. 312 A popular approach to circumvent the inadequacies of current IGPs is 313 through the use of an overlay model, such as IP over ATM or IP over 314 frame relay. The overlay model extends the design space by enabling 315 arbitrary virtual topologies to be provisioned atop the network's 316 physical topology. The virtual topology is constructed from virtual 317 circuits which appear as physical links to the IGP routing protocols. 318 The overlay model provides additional important services to support 319 traffic and resource control, including: (1) constraint-based routing 320 at the VC level, (2) support for administratively configurable 321 explicit VC paths, (3) path compression, (4) call admission control 322 functions, (5) traffic shaping and traffic policing functions, and 323 (6) survivability of VCs. These capabilities enable the actualization 324 of a variety of Traffic Engineering policies. For example, virtual 325 circuits can easily be rerouted to move traffic from over-utilized 326 resources onto relatively underutilized ones. 328 For Traffic Engineering in large dense networks, it is desirable to 329 equip MPLS with a level of functionality at least commensurate with 330 current overlay models. Fortunately, this can be done in a fairly 331 straight forward manner. 333 3.0 MPLS and Traffic Engineering 335 This section provides an overview of the applicability of MPLS to 336 Traffic Engineering. Subsequent sections discuss the set of 337 capabilities required to meet the Traffic Engineering requirements. 339 MPLS is strategically significant for Traffic Engineering because it 340 can potentially provide most of the functionality available from the 341 overlay model, in an integrated manner, and at a lower cost than the 342 currently competing alternatives. Equally importantly, MPLS offers 343 the possibility to automate aspects of the Traffic Engineering 344 function. This last consideration requires further investigation and 345 is beyond the scope of this manuscript. 347 A note on terminology: The concept of MPLS traffic trunks is used 348 extensively in the remainder of this document. According to Li and 349 Rekhter [3], a traffic trunk is an aggregation of traffic flows of 350 the same class which are placed inside a Label Switched Path. 351 Essentially, a traffic trunk is an abstract representation of traffic 352 to which specific characteristics can be associated. It is useful to 353 view traffic trunks as objects that can be routed; that is, the path 354 through which a traffic trunk traverses can be changed. In this 355 respect, traffic trunks are similar to virtual circuits in ATM and 356 Frame Relay networks. It is important, however, to emphasize that 357 there is a fundamental distinction between a traffic trunk and the 358 path, and indeed the LSP, through which it traverses. An LSP is a 359 specification of the label switched path through which the traffic 360 traverses. In practice, the terms LSP and traffic trunk are often 361 used synonymously. Additional characteristics of traffic trunks as 362 used in this manuscript are summarized in section 5.0. 364 The attractiveness of MPLS for Traffic Engineering can be attributed 365 to the following factors: (1) explicit label switched paths which are 366 not constrained by the destination based forwarding paradigm can be 367 easily created through manual administrative action or through 368 automated action by the underlying protocols, (2) LSPs can 369 potentially be efficiently maintained, (3) traffic trunks can be 370 instantiated and mapped onto LSPs, (4) a set of attributes can be 371 associated with traffic trunks which modulate their behavioral 372 characteristics, (5) a set of attributes can be associated with 373 resources which constrain the placement of LSPs and traffic trunks 374 across them, (6) MPLS allows for both traffic aggregation and 375 disaggregation whereas classical destination only based IP forwarding 376 permits only aggregation, (7) it is relatively easy to integrate a 377 "constraint-based routing" framework with MPLS, (8) a good 378 implementation of MPLS can offer significantly lower overhead than 379 competing alternatives for Traffic Engineering. 381 Additionally, through explicit label switched paths, MPLS permits a 382 quasi circuit switching capability to be superimposed on the current 383 Internet routing model. Many of the existing proposals for Traffic 384 Engineering over MPLS focus only on the potential to create explicit 385 LSPs. Although this capability is fundamental for Traffic 386 Engineering, it is not really sufficient. Additional augmentations 387 are required to foster the actualization of policies leading to 388 performance optimization of large operational networks. Some of the 389 necessary augmentations are described in this manuscript. 391 3.1 Induced MPLS Graph 393 This subsection introduces the concept of an "induced MPLS graph" 394 which is central to Traffic Engineering in MPLS domains. An induced 395 MPLS graph is analogous to a virtual topology in an overlay model. It 396 is logically mapped onto the physical network through the selection 397 of LSPs for traffic trunks. 399 An induced MPLS graph consists of a set of LSRs which comprise the 400 nodes of the graph and a set of LSPs which provide logical point to 401 point connectivity between the LSRs, and hence serve as the links of 402 the induced graph. it may be possible to construct hierarchical 403 induced MPLS graphs based on the concept of label stacks (see [1]). 405 Induced MPLS graphs are important because the basic problem of 406 bandwidth management in an MPLS domain is the issue of how to 407 efficiently map an induced MPLS graph onto the physical network 408 topology. The induced MPLS graph abstraction is formalized below. 410 Let G = (V, E, c) be a capacitated graph depicting the physical 411 topology of the network. Here, V is the set of nodes in the network 412 and E is the set of links; that is, for v and w in V, the object 413 (v,w) is in E if v and w are directly connected under G. The 414 parameter "c" is a set of capacity and other constraints associated 415 with E and V. We will refer to G as the "base" network topology. 417 Let H = (U, F, d) be the induced MPLS graph, where U is a subset of 418 V representing the set of LSRs in the network, or more precisely the 419 set of LSRs that are the endpoints of at least one LSP. Here, F is 420 the set of LSPs, so that for x and y in U, the object (x, y) is in F 421 if there is an LSP with x and y as endpoints. The parameter "d" is 422 the set of demands and restrictions associated with F. Evidently, H 423 is a directed graph. It can be seen that H depends on the 424 transitivity characteristics of G. 426 3.2 The Fundamental Problem of Traffic Engineering Over MPLS 428 There are basically three fundamental problems that relate to Traffic 429 Engineering over MPLS. 431 - The first problem concerns how to map packets onto forwarding 432 equivalence classes. 434 - The second problem concerns how to map forwarding equivalence 435 classes onto traffic trunks. 437 - The third problem concerns how to map traffic trunks onto the 438 physical network topology through label switched paths. 440 This document is not focusing on the first two problems listed. 441 (even-though they are quite important). Instead, the remainder of 442 this manuscript will focus on the capabilities that permit the third 443 mapping function to be performed in a manner resulting in efficient 444 and reliable network operations. This is really the problem of 445 mapping an induced MPLS graph (H) onto the "base" network topology 446 (G). 448 4.0 Augmented Capabilities for Traffic Engineering Over MPLS 450 The previous sections reviewed the basic functions of Traffic 451 Engineering in the contemporary Internet. The applicability of MPLS 452 to that activity was also discussed. The remaining sections of this 453 manuscript describe the functional capabilities required to fully 454 support Traffic Engineering over MPLS in large networks. 456 The proposed capabilities consist of: 458 1. A set of attributes associated with traffic trunks which 459 collectively specify their behavioral characteristics. 461 2. A set of attributes associated with resources which constrain 462 the placement of traffic trunks through them. These can also be 463 viewed as topology attribute constraints. 465 3. A "constraint-based routing" framework which is used to select 466 paths for traffic trunks subject to constraints imposed by items 467 1) and 2) above. The constraint-based routing framework does not 468 have to be part of MPLS. However, the two need to be tightly 469 integrated together. 471 The attributes associated with traffic trunks and resources, as well 472 as parameters associated with routing, collectively represent the 473 control variables which can be modified either through administrative 474 action or through automated agents to drive the network to a desired 475 state. 477 In an operational network, it is highly desirable that these 478 attributes can be dynamically modified online by an operator without 479 adversely disrupting network operations. 481 5.0 Traffic Trunk Attributes and Characteristics 483 This section describes the desirable attributes which can be 484 associated with traffic trunks to influence their behavioral 485 characteristics. 487 First, the basic properties of traffic trunks (as used in this 488 manuscript) are summarized below: 490 - A traffic trunk is an *aggregate* of traffic flows belonging 491 to the same class. In some contexts, it may be desirable to 492 relax this definition and allow traffic trunks to include 493 multi-class traffic aggregates. 495 - In a single class service model, such as the current Internet, 496 a traffic trunk could encapsulate all of the traffic between an 497 ingress LSR and an egress LSR, or subsets thereof. 499 - Traffic trunks are routable objects (similar to ATM VCs). 501 - A traffic trunk is distinct from the LSP through which it 502 traverses. In operational contexts, a traffic trunk can be 503 moved from one path onto another. 505 - A traffic trunk is unidirectional. 507 In practice, a traffic trunk can be characterized by its ingress and 508 egress LSRs, the forwarding equivalence class which is mapped onto 509 it, and a set of attributes which determine its behavioral 510 characteristics. 512 Two basic issues are of particular significance: (1) parameterization 513 of traffic trunks and (2) path placement and maintenance rules for 514 traffic trunks. 516 5.1 Bidirectional Traffic Trunks 518 Although traffic trunks are conceptually unidirectional, in many 519 practical contexts, it is useful to simultaneously instantiate two 520 traffic trunks with the same endpoints, but which carry packets in 521 opposite directions. The two traffic trunks are logically coupled 522 together. One trunk, called the forward trunk, carries traffic from 523 an originating node to a destination node. The other trunk, called 524 the backward trunk, carries traffic from the destination node to the 525 originating node. We refer to the amalgamation of two such traffic 526 trunks as one bidirectional traffic trunk (BTT) if the following two 527 conditions hold: 529 - Both traffic trunks are instantiated through an atomic action at 530 one LSR, called the originator node, or through an atomic action 531 at a network management station. 533 - Neither of the composite traffic trunks can exist without the 534 other. That is, both are instantiated and destroyed together. 536 The topological properties of BTTs should also be considered. A BTT 537 can be topologically symmetric or topologically asymmetric. A BTT is 538 said to be "topologically symmetric" if its constituent traffic 539 trunks are routed through the same physical path, even though they 540 operate in opposite directions. If, however, the component traffic 541 trunks are routed through different physical paths, then the BTT is 542 said to be "topologically asymmetric." 544 It should be noted that bidirectional traffic trunks are merely an 545 administrative convenience. In practice, most traffic engineering 546 functions can be implemented using only unidirectional traffic 547 trunks. 549 5.2 Basic Operations on Traffic Trunks 551 The basic operations on traffic trunks significant to Traffic 552 Engineering purposes are summarized below. 554 - Establish: To create an instance of a traffic trunk. 556 - Activate: To cause a traffic trunk to start passing traffic. 557 The establishment and activation of a traffic trunk are 558 logically separate events. They may, however, be implemented 559 or invoked as one atomic action. 561 - Deactivate: To cause a traffic trunk to stop passing traffic. 563 - Modify Attributes: To cause the attributes of a traffic trunk 564 to be modified. 566 - Reroute: To cause a traffic trunk to change its route. This 567 can be done through administrative action or automatically 568 by the underlying protocols. 570 - Destroy: To remove an instance of a traffic trunk from the 571 network and reclaim all resources allocated to it. Such 572 resources include label space and possibly available bandwidth. 574 The above are considered the basic operations on traffic trunks. 575 Additional operations are also possible such as policing and traffic 576 shaping. 578 5.3 Accounting and Performance Monitoring 580 Accounting and performance monitoring capabilities are very important 581 to the billing and traffic characterization functions. Performance 582 statistics obtained from accounting and performance monitoring 583 systems can be used for traffic characterization, performance 584 optimization, and capacity planning within the Traffic Engineering 585 realm.. 587 The capability to obtain statistics at the traffic trunk level is so 588 important that it should be considered an essential requirement for 589 Traffic Engineering over MPLS. 591 5.4 Basic Traffic Engineering Attributes of Traffic Trunks 593 An attribute of a traffic trunk is a parameter assigned to it which 594 influences its behavioral characteristics. 596 Attributes can be explicitly assigned to traffic trunks through 597 administration action or they can be implicitly assigned by the 598 underlying protocols when packets are classified and mapped into 599 equivalence classes at the ingress to an MPLS domain. Regardless of 600 how the attributes were originally assigned, for Traffic Engineering 601 purposes, it should be possible to administratively modify such 602 attributes. 604 The basic attributes of traffic trunks particularly significant for 605 Traffic Engineering are itemized below. 607 - Traffic parameter attributes 609 - Generic Path selection and maintenance attributes 611 - Priority attribute 613 - Preemption attribute 615 - Resilience attribute 617 - Policing attribute 619 The combination of traffic parameters and policing attributes is 620 analogous to usage parameter control in ATM networks. Most of the 621 attributes listed above have analogs in well established 622 technologies. Consequently, it should be relatively straight forward 623 to map the traffic trunk attributes onto many existing switching and 624 routing architectures. 626 Priority and preemption can be regarded as relational attributes 627 because they express certain binary relations between traffic trunks. 628 Conceptually, these binary relations determine the manner in which 629 traffic trunks interact with each other as they compete for network 630 resources during path establishment and path maintenance. 632 5.5 Traffic parameter attributes 634 Traffic parameters can be used to capture the characteristics of the 635 traffic streams (or more precisely the forwarding equivalence class) 636 to be transported through the traffic trunk. Such characteristics may 637 include peak rates, average rates, permissible burst size, etc. From 638 a traffic engineering perspective, the traffic parameters are 639 significant because they indicate the resource requirements of the 640 traffic trunk. This is useful for resource allocation and congestion 641 avoidance through anticipatory policies. 643 For the purpose of bandwidth allocation, a single canonical value of 644 bandwidth requirements can be computed from a traffic trunk's traffic 645 parameters. Techniques for performing these computations are well 646 known. One example of this is the theory of effective bandwidth. 648 5.6 Generic Path Selection and Management Attributes 650 Generic path selection and management attributes define the rules for 651 selecting the route taken by a traffic trunk as well as the rules for 652 maintenance of paths that are already established. 654 Paths can be computed automatically by the underlying routing 655 protocols or they can be defined administratively by a network 656 operator. If there are no resource requirements or restrictions 657 associated with a traffic trunk, then a topology driven protocol can 658 be used to select its path. However, if resource requirements or 659 policy restrictions exist, then a constraint-based routing scheme 660 should be used for path selection. 662 In Section 7, a constraint-based routing framework which can 663 automatically compute paths subject to a set of constraints is 664 described. Issues pertaining to explicit paths instantiated through 665 administrative action are discussed in Section 5.6.1 below. 667 Path management concerns all aspects pertaining to the maintenance of 668 paths traversed by traffic trunks. In some operational contexts, it 669 is desirable that an MPLS implementation can dynamically reconfigure 670 itself, to adapt to some notion of change in "system state." 671 Adaptivity and resilience are aspects of dynamic path management. 673 To guide the path selection and management process, a set of 674 attributes are required. The basic attributes and behavioral 675 characteristics associated with traffic trunk path selection and 676 management are described in the remainder of this sub-section. 678 5.6.1 Administratively Specified Explicit Paths 680 An administratively specified explicit path for a traffic trunk is 681 one which is configured through operator action. An administratively 682 specified path can be completely specified or partially specified. A 683 path is completely specified if all of the required hops between the 684 endpoints are indicated. A path is partially specified if only a 685 subset of intermediate hops are indicated. In this case, the 686 underlying protocols are required to complete the path. Due to 687 operator errors, an administratively specified path can be 688 inconsistent or illogical. The underlying protocols should be able to 689 detect such inconsistencies and provide appropriate feedback. 691 A "path preference rule" attribute should be associated with 692 administratively specified explicit paths. A path preference rule 693 attribute is a binary variable which indicates whether the 694 administratively configured explicit path is "mandatory" or "non- 695 mandatory." 697 If an administratively specified explicit path is selected with a 698 "mandatory attribute, then that path (and only that path) must be 699 used. If a mandatory path is topological infeasible (e.g. the two 700 endpoints are topologically partitioned), or if the path cannot be 701 instantiated because the available resources are inadequate, then the 702 path setup process fails. In other words, if a path is specified as 703 mandatory, then an alternate path cannot be used regardless of 704 prevailing circumstance. A mandatory path which is successfully 705 instantiated is also implicitly pinned. Once the path is instantiated 706 it cannot be changed except through deletion and instantiation of a 707 new path. 709 However, if an administratively specified explicit path is selected 710 with a "non-mandatory" preference rule attribute value, then the path 711 should be used if feasible. Otherwise, an alternate path can be 712 chosen instead by the underlying protocols. 714 5.6.2 Hierarchy of Preference Rules For Multi-Paths 716 In some practical contexts, it can be useful to have the ability to 717 administratively specify a set of candidate explicit paths for a 718 given traffic trunk and define a hierarchy of preference relations on 719 the paths. During path establishment, the preference rules are 720 applied to select a suitable path from the candidate list. Also, 721 under failure scenarios the preference rules are applied to select an 722 alternate path from the candidate list. 724 5.6.3 Resource Class Affinity Attributes 726 Resource class affinity attributes associated with a traffic trunk 727 can be used to specify the class of resources (see Section 6) which 728 are to be explicitly included or excluded from the path of the 729 traffic trunk. These are policy attributes which can be used to 730 impose additional constraints on the path traversed by a given 731 traffic trunk. Resource class affinity attributes for a traffic can 732 be specified as a sequence of tuples: 734 ; ; .. 736 The resource-class parameter identifies a resource class for which an 737 affinity relationship is defined with respect to the traffic trunk. 738 The affinity parameter indicates the affinity relationship; that is, 739 whether members of the resource class are to be included or excluded 740 from the path of the traffic trunk. Specifically, the affinity 741 parameter MAY be a binary variable which takes one of the following 742 values: (1) explicit inclusion, and (2) explicit exclusion. 744 If the affinity attribute is a binary variable, it may be possible to 745 use Boolean expressions to specify the resource class affinities 746 associated with a given traffic trunk. 748 If no resource class affinity attributes are specified, then a "don't 749 care" affinity relationship is assumed to hold between the traffic 750 trunk and all resources. That is, there is no requirement to 751 explicitly include or exclude any resources from the traffic trunk's 752 path. This should be the default in practice. 754 Resource class affinity attributes are very useful and powerful 755 constructs because they can be used to implement a variety of 756 policies. For example, they can be used to contain certain traffic 757 trunks within specific topological regions of the network. 759 A "constraint-based routing" framework (see section 7.0) can be used 760 to compute an explicit path for a traffic trunk subject to resource 761 class affinity constraints in the following manner: 763 1. For explicit inclusion, prune all resources not belonging 764 to the specified classes prior to performing path computation. 766 2. For explicit exclusion, prune all resources belonging to the 767 specified classes before performing path placement computations. 769 5.6.4 Adaptivity Attribute 771 Network characteristics and state change over time. For example, new 772 resources become available, failed resources become reactivated, and 773 allocated resources become deallocated. In general, sometimes more 774 efficient paths become available. Therefore, from a Traffic 775 Engineering perspective, it is necessary to have administrative 776 control parameters that can be used to specify how traffic trunks 777 respond to this dynamism. In some scenarios, it might be desirable to 778 dynamically change the paths of certain traffic trunks in response to 779 changes in network state. This process is called re-optimization. In 780 other scenarios, re-optimization might be very undesirable. 782 An Adaptivity attribute is a part of the path maintenance parameters 783 associated with traffic trunks. The adaptivity attribute associated 784 with a traffic trunk indicates whether the trunk is subject to re- 785 optimization. That is, an adaptivity attribute is a binary variable 786 which takes one of the following values: (1) permit re-optimization 787 and (2) disable re-optimization. 789 If re-optimization is enabled, then a traffic trunk can be rerouted 790 through different paths by the underlying protocols in response to 791 changes in network state (primarily changes in resource 792 availability). Conversely, if re-optimization is disabled, then the 793 traffic trunk is "pinned" to its established path and cannot be 794 rerouted in response to changes in network state. 796 Stability is a major concern when re-optimization is permitted. To 797 promote stability, an MPLS implementation should not be too reactive 798 to the evolutionary dynamics of the network. At the same time, it 799 must adapt fast enough so that optimal use can be made of network 800 assets. This implies that the frequency of re-optimization should be 801 administratively configurable to allow for tuning. 803 It is to be noted that re-optimization is distinct from resilience. A 804 different attribute is used to specify the resilience characteristics 805 of a traffic trunk (see section 5.9). In practice, it would seem 806 reasonable to expect traffic trunks subject to re-optimization to be 807 implicitly resilient to failures along their paths. However, a 808 traffic trunk which is not subject to re-optimization and whose path 809 is not administratively specified with a "mandatory" attribute can 810 also be required to be resilient to link and node failures along its 811 established path 813 Formally, it can be stated that adaptivity to state evolution through 814 re-optimization implies resilience to failures, whereas resilience to 815 failures does not imply general adaptivity through re-optimization to 816 state changes. 818 5.6.5 Load Distribution Across Parallel Traffic Trunks 820 Load distribution across multiple parallel traffic trunks between two 821 nodes is an important consideration. In many practical contexts, the 822 aggregate traffic between two nodes may be such that no single link 823 (hence no single path) can carry the load. However, the aggregate 824 flow might be less than the maximum permissible flow across a "min- 825 cut" that partitions the two nodes. In this case, the only feasible 826 solution is to appropriately divide the aggregate traffic into sub- 827 streams and route the sub-streams through multiple paths between the 828 two nodes. 830 In an MPLS domain, this problem can be addressed by instantiating 831 multiple traffic trunks between the two nodes, such that each traffic 832 trunk carries a proportion of the aggregate traffic. Therefore, a 833 flexible means of load assignment to multiple parallel traffic trunks 834 carrying traffic between a pair of nodes is required. 836 Specifically, from an operational perspective, in situations where 837 parallel traffic trunks are warranted, it would be useful to have 838 some attribute that can be used to indicate the relative proportion 839 of traffic to be carried by each traffic trunk. The underlying 840 protocols will then map the load onto the traffic trunks according to 841 the specified proportions. It is also, generally desirable to 842 maintain packet ordering between packets belong to the same micro- 843 flow (same source address, destination address, and port number). 845 5.7 Priority attribute 847 The priority attribute defines the relative importance of traffic 848 trunks. If a constraint-based routing framework is used with MPLS, 849 then priorities become very important because they can be used to 850 determine the order in which path selection is done for traffic 851 trunks at connection establishment and under fault scenarios. 853 Priorities are also important in implementations permitting 854 preemption because they can be used to impose a partial order on the 855 set of traffic trunks according to which preemptive policies can be 856 actualized. 858 5.8 Preemption attribute 860 The preemption attribute determines whether a traffic trunk can 861 preempt another traffic trunk from a given path, and whether another 862 traffic trunk can preempt a specific traffic trunk. Preemption is 863 useful for both traffic oriented and resource oriented performance 864 objectives. Preemption can used to assure that high priority traffic 865 trunks can always be routed through relatively favorable paths within 866 a differentiated services environment. 868 Preemption can also be used to implement various prioritized 869 restoration policies following fault events. 871 The preemption attribute can be used to specify four preempt modes 872 for a traffic trunk: (1) preemptor enabled, (2) non-preemptor, (3) 873 preemptable, and (4) non-preemptable. A preemptor enabled traffic 874 trunk can preempt lower priority traffic trunks designated as 875 preemptable. A traffic specified as non-preemptable cannot be 876 preempted by any other trunks, regardless of relative priorities. A 877 traffic trunk designated as preemptable can be preempted by higher 878 priority trunks which are preemptor enabled. 880 It is trivial to see that some of the preempt modes are mutually 881 exclusive. Using the numbering scheme depicted above, the feasible 882 preempt mode combinations for a given traffic trunk are as follows: 883 (1, 3), (1, 4), (2, 3), and (2, 4). The (2, 4) combination should be 884 the default. 886 A traffic trunk, say "A", can preempt another traffic trunk, say "B", 887 only if *all* of the following five conditions hold: (i) "A" has a 888 relatively higher priority than "B", (ii) "A" contends for a resource 889 utilized by "B", (iii) the resource cannot concurrently accommodate 890 "A" and "B" based on certain decision criteria, (iv) "A" is preemptor 891 enabled, and (v) "B" is preemptable. 893 Preemption is not considered a mandatory attribute under the current 894 best effort Internet service model although it is useful. However, in 895 a differentiated services scenario, the need for preemption becomes 896 more compelling. Moreover, in the emerging optical internetworking 897 architectures, where some protection and restoration functions may be 898 migrated from the optical layer to data network elements (such as 899 gigabit and terabit label switching routers) to reduce costs, 900 preemptive strategies can be used to reduce the restoration time for 901 high priority traffic trunks under fault conditions. 903 5.9 Resilience Attribute 905 The resilience attribute determines the behavior of a traffic trunk 906 under fault conditions. That is, when a fault occurs along the path 907 through which the traffic trunk traverses. The following basic 908 problems need to be addressed under such circumstances: (1) fault 909 detection, (2) failure notification, (3) recovery and service 910 restoration. Obviously, an MPLS implementation will have to 911 incorporate mechanisms to address these issues. 913 Many recovery policies can be specified for traffic trunks whose 914 established paths are impacted by faults. The following are examples 915 of feasible schemes: 917 1. Do not reroute the traffic trunk. For example, a survivability 918 scheme may already be in place, provisioned through an 919 alternate mechanism, which guarantees service continuity 920 under failure scenarios without the need to reroute traffic 921 trunks. An example of such an alternate scheme (certainly 922 many others exist), is a situation whereby multiple parallel 923 label switched paths are provisioned between two nodes, and 924 function in a manner such that failure of one LSP causes the 925 traffic trunk placed on it to be mapped onto the remaining LSPs 926 according to some well defined policy. 928 2. Reroute through a feasible path with enough resources. If none 929 exists, then do not reroute. 931 3. Reroute through any available path regardless of resource 932 constraints. 934 4. Many other schemes are possible including some which might be 935 combinations of the above. 937 A "basic" resilience attribute indicates the recovery procedure to be 938 applied to traffic trunks whose paths are impacted by faults. 939 Specifically, a "basic" resilience attribute is a binary variable 940 which determines whether the target traffic trunk is to be rerouted 941 when segments of its path fail. "Extended" resilience attributes can 942 be used to specify detailed actions to be taken under fault 943 scenarios. For example, an extended resilience attribute might 944 specify a set of alternate paths to use under fault conditions, as 945 well as the rules that govern the relative preference of each 946 specified path. 948 Resilience attributes mandate close interaction between MPLS and 949 routing. 951 5.10 Policing attribute 953 The policing attribute determines the actions that should be taken by 954 the underlying protocols when a traffic trunk becomes non-compliant. 955 That is, when a traffic trunk exceeds its contract as specified in 956 the traffic parameters. Generally, policing attributes can indicate 957 whether a non-conformant traffic trunk is to be rate limited, tagged, 958 or simply forwarded without any policing action. If policing is 959 used, then adaptations of established algorithms such as the ATM 960 Forum's GCRA [11] can be used to perform this function. 962 Policing is necessary in many operational scenarios, but is quite 963 undesirable in some others. In general, it is usually desirable to 964 police at the ingress to a network (to enforce compliance with 965 service level agreements) and to minimize policing within the core, 966 except when capacity constraints dictate otherwise. 968 Therefore, from a Traffic Engineering perspective, it is necessary to 969 be able to administratively enable or disable traffic policing for 970 each traffic trunk. 972 6.0 Resource Attributes 974 Resource attributes are part of the topology state parameters, which 975 are used to constrain the routing of traffic trunks through specific 976 resources. 978 6.1 Maximum Allocation Multiplier 980 The maximum allocation multiplier (MAM) of a resource is an 981 administratively configurable attribute which determines the 982 proportion of the resource that is available for allocation to 983 traffic trunks. This attribute is mostly applicable to link 984 bandwidth. However, it can also be applied to buffer resources on 985 LSRs. The concept of MAM is analogous to the concepts of subscription 986 and booking factors in frame relay and ATM networks. 988 The values of the MAM can be chosen so that a resource can be under- 989 allocated or over-allocated. A resource is said to be under- 990 allocated if the aggregate demands of all traffic trunks (as 991 expressed in the trunk traffic parameters) that can be allocated to 992 it are always less than the capacity of the resource. A resource is 993 said to be over-allocated if the aggregate demands of all traffic 994 trunks allocated to it can exceed the capacity of the resource. 996 Under-allocation can be used to bound the utilization of resources. 997 However,the situation under MPLS is more complex than in circuit 998 switched schemes because under MPLS, some flows can be routed via 999 conventional hop by hop protocols (also via explicit paths) without 1000 consideration for resource constraints. 1002 Over-allocation can be used to take advantage of the statistical 1003 characteristics of traffic in order to implement more efficient 1004 resource allocation policies. In particular, over-allocation can be 1005 used in situations where the peak demands of traffic trunks do not 1006 coincide in time. 1008 6.2 Resource Class Attribute 1010 Resource class attributes are administratively assigned parameters 1011 which express some notion of "class" for resources. Resource class 1012 attributes can be viewed as "colors" assigned to resources such that 1013 the set of resources with the same "color" conceptually belong to the 1014 same class. Resource class attributes can be used to implement a 1015 variety of policies. The key resources of interest here are links. 1016 When applied to links, the resource class attribute effectively 1017 becomes an aspect of the "link state" parameters. 1019 The concept of resource class attributes is a powerful abstraction. 1020 From a Traffic Engineering perspective, it can be used to implement 1021 many policies with regard to both traffic and resource oriented 1022 performance optimization. Specifically, resource class attributes can 1023 be used to: 1025 1. Apply uniform policies to a set of resources that do not need 1026 to be in the same topological region. 1028 2. Specify the relative preference of sets of resources for 1029 path placement of traffic trunks. 1031 3. Explicitly restrict the placement of traffic trunks 1032 to specific subsets of resources. 1034 4. Implement generalized inclusion / exclusion policies. 1036 5. Enforce traffic locality containment policies. That is, 1037 policies that seek to contain local traffic within 1038 specific topological regions of the network. 1040 Additionally, resource class attributes can be used for 1041 identification purposes. 1043 In general, a resource can be assigned more than one resource class 1044 attribute. For example, all of the OC-48 links in a given network may 1045 be assigned a distinguished resource class attribute. The subsets of 1046 OC-48 links which exist with a given abstraction domain of the 1047 network may be assigned additional resource class attributes in order 1048 to implement specific containment policies, or to architect the 1049 network in a certain manner. 1051 7.0 Constraint-Based Routing 1053 This section discusses the issues pertaining to constraint-based 1054 routing in MPLS domains. In contemporary terminology, constraint- 1055 based routing is often referred to as "QoS Routing" see [5,6,7,10]. 1056 This document uses the term "constraint-based routing" however, 1057 because it better captures the functionality envisioned, which 1058 generally encompasses QoS routing as a subset. 1060 constraint-based routing enables a demand driven, resource 1061 reservation aware, routing paradigm to co-exist with current topology 1062 driven hop by hop Internet interior gateway protocols. 1064 A constraint-based routing framework uses the following as input: 1066 - The attributes associated with traffic trunks. 1068 - The attributes associated with resources. 1070 - Other topology state information. 1072 Based on this information, a constraint-based routing process on each 1073 node automatically computes explicit routes for each traffic trunk 1074 originating from the node. In this case, an explicit route for each 1075 traffic trunk is a specification of a label switched path that 1076 satisfies the demand requirements expressed in the trunk's 1077 attributes, subject to constraints imposed by resource availability, 1078 administrative policy, and other topology state information. 1080 A constraint-based routing framework can greatly reduce the level of 1081 manual configuration and intervention required to actualize Traffic 1082 Engineering policies. 1084 In practice, the Traffic Engineer, an operator, or even an automaton 1085 will specify the endpoints of a traffic trunk and assign a set of 1086 attributes to the trunk which encapsulate the performance 1087 expectations and behavioral characteristics of the trunk. The 1088 constraint-based routing framework is then expected to find a 1089 feasible path to satisfy the expectations. If necessary, the Traffic 1090 Engineer or a traffic engineering support system can then use 1091 administratively configured explicit routes to perform fine grained 1092 optimization. 1094 7.1 Basic Features of Constraint-Based Routing 1096 A constraint-based routing framework should at least have the 1097 capability to automatically obtain a basic feasible solution to the 1098 traffic trunk path placement problem. 1100 In general, the constraint-based routing problem is known to be 1101 intractable for most realistic constraints. However, in practice, a 1102 very simple well known heuristic (see e.g. [9]) can be used to find a 1103 feasible path if one exists: 1105 - First prune resources that do not satisfy the requirements of 1106 the traffic trunk attributes. 1108 - Next, run a shortest path algorithm on the residual graph. 1110 Clearly, if a feasible path exists for a single traffic trunk, then 1111 the above simple procedure will find it. Additional rules can be 1112 specified to break ties and perform further optimizations. In 1113 general, ties should be broken so that congestion is minimized. When 1114 multiple traffic trunks are to be routed, however, it can be shown 1115 that the above algorithm may not always find a mapping, even when a 1116 feasible mapping exists. 1118 7.2 Implementation Considerations 1120 Many commercial implementations of frame relay and ATM switches 1121 already support some notion of constraint-based routing. For such 1122 devices or for the novel MPLS centric contraptions devised therefrom, 1123 it should be relatively easy to extend the current constraint-based 1124 routing implementations to accommodate the peculiar requirements of 1125 MPLS. 1127 For routers that use topology driven hop by hop IGPs, constraint- 1128 based routing can be incorporated in at least one of two ways: 1130 1. By extending the current IGP protocols such as OSPF and IS-IS to 1131 support constraint-based routing. Effort is already underway to 1132 provide such extensions to OSPF (see [5,7]). 1134 2. By adding a constraint-based routing process to each router which 1135 can co-exist with current IGPs. This scenario is depicted 1136 in Figure 1. 1138 ------------------------------------------ 1139 | Management Interface | 1140 ------------------------------------------ 1141 | | | 1142 ------------ ------------------ -------------- 1143 | MPLS |<->| Constraint-Based | | Conventional | 1144 | | | Routing Process | | IGP Process | 1145 ------------ ------------------ -------------- 1146 | | 1147 ----------------------- -------------- 1148 | Resource Attribute | | Link State | 1149 | Availability Database | | Database | 1150 ----------------------- -------------- 1152 Figure 1. Constraint-Based Routing Process on Layer 3 LSR 1154 There are many important details associated with implementing 1155 constraint-based routing on Layer 3 devices which we do not discuss 1156 here. These include the following: 1158 - Mechanisms for exchange of topology state information 1159 (resource availability information, link state information, 1160 resource attribute information) between constraint-based 1161 routing processes. 1163 - Mechanisms for maintenance of topology state information. 1165 - Interaction between constraint-based routing processes and 1166 conventional IGP processes. 1168 - Mechanisms to accommodate the adaptivity requirements of 1169 traffic trunks. 1171 - Mechanisms to accommodate the resilience and survivability 1172 requirements of traffic trunks. 1174 In summary, constraint-based routing assists in performance 1175 optimization of operational networks by automatically finding 1176 feasible paths that satisfy a set of constraints for traffic trunks. 1177 It can drastically reduce the amount of administrative explicit path 1178 configuration and manual intervention required to achieve Traffic 1179 Engineering objectives. 1181 8.0 Conclusion 1183 This manuscript presented a set of requirements for Traffic 1184 Engineering over MPLS. Many capabilities were described aimed at 1185 enhancing the applicability of MPLS to Traffic Engineering in the 1186 Internet. 1188 It should be noted that some of the issues described here can be 1189 addressed by incorporating a minimal set of building blocks into 1190 MPLS, and then using a network management superstructure to extend 1191 the functionality in order to realize the requirements. Also, the 1192 constraint-based routing framework does not have to be part of the 1193 core MPLS specifications. However, MPLS does require some interaction 1194 with a constraint-based routing framework in order to meet the 1195 requirements. 1197 9.0 Security Considerations 1199 This document does not introduce new security issues beyond those 1200 inherent in MPLS and may use the same mechanisms proposed for this 1201 technology. It is, however, specifically important that manipulation 1202 of administratively configurable parameters be executed in a secure 1203 manner by authorized entities. 1205 10.0 References 1207 [1] E. Rosen, A. Viswanathan, R. Callon, "A Proposed Architecture 1208 for MPLS", Work in Progress. 1210 [2] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, 1211 A. Viswanathan, "A Framework for Multiprotocol Label 1212 Switching", Work in Progress. 1214 [3] T. Li and Y. Rekhter, "Provider Architecture for Differentiated 1215 Services and Traffic Engineering (PASTE)," RFC 2430, 1216 October 1998. 1218 [4] Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow, "Cisco 1219 Systems' Tag Switching Architecture - Overview", RFC 2105, 1220 February 1997. 1222 [5] Z. Zhang, C. Sanchez, B. Salkewicz, E. Crawley "Quality of 1223 Service Extensions to OSPF", Work in Progress. 1225 [6] E. Crawley, R. Nair, B. Rajagopalan, H. Sandick, "A framework 1226 for QoS Based Routing in the Internet," RFC 2386, August 1998 1228 [7] R. Guerin, S. Kamat, A. Orda, T. Przygienda, D. Williams, 1229 "QoS Routing Mechanisms and OSPF Extensions," Work in Progress. 1231 [8] C. Yang and A. Reddy, "A Taxonomy for Congestion Control 1232 Algorithms in Packet Switching Networks," IEEE Network 1233 Magazine, Volume 9, Number 5, July/August 1995, 1235 [9] W. Lee, M. Hluchyi, and P. Humblet, "Routing Subject to 1236 Quality of Service Constraints in Integrated Communication 1237 Networks," IEEE Network, July 1995, pp 46-55. 1239 [10] ATM Forum, "Traffic Management Specification: Version 4.0" 1240 April 1996. 1242 [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1243 Levels", BCP 14, RFC 2119, March 1997. 1245 11.0 Acknowledgments 1247 The authors would like to thank Yakov Rekhter for his review of an 1248 earlier draft of this document. The authors would also like to thank 1249 Louis Mamakos and Bill Barns for their helpful suggestions, and 1250 Curtis Villamizar for providing some useful feedback. 1252 12.0 AUTHORS' ADDRESSES 1254 Daniel O. Awduche 1255 UUNET (MCI Worldcom) 1256 3060 Williams Drive 1257 Fairfax, VA 22031 1258 Email: awduche@uu.net 1259 Voice: +1 703-208-5277 1261 Joe Malcolm 1262 UUNET (MCI Worldcom) 1263 3060 Williams Drive 1264 Fairfax, VA 22031 1265 Email: jmalcolm@uu.net 1266 Voice: +1 703-206-5895 1268 Johnson Agogbua 1269 UUNET (MCI Worldcom) 1270 3060 Williams Drive 1271 Fairfax, VA 22031 1272 Email: ja@uu.net 1273 Voice: +1 703-206-5794 1275 Mike O'Dell 1276 UUNET (MCI Worldcom) 1277 3060 Williams Drive 1278 Fairfax, VA 22031 1279 Email: mo@uu.net 1280 Voice: +1 703-206-5890 1282 Jim McManus 1283 UUNET (MCI Worldcom) 1284 3060 Williams Drive 1285 Fairfax, VA 22031 1286 jmcmanus@uu.net 1287 Voice: +1 703-206-5607