idnits 2.17.1 draft-ietf-tsvwg-rsvp-ipsec-03.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 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1153. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1127. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1143. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 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], [KEYWORDS]), 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 31 has weird spacing: '... and may be...' == Line 271 has weird spacing: '...rations are...' == 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 (September 2006) is 6433 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: 7 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Generic Aggregate RSVP Reservations September 2006 3 Internet Draft Francois Le Faucheur 4 Bruce Davie 5 Cisco Systems, Inc. 7 Pratik Bose 8 Lockheed Martin 10 Chris Christou 11 Michael Davenport 12 Booz Allen Hamilton 13 draft-ietf-tsvwg-rsvp-ipsec-03.txt 14 Expires: March 2007 September 2006 16 Generic Aggregate RSVP Reservations 17 draft-ietf-tsvwg-rsvp-ipsec-03.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 [RSVP-AGG] defines aggregate RSVP reservations allowing resources to 44 be reserved in a Diffserv network for a given DSCP from a given 45 source to a given destination. [RSVP-AGG] also defines how end-to-end 46 RSVP reservations can be aggregated onto such aggregate reservations 48 Generic Aggregate RSVP Reservations September 2006 50 when transiting through a Diffserv cloud. There are situations where 51 multiple such aggregate reservations are needed for the same source 52 IP address, destination IP address and DSCP. However, this is not 53 supported by the aggregate reservations defined in [RSVP-AGG]. In 54 order to support this, the present document defines a more flexible 55 type of aggregate RSVP reservations, referred to as generic aggregate 56 reservation. Multiple such generic aggregate reservations can be 57 established for a given DSCP from a given source IP address to a 58 given destination IP address. The generic aggregate reservations may 59 be used to aggregate end-to-end RSVP reservations. This document also 60 defines the procedures for such aggregation. The generic aggregate 61 reservations may also be used end-to-end directly by end-systems 62 attached to a Diffserv network. 64 Copyright Notice 65 Copyright (C) The Internet Society (2006). 67 Table Of Content 69 1. Introduction...................................................3 70 1.1. Related RFCs and Internet-Drafts..........................5 71 1.2. Organization Of This Document.............................6 72 2. Object Definition..............................................6 73 2.1. SESSION Class.............................................7 74 2.2. SESSION-OF-INTEREST (SOI) Class..........................10 75 3. Processing Rules For Handling Generic Aggregate RSVP Reservations 76 .................................................................12 77 3.1. Required Changes to Path and Resv Processing.............12 78 4. Procedures for Aggregation over Generic Aggregate RSVP 79 Reservations.....................................................13 80 5. Example Usage Of Multiple Generic Aggregate Reservations Per DSCP 81 From a Given Aggregator to a Given Deaggregator..................17 82 6. Security Considerations.......................................20 83 7. IANA Considerations...........................................20 84 8. Acknowledgments...............................................21 85 9. Normative References..........................................21 86 10. Informative References.......................................22 87 11. Authors' Addresses...........................................22 88 Appendix A: Example Signaling Flow...............................24 90 Specification of Requirements 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [KEYWORDS]. 96 Generic Aggregate RSVP Reservations September 2006 98 1. Introduction 100 [RSVP-AGG] defines RSVP aggregate reservations allowing resources to 101 be reserved in a Diffserv network for a flow characterized by its 3- 102 tuple . 104 [RSVP-AGG] also defines the procedures for aggregation of end-to-end 105 RSVP reservations onto such aggregate reservations when transiting 106 through a Diffserv cloud. Such aggregation is illustrated in Figure 1. 107 This document reuses the terminology defined in [RSVP-AGG]. 109 -------------------------- 110 / Aggregation \ 111 |----| | Region | |----| 112 H--| R |\ |-----| |------| /| R |-->H 113 H--| |\\| | |---| |---| | |//| |-->H 114 |----| \| | | I | | I | | |/ |----| 115 | Agg |======================>| Deag | 116 /| | | | | | | |\ 117 H--------//| | |---| |---| | |\\-------->H 118 H--------/ |-----| |------| \-------->H 119 | | 120 \ / 121 -------------------------- 123 H = Host requesting end-to-end RSVP reservations 124 R = RSVP router 125 Agg = Aggregator 126 Deag = Deaggregator 127 I = Interior Router 129 --> = E2E RSVP reservation 130 ==> = Aggregate RSVP reservation 132 Figure 1 : Aggregation of E2E Reservations 133 over aggregate RSVP Reservations 135 These aggregate reservations use a SESSION type specified in [RSVP- 136 AGG] that contains the receiver (or Deaggregator) IP address and the 137 DSCP of the PHB from which Diffserv resources are to be reserved. For 138 example, in the case of IPv4, the SESSION object is specified as: 140 o Class = SESSION, 141 C-Type = RSVP-AGGREGATE-IP4 143 Generic Aggregate RSVP Reservations September 2006 145 +-------------+-------------+-------------+-------------+ 146 | IPv4 Session Address (4 bytes) | 147 +-------------+-------------+-------------+-------------+ 148 | /////////// | Flags | ///////// | DSCP | 149 +-------------+-------------+-------------+-------------+ 151 These aggregate reservations use a SENDER_TEMPLATE and FILTER_SPEC 152 types specified in [RSVP-AGG] and which contains only the sender (or 153 Aggregator) IP address. For example, in the case of IPv4, the 154 SENDER_TEMPLATE object is specified as: 156 o Class = SENDER_TEMPLATE, 157 C-Type = RSVP-AGGREGATE-IP4 159 +-------------+-------------+-------------+-------------+ 160 | IPv4 Aggregator Address (4 bytes) | 161 +-------------+-------------+-------------+-------------+ 163 Thus, it is possible to establish, from a given source IP address to 164 a given destination IP address, separate such aggregate reservations 165 for different DSCPs. However, from a given source IP address to a 166 given IP destination address, only a single [RSVP-AGG] aggregate 167 reservation can be established for a given DSCP. 169 Situations have since been identified where multiple such aggregate 170 reservations are needed for the same source IP address, destination 171 IP address and DSCP. One example is where E2E reservations using 172 different preemption priorities (as per [RSVP-PREEMP]) need to be 173 aggregated through a Diffserv cloud using the same DSCP. Using 174 multiple aggregate reservations for the same DSCP allows enforcement 175 of the different preemption priorities within the aggregation region. 176 In turn this allows much more efficient management of the Diffserv 177 resources and in period of resource shortage allows to sustain a 178 larger number of E2E reservations with higher preemption priorities. 180 For example, [SIG-NESTED] discusses in details how end-to-end RSVP 181 reservations can be established in a nested VPN environment through 182 RSVP aggregation. In particular, [SIG-NESTED] describes how multiple 183 parallel generic aggregate reservations (for the same DSCP), each 184 with different preemption priorities, can be used to efficiently 185 support the preemption priorities of end-to-end reservations. 187 This document addresses this requirement for multiple aggregate 188 reservations for the same DSCP, by defining a more flexible type of 189 aggregate RSVP reservations, referred to as generic aggregate 190 reservations. This is achieved primarily by adding the notions of a 192 Generic Aggregate RSVP Reservations September 2006 194 Virtual Destination Port and of an Extended Virtual Destination Port 195 in the RSVP Session object. 197 The notion of Virtual Destination Port was introduced in [RSVP-IPSEC] 198 to address a similar requirement (albeit in a different context) for 199 identification and demultiplexing of sessions beyond the IP 200 destination address. This document reuses this notion from [RSVP- 201 IPSEC] for identification and demultiplexing of generic aggregate 202 sessions beyond the IP destination address and DSCP. This allows 203 multiple generic aggregate reservations to be established for a given 204 DSCP, from a given source IP address to a given destination IP 205 address. 207 [RSVP-TE] introduced the concept of an Extended Tunnel ID (in 208 addition to the tunnel egress address and the Tunnel ID) in the 209 Session object used to establish MPLS Traffic Engineering tunnels 210 with RSVP. The Extended Tunnel ID provides a very convenient 211 mechanism for the tunnel ingress node to narrow the scope of the 212 session to the ingress-egress pair. The ingress node can achieve this 213 by using one of its own IP addresses as a globally unique identifier 214 and including it in the Extended Tunnel ID and therefore within the 215 Session object. This document reuses this notion of Extended Tunnel 216 ID from [RSVP-TE], simply renaming it Extended Virtual Destination 217 Port. This provides a convenient mechanism to narrow the scope of a 218 generic aggregate session to an Aggregator-Deaggregator pair. 220 The generic aggregate reservations may be used to aggregate end-to- 221 end RSVP reservations. This document also defines the procedures for 222 such aggregation. These procedures are based on those of [RSVP-AGG] 223 and this document only specifies the differences with those. 225 The generic aggregate reservations may also be used end-to-end 226 directly by end-systems attached to a Diffserv network. 228 1.1. Related RFCs and Internet-Drafts 230 This document is heavily based on [RSVP-AGG]. It reuses [RSVP-AGG] 231 wherever applicable and only specifies the necessary extensions 232 beyond [RSVP-AGG]. 234 The mechanisms defined in [BW-REDUC] allow an existing reservation to 235 be reduced in allocated bandwidth by RSVP routers in lieu of tearing 236 that reservation down. These mechanisms are applicable to the generic 237 aggregate reservations defined in the present document. 239 [RSVP-TUNNEL] describes a general approach to running RSVP over 240 various types of tunnels. One of these types of tunnel, referred to 241 as a "type 2 tunnel", has some similarity with the generic aggregate 242 reservations described in this document. The similarity stems from 244 Generic Aggregate RSVP Reservations September 2006 246 the fact that a single, aggregate reservation is made for the tunnel 247 while many individual flows are carried over that tunnel. However, 248 [RSVP-TUNNEL] does not address the use of Diffserv-based 249 classification and scheduling in the core of a network (between 250 tunnel endpoints), but rather relies on a UDP/IP tunnel header for 251 classification. This is why [RSVP-AGG] required additional objects 252 and procedures beyond those of [RSVP-TUNNEL]. Like [RSVP-AGG], this 253 document also assumes the use of Diffserv-based classification and 254 scheduling in the aggregation region and, thus, requires additional 255 objects and procedures beyond those of [RSVP-TUNNEL]. 257 As explained earlier, this document reuses the notion of Virtual 258 Destination Port from [RSVP-IPSEC] and the notion of Extended Tunnel 259 ID from [RSVP-TE]. 261 1.2. Organization Of This Document 263 Section 2 defines the new RSVP objects related to generic aggregate 264 reservations and to aggregation of E2E reservations onto those. 265 Section 3 describes the processing rules for handling of generic 266 aggregate reservations. Section 4 specifies the procedures for 267 aggregation of end to end RSVP reservations over generic aggregate 268 RSVP reservations. Section 5 provides example usage of how the 269 generic aggregate reservations may be used. 271 The Security Considerations and the IANA Considerations are 272 discussed in Section 6 and 7, respectively. 274 Finally, Appendix 1 provides an example signaling flow is 275 illustrating aggregation of E2E RSVP reservations onto generic 276 aggregate RSVP reservations. 278 2. Object Definition 280 This document reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP- 281 AGGREGATE-IP6 FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE and 282 RSVP-AGGREGATE-IP6 SENDER_TEMPLATE objects defined in [RSVP-AGG]. 284 This document defines: 285 - two new objects (GENERIC-AGGREGATE-IP4 SESSION and GENERIC- 286 AGGREGATE-IP6 SESSION) under the existing SESSION Class, and 287 - two new objects (GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI) 288 under a new SESSION-OF-INTEREST Class. 290 Detailed description of these objects is provided below in this 291 section. 293 Generic Aggregate RSVP Reservations September 2006 295 The GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION 296 objects are applicable to all types of RSVP messages. 298 This specification only defines the use of the GENERIC-AGG-IP4-SOI 299 and GENERIC-AGG-IP6-SOI objects in two circumstances: 300 - inside an E2E PathErr message which contains an error code of 301 NEW-AGGREGATE-NEEDED in order to convey the session of a new 302 generic aggregate reservation which needs to be established 303 - inside an E2E Resv message in order to convey the session of 304 the generic aggregate reservation onto which this E2E 305 reservation needs to be mapped. 306 Details of the corresponding procedures can be found in section 4. 308 However, it is envisioned that the ability to signal, inside RSVP 309 messages, the Session of another reservation (which has some 310 relationship with the current RSVP reservation) might have some other 311 applicability in the future. Thus, those objects have been specified 312 in a more generic manner under a flexible SESSION-OF-INTEREST class. 314 All the new objects defined in this document are optional with 315 respect to RSVP so that general RSVP implementations not concerned 316 with generic aggregate reservations do not have to support these 317 objects. RSVP routers supporting generic aggregate IPv4 (respectively 318 IPv6) reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION 319 object (respectively GENERIC-AGGREGATE-IP6 SESSION). RSVP routers 320 supporting RSVP aggregation over generic aggregate IPv4 (respectively 321 IPv6) reservations MUST support the GENERIC-AGG-IP4-SOI object 322 (respectively GENERIC-AGG-IP6-SOI). 324 2.1. SESSION Class 326 o GENERIC-AGGREGATE-IP4 SESSION object: 327 Class = 1 (SESSION) 328 C-Type = To be allocated by IANA 330 0 7 8 15 16 23 24 31 331 +-------------+-------------+-------------+-------------+ 332 | IPv4 DestAddress (4 bytes) | 333 +-------------+-------------+-------------+--+----------+ 334 | Reserved | Flags | vDstPort |Rd| DSCP | 335 +-------------+-------------+-------------+--+----------+ 336 | Extended vDstPort | 337 +-------------+-------------+-------------+-------------+ 338 0 7 8 15 16 23 24 31 340 IPv4 DestAddress (IPv4 Destination Address) 342 IPv4 address of the receiver (or Deaggregator) 344 Generic Aggregate RSVP Reservations September 2006 346 Reserved 348 A 8-bit field. All bits MUST be set to 0 on transmit. This field 349 MUST be ignored on receipt. 351 Flags 353 A 8-bit field. The content and processing of this field are the 354 same as for the Flags field of the IPv4/UDP SESSION object (see 355 [RSVP]) 357 VDstPort (Virtual Destination Port) 359 An 8-bit identifier used in the SESSION that remains constant 360 over the life of the generic aggregate reservation. 362 Rd (Reserved) 364 A 2-bit field. All bits MUST be set to 0 on transmit. This field 365 MUST be ignored on receipt. 367 DSCP (Diffserv Code Point) 369 A 6-bit field containing the DSCP of the PHB from which Diffserv 370 resources are to be reserved. 372 Extended vDstPort (Extended Virtual Destination Port) 374 A 32-bit identifier used in the SESSION that remains constant 375 over the life of the generic aggregate reservation. 376 A sender (or Aggregator) that wishes to narrow the scope of a 377 SESSION to the sender-receiver pair (or Aggregator-Deaggregator 378 pair) SHOULD place its IPv4 address here as a network unique 379 identifier. A sender (or Aggregator) that wishes to use a common 380 session with other senders (or Aggregators) in order to use a 381 shared reservation across senders (or Aggregators) MUST set this 382 field to all zeros. 384 o GENERIC-AGGREGATE-IP6 SESSION object: 385 Class = 1 (SESSION) 386 C-Type = To be allocated by IANA 388 Generic Aggregate RSVP Reservations September 2006 390 0 7 8 15 16 23 24 31 391 +-------------+-------------+-------------+-------------+ 392 | | 393 + + 394 | | 395 + IPv6 DestAddress (16 bytes) + 396 | | 397 + + 398 | | 399 +-------------+-------------+-------------+--+----------+ 400 | Reserved | Flags | vDstPort |Rd| DSCP | 401 +-------------+-------------+-------------+--+----------+ 402 | | 403 + + 404 | Extended vDstPort | 405 + + 406 | (16 bytes) | 407 + + 408 | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 0 7 8 15 16 25 26 31 412 IPv6 DestAddress (IPv6 Destination Address) 414 IPv6 address of the receiver (or Deaggregator) 416 Reserved 418 A 8-bit field. All bits MUST be set to 0 on transmit. This field 419 MUST be ignored on receipt. 421 Flags 423 A 8-bit field. The content and processing of this field are the 424 same as for the Flags field of the IPv6/UDP SESSION object (see 425 [RSVP]) 427 VDstPort (Virtual Destination Port) 429 A 8-bit identifier used in the SESSION that remains constant 430 over the life of the generic aggregate reservation. 432 Rd (Reserved) 434 Generic Aggregate RSVP Reservations September 2006 436 A 2-bit field. All bits MUST be set to 0 on transmit. This field 437 MUST be ignored on receipt. 439 DSCP (Diffserv Code Point) 441 A 6-bit field containing the DSCP of the PHB from which Diffserv 442 resources are to be reserved 444 Extended vDstPort (Extended Virtual Destination Port) 446 A 128-bit identifier used in the SESSION that remains constant 447 over the life of the generic aggregate reservation. 448 A sender (or Aggregator) that wishes to narrow the scope of a 449 SESSION to the sender-receiver pair (or Aggregator-Deaggregator 450 pair) SHOULD place its IPv6 address here as a network unique 451 identifier. A sender (or Aggregator) that wishes to use a common 452 session with other senders (or Aggregators) in order to use a 453 shared reservation across senders (or Aggregators) MUST set this 454 field to all zeros. 456 2.2. SESSION-OF-INTEREST (SOI) Class 458 o GENERIC-AGG-IP4-SOI object: 459 Class = To be allocated by IANA 460 C-Type = To be allocated by IANA 462 0 7 8 15 16 23 24 31 463 +-------------+-------------+-------------+-------------+ 464 | | SOI |GEN-AGG-IP4- | 465 | Length (bytes) | Class-Num |SOI C-Type | 466 +-------------+-------------+-------------+-------------+ 467 | | 468 // Content of a GENERIC-AGGREGATE-IP4 SESSION Object // 469 | | 470 +-------------+-------------+-------------+-------------+ 472 Content of a GENERIC-AGGREGATE-IP4 SESSION Object: 474 This field contains a copy of the Session object of the session 475 which is of interest for the reservation. In the case of a 476 GENERIC-AGG-IP4-SOI, the session of interest conveyed in this 477 field is a GENERIC-AGGREGATE-IP4 SESSION. 479 o GENERIC-AGG-IP6-SOI object: 481 Generic Aggregate RSVP Reservations September 2006 483 Class = To be allocated by IANA 484 (same as for GENERIC-AGG-IP4-SOI) 485 C-Type = To be allocated by IANA 487 0 7 8 15 16 23 24 31 488 +-------------+-------------+-------------+-------------+ 489 | | SOI |GEN-AGG-IP6- | 490 | Length (bytes) | Class-Num |SOI C-Type | 491 +-------------+-------------+-------------+-------------+ 492 | | 493 // Content of a GENERIC-AGGREGATE-IP6 SESSION Object // 494 | | 495 +-------------+-------------+-------------+-------------+ 497 Content of a GENERIC-AGGREGATE-IP6 SESSION Object: 499 This field contains a copy of the Session object of the session 500 which is of interest for the reservation. In the case of a 501 GENERIC-AGG-IP6-SOI, the session of interest conveyed in this 502 field is a GENERIC-AGGREGATE-IP6 SESSION. 504 For example, if a SESSION-OF-INTEREST object is used inside an E2E 505 Resv message (as per the procedures defined in section 4) to indicate 506 which generic aggregate IPv4 session the E2E reservation is to be 507 mapped onto, then the GENERIC-AGG-IP4-SOI object will be used and it 508 will be encoded like this: 510 0 7 8 15 16 23 24 31 511 +-------------+-------------+-------------+-------------+ 512 | | SOI |GEN-AGG-IP4- | 513 | Length (bytes) | Class-Num |SOI C-Type | 514 +-------------+-------------+-------------+-------------+ 515 | IPv4 DestAddress (4 bytes) | 516 +-------------+-------------+-------------+--+----------+ 517 | Reserved | Flags | vDstPort |Rd| DSCP | 518 +-------------+-------------+-------------+--+----------+ 519 | Extended vDstPort | 520 +-------------+-------------+-------------+-------------+ 521 0 7 8 15 16 23 24 31 523 Note that a SESSION-OF-INTEREST object is not a SESSION object in 524 itself. It does not replace the SESSION object in RSVP messages. It 525 does not modify the usage of the SESSION object in RSVP messages. It 526 simply allows conveying the Session of another RSVP reservation 527 inside RSVP signaling messages, for some particular purposes. In the 528 context of this document, it is used to convey, inside an E2E RSVP 529 message pertaining to an end-to-end reservation, the Session of a 531 Generic Aggregate RSVP Reservations September 2006 533 generic aggregate reservation associated with the E2E reservation. 534 Details for the corresponding procedures are specified in section 4. 536 3. Processing Rules For Handling Generic Aggregate RSVP Reservations 538 This section presents additions to the Processing Rules presented in 539 [RSVP-PROCESS]. These additions are required in order to properly 540 process the GENERIC-AGGREGATE-IP4 (resp. GENERIC-AGGREGATE-IP6) 541 SESSION object and the RSVP-AGGREGATE-IP4 (resp. RSVP-AGGREGATE-IP6) 542 FILTER_SPEC object. Values for referenced error codes can be found in 543 [RSVP]. As with the other RSVP documents, values for internally 544 reported (API) errors are not defined. 546 When referring to the new GENERIC-AGGREGATE-IP4 and GENERIC- 547 AGGREGATE-IP6 SESSION objects, IP version will not be included and 548 they will be referred to simply as GENERIC-AGGREGATE SESSION, unless 549 a specific distinction between IPv4 and IPv6 is being made. 551 When referring to the [RSVP-AGG] RSVP-AGGREGATE-IP4 and 552 RSVP-AGGREGATE-IP6 SESSION, FILTER_SPEC and SENDER_TEMPLATE objects, 553 IP version will not be included and they will be referred to simply 554 as RSVP-AGGREGATE, unless a specific distinction between IPv4 and 555 IPv6 is being made. 557 3.1. Required Changes to Path and Resv Processing 559 Both RESV and PATH processing will need to be changed to support the 560 new objects. 562 The following PATH message processing changes are required: 564 o When a session is defined using the GENERIC-AGGREGATE SESSION 565 object, only the [RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATE may 566 be used. When this condition is violated in a PATH message 567 received by an RSVP end-station, the RSVP end-station SHOULD 568 report a "Conflicting C-Type" API error to the application. 569 When this condition is violated in a PATH message received by 570 an RSVP router, the RSVP router MUST consider this as a 571 message formatting error. 573 o For PATH messages that contain the GENERIC-AGGREGATE SESSION 574 object, the VDstPort value, the Extended VDstPort value and 575 the DSCP value should be recorded (in addition to the 576 destination/Deaggregator address and source/aggregator 577 address). These values form part of the recorded state of the 578 session. The DSCP may need to be passed to traffic control; 579 however the vDstPort and Extended VDstPort are not passed to 581 Generic Aggregate RSVP Reservations September 2006 583 traffic control since they do not appear inside the data 584 packets of the corresponding reservation. 586 The changes to RESV message processing are: 588 o When a RESV message contains a [RSVP-AGG] RSVP-AGGREGATE 589 FILTER_SPEC, the session MUST be defined using either the 590 RSVP-AGGREGATE SESSION object (as per [RSVP-AGG]) or the 591 GENERIC-AGGREGATE SESSION object (as per this document). If 592 this condition is not met, an RSVP router or end-station MUST 593 consider that there is a message formatting error. 595 o When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION 596 type is GENERIC-AGGREGATE, each node MAY have a data 597 classifier installed for the flow: 599 * If the node needs to perform fine-grain classification (for 600 example to perform fine-grain policing on ingress at a trust 601 boundary) then the node MUST create a data classifier 602 described by the 3-tuple . 604 Note that if multiple reservations are established with 605 different Virtual Destination Ports (and/or different 606 Extended Virtual Destination Ports) but with the same 607 , then those cannot be 608 distinguished by the classifier. If the router is using the 609 classifier for policing purposes, the router will therefore 610 police those together and MUST program the policing rate to 611 the sum of the reserved rate across all the corresponding 612 reservations. 614 * If the node only needs to perform Diffserv classification 615 (for example inside the aggregation domain downstream of the 616 trust boundary) then the node MUST rely on the Diffserv data 617 classifier based on the DSCP only. 619 4. Procedures for Aggregation over Generic Aggregate RSVP Reservations 621 The procedures for aggregation of E2E reservations over generic 622 aggregate RSVP reservations are the same as the procedures specified 623 in [RSVP-AGG] with the exceptions of the procedure changes listed in 624 this section. 626 As specified in [RSVP-AGG], the Deaggregator is responsible for 627 mapping a given E2E reservation on a given aggregate reservation. The 628 Deaggregator requests establishment of a new aggregate reservation by 629 sending to the Aggregator an E2E PathErr message with an error code 630 of NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the Deaggregator conveys the 632 Generic Aggregate RSVP Reservations September 2006 634 DSCP of the new requested aggregate reservation by including a DCLASS 635 Object in the E2E PathErr and encoding the corresponding DSCP inside. 636 This document modifies and extends this procedure. The Deaggregator 637 MUST include in the E2E PathErr message, a SESSION-OF-INTEREST object 638 which contains the GENERIC-AGGREGATE Session to be used for 639 establishment of the requested generic aggregate reservation. Since 640 this GENERIC-AGGREGATE SESSION contains the DSCP, the DCLASS object 641 need not be included in the PathErr message. 643 Note that the Deaggregator can easily ensure that different 644 Aggregators use different sessions for their Aggregate Path towards a 645 given Deaggregator. This is because the Deaggregator can easily 646 select VDstPort and/or Extended VDstPort numbers which are different 647 for each Aggregator (for example by using the Aggregator address as 648 the Extended VDstPort) and can communicate those inside the GENERIC- 649 AGGREGATE SESSION included in the SESSION-OF-INTEREST object. This 650 provides an easy solution to establish separate reservations from 651 every Aggregator to a given Deaggregator. Conversely, if reservation 652 sharing were needed across multiple Aggregators, the Deaggregator 653 could facilitate this by allocating the same VDstPort and Extended 654 VDstPort to the multiple Aggregators and thus including the same 655 GENERIC-AGGREGATE SESSION inside the SESSION-OF-INTEREST object in 656 the E2E PathErr messages sent to these Aggregators. The Aggregators 657 could then all establish an Aggregate Path with the same GENERIC- 658 AGGREGATE SESSION. 660 Therefore various sharing scenarios can easily be supported. Policies 661 followed by the Deaggregator to determine which aggregators need 662 shared or separate reservations are beyond the scope of this document. 664 The Deaggregator MAY also include in the E2E PathErr message (with an 665 error code of NEW-AGGREGATE-NEEDED) additional RSVP objects which are 666 to be used for establishment of the new needed generic aggregate 667 reservation. For example, the Deaggregator MAY include in the E2E 668 PathErr an RSVP Signaled Preemption Priority Policy Element (as 669 specified in [RSVP-PREEMP]). 671 The [RSVP-AGG] procedures for processing of an E2E PathErr message 672 received with an error code of NEW-AGGREGATE-NEEDED by the Aggregator 673 are extended correspondingly. On receipt of such a message containing 674 a SESSION-OF-INTEREST object, the Aggregator MUST trigger 675 establishment of a generic aggregate reservation. In particular, it 676 MUST start sending aggregate Path messages with the GENERIC-AGGREGATE 677 SESSION found in the received SESSION-OF-INTEREST object. When an 678 RSVP Signaled Preemption Priority Policy Element is contained in the 679 received E2E PathErr message, the Aggregator MUST include this object 680 in the Aggregate Path for the corresponding generic aggregate 681 reservation. When other additional objects are contained in the 682 received E2E PathErr message and those can be unambiguously 684 Generic Aggregate RSVP Reservations September 2006 686 interpreted as related to the new needed generic aggregate 687 reservation (as opposed to related to the E2E reservation), the 688 Aggregator SHOULD include those in the Aggregate Path for the 689 corresponding generic aggregate reservation. The Aggregator MUST use 690 as the Source Address (i.e. as the Aggregator Address in the Sender- 691 Template) for the generic aggregate reservation, the address it uses 692 to identify itself as the PHOP when forwarding the E2E Path messages 693 corresponding to the E2E PathErr message. 695 The Deaggregator follows the same procedures as described in [RSVP- 696 AGG] for establishing, maintaining and clearing the aggregate Resv 697 state. However, in this document, the Deaggregator MUST use the 698 generic aggregate reservations and hence use the GENERIC-AGGREGATE 699 SESSION specified earlier in this document. 701 This document also modifies the procedures of [RSVP-AGG] related to 702 exchange of E2E Resv messages between Deaggregator and Aggregator. 703 The Deaggregator MUST include the new SESSION-OF-INTEREST object in 704 the E2E Resv message, in order to indicate to the Aggregator the 705 generic aggregate session to map a given E2E reservation onto. Again, 706 since the GENERIC-AGGREGATE SESSION (included in the SESSION-OF- 707 INTEREST object) contains the DSCP, the DCLASS object need not be 708 included in the E2E Resv message. The Aggregator MUST interpret the 709 SESSION-OF-INTEREST object in the E2E Resv as indicating which 710 generic aggregate reservation session the corresponding E2E 711 reservation is mapped onto. The Aggregator MUST not include the 712 SESSION-OF-INTEREST object when sending an E2E Resv upstream towards 713 the sender. 715 Based on relevant policy, the Deaggregator may decide at some point 716 that an aggregate reservation is no longer needed and should be torn 717 down. In that case, the Deaggregator MUST send an aggregate ResvTear. 718 On receipt of the aggregate ResvTear, the Aggregator SHOULD send an 719 aggregate PathTear (unless the relevant policy instructs the 720 aggregator to do otherwise or to wait for some time before doing so, 721 for example in order to speed-up potential re-establishment of the 722 aggregate reservation in the future). 724 [RSVP-AGG] describes how the Aggregator and Deaggregator can 725 communicate their respective identity to each other. For example the 726 Aggregator includes one of its IP addresses in the RSVP HOP object in 727 the E2E Path which is transmitted downstream and received by the 728 Deaggregator once it traversed the aggregation region. Similarly, the 729 Deaggregator identifies itself to the Aggregator by including one of 730 its IP addresses in various fields, including the ERROR SPECIFICATION 731 of the E2E PathErr message (containing the NEW-AGGREGATE-NEEDED Error 732 Code) and in the RSVP HOP object of the E2E Resv message. However, 733 [RSVP-AGG] does not discuss which IP addresses are to be selected by 734 the aggregator and Deaggregator for such purposes. Because these 736 Generic Aggregate RSVP Reservations September 2006 738 addresses are intended to identify the Aggregator and Deaggregator 739 and not to identify any specific interface on these devices, this 740 document RECOMMENDS that the Aggregator and Deaggregator SHOULD use 741 interface-independent addresses (for example a loopback address) 742 whenever they communicate their respective identity to each other. 743 This ensures that respective identification of the Aggregator and 744 Deaggregator is not impacted by any interface state change on these 745 devices. In turns this results in more stable operations and 746 considerably reduced RSVP signaling in the aggregation region. For 747 example, if interface-independent addresses are used by the 748 Aggregator and the Deaggregator, then a failure of an interface on 749 these devices may simply result in the rerouting of a given generic 750 aggregate reservation but will not result in the generic aggregate 751 reservation having to be torn down and another one established, nor 752 will it result in a change of mapping of E2E reservations on generic 753 aggregate reservations (assuming the Aggregator and Deaggregator 754 still have reachability after the failure and the Aggregator and 755 Deaggregator are still on the shortest path to the destination). 757 However, when identifying themselves to real RSVP neighbors (i.e. 758 neighbors which are not on the other side of the aggregation region), 759 the Aggregator and Deaggregator SHOULD continue using interface- 760 dependent addresses as per regular [RSVP] procedures. This applies 761 for example when the Aggregator identifies itself downstream as a 762 PHOP for the generic aggregate reservation or identifies itself 763 upstream as a NHOP for an E2E reservation. This also applies when the 764 Deaggregator identifies itself downstream as a PHOP for the E2E 765 reservation or identifies itself upstream as a NHOP for the generic 766 aggregate reservation. As part of the processing of generic aggregate 767 reservations, interior routers (i.e. routers within the aggregation 768 region) SHOULD continue using interface-dependent addresses as per 769 regular [RSVP] procedures. 771 More generally, within the aggregation region (ie between Aggregator 772 and Deaggregator) the operation of RSVP should be modeled with the 773 notion that E2E reservations are mapped to aggregate reservations and 774 are no longer tied to physical interfaces (as was the case with 775 regular RSVP). However, generic aggregate reservations (within the 776 aggregation region) as well as E2E reservations outside the 777 aggregation region, retain the model of regular RVSP and remain tied 778 to physical interfaces. 780 As discussed above, generic aggregate reservations may be established 781 edge-to-edge as a result of the establishment of E2E reservations 782 (from outside the aggregation region) which are to be aggregated over 783 the aggregation region. However, generic aggregate reservations may 784 also be used end-to-end by end-systems directly attached to a 785 Diffserv domain, such as PSTN Gateways. In that case, the generic 786 aggregate reservations may be established by the end-systems in 788 Generic Aggregate RSVP Reservations September 2006 790 response to application-level triggers such as voice call signaling. 791 Alternatively, generic aggregate reservations may also be used edge- 792 to-edge to manage bandwidth in a Diffserv cloud even if RSVP is not 793 used end-to-end. A simple example of such a usage would be the static 794 configuration of a generic aggregate reservation for a certain 795 bandwidth for traffic from an ingress (Aggregator) router to an 796 egress (Deaggregator) router. 798 In this case, the establishment of the generic aggregate reservations 799 is controlled by configuration on the Aggregator and on the 800 Deaggregator. Configuration on the Aggregator triggers generation of 801 the aggregate Path message and provides sufficient information to the 802 Aggregator to derive the content of the GENERIC-AGGREGATE SESSION 803 object. This would typically include Deaggregator IP address, DSCP 804 and possibly VDstPort. Configuration on the Deaggregator would 805 instruct the Deaggregator to respond to a received generic aggregate 806 Path message and would provide sufficient information to the 807 Deaggregator to control the reservation. This may include bandwidth 808 to be reserved by the Deaggregator (for a given 809 Deaggregator/DSCP/VDstPort tuple). 811 In the absence of E2E microflow reservations, the Aggregator can use 812 a variety of policies to set the DSCP of packets passing into the 813 aggregation region and how they are mapped onto generic aggregate 814 reservations, thus determining whether they gain access to the 815 resources reserved by the aggregate reservation. These policies are a 816 matter of local configuration, as usual for a device at the edge of a 817 Diffserv cloud. 819 5. Example Usage Of Multiple Generic Aggregate Reservations Per DSCP 820 From a Given Aggregator to a Given Deaggregator 822 Let us consider the environment depicted in Figure 2 below. RSVP 823 aggregation is used to support E2E reservations between Cloud-1, 824 Cloud-2 and Cloud-3. 826 I----------I I----------I 827 I Cloud-1 I I Cloud-2 I 828 I----------I I----------I 829 | | 830 Agg-Deag-1------------ Agg-Deag-2 831 / \ 832 / Aggregation | 833 | Region | 834 | | 835 | ---/ 836 \ / 838 Generic Aggregate RSVP Reservations September 2006 840 \Agg-Deag-3---------/ 841 | 842 I----------I 843 I Cloud-3 I 844 I----------I 846 Figure 2 : Example Usage of 847 Generic Aggregate IP Reservations 849 Let us assume that: 851 o the E2E reservations from Cloud-1 to Cloud-3 have a preemption 852 of either P1 or P2 854 o the E2E reservations from Cloud-2 to Cloud-3 have a preemption 855 of either P1 or P2 857 o the E2E reservations are only for Voice (which needs to be 858 treated in the aggregation region using the EF PHB) 860 o traffic from the E2E reservations is encapsulated in Aggregate 861 IP reservations from Aggregator to Deaggregator using GRE 862 tunneling ([GRE]). 864 Then, the following generic aggregate RSVP reservations may be 865 established from Agg-Deag-1 to Agg-Deag-3 for aggregation of the end- 866 to-end RSVP reservations: 868 A first generic aggregate reservation for aggregation of Voice 869 reservations from Cloud-1 to Cloud-3 requiring use of P1: 871 * GENERIC-AGGREGATE-IP4 SESSION: 872 IPv4 DestAddress= Agg-Deag-3 873 vDstPort=V1 874 DSCP=EF 875 Extended VDstPort= Agg-Deag-1 877 * STYLE=FF or SE 879 * IPv4/GPI FILTER_SPEC: 880 IPv4 SrcAddress= Agg-Deag-1 882 * POLICY_DATA (PREEMPTION_PRI)=P1 884 A second generic aggregate reservation for aggregation of Voice 885 reservations from Cloud-1 to Cloud-3 requiring use of P2: 887 * GENERIC-AGGREGATE-IP4 SESSION: 889 Generic Aggregate RSVP Reservations September 2006 891 IPv4 DestAddress= Agg-Deag-3 892 vDstPort=V2 893 DSCP=EF 894 Extended VDstPort= Agg-Deag-1 896 * STYLE=FF or SE 898 * IPv4/GPI FILTER_SPEC: 899 IPv4 SrcAddress= Agg-Deag-1 901 * POLICY_DATA (PREEMPTION_PRI)=P2 903 where V1 and V2 are arbitrary VDstPort values picked by Agg-Deag-3. 905 The following generic aggregate RSVP reservations may be established 906 from Agg-Deag-2 to Agg-Deag-3 for aggregation of the end-to-end RSVP 907 reservations: 909 A third generic aggregate reservation for aggregation of Voice 910 reservations from Cloud-2 to Cloud-3 requiring use of P1: 912 * GENERIC-AGGREGATE-IP4 SESSION: 913 IPv4 DestAddress= Agg-Deag-3 914 vDstPort=V3 915 DSCP=EF 916 Extended VDstPort= Agg-Deag-2 918 * STYLE=FF or SE 920 * IPv4/GPI FILTER_SPEC: 921 IPv4 SrcAddress= Agg-Deag-2 923 * POLICY_DATA (PREEMPTION_PRI)=P1 925 A fourth generic aggregate reservation for aggregation of Voice 926 reservations from Cloud-2 to Cloud-3 requiring use of P2: 928 * GENERIC-AGGREGATE-IP4 SESSION: 929 IPv4 DestAddress= Agg-Deag-3 930 vDstPort=V4 931 DSCP=EF 932 Extended VDstPort= Agg-Deag-2 934 * STYLE=FF or SE 936 * IPv4/GPI FILTER_SPEC: 937 IPv4 SrcAddress= Agg-Deag-2 939 * POLICY_DATA (PREEMPTION_PRI)=P2 941 Generic Aggregate RSVP Reservations September 2006 943 where V1 and V4 are arbitrary VDstPort values picked by Agg-Deag-3. 945 Note that V3 and V4 could be equal to (respectively) V1 and V2 since, 946 in this example, the Extended VDstPort of the GENERIC-AGGREGATE 947 Session contains the address of the Deaggregator and, thus, ensures 948 that different sessions are used for each Deaggregator. 950 6. Security Considerations 952 In the environments concerned by this document, RSVP messages are 953 used to control resource reservations for generic aggregate 954 reservations and may be used to control resource reservations for E2E 955 reservations being aggregated over the generic aggregate reservations. 956 To ensure the integrity of the associated reservation and admission 957 control mechanisms, the mechanisms defined in [RSVP-CRYPTO1] and 958 [RSVP-CRYPTO2] can be used. Those protect RSVP messages integrity 959 hop-by-hop and provide node authentication, thereby protecting 960 against corruption and spoofing of RSVP messages. These hop-by-hop 961 integrity mechanisms can naturally be used to protect the RSVP 962 messages used for generic aggregate reservations, to protect RSVP 963 messages used for E2E reservations outside the aggregation region, or 964 for both. These hop-by-hop RSVP integrity mechanisms can also be used 965 to protect RSVP messages used for E2E reservations when those transit 966 through the aggregation region. This is because the Aggregator and 967 Deaggregator behave as RSVP neighbors from the viewpoint of the E2E 968 flows (even if they are not necessarily IP neighbors nor RSVP-TE 969 neighbors). It that case, the Aggregator and Deaggregator need to use 970 a pre-shared secret. Where the dynamic Deaggregator determination 971 procedure defined in [RSVP-AGG] are used, the Aggregator does not 972 know ahead of time which router is going to act as the Deaggregator. 973 Thus, use of the mechanisms of [RSVP-CRYPTO1] and [RSVP-CRYPTO2] for 974 protection of RSVP E2E messages (e.g. E2E Path) while they transit 975 through the aggregation region may require the use of a secret pre- 976 shared across the Aggregator and all Deaggregators. 978 When generic aggregate reservations are used for aggregation of E2E 979 reservations, the security considerations discussed in [RSVP-AGG] 980 apply. 982 The security considerations discussed in [SIG-NESTED] apply when the 983 generic aggregate reservations are used in the presence of IPsec 984 gateways. 986 7. IANA Considerations 988 Generic Aggregate RSVP Reservations September 2006 990 This document requests that IANA allocates two new C-Types under the 991 existing SESSION Class (Class 1) for the two new RSVP objects 992 defined in section 2.1: GENERIC-AGGREGATE-IP4 SESSION and GENERIC- 993 AGGREGATE-IP6 SESSION. This allocation is in accordance with [RSVP- 994 MOD] which defines the default assignment policy as Standards Action 995 for new Class-Type values under an existing class. 997 This document also requests that IANA allocates one new Class-Num for 998 the SESSION-OF-INTEREST class, and two new C-Types for the two new 999 RSVP objects under that class defined in section 2.2: GENERIC-AGG- 1000 IP4-SOI and GENERIC-AGG-IP6-SOI. The Class-Num for the SESSION-OF- 1001 INTEREST class is to be allocated in the range from 128 to 183 1002 defined in [RSVP-MOD] as to be assigned by Standards Action. In 1003 accordance with [RSVP-MOD], the Class-Type values under the SESSION- 1004 OF-INTEREST class are to be allocated according to the following 1005 policy: 1006 o C-Type values from 0 through 127 are to be assigned by Standards 1007 Action 1008 o C-Type values from 128 through 191 are to be assigned by Expert 1009 Review 1010 o C-Type values from 192 through 255 are reserved for Vendor 1011 Private use 1012 o C-Type value 1 is to be allocated to the GENERIC-AGG-IP4-SOI 1013 object defined in this document 1014 o C-Type value 2 is to be allocated to the GENERIC-AGG-IP6-SOI 1015 object defined in this document. 1017 8. Acknowledgments 1019 This document borrows heavily from [RSVP-AGG]. It also borrows the 1020 concepts of Virtual Destination Port and Extended Virtual Destination 1021 Port respectively from [RSVP-IPSEC] and [RSVP-TE]. 1023 Also, we thank Fred Baker, Roger Levesque, Carol Iturralde, Daniel 1024 Voce, Anil Agarwal, Alexander Sayenko and Anca Zamfir for their input 1025 into the content of this document. Thanks to Steve Kent for 1026 insightful comments on usage of RSVP reservations in IPsec 1027 environments. 1029 9. Normative References 1031 [KEYWORDS] "Key words for use in RFCs to Indicate Requirement Levels", 1032 Bradner, RFC2119 1034 [RSVP] "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1035 Specification", Braden et al, RFC2205 1037 Generic Aggregate RSVP Reservations September 2006 1039 [RSVP-AGG] "Aggregation of RSVP for IPv4 and IPv6 Reservations", 1040 Baker et al, RFC3175 1042 [RSVP-CRYPTO1] Baker at al, RSVP Cryptographic Authentication, RFC 1043 2747, January 2000. 1045 [RSVP-CRYPTO2] Braden and Zhang, RSVP Cryptographic Authentication - 1046 Updated Message Type Value, RFC 3097, April 2001. 1048 [RSVP-IPSEC] "RSVP Extensions for IPsec Data Flows", Berger et al, 1049 RFC2207 1051 [RSVP-PROCESS] "Resource ReSerVation Protocol (RSVP) -- Version 1 1052 Message Processing Rules", Braden et al, RFC2209 1054 [RSVP-MOD] "Procedures for Modifying the Resource reSerVation 1055 Protocol (RSVP)", Kompella and Lang, RFC 3936, BCP 96 1057 10. Informative References 1059 [BW-REDUC] "A Resource Reservation Extension for the Reduction of 1060 andwidth of a Reservation Flow", Polk et al, RFC 4495 1062 [GRE] "Generic Routing Encapsulation (GRE) ", Farinacci et al, RFC 1063 2784 1065 [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy 1066 Element", RFC 3181, October 2001. 1068 [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, 1069 RFC 3209, December 2001. 1071 [RSVP-TUNNEL] "RSVP Operation Over IP Tunnels", Terzis et al., RFC 1072 2746, January 2000. 1074 [SIG-NESTED] "QoS Signaling in a Nested Virtual Private Network", 1075 Baker et al, draft-ietf-tsvwg-vpn-signaled-preemption, work in 1076 progress 1078 11. Authors' Addresses 1080 Francois Le Faucheur 1081 Cisco Systems, Inc. 1082 Village d'Entreprise Green Side - Batiment T3 1083 400, Avenue de Roumanille 1084 06410 Biot Sophia-Antipolis 1086 Generic Aggregate RSVP Reservations September 2006 1088 France 1089 Email: flefauch@cisco.com 1091 Bruce Davie 1092 Cisco Systems, Inc. 1093 300 Beaver Brook Road 1094 Boxborough, MA 01719 1095 USA 1096 Email: bdavie@cisco.com 1098 Pratik Bose 1099 Lockheed Martin 1100 22300 Comsat Drive Clarksburg, MD 20814 1101 USA 1102 Email: pratik.bose@lmco.com 1104 Christou Christou 1105 Booz Allen Hamilton 1106 8283 Greensboro Drive 1107 McLean, VA 22102 1108 USA 1109 Email: christou_chris@bah.com 1111 Michael Davenport 1112 Booz Allen Hamilton 1113 8283 Greensboro Drive 1114 McLean, VA 22102 1115 USA 1116 Email: davenport_michael@bah.com 1118 IPR Statements 1120 The IETF takes no position regarding the validity or scope of any 1121 Intellectual Property Rights or other rights that might be claimed to 1122 pertain to the implementation or use of the technology described in 1123 this document or the extent to which any license under such rights 1124 might or might not be available; nor does it represent that it has 1125 made any independent effort to identify any such rights. Information 1126 on the procedures with respect to rights in RFC documents can be 1127 found in BCP 78 and BCP 79. 1129 Copies of IPR disclosures made to the IETF Secretariat and any 1130 assurances of licenses to be made available, or the result of an 1131 attempt made to obtain a general license or permission for the use of 1133 Generic Aggregate RSVP Reservations September 2006 1135 such proprietary rights by implementers or users of this 1136 specification can be obtained from the IETF on-line IPR repository at 1137 http://www.ietf.org/ipr. 1139 The IETF invites any interested party to bring to its attention any 1140 copyrights, patents or patent applications, or other proprietary 1141 rights that may cover technology that may be required to implement 1142 this standard. 1143 Please address the information to the IETF at ietf-ipr@ietf.org. 1145 Disclaimer of Validity 1147 This document and the information contained herein are provided on an 1148 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1149 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1150 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1151 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1152 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1153 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1155 Copyright Notice 1157 Copyright (C) The Internet Society (2006). This document is subject 1158 to the rights, licenses and restrictions contained in BCP 78, and 1159 except as set forth therein, the authors retain all their rights. 1161 Appendix A: Example Signaling Flow 1163 This Appendix does not provide additional specification. It only 1164 illustrates the specification detailed in section 4 through a 1165 possible flow of RSVP signaling messages. This flow assumes an 1166 environment where E2E reservations are aggregated over generic 1167 aggregate RSVP reservations. It illustrates a possible RSVP message 1168 flow that could take place in the successful establishment of a 1169 unicast E2E reservation which is the first between a given pair of 1170 Aggregator/Deaggregator. 1172 Aggregator Deaggregator 1174 E2E Path 1175 -----------> 1176 (1) 1177 E2E Path 1179 Generic Aggregate RSVP Reservations September 2006 1181 -------------------------------> 1182 (2) 1183 E2E PathErr(New-agg-needed,SOI=GAx) 1184 <---------------------------------- 1185 E2E PathErr(New-agg-needed,SOI=GAy) 1186 <---------------------------------- 1187 (3) 1188 AggPath(Session=GAx) 1189 -------------------------------> 1190 AggPath(Session=GAy) 1191 -------------------------------> 1192 (4) 1193 E2E Path 1194 -----------> 1195 (5) 1196 AggResv (Session=GAx) 1197 <------------------------------- 1198 AggResv (Session=GAy) 1199 <------------------------------- 1200 (6) 1201 AggResvConfirm (Session=GAx) 1202 ------------------------------> 1203 AggResvConfirm (Session=GAy) 1204 ------------------------------> 1205 (7) 1206 E2E Resv 1207 <--------- 1208 (8) 1209 E2E Resv (SOI=GAx) 1210 <----------------------------- 1211 (9) 1212 E2E Resv 1213 <----------- 1215 (1) The Aggregator forwards E2E Path into the aggregation region 1216 after modifying its IP Protocol Number to RSVP-E2E-IGNORE 1218 (2) Let's assume no Aggregate Path exists. To be able to accurately 1219 update the ADSPEC of the E2E Path, the Deaggregator needs the ADSPEC 1220 of Aggregate PATH. In this example the Deaggregator elects to 1221 instruct the Aggregator to set up Aggregate Path states for the two 1222 supported DSCPs. To do that, the Deaggregator sends two E2E PathErr 1223 messages with a New-Agg-Needed PathErr code. Both PathErr messages 1224 also contain a SESSION-OF-INTEREST (SOI) object. In the first E2E 1225 PathErr, the SOI contains a GENERIC-AGGREGATE SESSION (GAx) whose 1226 DSCP is set to x. In the second E2E PathErr, the SOI contains a 1227 GENERIC-AGGREGATE SESSION (GAy) whose DSCP is set to y. In both 1228 messages the GENERIC-AGGREGATE SESSION contains an interface- 1230 Generic Aggregate RSVP Reservations September 2006 1232 independent Deaggregator address inside the DestAddress and 1233 appropriate values inside the vDstPort and Extended vDstPort fields. 1235 (3) The Aggregator follows the request from the Deaggregator and 1236 signals an Aggregate Path for both GENERIC-AGGREGATE Sessions (GAx 1237 and GAy). 1239 (4) The Deaggregator takes into account the information contained in 1240 the ADSPEC from both Aggregate Path and updates the E2E Path ADSPEC 1241 accordingly. The Deaggregator also modifies the E2E Path IP Protocol 1242 Number to RSVP before forwarding it. 1244 (5) In this example, the Deaggregator elects to immediately proceed 1245 with establishment of generic aggregate reservations for both DSCPs. 1246 In effect, the Deaggregator can be seen as anticipating the actual 1247 demand of E2E reservations so that resources are available on 1248 the generic aggregate reservations when the E2E Resv requests arrive, 1249 in order to speed up establishment of E2E reservations. Assume 1250 also that the Deaggregator includes the optional Resv Confirm 1251 Request in these Aggregate Resv. 1253 (6) The Aggregator merely complies with the received ResvConfirm 1254 Request and returns the corresponding Aggregate ResvConfirm. 1256 (7) The Deaggregator has explicit confirmation that both Aggregate 1257 Resv are established. 1259 (8) On receipt of the E2E Resv, the Deaggregator applies the mapping 1260 policy defined by the network administrator to map the E2E Resv 1261 onto a generic aggregate reservation. Let's assume that this policy 1262 is such that the E2E reservation is to be mapped onto the generic 1263 aggregate reservation with DSCP=x. The Deaggregator knows that a 1264 generic aggregate reservation (GAx) is in place for the corresponding 1265 DSCP since (7). The Deaggregator performs admission control of the 1266 E2E Resv onto the generic aggregate Reservation for DSCP=x (GAx). 1267 Assuming that the generic aggregate reservation for DSCP=x (GAx) had 1268 been established with sufficient bandwidth to support the E2E Resv, 1269 the Deaggregator adjusts its counter, tracking the unused bandwidth 1270 on the generic aggregate reservation and forwards the E2E Resv to the 1271 Aggregator including a SESSION-OF-INTEREST object conveying the 1272 selected mapping onto GAx (and hence onto DSCP=x). 1274 (9) The Aggregator records the mapping of the E2E Resv onto GAx (and 1275 onto DSCP=x). The Aggregator removes the SOI object and forwards the 1276 E2E Resv towards the sender.