idnits 2.17.1 draft-ietf-tsvwg-rsvp-ipsec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1012. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 996. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1002. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 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 document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 6) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RSVP-AGG], [RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 31 has weird spacing: '... and may be...' == Line 546 has weird spacing: '... inside the d...' -- 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 2006) is 6637 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: 'RFC2119' is mentioned on line 72, but not defined == Unused Reference: 'IPSEC-ARCH' is defined on line 916, but no explicit reference was found in the text == Unused Reference: 'DS-TUNNEL' is defined on line 919, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-tsvwg-vpn-signaled-preemption-00 ** Downref: Normative reference to an Informational draft: draft-ietf-tsvwg-vpn-signaled-preemption (ref. 'SIG-NESTED') ** Downref: Normative reference to an Informational RFC: RFC 2209 (ref. 'RSVP-PROCESS') ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC-ARCH') (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 2983 (ref. 'DS-TUNNEL') -- Unexpected draft version: The latest known version of draft-polk-tsvwg-rsvp-bw-reduction is -00, but you're referring to -01. Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Generic Aggregate RSVP Reservations February 2006 3 Internet Draft Francois Le Faucheur 4 Bruce Davie 5 Cisco Systems, Inc. 7 Pratik Bose 8 Lockheed Martin 10 Chris Christou 11 Michael Davenport 12 Booz Allen Hamilton 13 draft-ietf-tsvwg-rsvp-ipsec-00.txt 14 Expires: August 2006 February 2006 16 Generic Aggregate RSVP Reservations 17 draft-ietf-tsvwg-rsvp-ipsec-00.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 [RSVP-AGG] defines aggregate RSVP reservations allowing resources to 44 be reserved in a Diffserv network for a given DSCP from a given 45 source to a given destination. [RSVP-AGG] also defines how end-to-end 47 Generic Aggregate RSVP Reservations February 2006 49 RSVP reservations can be aggregated onto such aggregate reservations 50 when transiting through a Diffserv cloud. There are situations where 51 multiple such aggregate reservations are needed for the same source 52 IP address, destination IP address and DSCP. However, this is not 53 supported by the aggregate reservations defined in [RSVP-AGG]. In 54 order to support this, the present document defines a more flexible 55 type of aggregate RSVP reservations, referred to as generic aggregate 56 reservation. Multiple such generic aggregate reservations can be 57 established for a given DSCP from a given source IP address to a 58 given destination IP address. The generic aggregate reservations may 59 be used to aggregate end-to-end RSVP reservations. This document also 60 defines the procedures for such aggregation. The generic aggregate 61 reservations may also be used end-to-end directly by end-systems 62 attached to a Diffserv network. 64 Copyright Notice 65 Copyright (C) The Internet Society (2006). 67 Specification of Requirements 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 1. Introduction 75 [RSVP-AGG] defines RSVP aggregate reservations allowing resources to 76 be reserved in a Diffserv network for a flow characterized by its 3- 77 tuple . 79 [RSVP-AGG] also defines the procedures for aggregation of end-to-end 80 RSVP reservations onto such aggregate reservations when transiting 81 through a Diffserv cloud. Such aggregation is illustrated in Figure 1. 83 -------------------------- 84 / Aggregation \ 85 |----| | Region | |----| 86 H--| R |\ |-----| |------| /| R |-->H 87 H--| |\\| | |---| |---| | |//| |-->H 88 |----| \| | | I | | I | | |/ |----| 89 | Agg |======================>| Deag | 90 /| | | | | | | |\ 91 H--------//| | |---| |---| | |\\-------->H 92 H--------/ |-----| |------| \-------->H 93 | | 95 Generic Aggregate RSVP Reservations February 2006 97 \ / 98 -------------------------- 100 H = Host requesting end-to-end RSVP reservations 101 R = RSVP router 102 Agg = Aggregator 103 Deag = Deaggregator 104 I = Interior Router 106 --> = E2E RSVP reservation 107 ==> = Aggregate RSVP reservation 109 Figure 1 : Aggregation of E2E Reservations 110 over aggregate RSVP Reservations 112 These aggregate reservations use a SESSION type specified in [RSVP- 113 AGG] that contains the receiver (or Deaggregator) IP address and the 114 DSCP of the PHB from which Diffserv resources are to be reserved. For 115 example, in the case of IPv4, the SESSION object is specified as: 117 o IP4 SESSION object: Class = SESSION, 118 C-Type = RSVP-AGGREGATE-IP4 120 +-------------+-------------+-------------+-------------+ 121 | IPv4 Session Address (4 bytes) | 122 +-------------+-------------+-------------+-------------+ 123 | /////////// | Flags | ///////// | DSCP | 124 +-------------+-------------+-------------+-------------+ 126 These aggregate reservations use a SENDER_TEMPLATE and FILTER_SPEC 127 types specified in [RSVP-AGG] and which contains only the sender (or 128 Aggregator) IP address. For example, in the case of IPv4, the 129 SENDER_TEMPLATE is specified as: 131 o IP4 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE, 132 C-Type = RSVP-AGGREGATE-IP4 134 +-------------+-------------+-------------+-------------+ 135 | IPv4 Aggregator Address (4 bytes) | 136 +-------------+-------------+-------------+-------------+ 138 Thus it is possible to establish, from a given source IP address to a 139 given destination IP address, separate such aggregate reservations 140 for different DSCPs. However, from a given source IP address to a 142 Generic Aggregate RSVP Reservations February 2006 144 given IP destination address, only a single [RSVP-AGG] aggregate 145 reservation can be established for a given DSCP. 147 Situations have since been identified where multiple such aggregate 148 reservations are needed for the same source IP address, destination 149 IP address and DSCP. One example is where E2E reservations using 150 different preemption priorities (as per [RSVP-PREEMP]) need to be 151 aggregated through a Diffserv cloud using the same DSCP. Using 152 multiple aggregate reservations for the same DSCP allows enforcement 153 of the different preemption priorities within the aggregation region. 154 In turn this allows much more efficient management of the Diffserv 155 resources and in period of resource shortage allows to sustain a 156 larger number of E2E reservations with higher preemption priorities. 158 For example, [SIG-NESTED] discusses in details how end-to-end RSVP 159 reservations can be established in a nested VPN environment through 160 RSVP aggregation. In particular, [SIG-NESTED] describes how multiple 161 parallel generic aggregate reservations (for the same DSCP), each 162 with different preemption priorities, can be used to efficiently 163 support the preemption priorities of end-to-end reservations. 165 This document addresses this requirement for multiple aggregate 166 reservations for the same DSCP, by defining a more flexible type of 167 aggregate RSVP reservations, referred to as generic aggregate 168 reservations. This is achieved primarily by adding the notions of a 169 Virtual Destination Port and of an Extended Virtual Destination Port 170 in the RSVP Session object. 172 The notion of Virtual Destination Port was introduced in [RSVP-IPSEC] 173 to address a similar requirement (albeit in a different context) for 174 identification and demultiplexing of sessions beyond the IP 175 destination address. This document reuses this notion from [RSVP- 176 IPSEC] for identification and demultiplexing of generic aggregate 177 sessions beyond the IP destination address and DSCP. This allows 178 multiple generic aggregate reservations to be established for a given 179 DSCP, from a given source IP address to a given destination IP 180 address. 182 [RSVP-TE] introduced the concept of an Extended Tunnel ID (in 183 addition to the tunnel egress address and the Tunnel ID) in the 184 Session object used to establish MPLS Traffic Engineering tunnels 185 with RSVP. The Extended Tunnel ID provides a very convenient 186 mechanism for the tunnel ingress node to narrow the scope of the 187 session to the ingress-egress pair. The ingress node can achieve this 188 by using one of its own IP addresses as a globally unique identifier 189 and including it in the Extended Tunnel ID and therefore within the 190 Session object. This document reuses this notion of Extended Tunnel 191 ID from [RSVP-TE], simply renaming it Extended Virtual Destination 193 Generic Aggregate RSVP Reservations February 2006 195 Port, in order to provide a convenient mechanism to narrow the scope 196 of an generic aggregate session to an Aggregator-Deaggregator pair. 198 The generic aggregate reservations may be used to aggregate end-to- 199 end RSVP reservations. This document also defines the procedures for 200 such aggregation. These procedures are based on those of [RSVP-AGG] 201 and this document only specifies the differences with those. 203 The generic aggregate reservations may also be used end-to-end 204 directly by end-systems attached to a Diffserv network. 206 1.1. Related RFCs and Internet-Drafts 208 This document is heavily based on [RSVP-AGG]. It reuses [RSVP-AGG] 209 wherever applicable and specifies the necessary extensions beyond 210 [RSVP-AGG]. 212 The mechanisms defined in [BW-REDUC] allow an existing reservation to 213 be reduced in allocated bandwidth in lieu of tearing that reservation 214 down. These mechanisms are applicable to the generic aggregate 215 reservations defined in the present document. 217 [RSVP-TUNNEL] describes a general approach to running RSVP over 218 various types of tunnels. One of these types of tunnel, referred to 219 as a "type 2 tunnel", has some similarity with the generic aggregate 220 reservations described in this document. The similarity stems from 221 the fact that a single, aggregate reservation is made for the tunnel 222 while many individual flows are carried over that tunnel. However, 223 [RSVP-TUNNEL] does not address the use of Diffserv-based 224 classification and scheduling in the core of a network (between 225 tunnel endpoints), but rather relies on a UDP/IP tunnel header for 226 classification. This is why [RSVP-AGG] required additional objects 227 and procedures beyond those of [RSVP-TUNNEL]. Like [RSVP-AGG], this 228 document also assumes the use of Diffserv-based classification and 229 scheduling in the aggregation region and, thus, requires additional 230 objects and procedures beyond those of [RSVP-TUNNEL]. 232 As explained in section 1, this document reuses the notion of Virtual 233 Destination Port from [RSVP-IPSEC] and the notion of Extended Tunnel 234 ID from [RSVP-TE]. 236 1.2. Organization Of This Document 238 Section 2 defines the new RSVP objects related to generic aggregate 239 reservations. Section 3 describes the processing rules for handling 240 of generic aggregate reservations. Section 4 specifies the procedures 241 for aggregation of end to end RSVP reservations over generic 243 Generic Aggregate RSVP Reservations February 2006 245 aggregate RSVP reservations. Finally Section 5 provides example usage 246 of how the generic aggregate reservations may be used. 248 The IANA Considerations and the Security Considerations are discussed 249 in Section 6 and 7, respectively. 251 1.3. Change History 253 1.3.1. 254 Changes From draft-lefaucheur-rsvp-ipsec-02 To draft-ietf-tsvwg- 255 rsvp-ipsec-00 257 The most significant changes are: 259 o de-correlate the generic aggregate reservations from IPsec 260 operations, in line with comments from the Security experts 261 review. This significantly affects (and simplifies 262 considerably) the document in many places. 264 o add the notion of Extended Virtual Destination port (reusing 265 the notion of Extended Tunnel ID of [RSVP-TE]). 267 o added recommendations on use of IP addresses by Aggregator and 268 Deaggregator 270 1.3.2. 271 Changes From draft-lefaucheur-rsvp-ipsec-01 To draft-lefaucheur- 272 rsvp-ipsec-02 274 The most significant changes are: 276 o added text in section 4.2 about Aggregator/Deaggregator 277 responsibilities with respect to mapping of end-to-end 278 reservations onto aggregate reservations. The text also 279 clarified that DCLASS object is no longer needed in PathErr 280 message requesting new Aggregate Reservations 282 o Moved the text discussing details of the procedures to handle 283 dynamic update of SPI values from Security Considerations 284 section into a new section 4.4. 286 o updates to Security Considerations section to start addressing 287 some comments from Security experts review. 289 1.3.3. 290 Changes From draft-lefaucheur-rsvp-ipsec-00 To draft-lefaucheur- 291 rsvp-ipsec-01 293 The most significant change is the broadening of the applicability of 294 the new type of aggregate reservations beyond use for Aggregate 295 reservations for IPsec tunnels (to environments where IPsec is not 297 Generic Aggregate RSVP Reservations February 2006 299 used). This affects the document in multiple places including the 300 following changes: 302 o document renamed to "Generic Aggregate RSVP Reservations" 304 o added a subsection in Introduction to discuss a case where 305 Generic Aggregate RSVP Reservations are needed in non IPsec 306 environments 308 o added text about the fact that the Generic Aggregate 309 Reservations can be used with IP-in-IP and GRE encapsulation 310 (in addition to with IPsec AH and ESP) 312 o added example usage under Section 5 for environment where 313 IPsec is not used 315 The other significant changes are: 317 o added a subsection on the changes of the [RSVP-AGG] procedures 318 under Section 4 320 o added explanation about allocation of VDstPort values by 321 Deaggregator, in that same subsection 323 o added value of Protocol ID in all example generic aggregate 324 reservations in Section 5 326 2. Object Definition 328 This document defines two new objects under the SESSION Class and a 329 new object under a new AGGREGATION SESSION Class. 331 It reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP-AGGREGATE-IP6 332 FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE and RSVP-AGGREGATE- 333 IP6 SENDER_TEMPLATE objects defined in [RSVP-AGG]. 335 2.1. SESSION Class 337 o GENERIC-AGGREGATE-IPv4 SESSION object: 338 Class = 1 339 C-Type = To be allocated by IANA 341 0 7 8 15 16 23 24 31 342 +-------------+-------------+-------------+-------------+ 343 | IPv4 DestAddress (4 bytes) | 344 +-------------+-------------+-------------+--+----------+ 345 | Reserved | Flags | vDstPort |Rd| DSCP | 347 Generic Aggregate RSVP Reservations February 2006 349 +-------------+-------------+-------------+--+----------+ 350 | Extended vDstPort | 351 +-------------+-------------+-------------+-------------+ 352 0 7 8 15 16 23 24 31 354 IPv4 DestAddress (IPv4 Destination Address) 356 IPv4 address of the receiver (or Deaggregator) 358 Reserved 360 A 8-bit field. All bits MUST be set to 0 on transmit. This field 361 MUST be ignored on receipt. 363 VDstPort (Virtual Destination Port) 365 An 8-bit identifier used in the SESSION that remains constant 366 over the life of the generic aggregate reservation. 368 Rd (Reserved) 370 A 2-bit field. All bits MUST be set to 0 on transmit. This field 371 MUST be ignored on receipt. 373 DSCP (Diffserv Code Point) 375 A 6-bit field containing the DSCP of the PHB from which Diffserv 376 resources are to be reserved. 378 Extended vDstPort (Extended Virtual Destination Port) 380 A 32-bit identifier used in the SESSION that remains constant 381 over the life of the generic aggregate reservation. Normally set 382 to all zeros. A sender (or Aggregator) that wishes to narrow the 383 scope of a SESSION to the sender-receiver pair (or Aggregator- 384 Deaggregator pair) may place its IPv4 address here as a globally 385 unique identifier. 387 o GENERIC-AGGREGATE-IPv6 SESSION object: 388 Class = 1 389 C-Type = To be allocated by IANA 391 0 7 8 15 16 23 24 31 392 +-------------+-------------+-------------+-------------+ 394 Generic Aggregate RSVP Reservations February 2006 396 | | 397 + + 398 | | 399 + IPv6 DestAddress (16 bytes) + 400 | | 401 + + 402 | | 403 +-------------+-------------+-------------+--+----------+ 404 | Reserved | Flags | vDstPort |Rd| DSCP | 405 +-------------+-------------+-------------+--+----------+ 406 | | 407 + + 408 | Extended vDstPort | 409 + + 410 | (16 bytes) | 411 + + 412 | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 0 7 8 15 16 25 26 31 416 IPv6 DestAddress (IPv6 Destination Address) 418 IPv6 address of the receiver (or Deaggregator) 420 Reserved 422 A 8-bit field. All bits MUST be set to 0 on transmit. This field 423 MUST be ignored on receipt. 425 VDstPort (Virtual Destination Port) 427 A 8-bit identifier used in the SESSION that remains constant 428 over the life of the generic aggregate reservation. 430 Rd (Reserved) 432 A 2-bit field. All bits MUST be set to 0 on transmit. This field 433 MUST be ignored on receipt. 435 DSCP (Diffserv Code Point) 437 A 6-bit field containing the DSCP of the PHB from which Diffserv 438 resources are to be reserved 440 Generic Aggregate RSVP Reservations February 2006 442 Extended vDstPort (Extended Virtual Destination Port) 444 A 16-byte identifier used in the SESSION that remains constant 445 over the life of the generic aggregate reservation. Normally set 446 to all zeros. A sender (or Aggregator) that wishes to narrow the 447 scope of a SESSION to the sender-receiver pair (or Aggregator- 448 Deaggregator pair) may place its IPv6 address here as a globally 449 unique identifier. 451 2.2. AGGREGATION-SESSION Class 453 o IPv4-AGGREGATION-SESSION object: 454 Class = To be allocated by IANA 455 C-Type = To be allocated by IANA 457 0 7 8 15 16 23 24 31 458 +-------------+-------------+-------------+-------------+ 459 | Length (bytes) | Class-Num | C-Type | 460 +-------------+-------------+-------------+-------------+ 461 | | 462 // SESSION Object // 463 | | 464 +-------------+-------------+-------------+-------------+ 466 o IPv6-AGGREGATION-SESSION object: 467 Class = To be allocated by IANA (same as for 468 IPv4-AGGREGATION-SESSION) 469 C-Type = To be allocated by IANA 471 0 7 8 15 16 23 24 31 472 +-------------+-------------+-------------+-------------+ 473 | Length (bytes) | Class-Num | C-Type | 474 +-------------+-------------+-------------+-------------+ 475 | | 476 // SESSION Object // 477 | | 478 +-------------+-------------+-------------+-------------+ 480 For example, if the AGGREGATION-SESSION object is used to indicate 481 that the Aggregate Session needed is a GENERIC-AGGREGATE-IPv4 SESSION 482 then the AGGREGATION-SESSION will be encoded like this: 484 0 7 8 15 16 23 24 31 485 +-------------+-------------+-------------+-------------+ 486 | |IPv4-AGGR-SES|IPv4-AGGR-SES| 488 Generic Aggregate RSVP Reservations February 2006 490 | Length (bytes) | Class-Num | C-Type | 491 +-------------+-------------+-------------+-------------+ 492 | IPv4 DestAddress (4 bytes) | 493 +-------------+-------------+-------------+--+----------+ 494 | Reserved | Flags | vDstPort | DSCP | 495 +-------------+-------------+-------------+--+----------+ 496 | Extended vDstPort | 497 +-------------+-------------+-------------+-------------+ 498 0 7 8 15 16 23 24 31 500 3. Processing Rules For Handling Generic Aggregate RSVP Reservations 502 This section presents additions to the Processing Rules presented in 503 [RSVP-PROCESS]. These additions are required in order to properly 504 process the GENERIC-AGGREGATE-IPv4 (resp. GENERIC-AGGREGATE-IPv6) 505 SESSION object and the RSVP-AGGREGATE-IP4 (resp. RSVP-AGGREGATE-IP6) 506 FILTER_SPEC object. Values for referenced error codes can be found in 507 [RSVP]. As with the other RSVP documents, values for internally 508 reported (API) errors are not defined. 510 When referring to the new GENERIC-AGGREGATE-IPv4 and GENERIC- 511 AGGREGATE-IPv6 SESSION objects, IP version will not be included and 512 they will be referred to simply as GENERIC-AGGREGATE SESSION, unless 513 a specific distinction between IPv4 and IPv6 is being made. 515 When referring to the [RSVP-AGG] RSVP-AGGREGATE-IP4 and 516 RSVP-AGGREGATE-IP6 SESSION, FILTER_SPEC and SENDER_TEMPLATE objects, 517 IP version will not be included and they will be referred to simply 518 as RSVP-AGGREGATE, unless a specific distinction between IPv4 and 519 IPv6 is being made. 521 3.1. Required Changes to Path and Resv Processing 523 Both RESV and PATH processing will need to be changed to support the 524 new objects. 526 The following PATH message processing changes are required: 528 o When a session is defined using the GENERIC-AGGREGATE SESSION 529 object, only the [RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATE may 530 be used. When this condition is violated in a PATH message 531 received by an RSVP end-station, the RSVP end-station SHOULD 532 report a "Conflicting C-Type" API error to the application. 533 When this condition is violated in a PATH message received by 534 an RSVP router, the RSVP router MUST consider this as a 535 message formatting error. 537 Generic Aggregate RSVP Reservations February 2006 539 o For PATH messages that contain the GENERIC-AGGREGATE SESSION 540 object, the VDstPort value, the Extended VDstPort value and 541 the DSCP value should be recorded (in addition to the 542 destination/Deaggregator address and source/aggregator 543 address). These values form part of the recorded state of the 544 session. The DSCP may need to be passed to traffic control; 545 however the vDstPort and Extended VDstPort are not passed to 546 traffic control since they do not appear inside the data 547 packets of the corresponding reservation. 549 The changes to RESV message processing are: 551 o When a RESV message contains a [RSVP-AGG] RSVP-AGGREGATE 552 FILTER_SPEC, the session MUST be defined using either the 553 RSVP-AGGREGATE SESSION object (as per [RSVP-AGG]) or the 554 GENERIC-AGGREGATE SESSION object (as per this document). If 555 this condition is not met, an RSVP router or end-station MUST 556 consider that there is a message formatting error. 558 o When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION 559 type is GENERIC-AGGREGATE, each node MAY have a data 560 classifier installed for the flow: 562 * If the node needs to perform fine-grain classification (for 563 example to perform fine-grain policing on ingress at a trust 564 boundary) then the node MUST create a data classifier 565 described by the 3-tuple . 567 Note that if multiple reservations are established with 568 different Virtual Destination Ports (and/or different 569 Extended Virtual Destination Ports) but with the same 570 , then those cannot be 571 distinguished by the classifier. If the router is using the 572 classifier for policing purposes, the router will therefore 573 police those together and MUST program the policing rate to 574 the sum of the reserved rate across all the corresponding 575 reservations. 577 * If the node only needs to perform Diffserv classification 578 (for example inside the aggregation domain downstream of the 579 trust boundary) then the node MUST rely on the Diffserv data 580 classifier based on the DSCP only. 582 4. Procedures for Aggregation over Generic Aggregate RSVP Reservations 584 The procedures for Aggregation of E2E Reservations over Generic 585 Aggregate RSVP Reservations are the same as the procedures specified 587 Generic Aggregate RSVP Reservations February 2006 589 in [RSVP-AGG] with the exceptions of the procedure changes listed in 590 this section. 592 As specified in [RSVP-AGG], the Deaggregator is responsible for 593 mapping a given E2E reservation on a given aggregate reservation. The 594 Deaggregator requests establishment of a new aggregate reservation by 595 sending to the Aggregator an E2E PathErr message with an error code 596 of NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the Deaggregator conveys the 597 DSCP of the new requested aggregate reservation by including a DCLASS 598 Object in the E2E PathErr and encoding the corresponding DSCP inside. 599 This document modifies and extends this procedure. The Deaggregator 600 MUST include in the E2E PathErr message an AGGREGATION-SESSION object 601 which contains the Session to be used for establishment of the 602 requested generic aggregate reservation. Since the AGGREGATION- 603 SESSION object contains the DSCP, the DCLASS object need not be 604 included in the PathErr message. 606 Note that the Deaggregator can easily ensure that different 607 Aggregators use different sessions for their Aggregate Path towards a 608 given Deaggregator. This is because the Deaggregator can easily 609 select VDstPort and/or Extended VDstPort numbers which are different 610 for each Aggregator (for example by using the Aggregator address as 611 the Extended VDstPort) and can communicate those inside the 612 AGGREGATION-SESSION object. This provides an easy solution to 613 establish separate reservations from every Aggregator to a given 614 Deaggregator. Conversely, if reservation sharing were needed across 615 multiple Aggregators, the Deaggregator could facilitate this by 616 allocating the same VDstPort and Extended VDstPort to the multiple 617 Aggregators and thus including the same AGGREGATION-SESSION object in 618 the E2E PathErr messages sent to these Aggregators. The Aggregators 619 could then all establish an Aggregate Path with the same Session. 621 Therefore various sharing scenarios can easily be supported. Policies 622 followed by the Deaggregator to determine which aggregators need 623 shared or separate reservations are beyond the scope of this document. 625 The Deaggregator MAY also include in the E2E PathErr message (with an 626 error code of NEW-AGGREGATE-NEEDED) additional RSVP objects which are 627 to be used for establishment of the new needed generic aggregate 628 reservation. For example, the Deaggregator MAY include in the E2E 629 PathErr an RSVP Signaled Preemption Priority Policy Element (as 630 specified in [RSVP-PREEMP]. 632 The [RSVP-AGG] procedures for processing of an E2E PathErr message 633 with an error code of NEW-AGGREGATE-NEEDED by the Aggregator are 634 extended correspondingly. On receipt of such a message containing an 635 AGGREGATION-SESSION object, the Aggregator MUST use the Session 636 provided in the AGGREGATION-SESSION object to trigger establishment 637 of a generic aggregate reservation. The Aggregator MUST use the 639 Generic Aggregate RSVP Reservations February 2006 641 DestAddress found in the AGGREGATION-SESSION object as the 642 destination of the Aggregate Path. When an RSVP Signaled Preemption 643 Priority Policy Element is contained in the received E2E PathErr 644 message, the Aggregator MUST include this object in the Aggregate 645 Path for the corresponding generic aggregate reservation. When other 646 additional objects are contained in the received E2E PathErr message 647 and those can be unambiguously interpreted as related to the new 648 needed generic aggregate reservation (as opposed to related to the 649 E2E reservation), the Aggregator SHOULD include those in the 650 Aggregate Path for the corresponding generic aggregate reservation. 651 The Aggregator MUST use as the Source Address (i.e. as the Aggregator 652 Address) for the generic aggregate reservation, the address it uses 653 to identify itself as the PHOP when forwarding the E2E Path messages 654 corresponding to the E2E PathErr message. 656 The Deaggregator follows the same procedures as described in [RSVP- 657 AGG] for establishing, maintaining and clearing the aggregate Resv 658 state. However, in this document, the Deaggregator MUST use the 659 generic aggregate reservations and hence use the GENERIC-AGGREGATE 660 SESSION specified earlier in this document. 662 This document also modifies the procedures of [RSVP-AGG] related to 663 exchange of E2E Resv messages between Deaggregator and Aggregator. 664 The Deaggregator MUST include the new AGGREGATION-SESSION object in 665 the E2E Resv message, in order to convey to the Aggregator which 666 aggregate session to map a given E2E reservation onto. Again, since 667 the AGGREGATION-SESSION object contains the DSCP, the DCLASS object 668 need not be included in the E2E Resv message. The Aggregator MUST 669 interpret the AGGREGATION-SESSION object in the E2E Resv as 670 indicating which generic aggregate reservation session the 671 corresponding E2E reservation is mapped onto. 673 [RSVP-AGG] describes how the Aggregator and Deaggregator can 674 communicate their respective identity to each other. For example the 675 Aggregator includes one of its IP addresses in the RSVP HOP object in 676 the E2E Path which is transmitted downstream and received by the 677 Deaggregator once it traversed the aggregation region. Similarly, the 678 Deaggregator identifies itself to the Aggregator by including one of 679 its IP addresses in various fields, including the ERROR SPECIFICATION 680 of the E2E PathErr message (containing the NEW-AGGREGATE-NEEDED Error 681 Code), in the AGGREGATION-SESSION object included in the same E2E 682 PathErr message and in the RSVP HOP object of the E2E Resv message. 683 However, [RSVP-AGG] does not discuss which IP addresses are to be 684 selected by the aggregator and Deaggregator for such purposes. 685 Because these addresses are intended to identify the Aggregator and 686 Deaggregator and not to identify any specific interface on these 687 devices, this document RECOMMENDS that the Aggregator and 688 Deaggregator SHOULD use interface-independent addresses (for example 689 a loopback address) whenever they communicate their respective 691 Generic Aggregate RSVP Reservations February 2006 693 identity to each other. This ensures that respective identification 694 of the Aggregator and Deaggregator by any interface state change on 695 these devices. In turns this results in more stable operations and 696 considerably reduced RSVP signaling in the aggregation region. For 697 example, if interface-independent addresses are used by the 698 Aggregator and the Deaggregator, then a failure of an interface on 699 these devices may simply result in the rerouting of a given generic 700 aggregate reservation but will not result in the generic aggregate 701 reservation having to be torn down and another one established, nor 702 will it result in a change of mapping of E2E reservations on generic 703 aggregate reservations (assuming the Aggregator and Deaggregator 704 still have reachability after the failure and the Aggregator and 705 Deaggregator are still on the shortest path to the destination). 707 However, when identifying themselves to real RSVP neighbors (i.e. 708 neighbors which are not on the other side of the aggregation region), 709 the Aggregator and Deaggregator SHOULD continue using interface- 710 dependent addresses as per regular [RSVP] procedures. This applies 711 for example when the Aggregator identifies itself downstream as a 712 PHOP for the generic aggregate reservation or identifies itself 713 upstream as a NHOP for an E2E reservation. This also applies when the 714 Deaggregator identifies itself downstream as a PHOP for the E2E 715 reservation or identifies itself upstream as a NHOP for the generic 716 aggregate reservation. As part of the processing of generic aggregate 717 reservations, interior routers (i.e. routers within the aggregation 718 region) SHOULD continue using interface-dependent address as per 719 regular [RSVP] procedures. 721 More generally, within the aggregation region (ie between Aggregator 722 and Deaggregator) the operation of RSVP should be modeled with the 723 notion that E2E reservations are mapped to aggregate reservations and 724 are no longer tied to physical interfaces (as was the case with 725 regular RSVP). However, generic aggregate reservations (within the 726 aggregation region) as well as E2E reservations outside the 727 aggregation region, retain the model of regular RVSP and remain tied 728 to physical interfaces. 730 5. Example Usage Of Multiple Generic Aggregate Reservations Per DSCP 731 From a Given Aggregator to a Given Deaggregator 733 Let us consider the environment depicted in Figure 2 below. RSVP 734 aggregation is used to support E2E reservations between Cloud-1, 735 Cloud-2 and Cloud-3. 737 I----------I I----------I 738 I Cloud-1 I I Cloud-2 I 739 I----------I I----------I 741 Generic Aggregate RSVP Reservations February 2006 743 | | 744 Agg-Deag-1------------ Agg-Deag-2 745 / \ 746 / Aggregation | 747 | Region | 748 | | 749 | ---/ 750 \ / 751 \Agg-Deag-3---------/ 752 | 753 I----------I 754 I Cloud-3 I 755 I----------I 757 Figure 2 : Example Usage of 758 Generic Aggregate IP Reservations 760 Let us assume that: 762 o the E2E reservations from Cloud-1 to Cloud-3 have a preemption 763 of either P1 or P2 765 o the E2E reservations from Cloud-2 to Cloud-3 have a preemption 766 of either P1 or P2 768 o the E2E reservations are only for Voice (which needs to be 769 treated in the aggregation region using the EF PHB) 771 o traffic from the E2E reservations is encapsulated in Aggregate 772 IP reservations from Aggregator to Deaggregator using GRE 773 tunneling ([GRE]). 775 Then, the following generic aggregate RSVP reservations may be 776 established from Agg-Deag-1 to Agg-Deag-3 for aggregation of the end- 777 to-end RSVP reservations: 779 A first generic aggregate reservation for aggregation of Voice 780 reservations from Cloud-1 to Cloud-3 requiring use of P1: 782 * GENERIC-AGGREGATE-IPv4 SESSION= 783 IPv4 DestAddress= Agg-Deag-3 784 vDstPort=V1 785 DSCP=EF 786 Extended VDstPort= Agg-Deag-1 788 * STYLE=FF or SE 790 * IPv4/GPI FILTER_SPEC= 792 Generic Aggregate RSVP Reservations February 2006 794 IPv4 SrcAddress= Agg-Deag-1 796 * POLICY_DATA (PREEMPTION_PRI)=P1 798 A second generic aggregate reservation for aggregation of Voice 799 reservations from Cloud-1 to Cloud-3 requiring use of P2: 801 * GENERIC-AGGREGATE-IPv4 SESSION=Agg-Deag-3/V2/EF 802 IPv4 DestAddress= Agg-Deag-3 803 vDstPort=V2 804 DSCP=EF 805 Extended VDstPort= Agg-Deag-1 807 * STYLE=FF or SE 809 * IPv4/GPI FILTER_SPEC 810 IPv4 SrcAddress= Agg-Deag-1 812 * POLICY_DATA (PREEMPTION_PRI)=P2 814 where V1 and V2 are arbitrary VDstPort values picked by Agg-Deag-3. 816 The following generic aggregate RSVP reservations may be established 817 from Agg-Deag-2 to Agg-Deag-3 for aggregation of the end-to-end RSVP 818 reservations: 820 A third generic aggregate reservation for aggregation of Voice 821 reservations from Cloud-2 to Cloud-3 requiring use of P1: 823 * GENERIC-AGGREGATE-IPv4 SESSION 824 IPv4 DestAddress= Agg-Deag-3 825 vDstPort=V3 826 DSCP=EF 827 Extended VDstPort= Agg-Deag-2 829 * STYLE=FF or SE 831 * IPv4/GPI FILTER_SPEC 832 IPv4 SrcAddress= Agg-Deag-2 834 * POLICY_DATA (PREEMPTION_PRI)=P1 836 A fourth generic aggregate reservation for aggregation of Voice 837 reservations from Cloud-2 to Cloud-3 requiring use of P2: 839 * GENERIC-AGGREGATE-IPv4 SESSION 840 IPv4 DestAddress= Agg-Deag-3 841 vDstPort=V4 842 DSCP=EF 844 Generic Aggregate RSVP Reservations February 2006 846 Extended VDstPort= Agg-Deag-2 848 * STYLE=FF or SE 850 * IPv4/GPI FILTER_SPEC=Agg-Deag-2 851 IPv4 SrcAddress= Agg-Deag-2 853 * POLICY_DATA (PREEMPTION_PRI)=P2 855 where V1 and V4 are arbitrary VDstPort values picked by Agg-Deag-3. 856 Note that V3 and V4 could be equal to V1 and V2 since, in this 857 example, the Extended VDstPort of the GENERIC-AGGREGATE Session 858 contains the address of the Deaggregator and, thus, ensures that 859 different sessions are used for each Deaggregator. 861 6. Security Considerations 863 The security considerations associated with the RSVP protocol [RSVP] 864 apply to this document as it relies on RSVP. 866 When generic aggregate reservations are used for aggregation of E2E 867 reservations, the security considerations discussed in [RSVP-AGG] 868 apply. 870 The security considerations discussed in [SIG-NESTED] apply when the 871 generic aggregate reservations are used in the presence of IPsec 872 gateways. 874 7. IANA Considerations 876 This document requests that IANA allocates two new C-Types under the 877 Class 1 for the two new RSVP objects (GENERIC-AGGREGATE-IPv4 SESSION 878 and GENERIC-AGGREGATE-IPv6 SESSION) defined in section 2.1. 880 This document also requests that IANA allocates one new Class-Num and 881 two new C-Types for the two new RSVP objects (IPv4-AGGREGATION- 882 SESSION and IPv6-AGGREGATION-SESSION) defined in section 2.2. 884 8. Acknowledgments 886 This document borrows heavily from [RSVP-AGG]. It also borrows the 887 concepts of Virtual Destination Port and Extended Virtual Destination 888 Port respectively from [RSVP-IPSEC] and [RSVP-TE]. 890 Also, we thank Fred Baker, Roger Levesque, Carol Iturralde, Daniel 892 Generic Aggregate RSVP Reservations February 2006 894 Voce and Anil Agarwal for their input into the content of this 895 document. Thanks to Steve Kent for insightful comments on usage of 896 RSVP reservations in IPsec environments. 898 9. Normative References 900 [RSVP] "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 901 Specification", Braden et al, RFC2205 903 [RSVP-IPSEC] "RSVP Extensions for IPsec Data Flows", Berger et al, 904 RFC2207 906 [RSVP-AGG] "Aggregation of RSVP for IPv4 and IPv6 Reservations", 907 Baker et al, RFC3175 909 [SIG-NESTED] "QoS Signaling in a Nested Virtual Private Network", 910 Baker et al, draft-ietf-tsvwg-vpn-signaled-preemption-00.txt, work in 911 progress 913 [RSVP-PROCESS] "Resource ReSerVation Protocol (RSVP) -- Version 1 914 Message Processing Rules", Braden et al, RFC2209 916 [IPSEC-ARCH] "Security Architecture for the Internet Protocol", Kent 917 et al, RFC2401 919 [DS-TUNNEL] "Differentiated Services and Tunnels", Black, RFC2983 921 [GRE] Generic Routing Encapsulation (GRE). Farinacci et al, RFC 2784 923 10. Informative References 925 [BW-REDUC] "A Resource Reservation Extension for the Reduction of 926 andwidth of a Reservation Flow", Polk et al, draft-polk-tsvwg-rsvp- 927 bw-reduction-01.txt, work in progress 929 [RSVP-TUNNEL] "RSVP Operation Over IP Tunnels", Terzis et al., RFC 930 2746, January 2000. 932 [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy 933 Element", RFC 3181, October 2001. 935 [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, 936 RFC 3209, December 2001. 938 11. Authors Address: 940 Generic Aggregate RSVP Reservations February 2006 942 Francois Le Faucheur 943 Cisco Systems, Inc. 944 Village d'Entreprise Green Side - Batiment T3 945 400, Avenue de Roumanille 946 06410 Biot Sophia-Antipolis 947 France 948 Email: flefauch@cisco.com 950 Bruce Davie 951 Cisco Systems, Inc. 952 300 Beaver Brook Road 953 Boxborough, MA 01719 954 USA 955 Email: bdavie@cisco.com 957 Pratik Bose 958 Lockheed Martin 959 22300 Comsat Drive Clarksburg, MD 20814 960 USA 961 Email: pratik.bose@lmco. com 963 Christou Christou 964 Booz Allen Hamilton 965 8283 Greensboro Drive 966 McLean, VA 22102 967 USA 968 Email: christou_chris@bah.com 970 Michael Davenport 971 Booz Allen Hamilton 972 8283 Greensboro Drive 973 McLean, VA 22102 974 USA 975 Email: davenport_michael@bah.com 977 12. IPR Statements 979 The IETF takes no position regarding the validity or scope of any 980 Intellectual Property Rights or other rights that might be claimed to 981 pertain to the implementation or use of the technology described in 982 this document or the extent to which any license under such rights 983 might or might not be available; nor does it represent that it has 984 made any independent effort to identify any such rights. Information 986 Generic Aggregate RSVP Reservations February 2006 988 on the procedures with respect to rights in RFC documents can be 989 found in BCP 78 and BCP 79. 991 Copies of IPR disclosures made to the IETF Secretariat and any 992 assurances of licenses to be made available, or the result of an 993 attempt made to obtain a general license or permission for the use of 994 such proprietary rights by implementers or users of this 995 specification can be obtained from the IETF on-line IPR repository at 996 http://www.ietf.org/ipr. 998 The IETF invites any interested party to bring to its attention any 999 copyrights, patents or patent applications, or other proprietary 1000 rights that may cover technology that may be required to implement 1001 this standard. 1002 Please address the information to the IETF at ietf-ipr@ietf.org. 1004 13. Disclaimer of Validity 1006 This document and the information contained herein are provided on an 1007 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1008 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1009 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1010 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1011 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1012 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1014 14. Copyright Notice 1016 Copyright (C) The Internet Society (2005). This document is subject 1017 to the rights, licenses and restrictions contained in BCP 78, and 1018 except as set forth therein, the authors retain all their rights.