From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3213.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc3213.txt (limited to 'doc/rfc/rfc3213.txt') diff --git a/doc/rfc/rfc3213.txt b/doc/rfc/rfc3213.txt new file mode 100644 index 0000000..e475da9 --- /dev/null +++ b/doc/rfc/rfc3213.txt @@ -0,0 +1,395 @@ + + + + + + +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. + +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 the + + + + +Ash, 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 2002 + + +2. 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 2002 + + +6. 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", RFC + 2702, September 1999. + + [4] 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. + + [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", RFC + 3209, 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.com + + + + + + + + +Ash, et al Informational [Page 6] + +RFC 3213 Applicability Statement for CR-LDP January 2002 + + +9. 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] + -- cgit v1.2.3