Diameter Congestion and Filter Attributes
Extracted elements (18)
Enriched reporting via Flow-Count and Packet-Count provides relief from Deep Packet Inspection load and loss of information as traffic becomes increasingly encrypted; for example, low byte counts per packet indicate web traffic while high byte counts with few flows indicate video traffic.
Flow-Count and Packet-Count AVPs were added because a Filter-Rule can describe multiple flows but not the exact number, and existing accounting AVPs (Bytes, Time, Service-Units) do not differentiate between throughput and good-put or provide flow-level granularity needed for congestion management decisions.
If an administrator can provide congestion actions without reporting them to a Diameter application, they should use the Congestion-Treatment AVP to also reduce Diameter traffic during congestion events, avoiding unnecessary signaling overhead.
RFC 5777 does not support traffic identification for ECN-marked packets (RFC 3168) and lacks specific actions for congested flows; this document fills that gap by adding ECN-IP-Codepoint for classification and Congestion-Treatment for congestion-specific actions while reusing existing RFC 5777 attributes.
In Diameter Credit Control, if conditions associated with Excess-Treatment or Congestion-Treatment have occurred, Diameter Clients may autonomously send Credit-Control Requests (CCRs) during the Service Delivery session as interim events, including Flow-Count and Packet-Count AVPs.
The optional attributes defined in this document are forward and backwards compatible with RFC 5777, as they extend the existing Filter-Rule AVP framework without modifying its structure.
When Congestion-Treatment AVP is absent, the treatment of congested traffic is left to the discretion of the node performing QoS treatment, providing a graceful fallback for nodes that do not support the new AVP.
The Congestion-Treatment AVP is an action and MUST be an attribute of the Filter-Rule Grouped AVP as defined in RFC 5777.
Use of the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter base protocol as discussed in RFC 6733.
When the ECN-IP-Codepoint AVP is used for classification in the Filter-Rule, it MUST be part of the Classifier Grouped AVP as defined in RFC 5777.
Flow-Count and Packet-Count AVPs provide more information that can be privacy sensitive, directly related to traffic captured by filters and associated reports. Narrow filtering creates the highest privacy sensitivity but is too resource-intensive to be widely applied on large networks.
The Congestion-Treatment AVP (AVP Code 629) is of type Grouped and indicates how to treat traffic IP 5-tuple flow(s) when congestion is detected, whether by CE codepoint reception or other administratively defined criteria. It contains a mandatory Treatment-Action and optional QoS-Profile-Template and QoS-Parameters.
The ECN-IP-Codepoint AVP (AVP Code 628) is of type Enumerated and specifies the ECN codepoint values to match in the IP header: 0 (Not-ECT), 1 (ECT(1)), 2 (ECT(0)), and 3 (CE - Congestion Experienced), as defined in RFC 3168.
The Flow-Count AVP (AVP Code 630) is of type Unsigned64 and indicates the number of protocol-specific flows, where the protocol is determined by the associated filter (e.g., IPFilterRule, Filter-Id).
The Packet-Count AVP (AVP Code 631) is of type Unsigned64 and indicates the number of protocol-specific packets, where the protocol is determined by the associated filter.
IANA allocated four AVP codes in the Diameter AVP codes namespace (RFC 6733 Section 11.1.1): ECN-IP-Codepoint (628, Enumerated), Congestion-Treatment (629, Grouped), Flow-Count (630, Unsigned64), and Packet-Count (631, Unsigned64).
The ECN-IP-Codepoint and Congestion-Treatment AVPs are extensions of RFC 5777 and reuse its attributes; as such they do not raise new security concerns beyond those already addressed in RFC 5777 and the Diameter base protocol (RFC 6733).
The Congestion-Treatment AVP wire format (AVP Code 629, Grouped) contains a required Treatment-Action field and optional QoS-Profile-Template and QoS-Parameters fields, plus extensible AVPs: `Congestion-Treatment ::= < AVP Header: 629 > { Treatment-Action } [ QoS-Profile-Template ] [ QoS-Parameters ] * [ AVP ]`.