doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

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,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc3168>.
+
+   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
+              Ed., "Diameter Base Protocol", RFC 6733,
+              DOI 10.17487/RFC6733, October 2012,
+              <http://www.rfc-editor.org/info/rfc6733>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc5777>.
+
+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]
+