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