idnits 2.17.1 draft-ietf-tsvwg-rsvp-ipsec-05.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, updated by RFC 4748 on line 1318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1291. ** 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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 27) being 65 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == 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: 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 (February 2007) is 6273 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) == Missing Reference: 'RFC2205' is mentioned on line 1123, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1151, but not defined Summary: 3 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 February 2007 3 Internet Draft Francois Le Faucheur 4 Intended status: Proposed Standards 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-05.txt 14 Expires: August 13, 2007 February 13, 2007 16 Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations 17 draft-ietf-tsvwg-rsvp-ipsec-05.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 RFC3175 defines aggregate Resource ReSerVation Protocol (RSVP) 44 reservations allowing resources to be reserved in a Diffserv network 45 for a given Per Hop Behavior (PHB), or given set of PHBs, from a 46 given source to a given destination. RFC3175 also defines how end-to- 48 Generic Aggregate RSVP Reservations February 2007 50 end RSVP reservations can be aggregated onto such aggregate 51 reservations when transiting through a Diffserv cloud. There are 52 situations where multiple such aggregate reservations are needed for 53 the same source IP address, destination IP address and PHB (or set of 54 PHBs). However, this is not supported by the aggregate reservations 55 defined in RFC3175. In order to support this, the present document 56 defines a more flexible type of aggregate RSVP reservations, referred 57 to as generic aggregate reservation. Multiple such generic aggregate 58 reservations can be established for a given PHB (or set of PHBs) from 59 a given source IP address to a given destination IP address. The 60 generic aggregate reservations may be used to aggregate end-to-end 61 RSVP reservations. This document also defines the procedures for such 62 aggregation. The generic aggregate reservations may also be used end- 63 to-end directly by end-systems attached to a Diffserv network. 65 Table Of Content 67 1. Introduction...................................................3 68 1.1. Related IETF Documents....................................6 69 1.2. Organization Of This Document.............................6 70 2. Object Definition..............................................7 71 2.1. SESSION Class.............................................7 72 2.2. SESSION-OF-INTEREST (SOI) Class..........................10 73 3. Processing Rules For Handling Generic Aggregate RSVP Reservations 74 .................................................................12 75 3.1. Extensions to Path and Resv Processing...................13 76 4. Procedures for Aggregation over Generic Aggregate RSVP 77 Reservations.....................................................14 78 5. Example Usage Of Multiple Generic Aggregate Reservations Per PHB 79 From a Given Aggregator to a Given Deaggregator..................18 80 6. Security Considerations.......................................20 81 7. IANA Considerations...........................................23 82 8. Acknowledgments...............................................24 83 9. Normative References..........................................24 84 10. Informative References.......................................25 85 11. Authors' Addresses...........................................25 86 Appendix A: Example Signaling Flow...............................27 88 Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119. 94 Generic Aggregate RSVP Reservations February 2007 96 1. Introduction 98 [RSVP-AGG] defines RSVP aggregate reservations allowing resources to 99 be reserved in a Diffserv network for a flow characterized by its 3- 100 tuple . 102 [RSVP-AGG] also defines the procedures for aggregation of end-to-end 103 RSVP reservations onto such aggregate reservations when transiting 104 through a Diffserv cloud. Such aggregation is illustrated in Figure 1. 105 This document reuses the terminology defined in [RSVP-AGG]. 107 -------------------------- 108 / Aggregation \ 109 |----| | Region | |----| 110 H--| R |\ |-----| |------| /| R |-->H 111 H--| |\\| | |---| |---| | |//| |-->H 112 |----| \| | | I | | I | | |/ |----| 113 | Agg |======================>| Deag | 114 /| | | | | | | |\ 115 H--------//| | |---| |---| | |\\-------->H 116 H--------/ |-----| |------| \-------->H 117 | | 118 \ / 119 -------------------------- 121 H = Host requesting end-to-end RSVP reservations 122 R = RSVP router 123 Agg = Aggregator 124 Deag = Deaggregator 125 I = Interior Router 127 --> = E2E RSVP reservation 128 ==> = Aggregate RSVP reservation 130 Figure 1 : Aggregation of E2E Reservations 131 over aggregate RSVP Reservations 133 These aggregate reservations use a SESSION type specified in [RSVP- 134 AGG] that contains the receiver (or Deaggregator) IP address and the 135 DSCP of the Per Hop Behavior (PHB) from which Diffserv resources are 136 to be reserved. For example, in the case of IPv4, the SESSION object 137 is specified as: 139 o Class = SESSION, 140 C-Type = RSVP-AGGREGATE-IP4 142 Generic Aggregate RSVP Reservations February 2007 144 +-------------+-------------+-------------+-------------+ 145 | IPv4 Session Address (4 bytes) | 146 +-------------+-------------+-------------+-------------+ 147 | /////////// | Flags | ///////// | DSCP | 148 +-------------+-------------+-------------+-------------+ 150 These aggregate reservations use a SENDER_TEMPLATE and FILTER_SPEC 151 types specified in [RSVP-AGG] and which contains only the sender (or 152 Aggregator) IP address. For example, in the case of IPv4, the 153 SENDER_TEMPLATE object is specified as: 155 o Class = SENDER_TEMPLATE, 156 C-Type = RSVP-AGGREGATE-IP4 158 +-------------+-------------+-------------+-------------+ 159 | IPv4 Aggregator Address (4 bytes) | 160 +-------------+-------------+-------------+-------------+ 162 Thus, it is possible to establish, from a given source IP address to 163 a given destination IP address, separate such aggregate reservations 164 for different PHBs (or different sets of PHBs). However, from a given 165 source IP address to a given IP destination address, only a single 166 [RSVP-AGG] aggregate reservation can be established for a given PHB 167 (or given set of PHBs). 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 PHB (or set of PHBs). One example is where E2E 172 reservations using different preemption priorities (as per [RSVP- 173 PREEMP]) need to be aggregated through a Diffserv cloud using the 174 same PHB. Using multiple aggregate reservations for the same PHB 175 allows enforcement of the different preemption priorities within the 176 aggregation region. In turn this allows more efficient management of 177 the Diffserv resources and in period of resource shortage allows to 178 sustain a larger number of E2E reservations with higher preemption 179 priorities. 181 For example, [SIG-NESTED] discusses in detail how end-to-end RSVP 182 reservations can be established in a nested VPN environment through 183 RSVP aggregation. In particular, [SIG-NESTED] describes how multiple 184 parallel generic aggregate reservations (for the same PHB), each with 185 different preemption priorities, can be used to efficiently support 186 the preemption priorities of end-to-end reservations. 188 This document addresses this requirement for multiple aggregate 189 reservations for the same PHB (or same set of PHBs), by defining a 191 Generic Aggregate RSVP Reservations February 2007 193 more flexible type of aggregate RSVP reservations, referred to as 194 generic aggregate reservations. This is achieved primarily by adding 195 the notions of a Virtual Destination Port and of an Extended Virtual 196 Destination Port in the RSVP Session object. 198 The notion of Virtual Destination Port was introduced in [RSVP-IPSEC] 199 to address a similar requirement (albeit in a different context) for 200 identification and demultiplexing of sessions beyond the IP 201 destination address. This document reuses this notion from [RSVP- 202 IPSEC] for identification and demultiplexing of generic aggregate 203 sessions beyond the IP destination address and PHB. This allows 204 multiple generic aggregate reservations to be established for a given 205 PHB (or set of PHBs), from a given source IP address to a given 206 destination IP address. 208 [RSVP-TE] introduced the concept of an Extended Tunnel ID (in 209 addition to the tunnel egress address and the Tunnel ID) in the 210 Session object used to establish MPLS Traffic Engineering tunnels 211 with RSVP. The Extended Tunnel ID provides a very convenient 212 mechanism for the tunnel ingress node to narrow the scope of the 213 session to the ingress-egress pair. The ingress node can achieve this 214 by using one of its own IP addresses as a globally unique identifier 215 and including it in the Extended Tunnel ID and therefore within the 216 Session object. This document reuses this notion of Extended Tunnel 217 ID from [RSVP-TE], simply renaming it Extended Virtual Destination 218 Port. This provides a convenient mechanism to narrow the scope of a 219 generic aggregate session to an Aggregator-Deaggregator pair. 221 The RSVP Session object for generic aggregate reservations uses the 222 PHB Identification Code (PHB-ID) defined in [PHB-ID] to identify the 223 PHB, or set of PHBs, from which the Diffserv resources are to be 224 reserved. This is instead of using the Diffserv Code Point (DSCP) as 225 per [RSVP-AGG]. Using the PHB-ID instead of the DSCP allows explicit 226 indication of whether the Diffserv resources belong to a single PHB 227 or to a set of PHBs. It also facilitates handling of situations where 228 a generic aggregate reservation spans two (or more) Diffserv domains 229 which use different DSCP values for the same Diffserv PHB (or set of 230 PHBs) from which resources are reserved. This is because the PHB-ID 231 allows conveying of the PHB (or set of PHBs) independently of what 232 DSCP value(s) is used locally for that PHB (or set of PHBs). 234 The generic aggregate reservations may be used to aggregate end-to- 235 end RSVP reservations. This document also defines the procedures for 236 such aggregation. These procedures are based on those of [RSVP-AGG] 237 and this document only specifies the differences with those. 239 The generic aggregate reservations may also be used end-to-end 240 directly by end-systems attached to a Diffserv network. 242 Generic Aggregate RSVP Reservations February 2007 244 1.1. Related IETF Documents 246 This document is heavily based on [RSVP-AGG]. It reuses [RSVP-AGG] 247 wherever applicable and only specifies the necessary extensions 248 beyond [RSVP-AGG]. 250 The mechanisms defined in [BW-REDUC] allow an existing reservation to 251 be reduced in allocated bandwidth by RSVP routers in lieu of tearing 252 that reservation down. These mechanisms are applicable to the generic 253 aggregate reservations defined in the present document. 255 [RSVP-TUNNEL] describes a general approach to running RSVP over 256 various types of tunnels. One of these types of tunnel, referred to 257 as a "type 2 tunnel", has some similarity with the generic aggregate 258 reservations described in this document. The similarity stems from 259 the fact that a single, aggregate reservation is made for the tunnel 260 while many individual flows are carried over that tunnel. However, 261 [RSVP-TUNNEL] does not address the use of Diffserv-based 262 classification and scheduling in the core of a network (between 263 tunnel endpoints), but rather relies on a UDP/IP tunnel header for 264 classification. This is why [RSVP-AGG] required additional objects 265 and procedures beyond those of [RSVP-TUNNEL]. Like [RSVP-AGG], this 266 document also assumes the use of Diffserv-based classification and 267 scheduling in the aggregation region and, thus, requires additional 268 objects and procedures beyond those of [RSVP-TUNNEL]. 270 As explained earlier, this document reuses the notion of Virtual 271 Destination Port from [RSVP-IPSEC] and the notion of Extended Tunnel 272 ID from [RSVP-TE]. 274 1.2. Organization Of This Document 276 Section 2 defines the new RSVP objects related to generic aggregate 277 reservations and to aggregation of E2E reservations onto those. 278 Section 3 describes the processing rules for handling of generic 279 aggregate reservations. Section 4 specifies the procedures for 280 aggregation of end to end RSVP reservations over generic aggregate 281 RSVP reservations. Section 5 provides example usage of how the 282 generic aggregate reservations may be used. 284 The Security Considerations and the IANA Considerations are discussed 285 in Section 6 and 7, respectively. 287 Finally, Appendix 1 provides an example signaling flow is 288 illustrating aggregation of E2E RSVP reservations onto generic 289 aggregate RSVP reservations. 291 Generic Aggregate RSVP Reservations February 2007 293 2. Object Definition 295 This document reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP- 296 AGGREGATE-IP6 FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE and 297 RSVP-AGGREGATE-IP6 SENDER_TEMPLATE objects defined in [RSVP-AGG]. 299 This document defines: 300 - two new objects (GENERIC-AGGREGATE-IP4 SESSION and GENERIC- 301 AGGREGATE-IP6 SESSION) under the existing SESSION Class, and 302 - two new objects (GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI) 303 under a new SESSION-OF-INTEREST Class. 305 Detailed description of these objects is provided below in this 306 section. 308 The GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION 309 objects are applicable to all types of RSVP messages. 311 This specification defines the use of the GENERIC-AGG-IP4-SOI and 312 GENERIC-AGG-IP6-SOI objects in two circumstances: 313 - inside an E2E PathErr message which contains an error code of 314 NEW-AGGREGATE-NEEDED in order to convey the session of a new 315 generic aggregate reservation which needs to be established 316 - inside an E2E Resv message in order to convey the session of 317 the generic aggregate reservation onto which this E2E 318 reservation needs to be mapped. 319 Details of the corresponding procedures can be found in section 4. 321 However, it is envisioned that the ability to signal, inside RSVP 322 messages, the Session of another reservation (which has some 323 relationship with the current RSVP reservation) might have some other 324 applicability in the future. Thus, those objects have been specified 325 in a more generic manner under a flexible SESSION-OF-INTEREST class. 327 All the new objects defined in this document are optional with 328 respect to RSVP so that general RSVP implementations not concerned 329 with generic aggregate reservations do not have to support these 330 objects. RSVP routers supporting generic aggregate IPv4 (respectively 331 IPv6) reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION 332 object (respectively GENERIC-AGGREGATE-IP6 SESSION). RSVP routers 333 supporting RSVP aggregation over generic aggregate IPv4 (respectively 334 IPv6) reservations MUST support the GENERIC-AGG-IP4-SOI object 335 (respectively GENERIC-AGG-IP6-SOI). 337 2.1. SESSION Class 339 o GENERIC-AGGREGATE-IP4 SESSION object: 340 Class = 1 (SESSION) 342 Generic Aggregate RSVP Reservations February 2007 344 C-Type = To be allocated by IANA 346 0 7 8 15 16 23 24 31 347 +-------------+-------------+-------------+-------------+ 348 | IPv4 DestAddress (4 bytes) | 349 +-------------+-------------+-------------+-------------+ 350 | Reserved | Flags | PHB-ID | 351 +-------------+-------------+-------------+-------------+ 352 | Reserved | vDstPort | 353 +-------------+-------------+-------------+-------------+ 354 | Extended vDstPort | 355 +-------------+-------------+-------------+-------------+ 356 0 7 8 15 16 23 24 31 358 IPv4 DestAddress (IPv4 Destination Address) 360 IPv4 address of the receiver (or Deaggregator) 362 Reserved 364 A 8-bit field. All bits MUST be set to 0 on transmit. This field 365 MUST be ignored on receipt. 367 Flags 369 A 8-bit field. The content and processing of this field are the 370 same as for the Flags field of the IPv4/UDP SESSION object (see 371 [RSVP]) 373 PHB-ID (Per Hop Behavior Identification Code) 375 A 16-bit field containing the Per Hop Behavior Identification 376 Code of the PHB, or of the set of PHBs, from which Diffserv 377 resources are to be reserved. This field MUST be encoded as 378 specified in section 2 of [PHB-ID]. 380 Reserved 382 A 16-bit field. All bits MUST be set to 0 on transmit. This 383 field MUST be ignored on receipt. 385 VDstPort (Virtual Destination Port) 387 Generic Aggregate RSVP Reservations February 2007 389 A 16-bit identifier used in the SESSION that remains constant 390 over the life of the generic aggregate reservation. 392 Extended vDstPort (Extended Virtual Destination Port) 394 A 32-bit identifier used in the SESSION that remains constant 395 over the life of the generic aggregate reservation. 396 A sender (or Aggregator) that wishes to narrow the scope of a 397 SESSION to the sender-receiver pair (or Aggregator-Deaggregator 398 pair) SHOULD place its IPv4 address here as a network unique 399 identifier. A sender (or Aggregator) that wishes to use a common 400 session with other senders (or Aggregators) in order to use a 401 shared reservation across senders (or Aggregators) MUST set this 402 field to all zeros. 404 o GENERIC-AGGREGATE-IP6 SESSION object: 405 Class = 1 (SESSION) 406 C-Type = To be allocated by IANA 408 0 7 8 15 16 23 24 31 409 +-------------+-------------+-------------+-------------+ 410 | | 411 + + 412 | | 413 + IPv6 DestAddress (16 bytes) + 414 | | 415 + + 416 | | 417 +-------------+-------------+-------------+-------------+ 418 | Reserved | Flags | PHB-ID | 419 +-------------+-------------+-------------+-------------+ 420 | Reserved | vDstPort | 421 +-------------+-------------+-------------+-------------+ 422 | | 423 + + 424 | Extended vDstPort | 425 + + 426 | (16 bytes) | 427 + + 428 | | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 0 7 8 15 16 25 26 31 432 IPv6 DestAddress (IPv6 Destination Address) 434 IPv6 address of the receiver (or Deaggregator) 436 Generic Aggregate RSVP Reservations February 2007 438 Reserved 440 A 8-bit field. All bits MUST be set to 0 on transmit. This field 441 MUST be ignored on receipt. 443 Flags 445 A 8-bit field. The content and processing of this field are the 446 same as for the Flags field of the IPv6/UDP SESSION object (see 447 [RSVP]) 449 PHB-ID (Per Hop Behavior Identification Code) 451 A 16-bit field containing the Per Hop Behavior Identification 452 Code of the PHB, or of the set of PHBs, from which Diffserv 453 resources are to be reserved. This field MUST be encoded as 454 specified in section 2 of [PHB-ID]. 456 Reserved 458 A 16-bit field. All bits MUST be set to 0 on transmit. This 459 field MUST be ignored on receipt. 461 VDstPort (Virtual Destination Port) 463 A 16-bit identifier used in the SESSION that remains constant 464 over the life of the generic aggregate reservation. 466 Extended vDstPort (Extended Virtual Destination Port) 468 A 128-bit identifier used in the SESSION that remains constant 469 over the life of the generic aggregate reservation. 470 A sender (or Aggregator) that wishes to narrow the scope of a 471 SESSION to the sender-receiver pair (or Aggregator-Deaggregator 472 pair) SHOULD place its IPv6 address here as a network unique 473 identifier. A sender (or Aggregator) that wishes to use a common 474 session with other senders (or Aggregators) in order to use a 475 shared reservation across senders (or Aggregators) MUST set this 476 field to all zeros. 478 2.2. SESSION-OF-INTEREST (SOI) Class 480 Generic Aggregate RSVP Reservations February 2007 482 o GENERIC-AGG-IP4-SOI object: 483 Class = To be allocated by IANA 484 C-Type = To be allocated by IANA 486 0 7 8 15 16 23 24 31 487 +-------------+-------------+-------------+-------------+ 488 | | SOI |GEN-AGG-IP4- | 489 | Length (bytes) | Class-Num |SOI C-Type | 490 +-------------+-------------+-------------+-------------+ 491 | | 492 // Content of a GENERIC-AGGREGATE-IP4 SESSION Object // 493 | | 494 +-------------+-------------+-------------+-------------+ 496 Content of a GENERIC-AGGREGATE-IP4 SESSION Object: 498 This field contains a copy of the Session object of the session 499 which is of interest for the reservation. In the case of a 500 GENERIC-AGG-IP4-SOI, the session of interest conveyed in this 501 field is a GENERIC-AGGREGATE-IP4 SESSION. 503 o GENERIC-AGG-IP6-SOI object: 504 Class = To be allocated by IANA 505 (same as for GENERIC-AGG-IP4-SOI) 506 C-Type = To be allocated by IANA 508 0 7 8 15 16 23 24 31 509 +-------------+-------------+-------------+-------------+ 510 | | SOI |GEN-AGG-IP6- | 511 | Length (bytes) | Class-Num |SOI C-Type | 512 +-------------+-------------+-------------+-------------+ 513 | | 514 // Content of a GENERIC-AGGREGATE-IP6 SESSION Object // 515 | | 516 +-------------+-------------+-------------+-------------+ 518 Content of a GENERIC-AGGREGATE-IP6 SESSION Object: 520 This field contains a copy of the Session object of the session 521 which is of interest for the reservation. In the case of a 522 GENERIC-AGG-IP6-SOI, the session of interest conveyed in this 523 field is a GENERIC-AGGREGATE-IP6 SESSION. 525 For example, if a SESSION-OF-INTEREST object is used inside an E2E 526 Resv message (as per the procedures defined in section 4) to indicate 527 which generic aggregate IPv4 session the E2E reservation is to be 529 Generic Aggregate RSVP Reservations February 2007 531 mapped onto, then the GENERIC-AGG-IP4-SOI object will be used and it 532 will be encoded like this: 534 0 7 8 15 16 23 24 31 535 +-------------+-------------+-------------+-------------+ 536 | | SOI |GEN-AGG-IP4- | 537 | Length (bytes) | Class-Num |SOI C-Type | 538 +-------------+-------------+-------------+-------------+ 539 | IPv4 DestAddress (4 bytes) | 540 +-------------+-------------+-------------+--+----------+ 541 | Reserved | Flags | PHB-ID | 542 +-------------+-------------+-------------+-------------+ 543 | Reserved | vDstPort | 544 +-------------+-------------+-------------+-------------+ 545 | Extended vDstPort | 546 +-------------+-------------+-------------+-------------+ 547 0 7 8 15 16 23 24 31 549 Note that a SESSION-OF-INTEREST object is not a SESSION object in 550 itself. It does not replace the SESSION object in RSVP messages. It 551 does not modify the usage of the SESSION object in RSVP messages. It 552 simply allows conveying the Session of another RSVP reservation 553 inside RSVP signaling messages, for some particular purposes. In the 554 context of this document, it is used to convey, inside an E2E RSVP 555 message pertaining to an end-to-end reservation, the Session of a 556 generic aggregate reservation associated with the E2E reservation. 557 Details for the corresponding procedures are specified in section 4. 559 3. Processing Rules For Handling Generic Aggregate RSVP Reservations 561 This section presents extensions to the processing of RSVP messages 562 required by [RSVP] and presented in [RSVP-PROCESS]. These extensions 563 are required in order to properly process the GENERIC-AGGREGATE-IP4 564 (resp. GENERIC-AGGREGATE-IP6) SESSION object and the RSVP-AGGREGATE- 565 IP4 (resp. RSVP-AGGREGATE-IP6) FILTER_SPEC object. Values for 566 referenced error codes can be found in [RSVP]. As with the other RSVP 567 documents, values for internally reported (API) errors are not 568 defined. 570 When referring to the new GENERIC-AGGREGATE-IP4 and GENERIC- 571 AGGREGATE-IP6 SESSION objects, IP version will not be included and 572 they will be referred to simply as GENERIC-AGGREGATE SESSION, unless 573 a specific distinction between IPv4 and IPv6 is being made. 575 When referring to the [RSVP-AGG] RSVP-AGGREGATE-IP4 and 576 RSVP-AGGREGATE-IP6 SESSION, FILTER_SPEC and SENDER_TEMPLATE objects, 577 IP version will not be included and they will be referred to simply 579 Generic Aggregate RSVP Reservations February 2007 581 as RSVP-AGGREGATE, unless a specific distinction between IPv4 and 582 IPv6 is being made. 584 3.1. Extensions to Path and Resv Processing 586 The following PATH message processing changes are defined: 588 o When a session is defined using the GENERIC-AGGREGATE SESSION 589 object, only the [RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATE may 590 be used. When this condition is violated in a PATH message 591 received by an RSVP end-station, the RSVP end-station SHOULD 592 report a "Conflicting C-Type" API error to the application. 593 When this condition is violated in a PATH message received by 594 an RSVP router, the RSVP router MUST consider this as a 595 message formatting error. 597 o For PATH messages that contain the GENERIC-AGGREGATE SESSION 598 object, the VDstPort value, the Extended VDstPort value and 599 the PHB-ID value should be recorded (in addition to the 600 destination/Deaggregator address and source/aggregator 601 address). These values form part of the recorded state of the 602 session. The PHB-ID may need to be passed to traffic control; 603 however the vDstPort and Extended VDstPort are not passed to 604 traffic control since they do not appear inside the data 605 packets of the corresponding reservation. 607 The following changes to RESV message processing are defined: 609 o When a RESV message contains a [RSVP-AGG] RSVP-AGGREGATE 610 FILTER_SPEC, the session MUST be defined using either the 611 RSVP-AGGREGATE SESSION object (as per [RSVP-AGG]) or the 612 GENERIC-AGGREGATE SESSION object (as per this document). If 613 this condition is not met, an RSVP router or end-station MUST 614 consider that there is a message formatting error. 616 o When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION 617 type is GENERIC-AGGREGATE, each node uses data classifier as 618 per the following: 620 * to perform Diffserv classification the node MUST rely on the 621 Diffserv data classifier based on the DSCP only. The 622 relevant DSCP value(s) is the one (are those) associated 623 with the PHB-ID of the generic aggregate reservation. 624 * If the node also needs to perform fine-grain classification 625 (for example to perform fine-grain input policing at a trust 626 boundary) then the node MUST create a data classifier 627 described by the 3-tuple . 629 Generic Aggregate RSVP Reservations February 2007 631 The relevant DSCP value(s) is the one (are those) associated 632 with the PHB-ID of the generic aggregate reservation. 634 Note that if multiple generic aggregate reservations are 635 established with different Virtual Destination Ports (and/or 636 different Extended Virtual Destination Ports) but with the 637 same , then those cannot be 638 distinguished by the classifier. If the router is using the 639 classifier for policing purposes, the router will therefore 640 police those together and MUST program the policing rate to 641 the sum of the reserved rate across all the corresponding 642 reservations. 644 4. Procedures for Aggregation over Generic Aggregate RSVP Reservations 646 The procedures for aggregation of E2E reservations over generic 647 aggregate RSVP reservations are the same as the procedures specified 648 in [RSVP-AGG] with the exceptions of the procedure changes listed in 649 this section. 651 As specified in [RSVP-AGG], the Deaggregator is responsible for 652 mapping a given E2E reservation on a given aggregate reservation. The 653 Deaggregator requests establishment of a new aggregate reservation by 654 sending to the Aggregator an E2E PathErr message with an error code 655 of NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the Deaggregator conveys the 656 DSCP of the new requested aggregate reservation by including a DCLASS 657 Object in the E2E PathErr and encoding the corresponding DSCP inside. 658 This document modifies and extends this procedure. The Deaggregator 659 MUST include in the E2E PathErr message, a SESSION-OF-INTEREST object 660 which contains the GENERIC-AGGREGATE Session to be used for 661 establishment of the requested generic aggregate reservation. Since 662 this GENERIC-AGGREGATE SESSION contains the PHB-ID, the DCLASS object 663 need not be included in the PathErr message. 665 Note that the Deaggregator can easily ensure that different 666 Aggregators use different sessions for their Aggregate Path towards a 667 given Deaggregator. This is because the Deaggregator can easily 668 select VDstPort and/or Extended VDstPort numbers which are different 669 for each Aggregator (for example by using the Aggregator address as 670 the Extended VDstPort) and can communicate those inside the GENERIC- 671 AGGREGATE SESSION included in the SESSION-OF-INTEREST object. This 672 provides an easy solution to establish separate reservations from 673 every Aggregator to a given Deaggregator. Conversely, if reservation 674 sharing were needed across multiple Aggregators, the Deaggregator 675 could facilitate this by allocating the same VDstPort and Extended 676 VDstPort to the multiple Aggregators and thus including the same 677 GENERIC-AGGREGATE SESSION inside the SESSION-OF-INTEREST object in 678 the E2E PathErr messages sent to these Aggregators. The Aggregators 680 Generic Aggregate RSVP Reservations February 2007 682 could then all establish an Aggregate Path with the same GENERIC- 683 AGGREGATE SESSION. 685 Therefore various sharing scenarios can easily be supported. Policies 686 followed by the Deaggregator to determine which aggregators need 687 shared or separate reservations are beyond the scope of this document. 689 The Deaggregator MAY also include in the E2E PathErr message (with an 690 error code of NEW-AGGREGATE-NEEDED) additional RSVP objects which are 691 to be used for establishment of the new needed generic aggregate 692 reservation. For example, the Deaggregator MAY include in the E2E 693 PathErr an RSVP Signaled Preemption Priority Policy Element (as 694 specified in [RSVP-PREEMP]). 696 The [RSVP-AGG] procedures for processing of an E2E PathErr message 697 received with an error code of NEW-AGGREGATE-NEEDED by the Aggregator 698 are extended correspondingly. On receipt of such a message containing 699 a SESSION-OF-INTEREST object, the Aggregator MUST trigger 700 establishment of a generic aggregate reservation. In particular, it 701 MUST start sending aggregate Path messages with the GENERIC-AGGREGATE 702 SESSION found in the received SESSION-OF-INTEREST object. When an 703 RSVP Signaled Preemption Priority Policy Element is contained in the 704 received E2E PathErr message, the Aggregator MUST include this object 705 in the Aggregate Path for the corresponding generic aggregate 706 reservation. When other additional objects are contained in the 707 received E2E PathErr message and those can be unambiguously 708 interpreted as related to the new needed generic aggregate 709 reservation (as opposed to related to the E2E reservation), the 710 Aggregator SHOULD include those in the Aggregate Path for the 711 corresponding generic aggregate reservation. The Aggregator MUST use 712 as the Source Address (i.e. as the Aggregator Address in the Sender- 713 Template) for the generic aggregate reservation, the address it uses 714 to identify itself as the PHOP when forwarding the E2E Path messages 715 corresponding to the E2E PathErr message. 717 The Deaggregator follows the same procedures as described in [RSVP- 718 AGG] for establishing, maintaining and clearing the aggregate Resv 719 state. However, a Deaggregator behaving according to the present 720 specification MUST use the generic aggregate reservations and hence 721 use the GENERIC-AGGREGATE SESSION specified earlier in this document. 723 This document also modifies the procedures of [RSVP-AGG] related to 724 exchange of E2E Resv messages between Deaggregator and Aggregator. 725 The Deaggregator MUST include the new SESSION-OF-INTEREST object in 726 the E2E Resv message, in order to indicate to the Aggregator the 727 generic aggregate session to map a given E2E reservation onto. Again, 728 since the GENERIC-AGGREGATE SESSION (included in the SESSION-OF- 729 INTEREST object) contains the PHB-ID, the DCLASS object need not be 730 included in the E2E Resv message. The Aggregator MUST interpret the 732 Generic Aggregate RSVP Reservations February 2007 734 SESSION-OF-INTEREST object in the E2E Resv as indicating which 735 generic aggregate reservation session the corresponding E2E 736 reservation is mapped onto. The Aggregator MUST not include the 737 SESSION-OF-INTEREST object when sending an E2E Resv upstream towards 738 the sender. 740 Based on relevant policy, the Deaggregator may decide at some point 741 that an aggregate reservation is no longer needed and should be torn 742 down. In that case, the Deaggregator MUST send an aggregate ResvTear. 743 On receipt of the aggregate ResvTear, the Aggregator SHOULD send an 744 aggregate PathTear (unless the relevant policy instructs the 745 aggregator to do otherwise or to wait for some time before doing so, 746 for example in order to speed-up potential re-establishment of the 747 aggregate reservation in the future). 749 [RSVP-AGG] describes how the Aggregator and Deaggregator can 750 communicate their respective identity to each other. For example the 751 Aggregator includes one of its IP addresses in the RSVP HOP object in 752 the E2E Path which is transmitted downstream and received by the 753 Deaggregator once it traversed the aggregation region. Similarly, the 754 Deaggregator identifies itself to the Aggregator by including one of 755 its IP addresses in various fields, including the ERROR SPECIFICATION 756 of the E2E PathErr message (containing the NEW-AGGREGATE-NEEDED Error 757 Code) and in the RSVP HOP object of the E2E Resv message. However, 758 [RSVP-AGG] does not discuss which IP addresses are to be selected by 759 the aggregator and Deaggregator for such purposes. Because these 760 addresses are intended to identify the Aggregator and Deaggregator 761 and not to identify any specific interface on these devices, this 762 document RECOMMENDS that the Aggregator and Deaggregator SHOULD use 763 interface-independent addresses (for example a loopback address) 764 whenever they communicate their respective identity to each other. 765 This ensures that respective identification of the Aggregator and 766 Deaggregator is not impacted by any interface state change on these 767 devices. In turns this results in more stable operations and 768 considerably reduced RSVP signaling in the aggregation region. For 769 example, if interface-independent addresses are used by the 770 Aggregator and the Deaggregator, then a failure of an interface on 771 these devices may simply result in the rerouting of a given generic 772 aggregate reservation but will not result in the generic aggregate 773 reservation having to be torn down and another one established, nor 774 will it result in a change of mapping of E2E reservations on generic 775 aggregate reservations (assuming the Aggregator and Deaggregator 776 still have reachability after the failure and the Aggregator and 777 Deaggregator are still on the shortest path to the destination). 779 However, when identifying themselves to real RSVP neighbors (i.e. 780 neighbors which are not on the other side of the aggregation region), 781 the Aggregator and Deaggregator SHOULD continue using interface- 782 dependent addresses as per regular [RSVP] procedures. This applies 784 Generic Aggregate RSVP Reservations February 2007 786 for example when the Aggregator identifies itself downstream as a 787 PHOP for the generic aggregate reservation or identifies itself 788 upstream as a NHOP for an E2E reservation. This also applies when the 789 Deaggregator identifies itself downstream as a PHOP for the E2E 790 reservation or identifies itself upstream as a NHOP for the generic 791 aggregate reservation. As part of the processing of generic aggregate 792 reservations, interior routers (i.e. routers within the aggregation 793 region) SHOULD continue using interface-dependent addresses as per 794 regular [RSVP] procedures. 796 More generally, within the aggregation region (ie between Aggregator 797 and Deaggregator) the operation of RSVP should be modeled with the 798 notion that E2E reservations are mapped to aggregate reservations and 799 are no longer tied to physical interfaces (as was the case with 800 regular RSVP). However, generic aggregate reservations (within the 801 aggregation region) as well as E2E reservations outside the 802 aggregation region, retain the model of regular RVSP and remain tied 803 to physical interfaces. 805 As discussed above, generic aggregate reservations may be established 806 edge-to-edge as a result of the establishment of E2E reservations 807 (from outside the aggregation region) that are to be aggregated over 808 the aggregation region. However, generic aggregate reservations may 809 also be used end-to-end by end-systems directly attached to a 810 Diffserv domain, such as PSTN Gateways. In that case, the generic 811 aggregate reservations may be established by the end-systems in 812 response to application-level triggers such as voice call signaling. 813 Alternatively, generic aggregate reservations may also be used edge- 814 to-edge to manage bandwidth in a Diffserv cloud even if RSVP is not 815 used end-to-end. A simple example of such a usage would be the static 816 configuration of a generic aggregate reservation for a certain 817 bandwidth for traffic from an ingress (Aggregator) router to an 818 egress (Deaggregator) router. 820 In this case, the establishment of the generic aggregate reservations 821 is controlled by configuration on the Aggregator and on the 822 Deaggregator. Configuration on the Aggregator triggers generation of 823 the aggregate Path message and provides sufficient information to the 824 Aggregator to derive the content of the GENERIC-AGGREGATE SESSION 825 object. This would typically include Deaggregator IP address, PHB-ID 826 and possibly VDstPort. Configuration on the Deaggregator would 827 instruct the Deaggregator to respond to a received generic aggregate 828 Path message and would provide sufficient information to the 829 Deaggregator to control the reservation. This may include bandwidth 830 to be reserved by the Deaggregator (for a given Deaggregator/PHB- 831 ID/VDstPort tuple). 833 In the absence of E2E microflow reservations, the Aggregator can use 834 a variety of policies to set the DSCP of packets passing into the 836 Generic Aggregate RSVP Reservations February 2007 838 aggregation region and how they are mapped onto generic aggregate 839 reservations, thus determining whether they gain access to the 840 resources reserved by the aggregate reservation. These policies are a 841 matter of local configuration, as usual for a device at the edge of a 842 Diffserv cloud. 844 5. Example Usage Of Multiple Generic Aggregate Reservations Per PHB 845 From a Given Aggregator to a Given Deaggregator 847 Let us consider the environment depicted in Figure 2 below. RSVP 848 aggregation is used to support E2E reservations between Cloud-1, 849 Cloud-2 and Cloud-3. 851 I----------I I----------I 852 I Cloud-1 I I Cloud-2 I 853 I----------I I----------I 854 | | 855 Agg-Deag-1------------ Agg-Deag-2 856 / \ 857 / Aggregation | 858 | Region | 859 | | 860 | ---/ 861 \ / 862 \Agg-Deag-3---------/ 863 | 864 I----------I 865 I Cloud-3 I 866 I----------I 868 Figure 2 : Example Usage of 869 Generic Aggregate IP Reservations 871 Let us assume that: 873 o the E2E reservations from Cloud-1 to Cloud-3 have a preemption 874 of either P1 or P2 876 o the E2E reservations from Cloud-2 to Cloud-3 have a preemption 877 of either P1 or P2 879 o the E2E reservations are only for Voice (which needs to be 880 treated in the aggregation region using the EF PHB) 882 Generic Aggregate RSVP Reservations February 2007 884 o traffic from the E2E reservations is encapsulated in Aggregate 885 IP reservations from Aggregator to Deaggregator using GRE 886 tunneling ([GRE]). 888 Then, the following generic aggregate RSVP reservations may be 889 established from Agg-Deag-1 to Agg-Deag-3 for aggregation of the end- 890 to-end RSVP reservations: 892 A first generic aggregate reservation for aggregation of Voice 893 reservations from Cloud-1 to Cloud-3 requiring use of P1: 895 * GENERIC-AGGREGATE-IP4 SESSION: 896 IPv4 DestAddress= Agg-Deag-3 897 vDstPort=V1 898 PHB-ID=EF 899 Extended VDstPort= Agg-Deag-1 901 * STYLE=FF or SE 903 * IPv4/GPI FILTER_SPEC: 904 IPv4 SrcAddress= Agg-Deag-1 906 * POLICY_DATA (PREEMPTION_PRI)=P1 908 A second generic aggregate reservation for aggregation of Voice 909 reservations from Cloud-1 to Cloud-3 requiring use of P2: 911 * GENERIC-AGGREGATE-IP4 SESSION: 912 IPv4 DestAddress= Agg-Deag-3 913 vDstPort=V2 914 PHB-ID=EF 915 Extended VDstPort= Agg-Deag-1 917 * STYLE=FF or SE 919 * IPv4/GPI FILTER_SPEC: 920 IPv4 SrcAddress= Agg-Deag-1 922 * POLICY_DATA (PREEMPTION_PRI)=P2 924 where V1 and V2 are arbitrary VDstPort values picked by 925 Agg-Deag-3. 927 The following generic aggregate RSVP reservations may be established 928 from Agg-Deag-2 to Agg-Deag-3 for aggregation of the end-to-end RSVP 929 reservations: 931 A third generic aggregate reservation for aggregation of Voice 932 reservations from Cloud-2 to Cloud-3 requiring use of P1: 934 Generic Aggregate RSVP Reservations February 2007 936 * GENERIC-AGGREGATE-IP4 SESSION: 937 IPv4 DestAddress= Agg-Deag-3 938 vDstPort=V3 939 PHB-ID=EF 940 Extended VDstPort= Agg-Deag-2 942 * STYLE=FF or SE 944 * IPv4/GPI FILTER_SPEC: 945 IPv4 SrcAddress= Agg-Deag-2 947 * POLICY_DATA (PREEMPTION_PRI)=P1 949 A fourth generic aggregate reservation for aggregation of Voice 950 reservations from Cloud-2 to Cloud-3 requiring use of P2: 952 * GENERIC-AGGREGATE-IP4 SESSION: 953 IPv4 DestAddress= Agg-Deag-3 954 vDstPort=V4 955 PHB-ID=EF 956 Extended VDstPort= Agg-Deag-2 958 * STYLE=FF or SE 960 * IPv4/GPI FILTER_SPEC: 961 IPv4 SrcAddress= Agg-Deag-2 963 * POLICY_DATA (PREEMPTION_PRI)=P2 965 where V3 and V4 are arbitrary VDstPort values picked by Agg-Deag-3. 967 Note that V3 and V4 could be equal to (respectively) V1 and V2 since, 968 in this example, the Extended VDstPort of the GENERIC-AGGREGATE 969 Session contains the address of the Deaggregator and, thus, ensures 970 that different sessions are used for each Deaggregator. 972 6. Security Considerations 974 In the environments addressed by this document, RSVP messages are 975 used to control resource reservations for generic aggregate 976 reservations and may be used to control resource reservations for E2E 977 reservations being aggregated over the generic aggregate 978 reservations. To ensure the integrity of the associated reservation 979 and admission control mechanisms, the RSVP Authentication mechanisms 980 defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] may be used. These 981 protect RSVP message integrity hop-by-hop and provide node 982 authentication as well as replay protection, thereby protecting 984 Generic Aggregate RSVP Reservations February 2007 986 against corruption and spoofing of RSVP messages. These hop-by-hop 987 integrity mechanisms can be naturally used to protect the RSVP 988 messages used for generic aggregate reservations and to protect RSVP 989 messages used for E2E reservations outside the aggregation region. 990 These hop-by-hop RSVP integrity mechanisms can also be used to 991 protect RSVP messages used for E2E reservations when those transit 992 through the aggregation region. This is because the Aggregator and 993 Deaggregator behave as RSVP neighbors from the viewpoint of the E2E 994 flows (even if they are not necessarily IP neighbors). 996 [RSVP-CRYPTO1] discusses several approaches for key distribution. 997 First, the RSVP Authentication shared keys can be distributed 998 manually. This is the base option and its support is mandated for any 999 implementation. However, in some environments, this approach may 1000 become a burden if keys frequently change over time. Alternatively, a 1001 standard key management protocol for secure key distribution can be 1002 used. However, existing key distribution protocols may not be 1003 appropriate in all environments because of the complexity or 1004 operational burden they involve. 1006 The use of RSVP Authentication in parts of the network where there 1007 may be one or more IP hops in between two RSVP neighbors raises an 1008 additional challenge. This is because, with some RSVP messages such 1009 as a Path message, an RSVP router does not know the RSVP next hop for 1010 that message at the time of forwarding it. In fact, part of the role 1011 of a Path message is precisely to discover the RSVP next hop (and to 1012 dynamically re-discover it when it changes, say because of a routing 1013 change). Hence, the RSVP router may not know which security 1014 association to use when forwarding such a message. This applies in 1015 particular to the case where RSVP Authentication mechanisms are to be 1016 used for protection of RSVP E2E messages (e.g. E2E Path) while they 1017 transit through an aggregation region and where the dynamic 1018 Deaggregator determination procedure defined in [RSVP-AGG] is used. 1019 This is because the Aggregator and the Deaggregator behave as RSVP 1020 neighbors for the E2E reservation, while there may be one or more IP 1021 hops in between them, and the Aggregator does not know ahead of time 1022 which router is going to act as the Deaggregator. 1024 In that situation, one approach is to share the same RSVP 1025 Authentication shared key across all the RSVP routers of a part of 1026 the network where there may be RSVP neighbors with IP hops in 1027 between. For example, all the Aggregators or Deaggregators of an 1028 aggregation region could share the same RSVP Authentication key, 1029 while different per-neighbor keys could be used between any RSVP 1030 router pair straddling the boundary between two administrative 1031 domains that have agreed to use RSVP signaling. 1033 When the same RSVP Authentication shared key is to be shared among 1034 multiple RSVP neighbors, manual key distribution may be used. For 1036 Generic Aggregate RSVP Reservations February 2007 1038 situations where RSVP is being used for multicast flows, it might 1039 also be possible, in the future, to adapt a multicast key management 1040 method (e.g. from IETF Multicast Security Working Group) for key 1041 distribution with such multicast RSVP usage. For situations where 1042 RSVP is being used for unicast flows across domain boundaries, it is 1043 not currently clear how one might provide automated key 1044 management. Specification of a specific automated key management 1045 technique is outside the scope of this document. Operators should 1046 consider these key management issues when contemplating deployment of 1047 this specification. 1049 The RSVP Authentication mechanisms do not provide confidentiality. If 1050 confidentiality is required, IPsec ESP [IPSEC-ESP] may be used, 1051 although it imposes the burden of key distribution. It also faces the 1052 additional issue discussed for key management above in case there can 1053 be IP hops in between RSVP hops. In the future, confidentiality 1054 solutions may be developed for the case where there can be IP hops in 1055 between RSVP hops, perhaps by adapting confidentiality solutions 1056 developed by the IETF MSEC Working Group. Such confidentiality 1057 solutions for RSVP are outside the scope of this document. 1059 Protection against traffic analysis is also not provided by RSVP 1060 Authentication. Since generic aggregate reservations are intended to 1061 reserve resources collectively for a whole set of users or hosts, 1062 malicious snooping of the corresponding RSVP messages could provide 1063 more traffic analysis information than snooping of an E2E 1064 reservation. When RSVP neighbors are directly attached, mechanisms 1065 such as bulk link encryption might be used when protection against 1066 traffic analysis is required. This approach could be used inside the 1067 aggregation region for protection of the generic aggregate 1068 reservations. It may also be used outside the aggregation region for 1069 protection of the E2E reservation. However, it is not applicable to 1070 the protection of E2E reservations while the corresponding E2E RSVP 1071 messages transit through the aggregation region. 1073 When generic aggregate reservations are used for aggregation of E2E 1074 reservations, the security considerations discussed in [RSVP-AGG] 1075 apply and are revisited here. 1077 First, the loss of an aggregate reservation to an aggressor causes 1078 E2E flows to operate unreserved, and the reservation of a great 1079 excess of bandwidth may result in a denial of service. These issues 1080 are not confined to the extensions defined in the present document: 1081 RSVP itself has them. However, they may be exacerbated here by the 1082 fact that each aggregate reservation typically facilitates 1083 communication for many sessions. Hence compromising one such 1084 aggregate reservation can result in more damage than compromising a 1085 typical E2E reservation. Use of the RSVP Authentication mechanisms to 1086 protect against such attacks has been discussed above. 1088 Generic Aggregate RSVP Reservations February 2007 1090 An additional security consideration specific to RSVP aggregation 1091 involves the modification of the IP protocol number in RSVP Path 1092 messages that traverse an aggregation region. Malicious modification 1093 of the IP protocol number in a Path message would cause the message 1094 to be ignored by all subsequent RSVP devices on its path, preventing 1095 reservations from being made. It could even be possible to correct 1096 the value before it reached the receiver, making it difficult to 1097 detect the attack. Note that in theory, it might also be possible for 1098 a node to modify the IP protocol number for non-RSVP messages as 1099 well, thus interfering with the operation of other protocols. It is 1100 RECOMMENDED that implementations of this specification only support 1101 modification of the IP protocol number for RSVP Path, PathTear, and 1102 ResvConf messages. That is, a general facility for modification of 1103 the IP protocol number SHOULD NOT be made available. 1105 Network operators deploying routers with RSVP aggregation capability 1106 should be aware of the risks of inappropriate modification of the IP 1107 protocol number and should take appropriate steps (physical security, 1108 password protection, etc.) to reduce the risk that a router could be 1109 configured by an attacker to perform malicious modification of the 1110 protocol number. 1112 7. IANA Considerations 1114 This document requests IANA to modify the RSVP parameters registry, 1115 'Class Names, Class Numbers, and Class Types' subregistry, and assign 1116 two new C-Types under the existing SESSION Class (Class number 1), as 1117 suggested below: 1119 Class 1120 Number Class Name Reference 1121 ------ ----------------------- --------- 1123 1 SESSION [RFC2205] 1125 Class Types or C-Types: 1127 xx GENERIC-AGGREGATE-IP4 [RFCXXXX] 1128 yy GENERIC-AGGREGATE-IP6 [RFCXXXX] 1130 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1131 number of this specification. Suggested values: xx=17, yy=18] 1133 This document also requests IANA to modify the RSVP parameters 1134 registry, 'Class Names, Class Numbers, and Class Types' subregistry, 1136 Generic Aggregate RSVP Reservations February 2007 1138 and assign one new Class Number for the SESSION-OF-INTEREST class and 1139 two new C-Types for that class, according to the following table 1140 below: 1142 Class 1143 Number Class Name Reference 1144 ------ ----------------------- --------- 1146 zzz SESSION-OF-INTEREST [RFCXXXX] 1148 Class Types or C-Types: 1150 aa GENERIC-AGG-IP4-SOI [RFCXXXX] 1151 bb GENERIC-AGG-IP6-SOI [RFCXXXX] 1153 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1154 number of this specification. Suggested values: zzz=132 aa=1, bb=2] 1156 These allocations are in accordance with [RSVP-MOD]. 1158 8. Acknowledgments 1160 This document borrows heavily from [RSVP-AGG]. It also borrows the 1161 concepts of Virtual Destination Port and Extended Virtual Destination 1162 Port respectively from [RSVP-IPSEC] and [RSVP-TE]. 1164 Also, we thank Fred Baker, Roger Levesque, Carol Iturralde, Daniel 1165 Voce, Anil Agarwal, Alexander Sayenko and Anca Zamfir for their input 1166 into the content of this document. Thanks to Steve Kent for 1167 insightful comments on usage of RSVP reservations in IPsec 1168 environments. 1170 Ran Atkinson, Fred Baker, Luc Billot, Pascal Delprat and Eric Vyncke 1171 provided guidance and suggestions for the security considerations 1172 section. 1174 9. Normative References 1176 [IPSEC-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 1177 4303, December 2005. 1179 [PHB-ID] "Per Hop Behavior Identification Codes", Black et al., 1180 RFC3140, June 2001. 1182 [RSVP] "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1183 Specification", Braden et al, RFC2205. 1185 Generic Aggregate RSVP Reservations February 2007 1187 [RSVP-AGG] "Aggregation of RSVP for IPv4 and IPv6 Reservations", 1188 Baker et al, RFC3175. 1190 [RSVP-CRYPTO1] Baker at al, RSVP Cryptographic Authentication, RFC 1191 2747, January 2000. 1193 [RSVP-CRYPTO2] Braden and Zhang, RSVP Cryptographic Authentication - 1194 Updated Message Type Value, RFC 3097, April 2001. 1196 [RSVP-IPSEC] "RSVP Extensions for IPsec Data Flows", Berger et al, 1197 RFC2207. 1199 [RSVP-MOD] "Procedures for Modifying the Resource reSerVation 1200 Protocol (RSVP)", Kompella and Lang, RFC 3936, BCP 96. 1202 10. Informative References 1204 [BW-REDUC] "A Resource Reservation Extension for the Reduction of 1205 Bandwidth of a Reservation Flow", Polk et al, RFC 4495. 1207 [GRE] "Generic Routing Encapsulation (GRE) ", Farinacci et al, RFC 1208 2784. 1210 [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy 1211 Element", RFC 3181, October 2001. 1213 [RSVP-PROCESS] "Resource ReSerVation Protocol (RSVP) -- Version 1 1214 Message Processing Rules", Braden et al, RFC2209. 1216 [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, 1217 RFC 3209, December 2001. 1219 [RSVP-TUNNEL] "RSVP Operation Over IP Tunnels", Terzis et al., RFC 1220 2746, January 2000. 1222 [SIG-NESTED] "QoS Signaling in a Nested Virtual Private Network", 1223 Baker et al, draft-ietf-tsvwg-vpn-signaled-preemption, work in 1224 progress. 1226 11. Authors' Addresses 1228 Francois Le Faucheur 1229 Cisco Systems, Inc. 1230 Village d'Entreprise Green Side - Batiment T3 1231 400, Avenue de Roumanille 1232 06410 Biot Sophia-Antipolis 1234 Generic Aggregate RSVP Reservations February 2007 1236 France 1237 Email: flefauch@cisco.com 1239 Bruce Davie 1240 Cisco Systems, Inc. 1241 300 Beaver Brook Road 1242 Boxborough, MA 01719 1243 USA 1244 Email: bdavie@cisco.com 1246 Pratik Bose 1247 Lockheed Martin 1248 22300 Comsat Drive Clarksburg, MD 20814 1249 USA 1250 Email: pratik.bose@lmco.com 1252 Christou Christou 1253 Booz Allen Hamilton 1254 8283 Greensboro Drive 1255 McLean, VA 22102 1256 USA 1257 Email: christou_chris@bah.com 1259 Michael Davenport 1260 Booz Allen Hamilton 1261 8283 Greensboro Drive 1262 McLean, VA 22102 1263 USA 1264 Email: davenport_michael@bah.com 1266 Intellectual Property 1268 The IETF takes no position regarding the validity or scope of any 1269 Intellectual Property Rights or other rights that might be claimed to 1270 pertain to the implementation or use of the technology described in 1271 this document or the extent to which any license under such rights 1272 might or might not be available; nor does it represent that it has 1273 made any independent effort to identify any such rights. Information 1274 on the procedures with respect to rights in RFC documents can be 1275 found in BCP 78 and BCP 79. 1277 Copies of IPR disclosures made to the IETF Secretariat and any 1278 assurances of licenses to be made available, or the result of an 1279 attempt made to obtain a general license or permission for the use of 1281 Generic Aggregate RSVP Reservations February 2007 1283 such proprietary rights by implementers or users of this 1284 specification can be obtained from the IETF on-line IPR repository at 1285 http://www.ietf.org/ipr. 1287 The IETF invites any interested party to bring to its attention any 1288 copyrights, patents or patent applications, or other proprietary 1289 rights that may cover technology that may be required to implement 1290 this standard. Please address the information to the IETF at ietf- 1291 ipr@ietf.org. 1293 Full Copyright Statement 1295 Copyright (C) The IETF Trust (2007). 1297 This document is subject to the rights, licenses and restrictions 1298 contained in BCP 78, and except as set forth therein, the authors 1299 retain all their rights. 1301 D 1302 i 1303 c 1304 s 1305 l 1306 a 1307 m 1308 i 1309 r 1310 e 1312 This document and the information contained herein are provided on an 1313 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1314 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1315 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1316 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1317 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1318 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1320 Appendix A: Example Signaling Flow 1322 This Appendix does not provide additional specification. It only 1323 illustrates the specification detailed in section 4 through a 1324 possible flow of RSVP signaling messages. This flow assumes an 1325 environment where E2E reservations are aggregated over generic 1326 aggregate RSVP reservations. It illustrates a possible RSVP message 1327 flow that could take place in the successful establishment of a 1328 unicast E2E reservation which is the first between a given pair of 1329 Aggregator/Deaggregator. 1331 Generic Aggregate RSVP Reservations February 2007 1333 Aggregator Deaggregator 1335 E2E Path 1336 -----------> 1337 (1) 1338 E2E Path 1339 -------------------------------> 1340 (2) 1341 E2E PathErr(New-agg-needed,SOI=GAx) 1342 <---------------------------------- 1343 E2E PathErr(New-agg-needed,SOI=GAy) 1344 <---------------------------------- 1345 (3) 1346 AggPath(Session=GAx) 1347 -------------------------------> 1348 AggPath(Session=GAy) 1349 -------------------------------> 1350 (4) 1351 E2E Path 1352 -----------> 1353 (5) 1354 AggResv (Session=GAx) 1355 <------------------------------- 1356 AggResv (Session=GAy) 1357 <------------------------------- 1358 (6) 1359 AggResvConfirm (Session=GAx) 1360 ------------------------------> 1361 AggResvConfirm (Session=GAy) 1362 ------------------------------> 1363 (7) 1364 E2E Resv 1365 <--------- 1366 (8) 1367 E2E Resv (SOI=GAx) 1368 <----------------------------- 1369 (9) 1370 E2E Resv 1371 <----------- 1373 (1) The Aggregator forwards E2E Path into the aggregation region 1374 after modifying its IP Protocol Number to RSVP-E2E-IGNORE 1376 (2) Let's assume no Aggregate Path exists. To be able to accurately 1377 update the ADSPEC of the E2E Path, the Deaggregator needs the ADSPEC 1378 of Aggregate PATH. In this example the Deaggregator elects to 1379 instruct the Aggregator to set up Aggregate Path states for the two 1380 supported PHB-IDs. To do that, the Deaggregator sends two E2E PathErr 1382 Generic Aggregate RSVP Reservations February 2007 1384 messages with a New-Agg-Needed PathErr code. Both PathErr messages 1385 also contain a SESSION-OF-INTEREST (SOI) object. In the first E2E 1386 PathErr, the SOI contains a GENERIC-AGGREGATE SESSION (GAx) whose 1387 PHB-ID is set to x. In the second E2E PathErr, the SOI contains a 1388 GENERIC-AGGREGATE SESSION (GAy) whose PHB-ID is set to y. In both 1389 messages the GENERIC-AGGREGATE SESSION contains an interface- 1390 independent Deaggregator address inside the DestAddress and 1391 appropriate values inside the vDstPort and Extended vDstPort fields. 1393 (3) The Aggregator follows the request from the Deaggregator and 1394 signals an Aggregate Path for both GENERIC-AGGREGATE Sessions (GAx 1395 and GAy). 1397 (4) The Deaggregator takes into account the information contained in 1398 the ADSPEC from both Aggregate Path and updates the E2E Path ADSPEC 1399 accordingly. The Deaggregator also modifies the E2E Path IP Protocol 1400 Number to RSVP before forwarding it. 1402 (5) In this example, the Deaggregator elects to immediately proceed 1403 with establishment of generic aggregate reservations for both PHB-IDs. 1404 In effect, the Deaggregator can be seen as anticipating the actual 1405 demand of E2E reservations so that resources are available on 1406 the generic aggregate reservations when the E2E Resv requests arrive, 1407 in order to speed up establishment of E2E reservations. Assume 1408 also that the Deaggregator includes the optional Resv Confirm 1409 Request in these Aggregate Resv. 1411 (6) The Aggregator merely complies with the received ResvConfirm 1412 Request and returns the corresponding Aggregate ResvConfirm. 1414 (7) The Deaggregator has explicit confirmation that both Aggregate 1415 Resv are established. 1417 (8) On receipt of the E2E Resv, the Deaggregator applies the mapping 1418 policy defined by the network administrator to map the E2E Resv 1419 onto a generic aggregate reservation. Let's assume that this policy 1420 is such that the E2E reservation is to be mapped onto the generic 1421 aggregate reservation with PHB-ID=x. The Deaggregator knows that a 1422 generic aggregate reservation (GAx) is in place for the corresponding 1423 PHB-ID since (7). The Deaggregator performs admission control of the 1424 E2E Resv onto the generic aggregate Reservation for PHB-ID=x (GAx). 1425 Assuming that the generic aggregate reservation for PHB-ID=x (GAx) 1426 had been established with sufficient bandwidth to support the E2E 1427 Resv, the Deaggregator adjusts its counter, tracking the unused 1428 bandwidth on the generic aggregate reservation and forwards the E2E 1429 Resv to the Aggregator including a SESSION-OF-INTEREST object 1430 conveying the selected mapping onto GAx (and hence onto PHB-ID=x). 1432 Generic Aggregate RSVP Reservations February 2007 1434 (9) The Aggregator records the mapping of the E2E Resv onto GAx (and 1435 onto PHB-ID=x). The Aggregator removes the SOI object and forwards 1436 the E2E Resv towards the sender. 1438 Expires: August 13, 2007