doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc3210.txt b/doc/rfc/rfc3210.txt
new file mode 100644
index 0000000..aee4336
--- /dev/null
+++ b/doc/rfc/rfc3210.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         D. Awduche
+Request for Comments: 3210                                Movaz Networks
+Category: Informational                                       A.  Hannan
+                                                             Routingloop
+                                                                 X. Xiao
+                                                                Photuris
+                                                           December 2001
+
+
+     Applicability Statement for Extensions to RSVP for LSP-Tunnels
+
+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 (2001).  All Rights Reserved.
+
+Abstract
+
+   This memo discusses the applicability of "Extensions to RSVP
+   (Resource ReSerVation Protocol) for LSP Tunnels".  It highlights the
+   protocol's principles of operation and describes the network context
+   for which it was designed.  Guidelines for deployment are offered and
+   known protocol limitations are indicated.  This document is intended
+   to accompany the submission of "Extensions to RSVP for LSP Tunnels"
+   onto the Internet standards track.
+
+1.0 Introduction
+
+   Service providers and users have indicated that there is a great need
+   for traffic engineering capabilities in IP networks.  These traffic
+   engineering capabilities can be based on Multiprotocol Label
+   Switching (MPLS) and can be implemented on label switching routers
+   (LSRs) from different vendors that interoperate using a common
+   signaling and label distribution protocol.  A description of the
+   requirements for traffic engineering in MPLS based IP networks can be
+   found in [2].  There is, therefore, a requirement for an open, non-
+   proprietary, standards based signaling and label distribution
+   protocol for the MPLS traffic engineering application that will allow
+   label switching routers from different vendors to interoperate.
+
+   The "Extensions to RSVP for LSP tunnels" (RSVP-TE) specification [1]
+   was developed by the IETF MPLS working group to address this
+   requirement.  RSVP-TE is a composition of several related proposals
+
+
+
+Awduche, et. al.             Informational                      [Page 1]
+
+RFC 3210        Applicability Statement for Extensions     December 2001
+
+
+   submitted to the IETF MPLS working group.  It contains all the
+   necessary objects, packet formats, and procedures required to
+   establish and maintain explicit label switched paths (LSPs).
+   Explicit LSPs are foundational to the traffic engineering application
+   in MPLS based IP networks.  Besides the traffic engineering
+   application, the RSVP-TE specification may have other uses within the
+   Internet.
+
+   This memo describes the applicability of the RSVP-TE specifications
+   [1].  The protocol's principles of operation are highlighted, the
+   network context for which it was developed is described, guidelines
+   for deployment are offered, and known protocol limitations are
+   indicated.
+
+   This applicability statement concerns only the use of RSVP to set up
+   unicast LSP-tunnels.  It is noted that not all of the features
+   described in RFC2205 [3] are required to support the instantiation
+   and maintenance of LSP-tunnels.  Aspects related to the support of
+   other features and capabilities of RSVP by an implementation that
+   also supports LSP-tunnels are beyond the scope of this document.
+   However, support of such additional features and capabilities should
+   not introduce new security vulnerabilities in environments that only
+   use RSVP to set up LSP-tunnels.
+
+   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 that meets their
+   needs.
+
+   In particular, CR-LDP [6] and RSVP-TE [1] 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.
+
+2.0 Technical Overview of Extensions to RSVP for LSP Tunnels
+
+   The RSVP-TE specification extends the original RSVP protocol by
+   giving it new capabilities that support the following functions in an
+   MPLS domain:
+
+     (1) downstream-on-demand label distribution
+     (2) instantiation of explicit label switched paths
+     (3) allocation of network resources (e.g., bandwidth) to
+         explicit LSPs
+     (4) rerouting of established LSP-tunnels in a smooth fashion
+         using the concept of make-before-break
+
+
+
+Awduche, et. al.             Informational                      [Page 2]
+
+RFC 3210        Applicability Statement for Extensions     December 2001
+
+
+     (5) tracking of the actual route traversed by an LSP-tunnel
+     (6) diagnostics on LSP-tunnels
+     (7) the concept of nodal abstraction
+     (8) preemption options that are administratively controllable
+
+   The RSVP-TE specification introduces several new RSVP objects,
+   including the LABEL-REQUEST object, the RECORD-ROUTE object, the
+   LABEL object, the EXPLICIT-ROUTE object, and new SESSION objects.
+   New error messages are defined to provide notification of exception
+   conditions.  All of the new objects defined in RSVP-TE are optional
+   with respect to the RSVP protocol, except the LABEL-REQUEST and LABEL
+   objects, which are both mandatory for the establishment of LSP-
+   tunnels.
+
+   Two fundamental aspects distinguish the RSVP-TE specification [1]
+   from the original RSVP protocol [3].
+
+   The first distinguishing aspect is the fact that the RSVP-TE
+   specification [1] is intended for use by label switching routers (as
+   well as hosts) to establish and maintain LSP-tunnels and to reserve
+   network resources for such LSP-tunnels.  The original RSVP
+   specification [3], on the other hand, was intended for use by hosts
+   to request and reserve network resources for micro-flows.
+
+   The second distinguishing aspect is the fact that the RSVP-TE
+   specification generalizes the concept of "RSVP flow." The RSVP-TE
+   specification essentially allows an RSVP session to consist of an
+   arbitrary aggregation of traffic (based on local policies) between
+   the originating node of an LSP-tunnel and the egress node of the
+   tunnel.  To be definite, in the original RSVP protocol [3], a session
+   was defined as a data flow with a particular destination and
+   transport layer protocol.  In the RSVP-TE specification, however, a
+   session is implicitly defined as the set of packets that are assigned
+   the same MPLS label value at the originating node of an LSP-tunnel.
+   The assignment of labels to packets can be based on various criteria,
+   and may even encompass all packets (or subsets thereof) between the
+   endpoints of the LSP-tunnel.  Because traffic is aggregated, the
+   number of LSP-tunnels (hence the number of RSVP sessions) does not
+   increase proportionally with the number of flows in the network.
+   Therefore, the RSVP-TE specification [1] addresses a major scaling
+   issue with the original RSVP protocol [3], namely the large amount of
+   system resources that would otherwise be required to manage
+   reservations and maintain state for potentially thousands or even
+   millions of RSVP sessions at the micro-flow granularity.
+
+   The reader is referred to [1] for a technical description of the
+   RSVP-TE protocol specification.
+
+
+
+
+Awduche, et. al.             Informational                      [Page 3]
+
+RFC 3210        Applicability Statement for Extensions     December 2001
+
+
+3.0 Applicability of Extensions to RSVP for LSP Tunnels
+
+   Use of RSVP-TE is appropriate in contexts where it is useful to
+   establish and maintain explicit label switched paths in an MPLS
+   network.  LSP-tunnels may be instantiated for measurement purposes
+   and/or for routing control purposes.  They may also be instantiated
+   for other administrative reasons.
+
+   For the measurement application, an LSP-tunnel can be used to capture
+   various path statistics between its endpoints.  This can be
+   accomplished by associating various performance management and fault
+   management functions with an LSP-tunnel, such as packet and byte
+   counters.  For example, an LSP-tunnel can be instantiated, with or
+   without bandwidth allocation, solely for the purpose of monitoring
+   traffic flow statistics between two label switching routers.
+
+   For the routing control application, LSP-tunnels can be used to
+   forward subsets of traffic through paths that are independent of
+   routes computed by conventional Interior Gateway Protocol (IGP)
+   Shortest Path First (SPF) algorithms.  This feature introduces
+   significant flexibility into the routing function and allows policies
+   to be implemented that can result in the performance optimization of
+   operational networks.  For example, using LSP-tunnels, traffic can be
+   routed away from congested network resources onto relatively
+   underutilized ones.  More generally, load balancing policies can be
+   actualized that increase the effective capacity of the network.
+
+   To further enhance the control application, RSVP-TE may be augmented
+   with an ancillary constraint-based routing entity.  This entity may
+   compute explicit routes based on certain traffic attributes, while
+   taking network constraints into account.  Additionally, IGP link
+   state advertisements may be extended to propagate new topology state
+   information.  This information can be used by the constraint-based
+   routing entity to compute feasible routes.  Furthermore, the IGP
+   routing algorithm may itself be enhanced to take pre-established
+   LSP-tunnels into consideration while building the routing table.  All
+   these augmentations are useful, but not mandatory.  In fact, the
+   RSVP-TE specification may be deployed in certain contexts without any
+   of these additional components.
+
+   The capability to monitor point to point traffic statistics between
+   two routers and the capability to control the forwarding paths of
+   subsets of traffic through a given network topology together make the
+   RSVP-TE specifications applicable and useful for traffic engineering
+   within service provider networks.
+
+   These capabilities also make the RSVP-TE applicable, in some
+   contexts, as a component of an MPLS based VPN provisioning framework.
+
+
+
+Awduche, et. al.             Informational                      [Page 4]
+
+RFC 3210        Applicability Statement for Extensions     December 2001
+
+
+   It is significant that the MPLS architecture [4] states clearly that
+   no single label distribution protocol is assumed for the MPLS
+   technology.  Therefore, as noted in the introduction, this
+   applicability statement does not (and should not be construed to)
+   prevent a label switching router from implementing other signaling
+   and label distribution protocols that also support establishment of
+   explicit LSPs and traffic engineering in MPLS networks.
+
+4.0 Deployment and Policy Considerations
+
+   When deploying RSVP-TE, there should be well defined administrative
+   policies governing the selection of nodes that will serve as
+   endpoints for LSP-tunnels.  Furthermore, when devising a virtual
+   topology for LSP-tunnels, special consideration should be given to
+   the tradeoff between the operational complexity associated with a
+   large number of LSP-tunnels and the control granularity that large
+   numbers of LSP-tunnels allow.  Stated otherwise, a large number of
+   LSP-tunnels allows greater control over the distribution of traffic
+   across the network, but increases network operational complexity.  In
+   large networks, it may be advisable to start with a simple LSP-tunnel
+   virtual topology and then introduce additional complexity based on
+   observed or anticipated traffic flow patterns.
+
+   Administrative policies may also guide the amount of bandwidth to be
+   allocated (if any) to each LSP-tunnel.  Policies of this type may
+   take into consideration empirical traffic statistics derived from the
+   operational network in addition to other factors.
+
+5.0 Limitations
+
+   The RSVP-TE specification supports only unicast LSP-tunnels.
+   Multicast LSP-tunnels are not supported.
+
+   The RSVP-TE specification supports only unidirectional LSP-tunnels.
+   Bidirectional LSP-tunnels are not supported.
+
+   The soft state nature of RSVP remains a source of concern because of
+   the need to generate refresh messages periodically to maintain the
+   state of established LSP-tunnels.  This issue is addressed in several
+   proposals that have been submitted to the RSVP working group (see
+   e.g. [5]).
+
+6.0 Conclusion
+
+   The applicability of the "Extensions to RSVP for LSP Tunnels"
+   specification has been discussed in this document.  The specification
+   introduced several enhancements to the RSVP protocol, which make it
+
+
+
+
+Awduche, et. al.             Informational                      [Page 5]
+
+RFC 3210        Applicability Statement for Extensions     December 2001
+
+
+   applicable in contexts in which the original RSVP protocol would have
+   been inappropriate.  One context in which the RSVP-TE specification
+   is particularly applicable is in traffic engineering in MPLS based IP
+   networks.
+
+7.0 Security Considerations
+
+   This document does not introduce new security issues.  The RSVP-TE
+   specification adds new opaque objects to RSVP.  Therefore, the
+   security considerations pertaining to the original RSVP protocol
+   remain relevant.  When deployed in service provider networks, it is
+   mandatory to ensure that only authorized entities are permitted to
+   initiate establishment of LSP-tunnels.
+
+8.0 Acknowledgments
+
+   The authors gratefully acknowledge the useful comments received from
+   the following individuals during initial review of this memo in the
+   MPLS WG mailing list: Eric Gray, John Renwick, and George Swallow.
+
+9.0 References
+
+   [1]   Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and V.
+         Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC
+         3209, December 2001.
+
+   [2]   Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
+         McManus, "Requirements for Traffic Engineering Over MPLS," RFC
+         2702, September 1999.
+
+   [3]   Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
+         "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
+         Specification", RFC 2205, September 1997.
+
+   [4]   Rosen, E., Viswanathan, A. and R. Callon, "A Proposed
+         Architecture for MPLS", RFC 3031, January 2001.
+
+   [5]   Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.
+         Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
+         2961, April 2001.
+
+   [6]   Jamoussi, B. et al, "Constraint-Based LSP Setup using LDP,"
+         Work in Progress.
+
+
+
+
+
+
+
+
+Awduche, et. al.             Informational                      [Page 6]
+
+RFC 3210        Applicability Statement for Extensions     December 2001
+
+
+10.0 Authors' Addresses
+
+   Daniel O. Awduche
+   Movaz Networks
+   7926 Jones Branch Drive, Suite 615
+   McLean, VA 22102
+
+   EMail: awduche@movaz.com
+   Voice: +1 703-298-5291
+
+   Alan Hannan
+   RoutingLoop
+   112 Falkirk Court
+   Sunnyvale, CA 94087
+
+   EMail: alan@routingloop.com
+   Voice: +1 408 666-2326
+
+   XiPeng Xiao
+   Photuris Inc.
+   2025 Stierlin Ct.
+   Mountain View, CA 94043
+
+   EMail: xxiao@photuris.com
+   Voice: +1 650-919-3215
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Awduche, et. al.             Informational                      [Page 7]
+
+RFC 3210        Applicability Statement for Extensions     December 2001
+
+
+11.0  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Awduche, et. al.             Informational                      [Page 8]
+