idnits 2.17.1 draft-ietf-tsvwg-rsvp-pcn-06.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 (July 29, 2013) is 3923 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: January 29, 2014 Cisco Systems, Inc. 5 July 29, 2013 7 Generic Aggregation of Resource ReSerVation Protocol (RSVP) 8 for IPv4 And IPv6 Reservations over PCN domains 9 draft-ietf-tsvwg-rsvp-pcn-06 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 January 29, 2014. 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 3.16. Misconfiguration of PCN node . . . . . . . . . . . . . . . . 19 97 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . 20 98 4.1 PCN object . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 25 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 25 101 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 25 103 9. Informative References . . . . . . . . . . . . . . . . . . . . . 26 104 10. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 27 105 1. Introduction 107 1.1 Objective 109 Pre-Congestion Notification (PCN) can support the quality of service 110 (QoS) of inelastic flows within a Diffserv domain in a simple, 111 scalable, and robust fashion. Two mechanisms are used: admission 112 control and flow termination. Admission control is used to decide 113 whether to admit or block a new flow request, while flow termination 114 is used in abnormal circumstances to decide whether to terminate some 115 of the existing flows. To support these two features, the overall 116 rate of PCN-traffic is metered on every link in the domain, and PCN- 117 packets are appropriately marked when certain configured rates are 118 exceeded. These configured rates are below the rate of the link, 119 thus providing notification to boundary nodes about overloads before 120 any congestion occurs (hence "pre-congestion" notification). The 121 PCN-egress-nodes measure the rates of differently marked PCN traffic 122 in periodic intervals and report these rates to the Decision Points 123 for admission control and flow termination; the Decision Points use 124 these rates to make decisions. The Decision Points may be collocated 125 with the PCN-ingress-nodes, or their function may be implemented in a 126 centralized node. For more details see [RFC5559], [RFC6661], and 127 [RFC6662]. 129 The main objective of this document is to specify the signalling 130 protocol that can be used within a Pre-Congestion Notification (PCN) 131 domain to carry reports from a PCN-egress-node to a PCN Decision 132 point, considering that the PCN decision Point and PCN-ingress-node 133 are collocated. 134 If the PCN decision point is not collocated with the PCN-ingress-node 135 then additional signalling procedures are required that are out of 136 the scope of this document. Moreover, as mentioned above this 137 architecture conforms with PBAC when decision point is located in a 138 centralized node [RFC2753]. 140 Several signaling protocols can be used to carry reports from a PCN- 141 egress-node to a PCN-ingress-nodes. However, since both PCN-egress- 142 node and PCN-ingress-nodes are located on the data path, a signaling 143 protocol that follows the same path as the data path, like RSVP 144 (Resource Reservation Protocol), is more suited for this purpose. In 145 particular, this document specifies extensions to Generic 146 Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) 147 and Single Marking (SM) edge behaviors over a Diffserv cloud using 148 Pre-Congestion Notification. 150 1.2 Overview and Motivation 152 Two main Quality of Service (QoS) architectures have been specified 153 by the IETF. These are the Integrated Services (Intserv) [RFC1633] 154 architecture and the Differentiated Services (DiffServ) architecture 155 ([RFC2475]). 157 Intserv provides methods for the delivery of end-to-end Quality of 158 Service (QoS) to applications over heterogeneous networks. One of the 159 QoS signaling protocols used by the Intserv architecture is the 160 Resource reServation Protocol (RSVP) [RFC2205], which can be used by 161 applications to request per-flow resources from the network. These 162 RSVP requests can be admitted or rejected by the network. 163 Applications can express their quantifiable resource requirements 164 using Intserv parameters as defined in [RFC2211] and [RFC2212]. The 165 Controlled Load (CL) service [RFC2211] is a quality of service (QoS) 166 closely approximating the QoS that the same flow would receive from a 167 lightly loaded network element. The CL service is useful for 168 inelastic flows such as those used for real-time media. 170 The DiffServ architecture can support the differentiated treatment of 171 packets in very large scale environments. While Intserv and RSVP 172 classify packets per-flow, Diffserv networks classify packets into 173 one of a small number of aggregated flows or "classes", based on the 174 Diffserv codepoint (DSCP) in the packet IP header. At each Diffserv 175 router, packets are subjected to a "per-hop behavior" (PHB), which is 176 invoked by the DSCP. The primary benefit of Diffserv is its 177 scalability, since the need for per-flow state and per-flow 178 processing, is eliminated. 180 However, DiffServ does not include any mechanism for communication 181 between applications and the network. Several solutions have been 182 specified to solve this issue. One of these solutions is Intserv over 183 Diffserv [RFC2998] including resource-based admission control (RBAC), 184 policy-based admission control (PBAC), assistance in traffic 185 identification/classification, and traffic conditioning. 186 Intserv over Diffserv can operate over a statically provisioned 187 Diffserv region or RSVP aware. When it is RSVP aware, several 188 mechanisms may be used to support dynamic provisioning and topology- 189 aware admission control, including aggregate RSVP reservations, per- 190 flow RSVP, or a bandwidth broker. 191 [RFC3175] specifies aggregation of Resource ReSerVation 192 Protocol (RSVP) end-to-end reservations over aggregate RSVP 193 reservations. In [RFC3175] the RSVP aggregated reservation is 194 characterized by a RSVP SESSION object using the 3-tuple . 197 Several scenarios require the use of multiple generic aggregate 198 reservations that are established for a given PHB from a given source 199 IP address to a given destination IP address, see [SIG-NESTED], 200 [RFC4860]. For example, multiple generic aggregate reservations 201 can be applied in the situation that multiple e2e reservations using 202 different preemption priorities need to be aggregated through a PCN- 203 domain using the same PHB. By using multiple aggregate reservations 204 for the same PHB allows enforcement of the different preemption 205 priorities within the aggregation region. This allows more efficient 206 management of the Diffserv resources, and in periods of resource 207 shortage, this allows sustainment of a larger number of E2E 208 reservations with higher preemption priorities. In particular, 209 [SIG-NESTED] discusses in detail how end-to-end RSVP reservations can 210 be established in a nested VPN environment through RSVP aggregation. 212 [RFC4860] provides generic aggregate reservations by extending 213 [RFC3175] to support multiple aggregate reservations for the same 214 source IP address, destination IP address, and PHB (or set of PHBs). 215 In particular, multiple such generic aggregate reservations can be 216 established for a given PHB from a given source IP address to a given 217 destination IP address. This is achieved by adding the concept of a 218 Virtual Destination Port and of an Extended Virtual Destination Port 219 in the RSVP SESSION object. In addition to this, the RSVP SESSION 220 object for generic aggregate reservations uses the PHB Identification 221 Code (PHB-ID) defined in [RFC3140], instead of using the Diffserv 222 Code Point (DSCP) used in [RFC3175]. The PHB-ID is used to identify 223 the PHB, or set of PHBs, from which the Diffserv resources are to be 224 reserved. 226 The RSVP like signaling protocol required to carry reports from a 227 PCN-egress-node to a PCN-ingress-node needs to follow the PCN 228 signaling requirements defined in [RFC6663]. In addition to 229 that the signalling protocol functionality supported by the PCN- 230 ingress-nodes and PCN-egress-nodes needs to maintain logical 231 aggregate constructs (i.e. ingress-egress-aggregate state) and be 232 able to map e2e reservations to these aggregate constructs. Moreover, 233 no actual reservation state is needed to be maintained inside the PCN 234 domain, i.e., the PCN-interior-nodes are not maintaining any 235 reservation state. 237 This can be accomplished by two possible approaches: 239 Approach (1): 241 o) adapting the RFC 4860 aggregation procedures to fit the PCN 242 requirements with as little change as possible over the RFC 4860 243 functionality 245 o) hence performing aggregate RSVP signaling (even if it is to be 246 ignored by PCN interior nodes) 248 o) using this aggregate RSVP signaling procedures to carry PCN 249 information from PCN-egress-node to the PCN-ingress-node. 251 Approach (2): 253 o) adapting the RFC 4860 aggregation procedures to fit the PCN 254 requirements with more significant changes over RFC4860 (i.e. 255 the aspect of the procedures that have to do with maintaining 256 aggregate states and to do with mapping the e2e reservations to 257 aggregate constructs are kept, but the procedures that have to 258 do with the aggregate RSVP signaling and aggregate reservation 259 establishment/maintenance are dropped). 261 o) hence not performing aggregate RSVP signaling 263 o) piggy-backing of the PCN information inside the e2e RSVP 264 signaling. 266 Both approaches are probably viable, however, since the RFC 4860 267 operations have been thoroughly studied and implemented, it can be 268 considered that the RFC 4860 solution can better deal with the more 269 challenging situations (rerouting in the PCN domain, failure of an 270 PCN-ingress-node, failure of an PCN-egress-node, rerouting towards a 271 different edge, etc.). This is also the reason of choosing Approach 272 (1) for the specification of the signaling protocol used to carry PCN 273 information from the PCN-egress-node to the PCN-ingress-node. 275 In particular, this document specifies extensions to Generic 276 Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) 277 and Single Marking (SM) edge behaviors over a Diffserv cloud using 278 Pre-Congestion Notification. 280 This document follows the PCN signaling requirements defined in 281 [RFC6663] and specifies extensions to Generic Aggregated RSVP 282 [RFC4860] for support of PCN edge behaviors as specified in 283 [RFC6661] and [RFC6662]. Moreover, this document specifies how RSVP 284 aggregation can be used to setup and maintain: (1) Ingress Egress 285 Aggregate (IEA) states at Ingress and Egress nodes and (2) generic 286 aggregation of RSVP end-to-end RSVP reservations over PCN (Congestion 287 and Pre-Congestion Notification) domains. 289 To comply with this specification, PCN-nodes MUST be able to 290 support the functionality specified in [RFC5670], [RFC5559], 291 [RFC6660], [RFC6661], [RFC6662]. Furthermore, the PCN-boundary-nodes 292 MUST support the RSVP generic aggregated reservation procedures 293 specified in [RFC4860] which are augmented with procedures specified 294 in this document. 296 1.3. Terminology 298 This document uses terms defined in [RFC4860], [RFC3175], [RFC5559], 299 [RFC5670], [RFC6661], [RFC6662]. 301 For readability, a number of definitions from [RFC3175] as well as 302 definitions for terms used in [RFC5559], [RFC6661], and [RFC6662] are 303 provided here, where some of them are augmented with new meanings: 305 Aggregator This is the process in (or associated with) the 306 router at the ingress edge of the aggregation region 307 (with respect to the end-to-end RSVP reservation) 308 and behaving in accordance with [RFC4860]. In this 309 document, it is also the PCN-ingress-node and the 310 decision point. 312 Deaggregator This is the process in (or associated with) the 313 router at the egress edge of the aggregation region 314 (with respect to the end-to-end RSVP reservation) 315 and behaving in accordance with [RFC4860]. In this 316 document, it is also the PCN-egress-node. 318 E2E (or e2e) end to end 320 E2E Reservation This is an RSVP reservation such that: 322 (i) corresponding RSVP Path messages are initiated 323 upstream of the Aggregator and terminated 324 downstream of the Deaggregator, and 326 (ii) corresponding RSVP Resv messages are initiated 327 downstream of the Deaggregator and terminated 328 upstream of the Aggregator, and 330 (iii) this RSVP reservation is aggregated over an 331 Ingress Egress Aggregate (IEA) between the 332 Aggregator and Deaggregator. 333 An E2E RSVP reservation may be a per-flow 334 reservation, which in this document is only 335 maintained at the PCN-ingress-node and PCN-egress- 336 node. Alternatively, the E2E reservation may itself 337 be an aggregate reservation of various types (e.g., 338 Aggregate IP reservation, Aggregate IPsec 339 reservation, see [RFC4860]). As per regular RSVP 340 operations, E2E RSVP reservations are 341 unidirectional. 343 PHB-ID (Per Hop Behavior Identification Code) 344 A 16-bit field containing the Per Hop Behavior 345 Identification Code of the PHB, or of the set of 346 PHBs, from which Diffserv resources 347 are to be reserved. This field MUST be encoded as 348 specified in Section 2 of [RFC3140]. 350 VDstPort (Virtual Destination Port) 352 A 16-bit identifier used in the SESSION that 353 remains constant over the life of the generic 354 aggregate reservation. 356 Extended vDstPort (Extended Virtual Destination Port) 358 An identifier used in the SESSION that remains 359 constant over the life of the generic aggregate 360 reservation. The length of this idenitifier is 32- 361 bits when IPv4 addresses are used and 128 bits when 362 IPv6 addresses are used. A sender(or Aggregator) 363 that wishes to narrow the scope of a SESSION to the 364 sender-receiver pair (or Aggregator-Deaggregator 365 pair) SHOULD place its IPv4 or IPv6 address here as 366 a network unique identifier. A sender (or 367 Aggregator) that wishes to use a common session 368 with other senders (or Aggregators) in order to use 369 a shared reservation across senders (or 370 Aggregators) MUST set this field to all zeros. 372 In this document, the Extended vDstPort SHOULD 373 contain the IPv4 or IPv6 address of the Aggregator. 375 PCN-domain: a PCN-capable domain; a contiguous set of 376 PCN-enabled nodes that perform Diffserv scheduling 377 [RFC2474]; the complete set of PCN-nodes that in 378 principle can, through PCN-marking packets, 379 influence decisions about flow admission and 380 termination for the PCN-domain; includes 381 the PCN-egress-nodes, which measure these 382 PCN-marks, and the PCN-ingress-nodes. 384 PCN-boundary-node: a PCN-node that connects one PCN-domain to a node 385 either in another PCN-domain or in a non-PCN-domain. 387 PCN-interior-node: a node in a PCN-domain that is not a PCN- 388 boundary-node. 390 PCN-node: a PCN-boundary-node or a PCN-interior-node. 392 PCN-egress-node: a PCN-boundary-node in its role in handling 393 traffic as it leaves a PCN-domain. 395 PCN-ingress-node: a PCN-boundary-node in its role in handling 396 traffic as it enters a PCN-domain. In this 397 document the PCN-ingress-node operates also as a 398 Decision Point and aggregator. 400 PCN-traffic, 401 PCN-packets, 402 PCN-BA: a PCN-domain carries traffic of different Diffserv 403 behavior aggregates (BAs) [RFC2474]. The PCN-BA 404 uses the PCN mechanisms to carry PCN-traffic, and 405 the corresponding packets are PCN-packets. 406 The same network will carry traffic of other 407 Diffserv BAs. The PCN-BA is 408 distinguished by a combination of the Diffserv 409 codepoint (DSCP) and ECN fields. 411 Microflow: a single instance of an application-to-application 412 (from [RFC2474]) flow of packets which is identified by source 413 address, destination address, protocol id, and 414 source port, destination port (where applicable). 416 e2e microflow a microflow where its associated packets are being 417 forwarded on an E2E path. 419 PCN-flow: the unit of PCN-traffic that the PCN-boundary-node 420 admits (or terminates); the unit could be a single 421 e2e microflow (as defined in [RFC2474]) or some 422 identifiable collection of microflows. 424 RSVP generic aggregated reservation: an RSVP reservation that is 425 identified by using the RSVP SESSION object 426 for generic RSVP aggregate reservation. This RSVP 427 SESSION object is based on the RSVP SESSION object 428 specified in [RFC4860] augmented with the following 429 information: 431 o) the IPv4 DestAddress, IPv6 DestAddress SHOULD be 432 set to the IPv4 or IPv6 destination addresses, 433 respectively, of the Deaggregator (PCN-egress- 434 node) 436 o) PHB-ID (Per Hop Behavior Identification Code) 437 SHOULD be set equal to PCN-compatible Diffserv 438 codepoint(s). 440 o) Extended vDstPort SHOULD be set to the IPv4 or 441 IPv6 destination addresses, of the Aggregator 442 (PCN-ingress-node) 444 Ingress-egress-aggregate (IEA): 445 The collection of PCN-packets from all PCN-flows 446 that travel in one direction between a specific pair 447 of PCN-boundary-nodes. An ingress-egress-aggregate 448 is identified by the combination of (1) PCN-BA 449 (i.e., combination of the DSCP and ECN fields),(2) 450 IP addresses of the specific pair of 451 PCN-boundary-nodes used by the 452 ingress-egress-aggregate. In this document one RSVP 453 generic aggregated reservation is mapped to only 454 one ingress-egress-aggregate, while one 455 ingress-egress-aggregate is mapped to either 456 one or to more than one RSVP generic aggregated 457 reservations. 459 PCN-admission-state: 460 The state ("admit" or "block") derived by the 461 Decision Point for a given ingress-egress-aggregate 462 based on statistics about PCN-packet marking. The 463 Decision Point decides to admit or block new flows 464 offered to the aggregate based on the current value 465 of the PCN-admission-state. 467 Congestion level estimate (CLE): 468 The ratio of PCN-marked to total PCN-traffic 469 (measured in octets) received for a given ingress- 470 egress-aggregate during a given measurement period. 471 The CLE is used to derive the PCN-admission-state 472 and is also used by the report suppression procedure 473 if report suppression is activated. 474 t-meas: 475 A configurable time interval that defines the 476 measurement period over which the PCN-egress-node 477 collects statistics relating to PCN-traffic marking. 479 t-fail: 480 An interval after which the Decision Point (i.e., 481 PCN-ingress-node in this document) concludes that 482 communication from a given PCN-egress-node has failed 483 if it has received no reports from the 484 PCN-egress-node during that interval. 486 t-recvFail: 487 A timer per ingress-egress-aggregate that the 488 Decision point (i.e., PCN-ingress-node) sets every 489 time it receives an RSVP Aggregated RESV message for 490 that ingress-egress-aggregate. When its value 491 reaches t-fail it is assumed that the PCN-ingress- 492 node has lost contact with the PCN-egress-node. 493 Therefore the PCN-ingress-node blocks admission of 494 new PCN-flows into that aggregate and raises a 495 management alarm. 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. 513 However, one ingress-egress-aggregate matches to either 514 one or more than one RSVP generic aggregated reservations. 515 In addition, to comply with this specification it is considered that 516 the PCN-boundary nodes are able to distinguish by using the addresses 517 that the RSVP messages are addressed to, and process (1) RSVP 518 SESSIONS for generic aggregated sessions and their messages according 519 to [RFC4860], (2) e2e RSVP sessions and messages according to 520 [RFC2205]. Furthermore, it is considered that by configuration the 521 PCN-interior-nodes are not able to distinguish neither RSVP generic 522 aggregated sessions and their associated messages [RFC4860], nor e2e 523 RSVP sessions and their associated messages [RFC2205]. 525 -------------------------- 526 / PCN-domain \ 527 |----| | | |----| 528 H--| R |\ |-----| |------| /| R |-->H 529 H--| |\\| | |---| |---| | |//| |-->H 530 |----| \| | | I | | I | | |/ |----| 531 | Agg |======================>| Deag | 532 /| | | | | | | |\ 533 H--------//| | |---| |---| | |\\-------->H 534 H--------/ |-----| |------| \-------->H 535 | | 536 \ / 537 -------------------------- 539 H = Host requesting end-to-end RSVP reservations 540 R = RSVP router 541 Agg = Aggregator (PCN-ingress-node) 542 Deag = Deaggregator (PCN-egress-node) 543 I = Interior Router (PCN-interior-node) 545 --> = E2E RSVP reservation 546 ==> = Aggregate RSVP reservation 548 Figure 1 : Aggregation of E2E Reservations 549 over Generic Aggregate RSVP Reservations 550 in PCN domains, based on [RFC4860] 552 Moreover, each Aggregator and Deaggregator (i.e., PCN-boundary-nodes) 553 MUST support policies to initiate and maintain for each pair of 554 PCN-boundary-nodes of the same PCN-domain (1) one ingress-egress- 555 aggregate and (2) either one or more RSVP generic aggregated 556 reservations. Note that one RSVP generic aggregated reservation 557 matches to only one ingress-egress-aggregate, while one ingress- 558 egress-aggregate matches to either one or to more than one RSVP 559 generic aggregated reservations. This can be accomplished by using 560 for the different RSVP generic aggregated reservations the same 561 combinations of ingress and egress identifiers, but with a different 562 PHB-ID value (see [RFC4860]). The procedures for aggregation of E2E 563 reservations over generic aggregate RSVP reservations are the same as 564 the procedures specified in Section 4 of [RFC4860]. 566 Depending on a policy the Aggregator MUST be able to decide whether 567 an e2e microflow (i.e., PCN-flow) can be mapped into (1) one RSVP 568 generic aggregated reservation and (2) one ingress-egress-aggregate 569 maintained by the Aggregator (i.e., PCN-ingress-node). Note that each 570 RSVP generic aggregated reservation is identified by using the RSVP 571 SESSION object [RFC4860]. The RSVP SESSION object for generic 572 aggregate reservations is based on the RSVP SESSION object specified 573 in [RFC4860] augmented with the following information: 575 o) the IPv4 DestAddress, IPv6 DestAddress MUST be set to the IPv4 576 or IPv6 destination addresses, respectively, of the Deaggregator 577 (PCN-egress-node), see [RFC4860]. Note that the PCN-domain is 578 considered as being only one RSVP hop (for Generic aggregated 579 RSVP or e2e RSVP). This means that the next RSVP hop for the 580 Aggregator in the downstream direction is the Deaggregator and 581 the next RSVP hop for the Deaggregator in the upstream direction 582 is the Aggregator. Furthermore, it is considered that for the 583 determination of the Deaggregator, the same methods can be used 584 as the ones described in Section 4 of [RFC4860]. 586 o) PHB-ID (Per Hop Behavior Identification Code) SHOULD be set equal 587 to PCN-compatible Diffserv codepoint(s). 589 o) Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination 590 addresses, of the Aggregator (PCN-ingress-node), see [RFC4860]. 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 based on 596 [RFC5670]. In addition, the method of encoding and transport of pre- 597 congestion information is based [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 an ingress-egress-aggregate can be classified only at 607 the PCN-boundary-nodes using the combination of (1) PCN-BA (i.e., 608 combination of the DSCP and ECN fields), (2) IP addresses of the 609 specific pair of PCN-boundary-nodes used by a ingress-egress- 610 aggregate. The method of classification and traffic conditioning of 611 PCN-traffic and non-PCN traffic and PHB configuration is described in 612 [RFC6661] and [RFC6662]. Moreover, the PCN-traffic (e.g., e2e 613 microflows) belonging to a RSVP generic aggregated reservation can be 614 classified only at the PCN-boundary-nodes (i.e., Aggregator and 615 Deaggregator) by using the RSVP SESSION object for RSVP generic 616 aggregated reservations, see Section 2.1 of [RFC4860]. It is 617 considered that tunnels need to be used between Aggregators and 618 Deaggregators, using the same procedures as specified in Section 4 of 619 [RFC4860]. 621 2.4. Deaggregator (PCN-egress-node) Determination 623 To comply with this specification it is considered that to determine 624 the Deaggregator, the same methods can be used as the ones described 625 in Section 4 of [RFC4860]. 627 2.5. Mapping E2E Reservations Onto Aggregate Reservations 629 To comply with this specification it is considered that for the 630 mapping of e2e reservations onto aggregate reservations, the same 631 methods can be used as the ones described in Section 4 of [RFC4860], 632 augmented by the following rules: 634 o) PCN-ingress-node MUST use one or more policies to determine 635 whether an e2e RSVP reservation session associated with an e2e 636 Path message that arrives at the external interface of the PCN- 637 ingress-node can be mapped onto an existing RSVP generic 638 aggregation reservation state. 640 2.6. Size of Aggregate Reservations 642 To comply with this specification it is considered that for the 643 determination of the size of the RSVP generic aggregate reservations, 644 the same methods can be used as the ones described in [RFC4860] and 645 Section 1.4.4. of [RFC3175]. 647 2.7. E2E Path ADSPEC update 649 To comply with this specification it is considered that for the 650 update of the e2e Path ADSPEC, the same methods can be used as the 651 ones described in [RFC4860]. 653 2.8. Intra-domain Routes 655 The PCN-interior-nodes are neither maintaining e2e RSVP nor RSVP 656 generic aggregation states and reservations. Therefore, intra-domain 657 route changes will not affect intra-domain reservations since such 658 reservations are not maintained by the PCN-interior-nodes. 659 Furthermore, it is considered that by configuration, the PCN- 660 interior-nodes are not able to distinguish neither RSVP generic 661 aggregated sessions and their associated messages [RFC4860], nor e2e 662 RSVP sessions and their associated messages [RFC2205]. 664 2.9. Inter-domain Routes 666 The PCN-charter scope precludes inter-domain considerations. However, 667 for solving inter-domain routes changes associated with the operation 668 of the RSVP messages, the same methods SHOULD be used as the ones 669 described in [RFC4860] and in Section 1.4.7 of 670 [RFC3175]. 672 2.10. Reservations for Multicast Sessions 674 PCN does not consider reservations for multicast sessions. 676 2.11. Multi-level Aggregation 678 PCN does not consider multi-level aggregations within the PCN domain. 679 Therefore, the PCN-interior-nodes are not supporting multi-level 680 aggregation procedures. However, the Aggregator and Deaggregator 681 SHOULD support the multi-level aggregation procedures specified in 682 [RFC4860] and in Section 1.4.9 of [RFC3175]. 684 2.12. Reliability Issues 686 To comply with this specification it is considered that for solving 687 possible reliability issues, the same methods can be used as the ones 688 described in Section 4 of [RFC4860]. 690 2.13. Message Integrity and Node Authentication 692 To comply with this specification it is considered that for message 693 integrity and node authentication, the same methods can be used as 694 the ones described in Section 4 of [RFC4860] and [RFC5559]. 696 3. Elements of Procedure 698 This section describes the procedures used to implement the 699 aggregated RSVP procedure over PCN. It is considered that the 700 procedures for aggregation of e2e reservations over generic aggregate 701 RSVP reservations are same as the procedures specified in Section 702 4 of [RFC4860]. Please refer to [RFC4860] for all the below error 703 cases: 704 *) Incomplete message 705 *) Unexpected objects 707 3.1. Receipt of E2E Path Message By PCN-ingress-node (aggregating 708 router) 710 When the e2e RSVP message arrives at the exterior interface of the 711 Aggregator, i.e., PCN-ingress-node, then standard RSVP generic 712 aggregation [RFC4860] procedures are used, augmented with the 713 following rules: 715 o) The e2e RSVP reservation session associated with an e2e Path 716 message that arrives at the external interface of the PCN- 717 ingress-node is mapped/matched onto an existing RSVP generic 718 aggregation reservation state. 719 o) If the timer t-recvFail does NOT expire for a given PCN-egress- 720 node, then: 722 o) If (1) the PCN-admission state for the ingress-egress- 723 aggregate associated with the received e2e Path and (2) the 724 state for the selected RSVP generic aggregated reservation, 725 see [RFC4860], are "admit", the Decision Point (i.e., PCN- 726 ingress-node) SHOULD allow the new flow to be admitted to 727 that RSVP generic aggregated reservation, see [RFC6661] and 728 [RFC6662]. The e2e Path message is then forwarded towards 729 destination. 731 o) If for the same ingress-egress-aggregate and the same RSVP 732 generic aggregated reservation (1) the PCN-admission- 733 state and/or (2) the state for the RSVP generic aggregated 734 reservation are/is "block", the flow SHOULD NOT be 735 admitted by the Aggregator and an e2e PathErr message SHOULD 736 be generated, using standard e2e RSVP procedures 737 [RFC4495]. This e2e PathErr message is sent to the 738 originating sender of the e2e Path message, using standard 739 e2e RSVP procedures [RFC2205], [RFC4495]. This e2e PathErr 740 message is sent to the originating sender of the e2e Path 741 message. The e2e RSVP error code "01: Admission Control 742 failure" and the "Sub-code = 2: Requested bandwidth 743 unavailable " specified in Appendix B of [RFC2205] SHOULD be 744 used for this purpose. 746 o) If the timer t-recvFail expires for a given PCN-egress-node, the 747 Decision Point (i.e., PCN-ingress-node) SHOULD NOT 748 allow the e2e microflow (i.e., PCN-flow) to be admitted to that 749 RSVP generic aggregated reservation (which is matched to one 750 ingress-egress-aggregate), see [RFC6661], [RFC6662]. The 751 admission or rejection procedure of a PCN-flow into the PCN- 752 domain is defined in detail in: [RFC6661] and [RFC6662]. 753 If the Aggregator is not able to admit the e2e microflow it 754 SHOULD then generate an e2e PathErr message using standard e2e 755 RSVP procedures [RFC4495]. This e2e PathErr message is sent to 756 the originating sender of the e2e Path message. The e2e RSVP 757 error code "01: Admission Control failure" and the "Sub-code = 758 2: Requested bandwidth unavailable " specified in Appendix B of 759 [RFC2205] SHOULD be used for this purpose. 761 The way of how the PCN-admission-state is maintained is specified in 762 [RFC6661] and [RFC6662]. The way of how the RSVP generic aggregated 763 reservation state is maintained is specified in [RFC4860]. 765 3.2. Handling Of E2E Path Message By Interior Routers 767 The e2e Path messages traverse zero or more PCN-interior-nodes. 769 The PCN-interior-nodes receive the e2e Path message on an interior 770 interface and forward it on another interior interface. It is 771 considered that by configuration the PCN-interior-nodes are not able 772 to distinguish neither e2e RSVP sessions and their associated 773 messages [RFC2205]. Therefore, the e2e Path messages are simply 774 forwarded as normal IP datagrams. 776 3.3. Receipt of E2E Path Message By PCN-egress-node (deaggregating 777 router) 779 When receiving the e2e Path message the PCN-egress-node 780 (Deaggregator) performs main regular [RFC4860] procedures, augmented 781 with the following rules, see also [draft-lefaucheur-rsvp-ecn-01]: 783 o) The PCN-egress-node MUST NOT perform the RSVP-TTL vs IP TTL- 784 check and MUST NOT update the ADspec Break bit. This is because 785 the whole PCN-domain is effectively handled by e2e RSVP as a 786 virtual link on which integrated service is indeed supported 787 (and admission control performed) so that the Break bit MUST 788 NOT be set. 790 The PCN-egress-nodes forwards the e2e Path message towards the 791 receiver. 793 3.4. Initiation of new Aggregate Path Message By PCN-ingress-node 794 (Aggregating Router) 796 To comply with this specification it is considered that for the 797 initiation of the new RSVP aggregated Path message by the PCN- 798 ingress-node (Aggregator), the same methods can be used as the ones 799 described in [RFC4860]. 801 3.5. Handling Of new Aggregate Path Message By Interior Routers 803 The Aggregate Path messages traverse zero or more PCN-interior-nodes. 804 The PCN-interior-nodes receive the e2e Path message on an interior 805 interface and forward it on another interior interface. 806 It is considered that by configuration, the PCN-interior-nodes are 807 not able to distinguish neither RSVP generic aggregated sessions and 808 their associated messages [RFC4860]. Therefore, the Aggregated Path 809 messages are simply forwarded as normal IP datagrams. 811 3.6. Handling of E2E Resv Message by Deaggregating Router 813 When the e2e Resv message arrives at the exterior interface of the 814 Deaggregator, i.e., PCN-egress-node, then standard RSVP 815 aggregation [RFC4860] procedures are used. 817 3.7. Handling Of E2E Resv Message By Interior Routers 819 The e2e Resv messages traverse zero or more PCN-interior-nodes. The 820 PCN-interior-nodes receive the e2e Resv message on an interior 821 interface and forward it on another interior interface. It is 822 considered that by configuration the PCN-interior-nodes are not able 823 to distinguish neither e2e RSVP sessions and their associated 824 messages [RFC2205]. Therefore, the e2e Resv messages are simply 825 forwarded as normal IP datagrams. 827 3.8. Initiation of New Aggregate Resv Message By Deaggregating Router 829 To comply with this specification it is considered that for the 830 initiation of the new RSVP aggregated Resv message by the PCN- 831 egress-node (Deaggregator), the same methods can be used as the ones 832 described in Section 4 of [RFC4860] augmented with the following 833 rules: 835 o) At the end of each t-meas measurement interval, or less 836 frequently if "optional report suppression" is activated, see 837 [RFC6661], and [RFC6662], the PCN-egress-node MUST include the 838 new PCN object that will be sent to the associated Decision 839 Point (i.e., PCN-ingress-node). The PCN-egress-node reports the 840 data it measures for a particular ingress-egress-aggregate in a 841 PCN object, as specified in Section 4 of this document (see 842 [RFC6661], and [RFC6662]). The address of the PCN-ingress- 843 node, i.e., Aggregator, is the one specified in the same 844 ingress-egress-aggregate. It is considered that the ingress- 845 egress-aggregate state stores both IP addresses of the PCN- 846 ingress-node, i.e., Aggregator, and of the IP-egress-node, i.e., 847 Deaggregator. 849 3.9. Handling of Aggregate Resv Message by Interior Routers 851 The Aggregated Resv messages traverse zero or more PCN-interior- 852 nodes. The PCN-interior-nodes receive the Aggregated Resv message on 853 an interior interface and forward it on another interior interface. 854 It is considered that by configuration, the PCN-interior-nodes are 855 not able to distinguish neither RSVP generic aggregated sessions and 856 their associated messages [RFC4860]. Therefore, the Aggregated Resv 857 messages are simply forwarded as normal IP datagrams. 859 3.10. Handling of E2E Resv Message by Aggregating Router 861 When the e2e Resv message arrives at the interior interface of the 862 Aggregating router, i.e., PCN-ingress-node, then standard RSVP 863 aggregation [RFC4860] procedures are used. 865 3.11. Handling of Aggregated Resv Message by Aggregating Router 867 When the Aggregated Resv message arrives at the interior interface of 868 the Aggregating router, i.e., PCN-ingress-node, then standard RSVP 869 aggregation [RFC4860] procedures are used, augmented with the 870 following rules: 872 o) If the Decision Point is not collocated with the PCN-ingress- 873 node, then other procedures need to be specified of handling the 874 Aggregated Resv Message by the Aggregating router, i.e., PCN- 875 ingress-node. Even though these procedures are out of the scope 876 of this document, the PCN-ingress-node can refer to a central 877 decision point which can respond to the PCN ingress as per 878 [RFC2753] 879 o) If the Decision point is collocated with the PCN-ingress-node, 880 then the PCN-ingress-node (i.e. Aggregator) SHOULD use the 881 information carried by the PCN objects as specified in 882 [RFC6661], [RFC6662]. When the Aggregator (i.e., PCN-ingress- 883 node) needs to terminate an amount of traffic associated with 884 one ingress-egress-aggregate (see bullet 2 in Section 3.3.2 of 885 [RFC6661] and [RFC6662]), then several procedures of terminating 886 e2e microflows can be deployed. The default procedure of 887 terminating e2e microflows (i.e., PCN-flows) is as follows, see 888 e.g., [RFC6661]. 890 For the same ingress-egress-aggregate, select a number of e2e 891 microflows to be terminated in order to decrease the total 892 incoming amount of bandwidth associated with one ingress-egress- 893 aggregate by the amount of traffic to be terminated, see above. 894 In this situation the same mechanisms for terminating an e2e 895 microflow can be followed as specified in [RFC2205]. However, 896 based on a local policy, the Aggregator could use other ways of 897 selecting which microflows should be terminated. 898 For example, for the same ingress-egress-aggregate, select a 899 number of e2e microflows to be terminated or to reduce their 900 reserved bandwidth in order to decrease the total incoming 901 amount of bandwidth associated with one ingress-egress-aggregate 902 by the amount of traffic to be terminated. In this situation the 903 same mechanisms for terminating an e2e microflow or reducing 904 bandwidth associated with an e2e microflow can be followed as 905 specified in [RFC4495]. 907 3.12. Removal of E2E Reservation 909 To comply with this specification it is considered that for the 910 removal of e2e reservations, the same methods can be used as the ones 911 described in Section 4 of [RFC4860] and [RFC4495], augmented by the 912 methods described in Section 3.11. 914 3.13. Removal of Aggregate Reservation 916 To comply with this specification it is considered that for the 917 removal of RSVP generic aggregated reservations, the same methods can 918 be used as the ones described in Section 4 of [RFC4860] and Section 919 2.10 of [RFC3175]. In particular, should an aggregate reservation go 920 away (presumably due to a configuration change, route change, or 921 policy event), the e2e reservations it supports are no longer active. 922 They must be treated accordingly. 924 3.14. Handling of Data On Reserved E2E Flow by Aggregating Router 926 The handling of data on the reserved e2e Flow by Aggregating Router 927 is using the procedures described in [RFC4860] augmented with: 928 o) Regarding, PCN marking and traffic classification the procedures 929 defined in Section 2.2 and 2.4 of this document are used. 931 3.15. Procedures for Multicast Sessions 933 In this document no multicast sessions are considered. 935 3.16. Misconfiguration of PCN-node 937 In an event where a PCN-node is misconfigured within a PCN-domain, 938 the desired behavior is same as described in Section 3.9. Therefore, 939 the Aggregated Resv messages are simply forwarded as normal IP 940 datagrams. 942 4. Protocol Elements 944 The protocol elements in this document are using the protocol 945 elements defined in Section 4 [RFC4860] and Section 3 of [RFC3175] 946 augmented with the following rules: 948 o) A PCN-egress-node (i.e., Deaggregator) SHOULD send periodically 949 and at the end of each t-meas measurement interval, or less 950 frequently if "optional report suppression" is activated, an 951 (refresh) aggregated RSVP message to the PCN-ingress-node (i.e. 952 aggregator), see [RFC6661] and [RFC6662]. 954 o) the DSCP value included in the SESSION object, SHOULD be set equal 955 to a PCN-compatible Diffserv codepoint. 957 o) An aggregated Resv message MUST carry one or more C-type PCN 958 objects, see Section 4.1, to report the data measured by an 959 PCN-egress-node (i.e., Deaggregator). 961 o) As described in [RFC6661], [RFC6663], PCN reports 962 from the PCN-egress-node (Deaggregator) to the decision point may 963 contain flow identifiers for individual flows within an 964 ingress-egress-aggregate that have recently experienced 965 excess-marking. Hence, the PCN report messages used by the PCN CL 966 edge behavior MUST be capable of carrying sequences of octet 967 strings constituting such identifiers. When the PCN CL edge 968 behavior is used, the individual flow identifiers need to be 969 included in specific PCN objects, see Section 4.1 970 (C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs, 971 = RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs) 973 4.1 PCN object 975 The PCN object reports data measured by a PCN-egress-node and 976 carried by the generic aggregated RESV messages specified in 977 [RFC4860]. PCN objects are defined for different PCN edge behavior 978 drafts. This document defines six types of PCN objects: 980 o) Single Marking (SM) PCN object, when IPv4 addresses are used: 981 Class = PCN 982 C-Type = RSVP-AGGREGATE-IPv4-PCN-SM 984 +-------------+-------------+-------------+-------------+ 985 | IPv4 PCN-ingress-node Address (4 bytes) | 986 +-------------+-------------+-------------+-------------+ 987 | IPv4 PCN-egress-node Address (4 bytes) | 988 +-------------+-------------+-------------+-------------+ 989 | rate of not marked PCN-traffic (NM-rate) | 990 +-------------+-------------+-------------+-------------+ 991 | rate of PCN-marked PCN-traffic (PM-rate) | 992 +-------------+-------------+-------------+-------------| 994 o) Single Marking (SM) PCN object, when IPv6 addresses are used: 995 Class = PCN 996 C-Type = RSVP-AGGREGATE-IPv6-PCN-SM 998 +-------------+-------------+-------------+-------------+ 999 | | 1000 + + 1001 | | 1002 + IPv6 PCN-ingress-node Address (16 bytes) + 1003 | | 1004 + + 1005 | | 1006 +-------------+-------------+-------------+-------------+ 1007 | | 1008 + + 1009 | | 1010 + IPv6 PCN-egress-node Address (16 bytes) + 1011 | | 1012 + + 1013 | | 1014 +-------------+-------------+-------------+-------------+ 1015 | rate of not marked PCN-traffic (NM-rate) | 1016 +-------------+-------------+-------------+-------------+ 1017 | rate of PCN-marked PCN-traffic (PM-rate) | 1018 +-------------+-------------+-------------+-------------+ 1020 o) Controlled (CL) PCN object, IPv4 addresses are used: 1021 Class = PCN 1022 C-Type = RSVP-AGGREGATE-IPv4-PCN-CL 1024 +-------------+-------------+-------------+-------------+ 1025 | IPv4 PCN-ingress-node Address (4 bytes) | 1026 +-------------+-------------+-------------+-------------+ 1027 | IPv4 PCN-egress-node Address (4 bytes) | 1028 +-------------+-------------+-------------+-------------+ 1029 | rate of not marked PCN-traffic (NM-rate) | 1030 +-------------+-------------+-------------+-------------+ 1031 | rate of threshold-marked PCN-traffic (ThM-rate) | 1032 +-------------+-------------+-------------+-------------+ 1033 | rate of excess-traffic-marked PCN-traffic (ETM-rate) | 1034 +-------------+-------------+-------------+-------------+ 1036 o) Controlled (CL) PCN object, IPv6 addresses are used: 1037 Class = PCN 1038 C-Type = RSVP-AGGREGATE-IPv6-PCN-CL 1040 +-------------+-------------+-------------+-------------+ 1041 | | 1042 + + 1043 | | 1044 + IPv6 PCN-ingress-node Address (16 bytes) + 1045 | | 1046 + + 1047 | | 1048 +-------------+-------------+-------------+-------------+ 1049 | | 1050 + + 1051 | | 1052 + IPv6 PCN-egress-node Address (16 bytes) + 1053 | | 1054 + + 1055 | | 1056 +-------------+-------------+-------------+-------------+ 1057 | rate of not marked PCN-traffic (NM-rate) | 1058 +-------------+-------------+-------------+-------------+ 1059 | rate of threshold-marked PCN-traffic (ThM-rate) | 1060 +-------------+-------------+-------------+-------------+ 1061 | rate of excess-traffic-marked PCN-traffic (ETM-rate) | 1062 +-------------+-------------+-------------+-------------+ 1064 The fields carried by the PCN object are specified in 1065 [RFC6663], [RFC6661] and [RFC6662]: 1067 o the IPv4 or IPv6 address of the PCN-ingress-node and the IPv4 1068 or IPv6 address of the PCN-egress-node; together they specify the 1069 ingress-egress-aggregate to which the report refers. According to 1070 [RFC6663] the report should carry the identifier of the PCN- 1071 ingress-node and the identifier of the PCN-egress-node (typically 1072 their IP addresses); 1074 o rate of not-marked PCN-traffic (NM-rate) in octets/second; its 1075 format is a 32-bit IEEE floating point number; 1077 o rate of PCN-marked traffic (PM-rate) in octets/second; its format 1078 is a 32-bit IEEE floating point number; 1080 o rate of threshold-marked PCN traffic (ThM-rate) in 1081 octets/second; its format is a 32-bit IEEE floating point number; 1083 o rate of excess-traffic-marked traffic (ETM-rate) in 1084 octets/second; its format is a 32-bit IEEE floating point number; 1086 o) Controlled (CL) PCN CL Flow IDs object, IPv4 addresses are used: 1087 Class = PCN 1088 C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+ 1093 | Length | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Source Address | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Destination Address | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Source Port | Destination Port | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Protocol | Reserved | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 // // 1104 + + 1105 | Source Address | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Destination Address | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Source Port | Destination Port | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Protocol | Reserved | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 o) Length (1 byte): the length of the 1115 RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs object in units of 16 bytes. 1116 This field is used to specify the number of IPv4 flow IDs 1117 carried by this object. Each flow ID is represented by the 1118 combination of each subsequent 5 tuple: 1119 Source address, Destination address, Source Port, 1120 Destination Port and Protocol number. 1121 If Length is 0 then the RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs is 1122 empty. 1124 o) Source address (4 bytes): The IPv4 source address. 1126 o) Destination address (4 bytes): The IPv4 destination address. 1128 o) Protocol (1 byte): The IP protocol number. It refers to the 1129 true upper layer protocol carried by the packets. 1131 o) Source Port (2 bytes): contains the source port number. 1133 o) Destination Port (2 bytes): contains the destination port 1134 number. 1136 o) Controlled (CL) PCN CL Flow IDs object, IPv6 addresses are used: 1137 Class = PCN 1138 C-Type = RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs 1140 0 1 2 3 1141 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 1142 +-+-+-+-+-+-+-+-+ 1143 | Length | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | | 1146 | Source Address | 1147 | | 1148 | | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | | 1151 | Destination Address | 1152 | | 1153 | | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Source Port | Destination Port | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | Protocol | Reserved | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 // // 1160 + + 1161 | | 1162 | Source Address | 1163 | | 1164 | | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 | | 1167 | Destination Address | 1168 | | 1169 | | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | Source Port | Destination Port | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | Protocol | Reserved | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 o) Length (1 byte): the length of the 1177 RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs object in units of 40 bytes. 1178 This field is used to specify the number of flow IDs carried by 1179 this object. Each flow ID is represented by the combination of 1180 each subsequent 5 tuple fields: 1181 Source address, Destination address, Source Port, 1182 Destination Port and Protocol number. 1183 If Length is 0 then the RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs object 1184 is empty. 1186 o) Source address (16 bytes): The IPv6 source address. 1188 o) Destination address (16 bytes): The IPv6 destination address. 1190 o) Protocol (1 byte): The IP protocol number. It refers to the 1191 true upper layer protocol carried by the packets. 1193 o) Source Port (2 bytes): contains the source port number. 1195 o) Destination Port (2 bytes): contains the destination port 1196 number. 1198 5. Security Considerations 1200 The same security considerations specified in [RFC2205], [RFC4230], 1201 [RFC4860], [RFC5559] and [RFC6411]. 1203 6. IANA Considerations 1205 This document makes the following requests to the IANA: 1206 o allocate a new Object Class (PCN Object), see Section 4.1. 1208 7. Acknowledgments 1210 We would like to thank the authors of [draft-lefaucheur-rsvp-ecn- 1211 01.txt], since some ideas used in this document are based on the work 1212 initiated in [draft-lefaucheur-rsvp-ecn-01.txt]. Moreover, we would 1213 like to thank Bob Briscoe, David Black, Ken Carlberg, Tom Taylor, 1214 Philip Eardley, Michael Menth, Toby Moncaster, Francois Le Faucheur, 1215 James Polk and Lixia Zhang for the provided comments. 1217 8. Normative References 1219 [RFC6661] T. Taylor, A, Charny, F. Huang, 1220 G. Karagiannis, M. Menth, "PCN Boundary Node Behaviour for the 1221 Controlled Load (CL) Mode of Operation", July 1222 2012. 1224 [RFC6662] A. Charny, J. Zhang, 1225 G. Karagiannis, M. Menth, T. Taylor, "PCN Boundary Node Behaviour 1226 for the Single Marking (SM) Mode of Operation", 1227 July 2012. 1229 [RFC6663] G. Karagiannis, T. Taylor, 1230 K. Chan, M. Menth, P. Eardley, " Requirements for Signaling of (Pre-) 1231 Congestion Information in a DiffServ Domain", 1232 July 2012. 1234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1235 Requirement Levels", BCP 14, RFC 2119, March 1997. 1237 [RFC2205] Braden, R., ed., et al., "Resource ReSerVation Protocol 1238 (RSVP)- Functional Specification", RFC 2205, September 1997. 1240 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le 1241 Faucheur, "Per Hop Behavior Identification Codes", 1242 RFC 3140, June 2001. 1244 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1245 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 1246 September 2001. 1248 [RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation 1249 Protocol (RSVP) Extension for the Reduction of 1250 Bandwidth of a Reservation Flow", RFC 4495, May 2006. 1252 [RFC4860] F. Le Faucheur, B. Davie, P. Bose, C. Christou, M. 1253 Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) 1254 Reservations", RFC4860, May 2007. 1256 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", 1257 RFC 5670, November 2009. 1259 [RFC6660] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 1260 Encoding and Transport of Pre-Congestion Information", RFC 6660, 1261 July 2012. 1263 9. Informative References 1265 [draft-lefaucheur-rsvp-ecn-01.txt] Le Faucheur, F., Charny, A., 1266 Briscoe, B., Eardley, P., Chan, K., and J. Babiarz, "RSVP Extensions 1267 for Admission Control over Diffserv using Pre-congestion 1268 Notification (PCN) (Work in progress)", June 2006. 1270 [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated 1271 Services in the Internet Architecture: an Overview", RFC 1633, June 1272 1994. 1274 [RFC2211] J. Wroclawski, Specification of the Controlled-Load Network 1275 Element Service, September 1997 1277 [RFC2212] S. Shenker et al., Specification of Guaranteed Quality of 1278 Service, September 1997 1280 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1281 "Definition of the Differentiated Services Field (DS Field) in the 1282 IPv4 and IPv6 Headers", RFC 2474, December 1998. 1284 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and 1285 W. Weiss, "A framework for Differentiated Services", RFC 2475, 1286 December 1998. 1288 [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 1289 Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A 1290 Framework for Integrated Services Operation Over DiffServ Networks", 1291 RFC 2998, November 2000. 1293 [RFC4230] H. Tschofenig, R. Graveman, "RSVP Security Properties", 1294 RFC 4230, December 2005. 1296 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 1297 Architecture", RFC 5559, June 2009. 1299 [RFC6411] M. Behringer, F. Le Faucheur, B. Weis, "Applicability of 1300 Keying Methods for RSVP Security", RFC 6411, October 2011. 1302 [SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested 1303 Virtual Private Network", Work in Progress, July 2007. 1305 [RFC2753] Yavatkar, R., D. Pendarakis and R. Guerin, "A Framework for 1306 Policy-based Admission Control", January 2000. 1308 10. Authors' Address 1310 Georgios Karagiannis 1311 University of Twente 1312 P.O. Box 217 1313 7500 AE Enschede, 1314 The Netherlands 1315 EMail: g.karagiannis@utwente.nl 1317 Anurag Bhargava 1318 Cisco Systems, Inc. 1319 7100-9 Kit Creek Road 1320 PO Box 14987 1321 RESEARCH TRIANGLE PARK, NORTH CAROLINA 27709-4987 1322 USA 1323 Email: anuragb@cisco.com