idnits 2.17.00 (12 Aug 2021) /tmp/idnits37739/draft-huang-dime-pcn-collection-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2010) is 4323 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) -- No information found for draft-CL-edge-behaviour - is the name correct? -- No information found for draft-SM-edge-behaviour - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force F. Huang, Ed. 3 Internet-Draft T. Taylor 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 14, 2011 G. Zorn 6 Network Zen 7 H. Tschofenig 8 Nokia Siemens Networks 9 July 13, 2010 11 Diameter Application To Transfer PCN Data From Edge Nodes To a 12 Centralized Decision Point 13 draft-huang-dime-pcn-collection-03 15 Abstract 17 Pre-congestion notification (PCN) is a technique for maintaining QoS 18 for inelastic flows in a DIFFServ domain. The PCN architecture 19 requires that egress nodes send regular reports of PCN-defined 20 measurements to a decision point. It requires further that the 21 decision point occasionally be able to request certain measurements 22 from ingress nodes. The decision point can be located in different 23 places in the network. This memo defines a Diameter application to 24 support communications between the ingress and egress nodes and a 25 Diameter server acting as a PCN decision point. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 14, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 63 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Egress Node Behaviour . . . . . . . . . . . . . . . . . . 5 65 3.2. Decision Point Behaviour . . . . . . . . . . . . . . . . . 5 66 3.3. Ingress Node Behaviour . . . . . . . . . . . . . . . . . . 6 67 4. Diameter PCN Data Collection Application . . . . . . . . . . . 6 68 4.1. Advertising Application Support . . . . . . . . . . . . . 6 69 4.2. Session Management . . . . . . . . . . . . . . . . . . . . 6 70 4.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.3.1. Congestion-Report-Request (CRR) Command . . . . . . . 7 72 4.3.2. Congestion-Report-Answer (CRA) Command . . . . . . . . 8 73 4.3.3. Measurement-Poll-Request (MPR) Command . . . . . . . . 8 74 4.3.4. Measurement-Poll-Answer (MPA) Command . . . . . . . . 9 75 4.4. Attribute Value Pairs (AVPs) . . . . . . . . . . . . . . . 9 76 4.4.1. I-E-Aggregate-Id AVP . . . . . . . . . . . . . . . . . 10 77 4.4.2. PCN-Ingress-Node-Address AVP . . . . . . . . . . . . . 10 78 4.4.3. PCN-Egress-Node-Address AVP . . . . . . . . . . . . . 10 79 4.4.4. Framed-IP-Address AVP . . . . . . . . . . . . . . . . 10 80 4.4.5. Framed-IPv6-prefix AVP . . . . . . . . . . . . . . . . 10 81 4.4.6. VLAN-ID-Range AVP . . . . . . . . . . . . . . . . . . 11 82 4.4.7. Aggregate-PCN-Egress-Data AVP . . . . . . . . . . . . 11 83 4.4.8. NM-Rate AVP . . . . . . . . . . . . . . . . . . . . . 11 84 4.4.9. ETM-Rate AVP . . . . . . . . . . . . . . . . . . . . . 11 85 4.4.10. ThM-Rate AVP . . . . . . . . . . . . . . . . . . . . . 11 86 4.4.11. CLE-Value AVP . . . . . . . . . . . . . . . . . . . . 11 87 4.4.12. Classifier AVP . . . . . . . . . . . . . . . . . . . . 12 88 4.4.13. PCN-Sent-Info AVP . . . . . . . . . . . . . . . . . . 12 89 4.4.14. I-E-Aggregate-Sent-Rate AVP . . . . . . . . . . . . . 12 90 4.5. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . 12 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 92 5.1. Diameter Application Identifier . . . . . . . . . . . . . 13 93 5.2. Diameter Command Codes . . . . . . . . . . . . . . . . . . 13 94 5.3. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . 13 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 96 6.1. Traffic Security . . . . . . . . . . . . . . . . . . . . . 14 97 6.2. Device Security . . . . . . . . . . . . . . . . . . . . . 14 98 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 100 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 101 Appendix A. Appendix A. Related Work in ITU-T . . . . . . . . . 16 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 104 1. Introduction 106 The objective of Pre-Congestion Notification (PCN) is to protect the 107 quality of service (QoS) of inelastic flows within a Diffserv domain 108 [RFC2475] in a simple, scalable and robust fashion. Admission 109 control allows decisions on whether to admit or reject a new flow 110 request, and (in abnormal circumstances, such as router failure) to 111 provide flow termination of already admitted flows. These two 112 mechanisms together aim to protect the QoS properties of previously 113 admitted flows. To achieve this, the overall rate of the PCN traffic 114 is metered on every link in the PCN domain, and PCN packets are 115 appropriately marked when certain configured rates are exceeded. 116 These configured rates are below the rate of the link thus providing 117 notification before any congestion occurs ("pre-congestion 118 notification"). The level of marking allows decisions to be made 119 about whether to admit or terminate. A more detailed description of 120 the architecture can be found in [RFC5559]. 122 Marking statistics are gathered by egress nodes on a per-ingress- 123 egress aggregate basis. If multipath routing is in use, egress nodes 124 may also send a list of individual flows along with the marking 125 statistics, if these flows have experienced an elevated level of pre- 126 congestion. 128 The reported statistics are processed to determine whether new flows 129 can be admitted to the aggregate over the next measurement interval 130 and whether some flows should be terminated to protect QoS for the 131 remainder. (Flow termination is expected to be relatively 132 infrequent, typically a result of network failure.) The admission 133 state is based on a congestion level estimate (CLE), which the 134 decision node derives from the statistics that the egress node passes 135 to the decision point. The decision to terminate flows is made on 136 the basis of a different criterion, also derived from those 137 statistics. For further details see [I-D.SM-edge-behaviour] and 138 [I-D.CL-edge-behaviour]. 140 2. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 3. Procedures 148 The following subsections discuss the processing requirements placed 149 upon the various participating Diameter nodes by the PCN Data 150 Collection application. 152 3.1. Egress Node Behaviour 154 The egress node measures the traffic from a particular ingress node, 155 and calculates either two or three flow rates (octets per second) at 156 the ingress-egress-aggregate level, based on the PCN markings of the 157 packets it receives and the edge node behaviour that has been 158 deployed. The three rates are the PCN-unmarked rate (NM-Rate), the 159 PCN-threshold-marked rate (ThM-Rate), and the PCN-excess-traffic- 160 marked rate (ETM-Rate). The ThM-Rate is collected for the CL edge 161 node behaviour [I-D.CL-edge-behaviour], but not for the SM edge node 162 behaviour [I-D.SM-edge-behaviour]. The egress node calculates these 163 rates and reports them to the decision point every 100 to 500 ms. 165 The CL and SM edge node behaviour specifications also provide an 166 option for the egress node to calculate a congestion level estimate 167 (CLE), equal to the ratio of PCN-marked to total PCN traffic received 168 in the interval. The egress node reports the calculated CLE to the 169 decision point along with the basic traffic rates. 171 The CL and SM edge node behaviour specifications provide a further 172 option for report suppression when the calculated CLE is below a 173 reporting threshold for two or more successive reporting periods. It 174 is RECOMMENDED that the operator configure egress nodes to activate 175 the CLE reporting and report suppression options, to minimize the 176 reporting traffic volume in the network and the the processing load 177 at the decision point. 179 For the CL mode only, when multipath routing is in effect, the egress 180 node may be configured to collect identifiers of flows that 181 experienced PCN-excess-traffic-marking during the measurement 182 interval along with the calculated traffic rates. 184 The egress node MUST use a Congestion Report Request (CRR) command to 185 send the calculated rates and the flow identifiers, when applicable, 186 to the decision node. The Event-Timestamp AVP MUST be present within 187 the CRR, and MUST indicate the ending time of the latest measurement 188 period represented by the information within the message. At least 189 one instance of the Aggregate-PCN-Egress-Data AVP MUST be present. 190 Multiple instances of this AVP MAY be present, but each instance MUST 191 report on a different ingress-egress-aggregate. 193 3.2. Decision Point Behaviour 195 If the decision point receives an Congestion-Report-Request (CRR) 196 identified as belonging to the PCN Data Collection application, it 197 MUST acknowledge the message with a Congestion-Report-Answer (CRA). 199 The decision point usage of the information provided by PCN- 200 Congestion-Info and PCN-Excess- Flow-Info AVPs is described in the 201 applicable edge behavior specification ([I-D.SM-edge-behaviour] or 202 [I-D.CL-edge-behaviour]. 204 The decision point MAY send a Measurement-Poll-Request (MPR) to the 205 ingress node for a specific ingress-egress-aggregate for which flow 206 termination appears to be required. The decision point will make the 207 decision about sending the MPR depending on the content of the CRR 208 relating to the ingress-egress- aggregate concerned. The decision 209 point SHOULD copy the Event-Timestamp AVP it received in the CRR to 210 the MPR. 212 If the decision point receives a successful Measurement-Poll-Answer 213 message, it uses the information contained in the PCN-Sent-Info AVP 214 to determine how much traffic to terminate, as described in 215 [I-D.SM-edge-behaviour] or [I-D.CL-edge-behaviour]. 217 3.3. Ingress Node Behaviour 219 When an ingress node receives an MPR, it MUST generate a Measurement- 220 Poll-Answer message containing an instance of the PCN-Sent-Info AVP. 221 The I-E-Aggregate-Id within the PCN-Sent-Info AVP MUST be the same as 222 received in the MPR, and the I-E-Aggregate-Sent-Rate MUST be a rate 223 measured for that aggregate. If Event-Timestamp is present in the 224 MPR, the measurement upon which I-E-Aggregate-Sent-Rate is based 225 SHOULD be that for a period after the time given by Event-Timestamp. 226 In any case, Event- Timestamp MUST be present in the MPA, and if it 227 is, MUST give the end-time of the measurement period upon which I-E- 228 Aggregate-Sent-Rate is based. 230 4. Diameter PCN Data Collection Application 232 4.1. Advertising Application Support 234 Clients, servers, and proxies supporting the PCN Data Collection 235 application MUST advertise support by including the value in 236 the Auth-Application-Id of Congestion-Report-Request (CRR), 237 Congestion-Report-Answer (CRA), Measurement-Poll-Request (MPR), and 238 Measurement-Poll-Answer (MPA) messages. 240 4.2. Session Management 242 Diameter sessions for this application are implicitly terminated. An 243 implicitly terminated session is one for which the server does not 244 maintain session state information. The client does not need to send 245 any re- authorization or session termination requests to the server. 247 The Diameter base protocol includes the Auth-Session-State AVP as the 248 mechanism for the implementation of implicitly terminated sessions. 250 The client (server) SHALL include in its requests (responses) the 251 Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as 252 described in RFC 3588 [RFC3588]. As a consequence, the server does 253 not maintain any state information about this session and the client 254 does not need to send any session termination request. Neither the 255 Authorization-Lifetime AVP nor the Session-Timeout AVP SHALL be 256 present in requests or responses. 258 4.3. Commands 260 The PCN Data Collection application defines four new commands, 261 Congestion-Report-Request(CRR), Congestion-Report-Answer(CRA), 262 Measurement-Poll-Request (MPR) and Measurement-Poll-Answer (MPA). 264 4.3.1. Congestion-Report-Request (CRR) Command 266 The egress node sends the Congestion-Report-Request (CRR) command, 267 indicated by the Command-Code field set to and the Command 268 Flags' 'R' bit set, to report PCN marking statistics and possibly 269 individual flow identifiers. Multiple reports for different ingress- 270 egress-aggregates MAY be included in the same message, as described 271 in Section 3.1. 273 Message format: 275 ::= < Diameter Header: CC1, REQ, PXY > 276 < Session-Id > 277 { Auth-Application-Id } 278 { Auth-Session-State } 279 { Origin-Host } 280 { Origin-Realm } 281 { Destination-Realm } 282 * ( Aggregate-PCN-Egress-Data ) 283 ( Event-Timestamp ] 284 [ Destination-Host ] 285 * [ Proxy-Info ] 286 * [ Route-Record ] 287 * [ AVP ] 289 At least one instance of the Aggregate-PCN-Egress-Data AVP MUST be 290 present. The value of the Session-Id AVP MUST be unique and SHOULD 291 be set according to the recommendations in Section 8.8 of RFC 3588 292 [RFC3588]. 294 4.3.2. Congestion-Report-Answer (CRA) Command 296 The decision point uses the Congestion-Report-Answer (CRA) command, 297 indicated by the Command-Code field set to and the Command 298 Flags' 'R' bit cleared, to acknowledge a Congestion-Report-Request 299 command sent by an egress node. The Congestion-Report-Answer command 300 contains the same Session-Id as the corresponding request. The 301 Event-Timestamp AVP MUST be present and MUST contain the value 302 received in the CRR that is being acknowledged. 304 Message format: 306 ::= < Diameter Header: CC1, PXY > 307 < Session-Id > 308 { Auth-Application-Id } 309 { Auth-Session-State } 310 { Result-Code } 311 { Origin-Host } 312 { Origin-Realm } 313 ( Event-Timestamp ) 314 [ Error-Message ] 315 [ Error-Reporting-Host ] 316 [ Failed-AVP ] 317 * [ Proxy-Info ] 318 * [ AVP ] 320 4.3.3. Measurement-Poll-Request (MPR) Command 322 The decision point sends the Measurement-Poll-Request (MPR) command, 323 indicated by the Command-Code field set to and the Command 324 Flags' 'R' bit set, to request that an ingress node report the rate 325 at which PCN- marked traffic has been forwarded to a given ingress- 326 egress aggregate, measured over a time period constrained as 327 described in Section 3.3. The value of the Session-Id AVP MUST be 328 unique and SHOULD be set according to the recommendations in Section 329 8.8 of RFC 3588 [RFC3588]. The I-E-Aggregate-Id AVP MUST be present. 330 The Event-Timestamp AVP SHOULD be present. 332 Message format: 334 ::= < Diameter Header: CC2, REQ, PXY > 335 < Session-Id > 336 { Auth-Application-Id } 337 { Auth-Session-State } 338 { Origin-Host } 339 { Origin-Realm } 340 { Destination-Realm } 341 { I-E-Aggregate-Id } 342 [ Destination-Host ] 343 [ Event-Timestamp ] 344 * [ Proxy-Info ] 345 * [ Route-Record ] 346 * [ AVP ] 348 4.3.4. Measurement-Poll-Answer (MPA) Command 350 The ingress node sends the Measurement-Poll-Answer (MPA) command, 351 indicated by the Command-Code field set to and the Command 352 Flags' 'R' bit cleared, in response to an MPR sent by the decision 353 point. The Session-Id MUST be copied from the MPR to which the MPA 354 is responding. The PCN-Sent-Info and Event-Timestamp AVPs MUST be 355 present. 357 Message format: 359 ::= < Diameter Header: CC2, PXY > 360 < Session-Id > 361 { Auth-Application-Id } 362 { Auth-Session-State } 363 { Result-Code } 364 { Origin-Host } 365 { Origin-Realm } 366 { PCN-Sent-Info } 367 ( Event-Timestamp ) 368 [ Error-Message ] 369 [ Error-Reporting-Host ] 370 [ Failed-AVP ] 371 * [ Proxy-Info ] 372 * [ AVP ] 374 4.4. Attribute Value Pairs (AVPs) 376 This section describes the AVPs specific to the PCN Data Collection 377 application. The 'M' bit MUST be set and the 'V' bit MUST NOT be set 378 for all of these AVPs when used in the PCN Data Collection 379 application. 381 4.4.1. I-E-Aggregate-Id AVP 383 The I-E-Aggregate-Id AVP (AVP code ) is of type Grouped and 384 identifies a specific aggregate. 386 The I-E-Aggregate-Id AVP has the following format: 388 EDITOR'S NOTE: may need to add something that works for MPLS. 390 I-E-Aggregate-Id ::= < AVP Header: AVP1 > 391 [ PCN-Ingress-Node-Address ] 392 [ PCN-Egress-Node-Address ] 393 [ VLAN-ID-Range ] 394 * [ AVP ] 396 4.4.2. PCN-Ingress-Node-Address AVP 398 The PCN-Ingress-Node-Address AVP (AVP code ) is of type Grouped 399 and contains the address of a PCN-Ingress-Node. 401 The PCN-Ingress-Node-Address AVP has the following format: 403 PCN-Ingress-Node-Address ::= < AVP Header: AVP2 > 404 [ Framed-IP-Address ] 405 [ Framed-IPv6-Prefix ] 407 4.4.3. PCN-Egress-Node-Address AVP 409 The PCN-Egress-Node-Address AVP (AVP code ) is of type Grouped 410 and contains the address of a PCN-Egress-Node. 412 The PCN-Egress-Node-Address AVP has the following format: 414 PCN-Egress-Node-Address ::= < AVP Header: AVP3 > 415 [ Framed-IP-Address ] 416 [ Framed-IPv6-Prefix ] 418 4.4.4. Framed-IP-Address AVP 420 The Framed-IP-Address AVP is defined in the NASREQ application (RFC 421 4005 [RFC4005]). 423 4.4.5. Framed-IPv6-prefix AVP 425 The Framed-IPv6-prefix AVP is defined in the NASREQ application (RFC 426 4005 [RFC4005]). 428 4.4.6. VLAN-ID-Range AVP 430 The VLAN-ID-Range AVP, defined in ietf-dime-qos-attributes [I-D.ietf- 431 dime-qos-attributes], is of type Grouped and specifies the VLAN range 432 to match. 434 4.4.7. Aggregate-PCN-Egress-Data AVP 436 The PCN-Congestion-Info AVP (AVP code ) is of type Grouped. It 437 identifies an ingress-egress aggregate, reports the current value of 438 the PCN-unmarked, PCN-excess-traffic-marked, and optionally, PCN- 439 threshold- marked traffic rates and the CLE, and MAY identify zero or 440 more flows experiencing excess-traffic-marking. 442 The PCN-Congestion-Info AVP has the following format: 444 Aggregate-PCN-Egress-Data ::= < AVP Header: AVP4 > 445 { I-E-Aggregate-Id } 446 { NM-Rate } 447 { ETM-Rate } 448 [ ThM-Rate ] 449 [ CLE-Value ] 450 * [ Classifier ] 451 * [ AVP ] 453 4.4.8. NM-Rate AVP 455 The NM-Rate AVP (AVP code ) is of type Unsigned32. It gives 456 the calculated rate of receipt of PCN-unmarked traffic in octets per 457 second for a given ingress-egress-aggregate. 459 4.4.9. ETM-Rate AVP 461 The ETM-Rate AVP (AVP code ) is of type Unsigned32. It gives 462 the calculated rate of receipt of excess-traffic-marked traffic in 463 octets per second for a given ingress-egress-aggregate. 465 4.4.10. ThM-Rate AVP 467 The ThM-Rate AVP (AVP code ) is of type Unsigned32. It gives 468 the calculated rate of receipt of threshold-marked traffic in octets 469 per second for a given ingress-egress-aggregate. 471 4.4.11. CLE-Value AVP 473 The CLE-Value AVP (AVP code ) is of type Unsigned32. It gives 474 the calculated ratio of traffic rates of PCN-marked traffic to total 475 PCN traffic received at the egress node, multiplied by 1000 and 476 truncated, for a given ingress-egress-aggregate. By construction, 477 the value of the CLE-Value AVP ranges from 0 to 1000. 479 4.4.12. Classifier AVP 481 The Classifier AVP (AVP Code 511) is a grouped AVP that consists of a 482 set of attributes that specify how to match a packet. The Classifier 483 AVP is defined in [RFC5777]. In the present specification its 484 purpose is to identify a flow that is experiencing excess-traffic- 485 marking. 487 4.4.13. PCN-Sent-Info AVP 489 The PCN-Sent-Info AVP (AVP code ) is of type Grouped. It 490 provides the estimated rate of flow of PCN traffic in octets per 491 second that the ingress node has admitted to a given ingress-egress- 492 aggregate. 494 The PCN-Sent-Info AVP has the following format: 496 PCN-Sent-Info ::= < AVP Header: AVP9 > 497 { I-E-Aggregate-Id } 498 { I-E-Aggregate-Sent-Rate } 499 * [ AVP ] 501 4.4.14. I-E-Aggregate-Sent-Rate AVP 503 The I-E-Aggregate-Sent-Rate AVP (AVP code ) is of type 504 Unsigned32. It gives the estimated rate of flow of PCN traffic in 505 octets per second that the ingress node forwarded to the identified 506 ingress-egress aggregate, calculated for the measurement period 507 ending at the time given by the Event-Timestamp AVP. 509 4.5. AVP Occurrence Tables 511 The following table presents the AVPs defined in this document and 512 their occurrences in Diameter messages. Note that AVPs that can only 513 be present within a Grouped AVP are not represented in this table. 515 The table uses the following symbols: 517 0: The AVP MUST NOT be present in the message. 519 1: One instance of the AVP MUST be present in the message. 521 1+: One or more instances of the AVP MUST be present in the message. 523 +-----------------------+ 524 | Command-Code | 525 |-----+-----+-----+-----+ 526 AVP Name | CRR | CRA | MPR | MPA | 527 -------------------------------|-----+-----+-----+-----+ 528 Aggregate-PCN-Egress-Data | 1+ | 0 | 0 | 0 | 529 PCN-Sent-Info | 0 | 0 | 0 | 1 | 530 I-E-Aggregate-Id | (*) | 0 | 1 | (*) | 531 +-----+-----+-----+-----+ 533 (*): Note that the I-E-Aggregate-Id AVP appears alone in the MPR 534 command and is contained within the Aggregate-PCN-Egress-Data grouped 535 AVP (CRR command) and the PCN-Sent-Info grouped AVP (MPA command). 537 5. IANA Considerations 539 Upon publication of this memo as an RFC, IANA is requested to assign 540 values as described in the following sections. 542 5.1. Diameter Application Identifier 544 An application identifier for Diameter PCN Data Collection (, 545 Section 4.1) must be assigned according to the policy specified in 546 Section 11.3 of [RFC3588]. 548 5.2. Diameter Command Codes 550 Codes must be assigned for the following commands according to the 551 policy specified in [RFC3588], Section 11.2.1: 553 o Congestion-Report-Request (CRR) and Congestion-Report-Answer (CRA) 554 (, Section 4.3.1 and Section 4.3.2). 556 o Measurement-Poll-Request (MPR) and Measurement-Poll-Answer (MPA) 557 (, Section 4.3.3 and Section 4.3.4). 559 5.3. Attribute-Value Pairs 561 Codes must be assigned for the following AVPs using the policy 562 specified in [RFC3588], Section 11.1.1: 564 o I-E-Aggregate-Id (, Section 4.4.1) 566 o PCN-Ingress-Node-Address (, Section 4.4.2) 568 o PCN-Egress-Node-Address (, Section 4.4.3) 570 o Aggregate-PCN-Egress-Data (, Section 4.4.7) 572 o NM-Rate (, Section 4.4.8) 574 o ETM-Rate (, Section 4.4.9) 576 o ThM-Rate (, Section 4.4.10) 578 o CLE-Value (, Section 4.4.11) 580 o PCN-Sent-Info (, Section 4.4.13) 582 o I-E-Aggregate-Sent-Rate (, Section 4.4.14). 584 6. Security Considerations 586 The following sections discuss the security threats against the 587 Diameter PCN Data Collection application and describe some 588 countermeasures. 590 6.1. Traffic Security 592 Application traffic MUST be secured as specified in RFC 3588 593 [RFC3588] (i.e., through the use of (preferably) TLS or IPsec). In 594 the absence of appropriate protection, all manner (including man-in- 595 the-middle) of attacks are possible, potentially resulting in the 596 inappropriate termination and non-admittance of flows. 598 6.2. Device Security 600 Compromise of an ingress node by an attacker could result in the 601 inappropriate refusal of admittance to valid flows, while the 602 compromise of an egress node could allow the termination of valid 603 flows. 605 Compromise of the decision point could result in both denial of 606 admission to new flows and termination of existing flows, enabling an 607 attacker to essentially control PCN traffic on the affected network. 609 7. References 610 7.1. Normative References 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, March 1997. 615 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 616 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 618 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 619 "Diameter Network Access Server Application", RFC 4005, 620 August 2005. 622 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 623 and A. Lior, "Traffic Classification and Quality of 624 Service (QoS) Attributes for Diameter", RFC 5777, 625 February 2010. 627 7.2. Informative References 629 [I-D.CL-edge-behaviour] 630 Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. 631 Taylor, "PCN Boundary Node Behaviour for the Controlled 632 Load (CL) Mode of Operation (Work In progress)", 633 June 2010. 635 [I-D.SM-edge-behaviour] 636 Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. 637 Taylor, "PCN Boundary Node Behaviour for the Single 638 Marking (SM) Mode of Operation (Work in progress)", 639 June 2010. 641 [Q.3303.3] 642 ITU-T, "Resource control protocol No. 3 -- Protocols at 643 the Rw interface between a policy decision physical entity 644 (PD-PE) and a policy enforcement physical entity (PE-PE): 645 Diameter", ITU-T Recommendation Q.3303.3, May 2008. 647 649 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 650 and W. Weiss, "An Architecture for Differentiated 651 Services", RFC 2475, December 1998. 653 [RFC5431] Sun, D., "Diameter ITU-T Rw Policy Enforcement Interface 654 Application", RFC 5431, March 2009. 656 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 657 Architecture", RFC 5559, June 2009. 659 Appendix A. Appendix A. Related Work in ITU-T 661 The ITU-T is doing work to exploit the PCN technology in an 662 environment where the decisions are made by a central policy decision 663 point (decision point) [Q.3303.3], which needs the information 664 generated by PCN marking to support per-flow decisions on admission 665 and termination. This memo defines a Diameter application to 666 transfer the information from edge nodes to the decision point. 667 Egress node reports are sent by the egress node acting as client to 668 the decision point acting as server. Data generated at the ingress 669 node are needed only when flow termination is required. They are 670 requested by the decision point acting as client and sent in 671 responses by the ingress node acting as server. The decision point 672 thus acts both as client and as server in the same application. The 673 Rw application [RFC5431] provides a precedent for such an 674 application. 676 The PCN Data Collection application is related to existing ITU-T 677 applications as follows: 679 o The Rs application allows application-level functions to request 680 flow admission for individual application flows. 682 o The Rw application provides the control linkage between a Policy 683 Decision Point and an ingress router, to pass down decisions on 684 flow admission following either the push or the pull model. The 685 Rw application also passes flow termination decisions. 687 As can be seen from this brief description, the PCN Data Collection 688 application defined in this memo is complementary to the Rw 689 application. Within the strict terms of the ITU-T architecture, it 690 is a realization of a different interface, the Rc interface. 691 However, the PCN Data Collection application is intended for use in 692 any of a number of architectures based on a centralized policy 693 decision element. 695 Authors' Addresses 697 Fortune Huang (editor) 698 Huawei Technologies 699 Section F, Huawei 700 Industrial Base 701 Bantian Longgang, Shenzhen 518129 702 P.R. China 704 Email: fqhuang@huawei.com 705 Tom Taylor 706 Huawei Technologies 707 Ottawa, Ontario 708 Canada 710 Email: tom111.taylor@bell.net 712 Glen Zorn 713 Network Zen 714 1310 East Thomas Street 715 #306 716 Seattle,, Washington 98102 717 USA 719 Phone: +1 (206) 377-9035 720 Email: gwz@net-zen.net 722 Hannes Tschofenig 723 Nokia Siemens Networks 724 Linnoitustie 6 725 Espoo 02600 726 Finland 728 Phone: +358 (50) 4871445 729 Email: Hannes.Tschofenig@nsn.com 730 URI: http://www.tschofenig.priv.at