Internet Draft
Internet Engineering Task Force
INTERNET-DRAFT
MPLS Working Group                            Daniel O. Awduche
Expiration Date: March 2000                   UUNET (MCI Worldcom)
                                              Alan Hannan
                                              Xipeng Xiao
                                              Frontier Globalcenter
                                              September, 1999

     Applicability Statement for Extensions to RSVP for LSP-Tunnels

          draft-awduche-mpls-rsvp-tunnel-applicability-01.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.
   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.

D. O. Awduche, et al                                           [Page 1]

draft-awduche-mpls-rsvp-tunnel-applicability-01.txt March 2000

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 may be
   available from all label switching router vendors, which allow 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.

   This memo describes the applicability of the RSVP-Tunnel
   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.

   Two fundamental aspects distinguish the RSVP-Tunnel specification [1]
   from the original RSVP protocol [3].

   The first distinguishing aspect 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. 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-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

D. O. Awduche, et al                                           [Page 2]

draft-awduche-mpls-rsvp-tunnel-applicability-01.txt March 2000

   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
   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 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 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 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
     (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

D. O. Awduche, et al                                           [Page 3]

draft-awduche-mpls-rsvp-tunnel-applicability-01.txt March 2000

   The RSVP-Tunnel 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-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 object containing an MPLS label
   is inserted into the Resv message. As the Resv message propagates to
   the origination node (in the 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. Each node inserts its own LABEL object before propagating
   the Resv message upstream. This way, labels are allocated
   sequentially all the way from the egress node of the LSP-tunnel to
   the origination node. It is when the Resv message reaches the
   origination node that 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
   and/or for 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

D. O. Awduche, et al                                           [Page 4]

draft-awduche-mpls-rsvp-tunnel-applicability-01.txt March 2000

   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 Interior Gateway Protocol (IGP) Shortest
   Path First (SPF) algorithms. This feature provides significant
   control over the routing function and allows 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. 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-Tunnel 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-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 significant 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

D. O. Awduche, et al                                           [Page 5]

draft-awduche-mpls-rsvp-tunnel-applicability-01.txt March 2000

   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 should also guide the amount of bandwidth to
   be allocated (if any) to each LSP-tunnel. Policies of this type may
   take into consideration traffic statistics derived from the
   operational network in addition to 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
   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

   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
   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.

D. O. Awduche, et al                                           [Page 6]

draft-awduche-mpls-rsvp-tunnel-applicability-01.txt March 2000

7.0 Security Considerations

   This document does not introduce new security issues. The RSVP-Tunnel
   specification adds new opaque objects to RSVP and so 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] 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 7]

draft-awduche-mpls-rsvp-tunnel-applicability-01.txt March 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
   141 Caspian Court,
   Sunnyvale, CA 94089
   Email: alan@globalcenter.net,
   Voice: +1 408-543-4891

   Xipeng Xiao
   Frontier Globalcenter
   141 Caspian Court,
   Sunnyvale, CA 94089
   Email: xipeng@globalcenter.net,
   Voice: +1 408-543-4801

D. O. Awduche, et al                                           [Page 8]