GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4860

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].
  1. ————————-

/ 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
  1. → = 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:
  1. two new objects (GENERIC-AGGREGATE-IP4 SESSION and GENERIC-

AGGREGATE-IP6 SESSION) under the existing SESSION Class, and

  1. 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:
  1. 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.
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4860.txt · Last modified: 2007/05/02 22:55 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki