idnits 2.17.00 (12 Aug 2021) /tmp/idnits16743/draft-huang-dime-pcn-collection-00.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 (July 6, 2009) is 4701 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) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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 Huawei Technologies 4 Intended status: Standards Track G. Zorn, Ed. 5 Expires: January 7, 2010 Network Zen 6 July 6, 2009 8 The Diameter Precongestion Notification (PCN) Data Collection 9 Application 10 draft-huang-dime-pcn-collection-00 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 7, 2010. 35 Copyright Notice 37 Copyright (c) 2009 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 in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 Pre-Congestion notification (PCN) is a technique for maintaining QoS 49 for inelastic flows in a DIFFServ domain. The PCN architecture 50 requires that egress nodes send reports of congestion-related events 51 (flow admission state change, excess flow) reliably to a policy 52 decision point. The ITU-T is working on a variant of this 53 architecture which places the policy decision point in a central node 54 rather than ingress or egress nodes of the network. In this case the 55 policy decision point must request and obtain certain data from an 56 ingress node when it receives an excess flow report affecting that 57 ingress node. This memo defines a Diameter application to support 58 egress node reporting and data collection from the ingress node. The 59 nature of the data flows requires the policy decision point to act 60 both as server and as client. Hence this memo draws upon the 61 precedent established by the Rw application (RFC 5431 and ITU-T 62 Recommendation Q.3303.3). 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 69 4. The Diameter PCN Data Collection Application . . . . . . . . . 5 70 4.1. Advertising Application Support . . . . . . . . . . . . . 5 71 4.2. Diameter Session Usage . . . . . . . . . . . . . . . . . . 5 72 4.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.3.1. Congestion-Report-Request (CRR) Command . . . . . . . 6 74 4.3.2. Congestion-Report-Answer (CRA) Command . . . . . . . . 6 75 4.3.3. Measurement-Poll-Request (MPR) Command . . . . . . . . 7 76 4.3.4. Measurement-Poll-Answer (MPA) Command . . . . . . . . 7 77 4.4. Attribute Value Pairs (AVPs) . . . . . . . . . . . . . . . 8 78 4.4.1. I-E-Aggregate-Id AVP . . . . . . . . . . . . . . . . . 8 79 4.4.2. PCN-Congestion-Info AVP . . . . . . . . . . . . . . . 8 80 4.4.3. CLE-Value AVP . . . . . . . . . . . . . . . . . . . . 8 81 4.4.4. CLE-Report-Reason AVP . . . . . . . . . . . . . . . . 9 82 4.4.5. PCN-Excess-Flow-Info AVP . . . . . . . . . . . . . . . 9 83 4.4.6. I-E-Aggregate-Excess-Rate AVP . . . . . . . . . . . . 9 84 4.4.7. Flow Number AVP . . . . . . . . . . . . . . . . . . . 9 85 4.4.8. Flow Description . . . . . . . . . . . . . . . . . . . 10 86 4.4.9. PCN-Sent-Info AVP . . . . . . . . . . . . . . . . . . 10 87 4.4.10. I-E-Aggregate-Sent-Rate AVP . . . . . . . . . . . . . 11 88 4.5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 11 89 4.5.1. Overall Procedures . . . . . . . . . . . . . . . . . . 11 90 4.5.2. Egress Node Behaviour . . . . . . . . . . . . . . . . 11 91 4.5.3. PDP Behaviour . . . . . . . . . . . . . . . . . . . . 12 92 4.5.4. Ingress Node Behaviour . . . . . . . . . . . . . . . . 12 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 94 5.1. Diameter Application Identifier . . . . . . . . . . . . . 13 95 5.2. Diameter Command Codes . . . . . . . . . . . . . . . . . . 13 96 5.3. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . 13 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 98 6.1. Traffic Security . . . . . . . . . . . . . . . . . . . . . 14 99 6.2. Device Security . . . . . . . . . . . . . . . . . . . . . 14 100 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 101 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 102 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 105 1. Introduction 107 The objective of Pre-Congestion Notification (PCN) is to protect the 108 quality of service (QoS) of inelastic flows within a Diffserv domain 109 [RFC2475] in a simple, scalable and robust fashion. Two mechanisms 110 are used: admission control, to decide whether to admit or block a 111 new flow request, and (in abnormal circumstances) flow termination to 112 decide whether to terminate some of the existing flows. Together 113 they protect the QoS of previously admitted flows. To achieve this, 114 the overall rate of the PCN-traffic is metered on every link in the 115 PCN-domain, and PCN-packets are appropriately marked when certain 116 configured rates are exceeded. These configured rates are below the 117 rate of the link thus providing notification before any congestion 118 occurs ("pre-congestion notification"). The level of marking allows 119 decisions to be made about whether to admit or terminate. For a full 120 description of the PCN architecture, see [RFC5559]. 122 Marking statistics are gathered by egress nodes on a per-ingress- 123 egress aggregate basis. They are processed to determine whether new 124 flows can be admitted to the aggregate over the next measurement 125 interval and whether some flows should be terminated to protect QoS 126 for the remainder (flow termination is expected to be relatively 127 infrequent, typically a result of network failure). The admission 128 state is based on a congestion level estimate (CLE), which the egress 129 node reports to a decision point whenever the CLE value passes a set 130 threshold (upward or downward). The decision to terminate flows is 131 made on the basis of a different criterion. When the egress node 132 detects that this criterion has been satisfied, it sends a report to 133 the decision node providing measurement values that are used to 134 determine the total volume of traffic that must be terminated. If 135 equal cost multipath (ECMP) routing is in use, it also sends a list 136 of individual flows that were marked at the termination level. 138 2. Related Work 140 The ITU-T is doing work to exploit the PCN technology in an 141 environment where the decisions are made by a central policy decision 142 point (PDP) [Q.3303.3], which needs the information generated by PCN 143 marking to support per-flow decisions on admission and termination. 144 This memo defines a Diameter application to transfer the information 145 from edge nodes to the PDP. Egress node reports are sent by the 146 egress node acting as client to the PDP acting as server. Data 147 generated at the ingress node are needed only when flow termination 148 is required. They are requested by the PDP acting as client and sent 149 in responses by the ingress node acting as server. The PDP thus acts 150 both as client and as server in the same application. The Rw 151 application [RFC5431] provides a precedent for such an application. 153 The PCN Data Collection application is related to existing ITU-T 154 applications as follows: 156 o The Rs application allows application-level functions to request 157 flow admission for individual application flows. 159 o The Rw application provides the control linkage between a Policy 160 Decision Point and an ingress router, to pass down decisions on 161 flow admission following either the push or the pull model. The 162 Rw application also passes flow termination decisions. 164 As can be seen from this brief description, the PCN Data Collection 165 application defined in this memo is complementary to the Rw 166 application. Within the strict terms of the ITU-T architecture, it 167 is a realization of a different interface, the Rc interface. 168 However, the PCN Data Collection application is intended for use in 169 any of a number of architectures based on a centralized policy 170 decision element. 172 3. Requirements Language 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119]. 178 4. The Diameter PCN Data Collection Application 180 4.1. Advertising Application Support 182 Clients, servers, and proxies supporting the PCN Data Collection 183 application MUST advertise support by including the value in 184 the Auth-Application-Id of Congestion-Report-Request (CRR), 185 Congestion-Report-Answer (CRA), Measurement-Poll-Request (MPR), and 186 Measurement-Poll-Answer (MPA) messages. 188 4.2. Diameter Session Usage 190 Diameter sessions are implicitly terminated. An implicitly 191 terminated session is one for which the server does not maintain 192 state information. The client does not need to send any re- 193 authorization or session termination requests to the server. The 194 Diameter base protocol includes the Auth-Session-State AVP as the 195 mechanism for the implementation of implicitly terminated sessions. 196 The client (server) shall include in its requests (responses) the 197 Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as 198 described in RFC 3588 [RFC3588]. As a consequence, the server does 199 not maintain any state information about this session and the client 200 does not need to send any session termination request. Neither the 201 Authorization-Lifetime AVP nor the Session-Timeout AVP shall be 202 present in requests or responses. 204 4.3. Commands 206 The PCN Data Collection application defines four new commands, 207 Congestion-Report-Request(CRR), Congestion-Report-Answer(CRA), 208 Measurement-Poll-Request (MPR) and Measurement-Poll-Answer (MPA). 210 4.3.1. Congestion-Report-Request (CRR) Command 212 The egress node sends the Congestion-Report-Request (CRR) command, 213 indicated by the Command-Code field set to and the Command 214 Flags' 'R' bit set, to report when the congestion level estimate 215 (CLE) moves above or drops below the pre-congestion reporting 216 threshold, or when an excess flow condition is detected. Multiple 217 reports MAY be included in the same message, as described in 218 Section 4.5.2. 220 Message format: 222 ::= < Diameter Header: CC1, REQ, PXY > 223 < Session-Id > 224 { Auth Application Id } 225 { Origin-Host } 226 { Origin-Realm } 227 { Destination-Realm } 228 [ Destination-Host ] 229 [ Event-Timestamp ] 230 * [ PCN-Congestion-Info ] 231 * [ PCN-Excess-Flow-Info ] 232 * [ Proxy-Info ] 233 * [ Route-Record ] 234 * [ AVP ] 236 At least one instance of the PCN-Congestion-Info or the PCN-Excess- 237 Flow-Info AVP MUST be present. 239 4.3.2. Congestion-Report-Answer (CRA) Command 241 The PDP uses the Congestion-Report-Answer (CRA) command, indicated by 242 the Command-Code field set to and the Command Flags' 'R' bit 243 cleared, to acknowledge an Congestion-Report-Request command sent by 244 an egress node. The Congestion-Report-Answer command contains the 245 same Session-Id as the corresponding request. 247 Message format: 249 ::= < Diameter Header: CC1, PXY > 250 < Session-Id > 251 { Auth Application Id } 252 { Result-Code } 253 { Origin-Host } 254 { Origin-Realm } 255 [ Error-Message ] 256 [ Error-Reporting-Host ] 257 [ Failed-AVP ] 258 [ Event-Timestamp ] 259 * [ Proxy-Info ] 260 * [ AVP ] 262 4.3.3. Measurement-Poll-Request (MPR) Command 264 The PDP sends the Measurement-Poll-Request (MPR) command, indicated 265 by the Command-Code field set to and the Command Flags' 'R' bit 266 set, to request that an ingress node report the rate at which PCN- 267 marked traffic has been forwarded to a given ingress-egress 268 aggregate, measured over a given measurement period as described in 269 Section 4.5.4. 271 Message format: 273 ::= < Diameter Header: CC2, REQ, PXY > 274 < Session-Id > 275 { Auth Application Id } 276 { Origin-Host } 277 { Origin-Realm } 278 { Destination-Realm } 279 { I-E-Aggregate-Id } 280 [ Destination-Host ] 281 [ Event-Timestamp ] 282 * [ Proxy-Info ] 283 * [ Route-Record ] 284 * [ AVP ] 286 4.3.4. Measurement-Poll-Answer (MPA) Command 288 The ingress node sends the Measurement-Poll-Answer (MPA) command, 289 indicated by the Command-Code field set to and the Command 290 Flags' 'R' bit cleared, in response to an MPR sent by the PDP. 292 Message format: 294 ::= < Diameter Header: CC2, PXY > 295 < Session-Id > 296 { Auth Application Id } 297 { Result-Code } 298 { Origin-Host } 299 { Origin-Realm } 300 { PCN-Sent-Info } 301 [ Error-Message ] 302 [ Error-Reporting-Host ] 303 [ Failed-AVP ] 304 [ Event-Timestamp ] 305 * [ Proxy-Info ] 306 * [ AVP ] 308 4.4. Attribute Value Pairs (AVPs) 310 This section describes the AVPs specific to the PCN Data Collection 311 application. The 'M' bit MUST be set and the 'V' bit MUST NOT be set 312 for all of these AVPs when used in the PCN Data Collection 313 application. 315 4.4.1. I-E-Aggregate-Id AVP 317 The I-E-Aggregate-Id AVP (AVP code ) is of type UTF8String. It 318 identifies a specific ingress-egress aggregate flow. The internal 319 structure of the I-E-Aggregate-Id value is network dependent. 321 4.4.2. PCN-Congestion-Info AVP 323 The PCN-Congestion-Info AVP (AVP code ) is of type Grouped. It 324 identifies an ingress-egress aggregate, reports the current value of 325 the congestion level estimate (CLE), and indicates whether the report 326 is generated because the CLE has risen above the reporting threshold 327 or because it has fallen below the reporting threshold. 329 The PCN-Congestion-Info AVP has the following format: 331 PCN-Congestion-Info ::= < AVP Header: AVP2 > 332 { I-E-Aggregate-Id } 333 { CLE-Value } 334 { CLE-Report-Reason } 335 * [ AVP ] 337 4.4.3. CLE-Value AVP 339 The CLE-Value AVP (AVP code ) is of type Float32. It gives the 340 current (smoothed) congestion level estimate as a fraction between 341 0.0 and 1.0. 343 4.4.4. CLE-Report-Reason AVP 345 The CLE-Report-Reason AVP (AVP code ) is of type Enumerated. 346 The following values are defined in this document: 348 PRECONGESTION_ONSET (0) 349 The current CLE (reported in CLE-Value) is above the configured 350 onset reporting threshold. The CLE derived in the previous 351 measurement period was below that threshold. 353 PRECONGESTION_END (1) The current CLE (reported in CLE-Value) is 354 below the configured end-of-precongestion reporting threshold, 355 which may have the same value as the onset reporting threshold. 356 The CLE derived in the previous measurement period was above that 357 threshold. 359 4.4.5. PCN-Excess-Flow-Info AVP 361 The PCN-Excess-Flow-Info AVP (AVP code ) is of type Grouped. 362 It identifies an ingress-egress aggregate, reports a rate of excess 363 traffic for that aggregate, and MAY identify a number of individual 364 flows within that aggregate that experienced the markings that led to 365 the generation of the PCN-Excess-Flow-Info AVP. Precise details of 366 the conditions under which this AVP is generated and how the 367 indivdual flows are selected are given in the specification for the 368 PCN edge behaviour deployed in the domain. 370 The PCN-Excess-Flow-Info AVP has the following format: 372 PCN-Excess-Flow-Info ::= < AVP Header: AVP5 > 373 { I-E-Aggregate-Id } 374 { I-E-Aggregate-Excess-Rate } 375 * [ Flow Number ] 376 * [ Flow Description ] 377 * [ AVP ] 379 4.4.6. I-E-Aggregate-Excess-Rate AVP 381 The I-E-Aggregate-Excess-Rate AVP (AVP code ) is of type 382 Unsigned32. It gives the rate of flow of excess traffic in octets 383 per second that the egress node derived for the identified ingress- 384 egress aggregate for the measurement period ending at the time given 385 by the Event-Timestamp AVP (if present). 387 4.4.7. Flow Number AVP 389 The Flow Number AVP (AVP code 509) is of type Unsigned32, and it 390 contains the ordinal number of the IP flow(s). The rules for how the 391 ordinal number should be assigned are not described in this document. 393 4.4.8. Flow Description 395 The Flow Description AVP (AVP code 507) is of type IPFilterRule, and 396 defines a packet filter for an IP flow with the following 397 information: 399 o Direction (in or out). 401 o Source and destination IP address (possibly masked). 403 o Protocol. 405 o Source and destination port (list or ranges). 407 The b type shall be used with the following restrictions: 409 o Only the Action "permit" shall be used. 411 o No "options" shall be used. 413 o The invert modifier "!" for addresses shall not be used. 415 o The keyword "assigned" shall not be used. 417 The Flow description AVP shall be used to describe a single IP flow. 418 The direction "in" refers to uplink IP flows, and the direction "out" 419 refers to downlink IP flows. 421 4.4.9. PCN-Sent-Info AVP 423 The PCN-Sent-Info AVP (AVP code ) is of type Grouped. It 424 provides the rate of flow of PCN-marked traffic in octets per second 425 that the ingress node derived for the identified ingress-egress 426 aggregate for the measurement period ending at the time given by the 427 Event-Timestamp AVP (if present). 429 The PCN-Sent-Info AVP has the following format: 431 PCN-Sent-Info ::= < AVP Header: AVP8 > 432 { I-E-Aggregate-Id } 433 { I-E-Aggregate-Sent-Rate } 434 * [ AVP ] 436 4.4.10. I-E-Aggregate-Sent-Rate AVP 438 The I-E-Aggregate-Sent-Rate AVP (AVP code ) is of type 439 Unsigned32. It gives the rate of flow of PCN-marked traffic in 440 octets per second that the ingress node forwarded to the identified 441 ingress-egress aggregate, calculated for the measurement period 442 ending at the time given by the Event-Timestamp AVP (if present). 444 4.5. Procedures 446 The following subsections discuss the processing requirements placed 447 upon the various participating Diameter nodes by the PCN Data 448 Collection application. 450 4.5.1. Overall Procedures 452 The egress node measures the traffic from a particular ingress node, 453 and calculates the congestion level estimate(CLE) at the ingress- 454 egress aggregate level. The egress node may compare the CLE 455 calculated at the current interval with the CLE calculated at the 456 last interval, if the difference of the two CLEs exceeds a preset 457 range, the egress node sends the feedback information, including at 458 least the current CLE, to the PDP. After receiving the feedback 459 information, the PDP saves the it for admission control and flow 460 termination. After receiving a service flow request, the PDP can 461 determine whether to admit the request or not based on the feedback 462 information. Besides, the PDP also decides whether some of the 463 admitted flows need to be terminated. The PDP needs to signal to the 464 ingress node the decision about admission or termination. 466 4.5.2. Egress Node Behaviour 468 For each ingress-egress aggregate flow it serves, the egress node 469 meters received traffic for PCN markings, recomputes its smoothed 470 congestion level estimate, and determines whether there is excess 471 flow in successive measurement periods in accordance with the PCN 472 edge behaviour specification deployed in the domain. When a change 473 in the smoothed congestion level estimate causes it to cross a 474 reporting threshold, either upward or downward, the egress node MUST 475 send an Accounting-Request message to the PDP. Similarly, the egress 476 node MUST send an Accounting-Request message to the PDP when excess 477 flow is detected for an ingress-egress aggregate served by that node. 478 The Session-Id is irrelevant to the PCN Data Collection application 479 and MAY have any value that conforms to [RFC3588]. The Account- 480 Record-Type for the message MUST be set to EVENT_RECORD (1). The 481 Accounting-Record-Number AVP SHOULD be set to 0. 483 The Event-Timestamp AVP SHOULD be present, and SHOULD provide the 484 ending time of the measurement period from which the data triggering 485 the generation of the message were derived. At least one instance 486 either of the PCN-Congestion-Info or the PCN-Excess-Flow-Info AVP 487 MUST be present. Both AVPs MAY be present for the same ingress- 488 egress aggregate, if both apply according to the edge behaviour 489 specification. Multiple instances of either AVP MAY be present, but 490 each instance MUST report on a different ingress-egress aggregate. 492 4.5.3. PDP Behaviour 494 If the PDP receives an Accounting-Request (ACR) identified as 495 belonging to the PCN Data Collection application, it MUST acknowledge 496 the message with an Accounting-Answer (ACA). The PDP usage of the 497 information provided by PCN-Congestion-Info and PCN-Excess-Flow-Info 498 AVPs is described in the applicable edge behaviour specification. 500 When the PDP receives an ACR containing an PCN-Excess-Flow-Info AVP, 501 it MAY send a Measurement-Poll-Request (MPR) to the ingress node for 502 the aggregate concerned. The Account-Record-Type for the message 503 MUST be set to EVENT_RECORD (1). The I-E-Aggregate-Id MUST identify 504 the ingress-egress aggregate flow for which information is being 505 requested. The Event-Timestamp MUST be present if it was present in 506 the ACR that contained the PCN-Excess-Flow-Info AVP, and MUST have 507 the same value. 509 If the PDP receives a successful Measurement-Poll-Answer message, it 510 uses the information contained in the PCN-Sent-Info AVP as described 511 in the applicable edge behaviour specification. 513 4.5.4. Ingress Node Behaviour 515 When an ingress node receives an MPR, it MUST generate a Measurement- 516 Poll-Answer message containing an instance of the PCN-Sent-Info AVP. 517 The Account-Record-Type for the message MUST be set to EVENT_RECORD 518 (1). The Accounting-Record-Number AVP SHOULD be set to 0. The I-E- 519 Aggregate-Id within the PCN-Sent-Info AVP MUST be the same as 520 received in the MPR, and the I-E-Aggregate-Sent-Rate MUST be a rate 521 measured for that aggregate. If Event-Timestamp is present in the 522 MPR, the measurement upon which I-E-Aggregate-Sent-Rate is based 523 SHOULD be that for the latest measurement period ending before or at 524 the time given by Event-Timestamp, if available. In any case, Event- 525 Timestamp SHOULD be present in the MPA, and if it is, MUST give the 526 end-time of the measurement period upon which I-E-Aggregate-Sent-Rate 527 is based. 529 5. IANA Considerations 531 Upon publication of this memo as an RFC, IANA is requested to assign 532 values as described in the following sections. 534 5.1. Diameter Application Identifier 536 An application identifier for Diameter PCN Data Collection (, 537 Section 4.1) must be assigned according to the policy specified in 538 Section 11.3 of RFC 3588. 540 5.2. Diameter Command Codes 542 Command codes must be assigned for Congestion-Report-Request (CRR) 543 (, Section 4.3.1), Congestion-Report-Answer (MPA) (, 544 Section 4.3.2), Measurement-Poll-Request (MPR) (, Section 4.3.3) 545 and Measurement-Poll-Answer (MPA) (, Section 4.3.4) commands 546 according to the policy specified in RFC 3588, Section 11.2.1. 548 5.3. Attribute-Value Pairs 550 Codes must be assigned for the following AVPs using the policy 551 specified in RFC 3588, Section 11.1.1: 553 I-E-Aggregate-Id (, Section 4.4.1) 555 PCN-Congestion-Info (, Section 4.4.2) 557 CLE-Value (, Section 4.4.3) 559 CLE-Report-Reason (, Section 4.4.4) 561 PCN-Excess-Flow-Info (, Section 4.4.5) 563 I-E-Aggregate-Excess-Rate (, Section 4.4.6) 565 PCN-Sent-Info (, Section 4.4.9) 567 I-E-Aggregate-Sent-Rate (, Section 4.4.10) 569 6. Security Considerations 571 The following sections discuss the security threats against the 572 Diameter PCN Data Collection application and describe some 573 countermeasues. 575 6.1. Traffic Security 577 Application taffic MUST be secured as specified in RFC 3588 (i.e.,, 578 through the use of (preferably) TLS or IPsec). In the absence of 579 appropriate protection, all manner (including man-in-the-middle) of 580 attacks are possible, potentially resulting in the inappropriate 581 termination and non-adittance of flows. 583 6.2. Device Security 585 Compromise of an ingress node by an attacker could result in the 586 inappropriate refusal of admittance to valid flows, while the 587 compromise of an egress node could allow the termination of valid 588 flows. 590 Compromise of the PDP could result in both denial of admission to new 591 flows and termination of existing flows, enabling an attacker to 592 essentially control PCN traffic on the affected network. 594 7. References 596 7.1. Normative References 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, March 1997. 601 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 602 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 604 7.2. Informative References 606 [Q.3303.3] 607 ITU-T, "Resource control protocol No. 3 -- Protocols at 608 the Rw interface between a policy decision physical entity 609 (PD-PE) and a policy enforcement physical entity (PE-PE): 610 Diameter", May 2008, 611 . 613 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 614 and W. Weiss, "An Architecture for Differentiated 615 Services", RFC 2475, December 1998. 617 [RFC5431] Sun, D., "Diameter ITU-T Rw Policy Enforcement Interface 618 Application", RFC 5431, March 2009. 620 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 621 Architecture", RFC 5559, June 2009. 623 Authors' Addresses 625 Fortune Huang 626 Huawei Technologies 627 Section F 628 Huawei Industrial Base 629 Bantian Longgang, Shenzhen 518129 630 P.R. China 632 Email: fqhuang@huawei.com 634 Glen Zorn (editor) 635 Network Zen 636 1310 East Thomas Street 637 #306 638 Seattle, Washington 98102 639 USA 641 Phone: +1 (206) 377-9035 642 Email: gwz@net-zen.net