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