idnits 2.17.1 draft-bertz-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 : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 2014) is 3694 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: 1 error (**), 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) B. Hirschman 3 Internet-Draft L. Bertz 4 Intended Status: Proposed Standard Sprint 5 Expires: August 11, 2014 February 2014 7 Diameter Congestion and Filter Attributes 8 draft-bertz-dime-congestion-flow-attributes-02.txt 10 Abstract 12 This document defines optional ECN and filter related attributes that 13 can be used for improved traffic identification, support of ECN and 14 minimized filter administration within Diameter. 16 RFC 5777 defines a Filter-Rule AVP that accommodates extensions for 17 classification, conditions and actions. It does not support traffic 18 identification for packets using Explicit Congestion Notification as 19 defined in RFC 3168 and does not provide specific actions when the 20 flow(s) described by the Filter-Rule are congested. 22 A Filter-Rule can describe multiple flows but not the exact number of 23 flows. Flow count and other associated data (e.g. packets) is not 24 captured in Accounting applications, leaving administrators without 25 useful information regarding the effectiveness or understanding of 26 the filter definition. 28 These optional attributes are forward and backwards compatible with 29 RFC 5777. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 14, 2014. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 66 3. ECN-IP-Codepoint, Congestion-Treatment and Filter Attributes . 4 67 3.1. ECN-IP-Codepoint AVP . . . . . . . . . . . . . . . . . . . 4 68 3.2. Congestion-Treatment AVP . . . . . . . . . . . . . . . . . 5 69 3.3. Flow-Count AVP . . . . . . . . . . . . . . . . . . . . . . 5 70 3.4. Packet-Count AVP . . . . . . . . . . . . . . . . . . . . . 5 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 72 4.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 5 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 79 1. Introduction 81 Two optional Explicit Congestion Notification (ECN) [RFC3168] related 82 AVPs are specified in the document. The first AVP provides direct 83 support for ECN [RFC3168] in the IP header and the second AVP 84 provides the ability to define alternate traffic treatment when 85 congestion is experienced. 87 This document also defines two optional AVPs, Flow-Count and Packet- 88 Count, used for conveying flow information within the Diameter 89 protocol [RFC6733]. These AVPs were found to be useful for a wide 90 range of applications. The AVPs provide a way to convey information 91 of the group of flows described by the Filter-Rule, IPFilterRule or 92 other Diameter traffic filters. 94 The semantics and encoding of all AVPs can be found in Section 3. 96 Such AVPs are, for example, needed by some ECN applications to 97 determine the number of flows congested or used by administrators to 98 determine the impact of filter definitions. 100 Additional parameters may be defined in future documents as the need 101 arises. All parameters are defined as Diameter-encoded Attribute 102 Value Pairs (AVPs), which are described using a modified version of 103 the Augmented Backus-Naur Form (ABNF), see [RFC6733]. The data types 104 are also taken from [RFC6733]. 106 2. Terminology and Abbreviations 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC2119 [RFC2119]. 112 3. ECN-IP-Codepoint, Congestion-Treatment and Filter Attributes 114 3.1. ECN-IP-Codepoint AVP 116 The ECN-IP-Codepoint AVP (AVP Code TBD) is of type Enumerated and 117 specifies the Explicit Congestion Notification codepoint values to 118 match in the IP header. 120 Value | Binary | Keyword | References 121 ----------------------------------------------------------------- 122 0 | 00 | Non-ECT (Not ECN-Capable Transport)| [RFC3168] 123 1 | 01 | ECT(1) (ECN-Capable Transport) | [RFC3168] 124 2 | 10 | ECT(0) (ECN-Capable Transport) | [RFC3168] 125 3 | 11 | CE (Congestion Experienced) | [RFC3168] 126 When this AVP is used for classification in the Filter-Rule it MUST 127 be part of Classifier Grouped AVP as defined in RFC5777. 129 3.2. Congestion-Treatment AVP 131 The Congestion-Treatment AVP (AVP Code TBD) is of type Grouped and 132 indicates how congested traffic, i.e., traffic that has Explicit 133 Congestion Notification Congestion Experienced marking set or some 134 other administratively defined criteria, is treated. In case the 135 Congestion-Treatment AVP is absent the treatment of the congested 136 traffic is left to the discretion of the node performing QoS 137 treatment. 139 Congestion-Treatment ::= < AVP Header: TBD > 140 { Treatment-Action } 141 [ QoS-Profile-Template ] 142 [ QoS-Parameters ] 143 * [ AVP ] 145 Treatment-Action, QoS-Profile-Template and QoS-Parameters are defined 146 in [RFC5777]. The Congestion-Treatment AVP is an action and MUST be 147 an attribute of the Filter-Rule Grouped AVP as defined in RFC5777. 149 3.3. Flow-Count AVP 151 The Flow-Count AVP (AVP Code TBD) is of type Unsigned64. 153 It indicates the number of protocol specific flows. The protocol is 154 determined by the filter (e.g. IPFilterRule, Filter-Id, etc.). 156 3.4. Packet-Count AVP 158 The Packet-Count AVP (AVP Code TBD) is of type Unsigned64. 160 It indicates the number of protocol specific packets. The protocol 161 is determined by the filter (e.g. IPFilterRule, Filter-Id, etc.). 163 4. IANA Considerations 165 4.1. AVP Codes 167 IANA allocated AVP codes in the IANA-controlled namespace registry 168 specified in Section 11.1.1 of [RFC6733] for the following AVPs that 169 are defined in this document. 171 +----------------------------------------------------------------+ 172 | AVP Section | 173 |AVP Code Defined Data Type | 174 +----------------------------------------------------------------+ 175 |ECN-IP-Codepoint TBD 3.1 Enumerated | 176 |Congestion-Treatment TBD 3.2 Grouped | 177 |Flow-Count TBD 3.3 Unsigned64 | 178 |Packet-Count TBD 3.4 Unsinged64 | 179 +----------------------------------------------------------------+ 181 5. Security Considerations 183 The document does not raise any new security concerns. This document 184 describes an extension of RFC5777 that introduces a new filter 185 parameter applied to ECN as defined by [RFC3168]. It also defines a 186 new Grouped AVP that expresses what action to take should congestion 187 be detected. The Grouped AVP reuses attributes defined in RFC5777. 189 The security considerations of the Diameter protocol itself have been 190 discussed in RFC 6733 [RFC6733]. Use of the AVPs defined in this 191 document MUST take into consideration the security issues and 192 requirements of the Diameter base protocol. 194 6. Acknowledgements 196 We would like to thank Avi Lior for his guidance and feedback during 197 the development of this specification. 199 7. References 200 7.1. Normative References 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, March 1997. 205 [RFC3168] Black, D., Floyd, S., and K. Ramakrishnan, "The Addition 206 of Explicit Congestion Notification (ECN) to IP", RFC 207 3168, September 2001. 209 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 210 "Diameter Base Protocol", RFC 6733, October 2012. 212 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Lior, A. 213 and Jones, M. Ed., "Traffic Classification and Quality of 214 Service (QoS) Attributes for Diameter", RFC 5777, February 215 2010. 217 Authors' Addresses 219 Lyle Bertz 220 Sprint 221 6220 Sprint Parkway 222 Overland Park, KS 66251 223 United States 225 EMail: Lyle.T.Bertz@sprint.com 227 Brent Hirschman 228 Sprint 229 6220 Sprint Parkway 230 Overland Park, KS 66251 231 United States 233 EMail: Brent.Hirschman@sprint.com