summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3213.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3213.txt')
-rw-r--r--doc/rfc/rfc3213.txt395
1 files changed, 395 insertions, 0 deletions
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]
+