draft-ietf-tsvwg-rsvp-ipsec-00.txt   draft-ietf-tsvwg-rsvp-ipsec-01.txt 
Generic Aggregate RSVP Reservations February 2006
Internet Draft Francois Le Faucheur Internet Draft Francois Le Faucheur
Bruce Davie Bruce Davie
Cisco Systems, Inc. Cisco Systems, Inc.
Pratik Bose Pratik Bose
Lockheed Martin Lockheed Martin
Chris Christou Chris Christou
Michael Davenport Michael Davenport
Booz Allen Hamilton Booz Allen Hamilton
draft-ietf-tsvwg-rsvp-ipsec-00.txt draft-ietf-tsvwg-rsvp-ipsec-01.txt
Expires: August 2006 February 2006
Generic Aggregate RSVP Reservations Generic Aggregate RSVP Reservations
draft-ietf-tsvwg-rsvp-ipsec-00.txt draft-ietf-tsvwg-rsvp-ipsec-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 4 skipping to change at page 2, line 4
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
[RSVP-AGG] defines aggregate RSVP reservations allowing resources to [RSVP-AGG] defines aggregate RSVP reservations allowing resources to
be reserved in a Diffserv network for a given DSCP from a given be reserved in a Diffserv network for a given DSCP from a given
source to a given destination. [RSVP-AGG] also defines how end-to-end source to a given destination. [RSVP-AGG] also defines how end-to-end
Generic Aggregate RSVP Reservations February 2006
RSVP reservations can be aggregated onto such aggregate reservations RSVP reservations can be aggregated onto such aggregate reservations
when transiting through a Diffserv cloud. There are situations where when transiting through a Diffserv cloud. There are situations where
multiple such aggregate reservations are needed for the same source multiple such aggregate reservations are needed for the same source
IP address, destination IP address and DSCP. However, this is not IP address, destination IP address and DSCP. However, this is not
supported by the aggregate reservations defined in [RSVP-AGG]. In supported by the aggregate reservations defined in [RSVP-AGG]. In
order to support this, the present document defines a more flexible order to support this, the present document defines a more flexible
type of aggregate RSVP reservations, referred to as generic aggregate type of aggregate RSVP reservations, referred to as generic aggregate
reservation. Multiple such generic aggregate reservations can be reservation. Multiple such generic aggregate reservations can be
established for a given DSCP from a given source IP address to a established for a given DSCP from a given source IP address to a
given destination IP address. The generic aggregate reservations may given destination IP address. The generic aggregate reservations may
skipping to change at page 2, line 40 skipping to change at page 2, line 37
1. Introduction 1. Introduction
[RSVP-AGG] defines RSVP aggregate reservations allowing resources to [RSVP-AGG] defines RSVP aggregate reservations allowing resources to
be reserved in a Diffserv network for a flow characterized by its 3- be reserved in a Diffserv network for a flow characterized by its 3-
tuple <source IP address, destination IP address, DSCP>. tuple <source IP address, destination IP address, DSCP>.
[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 RSVP reservations onto such aggregate reservations when transiting
through a Diffserv cloud. Such aggregation is illustrated in Figure 1. through a Diffserv cloud. Such aggregation is illustrated 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
H--------/ |-----| |------| \-------->H H--------/ |-----| |------| \-------->H
| | | |
Generic Aggregate RSVP Reservations February 2006
\ / \ /
-------------------------- --------------------------
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 [RSVP-
AGG] that contains the receiver (or Deaggregator) IP address and the AGG] that contains the receiver (or Deaggregator) IP address and the
DSCP of the PHB from which Diffserv resources are to be reserved. For DSCP of the PHB from which Diffserv resources are to be reserved. For
example, in the case of IPv4, the SESSION object is specified as: example, in the case of IPv4, the SESSION object is specified as:
o IP4 SESSION object: Class = SESSION, o Class = SESSION,
C-Type = RSVP-AGGREGATE-IP4 C-Type = RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| 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 a SENDER_TEMPLATE and FILTER_SPEC
types specified in [RSVP-AGG] and which contains only the sender (or types specified in [RSVP-AGG] and which contains 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 is specified as: SENDER_TEMPLATE object is specified as:
o IP4 SENDER_TEMPLATE object: 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 a Thus, it is possible to establish, from a given source IP address to
given destination IP address, separate such aggregate reservations a given destination IP address, separate such aggregate reservations
for different DSCPs. However, from a given source IP address to a for different DSCPs. However, from a given source IP address to a
Generic Aggregate RSVP Reservations February 2006
given IP destination address, only a single [RSVP-AGG] aggregate given IP destination address, only a single [RSVP-AGG] aggregate
reservation can be established for a given DSCP. reservation can be established for a given DSCP.
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 DSCP. One example is where E2E reservations using IP address and DSCP. One example is where E2E reservations using
different preemption priorities (as per [RSVP-PREEMP]) need to be different preemption priorities (as per [RSVP-PREEMP]) need to be
aggregated through a Diffserv cloud using the same DSCP. Using aggregated through a Diffserv cloud using the same DSCP. Using
multiple aggregate reservations for the same DSCP allows enforcement multiple aggregate reservations for the same DSCP allows enforcement
of the different preemption priorities within the aggregation region. of the different preemption priorities within the aggregation region.
skipping to change at page 5, line 4 skipping to change at page 5, line 4
[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 this
by using one of its own IP addresses as a globally unique identifier by using one of its own IP addresses as a globally unique identifier
and including it in the Extended Tunnel ID and therefore within the and including it in the Extended Tunnel ID and therefore within the
Session object. This document reuses this notion of Extended Tunnel Session object. This document reuses this notion of Extended Tunnel
ID from [RSVP-TE], simply renaming it Extended Virtual Destination ID from [RSVP-TE], simply renaming it Extended Virtual Destination
Port. This provides a convenient mechanism to narrow the scope of a
Generic Aggregate RSVP Reservations February 2006 generic aggregate session to an Aggregator-Deaggregator pair.
Port, in order to provide a convenient mechanism to narrow the scope
of an generic aggregate session to an Aggregator-Deaggregator pair.
The generic aggregate reservations may be used to aggregate end-to- 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 with 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.
1.1. Related RFCs and Internet-Drafts 1.1. Related RFCs and Internet-Drafts
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 specifies the necessary extensions beyond wherever applicable and only specifies the necessary extensions
[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 in lieu of tearing that reservation be reduced in allocated bandwidth by RSVP routers in lieu of tearing
down. These mechanisms are applicable to the generic aggregate that reservation down. These mechanisms are applicable to the generic
reservations defined in the present document. 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
classification. This is why [RSVP-AGG] required additional objects classification. This is why [RSVP-AGG] required additional objects
and procedures beyond those of [RSVP-TUNNEL]. Like [RSVP-AGG], this and procedures beyond those of [RSVP-TUNNEL]. Like [RSVP-AGG], this
document also assumes the use of Diffserv-based classification and document also assumes the use of Diffserv-based classification and
scheduling in the aggregation region and, thus, requires additional scheduling in the aggregation region and, thus, requires additional
objects and procedures beyond those of [RSVP-TUNNEL]. objects and procedures beyond those of [RSVP-TUNNEL].
As explained in section 1, 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. Section 3 describes the processing rules for handling reservations and to aggregation of E2E reservations onto those.
of generic aggregate reservations. Section 4 specifies the procedures Section 3 describes the processing rules for handling of generic
for aggregation of end to end RSVP reservations over generic aggregate reservations. Section 4 specifies the procedures for
aggregation of end to end RSVP reservations over generic aggregate
Generic Aggregate RSVP Reservations February 2006 RSVP reservations. Section 5 provides example usage of how the
generic aggregate reservations may be used.
aggregate RSVP reservations. Finally Section 5 provides example usage The Security Considerations and the IANA Considerations are
of how the generic aggregate reservations may be used. discussed in Section 6 and 7, respectively.
The IANA Considerations and the Security Considerations are discussed Finally, Appendix 1 provides an example signaling flow is
in Section 6 and 7, respectively. illustrating aggregation of E2E RSVP reservations onto generic
aggregate RSVP reservations.
1.3. Change History 1.3. Change History
1.3.1. 1.3.1.
Changes From draft-ietf-tsvwg-rsvp-ipsec-00 To draft-ietf-tsvwg-
rsvp-ipsec-01
The most significant changes are:
o added text on pre-established aggregate reservations
o added text on tear-down of aggregate reservations
o modified text describing content of the Extended vDstPort
field
o renamed AGGREGATION-SESSION class into SESSION-OF-INTEREST
class
o added text clarifying which of the new objects may appear in
which message types
o added text to avoid confusion between the Session of a given
reservation and the Session which may be included in the
SESSION-OF-INTEREST object.
o included informative appendix showing an RSVP signalling flow
mirroring the one in RFC3175
1.3.2.
Changes From draft-lefaucheur-rsvp-ipsec-02 To draft-ietf-tsvwg- Changes From draft-lefaucheur-rsvp-ipsec-02 To draft-ietf-tsvwg-
rsvp-ipsec-00 rsvp-ipsec-00
The most significant changes are: The most significant changes are:
o de-correlate the generic aggregate reservations from IPsec o de-correlate the generic aggregate reservations from IPsec
operations, in line with comments from the Security experts operations, in line with comments from the Security experts
review. This significantly affects (and simplifies review. This significantly affects (and simplifies
considerably) the document in many places. considerably) the document in many places.
o add the notion of Extended Virtual Destination port (reusing o add the notion of Extended Virtual Destination port (reusing
the notion of Extended Tunnel ID of [RSVP-TE]). the notion of Extended Tunnel ID of [RSVP-TE]).
o added recommendations on use of IP addresses by Aggregator and o added recommendations on use of IP addresses by Aggregator and
Deaggregator Deaggregator
1.3.2. 1.3.3.
Changes From draft-lefaucheur-rsvp-ipsec-01 To draft-lefaucheur- Changes From draft-lefaucheur-rsvp-ipsec-01 To draft-lefaucheur-
rsvp-ipsec-02 rsvp-ipsec-02
The most significant changes are: The most significant changes are:
o added text in section 4.2 about Aggregator/Deaggregator o added text in section 4.2 about Aggregator/Deaggregator
responsibilities with respect to mapping of end-to-end responsibilities with respect to mapping of end-to-end
reservations onto aggregate reservations. The text also reservations onto aggregate reservations. The text also
clarified that DCLASS object is no longer needed in PathErr clarified that DCLASS object is no longer needed in PathErr
message requesting new Aggregate Reservations message requesting new Aggregate Reservations
o Moved the text discussing details of the procedures to handle o Moved the text discussing details of the procedures to handle
dynamic update of SPI values from Security Considerations dynamic update of SPI values from Security Considerations
section into a new section 4.4. section into a new section 4.4.
o updates to Security Considerations section to start addressing o updates to Security Considerations section to start addressing
some comments from Security experts review. some comments from Security experts review.
1.3.3. 1.3.4.
Changes From draft-lefaucheur-rsvp-ipsec-00 To draft-lefaucheur- Changes From draft-lefaucheur-rsvp-ipsec-00 To draft-lefaucheur-
rsvp-ipsec-01 rsvp-ipsec-01
The most significant change is the broadening of the applicability of The most significant change is the broadening of the applicability of
the new type of aggregate reservations beyond use for Aggregate the new type of aggregate reservations beyond use for Aggregate
reservations for IPsec tunnels (to environments where IPsec is not reservations for IPsec tunnels (to environments where IPsec is not
Generic Aggregate RSVP Reservations February 2006
used). This affects the document in multiple places including the used). This affects the document in multiple places including the
following changes: following changes:
o document renamed to "Generic Aggregate RSVP Reservations" o document renamed to "Generic Aggregate RSVP Reservations"
o added a subsection in Introduction to discuss a case where o added a subsection in Introduction to discuss a case where
Generic Aggregate RSVP Reservations are needed in non IPsec Generic Aggregate RSVP Reservations are needed in non IPsec
environments environments
o added text about the fact that the Generic Aggregate o added text about the fact that the Generic Aggregate
skipping to change at page 7, line 27 skipping to change at page 8, line 4
Reservations can be used with IP-in-IP and GRE encapsulation Reservations can be used with IP-in-IP and GRE encapsulation
(in addition to with IPsec AH and ESP) (in addition to with IPsec AH and ESP)
o added example usage under Section 5 for environment where o added example usage under Section 5 for environment where
IPsec is not used IPsec is not used
The other significant changes are: The other significant changes are:
o added a subsection on the changes of the [RSVP-AGG] procedures o added a subsection on the changes of the [RSVP-AGG] procedures
under Section 4 under Section 4
o added explanation about allocation of VDstPort values by o added explanation about allocation of VDstPort values by
Deaggregator, in that same subsection Deaggregator, in that same subsection
o added value of Protocol ID in all example generic aggregate o added value of Protocol ID in all example generic aggregate
reservations in Section 5 reservations in Section 5
2. Object Definition 2. Object Definition
This document defines two new objects under the SESSION Class and a This document reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP-
new object under a new AGGREGATION SESSION Class. AGGREGATE-IP6 FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE and
RSVP-AGGREGATE-IP6 SENDER_TEMPLATE objects defined in [RSVP-AGG].
It reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP-AGGREGATE-IP6 This document defines:
FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE and RSVP-AGGREGATE- - two new objects (GENERIC-AGGREGATE-IP4 SESSION and GENERIC-
IP6 SENDER_TEMPLATE objects defined in [RSVP-AGG]. AGGREGATE-IP6 SESSION) under the existing SESSION Class, and
- two new objects (GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI)
under a new SESSION-OF-INTEREST Class.
Detailed description of these objects is provided below in this
section.
The GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION
objects are applicable to all types of RSVP messages.
This specification only defines the use of the GENERIC-AGG-IP4-SOI
and GENERIC-AGG-IP6-SOI objects in two circumstances:
- inside an E2E PathErr message which contains an error code of
NEW-AGGREGATE-NEEDED in order to convey the session of a new
generic aggregate reservation which needs to be established
- inside an E2E Resv message in order to convey the session of
the generic aggregate reservation onto which this E2E
reservation needs to be mapped.
Details of the corresponding procedures can be found in section 4.
However, it is envisioned that the ability to signal, inside RSVP
messages, the Session of another reservation (which has some
relationship with the current RSVP reservation) might have some other
applicability in the future. Thus, those objects have been specified
in a more generic manner under a flexible SESSION-OF-INTEREST class.
All the new objects defined in this document are optional with
respect to RSVP so that general RSVP implementations not concerned
with generic aggregate reservations do not have to support these
objects. RSVP routers supporting generic aggregate IPv4 (respectively
IPv6) reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION
object (respectively GENERIC-AGGREGATE-IP6 SESSION). RSVP routers
supporting RSVP aggregation over generic aggregate IPv4 (respectively
IPv6) reservations MUST support the GENERIC-AGG-IP4-SOI object
(respectively GENERIC-AGG-IP6-SOI).
2.1. SESSION Class 2.1. SESSION Class
o GENERIC-AGGREGATE-IPv4 SESSION object: o GENERIC-AGGREGATE-IP4 SESSION object:
Class = 1 Class = 1 (SESSION)
C-Type = To be allocated by IANA 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 | vDstPort |Rd| DSCP | | Reserved | Flags | vDstPort |Rd| DSCP |
Generic Aggregate RSVP Reservations February 2006
+-------------+-------------+-------------+--+----------+ +-------------+-------------+-------------+--+----------+
| 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
skipping to change at page 8, line 39 skipping to change at page 10, line 8
MUST be ignored on receipt. MUST be ignored on receipt.
DSCP (Diffserv Code Point) DSCP (Diffserv Code Point)
A 6-bit field containing the DSCP of the PHB from which Diffserv A 6-bit field containing the DSCP of the PHB from which Diffserv
resources are to be reserved. resources are to be reserved.
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 the life of the generic aggregate reservation. Normally set over the life of the generic aggregate reservation.
to all zeros. A sender (or Aggregator) that wishes to narrow the A sender (or Aggregator) that wishes to narrow the scope of a
scope of a SESSION to the sender-receiver pair (or Aggregator- SESSION to the sender-receiver pair (or Aggregator-Deaggregator
Deaggregator pair) may place its IPv4 address here as a globally pair) SHOULD place its IPv4 address here as a globally unique
unique identifier. identifier. A sender (or Aggregator) that wishes to use a common
session with other senders (or Aggregators) in order to use a
shared reservation across senders (or Aggregators) MUST set this
field to all zeros.
o GENERIC-AGGREGATE-IPv6 SESSION object: o GENERIC-AGGREGATE-IP6 SESSION object:
Class = 1 Class = 1 (SESSION)
C-Type = To be allocated by IANA C-Type = To be allocated by IANA
0 7 8 15 16 23 24 31 0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Generic Aggregate RSVP Reservations February 2006
| | | |
+ + + +
| | | |
+ IPv6 DestAddress (16 bytes) + + IPv6 DestAddress (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+--+----------+ +-------------+-------------+-------------+--+----------+
| Reserved | Flags | vDstPort |Rd| DSCP | | Reserved | Flags | vDstPort |Rd| DSCP |
+-------------+-------------+-------------+--+----------+ +-------------+-------------+-------------+--+----------+
skipping to change at page 10, line 5 skipping to change at page 11, line 20
Rd (Reserved) Rd (Reserved)
A 2-bit field. All bits MUST be set to 0 on transmit. This field A 2-bit field. All bits MUST be set to 0 on transmit. This field
MUST be ignored on receipt. MUST be ignored on receipt.
DSCP (Diffserv Code Point) DSCP (Diffserv Code Point)
A 6-bit field containing the DSCP of the PHB from which Diffserv A 6-bit field containing the DSCP of the PHB from which Diffserv
resources are to be reserved resources are to be reserved
Generic Aggregate RSVP Reservations February 2006
Extended vDstPort (Extended Virtual Destination Port) Extended vDstPort (Extended Virtual Destination Port)
A 16-byte 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. Normally set over the life of the generic aggregate reservation.
to all zeros. A sender (or Aggregator) that wishes to narrow the A sender (or Aggregator) that wishes to narrow the scope of a
scope of a SESSION to the sender-receiver pair (or Aggregator- SESSION to the sender-receiver pair (or Aggregator-Deaggregator
Deaggregator pair) may place its IPv6 address here as a globally pair) SHOULD place its IPv6 address here as a globally unique
unique identifier. identifier. A sender (or Aggregator) that wishes to use a common
session with other senders (or Aggregators) in order to use a
shared reservation across senders (or Aggregators) MUST set this
field to all zeros.
2.2. AGGREGATION-SESSION Class 2.2. SESSION-OF-INTEREST (SOI) Class
o IPv4-AGGREGATION-SESSION object: o GENERIC-AGG-IP4-SOI object:
Class = To be allocated by IANA Class = To be allocated by IANA
C-Type = To be allocated by IANA C-Type = To be allocated by IANA
0 7 8 15 16 23 24 31 0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// SESSION Object // // Content of a GENERIC-AGGREGATE-IP4 SESSION Object //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o IPv6-AGGREGATION-SESSION object: Content of a GENERIC-AGGREGATE-IP4 SESSION Object:
Class = To be allocated by IANA (same as for
IPv4-AGGREGATION-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
GENERIC-AGG-IP4-SOI, the session of interest conveyed in this
field is a GENERIC-AGGREGATE-IP4 SESSION.
o GENERIC-AGG-IP6-SOI object:
Class = To be allocated by IANA
(same as for GENERIC-AGG-IP4-SOI)
C-Type = To be allocated by IANA C-Type = To be allocated by IANA
0 7 8 15 16 23 24 31 0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | | SOI |GEN-AGG-IP6- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// SESSION Object // // Content of a GENERIC-AGGREGATE-IP6 SESSION Object //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
For example, if the AGGREGATION-SESSION object is used to indicate Content of a GENERIC-AGGREGATE-IP6 SESSION Object:
that the Aggregate Session needed is a GENERIC-AGGREGATE-IPv4 SESSION
then the AGGREGATION-SESSION will be encoded like this:
0 7 8 15 16 23 24 31 This field contains a copy of the Session object of the session
+-------------+-------------+-------------+-------------+ which is of interest for the reservation. In the case of a
| |IPv4-AGGR-SES|IPv4-AGGR-SES| GENERIC-AGG-IP6-SOI, the session of interest conveyed in this
field is a GENERIC-AGGREGATE-IP6 SESSION.
Generic Aggregate RSVP Reservations February 2006 For example, if a SESSION-OF-INTEREST object is used inside an E2E
Resv message (as per the procedures defined in section 4) to indicate
which generic aggregate IPv4 session the E2E reservation is to be
mapped onto, then the GENERIC-AGG-IP4-SOI object will be used and it
will be encoded like this:
| Length (bytes) | Class-Num | C-Type | 0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) | | IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+--+----------+ +-------------+-------------+-------------+--+----------+
| Reserved | Flags | vDstPort | DSCP | | Reserved | Flags | vDstPort |Rd| DSCP |
+-------------+-------------+-------------+--+----------+ +-------------+-------------+-------------+--+----------+
| Extended vDstPort | | Extended vDstPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
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
itself. It does not replace the SESSION object in RSVP messages. It
does not modify the usage of the SESSION object in RSVP messages. It
simply allows conveying the Session of another RSVP reservation
inside RSVP signaling messages, for some particular purposes. In the
context of this document, it is used to convey, inside an E2E RSVP
message pertaining to an end-to-end reservation, the Session of a
generic aggregate reservation associated with the E2E reservation.
Details for the corresponding procedures are specified in section 4.
3. Processing Rules For Handling Generic Aggregate RSVP Reservations 3. Processing Rules For Handling Generic Aggregate RSVP Reservations
This section presents additions to the Processing Rules presented in This section presents additions to the Processing Rules presented in
[RSVP-PROCESS]. These additions are required in order to properly [RSVP-PROCESS]. These additions are required in order to properly
process the GENERIC-AGGREGATE-IPv4 (resp. GENERIC-AGGREGATE-IPv6) process the GENERIC-AGGREGATE-IP4 (resp. GENERIC-AGGREGATE-IP6)
SESSION object and the RSVP-AGGREGATE-IP4 (resp. RSVP-AGGREGATE-IP6) SESSION object and the RSVP-AGGREGATE-IP4 (resp. RSVP-AGGREGATE-IP6)
FILTER_SPEC object. Values for referenced error codes can be found in FILTER_SPEC object. Values for referenced error codes can be found in
[RSVP]. As with the other RSVP documents, values for internally [RSVP]. As with the other RSVP documents, values for internally
reported (API) errors are not defined. reported (API) errors are not defined.
When referring to the new GENERIC-AGGREGATE-IPv4 and GENERIC- When referring to the new GENERIC-AGGREGATE-IP4 and GENERIC-
AGGREGATE-IPv6 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-AGGREGATE-IP6 SESSION, FILTER_SPEC and SENDER_TEMPLATE objects, RSVP-AGGREGATE-IP6 SESSION, FILTER_SPEC and SENDER_TEMPLATE objects,
IP version will not be included and they will be referred to simply IP version will not be included and they will be referred to simply
as RSVP-AGGREGATE, unless a specific distinction between IPv4 and as RSVP-AGGREGATE, unless a specific distinction between IPv4 and
IPv6 is being made. IPv6 is being made.
3.1. Required Changes to Path and Resv Processing 3.1. Required Changes to Path and Resv Processing
skipping to change at page 12, line 5 skipping to change at page 14, line 5
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 RSVP router, the RSVP router MUST consider this as a an RSVP router, the RSVP router MUST consider this as a
message formatting error. message formatting error.
Generic Aggregate RSVP Reservations February 2006
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 DSCP value should be recorded (in addition to the the DSCP value should be recorded (in addition to the
destination/Deaggregator address and source/aggregator destination/Deaggregator address and source/aggregator
address). These values form part of the recorded state of the address). These values form part of the recorded state of the
session. The DSCP may need to be passed to traffic control; session. The DSCP may need to be passed to traffic control;
however the vDstPort and Extended VDstPort are not passed to however the vDstPort and Extended VDstPort are not passed to
traffic control since they do not appear inside the data traffic control since they do not appear inside the data
packets of the corresponding reservation. packets of the corresponding reservation.
skipping to change at page 12, line 52 skipping to change at page 14, line 50
the sum of the reserved rate across all the corresponding the sum of the reserved rate across all the corresponding
reservations. reservations.
* If the node only needs to perform Diffserv classification * If the node only needs to perform Diffserv classification
(for example inside the aggregation domain downstream of the (for example inside the aggregation domain downstream of the
trust boundary) then the node MUST rely on the Diffserv data trust boundary) then the node MUST rely on the Diffserv data
classifier based on the DSCP only. classifier based on the DSCP only.
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
Generic Aggregate RSVP Reservations February 2006
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. The
Deaggregator requests establishment of a new aggregate reservation by Deaggregator requests establishment of a new aggregate reservation by
sending to the Aggregator an E2E PathErr message with an error code sending to the Aggregator an E2E PathErr message with an error code
of NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the Deaggregator conveys the of NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the Deaggregator conveys the
DSCP of the new requested aggregate reservation by including a DCLASS DSCP of the new requested aggregate reservation by including a DCLASS
Object in the E2E PathErr and encoding the corresponding DSCP inside. Object in the E2E PathErr and encoding the corresponding DSCP inside.
This document modifies and extends this procedure. The Deaggregator This document modifies and extends this procedure. The Deaggregator
MUST include in the E2E PathErr message an AGGREGATION-SESSION object MUST include in the E2E PathErr message, a SESSION-OF-INTEREST object
which contains the Session to be used for establishment of the which contains the GENERIC-AGGREGATE Session to be used for
requested generic aggregate reservation. Since the AGGREGATION- establishment of the requested generic aggregate reservation. Since
SESSION object contains the DSCP, the DCLASS object need not be this GENERIC-AGGREGATE SESSION contains the DSCP, the DCLASS object
included in the PathErr message. 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 the Extended VDstPort) and can communicate those inside the GENERIC-
AGGREGATION-SESSION object. This provides an easy solution to AGGREGATE SESSION included in the SESSION-OF-INTEREST object. This
establish separate reservations from every Aggregator to a given provides an easy solution to establish separate reservations from
Deaggregator. Conversely, if reservation sharing were needed across every Aggregator to a given Deaggregator. Conversely, if reservation
multiple Aggregators, the Deaggregator could facilitate this by sharing were needed across multiple Aggregators, the Deaggregator
allocating the same VDstPort and Extended VDstPort to the multiple could facilitate this by allocating the same VDstPort and Extended
Aggregators and thus including the same AGGREGATION-SESSION object in VDstPort to the multiple Aggregators and thus including the same
GENERIC-AGGREGATE SESSION inside the SESSION-OF-INTEREST object in
the E2E PathErr messages sent to these Aggregators. The Aggregators the E2E PathErr messages sent to these Aggregators. The Aggregators
could then all establish an Aggregate Path with the same Session. could then all establish an Aggregate Path with the same GENERIC-
AGGREGATE SESSION.
Therefore various sharing scenarios can easily be supported. Policies Therefore various sharing scenarios can easily be supported. Policies
followed by the Deaggregator to determine which aggregators need followed by the Deaggregator to determine which aggregators need
shared or separate reservations are beyond the scope of this document. 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 new 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
with an error code of NEW-AGGREGATE-NEEDED by the Aggregator are received with an error code of NEW-AGGREGATE-NEEDED by the Aggregator
extended correspondingly. On receipt of such a message containing an are extended correspondingly. On receipt of such a message containing
AGGREGATION-SESSION object, the Aggregator MUST use the Session a SESSION-OF-INTEREST object, the Aggregator MUST trigger
provided in the AGGREGATION-SESSION object to trigger establishment establishment of a generic aggregate reservation. In particular, it
of a generic aggregate reservation. The Aggregator MUST use the MUST start sending aggregate Path messages with the GENERIC-AGGREGATE
SESSION found in the received SESSION-OF-INTEREST object. When an
Generic Aggregate RSVP Reservations February 2006 RSVP Signaled Preemption Priority Policy Element is contained in the
received E2E PathErr message, the Aggregator MUST include this object
DestAddress found in the AGGREGATION-SESSION object as the in the Aggregate Path for the corresponding generic aggregate
destination of the Aggregate Path. When an RSVP Signaled Preemption reservation. When other additional objects are contained in the
Priority Policy Element is contained in the received E2E PathErr received E2E PathErr message and those can be unambiguously
message, the Aggregator MUST include this object in the Aggregate interpreted as related to the new needed generic aggregate
Path for the corresponding generic aggregate reservation. When other reservation (as opposed to related to the E2E reservation), the
additional objects are contained in the received E2E PathErr message Aggregator SHOULD include those in the Aggregate Path for the
and those can be unambiguously interpreted as related to the new corresponding generic aggregate reservation. The Aggregator MUST use
needed generic aggregate reservation (as opposed to related to the as the Source Address (i.e. as the Aggregator Address in the Sender-
E2E reservation), the Aggregator SHOULD include those in the Template) for the generic aggregate reservation, the address it uses
Aggregate Path for the corresponding generic aggregate reservation.
The Aggregator MUST use as the Source Address (i.e. as the Aggregator
Address) for the generic aggregate reservation, the address it uses
to identify itself as the PHOP when forwarding the E2E Path messages to identify itself as the PHOP when forwarding the E2E Path messages
corresponding to the E2E PathErr message. 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 [RSVP-
AGG] for establishing, maintaining and clearing the aggregate Resv AGG] for establishing, maintaining and clearing the aggregate Resv
state. However, in this document, the Deaggregator MUST use the state. However, in this document, the Deaggregator MUST use the
generic aggregate reservations and hence use the GENERIC-AGGREGATE generic aggregate reservations and hence use the GENERIC-AGGREGATE
SESSION specified earlier in this document. 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 AGGREGATION-SESSION object in The Deaggregator MUST include the new SESSION-OF-INTEREST object in
the E2E Resv message, in order to convey to the Aggregator which the E2E Resv message, in order to indicate to the Aggregator the
aggregate session to map a given E2E reservation onto. Again, since generic aggregate session to map a given E2E reservation onto. Again,
the AGGREGATION-SESSION object contains the DSCP, the DCLASS object since the GENERIC-AGGREGATE SESSION (included in the SESSION-OF-
need not be included in the E2E Resv message. The Aggregator MUST INTEREST object) contains the DSCP, the DCLASS object need not be
interpret the AGGREGATION-SESSION object in the E2E Resv as included in the E2E Resv message. The Aggregator MUST interpret the
indicating which generic aggregate reservation session the SESSION-OF-INTEREST object in the E2E Resv as indicating which
corresponding E2E reservation is mapped onto. generic aggregate reservation session the corresponding E2E
reservation is mapped onto. The Aggregator MUST not include the
SESSION-OF-INTEREST object when sending an E2E Resv upstream towards
the sender.
Based on relevant policy, the Deaggregator may decide at some point
that an aggregate reservation is no longer needed and should be torn
down. In that case, the Deaggregator MUST send an aggregate ResvTear.
On receipt of the aggregate ResvTear, the Aggregator SHOULD send an
aggregate PathTear (unless the relevant policy instructs the
aggregator to do otherwise or to wait for some time before doing so,
for example in order to speed-up potential re-establishment of the
aggregate reservation in the future).
[RSVP-AGG] describes how the Aggregator and Deaggregator can [RSVP-AGG] describes how the Aggregator and Deaggregator can
communicate their respective identity to each other. For example the communicate their respective identity to each other. For example the
Aggregator includes one of its IP addresses in the RSVP HOP object in Aggregator includes one of its IP addresses in the RSVP HOP object in
the E2E Path which is transmitted downstream and received by the the E2E Path which is transmitted downstream and received by the
Deaggregator once it traversed the aggregation region. Similarly, the Deaggregator once it traversed the aggregation region. Similarly, the
Deaggregator identifies itself to the Aggregator by including one of Deaggregator identifies itself to the Aggregator by including one of
its IP addresses in various fields, including the ERROR SPECIFICATION its IP addresses in various fields, including the ERROR SPECIFICATION
of the E2E PathErr message (containing the NEW-AGGREGATE-NEEDED Error of the E2E PathErr message (containing the NEW-AGGREGATE-NEEDED Error
Code), in the AGGREGATION-SESSION object included in the same E2E Code) and in the RSVP HOP object of the E2E Resv message. However,
PathErr message and in the RSVP HOP object of the E2E Resv message. [RSVP-AGG] does not discuss which IP addresses are to be selected by
However, [RSVP-AGG] does not discuss which IP addresses are to be the aggregator and Deaggregator for such purposes. Because these
selected by the aggregator and Deaggregator for such purposes. addresses are intended to identify the Aggregator and Deaggregator
Because these addresses are intended to identify the Aggregator and and not to identify any specific interface on these devices, this
Deaggregator and not to identify any specific interface on these document RECOMMENDS that the Aggregator and Deaggregator SHOULD use
devices, this document RECOMMENDS that the Aggregator and interface-independent addresses (for example a loopback address)
Deaggregator SHOULD use interface-independent addresses (for example whenever they communicate their respective identity to each other.
a loopback address) whenever they communicate their respective This ensures that respective identification of the Aggregator and
Deaggregator is not impacted by any interface state change on these
Generic Aggregate RSVP Reservations February 2006 devices. In turns this results in more stable operations and
identity to each other. This ensures that respective identification
of the Aggregator and Deaggregator by any interface state change on
these devices. In turns this results in more stable operations and
considerably reduced RSVP signaling in the aggregation region. For considerably reduced RSVP signaling in the aggregation region. For
example, if interface-independent addresses are used by the example, if interface-independent addresses are used by the
Aggregator and the Deaggregator, then a failure of an interface on Aggregator and the Deaggregator, then a failure of an interface on
these devices may simply result in the rerouting of a given generic these devices may simply result in the rerouting of a given generic
aggregate reservation but will not result in the generic aggregate aggregate reservation but will not result in the generic aggregate
reservation having to be torn down and another one established, nor reservation having to be torn down and another one established, nor
will it result in a change of mapping of E2E reservations on generic will it 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).
skipping to change at page 15, line 32 skipping to change at page 17, line 42
neighbors which are not on the other side of the aggregation region), neighbors which 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
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 for an E2E reservation. This also applies when the
Deaggregator identifies itself downstream as a PHOP for the E2E Deaggregator identifies itself downstream as a PHOP for the E2E
reservation or identifies itself upstream as a NHOP for the generic reservation or identifies itself upstream as a NHOP for the generic
aggregate reservation. As part of the processing of generic aggregate aggregate reservation. As part of the processing of generic aggregate
reservations, interior routers (i.e. routers within the aggregation reservations, interior routers (i.e. routers within the aggregation
region) SHOULD continue using interface-dependent address as per region) SHOULD continue using interface-dependent addresses as per
regular [RSVP] procedures. regular [RSVP] procedures.
More generally, within the aggregation region (ie between Aggregator More generally, within the aggregation region (ie between Aggregator
and Deaggregator) the operation of RSVP should be modeled with the and Deaggregator) the operation of RSVP should be modeled with the
notion that E2E reservations are mapped to aggregate reservations and notion that E2E reservations are mapped to aggregate reservations and
are no longer tied to physical interfaces (as was the case with are no longer tied to physical interfaces (as was the case with
regular RSVP). However, generic aggregate reservations (within the regular RSVP). However, generic aggregate reservations (within the
aggregation region) as well as E2E reservations outside the aggregation region) as well as E2E reservations outside the
aggregation region, retain the model of regular RVSP and remain tied aggregation region, retain the model of regular RVSP and remain tied
to physical interfaces. to physical interfaces.
As discussed above, generic aggregate reservations may be established
edge-to-edge as a result of the establishment of E2E reservations
(from outside the aggregation region) which are to be aggregated over
the aggregation region. However, generic aggregate reservations may
also be used end-to-end by end-systems directly attached to a
Diffserv domain, such as PSTN Gateways. In that case, the generic
aggregate reservations may be established by the end-systems in
response to application-level triggers such as voice call signaling.
Alternatively, generic aggregate reservations may also be used edge-
to-edge to manage bandwidth in a Diffserv cloud even if RSVP is not
used end-to-end. A simple example of such a usage would be the static
configuration of a generic aggregate reservation for a certain
bandwidth for traffic from an ingress (Aggregator) router to an
egress (Deaggregator) router.
In this case, the establishment of the generic aggregate reservations
is controlled by configuration on the Aggregator and on the
Deaggregator. Configuration on the Aggregator triggers generation of
the aggregate Path message and provides sufficient information to the
Aggregator to derive the content of the GENERIC-AGGREGATE SESSION
object. This would typically include Deaggregator IP address, DSCP
and possibly VDstPort. Configuration on the Deaggregator would
instruct the Deaggregator to respond to a received generic aggregate
Path message and would provide sufficient information to the
Deaggregator to control the reservation. This may include bandwidth
to be reserved by the Deaggregator (for a given
Deaggregator/DSCP/VDstPort tuple).
In the absence of E2E microflow reservations, the Aggregator can use
a variety of policies to set the DSCP of packets passing into the
aggregation region and how they are mapped onto generic aggregate
reservations, thus determining whether they gain access to the
resources reserved by the aggregate reservation. These policies are a
matter of local configuration, as usual for a device at the edge of a
Diffserv cloud.
5. Example Usage Of Multiple Generic Aggregate Reservations Per DSCP 5. Example Usage Of Multiple Generic Aggregate Reservations Per DSCP
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
Generic Aggregate RSVP Reservations February 2006
| | | |
Agg-Deag-1------------ Agg-Deag-2 Agg-Deag-1------------ Agg-Deag-2
/ \ / \
/ Aggregation | / Aggregation |
| Region | | Region |
| | | |
| ---/ | ---/
\ / \ /
\Agg-Deag-3---------/ \Agg-Deag-3---------/
| |
skipping to change at page 16, line 46 skipping to change at page 19, line 43
IP reservations from Aggregator to Deaggregator using GRE IP reservations from Aggregator to Deaggregator using GRE
tunneling ([GRE]). tunneling ([GRE]).
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 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-IPv4 SESSION= * GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress= Agg-Deag-3 IPv4 DestAddress= Agg-Deag-3
vDstPort=V1 vDstPort=V1
DSCP=EF DSCP=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:
Generic Aggregate RSVP Reservations February 2006
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 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-IPv4 SESSION=Agg-Deag-3/V2/EF * GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress= Agg-Deag-3 IPv4 DestAddress= Agg-Deag-3
vDstPort=V2 vDstPort=V2
DSCP=EF DSCP=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 Agg-Deag-3. where V1 and V2 are arbitrary VDstPort values picked by Agg-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 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-IPv4 SESSION * GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress= Agg-Deag-3 IPv4 DestAddress= Agg-Deag-3
vDstPort=V3 vDstPort=V3
DSCP=EF DSCP=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 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-IPv4 SESSION * GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress= Agg-Deag-3 IPv4 DestAddress= Agg-Deag-3
vDstPort=V4 vDstPort=V4
DSCP=EF DSCP=EF
Generic Aggregate RSVP Reservations February 2006
Extended VDstPort= Agg-Deag-2 Extended VDstPort= Agg-Deag-2
* STYLE=FF or SE * STYLE=FF or SE
* IPv4/GPI FILTER_SPEC=Agg-Deag-2 * 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 V1 and V4 are arbitrary VDstPort values picked by Agg-Deag-3. where V1 and V4 are arbitrary VDstPort values picked by Agg-Deag-3.
Note that V3 and V4 could be equal to V1 and V2 since, in this
example, the Extended VDstPort of the GENERIC-AGGREGATE Session Note that V3 and V4 could be equal to (respectively) V1 and V2 since,
contains the address of the Deaggregator and, thus, ensures that in this example, the Extended VDstPort of the GENERIC-AGGREGATE
different sessions are used for each Deaggregator. Session contains the address of the Deaggregator and, thus, ensures
that different sessions are used for each Deaggregator.
6. Security Considerations 6. Security Considerations
The security considerations associated with the RSVP protocol [RSVP] The security considerations associated with the RSVP protocol [RSVP]
apply to this document as it relies on RSVP. apply to this document as it relies on RSVP.
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. apply.
The security considerations discussed in [SIG-NESTED] apply when the The security considerations discussed in [SIG-NESTED] apply when the
generic aggregate reservations are used in the presence of IPsec generic aggregate reservations are used in the presence of IPsec
gateways. gateways.
7. IANA Considerations 7. IANA Considerations
This document requests that IANA allocates two new C-Types under the This document requests that IANA allocates two new C-Types under the
Class 1 for the two new RSVP objects (GENERIC-AGGREGATE-IPv4 SESSION existing SESSION Class (Class 1)for the two new RSVP objects defined
and GENERIC-AGGREGATE-IPv6 SESSION) defined in section 2.1. in section 2.1: GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-
IP6 SESSION.
This document also requests that IANA allocates one new Class-Num and This document also requests that IANA allocates one new Class-Num for
two new C-Types for the two new RSVP objects (IPv4-AGGREGATION- the SESSION-OF-INTEREST class, and two new C-Types for the two new
SESSION and IPv6-AGGREGATION-SESSION) defined in section 2.2. RSVP objects under that class defined in section 2.2: GENERIC-AGG-
IP4-SOI and GENERIC-AGG-IP4-SOI.
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 respectively from [RSVP-IPSEC] and [RSVP-TE].
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
Generic Aggregate RSVP Reservations February 2006 into the content of this document. Thanks to Steve Kent for
insightful comments on usage of RSVP reservations in IPsec
Voce and Anil Agarwal for their input into the content of this environments.
document. Thanks to Steve Kent for insightful comments on usage of
RSVP reservations in IPsec environments.
9. Normative References 9. Normative References
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
Bradner, RFC2119
[RSVP] "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional [RSVP] "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", Braden et al, RFC2205 Specification", Braden et al, RFC2205
[RSVP-IPSEC] "RSVP Extensions for IPsec Data Flows", Berger et al, [RSVP-IPSEC] "RSVP Extensions for IPsec Data Flows", Berger et al,
RFC2207 RFC2207
[RSVP-AGG] "Aggregation of RSVP for IPv4 and IPv6 Reservations", [RSVP-AGG] "Aggregation of RSVP for IPv4 and IPv6 Reservations",
Baker et al, RFC3175 Baker et al, RFC3175
[SIG-NESTED] "QoS Signaling in a Nested Virtual Private Network",
Baker et al, draft-ietf-tsvwg-vpn-signaled-preemption-00.txt, work in
progress
[RSVP-PROCESS] "Resource ReSerVation Protocol (RSVP) -- Version 1 [RSVP-PROCESS] "Resource ReSerVation Protocol (RSVP) -- Version 1
Message Processing Rules", Braden et al, RFC2209 Message Processing Rules", Braden et al, RFC2209
[IPSEC-ARCH] "Security Architecture for the Internet Protocol", Kent [GRE] "Generic Routing Encapsulation (GRE) ", Farinacci et al, RFC
et al, RFC2401 2784
[DS-TUNNEL] "Differentiated Services and Tunnels", Black, RFC2983
[GRE] Generic Routing Encapsulation (GRE). Farinacci et al, RFC 2784
10. Informative References 10. Informative References
[SIG-NESTED] "QoS Signaling in a Nested Virtual Private Network",
Baker et al, draft-ietf-tsvwg-vpn-signaled-preemption, work in
progress
[BW-REDUC] "A Resource Reservation Extension for the Reduction of [BW-REDUC] "A Resource Reservation Extension for the Reduction of
andwidth of a Reservation Flow", Polk et al, draft-polk-tsvwg-rsvp- andwidth of a Reservation Flow", Polk et al, RFC 4495
bw-reduction-01.txt, work in progress
[RSVP-TUNNEL] "RSVP Operation Over IP Tunnels", Terzis et al., RFC [RSVP-TUNNEL] "RSVP Operation Over IP Tunnels", Terzis et al., RFC
2746, January 2000. 2746, January 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-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels,
RFC 3209, December 2001. RFC 3209, December 2001.
11. Authors Address: 11. Authors' Addresses
Generic Aggregate RSVP Reservations February 2006
Francois Le Faucheur Francois Le Faucheur
Cisco Systems, Inc. Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3 Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille 400, Avenue de Roumanille
06410 Biot Sophia-Antipolis 06410 Biot Sophia-Antipolis
France France
Email: flefauch@cisco.com Email: flefauch@cisco.com
Bruce Davie Bruce Davie
skipping to change at page 21, line 4 skipping to change at page 24, line 6
Email: davenport_michael@bah.com Email: davenport_michael@bah.com
12. IPR Statements 12. IPR Statements
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
Generic Aggregate RSVP Reservations February 2006
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
skipping to change at page 21, line 35 skipping to change at page 24, line 34
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Copyright Notice 14. Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
APPENDIX 1: Example Signaling Flow
This Appendix does not provide additional specification. It only
illustrates the specification detailed in section 4 through a
possible flow of RSVP signaling messages. This flow assumes an
environment where E2E reservations are aggregated over generic
aggregate RSVP reservations. It illustrates a possible RSVP message
flow that could take place in the successful establishment of a
unicast E2E reservation which is the first between a given pair of
Aggregator/Deaggregator.
Aggregator Deaggregator
E2E Path
----------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(New-agg-needed,SOI=GAx)
<----------------------------------
E2E PathErr(New-agg-needed,SOI=GAy)
<----------------------------------
(3)
AggPath(Session=GAx)
------------------------------->
AggPath(Session=GAy)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (Session=GAx)
<-------------------------------
AggResv (Session=GAy)
<-------------------------------
(6)
AggResvConfirm (Session=GAx)
------------------------------>
AggResvConfirm (Session=GAy)
------------------------------>
(7)
E2E Resv
<---------
(8)
E2E Resv (SOI=GAx)
<-----------------------------
(9)
E2E Resv
<-----------
(1) The Aggregator forwards E2E Path into the aggregation region
after modifying its IP Protocol Number to RSVP-E2E-IGNORE
(2) Let's assume no Aggregate Path exists. To be able to accurately
update the ADSPEC of the E2E Path, the Deaggregator needs the ADSPEC
of Aggregate PATH. In this example the Deaggregator elects to
instruct the Aggregator to set up Aggregate Path states for the two
supported DSCPs. To do that, the Deaggregator sends two E2E PathErr
messages with a New-Agg-Needed PathErr code. Both PathErr messages
also contain a SESSION-OF-INTEREST (SOI) object. In the first E2E
PathErr, the SOI contains a GENERIC-AGGREGATE SESSION (GAx) whose
DSCP is set to x. In the second E2E PathErr, the SOI contains a
GENERIC-AGGREGATE SESSION (GAy) whose DSCP is set to y. In both
messages the GENERIC-AGGREGATE SESSION contains an interface-
independent Deaggregator address inside the DestAddress and
appropriate values inside the vDstPort and Extended vDstPort fields.
(3) The Aggregator follows the request from the Deaggregator and
signals an Aggregate Path for both GENERIC-AGGREGATE Sessions (GAx
and GAy).
(4) The Deaggregator takes into account the information contained in
the ADSPEC from both Aggregate Path and updates the E2E Path ADSPEC
accordingly. The Deaggregator also modifies the E2E Path IP Protocol
Number to RSVP before forwarding it.
(5) In this example, the Deaggregator elects to immediately proceed
with establishment of generic aggregate reservations for both DSCPs.
In effect, the Deaggregator can be seen as anticipating the actual
demand of E2E reservations so that resources are available on
the generic aggregate reservations when the E2E Resv requests arrive,
in order to speed up establishment of E2E reservations. Assume
also that the Deaggregator includes the optional Resv Confirm
Request in these Aggregate Resv.
(6) The Aggregator merely complies with the received ResvConfirm
Request and returns the corresponding Aggregate ResvConfirm.
(7) The Deaggregator has explicit confirmation that both Aggregate
Resv are established.
(8) On receipt of the E2E Resv, the Deaggregator applies the mapping
policy defined by the network administrator to map the E2E Resv
onto a generic aggregate reservation. Let's assume that this policy
is such that the E2E reservation is to be mapped onto the generic
aggregate reservation with DSCP=x. The Deaggregator knows that a
generic aggregate reservation (GAx) is in place for the corresponding
DSCP since (7). The Deaggregator performs admission control of the
E2E Resv onto the generic aggregate Reservation for DSCP=x (GAx).
Assuming that the generic aggregate reservation for DSCP=x (GAx) had
been established with sufficient bandwidth to support the E2E Resv,
the Deaggregator adjusts its counter, tracking the unused bandwidth
on the generic aggregate reservation and forwards the E2E Resv to the
Aggregator including a SESSION-OF-INTEREST object conveying the
selected mapping onto GAx (and hence onto DSCP=x).
(9) The Aggregator records the mapping of the E2E Resv onto GAx (and
onto DSCP=x). The Aggregator removes the SOI object and forwards the
E2E Resv towards the sender.
 End of changes. 81 change blocks. 
211 lines changed or deleted 300 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/