| < 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/ | ||||