idnits 2.17.1 draft-ietf-tsvwg-rsvp-pcn-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 374 has weird spacing: '...croflow a m...' == Line 573 has weird spacing: '...rvation match...' == Line 577 has weird spacing: '...he same combi...' -- The document date (October 6, 2014) is 3483 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Georgios Karagiannis 2 Internet-Draft Huawei Technologies 3 Intended status: Experimental Anurag Bhargava 4 Expires: April 6, 2015 Cisco Systems, Inc. 5 October 6, 2014 7 Generic Aggregation of Resource ReSerVation Protocol (RSVP) 8 for IPv4 And IPv6 Reservations over PCN domains 9 draft-ietf-tsvwg-rsvp-pcn-11 11 Abstract 13 This document specifies extensions to Generic Aggregated RSVP 14 RFC 4860 for support of the PCN Controlled Load (CL) and Single 15 Marking (SM) edge behaviors over a Diffserv cloud using Pre- 16 Congestion Notification. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 6, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Overview and Motivation . . . . . . . . . . . . . . . . . . . 5 60 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1.4. Organization of This Document . . . . . . . . . . . . . . . . 11 62 2. Overview of RSVP extensions and Operations . . . . . . . . . . . 11 63 2.1. Overview of RSVP Aggregation Procedures in PCN domains . . . . . 11 64 2.2. PCN Marking and encoding and transport of pre-congestion 65 Information . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 2.3. Traffic Classification Within The Aggregation Region . . . . . . 13 67 2.4. Deaggregator (PCN-egress-node) Determination . . . . . . . . . . 13 68 2.5. Mapping E2E Reservations Onto Aggregate Reservations . . . . . . 13 69 2.6 Size of Aggregate Reservations . . . . . . . . . . . . . . . . . 14 70 2.7. E2E Path ADSPEC update . . . . . . . . . . . . . . . . . . . . . 14 71 2.8. Intra-domain Routes . . . . . . . . . . . . . . . . . . . . . . .14 72 2.9. Inter-domain Routes . . . . . . . . . . . . . . . . . . . . . . 15 73 2.10. Reservations for Multicast Sessions . . . . . . . . . . . . . . 15 74 2.11. Multi-level Aggregation . . . . . . . . . . . . . . . . . . . . 15 75 2.12. Reliability Issues . . . . . . . . . . . . . . . . . . . . . . 15 76 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . . . 15 77 3.1. Receipt of E2E Path Message by PCN-ingress-node 78 (aggregating router) . . . . . . . . . . . . . . . . . . . . . . 15 79 3.2. Handling Of E2E Path Message by Interior Routers . . . . . . . 16 80 3.3. Receipt of E2E Path Message by PCN-egress-node 81 (deaggregating router) . . . . . . . . . . . . . . . . . . . . . 16 82 3.4. Initiation of new Aggregate Path Message By PCN-ingress-node 83 (Aggregating Router) . . . . . . . . . . . . . . . . . . . . . 16 84 3.5. Handling Of new Aggregate Path Message by Interior Routers . . 16 85 3.6 Handling Of Aggregate Path Message by Deaggregating Router . . 16 86 3.7. Handling of E2E Resv Message by Deaggregating Router . . . . . 17 87 3.8. Handling Of E2E Resv Message by Interior Routers . . . . . . . 17 88 3.9. Initiation of New Aggregate Resv Message By Deaggregating Router 17 89 3.10. Handling of Aggregate Resv Message by Interior Routers . . . 18 90 3.11. Handling of E2E Resv Message by Aggregating Router . . . . . . 18 91 3.12. Handling of Aggregated Resv Message by Aggregating Router . . 18 92 3.13. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 19 93 3.14. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 19 94 3.15. Handling of Data On Reserved E2E Flow by Aggregating Router . 19 95 3.16. Procedures for Multicast Sessions . . . . . . . . . . . . . . 19 96 3.17. Misconfiguration of PCN node . . . . . . . . . . . . . . . . 19 97 3.18. PCN based Flow Termination . . . . . . . . . . . . . . . . . 19 98 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 20 99 4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 23 101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24 102 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 24 104 9. Informative References . . . . . . . . . . . . . . . . . . . . . 25 105 10. Appendix A: Example Signaling Flow . . . . . . . . . . . . . . . 26 106 11. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 29 107 1. Introduction 109 1.1 Objective 111 Pre-Congestion Notification (PCN) can support the quality of service 112 (QoS) of inelastic flows within a Diffserv domain in a simple, 113 scalable, and robust fashion. Two mechanisms are used: admission 114 control and flow termination. Admission control is used to decide 115 whether to admit or block a new flow request, while flow termination 116 is used in abnormal circumstances to decide whether to terminate some 117 of the existing flows. To support these two features, the overall 118 rate of PCN-traffic is metered on every link in the domain, and PCN- 119 packets are appropriately marked when certain configured rates are 120 exceeded. These configured rates are below the rate of the link, 121 thus providing notification to boundary nodes about overloads before 122 any congestion occurs (hence "pre-congestion" notification). The 123 PCN-egress-nodes measure the rates of differently marked PCN traffic 124 in periodic intervals and report these rates to the Decision Points 125 for admission control and flow termination; the Decision Points use 126 these rates to make decisions. The Decision Points may be collocated 127 with the PCN-ingress-nodes, or their function may be implemented in a 128 another node. For more details see [RFC5559], [RFC6661], and 129 [RFC6662]. 131 The main objective of this document is to specify the signaling 132 protocol that can be used within a Pre-Congestion Notification (PCN) 133 domain to carry reports from a PCN-ingress-node to a PCN Decision 134 point, considering that the PCN Decision Point and PCN-egress-node 135 are collocated. 136 If the PCN Decision Point is not collocated with the PCN-egress-node 137 then additional signaling procedures are required that are out of 138 the scope of this document. Moreover, as mentioned above this 139 architecture conforms with PBAC (Policy-Based Admission Control), 140 when the Decision Point is located in a another node then the PCN- 141 ingress-node [RFC2753]. 143 Several signaling protocols can be used to carry information between 144 PCN-boundary-nodes (PCN-ingress-node and PCN-egress-node). However, 145 since (1) both PCN-egress-node and PCN-ingress-nodes are located on 146 the data path and (2) the admission control procedure needs to be 147 done at PCN-egress-node, a signaling protocol that follows the same 148 path as the data path, like RSVP (Resource Reservation Protocol), is 149 more suited for this purpose. In particular, this document specifies 150 extensions to Generic Aggregated RSVP [RFC4860] for support of the 151 PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over 152 a Diffserv cloud using Pre-Congestion Notification. 154 This draft is intended to be published as Experimental in order to: 156 o) validate industry interest by allowing implementation and 157 deployment 159 o) gather operational experience, in particular around dynamic 160 interactions of RSVP signaling and PCN notification and 161 corresponding levels of performance. 163 Support for the techniques specified in this document involves RSVP 164 functionality in boundary nodes of a PCN domain whose interior nodes 165 forward RSVP traffic without performing RSVP functionality. 167 1.2 Overview and Motivation 169 Two main Quality of Service (QoS) architectures have been specified 170 by the IETF. These are the Integrated Services (Intserv) [RFC1633] 171 architecture and the Differentiated Services (DiffServ) architecture 172 ([RFC2475]). 174 Intserv provides methods for the delivery of end-to-end Quality of 175 Service (QoS) to applications over heterogeneous networks. One of the 176 QoS signaling protocols used by the Intserv architecture is the 177 Resource reServation Protocol (RSVP) [RFC2205], which can be used by 178 applications to request per-flow resources from the network. These 179 RSVP requests can be admitted or rejected by the network. 180 Applications can express their quantifiable resource requirements 181 using Intserv parameters as defined in [RFC2211] and [RFC2212]. The 182 Controlled Load (CL) service [RFC2211] is a quality of service (QoS) 183 closely approximating the QoS that the same flow would receive from a 184 lightly loaded network element. The CL service is useful for 185 inelastic flows such as those used for real-time media. 187 The DiffServ architecture can support the differentiated treatment of 188 packets in very large scale environments. While Intserv and RSVP 189 classify packets per-flow, Diffserv networks classify packets into 190 one of a small number of aggregated flows or "classes", based on the 191 Diffserv codepoint (DSCP) in the packet IP header. At each Diffserv 192 router, packets are subjected to a "per-hop behavior" (PHB), which is 193 invoked by the DSCP. The primary benefit of Diffserv is its 194 scalability, since the need for per-flow state and per-flow 195 processing, is eliminated. 197 However, DiffServ does not include any mechanism for communication 198 between applications and the network. Several solutions have been 199 specified to solve this issue. One of these solutions is Intserv over 200 Diffserv [RFC2998] including resource-based admission control (RBAC), 201 PBAC, assistance in traffic identification/classification, and 202 traffic conditioning. Intserv over Diffserv can operate over a 203 statically provisioned or a RSVP aware Diffserv region. When it is 204 RSVP aware, several mechanisms may be used to support dynamic 205 provisioning and topology-aware admission control, including 206 aggregate RSVP reservations, per-flow RSVP, or a bandwidth broker. 207 [RFC3175] specifies aggregation of Resource ReSerVation Protocol 208 (RSVP) end-to-end reservations over aggregate RSVP reservations. In 209 [RFC3175] the RSVP generic aggregated reservation is characterized by 210 a RSVP SESSION object using the 3-tuple . 213 Several scenarios require the use of multiple generic aggregate 214 reservations that are established for a given PHB from a given source 215 IP address to a given destination IP address, see [SIG-NESTED], 216 [RFC4860]. For example, multiple generic aggregate reservations 217 can be applied in the situation that multiple E2E reservations using 218 different preemption priorities need to be aggregated through a PCN- 219 domain using the same PHB. By using multiple aggregate reservations 220 for the same PHB, it allows enforcement of the different preemption 221 priorities within the aggregation region. This allows more efficient 222 management of the Diffserv resources, and in periods of resource 223 shortage, this allows sustainment of a larger number of E2E 224 reservations with higher preemption priorities. In particular, 225 [SIG-NESTED] discusses in detail how end-to-end RSVP reservations can 226 be established in a nested VPN environment through RSVP aggregation. 228 [RFC4860] provides generic aggregate reservations by extending 229 [RFC3175] to support multiple aggregate reservations for the same 230 source IP address, destination IP address, and PHB (or set of PHBs). 231 In particular, multiple such generic aggregate reservations can be 232 established for a given PHB from a given source IP address to a given 233 destination IP address. This is achieved by adding the concept of a 234 Virtual Destination Port and of an Extended Virtual Destination Port 235 in the RSVP SESSION object. In addition to this, the RSVP SESSION 236 object for generic aggregate reservations uses the PHB Identification 237 Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv 238 Code Point (DSCP) used in [RFC3175]. The PHB-ID is used to identify 239 the PHB, or set of PHBs, from which the Diffserv resources are to be 240 reserved. 241 The RSVP like signaling protocol required to carry (1) requests from 242 a PCN-egress-node to a PCN-ingress-node and (2) reports from a 243 PCN-ingress-node to a PCN-egress-node needs to follow the PCN 244 signaling requirements defined in [RFC6663]. In addition to 245 that the signaling protocol functionality supported by the PCN- 246 ingress-nodes and PCN-egress-nodes needs to maintain logical 247 aggregate constructs (i.e. ingress-egress-aggregate state) and be 248 able to map E2E reservations to these aggregate constructs. Moreover, 249 no actual reservation state is needed to be maintained inside the PCN 250 domain, i.e., the PCN-interior-nodes are not maintaining any 251 reservation state. 253 This can be accomplished by two possible approaches: 255 Approach (1): 257 o) adapting the RFC 4860 aggregation procedures to fit the PCN 258 requirements with as little change as possible over the RFC 4860 259 functionality 261 o) hence performing aggregate RSVP signaling (even if it is to be 262 ignored by PCN interior nodes) 264 o) using this aggregate RSVP signaling procedures to carry PCN 265 information between the PCN-boundary-nodes (PCN-ingress-node and 266 PCN-egress-node). 268 Approach (2): 270 o) adapting the RFC 4860 aggregation procedures to fit the PCN 271 requirements with more significant changes over RFC4860 (i.e. 272 the aspect of the procedures that have to do with maintaining 273 aggregate states and to do with mapping the E2E reservations to 274 aggregate constructs are kept, but the procedures that have to 275 do with the aggregate RSVP signaling and aggregate reservation 276 establishment/maintenance are dropped). 278 o) hence not performing aggregate RSVP signaling 280 o) piggy-backing of the PCN information inside the E2E RSVP 281 signaling. 283 Both approaches are probably viable, however, since the RFC 4860 284 operations have been thoroughly studied and implemented, it can be 285 considered that the RFC 4860 solution can better deal with the more 286 challenging situations (rerouting in the PCN domain, failure of an 287 PCN-ingress-node, failure of an PCN-egress-node, rerouting towards a 288 different edge, etc.). This is the reason for choosing Approach (1) 289 for the specification of the signaling protocol used to carry 290 PCN information between the PCN-boundary-nodes (PCN-ingress-node and 291 PCN-egress-node). 293 In particular, this document specifies extensions to Generic 294 Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) 295 and Single Marking (SM) edge behaviors over a Diffserv cloud using 296 Pre-Congestion Notification. 298 This document follows the PCN signaling requirements defined in 299 [RFC6663] and specifies extensions to Generic Aggregated RSVP 300 [RFC4860] for support of PCN edge behaviors as specified in 301 [RFC6661] and [RFC6662]. Moreover, this document specifies how RSVP 302 aggregation can be used to setup and maintain: (1) Ingress Egress 303 Aggregate (IEA) states at Ingress and Egress nodes and (2) generic 304 aggregation of RSVP end-to-end RSVP reservations over PCN (Congestion 305 and Pre-Congestion Notification) domains. 307 To comply with this specification, PCN-nodes MUST be able to 308 support the functionality specified in [RFC5670], [RFC5559], 309 [RFC6660], [RFC6661], [RFC6662]. Furthermore, the PCN-boundary-nodes 310 MUST support the RSVP generic aggregated reservation procedures 311 specified in [RFC4860] which are augmented with procedures specified 312 in this document. 314 1.3. Terminology 316 This document uses terms defined in [RFC4860], [RFC3175], [RFC5559], 317 [RFC5670], [RFC6661], [RFC6662]. 319 For readability, a number of definitions from [RFC3175] as well as 320 definitions for terms used in [RFC5559], [RFC6661], and [RFC6662] are 321 provided here, where some of them are augmented with new meanings: 323 Aggregator This is the process in (or associated with) the 324 router at the ingress edge of the aggregation region 325 (with respect to the end-to-end RSVP reservation) 326 and behaving in accordance with [RFC4860]. In this 327 document, it is also the PCN-ingress-node. It is 328 important to notice that in the context of this 329 document the Aggregator must be able to determine 330 the Deaggregator using the procedures specified in 331 Section 4 of [RFC4860] and in Section 1.4.2 of 332 [RFC3175]. 334 Congestion level estimate (CLE): 335 The ratio of PCN-marked to total PCN-traffic 336 (measured in octets) received for a given ingress- 337 egress-aggregate during a given measurement period. 338 The CLE is used to derive the PCN-admission-state 339 and is also used by the report suppression procedure 340 if report suppression is activated. 342 Deaggregator This is the process in (or associated with) the 343 router at the egress edge of the aggregation region 344 (with respect to the end-to-end RSVP reservation) 345 and behaving in accordance with [RFC4860]. In this 346 document, it is also the PCN-egress-node and 347 Decision Point. 349 E2E end to end 351 E2E Reservation This is an RSVP reservation such that: 353 (i) corresponding RSVP Path messages are initiated 354 upstream of the Aggregator and terminated 355 downstream of the Deaggregator, and 357 (ii) corresponding RSVP Resv messages are initiated 358 downstream of the Deaggregator and terminated 359 upstream of the Aggregator, and 361 (iii) this RSVP reservation is aggregated over an 362 Ingress Egress Aggregate (IEA) between the 363 Aggregator and Deaggregator. 364 An E2E RSVP reservation may be a per-flow 365 reservation, which in this document is only 366 maintained at the PCN-ingress-node and PCN-egress- 367 node. Alternatively, the E2E reservation may itself 368 be an aggregate reservation of various types (e.g., 369 Aggregate IP reservation, Aggregate IPsec 370 reservation, see [RFC4860]). As per regular RSVP 371 operations, E2E RSVP reservations are 372 unidirectional. 374 E2E microflow a microflow where its associated packets are being 375 forwarded on an E2E path. 377 Extended vDstPort (Extended Virtual Destination Port) 379 An identifier used in the SESSION that remains 380 constant over the life of the generic aggregate 381 reservation. The length of this identifier is 32- 382 bits when IPv4 addresses are used and 128 bits when 383 IPv6 addresses are used. 384 A sender(or Aggregator) that wishes to narrow the 385 scope of a SESSION to the sender-receiver pair (or 386 Aggregator-Deaggregator pair) should place its IPv4 387 or IPv6 address here as a network unique 388 identifier. A sender (or Aggregator) that wishes to 389 use a common session with other senders (or 390 Aggregators) in order to use a shared reservation 391 across senders (or Aggregators) must set this field 392 to all zeros. In this document, the Extended 393 vDstPort should contain the IPv4 or IPv6 address of 394 the Aggregator. 396 ETM-rate 397 The rate of excess-traffic-marked PCN-traffic 398 received at a PCN-egress-node for a given ingress- 399 egress-aggregate in octets per second. 401 Ingress-egress-aggregate (IEA): 402 The collection of PCN-packets from all PCN-flows 403 that travel in one direction between a specific pair 404 of PCN-boundary-nodes. In this document one RSVP 405 generic aggregated reservation is mapped to only 406 one ingress-egress-aggregate, while one 407 ingress-egress-aggregate is mapped to either 408 one or to more than one RSVP generic aggregated 409 reservations. PCN-flows and their PCN-traffic that 410 are mapped into a specific RSVP generic aggregated 411 reservation can also easily be mapped into their 412 corresponding ingress-egress-aggregate. 414 Microflow: a single instance of an application-to-application 415 (from [RFC2474]) flow of packets which is identified by source 416 address, destination address, protocol id, and 417 source port, destination port (where applicable). 419 PCN-domain: a PCN-capable domain; a contiguous set of 420 PCN-enabled nodes that perform Diffserv scheduling 421 [RFC2474]; the complete set of PCN-nodes that in 422 principle can, through PCN-marking packets, 423 influence decisions about flow admission and 424 termination within the domain; includes the PCN- 425 egress-nodes, which measure these PCN-marks, and the 426 PCN-ingress-nodes. 428 PCN-boundary-node: a PCN-node that connects one PCN-domain to a node 429 either in another PCN-domain or in a non-PCN-domain. 431 PCN-interior-node: a node in a PCN-domain that is not a PCN- 432 boundary-node. 434 PCN-node: a PCN-boundary-node or a PCN-interior-node. 436 PCN-egress-node: a PCN-boundary-node in its role in handling 437 traffic as it leaves a PCN-domain. In this 438 document the PCN-egress-node operates also as a 439 Decision Point and Deaggregator. 441 PCN-ingress-node: a PCN-boundary-node in its role in handling 442 traffic as it enters a PCN-domain. In this 443 document the PCN-ingress-node operates also as a 444 Aggregator. 446 PCN-traffic, 447 PCN-packets, 448 PCN-BA: a PCN-domain carries traffic of different Diffserv 449 behavior aggregates (BAs) [RFC2474]. The PCN-BA 450 uses the PCN mechanisms to carry PCN-traffic, and 451 the corresponding packets are PCN-packets. 452 The same network will carry traffic of other 453 Diffserv BAs. The PCN-BA is 454 distinguished by a combination of the Diffserv 455 codepoint (DSCP) and ECN fields. 457 PCN-flow: the unit of PCN-traffic that the PCN-boundary-node 458 admits (or terminates); the unit could be a single 459 E2E microflow (as defined in [RFC2474]) or some 460 identifiable collection of microflows. 462 PCN-admission-state: 463 The state ("admit" or "block") derived by the 464 Decision Point for a given ingress-egress-aggregate 465 based on statistics about PCN-packet marking. The 466 Decision Point decides to admit or block new flows 467 offered to the aggregate based on the current value 468 of the PCN-admission-state. 470 PCN-sent-rate 471 The rate of PCN-traffic received at a PCN-ingress- 472 node and destined for a given ingress-egress- 473 aggregate in octets per second. 475 PHB-ID (Per Hop Behavior Identification Code) 476 A 16-bit field containing the Per Hop Behavior 477 Identification Code of the PHB, or of the set of 478 PHBs, from which Diffserv resources 479 are to be reserved. This field must be encoded as 480 specified in Section 2 of [RFC3140]. 482 RSVP generic aggregated reservation: an RSVP reservation that is 483 identified by using the RSVP SESSION object 484 for generic RSVP aggregated reservation. This RSVP 485 SESSION object is based on the RSVP SESSION object 486 specified in [RFC4860] augmented with the following 487 information: 489 o) the IPv4 DestAddress, IPv6 DestAddress should be 490 set to the IPv4 or IPv6 destination addresses, 491 respectively, of the Deaggregator (PCN-egress- 492 node) 494 o) PHB-ID (Per Hop Behavior Identification Code) 495 should be set equal to PCN-compatible Diffserv 496 codepoint(s). 498 o) Extended vDstPort should be set to the IPv4 or 499 IPv6 destination addresses, of the Aggregator 500 (PCN-ingress-node) 502 VDstPort (Virtual Destination Port) 504 A 16-bit identifier used in the SESSION that 505 remains constant over the life of the generic 506 aggregate reservation. 508 1.4. Organization of This Document 510 This document is organized as follows. Section 2 gives an overview of 511 RSVP extensions and operations. The elements of the used procedures 512 are specified in Section 3. Section 4 describes the protocol 513 elements. The security considerations are given in section 5 and the 514 IANA considerations are provided in Section 6. 516 2. Overview of RSVP extensions and Operations 518 2.1 Overview of RSVP Aggregation Procedures in PCN domains 520 The PCN-boundary-nodes, see Figure 1, can support RSVP SESSIONS for 521 generic aggregated reservations {RFC4860], which are depending on 522 ingress-egress-aggregates. In particular, one RSVP generic aggregated 523 reservation matches to only one ingress-egress-aggregate. 525 However, one ingress-egress-aggregate matches to either 526 one, or more than one, RSVP generic aggregated reservations. 527 In addition, to comply with this specification, the PCN-boundary 528 nodes need to distinguish and process (1) RSVP SESSIONS for generic 529 aggregated sessions and their messages according to [RFC4860], (2) 530 E2E RSVP sessions and messages according to [RFC2205]. 532 This document locates all RSVP processing for a PCN domain at PCN- 533 Boundary nodes. PCN-interior-nodes do not perform any RSVP 534 functionality or maintain RSVP-related state information. Rather, 535 PCN-interior nodes forward all RSVP messages (for both generic 536 aggregated reservations[RFC4860] and end to end reservations 537 [RFC2205]) as if they were ordinary network traffic. 539 Moreover, each Aggregator and Deaggregator (i.e., PCN-boundary-nodes) 540 need to support policies to initiate and maintain for each pair of 541 PCN-boundary-nodes of the same PCN-domain one ingress-egress- 542 aggregate. 544 -------------------------- 545 / PCN-domain \ 546 |----| | | |----| 547 H--| R |\ |-----| |------| /| R |-->H 548 H--| |\\| | |---| |---| | |//| |-->H 549 |----| \| | | I | | I | | |/ |----| 550 | Agg |======================>| Deag | 551 /| | | | | | | |\ 552 H--------//| | |---| |---| | |\\-------->H 553 H--------/ |-----| |------| \-------->H 554 | | 555 \ / 556 -------------------------- 558 H = Host requesting end-to-end RSVP reservations 559 R = RSVP router 560 Agg = Aggregator (PCN-ingress-node) 561 Deag = Deaggregator (PCN-egress-node) 562 I = Interior Router (PCN-interior-node) 563 --> = E2E RSVP reservation 564 ==> = Aggregate RSVP reservation 566 Figure 1 : Aggregation of E2E Reservations 567 over Generic Aggregate RSVP Reservations 568 in PCN domains, based on [RFC4860] 570 Both the Aggregator and Deaggregator can maintain one or 571 more RSVP generic aggregated Reservations, but the Deaggregator is 572 the entity that initiates these RSVP generic aggregated reservations. 573 Note that one RSVP generic aggregated reservation matches to only 574 one ingress-egress-aggregate, while one ingress-egress-aggregate 575 matches to either one or to more than one RSVP generic aggregated 576 reservations. This can be accomplished by using for the different 577 RSVP generic aggregated reservations the same combinations of 578 ingress and egress identifiers, but with a different PHB-ID value 579 (see [RFC4860]). The procedures for aggregation of E2E reservations 580 over generic aggregate RSVP reservations are the same as the 581 procedures specified in Section 4 of [RFC4860], augmented with the 582 ones specified in Section 2.5. 584 One significant difference between this document and [RFC4860] is the 585 fact that in this document the admission control of E2E RSVP 586 reservations over the PCN core is performed according to the PCN 587 procedures, while in [RFC4860] this is achieved via first admitting 588 aggregate RSVP reservations over the aggregation region and then 589 admitting the E2E reservations over the aggregate RSVP reservations. 590 Therefore, in this document, the RSVP generic aggregate RSVP 591 reservations are not subject to admission control in the PCN-core, 592 and the E2E RSVP reservations are not subject to admission control 593 over the aggregate reservations. In turn, this means that several 594 procedures of [RFC4860] are significantly simplified in this 595 document: 596 o) unlike [RFC4860], the generic aggregate RSVP reservations need 597 not be admitted in the PCN core. 598 o) unlike [RFC4860], the RSVP aggregated traffic does not need to 599 be tunneled between Aggregator and Deaggregator, see Section 600 2.3. 601 o) unlike [RFC4860], the Deaggregator need not perform admission 602 control of E2E reservations over the aggregate RSVP 603 reservations. 604 o) unlike [RFC4860], there is no need for dynamic adjustment of 605 the RSVP generic aggregated reservation size, see Section 2.6. 607 2.2 PCN Marking and encoding and transport of pre-congestion 608 information 610 The method of PCN marking within the PCN domain is specified in 611 [RFC5670]. In addition, the method of encoding and transport of pre- 612 congestion information is specified in [RFC6660]. The PHB-ID (Per Hop 613 Behavior Identification Code) used SHOULD be set equal 614 to PCN-compatible Diffserv codepoint(s). 616 2.3. Traffic Classification Within The Aggregation Region 618 The PCN-ingress marks a PCN-BA using PCN-marking (i.e., combination 619 of the DSCP and ECN fields), which interior nodes use to 620 classify PCN-traffic. The PCN-traffic (e.g., E2E microflows) 621 belonging to a RSVP generic aggregated reservation can be 622 classified only at the PCN-boundary-nodes (i.e., Aggregator and 623 Deaggregator) by using the RSVP SESSION object for RSVP generic 624 aggregated reservations, see Section 2.1 of [RFC4860]. Note that the 625 DSCP value included in the SESSION object, SHOULD be set equal 626 to a PCN-compatible Diffserv codepoint. Since no admission control 627 procedures over the RSVP generic aggregated reservations in the PCN- 628 core are required, unlike [RFC4860], the RSVP aggregated traffic need 629 not to be tunneled between Aggregator and Deaggregator. In this 630 document one RSVP generic aggregated reservation is mapped to only 631 one ingress-egress-aggregate, while one ingress-egress-aggregate is 632 mapped to either one or to more than one RSVP generic aggregated 633 reservations. PCN-flows and their PCN-traffic that are mapped into a 634 specific RSVP generic aggregated reservation can also easily be 635 classified into their corresponding ingress-egress-aggregate. The 636 method of traffic conditioning of PCN-traffic and non-PCN traffic and 637 PHB configuration is described in [RFC6661] and [RFC6662]. 639 2.4. Deaggregator Determination 641 The present document assumes the same dynamic Deaggregator 642 determination method as used in [RFC4860]. 644 2.5. Mapping E2E Reservations Onto Aggregate Reservations 646 To comply with this specification for the mapping of E2E reservations 647 onto aggregate reservations, the same methods MUST be used as the 648 ones described in Section 4 of [RFC4860], augmented by the following 649 rules: 651 o) An Aggregator (also PCN-ingress-node in this document) or 652 Deaggregator (also PCN-egress-node and Decision Point in this 653 document) MUST use one or more policies to determine whether a 654 RSVP generic aggregated reservation can be mapped into an ingress- 655 Egress-aggregate. This can be accomplished by using for the 656 different RSVP generic aggregated reservations the same 657 combinations of ingress and egress identifiers, but with a 658 different PHB-ID value (see [RFC4860]) corresponding to the PCN 659 specifications. In particular, the RSVP SESSION object specified 660 in [RFC4860] augmented with the following information: 662 o) the IPv4 DestAddress, IPv6 DestAddress MUST be set to the 663 IPv4 or IPv6 destination addresses, respectively, of the 664 Deaggregator (PCN-egress-node), see [RFC4860]. Note that the 665 PCN-domain is considered as being only one RSVP hop (for 666 Generic aggregated RSVP or E2E RSVP). This means that the next 667 RSVP hop for the Aggregator in the downstream direction is the 668 Deaggregator and the next RSVP hop for the Deaggregator in the 669 upstream direction is the Aggregator. 671 o) PHB-ID (Per Hop Behavior Identification Code) SHOULD be set 672 equal to PCN-compatible Diffserv codepoint(s). 674 o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 675 destination addresses, of the Aggregator (PCN-ingress-node), 676 see [RFC4860]. 678 2.6. Size of Aggregate Reservations 680 Since:(i) no admission control of E2 reservations over the RSVP 681 aggregated reservations is required, and (ii) no admission control of 682 the RSVP aggregated reservation over the PCN core is required, 683 the size of the generic aggregate reservation is irrelevant and can 684 be set to any arbitrary value by the Deaggreagtor. The Deaggregator 685 SHOULD set the value of a generic aggregate reservation to a null 686 bandwidth. We also observe that there is no need for dynamic 687 adjustment of the RSVP aggregated reservation size. 689 2.7. E2E Path ADSPEC update 691 To comply with this specification, for the update of the E2E Path 692 ADSPEC, the same methods can be used as the ones described in 693 [RFC4860]. 695 2.8. Intra-domain Routes 697 The PCN-interior-nodes are neither maintaining E2E RSVP nor RSVP 698 generic aggregation states and reservations. Therefore, intra-domain 699 route changes will not affect intra-domain reservations since such 700 reservations are not maintained by the PCN-interior-nodes. 702 Furthermore, it is considered that by configuration, the PCN- 703 interior-nodes are not able to distinguish neither RSVP generic 704 aggregated sessions and their associated messages [RFC4860], nor E2E 705 RSVP sessions and their associated messages [RFC2205]. 707 2.9. Inter-domain Routes 709 The PCN-charter scope precludes inter-domain considerations. However, 710 for solving inter-domain routes changes associated with the operation 711 of the RSVP messages, the same methods SHOULD be used as the ones 712 described in [RFC4860] and in Section 1.4.7 of 713 [RFC3175]. 715 2.10. Reservations for Multicast Sessions 717 PCN does not consider reservations for multicast sessions. 719 2.11. Multi-level Aggregation 721 PCN does not consider multi-level aggregations within the PCN domain. 722 Therefore, the PCN-interior-nodes are not supporting multi-level 723 aggregation procedures. However, the Aggregator and Deaggregator 724 SHOULD support the multi-level aggregation procedures specified in 725 [RFC4860] and in Section 1.4.9 of [RFC3175]. 727 2.12. Reliability Issues 729 To comply with this specification, for solving possible reliability 730 issues, the same methods MUST used as the ones described in Section 4 731 of [RFC4860]. 733 3. Elements of Procedure 735 This section describes the procedures used to implement the 736 aggregated RSVP procedure over PCN. It is considered that the 737 procedures for aggregation of E2E reservations over generic aggregate 738 RSVP reservations are same as the procedures specified in Section 739 4 of [RFC4860] except where a departure from these procedures is 740 explicitly described in the present section. Please refer to 741 [RFC4860] for all the below error 742 cases: 743 o) Incomplete message 744 o) Unexpected objects 746 3.1. Receipt of E2E Path Message by Aggregating router 748 When the E2E Path message arrives at the exterior interface of the 749 Aggregator, (also PCN-ingress-node in this document), then standard 750 RSVP generic aggregation [RFC4860] procedures are used. 752 3.2. Handling Of E2E Path Message by Interior Routers 754 The E2E Path messages traverse zero or more PCN-interior-nodes. 755 The PCN-interior-nodes receive the E2E Path message on an interior 756 interface and forward it on another interior interface. 757 It is considered that, by configuration, the PCN-interior-nodes 758 ignore the E2E RSVP signaling messages [RFC2205]. Therefore, the E2E 759 Path messages are simply forwarded as normal IP datagrams. 761 3.3. Receipt of E2E Path Message by Deaggregating router 763 When receiving the E2E Path message the Deaggregator (also PCN- 764 egress-node and Decision Point in this document) performs the 765 regular [RFC4860] procedures, augmented with the following rules: 767 o) The Deaggregator MUST NOT perform the RSVP-TTL vs IP TTL- 768 check and MUST NOT update the ADspec Break bit. This is because 769 the whole PCN-domain is effectively handled by E2E RSVP as a 770 virtual link on which integrated service is indeed supported 771 (and admission control performed) so that the Break bit MUST 772 NOT be set, see also [draft-lefaucheur-rsvp-ecn-01]. 774 The Deaggregator forwards the E2E Path message towards the 775 receiver. 777 3.4. Initiation of new Aggregate Path Message by Aggregating Router 779 To comply with this specification, for the initiation of the new RSVP 780 generic aggregated Path message by the Aggregator (also PCN-ingress- 781 node in this document), the same methods MUST be used as the ones 782 described in [RFC4860]. 784 3.5. Handling Of Aggregate Path Message By Interior Routers 786 The Aggregate Path messages traverse zero or more PCN-interior-nodes. 787 The PCN-interior-nodes receive the Aggregated Path message on an 788 interior interface and forward it on another interior interface. 789 It is considered that, by configuration, the PCN-interior-nodes 790 ignore the Aggregated Path signaling messages. Therefore, the 791 Aggregated Path messages are simply forwarded as normal IP datagrams. 793 3.6. Handling Of Aggregate Path Message By Deaggregating Router 795 When receiving the Aggregated Path message, the Deaggregator (also 796 PCN-egress-node and Decision Point in this document) performs the 797 regular [RFC4860] procedures, augmented with the following rules: 799 o) When the received Aggregated Path message by the Deaggregator 800 contains the RSVP-AGGREGATE-IPv4-PCN-response or 801 RSVP-AGGREGATE-IPv6-PCN-response PCN objects, which carry the 802 PCN-sent-rate, then the procedures specified in Section 3.18 of 803 this document MUST be followed. 805 3.7. Handling of E2E Resv Message by Deaggregating Router 807 When the E2E Resv message arrives at the exterior interface of the 808 Deaggregator, (also PCN-egress-node and Decision Point in this 809 document) then standard RSVP aggregation [RFC4860] procedures are 810 used, augmented with the following rules: 812 o) The E2E RSVP session associated with an E2E Resv 813 message that arrives at the external interface of the Deaggregator 814 is mapped/matched with an RSVP generic aggregate and with a PCN 815 ingress-egress-aggregate. 817 o) Depending on the type of the PCN edge behavior supported by the 818 Deaggregator, the PCN admission control procedures specified in 819 Section 3.3.1 of [RFC6661] or [RFC6662] MUST be followed. Since no 820 admission control procedures over the RSVP aggregated reservations 821 in the PCN-core are required, unlike [RFC4860], the Deaggregator 822 does not perform any admission control of the E2E Reservation over 823 the mapped generic aggregate RSVP reservation. If the PCN based 824 admission control procedure is successful then the Deaggregator 825 MUST allow the new flow to be admitted onto the associated RSVP 826 generic aggregation reservation and onto the PCN ingress-egress- 827 aggregate, see [RFC6661] and [RFC6662]. If the PCN based admission 828 control procedure is not successful, then the E2E Resv MUST NOT be 829 admitted onto the associated RSVP generic aggregate reservation and 830 onto the PCN ingress-egress-aggregation. The E2E Resv message is 831 further processed according to [RFC4860]. 833 The way of how the PCN-admission-state is maintained is specified in 834 [RFC6661] and [RFC6662]. 836 3.8. Handling Of E2E Resv Message By Interior Routers 838 The E2E Resv messages traversing the PCN core are IP addressed to the 839 Aggregating router and are not marked with Router Alert, therefore 840 the E2E Resv messages are simply forwarded as normal IP datagrams. 842 3.9. Initiation of New Aggregate Resv Message By Deaggregating Router 844 To comply with this specification, for the initiation of the new RSVP 845 generic aggregated Resv message by the Deaggregator (also PCN-egress- 846 node and Decision Point in this document), the same methods MUST be 847 used as the ones described in 848 Section 4 of [RFC4860] augmented with the following rules: 850 o) The size of the generic aggregate reservation is irrelevant, see 851 Section 2.6, and can be set to any arbitrary value by the PCN- 852 egress node. The Deaggregator SHOULD set the value of a RSVP 853 generic aggregate reservation to a null bandwidth. We also 854 observe that there is no need for dynamic adjustment of the RSVP 855 generic aggregated reservation size. 857 o) When [RFC6661] is used and the ETM-rate measured by the 858 Deaggregator contains a non-zero value for some 859 ingress-egress-aggregate, see [RFC6661] and [RFC6662], the 860 Deagregator MUST request the PCN-ingress-node to provide an 861 estimate of the rate (PCN-sent-rate) at which the Aggregator 862 (also PCN-ingress-node in this document) is receiving PCN-traffic 863 that is destined for the given ingress-egress-aggregate. 865 o) When [RFC6662] is used and the PCN-admission-state computed by the 866 Deaggregator, on the basis of the CLE is "block" for the given 867 ingress-egress-aggregate, the Deaggregator MUST request the PCN- 868 ingress-node to provide an estimate of the rate (PCN-sent-rate) at 869 which the Aggregator is receiving PCN-traffic that is 870 destined for the given ingress-egress-aggregate. 872 o) In the above two cases and when the PCN-sent-rate needs to be 873 requested from the Aggregator, the Deaggregator MUST generate 874 and send an (refresh) Aggregated Resv message to the Aggregator 875 that MUST carry one of the following PCN objects, see Section 4.1, 876 depending on whether IPv4 or IPv6 is supported: 877 o) RSVP-AGGREGATE-IPv4-PCN-request 878 o) RSVP-AGGREGATE-IPv6-PCN-request. 880 3.10. Handling of Aggregate Resv Message by Interior Routers 882 The Aggregated Resv messages traversing the PCN core are IP addressed 883 to the Aggregating router and are not marked with Router Alert, 884 therefore the Aggregated Resv messages are simply forwarded as normal 885 IP datagrams. 887 3.11. Handling of E2E Resv Message by Aggregating Router 889 When the E2E Resv message arrives at the interior interface of the 890 Aggregator (also PCN-ingress-node in this document), then standard 891 RSVP aggregation [RFC4860] procedures are used. 893 3.12. Handling of Aggregated Resv Message by Aggregating Router 895 When the Aggregated Resv message arrives at the interior interface of 896 the Aggregator, (also PCN-ingress-node in this document), 897 then standard RSVP aggregation [RFC4860] procedures are used, 898 augmented with the following rules: 899 o) the Aggregator SHOULD use the information carried by the PCN 900 objects, see Section 4, and follow the steps specified in 901 [RFC6661], [RFC6662]. If the "R" flag carried by the 902 RSVP-AGGREGATE-IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN-request 903 PCN objects is set to ON, see Section 4.1, then the Aggregator 904 follows the steps described in Section 3.4 of [RFC6661] and 905 [RFC6662] on calculating the PCN-sent-rate. In particular, the 906 Aggregator MUST provide the estimated current rate of PCN-traffic 907 received at that node and destined for a given ingress-egress- 908 aggregate in octets per second (the PCN-sent-rate). The way this 909 rate estimate is derived is a matter of implementation, see 910 [RFC6661] or [RFC6662]. 912 o) the Aggregator initiates an Aggregated Path message. In 913 particular, when the Aggregator receives an Aggregated Resv 914 message which carries one of the following PCN objects: 915 RSVP-AGGREGATE-IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN- 916 request, with the flag "R" set to ON, see Section 4.1, the 917 Aggregator initiates an Aggregated Path message, and includes the 918 calculated PCN-sent-rate into the RSVP-AGGREGATE-IPv4-PCN-response 919 or RSVP-AGGREGATE-IPv6-PCN-response PCN objects, see Section 4.1, 920 which that MUST be carried by the Aggregated Path message. This 921 Aggregated Path message is sent towards the Deaggregator (also 922 PCN-egress-node and Decision Point in this document) that 923 requested the calculation of the PCN-sent-rate. 925 3.13. Removal of E2E Reservation 927 To comply with this specification, for the removal of E2E 928 reservations, the same methods MUST be used as the ones described in 929 Section 4 of [RFC4860] and [RFC4495]. 931 3.14. Removal of Aggregate Reservation 933 To comply with this specification, for the removal of RSVP generic 934 aggregated reservations, the same methods MUST be used as the ones 935 described in Section 4 of [RFC4860] and Section 2.10 of [RFC3175]. In 936 particular, should an aggregate reservation go away (presumably due 937 to a configuration change, route change, or policy event), the E2E 938 reservations it supports are no longer active. 939 They MUST be treated accordingly. 941 3.15. Handling of Data On Reserved E2E Flow by Aggregating Router 943 The handling of data on the reserved E2E flow by Aggregator (also 944 PCN-ingress-node in this document) uses the procedures described 945 in [RFC4860] augmented with: 946 o) Regarding, PCN marking and traffic classification the procedures 947 defined in Section 2.2 and 2.3 of this document are used. 949 3.16. Procedures for Multicast Sessions 951 In this document no multicast sessions are considered. 953 3.17. Misconfiguration of PCN-node 955 In an event where a PCN-node is misconfigured within a PCN-domain, 956 the desired behavior is same as described in Section 3.10. 958 3.18 PCN based Flow Termination 960 When the Deaggregator (also PCN-egress-node and Decision Point in 961 this document) needs to terminate an amount of traffic associated 962 with one ingress-egress-aggregate (see Section 3.3.2 of [RFC6661] and 963 [RFC6662]), then several procedures of terminating E2E microflows can 964 be deployed. The default procedure of terminating E2E microflows 965 (i.e., PCN-flows) is as follows, see i.e., [RFC6661] and [RFC6662]. 967 For the same ingress-egress-aggregate, select a number of E2E 968 microflows to be terminated in order to decrease the total incoming 969 amount of bandwidth associated with one ingress-egress-aggregate by 970 the amount of traffic to be terminated, see above. In this situation 971 the same mechanisms for terminating an E2E microflow can be followed 972 as specified in [RFC2205]. However, based on a local policy, the 973 Deaggregator could use other ways of selecting which microflows 974 should be terminated. For example, for the same ingress-egress- 975 aggregate, select a number of E2E microflows to be terminated or to 976 reduce their reserved bandwidth in order to decrease the total 977 incoming amount of bandwidth associated with one ingress-egress- 978 aggregate by the amount of traffic to be terminated. In this 979 situation the same mechanisms for terminating an E2E microflow or 980 reducing bandwidth associated with an E2E microflow can be followed 981 as specified in [RFC4495]. 983 4. Protocol Elements 985 The protocol elements in this document are using the ones defined in 986 Section 4 of [RFC4860] and Section 3 of [RFC3175] augmented with the 987 following rules: 988 o) the DSCP value included in the SESSION object, SHOULD be set equal 989 to a PCN-compatible Diffserv codepoint. 991 o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination 992 addresses, of the Aggregator (also PCN-ingress-node in this 993 document), see [RFC4860]. 995 o) When the Deaggregator (also PCN-egress-node and Decision Point 996 in this document) needs to request the PCN-sent-rate from the 997 PCN-ingress-node, see Section 3.9 of this document, the 998 Deaggregator MUST generate and send an (refresh) Aggregate 999 Resv message to the Aggregator that MUST carry one of the 1000 following PCN objects, see Section 4.1, depending on whether IPv4 1001 or IPv6 is supported: 1002 o) RSVP-AGGREGATE-IPv4-PCN-request 1003 o) RSVP-AGGREGATE-IPv6-PCN-request. 1005 o) When the Aggregator receives an Aggregate Resv message which 1006 carries one of the following PCN objects: 1007 RSVP-AGGREGATE-IPv4-PCN-request or 1008 RSVP-AGGREGATE-IPv6-PCN-request, with the flag "R" set to ON, see 1009 Section 4.1, then the Aggregator MUST generate and send to the 1010 Deaggregator an Aggregated Path message which carries one of the 1011 following PCN objects, see Section 4.1, depending on whether IPv4 1012 or IPv6 is supported: 1013 o) RSVP-AGGREGATE-IPv4-PCN-response, 1014 o) RSVP-AGGREGATE-IPv6-PCN-response. 1016 4.1 PCN objects 1018 This section describes four types of PCN objects that can be carried 1019 by the (refresh) Aggregate Path or the (refresh) Aggregate Resv 1020 messages specified in [RFC4860]. 1022 These objects are: 1023 o RSVP-AGGREGATE-IPv4-PCN-request, 1024 o RSVP-AGGREGATE-IPv6-PCN-request, 1025 o RSVP-AGGREGATE-IPv4-PCN-response, 1026 o RSVP-AGGREGATE-IPv6-PCN-response. 1028 o) RSVP-AGGREGATE-IPv4-PCN-request: PCN request object, when 1029 IPv4 addresses are used: 1030 Class = 248 (PCN) 1031 C-Type = 1 (RSVP-AGGREGATE-IPv4-PCN-request 1033 +-------------+-------------+-------------+-------------+ 1034 | IPv4 PCN-ingress-node Address (4 bytes) | 1035 +-------------+-------------+-------------+-------------+ 1036 | IPv4 PCN-egress-node Address (4 bytes) | 1037 +-------------+-------------+-------------+-------------+ 1038 | IPv4 Decision Point Address (4 bytes) | 1039 +-------------+-------------+-------------+-------------+ 1040 |R| Reserved | 1041 +-------------+-------------+-------------+-------------| 1043 o) RSVP-AGGREGATE-IPv6-PCN-request: PCN object, when 1044 IPv6 addresses are used: 1046 Class = 248 (PCN) 1047 C-Type = 2 (RSVP-AGGREGATE-IPv6-PCN-request 1049 +-------------+-------------+-------------+-------------+ 1050 | | 1051 + + 1052 | | 1053 + IPv6 PCN-ingress-node Address (16 bytes) + 1054 | | 1055 + + 1056 | | 1057 +-------------+-------------+-------------+-------------+ 1058 | | 1059 + + 1060 | | 1061 + IPv6 PCN-egress-node Address (16 bytes) + 1062 | | 1063 + + 1064 | | 1065 +-------------+-------------+-------------+-------------+ 1066 | | 1067 + + 1068 | | 1069 + Decision Point Address (16 bytes) + 1070 | | 1071 + + 1072 | | 1073 +-------------+-------------+-------------+-------------+ 1074 |R| Reserved | 1075 +-------------+-------------+-------------+-------------+ 1077 o) RSVP-AGGREGATE-IPv4-PCN-response: PCN object, IPv4 1078 addresses are used: 1079 Class = 248 (PCN) 1080 C-Type = 3 (RSVP-AGGREGATE-IPv4-PCN-response) 1082 +-------------+-------------+-------------+-------------+ 1083 | IPv4 PCN-ingress-node Address (4 bytes) | 1084 +-------------+-------------+-------------+-------------+ 1085 | IPv4 PCN-egress-node Address (4 bytes) | 1086 +-------------+-------------+-------------+-------------+ 1087 | IPv4 Decision Point Address (4 bytes) | 1088 +-------------+-------------+-------------+-------------+ 1089 | PCN-sent-rate | 1090 +-------------+-------------+-------------+-------------+ 1092 o) RSVP-AGGREGATE-IPv6-PCN-response: PCN object, IPv6 1093 addresses are used: 1094 Class = 248 (PCN) 1095 C-Type = 4 (RSVP-AGGREGATE-IPv6-PCN-response) 1097 +-------------+-------------+-------------+-------------+ 1098 | | 1099 + + 1100 | | 1101 + IPv6 PCN-ingress-node Address (16 bytes) + 1102 | | 1103 + + 1104 | | 1105 +-------------+-------------+-------------+-------------+ 1106 | | 1107 + + 1108 | | 1109 + IPv6 PCN-egress-node Address (16 bytes) + 1110 | | 1111 + + 1112 | | 1113 +-------------+-------------+-------------+-------------+ 1114 | | 1115 + + 1116 | | 1117 + Decision Point Address (16 bytes) + 1118 | | 1119 + + 1120 | | 1121 +-------------+-------------+-------------+-------------+ 1122 | PCN-sent-rate | 1123 +-------------+-------------+-------------+-------------+ 1125 The fields carried by the PCN object are specified in 1126 [RFC6663], [RFC6661] and [RFC6662]: 1128 o the IPv4 or IPv6 address of the PCN-ingress-node (Aggregator) and 1129 the IPv4 or IPv6 address of the PCN-egress-node (Deaggregator); 1130 together they specify the ingress-egress-aggregate to which the 1131 report refers. According to [RFC6663] the report should carry the 1132 identifier of the PCN-ingress-node (Aggregator) and the 1133 identifier of the PCN-egress-node (Deaggregator) (typically 1134 their IP addresses); 1136 o Decision Point address specify the IPv4 or IPv6 address of the 1137 Decision Point. In this document this field MUST contain the IP 1138 address of the Deaggregator. 1140 o "R": 1 bit flag that when set to ON, signifies, according to 1141 [RFC6661] and [RFC6662], that the PCN-ingress-node (Aggregator) 1142 MUST provide an estimate of the rate (PCN-sent-rate) at which the 1143 PCN-ingress-node (Aggregator) is receiving PCN-traffic that is 1144 destined for the given ingress-egress-aggregate. 1146 O "Reserved": 31 bits that are currently not used by this 1147 document and are reserved. These SHALL be set to 0 and SHALL be 1148 ignored on reception. 1150 o PCN-sent-rate: the PCN-sent-rate for the given 1151 ingress-egress-aggregate. It is expressed in octets/second; its 1152 format is a 32-bit IEEE floating point number; The PCN-sent-rate 1153 is specified in [RFC6661] and [RFC6662] and it represents the 1154 estimate of the rate at which the PCN-ingress-node (Aggregator) 1155 is receiving PCN-traffic that is destined for the given 1156 ingress-egress-aggregate. 1158 5. Security Considerations 1160 The security considerations specified in [RFC2205], [RFC4860] and 1161 [RFC5559] apply to this document. In addition, [RFC4230] and 1162 [RFC6411] provide useful guidance on RSVP security mechanisms. 1164 Security within a PCN domain is fundamentally based on the controlled 1165 environment trust assumption stated in Section 6.3.1 of [RFC5559], in 1166 particular that all PCN-nodes are PCN-enabled and are trusted 1167 to perform accurate PCN-metering and PCN-marking. 1169 In the PCN domain environments addressed by this document, Generic 1170 Aggregate Resource ReSerVation Protocol (RSVP) messages specified in 1171 [RFC4860] are used for support of the PCN Controlled Load (CL) and 1172 Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- 1173 Congestion Notification. Hence the security mechanisms discussed 1174 in [RFC4860] are applicable. Specifically, the INTEGRITY object 1175 [RFC2747][RFC3097] can be used to provide hop-by-hop RSVP message 1176 integrity, node authentication and replay protection, thereby 1177 protecting against corruption and spoofing of RSVP messages and 1178 PCN feedback conveyed by RSVP messages. 1180 For these reasons, this document does not introduce significant 1181 additional security considerations beyond those discussed in 1183 [RFC5559] and [RFC4860]. 1185 6. IANA Considerations 1187 IANA has modified the RSVP parameters registry, 'Class Names, 1188 Class Numbers, and Class Types' subregistry, to add a new 1189 Class Number and assign 4 new C-Types under this new Class 1190 Number, as described below, see Section 4.1: 1192 Class 1193 Number Class Name Reference 1194 ------ ---------------------- --------- 1195 248 PCN this document 1197 Class Types or C-Types: 1198 1 RSVP-AGGREGATE-IPv4-PCN-request this document 1199 2 RSVP-AGGREGATE-IPv6-PCN-request this document 1200 3 RSVP-AGGREGATE-IPv4-PCN-response this document 1201 4 RSVP-AGGREGATE-IPv6-PCN-response this document 1203 When this draft is published as an RFC, IANA should update the 1204 reference for the above 5 items to that published RFC (and the RFC 1205 Editor should remove this sentence). 1207 7. Acknowledgments 1209 We would like to thank the authors of [draft-lefaucheur-rsvp-ecn- 1210 01.txt], since some ideas used in this document are based on the work 1211 initiated in [draft-lefaucheur-rsvp-ecn-01.txt]. Moreover, we would 1212 like to thank Bob Briscoe, David Black, Ken Carlberg, Tom Taylor, 1213 Philip Eardley, Michael Menth, Toby Moncaster, James Polk, Scott 1214 Bradner, Lixia Zhang and Robert Sparks for the provided comments. In 1215 particular, we would like to thank Francois Le Faucheur for 1216 contributing in addition to comments also to a significant amount of 1217 text. 1219 8. Normative References 1221 [RFC6661] T. Taylor, A, Charny, F. Huang, 1222 G. Karagiannis, M. Menth, "PCN Boundary Node Behaviour for the 1223 Controlled Load (CL) Mode of Operation", July 1224 2012. 1226 [RFC6662] A. Charny, J. Zhang, 1227 G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node Behaviour 1228 for the Single Marking (SM) Mode of Operation", 1229 July 2012. 1231 [RFC6663] G. Karagiannis, T. Taylor, 1232 K. Chan, M. Menth, P. Eardley, " Requirements for Signaling of (Pre-) 1233 Congestion Information in a DiffServ Domain", 1234 July 2012. 1236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1237 Requirement Levels", BCP 14, RFC 2119, March 1997. 1239 [RFC2205] Braden, R., ed., et al., "Resource ReSerVation Protocol 1240 (RSVP)- Functional Specification", RFC 2205, September 1997. 1242 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le 1243 Faucheur, "Per Hop Behavior Identification Codes", 1244 RFC 3140, June 2001. 1246 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1247 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 1248 September 2001. 1250 [RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation 1251 Protocol (RSVP) Extension for the Reduction of 1252 Bandwidth of a Reservation Flow", RFC 4495, May 2006. 1254 [RFC4860] F. Le Faucheur, B. Davie, P. Bose, C. Christou, M. 1255 Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) 1256 Reservations", RFC4860, May 2007. 1258 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", 1259 RFC 5670, November 2009. 1261 [RFC6660] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 1262 Encoding and Transport of Pre-Congestion Information", RFC 6660, 1263 July 2012. 1265 9. Informative References 1267 [draft-lefaucheur-rsvp-ecn-01.txt] Le Faucheur, F., Charny, A., 1268 Briscoe, B., Eardley, P., Chan, K., and J. Babiarz, "RSVP Extensions 1269 for Admission Control over Diffserv using Pre-congestion 1270 Notification (PCN) (Work in progress)", June 2006. 1272 [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated 1273 Services in the Internet Architecture: an Overview", RFC 1633, June 1274 1994. 1276 [RFC2211] J. Wroclawski, Specification of the Controlled-Load Network 1277 Element Service, September 1997 1279 [RFC2212] S. Shenker et al., Specification of Guaranteed Quality of 1280 Service, September 1997 1282 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1283 "Definition of the Differentiated Services Field (DS Field) in the 1284 IPv4 and IPv6 Headers", RFC 2474, December 1998. 1286 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and 1287 W. Weiss, "A framework for Differentiated Services", RFC 2475, 1288 December 1998. 1290 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1291 Authentication", RFC 2747, January 2000. 1293 [RFC2753] Yavatkar, R., D. Pendarakis and R. Guerin, "A Framework for 1294 Policy-based Admission Control", January 2000. 1296 [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 1297 Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A 1298 Framework for Integrated Services Operation Over DiffServ Networks", 1299 RFC 2998, November 2000. 1301 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication 1302 -- Updated Message Type Value", RFC 3097, April 2001. 1304 [RFC4230] H. Tschofenig, R. Graveman, "RSVP Security Properties", 1305 RFC 4230, December 2005. 1307 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 1308 Architecture", RFC 5559, June 2009. 1310 [RFC6411] M. Behringer, F. Le Faucheur, B. Weis, "Applicability of 1311 Keying Methods for RSVP Security", RFC 6411, October 2011. 1313 [SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested 1314 Virtual Private Network", Work in Progress, July 2007. 1316 10. Appendix A: Example Signaling Flow 1318 This appendix is based on the appendix provided in [RFC4860]. In 1319 particular, it provides an example signaling flow of the 1320 specification detailed in Section 3 and 4. 1321 This signaling flow assumes an environment where E2E reservations are 1322 aggregated over generic aggregate RSVP reservations and applied over 1323 a PCN domain. In particular the Aggregator (PCN-ingress-node) and 1324 Deaggregator (PCN-egress-node) are located at the boundaries of the 1325 PCN domain. The PCN-interior-nodes are located within the PCN-domain, 1326 between the PCN-boundary nodes, but are not shown in this Figure. It 1327 illustrates a possible RSVP message flow that could take place in the 1328 successful establishment of a unicast E2E reservation that is the 1329 first between a given pair of Aggregator/Deaggregator. 1331 Aggregator (PCN-ingress-node) Deaggregator (PCN-egress-node) 1333 E2E Path 1334 -----------> 1335 (1) 1336 E2E Path 1337 -------------------------------> 1338 (2) 1339 E2E PathErr(New-agg-needed,SOI=GApcn) 1340 <---------------------------------- 1341 (3) 1342 AggPath(Session=GApcn) 1343 -------------------------------> 1344 (4) 1345 E2E Path 1346 -----------> 1347 (5) 1348 AggResv (Session=GApcn) (PCN object) 1349 <------------------------------- 1350 (6) 1351 AggResvConfirm (Session=GApcn) 1352 ------------------------------> 1353 (7) 1354 E2E Resv 1355 <--------- 1356 (8) 1357 E2E Resv (SOI=GApcn) 1358 <----------------------------- 1359 (9) 1360 E2E Resv 1361 <----------- 1363 (1) The Aggregator forwards E2E Path into the aggregation region 1364 after modifying its IP protocol number to RSVP-E2E-IGNORE 1366 (2) Let's assume no Aggregate Path exists. To be able to accurately 1367 update the ADSPEC of the E2E Path, the Deaggregator needs the 1368 ADSPEC of Aggregate Path. In this example, the Deaggregator 1369 elects to instruct the Aggregator to set up an Aggregate Path 1370 state for the PCN PHB-ID. To do that, the Deaggregator 1371 sends an E2E PathErr message with a New-Agg-Needed PathErr 1372 code. 1374 The PathErr message also contains a SESSION-OF-INTEREST 1375 (SOI) object. The SOI contains a GENERIC-AGGREGATE SESSION 1376 (GApcn) whose PHB-ID is set to the PCN PHB-ID. The GENERIC- 1377 AGGREGATE SESSION contains an interface-independent Deaggregator 1378 address inside the DestAddress and appropriate values inside the 1379 vDstPort and Extended vDstPort fields. In this document, the 1380 Extended vDstPort SHOULD contain the IPv4 or IPv6 address of 1381 the Aggregator. 1383 (3) The Aggregator follows the request from the Deaggregator and 1384 signals an Aggregate Path for the GENERIC-AGGREGATE Session 1385 (GApcn). 1387 (4) The Deaggregator takes into account the information contained in 1388 the ADSPEC from both Aggregate Paths and updates the E2E Path 1389 ADSPEC accordingly. The PCN-egress-node MUST NOT perform the 1390 RSVP-TTL vs IP TTL-check and MUST NOT update the ADspec Break 1391 bit. This is because the whole PCN-domain is effectively handled 1392 by E2E RSVP as a virtual link on which integrated service is 1393 indeed supported (and admission control performed) so that the 1394 Break bit MUST NOT be set, see also 1395 [draft-lefaucheur-rsvp-ecn-01]. The Deaggregator also modifies 1396 the E2E Path IP protocol number to RSVP before forwarding it. 1398 (5) In this example, the Deaggregator elects to immediately proceed 1399 with establishment of the generic aggregate reservation. In 1400 effect, the Deaggregator can be seen as anticipating 1401 the actual demand of E2E reservations so that the generic 1402 aggregate reservation is in place when the E2E Resv 1403 request arrives, in order to speed up establishment of E2E 1404 reservations. Here it is also assumed that the Deaggregator 1405 includes the optional Resv Confirm Request in the Aggregate 1406 Resv message. 1408 (6) The Aggregator merely complies with the received ResvConfirm 1409 Request and returns the corresponding Aggregate ResvConfirm. 1411 (7) The Deaggregator has explicit confirmation that the generic 1412 aggregate reservation is established. 1414 (8) On receipt of the E2E Resv, the Deaggregator applies the mapping 1415 policy defined by the network administrator to map the E2E Resv 1416 onto a generic aggregate reservation. Let's assume that this 1417 policy is such that the E2E reservation is to be mapped onto the 1418 generic aggregate reservation with the PCN PHB-ID=x. The 1419 Deaggregator knows that a generic aggregate reservation (GApcn) 1420 is in place for the corresponding PHB-ID since (7). At this step 1421 the Deaggregator maps the generic aggregated reservation onto one 1422 ingress-egress-aggregate maintained by the Deaggregator (as a 1423 PCN-egress-node), see Section 3.7. The Deaggregator performs 1424 admission control of the E2E Resv onto the generic Aggregate 1425 reservation for the PCN PHB-ID (GApcn). The Deaggregator takes 1426 also into account the PCN admission control procedure as 1427 as specified in [RFC6661] and [RFC6662], see Section 3.7. 1428 If one or both the admission control procedures (PCN based 1429 admission control procedure and admission control procedure 1430 specified in [RFC4860]) are not successful, then the E2E Resv is 1431 not admitted onto the associated RSVP generic aggregate 1432 reservation for the PCN PHB-ID (GApcn). Otherwise, assuming that 1433 the generic aggregate reservation for the PCN (GApcn) had been 1434 established with sufficient bandwidth to support the E2E Resv, 1435 the Deaggregator adjusts its counter, tracking the unused 1436 bandwidth on the generic aggregate reservation. Then it forwards 1437 the E2E Resv to the Aggregator including a SESSION-OF-INTEREST 1438 object conveying the selected mapping onto GApcn (and hence onto 1439 the PCN PHB-ID). 1441 (9) The Aggregator records the mapping of the E2E Resv onto GApcn 1442 (and onto the PCN PHB-ID). The Aggregator removes the SOI object 1443 and forwards the E2E Resv towards the sender. 1445 11. Authors' Address 1447 Georgios Karagiannis 1448 Huawei Technologies 1449 Hansaallee 205, 1450 40549 Dusseldorf, 1451 Germany 1452 Email: Georgios.Karagiannis@huawei.com 1454 Anurag Bhargava 1455 Cisco Systems, Inc. 1456 7100-9 Kit Creek Road 1457 PO Box 14987 1458 RESEARCH TRIANGLE PARK, NORTH CAROLINA 27709-4987 1459 USA 1460 Email: anuragb@cisco.com