draft-ietf-dime-ovli-09.txt   draft-ietf-dime-ovli-10.txt 
Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed. Diameter Maintenance and Extensions (DIME) J. Korhonen, Ed.
Internet-Draft Broadcom Internet-Draft Broadcom
Intended status: Standards Track S. Donovan, Ed. Intended status: Standards Track S. Donovan, Ed.
Expires: February 7, 2016 B. Campbell Expires: February 20, 2016 B. Campbell
Oracle Oracle
L. Morand L. Morand
Orange Labs Orange Labs
August 6, 2015 August 19, 2015
Diameter Overload Indication Conveyance Diameter Overload Indication Conveyance
draft-ietf-dime-ovli-09.txt draft-ietf-dime-ovli-10.txt
Abstract Abstract
This specification defines a base solution for Diameter overload This specification defines a base solution for Diameter overload
control, referred to as Diameter Overload Indication Conveyance control, referred to as Diameter Overload Indication Conveyance
(DOIC). (DOIC).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 February 7, 2016. This Internet-Draft will expire on February 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 28 skipping to change at page 2, line 28
5. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 12 5. Solution Procedures . . . . . . . . . . . . . . . . . . . . . 12
5.1. Capability Announcement . . . . . . . . . . . . . . . . . 12 5.1. Capability Announcement . . . . . . . . . . . . . . . . . 12
5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 13 5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 13
5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 13 5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 13
5.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 14 5.1.3. Agent Behavior . . . . . . . . . . . . . . . . . . . 14
5.2. Overload Report Processing . . . . . . . . . . . . . . . 15 5.2. Overload Report Processing . . . . . . . . . . . . . . . 15
5.2.1. Overload Control State . . . . . . . . . . . . . . . 15 5.2.1. Overload Control State . . . . . . . . . . . . . . . 15
5.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 19 5.2.2. Reacting Node Behavior . . . . . . . . . . . . . . . 19
5.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 20 5.2.3. Reporting Node Behavior . . . . . . . . . . . . . . . 20
5.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 22 5.3. Protocol Extensibility . . . . . . . . . . . . . . . . . 22
6. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 23 6. Loss Algorithm . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 24 6.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 23
6.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 24 6.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 24
7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 25 7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 24
7.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 25 7.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 25
7.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 25 7.2. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . . 25
7.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 26 7.3. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 25
7.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 26 7.4. OC-Sequence-Number AVP . . . . . . . . . . . . . . . . . 26
7.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 26 7.5. OC-Validity-Duration AVP . . . . . . . . . . . . . . . . 26
7.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 27 7.6. OC-Report-Type AVP . . . . . . . . . . . . . . . . . . . 26
7.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 27 7.7. OC-Reduction-Percentage AVP . . . . . . . . . . . . . . . 27
7.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27 7.8. Attribute Value Pair flag rules . . . . . . . . . . . . . 27
8. Error Response Codes . . . . . . . . . . . . . . . . . . . . 28 8. Error Response Codes . . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. New registries . . . . . . . . . . . . . . . . . . . . . 29 9.2. New registries . . . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 30 10.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 30
10.2. Denial of Service Attacks . . . . . . . . . . . . . . . 31 10.2. Denial of Service Attacks . . . . . . . . . . . . . . . 31
10.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . 32 10.3. Non-Compliant Nodes . . . . . . . . . . . . . . . . . . 31
10.4. End-to End-Security Issues . . . . . . . . . . . . . . . 32 10.4. End-to End-Security Issues . . . . . . . . . . . . . . . 32
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Issues left for future specifications . . . . . . . 35 Appendix A. Issues left for future specifications . . . . . . . 34
A.1. Additional traffic abatement algorithms . . . . . . . . . 35 A.1. Additional traffic abatement algorithms . . . . . . . . . 34
A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 35 A.2. Agent Overload . . . . . . . . . . . . . . . . . . . . . 34
A.3. New Error Diagnostic AVP . . . . . . . . . . . . . . . . 35 A.3. New Error Diagnostic AVP . . . . . . . . . . . . . . . . 35
Appendix B. Deployment Considerations . . . . . . . . . . . . . 35 Appendix B. Deployment Considerations . . . . . . . . . . . . . 35
Appendix C. Considerations for Applications Integrating the DOIC Appendix C. Considerations for Applications Integrating the DOIC
Solution . . . . . . . . . . . . . . . . . . . . . . 36 Solution . . . . . . . . . . . . . . . . . . . . . . 35
C.1. Application Classification . . . . . . . . . . . . . . . 36 C.1. Application Classification . . . . . . . . . . . . . . . 35
C.2. Application Type Overload Implications . . . . . . . . . 37 C.2. Application Type Overload Implications . . . . . . . . . 36
C.3. Request Transaction Classification . . . . . . . . . . . 38 C.3. Request Transaction Classification . . . . . . . . . . . 38
C.4. Request Type Overload Implications . . . . . . . . . . . 39 C.4. Request Type Overload Implications . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This specification defines a base solution for Diameter overload This specification defines a base solution for Diameter overload
control, referred to as Diameter Overload Indication Conveyance control, referred to as Diameter Overload Indication Conveyance
(DOIC), based on the requirements identified in [RFC7068]. (DOIC), based on the requirements identified in [RFC7068].
This specification addresses Diameter overload control between This specification addresses Diameter overload control between
Diameter nodes that support the DOIC solution. The solution, which Diameter nodes that support the DOIC solution. The solution, which
skipping to change at page 8, line 39 skipping to change at page 8, line 39
requested. requested.
Note that the loss algorithm defined in this document is a Note that the loss algorithm defined in this document is a
stateless abatement algorithm. As a result it does not require stateless abatement algorithm. As a result it does not require
any actions by reacting nodes prior to the receipt of an overload any actions by reacting nodes prior to the receipt of an overload
report. Stateful abatement algorithms that base the abatement report. Stateful abatement algorithms that base the abatement
logic on a history of request messages sent might require reacting logic on a history of request messages sent might require reacting
nodes to maintain state in advance of receiving an overload report nodes to maintain state in advance of receiving an overload report
to ensure that the overload reports can be properly handled. to ensure that the overload reports can be properly handled.
While it should only be done in exceptional circumstances and not
during an active occurrence of overload, a reacting node that wishes
to transition to a different abatement algorithm can stop advertising
support for the algorithm indicated by the reporting node, as long as
support for the loss algorithm is always advertised.
The DCA mechanism must also allow the scenario where the set of The DCA mechanism must also allow the scenario where the set of
features supported by the sender of a request and by agents in the features supported by the sender of a request and by agents in the
path of a request differ. In this case, the agent can update the OC- path of a request differ. In this case, the agent can update the OC-
Supported-Features AVP to reflect the mixture of the two sets of Supported-Features AVP to reflect the mixture of the two sets of
supported features. supported features.
Note: The logic to determine if the content of the OC-Supported- Note: The logic to determine if the content of the OC-Supported-
Features AVP should be changed is out-of-scope for this document, Features AVP should be changed is out-of-scope for this document,
as is the logic to determine the content of a modified OC- as is the logic to determine the content of a modified OC-
Supported-Features AVP. These are left to implementation Supported-Features AVP. These are left to implementation
skipping to change at page 14, line 14 skipping to change at page 14, line 14
drafts in response messages for transactions where the request drafts in response messages for transactions where the request
message does not include the OC-Supported-Features AVP. Lack of the message does not include the OC-Supported-Features AVP. Lack of the
OC-Supported-Features AVP in the request message indicates that there OC-Supported-Features AVP in the request message indicates that there
is no reacting node for the transaction. is no reacting node for the transaction.
A reporting node knows what overload control functionality is A reporting node knows what overload control functionality is
supported by the reacting node based on the content or absence of the supported by the reacting node based on the content or absence of the
OC-Feature-Vector AVP within the OC-Supported-Features AVP in the OC-Feature-Vector AVP within the OC-Supported-Features AVP in the
request message. request message.
A reporting node MUST A reporting node MUST select a single abatement A reporting node MUST select a single abatement algorithm in the OC-
algorithm in the OC-Feature-Vector AVP. The abatement algorithm Feature-Vector AVP. The abatement algorithm selected MUST indicate
selected MUST indicate the abatement algorithm the reporting node the abatement algorithm the reporting node wants the reacting node to
wants the reacting node to use when the reporting node enters an use when the reporting node enters an overload condition.
overload condition.
The abatement algorithm selected MUST be from the set of abatement The abatement algorithm selected MUST be from the set of abatement
algorithms contained in the request message's OC-Feature-Vector AVP. algorithms contained in the request message's OC-Feature-Vector AVP.
A reporting node that selects the loss algorithm may do so by A reporting node that selects the loss algorithm may do so by
including the OC-Feature-Vector AVP with an explicit indication of including the OC-Feature-Vector AVP with an explicit indication of
the loss algorithm, or it MAY omit OC-Feature-Vector. If it selects the loss algorithm, or it MAY omit OC-Feature-Vector. If it selects
a different algorithm, it MUST include the OC-Feature-Vector AVP with a different algorithm, it MUST include the OC-Feature-Vector AVP with
an explicit indication of the selected algorithm. an explicit indication of the selected algorithm.
skipping to change at page 16, line 26 skipping to change at page 16, line 21
A host-type OCS entry is identified by the pair of application-id and A host-type OCS entry is identified by the pair of application-id and
the node's DiameterIdentity. the node's DiameterIdentity.
A realm-type OCS entry is identified by the pair of application-id A realm-type OCS entry is identified by the pair of application-id
and realm. and realm.
The host-type and realm-type OCS entries include the following The host-type and realm-type OCS entries include the following
information (the actual information stored is an implementation information (the actual information stored is an implementation
decision): decision):
o Sequence number (as received in OC-OLR) o Sequence number (as received in OC-OLR, see Section 7.3)
o Time of expiry (derived from OC-Validity-Duration AVP received in o Time of expiry (derived from OC-Validity-Duration AVP received in
the OC-OLR AVP and time of reception of the message carrying OC- the OC-OLR AVP and time of reception of the message carrying OC-
OLR AVP) OLR AVP)
o Selected Abatement Algorithm (as received in the OC-Supported- o Selected Abatement Algorithm (as received in the OC-Supported-
Features AVP) Features AVP)
o Abatement Algorithm specific input data (as received in the OC-OLR o Abatement Algorithm specific input data (as received in the OC-OLR
AVP, for example, OC-Reduction-Percentage for the Loss abatement AVP, for example, OC-Reduction-Percentage for the Loss abatement
 End of changes. 19 change blocks. 
28 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/