Internet Draft Internet Engineering Task Force INTERNET-DRAFT MPLS Working Group Daniel O. Awduche Expiration Date: January 2000 UUNET (MCI Worldcom) Alan Hannan Xipeng Xiao Frontier Globalcenter July, 1999 Applicability Statement for Extensions to RSVP for LSP-Tunnels draft-awduche-mpls-rsvp-tunnel-applicability-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo discusses the applicability of "Extensions to RSVP for LSP Tunnels" [1]. It highlights the protocol's principles of operation and describes the network context for which it was designed. It offers guidelines for deployment and indicates known protocol limitations. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track. D. O. Awduche, et al [Page 1] draft-awduche-mpls-rsvp-tunnel-applicability-00.txt Jan 2000 1.0 Introduction Service providers and users have expressed a strong need for traffic engineering capabilities in IP networks (based on Multiprotocol Label Switching -MPLS-) that 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 be available from all label switching router vendors, allowing such devices to interoperate. The "Extensions to RSVP for LSP tunnels" (RSVP-Tunnel) specification [1] was developed by the IETF MPLS working group to address this requirement. RSVP-Tunnel is a composition of several related proposals 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-Tunnel specification may have other uses within the Internet. Two fundamental aspects distinguish the RSVP-Tunnel specification [1] from the original RSVP protocol [3]. The first is the fact that the RSVP-Tunnel 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; whereas the original RSVP specification [3] 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-Tunnel specification generalizes the concept of "RSVP flow." The RSVP-Tunnel specification essentially allows an RSVP session to consist of an arbitrary aggregation of traffic (based on local policies) between the origination 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-Tunnel specification, however, a session is implicitly defined as the set of packets that are assigned the same MPLS label value at the origination 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 D. O. Awduche, et al [Page 2] draft-awduche-mpls-rsvp-tunnel-applicability-00.txt Jan 2000 sessions) does not increase proportionally with the number of flows in the network. Therefore, the RSVP-Tunnel 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. This applicability statement does not preclude the use of other signaling and label distribution protocols for the traffic engineering application in MPLS based IP networks. Service providers are free to deploy whatever signaling protocol that meets their needs. 2.0 Technical Overview of Extensions to RSVP for LSP Tunnels The RSVP-Tunnel specification extends the original RSVP protocol with 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 (such as bandwidth) to explicit LSPs, (4) rerouting of established LSP-tunnels in a smooth fashion using the concept of make-before-break, (5) tracking of the actual route traversed by an LSP-tunnel, (6) diagnostics on LSP-tunnels, (7) the concept of node abstraction, and (8) preemption options that are administratively controllable. The RSVP-Tunnel specification introduces several new RSVP objects, including: LABEL-REQUEST object, RECORD-ROUTE object, LABEL object, EXPLICIT-ROUTE object, and new SESSION objects. New error messages are defined to provide notification of exception conditions. All the new objects defined in RSVP-Tunnel 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. Informally, establishment of an LSP-tunnel proceeds in the following way: First, the origination node of the LSP-tunnel creates an RSVP Path message and inserts a LABEL-REQUEST object into it. Optionally, an EXPLICIT-ROUTE object, a RECORD-ROUTE object, and a SESSION_ATTRIBUTE object may also be inserted into the path message. The LABEL-REQUEST object indicates that a label binding is requested; the EXPLICIT-ROUTE object depicts the explicit route for the LSP- tunnel as a sequence of abstract nodes; the RECORD-ROUTE object specifies that a path vector record of the route traversed is required; finally, the SESSION_ATTRIBUTE object is used for session identification and diagnosis. When the Path message reaches the egress node of the LSP-tunnel, a Resv message is created and a LABEL D. O. Awduche, et al [Page 3] draft-awduche-mpls-rsvp-tunnel-applicability-00.txt Jan 2000 object containing an MPLS label is inserted into the Resv message. As the Resv message propagates to the origination node, in reverse direction along the path traversed by the Path message, each node uses the MPLS label in the LABEL object from its downstream neighbor as outgoing label for the LSP-tunnel, and inserts its own LABEL object before propagating the Resv message upstream. In this way, labels are allocated sequentially all the way from the egress node of the LSP-tunnel to the origination node, whence the LSP-tunnel becomes established. 3.0 Applicability of Extensions to RSVP for LSP Tunnels Use of RSVP-Tunnel 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, or for control purposes, or for both. For the measurement application, an LSP-tunnel can be used to capture various path statistics between its endpoints. For example, an LSP- tunnel can be instantiated, with or without bandwidth allocation, purely for the purpose of monitoring traffic flow statistics between two label switching routers. For the control application, LSP-tunnels can be used to forward subsets of traffic through paths that are independent of routes computed by conventional IGP SPF algorithms. This provides significant control over the routing function, allowing policies to be implemented that 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-Tunnel may be augmented with an ancillary constraint-based routing entity that computes 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, which 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. Indeed, the RSVP-Tunnel specification may be deployed in certain contexts without any of these additional components. The capability to monitor point to point traffic statistics between D. O. Awduche, et al [Page 4] draft-awduche-mpls-rsvp-tunnel-applicability-00.txt Jan 2000 two routers and the capability to control the forwarding paths of subsets of traffic through a given network topology together make the RSVP-Tunnel specifications applicable and useful for traffic engineering within service provider networks. These capabilities also make the RSVP-Tunnel applicable, in some contexts, as a component of an MPLS based VPN provisioning framework. It is to be noted that the MPLS architecture [4] states clearly that no single label distribution protocol is assumed for the MPLS technology. Therefore, 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-Tunnel, there should be well defined administrative policies governing the selection of nodes that will serve as endpoints for LSP-tunnels. Furthermore, in 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 should also guide the amount of bandwidth that should be allocated (if any) to each LSP-tunnel. Such policies may take into account traffic statistics derived from the operational network as well as other factors. 5.0 Limitations The RSVP-Tunnel specification supports only unicast LSP-tunnels. Multicast LSP-tunnels are not supported. The RSVP-Tunnel 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 D. O. Awduche, et al [Page 5] draft-awduche-mpls-rsvp-tunnel-applicability-00.txt Jan 2000 state of established LSP-tunnels. This issue is addressed in several proposals that have been submitted to the RSVP working group (see e.g. [6]). 6.0 Conclusion This document discussed the applicability of the "Extensions to RSVP for LSP Tunnels" specification. The specification introduced several enhancements to the RSVP protocol, making it applicable in contexts in which the original RSVP protocol would have been inappropriate. One context in which the RSVP-Tunnel 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-Tunnel specification adds new opaque objects to RSVP, hence 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 References [1] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, V. Srinivasan, "Extensions to RSVP for LSP Tunnels," Work in Progress. [2] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, "Requirements for Traffic Engineering Over MPLS," Work in Progress. [3] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. [4] E. Rosen, A. Viswanathan, R. Callon, "A Proposed Architecture for MPLS", Work in Progress. [5] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, A. Viswanathan, "A Framework for Multiprotocol Label Switching", Work in Progress. [6] L. Berger, D. Gan, G. Swallow, "RSVP Refresh Reduction Extensions," Work in Progress. D. O. Awduche, et al [Page 6] draft-awduche-mpls-rsvp-tunnel-applicability-00.txt Jan 2000 10.0 AUTHORS' ADDRESSES Daniel O. Awduche UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031 Email: awduche@uu.net Voice: +1 703-208-5277 Alan Hannan Frontier Globalcenter 1154 E. Arques Ave. Sunnyvale, CA 94086 Email: alan@globalcenter.net, Voice: +1 408-328-4891 Xipeng Xiao Frontier Globalcenter 1154 E. Arques Ave. Sunnyvale, CA 94086 Email: xipeng@globalcenter.net, Voice: +1 408-328-480 D. O. Awduche, et al [Page 7]