From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7660.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc7660.txt (limited to 'doc/rfc/rfc7660.txt') diff --git a/doc/rfc/rfc7660.txt b/doc/rfc/rfc7660.txt new file mode 100644 index 0000000..06bea27 --- /dev/null +++ b/doc/rfc/rfc7660.txt @@ -0,0 +1,507 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Bertz +Request for Comments: 7660 S. Manning +Category: Standards Track Sprint +ISSN: 2070-1721 B. Hirschman + October 2015 + + + Diameter Congestion and Filter Attributes + +Abstract + + This document defines optional Diameter attributes that can be used + to help manage networks that use Explicit Congestion Notification + (ECN) or Diameter traffic filters. These new attributes allow for + improved data traffic identification, support of ECN, and minimal + Diameter filter administration. + + RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that + accommodates extensions for classification, conditions, and actions. + It, however, does not support traffic identification for packets + using Explicit Congestion Notification as defined in RFC 3168 and + does not provide specific actions when the flow(s) described by the + Filter-Rule are congested. + + Further, a Filter-Rule can describe multiple flows but not the exact + number of flows. Flow count and other associated data (e.g., + packets) are not captured by accounting applications, leaving + administrators without useful information regarding the effectiveness + or appropriateness of the filter definition. + + The optional attributes defined in this document are forward and + backwards compatible with RFC 5777. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7660. + + + + + +Bertz Standards Track [Page 1] + +RFC 7660 Congestion and Filter Attributes October 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. ECN-IP-Codepoint, Congestion-Treatment and Filter Attributes . 4 + 3.1. ECN-IP-Codepoint AVP . . . . . . . . . . . . . . . . . . . 4 + 3.2. Congestion-Treatment AVP . . . . . . . . . . . . . . . . . 4 + 3.3. Flow-Count AVP . . . . . . . . . . . . . . . . . . . . . . 5 + 3.4. Packet-Count AVP . . . . . . . . . . . . . . . . . . . . . 5 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5.1. Classifier Example . . . . . . . . . . . . . . . . . . . . 6 + 5.2. Diameter Credit Control (CC) with Congestion Information . 6 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 9 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 + + + + + + + + + + + + + + + + + + +Bertz Standards Track [Page 2] + +RFC 7660 Congestion and Filter Attributes October 2015 + + +1. Introduction + + Two optional AVPs related to Explicit Congestion Notification (ECN) + [RFC3168] are specified in this document. The first AVP provides + direct support for filtering ECN-marked traffic [RFC3168] and the + second AVP provides the ability to define alternate traffic treatment + when congestion is experienced. + + This document also defines two optional AVPs, Flow-Count and Packet- + Count, used for conveying flow information within the Diameter + protocol [RFC6733]. These AVPs were found to be useful for a wide + range of applications. The AVPs provide a way to convey information + of the group of flows described by the Filter-Rule, IPFilterRule, or + other Diameter traffic filters. + + The semantics and encoding of all AVPs can be found in Section 3. + + Such AVPs are, for example, needed by some congestion-management + functions to determine the number of flows congested or used by + administrators to determine the impact of filter definitions. + + Additional parameters may be defined in future documents as the need + arises. All parameters are defined as Diameter-encoded Attribute + Value Pairs (AVPs), which are described using a modified version of + the Augmented Backus-Naur Form (ABNF), see [RFC6733]. The data types + are also taken from [RFC6733]. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC2119 [RFC2119]. + + + + + + + + + + + + + + + + + + + +Bertz Standards Track [Page 3] + +RFC 7660 Congestion and Filter Attributes October 2015 + + +3. ECN-IP-Codepoint, Congestion-Treatment, and Filter Attributes + +3.1. ECN-IP-Codepoint AVP + + The ECN-IP-Codepoint AVP (AVP Code 628) is of type Enumerated and + specifies the ECN codepoint values to match in the IP header. + + Value | Binary | Keyword | References + ----------------------------------------------------------------- + 0 | 00 | Not-ECT (Not ECN-Capable Transport)| [RFC3168] + 1 | 01 | ECT(1) (ECN-Capable Transport) | [RFC3168] + 2 | 10 | ECT(0) (ECN-Capable Transport) | [RFC3168] + 3 | 11 | CE (Congestion Experienced) | [RFC3168] + + When this AVP is used for classification in the Filter-Rule, it MUST + be part of the Classifier Grouped AVP as defined in RFC 5777. + +3.2. Congestion-Treatment AVP + + The Congestion-Treatment AVP (AVP Code 629) is of type Grouped. It + indicates how to treat traffic IP (5-tuple) flow(s) when congestion + is detected. The detection of congestion can be based on the + reception of IP packets with the Congestion Experience (CE) codepoint + set (see [RFC3168]) or by any other administratively defined + criteria. + + A Filter-Rule may contain a Classifier that describes one or many + 5-tuples per RFC 5777. This treatment applies to all packets + associated to all 5-tuples (flows) captured by the Filter-Rule. + + If the Congestion-Treatment AVP is absent, the treatment of the + congested traffic is left to the discretion of the node performing + quality-of-service (QoS) treatment. + + Congestion-Treatment ::= < AVP Header: 629 > + { Treatment-Action } + [ QoS-Profile-Template ] + [ QoS-Parameters ] + * [ AVP ] + + Treatment-Action, QoS-Profile-Template, and QoS-Parameters are + defined in RFC 5777. The Congestion-Treatment AVP is an action and + MUST be an attribute of the Filter-Rule Grouped AVP as defined in RFC + 5777. + + + + + + + +Bertz Standards Track [Page 4] + +RFC 7660 Congestion and Filter Attributes October 2015 + + +3.3. Flow-Count AVP + + The Flow-Count AVP (AVP Code 630) is of type Unsigned64. + + It indicates the number of protocol-specific flows. The protocol is + determined by the filter (e.g., IPFilterRule, Filter-Id, etc.). + +3.4. Packet-Count AVP + + The Packet-Count AVP (AVP Code 631) is of type Unsigned64. + + It indicates the number of protocol-specific packets. The protocol + is determined by the filter (e.g., IPFilterRule, Filter-Id, etc.). + +4. IANA Considerations + +4.1. AVP Codes + + IANA allocated AVP codes in the IANA-controlled namespace registry + specified in Section 11.1.1 of [RFC6733] for the following AVPs that + are defined in this document. + + +------------------------------------------------------------------+ + | AVP Section | + |AVP Code Defined Data Type | + +------------------------------------------------------------------+ + |ECN-IP-Codepoint 628 3.1 Enumerated | + |Congestion-Treatment 629 3.2 Grouped | + |Flow-Count 630 3.3 Unsigned64 | + |Packet-Count 631 3.4 Unsigned64 | + +------------------------------------------------------------------+ + + + + + + + + + + + + + + + + + + + + +Bertz Standards Track [Page 5] + +RFC 7660 Congestion and Filter Attributes October 2015 + + +5. Examples + + The following examples illustrate the use of the AVPs defined in this + document. + +5.1. Classifier Example + + The Classifier AVP (AVP Code 511) specified in RFC 5777 is a grouped + AVP that consists of a set of attributes that specify how to match a + packet. The addition of the ECN-IP-Codepoint is shown here. + + Classifier ::= < AVP Header: 511 > + { Classifier-ID } + [ Protocol ] + [ Direction ] + [ ECN-IP-Codepoint ] + * [ From-Spec ] + * [ To-Spec ] + * [ Diffserv-Code-Point ] + [ Fragmentation-Flag ] + * [ IP-Option ] + * [ TCP-Option ] + [ TCP-Flags ] + * [ ICMP-Type ] + * [ ETH-Option ] + * [ AVP ] + + Setting the ECN-IP-Codepoint value to 'CE' would permit the capture + of CE flags in the Flow. + + Another Classifier with the ECN-IP-Codepoint value of 'ECT' could be + specified and, when coupled with the Flow-Count AVP, reports the + number of ECT-capable flows. + +5.2. Diameter Credit Control (CC) with Congestion Information + + Diameter nodes using Credit Control can use the Congestion-Treatment + AVP to trigger specific actions when congestion occurs. This is + similar to the Excess-Treatment Action. The ability to detect when + congestion occurs is specific to the AVPs in the Filter-Rule and + Diameter Client and is no different than how 'Excess' can be + determined for Excess-Treatment. If conditions associated with + Excess-Treatment [RFC5777] or Congestion-Treatment have occurred, + Diameter Clients may autonomously send Credit-Control Requests (CCRs) + during the Service Delivery session as interim events. This is shown + in Figure 1. + + + + + +Bertz Standards Track [Page 6] + +RFC 7660 Congestion and Filter Attributes October 2015 + + + Service Element + End User (CC Client) CC Server + | | | + |(1) Service Request | | + |-------------------->| | + | |(2) CCR (Initial, | + | | QoS-Resources(QoS-Desired)) | + | |--------------------------------->| + | |(3) CCA (Granted-Units, | + | | QoS-Resources(QoS-Authorized))| + | |<---------------------------------| + |(4) Service Delivery | | + |<------------------->| | + | (5) Congestion Detected | + | (6) Congestion Treatment Occurs | + | |(7) CCR (Termination, Used-Units, | + | | Flow-Count, Packet-Count, | + | | QoS-Resources(QoS-Delivered)) | + | |--------------------------------->| + | |(8) CCA | + | |<-------------------------------->| + | | | + | | | + |(9) End of Service | | + |-------------------->| | + | |(10)CCR (Termination, Used-Units, | + | | Flow-Count, Packet-Count, | + | | QoS-Resources(QoS-Delivered)) | + | |--------------------------------->| + | |(11) CCA | + | |<---------------------------------| + + Figure 1: Example of a Diameter Credit Control with + Congestion Information + + The 'Used-Service-Units' described in RFC 5777 examples is + customarily a Service-Units, Time-Units, or Byte-Count AVP. This is + insufficient to represent network state and does not differentiate + between throughput and good-put (good or quality throughput) even + though the filters may imply good or poor throughput. + + Flow-Count and Packet-Count AVPs defined in this document could be + sent with a CCR when the triggering event is related to Congestion- + Treatment. This provides the CC Server with a better view of the + type of congested traffic for improved decision making and charging. + Sending such AVPs under any condition permits rudimentary traffic + profiling regardless of network conditions. For instance, low byte + counts per packet is indicative of web traffic and high byte counts + + + +Bertz Standards Track [Page 7] + +RFC 7660 Congestion and Filter Attributes October 2015 + + + per packet with a small number of flows may be indicative of video + traffic. Enriched reporting described here provides relief from Deep + Packet Inspection load and loss of information as traffic becomes + increasingly encrypted. + + Some services, e.g., streaming services, limit the number of flows, + Flow-Count, as opposed to other units, i.e. Byte-Count. In such a + case, the Flow-Count AVP may be used in place of Service-Units. + +6. Security Considerations + + This document describes an extension of RFC 5777 that introduces a + new filter parameter applied to ECN as defined by [RFC3168]. It also + defines a new Grouped AVP that expresses what action to take should + congestion be detected. The Grouped AVP reuses attributes defined in + RFC 5777. As these are extensions to RFC 5777, they do not raise new + security concerns. + + The Flow-Count and Packet-Count AVPs can be provided in conjunction + with customary AVPs, e.g., Bytes, Time, Service units, during + accounting activities as described in the base protocol [RFC6733] or + other Diameter applications. These new AVPs provide more information + that can be privacy sensitive. The privacy sensitivity is directly + related to traffic captured by filters and associated reports. + Narrow filtering, which creates the highest level of privacy + sensitivity, is too resource intensive to be widely applied on large + networks. Paradoxically, improving reporting information lessens the + depth of inspection required to characterize traffic for many + congestion management activities as noted in Section 5.2. + + If an administrator can provide congestion actions without the need + to report them to a Diameter application, they should use the + Congestion-Treatment AVP, which also reduces Diameter traffic during + congestion events. + + The Security Considerations of the Diameter protocol itself have been + discussed in RFC 6733 [RFC6733]. Use of the AVPs defined in this + document MUST take into consideration the security issues and + requirements of the Diameter base protocol. + +7. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + + + + +Bertz Standards Track [Page 8] + +RFC 7660 Congestion and Filter Attributes October 2015 + + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", + RFC 3168, DOI 10.17487/RFC3168, September 2001, + . + + [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, + Ed., "Diameter Base Protocol", RFC 6733, + DOI 10.17487/RFC6733, October 2012, + . + + [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., + Ed., and A. Lior, "Traffic Classification and Quality of + Service (QoS) Attributes for Diameter", RFC 5777, + DOI 10.17487/RFC5777, February 2010, + . + +Acknowledgements + + We would like to thank Avi Lior for his guidance and feedback during + the development of this specification. + +Authors' Addresses + + Lyle Bertz + Sprint + 6220 Sprint Parkway + Overland Park, KS 66251 + United States + + Email: lyleb551144@gmail.com + + + Serge Manning + Sprint + 6220 Sprint Parkway + Overland Park, KS 66251 + United States + + Email: sergem913@gmail.com + + + Brent Hirschman + + Email: Brent.Hirschman@gmail.com + + + + + + + +Bertz Standards Track [Page 9] + -- cgit v1.2.3