idnits 2.17.1 draft-ietf-dime-congestion-flow-attributes-01.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 (October 2014) is 3478 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: April 30, 2014 B. Hirschman 6 October 2014 8 Diameter Congestion and Filter Attributes 9 draft-ietf-dime-congestion-flow-attributes-01.txt 11 Abstract 13 This document defines optional ECN and filter related attributes that 14 can be used for improved traffic identification, support of ECN and 15 minimized filter administration within Diameter. 17 RFC 5777 defines a Filter-Rule AVP that accommodates extensions for 18 classification, conditions and actions. It does not support traffic 19 identification for packets using Explicit Congestion Notification as 20 defined in RFC 3168 and does not provide specific actions when the 21 flow(s) described by the Filter-Rule are congested. 23 A Filter-Rule can describe multiple flows but not the exact number of 24 flows. Flow count and other associated data (e.g. packets) is not 25 captured in Accounting applications, leaving administrators without 26 useful information regarding the effectiveness or understanding of 27 the filter definition. 29 These optional attributes are forward and backwards compatible with 30 RFC 5777. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on February 14, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 68 3. ECN-IP-Codepoint, Congestion-Treatment and Filter Attributes . 4 69 3.1. ECN-IP-Codepoint AVP . . . . . . . . . . . . . . . . . . . 4 70 3.2. Congestion-Treatment AVP . . . . . . . . . . . . . . . . . 5 71 3.3. Flow-Count AVP . . . . . . . . . . . . . . . . . . . . . . 5 72 3.4. Packet-Count AVP . . . . . . . . . . . . . . . . . . . . . 5 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 6 75 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 5.1. Classifier Example . . . . . . . . . . . . . . . . . . . . 6 77 5.2. Diameter Credit Control (CC) with Congestion Information . 7 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 Two optional Explicit Congestion Notification (ECN) [RFC3168] related 87 AVPs are specified in the document. The first AVP provides direct 88 support for ECN [RFC3168] in the IP header and the second AVP 89 provides the ability to define alternate traffic treatment when 90 congestion is experienced. 92 This document also defines two optional AVPs, Flow-Count and Packet- 93 Count, used for conveying flow information within the Diameter 94 protocol [RFC6733]. These AVPs were found to be useful for a wide 95 range of applications. The AVPs provide a way to convey information 96 of the group of flows described by the Filter-Rule, IPFilterRule or 97 other Diameter traffic filters. 99 The semantics and encoding of all AVPs can be found in Section 3. 101 Such AVPs are, for example, needed by some ECN applications to 102 determine the number of flows congested or used by administrators to 103 determine the impact of filter definitions. 105 Additional parameters may be defined in future documents as the need 106 arises. All parameters are defined as Diameter-encoded Attribute 107 Value Pairs (AVPs), which are described using a modified version of 108 the Augmented Backus-Naur Form (ABNF), see [RFC6733]. The data types 109 are also taken from [RFC6733]. 111 2. Terminology and Abbreviations 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC2119 [RFC2119]. 117 3. ECN-IP-Codepoint, Congestion-Treatment and Filter Attributes 119 3.1. ECN-IP-Codepoint AVP 121 The ECN-IP-Codepoint AVP (AVP Code TBD) is of type Enumerated and 122 specifies the Explicit Congestion Notification codepoint values to 123 match in the IP header. 125 Value | Binary | Keyword | References 126 ----------------------------------------------------------------- 127 0 | 00 | Non-ECT (Not ECN-Capable Transport)| [RFC3168] 128 1 | 01 | ECT(1) (ECN-Capable Transport) | [RFC3168] 129 2 | 10 | ECT(0) (ECN-Capable Transport) | [RFC3168] 130 3 | 11 | CE (Congestion Experienced) | [RFC3168] 131 When this AVP is used for classification in the Filter-Rule it MUST 132 be part of Classifier Grouped AVP as defined in RFC5777. 134 3.2. Congestion-Treatment AVP 136 The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and 137 indicates how congested traffic, i.e., traffic that has Explicit 138 Congestion Notification Congestion Experienced marking set or some 139 other administratively defined criteria, is treated. In case the 140 Congestion-Treatment AVP is absent the treatment of the congested 141 traffic is left to the discretion of the node performing QoS 142 treatment. 144 Congestion-Treatment ::= < AVP Header: TBD > 145 { Treatment-Action } 146 [ QoS-Profile-Template ] 147 [ QoS-Parameters ] 148 * [ AVP ] 150 Treatment-Action, QoS-Profile-Template and QoS-Parameters are defined 151 in [RFC5777]. The Congestion-Treatment AVP is an action and MUST be 152 an attribute of the Filter-Rule Grouped AVP as defined in RFC5777. 154 3.3. Flow-Count AVP 156 The Flow-Count AVP (AVP Code TBD) is of type Unsigned64. 158 It indicates the number of protocol specific flows. The protocol is 159 determined by the filter (e.g. IPFilterRule, Filter-Id, etc.). 161 3.4. Packet-Count AVP 163 The Packet-Count AVP (AVP Code TBD) is of type Unsigned64. 165 It indicates the number of protocol specific packets. The protocol 166 is determined by the filter (e.g. IPFilterRule, Filter-Id, etc.). 168 4. IANA Considerations 170 4.1. AVP Codes 172 IANA allocated AVP codes in the IANA-controlled namespace registry 173 specified in Section 11.1.1 of [RFC6733] for the following AVPs that 174 are defined in this document. 176 +----------------------------------------------------------------+ 177 | AVP Section | 178 |AVP Code Defined Data Type | 179 +----------------------------------------------------------------+ 180 |ECN-IP-Codepoint TBD 3.1 Enumerated | 181 |Congestion-Treatment TBD 3.2 Grouped | 182 |Flow-Count TBD 3.3 Unsigned64 | 183 |Packet-Count TBD 3.4 Unsinged64 | 184 +----------------------------------------------------------------+ 186 5. Examples 188 The following examples illustrate the use of the AVPs defined in this 189 draft. 191 5.1. Classifier Example 193 The Classifier AVP (AVP Code 511) specified in RFC 5777 is a grouped 194 AVP that consists of a set of attributes that specify how to match a 195 packet. The addition of the ECN-IP-Codepoint is shown here. 197 Classifier ::= < AVP Header: 511 > 198 { Classifier-ID } 199 [ Protocol ] 200 [ Direction ] 201 [ ECP-IP-Codepoint ] 202 * [ From-Spec ] 203 * [ To-Spec ] 204 * [ Diffserv-Code-Point ] 205 [ Fragmentation-Flag ] 206 * [ IP-Option ] 207 * [ TCP-Option ] 208 [ TCP-Flags ] 209 * [ ICMP-Type ] 210 * [ ETH-Option ] 211 * [ AVP ] 213 Setting the ECP-IP-Codepoint value to 'CE' would permit the capture 214 of CE flags in the Flow. 216 Another Classifier with the ECP-IP-Codepoint value of 'ECT' could be 217 specified and, when coupled with the Flow-Count AVP, reports the 218 number of ECT capable flows. 220 5.2. Diameter Credit Control (CC) with Congestion Information 222 Diameter nodes using Charge Control can use the Congestion-Treatment 223 AVP to trigger specific actions when congestion occurs. This is 224 similar to the Excess-Treatment Action. The ability to detect when 225 congestion occurs is specific to the AVPs in the Filter-Rule and 226 Diameter Client and is no different than how 'Excess' can be 227 determined for Excess-Treatment. If Excess-Treatment or Congestion- 228 Treatment has occurred Diameter Clients may autonomously send CCRs 229 during the Service Delivery session as interim events. This is shown 230 in Figure 1. 232 Service Element 233 End User (CC Client) CC Server 234 | | | 235 |(1) Service Request | | 236 |-------------------->| | 237 | |(2) CCR (Initial, | 238 | | QoS-Resources(QoS-Desired)) | 239 | |--------------------------------->| 240 | |(3) CCA (Granted-Units, | 241 | | QoS-Resources(QoS-Authorized))| 242 | |<---------------------------------| 243 |(4) Service Delivery | | 244 |<------------------->| | 245 | (5) Congestion Detected | 246 | (6) Congestion Treatment Occurs | 247 | |(7) CCR (Termination, Used-Units, | 248 | | Flow-Count, Packet-Count, | 249 | | QoS-Resources(QoS-Delivered)) | 250 | |--------------------------------->| 251 | |(8) CCA | 252 | |<-------------------------------->| 253 | | | 254 | | | 255 |(9) End of Service | | 256 |-------------------->| | 257 | |(10)CCR (Termination, Used-Units, | 258 | | Flow-Count, Packet-Count, | 259 | | QoS-Resources(QoS-Delivered)) | 260 | |--------------------------------->| 261 | |(11) CCA | 262 | |<---------------------------------| 264 Figure 1: Example of a Diameter Credit Control with Congestion 265 Information 267 The 'Used-Service-Units' described in RFC5777 examples is customarily 268 a Service-Units, Time-Units or Byte-Count AVP. This is insufficient 269 to represent network state and does not differentiate between 270 throughput and good-put (good or quality throughput) even though the 271 filters may imply good or poor throughput. 273 Flow-Count and Packet-Count AVPs defined in this document could be 274 sent with a CCR when the triggering event is related to Congestion- 275 Treatment. This provides the CC Server with a better view of the 276 type of congested traffic for improved decision making and Charging. 277 Sending such AVPs under any condition permits rudimentary traffic 278 profiling regardless of network conditions. For instance, low byte 279 per packet counts is indicative of web traffic and high byte counts 280 per packet with a small number of flows may be indicative of video 281 traffic. Enriched reporting described here provides relief from Deep 282 Packet Inspection load and loss of information as traffic becomes 283 increasingly encrypted. 285 Some services, e.g. Streaming Services, limit the number of flows, 286 Flow-Count, as opposed to other Units, i.e. Byte-Count. In such a 287 case the Flow-Count AVP may be used in place of Service-Units. 289 6. Security Considerations 291 The document does not raise any new security concerns. This document 292 describes an extension of RFC5777 that introduces a new filter 293 parameter applied to ECN as defined by [RFC3168]. It also defines a 294 new Grouped AVP that expresses what action to take should congestion 295 be detected. The Grouped AVP reuses attributes defined in RFC5777. 297 The security considerations of the Diameter protocol itself have been 298 discussed in RFC 6733 [RFC6733]. Use of the AVPs defined in this 299 document MUST take into consideration the security issues and 300 requirements of the Diameter base protocol. 302 7. Acknowledgements 304 We would like to thank Avi Lior for his guidance and feedback during 305 the development of this specification. 307 8. References 308 8.1. Normative References 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 [RFC3168] Black, D., Floyd, S., and K. Ramakrishnan, "The Addition 314 of Explicit Congestion Notification (ECN) to IP", RFC 315 3168, September 2001. 317 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 318 "Diameter Base Protocol", RFC 6733, October 2012. 320 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Lior, A. 321 and Jones, M. Ed., "Traffic Classification and Quality of 322 Service (QoS) Attributes for Diameter", RFC 5777, February 323 2010. 325 Authors' Addresses 327 Lyle Bertz 328 Sprint 329 6220 Sprint Parkway 330 Overland Park, KS 66251 331 United States 333 EMail: lyleb551144@gmail.com 335 Serge Manning 336 Sprint 337 6220 Sprint Parkway 338 Overland Park, KS 66251 339 United States 341 EMail: sergem913@gmail.com 343 Brent Hirschman 345 EMail: Brent.Hirschman@gmail.com