idnits 2.17.1 draft-ietf-tsvwg-rsvp-ipsec-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1030. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1007. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1014. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1020. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RSVP-AGG], [RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 29 has weird spacing: '... and may be...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This document also modifies the procedures of [RSVP-AGG] related to exchange of E2E Resv messages between Deaggregator and Aggregator. The Deaggregator MUST include the new SESSION-OF-INTEREST object in the E2E Resv message, in order to indicate to the Aggregator the generic aggregate session to map a given E2E reservation onto. Again, since the GENERIC-AGGREGATE SESSION (included in the SESSION-OF-INTEREST object) contains the DSCP, the DCLASS object need not be included in the E2E Resv message. The Aggregator MUST interpret the SESSION-OF-INTEREST object in the E2E Resv as indicating which generic aggregate reservation session the corresponding E2E reservation is mapped onto. The Aggregator MUST not include the SESSION-OF-INTEREST object when sending an E2E Resv upstream towards the sender. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2006) is 6495 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2209 (ref. 'RSVP-PROCESS') Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Francois Le Faucheur 2 Bruce Davie 3 Cisco Systems, Inc. 5 Pratik Bose 6 Lockheed Martin 8 Chris Christou 9 Michael Davenport 10 Booz Allen Hamilton 11 draft-ietf-tsvwg-rsvp-ipsec-02.txt 12 Expires: January 2007 July 2006 14 Generic Aggregate RSVP Reservations 15 draft-ietf-tsvwg-rsvp-ipsec-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 [RSVP-AGG] defines aggregate RSVP reservations allowing resources to 42 be reserved in a Diffserv network for a given DSCP from a given 43 source to a given destination. [RSVP-AGG] also defines how end-to-end 44 RSVP reservations can be aggregated onto such aggregate reservations 45 when transiting through a Diffserv cloud. There are situations where 46 multiple such aggregate reservations are needed for the same source 47 IP address, destination IP address and DSCP. However, this is not 48 supported by the aggregate reservations defined in [RSVP-AGG]. In 49 order to support this, the present document defines a more flexible 50 type of aggregate RSVP reservations, referred to as generic aggregate 51 reservation. Multiple such generic aggregate reservations can be 52 established for a given DSCP from a given source IP address to a 53 given destination IP address. The generic aggregate reservations may 54 be used to aggregate end-to-end RSVP reservations. This document also 55 defines the procedures for such aggregation. The generic aggregate 56 reservations may also be used end-to-end directly by end-systems 57 attached to a Diffserv network. 59 Copyright Notice 60 Copyright (C) The Internet Society (2006). 62 Table Of Content 64 1. Introduction...................................................3 65 1.1. Related RFCs and Internet-Drafts..........................5 66 1.2. Organization Of This Document.............................6 67 2. Object Definition..............................................6 68 2.1. SESSION Class.............................................7 69 2.2. SESSION-OF-INTEREST (SOI) Class..........................10 70 3. Processing Rules For Handling Generic Aggregate RSVP Reservations 71 .................................................................11 72 3.1. Required Changes to Path and Resv Processing.............12 73 4. Procedures for Aggregation over Generic Aggregate RSVP 74 Reservations.....................................................13 75 5. Example Usage Of Multiple Generic Aggregate Reservations Per DSCP 76 From a Given Aggregator to a Given Deaggregator..................17 77 6. Security Considerations.......................................19 78 7. IANA Considerations...........................................20 79 8. Acknowledgments...............................................20 80 9. Normative References..........................................20 81 10. Informative References.......................................21 82 11. Authors' Addresses...........................................21 83 Appendix A: Example Signaling Flow...............................23 85 Specification of Requirements 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 1. Introduction 93 [RSVP-AGG] defines RSVP aggregate reservations allowing resources to 94 be reserved in a Diffserv network for a flow characterized by its 3- 95 tuple . 97 [RSVP-AGG] also defines the procedures for aggregation of end-to-end 98 RSVP reservations onto such aggregate reservations when transiting 99 through a Diffserv cloud. Such aggregation is illustrated in Figure 1. 100 This document reuses the terminology defined in [RSVP-AGG]. 102 -------------------------- 103 / Aggregation \ 104 |----| | Region | |----| 105 H--| R |\ |-----| |------| /| R |-->H 106 H--| |\\| | |---| |---| | |//| |-->H 107 |----| \| | | I | | I | | |/ |----| 108 | Agg |======================>| Deag | 109 /| | | | | | | |\ 110 H--------//| | |---| |---| | |\\-------->H 111 H--------/ |-----| |------| \-------->H 112 | | 113 \ / 114 -------------------------- 116 H = Host requesting end-to-end RSVP reservations 117 R = RSVP router 118 Agg = Aggregator 119 Deag = Deaggregator 120 I = Interior Router 122 --> = E2E RSVP reservation 123 ==> = Aggregate RSVP reservation 125 Figure 1 : Aggregation of E2E Reservations 126 over aggregate RSVP Reservations 128 These aggregate reservations use a SESSION type specified in [RSVP- 129 AGG] that contains the receiver (or Deaggregator) IP address and the 130 DSCP of the PHB from which Diffserv resources are to be reserved. For 131 example, in the case of IPv4, the SESSION object is specified as: 133 o Class = SESSION, 134 C-Type = RSVP-AGGREGATE-IP4 135 +-------------+-------------+-------------+-------------+ 136 | IPv4 Session Address (4 bytes) | 137 +-------------+-------------+-------------+-------------+ 138 | /////////// | Flags | ///////// | DSCP | 139 +-------------+-------------+-------------+-------------+ 141 These aggregate reservations use a SENDER_TEMPLATE and FILTER_SPEC 142 types specified in [RSVP-AGG] and which contains only the sender (or 143 Aggregator) IP address. For example, in the case of IPv4, the 144 SENDER_TEMPLATE object is specified as: 146 o Class = SENDER_TEMPLATE, 147 C-Type = RSVP-AGGREGATE-IP4 149 +-------------+-------------+-------------+-------------+ 150 | IPv4 Aggregator Address (4 bytes) | 151 +-------------+-------------+-------------+-------------+ 153 Thus, it is possible to establish, from a given source IP address to 154 a given destination IP address, separate such aggregate reservations 155 for different DSCPs. However, from a given source IP address to a 156 given IP destination address, only a single [RSVP-AGG] aggregate 157 reservation can be established for a given DSCP. 159 Situations have since been identified where multiple such aggregate 160 reservations are needed for the same source IP address, destination 161 IP address and DSCP. One example is where E2E reservations using 162 different preemption priorities (as per [RSVP-PREEMP]) need to be 163 aggregated through a Diffserv cloud using the same DSCP. Using 164 multiple aggregate reservations for the same DSCP allows enforcement 165 of the different preemption priorities within the aggregation region. 166 In turn this allows much more efficient management of the Diffserv 167 resources and in period of resource shortage allows to sustain a 168 larger number of E2E reservations with higher preemption priorities. 170 For example, [SIG-NESTED] discusses in details how end-to-end RSVP 171 reservations can be established in a nested VPN environment through 172 RSVP aggregation. In particular, [SIG-NESTED] describes how multiple 173 parallel generic aggregate reservations (for the same DSCP), each 174 with different preemption priorities, can be used to efficiently 175 support the preemption priorities of end-to-end reservations. 177 This document addresses this requirement for multiple aggregate 178 reservations for the same DSCP, by defining a more flexible type of 179 aggregate RSVP reservations, referred to as generic aggregate 180 reservations. This is achieved primarily by adding the notions of a 181 Virtual Destination Port and of an Extended Virtual Destination Port 182 in the RSVP Session object. 184 The notion of Virtual Destination Port was introduced in [RSVP-IPSEC] 185 to address a similar requirement (albeit in a different context) for 186 identification and demultiplexing of sessions beyond the IP 187 destination address. This document reuses this notion from [RSVP- 188 IPSEC] for identification and demultiplexing of generic aggregate 189 sessions beyond the IP destination address and DSCP. This allows 190 multiple generic aggregate reservations to be established for a given 191 DSCP, from a given source IP address to a given destination IP 192 address. 194 [RSVP-TE] introduced the concept of an Extended Tunnel ID (in 195 addition to the tunnel egress address and the Tunnel ID) in the 196 Session object used to establish MPLS Traffic Engineering tunnels 197 with RSVP. The Extended Tunnel ID provides a very convenient 198 mechanism for the tunnel ingress node to narrow the scope of the 199 session to the ingress-egress pair. The ingress node can achieve this 200 by using one of its own IP addresses as a globally unique identifier 201 and including it in the Extended Tunnel ID and therefore within the 202 Session object. This document reuses this notion of Extended Tunnel 203 ID from [RSVP-TE], simply renaming it Extended Virtual Destination 204 Port. This provides a convenient mechanism to narrow the scope of a 205 generic aggregate session to an Aggregator-Deaggregator pair. 207 The generic aggregate reservations may be used to aggregate end-to- 208 end RSVP reservations. This document also defines the procedures for 209 such aggregation. These procedures are based on those of [RSVP-AGG] 210 and this document only specifies the differences with those. 212 The generic aggregate reservations may also be used end-to-end 213 directly by end-systems attached to a Diffserv network. 215 1.1. Related RFCs and Internet-Drafts 217 This document is heavily based on [RSVP-AGG]. It reuses [RSVP-AGG] 218 wherever applicable and only specifies the necessary extensions 219 beyond [RSVP-AGG]. 221 The mechanisms defined in [BW-REDUC] allow an existing reservation to 222 be reduced in allocated bandwidth by RSVP routers in lieu of tearing 223 that reservation down. These mechanisms are applicable to the generic 224 aggregate reservations defined in the present document. 226 [RSVP-TUNNEL] describes a general approach to running RSVP over 227 various types of tunnels. One of these types of tunnel, referred to 228 as a "type 2 tunnel", has some similarity with the generic aggregate 229 reservations described in this document. The similarity stems from 230 the fact that a single, aggregate reservation is made for the tunnel 231 while many individual flows are carried over that tunnel. However, 232 [RSVP-TUNNEL] does not address the use of Diffserv-based 233 classification and scheduling in the core of a network (between 234 tunnel endpoints), but rather relies on a UDP/IP tunnel header for 235 classification. This is why [RSVP-AGG] required additional objects 236 and procedures beyond those of [RSVP-TUNNEL]. Like [RSVP-AGG], this 237 document also assumes the use of Diffserv-based classification and 238 scheduling in the aggregation region and, thus, requires additional 239 objects and procedures beyond those of [RSVP-TUNNEL]. 241 As explained earlier, this document reuses the notion of Virtual 242 Destination Port from [RSVP-IPSEC] and the notion of Extended Tunnel 243 ID from [RSVP-TE]. 245 1.2. Organization Of This Document 247 Section 2 defines the new RSVP objects related to generic aggregate 248 reservations and to aggregation of E2E reservations onto those. 249 Section 3 describes the processing rules for handling of generic 250 aggregate reservations. Section 4 specifies the procedures for 251 aggregation of end to end RSVP reservations over generic aggregate 252 RSVP reservations. Section 5 provides example usage of how the 253 generic aggregate reservations may be used. 255 The Security Considerations and the IANA Considerations are 256 discussed in Section 6 and 7, respectively. 258 Finally, Appendix 1 provides an example signaling flow is 259 illustrating aggregation of E2E RSVP reservations onto generic 260 aggregate RSVP reservations. 262 2. Object Definition 264 This document reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP- 265 AGGREGATE-IP6 FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE and 266 RSVP-AGGREGATE-IP6 SENDER_TEMPLATE objects defined in [RSVP-AGG]. 268 This document defines: 269 - two new objects (GENERIC-AGGREGATE-IP4 SESSION and GENERIC- 270 AGGREGATE-IP6 SESSION) under the existing SESSION Class, and 271 - two new objects (GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI) 272 under a new SESSION-OF-INTEREST Class. 274 Detailed description of these objects is provided below in this 275 section. 277 The GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION 278 objects are applicable to all types of RSVP messages. 280 This specification only defines the use of the GENERIC-AGG-IP4-SOI 281 and GENERIC-AGG-IP6-SOI objects in two circumstances: 282 - inside an E2E PathErr message which contains an error code of 283 NEW-AGGREGATE-NEEDED in order to convey the session of a new 284 generic aggregate reservation which needs to be established 285 - inside an E2E Resv message in order to convey the session of 286 the generic aggregate reservation onto which this E2E 287 reservation needs to be mapped. 288 Details of the corresponding procedures can be found in section 4. 290 However, it is envisioned that the ability to signal, inside RSVP 291 messages, the Session of another reservation (which has some 292 relationship with the current RSVP reservation) might have some other 293 applicability in the future. Thus, those objects have been specified 294 in a more generic manner under a flexible SESSION-OF-INTEREST class. 296 All the new objects defined in this document are optional with 297 respect to RSVP so that general RSVP implementations not concerned 298 with generic aggregate reservations do not have to support these 299 objects. RSVP routers supporting generic aggregate IPv4 (respectively 300 IPv6) reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION 301 object (respectively GENERIC-AGGREGATE-IP6 SESSION). RSVP routers 302 supporting RSVP aggregation over generic aggregate IPv4 (respectively 303 IPv6) reservations MUST support the GENERIC-AGG-IP4-SOI object 304 (respectively GENERIC-AGG-IP6-SOI). 306 2.1. SESSION Class 308 o GENERIC-AGGREGATE-IP4 SESSION object: 309 Class = 1 (SESSION) 310 C-Type = To be allocated by IANA 312 0 7 8 15 16 23 24 31 313 +-------------+-------------+-------------+-------------+ 314 | IPv4 DestAddress (4 bytes) | 315 +-------------+-------------+-------------+--+----------+ 316 | Reserved | Flags | vDstPort |Rd| DSCP | 317 +-------------+-------------+-------------+--+----------+ 318 | Extended vDstPort | 319 +-------------+-------------+-------------+-------------+ 320 0 7 8 15 16 23 24 31 322 IPv4 DestAddress (IPv4 Destination Address) 324 IPv4 address of the receiver (or Deaggregator) 326 Reserved 328 A 8-bit field. All bits MUST be set to 0 on transmit. This field 329 MUST be ignored on receipt. 331 VDstPort (Virtual Destination Port) 333 An 8-bit identifier used in the SESSION that remains constant 334 over the life of the generic aggregate reservation. 336 Rd (Reserved) 338 A 2-bit field. All bits MUST be set to 0 on transmit. This field 339 MUST be ignored on receipt. 341 DSCP (Diffserv Code Point) 343 A 6-bit field containing the DSCP of the PHB from which Diffserv 344 resources are to be reserved. 346 Extended vDstPort (Extended Virtual Destination Port) 348 A 32-bit identifier used in the SESSION that remains constant 349 over the life of the generic aggregate reservation. 350 A sender (or Aggregator) that wishes to narrow the scope of a 351 SESSION to the sender-receiver pair (or Aggregator-Deaggregator 352 pair) SHOULD place its IPv4 address here as a globally unique 353 identifier. A sender (or Aggregator) that wishes to use a common 354 session with other senders (or Aggregators) in order to use a 355 shared reservation across senders (or Aggregators) MUST set this 356 field to all zeros. 358 o GENERIC-AGGREGATE-IP6 SESSION object: 359 Class = 1 (SESSION) 360 C-Type = To be allocated by IANA 362 0 7 8 15 16 23 24 31 363 +-------------+-------------+-------------+-------------+ 364 | | 365 + + 366 | | 367 + IPv6 DestAddress (16 bytes) + 368 | | 369 + + 370 | | 371 +-------------+-------------+-------------+--+----------+ 372 | Reserved | Flags | vDstPort |Rd| DSCP | 373 +-------------+-------------+-------------+--+----------+ 374 | | 375 + + 376 | Extended vDstPort | 377 + + 378 | (16 bytes) | 379 + + 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 0 7 8 15 16 25 26 31 384 IPv6 DestAddress (IPv6 Destination Address) 386 IPv6 address of the receiver (or Deaggregator) 388 Reserved 390 A 8-bit field. All bits MUST be set to 0 on transmit. This field 391 MUST be ignored on receipt. 393 VDstPort (Virtual Destination Port) 395 A 8-bit identifier used in the SESSION that remains constant 396 over the life of the generic aggregate reservation. 398 Rd (Reserved) 400 A 2-bit field. All bits MUST be set to 0 on transmit. This field 401 MUST be ignored on receipt. 403 DSCP (Diffserv Code Point) 405 A 6-bit field containing the DSCP of the PHB from which Diffserv 406 resources are to be reserved 408 Extended vDstPort (Extended Virtual Destination Port) 410 A 128-bit identifier used in the SESSION that remains constant 411 over the life of the generic aggregate reservation. 413 A sender (or Aggregator) that wishes to narrow the scope of a 414 SESSION to the sender-receiver pair (or Aggregator-Deaggregator 415 pair) SHOULD place its IPv6 address here as a globally unique 416 identifier. A sender (or Aggregator) that wishes to use a common 417 session with other senders (or Aggregators) in order to use a 418 shared reservation across senders (or Aggregators) MUST set this 419 field to all zeros. 421 2.2. SESSION-OF-INTEREST (SOI) Class 423 o GENERIC-AGG-IP4-SOI object: 424 Class = To be allocated by IANA 425 C-Type = To be allocated by IANA 427 0 7 8 15 16 23 24 31 428 +-------------+-------------+-------------+-------------+ 429 | | SOI |GEN-AGG-IP4- | 430 | Length (bytes) | Class-Num |SOI C-Type | 431 +-------------+-------------+-------------+-------------+ 432 | | 433 // Content of a GENERIC-AGGREGATE-IP4 SESSION Object // 434 | | 435 +-------------+-------------+-------------+-------------+ 437 Content of a GENERIC-AGGREGATE-IP4 SESSION Object: 439 This field contains a copy of the Session object of the session 440 which is of interest for the reservation. In the case of a 441 GENERIC-AGG-IP4-SOI, the session of interest conveyed in this 442 field is a GENERIC-AGGREGATE-IP4 SESSION. 444 o GENERIC-AGG-IP6-SOI object: 445 Class = To be allocated by IANA 446 (same as for GENERIC-AGG-IP4-SOI) 447 C-Type = To be allocated by IANA 449 0 7 8 15 16 23 24 31 450 +-------------+-------------+-------------+-------------+ 451 | | SOI |GEN-AGG-IP6- | 452 | Length (bytes) | Class-Num |SOI C-Type | 453 +-------------+-------------+-------------+-------------+ 454 | | 455 // Content of a GENERIC-AGGREGATE-IP6 SESSION Object // 456 | | 457 +-------------+-------------+-------------+-------------+ 459 Content of a GENERIC-AGGREGATE-IP6 SESSION Object: 461 This field contains a copy of the Session object of the session 462 which is of interest for the reservation. In the case of a 463 GENERIC-AGG-IP6-SOI, the session of interest conveyed in this 464 field is a GENERIC-AGGREGATE-IP6 SESSION. 466 For example, if a SESSION-OF-INTEREST object is used inside an E2E 467 Resv message (as per the procedures defined in section 4) to indicate 468 which generic aggregate IPv4 session the E2E reservation is to be 469 mapped onto, then the GENERIC-AGG-IP4-SOI object will be used and it 470 will be encoded like this: 472 0 7 8 15 16 23 24 31 473 +-------------+-------------+-------------+-------------+ 474 | | SOI |GEN-AGG-IP4- | 475 | Length (bytes) | Class-Num |SOI C-Type | 476 +-------------+-------------+-------------+-------------+ 477 | IPv4 DestAddress (4 bytes) | 478 +-------------+-------------+-------------+--+----------+ 479 | Reserved | Flags | vDstPort |Rd| DSCP | 480 +-------------+-------------+-------------+--+----------+ 481 | Extended vDstPort | 482 +-------------+-------------+-------------+-------------+ 483 0 7 8 15 16 23 24 31 485 Note that a SESSION-OF-INTEREST object is not a SESSION object in 486 itself. It does not replace the SESSION object in RSVP messages. It 487 does not modify the usage of the SESSION object in RSVP messages. It 488 simply allows conveying the Session of another RSVP reservation 489 inside RSVP signaling messages, for some particular purposes. In the 490 context of this document, it is used to convey, inside an E2E RSVP 491 message pertaining to an end-to-end reservation, the Session of a 492 generic aggregate reservation associated with the E2E reservation. 493 Details for the corresponding procedures are specified in section 4. 495 3. Processing Rules For Handling Generic Aggregate RSVP Reservations 497 This section presents additions to the Processing Rules presented in 498 [RSVP-PROCESS]. These additions are required in order to properly 499 process the GENERIC-AGGREGATE-IP4 (resp. GENERIC-AGGREGATE-IP6) 500 SESSION object and the RSVP-AGGREGATE-IP4 (resp. RSVP-AGGREGATE-IP6) 501 FILTER_SPEC object. Values for referenced error codes can be found in 502 [RSVP]. As with the other RSVP documents, values for internally 503 reported (API) errors are not defined. 505 When referring to the new GENERIC-AGGREGATE-IP4 and GENERIC- 506 AGGREGATE-IP6 SESSION objects, IP version will not be included and 507 they will be referred to simply as GENERIC-AGGREGATE SESSION, unless 508 a specific distinction between IPv4 and IPv6 is being made. 510 When referring to the [RSVP-AGG] RSVP-AGGREGATE-IP4 and 511 RSVP-AGGREGATE-IP6 SESSION, FILTER_SPEC and SENDER_TEMPLATE objects, 512 IP version will not be included and they will be referred to simply 513 as RSVP-AGGREGATE, unless a specific distinction between IPv4 and 514 IPv6 is being made. 516 3.1. Required Changes to Path and Resv Processing 518 Both RESV and PATH processing will need to be changed to support the 519 new objects. 521 The following PATH message processing changes are required: 523 o When a session is defined using the GENERIC-AGGREGATE SESSION 524 object, only the [RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATE may 525 be used. When this condition is violated in a PATH message 526 received by an RSVP end-station, the RSVP end-station SHOULD 527 report a "Conflicting C-Type" API error to the application. 528 When this condition is violated in a PATH message received by 529 an RSVP router, the RSVP router MUST consider this as a 530 message formatting error. 532 o For PATH messages that contain the GENERIC-AGGREGATE SESSION 533 object, the VDstPort value, the Extended VDstPort value and 534 the DSCP value should be recorded (in addition to the 535 destination/Deaggregator address and source/aggregator 536 address). These values form part of the recorded state of the 537 session. The DSCP may need to be passed to traffic control; 538 however the vDstPort and Extended VDstPort are not passed to 539 traffic control since they do not appear inside the data 540 packets of the corresponding reservation. 542 The changes to RESV message processing are: 544 o When a RESV message contains a [RSVP-AGG] RSVP-AGGREGATE 545 FILTER_SPEC, the session MUST be defined using either the 546 RSVP-AGGREGATE SESSION object (as per [RSVP-AGG]) or the 547 GENERIC-AGGREGATE SESSION object (as per this document). If 548 this condition is not met, an RSVP router or end-station MUST 549 consider that there is a message formatting error. 551 o When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION 552 type is GENERIC-AGGREGATE, each node MAY have a data 553 classifier installed for the flow: 555 * If the node needs to perform fine-grain classification (for 556 example to perform fine-grain policing on ingress at a trust 557 boundary) then the node MUST create a data classifier 558 described by the 3-tuple . 560 Note that if multiple reservations are established with 561 different Virtual Destination Ports (and/or different 562 Extended Virtual Destination Ports) but with the same 563 , then those cannot be 564 distinguished by the classifier. If the router is using the 565 classifier for policing purposes, the router will therefore 566 police those together and MUST program the policing rate to 567 the sum of the reserved rate across all the corresponding 568 reservations. 570 * If the node only needs to perform Diffserv classification 571 (for example inside the aggregation domain downstream of the 572 trust boundary) then the node MUST rely on the Diffserv data 573 classifier based on the DSCP only. 575 4. Procedures for Aggregation over Generic Aggregate RSVP Reservations 577 The procedures for aggregation of E2E reservations over generic 578 aggregate RSVP reservations are the same as the procedures specified 579 in [RSVP-AGG] with the exceptions of the procedure changes listed in 580 this section. 582 As specified in [RSVP-AGG], the Deaggregator is responsible for 583 mapping a given E2E reservation on a given aggregate reservation. The 584 Deaggregator requests establishment of a new aggregate reservation by 585 sending to the Aggregator an E2E PathErr message with an error code 586 of NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the Deaggregator conveys the 587 DSCP of the new requested aggregate reservation by including a DCLASS 588 Object in the E2E PathErr and encoding the corresponding DSCP inside. 589 This document modifies and extends this procedure. The Deaggregator 590 MUST include in the E2E PathErr message, a SESSION-OF-INTEREST object 591 which contains the GENERIC-AGGREGATE Session to be used for 592 establishment of the requested generic aggregate reservation. Since 593 this GENERIC-AGGREGATE SESSION contains the DSCP, the DCLASS object 594 need not be included in the PathErr message. 596 Note that the Deaggregator can easily ensure that different 597 Aggregators use different sessions for their Aggregate Path towards a 598 given Deaggregator. This is because the Deaggregator can easily 599 select VDstPort and/or Extended VDstPort numbers which are different 600 for each Aggregator (for example by using the Aggregator address as 601 the Extended VDstPort) and can communicate those inside the GENERIC- 602 AGGREGATE SESSION included in the SESSION-OF-INTEREST object. This 603 provides an easy solution to establish separate reservations from 604 every Aggregator to a given Deaggregator. Conversely, if reservation 605 sharing were needed across multiple Aggregators, the Deaggregator 606 could facilitate this by allocating the same VDstPort and Extended 607 VDstPort to the multiple Aggregators and thus including the same 608 GENERIC-AGGREGATE SESSION inside the SESSION-OF-INTEREST object in 609 the E2E PathErr messages sent to these Aggregators. The Aggregators 610 could then all establish an Aggregate Path with the same GENERIC- 611 AGGREGATE SESSION. 613 Therefore various sharing scenarios can easily be supported. Policies 614 followed by the Deaggregator to determine which aggregators need 615 shared or separate reservations are beyond the scope of this document. 617 The Deaggregator MAY also include in the E2E PathErr message (with an 618 error code of NEW-AGGREGATE-NEEDED) additional RSVP objects which are 619 to be used for establishment of the new needed generic aggregate 620 reservation. For example, the Deaggregator MAY include in the E2E 621 PathErr an RSVP Signaled Preemption Priority Policy Element (as 622 specified in [RSVP-PREEMP]). 624 The [RSVP-AGG] procedures for processing of an E2E PathErr message 625 received with an error code of NEW-AGGREGATE-NEEDED by the Aggregator 626 are extended correspondingly. On receipt of such a message containing 627 a SESSION-OF-INTEREST object, the Aggregator MUST trigger 628 establishment of a generic aggregate reservation. In particular, it 629 MUST start sending aggregate Path messages with the GENERIC-AGGREGATE 630 SESSION found in the received SESSION-OF-INTEREST object. When an 631 RSVP Signaled Preemption Priority Policy Element is contained in the 632 received E2E PathErr message, the Aggregator MUST include this object 633 in the Aggregate Path for the corresponding generic aggregate 634 reservation. When other additional objects are contained in the 635 received E2E PathErr message and those can be unambiguously 636 interpreted as related to the new needed generic aggregate 637 reservation (as opposed to related to the E2E reservation), the 638 Aggregator SHOULD include those in the Aggregate Path for the 639 corresponding generic aggregate reservation. The Aggregator MUST use 640 as the Source Address (i.e. as the Aggregator Address in the Sender- 641 Template) for the generic aggregate reservation, the address it uses 642 to identify itself as the PHOP when forwarding the E2E Path messages 643 corresponding to the E2E PathErr message. 645 The Deaggregator follows the same procedures as described in [RSVP- 646 AGG] for establishing, maintaining and clearing the aggregate Resv 647 state. However, in this document, the Deaggregator MUST use the 648 generic aggregate reservations and hence use the GENERIC-AGGREGATE 649 SESSION specified earlier in this document. 651 This document also modifies the procedures of [RSVP-AGG] related to 652 exchange of E2E Resv messages between Deaggregator and Aggregator. 653 The Deaggregator MUST include the new SESSION-OF-INTEREST object in 654 the E2E Resv message, in order to indicate to the Aggregator the 655 generic aggregate session to map a given E2E reservation onto. Again, 656 since the GENERIC-AGGREGATE SESSION (included in the SESSION-OF- 657 INTEREST object) contains the DSCP, the DCLASS object need not be 658 included in the E2E Resv message. The Aggregator MUST interpret the 659 SESSION-OF-INTEREST object in the E2E Resv as indicating which 660 generic aggregate reservation session the corresponding E2E 661 reservation is mapped onto. The Aggregator MUST not include the 662 SESSION-OF-INTEREST object when sending an E2E Resv upstream towards 663 the sender. 665 Based on relevant policy, the Deaggregator may decide at some point 666 that an aggregate reservation is no longer needed and should be torn 667 down. In that case, the Deaggregator MUST send an aggregate ResvTear. 668 On receipt of the aggregate ResvTear, the Aggregator SHOULD send an 669 aggregate PathTear (unless the relevant policy instructs the 670 aggregator to do otherwise or to wait for some time before doing so, 671 for example in order to speed-up potential re-establishment of the 672 aggregate reservation in the future). 674 [RSVP-AGG] describes how the Aggregator and Deaggregator can 675 communicate their respective identity to each other. For example the 676 Aggregator includes one of its IP addresses in the RSVP HOP object in 677 the E2E Path which is transmitted downstream and received by the 678 Deaggregator once it traversed the aggregation region. Similarly, the 679 Deaggregator identifies itself to the Aggregator by including one of 680 its IP addresses in various fields, including the ERROR SPECIFICATION 681 of the E2E PathErr message (containing the NEW-AGGREGATE-NEEDED Error 682 Code) and in the RSVP HOP object of the E2E Resv message. However, 683 [RSVP-AGG] does not discuss which IP addresses are to be selected by 684 the aggregator and Deaggregator for such purposes. Because these 685 addresses are intended to identify the Aggregator and Deaggregator 686 and not to identify any specific interface on these devices, this 687 document RECOMMENDS that the Aggregator and Deaggregator SHOULD use 688 interface-independent addresses (for example a loopback address) 689 whenever they communicate their respective identity to each other. 690 This ensures that respective identification of the Aggregator and 691 Deaggregator is not impacted by any interface state change on these 692 devices. In turns this results in more stable operations and 693 considerably reduced RSVP signaling in the aggregation region. For 694 example, if interface-independent addresses are used by the 695 Aggregator and the Deaggregator, then a failure of an interface on 696 these devices may simply result in the rerouting of a given generic 697 aggregate reservation but will not result in the generic aggregate 698 reservation having to be torn down and another one established, nor 699 will it result in a change of mapping of E2E reservations on generic 700 aggregate reservations (assuming the Aggregator and Deaggregator 701 still have reachability after the failure and the Aggregator and 702 Deaggregator are still on the shortest path to the destination). 704 However, when identifying themselves to real RSVP neighbors (i.e. 705 neighbors which are not on the other side of the aggregation region), 706 the Aggregator and Deaggregator SHOULD continue using interface- 707 dependent addresses as per regular [RSVP] procedures. This applies 708 for example when the Aggregator identifies itself downstream as a 709 PHOP for the generic aggregate reservation or identifies itself 710 upstream as a NHOP for an E2E reservation. This also applies when the 711 Deaggregator identifies itself downstream as a PHOP for the E2E 712 reservation or identifies itself upstream as a NHOP for the generic 713 aggregate reservation. As part of the processing of generic aggregate 714 reservations, interior routers (i.e. routers within the aggregation 715 region) SHOULD continue using interface-dependent addresses as per 716 regular [RSVP] procedures. 718 More generally, within the aggregation region (ie between Aggregator 719 and Deaggregator) the operation of RSVP should be modeled with the 720 notion that E2E reservations are mapped to aggregate reservations and 721 are no longer tied to physical interfaces (as was the case with 722 regular RSVP). However, generic aggregate reservations (within the 723 aggregation region) as well as E2E reservations outside the 724 aggregation region, retain the model of regular RVSP and remain tied 725 to physical interfaces. 727 As discussed above, generic aggregate reservations may be established 728 edge-to-edge as a result of the establishment of E2E reservations 729 (from outside the aggregation region) which are to be aggregated over 730 the aggregation region. However, generic aggregate reservations may 731 also be used end-to-end by end-systems directly attached to a 732 Diffserv domain, such as PSTN Gateways. In that case, the generic 733 aggregate reservations may be established by the end-systems in 734 response to application-level triggers such as voice call signaling. 735 Alternatively, generic aggregate reservations may also be used edge- 736 to-edge to manage bandwidth in a Diffserv cloud even if RSVP is not 737 used end-to-end. A simple example of such a usage would be the static 738 configuration of a generic aggregate reservation for a certain 739 bandwidth for traffic from an ingress (Aggregator) router to an 740 egress (Deaggregator) router. 742 In this case, the establishment of the generic aggregate reservations 743 is controlled by configuration on the Aggregator and on the 744 Deaggregator. Configuration on the Aggregator triggers generation of 745 the aggregate Path message and provides sufficient information to the 746 Aggregator to derive the content of the GENERIC-AGGREGATE SESSION 747 object. This would typically include Deaggregator IP address, DSCP 748 and possibly VDstPort. Configuration on the Deaggregator would 749 instruct the Deaggregator to respond to a received generic aggregate 750 Path message and would provide sufficient information to the 751 Deaggregator to control the reservation. This may include bandwidth 752 to be reserved by the Deaggregator (for a given 753 Deaggregator/DSCP/VDstPort tuple). 755 In the absence of E2E microflow reservations, the Aggregator can use 756 a variety of policies to set the DSCP of packets passing into the 757 aggregation region and how they are mapped onto generic aggregate 758 reservations, thus determining whether they gain access to the 759 resources reserved by the aggregate reservation. These policies are a 760 matter of local configuration, as usual for a device at the edge of a 761 Diffserv cloud. 763 5. Example Usage Of Multiple Generic Aggregate Reservations Per DSCP 764 From a Given Aggregator to a Given Deaggregator 766 Let us consider the environment depicted in Figure 2 below. RSVP 767 aggregation is used to support E2E reservations between Cloud-1, 768 Cloud-2 and Cloud-3. 770 I----------I I----------I 771 I Cloud-1 I I Cloud-2 I 772 I----------I I----------I 773 | | 774 Agg-Deag-1------------ Agg-Deag-2 775 / \ 776 / Aggregation | 777 | Region | 778 | | 779 | ---/ 780 \ / 781 \Agg-Deag-3---------/ 782 | 783 I----------I 784 I Cloud-3 I 785 I----------I 787 Figure 2 : Example Usage of 788 Generic Aggregate IP Reservations 790 Let us assume that: 792 o the E2E reservations from Cloud-1 to Cloud-3 have a preemption 793 of either P1 or P2 795 o the E2E reservations from Cloud-2 to Cloud-3 have a preemption 796 of either P1 or P2 798 o the E2E reservations are only for Voice (which needs to be 799 treated in the aggregation region using the EF PHB) 801 o traffic from the E2E reservations is encapsulated in Aggregate 802 IP reservations from Aggregator to Deaggregator using GRE 803 tunneling ([GRE]). 805 Then, the following generic aggregate RSVP reservations may be 806 established from Agg-Deag-1 to Agg-Deag-3 for aggregation of the end- 807 to-end RSVP reservations: 809 A first generic aggregate reservation for aggregation of Voice 810 reservations from Cloud-1 to Cloud-3 requiring use of P1: 812 * GENERIC-AGGREGATE-IP4 SESSION: 813 IPv4 DestAddress= Agg-Deag-3 814 vDstPort=V1 815 DSCP=EF 816 Extended VDstPort= Agg-Deag-1 818 * STYLE=FF or SE 820 * IPv4/GPI FILTER_SPEC: 821 IPv4 SrcAddress= Agg-Deag-1 823 * POLICY_DATA (PREEMPTION_PRI)=P1 825 A second generic aggregate reservation for aggregation of Voice 826 reservations from Cloud-1 to Cloud-3 requiring use of P2: 828 * GENERIC-AGGREGATE-IP4 SESSION: 829 IPv4 DestAddress= Agg-Deag-3 830 vDstPort=V2 831 DSCP=EF 832 Extended VDstPort= Agg-Deag-1 834 * STYLE=FF or SE 836 * IPv4/GPI FILTER_SPEC: 837 IPv4 SrcAddress= Agg-Deag-1 839 * POLICY_DATA (PREEMPTION_PRI)=P2 841 where V1 and V2 are arbitrary VDstPort values picked by Agg-Deag-3. 843 The following generic aggregate RSVP reservations may be established 844 from Agg-Deag-2 to Agg-Deag-3 for aggregation of the end-to-end RSVP 845 reservations: 847 A third generic aggregate reservation for aggregation of Voice 848 reservations from Cloud-2 to Cloud-3 requiring use of P1: 850 * GENERIC-AGGREGATE-IP4 SESSION: 851 IPv4 DestAddress= Agg-Deag-3 852 vDstPort=V3 853 DSCP=EF 854 Extended VDstPort= Agg-Deag-2 856 * STYLE=FF or SE 858 * IPv4/GPI FILTER_SPEC: 859 IPv4 SrcAddress= Agg-Deag-2 861 * POLICY_DATA (PREEMPTION_PRI)=P1 863 A fourth generic aggregate reservation for aggregation of Voice 864 reservations from Cloud-2 to Cloud-3 requiring use of P2: 866 * GENERIC-AGGREGATE-IP4 SESSION: 867 IPv4 DestAddress= Agg-Deag-3 868 vDstPort=V4 869 DSCP=EF 870 Extended VDstPort= Agg-Deag-2 872 * STYLE=FF or SE 874 * IPv4/GPI FILTER_SPEC: 875 IPv4 SrcAddress= Agg-Deag-2 877 * POLICY_DATA (PREEMPTION_PRI)=P2 879 where V1 and V4 are arbitrary VDstPort values picked by Agg-Deag-3. 881 Note that V3 and V4 could be equal to (respectively) V1 and V2 since, 882 in this example, the Extended VDstPort of the GENERIC-AGGREGATE 883 Session contains the address of the Deaggregator and, thus, ensures 884 that different sessions are used for each Deaggregator. 886 6. Security Considerations 888 The security considerations associated with the RSVP protocol [RSVP] 889 apply to this document as it relies on RSVP. 891 When generic aggregate reservations are used for aggregation of E2E 892 reservations, the security considerations discussed in [RSVP-AGG] 893 apply. 895 The security considerations discussed in [SIG-NESTED] apply when the 896 generic aggregate reservations are used in the presence of IPsec 897 gateways. 899 7. IANA Considerations 901 This document requests that IANA allocates two new C-Types under the 902 existing SESSION Class (Class 1)for the two new RSVP objects defined 903 in section 2.1: GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE- 904 IP6 SESSION. 906 This document also requests that IANA allocates one new Class-Num for 907 the SESSION-OF-INTEREST class, and two new C-Types for the two new 908 RSVP objects under that class defined in section 2.2: GENERIC-AGG- 909 IP4-SOI and GENERIC-AGG-IP4-SOI. 911 8. Acknowledgments 913 This document borrows heavily from [RSVP-AGG]. It also borrows the 914 concepts of Virtual Destination Port and Extended Virtual Destination 915 Port respectively from [RSVP-IPSEC] and [RSVP-TE]. 917 Also, we thank Fred Baker, Roger Levesque, Carol Iturralde, Daniel 918 Voce, Anil Agarwal, Alexander Sayenko and Anca Zamfir for their input 919 into the content of this document. Thanks to Steve Kent for 920 insightful comments on usage of RSVP reservations in IPsec 921 environments. 923 9. Normative References 925 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 926 Bradner, RFC2119 928 [RSVP] "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 929 Specification", Braden et al, RFC2205 931 [RSVP-IPSEC] "RSVP Extensions for IPsec Data Flows", Berger et al, 932 RFC2207 934 [RSVP-AGG] "Aggregation of RSVP for IPv4 and IPv6 Reservations", 935 Baker et al, RFC3175 937 [RSVP-PROCESS] "Resource ReSerVation Protocol (RSVP) -- Version 1 938 Message Processing Rules", Braden et al, RFC2209 940 [GRE] "Generic Routing Encapsulation (GRE) ", Farinacci et al, RFC 941 2784 943 10. Informative References 945 [SIG-NESTED] "QoS Signaling in a Nested Virtual Private Network", 946 Baker et al, draft-ietf-tsvwg-vpn-signaled-preemption, work in 947 progress 949 [BW-REDUC] "A Resource Reservation Extension for the Reduction of 950 andwidth of a Reservation Flow", Polk et al, RFC 4495 952 [RSVP-TUNNEL] "RSVP Operation Over IP Tunnels", Terzis et al., RFC 953 2746, January 2000. 955 [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy 956 Element", RFC 3181, October 2001. 958 [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, 959 RFC 3209, December 2001. 961 11. Authors' Addresses 963 Francois Le Faucheur 964 Cisco Systems, Inc. 965 Village d'Entreprise Green Side - Batiment T3 966 400, Avenue de Roumanille 967 06410 Biot Sophia-Antipolis 968 France 969 Email: flefauch@cisco.com 971 Bruce Davie 972 Cisco Systems, Inc. 973 300 Beaver Brook Road 974 Boxborough, MA 01719 975 USA 976 Email: bdavie@cisco.com 978 Pratik Bose 979 Lockheed Martin 980 22300 Comsat Drive Clarksburg, MD 20814 981 USA 982 Email: pratik.bose@lmco.com 984 Christou Christou 985 Booz Allen Hamilton 986 8283 Greensboro Drive 987 McLean, VA 22102 988 USA 989 Email: christou_chris@bah.com 991 Michael Davenport 992 Booz Allen Hamilton 993 8283 Greensboro Drive 994 McLean, VA 22102 995 USA 996 Email: davenport_michael@bah.com 998 IPR Statements 1000 The IETF takes no position regarding the validity or scope of any 1001 Intellectual Property Rights or other rights that might be claimed to 1002 pertain to the implementation or use of the technology described in 1003 this document or the extent to which any license under such rights 1004 might or might not be available; nor does it represent that it has 1005 made any independent effort to identify any such rights. Information 1006 on the procedures with respect to rights in RFC documents can be 1007 found in BCP 78 and BCP 79. 1009 Copies of IPR disclosures made to the IETF Secretariat and any 1010 assurances of licenses to be made available, or the result of an 1011 attempt made to obtain a general license or permission for the use of 1012 such proprietary rights by implementers or users of this 1013 specification can be obtained from the IETF on-line IPR repository at 1014 http://www.ietf.org/ipr. 1016 The IETF invites any interested party to bring to its attention any 1017 copyrights, patents or patent applications, or other proprietary 1018 rights that may cover technology that may be required to implement 1019 this standard. 1020 Please address the information to the IETF at ietf-ipr@ietf.org. 1022 Disclaimer of Validity 1024 This document and the information contained herein are provided on an 1025 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1026 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1027 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1028 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1029 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1030 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1032 Copyright Notice 1034 Copyright (C) The Internet Society (2006). This document is subject 1035 to the rights, licenses and restrictions contained in BCP 78, and 1036 except as set forth therein, the authors retain all their rights. 1038 Appendix A: Example Signaling Flow 1040 This Appendix does not provide additional specification. It only 1041 illustrates the specification detailed in section 4 through a 1042 possible flow of RSVP signaling messages. This flow assumes an 1043 environment where E2E reservations are aggregated over generic 1044 aggregate RSVP reservations. It illustrates a possible RSVP message 1045 flow that could take place in the successful establishment of a 1046 unicast E2E reservation which is the first between a given pair of 1047 Aggregator/Deaggregator. 1049 Aggregator Deaggregator 1051 E2E Path 1052 -----------> 1053 (1) 1054 E2E Path 1055 -------------------------------> 1056 (2) 1057 E2E PathErr(New-agg-needed,SOI=GAx) 1058 <---------------------------------- 1059 E2E PathErr(New-agg-needed,SOI=GAy) 1060 <---------------------------------- 1061 (3) 1062 AggPath(Session=GAx) 1063 -------------------------------> 1064 AggPath(Session=GAy) 1065 -------------------------------> 1066 (4) 1067 E2E Path 1068 -----------> 1069 (5) 1071 AggResv (Session=GAx) 1072 <------------------------------- 1073 AggResv (Session=GAy) 1074 <------------------------------- 1075 (6) 1076 AggResvConfirm (Session=GAx) 1077 ------------------------------> 1078 AggResvConfirm (Session=GAy) 1079 ------------------------------> 1080 (7) 1081 E2E Resv 1082 <--------- 1083 (8) 1084 E2E Resv (SOI=GAx) 1085 <----------------------------- 1086 (9) 1087 E2E Resv 1088 <----------- 1090 (1) The Aggregator forwards E2E Path into the aggregation region 1091 after modifying its IP Protocol Number to RSVP-E2E-IGNORE 1093 (2) Let's assume no Aggregate Path exists. To be able to accurately 1094 update the ADSPEC of the E2E Path, the Deaggregator needs the ADSPEC 1095 of Aggregate PATH. In this example the Deaggregator elects to 1096 instruct the Aggregator to set up Aggregate Path states for the two 1097 supported DSCPs. To do that, the Deaggregator sends two E2E PathErr 1098 messages with a New-Agg-Needed PathErr code. Both PathErr messages 1099 also contain a SESSION-OF-INTEREST (SOI) object. In the first E2E 1100 PathErr, the SOI contains a GENERIC-AGGREGATE SESSION (GAx) whose 1101 DSCP is set to x. In the second E2E PathErr, the SOI contains a 1102 GENERIC-AGGREGATE SESSION (GAy) whose DSCP is set to y. In both 1103 messages the GENERIC-AGGREGATE SESSION contains an interface- 1104 independent Deaggregator address inside the DestAddress and 1105 appropriate values inside the vDstPort and Extended vDstPort fields. 1107 (3) The Aggregator follows the request from the Deaggregator and 1108 signals an Aggregate Path for both GENERIC-AGGREGATE Sessions (GAx 1109 and GAy). 1111 (4) The Deaggregator takes into account the information contained in 1112 the ADSPEC from both Aggregate Path and updates the E2E Path ADSPEC 1113 accordingly. The Deaggregator also modifies the E2E Path IP Protocol 1114 Number to RSVP before forwarding it. 1116 (5) In this example, the Deaggregator elects to immediately proceed 1117 with establishment of generic aggregate reservations for both DSCPs. 1118 In effect, the Deaggregator can be seen as anticipating the actual 1119 demand of E2E reservations so that resources are available on 1120 the generic aggregate reservations when the E2E Resv requests arrive, 1121 in order to speed up establishment of E2E reservations. Assume 1122 also that the Deaggregator includes the optional Resv Confirm 1123 Request in these Aggregate Resv. 1125 (6) The Aggregator merely complies with the received ResvConfirm 1126 Request and returns the corresponding Aggregate ResvConfirm. 1128 (7) The Deaggregator has explicit confirmation that both Aggregate 1129 Resv are established. 1131 (8) On receipt of the E2E Resv, the Deaggregator applies the mapping 1132 policy defined by the network administrator to map the E2E Resv 1133 onto a generic aggregate reservation. Let's assume that this policy 1134 is such that the E2E reservation is to be mapped onto the generic 1135 aggregate reservation with DSCP=x. The Deaggregator knows that a 1136 generic aggregate reservation (GAx) is in place for the corresponding 1137 DSCP since (7). The Deaggregator performs admission control of the 1138 E2E Resv onto the generic aggregate Reservation for DSCP=x (GAx). 1139 Assuming that the generic aggregate reservation for DSCP=x (GAx) had 1140 been established with sufficient bandwidth to support the E2E Resv, 1141 the Deaggregator adjusts its counter, tracking the unused bandwidth 1142 on the generic aggregate reservation and forwards the E2E Resv to the 1143 Aggregator including a SESSION-OF-INTEREST object conveying the 1144 selected mapping onto GAx (and hence onto DSCP=x). 1146 (9) The Aggregator records the mapping of the E2E Resv onto GAx (and 1147 onto DSCP=x). The Aggregator removes the SOI object and forwards the 1148 E2E Resv towards the sender.