Generic Aggregate RSVP Reservations        June 2006 
 
 
                                                                        
   Internet Draft                                  Francois Le Faucheur 
                                                            Bruce Davie 
                                                    Cisco Systems, Inc. 
                                                                        
                                                            Pratik Bose 
                                                        Lockheed Martin 
                                                                        
                                                         Chris Christou 
                                                      Michael Davenport 
                                                    Booz Allen Hamilton 
   draft-ietf-tsvwg-rsvp-ipsec-01.txt                                   
   Expires: December 2006                                     June 2006 
    
    
                    Generic Aggregate RSVP Reservations 
                    draft-ietf-tsvwg-rsvp-ipsec-01.txt 
                                      
    
    
    
Status of this Memo 
    
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that other 
   groups may also distribute working documents as Internet-Drafts.   
         
   Internet-Drafts are draft documents valid for a maximum of six months 
   and  may be updated, replaced, or obsoleted by other documents at any 
   time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress."   
         
   The list of current Internet-Drafts can be accessed at  
       http://www.ietf.org/ietf/1id-abstracts.txt.   
         
   The list of Internet-Draft Shadow Directories can be accessed at  
       http://www.ietf.org/shadow.html. 
    
    
Abstract 
    
   [RSVP-AGG] defines aggregate RSVP reservations allowing resources to 
   be reserved in a Diffserv network for a given DSCP from a given 
   source to a given destination. [RSVP-AGG] also defines how end-to-end 
 
 
Le Faucheur, et al.                                           [Page 1] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
   RSVP reservations can be aggregated onto such aggregate reservations 
   when transiting through a Diffserv cloud. There are situations where 
   multiple such aggregate reservations are needed for the same source 
   IP address, destination IP address and DSCP. However, this is not 
   supported by the aggregate reservations defined in [RSVP-AGG]. In 
   order to support this, the present document defines a more flexible 
   type of aggregate RSVP reservations, referred to as generic aggregate 
   reservation. Multiple such generic aggregate reservations can be 
   established for a given DSCP from a given source IP address to a 
   given destination IP address. The generic aggregate reservations may 
   be used to aggregate end-to-end RSVP reservations. This document also 
   defines the procedures for such aggregation. The generic aggregate 
   reservations may also be used end-to-end directly by end-systems 
   attached to a Diffserv network. 
    
    
Copyright Notice 
   Copyright (C) The Internet Society (2006). 
    
 
Specification of Requirements 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in [RFC2119]. 
    
    
1.  Introduction 
    
   [RSVP-AGG] defines RSVP aggregate reservations allowing resources to 
   be reserved in a Diffserv network for a flow characterized by its 3-
   tuple <source IP address, destination IP address, DSCP>.  
    
   [RSVP-AGG] also defines the procedures for aggregation of end-to-end 
   RSVP reservations onto such aggregate reservations when transiting 
   through a Diffserv cloud. Such aggregation is illustrated in Figure 1. 
   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 
 
 
Le Faucheur, et al.                                           [Page 2] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
                  |                            | 
                   \                          / 
                    -------------------------- 
    
   H       = Host requesting end-to-end RSVP reservations 
   R       = RSVP router 
   Agg     = Aggregator 
   Deag    = Deaggregator 
   I       = Interior Router 
    
   -->   = E2E RSVP reservation 
   ==>   = Aggregate RSVP reservation 
 
 
                Figure 1 : Aggregation of E2E Reservations  
                     over aggregate RSVP Reservations 
    
    
   These aggregate reservations use a SESSION type specified in [RSVP-
   AGG] that contains the receiver (or Deaggregator) IP address and the 
   DSCP of the PHB from which Diffserv resources are to be reserved. For 
   example, in the case of IPv4, the SESSION object is specified as: 
    
      o  Class = SESSION, 
         C-Type = RSVP-AGGREGATE-IP4 
    
           +-------------+-------------+-------------+-------------+ 
           |              IPv4 Session Address (4 bytes)           | 
           +-------------+-------------+-------------+-------------+ 
           | /////////// |    Flags    |  /////////  |     DSCP    | 
           +-------------+-------------+-------------+-------------+ 
    
    
   These aggregate reservations use a SENDER_TEMPLATE and FILTER_SPEC 
   types specified in [RSVP-AGG] and which contains only the sender (or 
   Aggregator) IP address. For example, in the case of IPv4, the 
   SENDER_TEMPLATE 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 DSCPs. However, from a given source IP address to a 
 
 
Le Faucheur, et al.                                           [Page 3] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
   given IP destination address, only a single [RSVP-AGG] aggregate 
   reservation can be established for a given DSCP. 
    
   Situations have since been identified where multiple such aggregate 
   reservations are needed for the same source IP address, destination 
   IP address and DSCP. One example is where E2E reservations using 
   different preemption priorities (as per [RSVP-PREEMP]) need to be 
   aggregated through a Diffserv cloud using the same DSCP. Using 
   multiple aggregate reservations for the same DSCP allows enforcement 
   of the different preemption priorities within the aggregation region. 
   In turn this allows much more efficient management of the Diffserv 
   resources and in period of resource shortage allows to sustain a 
   larger number of E2E reservations with higher preemption priorities.  
    
   For example, [SIG-NESTED] discusses in details how end-to-end RSVP 
   reservations can be established in a nested VPN environment through 
   RSVP aggregation. In particular, [SIG-NESTED] describes how multiple 
   parallel generic aggregate reservations (for the same DSCP), each 
   with different preemption priorities, can be used to efficiently 
   support the preemption priorities of end-to-end reservations. 
    
   This document addresses this requirement for multiple aggregate 
   reservations for the same DSCP, by defining a more flexible type of 
   aggregate RSVP reservations, referred to as generic aggregate 
   reservations. This is achieved primarily by adding the notions of a 
   Virtual Destination Port and of an Extended Virtual Destination Port 
   in the RSVP Session object.  
    
   The notion of Virtual Destination Port was introduced in [RSVP-IPSEC] 
   to address a similar requirement (albeit in a different context) for 
   identification and demultiplexing of sessions beyond the IP 
   destination address. This document reuses this notion from [RSVP-
   IPSEC] for identification and demultiplexing of generic aggregate 
   sessions beyond the IP destination address and DSCP. This allows 
   multiple generic aggregate reservations to be established for a given 
   DSCP, from a given source IP address to a given destination IP 
   address.  
    
   [RSVP-TE] introduced the concept of an Extended Tunnel ID (in 
   addition to the tunnel egress address and the Tunnel ID) in the 
   Session object used to establish MPLS Traffic Engineering tunnels 
   with RSVP. The Extended Tunnel ID provides a very convenient 
   mechanism for the tunnel ingress node to narrow the scope of the 
   session to the ingress-egress pair. The ingress node can achieve this 
   by using one of its own IP addresses as a globally unique identifier 
   and including it in the Extended Tunnel ID and therefore within the 
   Session object. This document reuses this notion of Extended Tunnel 
   ID from [RSVP-TE], simply renaming it Extended Virtual Destination 

 
 
Le Faucheur, et al.                                           [Page 4] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
   Port. This provides a convenient mechanism to narrow the scope of a 
   generic aggregate session to an Aggregator-Deaggregator pair. 
    
   The generic aggregate reservations may be used to aggregate end-to-
   end RSVP reservations. This document also defines the procedures for 
   such aggregation. These procedures are based on those of [RSVP-AGG] 
   and this document only specifies the differences with those.  
    
   The generic aggregate reservations may also be used end-to-end 
   directly by end-systems attached to a Diffserv network.  
    
1.1.  Related RFCs and Internet-Drafts 
    
   This document is heavily based on [RSVP-AGG]. It reuses [RSVP-AGG] 
   wherever applicable and 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 

 
 
Le Faucheur, et al.                                           [Page 5] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
   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 Section 6 and 7, respectively. 
    
   Finally, Appendix 1 provides an example signaling flow is 
   illustrating aggregation of E2E RSVP reservations onto generic 
   aggregate RSVP reservations. 
 
1.3.  Change History 
    
1.3.1. 
      Changes From draft-ietf-tsvwg-rsvp-ipsec-00 To draft-ietf-tsvwg-
     rsvp-ipsec-01 
    
   The most significant changes are: 
        
       o added text on pre-established aggregate reservations 
        
       o added text on tear-down of aggregate reservations 
        
       o modified text describing content of the Extended vDstPort 
          field 
        
       o renamed AGGREGATION-SESSION class into SESSION-OF-INTEREST 
          class 
        
       o added text clarifying which of the new objects may appear in 
          which message types  
        
       o added text to avoid confusion between the Session of a given 
          reservation and the Session which may be included in the 
          SESSION-OF-INTEREST object. 
        
       o included informative appendix showing an RSVP signalling flow 
          mirroring the one in RFC3175 
    
1.3.2. 
      Changes From draft-lefaucheur-rsvp-ipsec-02 To draft-ietf-tsvwg-
     rsvp-ipsec-00 
    
   The most significant changes are: 
        
       o de-correlate the generic aggregate reservations from IPsec 
          operations, in line with comments from the Security experts 
          review. This significantly affects (and simplifies 
          considerably) the document in many places. 
    
       o add the notion of Extended Virtual Destination port (reusing 
          the notion of Extended Tunnel ID of [RSVP-TE]). 
 
 
Le Faucheur, et al.                                           [Page 6] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
    
       o added recommendations on use of IP addresses by Aggregator and 
          Deaggregator 
    
1.3.3. 
      Changes From draft-lefaucheur-rsvp-ipsec-01 To draft-lefaucheur-
     rsvp-ipsec-02 
    
   The most significant changes are: 
    
       o added text in section 4.2 about Aggregator/Deaggregator 
          responsibilities with respect to mapping of end-to-end 
          reservations onto aggregate reservations.  The text also 
          clarified that DCLASS object is no longer needed in PathErr 
          message requesting new Aggregate Reservations 
        
       o Moved the text discussing details of the procedures to handle      
          dynamic update of SPI values from Security Considerations 
          section into a new section 4.4. 
        
       o updates to Security Considerations section to start addressing 
          some comments from Security experts review. 
    
1.3.4. 
      Changes From draft-lefaucheur-rsvp-ipsec-00 To draft-lefaucheur-
     rsvp-ipsec-01 
    
   The most significant change is the broadening of the applicability of 
   the new type of aggregate reservations beyond use for Aggregate 
   reservations for IPsec tunnels (to environments where IPsec is not 
   used). This affects the document in multiple places including the 
   following changes: 
    
       o document renamed to "Generic Aggregate RSVP Reservations" 
        
       o added a subsection in Introduction to discuss a case where 
          Generic Aggregate RSVP Reservations are needed in non IPsec 
          environments 
        
       o added text about the fact that the Generic Aggregate 
          Reservations can be used with IP-in-IP and GRE encapsulation 
          (in addition to with IPsec AH and ESP) 
        
       o added example usage under Section 5 for environment where 
          IPsec is not used  
        
   The other significant changes are: 
        
       o added a subsection on the changes of the [RSVP-AGG] procedures 
          under Section 4 
        
 
 
Le Faucheur, et al.                                           [Page 7] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
       o added explanation about allocation of VDstPort values by 
          Deaggregator, in that same subsection 
        
       o added value of Protocol ID in all example generic aggregate 
          reservations in Section 5 
    
    
2.  Object Definition 
    
   This document 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 only defines the use of the GENERIC-AGG-IP4-SOI 
   and GENERIC-AGG-IP6-SOI objects in two circumstances: 
      - inside an E2E PathErr message which contains an error code of 
        NEW-AGGREGATE-NEEDED in order to convey the session of a new 
        generic aggregate reservation which 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. 
    
   All the new objects defined in this document are optional with 
   respect to RSVP so that general RSVP implementations not concerned 
   with generic aggregate reservations do not have to support these 
   objects. RSVP routers supporting generic aggregate IPv4 (respectively 
   IPv6) reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION 
   object (respectively GENERIC-AGGREGATE-IP6 SESSION). RSVP routers 
   supporting RSVP aggregation over generic aggregate IPv4 (respectively 

 
 
Le Faucheur, et al.                                           [Page 8] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
   IPv6) reservations MUST support the GENERIC-AGG-IP4-SOI object 
   (respectively GENERIC-AGG-IP6-SOI). 
 
    
2.1.  SESSION Class 
    
      o GENERIC-AGGREGATE-IP4 SESSION object: 
                     Class = 1 (SESSION) 
                     C-Type = To be allocated by IANA 
    
               0           7 8          15 16         23 24          31 
              +-------------+-------------+-------------+-------------+ 
              |               IPv4 DestAddress (4 bytes)              | 
              +-------------+-------------+-------------+--+----------+ 
              | Reserved    |     Flags   |  vDstPort   |Rd|  DSCP    | 
              +-------------+-------------+-------------+--+----------+ 
              |                    Extended vDstPort                  | 
              +-------------+-------------+-------------+-------------+ 
               0           7 8          15 16         23 24          31 
    
   IPv4 DestAddress (IPv4 Destination Address) 
    
       IPv4 address of the receiver (or Deaggregator) 
    
    
   Reserved 
    
      A 8-bit field. All bits MUST be set to 0 on transmit. This field 
   MUST be ignored on receipt.  
    
    
   VDstPort (Virtual Destination Port) 
        
       An 8-bit identifier used in the SESSION that remains constant 
       over the life of the generic aggregate reservation. 
        
        
   Rd (Reserved) 
        
       A 2-bit field. All bits MUST be set to 0 on transmit. This field 
       MUST be ignored on receipt. 
        
        
   DSCP (Diffserv Code Point) 
        
       A 6-bit field containing the DSCP of the PHB from which Diffserv 
       resources are to be reserved. 
        
    
 
 
Le Faucheur, et al.                                           [Page 9] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
   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 globally 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 = To be allocated by IANA 
    
               0           7 8          15 16         23 24          31 
              +-------------+-------------+-------------+-------------+ 
              |                                                       | 
              +                                                       + 
              |                                                       | 
              +               IPv6 DestAddress (16 bytes)             + 
              |                                                       | 
              +                                                       + 
              |                                                       | 
              +-------------+-------------+-------------+--+----------+ 
              | Reserved    |     Flags   |  vDstPort   |Rd|   DSCP   | 
              +-------------+-------------+-------------+--+----------+ 
              |                                                       | 
              +                                                       + 
              |                       Extended vDstPort               | 
              +                                                       + 
              |                            (16 bytes)                 |  
              +                                                       + 
              |                                                       | 
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
               0           7 8          15 16            25 26       31 
    
   IPv6 DestAddress (IPv6 Destination Address) 
    
       IPv6 address of the receiver (or Deaggregator) 
    
    
   Reserved 
    
       A 8-bit field. All bits MUST be set to 0 on transmit. This field 
       MUST be ignored on receipt.  
    
 
 
Le Faucheur, et al.                                          [Page 10] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
    
   VDstPort (Virtual Destination Port) 
        
       A 8-bit identifier used in the SESSION that remains constant 
       over the life of the generic aggregate reservation. 
        
        
   Rd (Reserved) 
        
       A 2-bit field. All bits MUST be set to 0 on transmit. This field 
       MUST be ignored on receipt. 
        
        
   DSCP (Diffserv Code Point) 
        
       A 6-bit field containing the DSCP of the PHB from which Diffserv 
       resources are to be reserved 
    
    
   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 globally 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 = To be allocated by IANA 
                     C-Type = To be allocated by IANA 
    
                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: 
 
 
Le Faucheur, et al.                                          [Page 11] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
        
       This field contains a copy of the Session object of the session 
       which 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.   
    
         
    
      o GENERIC-AGG-IP6-SOI object: 
                     Class = To be allocated by IANA  
                             (same as for GENERIC-AGG-IP4-SOI) 
                     C-Type = To be allocated by IANA 
    
                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 
       which 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   |  vDstPort   |Rd|   DSCP   | 
               +-------------+-------------+-------------+--+----------+ 
               |                    Extended vDstPort                  | 
               +-------------+-------------+-------------+-------------+ 
                0           7 8          15 16         23 24          31 
 
 
Le Faucheur, et al.                                          [Page 12] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
    
    
   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 
   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 additions to the Processing Rules presented in 
   [RSVP-PROCESS]. These additions are required in order to properly 
   process the GENERIC-AGGREGATE-IP4 (resp. GENERIC-AGGREGATE-IP6) 
   SESSION object and the RSVP-AGGREGATE-IP4 (resp. RSVP-AGGREGATE-IP6) 
   FILTER_SPEC object. Values for referenced error codes can be found in 
   [RSVP]. As with the other RSVP documents, values for internally 
   reported (API) errors are not defined. 
    
   When referring to the new GENERIC-AGGREGATE-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.  Required Changes to Path and Resv Processing 
    
   Both RESV and PATH processing will need to be changed to support the 
   new objects. 
    
   The following PATH message processing changes are required: 
    
       o When a session is defined using the GENERIC-AGGREGATE SESSION 
          object, only the [RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATE may 
          be used. When this condition is violated in a PATH message 
          received by an RSVP end-station, the RSVP end-station SHOULD 
          report a "Conflicting C-Type" API error to the application. 
          When this condition is violated in a PATH message received by 
          an RSVP router, the RSVP router MUST consider this as a 
          message formatting error. 
 
 
Le Faucheur, et al.                                          [Page 13] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
        
       o For PATH messages that contain the GENERIC-AGGREGATE SESSION 
          object, the VDstPort value, the Extended VDstPort value and 
          the DSCP value should be recorded (in addition to the 
          destination/Deaggregator address and source/aggregator 
          address). These values form part of the recorded state of the 
          session. The DSCP may need to be passed to traffic control; 
          however the vDstPort and Extended VDstPort are not passed to 
          traffic control since they do not appear inside the data 
          packets of the corresponding reservation. 
    
   The changes to RESV message processing are: 
    
       o When a RESV message contains a [RSVP-AGG] RSVP-AGGREGATE 
          FILTER_SPEC, the session MUST be defined using either the 
          RSVP-AGGREGATE SESSION object (as per [RSVP-AGG]) or the 
          GENERIC-AGGREGATE SESSION object (as per this document). If 
          this condition is not met, an RSVP router or end-station MUST 
          consider that there is a message formatting error. 
        
       o When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION 
          type is GENERIC-AGGREGATE, each node MAY have a data 
          classifier installed for the flow: 
    
          * If the node needs to perform fine-grain classification (for 
           example to perform fine-grain policing on ingress at a trust 
           boundary) then the node MUST create a data classifier 
           described by the 3-tuple <DestAddress, SrcAddress, DSCP>. 
           
            Note that if multiple reservations are established with 
           different Virtual Destination Ports (and/or different 
           Extended Virtual Destination Ports) but with the same 
           <DestAddress, SrcAddress, DSCP>, then those cannot be 
           distinguished by the classifier. If the router is using the 
           classifier for policing purposes, the router will therefore 
           police those together and MUST program the policing rate to 
           the sum of the reserved rate across all the corresponding 
           reservations. 
    
          * If the node only needs to perform Diffserv classification 
           (for example inside the aggregation domain downstream of the 
           trust boundary) then the node MUST rely on the Diffserv data 
           classifier based on the DSCP only. 
    
    
4.  Procedures for Aggregation over Generic Aggregate RSVP Reservations 
    
   The procedures for aggregation of E2E reservations over generic 
   aggregate RSVP reservations are the same as the procedures specified 
 
 
Le Faucheur, et al.                                          [Page 14] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
   in [RSVP-AGG] with the exceptions of the procedure changes listed in 
   this section. 
    
   As specified in [RSVP-AGG], the Deaggregator is responsible for 
   mapping a given E2E reservation on a given aggregate reservation. The 
   Deaggregator requests establishment of a new aggregate reservation by 
   sending to the Aggregator an E2E PathErr message with an error code 
   of NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the Deaggregator conveys the 
   DSCP of the new requested aggregate reservation by including a DCLASS 
   Object in the E2E PathErr and encoding the corresponding DSCP inside. 
   This document modifies and extends this procedure. The Deaggregator 
   MUST include in the E2E PathErr message, a SESSION-OF-INTEREST object 
   which contains the GENERIC-AGGREGATE Session to be used for 
   establishment of the requested generic aggregate reservation. Since 
   this GENERIC-AGGREGATE SESSION contains the DSCP, the DCLASS object 
   need not be included in the PathErr message.  
    
   Note that the Deaggregator can easily ensure that different 
   Aggregators use different sessions for their Aggregate Path towards a 
   given Deaggregator. This is because the Deaggregator can easily 
   select VDstPort and/or Extended VDstPort numbers which are different 
   for each Aggregator (for example by using the Aggregator address as 
   the Extended VDstPort) and can communicate those inside the 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 new needed generic aggregate 
   reservation. For example, the Deaggregator MAY include in the E2E 
   PathErr an RSVP Signaled Preemption Priority Policy Element (as 
   specified in [RSVP-PREEMP]).  
    
   The [RSVP-AGG] procedures for processing of an E2E PathErr message 
   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 
 
 
Le Faucheur, et al.                                          [Page 15] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
   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 
   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 when forwarding the E2E Path messages 
   corresponding to the E2E PathErr message. 
    
   The Deaggregator follows the same procedures as described in [RSVP-
   AGG] for establishing, maintaining and clearing the aggregate Resv 
   state. However, in this document, the Deaggregator MUST use the 
   generic aggregate reservations and hence use the GENERIC-AGGREGATE 
   SESSION specified earlier in this document. 
    
   This document also modifies the procedures of [RSVP-AGG] related to 
   exchange of E2E Resv messages between Deaggregator and Aggregator. 
   The Deaggregator MUST include the new 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 DSCP, 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 identity to each other. For example the 
   Aggregator includes one of its IP addresses in the RSVP HOP object in 
 
 
Le Faucheur, et al.                                          [Page 16] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
   the E2E Path which is transmitted downstream and received by the 
   Deaggregator once it traversed the aggregation region. Similarly, the 
   Deaggregator identifies itself to the Aggregator by including one of 
   its IP addresses in various fields, including the ERROR SPECIFICATION 
   of the E2E PathErr message (containing the NEW-AGGREGATE-NEEDED Error 
   Code) 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 identity 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 turns this results in more stable operations and 
   considerably reduced RSVP signaling in the aggregation region. For 
   example, if interface-independent addresses are used by the 
   Aggregator and the Deaggregator, then a failure of an interface on 
   these devices may simply result in the rerouting of a given generic 
   aggregate reservation but will not result in the generic aggregate 
   reservation having to be torn down and another one established, nor 
   will it result in a change of mapping of E2E reservations on generic 
   aggregate reservations (assuming the Aggregator and Deaggregator 
   still have reachability after the failure and the Aggregator and 
   Deaggregator are still on the shortest path to the destination).  
    
   However, when identifying themselves to real RSVP neighbors (i.e. 
   neighbors which are not on the other side of the aggregation region), 
   the Aggregator and Deaggregator SHOULD continue using interface-
   dependent addresses as per regular [RSVP] procedures. This applies 
   for example when the Aggregator identifies itself downstream as a 
   PHOP for the generic aggregate reservation or identifies itself 
   upstream as a NHOP for an E2E reservation. This also applies when the 
   Deaggregator identifies itself downstream as a PHOP for the E2E 
   reservation or identifies itself upstream as a NHOP for the generic 
   aggregate reservation. As part of the processing of generic aggregate 
   reservations, interior routers (i.e. routers within the aggregation 
   region) SHOULD continue using interface-dependent addresses as per 
   regular [RSVP] procedures. 
    
   More generally, within the aggregation region (ie between Aggregator 
   and Deaggregator) the operation of RSVP should be modeled with the 
   notion that E2E reservations are mapped to aggregate reservations and 
   are no longer tied to physical interfaces (as was the case with 
   regular RSVP). However, generic aggregate reservations (within the 
   aggregation region) as well as E2E reservations outside the 
   aggregation region, retain the model of regular RVSP and remain tied 
   to physical interfaces. 
 
 
Le Faucheur, et al.                                          [Page 17] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
    
   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) which 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 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, DSCP 
   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/DSCP/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 usual for a device at the edge of a 
   Diffserv cloud. 
 
    
5.  Example Usage Of Multiple Generic Aggregate Reservations Per DSCP 
   From a Given Aggregator to a Given Deaggregator 
    
   Let us consider the environment depicted in Figure 2 below. RSVP 
   aggregation is used to support E2E reservations between Cloud-1, 
   Cloud-2 and Cloud-3. 
    
    
                 I----------I               I----------I 
                 I  Cloud-1 I               I  Cloud-2 I 
                 I----------I               I----------I 
 
 
Le Faucheur, et al.                                          [Page 18] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
                       |                      | 
                    Agg-Deag-1------------ Agg-Deag-2 
                       /                        \ 
                      /      Aggregation         | 
                     |         Region            |                    
                     |                           | 
                     |                       ---/ 
                      \                     /  
                       \Agg-Deag-3---------/ 
                             | 
                        I----------I 
                        I  Cloud-3 I 
                        I----------I 
    
    
                        Figure 2 : Example Usage of  
                     Generic Aggregate IP Reservations 
    
   Let us assume that: 
    
       o the E2E reservations from Cloud-1 to Cloud-3 have a preemption 
          of either P1 or P2 
        
       o the E2E reservations from Cloud-2 to Cloud-3 have a preemption 
          of either P1 or P2 
        
       o the E2E reservations are only for Voice (which needs to be 
          treated in the aggregation region using the EF PHB) 
        
       o traffic from the E2E reservations is encapsulated in Aggregate 
          IP reservations from Aggregator to Deaggregator using GRE 
          tunneling ([GRE]). 
    
   Then, the following generic aggregate RSVP reservations may be 
   established from Agg-Deag-1 to Agg-Deag-3 for aggregation of the end-
   to-end RSVP reservations: 
    
   A first generic aggregate reservation for aggregation of Voice 
   reservations from Cloud-1 to Cloud-3 requiring use of P1: 
    
          *  GENERIC-AGGREGATE-IP4 SESSION: 
                  IPv4 DestAddress= Agg-Deag-3 
                  vDstPort=V1 
                  DSCP=EF 
                  Extended VDstPort= Agg-Deag-1 
    
          *  STYLE=FF or SE 
    
          *  IPv4/GPI FILTER_SPEC: 
 
 
Le Faucheur, et al.                                          [Page 19] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
                  IPv4 SrcAddress= Agg-Deag-1 
    
          *  POLICY_DATA (PREEMPTION_PRI)=P1 
    
   A second generic aggregate reservation for aggregation of Voice 
   reservations from Cloud-1 to Cloud-3 requiring use of P2: 
    
          *  GENERIC-AGGREGATE-IP4 SESSION: 
                  IPv4 DestAddress= Agg-Deag-3 
                  vDstPort=V2 
                  DSCP=EF 
                  Extended VDstPort= Agg-Deag-1 
    
          *  STYLE=FF or SE 
    
          *  IPv4/GPI FILTER_SPEC: 
                  IPv4 SrcAddress= Agg-Deag-1 
    
          *  POLICY_DATA (PREEMPTION_PRI)=P2 
    
      where V1 and V2 are arbitrary VDstPort values picked by Agg-Deag-3. 
 
   The following generic aggregate RSVP reservations may be established 
   from Agg-Deag-2 to Agg-Deag-3 for aggregation of the end-to-end RSVP 
   reservations: 
    
   A third generic aggregate reservation for aggregation of Voice 
   reservations from Cloud-2 to Cloud-3 requiring use of P1: 
    
          *  GENERIC-AGGREGATE-IP4 SESSION:  
                  IPv4 DestAddress= Agg-Deag-3 
                  vDstPort=V3 
                  DSCP=EF 
                  Extended VDstPort= Agg-Deag-2 
    
          *  STYLE=FF or SE 
    
          *  IPv4/GPI FILTER_SPEC: 
                  IPv4 SrcAddress= Agg-Deag-2 
    
          *  POLICY_DATA (PREEMPTION_PRI)=P1 
    
   A fourth generic aggregate reservation for aggregation of Voice 
   reservations from Cloud-2 to Cloud-3 requiring use of P2: 
    
          *  GENERIC-AGGREGATE-IP4 SESSION: 
                  IPv4 DestAddress= Agg-Deag-3 
                  vDstPort=V4 
                  DSCP=EF 
 
 
Le Faucheur, et al.                                          [Page 20] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
                  Extended VDstPort= Agg-Deag-2 
    
          *  STYLE=FF or SE 
    
          *  IPv4/GPI FILTER_SPEC: 
                  IPv4 SrcAddress= Agg-Deag-2 
    
          *  POLICY_DATA (PREEMPTION_PRI)=P2 
    
      where V1 and V4 are arbitrary VDstPort values picked by Agg-Deag-3.    
    
   Note that V3 and V4 could be equal to (respectively) V1 and V2 since, 
   in this example, the Extended VDstPort of the GENERIC-AGGREGATE 
   Session contains the address of the Deaggregator and, thus, ensures 
   that different sessions are used for each Deaggregator. 
    
    
6.  Security Considerations 
    
   The security considerations associated with the RSVP protocol [RSVP] 
   apply to this document as it relies on RSVP. 
    
   When generic aggregate reservations are used for aggregation of E2E 
   reservations, the security considerations discussed in [RSVP-AGG] 
   apply. 
    
   The security considerations discussed in [SIG-NESTED] apply when the 
   generic aggregate reservations are used in the presence of IPsec 
   gateways. 
    
    
7.  IANA Considerations  
    
   This document requests that IANA allocates two new C-Types under the 
   existing SESSION Class (Class 1)for the two new RSVP objects  defined 
   in section 2.1: GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-
   IP6 SESSION. 
    
   This document also requests that IANA allocates one new Class-Num for 
   the SESSION-OF-INTEREST class, and two new C-Types for the two new 
   RSVP objects under that class defined in section 2.2: GENERIC-AGG-
   IP4-SOI and GENERIC-AGG-IP4-SOI. 
    
    
8.  Acknowledgments 
    
   This document borrows heavily from [RSVP-AGG]. It also borrows the 
   concepts of Virtual Destination Port and Extended Virtual Destination 
   Port respectively from [RSVP-IPSEC] and [RSVP-TE]. 
 
 
Le Faucheur, et al.                                          [Page 21] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
    
   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. 
    
    
9.  Normative References 
    
   [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 
   Bradner, RFC2119 
    
   [RSVP] "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 
   Specification", Braden et al, RFC2205 
    
   [RSVP-IPSEC] "RSVP Extensions for IPsec Data Flows", Berger et al, 
   RFC2207 
    
   [RSVP-AGG] "Aggregation of RSVP for IPv4 and IPv6 Reservations", 
   Baker et al, RFC3175 
    
   [RSVP-PROCESS] "Resource ReSerVation Protocol (RSVP) -- Version 1 
   Message Processing Rules", Braden et al, RFC2209 
    
   [GRE] "Generic Routing Encapsulation (GRE) ", Farinacci et al, RFC 
   2784 
    
    
10.  Informative References 
    
   [SIG-NESTED] "QoS Signaling in a Nested Virtual Private Network", 
   Baker et al, draft-ietf-tsvwg-vpn-signaled-preemption, work in 
   progress 
    
   [BW-REDUC] "A Resource Reservation Extension for the Reduction of 
   andwidth of a Reservation Flow", Polk et al, RFC 4495 
    
   [RSVP-TUNNEL] "RSVP Operation Over IP Tunnels", Terzis et al., RFC 
   2746, January 2000. 
    
   [RSVP-PREEMP]  Herzog, S., "Signaled Preemption Priority Policy 
   Element", RFC 3181, October 2001.  
    
   [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, 
   RFC 3209, December 2001. 
    
 

 
 
Le Faucheur, et al.                                          [Page 22] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
11.  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. 
   300 Beaver Brook Road 
   Boxborough, MA 01719  
   USA 
   Email: bdavie@cisco.com 
    
    
   Pratik Bose 
   Lockheed Martin 
   22300 Comsat Drive Clarksburg, MD 20814  
   USA 
   Email: pratik.bose@lmco.com 
    
    
   Christou Christou 
   Booz Allen Hamilton 
   8283 Greensboro Drive 
   McLean, VA 22102 
   USA 
   Email: christou_chris@bah.com 
    
    
   Michael Davenport 
   Booz Allen Hamilton 
   8283 Greensboro Drive 
   McLean, VA 22102 
   USA 
   Email: davenport_michael@bah.com  
    
       
12.  IPR Statements 
                                                       
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
 
 
Le Faucheur, et al.                                          [Page 23] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
   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.  
    
          
13.  Disclaimer of Validity 
                                             
   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.   
    
         
14.  Copyright Notice                                                
      
   Copyright (C) The Internet Society (2006).  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.  
    
    
 
 
APPENDIX 1: 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 which is the first between a given pair of 
   Aggregator/Deaggregator. 
 
 
Le Faucheur, et al.                                          [Page 24] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
    
    
           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 
 
 
Le Faucheur, et al.                                          [Page 25] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
   instruct the Aggregator to set up Aggregate Path states for the two 
   supported DSCPs. To do that, the Deaggregator 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 
   DSCP is set to x. In the second E2E PathErr, the SOI contains a 
   GENERIC-AGGREGATE SESSION (GAy) whose DSCP 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 Path 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 DSCPs. 
   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 
   Resv 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 DSCP=x. The Deaggregator knows that a 
   generic aggregate reservation (GAx) is in place for the corresponding 
   DSCP since (7). The Deaggregator performs admission control of the 
   E2E Resv onto the generic aggregate Reservation for DSCP=x (GAx). 
   Assuming that the generic aggregate reservation for DSCP=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 and forwards the E2E Resv to the 
   Aggregator including a SESSION-OF-INTEREST object conveying the 
   selected mapping onto GAx (and hence onto DSCP=x). 
 
 
Le Faucheur, et al.                                          [Page 26] 

                 Generic Aggregate RSVP Reservations        June 2006 
 
 
    
   (9)  The Aggregator records the mapping of the E2E Resv onto GAx (and 
   onto DSCP=x). The Aggregator removes the SOI object and forwards the 
   E2E Resv towards the sender. 













































 
 
Le Faucheur, et al.                                          [Page 27]