idnits 2.17.1 draft-ietf-tsvwg-rsvp-pcn-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4860]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 23, 2013) is 4051 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: August 23, 2013 Cisco Systems, Inc. 5 February 23, 2013 7 Generic Aggregation of Resource ReSerVation Protocol (RSVP) 8 for IPv4 And IPv6 Reservations over PCN domains 9 draft-ietf-tsvwg-rsvp-pcn-04 11 Abstract 13 This document specifies extensions to Generic Aggregated RSVP 14 [RFC4860] 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 August 23, 2013. 35 Copyright Notice 37 Copyright (c) 2013 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 . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . 14 73 2.10. Reservations for Multicast Sessions . . . . . . . . . . . . . . 14 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) . . . . . . . . . . . . . . . . . . . . . 17 85 3.5. Handling Of new Aggregate Path Message By Interior Routers . . 17 86 3.6. Handling of E2E Resv Message by Deaggregating Router . . . . . 17 87 3.7. Handling Of E2E Resv Message By Interior Routers . . . . . . . 17 88 3.8. Initiation of New Aggregate Resv Message By Deaggregating Router 17 89 3.9. Handling of Aggregate Resv Message by Interior Routers . . . . 18 90 3.10. Handling of E2E Resv Message by Aggregating Router . . . . . . 18 91 3.11. Handling of Aggregated Resv Message by Aggregating Router . . 18 92 3.12. Removal of E2E Reservation . . . . . . . . . . . . . . . . . . 19 93 3.13. Removal of Aggregate Reservation . . . . . . . . . . . . . . . 19 94 3.14. Handling of Data On Reserved E2E Flow by Aggregating Router . 19 95 3.15. Procedures for Multicast Sessions . . . . . . . . . . . . . . 19 96 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 19 97 4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 25 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 25 100 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 25 102 9. Informative References . . . . . . . . . . . . . . . . . . . . . 26 103 10. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 27 104 1. Introduction 106 1.1 Objective 108 Pre-Congestion Notification (PCN) can support the quality of service 109 (QoS) of inelastic flows within a Diffserv domain in a simple, 110 scalable, and robust fashion. Two mechanisms are used: admission 111 control and flow termination. Admission control is used to decide 112 whether to admit or block a new flow request, while flow termination 113 is used in abnormal circumstances to decide whether to terminate some 114 of the existing flows. To support these two features, the overall 115 rate of PCN-traffic is metered on every link in the domain, and PCN- 116 packets are appropriately marked when certain configured rates are 117 exceeded. These configured rates are below the rate of the link, 118 thus providing notification to boundary nodes about overloads before 119 any congestion occurs (hence "pre-congestion" notification). The 120 PCN-egress-nodes measure the rates of differently marked PCN traffic 121 in periodic intervals and report these rates to the Decision Points 122 for admission control and flow termination; the Decision Points use 123 these rates to make decisions. The Decision Points may be collocated 124 with the PCN-ingress-nodes, or their function may be implemented in a 125 centralized node. For more details see [RFC5559], [RFC6661], and 126 [RFC6662]. 128 The main objective of this document is to specify the signalling 129 protocol that can be used within a Pre-Congestion Notification (PCN) 130 domain to carry reports from a PCN-egress-node to a PCN Decision 131 point, considering that the PCN decision Point and PCN-ingress-node 132 are collocated. 133 If the PCN decision point is not collocated with the PCN-ingress-node 134 then additional signalling procedures are required that are out of 135 the scope of this document. 137 Several signaling protocols can be used to carry reports from a PCN- 138 egress-node to a PCN-ingress-nodes. However, since both PCN-egress- 139 node and PCN-ingress-nodes are located on the data path, a signaling 140 protocol that follows the same path as the data path, like RSVP 141 (Resource Reservation Protocol), is more suited for this purpose. In 142 particular, this document specifies extensions to Generic 143 Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) 144 and Single Marking (SM) edge behaviors over a Diffserv cloud using 145 Pre-Congestion Notification. 147 1.2 Overview and Motivation 149 Two main Quality of Service (QoS) architectures have been specified 150 by the IETF. These are the Integrated Services (Intserv) [RFC1633] 151 architecture and the Differentiated Services (DiffServ) architecture 152 ([RFC2475]). 154 Intserv provides methods for the delivery of end-to-end Quality of 155 Service (QoS) to applications over heterogeneous networks. One of the 156 QoS signaling protocols used by the Intserv architecture is the 157 Resource reServation Protocol (RSVP) [RFC2205], which can be used by 158 applications to request per-flow resources from the network. These 159 RSVP requests can be admitted or rejected by the network. 160 Applications can express their quantifiable resource requirements 161 using Intserv parameters as defined in [RFC2211] and [RFC2212]. The 162 Controlled Load (CL) service [RFC2211] is a quality of service (QoS) 163 closely approximating the QoS that the same flow would receive from a 164 lightly loaded network element. The CL service is useful for 165 inelastic flows such as those used for real-time media. 167 The DiffServ architecture can support the differentiated treatment of 168 packets in very large scale environments. While Intserv and RSVP 169 classify packets per-flow, Diffserv networks classify packets into 170 one of a small number of aggregated flows or "classes", based on the 171 Diffserv codepoint (DSCP) in the packet IP header. At each Diffserv 172 router, packets are subjected to a "per-hop behavior" (PHB), which is 173 invoked by the DSCP. The primary benefit of Diffserv is its 174 scalability, since the need for per-flow state and per-flow 175 processing, is eliminated. 177 However, DiffServ does not include any mechanism for communication 178 between applications and the network. Several solutions have been 179 specified to solve this issue. One of these solutions is Intserv over 180 Diffserv [RFC2998] including resource-based admission control, 181 policy-based admission control, assistance in traffic 182 identification/classification, and traffic conditioning. 183 Intserv over Diffserv can operate over a statically provisioned 184 Diffserv region or RSVP aware. When it is RSVP aware, several 185 mechanisms may be used to support dynamic provisioning and topology- 186 aware admission control, including aggregate RSVP reservations, per- 187 flow RSVP, or a bandwidth broker. 188 [RFC3175] specifies aggregation of Resource ReSerVation 189 Protocol (RSVP) end-to-end reservations over aggregate RSVP 190 reservations. In [RFC3175] the RSVP aggregated reservation is 191 characterized by a RSVP SESSION object using the 3-tuple . 194 Several scenarios require the use of multiple generic aggregate 195 reservations that are established for a given PHB from a given source 196 IP address to a given destination IP address, see [SIG-NESTED], 197 [RFC4860]. For example, multiple generic aggregate reservations 198 can be applied in the situation that multiple e2e reservations using 199 different preemption priorities need to be aggregated through a PCN- 200 domain using the same PHB. By using multiple aggregate reservations 201 for the same PHB allows enforcement of the different preemption 202 priorities within the aggregation region. This allows more efficient 203 management of the Diffserv resources, and in periods of resource 204 shortage, this allows sustainment of a larger number of E2E 205 reservations with higher preemption priorities. In particular, 206 [SIG-NESTED] discusses in detail how end-to-end RSVP reservations can 207 be established in a nested VPN environment through RSVP aggregation. 209 [RFC4860] provides generic aggregate reservations by extending 210 [RFC3175] to support multiple aggregate reservations for the same 211 source IP address, destination IP address, and PHB (or set of PHBs). 212 In particular, multiple such generic aggregate reservations can be 213 established for a given PHB from a given source IP address to a given 214 destination IP address. This is achieved by adding the concept of a 215 Virtual Destination Port and of an Extended Virtual Destination Port 216 in the RSVP SESSION object. In addition to this, the RSVP SESSION 217 object for generic aggregate reservations uses the PHB Identification 218 Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv 219 Code Point (DSCP) used in [RFC3175]. The PHB-ID is used to identify 220 the PHB, or set of PHBs, from which the Diffserv resources are to be 221 reserved. 223 The RSVP like signaling protocol required to carry reports from a 224 PCN-egress-node to a PCN-ingress-node needs to follow the PCN 225 signaling requirements defined in [RFC6663]. In addition to 226 that the signalling protocol functionality supported by the PCN- 227 ingress-nodes and PCN-egress-nodes needs to maintain logical 228 aggregate constructs (i.e. ingress-egrees-aggregate state) and be 229 able to map e2e reservations to these aggregate constructs. Moreover, 230 no actual reservation state is needed to be maintained inside the PCN 231 domain, i.e., the PCN-interior-nodes are not maintaing any 232 reservation state. 234 This can be accomplished by two possible approaches: 236 Approach (1): 238 o) adapting the RFC 4860 aggregation procedures to fit the PCN 239 requirements with as little change as possible over the RFC 4860 240 functionality 242 o) hence performing aggregate RSVP signaling (even if it is to be 243 ignored by PCN interior nodes) 245 o) using this aggregate RSVP signaling procedures to carry PCN 246 information from PCN-egress-node to the PCN-ingress-node. 248 Approach (2): 250 o) adapting the RFC 4860 aggregation procedures to fit the PCN 251 requirements with more significant changes over RFC4860 (i.e. 252 the aspect of the procedures that have to do with maintaining 253 aggregate states and to do with mapping the e2e reservations to 254 aggregate constructs are kept, but the procedures that have to 255 do with the aggregate RSVP signaling and aggregate reservation 256 establishment/maintenance are dropped). 258 o) hence not performing aggregate RSVP signaling 260 o) piggy-backing of the PCN information inside the e2e RSVP 261 signaling. 263 Both approaches are probably viable, however, since the RFC 4860 264 operations have been thoroughly studied and implemented, it can be 265 considered that the RFC 4860 solution can better deal with the more 266 challenging situations (rerouting in the PCN domain, failure of an 267 PCN-ingress-node, failure of an PCN-egress-node, rerouting towards a 268 different edge, etc.). This is also the reason of chossing Approach 269 (1) for the specification of the signaling protocol used to carry PCN 270 information from the PCN-egress-node to the PCN-ingress-node. In 271 particular, this document specifies extensions to Generic 272 Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) 273 and Single Marking (SM) edge behaviors over a Diffserv cloud using 274 Pre-Congestion Notification. 276 This document follows the PCN signaling requirements defined in 277 [RFC6663] and specifies extensions to Generic Aggregated RSVP 278 [RFC4860] for support of PCN edge behaviors as specified in 279 [RFC6661] and [RFC6662]. Moreover, this document specifies how RSVP 280 aggregation can be used to setup and maintain: (1) Ingress Egress 281 Aggregate (IEA) states at Ingress and Egress nodes and (2) generic 282 aggregation of RSVP end-to-end RSVP reservations over PCN (Congestion 283 and Pre-Congestion Notification) domains. 285 To comply with this specification, PCN-nodes MUST be able to 286 support the functionality specified in [RFC5670], [RFC5559], 287 [RFC6660], [RFC6661], [RFC6662]. Furthermore, the PCN-boundary-nodes 288 MUST support the RSVP generic aggregated reservation procedures 289 specified in [RFC4860] which are augmented with procedures specified 290 in this document. 292 1.3. Terminology 294 This document uses terms defined in [RFC4860], [RFC3175], [RFC5559], 295 [RFC5670], [RFC6661], [RFC6662]. 297 For readability, a number of definitions from [RFC3175] as well as 298 definitions for terms used in [RFC5559], [RFC6661], and [RFC6662] are 299 provided here, where some of them are augmented with new meanings: 301 Aggregator This is the process in (or associated with) the 302 router at the ingress edge of the aggregation region 303 (with respect to the end-to-end RSVP reservation) 304 and behaving in accordance with [RFC4860]. In this 305 document, it is also the PCN-ingress-node and the 306 decision point. 308 Deaggregator This is the process in (or associated with) the 309 router at the egress edge of the aggregation region 310 (with respect to the end-to-end RSVP reservation) 311 and behaving in accordance with [RFC4860]. In this 312 document, it is also the PCN-egress-node. 314 E2E (or e2e) end to end 316 E2E Reservation This is an RSVP reservation such that: 318 (i) corresponding RSVP Path messages are initiated 319 upstream of the Aggregator and terminated 320 downstream of the Deaggregator, and 322 (ii) corresponding RSVP Resv messages are initiated 323 downstream of the Deaggregator and terminated 324 upstream of the Aggregator, and 326 (iii) this RSVP reservation is aggregated over an 327 Ingress Egress Aggregate (IEA) between the 328 Aggregator and Deaggregator. 329 An E2E RSVP reservation may be a per-flow 330 reservation, which in this document is only 331 maintained at the PCN-ingress-node and PCN-egress- 332 node. Alternatively, the E2E reservation may itself 333 be an aggregate reservation of various types (e.g., 334 Aggregate IP reservation, Aggregate IPsec 335 reservation, see [RFC4860]). As per regular RSVP 336 operations, E2E RSVP reservations are 337 unidirectional. 339 PHB-ID (Per Hop Behavior Identification Code) 340 A 16-bit field containing the Per Hop Behavior 341 Identification Code of the PHB, or of the set of 342 PHBs, from which Diffserv resources 343 are to be reserved. This field MUST be encoded as 344 specified in Section 2 of [RFC3140]. 346 VDstPort (Virtual Destination Port) 348 A 16-bit identifier used in the SESSION that 349 remains constant over the life of the generic 350 aggregate reservation. 352 Extended vDstPort (Extended Virtual Destination Port) 354 An identifier used in the SESSION that remains 355 constant over the life of the generic aggregate 356 reservation. The length of this idenitifier is 32- 357 bits when IPv4 addresses are used and 128 bits when 358 IPv6 addresses are used. A sender(or Aggregator) 359 that wishes to narrow the scope of a SESSION to the 360 sender-receiver pair (or Aggregator-Deaggregator 361 pair) SHOULD place its IPv4 or IPv6 address here as 362 a network unique identifier. A sender (or 363 Aggregator) that wishes to use a common session 364 with other senders (or Aggregators) in order to use 365 a shared reservation across senders (or 366 Aggregators) MUST set this field to all zeros. 368 In this document, the Extended vDstPort SHOULD 369 contain the IPv4 or IPv6 address of the Aggregator. 371 PCN-domain: a PCN-capable domain; a contiguous set of 372 PCN-enabled nodes that perform Diffserv scheduling 373 [RFC2474]; the complete set of PCN-nodes that in 374 principle can, through PCN-marking packets, 375 influence decisions about flow admission and 376 termination for the PCN-domain; includes 377 the PCN-egress-nodes, which measure these 378 PCN-marks, and the PCN-ingress-nodes. 380 PCN-boundary-node: a PCN-node that connects one PCN-domain to a node 381 either in another PCN-domain or in a non-PCN-domain. 383 PCN-interior-node: a node in a PCN-domain that is not a PCN- 384 boundary-node. 386 PCN-node: a PCN-boundary-node or a PCN-interior-node. 388 PCN-egress-node: a PCN-boundary-node in its role in handling 389 traffic as it leaves a PCN-domain. 391 PCN-ingress-node: a PCN-boundary-node in its role in handling 392 traffic as it enters a PCN-domain. In this 393 document the PCN-ingress-node operates also as a 394 Decision Point and aggregator. 396 PCN-traffic, 397 PCN-packets, 398 PCN-BA: a PCN-domain carries traffic of different Diffserv 399 behavior aggregates (BAs) [RFC2474]. The PCN-BA 400 uses the PCN mechanisms to carry PCN-traffic, and 401 the corresponding packets are PCN-packets. 402 The same network will carry traffic of other 403 Diffserv BAs. The PCN-BA is 404 distinguished by a combination of the Diffserv 405 codepoint (DSCP) and ECN fields. 407 Microflow: a single instance of an application-to-application 408 (from [RFC2474]) flow of packets which is identified by source 409 address, destination address, protocol id, and 410 source port, destination port (where applicable). 412 e2e microflow a microflow where its associated packets are being 413 forwarded on an E2E path. 415 PCN-flow: the unit of PCN-traffic that the PCN-boundary-node 416 admits (or terminates); the unit could be a single 417 e2e microflow (as defined in [RFC2474]) or some 418 identifiable collection of microflows. 420 RSVP generic aggregated reservation: an RSVP reservation that is 421 identified by using the RSVP SESSION object 422 for generic RSVP aggregate reservation. This RSVP 423 SESSION object is based on the RSVP SESSION object 424 specified in [RFC4860] augmented with the following 425 information: 426 o) the IPv4 DestAddress, IPv6 DestAddress SHOULD be 427 set to the IPv4 or IPv6 destination addresses, 428 respectively, of the Deaggregator (PCN-egress- 429 node) 431 o) PHB-ID (Per Hop Behavior Identification Code) 432 SHOULD be set equal to PCN-compatible Diffserv 433 codepoint(s). 435 o) Extended vDstPort SHOULD be set to the IPv4 or 436 IPv6 destination addresses, of the Aggregator 437 (PCN-ingress-node) 439 Ingress-egress-aggregate (IEA): 440 The collection of PCN-packets from all PCN-flows 441 that travel in one direction between a specific pair 442 of PCN-boundary-nodes. An ingress-egress-aggregate 443 is identified by the combination of (1) PCN-BA 444 (i.e., combination of the DSCP and ECN fields),(2) 445 IP addresses of the specific pair of 446 PCN-boundary-nodes used by the 447 ingress-egress-aggregate. In this document one RSVP 448 generic aggregated reservation is mapped to only one 449 ingress-egress-aggregate, while one 450 ingress-egress-aggregate is mapped to either one 451 or to more than one RSVP generic aggregated 452 reservations. 454 PCN-admission-state: 455 The state ("admit" or "block") derived by the 456 Decision Point for a given ingress-egress-aggregate 457 based on statistics about PCN-packet marking. The 458 Decision Point decides to admit or block new flows 459 offered to the aggregate based on the current value 460 of the PCN-admission-state. 462 Congestion level estimate (CLE): 463 The ratio of PCN-marked to total PCN-traffic 464 (measured in octets) received for a given ingress- 465 egress-aggregate during a given measurement period. 466 The CLE is used to derive the PCN-admission-state 467 and is also used by the report suppression procedure 468 if report suppression is activated. 470 t-meas: 471 A configurable time interval that defines the 472 measurement period over which the PCN-egress-node 473 collects statistics relating to PCN-traffic marking. 475 t-fail: 476 An interval after which the Decision Point (i.e., 477 PCN-ingress-node) concludes that communication from a 478 given PCN-egress-node has failed if it has received 479 no reports from the PCN-egress-node during that 480 interval. 482 t-recvFail: 483 A timer per ingress-egress-aggregate that the 484 Decision point (i.e., PCN-ingress-node) sets every 485 time it receives an RSVP Aggregated RESV message for 486 that ingress-egress-aggregate. When its value 487 reaches t-fail it is assumed that the PCN-ingress- 488 node has lost contact with the PCN-egress-node. 489 Therefore the PCN-ingress-node blocks admission of 490 new PCN-flows into that aggregate and raises a 491 management alarm. 493 1.4. Organization of This Document 495 This document is organized as follows. Section 2 gives an overview of 496 RSVP extensions and operations. The elements of the used procedures 497 are specified in Section 3. Section 4 describes the protocol 498 elements. The security considerations are given in section 5 and the 499 IANA considerations are provided in Section 6. 501 2. Overview of RSVP extensions and Operations 503 2.1 Overview of RSVP Aggregation Procedures in PCN domains 505 The PCN-boundary-nodes, see Figure 1, can support RSVP SESSIONS for 506 generic aggregated reservations [RFC4860], which are depending on 507 ingress-egress-aggregates. In particular, one RSVP generic aggregated 508 reservation matches to only one ingress-egress-aggregate. 509 However, one ingress-egress-aggregate matches to either 510 one or to more than one RSVP generic aggregated reservations. 511 In addition, to comply with this specification it is considered that 512 the PCN-boundary nodes are able to distinguish by usng the addresses 513 that the RSVP messages are addressed to, and process (1) RSVP 514 SESSIONS for generic aggregated sessions and their messages according 515 to [RFC4860], (2) e2e RSVP sessions and messages according to 516 [RFC2205]. Furthermore, it is considered that by configuration the 517 PCN-interior-nodes are not able to distinguish neither RSVP generic 518 aggregated sessions and their associated messages [RFC4860], nor e2e 519 RSVP sessions and their associated messages [RFC2205]. 521 -------------------------- 522 / PCN-domain \ 523 |----| | | |----| 524 H--| R |\ |-----| |------| /| R |-->H 525 H--| |\\| | |---| |---| | |//| |-->H 526 |----| \| | | I | | I | | |/ |----| 527 | Agg |======================>| Deag | 528 /| | | | | | | |\ 529 H--------//| | |---| |---| | |\\-------->H 530 H--------/ |-----| |------| \-------->H 531 | | 532 \ / 533 -------------------------- 535 H = Host requesting end-to-end RSVP reservations 536 R = RSVP router 537 Agg = Aggregator (PCN-ingress-node) 538 Deag = Deaggregator (PCN-egress-node) 539 I = Interior Router (PCN-interior-node) 541 --> = E2E RSVP reservation 542 ==> = Aggregate RSVP reservation 544 Figure 1 : Aggregation of E2E Reservations 545 over Generic Aggregate RSVP Reservations 546 in PCN domains, based on [RFC4860] 548 Moreover, each Aggregator and Deaggregator (i.e., PCN-boundary-nodes) 549 MUST support policies to initiate and maintain for each pair of 550 PCN-boundary-nodes of the same PCN-domain (1) one ingress-egress- 551 aggregate and (2) either one or more RSVP generic aggregated 552 reservations. Note that one RSVP generic aggregated reservation 553 matches to only one ingress-egress-aggregate, while one ingress- 554 egress-aggregate matches to either one or to more than one RSVP 555 generic aggregated reservations. This can be accomplished by using 556 for the different RSVP generic aggregated reservations the same 557 combinations of ingress and egress identifiers, but with a different 558 PHB-ID value (see [RFC4860]). The procedures for aggregation of E2E 559 reservations over generic aggregate RSVP reservations are the same as 560 the procedures specified in Section 4 of [RFC4860]. 562 Depending on a policy the Aggregator MUST be able to decide whether 563 an e2e microflow (i.e., PCN-flow) can be mapped into (1) one RSVP 564 generic aggregated reservation and (2) one ingress-egress-aggregate 565 maintained by the Aggregator (i.e., PCN-ingress-node). Note that each 566 RSVP generic aggregated reservation is identified by using the RSVP 567 SESSION object [RFC4860]. The RSVP SESSION object for generic 568 aggregate reservations is based on the RSVP SESSION object specified 569 in [RFC4860] augmented with the following information: 571 o) the IPv4 DestAddress, IPv6 DestAddress MUST be set to the IPv4 572 or IPv6 destination addresses, respectively, of the Deaggregator 573 (PCN-egress-node), see [RFC4860]. Note that the PCN-domain is 574 considered as being only one RSVP hop (for Generic aggregated 575 RSVP or e2e RSVP). This means that the next RSVP hop for the 576 Aggregator in the downstream direction is the Deaggregator and 577 the next RSVP hop for the Deaggregator in the upstream direction 578 is the Aggregator. Furthermore, it is considered that for the 579 determination of the Deaggregator, the same methods can be used 580 as the ones described in Section 4 of [RFC4860]. 582 o) PHB-ID (Per Hop Behavior Identification Code) SHOULD be set equal 583 to PCN-compatible Diffserv codepoint(s). 585 o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination 586 addresses, of the Aggregator (PCN-ingress-node), see [RFC4860]. 588 2.2 PCN Marking and encoding and transport of pre-congestion 589 information 591 The method of PCN marking within the PCN domain is based on 592 [RFC5670]. In addition, the method of encoding and transport of pre- 593 congestion information is based [RFC6660]. The PHB-ID (Per Hop 594 Behavior Identification Code) used SHOULD be set equal 595 to PCN-compatible Diffserv codepoint(s). 597 2.3. Traffic Classification Within The Aggregation Region 599 The PCN-ingress marks a PCN-BA useing PCN-marking (i.e., combination 600 of the DSCP and ECN fields), which interior nodes use to 601 classify PCN-traffic. The PCN-traffic (e.g., e2e microflows) 602 belonging to an ingress-egress-aggregate can be classified only at 603 the PCN-boundary-nodes using the combination of (1) PCN-BA (i.e., 604 combination of the DSCP and ECN fields), (2) IP addresses of the 605 specific pair of PCN-boundary-nodes used by a ingress-egress- 606 aggregate. The method of classification and traffic conditioning of 607 PCN-traffic and non-PCN traffic and PHB configuration is described in 608 [RFC6661] and [RFC6662]. Moreover, the PCN-traffic (e.g., e2e 609 microflows) belonging to a RSVP generic aggregated reservation can be 610 classified only at the PCN-boundary-nodes (i.e., Aggregator and 611 Deaggregator) by using the RSVP SESSION object for RSVP generic 612 aggregated reservations, see Section 2.1 of [RFC4860]. It is 613 considered that tunnels need to be used between Aggregators and 614 Deaggregators, using the same procedures as specified in Section 4 of 615 [RFC4860]. 617 2.4. Deaggregator (PCN-egress-node) Determination 619 To comply with this specification it is considered that to determine 620 the Deaggregator, the same methods can be used as the ones described 621 in Section 4 of [RFC4860]. 623 2.5. Mapping E2E Reservations Onto Aggregate Reservations 625 To comply with this specification it is considered that for the 626 mapping of e2e reservations onto aggregate reservations, the same 627 methods can be used as the ones described in Section 4 of [RFC4860], 628 augmented by the following rules: 630 o) PCN-ingress-node MUST use one or more policies to determine 631 whether an e2e RSVP reservation session associated with an e2e 632 Path message that arrives at the external interface of the PCN- 633 ingress-node can be mapped onto an existing RSVP generic 634 aggregation reservation state. 636 2.6. Size of Aggregate Reservations 638 To comply with this specification it is considered that for the 639 determination of the size of the RSVP generic aggregate reservations, 640 the same methods can be used as the ones described in [RFC4860] and 641 Section 1.4.4. of [RFC3175]. 643 2.7. E2E Path ADSPEC update 645 To comply with this specification it is considered that for the 646 update of the e2e Path ADSPEC, the same methods can be used as the 647 ones described in [RFC4860]. 649 2.8. Intra-domain Routes 651 The PCN-interior-nodes are neither maintaining e2e RSVP nor RSVP 652 generic aggregation states and reservations. Therefore, intra-domain 653 route changes will not affect intra-domain reservations since such 654 reservations are not maintained by the PCN-interior-nodes. 655 Furthermore, it is considered that by configuration, the PCN- 656 interior-nodes are not able to distinguish neither RSVP generic 657 aggregated sessions and their associated messages [RFC4860], nor e2e 658 RSVP sessions and their associated messages [RFC2205]. 660 2.9. Inter-domain Routes 662 The PCN-charter scope precludes inter-domain considerations. However, 663 for solving inter-domain routes changes associated with the operation 664 of the RSVP messages, the same methods SHOULD be used as the ones 665 described in [RFC4860] and in Section 1.4.7 of 666 [RFC3175]. 668 2.10. Reservations for Multicast Sessions 670 PCN does not consider reservations for multicast sessions. 672 2.11. Multi-level Aggregation 674 PCN does not consider multi-level aggregations within the PCN domain. 675 Therefore, the PCN-interior-nodes are not supporting multi-level 676 aggregation procedures. However, the Aggregator and Deaggregator 677 SHOULD support the multi-level aggregation procedures specified in 678 [RFC4860] and in Section 1.4.9 of [RFC3175]. 680 2.12. Reliability Issues 682 To comply with this specification it is considered that for solving 683 possible reliability issues, the same methods can be used as the ones 684 described in Section 4 of [RFC4860]. 686 2.13. Message Integrity and Node Authentication 688 To comply with this specification it is considered that for message 689 integrity and node authentication, the same methods can be used as 690 the ones described in Section 4 of [RFC4860] and [RFC5559]. 692 3. Elements of Procedure 694 This section describes the procedures used to implement the 695 aggregated RSVP procedure over PCN. It is considered that the 696 procedures for aggregation of e2e reservations over generic aggregate 697 RSVP reservations are the same as the procedures specified in Section 698 4 of [RFC4860]. 700 3.1. Receipt of E2E Path Message By PCN-ingress-node (aggregating 701 router) 703 When the e2e RSVP message arrives at the exterior interface of the 704 Aggregator, i.e., PCN-ingress-node, then standard RSVP generic 705 aggregation [RFC4860] procedures are used, augmented with the 706 following rules: 708 o) The e2e RSVP reservation session associated with an e2e Path 709 message that arrives at the external interface of the PCN- 710 ingress-node is mapped/matched onto an existing RSVP generic 711 aggregation reservation state. 713 o) If the timer t-recvFail does NOT expire for a given PCN-egress- 714 node, then: 716 o) If (1) the PCN-admission state for the ingress-egress- 717 aggregate associated with the received e2e Path and (2) the 718 state for the selected RSVP generic aggregated reservation, 719 see [RFC4860], are "admit", the Decision Point (i.e., PCN- 720 ingress-node) SHOULD allow the new flow to be admitted to 721 that RSVP generic aggregated reservation, see [RFC6661] and 722 [RFC6662]. The e2e Path message is then forwarded towards 723 destination. 725 o) If for the same ingress-egress-aggregate and the same RSVP 726 generic aggregated reservation (1) the PCN-admission- 727 state and/or (2) the state for the RSVP generic aggregated 728 reservation are/is "block", the flow SHOULD NOT be 729 admitted by the Aggregator and an e2e PathErr message SHOULD 730 be generated, using standard e2e RSVP procedures 731 [RFC4495]. This e2e PathErr message is sent to the 732 originating sender of the e2e Path message, using standard 733 e2e RSVP procedures [RFC2205], [RFC4495]. A new error code 734 "PCN-domain rejects e2e reservation" MUST be augmented to 735 the RSVP error codes to inform the sender that a PCN domains 736 rejects the e2e reservation request. 738 o) If the timer t-recvFail expires for a given PCN-egress-node, the 739 Decision Point (i.e., PCN-ingress-node) SHOULD NOT 740 allow the e2e microflow (i.e., PCN-flow) to be admitted to that 741 RSVP generic aggregated reservation (which is matched to one 742 ingress-egress-aggregate), see [RFC6661], [RFC6662]. The 743 admission or rejection procedure of a PCN-flow into the PCN- 744 domain is defined in detail in: [RFC6661] and [RFC6662]. 745 If the Aggregator is not able to admit the e2e microflow it 746 SHOULD then generate an e2e PathErr message using standard e2e 747 RSVP procedures [RFC4495]. This e2e PathErr message is sent to 748 the originating sender of the e2e Path message. The e2e RSVP 749 error code "01: Admission Control failure" and the "Sub-code = 750 2: Requested bandwidth unavailable " specified in Appendix B of 751 [RFC2205] SHOULD be used for this purpose. 753 The way of how the PCN-admission-state is maintained is specified in 754 [RFC6661] and [RFC6662]. The way of how the RSVP generic aggregated 755 reservation state is maintained is specified in [RFC4860]. 757 3.2. Handling Of E2E Path Message By Interior Routers 759 The e2e Path messages traverse zero or more PCN-interior-nodes. 761 The PCN-interior-nodes receive the e2e Path message on an interior 762 interface and forward it on another interior interface. It is 763 considered that by configuration the PCN-interior-nodes are not able 764 to distinguish neither e2e RSVP sessions and their associated 765 messages [RFC2205]. Therefore, the e2e Path messages are simply 766 forwarded as normal IP datagrams. 768 3.3. Receipt of E2E Path Message By PCN-egress-node (deaggregating 769 router) 771 When receiving the e2e Path message the PCN-egress-node 772 (Deaggregator) performs main regular [RFC4860] procedures, augmented 773 with the following rules, see also [draft-lefaucheur-rsvp-ecn-01]: 775 o) The PCN-egress-node MUST NOT perform the RSVP-TTL vs IP TTL- 776 check and MUST NOT update the ADspec Break bit. This is because 777 the whole PCN-domain is effectively handled by e2e RSVP as a 778 virtual link on which integrated service is indeed supported 779 (and admission control performed) so that the Break bit MUST 780 NOT be set. 782 The PCN-egress-nodes forwards the e2e Path message towards the 783 receiver. 785 3.4. Initiation of new Aggregate Path Message By PCN-ingress-node 786 (Aggregating Router) 788 To comply with this specification it is considered that for the 789 initiation of the new RSVP aggregated Path message by the PCN- 790 ingress-node (Aggregator), the same methods can be used as the ones 791 described in [RFC4860]. 793 3.5. Handling Of new Aggregate Path Message By Interior Routers 795 The Aggregate Path messages traverse zero or more PCN-interior-nodes. 796 The PCN-interior-nodes receive the e2e Path message on an interior 797 interface and forward it on another interior interface. 798 It is considered that by configuration, the PCN-interior-nodes are 799 not able to distinguish neither RSVP generic aggregated sessions and 800 their associated messages [RFC4860]. Therefore, the Aggregated Path 801 messages are simply forwarded as normal IP datagrams. 803 3.6. Handling of E2E Resv Message by Deaggregating Router 805 When the e2e Resv message arrives at the exterior interface of the 806 Deaggregator, i.e., PCN-egress-node, then standard RSVP 807 aggregation [RFC4860] procedures are used. 809 3.7. Handling Of E2E Resv Message By Interior Routers 811 The e2e Resv messages traverse zero or more PCN-interior-nodes. The 812 PCN-interior-nodes receive the e2e Resv message on an interior 813 interface and forward it on another interior interface. It is 814 considered that by configuration the PCN-interior-nodes are not able 815 to distinguish neither e2e RSVP sessions and their associated 816 messages [RFC2205]. Therefore, the e2e Resv messages are simply 817 forwarded as normal IP datagrams. 819 3.8. Initiation of New Aggregate Resv Message By Deaggregating Router 821 To comply with this specification it is considered that for the 822 initiation of the new RSVP aggregated Resv message by the PCN- 823 ingress-node (Aggregator), the same methods can be used as the ones 824 described in Section 4 of [RFC4860] augmented with the following 825 rules: 827 o) At the end of each t-meas measurement interval, or less 828 frequently if "optional report suppression" is activated, see 829 [RFC6661], and [RFC6662], the PCN-egress-node MUST include the 830 new PCN object that will be sent to the associated Decision 831 Point (i.e., PCN-ingress-node). The PCN-egress-node reports the 832 data it measures for a particular ingress-egress-aggregate in a 833 PCN object, as specified in Section 4 of this document (see 834 [RFC6661], and [RFC6662]). The address of the PCN-ingress- 835 node, i.e., Aggregator, is the one specified in the same 836 ingress-egress-aggregate. It is considered that the ingress- 837 egress-aggregate state stores both IP addresses of the PCN- 838 ingress-node, i.e., Aggregator, and of the IP-egress-node, i.e., 839 Deaggregator. 841 3.9. Handling of Aggregate Resv Message by Interior Routers 843 The Aggregated Resv messages traverse zero or more PCN-interior- 844 nodes. The PCN-interior-nodes receive the Aggregated Resv message on 845 an interior interface and forward it on another interior interface. 846 It is considered that by configuration, the PCN-interior-nodes are 847 not able to distinguish neither RSVP generic aggregated sessions and 848 their associated messages [RFC4860]. Therefore, the Aggregated Resv 849 messages are simply forwarded as normal IP datagrams. 851 3.10. Handling of E2E Resv Message by Aggregating Router 853 When the e2e Resv message arrives at the interior interface of the 854 Aggregating router, i.e., PCN-ingress-node, then standard RSVP 855 aggregation [RFC4860] procedures are used. 857 3.11. Handling of Aggregated Resv Message by Aggregating Router 859 When the Aggregated Resv message arrives at the interior interface of 860 the Aggregating router, i.e., PCN-ingress-node, then standard RSVP 861 aggregation [RFC4860] procedures are used, augmented with the 862 following rules: 864 o) If the Decision Point is not collocated with the PCN-ingress- 865 node, then other procedures need to be specified of handling the 866 Aggregated Resv Message by the Aggregating router, i.e., PCN- 867 ingress-node. These procedures are out of the scope of this 868 document. 870 o) If the Decision point is collocated with the PCN-ingress-node, 871 then the PCN-ingress-node (i.e. Aggregator) SHOULD use the 872 information carried by the PCN objects as specified in 873 [RFC6661], [RFC6662]. When the Aggregator (i.e., PCN-ingress- 874 node) needs to terminate an amount of traffic associated with 875 one ingress-egress-aggregate (see bullet 2 in Section 3.3.2 of 876 [RFC6661] and [RFC6662]), then several procedures of terminating 877 e2e microflows can be deployed. The default procedure of 878 terminating e2e microflows (i.e., PCN-flows) is as follows, see 879 e.g., [RFC6661]. 881 For the same ingress-egress-aggregate, select a number of e2e 882 microflows to be terminated in order to decrease the total 883 incoming amount of bandwidth associated with one ingress-egress- 884 aggregate by the amount of traffic to be terminated, see above. 885 In this situation the same mechanisms for terminating an e2e 886 microflow can be followed as specified in [RFC2205]. However, 887 based on a local policy, the Aggregator could use other ways of 888 selecting which microflows should be terminated. 889 For example, for the same ingress-egress-aggregate, select a 890 number of e2e microflows to be terminated or to reduce their 891 reserved bandwidth in order to decrease the total incoming 892 amount of bandwidth associated with one ingress-egress-aggregate 893 by the amount of traffic to be terminated. In this situation the 894 same mechanisms for terminating an e2e microflow or reducing 895 bandwidth associated with an e2e microflow can be followed as 896 specified in [RFC4495]. 898 3.12. Removal of E2E Reservation 900 To comply with this specification it is considered that for the 901 removal of e2e reservations, the same methods can be used as the ones 902 described in Section 4 of [RFC4860] and [RFC4495], augmented by the 903 methods described in Section 3.11. 905 3.13. Removal of Aggregate Reservation 907 To comply with this specification it is considered that for the 908 removal of RSVP generic aggregated reservations, the same methods can 909 be used as the ones described in Section 4 of [RFC4860] and Section 910 2.10 of [RFC3175]. In particular, should an aggregate reservation go 911 away (presumably due to a configuration change, route change, or 912 policy event), the e2e reservations it supports are no longer active. 913 They must be treated accordingly. 915 3.14. Handling of Data On Reserved E2E Flow by Aggregating Router 917 The handling of data on the reserved e2e Flow by Aggregating Router 918 is using the procedures described in [RFC4860] augmented with: 920 o) Regarding, PCN marking and traffic classification the procedures 921 defined in Section 2.2 and 2.4 of this document are used. 923 3.15. Procedures for Multicast Sessions 925 In this document no multicast sessions are considered. 927 4. Protocol Elements 929 The protocol elements in this document are using the protocol 930 elements defined in Section 4 [RFC4860] and Section 3 of [RFC3175] 931 augmented with the following rules: 933 o) A PCN-egress-node (i.e., Deaggregator) SHOULD send periodically 934 and at the end of each t-meas measurement interval, or less 935 frequently if "optional report suppression" is activated, an 936 (refresh) aggregated RSVP message to the PCN-ingress-node (i.e. 937 aggregator), see [RFC6661] and [RFC6662]. 939 o) the DSCP value included in the SESSION object, SHOULD be set equal 940 to a PCN-compatible Diffserv codepoint. 942 o) An aggregated Resv message MUST carry one or more C-type PCN 943 objects, see Section 4.1, to report the data measured by an 944 PCN-egress-node (i.e., Deaggregator). 946 o) As described in [RFC6661], [RFC6663], PCN reports 947 from the PCN-egress-node (Deaggregator) to the decision point may 948 contain flow identifiers for individual flows within an 949 ingress-egress-aggregate that have recently experienced 950 excess-marking. Hence, the PCN report messages used by the PCN CL 951 edge behavior MUST be capable of carrying sequences of octet 952 strings constituting such identifiers. When the PCN CL edge 953 behavior is used, the individual flow identifiers need to be 954 included in specific PCN objects, see Section 4.1 955 (C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs, 956 = RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs) 958 4.1 PCN object 960 The PCN object reports data measured by a PCN-egress-node and 961 carried by the generic aggregated RESV messages specified in 962 [RFC4860]. PCN objects are defined for different PCN edge behavior 963 drafts. This document defines six types of PCN objects: 965 o) Single Marking (SM) PCN object, when IPv4 addresses are used: 966 Class = PCN 967 C-Type = RSVP-AGGREGATE-IPv4-PCN-SM 969 +-------------+-------------+-------------+-------------+ 970 | IPv4 PCN-ingress-node Address (4 bytes) | 971 +-------------+-------------+-------------+-------------+ 972 | IPv4 PCN-egress-node Address (4 bytes) | 973 +-------------+-------------+-------------+-------------+ 974 | rate of not marked PCN-traffic (NM-rate) | 975 +-------------+-------------+-------------+-------------+ 976 | rate of PCN-marked PCN-traffic (PM-rate) | 977 +-------------+-------------+-------------+-------------+ 979 o) Single Marking (SM) PCN object, when IPv6 addresses are used: 980 Class = PCN 981 C-Type = RSVP-AGGREGATE-IPv6-PCN-SM 983 +-------------+-------------+-------------+-------------+ 984 | | 985 + + 986 | | 987 + IPv6 PCN-ingress-node Address (16 bytes) + 988 | | 989 + + 990 | | 991 +-------------+-------------+-------------+-------------+ 992 | | 993 + + 994 | | 995 + IPv6 PCN-egress-node Address (16 bytes) + 996 | | 997 + + 998 | | 999 +-------------+-------------+-------------+-------------+ 1000 | rate of not marked PCN-traffic (NM-rate) | 1001 +-------------+-------------+-------------+-------------+ 1002 | rate of PCN-marked PCN-traffic (PM-rate) | 1003 +-------------+-------------+-------------+-------------+ 1005 o) Controlled (CL) PCN object, IPv4 addresses are used: 1006 Class = PCN 1007 C-Type = RSVP-AGGREGATE-IPv4-PCN-CL 1009 +-------------+-------------+-------------+-------------+ 1010 | IPv4 PCN-ingress-node Address (4 bytes) | 1011 +-------------+-------------+-------------+-------------+ 1012 | IPv4 PCN-egress-node Address (4 bytes) | 1013 +-------------+-------------+-------------+-------------+ 1014 | rate of not marked PCN-traffic (NM-rate) | 1015 +-------------+-------------+-------------+-------------+ 1016 | rate of threshold-marked PCN-traffic (ThM-rate) | 1017 +-------------+-------------+-------------+-------------+ 1018 | rate of excess-traffic-marked PCN-traffic (ETM-rate) | 1019 +-------------+-------------+-------------+-------------+ 1021 o) Controlled (CL) PCN object, IPv6 addresses are used: 1022 Class = PCN 1023 C-Type = RSVP-AGGREGATE-IPv6-PCN-CL 1025 +-------------+-------------+-------------+-------------+ 1026 | | 1027 + + 1028 | | 1029 + IPv6 PCN-ingress-node Address (16 bytes) + 1030 | | 1031 + + 1032 | | 1033 +-------------+-------------+-------------+-------------+ 1034 | | 1035 + + 1036 | | 1037 + IPv6 PCN-egress-node Address (16 bytes) + 1038 | | 1039 + + 1040 | | 1041 +-------------+-------------+-------------+-------------+ 1042 | rate of not marked PCN-traffic (NM-rate) | 1043 +-------------+-------------+-------------+-------------+ 1044 | rate of threshold-marked PCN-traffic (ThM-rate) | 1045 +-------------+-------------+-------------+-------------+ 1046 | rate of excess-traffic-marked PCN-traffic (ETM-rate) | 1047 +-------------+-------------+-------------+-------------+ 1049 The fields carried by the PCN object are specified in 1050 [RFC6663], [RFC6661] and [RFC6662]: 1052 o the IPv4 or IPv6 address of the PCN-ingress-node and the IPv4 1053 or IPv6 address of the PCN-egress-node; together they specify the 1054 ingress-egress-aggregate to which the report refers. According to 1055 [RFC6663] the report should carry the identifier of the PCN- 1056 ingress-node and the identifier of the PCN-egress-node (typically 1057 their IP addresses); 1059 o rate of not-marked PCN-traffic (NM-rate) in octets/second; its 1060 format is a 32-bit IEEE floating point number; 1062 o rate of PCN-marked traffic (PM-rate) in octets/second; its format 1063 is a 32-bit IEEE floating point number; 1065 o rate of threshold-marked PCN traffic (ThM-rate) in 1066 octets/second; its format is a 32-bit IEEE floating point number; 1068 o rate of excess-traffic-marked traffic (ETM-rate) in 1069 octets/second; its format is a 32-bit IEEE floating point number; 1071 o) Controlled (CL) PCN CL Flow IDs object, IPv4 addresses are used: 1072 Class = PCN 1073 C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs 1075 0 1 2 3 1076 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1077 +-+-+-+-+-+-+-+-+ 1078 | Length | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Source Address | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Destination Address | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Source Port | Destination Port | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | Protocol | Reserved | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 // // 1089 + + 1090 | Source Address | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Destination Address | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Source Port | Destination Port | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | Protocol | Reserved | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 o) Length (1 byte): the length of the 1100 RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs object in units of 16 bytes. 1101 This field is used to specify the number of IPv4 flow IDs 1102 carried by this object. Each flow ID is represented by the 1103 combination of each subsequent 5 tuple: 1104 Source address, Destination address, Source Port, 1105 Destination Port and Protocol number. 1106 If Length is 0 then the RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs is 1107 empty. 1109 o) Source address (4 bytes): The IPv4 source address. 1111 o) Destination address (4 bytes): The IPv4 destination address. 1113 o) Protocol (1 byte): The IP protocol number. It refers to the 1114 true upper layer protocol carried by the packets. 1116 o) Source Port (2 bytes): contains the source port number. 1118 o) Destination Port (2 bytes): contains the destination port 1119 number. 1121 o) Controlled (CL) PCN CL Flow IDs object, IPv6 addresses are used: 1122 Class = PCN 1123 C-Type = RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs 1125 0 1 2 3 1126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1127 +-+-+-+-+-+-+-+-+ 1128 | Length | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | | 1131 | Source Address | 1132 | | 1133 | | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | | 1136 | Destination Address | 1137 | | 1138 | | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Source Port | Destination Port | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Protocol | Reserved | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 // // 1145 + + 1146 | | 1147 | Source Address | 1148 | | 1149 | | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | | 1152 | Destination Address | 1153 | | 1154 | | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Source Port | Destination Port | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | Protocol | Reserved | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 o) Length (1 byte): the length of the 1162 RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs object in units of 40 bytes. 1163 This field is used to specify the number of flow IDs carried by 1164 this object. Each flow ID is represented by the combination of 1165 each subsequent 5 tuple fields: 1166 Source address, Destination address, Source Port, 1167 Destination Port and Protocol number. 1168 If Length is 0 then the RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs object 1169 is empty. 1171 o) Source address (16 bytes): The IPv6 source address. 1173 o) Destination address (16 bytes): The IPv6 destination address. 1175 o) Protocol (1 byte): The IP protocol number. It refers to the 1176 true upper layer protocol carried by the packets. 1178 o) Source Port (2 bytes): contains the source port number. 1180 o) Destination Port (2 bytes): contains the destination port 1181 number. 1183 5. Security Considerations 1185 The same security considerations specified in [RFC2205], [RFC4230], 1186 [RFC4860], [RFC5559] and [RFC6411]. 1188 6. IANA Considerations 1190 This document makes the following requests to the IANA: 1191 o allocate a new Object Class (PCN Object), see Section 4.1. 1193 o allocate a "PCN-domain rejects e2e reservation" Error Code that 1194 may appear only in e2e PathErr messages, see Section 3.1. 1196 7. Acknowledgments 1198 We would like to thank the authors of [draft-lefaucheur-rsvp-ecn- 1199 01.txt], since some ideas used in this document are based on the work 1200 initiated in [draft-lefaucheur-rsvp-ecn-01.txt]. Moreover, we would 1201 like to thank Tom Taylor, Philip Eardley, Michael Menth, 1202 Toby Moncaster, Francois Le Faucheur and James Polk for the provided 1203 comments. 1205 8. Normative References 1207 [RFC6661] T. Taylor, A, Charny, F. Huang, 1208 G. Karagiannis, M. Menth, "PCN Boundary Node Behaviour for the 1209 Controlled Load (CL) Mode of Operation", July 1210 2012. 1212 [RFC6662] A. Charny, J. Zhang, 1213 G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node Behaviour 1214 for the Single Marking (SM) Mode of Operation", 1215 July 2012. 1217 [RFC6663] G. Karagiannis, T. Taylor, 1218 K. Chan, M. Menth, P. Eardley, " Requirements for Signaling of (Pre-) 1219 Congestion Information in a DiffServ Domain", 1220 July 2012. 1222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1223 Requirement Levels", BCP 14, RFC 2119, March 1997. 1225 [RFC2205] Braden, R., ed., et al., "Resource ReSerVation Protocol 1226 (RSVP)- Functional Specification", RFC 2205, September 1997. 1228 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le 1229 Faucheur, "Per Hop Behavior Identification Codes", 1230 RFC 3140, June 2001. 1232 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1233 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 1234 September 2001. 1236 [RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation 1237 Protocol (RSVP) Extension for the Reduction of 1238 Bandwidth of a Reservation Flow", RFC 4495, May 2006. 1240 [RFC4860] F. Le Faucheur, B. Davie, P. Bose, C. Christou, M. 1241 Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) 1242 Reservations", RFC4860, May 2007. 1244 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", 1245 RFC 5670, November 2009. 1247 [RFC6660] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 1248 Encoding and Transport of Pre-Congestion Information", RFC 6660, 1249 July 2012. 1251 9. Informative References 1253 [draft-lefaucheur-rsvp-ecn-01.txt] Le Faucheur, F., Charny, A., 1254 Briscoe, B., Eardley, P., Chan, K., and J. Babiarz, "RSVP Extensions 1255 for Admission Control over Diffserv using Pre-congestion 1256 Notification (PCN) (Work in progress)", June 2006. 1258 [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated 1259 Services in the Internet Architecture: an Overview", RFC 1633, June 1260 1994. 1262 [RFC2211] J. Wroclawski, Specification of the Controlled-Load Network 1263 Element Service, September 1997 1265 [RFC2212] S. Shenker et al., Specification of Guaranteed Quality of 1266 Service, September 1997 1268 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1269 "Definition of the Differentiated Services Field (DS Field) in the 1270 IPv4 and IPv6 Headers", RFC 2474, December 1998. 1272 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and 1273 W. Weiss, "A framework for Differentiated Services", RFC 2475, 1274 December 1998. 1276 [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 1277 Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A 1278 Framework for Integrated Services Operation Over DiffServ Networks", 1279 RFC 2998, November 2000. 1281 [RFC4230] H. Tschofenig, R. Graveman, "RSVP Security Properties", 1282 RFC 4230, December 2005. 1284 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 1285 Architecture", RFC 5559, June 2009. 1287 [RFC6411] M. Behringer, F. Le Faucheur, B. Weis, "Applicability of 1288 Keying Methods for RSVP Security", RFC 6411, October 2011. 1290 [SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested 1291 Virtual Private Network", Work in Progress, February 2007. 1293 10. Authors' Address 1295 Georgios Karagiannis 1296 University of Twente 1297 P.O. Box 217 1298 7500 AE Enschede, 1299 The Netherlands 1300 EMail: g.karagiannis@utwente.nl 1302 Anurag Bhargava 1303 Cisco Systems, Inc. 1304 7100-9 Kit Creek Road 1305 PO Box 14987 1306 RESEARCH TRIANGLE PARK, NORTH CAROLINA 27709-4987 1307 USA 1308 Email: anuragb@cisco.com