Movatterモバイル変換

Network Working Group                                         D. AwducheRequest for Comments: 3210                                Movaz NetworksCategory: Informational                                       A.  Hannan                                                             Routingloop                                                                 X. Xiao                                                                Photuris                                                           December 2001Applicability Statement for Extensions to RSVP for LSP-TunnelsStatus 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 proposalsAwduche, 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 inRFC2205 [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-breakAwduche, 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 20013.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 itAwduche, 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,"RFC3209, December 2001.   [2]   Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.         McManus, "Requirements for Traffic Engineering Over MPLS,"RFC2702, 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",RFC2961, 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 200110.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-3215Awduche, et. al.             Informational                      [Page 7]

RFC 3210        Applicability Statement for Extensions     December 200111.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]