draft-ietf-dime-agent-overload-08.txt   draft-ietf-dime-agent-overload-09.txt 
Diameter Maintenance and Extensions (DIME) S. Donovan Diameter Maintenance and Extensions (DIME) S. Donovan
Internet-Draft Oracle Internet-Draft Oracle
Updates: RFC7683 (if approved) December 2, 2016 Updates: RFC7683 (if approved) February 7, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: June 5, 2017 Expires: August 11, 2017
Diameter Agent Overload and the Peer Overload Report Diameter Agent Overload and the Peer Overload Report
draft-ietf-dime-agent-overload-08.txt draft-ietf-dime-agent-overload-09.txt
Abstract Abstract
This specification documents an extension to RFC 7683 (Diameter This specification documents an extension to RFC 7683 (Diameter
Overload Indication Conveyance (DOIC)) base solution. The extension Overload Indication Conveyance (DOIC)) base solution. The extension
defines the Peer overload report type. The initial use case for the defines the Peer overload report type. The initial use case for the
Peer report is the handling of occurrences of overload of a Diameter Peer report is the handling of occurrences of overload of a Diameter
agent. agent.
Requirements Requirements
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 June 5, 2017. This Internet-Draft will expire on August 11, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 32
3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 8 3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 8
4. Interaction Between Host/Realm and Peer Overload Reports . . 8 4. Interaction Between Host/Realm and Peer Overload Reports . . 8
5. Peer Report Behavior . . . . . . . . . . . . . . . . . . . . 8 5. Peer Report Behavior . . . . . . . . . . . . . . . . . . . . 8
5.1. Capability Announcement . . . . . . . . . . . . . . . . . 8 5.1. Capability Announcement . . . . . . . . . . . . . . . . . 8
5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 8 5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 8
5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 9 5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 9
5.2. Peer Overload Report Handling . . . . . . . . . . . . . . 10 5.2. Peer Overload Report Handling . . . . . . . . . . . . . . 10
5.2.1. Overload Control State . . . . . . . . . . . . . . . 10 5.2.1. Overload Control State . . . . . . . . . . . . . . . 10
5.2.2. Reporting Node Maintenance of Peer Report OCS . . . . 11 5.2.2. Reporting Node Maintenance of Peer Report OCS . . . . 11
5.2.3. Reacting Node Maintenance of Peer Report OCS . . . . 11 5.2.3. Reacting Node Maintenance of Peer Report OCS . . . . 11
5.2.4. Peer Report Reporting Node Behavior . . . . . . . . . 12 5.2.4. Peer-Report Reporting Node Behavior . . . . . . . . . 12
5.2.5. Peer Report Reacting Node Behavior . . . . . . . . . 12 5.2.5. Peer-Report Reacting Node Behavior . . . . . . . . . 12
6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 13 6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 13
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 13 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 13
6.1.1. OC-Feature-Vector . . . . . . . . . . . . . . . . . . 14 6.1.1. OC-Feature-Vector . . . . . . . . . . . . . . . . . . 14
6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 14 6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 14
6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15 6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15
6.3. SourceID . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 15 6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
7.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. New registries . . . . . . . . . . . . . . . . . . . . . 16 7.2. New registries . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Informative References . . . . . . . . . . . . . . . . . 17 10.1. Informative References . . . . . . . . . . . . . . . . . 17
10.2. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Normative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 19 skipping to change at page 3, line 19
defines the Peer overload report type. The initial use case for the defines the Peer overload report type. The initial use case for the
Peer report is the handling of occurrences of overload of a Diameter Peer report is the handling of occurrences of overload of a Diameter
agent. agent.
This document defines the behavior of Diameter nodes when Diameter This document defines the behavior of Diameter nodes when Diameter
agents enter an overload condition and send an overload report agents enter an overload condition and send an overload report
requesting a reduction of traffic. It also defines new overload requesting a reduction of traffic. It also defines new overload
report type, the Peer overload report type, that is used for handling report type, the Peer overload report type, that is used for handling
of agent overload conditions. The Peer overload report type is of agent overload conditions. The Peer overload report type is
defined in a generic fashion so that it can also be used for other defined in a generic fashion so that it can also be used for other
Diameter overload scenaios. Diameter overload scenarios.
The base Diameter overload specification [RFC7683] addresses the The base Diameter overload specification [RFC7683] addresses the
handling of overload when a Diameter endpoint (a Diameter Client or handling of overload when a Diameter endpoint (a Diameter Client or
Diameter Server as defined in [RFC6733]) becomes overloaded. Diameter Server as defined in [RFC6733]) becomes overloaded.
In the base specification, the goal is to handle abatement of the In the base specification, the goal is to handle abatement of the
overload occurrence as close to the source of the Diameter traffic as overload occurrence as close to the source of the Diameter traffic as
is feasible. When possible this is done at the originator of the feasible. When possible this is done at the originator of the
traffic, generally referred to as a Diameter Client. A Diameter traffic, generally referred to as a Diameter Client. A Diameter
Agent might also handle the overload mitigation. For instance, a Agent might also handle the overload mitigation. For instance, a
Diameter Agent might handle Diameter overload mitigation when it Diameter Agent might handle Diameter overload mitigation when it
knows that a Diameter Client does not support the DOIC extension. knows that a Diameter Client does not support the DOIC extension.
This document extends the base Diameter endpoint overload This document extends the base Diameter endpoint overload
specification to address the case when Diameter Agents become specification to address the case when Diameter Agents become
overloaded. Just as is the case with other Diameter nodes -- overloaded. Just as is the case with other Diameter nodes --
Diameter Clients and Diameter Servers -- surges in Diameter traffic Diameter Clients and Diameter Servers -- surges in Diameter traffic
can cause a Diameter Agent to be asked to handle more Diameter can cause a Diameter Agent to be asked to handle more Diameter
skipping to change at page 4, line 11 skipping to change at page 4, line 11
2. Terminology and Abbreviations 2. Terminology and Abbreviations
Diameter Node Diameter Node
A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733 A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733
Diameter Agent. Diameter Agent.
Diameter Endpoint Diameter Endpoint
An RFC6733 Diameter Client and RFC6733 Diameter Server. An RFC6733 Diameter Client and RFC6733 Diameter Server.
Diameter Agent
An RFC6733 Diameter Agent.
Reporting Node Reporting Node
A DOIC Node that sends an overload report in a Diameter answer A DOIC Node that sends an overload report in a Diameter answer
message. message.
Reacting Node Reacting Node
A DOIC Node that receives and acts on a DOIC overload report. A DOIC Node that receives and acts on a DOIC overload report.
DOIC Node DOIC Node
skipping to change at page 5, line 32 skipping to change at page 5, line 38
agent must by handled by the client in a similar fashion as if the agent must by handled by the client in a similar fashion as if the
client were handling the overload of a directly connected server. client were handling the overload of a directly connected server.
When the agent becomes overloaded it will insert an overload report When the agent becomes overloaded it will insert an overload report
in answer messages flowing to the client. This overload report will in answer messages flowing to the client. This overload report will
contain a requested reduction in the amount of traffic sent to the contain a requested reduction in the amount of traffic sent to the
agent. The client will apply overload abatement behavior as defined agent. The client will apply overload abatement behavior as defined
in the base Diameter overload specification [RFC7683] or the in the base Diameter overload specification [RFC7683] or the
extension draft that defines the indicated overload abatement extension draft that defines the indicated overload abatement
algorithm. This will result in the throttling of the abated traffic algorithm. This will result in the throttling of the abated traffic
that would have been sent to the agent, as there is no alternative that would have been sent to the agent, as there is no alternative
route. An appropriate error response is sent back to the originator route. The client sends an appropriate error response to the
of the request. originator of the request.
3.1.2. Redundant Agents 3.1.2. Redundant Agents
Figure 3 and Figure 4 illustrate a second, and more likely, type of Figure 3 and Figure 4 illustrate a second, and more likely, type of
deployment scenario involving agents. In both of these cases, the deployment scenario involving agents. In both of these cases, the
client has Diameter connections to two agents. client has Diameter connections to two agents.
Figure 3 illustrates a client that has a primary connection to one of Figure 3 illustrates a client that has a primary connection to one of
the agents (agent a1) and a secondary connection to the other agent the agents (agent a1) and a secondary connection to the other agent
(agent a2). In this scenario, under normal circumstances, the client (agent a2). In this scenario, under normal circumstances, the client
skipping to change at page 6, line 40 skipping to change at page 6, line 42
In the case where one of the agents in the above scenario becomes In the case where one of the agents in the above scenario becomes
overloaded, the client should reduce the amount of traffic sent to overloaded, the client should reduce the amount of traffic sent to
the overloaded agent by the amount requested. This traffic should the overloaded agent by the amount requested. This traffic should
instead be routed through the non-overloaded agent. For example, instead be routed through the non-overloaded agent. For example,
assume that the overloaded agent requests a reduction of 10 percent. assume that the overloaded agent requests a reduction of 10 percent.
The client should send 10 percent of the traffic that would have been The client should send 10 percent of the traffic that would have been
routed to the overloaded agent through the non-overloaded agent. routed to the overloaded agent through the non-overloaded agent.
When the client has an active and a standby connection to the two When the client has an active and a standby connection to the two
agents then an alternative strategy for responding to an overload agents then an alternative strategy for responding to an overload
report from an agent is to change to standby connection to active and report from an agent is to change the standby connection to active
route all traffic through the new active connection. and route all traffic through the new active connection.
In the case where both agents are reporting overload, the client may In the case where both agents are reporting overload, the client may
need to start decreasing the total traffic sent to the agents. This need to start decreasing the total traffic sent to the agents. This
would be done in a similar fashion as discussed in Section 3.1.1 The would be done in a similar fashion as discussed in Section 3.1.1 The
amount of traffic depends on the combined reduction requested by the amount of traffic depends on the combined reduction requested by the
two agents. two agents.
3.1.3. Agent Chains 3.1.3. Agent Chains
There are also deployment scenarios where there can be multiple There are also deployment scenarios where there can be multiple
Diameter Agents between Diameter Clients and Diameter Servers. An Diameter Agents between Diameter Clients and Diameter Servers. An
example of this type of deployment include when there are Diameter example of this type of deployment includes when there are Diameter
agents between administrative domains. agents between administrative domains.
Figure 5 illustrates one such network deployment case. Note that Figure 5 illustrates one such network deployment case. Note that
while this figure shows a maximum of two agents being involved in a while this figure shows a maximum of two agents being involved in a
Diameter transaction, it is possible that more than two agents could Diameter transaction, it is possible that more than two agents could
be in the path of a transaction. be in the path of a transaction.
+---+ +---+ +-+ +---+ +---+ +-+
--|a11|-----|a21|---|s| --|a11|-----|a21|---|s|
+-+ / +---+ \ / +---+\ /+-+ +-+ / +---+ \ / +---+\ /+-+
|c|- x x |c|- x x
+-+ \ +---+ / \ +---+/ \+-+ +-+ \ +---+ / \ +---+/ \+-+
--|a12|-----|a22|---|s| --|a12|-----|a22|---|s|
+---+ +---+ +-+ +---+ +---+ +-+
Figure 5 Figure 5
Handling of overload of one or both of agents a11 or a12 in this case Handling of overload of one or both of agents a11 or a12 in this case
is equivalent to that discussed in section 2.2. is equivalent to that discussed in Section 3.1.2.
Overload of agents a21 and a22 must be handled by the previous hop Overload of agents a21 and a22 must be handled by the previous hop
agents. As such, agents a11 and a12 must handle the overload agents. As such, agents a11 and a12 must handle the overload
mitigation logic when receiving an agent overload report from agents mitigation logic when receiving an agent overload report from agents
a21 and a22. a21 and a22.
The handling of peer overload reports is similar to that discussed in The handling of peer overload reports is similar to that discussed in
Section 3.1.2. If the overload can be addressed using diversion then Section 3.1.2. If the overload can be addressed using diversion then
this approach should be taken. this approach should be taken.
skipping to change at page 8, line 45 skipping to change at page 8, line 45
5. Peer Report Behavior 5. Peer Report Behavior
This section defines the normative behavior associated with the Peer This section defines the normative behavior associated with the Peer
Report extension to the DOIC solution. Report extension to the DOIC solution.
5.1. Capability Announcement 5.1. Capability Announcement
5.1.1. Reacting Node Behavior 5.1.1. Reacting Node Behavior
When sending a Diameter request a DOIC node that supports the When sending a Diameter request a DOIC Node that supports the
OC_PEER_REPORT feature MUST include in the OC-Supported-Features AVP OC_PEER_REPORT (as defined in Section 6.1.1) feature MUST include in
an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. the OC-Supported-Features AVP an OC-Feature-Vector AVP with the
OC_PEER_REPORT bit set.
When sending a request a DOIC node that supports the OC_PEER_REPORT When sending a request a DOIC Node that supports the OC_PEER_REPORT
feature MUST include a SourceID AVP in the OC-Supported-Features AVP feature MUST include a SourceID AVP in the OC-Supported-Features AVP
with its own DiameterIdentity. with its own DiameterIdentity.
When an agent relays a request that includes a SourceID AVP in the When a Diameter Agent relays a request that includes a SourceID AVP
OC-Supported-Features AVP, a DOIC node that supports the in the OC-Supported-Features AVP, if the Diameter Agent supports the
OC_PEER_REPORT feature MUST remove the received SourceID AVP and OC_PEER_REPORT feature then it MUST remove the received SourceID AVP
replace it with a SourceID AVP containing its own Diameter identity. and replace it with a SourceID AVP containing its own
DiameterIdentity.
5.1.2. Reporting Node Behavior 5.1.2. Reporting Node Behavior
When receiving a request a DOIC node that supports the OC_PEER_REPORT When receiving a request a DOIC Node that supports the OC_PEER_REPORT
feature MUST update transaction state with an indication of whether feature MUST update transaction state with an indication of whether
or not the peer from which the request was received supports the or not the peer from which the request was received supports the
OC_PEER_REPORT feature. OC_PEER_REPORT feature.
Note: The transaction state is used when the DOIC node is acting Note: The transaction state is used when the DOIC Node is acting
as a peer-report reporting node and needs send OC-OLR reports of as a peer-report reporting node and needs send OC-OLR reports of
type PEER_REPORT in answer messages. The peer overload reports type peer in answer messages. The peer overload reports are only
are only included in answer messages being sent to peers that included in answer messages being sent to peers that support the
support the OC_PEER_REPORT feature. OC_PEER_REPORT feature.
The peer supports the OC_PEER_REPORT feature if the received request The peer supports the OC_PEER_REPORT feature if the received request
contains an OC-Supported-Features AVP with the OC-Feature-Vector with contains an OC-Supported-Features AVP with the OC-Feature-Vector with
the OC_PEER_REPORT feature bit set and with a SourceID AVP with a the OC_PEER_REPORT feature bit set and with a SourceID AVP with a
Diameter ID that matches the DiameterIdentity of the peer from which value that matches the DiameterIdentity of the peer from which the
the request was received. request was received.
When an agent relays an answer message, a reporting node that When an agent relays an answer message, a reporting node that
supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from
the OC-Supported-Features AVP. the OC-Supported-Features AVP.
When sending an answer message, a reporting node that supports the When sending an answer message, a reporting node that supports the
OC_PEER_REPORT feature MUST determine if the peer to which the answer OC_PEER_REPORT feature MUST determine if the peer to which the answer
is to be sent supports the OC_PEER_REPORT feature. is to be sent supports the OC_PEER_REPORT feature.
If the peer supports the OC_PEER_REPORT feature then the reporting If the peer supports the OC_PEER_REPORT feature then the reporting
skipping to change at page 10, line 13 skipping to change at page 10, line 13
becoming overloaded. becoming overloaded.
5.2. Peer Overload Report Handling 5.2. Peer Overload Report Handling
This section defines the behavior for the handling of overload This section defines the behavior for the handling of overload
reports of type peer. reports of type peer.
5.2.1. Overload Control State 5.2.1. Overload Control State
This section describes the Overload Control State (OCS) that might be This section describes the Overload Control State (OCS) that might be
maintained by both the peer report reporting node and the peer report maintained by both the peer-report reporting node and the peer-report
reacting node. reacting node.
This is an extension of the OCS handling defined in [RFC7683]. This is an extension of the OCS handling defined in [RFC7683].
5.2.1.1. Reporting Node Peer Report OCS 5.2.1.1. Reporting Node Peer Report OCS
A DOIC Node that supports the OC_PEER_REPORT feature SHOULD maintain A DOIC Node that supports the OC_PEER_REPORT feature SHOULD maintain
Reporting Node OCS, as defined in [RFC7683] and extended here. Reporting Node OCS, as defined in [RFC7683] and extended here.
If different abatement specific contents are sent to each peer then If different abatement specific contents are sent to each peer then
skipping to change at page 11, line 21 skipping to change at page 11, line 21
All rules for managing the reporting node OCS entries defined in All rules for managing the reporting node OCS entries defined in
[RFC7683] apply to the peer report. [RFC7683] apply to the peer report.
5.2.3. Reacting Node Maintenance of Peer Report OCS 5.2.3. Reacting Node Maintenance of Peer Report OCS
When a reacting node receives an OC-OLR AVP with a report type of When a reacting node receives an OC-OLR AVP with a report type of
peer it MUST determine if the report was generated by the Diameter peer it MUST determine if the report was generated by the Diameter
peer from which the report was received. peer from which the report was received.
If a reacting node receives an OC-OLR AVP of type peer and the If a reacting node receives an OC-OLR AVP of type peer and the
SourceID matches the ID of the Diameter peer from which the request SourceID matches the DiameterIdentity of the Diameter peer from which
was received then the report was received from a Diameter peer. the request was received then the report was generated by a Diameter
peer.
If a reacting node receives an OC-OLR AVP of type peer and the If a reacting node receives an OC-OLR AVP of type peer and the
SourceID does not match the ID of the Diameter peer from which the SourceID does not match the DiameterIdentity of the Diameter peer
request was received then the reacting node MUST ignore the overload from which the request was received then the reacting node MUST
report. ignore the overload report.
If the Peer Report OLR was received from a Diameter peer then the If the Peer Report OLR was received from a Diameter peer then the
reacting node MUST determine if it is for an existing or new overload reacting node MUST determine if it is for an existing or new overload
condition. condition.
The OLR is for an existing overload condition if the reacting node The OLR is for an existing overload condition if the reacting node
has an OCS that matches the received OLR. For a peer report-type, has an OCS that matches the received OLR. For a peer report, this
this means it matches the Application-ID and the peer's means it matches the Application-ID and the peer's DiameterIdentity
DiameterIdentity in an existing OCS entry. in an existing OCS entry.
If the OLR is for an existing overload condition then it MUST If the OLR is for an existing overload condition then it MUST
determine if the OLR is a retransmission or an update to the existing determine if the OLR is a retransmission or an update to the existing
OLR. OLR.
If the sequence number for the received OLR is greater than the If the sequence number for the received OLR is greater than the
sequence number stored in the matching OCS entry then the reacting sequence number stored in the matching OCS entry then the reacting
node MUST update the matching OCS entry. node MUST update the matching OCS entry.
If the sequence number for the received OLR is less than or equal to If the sequence number for the received OLR is less than or equal to
the sequence number in the matching OCS entry then the reacting node the sequence number in the matching OCS entry then the reacting node
MUST silently ignore the received OLR. The matching OCS MUST NOT be MUST silently ignore the received OLR. The matching OCS MUST NOT be
updated in this case. updated in this case.
If the received OLR is for a new overload condition then the reacting If the received OLR is for a new overload condition then the reacting
node MUST generate a new OCS entry for the overload condition. node MUST generate a new OCS entry for the overload condition.
For a peer report this means it creates an OCS entry with an For a peer report this means it creates an OCS entry with a
DiameterID from the SourceID AVP in the received OC-OLR AVP. DiameterIdentity from the SourceID AVP in the received OC-OLR AVP.
If the received OLR contains a validity duration of zero ("0") then If the received OLR contains a validity duration of zero ("0") then
the reacting node MUST update the OCS entry as being expired. the reacting node MUST update the OCS entry as being expired.
The reacting node does not delete an OCS when receiving an answer The reacting node does not delete an OCS when receiving an answer
message that does not contain an OC-OLR AVP (i.e. absence of OLR message that does not contain an OC-OLR AVP (i.e. absence of OLR
means "no change"). means "no change").
The reacting node sets the abatement algorithm based on the OC-Peer- The reacting node sets the abatement algorithm based on the OC-Peer-
Algo AVP in the received OC-Supported-Features AVP. Algo AVP in the received OC-Supported-Features AVP.
5.2.4. Peer Report Reporting Node Behavior 5.2.4. Peer-Report Reporting Node Behavior
When there is an existing reporting node peer report OCS entry, the When there is an existing reporting node peer report OCS entry, the
reporting node MUST include an OC-OLR AVP with a report type of peer reporting node MUST include an OC-OLR AVP with a report type of peer
using the contents of the reporting node peer report OCS entry in all using the contents of the reporting node peer report OCS entry in all
answer messages sent by the reporting node to peers that support the answer messages sent by the reporting node to peers that support the
OC_PEER_REPORT feature. OC_PEER_REPORT feature.
The reporting node determines if a peer supports the The reporting node determines if a peer supports the
OC_PEER_REPORT feature based on the indication recorded in the OC_PEER_REPORT feature based on the indication recorded in the
reporting node's transaction state. reporting node's transaction state.
The reporting node MUST include its DiameterIdentity in the SourceID The reporting node MUST include its DiameterIdentity in the SourceID
AVP in the OC-OLR AVP. This is used by DOIC nodes that support the AVP in the OC-OLR AVP. This is used by DOIC Nodes that support the
OC_PEER_REPORT feature to determine if the report was received from a OC_PEER_REPORT feature to determine if the report was received from a
Diameter peer. Diameter peer.
The reporting agent must follow all other overload reporting node The reporting agent must follow all other overload reporting node
behaviors outlined in the DOIC specification. behaviors outlined in the DOIC specification.
5.2.5. Peer Report Reacting Node Behavior 5.2.5. Peer-Report Reacting Node Behavior
A reacting node supporting this extension MUST support the receipt of A reacting node supporting this extension MUST support the receipt of
multiple overload reports in a single message. The message might multiple overload reports in a single message. The message might
include a host overload report, a realm overload report and/or a peer include a host overload report, a realm overload report and/or a peer
overload report. overload report.
When a reacting node sends a request it MUST determine if that When a reacting node sends a request it MUST determine if that
request matches an active OCS. request matches an active OCS.
In all cases, if the reacting node is an agent then it MUST strip the In all cases, if the reacting node is an agent then it MUST strip the
Peer Report OC-OLR AVP from the message. Peer Report OC-OLR AVP from the message.
If the request matches an active OCS then the reacting node MUST If the request matches an active OCS then the reacting node MUST
apply abatement treatment on the request. The abatement treatment apply abatement treatment to the request. The abatement treatment
applied depends on the abatement algorithm indicated in the OCS. applied depends on the abatement algorithm indicated in the OCS.
For peer overload reports, the preferred abatement treatment is For peer overload reports, the preferred abatement treatment is
diversion. As such, the reacting node SHOULD attempt to divert diversion. As such, the reacting node SHOULD attempt to divert
requests identified as needing abatement to other peers. requests identified as needing abatement to other peers.
If there is not sufficient capacity to divert abated traffic then the If there is not sufficient capacity to divert abated traffic then the
reacting node MUST throttle the necessary requests to fit within the reacting node MUST throttle the necessary requests to fit within the
available capacity of the peers able to handle the requests. available capacity of the peers able to handle the requests.
If the abatement treatment results in throttling of the request and If the abatement treatment results in throttling of the request and
if the reacting node is an agent then the agent MUST send an if the reacting node is an agent then the agent MUST send an
appropriate error as defined in [RFC7683]. appropriate error response as defined in [RFC7683].
In the case that the OCS entry validity duration expires or has a In the case that the OCS entry validity duration expires or has a
validity duration of zero ("0"), meaning that if the reporting node validity duration of zero ("0"), meaning that if the reporting node
has explicitly signaled the end of the overload condition then has explicitly signaled the end of the overload condition then
abatement associated with the overload abatement MUST be ended in a abatement associated with the OCS entry MUST be ended in a controlled
controlled fashion. fashion.
6. Peer Report AVPs 6. Peer Report AVPs
6.1. OC-Supported-Features AVP 6.1. OC-Supported-Features AVP
This extension adds a new feature to the OC-Feature-Vector AVP. This This extension adds a new feature to the OC-Feature-Vector AVP. This
feature indication shows support for handling of peer overload feature indication shows support for handling of peer overload
reports. Peer overload reports are used by agents to indicate the reports. Peer overload reports are used by agents to indicate the
need for overload abatement handling by the agent's peer. need for overload abatement handling by the agent's peer.
A supporting node must also include the SourceID AVP in the OC- A supporting node must also include the SourceID AVP in the OC-
Supported-Features capability AVP. Supported-Features capability AVP.
This AVP contains the Diameter Identity of the node that supports the This AVP contains the DiameterIdentity of the node that supports the
OC_PEER_REPORT feature. This AVP is used to determine if support for OC_PEER_REPORT feature. This AVP is used to determine if support for
the peer overload report is in an adjacent node. The value of this the peer overload report is in an adjacent node. The value of this
AVP should be the same Diameter identity used as part of the CER/CEA AVP should be the same Diameter identity used as part of the Diameter
base Diameter capabilities exchange. Capabilities Exchange procedure defined in [RFC7683].
This extension also adds the OC-Peer-Algo AVP to the OC-Supported- This extension also adds the OC-Peer-Algo AVP to the OC-Supported-
Features AVP. This AVP is used by a reporting node to indicate the Features AVP. This AVP is used by a reporting node to indicate the
abatement algorithm it will use for peer overload reports. abatement algorithm it will use for peer overload reports.
OC-Supported-Features ::= < AVP Header: 621 > OC-Supported-Features ::= < AVP Header: 621 >
[ OC-Feature-Vector ] [ OC-Feature-Vector ]
[ SourceID ] [ SourceID ]
[ OC-Peer-Algo] [ OC-Peer-Algo]
* [ AVP ] * [ AVP ]
6.1.1. OC-Feature-Vector 6.1.1. OC-Feature-Vector
The peer report feature defines a new feature bit is added for the The peer report feature defines a new feature bit for the OC-Feature-
OC-Feature-Vector AVP. Vector AVP.
OC_PEER_REPORT (0x0000000000000010) OC_PEER_REPORT (0x0000000000000010)
When this flag is set by a DOIC node it indicates that the DOIC When this flag is set by a DOIC Node it indicates that the DOIC
node supports the peer overload report type. Node supports the peer overload report type.
6.1.2. OC-Peer-Algo 6.1.2. OC-Peer-Algo
The OC-Peer-Algo AVP (AVP code TBD1) is of type Unsigned64 and The OC-Peer-Algo AVP (AVP code TBD1) is of type Unsigned64 and
contains a 64 bit flags field of announced capabilities of a DOIC contains a 64 bit flags field of announced capabilities of a DOIC
node. The value of zero (0) is reserved. Node. The value of zero (0) is reserved.
Feature bits defined for the OC-Feature-Vector AVP and associated Feature bits defined for the OC-Feature-Vector AVP and associated
with overload abatement algorithms are reused for this AVP. with overload abatement algorithms are reused for this AVP.
6.2. OC-OLR AVP 6.2. OC-OLR AVP
This extension makes no changes to the SequenceNumber or This extension makes no changes to the SequenceNumber or
ValidityDuration AVPs in the OC-OLR AVP. These AVPs are also be used ValidityDuration AVPs in the OC-OLR AVP. These AVPs are also be used
in peer overload reports. in peer overload reports.
The OC_PEER_REPORT feature extends the base Diameter overload The OC_PEER_REPORT feature extends the base Diameter overload
specification by defining a new overload report type of "peer". See specification by defining a new overload report type of "peer". See
section [7.6] in [RFC7683] for a description of the OC-Report-Type section [7.6] in [RFC7683] for a description of the OC-Report-Type
AVP. AVP.
The overload report MUST also include the Diameter identity of the The overload report MUST also include the Diameter identity of the
agent that generated the report. This is necessary to handle the agent that generated the report. This is necessary to handle the
case where there is a non supporting agent between the reporting node case where there is a non supporting agent between the reporting node
and the reacting node. Without the indication of the agent that and the reacting node. Without the indication of the agent that
generated the overload request, the reacting node could erroneously generated the overload report, the reacting node could erroneously
assume that the report applied to the non-supporting node. This assume that the report applied to the non-supporting node. This
could, in turn, result in unnecessary traffic being either could, in turn, result in unnecessary traffic being either diverted
redistributed or throttled. or throttled.
The SourceID AVP is used in the OC-OLR AVP to carry this The SourceID AVP is used in the OC-OLR AVP to carry this
DiameterIdentity. DiameterIdentity.
OC-OLR ::= < AVP Header: 623 > OC-OLR ::= < AVP Header: 623 >
< OC-Sequence-Number > < OC-Sequence-Number >
< OC-Report-Type > < OC-Report-Type >
[ OC-Reduction-Percentage ] [ OC-Reduction-Percentage ]
[ OC-Validity-Duration ] [ OC-Validity-Duration ]
[ SourceID ] [ SourceID ]
skipping to change at page 15, line 23 skipping to change at page 15, line 23
6.2.1. OC-Report-Type AVP 6.2.1. OC-Report-Type AVP
The following new report type is defined for the OC-Report-Type AVP. The following new report type is defined for the OC-Report-Type AVP.
PEER_REPORT 2 The overload treatment should apply to all requests PEER_REPORT 2 The overload treatment should apply to all requests
bound for the peer identified in the overload report. If the peer bound for the peer identified in the overload report. If the peer
identified in the overload report is not a peer to the reacting identified in the overload report is not a peer to the reacting
endpoint then the overload report should be stripped and not acted endpoint then the overload report should be stripped and not acted
upon. upon.
6.3. SourceID 6.3. SourceID AVP
The SourceID AVP (AVP code TBD2) is of type DiameterIdentity and is The SourceID AVP (AVP code TBD2) is of type DiameterIdentity and is
inserted by a Diameter node to indicate the source of the AVP in inserted by a Diameter node to indicate the source of the AVP in
which it is a part. which it is a part.
In the case of peer reports, the SourceID AVP indicates the node that In the case of peer reports, the SourceID AVP indicates the node that
supports this feature (in the OC-Supported-Features AVP) or the node supports this feature (in the OC-Supported-Features AVP) or the node
that generates an overload with a report type of peer (in the OC-OLR that generates an overload with a report type of peer (in the OC-OLR
AVP). AVP).
 End of changes. 40 change blocks. 
61 lines changed or deleted 68 lines changed or added

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