doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc4860.txt b/doc/rfc/rfc4860.txt
new file mode 100644
index 0000000..b07349d
--- /dev/null
+++ b/doc/rfc/rfc4860.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group                                     F. Le Faucheur
+Request for Comments: 4860                                      B. Davie
+Category: Standards Track                            Cisco Systems, Inc.
+                                                                 P. Bose
+                                                         Lockheed Martin
+                                                             C. Christou
+                                                            M. Davenport
+                                                     Booz Allen Hamilton
+                                                                May 2007
+
+
+  Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP)
+   reservations allowing resources to be reserved in a Diffserv network
+   for a given Per Hop Behavior (PHB), or given set of PHBs, from a
+   given source to a given destination.  RFC 3175 also defines how end-
+   to-end 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 PHB (or set
+   of PHBs).  However, this is not supported by the aggregate
+   reservations defined in RFC 3175.  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
+   PHB (or set of PHBs) 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.
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                     [Page 1]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Related IETF Documents .....................................6
+      1.2. Organization of This Document ..............................6
+      1.3. Requirements Language ......................................7
+   2. Object Definition ...............................................7
+      2.1. SESSION Class ..............................................8
+      2.2. SESSION-OF-INTEREST (SOI) Class ...........................11
+   3. Processing Rules for Handling Generic Aggregate RSVP
+      Reservations ...................................................13
+      3.1. Extensions to Path and Resv Processing ....................13
+   4. Procedures for Aggregation over Generic Aggregate RSVP
+      Reservations ...................................................14
+   5. Example Usage Of Multiple Generic Aggregate Reservations
+      per PHB from a Given Aggregator to a Given Deaggregator ........19
+   6. Security Considerations ........................................21
+   7. IANA Considerations ............................................24
+   8. Acknowledgments ................................................25
+   9. Normative References ...........................................26
+   10. Informative References ........................................26
+   Appendix A. Example Signaling Flow ................................28
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                     [Page 2]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+1.  Introduction
+
+   [RSVP-AGG] defines RSVP aggregate reservations that allow resources
+   to be reserved in a Diffserv network for a flow characterized by its
+   3-tuple <source IP address, destination IP address, Diffserv Code
+   Point>.
+
+   [RSVP-AGG] also defines the procedures for aggregation of end-to-end
+   (E2E) RSVP reservations onto such aggregate reservations when
+   transiting through a Diffserv cloud.  Such aggregation is illustrated
+   in Figure 1.  This document reuses the terminology defined in
+   [RSVP-AGG].
+
+                    --------------------------
+                   /       Aggregation        \
+      |----|      |          Region            |      |----|
+   H--| R  |\ |-----|                       |------| /| R  |-->H
+   H--|    |\\|     |   |---|     |---|     |      |//|    |-->H
+      |----| \|     |   | I |     | I |     |      |/ |----|
+              | Agg |======================>| Deag |
+             /|     |   |   |     |   |     |      |\
+   H--------//|     |   |---|     |---|     |      |\\-------->H
+   H--------/ |-----|                       |------| \-------->H
+                  |                            |
+                   \                          /
+                    --------------------------
+
+   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 Diffserv Code Point (DSCP) of the Per Hop Behavior (PHB) from
+   which Diffserv resources are to be reserved.  For example, in the
+   case of IPv4, the SESSION object is specified as:
+
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                     [Page 3]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+      o  Class = SESSION,
+         C-Type = RSVP-AGGREGATE-IP4
+
+           +-------------+-------------+-------------+-------------+
+           |              IPv4 Session Address (4 bytes)           |
+           +-------------+-------------+-------------+-------------+
+           | /////////// |    Flags    |  /////////  |     DSCP    |
+           +-------------+-------------+-------------+-------------+
+
+   These aggregate reservations use SENDER_TEMPLATE and FILTER_SPEC
+   types, specified in [RSVP-AGG], that contain only the sender (or
+   Aggregator) IP address.  For example, in the case of IPv4, the
+   SENDER_TEMPLATE object is specified as:
+
+      o  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 PHBs (or different sets of PHBs).  However, from a
+   given source IP address to a given IP destination address, only a
+   single [RSVP-AGG] aggregate reservation can be established for a
+   given PHB (or given set of PHBs).
+
+   Situations have since been identified where multiple such aggregate
+   reservations are needed for the same source IP address, destination
+   IP address, and PHB (or set of PHBs).  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 PHB.  Using multiple aggregate reservations for the same PHB
+   allows enforcement of the different preemption priorities within the
+   aggregation region.  In turn, this allows more efficient management
+   of the Diffserv resources, and in periods of resource shortage, this
+   allows sustainment of a larger number of E2E reservations with higher
+   preemption priorities.
+
+   For example, [SIG-NESTED] discusses in detail 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 PHB), each with
+   different preemption priorities, can be used to efficiently support
+   the preemption priorities of end-to-end reservations.
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                     [Page 4]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   This document addresses this requirement for multiple aggregate
+   reservations for the same PHB (or same set of PHBs), 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 PHB.  This
+   allows multiple generic aggregate reservations to be established for
+   a given PHB (or set of PHBs), 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 Port.  This provides a convenient mechanism to
+   narrow the scope of a generic aggregate session to an Aggregator-
+   Deaggregator pair.
+
+   The RSVP SESSION object for generic aggregate reservations uses the
+   PHB Identification Code (PHB-ID) defined in [PHB-ID] to identify the
+   PHB, or set of PHBs, from which the Diffserv resources are to be
+   reserved.  This is instead of using the Diffserv Code Point (DSCP) as
+   per [RSVP-AGG].  Using the PHB-ID instead of the DSCP allows explicit
+   indication of whether the Diffserv resources belong to a single PHB
+   or to a set of PHBs.  It also facilitates handling of situations
+   where a generic aggregate reservation spans two (or more) Diffserv
+   domains that use different DSCP values for the same Diffserv PHB (or
+   set of PHBs) from which resources are reserved.  This is because the
+   PHB-ID allows conveying of the PHB (or set of PHBs) independently of
+   what DSCP value(s) are used locally for that PHB (or set of PHBs).
+
+   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 from those.
+
+
+
+Le Faucheur, et al.         Standards Track                     [Page 5]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   The generic aggregate reservations may also be used end-to-end
+   directly by end-systems attached to a Diffserv network.
+
+1.1.  Related IETF Documents
+
+   This document is heavily based on [RSVP-AGG].  It reuses [RSVP-AGG]
+   wherever applicable and only specifies the necessary extensions
+   beyond [RSVP-AGG].
+
+   The mechanisms defined in [BW-REDUC] allow an existing reservation to
+   be reduced in allocated bandwidth by RSVP routers 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 earlier, 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 and to aggregation of E2E reservations onto those.
+   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 aggregate
+   RSVP reservations.  Section 5 provides example usage of how the
+   generic aggregate reservations may be used.
+
+   The Security Considerations and the IANA Considerations are discussed
+   in Sections 6 and 7, respectively.
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                     [Page 6]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   Finally, Appendix A provides an example signaling flow that
+   illustrates aggregation of E2E RSVP reservations onto generic
+   aggregate RSVP reservations.
+
+1.3.  Requirements Language
+
+   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 RFC 2119 [KEYWORDS].
+
+2.  Object Definition
+
+   This document 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].
+
+   This document defines:
+
+      - two new objects (GENERIC-AGGREGATE-IP4 SESSION and GENERIC-
+        AGGREGATE-IP6 SESSION) under the existing SESSION Class, and
+
+      - two new objects (GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI)
+        under a new SESSION-OF-INTEREST Class.
+
+   Detailed description of these objects is provided below in this
+   section.
+
+   The GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION
+   objects are applicable to all types of RSVP messages.
+
+   This specification defines the use of the GENERIC-AGG-IP4-SOI and
+   GENERIC-AGG-IP6-SOI objects in two circumstances:
+
+      - inside an E2E PathErr message that contains an error code of
+        NEW-AGGREGATE-NEEDED in order to convey the session of a new
+        generic aggregate reservation that needs to be established.
+
+      - inside an E2E Resv message in order to convey the session of the
+        generic aggregate reservation onto which this E2E reservation
+        needs to be mapped.
+
+   Details of the corresponding procedures can be found in Section 4.
+
+   However, it is envisioned that the ability to signal, inside RSVP
+   messages, the Session of another reservation (which has some
+   relationship with the current RSVP reservation) might have some other
+   applicability in the future.  Thus, those objects have been specified
+   in a more generic manner under a flexible SESSION-OF-INTEREST class.
+
+
+
+Le Faucheur, et al.         Standards Track                     [Page 7]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   All the new objects defined in this document are optional with
+   respect to RSVP so that general RSVP implementations that are not
+   concerned with generic aggregate reservations do not have to support
+   these objects.  RSVP routers supporting generic aggregate IPv4 or
+   IPv6 reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION
+   object or the GENERIC-AGGREGATE-IP6 SESSION object, respectively.
+   RSVP routers supporting RSVP aggregation over generic aggregate IPv4
+   or IPv6 reservations MUST support the GENERIC-AGG-IP4-SOI object or
+   GENERIC-AGG-IP6-SOI object, respectively.
+
+2.1.  SESSION Class
+
+   o GENERIC-AGGREGATE-IP4 SESSION object:
+                  Class = 1 (SESSION)
+                  C-Type = 17
+
+               0           7 8          15 16         23 24          31
+              +-------------+-------------+-------------+-------------+
+              |               IPv4 DestAddress (4 bytes)              |
+              +-------------+-------------+-------------+-------------+
+              | Reserved    |     Flags   |          PHB-ID           |
+              +-------------+-------------+-------------+-------------+
+              |          Reserved         |         vDstPort          |
+              +-------------+-------------+-------------+-------------+
+              |                    Extended vDstPort                  |
+              +-------------+-------------+-------------+-------------+
+               0           7 8          15 16         23 24          31
+
+   IPv4 DestAddress (IPv4 Destination Address)
+
+      IPv4 address of the receiver (or Deaggregator).
+
+   Reserved
+
+      An 8-bit field.  All bits MUST be set to 0 on transmit.  This
+      field MUST be ignored on receipt.
+
+   Flags
+
+      An 8-bit field.  The content and processing of this field are the
+      same as for the Flags field of the IPv4/UDP SESSION object (see
+      [RSVP]).
+
+
+
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                     [Page 8]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   PHB-ID (Per Hop Behavior Identification Code)
+
+      A 16-bit field containing the Per Hop Behavior Identification Code
+      of the PHB, or of the set of PHBs, from which Diffserv resources
+      are to be reserved.  This field MUST be encoded as specified in
+      Section 2 of [PHB-ID].
+
+   Reserved
+
+      A 16-bit field.  All bits MUST be set to 0 on transmit.  This
+      field MUST be ignored on receipt.
+
+   VDstPort (Virtual Destination Port)
+
+      A 16-bit identifier used in the SESSION that remains constant over
+      the life of the generic aggregate reservation.
+
+   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.  A sender (or
+      Aggregator) that wishes to narrow the scope of a SESSION to the
+      sender-receiver pair (or Aggregator-Deaggregator pair) SHOULD
+      place its IPv4 address here as a network unique identifier.  A
+      sender (or Aggregator) that wishes to use a common session with
+      other senders (or Aggregators) in order to use a shared
+      reservation across senders (or Aggregators) MUST set this field to
+      all zeros.
+
+   o GENERIC-AGGREGATE-IP6 SESSION object:
+                  Class = 1 (SESSION)
+                  C-Type = 18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                     [Page 9]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+               0           7 8          15 16         23 24          31
+              +-------------+-------------+-------------+-------------+
+              |                                                       |
+              +                                                       +
+              |                                                       |
+              +               IPv6 DestAddress (16 bytes)             +
+              |                                                       |
+              +                                                       +
+              |                                                       |
+              +-------------+-------------+-------------+-------------+
+              | Reserved    |     Flags   |          PHB-ID           |
+              +-------------+-------------+-------------+-------------+
+              |          Reserved         |         vDstPort          |
+              +-------------+-------------+-------------+-------------+
+              |                                                       |
+              +                                                       +
+              |                     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
+
+      An 8-bit field.  All bits MUST be set to 0 on transmit.  This
+      field MUST be ignored on receipt.
+
+   Flags
+
+      An 8-bit field.  The content and processing of this field are the
+      same as for the Flags field of the IPv6/UDP SESSION object (see
+      [RSVP]).
+
+   PHB-ID (Per Hop Behavior Identification Code)
+
+      A 16-bit field containing the Per Hop Behavior Identification Code
+      of the PHB, or of the set of PHBs, from which Diffserv resources
+      are to be reserved.  This field MUST be encoded as specified in
+      Section 2 of [PHB-ID].
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 10]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   Reserved
+
+      A 16-bit field.  All bits MUST be set to 0 on transmit.  This
+      field MUST be ignored on receipt.
+
+   VDstPort (Virtual Destination Port)
+
+      A 16-bit identifier used in the SESSION that remains constant over
+      the life of the generic aggregate reservation.
+
+   Extended vDstPort (Extended Virtual Destination Port)
+
+      A 128-bit identifier used in the SESSION that remains constant
+      over the life of the generic aggregate reservation.  A sender (or
+      Aggregator) that wishes to narrow the scope of a SESSION to the
+      sender-receiver pair (or Aggregator-Deaggregator pair) SHOULD
+      place its IPv6 address here as a network unique identifier.  A
+      sender (or Aggregator) that wishes to use a common session with
+      other senders (or Aggregators) in order to use a shared
+      reservation across senders (or Aggregators) MUST set this field to
+      all zeros.
+
+2.2.  SESSION-OF-INTEREST (SOI) Class
+
+   o GENERIC-AGG-IP4-SOI object:
+                  Class = 132
+                  C-Type = 1
+
+            0           7 8          15 16         23 24          31
+            +-------------+-------------+-------------+-------------+
+            |                           | SOI         |GEN-AGG-IP4- |
+            |       Length (bytes)      | Class-Num   |SOI C-Type   |
+            +-------------+-------------+-------------+-------------+
+            |                                                       |
+            //  Content of a GENERIC-AGGREGATE-IP4 SESSION Object  //
+            |                                                       |
+            +-------------+-------------+-------------+-------------+
+
+   Content of a GENERIC-AGGREGATE-IP4 SESSION Object:
+
+      This field contains a copy of the SESSION object of the session
+      that is of interest for the reservation.  In the case of a
+      GENERIC-AGG-IP4-SOI, the session of interest conveyed in this
+      field is a GENERIC-AGGREGATE-IP4 SESSION.
+
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 11]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   o GENERIC-AGG-IP6-SOI object:
+                  Class = 132
+                  C-Type = 2
+
+            0           7 8          15 16         23 24          31
+            +-------------+-------------+-------------+-------------+
+            |                           | SOI         |GEN-AGG-IP6- |
+            |       Length (bytes)      | Class-Num   |SOI C-Type   |
+            +-------------+-------------+-------------+-------------+
+            |                                                       |
+            //  Content of a GENERIC-AGGREGATE-IP6 SESSION Object  //
+            |                                                       |
+            +-------------+-------------+-------------+-------------+
+
+   Content of a GENERIC-AGGREGATE-IP6 SESSION Object:
+
+      This field contains a copy of the SESSION object of the session
+      that is of interest for the reservation.  In the case of a
+      GENERIC-AGG-IP6-SOI, the session of interest conveyed in this
+      field is a GENERIC-AGGREGATE-IP6 SESSION.
+
+   For example, if a SESSION-OF-INTEREST object is used inside an E2E
+   Resv message (as per the procedures defined in Section 4) to indicate
+   which generic aggregate IPv4 session the E2E reservation is to be
+   mapped onto, then the GENERIC-AGG-IP4-SOI object will be used, and it
+   will be encoded like this:
+
+             0           7 8          15 16         23 24          31
+            +-------------+-------------+-------------+-------------+
+            |                           | SOI         |GEN-AGG-IP4- |
+            |       Length (bytes)      | Class-Num   |SOI C-Type   |
+            +-------------+-------------+-------------+-------------+
+            |               IPv4 DestAddress (4 bytes)              |
+            +-------------+-------------+-------------+--+----------+
+            | Reserved    |     Flags   |          PHB-ID           |
+            +-------------+-------------+-------------+-------------+
+            |          Reserved         |         vDstPort          |
+            +-------------+-------------+-------------+-------------+
+            |                    Extended vDstPort                  |
+            +-------------+-------------+-------------+-------------+
+             0           7 8          15 16         23 24          31
+
+   Note that a SESSION-OF-INTEREST object is not a SESSION object in
+   itself.  It does not replace the SESSION object in RSVP messages.  It
+   does not modify the usage of the SESSION object in RSVP messages.  It
+   simply allows conveying the Session of another RSVP reservation
+   inside RSVP signaling messages, for some particular purposes.  In the
+   context of this document, it is used to convey, inside an E2E RSVP
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 12]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   message pertaining to an end-to-end reservation, the Session of a
+   generic aggregate reservation associated with the E2E reservation.
+   Details for the corresponding procedures are specified in Section 4.
+
+3.  Processing Rules for Handling Generic Aggregate RSVP Reservations
+
+   This section presents extensions to the processing of RSVP messages
+   required by [RSVP] and presented in [RSVP-PROCESS].  These extensions
+   are required in order to properly process the GENERIC-AGGREGATE-IP4
+   or GENERIC-AGGREGATE-IP6 SESSION object and the RSVP-AGGREGATE-IP4 or
+   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-IP4 and GENERIC-
+   AGGREGATE-IP6 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.  Extensions to Path and Resv Processing
+
+   The following PATH message processing changes are defined:
+
+      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.
+
+      o For PATH messages that contain the GENERIC-AGGREGATE SESSION
+        object, the VDstPort value, the Extended VDstPort value, and the
+        PHB-ID 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 PHB-ID 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.
+
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 13]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   The following changes to RESV message processing are defined:
+
+      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 uses data classifiers as per the
+        following:
+
+        * to perform Diffserv classification the node MUST rely on the
+          Diffserv data classifier based on the DSCP only.  The relevant
+          DSCP value(s) are those that are associated with the PHB-ID of
+          the generic aggregate reservation.
+
+        * If the node also needs to perform fine-grain classification
+          (for example, to perform fine-grain input policing at a trust
+          boundary) then the node MUST create a data classifier
+          described by the 3-tuple <DestAddress, SrcAddress, DSCP>.
+
+          The relevant DSCP value(s) are those that are associated with
+          the PHB-ID of the generic aggregate reservation.
+
+          Note that if multiple generic aggregate reservations are
+          established with different Virtual Destination Ports (and/or
+          different Extended Virtual Destination Ports) but with the
+          same <DestAddress, SrcAddress, PHB-ID>, 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.
+
+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
+   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
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 14]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   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 a SESSION-OF-INTEREST object that contains the
+   GENERIC-AGGREGATE SESSION to be used for establishment of the
+   requested generic aggregate reservation.  Since this GENERIC-
+   AGGREGATE SESSION contains the PHB-ID, 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 GENERIC-
+   AGGREGATE SESSION included in the SESSION-OF-INTEREST 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
+   GENERIC-AGGREGATE SESSION inside the SESSION-OF-INTEREST object in
+   the E2E PathErr messages sent to these Aggregators.  The Aggregators
+   could then all establish an Aggregate Path with the same GENERIC-
+   AGGREGATE 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 newly 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
+   received with an error code of NEW-AGGREGATE-NEEDED by the Aggregator
+   are extended correspondingly.  On receipt of such a message
+   containing a SESSION-OF-INTEREST object, the Aggregator MUST trigger
+   establishment of a generic aggregate reservation.  In particular, it
+   MUST start sending aggregate Path messages with the GENERIC-AGGREGATE
+   SESSION found in the received SESSION-OF-INTEREST object.  When an
+   RSVP Signaled Preemption Priority Policy Element is contained in the
+   received E2E PathErr message, the Aggregator MUST include this object
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 15]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   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 in the Sender-
+   Template) for the generic aggregate reservation, the address it uses
+   to identify itself as the PHOP (RSVP previous hop) 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, a Deaggregator behaving according to the
+   present specification 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 SESSION-OF-INTEREST object in
+   the E2E Resv message, in order to indicate to the Aggregator the
+   generic aggregate session to map a given E2E reservation onto.
+   Again, since the GENERIC-AGGREGATE SESSION (included in the SESSION-
+   OF-INTEREST object) contains the PHB-ID, the DCLASS object need not
+   be included in the E2E Resv message.  The Aggregator MUST interpret
+   the SESSION-OF-INTEREST object in the E2E Resv as indicating which
+   generic aggregate reservation session the corresponding E2E
+   reservation is mapped onto.  The Aggregator MUST not include the
+   SESSION-OF-INTEREST object when sending an E2E Resv upstream towards
+   the sender.
+
+   Based on relevant policy, the Deaggregator may decide at some point
+   that an aggregate reservation is no longer needed and should be torn
+   down.  In that case, the Deaggregator MUST send an aggregate
+   ResvTear.  On receipt of the aggregate ResvTear, the Aggregator
+   SHOULD send an aggregate PathTear (unless the relevant policy
+   instructs the Aggregator to do otherwise or to wait for some time
+   before doing so, for example in order to speed up potential re-
+   establishment of the aggregate reservation in the future).
+
+   [RSVP-AGG] describes how the Aggregator and Deaggregator can
+   communicate their respective identities to each other.  For example,
+   the Aggregator includes one of its IP addresses in the RSVP HOP
+   object in the E2E Path that is transmitted downstream and received by
+   the Deaggregator once it traversed the aggregation region.
+   Similarly, the Deaggregator identifies itself to the Aggregator by
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 16]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   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) 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 identities to each other.  This ensures that
+   respective identification of the Aggregator and Deaggregator is not
+   impacted by any interface state change on these devices.  In turn,
+   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.  Moreover, it
+   will not 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 that 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 (RSVP next hop) 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 addresses as per regular [RSVP] procedures.
+
+   More generally, within the aggregation region (i.e., 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.
+
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 17]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   As discussed above, generic aggregate reservations may be established
+   edge-to-edge as a result of the establishment of E2E reservations
+   (from outside the aggregation region) that are to be aggregated over
+   the aggregation region.  However, generic aggregate reservations may
+   also be used end-to-end by end-systems directly attached to a
+   Diffserv domain, such as Public Switched Telephone Network (PSTN)
+   gateways.  In that case, the generic aggregate reservations may be
+   established by the end-systems in response to application-level
+   triggers such as voice call signaling.  Alternatively, generic
+   aggregate reservations may also be used edge-to-edge to manage
+   bandwidth in a Diffserv cloud even if RSVP is not used end-to-end.  A
+   simple example of such a usage would be the static configuration of a
+   generic aggregate reservation for a certain bandwidth for traffic
+   from an ingress (Aggregator) router to an egress (Deaggregator)
+   router.
+
+   In this case, the establishment of the generic aggregate reservations
+   is controlled by configuration on the Aggregator and on the
+   Deaggregator.  Configuration on the Aggregator triggers generation of
+   the aggregate Path message and provides sufficient information to the
+   Aggregator to derive the content of the GENERIC-AGGREGATE SESSION
+   object.  This would typically include Deaggregator IP address, PHB-ID
+   and possibly VDstPort.  Configuration on the Deaggregator would
+   instruct the Deaggregator to respond to a received generic aggregate
+   Path message and would provide sufficient information to the
+   Deaggregator to control the reservation.  This may include bandwidth
+   to be reserved by the Deaggregator (for a given <Deaggregator,
+   PHB-ID, VDstPort> tuple).
+
+   In the absence of E2E microflow reservations, the Aggregator can use
+   a variety of policies to set the DSCP of packets passing into the
+   aggregation region and how they are mapped onto generic aggregate
+   reservations, thus determining whether they gain access to the
+   resources reserved by the aggregate reservation.  These policies are
+   a matter of local configuration, as is typical for a device at the
+   edge of a Diffserv cloud.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 18]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+5.  Example Usage Of Multiple Generic Aggregate Reservations per PHB
+    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
+                       |                      |
+                    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 -Expedited
+        Forwarding- PHB).
+
+      o Traffic from the E2E reservations is encapsulated in aggregate
+        IP reservations from Aggregator to Deaggregator using Generic
+        Routing Encapsulation [GRE] tunneling.
+
+   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:
+
+   (1) A first generic aggregate reservation for aggregation of Voice
+       reservations from Cloud-1 to Cloud-3 requiring use of P1:
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 19]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+          *  GENERIC-AGGREGATE-IP4 SESSION:
+                  IPv4 DestAddress = Agg-Deag-3
+                  vDstPort = V1
+                  PHB-ID = EF
+                  Extended VDstPort = Agg-Deag-1
+
+          *  STYLE = FF or SE
+
+          *  IPv4/GPI FILTER_SPEC:
+                  IPv4 SrcAddress = Agg-Deag-1
+
+          *  POLICY_DATA (PREEMPTION_PRI) = P1
+
+   (2) A second generic aggregate reservation for aggregation of Voice
+       reservations from Cloud-1 to Cloud-3 requiring use of P2:
+
+          *  GENERIC-AGGREGATE-IP4 SESSION:
+                  IPv4 DestAddress = Agg-Deag-3
+                  vDstPort = V2
+                  PHB-ID = 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:
+
+   (3) A third generic aggregate reservation for aggregation of Voice
+       reservations from Cloud-2 to Cloud-3 requiring use of P1:
+
+          *  GENERIC-AGGREGATE-IP4 SESSION:
+                  IPv4 DestAddress = Agg-Deag-3
+                  vDstPort = V3
+                  PHB-ID = EF
+                  Extended VDstPort = Agg-Deag-2
+
+          *  STYLE = FF or SE
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 20]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+          *  IPv4/GPI FILTER_SPEC:
+                  IPv4 SrcAddress = Agg-Deag-2
+
+          *  POLICY_DATA (PREEMPTION_PRI) = P1
+
+   (4) A fourth generic aggregate reservation for aggregation of Voice
+       reservations from Cloud-2 to Cloud-3 requiring use of P2:
+
+          *  GENERIC-AGGREGATE-IP4 SESSION:
+                  IPv4 DestAddress = Agg-Deag-3
+                  vDstPort = V4
+                  PHB-ID = EF
+                  Extended VDstPort = Agg-Deag-2
+
+          *  STYLE = FF or SE
+
+          *  IPv4/GPI FILTER_SPEC:
+                  IPv4 SrcAddress = Agg-Deag-2
+
+          *  POLICY_DATA (PREEMPTION_PRI) = P2
+
+       where V3 and V4 are arbitrary VDstPort values picked by Agg-
+       Deag-3.
+
+       Note that V3 and V4 could be equal to V1 and V2 (respectively)
+       since, in this example, the Extended VDstPort of the GENERIC-
+       AGGREGATE Session contains the address of the Aggregator and,
+       thus, ensures that different sessions are used from each
+       Aggregator.
+
+6.  Security Considerations
+
+   In the environments addressed by this document, RSVP messages are
+   used to control resource reservations for generic aggregate
+   reservations and may be used to control resource reservations for E2E
+   reservations being aggregated over the generic aggregate
+   reservations.  To ensure the integrity of the associated reservation
+   and admission control mechanisms, the RSVP Authentication mechanisms
+   defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] may be used.  These
+   protect RSVP message integrity hop-by-hop and provide node
+   authentication as well as replay protection, thereby protecting
+   against corruption and spoofing of RSVP messages.  These hop-by-hop
+   integrity mechanisms can be naturally used to protect the RSVP
+   messages used for generic aggregate reservations and to protect RSVP
+   messages used for E2E reservations outside the aggregation region.
+   These hop-by-hop RSVP integrity mechanisms can also be used to
+   protect RSVP messages used for E2E reservations when those transit
+   through the aggregation region.  This is because the Aggregator and
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 21]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   Deaggregator behave as RSVP neighbors from the viewpoint of the E2E
+   flows (even if they are not necessarily IP neighbors).
+
+   [RSVP-CRYPTO1] discusses several approaches for key distribution.
+   First, the RSVP Authentication shared keys can be distributed
+   manually.  This is the base option and its support is mandated for
+   any implementation.  However, in some environments, this approach may
+   become a burden if keys frequently change over time.  Alternatively,
+   a standard key management protocol for secure key distribution can be
+   used.  However, existing key distribution protocols may not be
+   appropriate in all environments because of the complexity or
+   operational burden they involve.
+
+   The use of RSVP Authentication in parts of the network where there
+   may be one or more IP hops in between two RSVP neighbors raises an
+   additional challenge.  This is because, with some RSVP messages such
+   as a Path message, an RSVP router does not know the RSVP next hop for
+   that message at the time of forwarding it.  In fact, part of the role
+   of a Path message is precisely to discover the RSVP next hop (and to
+   dynamically re-discover it when it changes, say because of a routing
+   change).  Hence, the RSVP router may not know which security
+   association to use when forwarding such a message.  This applies in
+   particular to the case where RSVP Authentication mechanisms are to be
+   used for protection of RSVP E2E messages (e.g., E2E Path) while they
+   transit through an aggregation region and where the dynamic
+   Deaggregator determination procedure defined in [RSVP-AGG] is used.
+   This is because the Aggregator and the Deaggregator behave as RSVP
+   neighbors for the E2E reservation, while there may be one or more IP
+   hops in between them, and the Aggregator does not know ahead of time
+   which router is going to act as the Deaggregator.
+
+   In that situation, one approach is to share the same RSVP
+   Authentication shared key across all the RSVP routers of a part of
+   the network where there may be RSVP neighbors with IP hops in
+   between.  For example, all the Aggregators or Deaggregators of an
+   aggregation region could share the same RSVP Authentication key,
+   while different per-neighbor keys could be used between any RSVP
+   router pair straddling the boundary between two administrative
+   domains that have agreed to use RSVP signaling.
+
+   When the same RSVP Authentication shared key is to be shared among
+   multiple RSVP neighbors, manual key distribution may be used.  For
+   situations where RSVP is being used for multicast flows, it might
+   also be possible, in the future, to adapt a multicast key management
+   method (e.g.  from IETF Multicast Security Working Group) for key
+   distribution with such multicast RSVP usage.  For situations where
+   RSVP is being used for unicast flows across domain boundaries, it is
+   not currently clear how one might provide automated key management.
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 22]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   Specification of a specific automated key management technique is
+   outside the scope of this document.  Operators should consider these
+   key management issues when contemplating deployment of this
+   specification.
+
+   The RSVP Authentication mechanisms do not provide confidentiality.
+   If confidentiality is required, IPsec ESP [IPSEC-ESP] may be used,
+   although it imposes the burden of key distribution.  It also faces
+   the additional issue discussed for key management above in the case
+   where there can be IP hops in between RSVP hops.  In the future,
+   confidentiality solutions may be developed for the case where there
+   can be IP hops in between RSVP hops, perhaps by adapting
+   confidentiality solutions developed by the IETF MSEC Working Group.
+   Such confidentiality solutions for RSVP are outside the scope of this
+   document.
+
+   Protection against traffic analysis is also not provided by RSVP
+   Authentication.  Since generic aggregate reservations are intended to
+   reserve resources collectively for a whole set of users or hosts,
+   malicious snooping of the corresponding RSVP messages could provide
+   more traffic analysis information than snooping of an E2E
+   reservation.  When RSVP neighbors are directly attached, mechanisms
+   such as bulk link encryption might be used when protection against
+   traffic analysis is required.  This approach could be used inside the
+   aggregation region for protection of the generic aggregate
+   reservations.  It may also be used outside the aggregation region for
+   protection of the E2E reservation.  However, it is not applicable to
+   the protection of E2E reservations while the corresponding E2E RSVP
+   messages transit through the aggregation region.
+
+   When generic aggregate reservations are used for aggregation of E2E
+   reservations, the security considerations discussed in [RSVP-AGG]
+   apply and are revisited here.
+
+   First, the loss of an aggregate reservation to an aggressor causes
+   E2E flows to operate unreserved, and the reservation of a great
+   excess of bandwidth may result in a denial of service.  These issues
+   are not confined to the extensions defined in the present document:
+   RSVP itself has them.  However, they may be exacerbated here by the
+   fact that each aggregate reservation typically facilitates
+   communication for many sessions.  Hence, compromising one such
+   aggregate reservation can result in more damage than compromising a
+   typical E2E reservation.  Use of the RSVP Authentication mechanisms
+   to protect against such attacks has been discussed above.
+
+   An additional security consideration specific to RSVP aggregation
+   involves the modification of the IP protocol number in RSVP Path
+   messages that traverse an aggregation region.  Malicious modification
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 23]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   of the IP protocol number in a Path message would cause the message
+   to be ignored by all subsequent RSVP devices on its path, preventing
+   reservations from being made.  It could even be possible to correct
+   the value before it reached the receiver, making it difficult to
+   detect the attack.  Note that, in theory, it might also be possible
+   for a node to modify the IP protocol number for non-RSVP messages as
+   well, thus interfering with the operation of other protocols.  It is
+   RECOMMENDED that implementations of this specification only support
+   modification of the IP protocol number for RSVP Path, PathTear, and
+   ResvConf messages.  That is, a general facility for modification of
+   the IP protocol number SHOULD NOT be made available.
+
+   Network operators deploying routers with RSVP aggregation capability
+   should be aware of the risks of inappropriate modification of the IP
+   protocol number and should take appropriate steps (physical security,
+   password protection, etc.) to reduce the risk that a router could be
+   configured by an attacker to perform malicious modification of the
+   protocol number.
+
+7.  IANA Considerations
+
+   IANA modified the RSVP parameters registry, 'Class Names, Class
+   Numbers, and Class Types' subregistry, and assigned two new C-Types
+   under the existing SESSION Class (Class number 1), as described
+   below:
+
+   Class
+   Number  Class Name                            Reference
+   ------  -----------------------               ---------
+
+        1  SESSION                               [RFC2205]
+
+           Class Types or C-Types:
+
+            17   GENERIC-AGGREGATE-IP4           [RFC4860]
+            18   GENERIC-AGGREGATE-IP6           [RFC4860]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 24]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   IANA also modified the RSVP parameters registry, 'Class Names, Class
+   Numbers, and Class Types' subregistry, and assigned one new Class
+   Number for the SESSION-OF-INTEREST class and two new C-Types for that
+   class, according to the table below:
+
+   Class
+   Number  Class Name                            Reference
+   ------  -----------------------               ---------
+
+      132  SESSION-OF-INTEREST                   [RFC4860]
+
+           Class Types or C-Types:
+
+              1  GENERIC-AGG-IP4-SOI             [RFC4860]
+              2  GENERIC-AGG-IP6-SOI             [RFC4860]
+
+   These allocations are in accordance with [RSVP-MOD].
+
+8.  Acknowledgments
+
+   This document borrows heavily from [RSVP-AGG].  It also borrows the
+   concepts of Virtual Destination Port and Extended Virtual Destination
+   Port from [RSVP-IPSEC] and [RSVP-TE], respectively.
+
+   Also, we thank Fred Baker, Roger Levesque, Carol Iturralde, Daniel
+   Voce, Anil Agarwal, Alexander Sayenko, and Anca Zamfir for their
+   input into the content of this document.  Thanks to Steve Kent for
+   insightful comments on usage of RSVP reservations in IPsec
+   environments.
+
+   Ran Atkinson, Fred Baker, Luc Billot, Pascal Delprat, and Eric Vyncke
+   provided guidance and suggestions for the security considerations
+   section.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 25]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+9.  Normative References
+
+   [IPSEC-ESP]    Kent, S., "IP Encapsulating Security Payload (ESP)",
+                  RFC 4303, December 2005.
+
+   [KEYWORDS]     Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [PHB-ID]       Black, D., Brim, S., Carpenter, B., and F. Le
+                  Faucheur, "Per Hop Behavior Identification Codes", RFC
+                  3140, June 2001.
+
+   [RSVP]         Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,
+                  and S. Jamin, "Resource ReSerVation Protocol (RSVP) --
+                  Version 1 Functional Specification", RFC 2205,
+                  September 1997.
+
+   [RSVP-AGG]     Baker, F., Iturralde, C., Le Faucheur, F., and B.
+                  Davie, "Aggregation of RSVP for IPv4 and IPv6
+                  Reservations", RFC 3175, September 2001.
+
+   [RSVP-CRYPTO1] Baker, F., Lindell, B., and M. Talwar, "RSVP
+                  Cryptographic Authentication", RFC 2747, January 2000.
+
+   [RSVP-CRYPTO2] Braden, R. and L. Zhang, "RSVP Cryptographic
+                  Authentication -- Updated Message Type Value", RFC
+                  3097, April 2001.
+
+   [RSVP-IPSEC]   Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
+                  Data Flows", RFC 2207, September 1997.
+
+   [RSVP-MOD]     Kompella, K. and J. Lang, "Procedures for Modifying
+                  the Resource reSerVation Protocol (RSVP)", BCP 96, RFC
+                  3936, October 2004.
+
+10.  Informative References
+
+   [BW-REDUC]     Polk, J. and S. Dhesikan, "A Resource Reservation
+                  Protocol (RSVP) Extension for the Reduction of
+                  Bandwidth of a Reservation Flow", RFC 4495, May 2006.
+
+   [GRE]          Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
+                  Traina, "Generic Routing Encapsulation (GRE)", RFC
+                  2784, March 2000.
+
+   [RSVP-PREEMP]  Herzog, S., "Signaled Preemption Priority Policy
+                  Element", RFC 3181, October 2001.
+
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 26]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+   [RSVP-PROCESS] Braden, R. and L. Zhang, "Resource ReSerVation
+                  Protocol (RSVP) -- Version 1 Message Processing
+                  Rules", RFC 2209, September 1997.
+
+   [RSVP-TE]      Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
+                  V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
+                  LSP Tunnels", RFC 3209, December 2001.
+
+   [RSVP-TUNNEL]  Terzis, A., Krawczyk, J., Wroclawski, J., and L.
+                  Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
+                  January 2000.
+
+   [SIG-NESTED]   Baker, F. and P. Bose, "QoS Signaling in a Nested
+                  Virtual Private Network", Work in Progress, February
+                  2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 27]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+Appendix A.  Example Signaling Flow
+
+   This appendix does not provide additional specification.  It only
+   illustrates the specification detailed in Section 4 through a
+   possible flow of RSVP signaling messages.  This flow assumes an
+   environment where E2E reservations are aggregated over generic
+   aggregate RSVP reservations.  It illustrates a possible RSVP message
+   flow that could take place in the successful establishment of a
+   unicast E2E reservation that is the first between a given pair of
+   Aggregator/Deaggregator.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 28]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+           Aggregator                              Deaggregator
+
+    E2E Path
+   ----------->
+                (1)
+                           E2E Path
+                   ------------------------------->
+                                                       (2)
+                    E2E PathErr(New-agg-needed,SOI=GAx)
+                   <----------------------------------
+                    E2E PathErr(New-agg-needed,SOI=GAy)
+                   <----------------------------------
+                (3)
+                         AggPath(Session=GAx)
+                   ------------------------------->
+                         AggPath(Session=GAy)
+                   ------------------------------->
+                                                       (4)
+                                                           E2E Path
+                                                          ----------->
+                                                       (5)
+                         AggResv (Session=GAx)
+                   <-------------------------------
+                         AggResv (Session=GAy)
+                   <-------------------------------
+                (6)
+                     AggResvConfirm (Session=GAx)
+                   ------------------------------>
+                     AggResvConfirm (Session=GAy)
+                   ------------------------------>
+                                                       (7)
+                                                           E2E Resv
+                                                          <---------
+                                                       (8)
+                           E2E Resv (SOI=GAx)
+                   <-----------------------------
+                (9)
+      E2E Resv
+   <-----------
+
+   (1) The Aggregator forwards E2E Path into the aggregation region
+       after modifying its IP protocol number to RSVP-E2E-IGNORE
+
+   (2) Let's assume no Aggregate Path exists.  To be able to accurately
+       update the ADSPEC of the E2E Path, the Deaggregator needs the
+       ADSPEC of Aggregate Path.  In this example, the Deaggregator
+       elects to instruct the Aggregator to set up Aggregate Path states
+       for the two supported PHB-IDs.  To do that, the Deaggregator
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 29]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+       sends two E2E PathErr messages with a New-Agg-Needed PathErr
+       code.  Both PathErr messages also contain a SESSION-OF-INTEREST
+       (SOI) object.  In the first E2E PathErr, the SOI contains a
+       GENERIC-AGGREGATE SESSION (GAx) whose PHB-ID is set to x.  In the
+       second E2E PathErr, the SOI contains a GENERIC-AGGREGATE SESSION
+       (GAy) whose PHB-ID is set to y.  In both messages the GENERIC-
+       AGGREGATE SESSION contains an interface-independent Deaggregator
+       address inside the DestAddress and appropriate values inside the
+       vDstPort and Extended vDstPort fields.
+
+   (3) The Aggregator follows the request from the Deaggregator and
+       signals an Aggregate Path for both GENERIC-AGGREGATE Sessions
+       (GAx and GAy).
+
+   (4) The Deaggregator takes into account the information contained in
+       the ADSPEC from both Aggregate Paths and updates the E2E Path
+       ADSPEC accordingly.  The Deaggregator also modifies the E2E Path
+       IP protocol number to RSVP before forwarding it.
+
+   (5) In this example, the Deaggregator elects to immediately proceed
+       with establishment of generic aggregate reservations for both
+       PHB-IDs.  In effect, the Deaggregator can be seen as anticipating
+       the actual demand of E2E reservations so that resources are
+       available on the generic aggregate reservations when the E2E Resv
+       requests arrive, in order to speed up establishment of E2E
+       reservations.  Assume also that the Deaggregator includes the
+       optional Resv Confirm Request in these Aggregate Resv.
+
+   (6) The Aggregator merely complies with the received ResvConfirm
+       Request and returns the corresponding Aggregate ResvConfirm.
+
+   (7) The Deaggregator has explicit confirmation that both Aggregate
+       Resvs are established.
+
+   (8) On receipt of the E2E Resv, the Deaggregator applies the mapping
+       policy defined by the network administrator to map the E2E Resv
+       onto a generic aggregate reservation.  Let's assume that this
+       policy is such that the E2E reservation is to be mapped onto the
+       generic aggregate reservation with PHB-ID=x.  The Deaggregator
+       knows that a generic aggregate reservation (GAx) is in place for
+       the corresponding PHB-ID since (7).  The Deaggregator performs
+       admission control of the E2E Resv onto the generic aggregate
+       reservation for PHB-ID=x (GAx).  Assuming that the generic
+       aggregate reservation for PHB-ID=x (GAx) had been established
+       with sufficient bandwidth to support the E2E Resv, the
+       Deaggregator adjusts its counter, tracking the unused bandwidth
+       on the generic aggregate reservation.  Then it forwards the E2E
+       Resv to the Aggregator including a SESSION-OF-INTEREST object
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 30]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+       conveying the selected mapping onto GAx (and hence onto
+       PHB-ID=x).
+
+   (9) The Aggregator records the mapping of the E2E Resv onto GAx (and
+       onto PHB-ID=x).  The Aggregator removes the SOI object and
+       forwards the E2E Resv towards the sender.
+
+Authors' Addresses
+
+   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.
+   1414 Massachusetts Ave.
+   Boxborough, MA 01719
+   USA
+   EMail: bds@cisco.com
+
+   Pratik Bose
+   Lockheed Martin
+   700 North Frederick Ave.
+   Gaithersburg, MD 20879
+   USA
+   EMail: pratik.bose@lmco.com
+
+   Chris Christou
+   Booz Allen Hamilton
+   13200 Woodland Park Road
+   Herndon, VA 20171
+   USA
+   EMail: christou_chris@bah.com
+
+   Michael Davenport
+   Booz Allen Hamilton
+   Suite 390
+   5220 Pacific Concourse Drive
+   Los Angeles, CA 90045
+   USA
+   EMail: davenport_michael@bah.com
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 31]
+
+RFC 4860          Generic Aggregate RSVP Reservations           May 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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.
+
+   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, THE IETF TRUST 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.
+
+Intellectual Property
+
+   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
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Le Faucheur, et al.         Standards Track                    [Page 32]
+