doc: Add RFC documents

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]
+