Movatterモバイル変換

Network Working Group                                             J. AshRequest for Comments: 3213                                          AT&TCategory: Informational                                        M. Girish                                                           Atoga Systems                                                                 E. Gray                                                               Sandburst                                                             B. Jamoussi                                                               G. Wright                                                   Nortel Networks Corp.                                                            January 2002Applicability Statement for CR-LDPStatus of this Memo   This memo provides information for the Internet community.  It does   not specify an Internet standard of any kind.  Distribution of this   memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2002).  All Rights Reserved.Abstract   This document discusses the applicability of Constraint-Based LSP   Setup using LDP.  It discusses possible network applications,   extensions to Label Distribution Protocol (LDP) required to implement   constraint-based routing, guidelines for deployment and known   limitations of the protocol.  This document is a prerequisite to   advancing CR-LDP on the standards track.1. Introduction   As the Internet evolves, additional capabilities are required to   ensure proper treatment of data [3], voice, video and other delay   sensitive traffic [4].  MPLS enhances source routing and allows for   certain techniques, used in circuit switching, in IP networks.  This   permits a scalable approach to handling these diverse transmission   requirements.  CR-LDP [1] is a simple, scalable, open, non-   proprietary, traffic engineering signaling protocol for MPLS IP   networks.   CR-LDP provides mechanisms for establishing explicitly routed Label   Switched Paths (LSPs).  These mechanisms are defined as extensions to   LDP [2].  Because LDP is a peer-to-peer protocol based on theAsh, et al                   Informational                      [Page 1]

RFC 3213           Applicability Statement for CR-LDP       January 2002   establishment and maintenance of TCP sessions, the following natural   benefits exist:      CR-LDP messages are reliably delivered by the underlying TCP, and      State information associated with explicitly routed LSPs does not      require periodic refresh.      CR-LDP messages are flow controlled (throttled) through TCP.   CR-LDP is defined for the specific purpose of establishing and   maintaining explicitly routed LSPs.  Additional optional capabilities   included have minimal impact on system performance and requirements   when not in use for a specific explicitly routed LSP.  Optional   capabilities provide for negotiation of LSP services and traffic   management parameters over and above best-effort packet delivery   including bandwidth allocation, setup and holding priorities.  CR-LDP   optionally allows these parameters to be dynamically modified without   disruption of the operational (in-service) LSP [4].   CR-LDP allows the specification of a set of parameters to be signaled   along with the LSP setup request.  Moreover, the network can be   provisioned with a set of edge traffic conditioning functions (which   could include marking, metering, policing and shaping).  This set of   parameters along with the specification of edge conditioning   functions can be shown to be adequate and powerful enough to   describe, characterize and parameterize a wide variety of QoS   scenarios and services including IP differentiated services [5],   integrated services [6], ATM service classes [7], and frame relay   [8].   CR-LDP is designed to adequately support the various media types that   MPLS was designed to support (ATM, FR, Ethernet, PPP, etc.).  Hence,   it will work equally well for Multi-service switched networks, router   networks, or hybrid networks.   This applicability statement does not preclude the use of other   signaling and label distribution protocols for the traffic   engineering application in MPLS based networks.  Service providers   are free to deploy whatever signaling protocol meets their needs.   In particular CR-LDP and RSVP-TE [9] are two signaling protocols that   perform similar functions in MPLS networks.  There is currently no   consensus on which protocol is technically superior.  Therefore,   network administrators should make a choice between the two based   upon their needs and particular situation.  Applicability of RSVP-TE   is described in [10].Ash, et al                   Informational                      [Page 2]

RFC 3213           Applicability Statement for CR-LDP       January 20022. Applicability of extensions to LDP   To provide support of additional LSP services, CR-LDP extensions are   defined in such a way as to be directly translatable to objects and   messages used in other protocols defined to provide similar services   [9].  Implementations can take advantage of this fact to:      Setup LSPs for provision of an aggregate service associated with      the services being provided via these other protocols.      Directly translate protocol messages to provide services defined      in a non-CR-LDP portion of the network.      Describe, characterize and parameterize a wide variety of QoS      scenarios and services including IP differentiated services,      integrated services, ATM service classes, and frame relay.   Steady state information required for proper maintenance of an LSP   may be as little as 200 bytes or less.  It is not unreasonable to   anticipate that CR-LDP implementations may support in excess of one   hundred thousand or one million LSPs switched through a single Label   Switching Router (LSR) under fairly stable conditions.   Because CR-LDP provides for low overhead per LSP - both in terms of   needed state information and control traffic - CR-LDP is applicable   in those portions of the Internet where very large numbers of LSPs   may need to be switched at each LSR.  An example of this would be   large backbone networks using MPLS exclusively to transport very   large numbers of traffic streams between a moderately large number of   MPLS edge nodes.   CR-LDP may also be applicable as a mediating service between networks   providing similar service extensions using widely varying signaling   models.3. Implementation and deployment considerations in relation to LDP   LDP specifies the following label distribution and management modes   (which can be combined in various logical ways described in LDP):      . Downstream On Demand label distribution      . Downstream Unsolicited label distribution      . Independent Label Distribution Control      . Ordered Label Distribution Control      . Conservative Label Retention Mode      . Liberal Label Retention Mode   The applicability of LDP is described in [11].Ash, et al                   Informational                      [Page 3]

RFC 3213           Applicability Statement for CR-LDP       January 2002   In networks where only Traffic Engineered LSPs are required, the CR-   LDP implementation and deployment does NOT require all the   functionality defined in the LDP specification.  The basic Discovery,   Session, and Notification messages are required.  However, CR-LDP   requires one specific combination of the label distribution modes:      . Downstream On Demand Ordered label distribution and        conservative Label Retention Mode   Although CR-LDP is defined as an extension to LDP, support for   Downstream Unsolicited Label Advertisement and Independent Control   modes is not required for support of Strict Explicit Routes.  In   addition, implementations of CR-LDP MAY be able to support Loose   Explicit Routes via the use of 'Abstract Nodes' and/or 'Hierarchical   Explicit Routing', without using LDP for hop-by-hop LSP setup.   CR-LDP also includes support for loose explicit routes.  Use of this   capability allows the network operator to define an 'explicit path'   through portions of their network with imperfect knowledge of the   entire network topology.  Proper use of this capability may also   allow CR-LDP implementations to inter-operate with 'vanilla' LDP   implementations - particularly if it is desired to set up an   explicitly routed LSP for best-effort packet delivery via a loosely   defined path.   Finally, in networks where both Routing Protocol-driven LSPs (a.k.a.   hop-by-hop LSPs) and Traffic Engineered LSPs are required, a single   protocol (LDP, with the extensions defined in CR-LDP) can be used for   both TE and Hop-by-Hop LSPs.  New protocols do not have to be   introduced in the network to provide TE-LSP signaling.4. Limitations   CR-LDP specification only supports point-to-point LSPs.  Multi-   point-to-point and point-to-multi-point are for further study (FFS).   CR-LDP specification only supports unidirectional LSP setup.  Bi-   directional LSP setup is FFS.   CR-LDP specification only supports a unique label allocation per LSP   setup.  Multiple label allocations per LSP setup are FFS.5. Security Considerations   No additional security issues are introduced in this document.  As an   extension to LDP, CR-LDP shares the security concerns associated with   LDP.Ash, et al                   Informational                      [Page 4]

RFC 3213           Applicability Statement for CR-LDP       January 20026. Acknowledgements   The authors would like to thank the following people for their   careful review of the document and their comments: Loa Andersson,   Peter Ashwood-Smith, Anoop Ghanwani, Juha Heinanen, Jon Weil and   Adrian Farrel.7. References   [1]  Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L.,        Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M.,        Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-        based LSP Setup Using LDP",RFC 3212, January 2002.   [2]  Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B.        Thomas, "LDP Specification",RFC 3036, January 2001.   [3]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.        McManus, "Requirements for Traffic Engineering Over MPLS",RFC2702, September 1999.   [4]  Ash, B., Lee, Y., Ashwood-Smith, P., Jamoussi, B., Fedyk, D.,        Skalecki, D. and L. Li, "LSP Modification using CR-LDP",RFC3214, January 2002.   [5]  Blake S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.        Weiss, "An Architecture for Differentiated Services",RFC 2475,        December 1998.   [6]  Shenker, S. and  J. Wroclawski, "General Characterization        Parameters for Integrated Service Network Elements",RFC 2215,        September 1997.   [7]  ATM Forum Traffic Management Specification Version 4.1 (AF-TM-        0121.000), March 1999.   [8]  CONGESTION  MANAGEMENT FOR  THE  ISDN  FRAME  RELAYING BEARER        SERVICE, ITU (CCITT) Recommendation I.370, 1991.   [9]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G.        Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",RFC3209, December 2001.   [10] Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement        for Extensions to RSVP for LSP-Tunnels",RFC 3210, December        2001.Ash, et al                   Informational                      [Page 5]

RFC 3213           Applicability Statement for CR-LDP       January 2002   [11] Thomas, B. and E. Gray, "LDP Applicability",RFC 3037, January        2001.8. Author's Addresses   Gerald R. Ash   AT&T   Room MT D5-2A01   200 Laurel Avenue   Middletown, NJ 07748   USA   Phone: 732-420-4578   Fax:   732-368-8659   EMail: gash@att.com   Eric Gray   Sandburst   600 Federal Drive   Andover, MA  01810   Phone: (978) 689-1610   EMail: eric.gray@sandburst.com   Gregory Wright   Nortel Networks Corp.   P O Box 3511 Station C   Ottawa, ON K1Y 4H7   Canada   Phone: +1 613 765-7912   EMail: gwright@nortelnetworks.com   M. K. Girish   Atoga Systems   49026 Milmont Drive   Fremont, CA 94538   EMail: muckai@atoga.com   Bilel Jamoussi   Nortel Networks Corp.   600 Technology Park Drive   Billerica, MA 01821   USA   phone: +1 978-288-4506   EMail: Jamoussi@nortelnetworks.comAsh, et al                   Informational                      [Page 6]

RFC 3213           Applicability Statement for CR-LDP       January 20029. 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.Ash, et al                   Informational                      [Page 7]