idnits 2.17.00 (12 Aug 2021) /tmp/idnits17619/draft-huang-dime-pcn-collection-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (October 26, 2009) is 4589 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) == Outdated reference: draft-ietf-dime-qos-attributes has been published as RFC 5777 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) == Outdated reference: draft-ietf-pcn-cl-edge-behaviour has been published as RFC 6661 == Outdated reference: draft-ietf-pcn-sm-edge-behaviour has been published as RFC 6662 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Huang 3 Internet-Draft T. Taylor 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 29, 2010 G. Zorn, Ed. 6 Network Zen 7 H. Tschofenig 8 Nokia Siemens Networks 9 October 26, 2009 11 The Diameter Precongestion Notification (PCN) Data Collection 12 Application 13 draft-huang-dime-pcn-collection-02 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 29, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 Pre-Congestion notification (PCN) is a technique for maintaining QoS 52 for inelastic flows in a DIFFServ domain. The PCN architecture 53 requires that egress nodes send reports of congestion-related events 54 reliably to a policy decision point. The policy decision point might 55 be located in different places of the network. In one architectural 56 variant the policy decision point is a central node rather than co- 57 located with the ingress or the egress nodes of the network. In this 58 case it needs to have access to certain information from the edge 59 nodes. This memo defines a Diameter application to support the 60 ingress and the egress node to interact with the Diameter server 61 acting as a policy decision point. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 67 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Overall Procedures . . . . . . . . . . . . . . . . . . . . 5 69 3.2. Egress Node behavior . . . . . . . . . . . . . . . . . . . 5 70 3.3. PDP behavior . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.4. Ingress Node behavior . . . . . . . . . . . . . . . . . . 6 72 4. Diameter PCN Data Collection Application . . . . . . . . . . . 6 73 4.1. Advertising Application Support . . . . . . . . . . . . . 6 74 4.2. Session Management . . . . . . . . . . . . . . . . . . . . 6 75 4.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.3.1. Congestion-Report-Request (CRR) Command . . . . . . . 7 77 4.3.2. Congestion-Report-Answer (CRA) Command . . . . . . . . 8 78 4.3.3. Measurement-Poll-Request (MPR) Command . . . . . . . . 8 79 4.3.4. Measurement-Poll-Answer (MPA) Command . . . . . . . . 9 80 4.4. Attribute Value Pairs (AVPs) . . . . . . . . . . . . . . . 9 81 4.4.1. I-E-Aggregate-Id AVP . . . . . . . . . . . . . . . . . 9 82 4.4.2. PCN-Ingress-Node-Address AVP . . . . . . . . . . . . . 10 83 4.4.3. PCN-Egress-Node-Address AVP . . . . . . . . . . . . . 10 84 4.4.4. Framed-IP-Address AVP . . . . . . . . . . . . . . . . 10 85 4.4.5. Framed-IPv6-prefix AVP . . . . . . . . . . . . . . . . 10 86 4.4.6. VLAN-ID-Range AVP . . . . . . . . . . . . . . . . . . 10 87 4.4.7. PCN-Congestion-Info AVP . . . . . . . . . . . . . . . 11 88 4.4.8. CLE-Value AVP . . . . . . . . . . . . . . . . . . . . 11 89 4.4.9. CLE-Report-Reason AVP . . . . . . . . . . . . . . . . 11 90 4.4.10. PCN-Excess-Flow-Info AVP . . . . . . . . . . . . . . . 11 91 4.4.11. I-E-Aggregate-Excess-Rate AVP . . . . . . . . . . . . 12 92 4.4.12. Classifier AVP . . . . . . . . . . . . . . . . . . . . 12 93 4.4.13. PCN-Sent-Info AVP . . . . . . . . . . . . . . . . . . 12 94 4.4.14. I-E-Aggregate-Sent-Rate AVP . . . . . . . . . . . . . 12 95 4.5. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . 13 96 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 97 5.1. Diameter Application Identifier . . . . . . . . . . . . . 13 98 5.2. Diameter Command Codes . . . . . . . . . . . . . . . . . . 14 99 5.3. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . 14 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 101 6.1. Traffic Security . . . . . . . . . . . . . . . . . . . . . 15 102 6.2. Device Security . . . . . . . . . . . . . . . . . . . . . 15 103 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 104 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 105 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 106 Appendix A. Related Work in ITU-T . . . . . . . . . . . . . . . . 16 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 109 1. Introduction 111 The objective of Pre-Congestion Notification (PCN) is to protect the 112 quality of service (QoS) of inelastic flows within a Diffserv domain 113 [RFC2475] in a simple, scalable and robust fashion. Admission 114 control allows to decide whether to admit or reject a new flow 115 request, and (in abnormal circumstances, such as router failure) to 116 provide flow termination of already admitted flows. These two 117 mechanisms together aim to protect the QoS properties of previously 118 admitted flows. To achieve this, the overall rate of the PCN traffic 119 is metered on every link in the PCN domain, and PCN packets are 120 appropriately marked when certain configured rates are exceeded. 121 These configured rates are below the rate of the link thus providing 122 notification before any congestion occurs ("pre-congestion 123 notification"). The level of marking allows decisions to be made 124 about whether to admit or terminate. A more detailed description of 125 the architecture can be found in [RFC5559]. 127 Marking statistics are gathered by egress nodes on a per-ingress- 128 egress aggregate basis. They are processed to determine whether new 129 flows can be admitted to the aggregate over the next measurement 130 interval and whether some flows should be terminated to protect QoS 131 for the 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 egress 134 node reports to a decision point whenever the CLE value passes a set 135 threshold (upward or downward). The decision to terminate flows is 136 made on the basis of a different criterion. When the egress node 137 detects that this criterion has been satisfied, it sends a report to 138 the decision node providing measurement values that are used to 139 determine the total volume of traffic that must be terminated. If 140 equal cost multipath (ECMP) routing is in use, it also sends a list 141 of individual flows that were marked at the termination level. 143 2. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 3. Procedures 151 The following subsections discuss the processing requirements placed 152 upon the various participating Diameter nodes by the PCN Data 153 Collection application. 155 3.1. Overall Procedures 157 The egress node measures the traffic from a particular ingress node, 158 and calculates the congestion level estimate(CLE) at the ingress- 159 egress aggregate level. The egress node may compare the CLE 160 calculated at the current interval with the CLE calculated at the 161 last interval, if the difference of the two CLEs exceeds a preset 162 range, the egress node sends the feedback information, including at 163 least the current CLE, to the PDP. After receiving the feedback 164 information, the PDP saves the it for admission control and flow 165 termination. After receiving a service flow request, the PDP can 166 determine whether to admit the request or not based on the feedback 167 information. Besides, the PDP also decides whether some of the 168 admitted flows need to be terminated. The PDP needs to signal to the 169 ingress node the decision about admission or termination. 171 3.2. Egress Node behavior 173 For each ingress-egress aggregate flow it serves, the egress node 174 meters received traffic for PCN markings, recomputes its smoothed 175 congestion level estimate, and determines whether there is excess 176 flow in successive measurement periods in accordance with the PCN 177 edge behavior specification (e.g. ietf-pcn-cl-edge-behaviour 178 [I-D.ietf-pcn-cl-edge-behaviour], ietf-pcn-sm-edge-behaviour 179 [I-D.ietf-pcn-sm-edge-behaviour]) deployed in the domain. When a 180 change in the smoothed congestion level estimate causes it to cross a 181 reporting threshold, either upward or downward, the egress node MUST 182 send a Congestion-Report-Request message to the PDP. Similarly, the 183 egress node MUST send a Congestion-Report-Request message to the PDP 184 when excess flow is detected for an ingress-egress aggregate served 185 by that node. 187 The Event-Timestamp AVP MUST be present, and MUST provide the ending 188 time of the measurement period from which the data triggering the 189 generation of the message were derived. At least one instance either 190 of the PCN-Congestion-Info or the PCN-Excess-Flow-Info AVP MUST be 191 present. Both AVPs MAY be present for the same ingress-egress 192 aggregate, if both apply according to the edge behavior 193 specification. Multiple instances of either AVP MAY be present, but 194 each instance MUST report on a different ingress-egress aggregate. 196 3.3. PDP behavior 198 If the PDP receives an Congestion-Report-Request (CRR) identified as 199 belonging to the PCN Data Collection application, it MUST acknowledge 200 the message with an Congestion-Report-Answer (CRA). The PDP usage of 201 the information provided by PCN-Congestion-Info and PCN-Excess-Flow- 202 Info AVPs is described in the applicable edge behavior specification. 204 When the PDP receives an CRR containing a PCN-Excess-Flow-Info AVP, 205 it MAY send a Measurement-Poll-Request (MPR) to the ingress node for 206 the aggregate concerned. The PDP will make the decision about 207 sending the MPR depending on the content of the received report. In 208 case the report indicates that a critical threshold has been reached 209 then it has to obtain information about which and how many flows to 210 terminate. The I-E-Aggregate-Id MUST identify the ingress-egress 211 aggregate flow for which information is being requested. The Event- 212 Timestamp MUST be present if it was present in the CRR that contained 213 the PCN-Excess-Flow-Info AVP, and MUST have the same value. 215 If the PDP receives a successful Measurement-Poll-Answer message, it 216 uses the information contained in the PCN-Sent-Info AVP as described 217 in the applicable edge behavior specification. 219 3.4. Ingress Node behavior 221 When an ingress node receives an MPR, it MUST generate a Measurement- 222 Poll-Answer message containing an instance of the PCN-Sent-Info AVP. 223 The I-E-Aggregate-Id within the PCN-Sent-Info AVP MUST be the same as 224 received in the MPR, and the I-E-Aggregate-Sent-Rate MUST be a rate 225 measured for that aggregate. If Event-Timestamp is present in the 226 MPR, the measurement upon which I-E-Aggregate-Sent-Rate is based 227 SHOULD be that for the latest measurement period ending before or at 228 the time given by Event-Timestamp, if available. In any case, Event- 229 Timestamp MUST be present in the MPA, and if it is, MUST give the 230 end-time of the measurement period upon which I-E-Aggregate-Sent-Rate 231 is based. 233 4. Diameter PCN Data Collection Application 235 4.1. Advertising Application Support 237 Clients, servers, and proxies supporting the PCN Data Collection 238 application MUST advertise support by including the value in 239 the Auth-Application-Id of Congestion-Report-Request (CRR), 240 Congestion-Report-Answer (CRA), Measurement-Poll-Request (MPR), and 241 Measurement-Poll-Answer (MPA) messages. 243 4.2. Session Management 245 Diameter sessions are implicitly terminated. An implicitly 246 terminated session is one for which the server does not maintain 247 session state information. The client does not need to send any re- 248 authorization or session termination requests to the server. The 249 Diameter base protocol includes the Auth-Session-State AVP as the 250 mechanism for the implementation of implicitly terminated sessions. 252 The client (server) SHALL include in its requests (responses) the 253 Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as 254 described in RFC 3588 [RFC3588]. As a consequence, the server does 255 not maintain any state information about this session and the client 256 does not need to send any session termination request. Neither the 257 Authorization-Lifetime AVP nor the Session-Timeout AVP SHALL be 258 present in requests or responses. 260 4.3. Commands 262 The PCN Data Collection application defines four new commands, 263 Congestion-Report-Request(CRR), Congestion-Report-Answer(CRA), 264 Measurement-Poll-Request (MPR) and Measurement-Poll-Answer (MPA). 266 4.3.1. Congestion-Report-Request (CRR) Command 268 The egress node sends the Congestion-Report-Request (CRR) command, 269 indicated by the Command-Code field set to and the Command 270 Flags' 'R' bit set, to report when the congestion level estimate 271 (CLE) moves above or drops below the pre-congestion reporting 272 threshold, or when an excess flow condition is detected. Multiple 273 reports MAY be included in the same message, as described in 274 Section 3.2. 276 Message format: 278 ::= < Diameter Header: CC1, REQ, PXY > 279 < Session-Id > 280 { Auth-Application-Id } 281 { Auth-Session-State } 282 { Origin-Host } 283 { Origin-Realm } 284 { Destination-Realm } 285 [ Destination-Host ] 286 [ Event-Timestamp ] 287 * [ PCN-Congestion-Info ] 288 * [ PCN-Excess-Flow-Info ] 289 * [ Proxy-Info ] 290 * [ Route-Record ] 291 * [ AVP ] 293 At least one instance of the PCN-Congestion-Info or the PCN-Excess- 294 Flow-Info AVP MUST be present; the value of the Session-Id AVP MUST 295 be unique and SHOULD be set according to the recommendations in 296 Section 8.8 of RFC 3588 [RFC3588]. 298 4.3.2. Congestion-Report-Answer (CRA) Command 300 The PDP uses the Congestion-Report-Answer (CRA) command, indicated by 301 the Command-Code field set to and the Command Flags' 'R' bit 302 cleared, to acknowledge an Congestion-Report-Request command sent by 303 an egress node. The Congestion-Report-Answer command contains the 304 same Session-Id as the corresponding request. 306 Message format: 308 ::= < Diameter Header: CC2, PXY > 309 < Session-Id > 310 { Auth-Application-Id } 311 { Auth-Session-State } 312 { Result-Code } 313 { Origin-Host } 314 { Origin-Realm } 315 [ Error-Message ] 316 [ Error-Reporting-Host ] 317 [ Failed-AVP ] 318 [ Event-Timestamp ] 319 * [ Proxy-Info ] 320 * [ AVP ] 322 4.3.3. Measurement-Poll-Request (MPR) Command 324 The PDP sends the Measurement-Poll-Request (MPR) command, indicated 325 by the Command-Code field set to and the Command Flags' 'R' bit 326 set, to request that an ingress node report the rate at which PCN- 327 marked traffic has been forwarded to a given ingress-egress 328 aggregate, measured over a given measurement period as described in 329 Section 3.4. The value of the Session-Id AVP MUST be unique and 330 SHOULD be set according to the recommendations in Section 8.8 of RFC 331 3588 [RFC3588]. 333 Message format: 335 ::= < Diameter Header: CC3, REQ, PXY > 336 < Session-Id > 337 { Auth-Application-Id } 338 { Auth-Session-State } 339 { Origin-Host } 340 { Origin-Realm } 341 { Destination-Realm } 342 { I-E-Aggregate-Id } 343 [ Destination-Host ] 344 [ Event-Timestamp ] 345 * [ Proxy-Info ] 346 * [ Route-Record ] 347 * [ AVP ] 349 4.3.4. Measurement-Poll-Answer (MPA) Command 351 The ingress node sends the Measurement-Poll-Answer (MPA) command, 352 indicated by the Command-Code field set to and the Command 353 Flags' 'R' bit cleared, in response to an MPR sent by the PDP. 355 Message format: 357 ::= < Diameter Header: CC4, PXY > 358 < Session-Id > 359 { Auth-Application-Id } 360 { Auth-Session-State } 361 { Result-Code } 362 { Origin-Host } 363 { Origin-Realm } 364 { PCN-Sent-Info } 365 [ Error-Message ] 366 [ Error-Reporting-Host ] 367 [ Failed-AVP ] 368 [ Event-Timestamp ] 369 * [ Proxy-Info ] 370 * [ AVP ] 372 4.4. Attribute Value Pairs (AVPs) 374 This section describes the AVPs specific to the PCN Data Collection 375 application. The 'M' bit MUST be set and the 'V' bit MUST NOT be set 376 for all of these AVPs when used in the PCN Data Collection 377 application. 379 4.4.1. I-E-Aggregate-Id AVP 381 The I-E-Aggregate-Id AVP (AVP code ) is of type Grouped and 382 identifies a specific aggregate. 384 The I-E-Aggregate-Id AVP has the following format: 386 I-E-Aggregate-Id ::= < AVP Header: AVP1 > 387 [ PCN-Ingress-Node-Address ] 388 [ PCN-Egress-Node-Address ] 389 [ VLAN-ID-Range ] 390 * [ AVP ] 392 4.4.2. PCN-Ingress-Node-Address AVP 394 The PCN-Ingress-Node-Address AVP (AVP code ) is of type Grouped 395 and contains the address of a PCN-Ingress-Node. 397 The PCN-Ingress-Node-Address AVP has the following format: 399 PCN-Ingress-Node-Address ::= < AVP Header: AVP2 > 400 [ Framed-IP-Address ] 401 [ Framed-IPv6-Prefix ] 403 4.4.3. PCN-Egress-Node-Address AVP 405 The PCN-Egress-Node-Address AVP (AVP code ) is of type Grouped 406 and contains the address of a PCN-Egress-Node. 408 The PCN-Egress-Node-Address AVP has the following format: 410 PCN-Egress-Node-Address ::= < AVP Header: AVP3 > 411 [ Framed-IP-Address ] 412 [ Framed-IPv6-Prefix ] 414 4.4.4. Framed-IP-Address AVP 416 The Framed-IP-Address AVP is defined in the NASREQ application (RFC 417 4005 [RFC4005]). 419 4.4.5. Framed-IPv6-prefix AVP 421 The Framed-IPv6-prefix AVP is defined in the NASREQ application (RFC 422 4005 [RFC4005]). 424 4.4.6. VLAN-ID-Range AVP 426 The VLAN-ID-Range AVP, defined in ietf-dime-qos-attributes 427 [I-D.ietf-dime-qos-attributes], is of type Grouped and specifies the 428 VLAN range to match. 430 4.4.7. PCN-Congestion-Info AVP 432 The PCN-Congestion-Info AVP (AVP code ) is of type Grouped. It 433 identifies an ingress-egress aggregate, reports the current value of 434 the congestion level estimate (CLE), and indicates whether the report 435 is generated because the CLE has risen above the reporting threshold 436 or because it has fallen below the reporting threshold. 438 The PCN-Congestion-Info AVP has the following format: 440 PCN-Congestion-Info ::= < AVP Header: AVP4 > 441 { I-E-Aggregate-Id } 442 { CLE-Value } 443 { CLE-Report-Reason } 444 * [ AVP ] 446 4.4.8. CLE-Value AVP 448 The CLE-Value AVP (AVP code ) is of type Float32. It gives the 449 current (smoothed) congestion level estimate as a fraction between 450 0.0 and 1.0. 452 4.4.9. CLE-Report-Reason AVP 454 The CLE-Report-Reason AVP (AVP code ) is of type Enumerated. 455 The following values are defined in this document: 457 PRECONGESTION_ONSET (0) 458 The current CLE (reported in CLE-Value) is above the configured 459 onset reporting threshold. The CLE derived in the previous 460 measurement period was below that threshold. 462 PRECONGESTION_END (1) The current CLE (reported in CLE-Value) is 463 below the configured end-of-precongestion reporting threshold, 464 which may have the same value as the onset reporting threshold. 465 The CLE derived in the previous measurement period was above that 466 threshold. 468 4.4.10. PCN-Excess-Flow-Info AVP 470 The PCN-Excess-Flow-Info AVP (AVP code ) is of type Grouped. 471 It identifies an ingress-egress aggregate, reports a rate of excess 472 traffic for that aggregate, and MAY identify a number of individual 473 flows within that aggregate that experienced the markings that led to 474 the generation of the PCN-Excess-Flow-Info AVP. Precise details of 475 the conditions under which this AVP is generated and how the 476 indivdual flows are selected are given in the specification for the 477 PCN edge behaviour deployed in the domain. 479 The PCN-Excess-Flow-Info AVP has the following format: 481 PCN-Excess-Flow-Info ::= < AVP Header: AVP7 > 482 { I-E-Aggregate-Id } 483 { I-E-Aggregate-Excess-Rate } 484 * [ Classifier ] 485 * [ AVP ] 487 4.4.11. I-E-Aggregate-Excess-Rate AVP 489 The I-E-Aggregate-Excess-Rate AVP (AVP code ) is of type 490 Unsigned32. It gives the rate of flow of excess traffic in octets 491 per second that the egress node derived for the identified ingress- 492 egress aggregate for the measurement period ending at the time given 493 by the Event-Timestamp AVP (if present). 495 4.4.12. Classifier AVP 497 The Classifier AVP (AVP Code TBD), defined in ietf-dime-qos- 498 attributes [I-D.ietf-dime-qos-attributes], is a grouped AVP that 499 consists of a set of attributes that specify how to match a packet. 501 4.4.13. PCN-Sent-Info AVP 503 The PCN-Sent-Info AVP (AVP code ) is of type Grouped. It 504 provides the rate of flow of PCN-marked traffic in octets per second 505 that the ingress node derived for the identified ingress-egress 506 aggregate for the measurement period ending at the time given by the 507 Event-Timestamp AVP (if present). 509 The PCN-Sent-Info AVP has the following format: 511 PCN-Sent-Info ::= < AVP Header: AVP9 > 512 { I-E-Aggregate-Id } 513 { I-E-Aggregate-Sent-Rate } 514 * [ AVP ] 516 4.4.14. I-E-Aggregate-Sent-Rate AVP 518 The I-E-Aggregate-Sent-Rate AVP (AVP code ) is of type 519 Unsigned32. It gives the rate of flow of PCN-marked traffic in 520 octets per second that the ingress node forwarded to the identified 521 ingress-egress aggregate, calculated for the measurement period 522 ending at the time given by the Event-Timestamp AVP (if present). 524 4.5. AVP Occurrence Tables 526 The following tables present the AVPs defined in this document and 527 their occurrences in Diameter messages. Note that AVPs that can only 528 be present within a Grouped AVP are not represented in this table. 530 The table uses the following symbols: 532 0: The AVP MUST NOT be present in the message. 534 0+: Zero or more instances of the AVP MAY be present in the 535 message. 537 0-1: Zero or one instance of the AVP MAY be present in the 538 message. 540 1: One instance of the AVP MUST be present in the message. 542 +-----------------------+ 543 | Command-Code | 544 |-----+-----+-----+-----+ 545 AVP Name | CRR | CRA | MPR | MPA | 546 -------------------------------|-----+-----+-----+-----+ 547 PCN-Congestion-Info | 0+ | 0 | 0 | 0 | 548 PCN-Excess-Flow-Info | 0+ | 0 | 0 | 0 | 549 PCN-Sent-Info | 0 | 0 | 0 | 1 | 550 I-E-Aggregate-Id | (*) | 0 | 1 | (*) | 551 +-----+-----+-----+-----+ 553 (*): Note that the I-E-Aggregate-Id AVP appears alone in the MPR 554 command and within the PCN-Sent-Info grouped AVP (MPA command), the 555 PCN-Excess-Flow-Info AVP, and the PCN-Congestion-Info AVP. 557 5. IANA Considerations 559 Upon publication of this memo as an RFC, IANA is requested to assign 560 values as described in the following sections. 562 5.1. Diameter Application Identifier 564 An application identifier for Diameter PCN Data Collection (, 565 Section 4.1) must be assigned according to the policy specified in 566 Section 11.3 of RFC 3588 [RFC3588]. 568 5.2. Diameter Command Codes 570 Codes must be assigned for the following commands according to the 571 policy specified in RFC 3588 [RFC3588], Section 11.2.1: 573 o Congestion-Report-Request (CRR) (, Section 4.3.1) 575 o Congestion-Report-Answer (MPA) (, Section 4.3.2) 577 o Measurement-Poll-Request (MPR) (, Section 4.3.3) 579 o Measurement-Poll-Answer (MPA) (, Section 4.3.4) 581 5.3. Attribute-Value Pairs 583 Codes must be assigned for the following AVPs using the policy 584 specified in RFC 3588 [RFC3588], Section 11.1.1: 586 o I-E-Aggregate-Id (, Section 4.4.1) 588 o PCN-Ingress-Node-Address (, Section 4.4.2) 590 o PCN-Egress-Node-Address (, Section 4.4.3) 592 o PCN-Congestion-Info (, Section 4.4.7) 594 o CLE-Value (, Section 4.4.8) 596 o CLE-Report-Reason (, Section 4.4.9) 598 o PCN-Excess-Flow-Info (, Section 4.4.10) 600 o I-E-Aggregate-Excess-Rate (, Section 4.4.11) 602 o PCN-Sent-Info (, Section 4.4.13) 604 o I-E-Aggregate-Sent-Rate (, Section 4.4.14) 606 6. Security Considerations 608 The following sections discuss the security threats against the 609 Diameter PCN Data Collection application and describe some 610 countermeasures. 612 6.1. Traffic Security 614 Application traffic MUST be secured as specified in RFC 3588 615 [RFC3588] (i.e., through the use of (preferably) TLS or IPsec). In 616 the absence of appropriate protection, all manner (including man-in- 617 the-middle) of attacks are possible, potentially resulting in the 618 inappropriate termination and non-admittance of flows. 620 6.2. Device Security 622 Compromise of an ingress node by an attacker could result in the 623 inappropriate refusal of admittance to valid flows, while the 624 compromise of an egress node could allow the termination of valid 625 flows. 627 Compromise of the PDP could result in both denial of admission to new 628 flows and termination of existing flows, enabling an attacker to 629 essentially control PCN traffic on the affected network. 631 7. References 633 7.1. Normative References 635 [I-D.ietf-dime-qos-attributes] 636 Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 637 and A. Lior, "Quality of Service Attributes for Diameter", 638 draft-ietf-dime-qos-attributes-13 (work in progress), 639 July 2009. 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 645 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 647 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 648 "Diameter Network Access Server Application", RFC 4005, 649 August 2005. 651 7.2. Informative References 653 [I-D.ietf-pcn-cl-edge-behaviour] 654 Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. 655 Taylor, "PCN Boundary Node Behaviour for the Controlled 656 Load (CL) Mode of Operation", 657 draft-ietf-pcn-cl-edge-behaviour-00 (work in progress), 658 July 2009. 660 [I-D.ietf-pcn-sm-edge-behaviour] 661 Charny, A., Karagiannis, G., Menth, M., and T. Taylor, 662 "PCN Boundary Node Behaviour for the Single Marking (SM) 663 Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-00 664 (work in progress), July 2009. 666 [Q.3303.3] 667 ITU-T, "Resource control protocol No. 3 -- Protocols at 668 the Rw interface between a policy decision physical entity 669 (PD-PE) and a policy enforcement physical entity (PE-PE): 670 Diameter", May 2008, 671 . 673 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 674 and W. Weiss, "An Architecture for Differentiated 675 Services", RFC 2475, December 1998. 677 [RFC5431] Sun, D., "Diameter ITU-T Rw Policy Enforcement Interface 678 Application", RFC 5431, March 2009. 680 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 681 Architecture", RFC 5559, June 2009. 683 Appendix A. Related Work in ITU-T 685 The ITU-T is doing work to exploit the PCN technology in an 686 environment where the decisions are made by a central policy decision 687 point (PDP) [Q.3303.3], which needs the information generated by PCN 688 marking to support per-flow decisions on admission and termination. 689 This memo defines a Diameter application to transfer the information 690 from edge nodes to the PDP. Egress node reports are sent by the 691 egress node acting as client to the PDP acting as server. Data 692 generated at the ingress node are needed only when flow termination 693 is required. They are requested by the PDP acting as client and sent 694 in responses by the ingress node acting as server. The PDP thus acts 695 both as client and as server in the same application. The Rw 696 application [RFC5431] provides a precedent for such an application. 698 The PCN Data Collection application is related to existing ITU-T 699 applications as follows: 701 o The Rs application allows application-level functions to request 702 flow admission for individual application flows. 704 o The Rw application provides the control linkage between a Policy 705 Decision Point and an ingress router, to pass down decisions on 706 flow admission following either the push or the pull model. The 707 Rw application also passes flow termination decisions. 709 As can be seen from this brief description, the PCN Data Collection 710 application defined in this memo is complementary to the Rw 711 application. Within the strict terms of the ITU-T architecture, it 712 is a realization of a different interface, the Rc interface. 713 However, the PCN Data Collection application is intended for use in 714 any of a number of architectures based on a centralized policy 715 decision element. 717 Authors' Addresses 719 Fortune Huang 720 Huawei Technologies 721 Section F 722 Huawei Industrial Base 723 Bantian Longgang, Shenzhen 518129 724 P.R. China 726 Email: fqhuang@huawei.com 728 Tom Taylor 729 Huawei Technologies 730 1852 Lorraine Ave 731 Ottawa, Ontario K1H 6Z8 732 Canada 734 Phone: +1 613 680 2675 735 Email: tom.taylor@rogers.com 737 Glen Zorn (editor) 738 Network Zen 739 1310 East Thomas Street 740 #306 741 Seattle, Washington 98102 742 USA 744 Phone: +1 (206) 377-9035 745 Email: gwz@net-zen.net 746 Hannes Tschofenig 747 Nokia Siemens Networks 748 Linnoitustie 6 749 Espoo 02600 750 Finland 752 Phone: +358 (50) 4871445 753 Email: Hannes.Tschofenig@nsn.com 754 URI: http://www.tschofenig.priv.at