rfc3346.txt

RFC 的详细文档！

   (non-hierarchical) IGP.  MPLS TE affinities can be used to explicitly
   keep continental traffic (traffic originating and terminating within
   a continent) from traversing transoceanic resources.

   Another example of using MPLS TE affinities to exclude certain
   traffic from a subset of circuits might be to keep inter-regional
   LSPs off of circuits that are reserved for intra-regional traffic.

   Still another example is the situation in a heterogeneous network
   consisting of links with different capacities, e.g., OC-12, OC-48,
   and OC-192.  In such networks, affinities can be used to force some
   types of traffic to only traverse links with a given capacity, e.g.
   OC-48.





Boyle, et al.                Informational                      [Page 5]

RFC 3346    Applicability Statement for Traffic Engineering  August 2002


3.4 Re-optimization After Restoration

   After the occurrence of a network failure, it may be desirable to
   calculate a new set paths for LSPs to optimizes performance over the
   residual topology.  This re-optimization is complementary to the
   fast-reroute operation used to reduce packet losses during routing
   transients under network restoration.  Traffic protection can also be
   accomplished by associating a primary LSP with a set of secondary
   LSPs, hot-standby LSPs, or a combination thereof [11].

4. Implementation Considerations

4.1 Architectural and Operational Considerations

   When deploying TE solutions in a service provider environment, the
   impact of administrative policies and the selection of nodes that
   will serve as endpoints for LSP-tunnels should be carefully
   considered.  As noted in [9], when devising a virtual topology for
   LSP-tunnels, special consideration should be given to the tradeoff
   between the operational complexity associated with a large number of
   LSP-tunnels and the control granularity that large numbers of LSP-
   tunnels allow.  In other words, a large number of LSP-tunnels allow
   greater control over the distribution of traffic across the network,
   but increases network operational complexity.  In large networks, it
   may be advisable to start with a simple LSP-tunnel virtual topology
   and then introduce additional complexity based on observed or
   anticipated traffic flow patterns [9].

   Administrative policies should guide the amount of bandwidth to be
   allocated to an LSP.  One may choose to set the bandwidth of a
   particular LSP to a statistic of the measured observed utilization
   over an interval of time, e.g., peak rate, or a particular percentile
   or quartile of the observed utilization.  Sufficient over-
   subscription (of LSPs) or under-reporting bandwidth on the physical
   links should be used to account for flows that exceed their normal
   limits on an event-driven basis.  Flows should be monitored for
   trends that indicate when the bandwidth parameter of an LSP should be
   resized.  Flows should be monitored constantly to detect unusual
   variance from expected levels.  If an unpoliced flow greatly exceeds
   its assigned bandwidth, action should be taken to determine the root
   cause and remedy the problem.  Traffic policing is an option that may
   be applied to deal with congestion problems, especially when some
   flows exceed their bandwidth parameters and interfere with other
   compliant flows.  However, it is usually more prudent to apply
   policing actions at the edge of the network rather than within the
   core, unless under exceptional circumstances.





Boyle, et al.                Informational                      [Page 6]

RFC 3346    Applicability Statement for Traffic Engineering  August 2002


   When creating LSPs, a hierarchical network approach may be used to
   alleviate scalability problems associated with flat full mesh virtual
   topologies.  In general, operational experience has shown that very
   large flows (between city pairs) are long-lived and have stable
   characteristics, while smaller flows (edge to edge) are more dynamic
   and have more fluctuating statistical characteristics.  A
   hierarchical architecture can be devised consisting of core and edge
   networks in which the core is traffic engineered and serves as an
   aggregation and transit infrastructure for edge traffic.

   However, over-aggregation of flows can result in a stream so large
   that it precludes the constraint-based routing algorithm from finding
   a feasible path through a network.  Splitting a flow by using two or
   more parallel LSPs and distributing the traffic across the LSPs can
   solve this problem, at the expense of introducing more state in the
   network.

   Failure scenarios should also be addressed when splitting a stream of
   traffic over several links.  It is of little value to establish a
   finely balanced set of flows over a set of links only to find that
   upon link failure the balance reacts poorly, or does not revert to
   the original situation upon restoration.

4.2 Network Management Aspects

   Networks planning to deploy MPLS for traffic engineering must
   consider network management aspects, particularly performance and
   fault management [12].  With the deployment of MPLS in any
   infrastructure, some additional operational tasks are required, such
   as constant monitoring to ensure that the performance of the network
   is not impacted in the end-to-end delivery of traffic.  In addition,
   traffic characteristics, such as latency across an LSP, may also need
   to be assessed on a regular basis to ensure that service-level
   guarantees are achieved.

   Obtaining information on LSP behavior is critical in determining the
   stability of an MPLS network.  When LSPs transition or path changes
   occur, packets may be dropped which impacts network performance.  It
   should be the goal of any network deploying MPLS to minimize the
   volatility of LSPs and reduce the root causes that induce this
   instability.  Unfortunately, there are very few, if any, NMS systems
   that are available at this time with the capability to provide the
   correct level of management support, particularly root cause
   analysis.  Consequently, most early adopters of MPLS develop their
   own management systems in-house for the MPLS domain.  The lack of
   availability of commercial network management systems that deal
   specifically with MPLS-related aspects is a significant impediment to
   the large-scale deployment of MPLS networks.



Boyle, et al.                Informational                      [Page 7]

RFC 3346    Applicability Statement for Traffic Engineering  August 2002


   The performance of an MPLS network is also dependent on the
   configured values of bandwidth for each LSP.  Since congestion is a
   common cause of performance degradation in operational networks, it
   is important to proactively avoid these situations.  While MPLS was
   designed to minimize congestion on links by utilizing bandwidth
   reservations, it is still heavily reliant on user configurable data.
   If the LSP bandwidth value does not properly represent the traffic
   demand of that LSP, over-utilization may occur and cause significant
   congestion within the network.  Therefore, it is important to
   develop, deploy, and maintain a good modeling tool for determining
   LSP bandwidth size.  Lack of this capability may result in sub-
   optimal network performance.

4.3 Capacity Engineering Aspects

   Traffic engineering has a goal of ensuring traffic performance
   objectives for different services.  This requires that the different
   network elements be dimensioned properly to handle the expected load.
   More specifically, in mapping given user demands onto network
   resources, network dimensioning involves the sizing of the network
   elements, such as links, processors, and buffers, so that performance
   objectives can be met at minimum cost.  Major inputs to the
   dimensioning process are cost models, characterization of user
   demands and specification of performance objectives.

   In using MPLS, dimensioning involves the assignment of resources such
   as bandwidth to a set of pre-selected LSPs for carrying traffic, and
   mapping the logical network of LSPs onto a physical network of links
   with capacity constraints.  The dimensioning process also determines
   the link capacity parameters or thresholds associated with the use of
   some bandwidth reservation scheme for service protection.  Service
   protection controls the QoS for certain service types by restricting
   access to bandwidth, or by giving priority access to one type of
   traffic over another.  Such methods are essential, e.g., to prevent
   starvation of low-priority flows, to guarantee a minimum amount of
   resources for flows with expected short duration, to improve the
   acceptance probability for flows with high bandwidth requirements, or
   to maintain network stability by preventing performance degradation
   in case of a local overload.

4.4 Network Measurement Aspects

   Network measurement entails robust statistics collection and systems
   development.  Knowing *what* to do with these measurements is often
   where the secret-sauce is.  Examples for different applications of
   measurements are described in [13].  For instance, to ensure that the
   QoS objectives have been met, performance measurements and
   performance monitoring are required so that real-time traffic control



Boyle, et al.                Informational                      [Page 8]

RFC 3346    Applicability Statement for Traffic Engineering  August 2002


   actions, or policy-based actions, can be taken.  Also, to
   characterize the traffic demands, traffic measurements are used to
   estimate the offered loads from different service classes and to
   provide forecasting of future demands for capacity planning purposes.
   Forecasting and planning may result in capacity augmentation or may
   lead to the introduction of new technology and architecture.

   To avoid QoS degradation at the packet level, measurement-based
   admission control can be employed by using online measurements of
   actual usage.  This is a form of preventive control to ensure that
   the QoS requirements of different service classes can be met
   simultaneously, while maintaining network efficiency at a high level.
   However, it requires proper network dimensioning to keep the
   probability for the refusal of connection/flow requests sufficiently
   low.

5. Limitations

   Significant resources can be expended to gain a proper understanding
   of how MPLS works.  Furthermore, significant engineering and testing
   resources may need to be invested to identify problems with vendor
   implementations of MPLS.  Initial deployment of MPLS software and the
   configurations management aspects to support TE can consume
   significant engineering, operations, and system development
   resources.  Developing automated systems to create router
   configurations for network elements can require significant software
   development and hardware resources.  Getting to a point where
   configurations for routers are updated in an automated fashion can be
   a time consuming process.  Tracking manual tweaks to router
   configurations, or problems associated with these can be an endless
   task.  What this means is that much more is required in the form of
   various types of tools to simplify and automate the MPLS TE function.

   Certain architectural choices can lead to operational, protocol, and
   router implementation scalability problems.  This is especially true
   as the number of LSP-tunnels or router configuration data in a
   network increases, which can be exacerbated by designs incorporating
   full meshes, which create O(N^2) number of LSPs, where N is the
   number of network-edge nodes.  In these cases, minimizing N through
   hierarchy, regionalization, or proper selection of tunnel termination
   points can affect the network's ability to scale.  Loss of scale in
   this sense can be via protocol instability, inability to change
   network configurations to accommodate growth, inability for router
   implementations to be updated, hold or properly process
   configurations, or loss of ability to adequately manage the network.






Boyle, et al.                Informational                      [Page 9]

RFC 3346    Applicability Statement for Traffic Engineering  August 2002


   Although widely deployed, MPLS TE is a new technology when compared
   to the classic IP routing protocols such as IS-IS, OSPF, and BGP.
   MPLS TE also has more configuration and protocol options.  As such,
   some implementations are not battle-hardened and automated testing of
   various configurations is difficult if not infeasible.  Multi-vendor
   environments are beginning to appear, although additional effort is
   usually required to ensure full interoperability.

   Common approaches to TE in service provider environments switch the
   forwarding paradigm from connectionless to connection oriented.
   Thus, operational analysis of the network may be complicated in some
   regards (and improved in others).  Inconsistencies in forwarding
   state result in dropped packets whereas with connectionless methods
   the packet will either loop and drop, or be misdirected onto another
   branch in the routing tree.