idnits 2.17.00 (12 Aug 2021) /tmp/idnits17902/draft-huang-dime-pcn-collection-01.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: o The invert modifier "!" for addresses SHALL not be used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: o The keyword "assigned" SHALL not be used. -- The document date (July 12, 2009) is 4695 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 (~~), 3 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: January 13, 2010 G. Zorn, Ed. 6 Network Zen 7 July 12, 2009 9 The Diameter Precongestion Notification (PCN) Data Collection 10 Application 11 draft-huang-dime-pcn-collection-01 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 13, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 Pre-Congestion notification (PCN) is a technique for maintaining QoS 50 for inelastic flows in a DIFFServ domain. The PCN architecture 51 requires that egress nodes send reports of congestion-related events 52 (flow admission state change, excess flow) reliably to a policy 53 decision point. The ITU-T is working on a variant of this 54 architecture which places the policy decision point in a central node 55 rather than ingress or egress nodes of the network. In this case the 56 policy decision point must request and obtain certain data from an 57 ingress node when it receives an excess flow report affecting that 58 ingress node. This memo defines a Diameter application to support 59 egress node reporting and data collection from the ingress node. The 60 nature of the data flows requires the policy decision point to act 61 both as server and as client. Hence this memo draws upon the 62 precedent established by the Rw application (RFC 5431 and ITU-T 63 Recommendation Q.3303.3). 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 70 4. The Diameter PCN Data Collection Application . . . . . . . . . 5 71 4.1. Advertising Application Support . . . . . . . . . . . . . 5 72 4.2. Diameter Session Usage . . . . . . . . . . . . . . . . . . 5 73 4.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.3.1. Congestion-Report-Request (CRR) Command . . . . . . . 6 75 4.3.2. Congestion-Report-Answer (CRA) Command . . . . . . . . 6 76 4.3.3. Measurement-Poll-Request (MPR) Command . . . . . . . . 7 77 4.3.4. Measurement-Poll-Answer (MPA) Command . . . . . . . . 8 78 4.4. Attribute Value Pairs (AVPs) . . . . . . . . . . . . . . . 8 79 4.4.1. I-E-Aggregate-Id AVP . . . . . . . . . . . . . . . . . 8 80 4.4.2. PCN-Congestion-Info AVP . . . . . . . . . . . . . . . 8 81 4.4.3. CLE-Value AVP . . . . . . . . . . . . . . . . . . . . 9 82 4.4.4. CLE-Report-Reason AVP . . . . . . . . . . . . . . . . 9 83 4.4.5. PCN-Excess-Flow-Info AVP . . . . . . . . . . . . . . . 9 84 4.4.6. I-E-Aggregate-Excess-Rate AVP . . . . . . . . . . . . 10 85 4.4.7. Flow-Number AVP . . . . . . . . . . . . . . . . . . . 10 86 4.4.8. Flow-Description AVP . . . . . . . . . . . . . . . . . 10 87 4.4.9. PCN-Sent-Info AVP . . . . . . . . . . . . . . . . . . 10 88 4.4.10. I-E-Aggregate-Sent-Rate AVP . . . . . . . . . . . . . 11 89 4.5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 11 90 4.5.1. Overall Procedures . . . . . . . . . . . . . . . . . . 11 91 4.5.2. Egress Node behavior . . . . . . . . . . . . . . . . . 11 92 4.5.3. PDP behavior . . . . . . . . . . . . . . . . . . . . . 12 93 4.5.4. Ingress Node behavior . . . . . . . . . . . . . . . . 12 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 95 5.1. Diameter Application Identifier . . . . . . . . . . . . . 13 96 5.2. Diameter Command Codes . . . . . . . . . . . . . . . . . . 13 97 5.3. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . 13 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 99 6.1. Traffic Security . . . . . . . . . . . . . . . . . . . . . 14 100 6.2. Device Security . . . . . . . . . . . . . . . . . . . . . 14 101 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 102 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 103 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 106 1. Introduction 108 The objective of Pre-Congestion Notification (PCN) is to protect the 109 quality of service (QoS) of inelastic flows within a Diffserv domain 110 [RFC2475] in a simple, scalable and robust fashion. Two mechanisms 111 are used: admission control, to decide whether to admit or block a 112 new flow request, and (in abnormal circumstances) flow termination to 113 decide whether to terminate some of the existing flows. Together 114 they protect the QoS of previously admitted flows. To achieve this, 115 the overall rate of the PCN-traffic is metered on every link in the 116 PCN-domain, and PCN-packets are appropriately marked when certain 117 configured rates are exceeded. These configured rates are below the 118 rate of the link thus providing notification before any congestion 119 occurs ("pre-congestion notification"). The level of marking allows 120 decisions to be made about whether to admit or terminate. For a full 121 description of the PCN architecture, see [RFC5559]. 123 Marking statistics are gathered by egress nodes on a per-ingress- 124 egress aggregate basis. They are processed to determine whether new 125 flows can be admitted to the aggregate over the next measurement 126 interval and whether some flows should be terminated to protect QoS 127 for the remainder (flow termination is expected to be relatively 128 infrequent, typically a result of network failure). The admission 129 state is based on a congestion level estimate (CLE), which the egress 130 node reports to a decision point whenever the CLE value passes a set 131 threshold (upward or downward). The decision to terminate flows is 132 made on the basis of a different criterion. When the egress node 133 detects that this criterion has been satisfied, it sends a report to 134 the decision node providing measurement values that are used to 135 determine the total volume of traffic that must be terminated. If 136 equal cost multipath (ECMP) routing is in use, it also sends a list 137 of individual flows that were marked at the termination level. 139 2. Related Work 141 The ITU-T is doing work to exploit the PCN technology in an 142 environment where the decisions are made by a central policy decision 143 point (PDP) [Q.3303.3], which needs the information generated by PCN 144 marking to support per-flow decisions on admission and termination. 145 This memo defines a Diameter application to transfer the information 146 from edge nodes to the PDP. Egress node reports are sent by the 147 egress node acting as client to the PDP acting as server. Data 148 generated at the ingress node are needed only when flow termination 149 is required. They are requested by the PDP acting as client and sent 150 in responses by the ingress node acting as server. The PDP thus acts 151 both as client and as server in the same application. The Rw 152 application [RFC5431] provides a precedent for such an application. 154 The PCN Data Collection application is related to existing ITU-T 155 applications as follows: 157 o The Rs application allows application-level functions to request 158 flow admission for individual application flows. 160 o The Rw application provides the control linkage between a Policy 161 Decision Point and an ingress router, to pass down decisions on 162 flow admission following either the push or the pull model. The 163 Rw application also passes flow termination decisions. 165 As can be seen from this brief description, the PCN Data Collection 166 application defined in this memo is complementary to the Rw 167 application. Within the strict terms of the ITU-T architecture, it 168 is a realization of a different interface, the Rc interface. 169 However, the PCN Data Collection application is intended for use in 170 any of a number of architectures based on a centralized policy 171 decision element. 173 3. Requirements Language 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119 [RFC2119]. 179 4. The Diameter PCN Data Collection Application 181 4.1. Advertising Application Support 183 Clients, servers, and proxies supporting the PCN Data Collection 184 application MUST advertise support by including the value in 185 the Auth-Application-Id of Congestion-Report-Request (CRR), 186 Congestion-Report-Answer (CRA), Measurement-Poll-Request (MPR), and 187 Measurement-Poll-Answer (MPA) messages. 189 4.2. Diameter Session Usage 191 Diameter sessions are implicitly terminated. An implicitly 192 terminated session is one for which the server does not maintain 193 state information. The client does not need to send any re- 194 authorization or session termination requests to the server. The 195 Diameter base protocol includes the Auth-Session-State AVP as the 196 mechanism for the implementation of implicitly terminated sessions. 197 The client (server) SHALL include in its requests (responses) the 198 Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as 199 described in RFC 3588 [RFC3588]. As a consequence, the server does 200 not maintain any state information about this session and the client 201 does not need to send any session termination request. Neither the 202 Authorization-Lifetime AVP nor the Session-Timeout AVP SHALL be 203 present in requests or responses. 205 4.3. Commands 207 The PCN Data Collection application defines four new commands, 208 Congestion-Report-Request(CRR), Congestion-Report-Answer(CRA), 209 Measurement-Poll-Request (MPR) and Measurement-Poll-Answer (MPA). 211 4.3.1. Congestion-Report-Request (CRR) Command 213 The egress node sends the Congestion-Report-Request (CRR) command, 214 indicated by the Command-Code field set to and the Command 215 Flags' 'R' bit set, to report when the congestion level estimate 216 (CLE) moves above or drops below the pre-congestion reporting 217 threshold, or when an excess flow condition is detected. Multiple 218 reports MAY be included in the same message, as described in 219 Section 4.5.2. 221 Message format: 223 ::= < Diameter Header: CC1, REQ, PXY > 224 < Session-Id > 225 { Auth-Application-Id } 226 { Auth-Session-State } 227 { Origin-Host } 228 { Origin-Realm } 229 { Destination-Realm } 230 [ Destination-Host ] 231 [ Event-Timestamp ] 232 * [ PCN-Congestion-Info ] 233 * [ PCN-Excess-Flow-Info ] 234 * [ Proxy-Info ] 235 * [ Route-Record ] 236 * [ AVP ] 238 At least one instance of the PCN-Congestion-Info or the PCN-Excess- 239 Flow-Info AVP MUST be present; the value of the Session-Id AVP MUST 240 be unique and SHOULD be set according to the recommendations in 241 Section 8.8 of RFC 3588. 243 4.3.2. Congestion-Report-Answer (CRA) Command 245 The PDP uses the Congestion-Report-Answer (CRA) command, indicated by 246 the Command-Code field set to and the Command Flags' 'R' bit 247 cleared, to acknowledge an Congestion-Report-Request command sent by 248 an egress node. The Congestion-Report-Answer command contains the 249 same Session-Id as the corresponding request. 251 Message format: 253 ::= < Diameter Header: CC2, PXY > 254 < Session-Id > 255 { Auth-Application-Id } 256 { Auth-Session-State } 257 { Result-Code } 258 { Origin-Host } 259 { Origin-Realm } 260 [ Error-Message ] 261 [ Error-Reporting-Host ] 262 [ Failed-AVP ] 263 [ Event-Timestamp ] 264 * [ Proxy-Info ] 265 * [ AVP ] 267 4.3.3. Measurement-Poll-Request (MPR) Command 269 The PDP sends the Measurement-Poll-Request (MPR) command, indicated 270 by the Command-Code field set to and the Command Flags' 'R' bit 271 set, to request that an ingress node report the rate at which PCN- 272 marked traffic has been forwarded to a given ingress-egress 273 aggregate, measured over a given measurement period as described in 274 Section 4.5.4. The value of the Session-Id AVP MUST be unique and 275 SHOULD be set according to the recommendations in Section 8.8 of RFC 276 3588. 278 Message format: 280 ::= < Diameter Header: CC3, REQ, PXY > 281 < Session-Id > 282 { Auth-Application-Id } 283 { Auth-Session-State } 284 { Origin-Host } 285 { Origin-Realm } 286 { Destination-Realm } 287 { I-E-Aggregate-Id } 288 [ Destination-Host ] 289 [ Event-Timestamp ] 290 * [ Proxy-Info ] 291 * [ Route-Record ] 292 * [ AVP ] 294 4.3.4. Measurement-Poll-Answer (MPA) Command 296 The ingress node sends the Measurement-Poll-Answer (MPA) command, 297 indicated by the Command-Code field set to and the Command 298 Flags' 'R' bit cleared, in response to an MPR sent by the PDP. 300 Message format: 302 ::= < Diameter Header: CC4, PXY > 303 < Session-Id > 304 { Auth-Application-Id } 305 { Auth-Session-State } 306 { Result-Code } 307 { Origin-Host } 308 { Origin-Realm } 309 { PCN-Sent-Info } 310 [ Error-Message ] 311 [ Error-Reporting-Host ] 312 [ Failed-AVP ] 313 [ Event-Timestamp ] 314 * [ Proxy-Info ] 315 * [ AVP ] 317 4.4. Attribute Value Pairs (AVPs) 319 This section describes the AVPs specific to the PCN Data Collection 320 application. The 'M' bit MUST be set and the 'V' bit MUST NOT be set 321 for all of these AVPs when used in the PCN Data Collection 322 application. 324 4.4.1. I-E-Aggregate-Id AVP 326 The I-E-Aggregate-Id AVP (AVP code ) is of type UTF8String. It 327 identifies a specific ingress-egress aggregate flow. The internal 328 structure of the I-E-Aggregate-Id value is network dependent. 330 4.4.2. PCN-Congestion-Info AVP 332 The PCN-Congestion-Info AVP (AVP code ) is of type Grouped. It 333 identifies an ingress-egress aggregate, reports the current value of 334 the congestion level estimate (CLE), and indicates whether the report 335 is generated because the CLE has risen above the reporting threshold 336 or because it has fallen below the reporting threshold. 338 The PCN-Congestion-Info AVP has the following format: 340 PCN-Congestion-Info ::= < AVP Header: AVP2 > 341 { I-E-Aggregate-Id } 342 { CLE-Value } 343 { CLE-Report-Reason } 344 * [ AVP ] 346 4.4.3. CLE-Value AVP 348 The CLE-Value AVP (AVP code ) is of type Float32. It gives the 349 current (smoothed) congestion level estimate as a fraction between 350 0.0 and 1.0. 352 4.4.4. CLE-Report-Reason AVP 354 The CLE-Report-Reason AVP (AVP code ) is of type Enumerated. 355 The following values are defined in this document: 357 PRECONGESTION_ONSET (0) 358 The current CLE (reported in CLE-Value) is above the configured 359 onset reporting threshold. The CLE derived in the previous 360 measurement period was below that threshold. 362 PRECONGESTION_END (1) The current CLE (reported in CLE-Value) is 363 below the configured end-of-precongestion reporting threshold, 364 which may have the same value as the onset reporting threshold. 365 The CLE derived in the previous measurement period was above that 366 threshold. 368 4.4.5. PCN-Excess-Flow-Info AVP 370 The PCN-Excess-Flow-Info AVP (AVP code ) is of type Grouped. 371 It identifies an ingress-egress aggregate, reports a rate of excess 372 traffic for that aggregate, and MAY identify a number of individual 373 flows within that aggregate that experienced the markings that led to 374 the generation of the PCN-Excess-Flow-Info AVP. Precise details of 375 the conditions under which this AVP is generated and how the 376 individual flows are selected are given in the specification for the 377 PCN edge behavior deployed in the domain. 379 The PCN-Excess-Flow-Info AVP has the following format: 381 PCN-Excess-Flow-Info ::= < AVP Header: AVP5 > 382 { I-E-Aggregate-Id } 383 { I-E-Aggregate-Excess-Rate } 384 * [ Flow Number ] 385 * [ Flow Description ] 386 * [ AVP ] 388 4.4.6. I-E-Aggregate-Excess-Rate AVP 390 The I-E-Aggregate-Excess-Rate AVP (AVP code ) is of type 391 Unsigned32. It gives the rate of flow of excess traffic in octets 392 per second that the egress node derived for the identified ingress- 393 egress aggregate for the measurement period ending at the time given 394 by the Event-Timestamp AVP (if present). 396 4.4.7. Flow-Number AVP 398 The Flow-Number AVP (Vendor code 10415, AVP code 509) 399 [ETSI-TS-129-209-V6.7.0] is of type Unsigned32, and it contains the 400 ordinal number of the IP flow(s). The rules for how the ordinal 401 number should be assigned are not described in this document. 403 4.4.8. Flow-Description AVP 405 The Flow-Description AVP (Vendor code 10415, AVP code 507) 406 [ETSI-TS-129-209-V6.7.0] is of type IPFilterRule, and defines a 407 packet filter for an IP flow with the following information: 409 o Direction (in or out). 411 o Source and destination IP address (possibly masked). 413 o Protocol. 415 o Source and destination port (list or ranges). 417 The b type SHALL be used with the following restrictions: 419 o Only the Action "permit" SHALL be used. 421 o No "options" SHALL be used. 423 o The invert modifier "!" for addresses SHALL not be used. 425 o The keyword "assigned" SHALL not be used. 427 The Flow-Description AVP SHALL be used to describe a single IP flow. 428 The direction "in" refers to uplink IP flows, and the direction "out" 429 refers to downlink IP flows. 431 4.4.9. PCN-Sent-Info AVP 433 The PCN-Sent-Info AVP (AVP code ) is of type Grouped. It 434 provides the rate of flow of PCN-marked traffic in octets per second 435 that the ingress node derived for the identified ingress-egress 436 aggregate for the measurement period ending at the time given by the 437 Event-Timestamp AVP (if present). 439 The PCN-Sent-Info AVP has the following format: 441 PCN-Sent-Info ::= < AVP Header: AVP7 > 442 { I-E-Aggregate-Id } 443 { I-E-Aggregate-Sent-Rate } 444 * [ AVP ] 446 4.4.10. I-E-Aggregate-Sent-Rate AVP 448 The I-E-Aggregate-Sent-Rate AVP (AVP code ) is of type 449 Unsigned32. It gives the rate of flow of PCN-marked traffic in 450 octets per second that the ingress node forwarded to the identified 451 ingress-egress aggregate, calculated for the measurement period 452 ending at the time given by the Event-Timestamp AVP (if present). 454 4.5. Procedures 456 The following subsections discuss the processing requirements placed 457 upon the various participating Diameter nodes by the PCN Data 458 Collection application. 460 4.5.1. Overall Procedures 462 The egress node measures the traffic from a particular ingress node, 463 and calculates the congestion level estimate(CLE) at the ingress- 464 egress aggregate level. The egress node may compare the CLE 465 calculated at the current interval with the CLE calculated at the 466 last interval, if the difference of the two CLEs exceeds a preset 467 range, the egress node sends the feedback information, including at 468 least the current CLE, to the PDP. After receiving the feedback 469 information, the PDP saves the it for admission control and flow 470 termination. After receiving a service flow request, the PDP can 471 determine whether to admit the request or not based on the feedback 472 information. Besides, the PDP also decides whether some of the 473 admitted flows need to be terminated. The PDP needs to signal to the 474 ingress node the decision about admission or termination. 476 4.5.2. Egress Node behavior 478 For each ingress-egress aggregate flow it serves, the egress node 479 meters received traffic for PCN markings, recomputes its smoothed 480 congestion level estimate, and determines whether there is excess 481 flow in successive measurement periods in accordance with the PCN 482 edge behavior specification deployed in the domain. When a change in 483 the smoothed congestion level estimate causes it to cross a reporting 484 threshold, either upward or downward, the egress node MUST send a 485 Congestion-Report-Request message to the PDP. Similarly, the egress 486 node MUST send a Congestion-Report-Request message to the PDP when 487 excess flow is detected for an ingress-egress aggregate served by 488 that node. 490 The Event-Timestamp AVP SHOULD be present, and SHOULD provide the 491 ending time of the measurement period from which the data triggering 492 the generation of the message were derived. At least one instance 493 either of the PCN-Congestion-Info or the PCN-Excess-Flow-Info AVP 494 MUST be present. Both AVPs MAY be present for the same ingress- 495 egress aggregate, if both apply according to the edge behavior 496 specification. Multiple instances of either AVP MAY be present, but 497 each instance MUST report on a different ingress-egress aggregate. 499 4.5.3. PDP behavior 501 If the PDP receives an Congestion-Report-Request (CRR) identified as 502 belonging to the PCN Data Collection application, it MUST acknowledge 503 the message with an Congestion-Report-Answer (CRA). The PDP usage of 504 the information provided by PCN-Congestion-Info and PCN-Excess-Flow- 505 Info AVPs is described in the applicable edge behavior specification. 507 When the PDP receives an CRR containing an PCN-Excess-Flow-Info AVP, 508 it MAY send a Measurement-Poll-Request (MPR) to the ingress node for 509 the aggregate concerned. The I-E-Aggregate-Id MUST identify the 510 ingress-egress aggregate flow for which information is being 511 requested. The Event-Timestamp MUST be present if it was present in 512 the CRR that contained the PCN-Excess-Flow-Info AVP, and MUST have 513 the same value. 515 If the PDP receives a successful Measurement-Poll-Answer message, it 516 uses the information contained in the PCN-Sent-Info AVP as described 517 in the applicable edge behavior specification. 519 4.5.4. Ingress Node behavior 521 When an ingress node receives an MPR, it MUST generate a Measurement- 522 Poll-Answer message containing an instance of the PCN-Sent-Info AVP. 523 The I-E-Aggregate-Id within the PCN-Sent-Info AVP MUST be the same as 524 received in the MPR, and the I-E-Aggregate-Sent-Rate MUST be a rate 525 measured for that aggregate. If Event-Timestamp is present in the 526 MPR, the measurement upon which I-E-Aggregate-Sent-Rate is based 527 SHOULD be that for the latest measurement period ending before or at 528 the time given by Event-Timestamp, if available. In any case, Event- 529 Timestamp SHOULD be present in the MPA, and if it is, MUST give the 530 end-time of the measurement period upon which I-E-Aggregate-Sent-Rate 531 is based. 533 5. IANA Considerations 535 Upon publication of this memo as an RFC, IANA is requested to assign 536 values as described in the following sections. 538 5.1. Diameter Application Identifier 540 An application identifier for Diameter PCN Data Collection (, 541 Section 4.1) must be assigned according to the policy specified in 542 Section 11.3 of RFC 3588. 544 5.2. Diameter Command Codes 546 Codes must be assigned for the following commands according to the 547 policy specified in RFC 3588, Section 11.2.1: 549 o Congestion-Report-Request (CRR) (, Section 4.3.1) 551 o Congestion-Report-Answer (MPA) (, Section 4.3.2) 553 o Measurement-Poll-Request (MPR) (, Section 4.3.3) 555 o Measurement-Poll-Answer (MPA) (, Section 4.3.4) 557 5.3. Attribute-Value Pairs 559 Codes must be assigned for the following AVPs using the policy 560 specified in RFC 3588, Section 11.1.1: 562 o I-E-Aggregate-Id (, Section 4.4.1) 564 o PCN-Congestion-Info (, Section 4.4.2) 566 o CLE-Value (, Section 4.4.3) 568 o CLE-Report-Reason (, Section 4.4.4) 570 o PCN-Excess-Flow-Info (, Section 4.4.5) 572 o I-E-Aggregate-Excess-Rate (, Section 4.4.6) 574 o PCN-Sent-Info (, Section 4.4.9) 576 o I-E-Aggregate-Sent-Rate (, Section 4.4.10) 578 6. Security Considerations 580 The following sections discuss the security threats against the 581 Diameter PCN Data Collection application and describe some 582 countermeasures. 584 6.1. Traffic Security 586 Application traffic MUST be secured as specified in RFC 3588 (i.e.,, 587 through the use of (preferably) TLS or IPsec). In the absence of 588 appropriate protection, all manner (including man-in-the-middle) of 589 attacks are possible, potentially resulting in the inappropriate 590 termination and non-admittance of flows. 592 6.2. Device Security 594 Compromise of an ingress node by an attacker could result in the 595 inappropriate refusal of admittance to valid flows, while the 596 compromise of an egress node could allow the termination of valid 597 flows. 599 Compromise of the PDP could result in both denial of admission to new 600 flows and termination of existing flows, enabling an attacker to 601 essentially control PCN traffic on the affected network. 603 7. References 605 7.1. Normative References 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, March 1997. 610 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 611 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 613 7.2. Informative References 615 [ETSI-TS-129-209-V6.7.0] 616 ETSI, "Universal Mobile Telecommunications System (UMTS); 617 Policy control over Gq interface (3GPP TS 29.209 version 618 6.7.0 Release 6)", ETSI TS 129.209 V6.7.0 (2007-06), 619 June 2007. 621 [Q.3303.3] 622 ITU-T, "Resource control protocol No. 3 -- Protocols at 623 the Rw interface between a policy decision physical entity 624 (PD-PE) and a policy enforcement physical entity (PE-PE): 626 Diameter", May 2008, 627 . 629 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 630 and W. Weiss, "An Architecture for Differentiated 631 Services", RFC 2475, December 1998. 633 [RFC5431] Sun, D., "Diameter ITU-T Rw Policy Enforcement Interface 634 Application", RFC 5431, March 2009. 636 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 637 Architecture", RFC 5559, June 2009. 639 Authors' Addresses 641 Fortune Huang 642 Huawei Technologies 643 Section F 644 Huawei Industrial Base 645 Bantian Longgang, Shenzhen 518129 646 P.R. China 648 Email: fqhuang@huawei.com 650 Tom Taylor 651 Huawei Technologies 652 1852 Lorraine Ave 653 Ottawa, Ontario K1H 6Z8 654 Canada 656 Phone: +1 613 680 2675 657 Email: tom.taylor@rogers.com 659 Glen Zorn (editor) 660 Network Zen 661 1310 East Thomas Street 662 #306 663 Seattle, Washington 98102 664 USA 666 Phone: +1 (206) 377-9035 667 Email: gwz@net-zen.net