doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc2702.txt b/doc/rfc/rfc2702.txt
new file mode 100644
index 0000000..0306464
--- /dev/null
+++ b/doc/rfc/rfc2702.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group                                          D. Awduche
+Request for Comments: 2702                                     J. Malcolm
+Category: Informational                                        J. Agogbua
+                                                                M. O'Dell
+                                                               J. McManus
+                                                     UUNET (MCI Worldcom)
+                                                           September 1999
+
+
+             Requirements for Traffic Engineering Over MPLS
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   This document presents a set of requirements for Traffic Engineering
+   over Multiprotocol Label Switching (MPLS). It identifies the
+   functional capabilities required to implement policies that
+   facilitate efficient and reliable network operations in an MPLS
+   domain. These capabilities can be used to optimize the utilization of
+   network resources and to enhance traffic oriented performance
+   characteristics.
+
+Table of Contents
+
+   1.0   Introduction .............................................  2
+   1.1   Terminology ..............................................  3
+   1.2   Document Organization ....................................  3
+   2.0   Traffic Engineering ......................................  4
+   2.1   Traffic Engineering Performance Objectives ...............  4
+   2.2   Traffic and Resource Control .............................  6
+   2.3   Limitations of Current IGP Control Mechanisms ............  6
+   3.0   MPLS and Traffic Engineering .............................  7
+   3.1   Induced MPLS Graph .......................................  9
+   3.2   The Fundamental Problem of Traffic Engineering Over MPLS .  9
+   4.0   Augmented Capabilities for Traffic Engineering Over MPLS . 10
+   5.0   Traffic Trunk Attributes and Characteristics   ........... 10
+   5.1   Bidirectional Traffic Trunks ............................. 11
+   5.2   Basic Operations on Traffic Trunks ....................... 12
+   5.3   Accounting and Performance Monitoring .................... 12
+
+
+
+Awduche, et al.              Informational                      [Page 1]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   5.4   Basic Attributes of Traffic Trunks ....................... 13
+   5.5   Traffic Parameter Attributes  ............................ 14
+   5.6   Generic Path Selection and Management Attributes ......... 14
+   5.6.1 Administratively Specified Explicit Paths ................ 15
+   5.6.2 Hierarchy of Preference Rules for Multi-paths ............ 15
+   5.6.3 Resource Class Affinity Attributes ....................... 16
+   5.6.4 Adaptivity Attribute ..................................... 17
+   5.6.5 Load Distribution Across Parallel Traffic Trunks ......... 18
+   5.7   Priority Attribute ....................................... 18
+   5.8   Preemption Attribute ..................................... 18
+   5.9   Resilience Attribute ..................................... 19
+   5.10  Policing Attribute  ...................................... 20
+   6.0   Resource Attributes ...................................... 21
+   6.1   Maximum Allocation Multiplier ............................ 21
+   6.2   Resource Class Attribute  ................................ 22
+   7.0   Constraint-Based Routing  ................................ 22
+   7.1   Basic Features of Constraint-Based Routing ............... 23
+   7.2   Implementation Considerations ............................ 24
+   8.0   Conclusion   ............................................. 25
+   9.0   Security Considerations .................................. 26
+   10.0  References   ............................................. 26
+   11.0  Acknowledgments .......................................... 27
+   12.0  Authors' Addresses ....................................... 28
+   13.0  Full Copyright Statement ................................. 29
+
+1.0 Introduction
+
+   Multiprotocol Label Switching (MPLS) [1,2] integrates a label
+   swapping framework with network layer routing. The basic idea
+   involves assigning short fixed length labels to  packets at the
+   ingress to an MPLS cloud (based on the concept of forwarding
+   equivalence classes [1,2]). Throughout the interior of the MPLS
+   domain, the labels attached to packets are used to make forwarding
+   decisions  (usually without recourse to the original packet headers).
+
+   A set of powerful constructs to address many critical issues in the
+   emerging differentiated services Internet can be devised from this
+   relatively simple paradigm.  One of the most significant initial
+   applications of MPLS will be in Traffic Engineering. The importance
+   of this application is already well-recognized (see [1,2,3]).
+
+   This manuscript is exclusively focused on the Traffic Engineering
+   applications of MPLS. Specifically, the goal of this document is to
+   highlight the issues and requirements for Traffic Engineering in a
+   large Internet backbone. The expectation is that the MPLS
+   specifications, or implementations derived therefrom, will address
+
+
+
+
+
+Awduche, et al.              Informational                      [Page 2]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   the realization of these objectives.  A description of the basic
+   capabilities and functionality required of an MPLS implementation to
+   accommodate the requirements is also presented.
+
+   It should be noted that even though the focus is on Internet
+   backbones, the capabilities described in this document are equally
+   applicable to Traffic Engineering in enterprise networks. In general,
+   the capabilities can  be applied to any label switched network under
+   a single technical administration in which at least two paths exist
+   between two nodes.
+
+   Some recent manuscripts have focused on the considerations pertaining
+   to Traffic Engineering and Traffic management under MPLS, most
+   notably the works of Li and Rekhter [3], and others.  In [3], an
+   architecture is proposed which employs MPLS and RSVP to provide
+   scalable differentiated services and Traffic Engineering in the
+   Internet.  The present manuscript complements the aforementioned and
+   similar efforts.  It reflects the authors' operational experience in
+   managing a large Internet backbone.
+
+1.1 Terminology
+
+   The reader is assumed to be familiar with the MPLS terminology as
+   defined in [1].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [11].
+
+1.2 Document Organization
+
+   The remainder of this document is organized as follows: Section 2
+   discusses the basic functions of Traffic Engineering in the Internet.
+   Section 3, provides an overview of the traffic Engineering potentials
+   of MPLS. Sections 1 to 3 are essentially background material. Section
+   4 presents an overview of the fundamental requirements for Traffic
+   Engineering over MPLS. Section 5 describes the desirable attributes
+   and characteristics of traffic trunks which are pertinent to Traffic
+   Engineering. Section 6 presents a set of attributes which can be
+   associated with resources to constrain the routability of traffic
+   trunks and LSPs through them. Section 7 advocates the introduction of
+   a "constraint-based routing" framework in MPLS domains.  Finally,
+   Section 8 contains concluding remarks.
+
+
+
+
+
+
+
+
+Awduche, et al.              Informational                      [Page 3]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+2.0 Traffic Engineering
+
+   This section describes the basic functions of Traffic Engineering in
+   an Autonomous System in the contemporary Internet. The limitations of
+   current IGPs with respect to traffic and resource control are
+   highlighted. This section serves as motivation for the requirements
+   on MPLS.
+
+   Traffic Engineering (TE) is concerned with performance optimization
+   of operational networks. In general, it encompasses the application
+   of technology and scientific principles to the measurement, modeling,
+   characterization, and control of Internet traffic, and the
+   application of such knowledge and techniques to achieve specific
+   performance objectives. The aspects of Traffic Engineering that are
+   of interest concerning MPLS are measurement and control.
+
+   A major goal of Internet Traffic Engineering is to facilitate
+   efficient and reliable network operations while simultaneously
+   optimizing network resource utilization and traffic performance.
+   Traffic Engineering has become an indispensable function in many
+   large Autonomous Systems because of the high cost of network assets
+   and the commercial and competitive nature of the Internet. These
+   factors emphasize the need for maximal operational efficiency.
+
+2.1 Traffic Engineering Performance Objectives
+
+   The key performance objectives associated with traffic engineering
+   can be classified as being either:
+
+    1. traffic oriented or
+
+    2. resource oriented.
+
+   Traffic oriented performance objectives include the aspects that
+   enhance the QoS of traffic streams. In a single class, best effort
+   Internet service model, the key traffic oriented performance
+   objectives include: minimization of packet loss, minimization of
+   delay, maximization of throughput, and enforcement of service level
+   agreements. Under a single class best effort Internet service model,
+   minimization of packet loss is one of the most important traffic
+   oriented performance objectives. Statistically bounded traffic
+   oriented performance objectives (such as peak to peak packet delay
+   variation, loss ratio, and maximum packet transfer delay) might
+   become useful in the forthcoming differentiated services Internet.
+
+   Resource oriented performance objectives include the aspects
+   pertaining to the optimization of resource utilization. Efficient
+   management of network resources is the vehicle for the attainment of
+
+
+
+Awduche, et al.              Informational                      [Page 4]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   resource oriented performance objectives. In particular, it is
+   generally desirable to ensure that subsets of network resources do
+   not become over utilized and congested while other subsets along
+   alternate feasible paths remain underutilized. Bandwidth is a crucial
+   resource in contemporary networks.  Therefore, a central function of
+   Traffic Engineering is to efficiently manage bandwidth resources.
+
+   Minimizing congestion is a primary traffic and resource oriented
+   performance objective.  The interest here is on congestion problems
+   that are prolonged rather than on transient congestion resulting from
+   instantaneous bursts.  Congestion typically manifests under two
+   scenarios:
+
+   1. When network resources are insufficient or inadequate to
+      accommodate offered load.
+
+   2. When traffic streams are inefficiently mapped onto available
+      resources; causing subsets of network resources to become
+      over-utilized while others remain underutilized.
+
+   The first type of congestion problem can be addressed by either: (i)
+   expansion of capacity, or (ii) application of classical congestion
+   control techniques, or (iii) both. Classical congestion control
+   techniques attempt to regulate the demand so that the traffic fits
+   onto available resources. Classical techniques for congestion control
+   include: rate limiting, window flow control, router queue management,
+   schedule-based control, and others; (see [8] and the references
+   therein).
+
+   The second type of congestion problems, namely those resulting from
+   inefficient resource allocation, can usually be addressed through
+   Traffic Engineering.
+
+   In general, congestion resulting from inefficient resource allocation
+   can be reduced by adopting load balancing policies. The objective of
+   such strategies is to minimize maximum congestion or alternatively to
+   minimize maximum resource utilization, through efficient resource
+   allocation. When congestion is minimized through efficient resource
+   allocation, packet loss decreases, transit delay decreases, and
+   aggregate throughput increases. Thereby, the perception of network
+   service quality experienced by end users becomes significantly
+   enhanced.
+
+   Clearly, load balancing is an important network performance
+   optimization policy. Nevertheless, the capabilities provided for
+   Traffic Engineering should be flexible enough so that network
+   administrators can implement other policies which take into account
+   the prevailing cost structure and the utility or revenue model.
+
+
+
+Awduche, et al.              Informational                      [Page 5]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+2.2 Traffic and Resource Control
+
+   Performance optimization of operational networks is fundamentally a
+   control problem. In the traffic engineering process model, the
+   Traffic Engineer, or a suitable automaton, acts as the controller in
+   an adaptive feedback control system. This system includes a set of
+   interconnected network elements, a network performance monitoring
+   system, and a set of network configuration management tools. The
+   Traffic Engineer formulates a control policy, observes the state of
+   the network through the monitoring system, characterizes the traffic,
+   and applies control actions to drive the network to a desired state,
+   in accordance with the control policy.  This can be accomplished
+   reactively by taking action in response to the current state of the
+   network, or pro-actively by using forecasting techniques to
+   anticipate future trends and applying action to obviate the predicted
+   undesirable future states.
+
+   Ideally, control actions should involve:
+
+   1. Modification of traffic management parameters,
+
+   2. Modification of parameters associated with routing, and
+
+   3. Modification of attributes and constraints associated with
+      resources.
+
+   The level of manual intervention involved in the traffic engineering
+   process should be minimized whenever possible.  This can be
+   accomplished by automating aspects of the control actions described
+   above, in a distributed and scalable fashion.
+
+2.3 Limitations of Current IGP Control Mechanisms
+
+   This subsection reviews some of the well known limitations of current
+   IGPs with regard to Traffic Engineering.
+
+   The control capabilities offered by existing Internet interior
+   gateway protocols are not adequate for Traffic Engineering.  This
+   makes it difficult to actualize effective policies to address network
+   performance problems.  Indeed, IGPs based on shortest path algorithms
+   contribute significantly to congestion problems in Autonomous Systems
+   within the Internet. SPF algorithms generally optimize based on a
+   simple additive metric. These protocols are topology driven, so
+   bandwidth availability and traffic characteristics are not factors
+   considered in routing decisions. Consequently, congestion frequently
+   occurs when:
+
+
+
+
+
+Awduche, et al.              Informational                      [Page 6]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   1. the shortest paths of multiple traffic streams converge on
+      specific links or router interfaces, or
+
+   2. a given traffic stream is routed through a link or router
+      interface which does not have enough bandwidth to accommodate
+      it.
+
+   These scenarios manifest even when feasible alternate paths with
+   excess capacity exist. It is this aspect of congestion problems (-- a
+   symptom of suboptimal resource allocation) that Traffic Engineering
+   aims to vigorously obviate.  Equal cost path load sharing can be used
+   to address the second cause for congestion listed above with some
+   degree of success, however it is generally not helpful in alleviating
+   congestion due to the first cause listed above and particularly not
+   in large networks with dense topology.
+
+   A popular approach to circumvent the inadequacies of current IGPs is
+   through the use of an overlay model, such as IP over ATM or IP over
+   frame relay. The overlay model extends the design space by enabling
+   arbitrary virtual topologies to be provisioned atop the network's
+   physical topology. The virtual topology is constructed from virtual
+   circuits which appear as physical links to the IGP routing protocols.
+   The overlay model provides additional important services to support
+   traffic and resource control, including: (1) constraint-based routing
+   at the VC level, (2) support for administratively configurable
+   explicit VC paths, (3) path compression, (4) call admission control
+   functions, (5) traffic shaping and traffic policing functions, and
+   (6) survivability of VCs. These capabilities enable the actualization
+   of a variety of Traffic Engineering policies. For example, virtual
+   circuits can easily be rerouted to move traffic from over-utilized
+   resources onto relatively underutilized ones.
+
+   For Traffic Engineering in large dense networks, it is desirable to
+   equip MPLS with a level of functionality at least commensurate with
+   current overlay models. Fortunately, this can be done in a fairly
+   straight forward manner.
+
+3.0  MPLS and Traffic Engineering
+
+   This section provides an overview of the applicability of MPLS to
+   Traffic Engineering. Subsequent sections discuss the set of
+   capabilities required to meet the Traffic Engineering requirements.
+
+   MPLS is strategically significant for Traffic Engineering because it
+   can potentially provide most of the functionality available from the
+   overlay model, in an integrated manner, and at a lower cost than the
+   currently competing alternatives. Equally importantly, MPLS offers
+
+
+
+
+Awduche, et al.              Informational                      [Page 7]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   the possibility to automate aspects of the Traffic Engineering
+   function. This last consideration requires further investigation and
+   is beyond the scope of this manuscript.
+
+   A note on terminology: The concept of MPLS traffic trunks is used
+   extensively in the remainder of this document. According to Li and
+   Rekhter [3], a traffic trunk is an aggregation of traffic flows of
+   the same class which are placed inside a Label Switched Path.
+   Essentially, a traffic trunk is an abstract representation of traffic
+   to which specific characteristics can be associated. It is useful to
+   view traffic trunks as objects that can be routed; that is, the path
+   through which a traffic trunk traverses can be changed. In this
+   respect, traffic trunks are similar to virtual circuits in ATM and
+   Frame Relay networks.  It is important, however, to emphasize that
+   there is a fundamental distinction between a traffic trunk and the
+   path, and indeed the LSP, through which it traverses. An LSP is a
+   specification of the label switched path through which the traffic
+   traverses. In practice, the terms LSP and traffic trunk are often
+   used synonymously. Additional characteristics of traffic trunks as
+   used in this manuscript are summarized in section 5.0.
+
+   The attractiveness of  MPLS for Traffic Engineering can be attributed
+   to the following factors: (1) explicit label switched paths which are
+   not constrained by the destination based forwarding paradigm can be
+   easily created through manual administrative action or through
+   automated action by the underlying protocols, (2) LSPs can
+   potentially be efficiently maintained, (3) traffic trunks can be
+   instantiated and mapped onto LSPs, (4) a set of attributes can be
+   associated with traffic trunks which modulate their behavioral
+   characteristics, (5) a set of attributes can be associated with
+   resources which constrain the placement of LSPs and traffic trunks
+   across them, (6) MPLS allows for both traffic aggregation and
+   disaggregation whereas classical destination only based IP forwarding
+   permits only aggregation, (7) it is relatively easy to integrate a
+   "constraint-based routing" framework with MPLS, (8) a good
+   implementation of MPLS can offer significantly lower overhead than
+   competing alternatives for Traffic Engineering.
+
+   Additionally, through explicit label switched paths, MPLS permits a
+   quasi circuit switching capability to be superimposed on the current
+   Internet routing model.  Many of the existing proposals for Traffic
+   Engineering over MPLS focus only on the potential to create explicit
+   LSPs. Although this capability is fundamental for Traffic
+   Engineering, it is not really sufficient.  Additional augmentations
+   are required to foster the actualization of policies leading to
+   performance optimization of large operational networks. Some of the
+   necessary augmentations are described in this manuscript.
+
+
+
+
+Awduche, et al.              Informational                      [Page 8]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+3.1 Induced MPLS Graph
+
+   This subsection introduces the concept of an "induced MPLS graph"
+   which is central to Traffic Engineering in MPLS domains. An induced
+   MPLS graph is analogous to a virtual topology in an overlay model. It
+   is logically mapped onto the physical network through the selection
+   of LSPs for traffic trunks.
+
+   An induced MPLS graph consists of a set of LSRs which comprise the
+   nodes of the graph and a set of LSPs which provide logical point to
+   point connectivity between the LSRs, and hence serve as the links of
+   the induced graph. it may be possible to construct hierarchical
+   induced MPLS graphs based on the concept of label stacks (see [1]).
+
+   Induced MPLS graphs are important because the basic problem of
+   bandwidth management in an MPLS domain is the issue of how to
+   efficiently map an induced MPLS graph onto the physical network
+   topology.  The induced MPLS graph abstraction is formalized below.
+
+   Let G = (V, E, c) be a capacitated graph depicting the physical
+   topology of the network. Here, V is the set of nodes in the network
+   and E is the set of links; that is, for v and w in V, the object
+   (v,w) is in E if v and w are directly connected under G. The
+   parameter "c" is a set of capacity and other constraints associated
+   with E and V. We will refer to G as the "base" network topology.
+
+   Let H = (U, F, d) be  the induced MPLS graph, where U is a subset of
+   V representing the set of LSRs in the network, or more precisely the
+   set of LSRs that are the endpoints of at least one LSP. Here, F is
+   the set of LSPs, so that for x and y in U, the object (x, y) is in F
+   if there is an LSP with x and y as endpoints. The parameter "d" is
+   the set of demands and restrictions associated with F. Evidently, H
+   is a directed graph. It can be seen that H depends on the
+   transitivity characteristics of G.
+
+3.2 The Fundamental Problem of Traffic Engineering Over MPLS
+
+   There are basically three fundamental problems that relate to Traffic
+   Engineering over MPLS.
+
+   - The first problem concerns how to map packets onto forwarding
+     equivalence classes.
+
+   - The second problem concerns how to map forwarding equivalence
+     classes onto traffic trunks.
+
+   - The third problem concerns how to map traffic trunks onto the
+     physical network topology through label switched paths.
+
+
+
+Awduche, et al.              Informational                      [Page 9]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   This document is not focusing on the first two problems listed.
+   (even-though they are quite important). Instead, the remainder of
+   this manuscript will focus on the capabilities that permit the third
+   mapping function to be performed in a manner resulting in efficient
+   and reliable network operations. This is really the problem of
+   mapping an induced MPLS graph (H) onto the "base" network topology
+   (G).
+
+4.0 Augmented  Capabilities for Traffic Engineering Over MPLS
+
+   The previous sections reviewed the basic functions of Traffic
+   Engineering in the contemporary Internet. The applicability of MPLS
+   to that activity was also discussed. The remaining sections of this
+   manuscript describe the functional capabilities required to fully
+   support Traffic Engineering over MPLS in large networks.
+
+   The proposed capabilities consist of:
+
+   1. A set of attributes associated with traffic trunks which
+      collectively specify their behavioral characteristics.
+
+   2. A set of attributes associated with resources which constrain
+      the placement of traffic trunks through them. These can also be
+      viewed as topology attribute constraints.
+
+   3. A "constraint-based routing" framework which is used to select
+      paths for traffic trunks subject to constraints imposed by items
+      1) and 2) above. The constraint-based routing framework does not
+      have to be part of MPLS. However, the two need to be tightly
+      integrated together.
+
+   The attributes associated with traffic trunks and resources, as well
+   as parameters associated with routing, collectively represent the
+   control variables which can be modified either through administrative
+   action or through automated agents to drive the network to a desired
+   state.
+
+   In an operational network, it is highly desirable that these
+   attributes can be dynamically modified online by an operator without
+   adversely disrupting network operations.
+
+5.0 Traffic Trunk Attributes and Characteristics
+
+   This section describes the desirable attributes which can be
+   associated with traffic trunks to influence their behavioral
+   characteristics.
+
+
+
+
+
+Awduche, et al.              Informational                     [Page 10]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   First, the basic properties of traffic trunks (as used in this
+   manuscript) are summarized below:
+
+    - A traffic trunk is an *aggregate* of traffic flows belonging
+      to the same class. In some contexts, it may be desirable to
+      relax this definition and allow traffic trunks to include
+      multi-class traffic aggregates.
+
+    - In a single class service model, such as the current Internet,
+      a traffic trunk could encapsulate all of the traffic between an
+      ingress LSR and an egress LSR, or subsets thereof.
+
+    - Traffic trunks are routable objects (similar to ATM VCs).
+
+    - A traffic trunk is distinct from the LSP through which it
+      traverses. In operational contexts, a traffic trunk can be
+      moved from one path onto another.
+
+    - A traffic trunk is unidirectional.
+
+   In practice, a traffic trunk can be characterized by its ingress and
+   egress LSRs, the forwarding equivalence class which is mapped onto
+   it, and a set of attributes which determine its behavioral
+   characteristics.
+
+   Two basic issues are of particular significance: (1) parameterization
+   of traffic trunks and (2) path placement and maintenance rules for
+   traffic trunks.
+
+5.1 Bidirectional Traffic Trunks
+
+   Although traffic trunks are conceptually unidirectional, in many
+   practical contexts, it is useful to  simultaneously instantiate two
+   traffic trunks with the same endpoints, but which carry packets in
+   opposite directions. The two traffic trunks are logically coupled
+   together.  One trunk, called the forward trunk, carries traffic from
+   an originating node to a destination node. The other trunk, called
+   the backward trunk, carries traffic from the destination node to the
+   originating node. We refer to the amalgamation of two such traffic
+   trunks as one bidirectional traffic trunk (BTT) if the following two
+   conditions hold:
+
+   - Both traffic trunks are instantiated through an atomic action at
+     one LSR, called the originator node, or through an atomic action
+     at a network management station.
+
+   - Neither of the composite traffic trunks can exist without the
+     other. That is, both are instantiated and destroyed together.
+
+
+
+Awduche, et al.              Informational                     [Page 11]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   The topological properties of BTTs should also be considered. A BTT
+   can be topologically symmetric or topologically asymmetric.  A BTT is
+   said to be "topologically symmetric" if its constituent traffic
+   trunks are routed through the same physical path, even though they
+   operate in opposite directions. If, however, the component traffic
+   trunks are routed through different physical paths, then the BTT is
+   said to be "topologically asymmetric."
+
+   It should be noted that bidirectional traffic trunks are merely an
+   administrative convenience. In practice, most traffic engineering
+   functions can be implemented using only unidirectional traffic
+   trunks.
+
+5.2 Basic Operations on Traffic Trunks
+
+   The basic operations on traffic trunks significant to Traffic
+   Engineering purposes are summarized below.
+
+   - Establish: To create an instance of a traffic trunk.
+
+   - Activate: To cause a traffic trunk to start passing traffic.
+     The establishment and activation of a traffic trunk are
+     logically separate events. They may, however, be implemented
+     or invoked as one atomic action.
+
+   - Deactivate: To cause a traffic trunk to stop passing traffic.
+
+   - Modify Attributes: To cause the attributes of a traffic trunk
+     to be modified.
+
+   - Reroute: To cause a traffic trunk to change its route. This
+     can be done through administrative action or automatically
+     by the underlying protocols.
+
+   - Destroy: To remove an instance of a traffic trunk from the
+     network and reclaim all resources allocated to it. Such
+     resources include label space and possibly available bandwidth.
+
+   The above are considered the basic operations on traffic trunks.
+   Additional operations are also possible such as policing and traffic
+   shaping.
+
+5.3 Accounting and Performance Monitoring
+
+   Accounting and performance monitoring capabilities are very important
+   to the billing and traffic characterization functions.  Performance
+   statistics obtained from accounting and performance monitoring
+
+
+
+
+Awduche, et al.              Informational                     [Page 12]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   systems can be used for traffic characterization, performance
+   optimization, and capacity planning within the Traffic Engineering
+   realm..
+
+   The capability to obtain statistics at the traffic trunk level is so
+   important that it should be considered an essential requirement for
+   Traffic Engineering over MPLS.
+
+5.4 Basic Traffic Engineering Attributes of Traffic Trunks
+
+   An attribute of a traffic trunk is a parameter assigned to it which
+   influences its behavioral characteristics.
+
+   Attributes can be explicitly assigned to traffic trunks through
+   administration action or they can be implicitly assigned by the
+   underlying protocols when packets are classified and mapped into
+   equivalence classes at the ingress to an MPLS domain. Regardless of
+   how the attributes were originally assigned, for Traffic Engineering
+   purposes, it should be possible to administratively modify such
+   attributes.
+
+   The basic attributes of traffic trunks  particularly significant for
+   Traffic Engineering are itemized below.
+
+   - Traffic parameter attributes
+
+   - Generic Path selection and maintenance attributes
+
+   - Priority attribute
+
+   - Preemption attribute
+
+   - Resilience attribute
+
+   - Policing  attribute
+
+   The combination of traffic parameters and policing attributes is
+   analogous to usage parameter control in ATM networks. Most of the
+   attributes listed above have analogs in well established
+   technologies.  Consequently, it should be relatively straight forward
+   to map the traffic trunk attributes onto many existing switching and
+   routing architectures.
+
+   Priority and preemption can be regarded as relational attributes
+   because they express certain binary relations between traffic trunks.
+   Conceptually, these binary relations determine the manner in which
+   traffic trunks interact with each other as they compete for network
+   resources during path establishment and path maintenance.
+
+
+
+Awduche, et al.              Informational                     [Page 13]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+5.5 Traffic parameter attributes
+
+   Traffic parameters can be used to capture the characteristics of the
+   traffic streams (or more precisely the forwarding equivalence class)
+   to be transported through the traffic trunk. Such characteristics may
+   include peak rates, average rates, permissible burst size, etc.  From
+   a traffic engineering perspective, the traffic parameters are
+   significant because they indicate the resource requirements of the
+   traffic trunk. This is useful for resource allocation and congestion
+   avoidance through anticipatory policies.
+
+   For the purpose of bandwidth allocation, a single canonical value of
+   bandwidth requirements can be computed from a traffic trunk's traffic
+   parameters.  Techniques for performing these computations are well
+   known. One example of this is the theory of effective bandwidth.
+
+5.6 Generic Path Selection and Management Attributes
+
+   Generic path selection and management attributes define the rules for
+   selecting the route taken by a traffic trunk as well as the rules for
+   maintenance of paths that are already established.
+
+   Paths can be computed automatically by the underlying routing
+   protocols or they can be defined administratively by a network
+   operator. If there are no resource requirements or restrictions
+   associated with a traffic trunk, then a topology driven protocol can
+   be used to select its path. However, if resource requirements or
+   policy restrictions exist, then a constraint-based routing scheme
+   should be used for path selection.
+
+   In Section 7, a constraint-based routing framework which can
+   automatically compute paths subject to a set of constraints is
+   described.  Issues pertaining to explicit paths instantiated through
+   administrative action are discussed in Section 5.6.1 below.
+
+   Path management concerns all aspects pertaining to the maintenance of
+   paths traversed by traffic trunks.  In some operational contexts, it
+   is desirable that an MPLS implementation can dynamically reconfigure
+   itself, to adapt to some notion of change in "system state."
+   Adaptivity and resilience are aspects of dynamic path management.
+
+   To guide the path selection and management process, a set of
+   attributes are required. The basic attributes and behavioral
+   characteristics associated with traffic trunk path selection and
+   management are described in the remainder of this sub-section.
+
+
+
+
+
+
+Awduche, et al.              Informational                     [Page 14]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+5.6.1 Administratively Specified Explicit Paths
+
+   An administratively specified explicit path for a traffic trunk is
+   one which is configured through operator action. An administratively
+   specified path can be completely specified or partially specified. A
+   path is completely specified if all of the required hops between the
+   endpoints are indicated. A path is partially specified if only a
+   subset of intermediate hops are indicated. In this case, the
+   underlying protocols are required to complete the path. Due to
+   operator errors, an administratively specified path can be
+   inconsistent or illogical. The underlying protocols should be able to
+   detect such inconsistencies and provide appropriate feedback.
+
+   A "path preference rule" attribute should be associated with
+   administratively specified explicit paths.  A path preference rule
+   attribute is a binary variable which  indicates whether the
+   administratively configured explicit path is "mandatory" or "non-
+   mandatory."
+
+   If an administratively specified explicit path is selected with a
+   "mandatory attribute, then that path (and only that path) must be
+   used. If a mandatory path is topological infeasible (e.g. the two
+   endpoints are topologically partitioned), or if the path cannot be
+   instantiated because the available resources are inadequate, then the
+   path setup process fails. In other words, if a path is specified as
+   mandatory, then an alternate path cannot be used regardless of
+   prevailing circumstance.  A mandatory path which is successfully
+   instantiated is also implicitly pinned. Once the path is instantiated
+   it cannot be changed except through deletion and instantiation of a
+   new path.
+
+   However, if an administratively specified explicit path is selected
+   with a "non-mandatory" preference rule attribute value, then the path
+   should be used if feasible.  Otherwise, an alternate path can be
+   chosen instead by the underlying protocols.
+
+5.6.2 Hierarchy of Preference Rules For Multi-Paths
+
+   In some practical contexts, it can be useful to have the ability to
+   administratively specify a set of candidate explicit paths for a
+   given traffic trunk and define a hierarchy of preference relations on
+   the paths. During path establishment, the preference rules are
+   applied to select a suitable path from the candidate list. Also,
+   under failure scenarios the preference rules are applied to select an
+   alternate path from the candidate list.
+
+
+
+
+
+
+Awduche, et al.              Informational                     [Page 15]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+5.6.3 Resource Class Affinity Attributes
+
+   Resource class affinity attributes associated with a traffic trunk
+   can be used to specify the class of resources (see Section 6) which
+   are to be explicitly included or excluded from the path of the
+   traffic trunk. These are policy attributes which can be used to
+   impose additional constraints on the path traversed by a given
+   traffic trunk.  Resource class affinity attributes for a traffic can
+   be specified as a sequence of tuples:
+
+    <resource-class, affinity>; <resource-class, affinity>; ..
+
+   The resource-class parameter identifies a resource class for which an
+   affinity relationship is defined with respect to the traffic trunk.
+   The affinity parameter indicates the affinity relationship; that is,
+   whether members of the resource class are to be included or excluded
+   from the path of the traffic trunk. Specifically, the affinity
+   parameter may be a binary variable which takes one of the following
+   values: (1) explicit inclusion, and (2) explicit exclusion.
+
+   If the affinity attribute is a binary variable, it may be possible to
+   use Boolean expressions to specify the resource class affinities
+   associated with a given traffic trunk.
+
+   If no resource class affinity attributes are specified, then a "don't
+   care" affinity relationship is assumed to hold between the traffic
+   trunk and all resources. That is, there is no requirement to
+   explicitly include or exclude any resources from the traffic trunk's
+   path. This should be the default in practice.
+
+   Resource class affinity attributes are very useful and powerful
+   constructs because they can be used to implement a variety of
+   policies. For example, they can be used to contain certain traffic
+   trunks within specific topological regions of the network.
+
+   A "constraint-based routing" framework (see section 7.0) can be used
+   to compute an explicit path for a traffic trunk subject to resource
+   class affinity constraints in the following manner:
+
+   1. For explicit inclusion, prune all resources not belonging
+      to the specified classes prior to performing path computation.
+
+   2. For explicit exclusion, prune all resources  belonging to the
+      specified classes before performing path placement computations.
+
+
+
+
+
+
+
+Awduche, et al.              Informational                     [Page 16]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+5.6.4 Adaptivity Attribute
+
+   Network characteristics and state change over time. For example, new
+   resources become available, failed resources become reactivated, and
+   allocated resources become deallocated. In general, sometimes more
+   efficient paths become available.  Therefore, from a Traffic
+   Engineering perspective, it is necessary to have administrative
+   control parameters that can be used to specify how traffic trunks
+   respond to this dynamism. In some scenarios, it might be desirable to
+   dynamically change the paths of certain traffic trunks in response to
+   changes in network state. This process is called re-optimization.  In
+   other scenarios, re-optimization might be very undesirable.
+
+   An Adaptivity attribute is a part of the path maintenance parameters
+   associated with traffic trunks. The adaptivity attribute associated
+   with a traffic trunk indicates whether the trunk is subject to re-
+   optimization.  That is, an adaptivity attribute is a binary variable
+   which takes one of the following values: (1) permit re-optimization
+   and (2) disable re-optimization.
+
+   If re-optimization is enabled, then a traffic trunk can be rerouted
+   through different paths by the underlying protocols in response to
+   changes in network state (primarily changes in resource
+   availability). Conversely, if re-optimization is disabled, then the
+   traffic trunk is "pinned" to its established path and cannot be
+   rerouted in response to changes in network state.
+
+   Stability is a major concern when re-optimization is permitted. To
+   promote stability, an MPLS implementation should not be too reactive
+   to the evolutionary dynamics of the network. At the same time, it
+   must adapt fast enough so that optimal use can be made of network
+   assets. This implies that the frequency of re-optimization should be
+   administratively configurable to allow for tuning.
+
+   It is to be noted that re-optimization is distinct from resilience. A
+   different attribute is used to specify the resilience characteristics
+   of a traffic trunk (see section 5.9).  In practice, it would seem
+   reasonable to expect traffic trunks subject to re-optimization to be
+   implicitly resilient to failures along their paths. However, a
+   traffic trunk which is not subject to re-optimization and whose path
+   is not administratively specified with a "mandatory" attribute can
+   also be required to be resilient to link and node failures along its
+   established path
+
+   Formally, it can be stated that adaptivity to state evolution through
+   re-optimization implies resilience to failures, whereas resilience to
+   failures does not imply general adaptivity through re-optimization to
+   state changes.
+
+
+
+Awduche, et al.              Informational                     [Page 17]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+5.6.5 Load Distribution Across Parallel Traffic Trunks
+
+   Load distribution across multiple parallel traffic trunks between two
+   nodes is an important consideration.  In many practical contexts, the
+   aggregate traffic between two nodes may be such that no single link
+   (hence no single path) can carry the load. However, the aggregate
+   flow might be less than the maximum permissible flow across a "min-
+   cut" that partitions the two nodes. In this case, the only feasible
+   solution is to appropriately divide the aggregate traffic into sub-
+   streams and route the sub-streams through multiple paths between the
+   two nodes.
+
+   In an MPLS domain, this problem can be addressed by instantiating
+   multiple traffic trunks between the two nodes, such that each traffic
+   trunk carries a proportion of the aggregate traffic. Therefore, a
+   flexible means of load assignment to multiple parallel traffic trunks
+   carrying traffic between a pair of nodes is required.
+
+   Specifically, from an operational perspective, in situations where
+   parallel traffic trunks are warranted,  it would be useful to have
+   some attribute that can be used to indicate the relative proportion
+   of traffic to be carried by each traffic trunk. The underlying
+   protocols will then map the load onto the traffic trunks according to
+   the specified proportions. It is also, generally desirable to
+   maintain packet ordering between packets belong to the same micro-
+   flow (same source address, destination address, and port number).
+
+5.7 Priority attribute
+
+   The priority attribute defines the relative importance of traffic
+   trunks.  If a constraint-based routing framework is used with MPLS,
+   then priorities become very important because they can be used to
+   determine the order in which path selection is done for traffic
+   trunks at connection establishment and under fault scenarios.
+
+   Priorities are also important in implementations  permitting
+   preemption because they can be used to impose a partial order on the
+   set of traffic trunks according to which preemptive policies can be
+   actualized.
+
+5.8 Preemption attribute
+
+   The preemption attribute determines whether a traffic trunk can
+   preempt another traffic trunk from a given path, and whether another
+   traffic trunk can preempt a specific traffic trunk.  Preemption is
+   useful for both traffic oriented and resource oriented performance
+
+
+
+
+
+Awduche, et al.              Informational                     [Page 18]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   objectives. Preemption can used to assure that high priority traffic
+   trunks can always be routed through relatively favorable paths within
+   a differentiated services environment.
+
+   Preemption can also be used to implement various prioritized
+   restoration policies following fault events.
+
+   The preemption attribute can be used to specify four preempt modes
+   for a traffic trunk: (1) preemptor enabled, (2) non-preemptor, (3)
+   preemptable, and (4) non-preemptable. A preemptor enabled traffic
+   trunk can preempt lower priority traffic trunks designated as
+   preemptable. A traffic specified as non-preemptable cannot be
+   preempted by any other trunks, regardless of relative priorities. A
+   traffic trunk designated as preemptable can be preempted by higher
+   priority trunks which are preemptor enabled.
+
+   It is trivial to see that some of the preempt modes are mutually
+   exclusive. Using the numbering scheme depicted above, the feasible
+   preempt mode combinations for a given traffic trunk are as follows:
+   (1, 3), (1, 4), (2, 3), and (2, 4). The (2, 4) combination should be
+   the default.
+
+   A traffic trunk, say "A", can preempt another traffic trunk, say "B",
+   only if *all* of the following five conditions hold: (i) "A" has a
+   relatively higher priority than "B", (ii) "A" contends for a resource
+   utilized by "B", (iii) the resource cannot concurrently accommodate
+   "A" and "B" based on certain decision criteria, (iv) "A" is preemptor
+   enabled, and (v) "B" is preemptable.
+
+   Preemption is not considered a mandatory attribute under the current
+   best effort Internet service model although it is useful. However, in
+   a differentiated services scenario, the need for preemption becomes
+   more compelling. Moreover, in the emerging optical internetworking
+   architectures, where some protection and restoration functions may be
+   migrated from the optical layer to data network elements (such as
+   gigabit and terabit label switching routers) to reduce costs,
+   preemptive strategies can be used to reduce the restoration time for
+   high priority traffic trunks under fault conditions.
+
+5.9 Resilience Attribute
+
+   The resilience attribute determines the behavior of a traffic trunk
+   under fault conditions. That is, when a fault occurs along the path
+   through which the traffic trunk traverses. The following basic
+   problems need to be addressed under such circumstances: (1) fault
+   detection, (2) failure notification, (3) recovery and service
+   restoration. Obviously, an MPLS implementation will have to
+   incorporate mechanisms to address these issues.
+
+
+
+Awduche, et al.              Informational                     [Page 19]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   Many recovery policies can be specified for traffic trunks whose
+   established paths are impacted by faults. The following are examples
+   of feasible schemes:
+
+   1. Do not reroute the traffic trunk. For example, a survivability
+      scheme may already be in place, provisioned through an
+      alternate mechanism, which guarantees service continuity
+      under failure scenarios without the need to reroute traffic
+      trunks. An example of such an alternate scheme (certainly
+      many others exist), is a situation whereby multiple parallel
+      label switched paths are provisioned between two nodes, and
+      function in a manner such that failure of one LSP causes the
+      traffic trunk placed on it to be mapped onto the remaining LSPs
+      according to some well defined policy.
+
+   2. Reroute through a feasible path with enough resources. If none
+      exists, then do not reroute.
+
+   3. Reroute through any available path regardless of resource
+      constraints.
+
+   4. Many other schemes are possible including some which might be
+      combinations of the above.
+
+   A "basic" resilience attribute indicates the recovery procedure to be
+   applied to traffic trunks whose paths are impacted by faults.
+   Specifically, a "basic" resilience attribute is a binary variable
+   which determines whether the target traffic trunk is to be rerouted
+   when segments of its path fail. "Extended" resilience attributes can
+   be used to specify detailed actions to be taken under fault
+   scenarios.  For example, an extended resilience attribute might
+   specify a set of alternate paths to use under fault conditions, as
+   well as the rules that govern the relative preference of each
+   specified path.
+
+   Resilience attributes mandate close interaction between MPLS and
+   routing.
+
+5.10 Policing attribute
+
+   The policing attribute determines the actions that should be taken by
+   the underlying protocols when a traffic trunk becomes non-compliant.
+   That is, when a traffic trunk exceeds its contract as specified in
+   the traffic parameters.  Generally, policing attributes can indicate
+   whether a non-conformant traffic trunk is to be rate limited, tagged,
+   or simply forwarded without any policing action.  If policing is
+   used, then adaptations of established algorithms such as the ATM
+   Forum's GCRA [11] can be used to perform this function.
+
+
+
+Awduche, et al.              Informational                     [Page 20]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   Policing is necessary in many operational scenarios, but is quite
+   undesirable in some others. In general, it is usually desirable to
+   police at the ingress to a network (to enforce compliance with
+   service level agreements) and to minimize policing within the core,
+   except when capacity constraints dictate otherwise.
+
+   Therefore, from a Traffic Engineering perspective, it is necessary to
+   be able to administratively enable or disable traffic policing for
+   each traffic trunk.
+
+6.0 Resource Attributes
+
+   Resource attributes are part of the topology state parameters, which
+   are used to constrain the routing of traffic trunks through specific
+   resources.
+
+6.1 Maximum Allocation Multiplier
+
+   The maximum allocation multiplier (MAM) of a resource is an
+   administratively configurable attribute which determines the
+   proportion of the resource that is available for allocation to
+   traffic trunks.  This attribute is mostly applicable to link
+   bandwidth. However,  it can also be applied to buffer resources on
+   LSRs. The concept of MAM is analogous to the concepts of subscription
+   and booking factors in frame relay and ATM networks.
+
+   The values of the MAM can be chosen so that a resource can be under-
+   allocated or over-allocated. A resource is said  to be under-
+   allocated if the aggregate demands of all traffic trunks (as
+   expressed in the trunk traffic parameters) that can be allocated to
+   it are always less than the capacity of the resource. A resource is
+   said to be over-allocated if the aggregate demands of all traffic
+   trunks allocated to it can exceed the capacity of the resource.
+
+   Under-allocation can be used to bound the utilization of resources.
+   However,the situation under MPLS is more complex than in circuit
+   switched schemes because under MPLS, some flows can be routed via
+   conventional hop by hop protocols (also via explicit paths) without
+   consideration for resource constraints.
+
+   Over-allocation can be used to take advantage of the statistical
+   characteristics of traffic in order to implement more efficient
+   resource allocation policies. In particular, over-allocation can be
+   used in situations where the peak demands of traffic trunks do not
+   coincide in time.
+
+
+
+
+
+
+Awduche, et al.              Informational                     [Page 21]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+6.2 Resource Class Attribute
+
+   Resource class attributes are administratively assigned parameters
+   which express some notion of "class" for resources. Resource class
+   attributes can be viewed as "colors" assigned to resources such that
+   the set of resources with the same "color" conceptually belong to the
+   same class. Resource class attributes can be used to implement a
+   variety of policies. The key resources of interest here are links.
+   When applied to links, the resource class attribute effectively
+   becomes  an aspect of the "link state" parameters.
+
+   The concept of resource class attributes is a powerful abstraction.
+   From a Traffic Engineering perspective, it can be used to implement
+   many policies with regard to both traffic and resource oriented
+   performance optimization. Specifically, resource class attributes can
+   be used to:
+
+   1. Apply uniform policies to a set of resources that do not need
+      to be in the same topological region.
+
+   2. Specify the relative preference of sets of resources for
+      path placement of traffic trunks.
+
+   3. Explicitly restrict the placement of traffic trunks
+      to  specific subsets of resources.
+
+   4. Implement generalized inclusion / exclusion policies.
+
+   5. Enforce traffic locality containment policies. That is,
+      policies    that seek to contain local traffic within
+      specific topological regions of the network.
+
+   Additionally, resource class attributes can be used for
+   identification purposes.
+
+   In general, a resource can be assigned more than one resource class
+   attribute. For example, all of the OC-48 links in a given network may
+   be assigned a distinguished resource class attribute. The subsets of
+   OC-48 links which exist with a given abstraction domain of the
+   network may be assigned additional resource class attributes in order
+   to implement specific containment policies, or to architect the
+   network in a certain manner.
+
+7.0 Constraint-Based Routing
+
+   This section discusses the issues pertaining to constraint-based
+   routing in MPLS domains. In contemporary terminology, constraint-
+   based routing is often referred to as "QoS Routing" see [5,6,7,10].
+
+
+
+Awduche, et al.              Informational                     [Page 22]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   This document uses the term "constraint-based routing" however,
+   because it better captures the functionality envisioned, which
+   generally encompasses QoS routing as a subset.
+
+   constraint-based routing enables a demand driven, resource
+   reservation aware, routing paradigm to co-exist with current topology
+   driven hop by hop Internet interior gateway protocols.
+
+   A constraint-based routing framework uses the following as input:
+
+    - The attributes associated with traffic trunks.
+
+    - The attributes associated with resources.
+
+    - Other topology state information.
+
+   Based on this information, a constraint-based routing process on each
+   node automatically computes explicit routes for each traffic trunk
+   originating from the node. In this case, an explicit route for each
+   traffic trunk is a specification of a label switched path that
+   satisfies the demand requirements expressed in the trunk's
+   attributes, subject to constraints imposed by resource availability,
+   administrative policy, and other topology state information.
+
+   A constraint-based routing framework can greatly reduce the level of
+   manual configuration and intervention required to actualize Traffic
+   Engineering policies.
+
+   In practice, the Traffic Engineer, an operator, or even an automaton
+   will specify the endpoints of a traffic trunk and assign a set of
+   attributes to the trunk which encapsulate the performance
+   expectations and behavioral characteristics of the trunk. The
+   constraint-based routing framework is then expected to find a
+   feasible path to satisfy the expectations.  If necessary, the Traffic
+   Engineer or a traffic engineering support system can then use
+   administratively configured explicit routes to perform fine grained
+   optimization.
+
+7.1 Basic Features of Constraint-Based Routing
+
+   A constraint-based routing framework should at least have the
+   capability to automatically obtain a basic feasible solution to the
+   traffic trunk path placement problem.
+
+   In general, the constraint-based routing problem is known to be
+   intractable for most realistic constraints. However, in practice, a
+   very simple well known heuristic (see e.g. [9]) can be used to find a
+   feasible path if one exists:
+
+
+
+Awduche, et al.              Informational                     [Page 23]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+    - First prune resources that do not satisfy the requirements of
+      the traffic trunk attributes.
+
+    - Next, run a shortest path algorithm on the residual graph.
+
+   Clearly, if a feasible path exists for a single traffic trunk, then
+   the above simple procedure will find it. Additional rules can be
+   specified to break ties and perform further optimizations.  In
+   general, ties should be broken so that congestion is minimized.  When
+   multiple traffic trunks are to be routed, however, it can be shown
+   that the above algorithm may not always find a mapping, even when a
+   feasible mapping exists.
+
+7.2 Implementation Considerations
+
+   Many commercial implementations of frame relay and ATM switches
+   already support some notion of constraint-based routing. For such
+   devices or for the novel MPLS centric contraptions devised therefrom,
+   it should be relatively easy to extend the current constraint-based
+   routing implementations to accommodate the peculiar requirements of
+   MPLS.
+
+   For routers that use topology driven hop by hop IGPs, constraint-
+   based routing can be incorporated in at least one of two ways:
+
+   1. By extending the current IGP protocols such as OSPF and IS-IS to
+      support constraint-based routing. Effort is already underway to
+      provide such extensions to OSPF (see [5,7]).
+
+   2. By adding a constraint-based routing process to each router which
+      can co-exist with current IGPs. This scenario is depicted
+      in Figure 1.
+
+         ------------------------------------------
+        |          Management Interface            |
+         ------------------------------------------
+            |                 |                 |
+     ------------     ------------------    --------------
+    |    MPLS    |<->| Constraint-Based |  | Conventional |
+    |            |   | Routing Process  |  | IGP Process  |
+     ------------     ------------------    --------------
+                           |                  |
+             -----------------------    --------------
+            | Resource  Attribute   |  | Link State   |
+            | Availability Database |  | Database     |
+             -----------------------    --------------
+
+    Figure 1. Constraint-Based Routing Process on Layer 3 LSR
+
+
+
+Awduche, et al.              Informational                     [Page 24]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+   There are many important details associated with implementing
+   constraint-based routing on Layer 3 devices which we do not discuss
+   here. These include the following:
+
+   - Mechanisms for exchange of topology state information
+     (resource availability information, link state information,
+     resource attribute information) between constraint-based
+     routing processes.
+
+   - Mechanisms for maintenance of topology state information.
+
+   - Interaction between constraint-based routing processes and
+     conventional IGP processes.
+
+   - Mechanisms to accommodate the adaptivity requirements of
+     traffic trunks.
+
+   - Mechanisms to accommodate the resilience and survivability
+     requirements of traffic trunks.
+
+   In summary, constraint-based routing assists in performance
+   optimization of operational networks by automatically finding
+   feasible paths that satisfy a set of constraints for traffic trunks.
+   It can drastically reduce the amount of administrative explicit path
+   configuration and manual intervention required to achieve Traffic
+   Engineering objectives.
+
+8.0 Conclusion
+
+   This manuscript presented a set of requirements for Traffic
+   Engineering over MPLS. Many capabilities were described aimed at
+   enhancing the applicability of MPLS to Traffic Engineering in the
+   Internet.
+
+   It should be noted that some of the issues described here can be
+   addressed by incorporating a minimal set of building blocks into
+   MPLS, and then using a network management superstructure to extend
+   the functionality in order to realize the requirements. Also, the
+   constraint-based routing framework does not have to be part of the
+   core MPLS specifications. However, MPLS does require some interaction
+   with a constraint-based routing framework in order to meet the
+   requirements.
+
+
+
+
+
+
+
+
+
+Awduche, et al.              Informational                     [Page 25]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+9.0 Security Considerations
+
+   This document does not introduce new security issues beyond those
+   inherent in MPLS and may use the same mechanisms proposed for this
+   technology. It is, however, specifically important that manipulation
+   of administratively configurable parameters be executed in a secure
+   manner by authorized entities.
+
+10.0 References
+
+   [1]  Rosen, E., Viswanathan, A. and R. Callon, "A Proposed
+        Architecture for MPLS", Work in Progress.
+
+   [2]  Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G.
+        and A. Viswanathan, "A Framework for Multiprotocol Label
+        Switching", Work in Progress.
+
+   [3]  Li, T. and Y. Rekhter, "Provider Architecture for Differentiated
+        Services and Traffic Engineering (PASTE)", RFC 2430, October
+        1998.
+
+   [4]  Rekhter, Y., Davie, B., Katz, D., Rosen, E. and  G. Swallow,
+        "Cisco Systems' Tag Switching Architecture - Overview", RFC
+        2105, February 1997.
+
+   [5]  Zhang, Z., Sanchez, C., Salkewicz, B. and E. Crawley "Quality of
+        Service Extensions to OSPF", Work in Progress.
+
+   [6]  Crawley, E., Nair, F., Rajagopalan, B. and H. Sandick, "A
+        Framework for QoS Based Routing in the Internet", RFC 2386,
+        August 1998.
+
+   [7]  Guerin, R., Kamat, S., Orda, A., Przygienda, T. and D. Williams,
+        "QoS Routing Mechanisms and OSPF Extensions", RFC 2676, August
+        1999.
+
+   [8]  C. Yang and A. Reddy, "A Taxonomy for Congestion Control
+        Algorithms in Packet Switching Networks," IEEE Network Magazine,
+        Volume 9, Number 5, July/August 1995.
+
+   [9]  W. Lee, M. Hluchyi, and P. Humblet, "Routing Subject to Quality
+        of Service Constraints in Integrated Communication Networks,"
+        IEEE Network, July 1995, pp 46-55.
+
+   [10] ATM Forum, "Traffic Management Specification: Version 4.0" April
+        1996.
+
+
+
+
+
+Awduche, et al.              Informational                     [Page 26]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+11.0 Acknowledgments
+
+   The authors would like to thank Yakov Rekhter for his review of an
+   earlier draft of this document. The authors would also like to thank
+   Louis Mamakos and Bill Barns for their helpful suggestions, and
+   Curtis Villamizar for providing some useful feedback.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Awduche, et al.              Informational                     [Page 27]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+12.0 Authors' Addresses
+
+   Daniel O. Awduche
+   UUNET (MCI Worldcom)
+   3060 Williams Drive
+   Fairfax, VA 22031
+
+   Phone: +1 703-208-5277
+   EMail: awduche@uu.net
+
+
+   Joe Malcolm
+   UUNET  (MCI Worldcom)
+   3060 Williams Drive
+   Fairfax, VA 22031
+
+   Phone: +1 703-206-5895
+   EMail: jmalcolm@uu.net
+
+
+   Johnson Agogbua
+   UUNET  (MCI Worldcom)
+   3060 Williams Drive
+   Fairfax, VA 22031
+
+   Phone: +1 703-206-5794
+   EMail: ja@uu.net
+
+
+   Mike O'Dell
+   UUNET  (MCI Worldcom)
+   3060 Williams Drive
+   Fairfax, VA 22031
+
+   Phone: +1 703-206-5890
+   EMail: mo@uu.net
+
+
+   Jim McManus
+   UUNET  (MCI Worldcom)
+   3060 Williams Drive
+   Fairfax, VA 22031
+
+   Phone: +1 703-206-5607
+   EMail: jmcmanus@uu.net
+
+
+
+
+
+
+Awduche, et al.              Informational                     [Page 28]
+
+RFC 2702                MPLS Traffic Engineering          September 1999
+
+
+13.0  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Awduche, et al.              Informational                     [Page 29]
+