draft-ietf-dime-agent-overload-10.txt   draft-ietf-dime-agent-overload-11.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) March 7, 2017 Updates: RFC7683 (if approved) March 22, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: September 8, 2017 Expires: September 23, 2017
Diameter Agent Overload and the Peer Overload Report Diameter Agent Overload and the Peer Overload Report
draft-ietf-dime-agent-overload-10.txt draft-ietf-dime-agent-overload-11.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 September 8, 2017. This Internet-Draft will expire on September 23, 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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Peer Report Use Cases . . . . . . . . . . . . . . . . . . . . 4 3. Peer Report Use Cases . . . . . . . . . . . . . . . . . . . . 4
3.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 4 3.1. Diameter Agent Overload Use Cases . . . . . . . . . . . . 4
3.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Single Agent . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 5 3.1.2. Redundant Agents . . . . . . . . . . . . . . . . . . 6
3.1.3. Agent Chains . . . . . . . . . . . . . . . . . . . . 7 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 3.2.1. Hop-by-hop Abatement Algorithms . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . 9
5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 8 5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 9
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 . . . . . . . . . 13
6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 13 6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 14
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 13 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 14
6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 14 6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 14
6.1.2. OC-Peer-Algo 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.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 . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . . 18
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
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.
This document defines the behavior of Diameter nodes when Diameter This document defines the behavior of Diameter nodes when Diameter
skipping to change at page 3, line 50 skipping to change at page 3, line 50
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 [RFC7683] and is expected to overload mitigation algorithm defined in [RFC7683] and is expected to
work for other overload abatement algorithms defined in extensions to work for other overload abatement algorithms defined in extensions to
the DOIC solution. the DOIC solution.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
AVP
Attribute Value Pair
Diameter Node 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 Diameter Endpoint
An RFC6733 Diameter Client and RFC6733 Diameter Server. An [RFC7683] Diameter Client and [RFC7683] Diameter Server.
Diameter Agent Diameter Agent
An RFC6733 Diameter Agent. An [RFC7683] Diameter Agent.
Reporting Node Reporting Node
A DOIC Node that sends an overload report in a Diameter answer A DOIC Node that sends an overload report in a Diameter answer
message. message.
Reacting Node Reacting Node
A DOIC Node that receives and acts on a DOIC overload report. A DOIC Node that receives and acts on a DOIC overload report.
skipping to change at page 4, line 43 skipping to change at page 4, line 46
There are two primary classes of use cases currently identified, There are two primary classes of use cases currently identified,
those involving the overload of agents and those involving overload those involving the overload of agents and those involving overload
of Diameter endpoints. In both cases the goal is to use an overload of Diameter endpoints. In both cases the goal is to use an overload
algorithm that controls traffic sent towards peers. algorithm that controls traffic sent towards peers.
3.1. Diameter Agent Overload Use Cases 3.1. Diameter Agent Overload Use Cases
The peer report needs to support the following 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 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 6, line 32 skipping to change at page 6, line 42
+--+ +-+ +--+ +-+
--|a1|---|s| --|a1|---|s|
+-+ / +--+\ /+-+ +-+ / +--+\ /+-+
|c|- x |c|- x
+-+ \ +--+/ \+-+ +-+ \ +--+/ \+-+
--|a2|---|s| --|a2|---|s|
+--+ +-+ +--+ +-+
Figure 4 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 overloaded, the client should reduce the amount of traffic sent to
the overloaded agent by the amount requested. This traffic should the overloaded agent by the amount requested. This traffic should
instead be routed through the non-overloaded agent. For example, instead be routed through the non-overloaded agent. For example,
assume that the overloaded agent requests a reduction of 10 percent. assume that the overloaded agent requests a reduction of 10 percent.
The client should send 10 percent of the traffic that would have been The client should send 10 percent of the traffic that would have been
routed to the overloaded agent through the non-overloaded agent. routed to the overloaded agent through the non-overloaded agent.
When the client has an active and a standby connection to the two When the client has an active and a standby connection to the two
agents then an alternative strategy for responding to an overload agents then an alternative strategy for responding to an overload
report from an agent is to change the standby connection to active report from an agent is to change the standby connection to active.
and route all traffic through the new active connection. 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 In the case where both agents are reporting overload, the client may
need to start decreasing the total traffic sent to the agents. This 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 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 amount of traffic depends on the combined reduction requested by the
two agents. two agents.
3.1.3. Agent Chains 3.1.3. Agent Chains
There are also deployment scenarios where there can be multiple There are also deployment scenarios where there can be multiple
skipping to change at page 17, line 5 skipping to change at page 17, line 16
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.
This impact is amplified in an agent that sits at the edge of a 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 network that serves as the entry point from all other
Diameter networks. Diameter networks.
The impacts of this attack, as well as the mitigation strategies, are
the same as outlined in [RFC7683].
9. Acknowledgements 9. Acknowledgements
Adam Roach and Eric McMurry for the work done in defining a Adam Roach and Eric McMurry for the work done in defining a
comprehensive Diameter overload solution in draft-roach-dime- comprehensive Diameter overload solution in draft-roach-dime-
overload-ctrl-03.txt. overload-ctrl-03.txt.
Ben Campbell for his insights and review of early versions of this Ben Campbell for his insights and review of early versions of this
document. document.
10. References 10. References
 End of changes. 19 change blocks. 
22 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/