idnits 2.17.1 draft-ietf-tsvwg-rsvp-pcn-09.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 362 has weird spacing: '...croflow a m...' == Line 557 has weird spacing: '...rvation match...' == Line 561 has weird spacing: '...he same combi...' -- The document date (August 11, 2014) is 3544 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 University of Twente 3 Intended status: Experimental Anurag Bhargava 4 Expires: February 11, 2015 Cisco Systems, Inc. 5 August 11, 2014 7 Generic Aggregation of Resource ReSerVation Protocol (RSVP) 8 for IPv4 And IPv6 Reservations over PCN domains 9 draft-ietf-tsvwg-rsvp-pcn-09 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 February 11, 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 . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . 23 103 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 104 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 24 105 9. Informative References . . . . . . . . . . . . . . . . . . . . . 25 106 10. Appendix A: Example Signaling Flow . . . . . . . . . . . . . . . 25 107 11. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 28 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 1.2 Overview and Motivation 157 Two main Quality of Service (QoS) architectures have been specified 158 by the IETF. These are the Integrated Services (Intserv) [RFC1633] 159 architecture and the Differentiated Services (DiffServ) architecture 160 ([RFC2475]). 162 Intserv provides methods for the delivery of end-to-end Quality of 163 Service (QoS) to applications over heterogeneous networks. One of the 164 QoS signaling protocols used by the Intserv architecture is the 165 Resource reServation Protocol (RSVP) [RFC2205], which can be used by 166 applications to request per-flow resources from the network. These 167 RSVP requests can be admitted or rejected by the network. 168 Applications can express their quantifiable resource requirements 169 using Intserv parameters as defined in [RFC2211] and [RFC2212]. The 170 Controlled Load (CL) service [RFC2211] is a quality of service (QoS) 171 closely approximating the QoS that the same flow would receive from a 172 lightly loaded network element. The CL service is useful for 173 inelastic flows such as those used for real-time media. 175 The DiffServ architecture can support the differentiated treatment of 176 packets in very large scale environments. While Intserv and RSVP 177 classify packets per-flow, Diffserv networks classify packets into 178 one of a small number of aggregated flows or "classes", based on the 179 Diffserv codepoint (DSCP) in the packet IP header. At each Diffserv 180 router, packets are subjected to a "per-hop behavior" (PHB), which is 181 invoked by the DSCP. The primary benefit of Diffserv is its 182 scalability, since the need for per-flow state and per-flow 183 processing, is eliminated. 185 However, DiffServ does not include any mechanism for communication 186 between applications and the network. Several solutions have been 187 specified to solve this issue. One of these solutions is Intserv over 188 Diffserv [RFC2998] including resource-based admission control (RBAC), 189 PBAC, assistance in traffic identification/classification, and 190 traffic conditioning. Intserv over Diffserv can operate over a 191 statically provisioned Diffserv region or RSVP aware. When it is RSVP 192 aware, several mechanisms may be used to support dynamic provisioning 193 and topology-aware admission control, including aggregate RSVP 194 reservations, per-flow RSVP, or a bandwidth broker. [RFC3175] 195 specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to- 196 end reservations over aggregate RSVP reservations. In [RFC3175] the 197 RSVP generic aggregated reservation is characterized by a RSVP 198 SESSION object using the 3-tuple . 201 Several scenarios require the use of multiple generic aggregate 202 reservations that are established for a given PHB from a given source 203 IP address to a given destination IP address, see [SIG-NESTED], 204 [RFC4860]. For example, multiple generic aggregate reservations 205 can be applied in the situation that multiple E2E reservations using 206 different preemption priorities need to be aggregated through a PCN- 207 domain using the same PHB. By using multiple aggregate reservations 208 for the same PHB allows enforcement of the different preemption 209 priorities within the aggregation region. This allows more efficient 210 management of the Diffserv resources, and in periods of resource 211 shortage, this allows sustainment of a larger number of E2E 212 reservations with higher preemption priorities. In particular, 213 [SIG-NESTED] discusses in detail how end-to-end RSVP reservations can 214 be established in a nested VPN environment through RSVP aggregation. 216 [RFC4860] provides generic aggregate reservations by extending 217 [RFC3175] to support multiple aggregate reservations for the same 218 source IP address, destination IP address, and PHB (or set of PHBs). 219 In particular, multiple such generic aggregate reservations can be 220 established for a given PHB from a given source IP address to a given 221 destination IP address. This is achieved by adding the concept of a 222 Virtual Destination Port and of an Extended Virtual Destination Port 223 in the RSVP SESSION object. In addition to this, the RSVP SESSION 224 object for generic aggregate reservations uses the PHB Identification 225 Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv 226 Code Point (DSCP) used in [RFC3175]. The PHB-ID is used to identify 227 the PHB, or set of PHBs, from which the Diffserv resources are to be 228 reserved. 229 The RSVP like signaling protocol required to carry (1) requests from 230 a PCN-egress-node to a PCN-ingress-node and (2) reports from a 231 PCN-ingress-node to a PCN-egress-node needs to follow the PCN 232 signaling requirements defined in [RFC6663]. In addition to 233 that the signaling protocol functionality supported by the PCN- 234 ingress-nodes and PCN-egress-nodes needs to maintain logical 235 aggregate constructs (i.e. ingress-egress-aggregate state) and be 236 able to map E2E reservations to these aggregate constructs. Moreover, 237 no actual reservation state is needed to be maintained inside the PCN 238 domain, i.e., the PCN-interior-nodes are not maintaining any 239 reservation state. 241 This can be accomplished by two possible approaches: 243 Approach (1): 245 o) adapting the RFC 4860 aggregation procedures to fit the PCN 246 requirements with as little change as possible over the RFC 4860 247 functionality 249 o) hence performing aggregate RSVP signaling (even if it is to be 250 ignored by PCN interior nodes) 252 o) using this aggregate RSVP signaling procedures to carry PCN 253 information between the PCN-boundary-nodes (PCN-ingress-node and 254 PCN-egress-node). 256 Approach (2): 258 o) adapting the RFC 4860 aggregation procedures to fit the PCN 259 requirements with more significant changes over RFC4860 (i.e. 260 the aspect of the procedures that have to do with maintaining 261 aggregate states and to do with mapping the E2E reservations to 262 aggregate constructs are kept, but the procedures that have to 263 do with the aggregate RSVP signaling and aggregate reservation 264 establishment/maintenance are dropped). 266 o) hence not performing aggregate RSVP signaling 268 o) piggy-backing of the PCN information inside the E2E RSVP 269 signaling. 271 Both approaches are probably viable, however, since the RFC 4860 272 operations have been thoroughly studied and implemented, it can be 273 considered that the RFC 4860 solution can better deal with the more 274 challenging situations (rerouting in the PCN domain, failure of an 275 PCN-ingress-node, failure of an PCN-egress-node, rerouting towards a 276 different edge, etc.). This is the reason for choosing Approach (1) 277 for the specification of the signaling protocol used to carry 278 PCN information between the PCN-boundary-nodes (PCN-ingress-node and 279 PCN-egress-node). 281 In particular, this document specifies extensions to Generic 282 Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) 283 and Single Marking (SM) edge behaviors over a Diffserv cloud using 284 Pre-Congestion Notification. 286 This document follows the PCN signaling requirements defined in 287 [RFC6663] and specifies extensions to Generic Aggregated RSVP 288 [RFC4860] for support of PCN edge behaviors as specified in 289 [RFC6661] and [RFC6662]. Moreover, this document specifies how RSVP 290 aggregation can be used to setup and maintain: (1) Ingress Egress 291 Aggregate (IEA) states at Ingress and Egress nodes and (2) generic 292 aggregation of RSVP end-to-end RSVP reservations over PCN (Congestion 293 and Pre-Congestion Notification) domains. 295 To comply with this specification, PCN-nodes MUST be able to 296 support the functionality specified in [RFC5670], [RFC5559], 297 [RFC6660], [RFC6661], [RFC6662]. Furthermore, the PCN-boundary-nodes 298 MUST support the RSVP generic aggregated reservation procedures 299 specified in [RFC4860] which are augmented with procedures specified 300 in this document. 302 1.3. Terminology 304 This document uses terms defined in [RFC4860], [RFC3175], [RFC5559], 305 [RFC5670], [RFC6661], [RFC6662]. 307 For readability, a number of definitions from [RFC3175] as well as 308 definitions for terms used in [RFC5559], [RFC6661], and [RFC6662] are 309 provided here, where some of them are augmented with new meanings: 311 Aggregator This is the process in (or associated with) the 312 router at the ingress edge of the aggregation region 313 (with respect to the end-to-end RSVP reservation) 314 and behaving in accordance with [RFC4860]. In this 315 document, it is also the PCN-ingress-node. It is 316 important to notice that in the context of this 317 document the Aggregator MUST be able to determine 318 the Deaggregator using the procedures specified in 319 Section 4 of [RFC4860] and in Section 1.4.2 of 320 [RFC3175]. 322 Congestion level estimate (CLE): 323 The ratio of PCN-marked to total PCN-traffic 324 (measured in octets) received for a given ingress- 325 egress-aggregate during a given measurement period. 326 The CLE is used to derive the PCN-admission-state 327 and is also used by the report suppression procedure 328 if report suppression is activated. 330 Deaggregator This is the process in (or associated with) the 331 router at the egress edge of the aggregation region 332 (with respect to the end-to-end RSVP reservation) 333 and behaving in accordance with [RFC4860]. In this 334 document, it is also the PCN-egress-node and 335 Decision Point. 337 E2E end to end 339 E2E Reservation This is an RSVP reservation such that: 341 (i) corresponding RSVP Path messages are initiated 342 upstream of the Aggregator and terminated 343 downstream of the Deaggregator, and 345 (ii) corresponding RSVP Resv messages are initiated 346 downstream of the Deaggregator and terminated 347 upstream of the Aggregator, and 349 (iii) this RSVP reservation is aggregated over an 350 Ingress Egress Aggregate (IEA) between the 351 Aggregator and Deaggregator. 352 An E2E RSVP reservation may be a per-flow 353 reservation, which in this document is only 354 maintained at the PCN-ingress-node and PCN-egress- 355 node. Alternatively, the E2E reservation may itself 356 be an aggregate reservation of various types (e.g., 357 Aggregate IP reservation, Aggregate IPsec 358 reservation, see [RFC4860]). As per regular RSVP 359 operations, E2E RSVP reservations are 360 unidirectional. 362 E2E microflow a microflow where its associated packets are being 363 forwarded on an E2E path. 365 Extended vDstPort (Extended Virtual Destination Port) 367 An identifier used in the SESSION that remains 368 constant over the life of the generic aggregate 369 reservation. The length of this identifier is 32- 370 bits when IPv4 addresses are used and 128 bits when 371 IPv6 addresses are used. 373 A sender(or Aggregator) that wishes to narrow the 374 scope of a SESSION to the sender-receiver pair (or 375 Aggregator-Deaggregator pair) SHOULD place its IPv4 376 or IPv6 address here as a network unique 377 identifier. A sender (or Aggregator) that wishes to 378 use a common session with other senders (or 379 Aggregators) in order to use a shared reservation 380 across senders (or Aggregators) MUST set this field 381 to all zeros. In this document, the Extended 382 vDstPort SHOULD contain the IPv4 or IPv6 address of 383 the Aggregator. 385 ETM-rate 386 The rate of excess-traffic-marked PCN-traffic 387 received at a PCN-egress-node for a given ingress- 388 egress-aggregate in octets per second. 390 Ingress-egress-aggregate (IEA): 391 The collection of PCN-packets from all PCN-flows 392 that travel in one direction between a specific pair 393 of PCN-boundary-nodes. In this document one RSVP 394 generic aggregated reservation is mapped to only 395 one ingress-egress-aggregate, while one 396 ingress-egress-aggregate is mapped to either 397 one or to more than one RSVP generic aggregated 398 reservations. PCN-flows and their PCN-traffic that 399 are mapped into a specific RSVP generic aggregated 400 reservation can also easily be mapped into their 401 corresponding ingress-egress-aggregate. 403 Microflow: a single instance of an application-to-application 404 (from [RFC2474]) flow of packets which is identified by source 405 address, destination address, protocol id, and 406 source port, destination port (where applicable). 408 PCN-domain: a PCN-capable domain; a contiguous set of 409 PCN-enabled nodes that perform Diffserv scheduling 410 [RFC2474]; the complete set of PCN-nodes that in 411 principle can, through PCN-marking packets, 412 influence decisions about flow admission and 413 termination for the PCN-domain; includes 414 the PCN-egress-nodes, which measure these 415 PCN-marks, and the PCN-ingress-nodes. 417 PCN-boundary-node: a PCN-node that connects one PCN-domain to a node 418 either in another PCN-domain or in a non-PCN-domain. 420 PCN-interior-node: a node in a PCN-domain that is not a PCN- 421 boundary-node. 423 PCN-node: a PCN-boundary-node or a PCN-interior-node. 425 PCN-egress-node: a PCN-boundary-node in its role in handling 426 traffic as it leaves a PCN-domain. In this 427 document the PCN-egress-node operates also as a 428 Decision Point and Deaggregator. 430 PCN-ingress-node: a PCN-boundary-node in its role in handling 431 traffic as it enters a PCN-domain. In this 432 document the PCN-ingress-node operates also as a 433 Aggregator. 435 PCN-traffic, 436 PCN-packets, 437 PCN-BA: a PCN-domain carries traffic of different Diffserv 438 behavior aggregates (BAs) [RFC2474]. The PCN-BA 439 uses the PCN mechanisms to carry PCN-traffic, and 440 the corresponding packets are PCN-packets. 441 The same network will carry traffic of other 442 Diffserv BAs. The PCN-BA is 443 distinguished by a combination of the Diffserv 444 codepoint (DSCP) and ECN fields. 446 PCN-flow: the unit of PCN-traffic that the PCN-boundary-node 447 admits (or terminates); the unit could be a single 448 E2E microflow (as defined in [RFC2474]) or some 449 identifiable collection of microflows. 451 PCN-admission-state: 452 The state ("admit" or "block") derived by the 453 Decision Point for a given ingress-egress-aggregate 454 based on statistics about PCN-packet marking. The 455 Decision Point decides to admit or block new flows 456 offered to the aggregate based on the current value 457 of the PCN-admission-state. 459 PCN-sent-rate 460 The rate of PCN-traffic received at a PCN-ingress- 461 node and destined for a given ingress-egress- 462 aggregate in octets per second. 464 PHB-ID (Per Hop Behavior Identification Code) 465 A 16-bit field containing the Per Hop Behavior 466 Identification Code of the PHB, or of the set of 467 PHBs, from which Diffserv resources 468 are to be reserved. This field MUST be encoded as 469 specified in Section 2 of [RFC3140]. 471 RSVP generic aggregated reservation: an RSVP reservation that is 472 identified by using the RSVP SESSION object 473 for generic RSVP aggregated reservation. This RSVP 474 SESSION object is based on the RSVP SESSION object 475 specified in [RFC4860] augmented with the following 476 information: 478 o) the IPv4 DestAddress, IPv6 DestAddress SHOULD be 479 set to the IPv4 or IPv6 destination addresses, 480 respectively, of the Deaggregator (PCN-egress- 481 node) 483 o) PHB-ID (Per Hop Behavior Identification Code) 484 SHOULD be set equal to PCN-compatible Diffserv 485 codepoint(s). 487 o) Extended vDstPort SHOULD be set to the IPv4 or 488 IPv6 destination addresses, of the Aggregator 489 (PCN-ingress-node) 491 VDstPort (Virtual Destination Port) 493 A 16-bit identifier used in the SESSION that 494 remains constant over the life of the generic 495 aggregate reservation. 497 1.4. Organization of This Document 499 This document is organized as follows. Section 2 gives an overview of 500 RSVP extensions and operations. The elements of the used procedures 501 are specified in Section 3. Section 4 describes the protocol 502 elements. The security considerations are given in section 5 and the 503 IANA considerations are provided in Section 6. 505 2. Overview of RSVP extensions and Operations 507 2.1 Overview of RSVP Aggregation Procedures in PCN domains 509 The PCN-boundary-nodes, see Figure 1, can support RSVP SESSIONS for 510 generic aggregated reservations {RFC4860], which are depending on 511 ingress-egress-aggregates. In particular, one RSVP generic aggregated 512 reservation matches to only one ingress-egress-aggregate. 514 However, one ingress-egress-aggregate matches to either 515 one, or more than one, RSVP generic aggregated reservations. 516 In addition, to comply with this specification, the PCN-boundary 517 nodes need to distinguish and process (1) RSVP SESSIONS for generic 518 aggregated sessions and their messages according to [RFC4860], (2) 519 E2E RSVP sessions and messages according to [RFC2205]. Furthermore, 520 it is considered that by configuration the PCN-interior-nodes do not 521 intercept (nor process) RSVP messages associated with generic 522 aggregated reservation [RFC4860], or with end to end RSVP 523 reservations [RFC2205]. Moreover, each Aggregator and Deaggregator 524 (i.e., PCN-boundary-nodes) need to support policies to initiate and 525 maintain for each pair of PCN-boundary-nodes of the same PCN-domain 526 one ingress-egress-aggregate. 528 -------------------------- 529 / PCN-domain \ 530 |----| | | |----| 531 H--| R |\ |-----| |------| /| R |-->H 532 H--| |\\| | |---| |---| | |//| |-->H 533 |----| \| | | I | | I | | |/ |----| 534 | Agg |======================>| Deag | 535 /| | | | | | | |\ 536 H--------//| | |---| |---| | |\\-------->H 537 H--------/ |-----| |------| \-------->H 538 | | 539 \ / 540 -------------------------- 542 H = Host requesting end-to-end RSVP reservations 543 R = RSVP router 544 Agg = Aggregator (PCN-ingress-node) 545 Deag = Deaggregator (PCN-egress-node) 546 I = Interior Router (PCN-interior-node) 547 --> = E2E RSVP reservation 548 ==> = Aggregate RSVP reservation 550 Figure 1 : Aggregation of E2E Reservations 551 over Generic Aggregate RSVP Reservations 552 in PCN domains, based on [RFC4860] 554 Both the Aggregator and Deaggregator can maintain one or 555 more RSVP generic aggregated Reservations, but the Deaggregator is 556 the entity that initiates these RSVP generic aggregated reservations. 557 Note that one RSVP generic aggregated reservation matches to only 558 one ingress-egress-aggregate, while one ingress-egress-aggregate 559 matches to either one or to more than one RSVP generic aggregated 560 reservations. This can be accomplished by using for the different 561 RSVP generic aggregated reservations the same combinations of 562 ingress and egress identifiers, but with a different PHB-ID value 563 (see [RFC4860]). The procedures for aggregation of E2E reservations 564 over generic aggregate RSVP reservations are the same as the 565 procedures specified in Section 4 of [RFC4860], augmented with the 566 ones specified in Section 2.5. 568 One significant difference between this document and [RFC4860] is the 569 fact that in this document the admission control of E2E RSVP 570 reservations over the PCN core is performed according to the PCN 571 procedures, while in [RFC4860] this is achieved via first admitting 572 aggregate RSVP reservations over the aggregation region and then 573 admitting the E2E reservations over the aggregate RSVP reservations. 574 Therefore, in this document, the RSVP generic aggregate RSVP 575 reservations are not subject to admission control in the PCN-core, 576 and the E2E RSVP reservations are not subject to admission control 577 over the aggregate reservations. In turn, this means that several 578 procedures of [RFC4860] are significantly simplified in this 579 document: 581 o) unlike [RFC4860], the generic aggregate RSVP reservations need 582 not be admitted in the PCN core. 583 o) unlike [RFC4860], the RSVP aggregated traffic does not need to 584 be tunneled between Aggregator and Deaggregator, see Section 585 2.3. 586 o) unlike [RFC4860], the Deaggregator need not perform admission 587 control of E2E reservations over the aggregate RSVP 588 reservations. 589 o) unlike [RFC4860], there is no need for dynamic adjustment of 590 the RSVP generic aggregated reservation size, see Section 2.6. 592 2.2 PCN Marking and encoding and transport of pre-congestion 593 information 595 The method of PCN marking within the PCN domain is specified in 596 [RFC5670]. In addition, the method of encoding and transport of pre- 597 congestion information is specified in [RFC6660]. The PHB-ID (Per Hop 598 Behavior Identification Code) used SHOULD be set equal 599 to PCN-compatible Diffserv codepoint(s). 601 2.3. Traffic Classification Within The Aggregation Region 603 The PCN-ingress marks a PCN-BA using PCN-marking (i.e., combination 604 of the DSCP and ECN fields), which interior nodes use to 605 classify PCN-traffic. The PCN-traffic (e.g., E2E microflows) 606 belonging to a RSVP generic aggregated reservation can be 607 classified only at the PCN-boundary-nodes (i.e., Aggregator and 608 Deaggregator) by using the RSVP SESSION object for RSVP generic 609 aggregated reservations, see Section 2.1 of [RFC4860]. Note that the 610 DSCP value included in the SESSION object, SHOULD be set equal 611 to a PCN-compatible Diffserv codepoint. Since no admission control 612 procedures over the RSVP generic aggregated reservations in the PCN- 613 core are required, unlike [RFC4860], the RSVP aggregated traffic need 614 not to be tunneled between Aggregator and Deaggregator. In this 615 document one RSVP generic aggregated reservation is mapped to only 616 one ingress-egress-aggregate, while one ingress-egress-aggregate is 617 mapped to either one or to more than one RSVP generic aggregated 618 reservations. PCN-flows and their PCN-traffic that are mapped into a 619 specific RSVP generic aggregated reservation can also easily be 620 classified into their corresponding ingress-egress-aggregate. The 621 method of traffic conditioning of PCN-traffic and non-PCN traffic and 622 PHB configuration is described in [RFC6661] and [RFC6662]. 624 2.4. Deaggregator Determination 626 The present document assumes the same dynamic Deaggregator 627 determination method as used in [RFC4860]. 629 2.5. Mapping E2E Reservations Onto Aggregate Reservations 631 To comply with this specification for the mapping of E2E reservations 632 onto aggregate reservations, the same methods MUST be used as the 633 ones described in Section 4 of [RFC4860], augmented by the following 634 rules: 636 o) An Aggregator (also PCN-ingress-node in this document) or 637 Deaggregator (also PCN-egress-node and Decision Point in this 638 document) MUST use one or more policies to determine whether a 639 RSVP generic aggregated reservation can be mapped into an ingress- 640 Egress-aggregate. This can be accomplished by using for the 641 different RSVP generic aggregated reservations the same 642 combinations of ingress and egress identifiers, but with a 643 different PHB-ID value (see [RFC4860]) corresponding to the PCN 644 specifications. In particular, the RSVP SESSION object specified 645 in [RFC4860] augmented with the following information: 647 o) the IPv4 DestAddress, IPv6 DestAddress MUST be set to the 648 IPv4 or IPv6 destination addresses, respectively, of the 649 Deaggregator (PCN-egress-node), see [RFC4860]. Note that the 650 PCN-domain is considered as being only one RSVP hop (for 651 Generic aggregated RSVP or E2E RSVP). This means that the next 652 RSVP hop for the Aggregator in the downstream direction is the 653 Deaggregator and the next RSVP hop for the Deaggregator in the 654 upstream direction is the Aggregator. 656 o) PHB-ID (Per Hop Behavior Identification Code) SHOULD be set 657 equal to PCN-compatible Diffserv codepoint(s). 659 o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 660 destination addresses, of the Aggregator (PCN-ingress-node), 661 see [RFC4860]. 663 2.6. Size of Aggregate Reservations 665 Since:(i) no admission control of E2 reservations over the RSVP 666 aggregated reservations is required, and (ii) no admission control of 667 the RSVP aggregated reservation over the PCN core is required, 668 the size of the generic aggregate reservation is irrelevant and can 669 be set to any arbitrary value by the Deaggreagtor. The Deaggregator 670 SHOULD set the value of a generic aggregate reservation to a null 671 bandwidth. We also observe that there is no need for dynamic 672 adjustment of the RSVP aggregated reservation size. 674 2.7. E2E Path ADSPEC update 676 To comply with this specification, for the update of the E2E Path 677 ADSPEC, the same methods can be used as the ones described in 678 [RFC4860]. 680 2.8. Intra-domain Routes 682 The PCN-interior-nodes are neither maintaining E2E RSVP nor RSVP 683 generic aggregation states and reservations. Therefore, intra-domain 684 route changes will not affect intra-domain reservations since such 685 reservations are not maintained by the PCN-interior-nodes. 686 Furthermore, it is considered that by configuration, the PCN- 687 interior-nodes are not able to distinguish neither RSVP generic 688 aggregated sessions and their associated messages [RFC4860], nor E2E 689 RSVP sessions and their associated messages [RFC2205]. 691 2.9. Inter-domain Routes 693 The PCN-charter scope precludes inter-domain considerations. However, 694 for solving inter-domain routes changes associated with the operation 695 of the RSVP messages, the same methods SHOULD be used as the ones 696 described in [RFC4860] and in Section 1.4.7 of 697 [RFC3175]. 699 2.10. Reservations for Multicast Sessions 701 PCN does not consider reservations for multicast sessions. 703 2.11. Multi-level Aggregation 705 PCN does not consider multi-level aggregations within the PCN domain. 706 Therefore, the PCN-interior-nodes are not supporting multi-level 707 aggregation procedures. However, the Aggregator and Deaggregator 708 SHOULD support the multi-level aggregation procedures specified in 709 [RFC4860] and in Section 1.4.9 of [RFC3175]. 711 2.12. Reliability Issues 713 To comply with this specification, for solving possible reliability 714 issues, the same methods MUST used as the ones described in Section 4 715 of [RFC4860]. 717 2.13. Message Integrity and Node Authentication 719 To comply with this specification, for message integrity and node 720 authentication, the same methods MUST be used as the ones described 721 in Section 4 of [RFC4860] and [RFC5559]. 723 3. Elements of Procedure 725 This section describes the procedures used to implement the 726 aggregated RSVP procedure over PCN. It is considered that the 727 procedures for aggregation of E2E reservations over generic aggregate 728 RSVP reservations are same as the procedures specified in Section 729 4 of [RFC4860] except where a departure from these procedures is 730 explicitly described in the present section. Please refer to 731 [RFC4860] for all the below error 732 cases: 733 o) Incomplete message 734 o) Unexpected objects 736 3.1. Receipt of E2E Path Message by Aggregating router 738 When the E2E Path message arrives at the exterior interface of the 739 Aggregator, (also PCN-ingress-node in this document), then standard 740 RSVP generic aggregation [RFC4860] procedures are used. 742 3.2. Handling Of E2E Path Message by Interior Routers 744 The E2E Path messages traverse zero or more PCN-interior-nodes. 745 The PCN-interior-nodes receive the E2E Path message on an interior 746 interface and forward it on another interior interface. 747 It is considered that, by configuration, the PCN-interior-nodes 748 ignore the E2E RSVP signaling messages [RFC2205]. Therefore, the E2E 749 Path messages are simply forwarded as normal IP datagrams. 751 3.3. Receipt of E2E Path Message by Deaggregating router 753 When receiving the E2E Path message the Deaggregator (also PCN- 754 egress-node and Decision Point in this document) performs the 755 regular [RFC4860] procedures, augmented with the following rules: 757 o) The Deaggregator MUST NOT perform the RSVP-TTL vs IP TTL- 758 check and MUST NOT update the ADspec Break bit. This is because 759 the whole PCN-domain is effectively handled by E2E RSVP as a 760 virtual link on which integrated service is indeed supported 761 (and admission control performed) so that the Break bit MUST 762 NOT be set, see also [draft-lefaucheur-rsvp-ecn-01]. 764 The Deaggregator forwards the E2E Path message towards the 765 receiver. 767 3.4. Initiation of new Aggregate Path Message by Aggregating Router 769 To comply with this specification, for the initiation of the new RSVP 770 generic aggregated Path message by the Aggregator (also PCN-ingress- 771 node in this document), the same methods MUST be used as the ones 772 described in [RFC4860]. 774 3.5. Handling Of Aggregate Path Message By Interior Routers 776 The Aggregate Path messages traverse zero or more PCN-interior-nodes. 777 The PCN-interior-nodes receive the Aggregated Path message on an 778 interior interface and forward it on another interior interface. 779 It is considered that, by configuration, the PCN-interior-nodes 780 ignore the Aggregated Path signaling messages. Therefore, the 781 Aggregated Path messages are simply forwarded as normal IP datagrams. 783 3.6. Handling Of Aggregate Path Message By Deaggregating Router 785 When receiving the Aggregated Path message, the Deaggregator (also 786 PCN-egress-node and Decision Point in this document) performs the 787 regular [RFC4860] procedures, augmented with the following rules: 789 o) When the received Aggregated Path message by the Deaggregator 790 contains the RSVP-AGGREGATE-IPv4-PCN-response or 791 RSVP-AGGREGATE-IPv6-PCN-response PCN objects, which carry the 792 PCN-sent-rate, then the procedures specified in Section 3.18 of 793 this document MUST be followed. 795 3.7. Handling of E2E Resv Message by Deaggregating Router 797 When the E2E Resv message arrives at the exterior interface of the 798 Deaggregator, (also PCN-egress-node and Decision Point in this 799 document) then standard RSVP aggregation [RFC4860] procedures are 800 used, augmented with the following rules: 802 o) The E2E RSVP session associated with an E2E Resv 803 message that arrives at the external interface of the Deaggregator 804 is mapped/matched with an RSVP generic aggregate and with a PCN 805 ingress-egress-aggregate. 807 o) Depending on the type of the PCN edge behavior supported by the 808 Deaggregator, the PCN admission control procedures specified in 809 Section 3.3.1 of [RFC6661] or [RFC6662] MUST be followed. Since no 810 admission control procedures over the RSVP aggregated reservations 811 in the PCN-core are required, unlike [RFC4860], the Deaggregator 812 does not perform any admission control of the E2E Reservation over 813 the mapped generic aggregate RSVP reservation. If the PCN based 814 admission control procedure is successful then the Deaggregator 815 MUST allow the new flow to be admitted onto the associated RSVP 816 generic aggregation reservation and onto the PCN ingress-egress- 817 aggregate, see [RFC6661] and [RFC6662]. If the PCN based admission 818 control procedure is not successful, then the E2E Resv MUST NOT be 819 admitted onto the associated RSVP generic aggregate reservation and 820 onto the PCN ingress-egress-aggregation. The E2E Resv message is 821 further processed according to [RFC4860]. 823 The way of how the PCN-admission-state is maintained is specified in 824 [RFC6661] and [RFC6662]. 826 3.8. Handling Of E2E Resv Message By Interior Routers 828 The E2E Resv messages traversing the PCN core are IP addressed to the 829 Aggregating router and are not marked with Router Alert, therefore 830 the E2E Resv messages are simply forwarded as normal IP datagrams. 832 3.9. Initiation of New Aggregate Resv Message By Deaggregating Router 834 To comply with this specification, for the initiation of the new RSVP 835 generic aggregated Resv message by the Deaggregator (also PCN-egress- 836 node and Decision Point in this document), the same methods MUST be 837 used as the ones described in 838 Section 4 of [RFC4860] augmented with the following rules: 840 o) The size of the generic aggregate reservation is irrelevant, see 841 Section 2.6, and can be set to any arbitrary value by the PCN- 842 egress node. The Deaggregator SHOULD set the value of a RSVP 843 generic aggregate reservation to a null bandwidth. We also 844 observe that there is no need for dynamic adjustment of the RSVP 845 generic aggregated reservation size. 847 o) When [RFC6661] is used and the ETM-rate measured by the 848 Deaggregator contains a non-zero value for some 849 ingress-egress-aggregate, see [RFC6661] and [RFC6662], the 850 Deagregator MUST request the PCN-ingress-node to provide an 851 estimate of the rate (PCN-sent-rate) at which the Aggregator 852 (also PCN-ingress-node in this document) is receiving PCN-traffic 853 that is destined for the given ingress-egress-aggregate. 855 o) When [RFC6662] is used and the PCN-admission-state computed by the 856 Deaggregator, on the basis of the CLE is "block" for the given 857 ingress-egress-aggregate, the Deaggregator MUST request the PCN- 858 ingress-node to provide an estimate of the rate (PCN-sent-rate) at 859 which the Aggregator is receiving PCN-traffic that is 860 destined for the given ingress-egress-aggregate. 862 o) In the above two cases and when the PCN-sent-rate needs to be 863 requested from the Aggregator, the Deaggregator MUST generate 864 and send an (refresh) Aggregated Resv message to the Aggregator 865 that MUST carry one of the following PCN objects, see Section 4.1, 866 depending on whether IPv4 or IPv6 is supported: 867 o) RSVP-AGGREGATE-IPv4-PCN-request 868 o) RSVP-AGGREGATE-IPv6-PCN-request. 870 3.10. Handling of Aggregate Resv Message by Interior Routers 872 The Aggregated Resv messages traversing the PCN core are IP addressed 873 to the Aggregating router and are not marked with Router Alert, 874 therefore the Aggregated Resv messages are simply forwarded as normal 875 IP datagrams. 877 3.11. Handling of E2E Resv Message by Aggregating Router 879 When the E2E Resv message arrives at the interior interface of the 880 Aggregator (also PCN-ingress-node in this document), then standard 881 RSVP aggregation [RFC4860] procedures are used. 883 3.12. Handling of Aggregated Resv Message by Aggregating Router 885 When the Aggregated Resv message arrives at the interior interface of 886 the Aggregator, (also PCN-ingress-node in this document), 887 then standard RSVP aggregation [RFC4860] procedures are used, 888 augmented with the following rules: 889 o) the Aggregator SHOULD use the information carried by the PCN 890 objects, see Section 4, and follow the steps specified in 891 [RFC6661], [RFC6662]. If the "R" flag carried by the 892 RSVP-AGGREGATE-IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN-request 893 PCN objects is set to ON, see Section 4.1, then the Aggregator 894 follows the steps described in Section 3.4 of [RFC6661] and 895 [RFC6662] on calculating the PCN-sent-rate. In particular, the 896 Aggregator MUST provide the estimated current rate of PCN-traffic 897 received at that node and destined for a given ingress-egress- 898 aggregate in octets per second (the PCN-sent-rate). The way this 899 rate estimate is derived is a matter of implementation, see 900 [RFC6661] or [RFC6662]. 902 o) the Aggregator initiates an Aggregated Path message. In 903 particular, when the Aggregator receives an Aggregated Resv 904 message which carries one of the following PCN objects: 905 RSVP-AGGREGATE-IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN- 906 request, with the flag "R" set to ON, see Section 4.1, the 907 Aggregator initiates an Aggregated Path message, and includes the 908 calculated PCN-sent-rate into the RSVP-AGGREGATE-IPv4-PCN-response 909 or RSVP-AGGREGATE-IPv6-PCN-response PCN objects, see Section 4.1, 910 which that MUST be carried by the Aggregated Path message. This 911 Aggregated Path message is sent towards the Deaggregator (also 912 PCN-egress-node and Decision Point in this document) that 913 requested the calculation of the PCN-sent-rate. 915 3.13. Removal of E2E Reservation 917 To comply with this specification, for the removal of E2E 918 reservations, the same methods MUST be used as the ones described in 919 Section 4 of [RFC4860] and [RFC4495]. 921 3.14. Removal of Aggregate Reservation 923 To comply with this specification, for the removal of RSVP generic 924 aggregated reservations, the same methods MUST be used as the ones 925 described in Section 4 of [RFC4860] and Section 2.10 of [RFC3175]. In 926 particular, should an aggregate reservation go away (presumably due 927 to a configuration change, route change, or policy event), the E2E 928 reservations it supports are no longer active. 929 They MUST be treated accordingly. 931 3.15. Handling of Data On Reserved E2E Flow by Aggregating Router 933 The handling of data on the reserved E2E flow by Aggregator (also 934 PCN-ingress-node in this document) uses the procedures described 935 in [RFC4860] augmented with: 936 o) Regarding, PCN marking and traffic classification the procedures 937 defined in Section 2.2 and 2.3 of this document are used. 939 3.16. Procedures for Multicast Sessions 941 In this document no multicast sessions are considered. 943 3.17. Misconfiguration of PCN-node 945 In an event where a PCN-node is misconfigured within a PCN-domain, 946 the desired behavior is same as described in Section 3.10. 948 3.18 PCN based Flow Termination 950 When the Deaggregator (also PCN-egress-node and Decision Point in 951 this document) needs to terminate an amount of traffic associated 952 with one ingress-egress-aggregate (see Section 3.3.2 of [RFC6661] and 953 [RFC6662]), then several procedures of terminating E2E microflows can 954 be deployed. The default procedure of terminating E2E microflows 955 (i.e., PCN-flows) is as follows, see i.e., [RFC6661] and [RFC6662]. 957 For the same ingress-egress-aggregate, select a number of E2E 958 microflows to be terminated in order to decrease the total incoming 959 amount of bandwidth associated with one ingress-egress-aggregate by 960 the amount of traffic to be terminated, see above. In this situation 961 the same mechanisms for terminating an E2E microflow can be followed 962 as specified in [RFC2205]. However, based on a local policy, the 963 Deaggregator could use other ways of selecting which microflows 964 should be terminated. For example, for the same ingress-egress- 965 aggregate, select a number of E2E microflows to be terminated or to 966 reduce their reserved bandwidth in order to decrease the total 967 incoming amount of bandwidth associated with one ingress-egress- 968 aggregate by the amount of traffic to be terminated. In this 969 situation the same mechanisms for terminating an E2E microflow or 970 reducing bandwidth associated with an E2E microflow can be followed 971 as specified in [RFC4495]. 973 4. Protocol Elements 975 The protocol elements in this document are using the ones defined in 976 Section 4 of [RFC4860] and Section 3 of [RFC3175] augmented with the 977 following rules: 978 o) the DSCP value included in the SESSION object, SHOULD be set equal 979 to a PCN-compatible Diffserv codepoint. 981 o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination 982 addresses, of the Aggregator (also PCN-ingress-node in this 983 document), see [RFC4860]. 985 o) When the Deaggregator (also PCN-egress-node and Decision Point 986 in this document) needs to request the PCN-sent-rate from the 987 PCN-ingress-node, see Section 3.9 of this document, the 988 Deaggregator MUST generate and send an (refresh) Aggregate 989 Resv message to the Aggregator that MUST carry one of the 990 following PCN objects, see Section 4.1, depending on whether IPv4 991 or IPv6 is supported: 992 o) RSVP-AGGREGATE-IPv4-PCN-request 993 o) RSVP-AGGREGATE-IPv6-PCN-request. 995 o) When the Aggregator receives an Aggregate Resv message which 996 carries one of the following PCN objects: 997 RSVP-AGGREGATE-IPv4-PCN-request or 998 RSVP-AGGREGATE-IPv6-PCN-request, with the flag "R" set to ON, see 999 Section 4.1, then the Aggregator MUST generate and send to the 1000 Deaggregator an Aggregated Path message which carries one of the 1001 following PCN objects, see Section 4.1, depending on whether IPv4 1002 or IPv6 is supported: 1003 o) RSVP-AGGREGATE-IPv4-PCN-response, 1004 o) RSVP-AGGREGATE-IPv6-PCN-response. 1006 4.1 PCN objects 1008 This section describes four types of PCN objects that can be carried 1009 by the (refresh) Aggregate Path or the (refresh) Aggregate Resv 1010 messages specified in [RFC4860]. 1012 These objects are: 1013 o RSVP-AGGREGATE-IPv4-PCN-request, 1014 o RSVP-AGGREGATE-IPv6-PCN-request, 1015 o RSVP-AGGREGATE-IPv4-PCN-response, 1016 o RSVP-AGGREGATE-IPv6-PCN-response. 1018 o) RSVP-AGGREGATE-IPv4-PCN-request: PCN request object, when 1019 IPv4 addresses are used: 1020 Class = 248 (PCN) 1021 C-Type = 1 (RSVP-AGGREGATE-IPv4-PCN-request 1023 +-------------+-------------+-------------+-------------+ 1024 | IPv4 PCN-ingress-node Address (4 bytes) | 1025 +-------------+-------------+-------------+-------------+ 1026 | IPv4 PCN-egress-node Address (4 bytes) | 1027 +-------------+-------------+-------------+-------------+ 1028 | IPv4 Decision Point Address (4 bytes) | 1029 +-------------+-------------+-------------+-------------+ 1030 |R| Reserved | 1031 +-------------+-------------+-------------+-------------| 1033 o) RSVP-AGGREGATE-IPv6-PCN-request: PCN object, when 1034 IPv6 addresses are used: 1036 Class = 248 (PCN) 1037 C-Type = 2 (RSVP-AGGREGATE-IPv6-PCN-request 1039 +-------------+-------------+-------------+-------------+ 1040 | | 1041 + + 1042 | | 1043 + IPv6 PCN-ingress-node Address (16 bytes) + 1044 | | 1045 + + 1046 | | 1047 +-------------+-------------+-------------+-------------+ 1048 | | 1049 + + 1050 | | 1051 + IPv6 PCN-egress-node Address (16 bytes) + 1052 | | 1053 + + 1054 | | 1055 +-------------+-------------+-------------+-------------+ 1056 | | 1057 + + 1058 | | 1059 + Decision Point Address (16 bytes) + 1060 | | 1061 + + 1062 | | 1063 +-------------+-------------+-------------+-------------+ 1064 |R| Reserved | 1065 +-------------+-------------+-------------+-------------+ 1067 o) RSVP-AGGREGATE-IPv4-PCN-response: PCN object, IPv4 1068 addresses are used: 1069 Class = 248 (PCN) 1070 C-Type = 3 (RSVP-AGGREGATE-IPv4-PCN-response) 1072 +-------------+-------------+-------------+-------------+ 1073 | IPv4 PCN-ingress-node Address (4 bytes) | 1074 +-------------+-------------+-------------+-------------+ 1075 | IPv4 PCN-egress-node Address (4 bytes) | 1076 +-------------+-------------+-------------+-------------+ 1077 | IPv4 Decision Point Address (4 bytes) | 1078 +-------------+-------------+-------------+-------------+ 1079 | PCN-sent-rate | 1080 +-------------+-------------+-------------+-------------+ 1082 o) RSVP-AGGREGATE-IPv6-PCN-response: PCN object, IPv6 1083 addresses are used: 1084 Class = 248 (PCN) 1085 C-Type = 4 (RSVP-AGGREGATE-IPv6-PCN-response) 1087 +-------------+-------------+-------------+-------------+ 1088 | | 1089 + + 1090 | | 1091 + IPv6 PCN-ingress-node Address (16 bytes) + 1092 | | 1093 + + 1094 | | 1095 +-------------+-------------+-------------+-------------+ 1096 | | 1097 + + 1098 | | 1099 + IPv6 PCN-egress-node Address (16 bytes) + 1100 | | 1101 + + 1102 | | 1103 +-------------+-------------+-------------+-------------+ 1104 | | 1105 + + 1106 | | 1107 + Decision Point Address (16 bytes) + 1108 | | 1109 + + 1110 | | 1111 +-------------+-------------+-------------+-------------+ 1112 | PCN-sent-rate | 1113 +-------------+-------------+-------------+-------------+ 1115 The fields carried by the PCN object are specified in 1116 [RFC6663], [RFC6661] and [RFC6662]: 1118 o the IPv4 or IPv6 address of the PCN-ingress-node (Aggregator) and 1119 the IPv4 or IPv6 address of the PCN-egress-node (Deaggregator); 1120 together they specify the ingress-egress-aggregate to which the 1121 report refers. According to [RFC6663] the report should carry the 1122 identifier of the PCN-ingress-node (Aggregator) and the 1123 identifier of the PCN-egress-node (Deaggregator) (typically 1124 their IP addresses); 1126 o Decision Point address specify the IPv4 or IPv6 address of the 1127 Decision Point. In this document this field MUST contain the IP 1128 address of the Deaggregator. 1130 o "R": 1 bit flag that when set to ON, signifies, according to 1131 [RFC6661] and [RFC6662], that the PCN-ingress-node (Aggregator) 1132 MUST provide an estimate of the rate (PCN-sent-rate) at which the 1133 PCN-ingress-node (Aggregator) is receiving PCN-traffic that is 1134 destined for the given ingress-egress-aggregate. 1136 O "Reserved": 31 bits that are currently not used by this 1137 document and are reserved. These SHALL be set to 0 and SHALL be 1138 ignored on reception. 1140 o PCN-sent-rate: the PCN-sent-rate for the given 1141 ingress-egress-aggregate. It is expressed in octets/second; its 1142 format is a 32-bit IEEE floating point number; The PCN-sent-rate 1143 is specified in [RFC6661] and [RFC6662] and it represents the 1144 estimate of the rate at which the PCN-ingress-node (Aggregator) 1145 is receiving PCN-traffic that is destined for the given 1146 ingress-egress-aggregate. 1148 5. Security Considerations 1150 The same security considerations specified in [RFC2205], [RFC4230], 1151 [RFC4860], [RFC5559] and [RFC6411]. 1153 6. IANA Considerations 1155 IANA has modified the RSVP parameters registry, 'Class Names, 1156 Class Numbers, and Class Types' subregistry, to add a new 1157 Class Number and assign 4 new C-Types under this new Class 1158 Number, as described below, see Section 4.1: 1160 Class 1161 Number Class Name Reference 1162 ------ ---------------------- --------- 1163 248 PCN this document 1165 Class Types or C-Types: 1166 1 RSVP-AGGREGATE-IPv4-PCN-request this document 1167 2 RSVP-AGGREGATE-IPv6-PCN-request this document 1168 3 RSVP-AGGREGATE-IPv4-PCN-response this document 1169 4 RSVP-AGGREGATE-IPv6-PCN-response this document 1171 When this draft is published as an RFC, IANA should update the 1172 reference for the above 5 items to that published RFC (and the RFC 1173 Editor should remove this sentence). 1175 7. Acknowledgments 1177 We would like to thank the authors of [draft-lefaucheur-rsvp-ecn- 1178 01.txt], since some ideas used in this document are based on the work 1179 initiated in [draft-lefaucheur-rsvp-ecn-01.txt]. Moreover, we would 1180 like to thank Bob Briscoe, David Black, Ken Carlberg, Tom Taylor, 1181 Philip Eardley, Michael Menth, Toby Moncaster, James Polk, Scott 1182 Bradner and Lixia Zhang for the provided comments. In particular, we 1183 would like to thank Francois Le Faucheur for contributing in addition 1184 to comments also to a significant amount of text. 1186 8. Normative References 1188 [RFC6661] T. Taylor, A, Charny, F. Huang, 1189 G. Karagiannis, M. Menth, "PCN Boundary Node Behaviour for the 1190 Controlled Load (CL) Mode of Operation", July 1191 2012. 1193 [RFC6662] A. Charny, J. Zhang, 1194 G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node Behaviour 1195 for the Single Marking (SM) Mode of Operation", 1196 July 2012. 1198 [RFC6663] G. Karagiannis, T. Taylor, 1199 K. Chan, M. Menth, P. Eardley, " Requirements for Signaling of (Pre-) 1200 Congestion Information in a DiffServ Domain", 1201 July 2012. 1203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1204 Requirement Levels", BCP 14, RFC 2119, March 1997. 1206 [RFC2205] Braden, R., ed., et al., "Resource ReSerVation Protocol 1207 (RSVP)- Functional Specification", RFC 2205, September 1997. 1209 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le 1210 Faucheur, "Per Hop Behavior Identification Codes", 1211 RFC 3140, June 2001. 1213 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1214 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 1215 September 2001. 1217 [RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation 1218 Protocol (RSVP) Extension for the Reduction of 1219 Bandwidth of a Reservation Flow", RFC 4495, May 2006. 1221 [RFC4860] F. Le Faucheur, B. Davie, P. Bose, C. Christou, M. 1222 Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) 1223 Reservations", RFC4860, May 2007. 1225 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", 1226 RFC 5670, November 2009. 1228 [RFC6660] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 1229 Encoding and Transport of Pre-Congestion Information", RFC 6660, 1230 July 2012. 1232 9. Informative References 1234 [draft-lefaucheur-rsvp-ecn-01.txt] Le Faucheur, F., Charny, A., 1235 Briscoe, B., Eardley, P., Chan, K., and J. Babiarz, "RSVP Extensions 1236 for Admission Control over Diffserv using Pre-congestion 1237 Notification (PCN) (Work in progress)", June 2006. 1239 [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated 1240 Services in the Internet Architecture: an Overview", RFC 1633, June 1241 1994. 1243 [RFC2211] J. Wroclawski, Specification of the Controlled-Load Network 1244 Element Service, September 1997 1246 [RFC2212] S. Shenker et al., Specification of Guaranteed Quality of 1247 Service, September 1997 1249 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1250 "Definition of the Differentiated Services Field (DS Field) in the 1251 IPv4 and IPv6 Headers", RFC 2474, December 1998. 1253 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and 1254 W. Weiss, "A framework for Differentiated Services", RFC 2475, 1255 December 1998. 1257 [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 1258 Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A 1259 Framework for Integrated Services Operation Over DiffServ Networks", 1260 RFC 2998, November 2000. 1262 [RFC4230] H. Tschofenig, R. Graveman, "RSVP Security Properties", 1263 RFC 4230, December 2005. 1265 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 1266 Architecture", RFC 5559, June 2009. 1268 [RFC6411] M. Behringer, F. Le Faucheur, B. Weis, "Applicability of 1269 Keying Methods for RSVP Security", RFC 6411, October 2011. 1271 [SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested 1272 Virtual Private Network", Work in Progress, July 2007. 1274 [RFC2753] Yavatkar, R., D. Pendarakis and R. Guerin, "A Framework for 1275 Policy-based Admission Control", January 2000. 1277 10. Appendix A: Example Signaling Flow 1279 This appendix is based on the appendix provided in [RFC4860]. In 1280 particular, it provides an example signaling flow of the 1281 specification detailed in Section 3 and 4. 1283 This signaling flow assumes an environment where E2E reservations are 1284 aggregated over generic aggregate RSVP reservations and applied over 1285 a PCN domain. In particular the Aggregator (PCN-ingress-node) and 1286 Deaggregator (PCN-egress-node) are located at the boundaries of the 1287 PCN domain. The PCN-interior-nodes are located within the PCN-domain, 1288 between the PCN-boundary nodes, but are not shown in this Figure. It 1289 illustrates a possible RSVP message flow that could take place in the 1290 successful establishment of a unicast E2E reservation that is the 1291 first between a given pair of Aggregator/Deaggregator. 1293 Aggregator (PCN-ingress-node) Deaggregator (PCN-egress-node) 1295 E2E Path 1296 -----------> 1297 (1) 1298 E2E Path 1299 -------------------------------> 1300 (2) 1301 E2E PathErr(New-agg-needed,SOI=GApcn) 1302 <---------------------------------- 1303 (3) 1304 AggPath(Session=GApcn) 1305 -------------------------------> 1306 (4) 1307 E2E Path 1308 -----------> 1309 (5) 1310 AggResv (Session=GApcn) (PCN object) 1311 <------------------------------- 1312 (6) 1313 AggResvConfirm (Session=GApcn) 1314 ------------------------------> 1315 (7) 1316 E2E Resv 1317 <--------- 1318 (8) 1319 E2E Resv (SOI=GApcn) 1320 <----------------------------- 1321 (9) 1322 E2E Resv 1323 <----------- 1325 (1) The Aggregator forwards E2E Path into the aggregation region 1326 after modifying its IP protocol number to RSVP-E2E-IGNORE 1328 (2) Let's assume no Aggregate Path exists. To be able to accurately 1329 update the ADSPEC of the E2E Path, the Deaggregator needs the 1330 ADSPEC of Aggregate Path. In this example, the Deaggregator 1331 elects to instruct the Aggregator to set up an Aggregate Path 1332 state for the PCN PHB-ID. To do that, the Deaggregator 1333 sends an E2E PathErr message with a New-Agg-Needed PathErr 1334 code. 1336 The PathErr message also contains a SESSION-OF-INTEREST 1337 (SOI) object. The SOI contains a GENERIC-AGGREGATE SESSION 1338 (GApcn) whose PHB-ID is set to the PCN PHB-ID. The GENERIC- 1339 AGGREGATE SESSION contains an interface-independent Deaggregator 1340 address inside the DestAddress and appropriate values inside the 1341 vDstPort and Extended vDstPort fields. In this document, the 1342 Extended vDstPort SHOULD contain the IPv4 or IPv6 address of 1343 the Aggregator. 1345 (3) The Aggregator follows the request from the Deaggregator and 1346 signals an Aggregate Path for the GENERIC-AGGREGATE Session 1347 (GApcn). 1349 (4) The Deaggregator takes into account the information contained in 1350 the ADSPEC from both Aggregate Paths and updates the E2E Path 1351 ADSPEC accordingly. The PCN-egress-node MUST NOT perform the 1352 RSVP-TTL vs IP TTL-check and MUST NOT update the ADspec Break 1353 bit. This is because the whole PCN-domain is effectively handled 1354 by E2E RSVP as a virtual link on which integrated service is 1355 indeed supported (and admission control performed) so that the 1356 Break bit MUST NOT be set, see also 1357 [draft-lefaucheur-rsvp-ecn-01]. The Deaggregator also modifies 1358 the E2E Path IP protocol number to RSVP before forwarding it. 1360 (5) In this example, the Deaggregator elects to immediately proceed 1361 with establishment of the generic aggregate reservation. In 1362 effect, the Deaggregator can be seen as anticipating 1363 the actual demand of E2E reservations so that the generic 1364 aggregate reservation is in place when the E2E Resv 1365 request arrives, in order to speed up establishment of E2E 1366 reservations. Here it is also assumed that the Deaggregator 1367 includes the optional Resv Confirm Request in the Aggregate 1368 Resv message. 1370 (6) The Aggregator merely complies with the received ResvConfirm 1371 Request and returns the corresponding Aggregate ResvConfirm. 1373 (7) The Deaggregator has explicit confirmation that the generic 1374 aggregate reservation is established. 1376 (8) On receipt of the E2E Resv, the Deaggregator applies the mapping 1377 policy defined by the network administrator to map the E2E Resv 1378 onto a generic aggregate reservation. Let's assume that this 1379 policy is such that the E2E reservation is to be mapped onto the 1380 generic aggregate reservation with the PCN PHB-ID=x. The 1381 Deaggregator knows that a generic aggregate reservation (GApcn) 1382 is in place for the corresponding PHB-ID since (7). At this step 1383 the Deaggregator maps the generic aggregated reservation onto one 1384 ingress-egress-aggregate maintained by the Deaggregator (as a 1385 PCN-egress-node), see Section 3.7. The Deaggregator performs 1386 admission control of the E2E Resv onto the generic Aggregate 1387 reservation for the PCN PHB-ID (GApcn). The Deaggregator takes 1388 also into account the PCN admission control procedure as 1389 as specified in [RFC6661] and [RFC6662], see Section 3.7. 1391 If one or both the admission control procedures (PCN based 1392 admission control procedure and admission control procedure 1393 specified in [RFC4860]) are not successful, then the E2E Resv is 1394 not admitted onto the associated RSVP generic aggregate 1395 reservation for the PCN PHB-ID (GApcn). Otherwise, assuming that 1396 the generic aggregate reservation for the PCN (GApcn) had been 1397 established with sufficient bandwidth to support the E2E Resv, 1398 the Deaggregator adjusts its counter, tracking the unused 1399 bandwidth on the generic aggregate reservation. Then it forwards 1400 the E2E Resv to the Aggregator including a SESSION-OF-INTEREST 1401 object conveying the selected mapping onto GApcn (and hence onto 1402 the PCN PHB-ID). 1404 (9) The Aggregator records the mapping of the E2E Resv onto GApcn 1405 (and onto the PCN PHB-ID). The Aggregator removes the SOI object 1406 and forwards the E2E Resv towards the sender. 1408 11. Authors' Address 1410 Georgios Karagiannis 1411 University of Twente 1412 P.O. Box 217 1413 7500 AE Enschede, 1414 The Netherlands 1415 EMail: g.karagiannis@utwente.nl 1417 Anurag Bhargava 1418 Cisco Systems, Inc. 1419 7100-9 Kit Creek Road 1420 PO Box 14987 1421 RESEARCH TRIANGLE PARK, NORTH CAROLINA 27709-4987 1422 USA 1423 Email: anuragb@cisco.com