--- 1/draft-ietf-dime-agent-overload-10.txt 2017-03-22 14:13:11.879474379 -0700 +++ 2/draft-ietf-dime-agent-overload-11.txt 2017-03-22 14:13:11.915475242 -0700 @@ -1,19 +1,19 @@ Diameter Maintenance and Extensions (DIME) S. Donovan Internet-Draft Oracle -Updates: RFC7683 (if approved) March 7, 2017 +Updates: RFC7683 (if approved) March 22, 2017 Intended status: Standards Track -Expires: September 8, 2017 +Expires: September 23, 2017 Diameter Agent Overload and the Peer Overload Report - draft-ietf-dime-agent-overload-10.txt + draft-ietf-dime-agent-overload-11.txt Abstract This specification documents an extension to RFC 7683 (Diameter Overload Indication Conveyance (DOIC)) base solution. The extension defines the Peer overload report type. The initial use case for the Peer report is the handling of occurrences of overload of a Diameter agent. Requirements @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 8, 2017. + This Internet-Draft will expire on September 23, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -53,53 +53,53 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 3. Peer Report Use Cases . . . . . . . . . . . . . . . . . . . . 4 3.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 4 - 3.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 4 - 3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 5 + 3.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 5 + 3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 6 3.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 7 - 3.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 7 + 3.2. Diameter Endpoint Use Cases . . . . . . . . . . . . . . . 8 3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 8 4. Interaction Between Host/Realm and Peer Overload Reports . . 8 5. Peer Report Behavior . . . . . . . . . . . . . . . . . . . . 8 - 5.1. Capability Announcement . . . . . . . . . . . . . . . . . 8 - 5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 8 + 5.1. Capability Announcement . . . . . . . . . . . . . . . . . 9 + 5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 9 5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 9 5.2. Peer Overload Report Handling . . . . . . . . . . . . . . 10 5.2.1. Overload Control State . . . . . . . . . . . . . . . 10 5.2.2. Reporting 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.5. Peer-Report Reacting Node Behavior . . . . . . . . . 12 - 6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 13 - 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 13 + 5.2.5. Peer-Report Reacting Node Behavior . . . . . . . . . 13 + 6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14 + 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14 6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 14 6.1.2. OC-Peer-Algo AVP . . . . . . . . . . . . . . . . . . 14 - 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 14 + 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15 6.3. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15 - 6.4. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 15 + 6.4. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 7.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. New Registries . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Informative References . . . . . . . . . . . . . . . . . 17 10.2. Normative References . . . . . . . . . . . . . . . . . . 17 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) [RFC7683] base solution. The extension defines the Peer overload report type. The initial use case for the Peer report is the handling of occurrences of overload of a Diameter agent. This document defines the behavior of Diameter nodes when Diameter @@ -132,31 +132,36 @@ the Diameter Overload Requirements [RFC7068]. This document defines a new overload report type to communicate occurrences of agent overload. This report type works for the "Loss" overload mitigation algorithm defined in [RFC7683] and is expected to work for other overload abatement algorithms defined in extensions to the DOIC solution. 2. Terminology and Abbreviations + AVP + + Attribute Value Pair + Diameter Node - A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733 - Diameter Agent. + + A [RFC7683] Diameter Client, an [RFC7683] Diameter Server, and + [RFC7683] Diameter Agent. Diameter Endpoint - An RFC6733 Diameter Client and RFC6733 Diameter Server. + An [RFC7683] Diameter Client and [RFC7683] Diameter Server. Diameter Agent - An RFC6733 Diameter Agent. + An [RFC7683] Diameter Agent. Reporting Node A DOIC Node that sends an overload report in a Diameter answer message. Reacting Node A DOIC Node that receives and acts on a DOIC overload report. @@ -172,20 +177,24 @@ There are two primary classes of use cases currently identified, those involving the overload of agents and those involving overload of Diameter endpoints. In both cases the goal is to use an overload algorithm that controls traffic sent towards peers. 3.1. Diameter Agent Overload Use Cases The peer report needs to support the following use cases. + In the figures in this section, elements labeled "c" are Diameter + Clients, elements labeled "a" are Diameter Agents and elements + labeled "s" are Diameter Servers. + 3.1.1. Single Agent 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 the agent then the client is unable to send Diameter traffic toward the server. +-+ +-+ +-+ |c|----|a|----|s| +-+ +-+ +-+ @@ -252,32 +261,33 @@ +--+ +-+ --|a1|---|s| +-+ / +--+\ /+-+ |c|- x +-+ \ +--+/ \+-+ --|a2|---|s| +--+ +-+ Figure 4 - In the case where one of the agents in the above scenario becomes + In the case where one of the agents in the above scenarios become overloaded, the client should reduce the amount of traffic sent to the overloaded agent by the amount requested. This traffic should instead be routed through the non-overloaded agent. For example, assume that the overloaded agent requests a reduction of 10 percent. The client should send 10 percent of the traffic that would have been routed to the overloaded agent through the non-overloaded agent. When the client has an active and a standby connection to the two agents then an alternative strategy for responding to an overload - report from an agent is to change the standby connection to active - and route all traffic through the new active connection. + report from an agent is to change the standby connection to active. + This will result in all traffic being routed through the new active + connection. In the case where both agents are reporting overload, the client may need to start decreasing the total traffic sent to the agents. This would be done in a similar fashion as discussed in Section 3.1.1 The amount of traffic depends on the combined reduction requested by the two agents. 3.1.3. Agent Chains There are also deployment scenarios where there can be multiple @@ -737,20 +748,23 @@ report could have a bigger impact on a Diameter network as agents can be concentration points in a Diameter network. Where an end-point report would impact the traffic sent to a single Diameter server, for example, a peer report could throttle all traffic to the Diameter network. This impact is amplified in an agent that sits at the edge of a Diameter network that serves as the entry point from all other Diameter networks. + The impacts of this attack, as well as the mitigation strategies, are + the same as outlined in [RFC7683]. + 9. Acknowledgements Adam Roach and Eric McMurry for the work done in defining a comprehensive Diameter overload solution in draft-roach-dime- overload-ctrl-03.txt. Ben Campbell for his insights and review of early versions of this document. 10. References