Internet Draft
MPLS Working Group                                     Daniel O. Awduche
Internet Draft                                UUNET (MCI Worldcom), Inc.
Expiration Date: March 2000
                                                              Lou Berger
                                                         LabN Consulting

                                                             Der-Hwa Gan
                                                  Juniper Networks, Inc.

                                                                 Tony Li
                                                  Procket Networks, Inc.

                                                          George Swallow
                                                     Cisco Systems, Inc.

                                                        Vijay Srinivasan
                                                  Torrent Networks, Inc.

                                                          September 1999

                   Extensions to RSVP for LSP Tunnels

                 draft-ietf-mpls-rsvp-lsp-tunnel-03.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.

   To view the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
   Directory, see http://www.ietf.org/shadow.html.

Abstract

   This document describes the use of RSVP, including all the necessary
   extensions, to establish label-switched paths (LSPs) in MPLS.  Since
   the flow along an LSP is completely identified by the label applied

Swallow, editor                                                 [Page 1]

Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt   September 1999

   at the ingress node of the path, these paths may be treated as
   tunnels.  A key application of LSP tunnels is traffic engineering
   with MPLS as specified in [3].

   We propose several additional objects that extend RSVP, allowing the
   establishment of explicitly routed label switched paths using RSVP as
   a signaling protocol.  The result is the instantiation of label-
   switched tunnels which can be automatically routed  away from network
   failures, congestion, and bottlenecks.

Swallow, editor                                                 [Page 2]

Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt   September 1999

Contents

    1      Introduction and Background  ............................   5
    1.1    Introduction  ...........................................   5
    1.2    Background  .............................................   6
    2      Overview   ..............................................   7
    2.1    LSP Tunnels  ............................................   7
    2.2    Operation of LSP Tunnels  ...............................   8
    2.3    Service Classes  ........................................  10
    2.4    Reservation Styles  .....................................  10
    2.4.1  Fixed Filter (FF) Style  ................................  10
    2.4.2  Wildcard Filter (WF) Style  .............................  10
    2.4.3  Shared Explicit (SE) Style  .............................  11
    2.5    Rerouting LSP Tunnels  ..................................  12
    3      LSP Tunnel related Message Formats  .....................  13
    3.1    Path Message  ...........................................  14
    3.2    Resv Message  ...........................................  14
    4      LSP Tunnel related Objects  .............................  15
    4.1    Label Object  ...........................................  15
    4.1.1  Handling Label Objects in Resv messages  ................  16
    4.1.2  Non-support of the Label Object  ........................  16
    4.2    Label Request Object  ...................................  17
    4.2.1  Handling of LABEL_REQUEST  ..............................  20
    4.2.2  Non-support of the Label Request Object  ................  21
    4.3    Explicit Route Object  ..................................  21
    4.3.1  Applicability  ..........................................  22
    4.3.2  Semantics of the Explicit Route Object  .................  22
    4.3.3  Subobjects  .............................................  23
    4.3.4  Processing of the Explicit Route Object  ................  27
    4.3.5  Loops  ..................................................  29
    4.3.6  Non-support of the Explicit Route Object  ...............  29
    4.4    Record Route Object  ....................................  29
    4.4.1  Subobjects  .............................................  30
    4.4.2  Applicability  ..........................................  32
    4.4.3  Handling RRO  ...........................................  33
    4.4.4  Loop Detection  .........................................  34
    4.4.5  Non-support of RRO  .....................................  35
    4.5    Error Codes for ERO and RRO  ............................  35
    4.6    Session, Sender Template, and Filter Spec Objects  ......  36
    4.6.1  Session Object  .........................................  36
    4.6.2  Sender Template Object  .................................  37
    4.6.3  Filter Specification Object  ............................  37
    4.6.4  Reroute Procedure  ......................................  38
    4.7    Session Attribute Object  ...............................  39
    4.8    Tspec and Flowspec Object for Class-of-Service Service...  41
    5      Security Considerations  ................................  43

Swallow, editor                                                 [Page 3]

Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt   September 1999

    6      Intellectual Property Considerations  ...................  43
    7      Acknowledgments  ........................................  43
    8      References  .............................................  43
    9      Authors' Addresses  .....................................  45

Swallow, editor                                                 [Page 4]

Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt   September 1999

1. Introduction and Background

1.1. Introduction

   Section 2.9 of the MPLS architecture [2] defines a label distribution
   protocol as a set of procedures by which one Label Switched Router
   (LSR) informs another of the meaning of labels used to forward
   traffic between and through them.  The MPLS architecture does not
   assume a single label distribution protocol.  This document is a
   specification of extensions to RSVP for establishing label switched
   paths (LSPs) in Multi-protocol Label Switching (MPLS) networks.

   Several of the new features described in this document were motivated
   by the requirements for traffic engineering over MPLS (see [3]). In
   particular, the extended RSVP protocol supports the instantiation of
   explicitly routed LSPs, with or without resource reservations. It
   also supports smooth rerouting of LSPs, preemption, and loop
   detection.

   Since the traffic that flows along a label-switched path is defined
   by the label applied at the ingress node of the LSP, these paths can
   be treated as tunnels.  When an LSP is used in this way we refer to
   it as an LSP tunnel.

   LSP tunnels allow the implementation of a variety of policies related
   to network performance optimization.  For example, LSP tunnels can be
   automatically or manually routed away from network failures,
   congestion, and bottlenecks. Furthermore, multiple parallel LSP
   tunnels can be established between two nodes, and traffic between the
   two nodes can be mapped onto the LSP tunnels according to local
   policy. Although traffic engineering (that is, performance
   optimization of operational networks) is expected to be an important
   application of this specification, the extended RSVP protocol can be
   used in a much wider context.

   The purpose of this document is to describe the use of RSVP to
   establish LSP tunnels.  The intent is to fully describe all the
   objects, packet formats, and procedures required to realize
   interoperable implementations.  A few new objects are also defined
   that enhance management and diagnostics of LSP tunnels.

   All objects described in this specification are optional with respect
   to RSVP.  This document discusses what happens when an object
   described here is not supported by a node.

   Throughout this document, the discussion will be restricted to
   unicast label switched paths.  Multicast LSPs are left for further
   study.

Swallow, editor                                                 [Page 5]

Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt   September 1999

1.2. Background

   Hosts and routers that support both RSVP [1] and Multi-Protocol Label
   Switching [2] can associate labels with RSVP flows. When MPLS and
   RSVP are combined, the definition of a flow can be made more
   flexible.  Once a label switched path (LSP) is established, the
   traffic through the path is defined by the label applied at the
   ingress node of the LSP. The mapping of label to traffic can be
   accomplished using a number of different criteria.  The set of
   packets that are assigned the same label value by a specific node are
   said to belong to the same forwarding equivalence class (FEC) (see
   [2]), and effectively define the "RSVP flow."  When traffic is mapped
   onto a label-switched path in this way, we call the LSP an "LSP
   Tunnel".  When labels are associated with traffic flows, it becomes
   possible for a router to identify the appropriate reservation state
   for a packet based on the packet's label value.

   The signaling protocol model uses downstream-on-demand label
   distribution.  A request to bind labels to a specific LSP tunnel is
   initiated by an ingress node through the RSVP Path message. For this
   purpose, the RSVP Path message is augmented with a LABEL_REQUEST
   object. Labels are allocated downstream and distributed (propagated
   upstream) by means of the RSVP Resv message. For this purpose, the
   RSVP Resv message is extended with a special LABEL object. Label
   stacking is also supported. The procedures for label allocation,
   distribution, binding, and stacking are described in subsequent
   sections of this document.

   The signaling protocol model also supports explicit routing
   capability. This is accomplished by incorporating a simple
   EXPLICIT_ROUTE object into RSVP Path messages. The EXPLICIT_ROUTE
   object encapsulates a concatenation of hops which constitutes the
   explicitly routed path. Using this object, the paths taken by label-
   switched RSVP-MPLS flows can be pre-determined, independent of
   conventional IP routing.  The explicitly routed path can be
   administratively specified, or automatically computed by a suitable
   entity based on QoS and policy requirements, taking into
   consideration the prevailing network state. In general, path
   computation can be  control-driven or data-driven.  The mechanisms,
   processes, and algorithms used to compute explicitly routed paths are
   beyond the scope of this specification.

   One useful application of explicit routing is traffic engineering.
   Using explicitly routed LSPs, a node at the ingress edge of an MPLS
   domain can control the path through which traffic  traverses from
   itself, through the MPLS network, to an egress node.  Explicit
   routing can be used to optimize the utilization of network resources
   and enhance traffic oriented performance characteristics.

Swallow, editor                                                 [Page 6]

Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt   September 1999

   The concept of explicitly routed label switched paths can be
   generalized through the notion of abstract nodes. An abstract node is
   a group of nodes whose internal topology is opaque to the ingress
   node of the LSP. An abstract node is said to be trivial if it is a
   singleton, that is if it contains only one physical node. Using this
   concept of abstraction, an explicitly routed LSP can be specified as
   a sequence of IP prefixes or a sequence of Autonomous Systems.

   The signaling protocol model supports the specification of an
   explicit path as a sequence of strict and loose routes. The
   combination of abstract nodes, and strict and loose routes
   significantly enhances the flexibility of path definitions.

   An advantage of using RSVP to establish LSP tunnels is that it
   enables the allocation of resources along the path. For example,
   bandwidth can be allocated to an LSP tunnel using standard RSVP
   reservations and Integrated Services service classes [4].

   While resource reservations are useful, they are not mandatory.
   Indeed, an LSP can be instantiated without any resource reservations
   whatsoever. Such LSPs without resource reservations can be used, for
   example, to carry best effort traffic. They can also be used in many
   other contexts, including implementation of fall-back and recovery
   policies under fault conditions, and so forth.

2. Overview

2.1. LSP Tunnels

   According to [1], "RSVP defines a 'session' to be a data flow with a
   particular destination and transport-layer protocol." However, when
   RSVP and MPLS are combined, a flow or session can be defined with
   greater flexibility and generality.  The ingress node of an LSP can
   use a variety of means to determine which packets are assigned a
   particular label.  Once a label is assigned to a set of packets, the
   label effectively defines the "flow" through the LSP.  We refer to
   such an LSP as an "LSP tunnel" because the traffic through it is
   opaque to intermediate nodes along the label switched path.

   A new RSVP SESSION object, called LSP_TUNNEL_IPv4, has been defined
   to support the LSP tunnel feature.  The semantics of this object,
   from the perspective of a node along the label switched path, is that
   traffic belonging to the LSP tunnel is identified solely on the basis
   of packets arriving from the PHOP or "previous hop" (see [1]) with
   the particular label value(s) assigned by this node to upstream
   senders to the session.  In fact, the IPv4 that appears in the object

Swallow, editor                                                 [Page 7]

Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt   September 1999

   name only denotes that the destination address is an IPv4 address.

2.2. Operation of LSP Tunnels

   This section summarizes some of the features supported by RSVP as
   extended by this document related to the operation of LSP tunnels.
   These include: (1) the capability to establish LSP tunnels with or
   without QoS requirements, (2) the capability to dynamically reroute
   an established LSP tunnel, (3) the capability to observe the actual
   route traversed by an established LSP tunnel, (4) the capability to
   identify and diagnose LSP tunnels, (5) the capability to preempt an
   established LSP tunnel under administrative policy control, and (6)
   the capability to perform downstream-on-demand label allocation,
   distribution, and binding. In the following paragraphs, these
   features are briefly described.  More detailed descriptions can be
   found in subsequent sections of this document.

   To create an LSP tunnel, the first MPLS node on the path -- that is,
   the sender node with respect to the path -- creates an RSVP Path
   message with a session type of LSP_Tunnel_IPv4 and inserts a
   LABEL_REQUEST object into the Path message. The LABEL_REQUEST object
   indicates that a label binding for this path is requested and also
   provides an indication of the network layer protocol that is to be
   carried over this path. The reason for this is that the network layer
   protocol sent down an LSP cannot be assumed to be IPv4 and cannot be
   deduced from the L2 header, which simply identifies the higher layer
   protocol as MPLS.

   If the sender node has knowledge of a route that has high likelihood
   of meeting the tunnel's QoS requirements, or that makes efficient use
   of network resources, or that satisfies some policy criteria, the
   node can decide to use the route for some or all of its sessions. To
   do this, the sender node adds an EXPLICIT_ROUTE object to the RSVP
   Path message. The EXPLICIT_ROUTE object specifies the route as a
   sequence of abstract nodes.

   If, after a session has been successfully established and the sender
   node discovers a better route, the sender can dynamically reroute the
   session by simply changing the EXPLICIT_ROUTE object.  If problems
   are encountered with an EXPLICIT_ROUTE object, either because it
   causes a routing loop or because some intermediate routers do not
   support it, the sender node is notified.

   By adding a RECORD_ROUTE object to the Path message, the sender node
   can receive information about the actual route that the LSP tunnel
   traverses. The sender node can also use this object to request
   notification from the network concerning changes to the routing path.

Swallow, editor                                                 [Page 8]

Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt   September 1999

   The RECORD_ROUTE object is analogous to a path vector, and hence can
   be used for loop detection.

   Finally, a SESSION_ATTRIBUTE object can be added to Path messages to
   aid in session identification and diagnostics.  Additional control
   information, such as preemption, priority, and local-protection, are
   also included in this object.

   When the EXPLICIT_ROUTE object (ERO) is present, the Path message is
   forwarded towards its destination along a path specified by the ERO.
   Each node along the path records the ERO in its path state block.
   Nodes may also modify the ERO before forwarding the Path message. In
   this case the modified ERO should be stored in the path state block.

   The LABEL_REQUEST object requests intermediate routers and receiver
   nodes to provide a label binding for the session.  If a node is
   incapable of providing a label binding, it sends a PathErr message
   with an "unknown object class" error.  If the LABEL_REQUEST object is
   not supported end to end, the sender node will be notified by the
   first node which does not provide this support.

   The destination node of a label-switched path responds to a
   LABEL_REQUEST by including a LABEL object in its response RSVP Resv
   message.  The LABEL object is inserted in the filter spec list
   immediately following the filter spec to which it pertains.

   The Resv message is sent back upstream towards the sender, in a
   direction opposite to that followed by the Path message. Each node
   that receives a Resv message containing a LABEL object uses that
   label for outgoing traffic associated with this LSP tunnel.  If the
   node is not the sender, it allocates a new label and places that
   label in the corresponding LABEL object of the Resv message which it
   sends upstream to the PHOP. The label sent upstream in the LABEL
   object is the label which this node will use to identify incoming
   traffic associated with this LSP tunnel. This label also serves as
   shorthand for the Filter Spec. The node can now update its "Incoming
   Label Map" (ILM), which is used to map incoming labeled packets to a
   "Next Hop Label Forwarding Entry" (NHLFE), see [2].

   When the Resv message propagates upstream to the sender node, a
   label-switched path is effectively established.

Swallow, editor                                                 [Page 9]

Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt   September 1999

2.3. Service Classes

   This document does not restrict the type of Integrated Service
   requests for reservations.  However, an implementation should support
   the Controlled-Load service [4] and the Class-of-Service service, see
   Section 4.8.

2.4. Reservation Styles

   The receiver node can select from among a set of possible reservation
   styles for each session, and each RSVP session must have a particular
   style.  Senders have no influence on the choice of reservation style.
   The receiver can choose different reservation styles for different
   LSPs.

   An RSVP session can result in one or more LSPs, depending on the
   reservation style chosen.

   Some reservation styles, such as FF, dedicate a particular
   reservation to an individual sender node.  Other reservation styles,
   such as WF and SE, can share a reservation among several sender
   nodes.  The following sections discuss the different reservation
   styles and their advantages and disadvantages.  A more detailed
   discussion of reservation styles can be found in [1].

2.4.1. Fixed Filter (FF) Style

   The Fixed Filter (FF) reservation style creates a distinct
   reservation for traffic from each sender that is not shared by other
   senders.  This style is common for applications in which traffic from
   each sender is likely to be concurrent and independent.  The total
   amount of reserved bandwidth on a link for sessions using FF is the
   sum of the reservations for the individual senders.

   Because each sender has its own reservation, a unique label and a
   separate label-switched-path can be assigned to each sender.  This
   can result in a point-to-point LSP between every sender/receiver
   pair.

2.4.2. Wildcard Filter (WF) Style

   With the Wildcard Filter (WF) reservation style, a single shared
   reservation is used for all senders to a session.  The total
   reservation on a link remains the same regardless of the number of
   senders.

Swallow, editor                                                [Page 10]

Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt   September 1999

   A single multipoint-to-point label-switched-path is created for all
   senders to the session. On links that senders to the session share, a
   single label value is allocated to the session.  If there is only one
   sender, the LSP looks like a normal point-to-point connection.  When
   multiple senders are present, a multipoint-to-point LSP (a reversed
   tree) is created.

   This style is useful for applications in which not all senders send
   traffic at the same time.  A phone conference, for example, is an
   application where not all speakers talk at the same time.  If,
   however, all senders send simultaneously, then there is no means of
   getting the proper reservations made.  Either the reserved bandwidth
   on links close to the destination will be less than what is required
   or then the reserved bandwidth on links close to some senders will be
   greater than what is required.  This restricts the applicability of
   WF for traffic engineering purposes.

   Furthermore, because of the merging rules of WF, EXPLICIT_ROUTE
   objects cannot be used with WF reservations.  As a result of this
   issue and the lack of applicability to traffic engineering, use of WF
   is not considered in this document.

2.4.3. Shared Explicit (SE) Style

   The Shared Explicit (SE) style allows a receiver to explicitly
   specify the senders to be included in a reservation.  There is a
   single reservation on a link for all the senders listed.  Because
   each sender is explicitly listed in the Resv message, different
   labels may be assigned to different senders, thereby creating
   separate LSPs.

   SE style reservations can be provided using multipoint-to-point
   label-switched-path or LSP per sender.  Multipoint-to-point LSPs may
   be used when path messages do not carry the EXPLICIT_ROUTE object, or
   when Path messages have identical EXPLICIT_ROUTE objects.  In either
   of these cases a common label may be assigned.

   Path messages from different senders can each carry their own ERO,
   and the paths taken by the senders can converge and diverge at any
   point in the network topology.  When Path messages have differing
   EXPLICIT_ROUTE objects, separate LSPs for each EXPLICIT_ROUTE object
   must be established.

Swallow, editor                                                [Page 11]

Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt   September 1999

2.5. Rerouting LSP Tunnels

   One of the requirements for Traffic Engineering is the capability to
   reroute an established LSP tunnel under a number of conditions, based
   on administrative policy. For example, in some contexts, an
   administrative policy may dictate that a given LSP tunnel is to be
   rerouted when a more "optimal" route becomes available. Another
   important context when LSP tunnel reroute is usually required is upon
   failure of a resource along the tunnel's established path.  Under
   some policies, it may also be necessary to return the LSP tunnel to
   its original path when the failed resource becomes re-activated.

   In general, it is highly desirable not to disrupt traffic, or
   adversely impact network operations while LSP tunnel rerouting is in
   progress.  This adaptive and smooth rerouting requirement
   necessitates establishing a new LSP tunnel and transferring traffic
   from the old LSP tunnel onto it before tearing down the old LSP
   tunnel. This concept is called "make-before-break." A problem can
   arise because the old and new LSP tunnels might compete with other
   for resources on network segments which they have in common.
   Depending on availability of resources, this competition can cause
   Admission Control to prevent the new tunnel from being established.
   An advantage of using RSVP to establish LSP tunnels is that it solves
   this problem very elegantly.

   To support make-before-break in a smooth fashion, it is necessary
   that on links that are common to the old and new LSPs, resources used
   by the old LSP tunnel should not be released before traffic is
   transitioned to the new LSP tunnel, and reservations should not be
   counted twice because this might cause Admission Control to reject
   the new LSP tunnel.

   The combination of the LSP_TUNNEL_IPv4 SESSION object and the SE
   reservation style naturally achieves smooth transitions.  The basic
   idea is that the old and new LSP tunnels share resources along links
   which they have in common. The LSP_TUNNEL_IPv4 SESSION object is used
   to narrow the scope of the RSVP session to the particular tunnel in
   question.  To uniquely identify a tunnel, we use the combination of
   the destination IP address (an address of the node which is the
   egress of the tunnel), a Tunnel ID, and the tunnel ingress node's IP
   address, which is placed in the Extended Tunnel ID field.

   During the reroute operation, the tunnel ingress needs to appear as
   two different senders to the RSVP session.  This is achieved by the
   inclusion of an "LSP ID", which is carried in the SENDER_TEMPLATE and
   FILTER_SPEC objects.  Since the semantics of these objects are
   changed, a new C-Type is assigned.

Swallow, editor                                                [Page 12]

Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt   September 1999

   To effect a reroute, the ingress node picks a new LSP ID and forms a
   new SENDER_TEMPLATE.  The ingress node then creates a new ERO to
   define the new path.  Thereafter the node sends a new Path Message
   using the original SESSION object and the new SENDER_TEMPLATE and
   ERO.  It continues to use the old LSP and refresh the old Path
   message.  On links that are not held in common, the new Path message
   is treated as a conventional new LSP tunnel setup.  On links held in
   common, the shared SESSION object and SE style allow the LSP to be
   established sharing resources with the old LSP.  Once the ingress
   node receives a Resv message for the new LSP, it can transition
   traffic to it and tear down the old LSP.

3. LSP Tunnel related Message Formats

   Five new objects are defined in this section:

      Object name          Applicable RSVP messages
      ---------------      ------------------------
      LABEL_REQUEST          Path
      LABEL                  Resv
      EXPLICIT_ROUTE         Path
      RECORD_ROUTE           Path, Resv
      SESSION_ATTRIBUTE      Path

   New C-Types are also assigned for the SESSION, SENDER_TEMPLATE,
   FILTER_SPEC, FLOWSPEC objects.

   Detailed descriptions of the new objects are given in later sections.
   All new objects are optional with respect to RSVP.  An implementation
   can choose to support a subset of objects.  However, the
   LABEL_REQUEST and LABEL objects are mandatory with respect to this
   specification.

   The LABEL and RECORD_ROUTE objects, are sender specific.  They must
   immediately follow either the SENDER_TEMPLATE in Path messages, or
   the FILTER_SPEC in Resv messages.

   The placement of EXPLICIT_ROUTE, LABEL_REQUEST, and SESSION_ATTRIBUTE
   objects is simply a recommendation.  The ordering of these objects is
   not important, so an implementation must be prepared to accept
   objects in any order.

Swallow, editor                                                [Page 13]

Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt   September 1999

3.1. Path Message

   The format of the Path message is as follows:

       ::=        [  ]
                                
                               
                               [  ]
                               
                               [  ]
                               [  ... ]
                               [  ]

       ::=   [  ]
                               [  ]
                               [  ]

3.2. Resv Message

   The format of the Resv message is as follows:

       ::=        [  ]
                                 
                               
                               [  ]  [  ]
                               [  ... ]