rfc3346.txt

RFC 的详细文档！

   Currently deployed MPLS TE approaches can be adversely affected by
   both internal and external router and link failures.  This can create
   a mismatch between the signaled capacity and the traffic an LSP-
   tunnel carries.

   Many routers in service provider environments are already under
   stress processing the software workload associated with running IGP,
   BGP, and IPC.  Enabling TE in an MPLS environment involves adding
   traffic engineering databases and processes, adding additional
   information to be carried by the routing processes, and adding
   signaling state and processing to these network elements.  Additional
   traffic measurements may also need to be supported.  In some
   environments, this additional load may not be feasible.

   MPLS in general and MPLS-TE in particular is not a panacea for lack
   of network capacity, or lack of proper capacity planning and
   provisioning in the network dimensioning process.  MPLS-TE may cause
   network traffic to traverse greater distances or to take paths with
   more network elements, thereby incurring greater latency.  Generally,
   this added inefficiency is done to prevent shortcomings in capacity
   planning or available resources path to avoid hot spots.  The ability
   of TE to accommodate more traffic on a given topology can also be
   characterized as a short-term gain during periods of persistent
   traffic growth.  These approaches cannot achieve impossible mappings
   of traffic onto topologies.  Failure to properly capacity plan and
   execute will lead to congestion, no matter what technology aids are
   employed.








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


6. Conclusion

   The applicability of traffic engineering in Internet service provider
   environments has been discussed in this document.  The focus has been
   on the use of MPLS-based approaches to achieve traffic engineering in
   this context.  The applicability of traffic engineering and
   associated management and deployment considerations have been
   described, and the limitations highlighted.

   MPLS combines the ability to monitor point-to-point traffic
   statistics between two routers and the capability to control the
   forwarding paths of subsets of traffic through a given network
   topology.  This makes traffic engineering with MPLS applicable and
   useful for improving network performance by effectively mapping
   traffic flows onto links within service provider networks.  Tools
   that simplify and automate the MPLS TE functions and activation help
   to realize the full potential.

7. Security Considerations

   This document does not introduce new security issues.  When deployed
   in service provider networks, it is mandatory to ensure that only
   authorized entities are permitted to initiate establishment of LSP-
   tunnels.

8. References

   1  Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
      Switching Architecture," RFC 3031, January 2001.

   2  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus,
      "Requirements for Traffic Engineering Over MPLS," RFC 2702,
      September 1999.

   3  X. Xiao, A. Hannan, B. Bailey, and L. Ni, "Traffic Engineering
      with MPLS in the Internet," IEEE Network, March/April 2000.

   4  V. Springer, C. Pierantozzi, and J. Boyle, "Level3 MPLS Protocol
      Architecture," Work in Progress.

   5  T. Li, and H. Smit, "IS-IS Extensions for Traffic Engineering,"
      Work in Progress.

   6  D. Katz, D. Yeung, and K. Kompella, "Traffic Engineering
      Extensions to OSPF," Work in Progress.






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


   7  Awduche, D., Berger, L., Gan, D.H., Li, T., Srinivasan, V. and G.
      Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209,
      December 2001.

   8  Jamoussi, B. (Editor), "Constraint-Based LSP Setup using LDP," RFC
      3212, January 2002.

   9  Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement for
      Extensions to RSVP for LSP-Tunnels," RFC 3210, December 2001.

   10 Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X. Xiao,
      "Overview and Principles of Internet Traffic Engineering", RFC
      3272, May 2002.

   11 W.S. Lai, D. McDysan, J. Boyle, M. Carlzon, R. Coltun, T.
      Griffin, E. Kern, and T. Reddington, "Network Hierarchy and
      Multilayer Survivability," Work in Progress.

   12 D. Awduche, "MPLS and Traffic Engineering in IP Networks," IEEE
      Communications Magazine, December 1999.

   13 W.S. Lai, B. Christian, R.W. Tibbs, and S. Van den Berghe, "A
      Framework for Internet Traffic Engineering Measurement," Work in
      Progress.

9. Acknowledgments

   The effectiveness of the MPLS protocols for traffic engineering in
   service provider networks is in large part due to the experience
   gained and foresight given by network engineers and developers
   familiar with traffic engineering with ATM in these environments.  In
   particular, the authors wish to acknowledge the authors of RFC 2702
   for the clear articulation of the requirements, as well as the
   developers and testers of code in deployment today for keeping their
   focus.
















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


10. Authors' Addresses

   Jim Boyle
   Protocol Driven Networks
   Tel: [phone]
   EMail: [e-mail]

   Vijay Gill
   AOL Time Warner, Inc.
   12100 Sunrise Valley Drive
   Reston, VA 20191
   EMail: [e-mail]

   Alan Hannan
   RoutingLoop Intergalactic
   112 Falkirk Court
   Sunnyvale, CA 94087, USA
   Tel: [phone]
   EMail: [e-mail]

   Dave Cooper
   Global Crossing
   960 Hamlin Court
   Sunnyvale, CA 94089, USA
   Tel: [phone]
   EMail: [e-mail]

   Daniel O. Awduche
   Movaz Networks
   7926 Jones Branch Drive, Suite 615
   McLean, VA 22102, USA
   Tel: [phone]
   EMail: [e-mail]

   Blaine Christian
   Worldcom
   22001 Loudoun County Parkway, Room D1-2-737
   Ashburn, VA 20147, USA
   Tel: [phone]
   EMail: [e-mail]

   Wai Sum Lai
   AT&T
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Tel: [phone]
   EMail: [e-mail]




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


11.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.



















Boyle, et al.                Informational                     [Page 14]