draft-ietf-tsvwg-rsvp-ipsec-02.txt   draft-ietf-tsvwg-rsvp-ipsec-03.txt 
Generic Aggregate RSVP Reservations September 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-02.txt draft-ietf-tsvwg-rsvp-ipsec-03.txt
Expires: March 2007 September 2006
Generic Aggregate RSVP Reservations Generic Aggregate RSVP Reservations
draft-ietf-tsvwg-rsvp-ipsec-02.txt draft-ietf-tsvwg-rsvp-ipsec-03.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
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
RSVP reservations can be aggregated onto such aggregate reservations RSVP reservations can be aggregated onto such aggregate reservations
Generic Aggregate RSVP Reservations September 2006
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
be used to aggregate end-to-end RSVP reservations. This document also be used to aggregate end-to-end RSVP reservations. This document also
skipping to change at page 2, line 30 skipping to change at page 2, line 33
Table Of Content Table Of Content
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Related RFCs and Internet-Drafts..........................5 1.1. Related RFCs and Internet-Drafts..........................5
1.2. Organization Of This Document.............................6 1.2. Organization Of This Document.............................6
2. Object Definition..............................................6 2. Object Definition..............................................6
2.1. SESSION Class.............................................7 2.1. SESSION Class.............................................7
2.2. SESSION-OF-INTEREST (SOI) Class..........................10 2.2. SESSION-OF-INTEREST (SOI) Class..........................10
3. Processing Rules For Handling Generic Aggregate RSVP Reservations 3. Processing Rules For Handling Generic Aggregate RSVP Reservations
.................................................................11 .................................................................12
3.1. Required Changes to Path and Resv Processing.............12 3.1. Required Changes to Path and Resv Processing.............12
4. Procedures for Aggregation over Generic Aggregate RSVP 4. Procedures for Aggregation over Generic Aggregate RSVP
Reservations.....................................................13 Reservations.....................................................13
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..................17 From a Given Aggregator to a Given Deaggregator..................17
6. Security Considerations.......................................19 6. Security Considerations.......................................20
7. IANA Considerations...........................................20 7. IANA Considerations...........................................20
8. Acknowledgments...............................................20 8. Acknowledgments...............................................21
9. Normative References..........................................20 9. Normative References..........................................21
10. Informative References.......................................21 10. Informative References.......................................22
11. Authors' Addresses...........................................21 11. Authors' Addresses...........................................22
Appendix A: Example Signaling Flow...............................23 Appendix A: Example Signaling Flow...............................24
Specification of Requirements Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [KEYWORDS].
Generic Aggregate RSVP Reservations September 2006
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.
skipping to change at page 4, line 4 skipping to change at page 4, line 4
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 Class = SESSION, o Class = SESSION,
C-Type = RSVP-AGGREGATE-IP4 C-Type = RSVP-AGGREGATE-IP4
Generic Aggregate RSVP Reservations September 2006
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| 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 object is specified as: SENDER_TEMPLATE object is specified as:
skipping to change at page 5, line 4 skipping to change at page 5, line 4
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 DSCP), each parallel generic aggregate reservations (for the same DSCP), each
with different preemption priorities, can be used to efficiently with different preemption priorities, can be used to efficiently
support the preemption priorities of end-to-end reservations. support 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 DSCP, by defining a more flexible type of reservations for the same DSCP, by defining a more flexible type of
aggregate RSVP reservations, referred to as generic aggregate aggregate RSVP reservations, referred to as generic aggregate
reservations. This is achieved primarily by adding the notions of a reservations. This is achieved primarily by adding the notions of a
Generic Aggregate RSVP Reservations September 2006
Virtual Destination Port and of an Extended Virtual Destination Port Virtual Destination Port and of an Extended Virtual Destination Port
in the RSVP Session object. 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 [RSVP-
IPSEC] for identification and demultiplexing of generic aggregate IPSEC] for identification and demultiplexing of generic aggregate
sessions beyond the IP destination address and DSCP. This allows sessions beyond the IP destination address and DSCP. This allows
multiple generic aggregate reservations to be established for a given multiple generic aggregate reservations to be established for a given
skipping to change at page 6, line 4 skipping to change at page 6, line 4
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 generic
aggregate 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
Generic Aggregate RSVP Reservations September 2006
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].
skipping to change at page 7, line 5 skipping to change at page 7, line 5
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.
Generic Aggregate RSVP Reservations September 2006
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 only defines the use of the GENERIC-AGG-IP4-SOI This specification only defines the use of the GENERIC-AGG-IP4-SOI
and GENERIC-AGG-IP6-SOI objects in two circumstances: and GENERIC-AGG-IP6-SOI objects in two circumstances:
- inside an E2E PathErr message which contains an error code of - inside an E2E PathErr message which 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 which needs to be established
- inside an E2E Resv message in order to convey the session of - inside an E2E Resv message in order to convey the session of
the generic aggregate reservation onto which this E2E the generic aggregate reservation onto which this E2E
skipping to change at page 8, line 4 skipping to change at page 8, line 4
+-------------+-------------+-------------+--+----------+ +-------------+-------------+-------------+--+----------+
| Reserved | Flags | vDstPort |Rd| 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
IPv4 DestAddress (IPv4 Destination Address) IPv4 DestAddress (IPv4 Destination Address)
IPv4 address of the receiver (or Deaggregator) IPv4 address of the receiver (or Deaggregator)
Generic Aggregate RSVP Reservations September 2006
Reserved Reserved
A 8-bit field. All bits MUST be set to 0 on transmit. This field A 8-bit field. All bits MUST be set to 0 on transmit. This field
MUST be ignored on receipt. MUST be ignored on receipt.
Flags
A 8-bit field. The content and processing of this field are the
same as for the Flags field of the IPv4/UDP SESSION object (see
[RSVP])
VDstPort (Virtual Destination Port) VDstPort (Virtual Destination Port)
An 8-bit identifier used in the SESSION that remains constant An 8-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.
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.
skipping to change at page 8, line 30 skipping to change at page 8, line 39
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. over the life of the generic aggregate reservation.
A sender (or Aggregator) that wishes to narrow the scope of a A sender (or Aggregator) that wishes to narrow the scope of a
SESSION to the sender-receiver pair (or Aggregator-Deaggregator SESSION to the sender-receiver pair (or Aggregator-Deaggregator
pair) SHOULD place its IPv4 address here as a globally unique pair) SHOULD place its IPv4 address here as a network unique
identifier. A sender (or Aggregator) that wishes to use a common identifier. A sender (or Aggregator) that wishes to use a common
session with other senders (or Aggregators) in order to use a session with other senders (or Aggregators) in order to use a
shared reservation across senders (or Aggregators) MUST set this shared reservation across senders (or Aggregators) MUST set this
field to all zeros. field to 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 = To be allocated by IANA
Generic Aggregate RSVP Reservations September 2006
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 29 skipping to change at page 9, line 38
IPv6 DestAddress (IPv6 Destination Address) IPv6 DestAddress (IPv6 Destination Address)
IPv6 address of the receiver (or Deaggregator) IPv6 address of the receiver (or Deaggregator)
Reserved Reserved
A 8-bit field. All bits MUST be set to 0 on transmit. This field A 8-bit field. All bits MUST be set to 0 on transmit. This field
MUST be ignored on receipt. MUST be ignored on receipt.
Flags
A 8-bit field. The content and processing of this field are the
same as for the Flags field of the IPv6/UDP SESSION object (see
[RSVP])
VDstPort (Virtual Destination Port) VDstPort (Virtual Destination Port)
A 8-bit identifier used in the SESSION that remains constant A 8-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.
Rd (Reserved) Rd (Reserved)
Generic Aggregate RSVP Reservations September 2006
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
Extended vDstPort (Extended Virtual Destination Port) Extended vDstPort (Extended Virtual Destination Port)
skipping to change at page 10, line 4 skipping to change at page 10, line 19
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 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 Aggregator) that wishes to narrow the scope of a A sender (or Aggregator) that wishes to narrow the scope of a
SESSION to the sender-receiver pair (or Aggregator-Deaggregator SESSION to the sender-receiver pair (or Aggregator-Deaggregator
pair) SHOULD place its IPv6 address here as a globally unique pair) SHOULD place its IPv6 address here as a network unique
identifier. A sender (or Aggregator) that wishes to use a common identifier. A sender (or Aggregator) that wishes to use a common
session with other senders (or Aggregators) in order to use a session with other senders (or Aggregators) in order to use a
shared reservation across senders (or Aggregators) MUST set this shared reservation across senders (or Aggregators) MUST set this
field to all zeros. field to all zeros.
2.2. SESSION-OF-INTEREST (SOI) Class 2.2. SESSION-OF-INTEREST (SOI) Class
o GENERIC-AGG-IP4-SOI 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
skipping to change at page 10, line 37 skipping to change at page 11, line 4
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
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 which 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:
Generic Aggregate RSVP Reservations September 2006
Class = To be allocated by IANA Class = To be allocated by IANA
(same as for GENERIC-AGG-IP4-SOI) (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
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP6- | | | SOI |GEN-AGG-IP6- |
| Length (bytes) | Class-Num |SOI C-Type | | Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
skipping to change at page 11, line 37 skipping to change at page 12, line 4
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
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 RSVP Reservations September 2006
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 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-IP4 (resp. GENERIC-AGGREGATE-IP6) 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
skipping to change at page 12, line 39 skipping to change at page 13, line 4
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.
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
Generic Aggregate RSVP Reservations September 2006
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.
The changes to RESV message processing are: The changes to RESV message processing are:
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-AGGREGATE SESSION object (as per [RSVP-AGG]) or the RSVP-AGGREGATE SESSION object (as per [RSVP-AGG]) or the
GENERIC-AGGREGATE SESSION object (as per this document). If GENERIC-AGGREGATE SESSION object (as per this document). If
this condition is not met, an RSVP router or end-station MUST this condition is not met, an RSVP router or end-station MUST
skipping to change at page 13, line 37 skipping to change at page 14, line 4
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. 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
Generic Aggregate RSVP Reservations September 2006
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, a SESSION-OF-INTEREST object MUST include in the E2E PathErr message, a SESSION-OF-INTEREST object
which contains the GENERIC-AGGREGATE Session to be used for which contains the GENERIC-AGGREGATE Session to be used for
establishment of the requested generic aggregate reservation. Since establishment of the requested generic aggregate reservation. Since
this GENERIC-AGGREGATE SESSION contains the DSCP, the DCLASS object this GENERIC-AGGREGATE SESSION contains the DSCP, the DCLASS object
need not be 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
skipping to change at page 14, line 38 skipping to change at page 15, line 4
are extended correspondingly. On receipt of such a message containing are extended correspondingly. On receipt of such a message containing
a SESSION-OF-INTEREST object, the Aggregator MUST trigger 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
Generic Aggregate RSVP Reservations September 2006
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 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-
skipping to change at page 15, line 39 skipping to change at page 16, line 4
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) and in the RSVP HOP object of the E2E Resv message. However, Code) and in the RSVP HOP object of the E2E Resv message. However,
[RSVP-AGG] does not discuss which IP addresses are to be selected by [RSVP-AGG] does not discuss which IP addresses are to be selected by
the aggregator and Deaggregator for such purposes. Because these the aggregator and Deaggregator for such purposes. Because these
Generic Aggregate RSVP Reservations September 2006
addresses are intended to identify the Aggregator and Deaggregator addresses are intended to identify the Aggregator and Deaggregator
and not to identify any specific interface on these devices, this and not to identify any specific interface on these devices, this
document RECOMMENDS that the Aggregator and Deaggregator SHOULD use document RECOMMENDS that the Aggregator and Deaggregator SHOULD use
interface-independent addresses (for example a loopback address) interface-independent addresses (for example a loopback address)
whenever they communicate their respective identity to each other. whenever they communicate their respective identity to each other.
This ensures that respective identification of the Aggregator and This ensures that respective identification of the Aggregator and
Deaggregator is not impacted by any interface state change on these Deaggregator is not impacted by any interface state change on these
devices. In turns this results in more stable operations and 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
skipping to change at page 16, line 38 skipping to change at page 17, line 4
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 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) which are to be aggregated over (from outside the aggregation region) which 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 PSTN Gateways. In that case, the generic
aggregate reservations may be established by the end-systems in aggregate reservations may be established by the end-systems in
Generic Aggregate RSVP Reservations September 2006
response to application-level triggers such as voice call signaling. response to application-level triggers such as voice call signaling.
Alternatively, generic aggregate reservations may also be used edge- Alternatively, generic aggregate reservations may also be used edge-
to-edge to manage bandwidth in a Diffserv cloud even if RSVP is not 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 used end-to-end. A simple example of such a usage would be the static
configuration of a generic aggregate reservation for a certain configuration of a generic aggregate reservation for a certain
bandwidth for traffic from an ingress (Aggregator) router to an bandwidth for traffic from an ingress (Aggregator) router to an
egress (Deaggregator) router. 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
skipping to change at page 17, line 36 skipping to change at page 18, line 4
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 |
| | | |
| ---/ | ---/
\ / \ /
Generic Aggregate RSVP Reservations September 2006
\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:
skipping to change at page 18, line 38 skipping to change at page 19, line 4
* 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 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:
Generic Aggregate RSVP Reservations September 2006
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
skipping to change at page 19, line 41 skipping to change at page 20, line 5
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)=P2 * POLICY_DATA (PREEMPTION_PRI)=P2
Generic Aggregate RSVP Reservations September 2006
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 (respectively) V1 and V2 since, Note that V3 and V4 could be equal to (respectively) V1 and V2 since,
in this example, the Extended VDstPort of the GENERIC-AGGREGATE in this example, the Extended VDstPort of the GENERIC-AGGREGATE
Session contains the address of the Deaggregator and, thus, ensures Session contains the address of the Deaggregator and, thus, ensures
that different sessions are used for each Deaggregator. that different sessions are used for each Deaggregator.
6. Security Considerations 6. Security Considerations
The security considerations associated with the RSVP protocol [RSVP] In the environments concerned by this document, RSVP messages are
apply to this document as it relies on RSVP. used to control resource reservations for generic aggregate
reservations and may be used to control resource reservations for E2E
reservations being aggregated over the generic aggregate reservations.
To ensure the integrity of the associated reservation and admission
control mechanisms, the mechanisms defined in [RSVP-CRYPTO1] and
[RSVP-CRYPTO2] can be used. Those protect RSVP messages integrity
hop-by-hop and provide node authentication, thereby protecting
against corruption and spoofing of RSVP messages. These hop-by-hop
integrity mechanisms can naturally be used to protect the RSVP
messages used for generic aggregate reservations, to protect RSVP
messages used for E2E reservations outside the aggregation region, or
for both. These hop-by-hop RSVP integrity mechanisms can also be used
to protect RSVP messages used for E2E reservations when those transit
through the aggregation region. This is because the Aggregator and
Deaggregator behave as RSVP neighbors from the viewpoint of the E2E
flows (even if they are not necessarily IP neighbors nor RSVP-TE
neighbors). It that case, the Aggregator and Deaggregator need to use
a pre-shared secret. Where the dynamic Deaggregator determination
procedure defined in [RSVP-AGG] are used, the Aggregator does not
know ahead of time which router is going to act as the Deaggregator.
Thus, use of the mechanisms of [RSVP-CRYPTO1] and [RSVP-CRYPTO2] for
protection of RSVP E2E messages (e.g. E2E Path) while they transit
through the aggregation region may require the use of a secret pre-
shared across the Aggregator and all Deaggregators.
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
Generic Aggregate RSVP Reservations September 2006
This document requests that IANA allocates two new C-Types under the This document requests that IANA allocates two new C-Types under the
existing SESSION Class (Class 1)for the two new RSVP objects defined existing SESSION Class (Class 1) for the two new RSVP objects
in section 2.1: GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE- defined in section 2.1: GENERIC-AGGREGATE-IP4 SESSION and GENERIC-
IP6 SESSION. AGGREGATE-IP6 SESSION. This allocation is in accordance with [RSVP-
MOD] which defines the default assignment policy as Standards Action
for new Class-Type values under an existing class.
This document also requests that IANA allocates one new Class-Num for This document also requests that IANA allocates one new Class-Num for
the SESSION-OF-INTEREST class, and two new C-Types for the two new the SESSION-OF-INTEREST class, and two new C-Types for the two new
RSVP objects under that class defined in section 2.2: GENERIC-AGG- RSVP objects under that class defined in section 2.2: GENERIC-AGG-
IP4-SOI and GENERIC-AGG-IP4-SOI. IP4-SOI and GENERIC-AGG-IP6-SOI. The Class-Num for the SESSION-OF-
INTEREST class is to be allocated in the range from 128 to 183
defined in [RSVP-MOD] as to be assigned by Standards Action. In
accordance with [RSVP-MOD], the Class-Type values under the SESSION-
OF-INTEREST class are to be allocated according to the following
policy:
o C-Type values from 0 through 127 are to be assigned by Standards
Action
o C-Type values from 128 through 191 are to be assigned by Expert
Review
o C-Type values from 192 through 255 are reserved for Vendor
Private use
o C-Type value 1 is to be allocated to the GENERIC-AGG-IP4-SOI
object defined in this document
o C-Type value 2 is to be allocated to the GENERIC-AGG-IP6-SOI
object defined in this document.
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 Voce, Anil Agarwal, Alexander Sayenko and Anca Zamfir for their input
into the content of this document. Thanks to Steve Kent for 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.
9. Normative References 9. Normative References
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", [KEYWORDS] "Key words for use in RFCs to Indicate Requirement Levels",
Bradner, RFC2119 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, Generic Aggregate RSVP Reservations September 2006
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
[RSVP-CRYPTO1] Baker at al, RSVP Cryptographic Authentication, RFC
2747, January 2000.
[RSVP-CRYPTO2] Braden and Zhang, RSVP Cryptographic Authentication -
Updated Message Type Value, RFC 3097, April 2001.
[RSVP-IPSEC] "RSVP Extensions for IPsec Data Flows", Berger et al,
RFC2207
[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
[GRE] "Generic Routing Encapsulation (GRE) ", Farinacci et al, RFC [RSVP-MOD] "Procedures for Modifying the Resource reSerVation
2784 Protocol (RSVP)", Kompella and Lang, RFC 3936, BCP 96
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, RFC 4495 andwidth of a Reservation Flow", Polk et al, RFC 4495
[RSVP-TUNNEL] "RSVP Operation Over IP Tunnels", Terzis et al., RFC [GRE] "Generic Routing Encapsulation (GRE) ", Farinacci et al, RFC
2746, January 2000. 2784
[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.
[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 11. Authors' Addresses
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
Generic Aggregate RSVP Reservations September 2006
France France
Email: flefauch@cisco.com Email: flefauch@cisco.com
Bruce Davie Bruce Davie
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: bdavie@cisco.com Email: bdavie@cisco.com
skipping to change at page 22, line 35 skipping to change at page 24, line 4
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
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
Generic Aggregate RSVP Reservations September 2006
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.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. this standard.
Please address the information to the IETF at ietf-ipr@ietf.org. Please address the information to the IETF at ietf-ipr@ietf.org.
skipping to change at page 23, line 33 skipping to change at page 25, line 4
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 which is the first between a given pair of
Aggregator/Deaggregator. Aggregator/Deaggregator.
Aggregator Deaggregator Aggregator Deaggregator
E2E Path E2E Path
-----------> ----------->
(1) (1)
E2E Path E2E Path
Generic Aggregate RSVP Reservations September 2006
-------------------------------> ------------------------------->
(2) (2)
E2E PathErr(New-agg-needed,SOI=GAx) E2E PathErr(New-agg-needed,SOI=GAx)
<---------------------------------- <----------------------------------
E2E PathErr(New-agg-needed,SOI=GAy) E2E PathErr(New-agg-needed,SOI=GAy)
<---------------------------------- <----------------------------------
(3) (3)
AggPath(Session=GAx) AggPath(Session=GAx)
-------------------------------> ------------------------------->
AggPath(Session=GAy) AggPath(Session=GAy)
skipping to change at page 24, line 37 skipping to change at page 26, line 4
update the ADSPEC of the E2E Path, the Deaggregator needs the ADSPEC update the ADSPEC of the E2E Path, the Deaggregator needs the ADSPEC
of Aggregate PATH. In this example the Deaggregator elects to of Aggregate PATH. In this example the Deaggregator elects to
instruct the Aggregator to set up Aggregate Path states for the two instruct the Aggregator to set up Aggregate Path states for the two
supported DSCPs. To do that, the Deaggregator sends two E2E PathErr supported DSCPs. To do that, the Deaggregator sends two E2E PathErr
messages with a New-Agg-Needed PathErr code. Both PathErr messages messages with a New-Agg-Needed PathErr code. Both PathErr messages
also contain a SESSION-OF-INTEREST (SOI) object. In the first E2E also contain a SESSION-OF-INTEREST (SOI) object. In the first E2E
PathErr, the SOI contains a GENERIC-AGGREGATE SESSION (GAx) whose PathErr, the SOI contains a GENERIC-AGGREGATE SESSION (GAx) whose
DSCP is set to x. In the second E2E PathErr, the SOI contains a 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 GENERIC-AGGREGATE SESSION (GAy) whose DSCP is set to y. In both
messages the GENERIC-AGGREGATE SESSION contains an interface- messages the GENERIC-AGGREGATE SESSION contains an interface-
Generic Aggregate RSVP Reservations September 2006
independent Deaggregator address inside the DestAddress and independent Deaggregator address inside the DestAddress and
appropriate values inside the vDstPort and Extended vDstPort fields. 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 (GAx
and GAy). 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 Path and updates the E2E Path ADSPEC
accordingly. The Deaggregator also modifies the E2E Path IP Protocol accordingly. The Deaggregator also modifies the E2E Path IP Protocol
 End of changes. 45 change blocks. 
30 lines changed or deleted 164 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/