< draft-roach-dime-overload-ctrl-00.txt   draft-roach-dime-overload-ctrl-01.txt >
DIME A. B. Roach DIME A. B. Roach
Internet-Draft Tekelec Internet-Draft Tekelec
Intended status: Standards Track October 2, 2012 Intended status: Standards Track October 22, 2012
Expires: April 5, 2013 Expires: April 25, 2013
A Mechanism for Diameter Overload Control A Mechanism for Diameter Overload Control
draft-roach-dime-overload-ctrl-00 draft-roach-dime-overload-ctrl-01
Abstract Abstract
When a Diameter server or agent becomes overloaded, it needs to be When a Diameter server or agent becomes overloaded, it needs to be
able to gracefully reduce its load, typically by informing clients to able to gracefully reduce its load, typically by informing clients to
reduce or stop sending traffic for some period of time. Otherwise, reduce or stop sending traffic for some period of time. Otherwise,
it must continue to expend resources parsing and responding to it must continue to expend resources parsing and responding to
Diameter messages. Diameter messages.
This document proposes a concrete, application-independent mechanism This document proposes a concrete, application-independent mechanism
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 April 5, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Mechanism Properties . . . . . . . . . . . . . . . . . . . 4 1.1. Mechanism Properties . . . . . . . . . . . . . . . . . . . 4
1.2. Overview of Operation . . . . . . . . . . . . . . . . . . 6 1.2. Overview of Operation . . . . . . . . . . . . . . . . . . 6
1.3. Documentation Conventions . . . . . . . . . . . . . . . . 6 1.3. Documentation Conventions . . . . . . . . . . . . . . . . 6
2. Overload Scopes . . . . . . . . . . . . . . . . . . . . . . . 6 2. Overload Scopes . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Scope Descriptions . . . . . . . . . . . . . . . . . . . . 7 2.1. Scope Descriptions . . . . . . . . . . . . . . . . . . . . 7
2.2. Combining Scopes . . . . . . . . . . . . . . . . . . . . . 8 2.2. Combining Scopes . . . . . . . . . . . . . . . . . . . . . 8
3. Diameter Node Behavior . . . . . . . . . . . . . . . . . . . . 9 3. Diameter Node Behavior . . . . . . . . . . . . . . . . . . . . 9
3.1. Connection Establishment Procedures . . . . . . . . . . . 9 3.1. Connection Establishment Procedures . . . . . . . . . . . 9
3.2. Diameter Client and Diameter Server Behavior . . . . . . . 11 3.2. Diameter Client and Diameter Server Behavior . . . . . . . 11
3.2.1. Sending a Request . . . . . . . . . . . . . . . . . . 11 3.2.1. Sending a Request . . . . . . . . . . . . . . . . . . 12
3.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 13 3.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 13
3.2.3. Sending an Answer . . . . . . . . . . . . . . . . . . 14 3.2.3. Sending an Answer . . . . . . . . . . . . . . . . . . 14
3.2.4. Receiving an Answer . . . . . . . . . . . . . . . . . 15 3.2.4. Receiving an Answer . . . . . . . . . . . . . . . . . 15
3.3. Diameter Agent Behavior . . . . . . . . . . . . . . . . . 15 3.3. Diameter Agent Behavior . . . . . . . . . . . . . . . . . 15
3.3.1. Proxying a Request . . . . . . . . . . . . . . . . . . 15 3.3.1. Proxying a Request . . . . . . . . . . . . . . . . . . 16
3.3.2. Proxying an Answer . . . . . . . . . . . . . . . . . . 16 3.3.2. Proxying an Answer . . . . . . . . . . . . . . . . . . 16
3.4. Proactive Load and Overload Communication . . . . . . . . 16 3.4. Proactive Load and Overload Communication . . . . . . . . 16
3.5. Load Processing . . . . . . . . . . . . . . . . . . . . . 16 3.5. Load Processing . . . . . . . . . . . . . . . . . . . . . 16
3.5.1. Sending Load Information . . . . . . . . . . . . . . . 17 3.5.1. Sending Load Information . . . . . . . . . . . . . . . 17
3.5.2. Receiving Load Information . . . . . . . . . . . . . . 18 3.5.2. Receiving Load Information . . . . . . . . . . . . . . 18
3.6. Session Establishment for Session Groups . . . . . . . . . 19 3.6. Session Establishment for Session Groups . . . . . . . . . 19
3.6.1. Session Group Concepts . . . . . . . . . . . . . . . . 19 3.6.1. Session Group Concepts . . . . . . . . . . . . . . . . 19
3.6.2. Session Group Procedures . . . . . . . . . . . . . . . 21 3.6.2. Session Group Procedures . . . . . . . . . . . . . . . 21
4. Loss-Based Overload Control Algorithm . . . . . . . . . . . . 21 4. Loss-Based Overload Control Algorithm . . . . . . . . . . . . 22
4.1. Overload-Metric values for the 'Loss' Algorithm . . . . . 22 4.1. Overload-Metric values for the 'Loss' Algorithm . . . . . 22
4.2. Example Implementation . . . . . . . . . . . . . . . . . . 22 4.2. Example Implementation . . . . . . . . . . . . . . . . . . 23
5. Diameter AVPs for Overload . . . . . . . . . . . . . . . . . . 26 5. Diameter AVPs for Overload . . . . . . . . . . . . . . . . . . 27
5.1. Load-Info AVP . . . . . . . . . . . . . . . . . . . . . . 27 5.1. Load-Info AVP . . . . . . . . . . . . . . . . . . . . . . 27
5.2. Supported-Scopes AVP . . . . . . . . . . . . . . . . . . . 27 5.2. Supported-Scopes AVP . . . . . . . . . . . . . . . . . . . 28
5.3. Overload-Algorithm AVP . . . . . . . . . . . . . . . . . . 28 5.3. Overload-Algorithm AVP . . . . . . . . . . . . . . . . . . 28
5.4. Overload-Info-Scope AVP . . . . . . . . . . . . . . . . . 28 5.4. Overload-Info-Scope AVP . . . . . . . . . . . . . . . . . 29
5.4.1. Realm Scope . . . . . . . . . . . . . . . . . . . . . 29 5.4.1. Realm Scope . . . . . . . . . . . . . . . . . . . . . 30
5.4.2. Application-ID Scope . . . . . . . . . . . . . . . . . 30 5.4.2. Application-ID Scope . . . . . . . . . . . . . . . . . 30
5.4.3. Host Scope . . . . . . . . . . . . . . . . . . . . . . 30 5.4.3. Host Scope . . . . . . . . . . . . . . . . . . . . . . 30
5.4.4. Session Scope . . . . . . . . . . . . . . . . . . . . 30 5.4.4. Session Scope . . . . . . . . . . . . . . . . . . . . 30
5.4.5. Connection Scope . . . . . . . . . . . . . . . . . . . 30 5.4.5. Connection Scope . . . . . . . . . . . . . . . . . . . 30
5.4.6. Session Group Scope . . . . . . . . . . . . . . . . . 30 5.4.6. Session Group Scope . . . . . . . . . . . . . . . . . 31
5.5. Overload-Metric AVP . . . . . . . . . . . . . . . . . . . 31 5.5. Overload-Metric AVP . . . . . . . . . . . . . . . . . . . 31
5.6. Period-Of-Validity AVP . . . . . . . . . . . . . . . . . . 31 5.6. Period-Of-Validity AVP . . . . . . . . . . . . . . . . . . 31
5.7. Session-Group AVP . . . . . . . . . . . . . . . . . . . . 31 5.7. Session-Group AVP . . . . . . . . . . . . . . . . . . . . 31
5.8. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.8. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7.1. New Diameter AVPs . . . . . . . . . . . . . . . . . . . . 32 7.1. New Diameter AVPs . . . . . . . . . . . . . . . . . . . . 32
7.2. New Diameter Disconnect-Cause . . . . . . . . . . . . . . 32 7.2. New Diameter Disconnect-Cause . . . . . . . . . . . . . . 32
7.3. New Diameter Response Code . . . . . . . . . . . . . . . . 33 7.3. New Diameter Response Code . . . . . . . . . . . . . . . . 33
7.4. New Command Flag . . . . . . . . . . . . . . . . . . . . . 33 7.4. New Command Flag . . . . . . . . . . . . . . . . . . . . . 33
7.5. Overload Algorithm Registry . . . . . . . . . . . . . . . 33 7.5. Overload Algorithm Registry . . . . . . . . . . . . . . . 33
7.6. Overload Scope Registry . . . . . . . . . . . . . . . . . 33 7.6. Overload Scope Registry . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. Normative References . . . . . . . . . . . . . . . . . . . 34 8.1. Normative References . . . . . . . . . . . . . . . . . . . 34
8.2. Informative References . . . . . . . . . . . . . . . . . . 34 8.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34
Appendix B. Requirements Analysis . . . . . . . . . . . . . . . . 34 Appendix B. Requirements Analysis . . . . . . . . . . . . . . . . 35
Appendix C. Extending the Overload Mechanism . . . . . . . . . . 35 Appendix C. Extending the Overload Mechanism . . . . . . . . . . 35
C.1. New Algorithms . . . . . . . . . . . . . . . . . . . . . . 35 C.1. New Algorithms . . . . . . . . . . . . . . . . . . . . . . 35
C.2. New Scopes . . . . . . . . . . . . . . . . . . . . . . . . 35 C.2. New Scopes . . . . . . . . . . . . . . . . . . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 Appendix D. Design Rationale . . . . . . . . . . . . . . . . . . 36
D.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . . 36
D.2. Load AVP in All Packets . . . . . . . . . . . . . . . . . 37
D.3. Graceful Failure . . . . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
When a Diameter [I-D.ietf-dime-rfc3588bis] server or agent becomes When a Diameter [I-D.ietf-dime-rfc3588bis] server or agent becomes
overloaded, it needs to be able to gracefully reduce its load, overloaded, it needs to be able to gracefully reduce its load,
typically by informing clients to reduce or stop sending traffic for typically by informing clients to reduce or stop sending traffic for
some period of time. Otherwise, it must continue to expend resources some period of time. Otherwise, it must continue to expend resources
parsing and responding to Diameter messages. parsing and responding to Diameter messages.
This document defines a mechanism for communicating the load and This document defines a mechanism for communicating the load and
skipping to change at page 7, line 28 skipping to change at page 7, line 28
in servers that need to make use of external resources for certain in servers that need to make use of external resources for certain
applications but not for others. For example, if a single server is applications but not for others. For example, if a single server is
handling two applications, one of which uses an external database handling two applications, one of which uses an external database
while the other does not, it may become overloaded for the while the other does not, it may become overloaded for the
application that uses the external database when the database application that uses the external database when the database
response latency increases. response latency increases.
The indication of scopes for overload information (using the The indication of scopes for overload information (using the
Overload-Info-Scope AVP; see Section 5.4) allows a node to indicate a Overload-Info-Scope AVP; see Section 5.4) allows a node to indicate a
subset of requests to which overload information is to be applied. subset of requests to which overload information is to be applied.
This document defines seven scopes, five of which are mandatory to This document defines seven scopes; only "Connection" scope is
implement. The use of the two optional scopes, along with the use of mandatory to implement. The use of the optional scopes, along with
any additional scopes defined in other documents, is negotiated at the use of any additional scopes defined in other documents, is
connection establishment time; see Section 3.1. negotiated at connection establishment time; see Section 3.1.
2.1. Scope Descriptions 2.1. Scope Descriptions
Destination-Realm: This scope, which is mandatory to implement, Destination-Realm: This scope, which nodes SHOULD implement,
pertains to all transactions that have a Destination-Realm AVP pertains to all transactions that have a Destination-Realm AVP
matching the indicated value. matching the indicated value.
Application-ID: This scope, which is mandatory to implement, Application-ID: This scope, which nodes SHOULD implement, pertains
pertains to all transactions that contain an Application-ID to all transactions that contain an Application-ID field
field matching the indicated value.
Destination-Host: This scope, which is mandatory to implement,
pertains to all transactions that have a Destination-Host AVP
matching the indicated value. matching the indicated value.
Host: This scope, which is mandatory to implement, pertains to all Destination-Host: This scope, which nodes SHOULD implement, pertains
to all transactions that have a Destination-Host AVP matching
the indicated value.
Host: This scope, which nodes SHOULD implement, pertains to all
transactions sent directly to the host matching the indicated transactions sent directly to the host matching the indicated
value. value.
Connection: This scope, which is mandatory to implement, pertains to Connection: This scope, which nodes MUST implement, pertains to all
all transactions sent on the same TCP connection or SCTP transactions sent on the same TCP connection or SCTP
association. This scope has no details indicating which association. This scope has no details indicating which
connection or association it applies to; instead, the recipient connection or association it applies to; instead, the recipient
of an indication of "Connection" scope is to use the connection of an indication of "Connection" scope is to use the connection
or association on which the message was received as the or association on which the message was received as the
indicated connection or association. In other words, any use indicated connection or association. In other words, any use
of Connection scope applies to "this connection." of Connection scope applies to "this connection."
Session-Group: This scope, which is optional to implement, pertains Session-Group: This scope, which nodes MAY implement, pertains to
to all transactions in a session that has been assigned to the all transactions in a session that has been assigned to the
indicated group. For more information on assigning sessions to indicated group. For more information on assigning sessions to
groups, see Section 3.6. groups, see Section 3.6.
Session: This scope, which is optional to implement, pertains to all Session: This scope, which nodes MAY implement, pertains to all
transactions in the indicated session. transactions in the indicated session.
Some applications do not have long-running sessions containing Some applications do not have long-running sessions containing
multiple transactions. For such applications, the use of "Session- multiple transactions. For such applications, the use of "Session-
Group" and "Session" scopes do not make sense. Such applications Group" and "Session" scopes do not make sense. Such applications
will instead make use of the most applicable of the remaining five will instead make use of the most applicable of the remaining five
scopes (plus any negotiated extension scopes) to achieve overload scopes (plus any negotiated extension scopes) to achieve overload
control. control.
OPEN ISSUE: Is there value to including a stream-level scope for OPEN ISSUE: Is there value to including a stream-level scope for
skipping to change at page 9, line 13 skipping to change at page 9, line 13
overloaded" scope is used for traffic shaping. overloaded" scope is used for traffic shaping.
To prevent the complexity of implementing arbitrary scope combination To prevent the complexity of implementing arbitrary scope combination
rules, only the following combinations of scopes are allowed (OPEN rules, only the following combinations of scopes are allowed (OPEN
ISSUE -- we need to figure out what makes most sense for expressing ISSUE -- we need to figure out what makes most sense for expressing
these combinations. Formal grammar? Prose? A table of some kind? these combinations. Formal grammar? Prose? A table of some kind?
For now, they're expressed as a pseudo-ABNF): For now, they're expressed as a pseudo-ABNF):
o 1*(Destination-Realm) 0*1(Application-ID) o 1*(Destination-Realm) 0*1(Application-ID)
o 1*(Application-ID) 0*1(Destination-Realm) o 1*(Application-ID) 0*1(Destination-Realm)
o 1*(Application-ID) 0*1(Destination-Host)
o 1*(Application-ID) 0*1(Host)
o 1*(Application-ID) 0*1(Connection)
o 1*(Destination-Host) o 1*(Destination-Host)
o 1*1(Next-Hop) o 1*1(Host)
o 1*1(Connection) o 1*1(Connection)
o 1*(Session-Group) 0*1(Next-Hop | Connection) o 1*(Session-Group) 0*1(Host | Connection)
o 1*(Session) 0*1(Next-Hop | Connection) o 1*(Session) 0*1(Host | Connection)
OPEN ISSUE: Is this the right set of scope combinations? Is there OPEN ISSUE: Is this the right set of scope combinations? Is there
a need for more? Are any of these unnecessary? Ideally, this a need for more? Are any of these unnecessary? Ideally, this
should be the smallest set of combinations that lets nodes report should be the smallest set of combinations that lets nodes report
what they realistically need to report. what they realistically need to report.
Any document that creates additional scopes MUST define how they may Any document that creates additional scopes MUST define how they may
be combined with all scopes registered with IANA at the time of their be combined with all scopes registered with IANA at the time of their
publication. publication.
skipping to change at page 10, line 9 skipping to change at page 10, line 12
Diameter capabilities exchange. Optional protocol features and Diameter capabilities exchange. Optional protocol features and
extensions to this mechanism are also negotiated at this time. No extensions to this mechanism are also negotiated at this time. No
provision is provided for renegotiation of mechanism use or provision is provided for renegotiation of mechanism use or
extensions during the course of a connection. If peers wish to make extensions during the course of a connection. If peers wish to make
changes to the mechanism, they must create a new connection to do so. changes to the mechanism, they must create a new connection to do so.
The connection initiator includes a Load-Info AVP in the CER The connection initiator includes a Load-Info AVP in the CER
(Capabilities-Exchange-Request) message that it sends after (Capabilities-Exchange-Request) message that it sends after
establishing the connection. This Load-Info AVP MUST contain a establishing the connection. This Load-Info AVP MUST contain a
Supported-Scopes AVP and an Overload-Algorithm AVP. The Supported- Supported-Scopes AVP and an Overload-Algorithm AVP. The Supported-
Scopes AVP indicates a comprehensive list of optional scopes Scopes AVP includes a comprehensive list of scopes supported that the
supported by the connection initiator. See Section 5.2 for connection initiator can receive and understand. See Section 5.2 for
information on the format of the Supported-Scopes AVP. information on the format of the Supported-Scopes AVP.
The Load-Info AVP in a CER message also MAY contain one or more The Load-Info AVP in a CER message also MAY contain one or more
Overload-Algorithm AVPs. If present, these AVPs indicate every Overload-Algorithm AVPs. If present, these AVPs indicate every
Overload-Algorithm the connection initiator is willing to support for Overload-Algorithm the connection initiator is willing to support for
the connection that is being established. If the connection the connection that is being established. If the connection
initiator supports only the "Loss" algorithm, it MAY indicate this initiator supports only the "Loss" algorithm, it MAY indicate this
fact by omitting the Overload-Algorithm altogether. fact by omitting the Overload-Algorithm altogether.
The Load-Info AVP in a CER message MAY also contain additional AVPs, The Load-Info AVP in a CER message MAY also contain additional AVPs,
as defined in other documents, for the purpose of negotiation as defined in other documents, for the purpose of negotiation
extensions to the Overload mechanism. extensions to the Overload mechanism.
The Diameter node that receives a CER message first examines it for The Diameter node that receives a CER message first examines it for
the presence of a Load-Info AVP. If no such AVP is present, the node the presence of a Load-Info AVP. If no such AVP is present, the node
concludes that the overload control mechanism is not supported for concludes that the overload control mechanism is not supported for
this connection, and no further overload-related negotiation is this connection, and no further overload-related negotiation is
performed. If the received CER contains a Load-Info AVP, the performed. If the received CER contains a Load-Info AVP, the
recipient of that message extracts the value of the Supported-Scopes recipient of that message stores that information locally in the
AVP, performs a logical intersection (bit-wise and) between the context of the connection being established. It then examines the
indicated scopes with its own supported scopes, and stores that Overload-Algorithm AVPs, if present, and selects a single algorithm
information locally in the context of the connection being from that list. If no Overload-Algorithm is indicated, then the base
established. It then examines the Overload-Algorithm AVPs, if "Loss" algorithm is used for the connection. In either case, the
present, and selects a single algorithm from that list. If no recipient of the CER stores this algorithm in the context of the
Overload-Algorithm is indicated, then the base "Loss" algorithm is connection.
used for the connection. In either case, the recipient of the CER
stores this algorithm in the context of the connection.
When a node conformant to this specification sends a Capabilities- When a node conformant to this specification sends a Capabilities-
Exchange-Answer (CEA) message in answer to a CER that contained a Exchange-Answer (CEA) message in answer to a CER that contained a
Load-Info AVP, the CEA MUST contain a Load-Info AVP. This Load-Info Load-Info AVP, the CEA MUST contain a Load-Info AVP. This Load-Info
AVP MUST contain a Supported-Scopes AVP that indicates the scopes to AVP MUST contain a Supported-Scopes AVP that includes a comprehensive
be used for this connection (which is the same set stored in the list of scopes supported that the connection initiator can receive
paragraph above). The CEA also contains zero or one Overload- and understand. The CEA also contains zero or one Overload-Algorithm
Algorithm AVPs. If present, this Overload-Algorithm MUST match one AVPs. If present, this Overload-Algorithm MUST match one of the
of the Overload-Algorithm AVPs sent in the CER, and it indicates the Overload-Algorithm AVPs sent in the CER, and it indicates the
overload control algorithm that will be used for the connection. If overload control algorithm that will be used for the connection. If
the CEA contains no Overload-Algorithm, the connection will use the the CEA contains no Overload-Algorithm, the connection will use the
"Loss" algorithm. "Loss" algorithm.
When a node receives a CEA message, it examines it for the presence When a node receives a CEA message, it examines it for the presence
of a Load-Info AVP. If no such AVP is present, the node concludes of a Load-Info AVP. If no such AVP is present, the node concludes
that the overload mechanism is not supported for this connection. If that the overload mechanism is not supported for this connection. If
the received CEA contains a Load-Info AVP, then the recipient the received CEA contains a Load-Info AVP, then the recipient
extracts the Supported-Scopes information, and stores them locally in extracts the Supported-Scopes information, and stores them locally in
the context of the connection being established. It then checks for the context of the connection being established. It then checks for
skipping to change at page 11, line 21 skipping to change at page 11, line 24
algorithm. algorithm.
If a node receives a CEA message that indicates support for a scope If a node receives a CEA message that indicates support for a scope
that it did not indicate in its CER or which selects an overload that it did not indicate in its CER or which selects an overload
control algorithm that it did not advertise in its CER, then it MUST control algorithm that it did not advertise in its CER, then it MUST
terminate the connection by sending a DPR with a Disconnect-Cause of terminate the connection by sending a DPR with a Disconnect-Cause of
NEGOTIATION_FAILURE, (128 [actual value TBD]) indicating that the CEA NEGOTIATION_FAILURE, (128 [actual value TBD]) indicating that the CEA
sender has failed to properly follow the negotiation process sender has failed to properly follow the negotiation process
described above. described above.
Note that the Supported-Scopes announcement during capabilities
exchange is a set of mutual advertisements of which scopes the two
nodes are willing to receive information about. It is not a
negotiation. It is perfectly acceptable for a node to send
information for scopes it did not include in the Supported-Scopes AVP
it sent, as long as the recipient indicated support for receiving
such a scope. For example, a Diameter agent, during connection
establishment with a client, may indicate support for receiving only
"Connection" and "Host" scope; however, if the client indicated
support for "Application" scope, then the agent is free to send Load-
Info AVPs that make use of "Application" scope to the client.
3.2. Diameter Client and Diameter Server Behavior 3.2. Diameter Client and Diameter Server Behavior
The following sections describe the behavior that Diameter clients The following sections describe the behavior that Diameter clients
and Diameter servers implement for the overload control mechanism. and Diameter servers implement for the overload control mechanism.
Behavior at Diameter Agents is described in Section 3.3. Behavior at Diameter Agents is described in Section 3.3.
To implement overload control, Diameter nodes need to keep track of To implement overload control, Diameter nodes need to keep track of
three important metrics for each of the scopes for which information three important metrics for each of the scopes for which information
has been received: the overload metric for the scope, the period of has been received: the overload metric for the scope, the period of
validity for that overload metric, and the load within that scope. validity for that overload metric, and the load within that scope.
skipping to change at page 11, line 48 skipping to change at page 12, line 14
scope entry" to refer to that information that is being maintained to scope entry" to refer to that information that is being maintained to
send to other nodes. send to other nodes.
In order to allow recipients of overload information to perform In order to allow recipients of overload information to perform
certain performance optimizations, we also define a new command flag, certain performance optimizations, we also define a new command flag,
called 'O'verload. This bit, when set, indicates that the message called 'O'verload. This bit, when set, indicates that the message
contains at least one Load-Info AVP with a non-zero Overload-Metric contains at least one Load-Info AVP with a non-zero Overload-Metric
-- in other words, the sending node is overloaded for at least one -- in other words, the sending node is overloaded for at least one
context. See Section 7.4 for the definition of the 'O'verload bit. context. See Section 7.4 for the definition of the 'O'verload bit.
OPEN ISSUE: Is there anything we can do to make this 'O'verload
bit even more useful? Perhaps setting it only when the overload
value has changed, or changed by a certain amount?
3.2.1. Sending a Request 3.2.1. Sending a Request
This section applies only to those requests sent to peers who This section applies only to those requests sent to peers who
negotiated use of the overload control mechanism during capabilities negotiated use of the overload control mechanism during capabilities
exchange. Requests sent over other connections are handled the same exchange. Requests sent over other connections are handled the same
as they would in the absence of the overload control mechanism. as they would in the absence of the overload control mechanism.
Before sending a request, a Diameter node must first determine which Before sending a request, a Diameter node must first determine which
scope applies. It does this as follows: first, a next hop host and scope applies. It does this as follows: first, a next hop host and
connection are determined, according to normal Diameter procedures connection are determined, according to normal Diameter procedures
skipping to change at page 22, line 43 skipping to change at page 23, line 5
clients, these failures cause the client to behave as if they clients, these failures cause the client to behave as if they
received a transient error in response to the request. received a transient error in response to the request.
It is acceptable, when implementing the "Loss" algorithm, for the It is acceptable, when implementing the "Loss" algorithm, for the
reduction in transactions to make use of a statistical loss function reduction in transactions to make use of a statistical loss function
(e.g., random assignment of transactions into "success" and "failure" (e.g., random assignment of transactions into "success" and "failure"
categories based on the indicated percentage). In such a case, the categories based on the indicated percentage). In such a case, the
actual traffic reduction might vary slightly from the percentage actual traffic reduction might vary slightly from the percentage
indicated, albeit in an insignificant amount. indicated, albeit in an insignificant amount.
The selection of which messages to withhold from sending does not
need to be arbitrary. For example, implementations are allowed to
distinguish between higher-priority and lower-priority messages, and
drop the lower-priority messages in favor of dropping the higher
priority messages, as long as the total reduction in traffic conforms
to the Overload-Metric in effect at the time. The selection of which
messages to prioritize over others will likely vary from application
to application (and may even be subject to standardization as part of
the application definition). One example of such a prioritization
scheme would be to treat those messages that result in the creation
of a new session as lower priority then those messages sent in the
context of an established session.
4.2. Example Implementation 4.2. Example Implementation
The exact means a client uses to implement the requirement that it The exact means a client uses to implement the requirement that it
reduce traffic by a requested percentage is left to the discretion of reduce traffic by a requested percentage is left to the discretion of
the implementor. However, to aid in understanding the nature of such the implementor. However, to aid in understanding the nature of such
an implementation, we present an example of a valid implementation in an implementation, we present an example of a valid implementation in
pseudo-code. pseudo-code.
In this example, we consider that the sending node maintains two In this example, we consider that the sending node maintains two
classes of request. The first category are considered of lower classes of request. The first category are considered of lower
skipping to change at page 27, line 42 skipping to change at page 28, line 8
[ Supported-Scopes ] [ Supported-Scopes ]
* [ Overload-Algorithm ] * [ Overload-Algorithm ]
[ Period-Of-Validity ] [ Period-Of-Validity ]
[ Session-Group ] [ Session-Group ]
[ Load ] [ Load ]
* [ AVP ] * [ AVP ]
5.2. Supported-Scopes AVP 5.2. Supported-Scopes AVP
The Supported-Scopes AVP (AVP code 1601) is of type Uint64, and is The Supported-Scopes AVP (AVP code 1601) is of type Uint64, and is
used during capabilities exchange to negotiate the scopes that can be used during capabilities exchange to indicate the scopes that a given
used for the connection. Nodes that support the mechanism defined in node can receive on the connection. Nodes that support the mechanism
this document MUST include a Supported-Scopes AVP in all CER defined in this document MUST include a Supported-Scopes AVP in all
messages. It also MUST appear in any CEA messages sent in answer to CER messages. It also MUST appear in any CEA messages sent in answer
a CER message containing a Load-Info AVP. The Supported-Scopes AVP to a CER message containing a Load-Info AVP. The Supported-Scopes
MUST NOT appear in any other message types. See Section 5.4 for an AVP MUST NOT appear in any other message types. See Section 5.4 for
initial list of scopes. an initial list of scopes.
The Supported-Scopes AVP contains a bitmap that indicates the scopes The Supported-Scopes AVP contains a bitmap that indicates the scopes
supported by the client. The five mandatory scopes (Destination- supported by the sender. Within the bitmap, the least significant
Realm, Application-ID, Destination-Host, Next-Hop, and Connection) bit indicates support for scope 1 (Destination-Realm), while the next
are not signaled. Within the bitmap, the least significant bit least significant bit indicates support for scope 2 (Application-ID),
indicates support for scope 6 (Session-Group), while the next least and so on. In general, if we consider the bits to be numbered from 0
significant bit indicates support for scope 7 (Session). In general, (LSB) to 63 (MSB), then any bit n corresponds to the scope type
if we consider the bits to be numbered from 0 (LSB) to 63 (MSB), then numbered n+1. This scheme allows for up to 64 total scopes to be
any bit n corresponds to the scope type numbered n+6. This scheme supported. More formally, the bitmask used to indicate support for
allows for up to 69 total scopes to be supported (including the five any specific context is calculated as follows (where the symbol "<<"
mandatory scopes). More formally, the bitmask used to indicate indicates a bit shift left):
support for any specific context is calculated as follows (where the
symbol "<<" indicates a bit shift left):
bitmask = 1 << (n - 6) bitmask = 1 << (n - 1)
For additional clarity, the bitmasks for the two optional scopes For additional clarity, the bitmasks for the scopes defined in this
defined in this document are as follows: document are as follows:
+-------+---------+---------------+ +-------+--------------------+-------------------+
| Scope | Bitmask | Scope | | Scope | Bitmask | Scope |
+-------+---------+---------------+ +-------+--------------------+-------------------+
| 6 | 0x01 | Session-Group | | 1 | 0x0000000000000001 | Destination-Realm |
| 7 | 0x02 | Session | | 2 | 0x0000000000000002 | Application-ID |
+-------+---------+---------------+ | 3 | 0x0000000000000004 | Destination-Host |
| 4 | 0x0000000000000008 | Host |
| 5 | 0x0000000000000010 | Connection |
| 6 | 0x0000000000000020 | Session-Group |
| 7 | 0x0000000000000040 | Session |
+-------+--------------------+-------------------+
The negotiation process that makes use of the Supported-Scopes AVP is The advertisement process that makes use of the Supported-Scopes AVP
described in Section 3.1. The Supported-Scopes AVP may be omitted if is described in Section 3.1.
no optional scopes are supported.
5.3. Overload-Algorithm AVP 5.3. Overload-Algorithm AVP
The Overload-Algorithm AVP (AVP code 1602) is of type Enumerated, and The Overload-Algorithm AVP (AVP code 1602) is of type Enumerated, and
is used to negotiate the algorithm that will be used for load is used to negotiate the algorithm that will be used for load
abatement. The Overload-Algorithm AVP MAY appear in CER and CEA abatement. The Overload-Algorithm AVP MAY appear in CER and CEA
messages, and MUST NOT appear in any other message types. If absent, messages, and MUST NOT appear in any other message types. If absent,
an Overload Algorithm of type 1 (Loss) is indicated. Additional an Overload Algorithm of type 1 (Loss) is indicated. Additional
values can be registered by other documents; see Appendix C.1. values can be registered by other documents; see Appendix C.1.
Initial values for the enumeration are as follows: Initial values for the enumeration are as follows:
skipping to change at page 34, line 4 skipping to change at page 34, line 6
This document defines a new table, to be titled "Overload-Info-Scope This document defines a new table, to be titled "Overload-Info-Scope
Values (code 1603)", in the "aaa-parameters" registry. Its initial Values (code 1603)", in the "aaa-parameters" registry. Its initial
values are to be taken from the table in Section 5.4. values are to be taken from the table in Section 5.4.
New entries in this table follow the IANA policy of "Specification New entries in this table follow the IANA policy of "Specification
Required." (Open Issue: The WG should discuss registration policy to Required." (Open Issue: The WG should discuss registration policy to
ensure that we think this is the right balance). ensure that we think this is the right balance).
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-dime-overload-reqs] [I-D.ietf-dime-overload-reqs]
McMurry, E. and B. Campbell, "Diameter Overload Control McMurry, E. and B. Campbell, "Diameter Overload Control
Requirements", draft-ietf-dime-overload-reqs-00 (work in Requirements", draft-ietf-dime-overload-reqs-00 (work in
progress), September 2012. progress), September 2012.
[I-D.ietf-dime-rfc3588bis] [I-D.ietf-dime-rfc3588bis]
Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", draft-ietf-dime-rfc3588bis-34 "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-34
(work in progress), June 2012. (work in progress), June 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[I-D.ietf-soc-overload-control] [I-D.ietf-soc-overload-control]
Gurbani, V., Hilt, V., and H. Schulzrinne, "Session Gurbani, V., Hilt, V., and H. Schulzrinne, "Session
Initiation Protocol (SIP) Overload Control", Initiation Protocol (SIP) Overload Control",
draft-ietf-soc-overload-control-09 (work in progress), draft-ietf-soc-overload-control-10 (work in progress),
July 2012. October 2012.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design [RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design
Considerations for Session Initiation Protocol (SIP) Considerations for Session Initiation Protocol (SIP)
Overload Control", RFC 6357, August 2011. Overload Control", RFC 6357, August 2011.
Appendix A. Acknowledgements Appendix A. Acknowledgements
skipping to change at page 36, line 4 skipping to change at page 36, line 9
Because it is impossible to foresee all the potential constructs that Because it is impossible to foresee all the potential constructs that
it might be useful to scope operations to for the purposes of it might be useful to scope operations to for the purposes of
overload, we allow for the registration of new scopes. overload, we allow for the registration of new scopes.
At a minimum, such description needs to include: At a minimum, such description needs to include:
1. The name and IANA-registered number for negotiating and 1. The name and IANA-registered number for negotiating and
indicating the scope (see Section 5.4). indicating the scope (see Section 5.4).
2. A syntax for the "Details" field of the Overload-Info-Scope AVP, 2. A syntax for the "Details" field of the Overload-Info-Scope AVP,
preferably derived from one of the base Diameter data types. preferably derived from one of the base Diameter data types.
3. An explicit and unambiguous description of how both parties to 3. An explicit and unambiguous description of how both parties to
the overload control mechanism can determine which transactions the overload control mechanism can determine which transactions
correspond to the indicated scope. correspond to the indicated scope.
4. A clear and exhaustive list that extends the one in Section 2.2, 4. A clear and exhaustive list that extends the one in Section 2.2,
indicating exactly which combinations of scopes are allowed with indicating exactly which combinations of scopes are allowed with
the new scope. This list must take into account all of the IANA- the new scope. This list must take into account all of the IANA-
registered scopes at the time of its publication. registered scopes at the time of its publication.
It is acceptable for new scopes to be specific to constructs within It is acceptable for new scopes to be specific to constructs within
one or several applications. In other words, it may be desirable to one or several applications. In other words, it may be desirable to
define scopes that can be applied to one kind of application while define scopes that can be applied to one kind of application while
not making sense for another. Extension documents should be very not making sense for another. Extension documents should be very
clear that such is the case, however, if they choose to do so. clear that such is the case, however, if they choose to do so.
Appendix D. Design Rationale
The current design proposed in this document takes into account
several trade-offs and requirements that may not be immediately
obvious. The remainder of this appendix highlights some of the
potentially more controversial and/or non-obvious of these, and
attempts to explain why such decisions were made they way they were.
That said, none of the following text is intended to represent a line
in the sand. All of the decisions can be revisited if necessary,
especially if additional facts are brought into the analysis that
change the balance of the decisions.
D.1. Piggybacking
The decision to piggyback load information on existing messages
derives primarily from REQ 14 in [I-D.ietf-dime-overload-reqs]: "The
mechanism SHOULD provide for increased feedback when traffic levels
increase. The mechanism MUST NOT do this in such a way that it
increases the number of messages while at high loads."
If we were to introduce new messaging -- say, by defining a new
overload control Application -- then a node in overload would be
required to generate more messages at high load in order to keep
overload information in its peers up-to-date.
If further analysis determines that other factors are ultimately more
important than the provisions of REQ 14, several factors would need
to be considered.
First and foremost would be the prohibition, in the base Diameter
specification ([I-D.ietf-dime-rfc3588bis]), against adding new
commands to an existing application. Specifically, section 1.3.4
stipulates: "[A] new Diameter application MUST be created when one or
more of the following criteria are met:... A new command is used
within the existing application either because an additional command
is added, an existing command has been modified so that a new Command
Code had to be registered, or a command has been deleted." Because
of this stipulation, the addition of new command codes to existing
applications would require registration of entirely new application
IDs for those applications to support overload control. We consider
this to be too disruptive a change to consider.
By the author's reading, there is no provision that exempts the
"Diameter Common Messages" Application (Application ID 0) from the
above clauses. This effectively prohibits the additional of new
messages to this Application. While it may be theoretically possible
to specify behavior that hijacks the DWR/DWA watchdog messages for
the purpose of overload control messaging, doing so requires a
complete redefinition of their behavior and, fundamentally, their
semantics. This approach seems, at first blush, to be an
unacceptable change to the base Application.
The remaining approach -- defining a new application for overload
control -- has some promise, if we decide not to fulfill REQ 14. It
remains to be seen whether the users of the Diameter protocol,
including other SDOs who define applications for Diameter, are
willing to specify the use of multiple Diameter Applications for use
on a single reference point.
D.2. Load AVP in All Packets
Some have questioned the currently specified behavior of message
senders including a Load AVP in every message sent. This is being
proposed as a potential performance enhancement, with the idea being
that message recipients can save processing time by examining
arbitrarily selected messages for load information, rather than
looking for a Load AVP in every message that arrives. Of course, to
enable this kind of sampling, the Load AVP must be guaranteed to be
present; otherwise, attempts to find it will occasionally fail.
The reciprocal approach, of sending a Load AVP only when the Load has
changed (or changed by more than a certain amount), requires the
recipient to search through the Load-Info grouped AVP in every
message received in order to determine whether a Load AVP is present.
On a cursory analysis, we determined that appending a Load AVP to
each message is fundamentally a cheaper operation than traversing the
contents of each Load-Info AVP to determine whether a Load AVP is
present.
If a later decision is made to require examination of each message to
determine whether it include a Load AVP, we may be able to obtain
some efficiencies by requiring Load to be the first AVP in the Load-
Info AVP.
D.3. Graceful Failure
Some commenters have raised the question of whether a node can reject
an incoming connection upon recognizing that the remote node does not
support the Diameter overload control mechanism. One suggestion has
been to add a response code to indicate exactly such a situation.
So far, we have opted against doing so. Instead, we anticipate an
incremental deployment of the overload control mechanism, which will
likely consist of a mixture of nodes that support and node that do
not support the mechanism. Were we to allow the rejection of
connections that do not support the mechanism, we would create a
situation that necessitates a "flag day," on which every Diameter
node in a network is required to simultaneously, and in perfect
synchronization, switch from not supporting the overload mechanism,
to supporting it.
Given the operational difficulty of the foregoing, we have decided
that defining a response code, even if optional, that was to be used
to reject connections merely for the lack of overload control
support, would form an attractive nuisance for implementors. The
result could easily be a potential operational nightmare for network
operators.
Author's Address Author's Address
Adam Roach Adam Roach
Tekelec Tekelec
17210 Campbell Rd. 17210 Campbell Rd.
Suite 250 Suite 250
Dallas, TX 75252 Dallas, TX 75252
US US
Email: adam@nostrum.com Email: adam@nostrum.com
 End of changes. 38 change blocks. 
84 lines changed or deleted 230 lines changed or added

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