Network Working Group J. Ash Request for Comments: 3213 AT&T Category: Informational M. Girish Atoga Systems E. Gray Sandburst B. Jamoussi G. Wright Nortel Networks Corp. January 2002 Applicability Statement for CR-LDP Status 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.
AbstractThis 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. 3], voice, video and other delay sensitive traffic . 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  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 . Because LDP is a peer-to-peer protocol based on the
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 . 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 , integrated services , ATM service classes , and frame relay . 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  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 .
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. 11].
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.
 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.  Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.  Ash, B., Lee, Y., Ashwood-Smith, P., Jamoussi, B., Fedyk, D., Skalecki, D. and L. Li, "LSP Modification using CR-LDP", RFC 3214, January 2002.  Blake S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.  Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.  ATM Forum Traffic Management Specification Version 4.1 (AF-TM- 0121.000), March 1999.  CONGESTION MANAGEMENT FOR THE ISDN FRAME RELAYING BEARER SERVICE, ITU (CCITT) Recommendation I.370, 1991.  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.  Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels", RFC 3210, December 2001.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.