draft-ietf-tsvwg-rsvp-ipsec-05.txt   rfc4860.txt 
Generic Aggregate RSVP Reservations February 2007 Network Working Group F. Le Faucheur
Request for Comments: 4860 B. Davie
Internet Draft Francois Le Faucheur Category: Standards Track Cisco Systems, Inc.
Intended status: Proposed Standards Bruce Davie P. Bose
Cisco Systems, Inc.
Pratik Bose
Lockheed Martin Lockheed Martin
C. Christou
Chris Christou M. Davenport
Michael Davenport
Booz Allen Hamilton Booz Allen Hamilton
draft-ietf-tsvwg-rsvp-ipsec-05.txt
Expires: August 13, 2007 February 13, 2007
Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations
draft-ietf-tsvwg-rsvp-ipsec-05.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 Status of This Memo
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 This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The IETF Trust (2007).
http://www.ietf.org/shadow.html.
Abstract Abstract
RFC3175 defines aggregate Resource ReSerVation Protocol (RSVP) RFC3175 defines aggregate Resource ReSerVation Protocol (RSVP)
reservations allowing resources to be reserved in a Diffserv network reservations allowing resources to be reserved in a Diffserv network
for a given Per Hop Behavior (PHB), or given set of PHBs, from a for a given Per Hop Behavior (PHB), or given set of PHBs, from a
given source to a given destination. RFC3175 also defines how end-to- given source to a given destination. RFC 3175 also defines how end-
to-end RSVP reservations can be aggregated onto such aggregate
Generic Aggregate RSVP Reservations February 2007
end RSVP reservations can be aggregated onto such aggregate
reservations when transiting through a Diffserv cloud. There are reservations when transiting through a Diffserv cloud. There are
situations where multiple such aggregate reservations are needed for situations where multiple such aggregate reservations are needed for
the same source IP address, destination IP address and PHB (or set of the same source IP address, destination IP address, and PHB (or set
PHBs). However, this is not supported by the aggregate reservations of PHBs). However, this is not supported by the aggregate
defined in RFC3175. In order to support this, the present document reservations defined in RFC 3175. In order to support this, the
defines a more flexible type of aggregate RSVP reservations, referred present document defines a more flexible type of aggregate RSVP
to as generic aggregate reservation. Multiple such generic aggregate reservations, referred to as generic aggregate reservation. Multiple
reservations can be established for a given PHB (or set of PHBs) from such generic aggregate reservations can be established for a given
a given source IP address to a given destination IP address. The PHB (or set of PHBs) from a given source IP address to a given
generic aggregate reservations may be used to aggregate end-to-end destination IP address. The generic aggregate reservations may be
RSVP reservations. This document also defines the procedures for such used to aggregate end-to-end RSVP reservations. This document also
aggregation. The generic aggregate reservations may also be used end- defines the procedures for such aggregation. The generic aggregate
to-end directly by end-systems attached to a Diffserv network. reservations may also be used end-to-end directly by end-systems
attached to a Diffserv network.
Table Of Content Table of Contents
1. Introduction...................................................3 1. Introduction ....................................................3
1.1. Related IETF Documents....................................6 1.1. Related IETF Documents .....................................6
1.2. Organization Of This Document.............................6 1.2. Organization of This Document ..............................6
2. Object Definition..............................................7 1.3. Requirements Language ......................................7
2.1. SESSION Class.............................................7 2. Object Definition ...............................................7
2.2. SESSION-OF-INTEREST (SOI) Class..........................10 2.1. SESSION Class ..............................................8
3. Processing Rules For Handling Generic Aggregate RSVP Reservations 2.2. SESSION-OF-INTEREST (SOI) Class ...........................11
.................................................................12 3. Processing Rules for Handling Generic Aggregate RSVP
3.1. Extensions to Path and Resv Processing...................13 Reservations ...................................................13
3.1. Extensions to Path and Resv Processing ....................13
4. Procedures for Aggregation over Generic Aggregate RSVP 4. Procedures for Aggregation over Generic Aggregate RSVP
Reservations.....................................................14 Reservations ...................................................14
5. Example Usage Of Multiple Generic Aggregate Reservations Per PHB 5. Example Usage Of Multiple Generic Aggregate Reservations
From a Given Aggregator to a Given Deaggregator..................18 per PHB from a Given Aggregator to a Given Deaggregator ........19
6. Security Considerations.......................................20 6. Security Considerations ........................................21
7. IANA Considerations...........................................23 7. IANA Considerations ............................................24
8. Acknowledgments...............................................24 8. Acknowledgments ................................................25
9. Normative References..........................................24 9. Normative References ...........................................26
10. Informative References.......................................25 10. Informative References ........................................26
11. Authors' Addresses...........................................25 Appendix A. Example Signaling Flow ................................28
Appendix A: Example Signaling Flow...............................27
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.
Generic Aggregate RSVP Reservations February 2007
1. Introduction 1. Introduction
[RSVP-AGG] defines RSVP aggregate reservations allowing resources to [RSVP-AGG] defines RSVP aggregate reservations that allow resources
be reserved in a Diffserv network for a flow characterized by its 3- to be reserved in a Diffserv network for a flow characterized by its
tuple <source IP address, destination IP address, DSCP>. 3-tuple <source IP address, destination IP address, Diffserv Code
Point>.
[RSVP-AGG] also defines the procedures for aggregation of end-to-end [RSVP-AGG] also defines the procedures for aggregation of end-to-end
RSVP reservations onto such aggregate reservations when transiting (E2E) RSVP reservations onto such aggregate reservations when
through a Diffserv cloud. Such aggregation is illustrated in Figure 1. transiting through a Diffserv cloud. Such aggregation is illustrated
This document reuses the terminology defined in [RSVP-AGG]. in Figure 1. This document reuses the terminology defined in
[RSVP-AGG].
-------------------------- --------------------------
/ Aggregation \ / Aggregation \
|----| | Region | |----| |----| | Region | |----|
H--| R |\ |-----| |------| /| R |-->H H--| R |\ |-----| |------| /| R |-->H
H--| |\\| | |---| |---| | |//| |-->H H--| |\\| | |---| |---| | |//| |-->H
|----| \| | | I | | I | | |/ |----| |----| \| | | I | | I | | |/ |----|
| Agg |======================>| Deag | | Agg |======================>| Deag |
/| | | | | | | |\ /| | | | | | | |\
H--------//| | |---| |---| | |\\-------->H H--------//| | |---| |---| | |\\-------->H
skipping to change at page 3, line 42 skipping to change at page 3, line 42
H = Host requesting end-to-end RSVP reservations H = Host requesting end-to-end RSVP reservations
R = RSVP router R = RSVP router
Agg = Aggregator Agg = Aggregator
Deag = Deaggregator Deag = Deaggregator
I = Interior Router I = Interior Router
--> = E2E RSVP reservation --> = E2E RSVP reservation
==> = Aggregate RSVP reservation ==> = Aggregate RSVP reservation
Figure 1 : Aggregation of E2E Reservations Figure 1 : Aggregation of E2E Reservations
over aggregate RSVP Reservations over Aggregate RSVP Reservations
These aggregate reservations use a SESSION type specified in [RSVP- These aggregate reservations use a SESSION type specified in
AGG] that contains the receiver (or Deaggregator) IP address and the [RSVP-AGG] that contains the receiver (or Deaggregator) IP address
DSCP of the Per Hop Behavior (PHB) from which Diffserv resources are and the Diffserv Code Point (DSCP) of the Per Hop Behavior (PHB) from
to be reserved. For example, in the case of IPv4, the SESSION object which Diffserv resources are to be reserved. For example, in the
is specified as: case of IPv4, the SESSION object is specified as:
o Class = SESSION, o Class = SESSION,
C-Type = RSVP-AGGREGATE-IP4 C-Type = RSVP-AGGREGATE-IP4
Generic Aggregate RSVP Reservations February 2007
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Session Address (4 bytes) | | IPv4 Session Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP | | /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
These aggregate reservations use a SENDER_TEMPLATE and FILTER_SPEC These aggregate reservations use SENDER_TEMPLATE and FILTER_SPEC
types specified in [RSVP-AGG] and which contains only the sender (or types, specified in [RSVP-AGG], that contain only the sender (or
Aggregator) IP address. For example, in the case of IPv4, the Aggregator) IP address. For example, in the case of IPv4, the
SENDER_TEMPLATE object is specified as: SENDER_TEMPLATE object is specified as:
o Class = SENDER_TEMPLATE, o Class = SENDER_TEMPLATE,
C-Type = RSVP-AGGREGATE-IP4 C-Type = RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Aggregator Address (4 bytes) | | IPv4 Aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Thus, it is possible to establish, from a given source IP address to Thus, it is possible to establish, from a given source IP address to
a given destination IP address, separate such aggregate reservations a given destination IP address, separate such aggregate reservations
for different PHBs (or different sets of PHBs). However, from a given for different PHBs (or different sets of PHBs). However, from a
source IP address to a given IP destination address, only a single given source IP address to a given IP destination address, only a
[RSVP-AGG] aggregate reservation can be established for a given PHB single [RSVP-AGG] aggregate reservation can be established for a
(or given set of PHBs). given PHB (or given set of PHBs).
Situations have since been identified where multiple such aggregate Situations have since been identified where multiple such aggregate
reservations are needed for the same source IP address, destination reservations are needed for the same source IP address, destination
IP address and PHB (or set of PHBs). One example is where E2E IP address, and PHB (or set of PHBs). One example is where E2E
reservations using different preemption priorities (as per [RSVP- reservations using different preemption priorities (as per
PREEMP]) need to be aggregated through a Diffserv cloud using the [RSVP-PREEMP]) need to be aggregated through a Diffserv cloud using
same PHB. Using multiple aggregate reservations for the same PHB the same PHB. Using multiple aggregate reservations for the same PHB
allows enforcement of the different preemption priorities within the allows enforcement of the different preemption priorities within the
aggregation region. In turn this allows more efficient management of aggregation region. In turn, this allows more efficient management
the Diffserv resources and in period of resource shortage allows to of the Diffserv resources, and in periods of resource shortage, this
sustain a larger number of E2E reservations with higher preemption allows sustainment of a larger number of E2E reservations with higher
priorities. preemption priorities.
For example, [SIG-NESTED] discusses in detail how end-to-end RSVP For example, [SIG-NESTED] discusses in detail how end-to-end RSVP
reservations can be established in a nested VPN environment through reservations can be established in a nested VPN environment through
RSVP aggregation. In particular, [SIG-NESTED] describes how multiple RSVP aggregation. In particular, [SIG-NESTED] describes how multiple
parallel generic aggregate reservations (for the same PHB), each with parallel generic aggregate reservations (for the same PHB), each with
different preemption priorities, can be used to efficiently support different preemption priorities, can be used to efficiently support
the preemption priorities of end-to-end reservations. the preemption priorities of end-to-end reservations.
This document addresses this requirement for multiple aggregate This document addresses this requirement for multiple aggregate
reservations for the same PHB (or same set of PHBs), by defining a reservations for the same PHB (or same set of PHBs), by defining a
Generic Aggregate RSVP Reservations February 2007
more flexible type of aggregate RSVP reservations, referred to as more flexible type of aggregate RSVP reservations, referred to as
generic aggregate reservations. This is achieved primarily by adding generic aggregate reservations. This is achieved primarily by adding
the notions of a Virtual Destination Port and of an Extended Virtual the notions of a Virtual Destination Port and of an Extended Virtual
Destination Port in the RSVP Session object. Destination Port in the RSVP SESSION object.
The notion of Virtual Destination Port was introduced in [RSVP-IPSEC] The notion of Virtual Destination Port was introduced in [RSVP-IPSEC]
to address a similar requirement (albeit in a different context) for to address a similar requirement (albeit in a different context) for
identification and demultiplexing of sessions beyond the IP identification and demultiplexing of sessions beyond the IP
destination address. This document reuses this notion from [RSVP- destination address. This document reuses this notion from
IPSEC] for identification and demultiplexing of generic aggregate [RSVP-IPSEC] for identification and demultiplexing of generic
sessions beyond the IP destination address and PHB. This allows aggregate sessions beyond the IP destination address and PHB. This
multiple generic aggregate reservations to be established for a given allows multiple generic aggregate reservations to be established for
PHB (or set of PHBs), from a given source IP address to a given a given PHB (or set of PHBs), from a given source IP address to a
destination IP address. given destination IP address.
[RSVP-TE] introduced the concept of an Extended Tunnel ID (in [RSVP-TE] introduced the concept of an Extended Tunnel ID (in
addition to the tunnel egress address and the Tunnel ID) in the addition to the tunnel egress address and the Tunnel ID) in the
Session object used to establish MPLS Traffic Engineering tunnels SESSION object used to establish MPLS Traffic Engineering tunnels
with RSVP. The Extended Tunnel ID provides a very convenient with RSVP. The Extended Tunnel ID provides a very convenient
mechanism for the tunnel ingress node to narrow the scope of the mechanism for the tunnel ingress node to narrow the scope of the
session to the ingress-egress pair. The ingress node can achieve this session to the ingress-egress pair. The ingress node can achieve
by using one of its own IP addresses as a globally unique identifier this by using one of its own IP addresses as a globally unique
and including it in the Extended Tunnel ID and therefore within the identifier and including it in the Extended Tunnel ID and therefore
Session object. This document reuses this notion of Extended Tunnel within the SESSION object. This document reuses this notion of
ID from [RSVP-TE], simply renaming it Extended Virtual Destination Extended Tunnel ID from [RSVP-TE], simply renaming it Extended
Port. This provides a convenient mechanism to narrow the scope of a Virtual Destination Port. This provides a convenient mechanism to
generic aggregate session to an Aggregator-Deaggregator pair. narrow the scope of a generic aggregate session to an Aggregator-
Deaggregator pair.
The RSVP Session object for generic aggregate reservations uses the The RSVP SESSION object for generic aggregate reservations uses the
PHB Identification Code (PHB-ID) defined in [PHB-ID] to identify 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 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 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 per [RSVP-AGG]. Using the PHB-ID instead of the DSCP allows explicit
indication of whether the Diffserv resources belong to a single PHB indication of whether the Diffserv resources belong to a single PHB
or to a set of PHBs. It also facilitates handling of situations where or to a set of PHBs. It also facilitates handling of situations
a generic aggregate reservation spans two (or more) Diffserv domains where a generic aggregate reservation spans two (or more) Diffserv
which use different DSCP values for the same Diffserv PHB (or set of domains that use different DSCP values for the same Diffserv PHB (or
PHBs) from which resources are reserved. This is because the PHB-ID set of PHBs) from which resources are reserved. This is because the
allows conveying of the PHB (or set of PHBs) independently of what PHB-ID allows conveying of the PHB (or set of PHBs) independently of
DSCP value(s) is used locally for that PHB (or set of PHBs). 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- The generic aggregate reservations may be used to aggregate end-to-
end RSVP reservations. This document also defines the procedures for end RSVP reservations. This document also defines the procedures for
such aggregation. These procedures are based on those of [RSVP-AGG] such aggregation. These procedures are based on those of [RSVP-AGG],
and this document only specifies the differences with those. and this document only specifies the differences from those.
The generic aggregate reservations may also be used end-to-end The generic aggregate reservations may also be used end-to-end
directly by end-systems attached to a Diffserv network. directly by end-systems attached to a Diffserv network.
Generic Aggregate RSVP Reservations February 2007
1.1. Related IETF Documents 1.1. Related IETF Documents
This document is heavily based on [RSVP-AGG]. It reuses [RSVP-AGG] This document is heavily based on [RSVP-AGG]. It reuses [RSVP-AGG]
wherever applicable and only specifies the necessary extensions wherever applicable and only specifies the necessary extensions
beyond [RSVP-AGG]. beyond [RSVP-AGG].
The mechanisms defined in [BW-REDUC] allow an existing reservation to The mechanisms defined in [BW-REDUC] allow an existing reservation to
be reduced in allocated bandwidth by RSVP routers in lieu of tearing be reduced in allocated bandwidth by RSVP routers in lieu of tearing
that reservation down. These mechanisms are applicable to the generic that reservation down. These mechanisms are applicable to the
aggregate reservations defined in the present document. generic aggregate reservations defined in the present document.
[RSVP-TUNNEL] describes a general approach to running RSVP over [RSVP-TUNNEL] describes a general approach to running RSVP over
various types of tunnels. One of these types of tunnel, referred to various types of tunnels. One of these types of tunnel, referred to
as a "type 2 tunnel", has some similarity with the generic aggregate as a "type 2 tunnel", has some similarity with the generic aggregate
reservations described in this document. The similarity stems from reservations described in this document. The similarity stems from
the fact that a single, aggregate reservation is made for the tunnel the fact that a single, aggregate reservation is made for the tunnel
while many individual flows are carried over that tunnel. However, while many individual flows are carried over that tunnel. However,
[RSVP-TUNNEL] does not address the use of Diffserv-based [RSVP-TUNNEL] does not address the use of Diffserv-based
classification and scheduling in the core of a network (between classification and scheduling in the core of a network (between
tunnel endpoints), but rather relies on a UDP/IP tunnel header for tunnel endpoints), but rather relies on a UDP/IP tunnel header for
skipping to change at page 6, line 43 skipping to change at page 6, line 44
As explained earlier, this document reuses the notion of Virtual As explained earlier, this document reuses the notion of Virtual
Destination Port from [RSVP-IPSEC] and the notion of Extended Tunnel Destination Port from [RSVP-IPSEC] and the notion of Extended Tunnel
ID from [RSVP-TE]. ID from [RSVP-TE].
1.2. Organization Of This Document 1.2. Organization Of This Document
Section 2 defines the new RSVP objects related to generic aggregate Section 2 defines the new RSVP objects related to generic aggregate
reservations and to aggregation of E2E reservations onto those. reservations and to aggregation of E2E reservations onto those.
Section 3 describes the processing rules for handling of generic Section 3 describes the processing rules for handling of generic
aggregate reservations. Section 4 specifies the procedures for aggregate reservations. Section 4 specifies the procedures for
aggregation of end to end RSVP reservations over generic aggregate aggregation of end-to-end RSVP reservations over generic aggregate
RSVP reservations. Section 5 provides example usage of how the RSVP reservations. Section 5 provides example usage of how the
generic aggregate reservations may be used. generic aggregate reservations may be used.
The Security Considerations and the IANA Considerations are discussed The Security Considerations and the IANA Considerations are discussed
in Section 6 and 7, respectively. in Sections 6 and 7, respectively.
Finally, Appendix 1 provides an example signaling flow is Finally, Appendix A provides an example signaling flow that
illustrating aggregation of E2E RSVP reservations onto generic illustrates aggregation of E2E RSVP reservations onto generic
aggregate RSVP reservations. aggregate RSVP reservations.
Generic Aggregate RSVP Reservations February 2007 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 2. Object Definition
This document reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP- This document reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP-
AGGREGATE-IP6 FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE and AGGREGATE-IP6 FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE, and
RSVP-AGGREGATE-IP6 SENDER_TEMPLATE objects defined in [RSVP-AGG]. RSVP-AGGREGATE-IP6 SENDER_TEMPLATE objects defined in [RSVP-AGG].
This document defines: This document defines:
- two new objects (GENERIC-AGGREGATE-IP4 SESSION and GENERIC- - two new objects (GENERIC-AGGREGATE-IP4 SESSION and GENERIC-
AGGREGATE-IP6 SESSION) under the existing SESSION Class, and AGGREGATE-IP6 SESSION) under the existing SESSION Class, and
- two new objects (GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI) - two new objects (GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI)
under a new SESSION-OF-INTEREST Class. under a new SESSION-OF-INTEREST Class.
Detailed description of these objects is provided below in this Detailed description of these objects is provided below in this
section. section.
The GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION The GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION
objects are applicable to all types of RSVP messages. objects are applicable to all types of RSVP messages.
This specification defines the use of the GENERIC-AGG-IP4-SOI and This specification defines the use of the GENERIC-AGG-IP4-SOI and
skipping to change at page 7, line 27 skipping to change at page 7, line 37
under a new SESSION-OF-INTEREST Class. under a new SESSION-OF-INTEREST Class.
Detailed description of these objects is provided below in this Detailed description of these objects is provided below in this
section. section.
The GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION The GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION
objects are applicable to all types of RSVP messages. objects are applicable to all types of RSVP messages.
This specification defines the use of the GENERIC-AGG-IP4-SOI and This specification defines the use of the GENERIC-AGG-IP4-SOI and
GENERIC-AGG-IP6-SOI objects in two circumstances: GENERIC-AGG-IP6-SOI objects in two circumstances:
- inside an E2E PathErr message which contains an error code of
- inside an E2E PathErr message that contains an error code of
NEW-AGGREGATE-NEEDED in order to convey the session of a new NEW-AGGREGATE-NEEDED in order to convey the session of a new
generic aggregate reservation which needs to be established generic aggregate reservation that needs to be established.
- inside an E2E Resv message in order to convey the session of
the generic aggregate reservation onto which this E2E - inside an E2E Resv message in order to convey the session of the
reservation needs to be mapped. generic aggregate reservation onto which this E2E reservation
Details of the corresponding procedures can be found in section 4. 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 However, it is envisioned that the ability to signal, inside RSVP
messages, the Session of another reservation (which has some messages, the Session of another reservation (which has some
relationship with the current RSVP reservation) might have some other relationship with the current RSVP reservation) might have some other
applicability in the future. Thus, those objects have been specified applicability in the future. Thus, those objects have been specified
in a more generic manner under a flexible SESSION-OF-INTEREST class. in a more generic manner under a flexible SESSION-OF-INTEREST class.
All the new objects defined in this document are optional with All the new objects defined in this document are optional with
respect to RSVP so that general RSVP implementations not concerned respect to RSVP so that general RSVP implementations that are not
with generic aggregate reservations do not have to support these concerned with generic aggregate reservations do not have to support
objects. RSVP routers supporting generic aggregate IPv4 (respectively these objects. RSVP routers supporting generic aggregate IPv4 or
IPv6) reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION IPv6 reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION
object (respectively GENERIC-AGGREGATE-IP6 SESSION). RSVP routers object or the GENERIC-AGGREGATE-IP6 SESSION object, respectively.
supporting RSVP aggregation over generic aggregate IPv4 (respectively RSVP routers supporting RSVP aggregation over generic aggregate IPv4
IPv6) reservations MUST support the GENERIC-AGG-IP4-SOI object or IPv6 reservations MUST support the GENERIC-AGG-IP4-SOI object or
(respectively GENERIC-AGG-IP6-SOI). GENERIC-AGG-IP6-SOI object, respectively.
2.1. SESSION Class 2.1. SESSION Class
o GENERIC-AGGREGATE-IP4 SESSION object: o GENERIC-AGGREGATE-IP4 SESSION object:
Class = 1 (SESSION) Class = 1 (SESSION)
C-Type = 17
Generic Aggregate RSVP Reservations February 2007
C-Type = To be allocated by IANA
0 7 8 15 16 23 24 31 0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) | | IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID | | Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Reserved | vDstPort | | Reserved | vDstPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Extended vDstPort | | Extended vDstPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31 0 7 8 15 16 23 24 31
IPv4 DestAddress (IPv4 Destination Address) IPv4 DestAddress (IPv4 Destination Address)
IPv4 address of the receiver (or Deaggregator) IPv4 address of the receiver (or Deaggregator).
Reserved Reserved
A 8-bit field. All bits MUST be set to 0 on transmit. This field An 8-bit field. All bits MUST be set to 0 on transmit. This
MUST be ignored on receipt. field MUST be ignored on receipt.
Flags Flags
A 8-bit field. The content and processing of this field are the 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 same as for the Flags field of the IPv4/UDP SESSION object (see
[RSVP]) [RSVP]).
PHB-ID (Per Hop Behavior Identification Code) PHB-ID (Per Hop Behavior Identification Code)
A 16-bit field containing the Per Hop Behavior Identification A 16-bit field containing the Per Hop Behavior Identification Code
Code of the PHB, or of the set of PHBs, from which Diffserv of the PHB, or of the set of PHBs, from which Diffserv resources
resources are to be reserved. This field MUST be encoded as are to be reserved. This field MUST be encoded as specified in
specified in section 2 of [PHB-ID]. Section 2 of [PHB-ID].
Reserved Reserved
A 16-bit field. All bits MUST be set to 0 on transmit. This A 16-bit field. All bits MUST be set to 0 on transmit. This
field MUST be ignored on receipt. field MUST be ignored on receipt.
VDstPort (Virtual Destination Port) VDstPort (Virtual Destination Port)
Generic Aggregate RSVP Reservations February 2007 A 16-bit identifier used in the SESSION that remains constant over
the life of the generic aggregate reservation.
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) Extended vDstPort (Extended Virtual Destination Port)
A 32-bit identifier used in the SESSION that remains constant A 32-bit identifier used in the SESSION that remains constant over
over the life of the generic aggregate reservation. the life of the generic aggregate reservation. A sender (or
A sender (or Aggregator) that wishes to narrow the scope of a Aggregator) that wishes to narrow the scope of a SESSION to the
SESSION to the sender-receiver pair (or Aggregator-Deaggregator sender-receiver pair (or Aggregator-Deaggregator pair) SHOULD
pair) SHOULD place its IPv4 address here as a network unique place its IPv4 address here as a network unique identifier. A
identifier. A sender (or Aggregator) that wishes to use a common sender (or Aggregator) that wishes to use a common session with
session with other senders (or Aggregators) in order to use a other senders (or Aggregators) in order to use a shared
shared reservation across senders (or Aggregators) MUST set this reservation across senders (or Aggregators) MUST set this field to
field to all zeros. all zeros.
o GENERIC-AGGREGATE-IP6 SESSION object: o GENERIC-AGGREGATE-IP6 SESSION object:
Class = 1 (SESSION) Class = 1 (SESSION)
C-Type = To be allocated by IANA C-Type = 18
0 7 8 15 16 23 24 31 0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IPv6 DestAddress (16 bytes) + + IPv6 DestAddress (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 9, line 52 skipping to change at page 10, line 30
| Extended vDstPort | | Extended vDstPort |
+ + + +
| (16 bytes) | | (16 bytes) |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15 16 25 26 31 0 7 8 15 16 25 26 31
IPv6 DestAddress (IPv6 Destination Address) IPv6 DestAddress (IPv6 Destination Address)
IPv6 address of the receiver (or Deaggregator) IPv6 address of the receiver (or Deaggregator).
Generic Aggregate RSVP Reservations February 2007
Reserved Reserved
A 8-bit field. All bits MUST be set to 0 on transmit. This field An 8-bit field. All bits MUST be set to 0 on transmit. This
MUST be ignored on receipt. field MUST be ignored on receipt.
Flags Flags
A 8-bit field. The content and processing of this field are the 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 same as for the Flags field of the IPv6/UDP SESSION object (see
[RSVP]) [RSVP]).
PHB-ID (Per Hop Behavior Identification Code) PHB-ID (Per Hop Behavior Identification Code)
A 16-bit field containing the Per Hop Behavior Identification A 16-bit field containing the Per Hop Behavior Identification Code
Code of the PHB, or of the set of PHBs, from which Diffserv of the PHB, or of the set of PHBs, from which Diffserv resources
resources are to be reserved. This field MUST be encoded as are to be reserved. This field MUST be encoded as specified in
specified in section 2 of [PHB-ID]. Section 2 of [PHB-ID].
Reserved Reserved
A 16-bit field. All bits MUST be set to 0 on transmit. This A 16-bit field. All bits MUST be set to 0 on transmit. This
field MUST be ignored on receipt. field MUST be ignored on receipt.
VDstPort (Virtual Destination Port) VDstPort (Virtual Destination Port)
A 16-bit identifier used in the SESSION that remains constant A 16-bit identifier used in the SESSION that remains constant over
over the life of the generic aggregate reservation. the life of the generic aggregate reservation.
Extended vDstPort (Extended Virtual Destination Port) Extended vDstPort (Extended Virtual Destination Port)
A 128-bit identifier used in the SESSION that remains constant A 128-bit identifier used in the SESSION that remains constant
over the life of the generic aggregate reservation. over the life of the generic aggregate reservation. A sender (or
A sender (or Aggregator) that wishes to narrow the scope of a Aggregator) that wishes to narrow the scope of a SESSION to the
SESSION to the sender-receiver pair (or Aggregator-Deaggregator sender-receiver pair (or Aggregator-Deaggregator pair) SHOULD
pair) SHOULD place its IPv6 address here as a network unique place its IPv6 address here as a network unique identifier. A
identifier. A sender (or Aggregator) that wishes to use a common sender (or Aggregator) that wishes to use a common session with
session with other senders (or Aggregators) in order to use a other senders (or Aggregators) in order to use a shared
shared reservation across senders (or Aggregators) MUST set this reservation across senders (or Aggregators) MUST set this field to
field to all zeros. all zeros.
2.2. SESSION-OF-INTEREST (SOI) Class 2.2. SESSION-OF-INTEREST (SOI) Class
Generic Aggregate RSVP Reservations February 2007
o GENERIC-AGG-IP4-SOI object: o GENERIC-AGG-IP4-SOI object:
Class = To be allocated by IANA Class = 132
C-Type = To be allocated by IANA C-Type = 1
0 7 8 15 16 23 24 31 0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- | | | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type | | Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// Content of a GENERIC-AGGREGATE-IP4 SESSION Object // // Content of a GENERIC-AGGREGATE-IP4 SESSION Object //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
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 This field contains a copy of the SESSION object of the session
which is of interest for the reservation. In the case of a that is of interest for the reservation. In the case of a
GENERIC-AGG-IP4-SOI, the session of interest conveyed in this GENERIC-AGG-IP4-SOI, the session of interest conveyed in this
field is a GENERIC-AGGREGATE-IP4 SESSION. field is a GENERIC-AGGREGATE-IP4 SESSION.
o GENERIC-AGG-IP6-SOI object: o GENERIC-AGG-IP6-SOI object:
Class = To be allocated by IANA Class = 132
(same as for GENERIC-AGG-IP4-SOI) C-Type = 2
C-Type = To be allocated by IANA
0 7 8 15 16 23 24 31 0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP6- | | | SOI |GEN-AGG-IP6- |
| Length (bytes) | Class-Num |SOI C-Type | | Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// Content of a GENERIC-AGGREGATE-IP6 SESSION Object // // Content of a GENERIC-AGGREGATE-IP6 SESSION Object //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
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 This field contains a copy of the SESSION object of the session
which is of interest for the reservation. In the case of a that is of interest for the reservation. In the case of a
GENERIC-AGG-IP6-SOI, the session of interest conveyed in this GENERIC-AGG-IP6-SOI, the session of interest conveyed in this
field is a GENERIC-AGGREGATE-IP6 SESSION. field is a GENERIC-AGGREGATE-IP6 SESSION.
For example, if a SESSION-OF-INTEREST object is used inside an E2E 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 Resv message (as per the procedures defined in Section 4) to indicate
which generic aggregate IPv4 session the E2E reservation is to be 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
Generic Aggregate RSVP Reservations February 2007
mapped onto, then the GENERIC-AGG-IP4-SOI object will be used and it
will be encoded like this: will be encoded like this:
0 7 8 15 16 23 24 31 0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- | | | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type | | Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) | | IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+--+----------+ +-------------+-------------+-------------+--+----------+
| Reserved | Flags | PHB-ID | | Reserved | Flags | PHB-ID |
skipping to change at page 12, line 33 skipping to change at page 13, line 6
0 7 8 15 16 23 24 31 0 7 8 15 16 23 24 31
Note that a SESSION-OF-INTEREST object is not a SESSION object in 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 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 does not modify the usage of the SESSION object in RSVP messages. It
simply allows conveying the Session of another RSVP reservation simply allows conveying the Session of another RSVP reservation
inside RSVP signaling messages, for some particular purposes. In the inside RSVP signaling messages, for some particular purposes. In the
context of this document, it is used to convey, inside an E2E RSVP 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 message pertaining to an end-to-end reservation, the Session of a
generic aggregate reservation associated with the E2E reservation. generic aggregate reservation associated with the E2E reservation.
Details for the corresponding procedures are specified in section 4. Details for the corresponding procedures are specified in Section 4.
3. Processing Rules For Handling Generic Aggregate RSVP Reservations 3. Processing Rules for Handling Generic Aggregate RSVP Reservations
This section presents extensions to the processing of RSVP messages This section presents extensions to the processing of RSVP messages
required by [RSVP] and presented in [RSVP-PROCESS]. These extensions required by [RSVP] and presented in [RSVP-PROCESS]. These extensions
are required in order to properly process the GENERIC-AGGREGATE-IP4 are required in order to properly process the GENERIC-AGGREGATE-IP4
(resp. GENERIC-AGGREGATE-IP6) SESSION object and the RSVP-AGGREGATE- or GENERIC-AGGREGATE-IP6 SESSION object and the RSVP-AGGREGATE-IP4 or
IP4 (resp. RSVP-AGGREGATE-IP6) FILTER_SPEC object. Values for RSVP-AGGREGATE-IP6 FILTER_SPEC object. Values for referenced error
referenced error codes can be found in [RSVP]. As with the other RSVP codes can be found in [RSVP]. As with the other RSVP documents,
documents, values for internally reported (API) errors are not values for internally reported (API) errors are not defined.
defined.
When referring to the new GENERIC-AGGREGATE-IP4 and GENERIC- When referring to the new GENERIC-AGGREGATE-IP4 and GENERIC-
AGGREGATE-IP6 SESSION objects, IP version will not be included and AGGREGATE-IP6 SESSION objects, IP version will not be included, and
they will be referred to simply as GENERIC-AGGREGATE SESSION, unless they will be referred to simply as GENERIC-AGGREGATE SESSION, unless
a specific distinction between IPv4 and IPv6 is being made. a specific distinction between IPv4 and IPv6 is being made.
When referring to the [RSVP-AGG] RSVP-AGGREGATE-IP4 and When referring to the [RSVP-AGG] RSVP-AGGREGATE-IP4 and RSVP-
RSVP-AGGREGATE-IP6 SESSION, FILTER_SPEC and SENDER_TEMPLATE objects, AGGREGATE-IP6 SESSION, FILTER_SPEC, and SENDER_TEMPLATE objects, IP
IP version will not be included and they will be referred to simply version will not be included, and they will be referred to simply as
RSVP-AGGREGATE, unless a specific distinction between IPv4 and IPv6
Generic Aggregate RSVP Reservations February 2007 is being made.
as RSVP-AGGREGATE, unless a specific distinction between IPv4 and
IPv6 is being made.
3.1. Extensions to Path and Resv Processing 3.1. Extensions to Path and Resv Processing
The following PATH message processing changes are defined: The following PATH message processing changes are defined:
o When a session is defined using the GENERIC-AGGREGATE SESSION o When a session is defined using the GENERIC-AGGREGATE SESSION
object, only the [RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATE may object, only the [RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATE may
be used. When this condition is violated in a PATH message be used. When this condition is violated in a PATH message
received by an RSVP end-station, the RSVP end-station SHOULD received by an RSVP end-station, the RSVP end-station SHOULD
report a "Conflicting C-Type" API error to the application. report a "Conflicting C-Type" API error to the application.
When this condition is violated in a PATH message received by When this condition is violated in a PATH message received by an
an RSVP router, the RSVP router MUST consider this as a RSVP router, the RSVP router MUST consider this as a message
message formatting error. formatting error.
o For PATH messages that contain the GENERIC-AGGREGATE SESSION o For PATH messages that contain the GENERIC-AGGREGATE SESSION
object, the VDstPort value, the Extended VDstPort value and object, the VDstPort value, the Extended VDstPort value, and the
the PHB-ID value should be recorded (in addition to the PHB-ID value should be recorded (in addition to the
destination/Deaggregator address and source/aggregator destination/Deaggregator address and source/Aggregator address).
address). These values form part of the recorded state of the These values form part of the recorded state of the session.
session. The PHB-ID may need to be passed to traffic control; The PHB-ID may need to be passed to traffic control; however the
however the vDstPort and Extended VDstPort are not passed to vDstPort and Extended VDstPort are not passed to traffic control
traffic control since they do not appear inside the data since they do not appear inside the data packets of the
packets of the corresponding reservation. corresponding reservation.
The following changes to RESV message processing are defined: The following changes to RESV message processing are defined:
o When a RESV message contains a [RSVP-AGG] RSVP-AGGREGATE o When a RESV message contains a [RSVP-AGG] RSVP-AGGREGATE
FILTER_SPEC, the session MUST be defined using either the FILTER_SPEC, the session MUST be defined using either the RSVP-
RSVP-AGGREGATE SESSION object (as per [RSVP-AGG]) or the AGGREGATE SESSION object (as per [RSVP-AGG]) or the GENERIC-
GENERIC-AGGREGATE SESSION object (as per this document). If AGGREGATE SESSION object (as per this document). If this
this condition is not met, an RSVP router or end-station MUST condition is not met, an RSVP router or end-station MUST
consider that there is a message formatting error. consider that there is a message formatting error.
o When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION o When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION type
type is GENERIC-AGGREGATE, each node uses data classifier as is GENERIC-AGGREGATE, each node uses data classifiers as per the
per the following: following:
* to perform Diffserv classification the node MUST rely on the * to perform Diffserv classification the node MUST rely on the
Diffserv data classifier based on the DSCP only. The Diffserv data classifier based on the DSCP only. The relevant
relevant DSCP value(s) is the one (are those) associated DSCP value(s) are those that are associated with the PHB-ID of
with the PHB-ID of the generic aggregate reservation. the generic aggregate reservation.
* If the node also needs to perform fine-grain classification * If the node also needs to perform fine-grain classification
(for example to perform fine-grain input policing at a trust (for example, to perform fine-grain input policing at a trust
boundary) then the node MUST create a data classifier boundary) then the node MUST create a data classifier
described by the 3-tuple <DestAddress, SrcAddress, DSCP>. described by the 3-tuple <DestAddress, SrcAddress, DSCP>.
Generic Aggregate RSVP Reservations February 2007 The relevant DSCP value(s) are those that are associated with
the PHB-ID of the generic aggregate reservation.
The relevant DSCP value(s) is the one (are those) associated
with the PHB-ID of the generic aggregate reservation.
Note that if multiple generic aggregate reservations are Note that if multiple generic aggregate reservations are
established with different Virtual Destination Ports (and/or established with different Virtual Destination Ports (and/or
different Extended Virtual Destination Ports) but with the different Extended Virtual Destination Ports) but with the
same <DestAddress, SrcAddress, PHB-ID>, then those cannot be same <DestAddress, SrcAddress, PHB-ID>, then those cannot be
distinguished by the classifier. If the router is using the distinguished by the classifier. If the router is using the
classifier for policing purposes, the router will therefore classifier for policing purposes, the router will therefore
police those together and MUST program the policing rate to police those together and MUST program the policing rate to
the sum of the reserved rate across all the corresponding the sum of the reserved rate across all the corresponding
reservations. reservations.
4. Procedures for Aggregation over Generic Aggregate RSVP Reservations 4. Procedures for Aggregation over Generic Aggregate RSVP Reservations
The procedures for aggregation of E2E reservations over generic The procedures for aggregation of E2E reservations over generic
aggregate RSVP reservations are the same as the procedures specified aggregate RSVP reservations are the same as the procedures specified
in [RSVP-AGG] with the exceptions of the procedure changes listed in in [RSVP-AGG] with the exceptions of the procedure changes listed in
this section. this section.
As specified in [RSVP-AGG], the Deaggregator is responsible for As specified in [RSVP-AGG], the Deaggregator is responsible for
mapping a given E2E reservation on a given aggregate reservation. The mapping a given E2E reservation on a given aggregate reservation.
Deaggregator requests establishment of a new aggregate reservation by The Deaggregator requests establishment of a new aggregate
sending to the Aggregator an E2E PathErr message with an error code reservation by sending to the Aggregator an E2E PathErr message with
of NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the Deaggregator conveys the an error code of NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the
DSCP of the new requested aggregate reservation by including a DCLASS Deaggregator conveys the DSCP of the new requested aggregate
Object in the E2E PathErr and encoding the corresponding DSCP inside. reservation by including a DCLASS Object in the E2E PathErr and
This document modifies and extends this procedure. The Deaggregator encoding the corresponding DSCP inside. This document modifies and
MUST include in the E2E PathErr message, a SESSION-OF-INTEREST object extends this procedure. The Deaggregator MUST include in the E2E
which contains the GENERIC-AGGREGATE Session to be used for PathErr message a SESSION-OF-INTEREST object that contains the
establishment of the requested generic aggregate reservation. Since GENERIC-AGGREGATE SESSION to be used for establishment of the
this GENERIC-AGGREGATE SESSION contains the PHB-ID, the DCLASS object requested generic aggregate reservation. Since this GENERIC-
need not be included in the PathErr message. 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 Note that the Deaggregator can easily ensure that different
Aggregators use different sessions for their Aggregate Path towards a Aggregators use different sessions for their Aggregate Path towards a
given Deaggregator. This is because the Deaggregator can easily given Deaggregator. This is because the Deaggregator can easily
select VDstPort and/or Extended VDstPort numbers which are different select VDstPort and/or Extended VDstPort numbers which are different
for each Aggregator (for example by using the Aggregator address as for each Aggregator (for example, by using the Aggregator address as
the Extended VDstPort) and can communicate those inside the GENERIC- the Extended VDstPort) and can communicate those inside the GENERIC-
AGGREGATE SESSION included in the SESSION-OF-INTEREST object. This AGGREGATE SESSION included in the SESSION-OF-INTEREST object. This
provides an easy solution to establish separate reservations from provides an easy solution to establish separate reservations from
every Aggregator to a given Deaggregator. Conversely, if reservation every Aggregator to a given Deaggregator. Conversely, if reservation
sharing were needed across multiple Aggregators, the Deaggregator sharing were needed across multiple Aggregators, the Deaggregator
could facilitate this by allocating the same VDstPort and Extended could facilitate this by allocating the same VDstPort and Extended
VDstPort to the multiple Aggregators and thus including the same VDstPort to the multiple Aggregators, and thus including the same
GENERIC-AGGREGATE SESSION inside the SESSION-OF-INTEREST object in GENERIC-AGGREGATE SESSION inside the SESSION-OF-INTEREST object in
the E2E PathErr messages sent to these Aggregators. The Aggregators the E2E PathErr messages sent to these Aggregators. The Aggregators
Generic Aggregate RSVP Reservations February 2007
could then all establish an Aggregate Path with the same GENERIC- could then all establish an Aggregate Path with the same GENERIC-
AGGREGATE SESSION. AGGREGATE SESSION.
Therefore various sharing scenarios can easily be supported. Policies Therefore, various sharing scenarios can easily be supported.
followed by the Deaggregator to determine which aggregators need Policies followed by the Deaggregator to determine which Aggregators
shared or separate reservations are beyond the scope of this document. need shared or separate reservations are beyond the scope of this
document.
The Deaggregator MAY also include in the E2E PathErr message (with an The Deaggregator MAY also include in the E2E PathErr message (with an
error code of NEW-AGGREGATE-NEEDED) additional RSVP objects which are error code of NEW-AGGREGATE-NEEDED) additional RSVP objects which are
to be used for establishment of the new needed generic aggregate to be used for establishment of the newly needed generic aggregate
reservation. For example, the Deaggregator MAY include in the E2E reservation. For example, the Deaggregator MAY include in the E2E
PathErr an RSVP Signaled Preemption Priority Policy Element (as PathErr an RSVP Signaled Preemption Priority Policy Element (as
specified in [RSVP-PREEMP]). specified in [RSVP-PREEMP]).
The [RSVP-AGG] procedures for processing of an E2E PathErr message The [RSVP-AGG] procedures for processing of an E2E PathErr message
received with an error code of NEW-AGGREGATE-NEEDED by the Aggregator received with an error code of NEW-AGGREGATE-NEEDED by the Aggregator
are extended correspondingly. On receipt of such a message containing are extended correspondingly. On receipt of such a message
a SESSION-OF-INTEREST object, the Aggregator MUST trigger containing a SESSION-OF-INTEREST object, the Aggregator MUST trigger
establishment of a generic aggregate reservation. In particular, it establishment of a generic aggregate reservation. In particular, it
MUST start sending aggregate Path messages with the GENERIC-AGGREGATE MUST start sending aggregate Path messages with the GENERIC-AGGREGATE
SESSION found in the received SESSION-OF-INTEREST object. When an SESSION found in the received SESSION-OF-INTEREST object. When an
RSVP Signaled Preemption Priority Policy Element is contained in the RSVP Signaled Preemption Priority Policy Element is contained in the
received E2E PathErr message, the Aggregator MUST include this object received E2E PathErr message, the Aggregator MUST include this object
in the Aggregate Path for the corresponding generic aggregate in the Aggregate Path for the corresponding generic aggregate
reservation. When other additional objects are contained in the reservation. When other additional objects are contained in the
received E2E PathErr message and those can be unambiguously received E2E PathErr message and those can be unambiguously
interpreted as related to the new needed generic aggregate interpreted as related to the new needed generic aggregate
reservation (as opposed to related to the E2E reservation), the reservation (as opposed to related to the E2E reservation), the
Aggregator SHOULD include those in the Aggregate Path for the Aggregator SHOULD include those in the Aggregate Path for the
corresponding generic aggregate reservation. The Aggregator MUST use corresponding generic aggregate reservation. The Aggregator MUST use
as the Source Address (i.e. as the Aggregator Address in the Sender- as the Source Address (i.e., as the Aggregator Address in the Sender-
Template) for the generic aggregate reservation, the address it uses Template) for the generic aggregate reservation, the address it uses
to identify itself as the PHOP when forwarding the E2E Path messages to identify itself as the PHOP (RSVP previous hop) when forwarding
corresponding to the E2E PathErr message. the E2E Path messages corresponding to the E2E PathErr message.
The Deaggregator follows the same procedures as described in [RSVP- The Deaggregator follows the same procedures as described in
AGG] for establishing, maintaining and clearing the aggregate Resv [RSVP-AGG] for establishing, maintaining and clearing the aggregate
state. However, a Deaggregator behaving according to the present Resv state. However, a Deaggregator behaving according to the
specification MUST use the generic aggregate reservations and hence present specification MUST use the generic aggregate reservations and
use the GENERIC-AGGREGATE SESSION specified earlier in this document. hence use the GENERIC-AGGREGATE SESSION specified earlier in this
document.
This document also modifies the procedures of [RSVP-AGG] related to This document also modifies the procedures of [RSVP-AGG] related to
exchange of E2E Resv messages between Deaggregator and Aggregator. exchange of E2E Resv messages between Deaggregator and Aggregator.
The Deaggregator MUST include the new SESSION-OF-INTEREST object in The Deaggregator MUST include the new SESSION-OF-INTEREST object in
the E2E Resv message, in order to indicate to the Aggregator the the E2E Resv message, in order to indicate to the Aggregator the
generic aggregate session to map a given E2E reservation onto. Again, generic aggregate session to map a given E2E reservation onto.
since the GENERIC-AGGREGATE SESSION (included in the SESSION-OF- Again, since the GENERIC-AGGREGATE SESSION (included in the SESSION-
INTEREST object) contains the PHB-ID, the DCLASS object need not be OF-INTEREST object) contains the PHB-ID, the DCLASS object need not
included in the E2E Resv message. The Aggregator MUST interpret the 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 RSVP Reservations February 2007
SESSION-OF-INTEREST object in the E2E Resv as indicating which
generic aggregate reservation session the corresponding E2E generic aggregate reservation session the corresponding E2E
reservation is mapped onto. The Aggregator MUST not include the reservation is mapped onto. The Aggregator MUST not include the
SESSION-OF-INTEREST object when sending an E2E Resv upstream towards SESSION-OF-INTEREST object when sending an E2E Resv upstream towards
the sender. the sender.
Based on relevant policy, the Deaggregator may decide at some point Based on relevant policy, the Deaggregator may decide at some point
that an aggregate reservation is no longer needed and should be torn that an aggregate reservation is no longer needed and should be torn
down. In that case, the Deaggregator MUST send an aggregate ResvTear. down. In that case, the Deaggregator MUST send an aggregate
On receipt of the aggregate ResvTear, the Aggregator SHOULD send an ResvTear. On receipt of the aggregate ResvTear, the Aggregator
aggregate PathTear (unless the relevant policy instructs the SHOULD send an aggregate PathTear (unless the relevant policy
aggregator to do otherwise or to wait for some time before doing so, instructs the Aggregator to do otherwise or to wait for some time
for example in order to speed-up potential re-establishment of the before doing so, for example in order to speed up potential re-
aggregate reservation in the future). establishment of the aggregate reservation in the future).
[RSVP-AGG] describes how the Aggregator and Deaggregator can [RSVP-AGG] describes how the Aggregator and Deaggregator can
communicate their respective identity to each other. For example the communicate their respective identities to each other. For example,
Aggregator includes one of its IP addresses in the RSVP HOP object in the Aggregator includes one of its IP addresses in the RSVP HOP
the E2E Path which is transmitted downstream and received by the object in the E2E Path that is transmitted downstream and received by
Deaggregator once it traversed the aggregation region. Similarly, the the Deaggregator once it traversed the aggregation region.
Deaggregator identifies itself to the Aggregator by including one of Similarly, the Deaggregator identifies itself to the Aggregator by
its IP addresses in various fields, including the ERROR SPECIFICATION including one of its IP addresses in various fields, including the
of the E2E PathErr message (containing the NEW-AGGREGATE-NEEDED Error ERROR SPECIFICATION of the E2E PathErr message (containing the NEW-
Code) and in the RSVP HOP object of the E2E Resv message. However, AGGREGATE-NEEDED Error Code) and in the RSVP HOP object of the E2E
[RSVP-AGG] does not discuss which IP addresses are to be selected by Resv message. However, [RSVP-AGG] does not discuss which IP
the aggregator and Deaggregator for such purposes. Because these addresses are to be selected by the Aggregator and Deaggregator for
addresses are intended to identify the Aggregator and Deaggregator such purposes. Because these addresses are intended to identify the
and not to identify any specific interface on these devices, this Aggregator and Deaggregator and not to identify any specific
document RECOMMENDS that the Aggregator and Deaggregator SHOULD use interface on these devices, this document RECOMMENDS that the
interface-independent addresses (for example a loopback address) Aggregator and Deaggregator SHOULD use interface-independent
whenever they communicate their respective identity to each other. addresses (for example, a loopback address) whenever they communicate
This ensures that respective identification of the Aggregator and their respective identities to each other. This ensures that
Deaggregator is not impacted by any interface state change on these respective identification of the Aggregator and Deaggregator is not
devices. In turns this results in more stable operations and impacted by any interface state change on these devices. In turn,
considerably reduced RSVP signaling in the aggregation region. For this results in more stable operations and considerably reduced RSVP
example, if interface-independent addresses are used by the signaling in the aggregation region. For example, if interface-
Aggregator and the Deaggregator, then a failure of an interface on independent addresses are used by the Aggregator and the
these devices may simply result in the rerouting of a given generic Deaggregator, then a failure of an interface on these devices may
aggregate reservation but will not result in the generic aggregate simply result in the rerouting of a given generic aggregate
reservation having to be torn down and another one established, nor reservation, but will not result in the generic aggregate reservation
will it result in a change of mapping of E2E reservations on generic 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 aggregate reservations (assuming the Aggregator and Deaggregator
still have reachability after the failure and the Aggregator and still have reachability after the failure, and the Aggregator and
Deaggregator are still on the shortest path to the destination). Deaggregator are still on the shortest path to the destination).
However, when identifying themselves to real RSVP neighbors (i.e. However, when identifying themselves to real RSVP neighbors (i.e.,
neighbors which are not on the other side of the aggregation region), neighbors that are not on the other side of the aggregation region),
the Aggregator and Deaggregator SHOULD continue using interface- the Aggregator and Deaggregator SHOULD continue using interface-
dependent addresses as per regular [RSVP] procedures. This applies dependent addresses as per regular [RSVP] procedures. This applies
Generic Aggregate RSVP Reservations February 2007
for example when the Aggregator identifies itself downstream as a for example when the Aggregator identifies itself downstream as a
PHOP for the generic aggregate reservation or identifies itself PHOP for the generic aggregate reservation or identifies itself
upstream as a NHOP for an E2E reservation. This also applies when the upstream as a NHOP (RSVP next hop) for an E2E reservation. This also
Deaggregator identifies itself downstream as a PHOP for the E2E applies when the Deaggregator identifies itself downstream as a PHOP
reservation or identifies itself upstream as a NHOP for the generic for the E2E reservation or identifies itself upstream as a NHOP for
aggregate reservation. As part of the processing of generic aggregate the generic aggregate reservation. As part of the processing of
reservations, interior routers (i.e. routers within the aggregation generic aggregate reservations, interior routers (i.e., routers
region) SHOULD continue using interface-dependent addresses as per within the aggregation region) SHOULD continue using interface-
regular [RSVP] procedures. dependent addresses as per regular [RSVP] procedures.
More generally, within the aggregation region (ie between Aggregator More generally, within the aggregation region (i.e., between
and Deaggregator) the operation of RSVP should be modeled with the Aggregator and Deaggregator) the operation of RSVP should be modeled
notion that E2E reservations are mapped to aggregate reservations and with the notion that E2E reservations are mapped to aggregate
are no longer tied to physical interfaces (as was the case with reservations and are no longer tied to physical interfaces (as was
regular RSVP). However, generic aggregate reservations (within the the case with regular RSVP). However, generic aggregate reservations
aggregation region) as well as E2E reservations outside the (within the aggregation region) as well as E2E reservations (outside
aggregation region, retain the model of regular RVSP and remain tied the aggregation region) retain the model of regular RVSP and remain
to physical interfaces. tied to physical interfaces.
As discussed above, generic aggregate reservations may be established As discussed above, generic aggregate reservations may be established
edge-to-edge as a result of the establishment of E2E reservations edge-to-edge as a result of the establishment of E2E reservations
(from outside the aggregation region) that are to be aggregated over (from outside the aggregation region) that are to be aggregated over
the aggregation region. However, generic aggregate reservations may the aggregation region. However, generic aggregate reservations may
also be used end-to-end by end-systems directly attached to a also be used end-to-end by end-systems directly attached to a
Diffserv domain, such as PSTN Gateways. In that case, the generic Diffserv domain, such as Public Switched Telephone Network (PSTN)
aggregate reservations may be established by the end-systems in gateways. In that case, the generic aggregate reservations may be
response to application-level triggers such as voice call signaling. established by the end-systems in response to application-level
Alternatively, generic aggregate reservations may also be used edge- triggers such as voice call signaling. Alternatively, generic
to-edge to manage bandwidth in a Diffserv cloud even if RSVP is not aggregate reservations may also be used edge-to-edge to manage
used end-to-end. A simple example of such a usage would be the static bandwidth in a Diffserv cloud even if RSVP is not used end-to-end. A
configuration of a generic aggregate reservation for a certain simple example of such a usage would be the static configuration of a
bandwidth for traffic from an ingress (Aggregator) router to an generic aggregate reservation for a certain bandwidth for traffic
egress (Deaggregator) router. from an ingress (Aggregator) router to an egress (Deaggregator)
router.
In this case, the establishment of the generic aggregate reservations In this case, the establishment of the generic aggregate reservations
is controlled by configuration on the Aggregator and on the is controlled by configuration on the Aggregator and on the
Deaggregator. Configuration on the Aggregator triggers generation of Deaggregator. Configuration on the Aggregator triggers generation of
the aggregate Path message and provides sufficient information to the the aggregate Path message and provides sufficient information to the
Aggregator to derive the content of the GENERIC-AGGREGATE SESSION Aggregator to derive the content of the GENERIC-AGGREGATE SESSION
object. This would typically include Deaggregator IP address, PHB-ID object. This would typically include Deaggregator IP address, PHB-ID
and possibly VDstPort. Configuration on the Deaggregator would and possibly VDstPort. Configuration on the Deaggregator would
instruct the Deaggregator to respond to a received generic aggregate instruct the Deaggregator to respond to a received generic aggregate
Path message and would provide sufficient information to the Path message and would provide sufficient information to the
Deaggregator to control the reservation. This may include bandwidth Deaggregator to control the reservation. This may include bandwidth
to be reserved by the Deaggregator (for a given Deaggregator/PHB- to be reserved by the Deaggregator (for a given <Deaggregator,
ID/VDstPort tuple). PHB-ID, VDstPort> tuple).
In the absence of E2E microflow reservations, the Aggregator can use In the absence of E2E microflow reservations, the Aggregator can use
a variety of policies to set the DSCP of packets passing into the a variety of policies to set the DSCP of packets passing into the
Generic Aggregate RSVP Reservations February 2007
aggregation region and how they are mapped onto generic aggregate aggregation region and how they are mapped onto generic aggregate
reservations, thus determining whether they gain access to the reservations, thus determining whether they gain access to the
resources reserved by the aggregate reservation. These policies are a resources reserved by the aggregate reservation. These policies are
matter of local configuration, as usual for a device at the edge of a a matter of local configuration, as is typical for a device at the
Diffserv cloud. edge of a Diffserv cloud.
5. Example Usage Of Multiple Generic Aggregate Reservations Per PHB 5. Example Usage Of Multiple Generic Aggregate Reservations per PHB
From a Given Aggregator to a Given Deaggregator from a Given Aggregator to a Given Deaggregator
Let us consider the environment depicted in Figure 2 below. RSVP Let us consider the environment depicted in Figure 2 below. RSVP
aggregation is used to support E2E reservations between Cloud-1, aggregation is used to support E2E reservations between Cloud-1,
Cloud-2 and Cloud-3. Cloud-2, and Cloud-3.
I----------I I----------I I----------I I----------I
I Cloud-1 I I Cloud-2 I I Cloud-1 I I Cloud-2 I
I----------I I----------I I----------I I----------I
| | | |
Agg-Deag-1------------ Agg-Deag-2 Agg-Deag-1------------ Agg-Deag-2
/ \ / \
/ Aggregation | / Aggregation |
| Region | | Region |
| | | |
| ---/ | ---/
\ / \ /
\Agg-Deag-3---------/ \Agg-Deag-3---------/
| |
I----------I I----------I
I Cloud-3 I I Cloud-3 I
I----------I I----------I
Figure 2 : Example Usage of Figure 2 : Example Usage of Generic Aggregate IP Reservations
Generic Aggregate IP Reservations
Let us assume that: Let us assume that:
o the E2E reservations from Cloud-1 to Cloud-3 have a preemption o The E2E reservations from Cloud-1 to Cloud-3 have a preemption
of either P1 or P2 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 o The E2E reservations from Cloud-2 to Cloud-3 have a preemption
treated in the aggregation region using the EF PHB) of either P1 or P2.
Generic Aggregate RSVP Reservations February 2007 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 o Traffic from the E2E reservations is encapsulated in aggregate
IP reservations from Aggregator to Deaggregator using GRE IP reservations from Aggregator to Deaggregator using Generic
tunneling ([GRE]). Routing Encapsulation [GRE] tunneling.
Then, the following generic aggregate RSVP reservations may be Then, the following generic aggregate RSVP reservations may be
established from Agg-Deag-1 to Agg-Deag-3 for aggregation of the end- established from Agg-Deag-1 to Agg-Deag-3 for aggregation of the end-
to-end RSVP reservations: to-end RSVP reservations:
A first generic aggregate reservation for aggregation of Voice (1) A first generic aggregate reservation for aggregation of Voice
reservations from Cloud-1 to Cloud-3 requiring use of P1: reservations from Cloud-1 to Cloud-3 requiring use of P1:
* GENERIC-AGGREGATE-IP4 SESSION: * GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress= Agg-Deag-3 IPv4 DestAddress= Agg-Deag-3
vDstPort=V1 vDstPort=V1
PHB-ID=EF PHB-ID=EF
Extended VDstPort= Agg-Deag-1 Extended VDstPort= Agg-Deag-1
* STYLE=FF or SE * STYLE=FF or SE
* IPv4/GPI FILTER_SPEC: * IPv4/GPI FILTER_SPEC:
IPv4 SrcAddress= Agg-Deag-1 IPv4 SrcAddress= Agg-Deag-1
* POLICY_DATA (PREEMPTION_PRI)=P1 * POLICY_DATA (PREEMPTION_PRI)=P1
A second generic aggregate reservation for aggregation of Voice (2) A second generic aggregate reservation for aggregation of Voice
reservations from Cloud-1 to Cloud-3 requiring use of P2: reservations from Cloud-1 to Cloud-3 requiring use of P2:
* GENERIC-AGGREGATE-IP4 SESSION: * GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress= Agg-Deag-3 IPv4 DestAddress= Agg-Deag-3
vDstPort=V2 vDstPort=V2
PHB-ID=EF PHB-ID=EF
Extended VDstPort= Agg-Deag-1 Extended VDstPort= Agg-Deag-1
* STYLE=FF or SE * STYLE=FF or SE
* IPv4/GPI FILTER_SPEC: * IPv4/GPI FILTER_SPEC:
IPv4 SrcAddress= Agg-Deag-1 IPv4 SrcAddress= Agg-Deag-1
* POLICY_DATA (PREEMPTION_PRI)=P2 * POLICY_DATA (PREEMPTION_PRI)=P2
where V1 and V2 are arbitrary VDstPort values picked by where V1 and V2 are arbitrary VDstPort values picked by Agg-
Agg-Deag-3. Deag-3.
The following generic aggregate RSVP reservations may be established 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 from Agg-Deag-2 to Agg-Deag-3 for aggregation of the end-to-end RSVP
reservations: reservations:
A third generic aggregate reservation for aggregation of Voice (3) A third generic aggregate reservation for aggregation of Voice
reservations from Cloud-2 to Cloud-3 requiring use of P1: reservations from Cloud-2 to Cloud-3 requiring use of P1:
Generic Aggregate RSVP Reservations February 2007
* GENERIC-AGGREGATE-IP4 SESSION: * GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress= Agg-Deag-3 IPv4 DestAddress= Agg-Deag-3
vDstPort=V3 vDstPort=V3
PHB-ID=EF PHB-ID=EF
Extended VDstPort= Agg-Deag-2 Extended VDstPort= Agg-Deag-2
* STYLE=FF or SE * STYLE=FF or SE
* IPv4/GPI FILTER_SPEC: * IPv4/GPI FILTER_SPEC:
IPv4 SrcAddress= Agg-Deag-2 IPv4 SrcAddress= Agg-Deag-2
* POLICY_DATA (PREEMPTION_PRI)=P1 * POLICY_DATA (PREEMPTION_PRI)=P1
A fourth generic aggregate reservation for aggregation of Voice (4) A fourth generic aggregate reservation for aggregation of Voice
reservations from Cloud-2 to Cloud-3 requiring use of P2: reservations from Cloud-2 to Cloud-3 requiring use of P2:
* GENERIC-AGGREGATE-IP4 SESSION: * GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress= Agg-Deag-3 IPv4 DestAddress= Agg-Deag-3
vDstPort=V4 vDstPort=V4
PHB-ID=EF PHB-ID=EF
Extended VDstPort= Agg-Deag-2 Extended VDstPort= Agg-Deag-2
* STYLE=FF or SE * STYLE=FF or SE
* IPv4/GPI FILTER_SPEC: * IPv4/GPI FILTER_SPEC:
IPv4 SrcAddress= Agg-Deag-2 IPv4 SrcAddress= Agg-Deag-2
* POLICY_DATA (PREEMPTION_PRI)=P2 * POLICY_DATA (PREEMPTION_PRI)=P2
where V3 and V4 are arbitrary VDstPort values picked by Agg-Deag-3. where V3 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, Note that V3 and V4 could be equal to V1 and V2 (respectively)
in this example, the Extended VDstPort of the GENERIC-AGGREGATE since, in this example, the Extended VDstPort of the GENERIC-
Session contains the address of the Deaggregator and, thus, ensures AGGREGATE Session contains the address of the Aggregator and,
that different sessions are used for each Deaggregator. thus, ensures that different sessions are used from each
Aggregator.
6. Security Considerations 6. Security Considerations
In the environments addressed by this document, RSVP messages are In the environments addressed by this document, RSVP messages are
used to control resource reservations for generic aggregate used to control resource reservations for generic aggregate
reservations and may be used to control resource reservations for E2E reservations and may be used to control resource reservations for E2E
reservations being aggregated over the generic aggregate reservations being aggregated over the generic aggregate
reservations. To ensure the integrity of the associated reservation reservations. To ensure the integrity of the associated reservation
and admission control mechanisms, the RSVP Authentication mechanisms and admission control mechanisms, the RSVP Authentication mechanisms
defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] may be used. These defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] may be used. These
protect RSVP message integrity hop-by-hop and provide node protect RSVP message integrity hop-by-hop and provide node
authentication as well as replay protection, thereby protecting authentication as well as replay protection, thereby protecting
Generic Aggregate RSVP Reservations February 2007
against corruption and spoofing of RSVP messages. These hop-by-hop against corruption and spoofing of RSVP messages. These hop-by-hop
integrity mechanisms can be naturally used to protect the RSVP integrity mechanisms can be naturally used to protect the RSVP
messages used for generic aggregate reservations and to protect RSVP messages used for generic aggregate reservations and to protect RSVP
messages used for E2E reservations outside the aggregation region. messages used for E2E reservations outside the aggregation region.
These hop-by-hop RSVP integrity mechanisms can also be used to These hop-by-hop RSVP integrity mechanisms can also be used to
protect RSVP messages used for E2E reservations when those transit protect RSVP messages used for E2E reservations when those transit
through the aggregation region. This is because the Aggregator and through the aggregation region. This is because the Aggregator and
Deaggregator behave as RSVP neighbors from the viewpoint of the E2E Deaggregator behave as RSVP neighbors from the viewpoint of the E2E
flows (even if they are not necessarily IP neighbors). flows (even if they are not necessarily IP neighbors).
[RSVP-CRYPTO1] discusses several approaches for key distribution. [RSVP-CRYPTO1] discusses several approaches for key distribution.
First, the RSVP Authentication shared keys can be distributed First, the RSVP Authentication shared keys can be distributed
manually. This is the base option and its support is mandated for any manually. This is the base option and its support is mandated for
implementation. However, in some environments, this approach may any implementation. However, in some environments, this approach may
become a burden if keys frequently change over time. Alternatively, a become a burden if keys frequently change over time. Alternatively,
standard key management protocol for secure key distribution can be a standard key management protocol for secure key distribution can be
used. However, existing key distribution protocols may not be used. However, existing key distribution protocols may not be
appropriate in all environments because of the complexity or appropriate in all environments because of the complexity or
operational burden they involve. operational burden they involve.
The use of RSVP Authentication in parts of the network where there 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 may be one or more IP hops in between two RSVP neighbors raises an
additional challenge. This is because, with some RSVP messages such 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 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 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 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 dynamically re-discover it when it changes, say because of a routing
change). Hence, the RSVP router may not know which security change). Hence, the RSVP router may not know which security
association to use when forwarding such a message. This applies in association to use when forwarding such a message. This applies in
particular to the case where RSVP Authentication mechanisms are to be particular to the case where RSVP Authentication mechanisms are to be
used for protection of RSVP E2E messages (e.g. E2E Path) while they used for protection of RSVP E2E messages (e.g., E2E Path) while they
transit through an aggregation region and where the dynamic transit through an aggregation region and where the dynamic
Deaggregator determination procedure defined in [RSVP-AGG] is used. Deaggregator determination procedure defined in [RSVP-AGG] is used.
This is because the Aggregator and the Deaggregator behave as RSVP This is because the Aggregator and the Deaggregator behave as RSVP
neighbors for the E2E reservation, while there may be one or more IP 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 hops in between them, and the Aggregator does not know ahead of time
which router is going to act as the Deaggregator. which router is going to act as the Deaggregator.
In that situation, one approach is to share the same RSVP In that situation, one approach is to share the same RSVP
Authentication shared key across all the RSVP routers of a part of Authentication shared key across all the RSVP routers of a part of
the network where there may be RSVP neighbors with IP hops in the network where there may be RSVP neighbors with IP hops in
between. For example, all the Aggregators or Deaggregators of an between. For example, all the Aggregators or Deaggregators of an
aggregation region could share the same RSVP Authentication key, aggregation region could share the same RSVP Authentication key,
while different per-neighbor keys could be used between any RSVP while different per-neighbor keys could be used between any RSVP
router pair straddling the boundary between two administrative router pair straddling the boundary between two administrative
domains that have agreed to use RSVP signaling. domains that have agreed to use RSVP signaling.
When the same RSVP Authentication shared key is to be shared among When the same RSVP Authentication shared key is to be shared among
multiple RSVP neighbors, manual key distribution may be used. For multiple RSVP neighbors, manual key distribution may be used. For
Generic Aggregate RSVP Reservations February 2007
situations where RSVP is being used for multicast flows, it might situations where RSVP is being used for multicast flows, it might
also be possible, in the future, to adapt a multicast key management also be possible, in the future, to adapt a multicast key management
method (e.g. from IETF Multicast Security Working Group) for key method (e.g. from IETF Multicast Security Working Group) for key
distribution with such multicast RSVP usage. For situations where distribution with such multicast RSVP usage. For situations where
RSVP is being used for unicast flows across domain boundaries, it is RSVP is being used for unicast flows across domain boundaries, it is
not currently clear how one might provide automated key not currently clear how one might provide automated key management.
management. 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 Specification of a specific automated key management technique is
confidentiality is required, IPsec ESP [IPSEC-ESP] may be used, outside the scope of this document. Operators should consider these
although it imposes the burden of key distribution. It also faces the key management issues when contemplating deployment of this
additional issue discussed for key management above in case there can specification.
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 The RSVP Authentication mechanisms do not provide confidentiality.
between RSVP hops, perhaps by adapting confidentiality solutions If confidentiality is required, IPsec ESP [IPSEC-ESP] may be used,
developed by the IETF MSEC Working Group. Such confidentiality although it imposes the burden of key distribution. It also faces
solutions for RSVP are outside the scope of this document. 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 Protection against traffic analysis is also not provided by RSVP
Authentication. Since generic aggregate reservations are intended to Authentication. Since generic aggregate reservations are intended to
reserve resources collectively for a whole set of users or hosts, reserve resources collectively for a whole set of users or hosts,
malicious snooping of the corresponding RSVP messages could provide malicious snooping of the corresponding RSVP messages could provide
more traffic analysis information than snooping of an E2E more traffic analysis information than snooping of an E2E
reservation. When RSVP neighbors are directly attached, mechanisms reservation. When RSVP neighbors are directly attached, mechanisms
such as bulk link encryption might be used when protection against such as bulk link encryption might be used when protection against
traffic analysis is required. This approach could be used inside the traffic analysis is required. This approach could be used inside the
aggregation region for protection of the generic aggregate aggregation region for protection of the generic aggregate
skipping to change at page 22, line 52 skipping to change at page 23, line 45
When generic aggregate reservations are used for aggregation of E2E When generic aggregate reservations are used for aggregation of E2E
reservations, the security considerations discussed in [RSVP-AGG] reservations, the security considerations discussed in [RSVP-AGG]
apply and are revisited here. apply and are revisited here.
First, the loss of an aggregate reservation to an aggressor causes First, the loss of an aggregate reservation to an aggressor causes
E2E flows to operate unreserved, and the reservation of a great E2E flows to operate unreserved, and the reservation of a great
excess of bandwidth may result in a denial of service. These issues excess of bandwidth may result in a denial of service. These issues
are not confined to the extensions defined in the present document: are not confined to the extensions defined in the present document:
RSVP itself has them. However, they may be exacerbated here by the RSVP itself has them. However, they may be exacerbated here by the
fact that each aggregate reservation typically facilitates fact that each aggregate reservation typically facilitates
communication for many sessions. Hence compromising one such communication for many sessions. Hence, compromising one such
aggregate reservation can result in more damage than compromising a aggregate reservation can result in more damage than compromising a
typical E2E reservation. Use of the RSVP Authentication mechanisms to typical E2E reservation. Use of the RSVP Authentication mechanisms
protect against such attacks has been discussed above. to protect against such attacks has been discussed above.
Generic Aggregate RSVP Reservations February 2007
An additional security consideration specific to RSVP aggregation An additional security consideration specific to RSVP aggregation
involves the modification of the IP protocol number in RSVP Path involves the modification of the IP protocol number in RSVP Path
messages that traverse an aggregation region. Malicious modification messages that traverse an aggregation region. Malicious modification
of the IP protocol number in a Path message would cause the message 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 to be ignored by all subsequent RSVP devices on its path, preventing
reservations from being made. It could even be possible to correct reservations from being made. It could even be possible to correct
the value before it reached the receiver, making it difficult to the value before it reached the receiver, making it difficult to
detect the attack. Note that in theory, it might also be possible for detect the attack. Note that, in theory, it might also be possible
a node to modify the IP protocol number for non-RSVP messages as 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 well, thus interfering with the operation of other protocols. It is
RECOMMENDED that implementations of this specification only support RECOMMENDED that implementations of this specification only support
modification of the IP protocol number for RSVP Path, PathTear, and modification of the IP protocol number for RSVP Path, PathTear, and
ResvConf messages. That is, a general facility for modification of ResvConf messages. That is, a general facility for modification of
the IP protocol number SHOULD NOT be made available. the IP protocol number SHOULD NOT be made available.
Network operators deploying routers with RSVP aggregation capability Network operators deploying routers with RSVP aggregation capability
should be aware of the risks of inappropriate modification of the IP should be aware of the risks of inappropriate modification of the IP
protocol number and should take appropriate steps (physical security, protocol number and should take appropriate steps (physical security,
password protection, etc.) to reduce the risk that a router could be password protection, etc.) to reduce the risk that a router could be
configured by an attacker to perform malicious modification of the configured by an attacker to perform malicious modification of the
protocol number. protocol number.
7. IANA Considerations 7. IANA Considerations
This document requests IANA to modify the RSVP parameters registry, IANA modified the RSVP parameters registry, 'Class Names, Class
'Class Names, Class Numbers, and Class Types' subregistry, and assign Numbers, and Class Types' subregistry, and assigned two new C-Types
two new C-Types under the existing SESSION Class (Class number 1), as under the existing SESSION Class (Class number 1), as described
suggested below: below:
Class Class
Number Class Name Reference Number Class Name Reference
------ ----------------------- --------- ------ ----------------------- ---------
1 SESSION [RFC2205] 1 SESSION [RFC2205]
Class Types or C-Types: Class Types or C-Types:
xx GENERIC-AGGREGATE-IP4 [RFCXXXX] 17 GENERIC-AGGREGATE-IP4 [RFC4860]
yy GENERIC-AGGREGATE-IP6 [RFCXXXX] 18 GENERIC-AGGREGATE-IP6 [RFC4860]
IANA also modified the RSVP parameters registry, 'Class Names, Class
[Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC Numbers, and Class Types' subregistry, and assigned one new Class
number of this specification. Suggested values: xx=17, yy=18] Number for the SESSION-OF-INTEREST class and two new C-Types for that
class, according to the table below:
This document also requests IANA to modify the RSVP parameters
registry, 'Class Names, Class Numbers, and Class Types' subregistry,
Generic Aggregate RSVP Reservations February 2007
and assign one new Class Number for the SESSION-OF-INTEREST class and
two new C-Types for that class, according to the following table
below:
Class Class
Number Class Name Reference Number Class Name Reference
------ ----------------------- --------- ------ ----------------------- ---------
zzz SESSION-OF-INTEREST [RFCXXXX] 132 SESSION-OF-INTEREST [RFC4860]
Class Types or C-Types: Class Types or C-Types:
aa GENERIC-AGG-IP4-SOI [RFCXXXX] 1 GENERIC-AGG-IP4-SOI [RFC4860]
bb GENERIC-AGG-IP6-SOI [RFCXXXX] 2 GENERIC-AGG-IP6-SOI [RFC4860]
[Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC
number of this specification. Suggested values: zzz=132 aa=1, bb=2]
These allocations are in accordance with [RSVP-MOD]. These allocations are in accordance with [RSVP-MOD].
8. Acknowledgments 8. Acknowledgments
This document borrows heavily from [RSVP-AGG]. It also borrows the This document borrows heavily from [RSVP-AGG]. It also borrows the
concepts of Virtual Destination Port and Extended Virtual Destination concepts of Virtual Destination Port and Extended Virtual Destination
Port respectively from [RSVP-IPSEC] and [RSVP-TE]. Port from [RSVP-IPSEC] and [RSVP-TE], respectively.
Also, we thank Fred Baker, Roger Levesque, Carol Iturralde, Daniel Also, we thank Fred Baker, Roger Levesque, Carol Iturralde, Daniel
Voce, Anil Agarwal, Alexander Sayenko and Anca Zamfir for their input Voce, Anil Agarwal, Alexander Sayenko, and Anca Zamfir for their
into the content of this document. Thanks to Steve Kent for input into the content of this document. Thanks to Steve Kent for
insightful comments on usage of RSVP reservations in IPsec insightful comments on usage of RSVP reservations in IPsec
environments. environments.
Ran Atkinson, Fred Baker, Luc Billot, Pascal Delprat and Eric Vyncke Ran Atkinson, Fred Baker, Luc Billot, Pascal Delprat, and Eric Vyncke
provided guidance and suggestions for the security considerations provided guidance and suggestions for the security considerations
section. section.
9. Normative References 9. Normative References
[IPSEC-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC [IPSEC-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
4303, December 2005. RFC 4303, December 2005.
[PHB-ID] "Per Hop Behavior Identification Codes", Black et al., [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
RFC3140, June 2001. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RSVP] "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional [PHB-ID] Black, D., Brim, S., Carpenter, B., and F. Le
Specification", Braden et al, RFC2205. Faucheur, "Per Hop Behavior Identification Codes", RFC
3140, June 2001.
Generic Aggregate RSVP Reservations February 2007 [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] "Aggregation of RSVP for IPv4 and IPv6 Reservations", [RSVP-AGG] Baker, F., Iturralde, C., Le Faucheur, F., and B.
Baker et al, RFC3175. Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
[RSVP-CRYPTO1] Baker at al, RSVP Cryptographic Authentication, RFC [RSVP-CRYPTO1] Baker, F., Lindell, B., and M. Talwar, "RSVP
2747, January 2000. Cryptographic Authentication", RFC 2747, January 2000.
[RSVP-CRYPTO2] Braden and Zhang, RSVP Cryptographic Authentication - [RSVP-CRYPTO2] Braden, R. and L. Zhang, "RSVP Cryptographic
Updated Message Type Value, RFC 3097, April 2001. Authentication -- Updated Message Type Value", RFC
3097, April 2001.
[RSVP-IPSEC] "RSVP Extensions for IPsec Data Flows", Berger et al, [RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
RFC2207. Data Flows", RFC 2207, September 1997.
[RSVP-MOD] "Procedures for Modifying the Resource reSerVation [RSVP-MOD] Kompella, K. and J. Lang, "Procedures for Modifying
Protocol (RSVP)", Kompella and Lang, RFC 3936, BCP 96. the Resource reSerVation Protocol (RSVP)", BCP 96, RFC
3936, October 2004.
10. Informative References 10. Informative References
[BW-REDUC] "A Resource Reservation Extension for the Reduction of [BW-REDUC] Polk, J. and S. Dhesikan, "A Resource Reservation
Bandwidth of a Reservation Flow", Polk et al, RFC 4495. Protocol (RSVP) Extension for the Reduction of
Bandwidth of a Reservation Flow", RFC 4495, May 2006.
[GRE] "Generic Routing Encapsulation (GRE) ", Farinacci et al, RFC [GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
2784. Traina, "Generic Routing Encapsulation (GRE)", RFC
2784, March 2000.
[RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy
Element", RFC 3181, October 2001. Element", RFC 3181, October 2001.
[RSVP-PROCESS] "Resource ReSerVation Protocol (RSVP) -- Version 1 [RSVP-PROCESS] Braden, R. and L. Zhang, "Resource ReSerVation
Message Processing Rules", Braden et al, RFC2209. Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997.
[RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels,
RFC 3209, December 2001.
[RSVP-TUNNEL] "RSVP Operation Over IP Tunnels", Terzis et al., RFC
2746, January 2000.
[SIG-NESTED] "QoS Signaling in a Nested Virtual Private Network",
Baker et al, draft-ietf-tsvwg-vpn-signaled-preemption, work in
progress.
11. Authors' Addresses
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot Sophia-Antipolis
Generic Aggregate RSVP Reservations February 2007
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
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
Generic Aggregate RSVP Reservations February 2007
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.
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
contained in BCP 78, and except as set forth therein, the authors V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
retain all their rights. LSP Tunnels", RFC 3209, December 2001.
D [RSVP-TUNNEL] Terzis, A., Krawczyk, J., Wroclawski, J., and L.
i Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
c January 2000.
s
l
a
m
i
r
e
This document and the information contained herein are provided on an [SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Virtual Private Network", Work in Progress, February
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2007.
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.
Appendix A: Example Signaling Flow Appendix A. Example Signaling Flow
This Appendix does not provide additional specification. It only This appendix does not provide additional specification. It only
illustrates the specification detailed in section 4 through a illustrates the specification detailed in Section 4 through a
possible flow of RSVP signaling messages. This flow assumes an possible flow of RSVP signaling messages. This flow assumes an
environment where E2E reservations are aggregated over generic environment where E2E reservations are aggregated over generic
aggregate RSVP reservations. It illustrates a possible RSVP message aggregate RSVP reservations. It illustrates a possible RSVP message
flow that could take place in the successful establishment of a flow that could take place in the successful establishment of a
unicast E2E reservation which is the first between a given pair of unicast E2E reservation that is the first between a given pair of
Aggregator/Deaggregator. Aggregator/Deaggregator.
Generic Aggregate RSVP Reservations February 2007
Aggregator Deaggregator Aggregator Deaggregator
E2E Path E2E Path
-----------> ----------->
(1) (1)
E2E Path E2E Path
-------------------------------> ------------------------------->
(2) (2)
E2E PathErr(New-agg-needed,SOI=GAx) E2E PathErr(New-agg-needed,SOI=GAx)
<---------------------------------- <----------------------------------
skipping to change at page 28, line 48 skipping to change at page 29, line 46
E2E Resv E2E Resv
<--------- <---------
(8) (8)
E2E Resv (SOI=GAx) E2E Resv (SOI=GAx)
<----------------------------- <-----------------------------
(9) (9)
E2E Resv E2E Resv
<----------- <-----------
(1) The Aggregator forwards E2E Path into the aggregation region (1) The Aggregator forwards E2E Path into the aggregation region
after modifying its IP Protocol Number to RSVP-E2E-IGNORE after modifying its IP protocol number to RSVP-E2E-IGNORE
(2) Let's assume no Aggregate Path exists. To be able to accurately (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 update the ADSPEC of the E2E Path, the Deaggregator needs the
of Aggregate PATH. In this example the Deaggregator elects to ADSPEC of Aggregate Path. In this example, the Deaggregator
instruct the Aggregator to set up Aggregate Path states for the two elects to instruct the Aggregator to set up Aggregate Path states
supported PHB-IDs. To do that, the Deaggregator sends two E2E PathErr for the two supported PHB-IDs. To do that, the Deaggregator
sends two E2E PathErr messages with a New-Agg-Needed PathErr
Generic Aggregate RSVP Reservations February 2007 code. Both PathErr messages also contain a SESSION-OF-INTEREST
(SOI) object. In the first E2E PathErr, the SOI contains a
messages with a New-Agg-Needed PathErr code. Both PathErr messages GENERIC-AGGREGATE SESSION (GAx) whose PHB-ID is set to x. In the
also contain a SESSION-OF-INTEREST (SOI) object. In the first E2E second E2E PathErr, the SOI contains a GENERIC-AGGREGATE SESSION
PathErr, the SOI contains a GENERIC-AGGREGATE SESSION (GAx) whose (GAy) whose PHB-ID is set to y. In both messages the GENERIC-
PHB-ID is set to x. In the second E2E PathErr, the SOI contains a AGGREGATE SESSION contains an interface-independent Deaggregator
GENERIC-AGGREGATE SESSION (GAy) whose PHB-ID is set to y. In both address inside the DestAddress and appropriate values inside the
messages the GENERIC-AGGREGATE SESSION contains an interface- vDstPort and Extended vDstPort fields.
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 (3) The Aggregator follows the request from the Deaggregator and
signals an Aggregate Path for both GENERIC-AGGREGATE Sessions (GAx signals an Aggregate Path for both GENERIC-AGGREGATE Sessions
and GAy). (GAx and GAy).
(4) The Deaggregator takes into account the information contained in (4) The Deaggregator takes into account the information contained in
the ADSPEC from both Aggregate Path and updates the E2E Path ADSPEC the ADSPEC from both Aggregate Paths and updates the E2E Path
accordingly. The Deaggregator also modifies the E2E Path IP Protocol ADSPEC accordingly. The Deaggregator also modifies the E2E Path
Number to RSVP before forwarding it. IP protocol number to RSVP before forwarding it.
(5) In this example, the Deaggregator elects to immediately proceed (5) In this example, the Deaggregator elects to immediately proceed
with establishment of generic aggregate reservations for both PHB-IDs. with establishment of generic aggregate reservations for both
In effect, the Deaggregator can be seen as anticipating the actual PHB-IDs. In effect, the Deaggregator can be seen as anticipating
demand of E2E reservations so that resources are available on the actual demand of E2E reservations so that resources are
the generic aggregate reservations when the E2E Resv requests arrive, available on the generic aggregate reservations when the E2E Resv
in order to speed up establishment of E2E reservations. Assume requests arrive, in order to speed up establishment of E2E
also that the Deaggregator includes the optional Resv Confirm reservations. Assume also that the Deaggregator includes the
Request in these Aggregate Resv. optional Resv Confirm Request in these Aggregate Resv.
(6) The Aggregator merely complies with the received ResvConfirm (6) The Aggregator merely complies with the received ResvConfirm
Request and returns the corresponding Aggregate ResvConfirm. Request and returns the corresponding Aggregate ResvConfirm.
(7) The Deaggregator has explicit confirmation that both Aggregate (7) The Deaggregator has explicit confirmation that both Aggregate
Resv are established. Resvs are established.
(8) On receipt of the E2E Resv, the Deaggregator applies the mapping (8) On receipt of the E2E Resv, the Deaggregator applies the mapping
policy defined by the network administrator to map the E2E Resv policy defined by the network administrator to map the E2E Resv
onto a generic aggregate reservation. Let's assume that this policy onto a generic aggregate reservation. Let's assume that this
is such that the E2E reservation is to be mapped onto the generic policy is such that the E2E reservation is to be mapped onto the
aggregate reservation with PHB-ID=x. The Deaggregator knows that a generic aggregate reservation with PHB-ID=x. The Deaggregator
generic aggregate reservation (GAx) is in place for the corresponding knows that a generic aggregate reservation (GAx) is in place for
PHB-ID since (7). The Deaggregator performs admission control of the the corresponding PHB-ID since (7). The Deaggregator performs
E2E Resv onto the generic aggregate Reservation for PHB-ID=x (GAx). admission control of the E2E Resv onto the generic aggregate
Assuming that the generic aggregate reservation for PHB-ID=x (GAx) reservation for PHB-ID=x (GAx). Assuming that the generic
had been established with sufficient bandwidth to support the E2E aggregate reservation for PHB-ID=x (GAx) had been established
Resv, the Deaggregator adjusts its counter, tracking the unused with sufficient bandwidth to support the E2E Resv, the
bandwidth on the generic aggregate reservation and forwards the E2E 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 Resv to the Aggregator including a SESSION-OF-INTEREST object
conveying the selected mapping onto GAx (and hence onto PHB-ID=x). conveying the selected mapping onto GAx (and hence onto
PHB-ID=x).
Generic Aggregate RSVP Reservations February 2007
(9) The Aggregator records the mapping of the E2E Resv onto GAx (and (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 onto PHB-ID=x). The Aggregator removes the SOI object and
the E2E Resv towards the sender. forwards the E2E Resv towards the sender.
Expires: August 13, 2007 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
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.
 End of changes. 160 change blocks. 
634 lines changed or deleted 479 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/