rfc2702.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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