< draft-ietf-dime-agent-overload-04.txt   draft-ietf-dime-agent-overload-05.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 March 18, 2016 Intended status: Standards Track May 19, 2016
Expires: September 19, 2016 Expires: November 20, 2016
Diameter Agent Overload and the Peer Overload Report Diameter Agent Overload and the Peer Overload Report
draft-ietf-dime-agent-overload-04.txt draft-ietf-dime-agent-overload-05.txt
Abstract Abstract
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
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 40 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 September 19, 2016. This Internet-Draft will expire on November 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 39 skipping to change at page 2, line 39
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 . . . . . . . . . 13 5.2.4. Peer Report Reporting Node Behavior . . . . . . . . . 13
5.2.5. Peer Report Reacting Node Behavior . . . . . . . . . 13 5.2.5. Peer Report Reacting Node Behavior . . . . . . . . . 13
6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14 6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14
6.1.1. OC-Feature-Vector . . . . . . . . . . . . . . . . . . 14 6.1.1. OC-Feature-Vector . . . . . . . . . . . . . . . . . . 14
6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 15 6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 15
6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15 6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15
6.3. OC-SourceID . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. SourceID . . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 16 6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. Normative References . . . . . . . . . . . . . . . . . . . . 17 10. Normative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
skipping to change at page 8, line 36 skipping to change at page 8, line 36
an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.
Note: The sender of a request can be a Diameter Client or Diameter Note: The sender of a request can be a Diameter Client or Diameter
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 OC_PEER_REPORT feature does not impact the logic for Support for the OC_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 OC_PEER_REPORT When sending a request a DOIC node that supports the OC_PEER_REPORT
feature MUST include an OC-SourceID AVP in the OC-Supported-Features feature MUST include a SourceID AVP in the OC-Supported-Features AVP
AVP with its own DiameterIdentity. with its own DiameterIdentity.
Note: This allows the DOIC nodes 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 or if the request traversed a node that does not support the
OC_PEER_REPORT feature. OC_PEER_REPORT feature.
When relaying a request that includes an OC-SourceID AVP in the OC- When relaying a request that includes a SourceID AVP in the OC-
Supported-Features AVP, a DOIC node that supuports the OC_PEER_REPORT Supported-Features AVP, a DOIC node that supuports the OC_PEER_REPORT
feature must remove the received OC-SourceID AVP and replace it with feature must remove the received SourceID AVP and replace it with a
an OC-SourceID AVP containing its own Diameter identity. 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 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
skipping to change at page 9, line 31 skipping to change at page 9, line 31
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
OC-Feature-Vector with the OC_PEER_REPORT feature bit cleared. OC-Feature-Vector with the OC_PEER_REPORT feature bit cleared.
The received request contains an OC-Supported-Features AVP with a The received request contains an OC-Supported-Features AVP with a
OC-Feature-Vector with the OC_PEER_REPORT feature bit set but with OC-Feature-Vector with the OC_PEER_REPORT feature bit set but with
an OC-SourceID AVP with a DiameterIdentity that does not match the a SourceID AVP with a DiameterIdentity that does not match the
DiameterIdentity of the peer from which the request was received. DiameterIdentity of the peer from which the request was received.
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 an OC-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 Diameter ID that matches the DiameterIdentity of the peer from which
the request was received. the request was received.
When relaying an answer message, a reporting node that supports the When relaying an answer message, a reporting node that supports the
OC_PEER_REPORT feature MUST strip any SourceID AVP from the OC- OC_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
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
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 OC_PEER_REPORT feature then the reporting If the peer supports the OC_PEER_REPORT feature then the reporting
node MUST insert the OC-SourceID AVP in the OC-Supported-Features AVP node MUST insert the SourceID AVP in the OC-Supported-Features AVP in
in the answer message. the answer message.
If the peer supports the OC_PEER_REPORT feature then the reporting If the peer supports the OC_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 the reacting nodes to use algorithm that the reporting node wants the reacting nodes to use
should 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
skipping to change at page 12, line 9 skipping to change at page 12, line 9
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 the DiameterID in the SourceID contained in the OLR matches the If the DiameterID in the SourceID contained in the OLR matches the
DiameterIdentity of the peer from which the request was received then DiameterIdentity of the peer from which the request was received then
the report was received from a Diameter peer. the 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
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 ignore the overload request was received then the reacting node MUST ignore the overload
report. report.
In all cases, if the reacting node is a relay then it MUST strip the In all cases, if the reacting node is a relay then it MUST strip the
OC-OLR AVP from the message. 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.
skipping to change at page 13, line 20 skipping to change at page 13, line 20
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 nodes transaction state. reporting nodes transaction state.
The reporting node MUST include its DiameterIdentity in the OC- The reporting node MUST include its DiameterIdentity in the SourceID
SourceID AVP in the OC-OLR AVP. This is used by DOIC nodes that AVP in the OC-OLR AVP. This is used by DOIC nodes that support the
support the OC_PEER_REPORT feature to determine if the report was OC_PEER_REPORT feature to determine if the report was received from a
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.
skipping to change at page 14, line 20 skipping to change at page 14, line 20
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 agents peer. need for overload abatement handling by the agents peer.
A supporting node must also include the OC-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 Diameter Identity 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 CER/CEA
base Diameter capabilities exchange. base Diameter capabilities exchange.
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: TBD1 > OC-Supported-Features ::= < AVP Header: TBD1 >
[ OC-Feature-Vector ] [ OC-Feature-Vector ]
[ OC-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 is added for the
OC-Feature-Vector AVP. OC-Feature-Vector AVP.
OC_PEER_REPORT (0x0000000000000010) OC_PEER_REPORT (0x0000000000000010)
skipping to change at page 15, line 34 skipping to change at page 15, line 34
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 request, 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
redistributed or throttled. redistributed or throttled.
The OC-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: TBD2 > OC-OLR ::= < AVP Header: TBD2 >
< OC-Sequence-Number > < OC-Sequence-Number >
< OC-Report-Type > < OC-Report-Type >
[ OC-Reduction-Percentage ] [ OC-Reduction-Percentage ]
[ OC-Validity-Duration ] [ OC-Validity-Duration ]
[ OC-Source-ID ] [ SourceID ]
* [ AVP ] * [ AVP ]
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. OC-SourceID 6.3. SourceID
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 the DOIC node that either indicates support for this inserted by a Diameter node to indicate the source of the AVP in
feature (in the OC-Supported-Features AVP) or that generates an OC- which it is a part.
OLR AVP with a report type of peer.
It contains the Diameter Identity of the inserting node. This is In the case of peer reports, the SourceID AVP indicates the node that
used by other DOIC nodes to determine if the a peer indicated support support for this feature (in the OC-Supported-Features AVP) or the
this feature or inserted the peer report. node that generates an overload with a report type of peer (in the
OC-OLR AVP).
It contains the DiameterIdentity of the inserting node. This is used
by other Diameter nodes to determine the node that inserted the
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-SourceID TBD1 x.x DiameterIdentity | | V | |SourceID TBD1 x.x DiameterIdentity | | V |
|OC-Peer-Algo TBD2 x.x Unsigned64 | | V | |OC-Peer-Algo TBD2 x.x Unsigned64 | | 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. All New AVPs defined by this specification are listed in Section 6. All
AVP codes are allocated from the 'Authentication, Authorization, and AVP codes are allocated from the 'Authentication, Authorization, and
Accounting (AAA) Parameters' AVP Codes registry. Accounting (AAA) Parameters' AVP Codes registry.
 End of changes. 20 change blocks. 
31 lines changed or deleted 35 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/