< draft-ietf-dime-ovli-06.txt   draft-ietf-dime-ovli-07.txt >
Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed. Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed.
Internet-Draft Broadcom Internet-Draft Broadcom
Intended status: Standards Track S. Donovan, Ed. Intended status: Standards Track S. Donovan, Ed.
Expires: July 12, 2015 B. Campbell Expires: July 30, 2015 B. Campbell
Oracle Oracle
L. Morand L. Morand
Orange Labs Orange Labs
January 8, 2015 January 26, 2015
Diameter Overload Indication Conveyance Diameter Overload Indication Conveyance
draft-ietf-dime-ovli-06.txt draft-ietf-dime-ovli-07.txt
Abstract Abstract
This specification defines a base solution for Diameter overload This specification defines a base solution for Diameter overload
control, referred to as Diameter Overload Indication Conveyance control, referred to as Diameter Overload Indication Conveyance
(DOIC). (DOIC).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 12, 2015. This Internet-Draft will expire on July 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
4.5. Simplified Example Architecture . . . . . . . . . . . . . 11 4.5. Simplified Example Architecture . . . . . . . . . . . . . 11
5. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 12 5. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 12
5.1. Capability Announcement . . . . . . . . . . . . . . . . . 12 5.1. Capability Announcement . . . . . . . . . . . . . . . . . 12
5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 13 5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 13
5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 13 5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 13
5.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 14 5.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 14
5.2. Overload Report Processing . . . . . . . . . . . . . . . 15 5.2. Overload Report Processing . . . . . . . . . . . . . . . 15
5.2.1. Overload Control State . . . . . . . . . . . . . . . 15 5.2.1. Overload Control State . . . . . . . . . . . . . . . 15
5.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 19 5.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 19
5.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 20 5.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 20
5.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 21 5.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 22
6. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 22 6. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 23 6.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 23
6.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 24 6.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 24
7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 24 7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 24
7.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 25 7.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 25
7.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 25 7.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 25
7.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 25 7.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 25
7.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 26 7.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 26
7.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 26 7.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 26
7.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 26 7.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 26
7.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 27 7.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 27
7.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27 7.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27
8. Error Response Codes . . . . . . . . . . . . . . . . . . . . 28 8. Error Response Codes . . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. New registries . . . . . . . . . . . . . . . . . . . . . 28 9.2. New registries . . . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 29 10.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 30
10.2. Denial of Service Attacks . . . . . . . . . . . . . . . 31 10.2. Denial of Service Attacks . . . . . . . . . . . . . . . 31
10.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . 31 10.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . 31
10.4. End-to End-Security Issues . . . . . . . . . . . . . . . 31 10.4. End-to End-Security Issues . . . . . . . . . . . . . . . 32
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Issues left for future specifications . . . . . . . 34 Appendix A. Issues left for future specifications . . . . . . . 34
A.1. Additional traffic abatement algorithms . . . . . . . . . 34 A.1. Additional traffic abatement algorithms . . . . . . . . . 34
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 34 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 34
A.3. New Error Diagnostic AVP . . . . . . . . . . . . . . . . 34 A.3. New Error Diagnostic AVP . . . . . . . . . . . . . . . . 34
Appendix B. Deployment Considerations . . . . . . . . . . . . . 34 Appendix B. Deployment Considerations . . . . . . . . . . . . . 34
Appendix C. Requirements Conformance Analysis . . . . . . . . . 35 Appendix C. Requirements Conformance Analysis . . . . . . . . . 35
skipping to change at page 4, line 22 skipping to change at page 4, line 22
2. Terminology and Abbreviations 2. Terminology and Abbreviations
Abatement Abatement
Reaction to receipt of an overload report resulting in a reduction Reaction to receipt of an overload report resulting in a reduction
in traffic sent to the reporting node. Abatement actions include in traffic sent to the reporting node. Abatement actions include
diversion and throttling. diversion and throttling.
Abatement Algorithm Abatement Algorithm
An extensible mechanism requested by reporting nodes and used by An extensible method requested by reporting nodes and used by
reacting nodes to reduce the amount of traffic sent during an reacting nodes to reduce the amount of traffic sent during an
occurrence of overload control. occurrence of overload control.
Diversion Diversion
An overload abatement mechanism, where the reacting node selects An overload abatement treatment where the reacting node selects
alternate destinations or paths for for requests. alternate destinations or paths for requests.
Host-Routed Requests Host-Routed Requests
Requests that a reacting node knows will be served by a particular Requests that a reacting node knows will be served by a particular
host, either due to the presence of a Destination-Host AVP, or by host, either due to the presence of a Destination-Host AVP, or by
some other local knowledge on the part of the reacting node. some other local knowledge on the part of the reacting node.
Overload Control State (OCS) Overload Control State (OCS)
Internal state maintained by a reporting or reacting node Internal state maintained by a reporting or reacting node
skipping to change at page 5, line 14 skipping to change at page 5, line 14
Requests that a reacting node does not know which host will Requests that a reacting node does not know which host will
service the request. service the request.
Reporting Node Reporting Node
A Diameter node that generates an overload report. (This may or A Diameter node that generates an overload report. (This may or
may not be the overloaded node.) may not be the overloaded node.)
Throttling Throttling
A mechanism for overload abatement that limits the number of An abatement treatment that limits the number of requests sent by
requests sent by the DIOC reacting node. Throttling can include a the DIOC reacting node. Throttling can include a Diameter Client
Diameter Client choosing to not send requests, or a Diameter Agent choosing to not send requests, or a Diameter Agent or Server
or Server rejecting requests with appropriate error responses. In rejecting requests with appropriate error responses. In both
both cases the result of the throttling is a permanent rejection cases the result of the throttling is a permanent rejection of the
of the transaction. transaction.
3. Conventions Used in This Document 3. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
RFC 2119 [RFC2119] interpretation does not apply for the above listed
words when they are not used in all-caps format.
4. Solution Overview 4. Solution Overview
The Diameter Overload Information Conveyance (DOIC) solution allows The Diameter Overload Information Conveyance (DOIC) solution allows
Diameter nodes to request other Diameter nodes to perform overload Diameter nodes to request other Diameter nodes to perform overload
abatement actions, that is, actions to reduce the load offered to the abatement actions, that is, actions to reduce the load offered to the
overloaded node or realm. overloaded node or realm.
A Diameter node that supports DOIC is known as a "DOIC node". Any A Diameter node that supports DOIC is known as a "DOIC node". Any
Diameter node can act as a DOIC node, including Diameter Clients, Diameter node can act as a DOIC node, including Diameter Clients,
Diameter Servers, and Diameter Agents. DOIC nodes are further Diameter Servers, and Diameter Agents. DOIC nodes are further
skipping to change at page 8, line 49 skipping to change at page 9, line 5
requested. requested.
Note that the loss algorithm defined in this document is a Note that the loss algorithm defined in this document is a
stateless abatement algorithm. As a result it does not require stateless abatement algorithm. As a result it does not require
any actions by reacting nodes prior to the receipt of an overload any actions by reacting nodes prior to the receipt of an overload
report. Stateful abatement algorithms that base the abatement report. Stateful abatement algorithms that base the abatement
logic on a history of request messages sent might require reacting logic on a history of request messages sent might require reacting
nodes to maintain state in advance of receiving an overload report nodes to maintain state in advance of receiving an overload report
to ensure that the overload reports can be properly handled. to ensure that the overload reports can be properly handled.
Reporting nodes can change the overload abatement algorithm indicated
in the OC-Feature-Vector AVP if the reporting node is not currently
in an overload condition and sending overload reports. The reporting
node is not allowed to change the overload abatement algorithm while
the reporting node is in an overload condition.
The DCA mechanism must also allow the scenario where the set of The DCA mechanism must also allow the scenario where the set of
features supported by the sender of a request and by agents in the features supported by the sender of a request and by agents in the
path of a request differ. In this case, the agent can update the OC- path of a request differ. In this case, the agent can update the OC-
Supported-Features AVP to reflect the mixture of the two sets of Supported-Features AVP to reflect the mixture of the two sets of
supported features. supported features.
Note: The logic to determine if the content of the OC-Supported- Note: The logic to determine if the content of the OC-Supported-
Features AVP should be changed is out-of-scope for this document, Features AVP should be changed is out-of-scope for this document,
as is the logic to determine the content of a modified OC- as is the logic to determine the content of a modified OC-
Supported-Features AVP. These are left to implementation Supported-Features AVP. These are left to implementation
skipping to change at page 10, line 17 skipping to change at page 10, line 15
Note: Known issues exist if multiple sources for overload reports Note: Known issues exist if multiple sources for overload reports
which apply to the same Diameter entity exist. Reacting nodes which apply to the same Diameter entity exist. Reacting nodes
have no way of determining the source and, as such, will treat have no way of determining the source and, as such, will treat
them as coming from a single source. Variance in sequence numbers them as coming from a single source. Variance in sequence numbers
between the two sources can then cause incorrect overload between the two sources can then cause incorrect overload
abatement treatment to be applied for indeterminate periods of abatement treatment to be applied for indeterminate periods of
time. time.
Reporting nodes are responsible for determining the need for a Reporting nodes are responsible for determining the need for a
reduction of traffic. The method for making this determination is reduction of traffic. The method for making this determination is
implementation specific and depend on the type of overload report implementation specific and depends on the type of overload report
being generated. A host-report might be generated by tracking use of being generated. A host-report might be generated by tracking use of
resources required by the host to handle transactions for the resources required by the host to handle transactions for the
Diameter application. A realm-report generally impacts the traffic Diameter application. A realm-report generally impacts the traffic
sent to multiple hosts and, as such, requires tracking the capacity sent to multiple hosts and, as such, requires tracking the capacity
of all servers able to handle realm- routed requests for the of all servers able to handle realm-routed requests for the
application and realm. application and realm.
Once a reporting node determines the need for a reduction in traffic, Once a reporting node determines the need for a reduction in traffic,
it uses the DOIC defined AVPs to report on the condition. These AVPs it uses the DOIC defined AVPs to report on the condition. These AVPs
are included in answer messages sent or relayed by the reporting are included in answer messages sent or relayed by the reporting
node. The reporting node indicates the overload abatement algorithm node. The reporting node indicates the overload abatement algorithm
that is to be used to handle the traffic reduction in the OC- that is to be used to handle the traffic reduction in the OC-
Supported-Features AVP. The OC-OLR AVP is used to communicate Supported-Features AVP. The OC-OLR AVP is used to communicate
information about the requested reduction. information about the requested reduction.
Reacting nodes, upon receipt of an overload report, applying the Reacting nodes, upon receipt of an overload report, apply the
overload abatement algorithm to traffic impacted by the overload overload abatement algorithm to traffic impacted by the overload
report. The method used to determine the requests that are to report. The method used to determine the requests that are to
receive overload abatement treatment is dependent on the abatement receive overload abatement treatment is dependent on the abatement
algorithm. The loss abatement algorithm is defined in this document algorithm. The loss abatement algorithm is defined in this document
(Section 6). Other abatement algorithms can be defined in extensions (Section 6). Other abatement algorithms can be defined in extensions
to the DOIC solutions. to the DOIC solution.
Two types of overload abatement treatment are defined, diversion and Two types of overload abatement treatment are defined, diversion and
throttling. Reacting nodes are responsible for determining which throttling. Reacting nodes are responsible for determining which
treatment is appropriate for individual requests. treatment is appropriate for individual requests.
As the conditions that lead to the generation of the overload report As the conditions that lead to the generation of the overload report
change the reporting node can send new overload reports requesting change the reporting node can send new overload reports requesting
greater reduction if the condition gets worse or less reduction if greater reduction if the condition gets worse or less reduction if
the condition improves. The reporting node sends an overload report the condition improves. The reporting node sends an overload report
with a duration of zero to indicate that the overload condition has with a duration of zero to indicate that the overload condition has
skipping to change at page 11, line 27 skipping to change at page 11, line 23
definition of new report types and the definition of new scopes of definition of new report types and the definition of new scopes of
messages impacted by an overload report. messages impacted by an overload report.
A DOIC node communicates supported features by including them in the A DOIC node communicates supported features by including them in the
OC-Feature-Vector AVP, as a sub-AVP of OC-Supported-Features. Any OC-Feature-Vector AVP, as a sub-AVP of OC-Supported-Features. Any
non-backwards compatible DOIC extensions define new values for the non-backwards compatible DOIC extensions define new values for the
OC-Feature-Vector AVP. DOIC extensions also have the ability to add OC-Feature-Vector AVP. DOIC extensions also have the ability to add
new AVPs to the OC-Supported-Features AVP, if additional information new AVPs to the OC-Supported-Features AVP, if additional information
about the new feature is required. about the new feature is required.
Overload reports can be also extended by adding new sub-AVPs to the Overload reports can also be extended by adding new sub-AVPs to the
OC-OLR AVP, allowing reporting nodes to communicate additional OC-OLR AVP, allowing reporting nodes to communicate additional
information about handling an overload condition. information about handling an overload condition.
If necessary, new extensions can also define new AVPs that are not If necessary, new extensions can also define new AVPs that are not
part of the OC-Supported-Features and OC-OLR group AVPs. It is, part of the OC-Supported-Features and OC-OLR group AVPs. It is,
however, recommended that DOIC extensions use the OC-Supported- however, recommended that DOIC extensions use the OC-Supported-
Features AVP and OC-OLR AVP to carry all DOIC related AVPs. Features AVP and OC-OLR AVP to carry all DOIC related AVPs.
4.5. Simplified Example Architecture 4.5. Simplified Example Architecture
Figure 1 illustrates the simplified architecture for Diameter Figure 1 illustrates the simplified architecture for Diameter
overload information conveyance. overload information conveyance.
Realm X Same or other Realms Realm X Same or other Realms
<--------------------------------------> <----------------------> <--------------------------------------> <---------------------->
+--^-----+ : (optional) : +--------+ : (optional) :
|Diameter| : : |Diameter| : :
|Server A|--+ .--. : +---^----+ : .--. |Server A|--+ .--. : +--------+ : .--.
+--------+ | _( `. : |Diameter| : _( `. +---^----+ +--------+ | _( `. : |Diameter| : _( `. +--------+
+--( )--:-| Agent |-:--( )--|Diameter| +--( )--:-| Agent |-:--( )--|Diameter|
+--------+ | ( ` . ) ) : +-----^--+ : ( ` . ) ) | Client | +--------+ | ( ` . ) ) : +--------+ : ( ` . ) ) | Client |
|Diameter|--+ `--(___.-' : : `--(___.-' +-----^--+ |Diameter|--+ `--(___.-' : : `--(___.-' +--------+
|Server B| : : |Server B| : :
+---^----+ : : +--------+ : :
End-to-end Overload Indication End-to-end Overload Indication
1) <-----------------------------------------------> 1) <----------------------------------------------->
Diameter Application Y Diameter Application Y
Overload Indication A Overload Indication A' Overload Indication A Overload Indication A'
2) <----------------------> <----------------------> 2) <----------------------> <---------------------->
Diameter Application Y Diameter Application Y Diameter Application Y Diameter Application Y
Figure 1: Simplified architecture choices for overload indication Figure 1: Simplified architecture choices for overload indication
skipping to change at page 13, line 25 skipping to change at page 13, line 25
An OC-Supported-Features AVP in answer messages indicates there is a An OC-Supported-Features AVP in answer messages indicates there is a
reporting node for the transaction. The reacting node MAY take reporting node for the transaction. The reacting node MAY take
action, for example creating state for some stateful abatement action, for example creating state for some stateful abatement
algorithm, based on the features indicated in the OC-Feature-Vector algorithm, based on the features indicated in the OC-Feature-Vector
AVP. AVP.
Note: The loss abatement algorithm does not require stateful Note: The loss abatement algorithm does not require stateful
behavior when there is no active overload report. behavior when there is no active overload report.
Reacting nodes need to be prepared for the reporting node to change
selected algorithms. This can happen at any time, including when the
reporting node has sent an active overload report. The reacting node
can minimize the potential for changes by modifying the advertised
abatement algorithms sent to an overloaded reporting node to the
currently selected algorithm and loss (or just loss if it is the
currently selected algorithm). This has the effect of limiting the
potential change in abatement algorithm from the currently selected
algorithm to loss, avoiding changes to more complex abatement
algorithms that require state to operate properly.
5.1.2. Reporting Node Behavior 5.1.2. Reporting Node Behavior
Upon receipt of a request message, a reporting node determines if Upon receipt of a request message, a reporting node determines if
there is a reacting node for the transaction based on the presence of there is a reacting node for the transaction based on the presence of
the OC-Supported-Features AVP in the request message. the OC-Supported-Features AVP in the request message.
If the request message contains an OC-Supported-Features AVP then a If the request message contains an OC-Supported-Features AVP then a
reporting node MUST include the OC-Supported-Features AVP in the reporting node MUST include the OC-Supported-Features AVP in the
answer message for that transaction. answer message for that transaction.
skipping to change at page 14, line 20 skipping to change at page 14, line 29
The abatement algorithm selected MUST be from the set of abatement The abatement algorithm selected MUST be from the set of abatement
algorithms contained in the request message's OC-Feature-Vector AVP. algorithms contained in the request message's OC-Feature-Vector AVP.
A reporting node that selects the loss algorithm may do so by A reporting node that selects the loss algorithm may do so by
including the OC-Feature-Vector AVP with an explicit indication of including the OC-Feature-Vector AVP with an explicit indication of
the loss algorithm, or it MAY omit OC-Feature-Vector. If it selects the loss algorithm, or it MAY omit OC-Feature-Vector. If it selects
a different algorithm, it MUST include the OC-Feature-Vector AVP with a different algorithm, it MUST include the OC-Feature-Vector AVP with
an explicit indication of the selected algorithm. an explicit indication of the selected algorithm.
A reporting node MUST NOT change the selected algorithm during the
period of time that starts when entering an overload condition and
ends when the associated OCS becomes invalid in all reacting nodes.
The reporting node MAY change the overload abatement algorithm
indicated in the OC-Supported-Features AVP at any time as long as no
previously sent OLRs may be active.
The reporting node SHOULD indicate support for other DOIC features The reporting node SHOULD indicate support for other DOIC features
defined in extension drafts that it supports and that apply to the defined in extension drafts that it supports and that apply to the
transaction. It does so using the OC-Feature-Vector AVP. transaction. It does so using the OC-Feature-Vector AVP.
Note: Not all DOIC features will apply to all Diameter Note: Not all DOIC features will apply to all Diameter
applications or deployment scenarios. The features included in applications or deployment scenarios. The features included in
the OC-Feature-Vector AVP are based on local reporting node the OC-Feature-Vector AVP are based on local reporting node
policy. policy.
5.1.3. Agent Behavior 5.1.3. Agent Behavior
Diameter Agents that support DOIC MAY ensure that all messages Diameter Agents that support DOIC can ensure that all messages
relayed by the agent contain the OC-Supported-Features AVP. relayed by the agent contain the OC-Supported-Features AVP.
A Diameter Agent SHOULD take on reacting node behavior for Diameter A Diameter Agent MAY take on reacting node behavior for Diameter
endpoints that do not support the DOIC solution. A Diameter Agent endpoints that do not support the DOIC solution. A Diameter Agent
detects that a Diameter endpoint does not support DOIC reacting node detects that a Diameter endpoint does not support DOIC reacting node
behavior when there is no OC-Supported-Features AVP in a request behavior when there is no OC-Supported-Features AVP in a request
message. message.
For a Diameter Agent to be a reacting node for a non supporting For a Diameter Agent to be a reacting node for a non supporting
Diameter endpoint, the Diameter Agent MUST include the OC-Supported- Diameter endpoint, the Diameter Agent MUST include the OC-Supported-
Features AVP in request messages it relays that do not contain the Features AVP in request messages it relays that do not contain the
OC-Supported-Features AVP. OC-Supported-Features AVP.
skipping to change at page 15, line 42 skipping to change at page 15, line 44
upstream and downstream DOIC nodes. upstream and downstream DOIC nodes.
5.2. Overload Report Processing 5.2. Overload Report Processing
5.2.1. Overload Control State 5.2.1. Overload Control State
Both reacting and reporting nodes maintain Overload Control State Both reacting and reporting nodes maintain Overload Control State
(OCS) for active overload conditions. The following sections define (OCS) for active overload conditions. The following sections define
behavior associated with that OCS. behavior associated with that OCS.
The contents of the OCS in the reporting node and in the reacting
node represent logical constructs. The actual internal physical
structure of the state included in the OCS is an implementation
decision.
5.2.1.1. Overload Control State for Reacting Nodes 5.2.1.1. Overload Control State for Reacting Nodes
A reacting node SHOULD maintain the following OCS per supported A reacting node maintains the following OCS per supported Diameter
Diameter application: application:
o A host-type OCS entry for each Destination-Host to which it sends o A host-type OCS entry for each Destination-Host to which it sends
host-type requests and host-type requests and
o A realm-type OCS entry for each Destination-Realm to which it o A realm-type OCS entry for each Destination-Realm to which it
sends realm-type requests. sends realm-type requests.
A host-type OCS entry is identified by the pair of application-id and A host-type OCS entry is identified by the pair of application-id and
the node's DiameterIdentity. the node's DiameterIdentity.
A realm-type OCS entry is identified by the pair of application-id A realm-type OCS entry is identified by the pair of application-id
and realm. and realm.
The host-type and realm-type OCS entries MAY include the following The host-type and realm-type OCS entries include the following
information (the actual information stored is an implementation information (the actual information stored is an implementation
decision): decision):
o Sequence number (as received in OC-OLR) o Sequence number (as received in OC-OLR)
o Time of expiry (derived from OC-Validity-Duration AVP received in o Time of expiry (derived from OC-Validity-Duration AVP received in
the OC-OLR AVP and time of reception of the message carrying OC- the OC-OLR AVP and time of reception of the message carrying OC-
OLR AVP) OLR AVP)
o Selected Abatement Algorithm (as received in the OC-Supported- o Selected Abatement Algorithm (as received in the OC-Supported-
Features AVP) Features AVP)
o Abatement Algorithm specific input data (as received in the OC-OLR o Abatement Algorithm specific input data (as received in the OC-OLR
AVP, for example, OC-Reduction-Percentage for the Loss abatement AVP, for example, OC-Reduction-Percentage for the Loss abatement
algorithm) algorithm)
5.2.1.2. Overload Control State for Reporting Nodes 5.2.1.2. Overload Control State for Reporting Nodes
A reporting node SHOULD maintain OCS entries per supported Diameter A reporting node maintains OCS entries per supported Diameter
application, per supported (and eventually selected) Abatement application, per supported (and eventually selected) Abatement
Algorithm and per report-type. Algorithm and per report-type.
An OCS entry is identified by the tuple of Application-Id, Report- An OCS entry is identified by the tuple of Application-Id, Report-
Type and Abatement Algorithm and MAY include the following Type and Abatement Algorithm and includes the following information
information (the actual information stored is an implementation (the actual information stored is an implementation decision):
decision):
o Sequence number o Sequence number
o Validity Duration o Validity Duration
o Expiration Time o Expiration Time
o Algorithm specific input data (for example, the Reduction o Algorithm specific input data (for example, the Reduction
Percentage for the Loss Abatement Algorithm) Percentage for the Loss Abatement Algorithm)
5.2.1.3. Reacting Node Maintenance of Overload Control State 5.2.1.3. Reacting Node Maintenance of Overload Control State
When a reacting node receives an OC-OLR AVP, it MUST determine if it When a reacting node receives an OC-OLR AVP, it MUST determine if it
is for an existing or new overload condition. is for an existing or new overload condition.
Note: For the remainder of this section the term OLR refers to the Note: For the remainder of this section the term OLR refers to the
combination of the contents of the received OC-OLR AVP and the combination of the contents of the received OC-OLR AVP and the
abatement algorithm indicated in the received OC-Supported- abatement algorithm indicated in the received OC-Supported-
Features AVP. Features AVP.
When receiving an answer message with multiple OLRs of different When receiving an answer message with multiple OLRs of different
supported report types, a reacting node MUST process each received supported report types, a reacting node MUST process each received
OLR. OLR.
When receiving an answer message with multiple OLRs and multiple of
the OLRs are of the same supported report types, a reacting node
SHOULD ignore the duplicated OLRs.
A reacting node SHOULD ignore an OC-OLR with a OC-Report-Type AVP
that contains an unrecognized value.
The OLR is for an existing overload condition if a reacting node has The OLR is for an existing overload condition if a reacting node has
an OCS that matches the received OLR. an OCS that matches the received OLR.
For a host-report this means it matches the application-id and the For a host-report this means it matches the application-id and the
host's DiameterIdentity in an existing host OCS entry. host's DiameterIdentity in an existing host OCS entry.
For a realm-report this means it matches the application-id and the For a realm-report this means it matches the application-id and the
realm in an existing realm OCS entry. realm in an existing realm OCS entry.
If the OLR is for an existing overload condition then a reacting node If the OLR is for an existing overload condition then a reacting node
skipping to change at page 18, line 41 skipping to change at page 18, line 45
zero ("0"). zero ("0").
When generating sequence numbers for new overload conditions, the new When generating sequence numbers for new overload conditions, the new
sequence number MUST be greater than any sequence number in an active sequence number MUST be greater than any sequence number in an active
(unexpired) overload report for the same application and report-type (unexpired) overload report for the same application and report-type
previously sent by the reporting node. This property MUST hold over previously sent by the reporting node. This property MUST hold over
a reboot of the reporting node. a reboot of the reporting node.
Note: One way of addressing this over a reboot of a reporting node Note: One way of addressing this over a reboot of a reporting node
is to use a time stamp for the first overload condition that is to use a time stamp for the first overload condition that
occurs after the report and to start using sequence numbers of occurs after the report and to start using sequences beginning
zero for subsequent overload conditions. with zero for subsequent overload conditions.
A reporting node MUST update an OCS entry when it needs to adjust the A reporting node MUST update an OCS entry when it needs to adjust the
validity duration of the overload condition at reacting nodes. validity duration of the overload condition at reacting nodes.
For instance, if a reporting node wishes to instruct reacting For instance, if a reporting node wishes to instruct reacting
nodes to continue overload abatement for a longer period of time nodes to continue overload abatement for a longer period of time
than originally communicated. This also applies if the reporting than originally communicated. This also applies if the reporting
node wishes to shorten the period of time that overload abatement node wishes to shorten the period of time that overload abatement
is to continue. is to continue.
A reporting node MUST NOT update the abatement algorithm in an active
OCS entry.
A reporting node MUST update an OCS entry when it wishes to adjust A reporting node MUST update an OCS entry when it wishes to adjust
any abatement algorithm specific parameters, including, for example, any abatement algorithm specific parameters, including, for example,
the reduction percentage used for the Loss abatement algorithm. the reduction percentage used for the Loss abatement algorithm.
For instance, if a reporting node wishes to change the reduction For instance, if a reporting node wishes to change the reduction
percentage either higher, if the overload condition has worsened, percentage either higher, if the overload condition has worsened,
or lower, if the overload condition has improved, then the or lower, if the overload condition has improved, then the
reporting node would update the appropriate OCS entry. reporting node would update the appropriate OCS entry.
A reporting node MUST increment the sequence number associated with A reporting node MUST increment the sequence number associated with
skipping to change at page 20, line 5 skipping to change at page 20, line 8
Section 6 for the overload abatement algorithm logic applied. Section 6 for the overload abatement algorithm logic applied.
If the overload abatement algorithm selects the request for overload If the overload abatement algorithm selects the request for overload
abatement treatment then the reacting node MUST apply overload abatement treatment then the reacting node MUST apply overload
abatement treatment on the request. The abatement treatment applied abatement treatment on the request. The abatement treatment applied
depends on the context of the request. depends on the context of the request.
If diversion abatement treatment is possible (i.e. a different path If diversion abatement treatment is possible (i.e. a different path
for the request can be selected where the overloaded node is not part for the request can be selected where the overloaded node is not part
of the different path), then the reacting node SHOULD apply diversion of the different path), then the reacting node SHOULD apply diversion
abatement treatment to the request. Otherwise the reacting node abatement treatment to the request. The reacting node MUST apply
SHOULD apply throttling abatement treatment to the request. throttling abatement treatment to requests identified for abatement
treatment when diversion treatment is not possible or was not
applied.
Note: This only addresses the case where there are two defined
abatement treatments, diversion and throttling. Any extension
that defines a new abatement treatment must also defined the
interaction of the new abatement treatment with existing
treatments.
If the overload abatement treatment results in throttling of the If the overload abatement treatment results in throttling of the
request and if the reacting node is an agent then the agent MUST send request and if the reacting node is an agent then the agent MUST send
an appropriate error as defined in Section 8. an appropriate error as defined in Section 8.
Diameter endpoints that throttle requests need to do so according to Diameter endpoints that throttle requests need to do so according to
the rules of the client application. Those rules will vary by the rules of the client application. Those rules will vary by
application, and are beyond the scope of this document. application, and are beyond the scope of this document.
In the case that the OCS entry indicated no traffic was to be sent to In the case that the OCS entry indicated no traffic was to be sent to
skipping to change at page 22, line 23 skipping to change at page 22, line 33
OC-OLR AVPs defined in this document. OC-OLR AVPs defined in this document.
[RFC6733] defined Grouped AVP extension mechanisms apply. This [RFC6733] defined Grouped AVP extension mechanisms apply. This
allows, for example, defining a new feature that is mandatory to be allows, for example, defining a new feature that is mandatory to be
understood even when piggybacked on an existing application. understood even when piggybacked on an existing application.
When defining new report type values, the corresponding specification When defining new report type values, the corresponding specification
MUST define the semantics of the new report types and how they affect MUST define the semantics of the new report types and how they affect
the OC-OLR AVP handling. the OC-OLR AVP handling.
The OC-OLR AVP can be expanded with optional sub-AVPs only if a The OC-Supported-Feature and OC-OLR AVPs can be expanded with
legacy DOIC implementation can safely ignore them without breaking optional sub-AVPs only if a legacy DOIC implementation can safely
backward compatibility for the given OC-Report-Type AVP value. ignore them without breaking backward compatibility for the given OC-
Report-Type AVP value. Any new sub-AVPs MUST NOT require that the
M-bit be set.
Documents that introduce new report types MUST describe any Documents that introduce new report types MUST describe any
limitations on their use across non-supporting agents. limitations on their use across non-supporting agents.
As with any Diameter specification, RFC6733 requires all new AVPs to As with any Diameter specification, RFC6733 requires all new AVPs to
be registered with IANA. See Section 9 for the required procedures. be registered with IANA. See Section 9 for the required procedures.
New features (feature bits in the OC-Feature-Vector AVP) and report New features (feature bits in the OC-Feature-Vector AVP) and report
types (in the OC-Report-Type AVP) MUST be registered with IANA. types (in the OC-Report-Type AVP) MUST be registered with IANA.
6. Loss Algorithm 6. Loss Algorithm
skipping to change at page 24, line 21 skipping to change at page 24, line 32
indicated in the OC-Supported-Features AVP is the loss algorithm, the indicated in the OC-Supported-Features AVP is the loss algorithm, the
reacting node MUST apply abatement treatment to the requested reacting node MUST apply abatement treatment to the requested
percentage of request messages sent. percentage of request messages sent.
Note: The loss algorithm is a stateless algorithm. As a result, Note: The loss algorithm is a stateless algorithm. As a result,
the reacting node does not guarantee that there will be an the reacting node does not guarantee that there will be an
absolute reduction in traffic sent. Rather, it guarantees that absolute reduction in traffic sent. Rather, it guarantees that
the requested percentage of new requests will be given abatement the requested percentage of new requests will be given abatement
treatment. treatment.
When applying overload abatement treatment for the loss abatement
algorithm, the reacting node MUST abate the requested percentage of
requests that would have otherwise been sent to the reporting host or
realm.
If reacting node comes out of the 100 percent traffic reduction as a If reacting node comes out of the 100 percent traffic reduction as a
result of the overload report timing out, the following procedures result of the overload report timing out, the reacting node sending
are RECOMMENDED to be applied. The reacting node sending the traffic the traffic SHOULD be conservative and, for example, first send
should be conservative and, for example, first send "probe" messages "probe" messages to learn the overload condition of the overloaded
to learn the overload condition of the overloaded node before node before converging to any traffic amount/rate decided by the
converging to any traffic amount/rate decided by the sender. Similar sender. Similar concerns apply in all cases when the overload report
concerns apply in all cases when the overload report times out unless times out unless the previous overload report stated 0 percent
the previous overload report stated 0 percent reduction. reduction.
The goal of this behavior is to reduce the probability of overload The goal of this behavior is to reduce the probability of overload
condition thrashing where an immediate transition from 100% condition thrashing where an immediate transition from 100%
reduction to 0% reduction results in the reporting node moving reduction to 0% reduction results in the reporting node moving
quickly back into an overload condition. quickly back into an overload condition.
If the reacting node does not receive an OLR in answers received from
the formerly overloaded node then the reacting node SHOULD slowly
increase the rate of traffic sent to the overloaded node.
7. Attribute Value Pairs 7. Attribute Value Pairs
This section describes the encoding and semantics of the Diameter This section describes the encoding and semantics of the Diameter
Overload Indication Attribute Value Pairs (AVPs) defined in this Overload Indication Attribute Value Pairs (AVPs) defined in this
document. document.
7.1. OC-Supported-Features AVP 7.1. OC-Supported-Features AVP
The OC-Supported-Features AVP (AVP code TBD1) is of type Grouped and The OC-Supported-Features AVP (AVP code TBD1) is of type Grouped and
serves two purposes. First, it announces a node's support for the serves two purposes. First, it announces a node's support for the
skipping to change at page 26, line 31 skipping to change at page 26, line 31
used as a non-volatile increasing counter for a sequence of overload used as a non-volatile increasing counter for a sequence of overload
reports between two DOIC nodes for the same overload occurrence. reports between two DOIC nodes for the same overload occurrence.
Sequence numbers are treated in a uni-directional manner, i.e. two Sequence numbers are treated in a uni-directional manner, i.e. two
sequence numbers on each direction between two DOIC nodes are not sequence numbers on each direction between two DOIC nodes are not
related or correlated. related or correlated.
7.5. OC-Validity-Duration AVP 7.5. OC-Validity-Duration AVP
The OC-Validity-Duration AVP (AVP code TBD5) is of type Unsigned32 The OC-Validity-Duration AVP (AVP code TBD5) is of type Unsigned32
and indicates in seconds the validity time of the overload report. and indicates in seconds the validity time of the overload report.
The number of mseconds is measured after reception of the first OC- The number of seconds is measured after reception of the first OC-OLR
OLR AVP with a given value of OC-Sequence-Number AVP. The default AVP with a given value of OC-Sequence-Number AVP. The default value
value for the OC-Validity-Duration AVP is 30 seconds. When the OC- for the OC-Validity-Duration AVP is 30 seconds. When the OC-
Validity-Duration AVP is not present in the OC-OLR AVP, the default Validity-Duration AVP is not present in the OC-OLR AVP, the default
value applies. The maximum value for the OC-Validity-Duration AVP is value applies. The maximum value for the OC-Validity-Duration AVP is
86,400 seconds (24 hours). 86,400 seconds (24 hours).
7.6. OC-Report-Type AVP 7.6. OC-Report-Type AVP
The OC-Report-Type AVP (AVP code TBD6) is of type Enumerated. The The OC-Report-Type AVP (AVP code TBD6) is of type Enumerated. The
value of the AVP describes what the overload report concerns. The value of the AVP describes what the overload report concerns. The
following values are initially defined: following values are initially defined:
skipping to change at page 28, line 12 skipping to change at page 28, line 12
As described in the Diameter base protocol [RFC6733], the M-bit usage As described in the Diameter base protocol [RFC6733], the M-bit usage
for a given AVP in a given command may be defined by the application. for a given AVP in a given command may be defined by the application.
8. Error Response Codes 8. Error Response Codes
When a DOIC node rejects a Diameter request due to overload, the DOIC When a DOIC node rejects a Diameter request due to overload, the DOIC
node MUST select an appropriate error response code. This node MUST select an appropriate error response code. This
determination is made based on the probability of the request determination is made based on the probability of the request
succeeding if retried on a different path. succeeding if retried on a different path.
Note: This only applies for DOIC nodes that are not the originator
of the request.
A reporting node rejecting a Diameter request due to an overload A reporting node rejecting a Diameter request due to an overload
condition SHOULD send a DIAMETER_TOO_BUSY error response, if it can condition SHOULD send a DIAMETER_TOO_BUSY error response, if it can
assume that the same request may succeed on a different path. assume that the same request may succeed on a different path.
If a reporting node knows or assumes that the same request will not If a reporting node knows or assumes that the same request will not
succeed on a different path, DIAMETER_UNABLE_TO_COMPLY error response succeed on a different path, DIAMETER_UNABLE_TO_COMPLY error response
SHOULD be used. Retrying would consume valuable resources during an SHOULD be used. Retrying would consume valuable resources during an
occurrence of overload. occurrence of overload.
For instance, if the request arrived at the reporting node without For instance, if the request arrived at the reporting node without
 End of changes. 43 change blocks. 
89 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/