draft-ietf-dime-overload-reqs-08.txt   draft-ietf-dime-overload-reqs-09.txt 
Network Working Group E. McMurry Network Working Group E. McMurry
Internet-Draft B. Campbell Internet-Draft B. Campbell
Intended status: Informational Tekelec Intended status: Informational Tekelec
Expires: January 16, 2014 July 15, 2013 Expires: January 16, 2014 July 15, 2013
Diameter Overload Control Requirements Diameter Overload Control Requirements
draft-ietf-dime-overload-reqs-08 draft-ietf-dime-overload-reqs-09
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 sending traffic for some period of time. Otherwise, it must reduce sending traffic for some period of time. Otherwise, it must
continue to expend resources parsing and responding to Diameter continue to expend resources parsing and responding to Diameter
messages, possibly resulting in congestion collapse. The existing messages, possibly resulting in congestion collapse. The existing
Diameter mechanisms, listed in Section 4 are not sufficient for this Diameter mechanisms, listed in Section 4 are not sufficient for this
purpose. This document describes the limitations of the existing purpose. This document describes the limitations of the existing
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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
1.1. Documentation Conventions . . . . . . . . . . . . . . . . 3 1.1. Documentation Conventions . . . . . . . . . . . . . . . . 3
1.2. Causes of Overload . . . . . . . . . . . . . . . . . . . . 4 1.2. Causes of Overload . . . . . . . . . . . . . . . . . . . . 4
1.3. Effects of Overload . . . . . . . . . . . . . . . . . . . 5 1.3. Effects of Overload . . . . . . . . . . . . . . . . . . . 5
1.4. Overload vs. Network Congestion . . . . . . . . . . . . . 6 1.4. Overload vs. Network Congestion . . . . . . . . . . . . . 5
1.5. Diameter Applications in a Broader Network . . . . . . . . 6 1.5. Diameter Applications in a Broader Network . . . . . . . . 6
2. Overload Control Scenarios . . . . . . . . . . . . . . . . . . 6 2. Overload Control Scenarios . . . . . . . . . . . . . . . . . . 6
2.1. Peer to Peer Scenarios . . . . . . . . . . . . . . . . . . 7 2.1. Peer to Peer Scenarios . . . . . . . . . . . . . . . . . . 7
2.2. Agent Scenarios . . . . . . . . . . . . . . . . . . . . . 9 2.2. Agent Scenarios . . . . . . . . . . . . . . . . . . . . . 9
2.3. Interconnect Scenario . . . . . . . . . . . . . . . . . . 12 2.3. Interconnect Scenario . . . . . . . . . . . . . . . . . . 12
3. Diameter Overload Case Studies . . . . . . . . . . . . . . . . 13 3. Diameter Overload Case Studies . . . . . . . . . . . . . . . . 13
3.1. Overload in Mobile Data Networks . . . . . . . . . . . . . 13 3.1. Overload in Mobile Data Networks . . . . . . . . . . . . . 13
3.2. 3GPP Study on Core Network Overload . . . . . . . . . . . 15 3.2. 3GPP Study on Core Network Overload . . . . . . . . . . . 15
4. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 15 4. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 15
5. Issues with the Current Mechanisms . . . . . . . . . . . . . . 16 5. Issues with the Current Mechanisms . . . . . . . . . . . . . . 16
skipping to change at page 3, line 47 skipping to change at page 3, line 47
overload along with related scenarios and studies. Finally, it overload along with related scenarios and studies. Finally, it
offers a set of normative requirements for an improved overload offers a set of normative requirements for an improved overload
indication mechanism. indication mechanism.
1.1. Documentation Conventions 1.1. Documentation Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as defined in [RFC2119], with the document are to be interpreted as defined in [RFC2119], with the
exception that they are not intended for interoperability of exception that they are not intended for interoperability of
implementations. implementations. Rather, they are used to describe requirements
towards future specifications where the interoperability requirements
These requirements concern the standards specification process and will be defined.
not the implementation of specified standards. All requirements in
this document must be reflected by standards specifications to be
developed. However, which of the features specified by these
standards will be mandatory, recommended, or optional for compliant
implementations is to be defined by standards track document(s) and
not in this document.
The terms "client", "server", "agent", "node", "peer", "upstream", The terms "client", "server", "agent", "node", "peer", "upstream",
and "downstream" are used as defined in [RFC6733]. and "downstream" are used as defined in [RFC6733].
1.2. Causes of Overload 1.2. Causes of Overload
Overload occurs when an element, such as a Diameter server or agent, Overload occurs when an element, such as a Diameter server or agent,
has insufficient resources to successfully process all of the traffic has insufficient resources to successfully process all of the traffic
it is receiving. Resources include all of the capabilities of the it is receiving. Resources include all of the capabilities of the
element used to process a request, including CPU processing, memory, element used to process a request, including CPU processing, memory,
skipping to change at page 18, line 32 skipping to change at page 18, line 32
particular issues for overload control and have been addressed in an particular issues for overload control and have been addressed in an
ad hoc fashion by various implementations. Addressing these in a ad hoc fashion by various implementations. Addressing these in a
standard way would be a useful exercise, but it us beyond the scope standard way would be a useful exercise, but it us beyond the scope
of this document. of this document.
6. Extensibility and Application Independence 6. Extensibility and Application Independence
Given the variety of scenarios Diameter elements can be deployed in, Given the variety of scenarios Diameter elements can be deployed in,
and the variety of roles they can fulfill with Diameter and other and the variety of roles they can fulfill with Diameter and other
technologies, a single algorithm for handling overload may not be technologies, a single algorithm for handling overload may not be
sufficient. This effort cannot anticipate all possible future sufficient. For purposes of this discussion, algorithm is inclusive
scenarios and roles. Extensibility, particularly of algorithms used of behavior for control of overload, but does not encompass the
to deal with overload, will be important to cover these cases. general mechanism or transport of control information. This effort
cannot anticipate all possible future scenarios and roles.
Extensibility, particularly of algorithms used to deal with overload,
will be important to cover these cases.
Similarly, the scopes that overload information may apply to may Similarly, the scopes that overload information may apply to may
include cases that have not yet been considered. Extensibility in include cases that have not yet been considered. Extensibility in
this area will also be important. this area will also be important.
The basic mechanism is intended to be application-independent, that The basic mechanism is intended to be application-independent, that
is, a Diameter node can use it across any existing and future is, a Diameter node can use it across any existing and future
Diameter applications and expect reasonable results. Certain Diameter applications and expect reasonable results. Certain
Diameter applications might, however, benefit from application- Diameter applications might, however, benefit from application-
specific behavior over and above the mechanism's defaults. For specific behavior over and above the mechanism's defaults. For
 End of changes. 4 change blocks. 
14 lines changed or deleted 11 lines changed or added

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