[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 4860

                 Generic Aggregate RSVP Reservations    February 2006



   Internet Draft                                  Francois Le Faucheur
                                                            Bruce Davie
                                                    Cisco Systems, Inc.

                                                            Pratik Bose
                                                        Lockheed Martin

                                                         Chris Christou
                                                      Michael Davenport
                                                    Booz Allen Hamilton
   draft-ietf-tsvwg-rsvp-ipsec-00.txt
   Expires: August 2006                                   February 2006


                    Generic Aggregate RSVP Reservations
                    draft-ietf-tsvwg-rsvp-ipsec-00.txt




Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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

   [RSVP-AGG] defines aggregate RSVP reservations allowing resources to
   be reserved in a Diffserv network for a given DSCP from a given
   source to a given destination. [RSVP-AGG] also defines how end-to-end


Le Faucheur, et al.                                           [Page 1]

                 Generic Aggregate RSVP Reservations    February 2006


   RSVP reservations can be aggregated onto such aggregate reservations
   when transiting through a Diffserv cloud. There are situations where
   multiple such aggregate reservations are needed for the same source
   IP address, destination IP address and DSCP. However, this is not
   supported by the aggregate reservations defined in [RSVP-AGG]. In
   order to support this, the present document defines a more flexible
   type of aggregate RSVP reservations, referred to as generic aggregate
   reservation. Multiple such generic aggregate reservations can be
   established for a given DSCP from a given source IP address to a
   given destination IP address. The generic aggregate reservations may
   be used to aggregate end-to-end RSVP reservations. This document also
   defines the procedures for such aggregation. The generic aggregate
   reservations may also be used end-to-end directly by end-systems
   attached to a Diffserv network.


Copyright Notice
      Copyright (C) The Internet Society (2006).


Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


1.  Introduction

   [RSVP-AGG] defines RSVP aggregate reservations allowing resources to
   be reserved in a Diffserv network for a flow characterized by its 3-
   tuple <source IP address, destination IP address, DSCP>.

   [RSVP-AGG] also defines the procedures for aggregation of end-to-end
   RSVP reservations onto such aggregate reservations when transiting
   through a Diffserv cloud. Such aggregation is illustrated in Figure 1.


                    --------------------------
                   /       Aggregation        \
      |----|      |          Region            |      |----|
   H--| R  |\ |-----|                       |------| /| R  |-->H
   H--|    |\\|     |   |---|     |---|     |      |//|    |-->H
      |----| \|     |   | I |     | I |     |      |/ |----|
              | Agg |======================>| Deag |
             /|     |   |   |     |   |     |      |\
   H--------//|     |   |---|     |---|     |      |\\-------->H
   H--------/ |-----|                       |------| \-------->H
                  |                            |


Le Faucheur, et al.                                           [Page 2]

                 Generic Aggregate RSVP Reservations    February 2006


                   \                          /
                    --------------------------

   H       = Host requesting end-to-end RSVP reservations
   R       = RSVP router
   Agg     = Aggregator
   Deag    = Deaggregator
   I       = Interior Router

   -->   = E2E RSVP reservation
   ==>   = Aggregate RSVP reservation


                Figure 1 : Aggregation of E2E Reservations
                     over aggregate RSVP Reservations


   These aggregate reservations use a SESSION type specified in [RSVP-
   AGG] that contains the receiver (or Deaggregator) IP address and the
   DSCP of the PHB from which Diffserv resources are to be reserved. For
   example, in the case of IPv4, the SESSION object is specified as:

      o  IP4 SESSION object: Class = SESSION,
         C-Type = RSVP-AGGREGATE-IP4

           +-------------+-------------+-------------+-------------+
           |              IPv4 Session Address (4 bytes)           |
           +-------------+-------------+-------------+-------------+
           | /////////// |    Flags    |  /////////  |     DSCP    |
           +-------------+-------------+-------------+-------------+


   These aggregate reservations use a SENDER_TEMPLATE and FILTER_SPEC
   types specified in [RSVP-AGG] and which contains only the sender (or
   Aggregator) IP address. For example, in the case of IPv4, the
   SENDER_TEMPLATE is specified as:

      o  IP4 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE,
         C-Type = RSVP-AGGREGATE-IP4

           +-------------+-------------+-------------+-------------+
           |                IPv4 Aggregator Address (4 bytes)      |
           +-------------+-------------+-------------+-------------+


   Thus it is possible to establish, from a given source IP address to a
   given destination IP address, separate such aggregate reservations
   for different DSCPs. However, from a given source IP address to a



Le Faucheur, et al.                                           [Page 3]

                 Generic Aggregate RSVP Reservations    February 2006


   given IP destination address, only a single [RSVP-AGG] aggregate
   reservation can be established for a given DSCP.

   Situations have since been identified where multiple such aggregate
   reservations are needed for the same source IP address, destination
   IP address and DSCP. One example is where E2E reservations using
   different preemption priorities (as per [RSVP-PREEMP]) need to be
   aggregated through a Diffserv cloud using the same DSCP. Using
   multiple aggregate reservations for the same DSCP allows enforcement
   of the different preemption priorities within the aggregation region.
   In turn this allows much more efficient management of the Diffserv
   resources and in period of resource shortage allows to sustain a
   larger number of E2E reservations with higher preemption priorities.

   For example, [SIG-NESTED] discusses in details how end-to-end RSVP
   reservations can be established in a nested VPN environment through
   RSVP aggregation. In particular, [SIG-NESTED] describes how multiple
   parallel generic aggregate reservations (for the same DSCP), each
   with different preemption priorities, can be used to efficiently
   support the preemption priorities of end-to-end reservations.

   This document addresses this requirement for multiple aggregate
   reservations for the same DSCP, by defining a more flexible type of
   aggregate RSVP reservations, referred to as generic aggregate
   reservations. This is achieved primarily by adding the notions of a
   Virtual Destination Port and of an Extended Virtual Destination Port
   in the RSVP Session object.

   The notion of Virtual Destination Port was introduced in [RSVP-IPSEC]
   to address a similar requirement (albeit in a different context) for
   identification and demultiplexing of sessions beyond the IP
   destination address. This document reuses this notion from [RSVP-
   IPSEC] for identification and demultiplexing of generic aggregate
   sessions beyond the IP destination address and DSCP. This allows
   multiple generic aggregate reservations to be established for a given
   DSCP, from a given source IP address to a given destination IP
   address.

   [RSVP-TE] introduced the concept of an Extended Tunnel ID (in
   addition to the tunnel egress address and the Tunnel ID) in the
   Session object used to establish MPLS Traffic Engineering tunnels
   with RSVP. The Extended Tunnel ID provides a very convenient
   mechanism for the tunnel ingress node to narrow the scope of the
   session to the ingress-egress pair. The ingress node can achieve this
   by using one of its own IP addresses as a globally unique identifier
   and including it in the Extended Tunnel ID and therefore within the
   Session object. This document reuses this notion of Extended Tunnel
   ID from [RSVP-TE], simply renaming it Extended Virtual Destination



Le Faucheur, et al.                                           [Page 4]

                 Generic Aggregate RSVP Reservations    February 2006


   Port, in order to provide a convenient mechanism to narrow the scope
   of an generic aggregate session to an Aggregator-Deaggregator pair.

   The generic aggregate reservations may be used to aggregate end-to-
   end RSVP reservations. This document also defines the procedures for
   such aggregation. These procedures are based on those of [RSVP-AGG]
   and this document only specifies the differences with those.

   The generic aggregate reservations may also be used end-to-end
   directly by end-systems attached to a Diffserv network.


1.1.  Related RFCs and Internet-Drafts

   This document is heavily based on [RSVP-AGG]. It reuses [RSVP-AGG]
   wherever applicable and specifies the necessary extensions beyond
   [RSVP-AGG].

   The mechanisms defined in [BW-REDUC] allow an existing reservation to
   be reduced in allocated bandwidth in lieu of tearing that reservation
   down. These mechanisms are applicable to the generic aggregate
   reservations defined in the present document.

   [RSVP-TUNNEL] describes a general approach to running RSVP over
   various types of tunnels. One of these types of tunnel, referred to
   as a "type 2 tunnel", has some similarity with the generic aggregate
   reservations described in this document. The similarity stems from
   the fact that a single, aggregate reservation is made for the tunnel
   while many individual flows are carried over that tunnel. However,
   [RSVP-TUNNEL] does not address the use of Diffserv-based
   classification and scheduling in the core of a network (between
   tunnel endpoints), but rather relies on a UDP/IP tunnel header for
   classification. This is why [RSVP-AGG] required additional objects
   and procedures beyond those of [RSVP-TUNNEL]. Like [RSVP-AGG], this
   document also assumes the use of Diffserv-based classification and
   scheduling in the aggregation region and, thus, requires additional
   objects and procedures beyond those of [RSVP-TUNNEL].

   As explained in section 1, this document reuses the notion of Virtual
   Destination Port from [RSVP-IPSEC] and the notion of Extended Tunnel
   ID from [RSVP-TE].

1.2.  Organization Of This Document

   Section 2 defines the new RSVP objects related to generic aggregate
   reservations. Section 3 describes the processing rules for handling
   of generic aggregate reservations. Section 4 specifies the procedures
   for aggregation of end to end RSVP reservations over generic



Le Faucheur, et al.                                           [Page 5]

                 Generic Aggregate RSVP Reservations    February 2006


   aggregate RSVP reservations. Finally Section 5 provides example usage
   of how the generic aggregate reservations may be used.

   The IANA Considerations and the Security Considerations are discussed
   in Section 6 and 7, respectively.

1.3.  Change History

1.3.1.
      Changes From draft-lefaucheur-rsvp-ipsec-02 To draft-ietf-tsvwg-
     rsvp-ipsec-00

   The most significant changes are:

       o de-correlate the generic aggregate reservations from IPsec
          operations, in line with comments from the Security experts
          review. This significantly affects (and simplifies
          considerably) the document in many places.

       o add the notion of Extended Virtual Destination port (reusing
          the notion of Extended Tunnel ID of [RSVP-TE]).

       o added recommendations on use of IP addresses by Aggregator and
          Deaggregator

1.3.2.
      Changes From draft-lefaucheur-rsvp-ipsec-01 To draft-lefaucheur-
     rsvp-ipsec-02

   The most significant changes are:

       o added text in section 4.2 about Aggregator/Deaggregator
          responsibilities with respect to mapping of end-to-end
          reservations onto aggregate reservations.  The text also
          clarified that DCLASS object is no longer needed in PathErr
          message requesting new Aggregate Reservations

       o Moved the text discussing details of the procedures to handle
          dynamic update of SPI values from Security Considerations
          section into a new section 4.4.

       o updates to Security Considerations section to start addressing
          some comments from Security experts review.

1.3.3.
      Changes From draft-lefaucheur-rsvp-ipsec-00 To draft-lefaucheur-
     rsvp-ipsec-01

   The most significant change is the broadening of the applicability of
   the new type of aggregate reservations beyond use for Aggregate
   reservations for IPsec tunnels (to environments where IPsec is not



Le Faucheur, et al.                                           [Page 6]

                 Generic Aggregate RSVP Reservations    February 2006


   used). This affects the document in multiple places including the
   following changes:

       o document renamed to "Generic Aggregate RSVP Reservations"

       o added a subsection in Introduction to discuss a case where
          Generic Aggregate RSVP Reservations are needed in non IPsec
          environments

       o added text about the fact that the Generic Aggregate
          Reservations can be used with IP-in-IP and GRE encapsulation
          (in addition to with IPsec AH and ESP)

       o added example usage under Section 5 for environment where
          IPsec is not used

   The other significant changes are:

       o added a subsection on the changes of the [RSVP-AGG] procedures
          under Section 4

       o added explanation about allocation of VDstPort values by
          Deaggregator, in that same subsection

       o added value of Protocol ID in all example generic aggregate
          reservations in Section 5


2.  Object Definition

   This document defines two new objects under the SESSION Class and a
   new object under a new AGGREGATION SESSION Class.

   It reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP-AGGREGATE-IP6
   FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE and RSVP-AGGREGATE-
   IP6 SENDER_TEMPLATE objects defined in [RSVP-AGG].


2.1.  SESSION Class

      o    GENERIC-AGGREGATE-IPv4 SESSION object:
                     Class = 1
                     C-Type = To be allocated by IANA

               0           7 8          15 16         23 24          31
              +-------------+-------------+-------------+-------------+
              |               IPv4 DestAddress (4 bytes)              |
              +-------------+-------------+-------------+--+----------+
              | Reserved    |     Flags   |  vDstPort   |Rd|  DSCP    |


Le Faucheur, et al.                                           [Page 7]

                 Generic Aggregate RSVP Reservations    February 2006


              +-------------+-------------+-------------+--+----------+
              |                    Extended vDstPort                  |
              +-------------+-------------+-------------+-------------+
               0           7 8          15 16         23 24          31

   IPv4 DestAddress (IPv4 Destination Address)

       IPv4 address of the receiver (or Deaggregator)

   Reserved

      A 8-bit field. All bits MUST be set to 0 on transmit. This field
   MUST be ignored on receipt.


   VDstPort (Virtual Destination Port)

       An 8-bit identifier used in the SESSION that remains constant
       over the life of the generic aggregate reservation.


   Rd (Reserved)

       A 2-bit field. All bits MUST be set to 0 on transmit. This field
       MUST be ignored on receipt.


   DSCP (Diffserv Code Point)

       A 6-bit field containing the DSCP of the PHB from which Diffserv
       resources are to be reserved.


   Extended vDstPort (Extended Virtual Destination Port)

       A 32-bit identifier used in the SESSION that remains constant
       over the life of the generic aggregate reservation. Normally set
       to all zeros. A sender (or Aggregator) that wishes to narrow the
       scope of a SESSION to the sender-receiver pair (or Aggregator-
       Deaggregator pair) may place its IPv4 address here as a globally
       unique identifier.


         o    GENERIC-AGGREGATE-IPv6 SESSION object:
                     Class = 1
                     C-Type = To be allocated by IANA

               0           7 8          15 16         23 24          31
              +-------------+-------------+-------------+-------------+


Le Faucheur, et al.                                           [Page 8]

                 Generic Aggregate RSVP Reservations    February 2006


              |                                                       |
              +                                                       +
              |                                                       |
              +               IPv6 DestAddress (16 bytes)             +
              |                                                       |
              +                                                       +
              |                                                       |
              +-------------+-------------+-------------+--+----------+
              | Reserved    |     Flags   |  vDstPort   |Rd|   DSCP   |
              +-------------+-------------+-------------+--+----------+
              |                                                       |
              +                                                       +
              |                       Extended vDstPort               |
              +                                                       +
              |                            (16 bytes)                 |
              +                                                       +
              |                                                       |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               0           7 8          15 16            25 26       31

   IPv6 DestAddress (IPv6 Destination Address)

       IPv6 address of the receiver (or Deaggregator)


   Reserved

      A 8-bit field. All bits MUST be set to 0 on transmit. This field
   MUST be ignored on receipt.


   VDstPort (Virtual Destination Port)

       A 8-bit identifier used in the SESSION that remains constant
       over the life of the generic aggregate reservation.


   Rd (Reserved)

       A 2-bit field. All bits MUST be set to 0 on transmit. This field
       MUST be ignored on receipt.


   DSCP (Diffserv Code Point)

       A 6-bit field containing the DSCP of the PHB from which Diffserv
       resources are to be reserved




Le Faucheur, et al.                                           [Page 9]

                 Generic Aggregate RSVP Reservations    February 2006


   Extended vDstPort (Extended Virtual Destination Port)

       A 16-byte identifier used in the SESSION that remains constant
       over the life of the generic aggregate reservation. Normally set
       to all zeros. A sender (or Aggregator) that wishes to narrow the
       scope of a SESSION to the sender-receiver pair (or Aggregator-
       Deaggregator pair) may place its IPv6 address here as a globally
       unique identifier.


2.2.  AGGREGATION-SESSION Class

              o    IPv4-AGGREGATION-SESSION object:
                     Class = To be allocated by IANA
                     C-Type = To be allocated by IANA

                0           7 8          15 16         23 24          31
               +-------------+-------------+-------------+-------------+
               |       Length (bytes)      |  Class-Num  |   C-Type    |
               +-------------+-------------+-------------+-------------+
               |                                                       |
               //                  SESSION Object                     //
               |                                                       |
               +-------------+-------------+-------------+-------------+


              o    IPv6-AGGREGATION-SESSION object:
                     Class = To be allocated by IANA (same as for
                                               IPv4-AGGREGATION-SESSION)
                     C-Type = To be allocated by IANA

                0           7 8          15 16         23 24          31
               +-------------+-------------+-------------+-------------+
               |       Length (bytes)      |  Class-Num  |   C-Type    |
               +-------------+-------------+-------------+-------------+
               |                                                       |
               //                  SESSION Object                     //
               |                                                       |
               +-------------+-------------+-------------+-------------+



   For example, if the AGGREGATION-SESSION object is used to indicate
   that the Aggregate Session needed is a GENERIC-AGGREGATE-IPv4 SESSION
   then the AGGREGATION-SESSION will be encoded like this:

                0           7 8          15 16         23 24          31
               +-------------+-------------+-------------+-------------+
               |                           |IPv4-AGGR-SES|IPv4-AGGR-SES|


Le Faucheur, et al.                                          [Page 10]

                 Generic Aggregate RSVP Reservations    February 2006


               |       Length (bytes)      |  Class-Num  |   C-Type    |
               +-------------+-------------+-------------+-------------+
               |               IPv4 DestAddress (4 bytes)              |
               +-------------+-------------+-------------+--+----------+
               | Reserved    |     Flags   |  vDstPort      |   DSCP   |
               +-------------+-------------+-------------+--+----------+
               |                    Extended vDstPort                  |
               +-------------+-------------+-------------+-------------+
                0           7 8          15 16         23 24          31




3.  Processing Rules For Handling Generic Aggregate RSVP Reservations

   This section presents additions to the Processing Rules presented in
   [RSVP-PROCESS]. These additions are required in order to properly
   process the GENERIC-AGGREGATE-IPv4 (resp. GENERIC-AGGREGATE-IPv6)
   SESSION object and the RSVP-AGGREGATE-IP4 (resp. RSVP-AGGREGATE-IP6)
   FILTER_SPEC object. Values for referenced error codes can be found in
   [RSVP]. As with the other RSVP documents, values for internally
   reported (API) errors are not defined.

   When referring to the new GENERIC-AGGREGATE-IPv4 and GENERIC-
   AGGREGATE-IPv6 SESSION objects, IP version will not be included and
   they will be referred to simply as GENERIC-AGGREGATE SESSION, unless
   a specific distinction between IPv4 and IPv6 is being made.

   When referring to the [RSVP-AGG] RSVP-AGGREGATE-IP4 and
   RSVP-AGGREGATE-IP6 SESSION, FILTER_SPEC and SENDER_TEMPLATE objects,
   IP version will not be included and they will be referred to simply
   as RSVP-AGGREGATE, unless a specific distinction between IPv4 and
   IPv6 is being made.

3.1.  Required Changes to Path and Resv Processing

   Both RESV and PATH processing will need to be changed to support the
   new objects.

   The following PATH message processing changes are required:

       o When a session is defined using the GENERIC-AGGREGATE SESSION
          object, only the [RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATE may
          be used. When this condition is violated in a PATH message
          received by an RSVP end-station, the RSVP end-station SHOULD
          report a "Conflicting C-Type" API error to the application.
          When this condition is violated in a PATH message received by
          an RSVP router, the RSVP router MUST consider this as a
          message formatting error.


Le Faucheur, et al.                                          [Page 11]

                 Generic Aggregate RSVP Reservations    February 2006



       o For PATH messages that contain the GENERIC-AGGREGATE SESSION
          object, the VDstPort value, the Extended VDstPort value and
          the DSCP value should be recorded (in addition to the
          destination/Deaggregator address and source/aggregator
          address). These values form part of the recorded state of the
          session. The DSCP may need to be passed to traffic control;
          however the vDstPort and Extended VDstPort are not passed to
          traffic control since they do not appear inside  the data
          packets of the corresponding reservation.

   The changes to RESV message processing are:

       o When a RESV message contains a [RSVP-AGG] RSVP-AGGREGATE
          FILTER_SPEC, the session MUST be defined using either the
          RSVP-AGGREGATE SESSION object (as per [RSVP-AGG]) or the
          GENERIC-AGGREGATE SESSION object (as per this document). If
          this condition is not met, an RSVP router or end-station MUST
          consider that there is a message formatting error.

       o When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION
          type is GENERIC-AGGREGATE, each node MAY have a data
          classifier installed for the flow:

          * If the node needs to perform fine-grain classification (for
           example to perform fine-grain policing on ingress at a trust
           boundary) then the node MUST create a data classifier
           described by the 3-tuple <DestAddress, SrcAddress, DSCP>.

            Note that if multiple reservations are established with
           different Virtual Destination Ports (and/or different
           Extended Virtual Destination Ports) but with the same
           <DestAddress, SrcAddress, DSCP>, then those cannot be
           distinguished by the classifier. If the router is using the
           classifier for policing purposes, the router will therefore
           police those together and MUST program the policing rate to
           the sum of the reserved rate across all the corresponding
           reservations.

          * If the node only needs to perform Diffserv classification
           (for example inside the aggregation domain downstream of the
           trust boundary) then the node MUST rely on the Diffserv data
           classifier based on the DSCP only.


4.  Procedures for Aggregation over Generic Aggregate RSVP Reservations

   The procedures for Aggregation of E2E Reservations over Generic
   Aggregate RSVP Reservations are the same as the procedures specified


Le Faucheur, et al.                                          [Page 12]

                 Generic Aggregate RSVP Reservations    February 2006


   in [RSVP-AGG] with the exceptions of the procedure changes listed in
   this section.

   As specified in [RSVP-AGG], the Deaggregator is responsible for
   mapping a given E2E reservation on a given aggregate reservation. The
   Deaggregator requests establishment of a new aggregate reservation by
   sending to the Aggregator an E2E PathErr message with an error code
   of NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the Deaggregator conveys the
   DSCP of the new requested aggregate reservation by including a DCLASS
   Object in the E2E PathErr and encoding the corresponding DSCP inside.
   This document modifies and extends this procedure. The Deaggregator
   MUST include in the E2E PathErr message an AGGREGATION-SESSION object
   which contains the Session to be used for establishment of the
   requested generic aggregate reservation. Since the AGGREGATION-
   SESSION object contains the DSCP, the DCLASS object need not be
   included in the PathErr message.

   Note that the Deaggregator can easily ensure that different
   Aggregators use different sessions for their Aggregate Path towards a
   given Deaggregator. This is because the Deaggregator can easily
   select VDstPort and/or Extended VDstPort numbers which are different
   for each Aggregator (for example by using the Aggregator address as
   the Extended VDstPort) and can communicate those inside the
   AGGREGATION-SESSION object. This provides an easy solution to
   establish separate reservations from every Aggregator to a given
   Deaggregator. Conversely, if reservation sharing were needed across
   multiple Aggregators, the Deaggregator could facilitate this by
   allocating the same VDstPort and Extended VDstPort to the multiple
   Aggregators and thus including the same AGGREGATION-SESSION object in
   the E2E PathErr messages sent to these Aggregators. The Aggregators
   could then all establish an Aggregate Path with the same Session.

   Therefore various sharing scenarios can easily be supported. Policies
   followed by the Deaggregator to determine which aggregators need
   shared or separate reservations are beyond the scope of this document.

   The Deaggregator MAY also include in the E2E PathErr message (with an
   error code of NEW-AGGREGATE-NEEDED) additional RSVP objects which are
   to be used for establishment of the new needed generic aggregate
   reservation. For example, the Deaggregator MAY include in the E2E
   PathErr an RSVP Signaled Preemption Priority Policy Element (as
   specified in [RSVP-PREEMP].

   The [RSVP-AGG] procedures for processing of an E2E PathErr message
   with an error code of NEW-AGGREGATE-NEEDED by the Aggregator are
   extended correspondingly. On receipt of such a message containing an
   AGGREGATION-SESSION object, the Aggregator MUST use the Session
   provided in the AGGREGATION-SESSION object to trigger establishment
   of a generic aggregate reservation. The Aggregator MUST use the


Le Faucheur, et al.                                          [Page 13]

                 Generic Aggregate RSVP Reservations    February 2006


   DestAddress found in the AGGREGATION-SESSION object as the
   destination of the Aggregate Path. When an RSVP Signaled Preemption
   Priority Policy Element is contained in the received E2E PathErr
   message, the Aggregator MUST include this object in the Aggregate
   Path for the corresponding generic aggregate reservation. When other
   additional objects are contained in the received E2E PathErr message
   and those can be unambiguously interpreted as related to the new
   needed generic aggregate reservation (as opposed to related to the
   E2E reservation), the Aggregator SHOULD include those in the
   Aggregate Path for the corresponding generic aggregate reservation.
   The Aggregator MUST use as the Source Address (i.e. as the Aggregator
   Address) for the generic aggregate reservation, the address it uses
   to identify itself as the PHOP when forwarding the E2E Path messages
   corresponding to the E2E PathErr message.

   The Deaggregator follows the same procedures as described in [RSVP-
   AGG] for establishing, maintaining and clearing the aggregate Resv
   state. However, in this document, the Deaggregator MUST use the
   generic aggregate reservations and hence use the GENERIC-AGGREGATE
   SESSION specified earlier in this document.

   This document also modifies the procedures of [RSVP-AGG] related to
   exchange of E2E Resv messages between Deaggregator and Aggregator.
   The Deaggregator MUST include the new AGGREGATION-SESSION object in
   the E2E Resv message, in order to convey to the Aggregator which
   aggregate session to map a given E2E reservation onto. Again, since
   the AGGREGATION-SESSION object contains the DSCP, the DCLASS object
   need not be included in the E2E Resv message. The Aggregator MUST
   interpret the AGGREGATION-SESSION object in the E2E Resv as
   indicating which generic aggregate reservation session the
   corresponding E2E reservation is mapped onto.

   [RSVP-AGG] describes how the Aggregator and Deaggregator can
   communicate their respective identity to each other. For example the
   Aggregator includes one of its IP addresses in the RSVP HOP object in
   the E2E Path which is transmitted downstream and received by the
   Deaggregator once it traversed the aggregation region. Similarly, the
   Deaggregator identifies itself to the Aggregator by including one of
   its IP addresses in various fields, including the ERROR SPECIFICATION
   of the E2E PathErr message (containing the NEW-AGGREGATE-NEEDED Error
   Code), in the AGGREGATION-SESSION object included in the same E2E
   PathErr message and in the RSVP HOP object of the E2E Resv message.
   However, [RSVP-AGG] does not discuss which IP addresses are to be
   selected by the aggregator and Deaggregator for such purposes.
   Because these addresses are intended to identify the Aggregator and
   Deaggregator and not to identify any specific interface on these
   devices, this document RECOMMENDS that the Aggregator and
   Deaggregator SHOULD use interface-independent addresses (for example
   a loopback address) whenever they communicate their respective


Le Faucheur, et al.                                          [Page 14]

                 Generic Aggregate RSVP Reservations    February 2006


   identity to each other. This ensures that respective identification
   of the Aggregator and Deaggregator by any interface state change on
   these devices. In turns this results in more stable operations and
   considerably reduced RSVP signaling in the aggregation region. For
   example, if interface-independent addresses are used by the
   Aggregator and the Deaggregator, then a failure of an interface on
   these devices may simply result in the rerouting of a given generic
   aggregate reservation but will not result in the generic aggregate
   reservation having to be torn down and another one established, nor
   will it result in a change of mapping of E2E reservations on generic
   aggregate reservations (assuming the Aggregator and Deaggregator
   still have reachability after the failure and the Aggregator and
   Deaggregator are still on the shortest path to the destination).

   However, when identifying themselves to real RSVP neighbors (i.e.
   neighbors which are not on the other side of the aggregation region),
   the Aggregator and Deaggregator SHOULD continue using interface-
   dependent addresses as per regular [RSVP] procedures. This applies
   for example when the Aggregator identifies itself downstream as a
   PHOP for the generic aggregate reservation or identifies itself
   upstream as a NHOP for an E2E reservation. This also applies when the
   Deaggregator identifies itself downstream as a PHOP for the E2E
   reservation or identifies itself upstream as a NHOP for the generic
   aggregate reservation. As part of the processing of generic aggregate
   reservations, interior routers (i.e. routers within the aggregation
   region) SHOULD continue using interface-dependent address as per
   regular [RSVP] procedures.

   More generally, within the aggregation region (ie between Aggregator
   and Deaggregator) the operation of RSVP should be modeled with the
   notion that E2E reservations are mapped to aggregate reservations and
   are no longer tied to physical interfaces (as was the case with
   regular RSVP). However, generic aggregate reservations (within the
   aggregation region) as well as E2E reservations outside the
   aggregation region, retain the model of regular RVSP and remain tied
   to physical interfaces.


5.  Example Usage Of Multiple Generic Aggregate Reservations Per DSCP
   From a Given Aggregator to a Given Deaggregator

   Let us consider the environment depicted in Figure 2 below. RSVP
   aggregation is used to support E2E reservations between Cloud-1,
   Cloud-2 and Cloud-3.


                 I----------I               I----------I
                 I  Cloud-1 I               I  Cloud-2 I
                 I----------I               I----------I


Le Faucheur, et al.                                          [Page 15]

                 Generic Aggregate RSVP Reservations    February 2006


                       |                      |
                    Agg-Deag-1------------ Agg-Deag-2
                       /                        \
                      /      Aggregation         |
                     |         Region            |
                     |                           |
                     |                       ---/
                      \                     /
                       \Agg-Deag-3---------/
                             |
                        I----------I
                        I  Cloud-3 I
                        I----------I


                        Figure 2 : Example Usage of
                     Generic Aggregate IP Reservations

   Let us assume that:

       o the E2E reservations from Cloud-1 to Cloud-3 have a preemption
          of either P1 or P2

       o the E2E reservations from Cloud-2 to Cloud-3 have a preemption
          of either P1 or P2

       o the E2E reservations are only for Voice (which needs to be
          treated in the aggregation region using the EF PHB)

       o traffic from the E2E reservations is encapsulated in Aggregate
          IP reservations from Aggregator to Deaggregator using GRE
          tunneling ([GRE]).

   Then, the following generic aggregate RSVP reservations may be
   established from Agg-Deag-1 to Agg-Deag-3 for aggregation of the end-
   to-end RSVP reservations:

   A first generic aggregate reservation for aggregation of Voice
   reservations from Cloud-1 to Cloud-3 requiring use of P1:

          *  GENERIC-AGGREGATE-IPv4 SESSION=
                  IPv4 DestAddress= Agg-Deag-3
                  vDstPort=V1
                  DSCP=EF
                  Extended VDstPort= Agg-Deag-1

          *  STYLE=FF or SE

          *  IPv4/GPI FILTER_SPEC=


Le Faucheur, et al.                                          [Page 16]

                 Generic Aggregate RSVP Reservations    February 2006


                  IPv4 SrcAddress= Agg-Deag-1

          *  POLICY_DATA (PREEMPTION_PRI)=P1

   A second generic aggregate reservation for aggregation of Voice
   reservations from Cloud-1 to Cloud-3 requiring use of P2:

          *  GENERIC-AGGREGATE-IPv4 SESSION=Agg-Deag-3/V2/EF
                  IPv4 DestAddress= Agg-Deag-3
                  vDstPort=V2
                  DSCP=EF
                  Extended VDstPort= Agg-Deag-1

          *  STYLE=FF or SE

          *  IPv4/GPI FILTER_SPEC
                  IPv4 SrcAddress= Agg-Deag-1

          *  POLICY_DATA (PREEMPTION_PRI)=P2

      where V1 and V2 are arbitrary VDstPort values picked by Agg-Deag-3.

   The following generic aggregate RSVP reservations may be established
   from Agg-Deag-2 to Agg-Deag-3 for aggregation of the end-to-end RSVP
   reservations:

   A third generic aggregate reservation for aggregation of Voice
   reservations from Cloud-2 to Cloud-3 requiring use of P1:

          *  GENERIC-AGGREGATE-IPv4 SESSION
                  IPv4 DestAddress= Agg-Deag-3
                  vDstPort=V3
                  DSCP=EF
                  Extended VDstPort= Agg-Deag-2

          *  STYLE=FF or SE

          *  IPv4/GPI FILTER_SPEC
                  IPv4 SrcAddress= Agg-Deag-2

          *  POLICY_DATA (PREEMPTION_PRI)=P1

   A fourth generic aggregate reservation for aggregation of Voice
   reservations from Cloud-2 to Cloud-3 requiring use of P2:

          *  GENERIC-AGGREGATE-IPv4 SESSION
                  IPv4 DestAddress= Agg-Deag-3
                  vDstPort=V4
                  DSCP=EF


Le Faucheur, et al.                                          [Page 17]

                 Generic Aggregate RSVP Reservations    February 2006


                  Extended VDstPort= Agg-Deag-2

          *  STYLE=FF or SE

          *  IPv4/GPI FILTER_SPEC=Agg-Deag-2
                  IPv4 SrcAddress= Agg-Deag-2

          *  POLICY_DATA (PREEMPTION_PRI)=P2

      where V1 and V4 are arbitrary VDstPort values picked by Agg-Deag-3.
      Note that V3 and V4 could be equal to V1 and V2 since, in this
   example, the Extended VDstPort of the GENERIC-AGGREGATE Session
   contains the address of the Deaggregator and, thus, ensures that
   different sessions are used for each Deaggregator.


6.  Security Considerations

   The security considerations associated with the RSVP protocol [RSVP]
   apply to this document as it relies on RSVP.

   When generic aggregate reservations are used for aggregation of E2E
   reservations, the security considerations discussed in [RSVP-AGG]
   apply.

   The security considerations discussed in [SIG-NESTED] apply when the
   generic aggregate reservations are used in the presence of IPsec
   gateways.


7.  IANA Considerations

   This document requests that IANA allocates two new C-Types under the
   Class 1 for the two new RSVP objects (GENERIC-AGGREGATE-IPv4 SESSION
   and GENERIC-AGGREGATE-IPv6 SESSION) defined in section 2.1.

   This document also requests that IANA allocates one new Class-Num and
   two new C-Types for the two new RSVP objects (IPv4-AGGREGATION-
   SESSION and IPv6-AGGREGATION-SESSION) defined in section 2.2.


8.  Acknowledgments

   This document borrows heavily from [RSVP-AGG]. It also borrows the
   concepts of Virtual Destination Port and Extended Virtual Destination
   Port respectively from [RSVP-IPSEC] and [RSVP-TE].

   Also, we thank Fred Baker, Roger Levesque, Carol Iturralde, Daniel



Le Faucheur, et al.                                          [Page 18]

                 Generic Aggregate RSVP Reservations    February 2006


   Voce and Anil Agarwal for their input into the content of this
   document. Thanks to Steve Kent for insightful comments on usage of
   RSVP reservations in IPsec environments.


9.  Normative References

   [RSVP] "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
   Specification", Braden et al, RFC2205

   [RSVP-IPSEC] "RSVP Extensions for IPsec Data Flows", Berger et al,
   RFC2207

   [RSVP-AGG] "Aggregation of RSVP for IPv4 and IPv6 Reservations",
   Baker et al, RFC3175

   [SIG-NESTED] "QoS Signaling in a Nested Virtual Private Network",
   Baker et al, draft-ietf-tsvwg-vpn-signaled-preemption-00.txt, work in
   progress

   [RSVP-PROCESS] "Resource ReSerVation Protocol (RSVP) -- Version 1
   Message Processing Rules", Braden et al, RFC2209

   [IPSEC-ARCH] "Security Architecture for the Internet Protocol", Kent
   et al, RFC2401

   [DS-TUNNEL] "Differentiated Services and Tunnels", Black, RFC2983

   [GRE] Generic Routing Encapsulation (GRE). Farinacci et al, RFC 2784


10.  Informative References

   [BW-REDUC] "A Resource Reservation Extension for the Reduction of
   andwidth of a Reservation Flow", Polk et al, draft-polk-tsvwg-rsvp-
   bw-reduction-01.txt, work in progress

   [RSVP-TUNNEL] "RSVP Operation Over IP Tunnels", Terzis et al., RFC
   2746, January 2000.

   [RSVP-PREEMP]  Herzog, S., "Signaled Preemption Priority Policy
   Element", RFC 3181, October 2001.

   [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels,
   RFC 3209, December 2001.


11.  Authors Address:



Le Faucheur, et al.                                          [Page 19]

                 Generic Aggregate RSVP Reservations    February 2006


   Francois Le Faucheur
   Cisco Systems, Inc.
   Village d'Entreprise Green Side - Batiment T3
   400, Avenue de Roumanille
   06410 Biot Sophia-Antipolis
   France
   Email: flefauch@cisco.com


   Bruce Davie
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, MA 01719
   USA
   Email: bdavie@cisco.com


   Pratik Bose
   Lockheed Martin
   22300 Comsat Drive Clarksburg, MD 20814
   USA
   Email: pratik.bose@lmco. com


   Christou Christou
   Booz Allen Hamilton
   8283 Greensboro Drive
   McLean, VA 22102
   USA
   Email: christou_chris@bah.com


   Michael Davenport
   Booz Allen Hamilton
   8283 Greensboro Drive
   McLean, VA 22102
   USA
   Email: davenport_michael@bah.com


12.  IPR Statements

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information



Le Faucheur, et al.                                          [Page 20]

                 Generic Aggregate RSVP Reservations    February 2006


   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.
   Please address the information to the IETF at ietf-ipr@ietf.org.


13.  Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


14.  Copyright Notice

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


















Le Faucheur, et al.                                          [Page 21]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/