rfc2702.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,425 行 · 第 1/5 页

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