draft-ietf-dime-agent-overload-09.txt   draft-ietf-dime-agent-overload-10.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) February 7, 2017 Updates: RFC7683 (if approved) March 7, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: August 11, 2017 Expires: September 8, 2017
Diameter Agent Overload and the Peer Overload Report Diameter Agent Overload and the Peer Overload Report
draft-ietf-dime-agent-overload-09.txt draft-ietf-dime-agent-overload-10.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 August 11, 2017. This Internet-Draft will expire on September 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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 AVP . . . . . . . . . . . . . . . . 14
6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 14 6.1.2. OC-Peer-Algo AVP . . . . . . . . . . . . . . . . . . 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 AVP . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 17
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
1. Introduction 1. Introduction
This specification documents an extension to the Diameter Overload This specification documents an extension to the Diameter Overload
Indication Conveyance (DOIC) [RFC7683] base solution. The extension Indication Conveyance (DOIC) [RFC7683] 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
skipping to change at page 8, line 34 skipping to change at page 8, line 34
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. In this scenario, when doing abatement on the peer overload report. In this scenario, when doing abatement on the
PEER report, the reacting node SHOULD take into consideration the PEER report, the reacting node SHOULD take into consideration the
number of messages already throttled by the handling of the HOST/ number of messages already throttled by the handling of the HOST/
REALM report abatement. REALM report abatement.
Note: The goal is to avoid traffic oscillations that might result Note: The goal is to avoid traffic oscillations that might result
from throttling of messages for both the HOST/REALM overload from throttling of messages for both the HOST/REALM overload
reports and the PEER overload reports. This is especially a reports and the PEER overload reports. This is especially a
concern if both reports are of type LOSS. concern if both reports indicate the LOSS abatement algorithm.
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
skipping to change at page 11, line 22 skipping to change at page 11, line 22
[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 DiameterIdentity of the Diameter peer from which SourceID matches the DiameterIdentity of the Diameter peer from which
the request was received then the report was generated by a Diameter the response message was received then the report was generated by a
peer. 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 DiameterIdentity of the Diameter peer SourceID does not match the DiameterIdentity of the Diameter peer
from which the request was received then the reacting node MUST from which the response message was received then the reacting node
ignore the overload report. MUST ignore the overload report.
If the Peer Report OLR was received from a Diameter peer then the Note: Under normal circumstances, a Diameter node will not add a
peer report when sending to a peer that does not support this
extension. This requirement is to handle the case where peer
reports are erroneously or maliciously inserted into response
messages.
If the peer report 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 peer report is for an existing overload condition if the reacting
has an OCS that matches the received OLR. For a peer report, this node has an OCS that matches the received peer report. For a peer
means it matches the Application-ID and the peer's DiameterIdentity report, this means it matches the Application-ID and the peer's
in an existing OCS entry. DiameterIdentity in an existing OCS entry.
If the OLR is for an existing overload condition then it MUST If the peer report 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 peer report is a retransmission or an update to the
OLR. existing OLR.
If the sequence number for the received OLR is greater than the If the sequence number for the received peer report is greater than
sequence number stored in the matching OCS entry then the reacting the sequence number stored in the matching OCS entry then the
node MUST update the matching OCS entry. reacting 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 peer report is less than or
the sequence number in the matching OCS entry then the reacting node equal to the sequence number in the matching OCS entry then the
MUST silently ignore the received OLR. The matching OCS MUST NOT be reacting node MUST silently ignore the received peer report. The
updated in this case. matching OCS MUST NOT be updated in this case.
If the received OLR is for a new overload condition then the reacting If the received peer report is for a new overload condition then the
node MUST generate a new OCS entry for the overload condition. reacting node MUST generate a new OCS entry for the overload
condition.
For a peer report this means it creates an OCS entry with a For a peer report this means it creates an OCS entry with a
DiameterIdentity 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 peer report contains a validity duration of zero
the reacting node MUST update the OCS entry as being expired. ("0") then 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
skipping to change at page 14, line 11 skipping to change at page 14, line 15
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 AVP
The peer report feature defines a new feature bit for the OC-Feature- The peer report feature defines a new feature bit for the 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 AVP
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 OC_Sequence_Number or
ValidityDuration AVPs in the OC-OLR AVP. These AVPs are also be used OC_Validity_Duration AVPs in the OC-OLR AVP. These AVPs are also be
in peer overload reports. used 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
skipping to change at page 15, line 38 skipping to change at page 15, line 43
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).
It contains the DiameterIdentity of the inserting node. This is used It contains the DiameterIdentity of the inserting node. This is used
by other Diameter nodes to determine the node that inserted the by other Diameter nodes to determine the node that inserted the
enclosing AVP that contains the SourceID AVP. enclosing AVP that contains the SourceID AVP.
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-Peer-Algo TBD1 x.x Unsigned64 | | V | |OC-Peer-Algo TBD1 6.1.2 Unsigned64 | | V |
|SourceID TBD2 x.x DiameterIdentity | | V | |SourceID TBD2 6.3 DiameterIdentity | | V |
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
7. IANA Considerations 7. IANA Considerations
7.1. AVP codes 7.1. AVP Codes
New AVPs defined by this specification are listed in Section 6.4. New AVPs defined by this specification are listed in Section 6.4.
All AVP codes are allocated from the 'Authentication, Authorization, All AVP codes are allocated from the 'Authentication, Authorization,
and Accounting (AAA) Parameters' AVP Codes registry. and Accounting (AAA) Parameters' AVP Codes registry.
One new OC-Report-Type AVP value is defined in Section 6.2.1 One new OC-Report-Type AVP value is defined in Section 6.2.1
7.2. New registries 7.2. New Registries
There are no new IANA registries introduced by this document. There are no new IANA registries introduced by this document.
The values used for the OC-Peer-Algo AVP are the subset of the "OC- The values used for the OC-Peer-Algo AVP are the subset of the "OC-
Feature-Vector AVP Values (code 622)" registry. Only the values in Feature-Vector AVP Values (code 622)" registry. Only the values in
that registry that apply to overload abatement algorithms apply to that registry that apply to overload abatement algorithms apply to
the OC-Peer-Algo AVP. the OC-Peer-Algo AVP.
8. Security Considerations 8. Security Considerations
 End of changes. 25 change blocks. 
45 lines changed or deleted 52 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/