draft-ietf-dime-agent-overload-02.txt   draft-ietf-dime-agent-overload-03.txt 
Diameter Maintenance and Extensions (DIME) S. Donovan Diameter Maintenance and Extensions (DIME) S. Donovan
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track August 31, 2015 Intended status: Standards Track October 14, 2015
Expires: March 3, 2016 Expires: April 16, 2016
Diameter Agent Overload Diameter Agent Overload and the Peer Overload Report
draft-ietf-dime-agent-overload-02.txt draft-ietf-dime-agent-overload-03.txt
Abstract Abstract
This specification documents an extension to the Diameter Overload This specification documents an extension to the Diameter Overload
Indication Conveyance (DOIC) base solution. The extension addresses Indication Conveyance (DOIC) base solution. The extension defines
the handling of occurrences of overload of a Diameter agent, or more the Peer overload report type. The initial use case for the Peer
generally, a Diameter peer. report is the handling of occurrences of overload of a Diameter
agent.
Requirements Requirements
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].
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 39 skipping to change at page 1, line 40
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 March 3, 2016. This Internet-Draft will expire on April 16, 2016.
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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Peer Report Use Cases . . . . . . . . . . . . . . . . . . . . 4 3. Peer Report Use Cases . . . . . . . . . . . . . . . . . . . . 4
3.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 5 3.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 4
3.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 6 3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 5
3.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 7 3.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 6
3.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 8 3.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 7
3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 8 3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . 9 5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 8
5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 9 5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 9
5.2. Peer Report Overload Report Handling . . . . . . . . . . 11 5.2. Peer Report Overload Report Handling . . . . . . . . . . 10
5.2.1. Overload Control State . . . . . . . . . . . . . . . 11 5.2.1. Overload Control State . . . . . . . . . . . . . . . 10
5.2.2. Reporting Node Maintenance of Peer Report OCS . . . . 12 5.2.2. Reporting Node Maintenance of Peer Report OCS . . . . 11
5.2.3. Reacting Node Maintenance of Peer Report OCS . . . . 12 5.2.3. Reacting Node Maintenance of Peer Report OCS . . . . 11
5.2.4. Peer Report Reporting Node Behavior . . . . . . . . . 14 5.2.4. Peer Report Reporting Node Behavior . . . . . . . . . 13
5.2.5. Peer Report Reacting Node Behavior . . . . . . . . . 14 5.2.5. Peer Report Reacting Node Behavior . . . . . . . . . 13
6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 15 6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 15 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14
6.1.1. OC-Feature-Vector . . . . . . . . . . . . . . . . . . 15 6.1.1. OC-Feature-Vector . . . . . . . . . . . . . . . . . . 14
6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 16 6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 15
6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 17 6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 16
6.3. OC-SourceID . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. OC-SourceID . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 17 6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. Normative References . . . . . . . . . . . . . . . . . . . . 18 10. Normative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
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. requesting a reduction of traffic. It also defines new overload
report type, the Peer overload report type, that is used for handling
of agent overload conditions. The Peer overload report type is
defined in a generic fashion so that it can also be used for other
Diameter overload scenaios.
The base Diameter overload specification [I-D.ietf-dime-ovli] The base Diameter overload specification [I-D.ietf-dime-ovli]
addresses the handling of overload when a Diameter endpoint (a addresses the handling of overload when a Diameter endpoint (a
Diameter Client or Diameter Server as defined in [RFC6733]) becomes Diameter Client or Diameter Server as defined in [RFC6733]) becomes
overloaded. 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 is 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
skipping to change at page 3, line 33 skipping to change at page 3, line 37
traffic than it was configured to handle. For a more detailed traffic than it was configured to handle. For a more detailed
discussion of what can cause the overload of Diameter nodes, refer to discussion of what can cause the overload of Diameter nodes, refer to
the Diameter Overload Requirements [RFC7068]. the Diameter Overload Requirements [RFC7068].
This document defines a new overload report type to communicate This document defines a new overload report type to communicate
occurrences of agent overload. This report type works for the "Loss" occurrences of agent overload. This report type works for the "Loss"
overload mitigation algorithm defined in [I-D.ietf-dime-ovli] and is overload mitigation algorithm defined in [I-D.ietf-dime-ovli] and is
expected to work for other overload abatement algorithms defined in expected to work for other overload abatement algorithms defined in
extensions to the DOIC solution. extensions to the DOIC solution.
The handling of endpoint overload and agent overload is very similar.
The primary differences are the following:
o Endpoint overload is handled as close to the originator of the
traffic as possible.
o Agent overload is handled by the previous hop Diameter Node.
o Endpoint overload mitigation deals with traffic targeted for a
single Diameter application. As such, it is assumed that an
overload report impacts just the application implied by the
message carrying the overload report.
o Agent overload deals with all traffic targeted for an agent,
independent of the application. As such, a single agent overload
report can impact multiple applications.
Editor's Note: Open Issue - Does a peer report apply to the
implicitly communicated application-id in the same way as host and
realm reports do or does it apply to all applications handled by the
peer? Do we need the ability for to support both cases?
Open Issue - To support the ability of an agent to select a different
abatement algorithm than endpoints, we probably need to extend the
OC-Supported-Features AVP to include an OC-Abatement-Algorithm AVP.
This is currently shown to be in the OC-OLR AVP but needs to be moved
as this information is needed prior to receiving the OC-OLR. It
probably needs to be changed to OC-Peer-Abatement-Algorithm.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
Editors note - These definitions need to be made consistent with the Editors note - These definitions need to be made consistent with the
base Diameter overload specification defined in [I-D.ietf-dime-ovli]. base Diameter overload specification defined in [I-D.ietf-dime-ovli].
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.
skipping to change at page 4, line 47 skipping to change at page 4, line 21
DIOC Node DIOC Node
A Diameter Node that supports the DOIC solution defined in A Diameter Node that supports the DOIC solution defined in
[I-D.ietf-dime-ovli]. [I-D.ietf-dime-ovli].
3. Peer Report Use Cases 3. Peer Report Use Cases
This section outlines representative use cases for the peer report This section outlines representative use cases for the peer report
used to communicate agent overload. used to communicate agent overload.
There are two primary classes of use cases, those involving the There are two primary classes of use cases currently identified,
overload of agents and those involving overload of Diameter endpoints those involving the overload of agents and those involving overload
(Diameter Clients and Diameter Servers). of Diameter endpoints (Diameter Clients and Diameter Servers) that
wish to use an overload algorithm suited controlling traffic sent
from a peer.
3.1. Diameter Agent Overload Use Cases 3.1. Diameter Agent Overload Use Cases
The agent overload extension must support the following use cases. The peer report needs to support the following use cases.
3.1.1. Single Agent 3.1.1. Single Agent
This use case is illustrated in Figure 1. In this case, the client This use case is illustrated in Figure 1. In this case, the client
sends all traffic through the single agent. If there is a failure in sends all traffic through the single agent. If there is a failure in
the agent then the client is unable to send Diameter traffic toward the agent then the client is unable to send Diameter traffic toward
the server. the server.
+-+ +-+ +-+ +-+ +-+ +-+
|c|----|a|----|s| |c|----|a|----|s|
skipping to change at page 7, line 48 skipping to change at page 7, line 23
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 2.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.
Editor's note: Probably need to elaborate the reasoning behind the
need for the agent overload report being handled by the previous hop
agent.
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 2.2. If the overload can be addressed using diversion then section 2.2. If the overload can be addressed using diversion then
this approach should be taken. this approach should be taken.
If both of the agents have requested a reduction in traffic then the If both of the agents have requested a reduction in traffic then the
previous hop agent must start throttling the appropriate number of previous hop agent must start throttling the appropriate number of
transactions. When throttling requests, an agent uses the same error transactions. When throttling requests, an agent uses the same error
responses as defined in the base DOIC specification responses as defined in the base DOIC specification
[I-D.ietf-dime-ovli]. [I-D.ietf-dime-ovli].
3.2. Diameter Endpoint Use Cases 3.2. Diameter Endpoint Use Cases
This section outlines use cases for the peer report feature involving This section outlines use cases for the peer overload report
Diameter Clients and Diameter Servers. involving Diameter Clients and Diameter Servers.
3.2.1. Hop-by-hop Abatement Algorithms 3.2.1. Hop-by-hop Abatement Algorithms
It is envisioned that abatement algorithms will be defined that will It is envisioned that abatement algorithms will be defined that will
support the option for Diameter Endpoints to send peer reports. For support the option for Diameter Endpoints to send peer reports. For
instance, it is envisioned that one usage scenario for the rate instance, it is envisioned that one usage scenario for the rate
algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked
on by the DIME working group as this is written, will involve on by the DIME working group as this is written, will involve
abatement being done on a hop-by-hop basis. abatement being done on a hop-by-hop basis.
This rate deployment scenario would involve Diameter Endpoints This rate deployment scenario would involve Diameter Endpoints
generating peer reports and selecting the rate algorithm for generating peer reports and selecting the rate algorithm for
abatement of overload conditions. abatement of overload conditions.
4. Interaction Between Host/Realm and Peer Overload Reports 4. Interaction Between Host/Realm and Peer Overload Reports
It is possible that both an agent and a server in the path of a It is possible that both an agent and an end-point in the path of a
transaction are overloaded at the same time. When this occurs, transaction are overloaded at the same time. When this occurs,
Diameter entities will need to handle both overload reports. In this Diameter entities need to handle both overload reports. In this
scenario the reacting node should first handle the throttling of the scenario the reacting node should first handle the throttling of the
overloaded host or realm. Any messages that survive throttling due overloaded host or realm. Any messages that survive throttling due
to host or realm reports should then go through abatement for the to host or realm reports should then go through abatement for the
peer overload report. peer overload report.
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.
skipping to change at page 9, line 24 skipping to change at page 8, line 44
Server that originates the Diamter request or a Diameter Agent Server that originates the Diamter request or a Diameter Agent
that relays the request. that relays the request.
Support for the peer report feature does not impact the logic for Support for the peer report feature does not impact the logic for
setting of other feature bits in the OC-Feature-Vector AVP. setting of other feature bits in the OC-Feature-Vector AVP.
When sending a request a DOIC node that supports the Peer Report When sending a request a DOIC node that supports the Peer Report
feature MUST include an OC-SourceID AVP in the OC-Supported-Features feature MUST include an OC-SourceID AVP in the OC-Supported-Features
AVP with its own DiameterID. AVP with its own DiameterID.
Note: This allows the next DOIC node in the path of the request to Note: This allows the DOIC nodes in the path of the request to
determine if the indication of support came from a Diameter peer determine if the indication of support came from a Diameter peer
or if the request traversed a node that does not support the peer or if the request traversed a node that does not support the peer
feature. feature.
When relaying a request that includes an OC-SourceID AVP in the OC-
Supported-Features AVP, a DOIC node that supuports the Peer Report
feature must remove the received OC-SourceID AVP and replace it with
an OC-SourceID AVP containing its own Diameter identity.
5.1.2. Reporting Node Behavior 5.1.2. Reporting Node Behavior
When receiving a request a DOIC node that supports the Peer Report When receiving a request a DOIC node that supports the 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 Peer or not the peer from which the request was received supports the Peer
Report feature. 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 to insert OC-Supported- as a peer-report reporting node and needs send OC-OLR reports of
Feature AVP indicating support for the OLR_PEER_REPORT feature and type PEER_REPORT in answer messages. The peer overload reports
OC-OLR reports of type PEER_REPORT into answer messages. These are only included in answer messages being sent to peers that
AVP OLR are only included in answer messages being sent to peers support the OLR_PEER_REPORT feature.
that support the OLR_PEER_REPORT feature.
The following are indications that the peer does not support the The following are indications that the peer does not support the
OLR_PEER_REPORT feature: OLR_PEER_REPORT feature:
The request does not contain an OC-Supported-Features AVP. The request does not contain an OC-Supported-Features AVP.
The received request contains an OC-Supported-Features AVP with no The received request contains an OC-Supported-Features AVP with no
OC-Feature-Vector. OC-Feature-Vector.
The received request contains an OC-Supported-Features AVP with a The received request contains an OC-Supported-Features AVP with a
skipping to change at page 10, line 19 skipping to change at page 9, line 40
OC-Feature-Vector with the OLR_PEER_REPORT feature bit set but OC-Feature-Vector with the OLR_PEER_REPORT feature bit set but
with an OC-SourceID AVP with a DiameterID that does not match the with an OC-SourceID AVP with a DiameterID that does not match the
DiameterID of the peer from which the request was received. DiameterID of the peer from which the request was received.
The peer supports the OLR_PEER_REPORT feature if the received request The peer supports the OLR_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 OLR_PEER_REPORT feature bit set and with an OC-SourceID AVP with the OLR_PEER_REPORT feature bit set and with an OC-SourceID AVP with
a Diameter ID that matches the DiameterID of the peer from which the a Diameter ID that matches the DiameterID of the peer from which the
request was received. request was received.
When receiving a request a DOIC node that supports the Peer Report When relaying an answer message, a reporting node that supports the
feature MUST remove any received OC-SourceID AVP from the OC-
Supported-Features AVP. This is done to prevent the OC-SourceID AVP
from being included in a relayed message through a node that supports
the Peer Report feature.
Note: If the DOIC node relays the message then it will insert an
OC-SourceID AVP with its own DiameterID in the OC-Supported-
Features AVP in the relayed message.
When sending an answer message, a reporting node that supports the
OLR_PEER_REPORT feature MUST strip any SourceID AVP from the OC- OLR_PEER_REPORT feature MUST strip any SourceID AVP from the OC-
Supported-Features AVP. 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
OLR_PEER_REPORT feature MUST determine if the peer to which the OLR_PEER_REPORT feature MUST determine if the peer to which the
answer is to be sent supports the OLR_PEER_REPORT feature. answer is to be sent supports the OLR_PEER_REPORT feature.
If the peer supports the OLR_PEER_REPORT feature then the reporting If the peer supports the OLR_PEER_REPORT feature then the reporting
node MUST indicate support for the feature in the Supported-Features node MUST indicate support for the feature in the Supported-Features
AVP. AVP.
If the peer supports the OLR_PEER_REPORT feature then the reporting If the peer supports the OLR_PEER_REPORT feature then the reporting
node MUST insert the OC-SourceID AVP in the OC-Supported-Features AVP node MUST insert the OC-SourceID AVP in the OC-Supported-Features AVP
in the answer message. in the answer message.
If the peer supports the OLR_PEER_REPORT feature then the reporting If the peer supports the OLR_PEER_REPORT feature then the reporting
node MUST insert the OC-Peer-Algo AVP in the OC-Supported-Features node MUST insert the OC-Peer-Algo AVP in the OC-Supported-Features
AVP. The OC-Peer-Algo AVP MUST indicate the overload abatement AVP. The OC-Peer-Algo AVP MUST indicate the overload abatement
algorithm that the reporting node wants reacting nodes to use should algorithm that the reporting node wants the reacting nodes to use
the reporting node send a peer overload report as a result of should the reporting node send a peer overload report as a result of
becoming overloaded. becoming overloaded.
5.2. Peer Report Overload Report Handling 5.2. Peer Report 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
skipping to change at page 11, line 26 skipping to change at page 10, line 37
5.2.1.1. Reporting Node Peer Report OCS 5.2.1.1. Reporting Node Peer Report OCS
A DOIC Node that supports the Peer Report feature SHOULD maintain A DOIC Node that supports the Peer Report feature SHOULD maintain
Reporting Node Peer Report OCS. This is used to record overload Reporting Node Peer Report OCS. This is used to record overload
events and build overload reports at the reporting node. events and build overload reports at the reporting node.
If different abatement specific contents are sent to each peer then If different abatement specific contents are sent to each peer then
the reporting node MUST maintain a separate peer node peer report OCS the reporting node MUST maintain a separate peer node peer report OCS
entry per peer to which a peer overload report is sent. entry per peer to which a peer overload report is sent.
The rate overload abatement algorithm allows for different rates Note: The rate overload abatement algorithm allows for different
to be sent to each peer. rates to be sent to each peer.
The Reporting Node Peer Report OCS entry MAY include the following The Reporting Node Peer Report OCS entry MAY include the following
information (the actual information stored is an implementation information (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
skipping to change at page 12, line 7 skipping to change at page 11, line 16
5.2.1.2. Reacting Node Peer Report OCS 5.2.1.2. Reacting Node Peer Report OCS
A DOIC node that supports the Peer Report feature SHOULD maintain A DOIC node that supports the Peer Report feature SHOULD maintain
Reacting Node Peer Report OCS for each peer with which it Reacting Node Peer Report OCS for each peer with which it
communicates. This is used to record overload reports received from communicates. This is used to record overload reports received from
peer nodes. peer nodes.
A Reacting Node Peer Report OCS entry is identified by the DiameterID A Reacting Node Peer Report OCS entry is identified by the DiameterID
of the peer as communicated during the RFC6733 defined Capability of the peer as communicated during the RFC6733 defined Capability
Exchange procedure Exchange procedure.
The Reacting Node Peer Report OCS entry MAY include the following The Reacting Node Peer Report OCS entry MAY include the following
information (the actual information stored is an implementation information (the actual information stored is an implementation
decision): decision):
o Sequence number o Sequence number
o Expiration Time o Expiration Time
o Abatement Algorithm o Abatement Algorithm
skipping to change at page 12, line 33 skipping to change at page 11, line 42
A reporting node SHOULD create a new Reporting Node Peer Report OCS A reporting node SHOULD create a new Reporting Node Peer Report OCS
entry Section 5.2.1.1 in an overload condition and sending a peer entry Section 5.2.1.1 in an overload condition and sending a peer
overload report to a peer for the first time. overload report to a peer for the first time.
If the reporting node knows that there are no reacting nodes If the reporting node knows that there are no reacting nodes
supporting the Peer Report feature then the reporting node can supporting the Peer Report feature then the reporting node can
choose to not create OCS entries. choose to not create OCS entries.
All rules for managing the reporting node OCS entries defined in All rules for managing the reporting node OCS entries defined in
[DOIC] apply to the peer report. [I-D.ietf-dime-ovli] 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 an 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 the DiameterID in the SourceID contained in the OLR matches the If the DiameterID in the SourceID contained in the OLR matches the
DiameterID of the peer from which the request was received then the DiameterID of the peer from which the request was received then the
report was received from a Diameter peer. report was received from a Diameter peer.
If a reacting node receives an OC-OLR AVP of type peer and the OC- If a reacting node receives an OC-OLR AVP of type peer and the OC-
SourceID does not match the ID of the Diameter peer from which the SourceID does not match the ID of the Diameter peer from which the
request was received then the reacting node MUST strip the OC-OLR AVP request was received then the reacting node MUST ignore the overload
from the message and not use it to update reacting node peer report report.
OCS entries.
In all cases, if the reacting node is a relay then it MUST strip the
OC-OLR AVP from the message.
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. has an OCS that matches the received OLR. For a peer report-type
this means the DiameterID received in the SourceID AVP matches the
For a peer report-type this means the DiameterID received in the DiameterID of an existing peer report OLR.
SourceID AVP matches the DiameterID of an existing peer report OLR.
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.
Editor's note: The above four paragraphs are copied form the DOIC
specification. Is it possible to include this behavior by
reference or do we need to include all of these statements in this
specification as well.
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 an
DiameterID from the SourceID AVP in the received OC-OLR AVP. DiameterID 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").
skipping to change at page 14, line 29 skipping to change at page 13, line 32
report feature to determine if the report was received from a 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 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.
If the request matches and active OCS then the reacting node MUST If the request matches and active OCS then the reacting node MUST
apply abatement treatment on the request. The abatement treatment apply abatement treatment on the request. The abatement treatment
applied depends on the abatement algorithm stored 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 a host-routed request, as defined in [I-D.ietf-dime-ovli], is
selected for abatement and the request must be routed to the DOIC
node that generated the peer overload report -- meaning that the
request is a host-routed request as defined in the DOIC specification
-- then the reacting node MUST throttle the request.
This would result from an overloaded Diameter endpoint (Diameter
Server or Diameter Client) sending a peer overload report and the
request contains a Destination-Host AVP with a DiameterID that
matches the DiameterID in the SourceID AVP received in the peer
overload report.
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 [I-D.ietf-dime-ovli]. appropriate error as defined in [I-D.ietf-dime-ovli].
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 it the reporting node validity duration of zero ("0"), meaning that it the reporting node
skipping to change at page 15, line 39 skipping to change at page 14, line 29
A supporting node must also include the OC-SourceID AVP in the OC- A supporting node must also include the OC-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 Diameter Identity of the node that supports the
OLR_PEER_REPORT feature. This AVP is used to determine if support OLR_PEER_REPORT feature. This AVP is used to determine if support
for the peer overload report is in an adjacent node. The value of for 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 this AVP should be the same Diameter identity used as part of the
CER/CEA base Diameter capabilities exchange. CER/CEA base Diameter capabilities exchange.
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
abatement algorithm it will use for peer overload reports.
OC-Supported-Features ::= < AVP Header: TBD1 > OC-Supported-Features ::= < AVP Header: TBD1 >
[ OC-Feature-Vector ] [ OC-Feature-Vector ]
[ OC-SourceID ] [ OC-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 is added for the
OC-Feature-Vector AVP. OC-Feature-Vector AVP.
skipping to change at page 16, line 4 skipping to change at page 14, line 45
[ OC-SourceID ] [ OC-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 is added for the
OC-Feature-Vector AVP. OC-Feature-Vector AVP.
OLR_PEER_REPORT (0x0000000000000010) OLR_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 TBD6) 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 in for this AVP. with overload abatement algorithms are reused in for this AVP.
Editor's node: This is to avoid the need for an additional IANA Editor's node: This is to avoid the need for an additional IANA
registry. registry.
6.2. OC-OLR AVP 6.2. OC-OLR AVP
skipping to change at page 17, line 17 skipping to change at page 16, line 17
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. OC-SourceID 6.3. OC-SourceID
The SourceID AVP (AVP code TBD) is of type DiameterIdentity and is The SourceID AVP (AVP code TBD2) is of type DiameterIdentity and is
inserted by the DOIC node that either indicates support for this inserted by the DOIC node that either indicates support for this
feature (in the OC-Supported-Features AVP) or that generates an OC- feature (in the OC-Supported-Features AVP) or that generates an OC-
OLR AVP with a report type of peer. OLR AVP with a report type of peer.
It contains the Diameter Identity of the inserting node. This is It contains the Diameter Identity of the inserting node. This is
used by other DOIC nodes to determine if the a peer indicated support used by other DOIC nodes to determine if the a peer indicated support
this feature or inserted the peer report. this feature or inserted the peer report.
6.4. Attribute Value Pair flag rules 6.4. Attribute Value Pair flag rules
+---------+ +---------+
|AVP flag | |AVP flag |
|rules | |rules |
+----+----+ +----+----+
AVP Section | |MUST| AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT| Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
|OC-SourceID TBD1 x.x Unsigned64 | | V | |OC-SourceID TBD1 x.x Unsigned64 | | V |
|OC-Peer-Algo TBD1 x.x Unsigned64 | | V | |OC-Peer-Algo TBD2 x.x Unsigned64 | | V |
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
7. IANA Considerations 7. IANA Considerations
Editors note: This section will be completed once the base overload Editors note: This section will be completed once the base overload
document has finished the definition of extension IANA requirements. document has finished the definition of extension IANA requirements.
8. Security Considerations 8. Security Considerations
Agent overload is an extension to the based Diameter overload Agent overload is an extension to the base Diameter overload
mechanism. As such, all of the security considerations outlined in mechanism. As such, all of the security considerations outlined in
[I-D.ietf-dime-ovli] apply to the agent overload scenarios. [I-D.ietf-dime-ovli] apply to the agent overload scenarios.
It is possible that the malicious insertion of an agent overload It is possible that the malicious insertion of an agent overload
report could have a bigger impact on a Diameter network as agents can report could have a bigger impact on a Diameter network as agents can
be concentration points in a Diameter network. Where an end-point be concentration points in a Diameter network. Where an end-point
report would impact the traffic sent to a single Diameter server, for report would impact the traffic sent to a single Diameter server, for
example, a peer report could throttle all traffic to the Diameter example, a peer report could throttle all traffic to the Diameter
network. network.
 End of changes. 37 change blocks. 
132 lines changed or deleted 89 lines changed or added

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