RFC 3213

Applicability Statement for CR-LDP 🦋

• Stream: Network Working Group
• RFC: 3213
• Authors: J. Ash (AT&T), M. Girish (Atoga Systems), E. Gray (Sandburst), B. Jamoussi and G. Wright (Nortel Networks Corp.)
• Category: Informational
• Date: January 2002
• Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates

Part 1 of 2 🎀

---

Status of this Memo 🌸

Okay so this memo is just here to give info to the Internet community 💖. It does not specify an Internet standard of any kind, so it's not a rulebook. Distribution of this memo is unlimited, so share it with everyone 🫶.

Copyright Notice ✨

Copyright (C) The Internet Society (2002). All Rights Reserved. 💜

Abstract 🍓

This doc talks about how well Constraint-Based LSP Setup using LDP fits different situations. It covers possible network applications, the extensions to Label Distribution Protocol (LDP) that you need for constraint-based routing, deployment tips, and the known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track, so it's kind of a big deal 👑.

1. Introduction 🧚

As the Internet evolves, it needs extra abilities to properly treat data [3], voice, video, and other delay sensitive traffic [4]. MPLS enhances source routing and lets IP networks use certain techniques that used to belong to circuit switching. This gives us a scalable way to handle all those different transmission needs 🌈.

CR-LDP [1] is a simple, scalable, open, non-proprietary, traffic engineering signaling protocol for MPLS IP networks. It's giving pure efficiency 💅.

CR-LDP gives us mechanisms for setting up explicitly routed Label Switched Paths (LSPs). These mechanisms are defined as extensions to LDP [2]. Because LDP is a peer-to-peer protocol that runs on establishing and maintaining TCP sessions, you get some seriously natural perks:

• CR-LDP messages are reliably delivered by the underlying TCP, and state information associated with explicitly routed LSPs does not require periodic refresh. No constant check-ins needed 🙈.
• CR-LDP messages are flow controlled (throttled) through TCP. So nothing gets flooded, which is so iconic 🦋.

CR-LDP is built for one specific purpose: establishing and maintaining explicitly routed LSPs. Extra optional capabilities have minimal impact on system performance and requirements when they aren't being used for a specific explicitly routed LSP, so they don't slow down the basic vibe ✨. Those optional capabilities let you negotiate LSP services and traffic management parameters beyond best-effort packet delivery, including bandwidth allocation and setup and holding priorities 💪. CR-LDP can also optionally let these parameters be dynamically modified without disrupting the operational (in-service) LSP [4]. Main character energy, no downtime 👑.

CR-LDP lets you specify a set of parameters that get signaled along with the LSP setup request. On top of that, 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, together with the 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. That includes IP differentiated services [5], integrated services [6], ATM service classes [7], and frame relay [8]. Iconic range, no notes 😭.

CR-LDP is designed to adequately support the various media types that MPLS was designed to support (ATM, FR, Ethernet, PPP, etc.). So 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. Your network, your rules 💅.

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, so it's not a settled fight 🙈. Network administrators should make a choice between the two based upon their needs and particular situation. Applicability of RSVP-TE is described in [10].

2. Applicability of extensions to LDP 🎀

To support additional LSP services, CR-LDP extensions are defined so they're directly translatable to objects and messages used in other protocols that provide similar services [9]. Implementations can take advantage of this to:

• Set up 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. Honestly, it is not unreasonable to expect 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 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 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].

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. So it's flexible, but it's not a must 🙈.

CR-LDP also includes support for loose explicit routes. This lets the network operator define an 'explicit path' through portions of their network even when they have imperfect knowledge of the entire network topology 🗺️. Using this capability properly may also let CR-LDP implementations interoperate with 'vanilla' LDP implementations, especially if you want 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 don't have to be introduced in the network to provide TE-LSP signaling. One protocol, zero drama ✨.

4. Limitations 🥀

Okay, the not-so-slay part: 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 💀.

9. Full Copyright Statement ✨

okay so this part is the legal bit, but make it cute 🎀 The Internet Society owns the copyright here (2002), and all rights are reserved. 💅

Here's the vibe: you're allowed to copy this document and share it with your friends 🫶, and you can even make derivative works that comment on or explain it or help people implement it, and publish and distribute those too, in whole or in part, with no restriction of any kind. The one catch is that the above copyright notice and this paragraph have to stay on all those copies and derivative works. 🔒

BUT, and this is a big but 🙈, the document itself may not be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: you can change it as needed for developing Internet standards (in which case you have to follow the copyright procedures defined in the Internet Standards process), or you can translate it into languages other than English. 🌍

The permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Forever and ever, bestie 💜

Now the disclaimer, which is not as fun but super important 😭 This document and the information in it is provided on an "AS IS" basis. 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. No guarantees, no cap 🧢

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. Shoutout to the Internet Society for keeping the RFC Editor running! 👑