idnits 2.17.00 (12 Aug 2021) /tmp/idnits23770/draft-ietf-dime-congestion-flow-attributes-02.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 2015) is 2495 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions (DIME) L. Bertz 3 Internet-Draft S. Manning 4 Intended Status: Proposed Standard Sprint 5 Expires: December 1, 2015 B. Hirschman 6 July 2015 8 Diameter Congestion and Filter Attributes 9 draft-ietf-dime-congestion-flow-attributes-02.txt 11 Abstract 13 This document defines optional Diameter attributes that can be used 14 to help manage networks that use Explicit Congestion Notification 15 (ECN) or Diameter traffic filters. These new attributes allow for 16 improved data traffic identification, support of ECN and minimize 17 Diameter filter administration. 19 RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that 20 accommodates extensions for classification, conditions and actions. 21 It however, does not support traffic identification for packets using 22 Explicit Congestion Notification as defined in RFC 3168 and does not 23 provide specific actions when the flow(s) described by the Filter- 24 Rule are congested. 26 Further, a Filter-Rule can describe multiple flows but not the exact 27 number of flows. Flow count and other associated data (e.g. packets) 28 are not captured by Accounting applications, leaving administrators 29 without useful information regarding the effectiveness or 30 appropriateness of the filter definition. 32 The optional attributes defined in this document are forward and 33 backwards compatible with RFC 5777. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on December 1, 2015. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 70 3. ECN-IP-Codepoint, Congestion-Treatment and Filter Attributes . 4 71 3.1. ECN-IP-Codepoint AVP . . . . . . . . . . . . . . . . . . . 4 72 3.2. Congestion-Treatment AVP . . . . . . . . . . . . . . . . . 5 73 3.3. Flow-Count AVP . . . . . . . . . . . . . . . . . . . . . . 5 74 3.4. Packet-Count AVP . . . . . . . . . . . . . . . . . . . . . 5 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 4.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 6 77 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 5.1. Classifier Example . . . . . . . . . . . . . . . . . . . . 6 79 5.2. Diameter Credit Control (CC) with Congestion Information . 7 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 86 1. Introduction 88 Two optional Explicit Congestion Notification (ECN) [RFC3168] related 89 AVPs are specified in this document. The first AVP provides direct 90 support for filtering ECN marked traffic [RFC3168] and the second AVP 91 provides the ability to define alternate traffic treatment when 92 congestion is experienced. 94 This document also defines two optional AVPs, Flow-Count and Packet- 95 Count, used for conveying flow information within the Diameter 96 protocol [RFC6733]. These AVPs were found to be useful for a wide 97 range of applications. The AVPs provide a way to convey information 98 of the group of flows described by the Filter-Rule, IPFilterRule or 99 other Diameter traffic filters. 101 The semantics and encoding of all AVPs can be found in Section 3. 103 Such AVPs are, for example, needed by some congestion management 104 functions to determine the number of flows congested or used by 105 administrators to determine the impact of filter definitions. 107 Additional parameters may be defined in future documents as the need 108 arises. All parameters are defined as Diameter-encoded Attribute 109 Value Pairs (AVPs), which are described using a modified version of 110 the Augmented Backus-Naur Form (ABNF), see [RFC6733]. The data types 111 are also taken from [RFC6733]. 113 2. Terminology and Abbreviations 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC2119 [RFC2119]. 119 3. ECN-IP-Codepoint, Congestion-Treatment and Filter Attributes 121 3.1. ECN-IP-Codepoint AVP 123 The ECN-IP-Codepoint AVP (AVP Code TBD1) is of type Enumerated and 124 specifies the Explicit Congestion Notification codepoint values to 125 match in the IP header. 127 Value | Binary | Keyword | References 128 ----------------------------------------------------------------- 129 0 | 00 | Non-ECT (Not ECN-Capable Transport)| [RFC3168] 130 1 | 01 | ECT(1) (ECN-Capable Transport) | [RFC3168] 131 2 | 10 | ECT(0) (ECN-Capable Transport) | [RFC3168] 132 3 | 11 | CE (Congestion Experienced) | [RFC3168] 133 When this AVP is used for classification in the Filter-Rule it MUST 134 be part of Classifier Grouped AVP as defined in RFC5777. 136 3.2. Congestion-Treatment AVP 138 The Congestion-Treatment AVP (AVP Code TBD2) is of type Grouped. It 139 indicates how to treat traffic IP (5-tuple) flow(s) when congestion 140 is detected. The detection of congestion can be based on the 141 reception of IP packets with the Congestion Experience (CE) codepoint 142 set (see [RFC3168]) or by any other administratively defined 143 criteria. 145 A Filter-Rule may contain a Classifier that describes one or many 5- 146 tuples per RFC5777. This treatment applies to all packets associated 147 to all 5-tuples (flows) captured by the Filter-Rule. 149 If the Congestion-Treatment AVP is absent the treatment of the 150 congested traffic is left to the discretion of the node performing 151 QoS treatment. 153 Congestion-Treatment ::= < AVP Header: TBD2 > 154 { Treatment-Action } 155 [ QoS-Profile-Template ] 156 [ QoS-Parameters ] 157 * [ AVP ] 159 Treatment-Action, QoS-Profile-Template and QoS-Parameters are defined 160 in RFC5777. The Congestion-Treatment AVP is an action and MUST be an 161 attribute of the Filter-Rule Grouped AVP as defined in RFC5777. 163 3.3. Flow-Count AVP 165 The Flow-Count AVP (AVP Code TBD3) is of type Unsigned64. 167 It indicates the number of protocol specific flows. The protocol is 168 determined by the filter (e.g. IPFilterRule, Filter-Id, etc.). 170 3.4. Packet-Count AVP 172 The Packet-Count AVP (AVP Code TBD4) is of type Unsigned64. 174 It indicates the number of protocol specific packets. The protocol 175 is determined by the filter (e.g. IPFilterRule, Filter-Id, etc.). 177 4. IANA Considerations 179 4.1. AVP Codes 181 IANA allocated AVP codes in the IANA-controlled namespace registry 182 specified in Section 11.1.1 of [RFC6733] for the following AVPs that 183 are defined in this document. 185 +----------------------------------------------------------------+ 186 | AVP Section | 187 |AVP Code Defined Data Type | 188 +----------------------------------------------------------------+ 189 |ECN-IP-Codepoint TBD1 3.1 Enumerated | 190 |Congestion-Treatment TBD2 3.2 Grouped | 191 |Flow-Count TBD3 3.3 Unsigned64 | 192 |Packet-Count TBD4 3.4 Unsinged64 | 193 +----------------------------------------------------------------+ 195 5. Examples 197 The following examples illustrate the use of the AVPs defined in this 198 draft. 200 5.1. Classifier Example 202 The Classifier AVP (AVP Code 511) specified in RFC5777 is a grouped 203 AVP that consists of a set of attributes that specify how to match a 204 packet. The addition of the ECN-IP-Codepoint is shown here. 206 Classifier ::= < AVP Header: 511 > 207 { Classifier-ID } 208 [ Protocol ] 209 [ Direction ] 210 [ ECN-IP-Codepoint ] 211 * [ From-Spec ] 212 * [ To-Spec ] 213 * [ Diffserv-Code-Point ] 214 [ Fragmentation-Flag ] 215 * [ IP-Option ] 216 * [ TCP-Option ] 217 [ TCP-Flags ] 218 * [ ICMP-Type ] 219 * [ ETH-Option ] 220 * [ AVP ] 222 Setting the ECN-IP-Codepoint value to 'CE' would permit the capture 223 of CE flags in the Flow. 225 Another Classifier with the ECN-IP-Codepoint value of 'ECT' could be 226 specified and, when coupled with the Flow-Count AVP, reports the 227 number of ECT capable flows. 229 5.2. Diameter Credit Control (CC) with Congestion Information 231 Diameter nodes using Credit Control can use the Congestion-Treatment 232 AVP to trigger specific actions when congestion occurs. This is 233 similar to the Excess-Treatment Action. The ability to detect when 234 congestion occurs is specific to the AVPs in the Filter-Rule and 235 Diameter Client and is no different than how 'Excess' can be 236 determined for Excess-Treatment. If conditions associated with 237 Excess-Treatment [RFC5777] or Congestion-Treatment has occurred 238 Diameter Clients may autonomously send Credit Control Requests (CCRs) 239 during the Service Delivery session as interim events. This is shown 240 in Figure 1. 242 Service Element 243 End User (CC Client) CC Server 244 | | | 245 |(1) Service Request | | 246 |-------------------->| | 247 | |(2) CCR (Initial, | 248 | | QoS-Resources(QoS-Desired)) | 249 | |--------------------------------->| 250 | |(3) CCA (Granted-Units, | 251 | | QoS-Resources(QoS-Authorized))| 252 | |<---------------------------------| 253 |(4) Service Delivery | | 254 |<------------------->| | 255 | (5) Congestion Detected | 256 | (6) Congestion Treatment Occurs | 257 | |(7) CCR (Termination, Used-Units, | 258 | | Flow-Count, Packet-Count, | 259 | | QoS-Resources(QoS-Delivered)) | 260 | |--------------------------------->| 261 | |(8) CCA | 262 | |<-------------------------------->| 263 | | | 264 | | | 265 |(9) End of Service | | 266 |-------------------->| | 267 | |(10)CCR (Termination, Used-Units, | 268 | | Flow-Count, Packet-Count, | 269 | | QoS-Resources(QoS-Delivered)) | 270 | |--------------------------------->| 271 | |(11) CCA | 272 | |<---------------------------------| 274 Figure 1: Example of a Diameter Credit Control with Congestion 275 Information 277 The 'Used-Service-Units' described in RFC5777 examples is customarily 278 a Service-Units, Time-Units or Byte-Count AVP. This is insufficient 279 to represent network state and does not differentiate between 280 throughput and good-put (good or quality throughput) even though the 281 filters may imply good or poor throughput. 283 Flow-Count and Packet-Count AVPs defined in this document could be 284 sent with a CCR when the triggering event is related to Congestion- 285 Treatment. This provides the CC Server with a better view of the 286 type of congested traffic for improved decision making and charging. 287 Sending such AVPs under any condition permits rudimentary traffic 288 profiling regardless of network conditions. For instance, low byte 289 per packet counts is indicative of web traffic and high byte counts 290 per packet with a small number of flows may be indicative of video 291 traffic. Enriched reporting described here provides relief from Deep 292 Packet Inspection load and loss of information as traffic becomes 293 increasingly encrypted. 295 Some services, e.g. Streaming Services, limit the number of flows, 296 Flow-Count, as opposed to other Units, i.e. Byte-Count. In such a 297 case the Flow-Count AVP may be used in place of Service-Units. 299 6. Security Considerations 301 This document describes an extension of RFC5777 that introduces a new 302 filter parameter applied to ECN as defined by [RFC3168]. It also 303 defines a new Grouped AVP that expresses what action to take should 304 congestion be detected. The Grouped AVP reuses attributes defined in 305 RFC5777. As these are extensions to RFC 5777, they do not raise new 306 security concerns. 308 The Flow-Count and Packet-Count AVPs can be provided in conjunction 309 with customary AVPs, e.g. Bytes, Time, Service Units, during 310 Accounting activities as described in the base protocol [RFC6733] or 311 other Diameter applications. These new AVPs provide more information 312 that can be privacy sensitive. The privacy sensitivity is directly 313 related to traffic captured by Filters and associated reports. 314 Narrow filtering, which creates the highest level of privacy 315 sensitivity, is too resource intensive to be widely applied on large 316 networks. Paradoxically, improving reporting information lessens the 317 depth of inspection required to characterize traffic for many 318 congestion management activities as noted in Section 5.2. 320 If an administrator can provide congestion actions without the need 321 to report them to a Diameter application they should use the 322 Congestion-Treatment AVP which also reduces Diameter traffic during 323 congestion events. 325 The security considerations of the Diameter protocol itself have been 326 discussed in RFC 6733 [RFC6733]. Use of the AVPs defined in this 327 document MUST take into consideration the security issues and 328 requirements of the Diameter base protocol. 330 7. Acknowledgements 332 We would like to thank Avi Lior for his guidance and feedback during 333 the development of this specification. 335 8. References 336 8.1. Normative References 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC3168] Black, D., Floyd, S., and K. Ramakrishnan, "The Addition 342 of Explicit Congestion Notification (ECN) to IP", RFC 343 3168, September 2001. 345 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 346 "Diameter Base Protocol", RFC 6733, October 2012. 348 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Lior, A. 349 and Jones, M. Ed., "Traffic Classification and Quality of 350 Service (QoS) Attributes for Diameter", RFC 5777, February 351 2010. 353 Authors' Addresses 355 Lyle Bertz 356 Sprint 357 6220 Sprint Parkway 358 Overland Park, KS 66251 359 United States 361 EMail: lyleb551144@gmail.com 363 Serge Manning 364 Sprint 365 6220 Sprint Parkway 366 Overland Park, KS 66251 367 United States 369 EMail: sergem913@gmail.com 371 Brent Hirschman 373 EMail: Brent.Hirschman@gmail.com