rfc2702.txt

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

   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.