One document matched: draft-ietf-dime-overload-reqs-12.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY
rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY
rfc6733 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.xml"> <!ENTITY
rfc5390 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5390.xml"> <!ENTITY
rfc6357 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6357.xml"> <!ENTITY
rfc2914 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2914.xml"> <!ENTITY
rfc3539 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3539.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc symrefs="yes" ?>
<rfc category="info" ipr="trust200902">
<front>
<title>Diameter Overload Control Requirements</title>
<author fullname="Eric McMurry" initials="E." surname="McMurry">
<organization>Tekelec</organization>
<address>
<postal>
<street>17210 Campbell Rd.</street>
<street>Suite 250</street>
<city>Dallas</city>
<region>TX</region>
<code>75252</code>
<country>US</country>
</postal>
<email>emcmurry@computer.org</email>
</address>
</author>
<author fullname="Ben Campbell" initials="B." surname="Campbell">
<organization>Tekelec</organization>
<address>
<postal>
<street>17210 Campbell Rd.</street>
<street>Suite 250</street>
<city>Dallas</city>
<region>TX</region>
<code>75252</code>
<country>US</country>
</postal>
<email>ben@nostrum.com</email>
</address>
</author>
<date/>
<!-- Date is auto-generated -->
<area>Operations</area>
<abstract>
<t>
When a Diameter server or agent becomes overloaded, it needs to be able
to gracefully reduce its load, typically by informing clients to reduce
sending traffic for some period of time. Otherwise, it must continue to
expend resources parsing and responding to Diameter messages, possibly
resulting in congestion collapse. The existing Diameter mechanisms are
not sufficient for this purpose. This document describes the
limitations of the existing mechanisms. Requirements for new overload
management mechanisms are also provided.
</t>
</abstract>
</front>
<middle>
<section anchor = "intro" title="Introduction">
<t>
A Diameter <xref target = "RFC6733"/> node is said to be overloaded
when it has insufficient resources to successfully process all of the
Diameter requests that it receives. When a node becomes overloaded, it
needs to be able to gracefully reduce its load, typically by informing
clients to reduce sending traffic for some period of time. Otherwise,
it must continue to expend resources parsing and responding to Diameter
messages, possibly resulting in congestion collapse. The existing
mechanisms provided by Diameter are not sufficient for this purpose.
This document describes the limitations of the existing mechanisms, and
provides requirements for new overload management mechanisms.
</t>
<t>
This document draws on the work done on SIP overload control
(<xref target="RFC5390"/>, <xref target="RFC6357"/>) as well as on
experience gained via overload handling in Signaling System No. 7 (SS7)
networks and studies done by the Third Generation Partnership Project
(3GPP) (<xref target="overload_studies" />).
</t>
<t>
Diameter is not typically an end-user protocol; rather it is generally
used as one component in support of some end-user activity.
</t>
<t>
For example, a SIP server might use Diameter to authenticate and
authorize user access. Overload in the Diameter backend infrastructure
will likely impact the experience observed by the end user in the SIP
application.
</t>
<t>
The impact of Diameter overload on the client application (a client
application may use the Diameter protocol and other protocols to do its
job) is beyond the scope of this document.
</t>
<t>
This document presents non-normative descriptions of causes of overload
along with related scenarios and studies. Finally, it offers a set of
normative requirements for an improved overload indication mechanism.
</t>
<section title="Documentation Conventions">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as defined in
<xref target="RFC2119"/>, with the exception that they are not
intended for interoperability of implementations. Rather, they are
used to describe requirements towards future specifications where the
interoperability requirements will be defined.
</t>
<t>
The terms "client", "server", "agent", "node", "peer", "upstream",
and "downstream" are used as defined in <xref target="RFC6733" />.
</t>
</section>
<section title="Causes of Overload" anchor="causes">
<t>
Overload occurs when an element, such as a Diameter server or agent,
has insufficient resources to successfully process all of the traffic
it is receiving. Resources include all of the capabilities of the
element used to process a request, including CPU processing, memory,
I/O, and disk resources. It can also include external resources such
as a database or DNS server, in which case the CPU, processing,
memory, I/O, and disk resources of those elements are effectively
part of the logical element processing the request.
</t>
<t>
External resources can include upstream Diameter nodes; for example,
a Diameter agent can become effectively overloaded if one or more
upstream nodes are overloaded. While overload is not the same thing
as network congestion, network congestion can reduce a Diameter nodes
ability to process and respond to requests, thus contributing to
overload.
</t>
<t>
A Diameter node can become overloaded due to request levels that
exceed its capacity, a reduction of available resources ( for
example, a local or upstream hardware failure) or a combination of
the two.
</t>
<t>
Overload can occur for many reasons, including:
</t>
<t>
<list style="hanging">
<t hangText="Inadequate capacity:">
When designing Diameter networks, that is, application layer
multi-node Diameter deployments, it can be very difficult to
predict all scenarios that may cause elevated traffic. It may also
be more costly to implement support for some scenarios than a
network operator may deem worthwhile. This results in the
likelihood that a Diameter network will not have adequate capacity
to handle all situations.
<vspace blankLines="1" />
</t>
<t hangText="Dependency failures:">
A Diameter node can become overloaded because a resource on which
it is dependent has failed or become overloaded, greatly reducing
the logical capacity of the node. In these cases, even minimal
traffic might cause the node to go into overload. Examples of such
dependency overloads include DNS servers, databases, disks, and
network interfaces.
<vspace blankLines="1" />
</t>
<t hangText="Component failures:">
A Diameter node can become overloaded when it is a member of a
cluster of servers that each share the load of traffic, and one or
more of the other members in the cluster fail. In this case, the
remaining nodes take over the work of the failed nodes. Normally,
capacity planning takes such failures into account, and servers
are typically run with enough spare capacity to handle failure of
another node. However, unusual failure conditions can cause many
nodes to fail at once. This is often the case with software
failures, where a bad packet or bad database entry hits the same
bug in a set of nodes in a cluster.
<vspace blankLines="1" />
</t>
<t hangText="Network Initiated Traffic Flood:">
Issues with the radio access network in a mobile network such as
radio overlays with frequent handovers, and operational changes
are examples of network events that can precipitate a flood of
Diameter signaling traffic, such as an avalanche restart. Failure
of a Diameter proxy may also result in a large amount of signaling
as connections and sessions are reestablished.
<vspace blankLines="1" />
</t>
<t hangText="Subscriber Initiated Traffic Flood:">
Large gatherings of subscribers or events that result in many
subscribers interacting with the network in close time proximity
can result in Diameter signaling traffic floods. For example, the
finale of a large fireworks show could be immediately followed by
many subscribers posting messages, pictures, and videos
concentrated on one portion of a network. Subscriber devices, such
as smartphones, may use aggressive registration strategies that
generate unusually high Diameter traffic loads.
<vspace blankLines="1" />
</t>
<t hangText="DoS attacks:">
An attacker, wishing to disrupt service in the network, can cause
a large amount of traffic to be launched at a target element. This
can be done from a central source of traffic or through a
distributed DoS attack. In all cases, the volume of traffic well
exceeds the capacity of the element, sending the system into
overload.
</t>
</list>
</t>
</section>
<section title="Effects of Overload" anchor="effects">
<t>
Modern Diameter networks, comprised of application layer multi-node
deployments of Diameter elements, may operate at very large
transaction volumes. If a Diameter node becomes overloaded, or even
worse, fails completely, a large number of messages may be lost very
quickly. Even with redundant servers, many messages can be lost in
the time it takes for failover to complete. While a Diameter client
or agent should be able to retry such requests, an overloaded peer
may cause a sudden large increase in the number of transaction
transactions needing to be retried, rapidly filling local queues or
otherwise contributing to local overload. Therefore Diameter devices
need to be able to shed load before critical failures can occur.
</t>
</section>
<section title="Overload vs. Network Congestion">
<t>
This document uses the term "overload" to refer to application-layer
overload at Diameter nodes. This is distinct from "network
congestion", that is, congestion that occurs at the lower networking
layers that may impact the delivery of Diameter messages between
nodes. The authors recognize that element overload and network
congestion are interrelated, and that overload can contribute to
network congestion and vice versa.
</t>
<t>
Network congestion issues are better handled by the transport
protocols. Diameter uses TCP and SCTP, both of which include
congestion management features. Analysis of whether those features
are sufficient for transport level congestion between Diameter nodes,
and any work to further mitigate network congestion is out of scope
both for this document, and for the work proposed by this document.
</t>
</section>
<section title="Diameter Applications in a Broader Network">
<t>
Most elements using Diameter applications do not use Diameter
exclusively. It is important to realize that overload of an element
can be caused by a number of factors that may be unrelated to the
processing of Diameter or Diameter applications.
</t>
<t>
An element that doesn't use Diameter exclusively needs to be able to
signal to Diameter peers that it is experiencing overload regardless
of the cause of the overload, since the overload will affect that
element's ability to process Diameter transactions. If the element
communicates with other protocols than Diameter, it may also need to
signal the overload situation on these protocols depending on its
function and the architecture of the network and application it is
providing services for. Whether that is necessary can only be decided
within the context of that architecture and use cases. A mechanism
for signaling overload with Diameter, which this specification
details the requirements for, provides Diameter nodes the ability to
signal their Diameter peers of overload, mitigating that part of the
issue. Diameter nodes may need to use this, as well as other
mechanisms, to solve their broader overload issues. Indicating
overload on protocols other than Diameter is out of scope for this
document, and for the work proposed by this document.
</t>
</section>
</section>
<section anchor="scenarios" title="Overload Control Scenarios">
<t>
Several Diameter deployment scenarios exist that may impact overload
management. The following scenarios help motivate the requirements for
an overload management mechanism.
</t>
<t>
These scenarios are by no means exhaustive, and are in general
simplified for the sake of clarity. In particular, the authors assume
for the sake of clarity that the client sends Diameter requests to the
server, and the server sends responses to client, even though Diameter
supports bidirectional applications. Each direction in such an
application can be modeled separately.
</t>
<t>
In a large scale deployment, many of the nodes represented in these
scenarios would be deployed as clusters of servers. The authors assume
that such a cluster is responsible for managing its own internal load
balancing and overload management so that it appears as a single
Diameter node. That is, other Diameter nodes can treat it as single,
monolithic node for the purposes of overload management.
</t>
<t>
These scenarios do not illustrate the client application. As mentioned
in <xref target="intro" />, Diameter is not typically an end-user
protocol; rather it is generally used in support of some other client
application. These scenarios do not consider the impact of Diameter
overload on the client application.
</t>
<section anchor="p2p-scenarios" title="Peer to Peer Scenarios">
<t>
This section describes Diameter peer-to-peer scenarios. That is,
scenarios where a Diameter client talks directly with a Diameter
server, without the use of a Diameter agent.
</t>
<t>
<xref target="fig-p2p-basic"/> illustrates the simplest possible
Diameter relationship. The client and server share a one-to-one
peer-to-peer relationship. If the server becomes overloaded, either
because the client exceeds the server's capacity, or because the
server's capacity is reduced due to some resource dependency, the
client needs to reduce the amount of Diameter traffic it sends to the
server. Since the client cannot forward requests to another server,
it must either queue requests until the server recovers, or itself
become overloaded in the context of the client application and other
protocols it may also use.
</t>
<figure anchor="fig-p2p-basic" title="Basic Peer to Peer Scenario">
<artwork>
+------------------+
| |
| |
| Server |
| |
+--------+---------+
|
|
+--------+---------+
| |
| |
| Client |
| |
+------------------+
</artwork>
</figure>
<t>
<xref target ="fig-p2p-multi-server"/> shows a similar scenario,
except in this case the client has multiple servers that can handle
work for a specific realm and application. If server 1 becomes
overloaded, the client can forward traffic to server 2. Assuming
server 2 has sufficient reserve capacity to handle the forwarded
traffic, the client should be able to continue serving client
application protocol users. If server 1 is approaching overload, but
can still handle some number of new request, it needs to be able to
instruct the client to forward a subset of its traffic to server 2.
</t>
<figure anchor="fig-p2p-multi-server" title="Multiple Server Peer to Peer Scenario">
<artwork>
+------------------+ +------------------+
| | | |
| | | |
| Server 1 | | Server 2 |
| | | |
+--------+-`.------+ +------.'+---------+
`. .'
`. .'
`. .'
`. .'
+-------`.'--------+
| |
| |
| Client |
| |
+------------------+
</artwork>
</figure>
<t>
<xref target="fig-p2p-multi-app" /> illustrates a peer-to-peer
scenario with multiple Diameter realm and application combinations.
In this example, server 2 can handle work for both applications. Each
application might have different resource dependencies. For example,
a server might need to access one database for application A, and
another for application B. This creates a possibility that Server 2
could become overloaded for application A but not for application B,
in which case the client would need to divert some part of its
application A requests to server 1, but should not divert any
application B requests. This requires server 2 to be able to
distinguish between applications when it indicates an overload
condition to the client.
</t>
<t>
On the other hand, it's possible that the servers host many
applications. If server 2 becomes overloaded for all applications, it
would be undesirable for it to have to notify the client separately
for each application. Therefore it also needs a way to indicate that
it is overloaded for all possible applications.
</t>
<figure anchor="fig-p2p-multi-app" title="Multiple Application Peer to Peer Scenario">
<artwork>
+---------------------------------------------+
| Application A +----------------------+----------------------+
|+------------------+ | +----------------+ | +------------------+|
|| | | | | | | ||
|| | | | | | | ||
|| Server 1 | | | Server 2 | | | Server 3 ||
|| | | | | | | ||
|+--------+---------+ | +-------+--------+ | +-+----------------+|
| | | | | | |
+---------+-----------+----------+-----------+ | |
| | | | |
| | | | Application B |
| +----------+----------------+-----------------+
``-.._ | |
`-..__ | _.-''
`--._ | _.-''
``-._ | _.-''
+-----`-.-''-----+
| |
| |
| Client |
| |
+----------------+
</artwork>
</figure>
</section>
<section anchor="agent-scenarios" title="Agent Scenarios">
<t>
This section describes scenarios that include a Diameter agent,
either in the form of a Diameter relay or Diameter proxy. These
scenarios do not consider Diameter redirect agents, since they are
more readily modeled as end-servers.
</t>
<t>
<xref target="fig-agent-basic" /> illustrates a simple Diameter agent
scenario with a single client, agent, and server. In this case,
overload can occur at the server, at the agent, or both. But in most
cases, client behavior is the same whether overload occurs at the
server or at the agent. From the client's perspective, server
overload and agent overload is the same thing.
</t>
<figure anchor="fig-agent-basic" title="Basic Agent Scenario">
<artwork>
+------------------+
| |
| |
| Server |
| |
+--------+---------+
|
|
+--------+---------+
| |
| |
| Agent |
| |
+--------+---------+
|
|
+--------+---------+
| |
| |
| Client |
| |
+------------------+
</artwork>
</figure>
<t>
<xref target="fig-agent-multi-server" /> shows an agent scenario with
multiple servers. If server 1 becomes overloaded, but server 2 has
sufficient reserve capacity, the agent may be able to transparently
divert some or all Diameter requests originally bound for server 1 to
server 2.
</t>
<t>
In most cases, the client does not have detailed knowledge of the
Diameter topology upstream of the agent. If the agent uses dynamic
discovery to find eligible servers, the set of eligible servers may
not be enumerable from the perspective of the client. Therefore, in
most cases the agent needs to deal with any upstream overload issues
in a way that is transparent to the client. If one server notifies
the agent that it has become overloaded, the notification should not
be passed back to the client in a way that the client could
mistakenly perceive the agent itself as being overloaded. If the set
of all possible destinations upstream of the agent no longer has
sufficient capacity for incoming load, the agent itself becomes
effectively overloaded.
</t>
<t>
On the other hand, there are cases where the client needs to be able
to select a particular server from behind an agent. For example, if a
Diameter request is part of a multiple-round-trip authentication, or
is otherwise part of a Diameter "session", it may have a
DestinationHost AVP that requires the request to be served by server
1. Therefore the agent may need to inform a client that a particular
upstream server is overloaded or otherwise unavailable. Note that
there can be many ways a server can be specified, which may have
different implications (e.g. by IP address, by host name, etc).
</t>
<figure anchor="fig-agent-multi-server" title="Multiple Server Agent Scenario">
<artwork>
+------------------+ +------------------+
| | | |
| | | |
| Server 1 | | Server 2 |
| | | |
+--------+-`.------+ +------.'+---------+
`. .'
`. .'
`. .'
`. .'
+-------`.'--------+
| |
| |
| Agent |
| |
+--------+---------+
|
|
|
+--------+---------+
| |
| |
| Client |
| |
+------------------+
</artwork>
</figure>
<t>
<xref target="fig-agent-multi-app" /> shows a scenario where an agent
routes requests to a set of servers for more than one Diameter realm
and application. In this scenario, if server 1 becomes overloaded or
unavailable while server 2 still has available capacity, the agent
may effectively operate at reduced capacity for application A, but at
full capacity for application B. Therefore, the agent needs to be
able to report that it is overloaded for one application, but not for
another.
</t>
<figure anchor="fig-agent-multi-app" title="Multiple Application Agent Scenario">
<artwork>
+--------------------------------------------+
| Application A +----------------------+----------------------+
|+------------------+ | +----------------+ | +------------------+|
|| | | | | | | ||
|| | | | | | | ||
|| Server 1 | | | Server 2 | | | Server 3 ||
|| | | | | | | ||
|+---------+--------+ | +-------+--------+ | +--+---------------+|
| | | | | | |
+----------+----------+----------+-----------+ | |
| | | | |
| | | | Application B |
| +----------+-----------------+----------------+
| | |
``--.__ | _.
``-.__ | __.--''
`--.._ | _..--'
+----``-+.''-----+
| |
| |
| Agent |
| |
+-------+--------+
|
|
+-------+--------+
| |
| |
| Client |
| |
+----------------+
</artwork>
</figure>
</section>
<section title="Interconnect Scenario">
<t>
Another scenario to consider when looking at Diameter overload is
that of multiple network operators using Diameter components
connected through an interconnect service, e.g. using IPX. IPX (IP
eXchange) <xref target="IR.34"/> is an Inter-Operator IP Backbone
that provides roaming interconnection network between mobile
operators and service providers. The IPX is also used to transport
Diameter signaling between operators <xref target="IR.88"/>.
<xref target="fig-interconnect" /> shows two network operators with
an interconnect network in-between. There could be any number of
these networks between any two network operator's networks.
</t>
<figure anchor="fig-interconnect" title="Two Network Interconnect Scenario">
<artwork>
+-------------------------------------------+
| Interconnect |
| |
| +--------------+ +--------------+ |
| | Server 3 |------| Server 4 | |
| +--------------+ +--------------+ |
| .' `. |
+------.-'--------------------------`.------+
.' `.
.-' `.
------------.'-----+ +----`.-------------
+----------+ | | +----------+
| Server 1 | | | | Server 2 |
+----------+ | | +----------+
| |
Network Operator 1 | | Network Operator 2
-------------------+ +-------------------
</artwork>
</figure>
<t>
The characteristics of the information that an operator would want to
share over such a connection are different from the information
shared between components within a network operator's network.
Network operators may not want to convey topology or operational
information, which limits how much overload and loading information
can be sent. For the interconnect scenario shown, Server 2 may want
to signal overload to Server 1, to affect traffic coming from Network
Operator 1.
</t>
<t>
This case is distinct from those internal to a network operator's
network, where there may be many more elements in a more complicated
topology. Also, the elements in the interconnect network may not
support Diameter overload control, and the network operators may not
want the interconnect network to use overload or loading information.
They may only want the information to pass through the interconnect
network without further processing or action by the interconnect
network even if the elements in the interconnect network do support
Diameter overload control.
</t>
</section>
</section>
<section title="Diameter Overload Case Studies" anchor="overload_studies">
<section title="Overload in Mobile Data Networks">
<t>
As the number of Third Generation (3G) and Long Term Evolution (LTE)
enabled smartphone devices continue to expand in mobile networks,
there have been situations where high signaling traffic load led to
overload events at the Diameter-based Home Location Registries (HLR)
and/or Home Subscriber Servers (HSS) <xref target="TR23.843"/>. The
root causes of the HLR congestion events were manifold but included
hardware failure and procedural errors. The result was high signaling
traffic load on the HLR and HSS.
</t>
<t>
The 3GPP architecture <xref target="TS23.002"/> makes extensive use
of Diameter. It is used for mobility management
<xref target="TS29.272"/> (and others), (IP Multimedia Subsystem) IMS
<xref target="TS29.228"/> (and others), policy and charging control
<xref target="TS29.212"/> (and others) as well as other functions.
The details of the architecture are out of scope for this document,
but it is worth noting that there are quite a few Diameter
applications, some with quite large amounts of Diameter signaling in
deployed networks.
</t>
<t>
The 3GPP specifications do not currently address overload for
Diameter applications or provide an equivalent load control mechanism
to those provided in the more traditional SS7 elements in (Global
System for Mobile Communications) GSM <xref target="TS29.002"/>. The
capabilities specified in the 3GPP standards do not adequately
address the abnormal condition where excessively high signaling
traffic load situations are experienced.
</t>
<t>
Smartphones, an increasingly large percentage of mobile devices,
contribute much more heavily, relative to non-smartphones, to the
continuation of a registration surge due to their very aggressive
registration algorithms. Smartphone behavior contributes to network
loading and can contribute to overload conditions. The aggressive
smartphone logic is designed to:
</t>
<t>
<list style='letters'>
<t>
always have voice and data registration, and
<vspace blankLines="1" />
</t>
<t>
constantly try to be on 3G or LTE data (and thus on 3G voice or
VoLTE <xref target="IR.92"/>) for their added benefits.
</t>
</list>
</t>
<t>
Non-smartphones typically have logic to wait for a time period after
registering successfully on voice and data.
</t>
<t>
The smartphone aggressive registration is problematic in two ways:
</t>
<t>
<list style="symbols">
<t>
first by generating excessive signaling load towards the HSS that
is ten times that from a non-smartphone,
<vspace blankLines="1" />
</t>
<t>
and second by causing continual registration attempts when a
network failure affects registrations through the 3G data network.
</t>
</list>
</t>
</section>
<section title="3GPP Study on Core Network Overload">
<t>
A study in 3GPP SA2 on core network overload has produced the
technical report <xref target="TR23.843"/>. This enumerates several
causes of overload in mobile core networks including portions that
are signaled using Diameter. TR23.843 is a work in progress and is
not complete. However, it is useful for pointing out scenarios and
the general need for an overload control mechanism for Diameter.
</t>
<t>
It is common for mobile networks to employ more than one radio
technology and to do so in an overlay fashion with multiple
technologies present in the same location (such as 2nd or 3rd
generation mobile technologies along with LTE). This presents
opportunities for traffic storms when issues occur on one overlay and
not another as all devices that had been on the overlay with issues
switch. This causes a large amount of Diameter traffic as locations
and policies are updated.
</t>
<t>
Another scenario called out by this study is a flood of registration
and mobility management events caused by some element in the core
network failing. This flood of traffic from end nodes falls under the
network initiated traffic flood category. There is likely to also be
traffic resulting directly from the component failure in this case. A
similar flood can occur when elements or components recover as well.
</t>
<t>
Subscriber initiated traffic floods are also indicated in this study
as an overload mechanism where a large number of mobile devices
attempting to access services at the same time, such as in response
to an entertainment event or a catastrophic event.
</t>
<t>
While this 3GPP study is concerned with the broader effects of these
scenarios on wireless networks and their elements, they have
implications specifically for Diameter signaling. One of the goals of
this document is to provide guidance for a core mechanism that can be
used to mitigate the scenarios called out by this study.
</t>
</section>
</section>
<section anchor="Existing_Mechanisms" title="Existing Mechanisms">
<t>
Diameter offers both implicit and explicit mechanisms for a Diameter
node to learn that a peer is overloaded or unreachable. The implicit
mechanism is simply the lack of responses to requests. If a client
fails to receive a response in a certain time period, it assumes the
upstream peer is unavailable, or overloaded to the point of effective
unavailability. The <xref target = "RFC3539">watchdog mechanism</xref>
ensures that a certain rate of transaction responses occur even when
there is otherwise little or no other Diameter traffic.
</t>
<t>
The explicit mechanism can involve specific protocol error responses,
where an agent or server tells a downstream peer that it is either too
busy to handle a request (DIAMETER_TOO_BUSY) or unable to route a
request to an upstream destination (DIAMETER_UNABLE_TO_DELIVER),
perhaps because that destination itself is overloaded to the point of
unavailability.
</t>
<t>
Another explicit mechanism, a DPR (Disconnect-Peer-Request) message,
can be sent with a Disconnect-Cause of BUSY. This signals the sender's
intent to close the transport connection, and requests the client not
to reconnect.
</t>
<t>
Once a Diameter node learns that an upstream peer has become overloaded
via one of these mechanisms, it can then attempt to take action to
reduce the load. This usually means forwarding traffic to an alternate
destination, if available. If no alternate destination is available,
the node must either reduce the number of messages it originates (in
the case of a client) or inform the client to reduce traffic (in the
case of an agent.)
</t>
<t>
Diameter requires the use of a congestion-managed transport layer,
currently TCP or SCTP, to mitigate network congestion. It is expected
that these transports manage network congestion and that issues with
transport (e.g. congestion propagation and window management) are
managed at that level. But even with a congestion-managed transport, a
Diameter node can become overloaded at the Diameter protocol or
application layers due to the causes described in
<xref target="causes" /> and congestion managed transports do not
provide facilities (and are at the wrong level) to handle server
overload. Transport level congestion management is also not sufficient
to address overload in cases of multi-hop and multi-destination
signaling.
</t>
</section>
<section title="Issues with the Current Mechanisms" anchor="issues">
<t>
The currently available Diameter mechanisms for indicating an overload
condition are not adequate to avoid service outages due to overload.
This inadequacy may, in turn, contribute to broader congestion impacts
due to unresponsive Diameter nodes causing application or transport
layer retransmissions. In particular, they do not allow a Diameter
agent or server to shed load as it approaches overload. At best, a node
can only indicate that it needs to entirely stop receiving requests,
i.e. that it has effectively failed. Even that is problematic due to
the inability to indicate durational validity on the transient errors
available in the base Diameter protocol. Diameter offers no mechanism
to allow a node to indicate different overload states for different
categories of messages, for example, if it is overloaded for one
Diameter application but not another.
</t>
<section title = "Problems with Implicit Mechanism">
<t>
The implicit mechanism doesn't allow an agent or server to inform the
client of a problem until it is effectively too late to do anything
about it. The client does not know to take action until the upstream
node has effectively failed. A Diameter node has no opportunity to
shed load early to avoid collapse in the first place.
</t>
<t>
Additionally, the implicit mechanism cannot distinguish between
overload of a Diameter node and network congestion. Diameter treats
the failure to receive an answer as a transport failure.
</t>
</section>
<section title="Problems with Explicit Mechanisms">
<t>
The Diameter specification is ambiguous on how a client should handle
receipt of a DIAMETER_TOO_BUSY response. The
<xref target="RFC6733">base specification</xref> indicates that the
sending client should attempt to send the request to a different
peer. It makes no suggestion that the receipt of a DIAMETER_TOO_BUSY
response should affect future Diameter messages in any way.
</t>
<t>
The Authentication, Authorization, and Accounting (AAA) Transport
Profile <xref target="RFC3539" /> recommends that a AAA node that
receives a "Busy" response failover all remaining requests to a
different agent or server. But while the Diameter base specification
explicitly depends on RFC3539 to define transport behavior, it does
not refer to RFC3539 in the description of behavior on receipt of
DIAMETER_TOO_BUSY. There's a strong likelihood that at least some
implementations will continue to send Diameter requests to an
upstream peer even after receiving a DIAMETER_TOO_BUSY error.
</t>
<t>
<xref target="RFC2914">BCP 41</xref> describes, among other things,
how end-to-end application behavior can help avoid congestion
collapse. In particular, an application should avoid sending messages
that will never be delivered or processed. The DIAMETER_TOO_BUSY
behavior as described in the Diameter base specification fails at
this, since if an upstream node becomes overloaded, a client attempts
each request, and does not discover the need to failover the request
until the initial attempt fails.
</t>
<t>
The situation is improved if implementations follow the
<xref target="RFC3539"/> recommendation and keep state about
upstream peer overload. But even then, the Diameter specification
offers no guidance on how long a client should wait before retrying
the overloaded destination. If an agent or server supports multiple
realms and/or applications, DIAMETER_TOO_BUSY offers no way to
indicate that it is overloaded for one application but not another. A
DIAMETER_TOO_BUSY error can only indicate overload at a "whole
server" scope.
</t>
<t>
Agent processing of a DIAMETER_TOO_BUSY response is also problematic
as described in the base specification. DIAMETER_TOO_BUSY is defined
as a protocol error. If an agent receives a protocol error, it may
either handle it locally or it may forward the response back towards
the downstream peer. If a downstream peer receives the
DIAMETER_TOO_BUSY response, it may stop sending all requests to the
agent for some period of time, even though the agent may still be
able to deliver requests to other upstream peers.
</t>
<t>
DIAMETER_UNABLE_TO_DELIVER, or using DPR with cause code BUSY also
have no mechanisms for specifying the scope or cause of the failure,
or the durational validity.
</t>
<t>
The issues with error responses in <xref target="RFC6733"/> extend
beyond the particular issues for overload control and have been
addressed in an ad hoc fashion by various implementations. Addressing
these in a standard way would be a useful exercise, but it us beyond
the scope of this document.
</t>
</section>
</section>
<section title="Extensibility and Application Independence">
<t>
Given the variety of scenarios Diameter elements can be deployed in,
and the variety of roles they can fulfill with Diameter and other
technologies, a single algorithm for handling overload may not be
sufficient. For purposes of this discussion, algorithm is inclusive of
behavior for control of overload, but does not encompass the 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.
</t>
<t>
Similarly, the scopes that overload information may apply to may
include cases that have not yet been considered. Extensibility in this
area will also be important.
</t>
<t>
The basic mechanism is intended to be application-independent, that is,
a Diameter node can use it across any existing and future Diameter
applications and expect reasonable results. Certain Diameter
applications might, however, benefit from application-specific behavior
over and above the mechanism's defaults. For example, an application
specification might specify relative priorities of messages or
selection of a specific overload control algorithm.
</t>
</section>
<section anchor="requirements" title="Solution Requirements">
<t>
This section proposes requirements for an improved mechanism to control
Diameter overload, with the goals of improving the issues described in
<xref target="issues" /> and supporting the scenarios described in
<xref target="scenarios" />. These requirements are stated primarily in
terms of individual node behavior to inform the design of the improved
mechanism; solution designers should keep in mind that the overall goal
is improved overall system behavior across all the nodes involved, not
just improved behavior from specific individual nodes.
</t>
<!-- general requirements -->
<section title="General">
<t>
<list style='format REQ %d:' counter='Requirements'>
<t>
The solution MUST provide a communication method for Diameter
nodes to exchange load and overload information.
<vspace blankLines="1" />
</t>
<t>
The solution MUST allow Diameter nodes to support overload control
regardless of which Diameter applications they support. Diameter
clients and agents must be able to use the received load and
overload information to support graceful behavior during an
overload condition. Graceful behavior under overload conditions is
best described by REQ 3.
<vspace blankLines="1" />
</t>
<t>
The solution MUST limit the impact of overload on the overall
useful throughput of a Diameter server, even when the incoming
load on the network is far in excess of its capacity. The overall
useful throughput under load is the ultimate measure of the value
of a solution.
<vspace blankLines="1" />
</t>
<t>
Diameter allows requests to be sent from either side of a
connection and either side of a connection may have need to
provide its overload status. The solution MUST allow each side of
a connection to independently inform the other of its overload
status.
<vspace blankLines="1" />
</t>
<t>
Diameter allows nodes to determine their peers via dynamic
discovery or manual configuration. The solution MUST work
consistently without regard to how peers are determined.
<vspace blankLines="1" />
</t>
<t>
The solution designers SHOULD seek to minimize the amount of new
configuration required in order to work. For example, it is better
to allow peers to advertise or negotiate support for the solution,
rather than to require this knowledge to be configured at each
node.
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
<!-- performance -->
<section title="Performance">
<t>
<list style='format REQ %d:' counter='Requirements'>
<t anchor="stability_req">
The solution and any associated default algorithm(s) MUST ensure
that the system remains stable. At some point after an overload
condition has ended, the solution MUST enable capacity to
stabilize and become equal to what it would be in the absence of
an overload condition. Note that this also requires that the
solution MUST allow nodes to shed load without introducing non
converging oscillations during or after an overload condition.
<vspace blankLines="1" />
</t>
<t>
Supporting nodes MUST be able to distinguish current overload
information from stale information.
<vspace blankLines="1" />
</t>
<t>
The solution MUST function across fully loaded as well as
quiescent transport connections. This is partially derived from
the requirement for stability in REQ 7.
<vspace blankLines="1" />
</t>
<t>
Consumers of overload information MUST be able to determine when
the overload condition improves or ends.
<vspace blankLines="1" />
</t>
<t>
The solution MUST be able to operate in networks of different
sizes.
<vspace blankLines="1" />
</t>
<t>
When a single network node fails, goes into overload, or suffers
from reduced processing capacity, the solution MUST make it
possible to limit the impact of this on other nodes in the
network. This helps to prevent a small-scale failure from becoming
a widespread outage.
<vspace blankLines="1" />
</t>
<t>
The solution MUST NOT introduce substantial additional work for
node in an overloaded state. For example, a requirement for an
overloaded node to send overload information every time it
received a new request would introduce substantial work.
<vspace blankLines="1" />
</t>
<t>
Some scenarios that result in overload involve a rapid increase of
traffic with little time between normal levels and overload
inducing levels. The solution SHOULD provide for rapid feedback
when traffic levels increase.
<vspace blankLines="1" />
</t>
<t>
The solution MUST NOT interfere with the congestion control
mechanisms of underlying transport protocols. For example, a
solution that opened additional TCP connections when the network
is congested would reduce the effectiveness of the underlying
congestion control mechanisms.
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
<!-- mixed support -->
<section title="Heterogeneous Support for Solution">
<t>
<list style='format REQ %d:' counter='Requirements'>
<t>
The solution is likely to be deployed incrementally. The solution
MUST support a mixed environment where some, but not all, nodes
implement it.
<vspace blankLines="1" />
</t>
<t>
In a mixed environment with nodes that support the solution and
that do not, the solution MUST NOT result in materially less
useful throughput as would have resulted if the solution were not
present. It SHOULD result in less severe congestion in this
environment.
<vspace blankLines="1" />
</t>
<t>
In a mixed environment of nodes that support the solution and that
do not, the solution MUST NOT preclude elements that support
overload control from treating elements that do not support
overload control in a equitable fashion relative to those that do.
Users and operators of nodes that do not support the solution MUST
NOT unfairly benefit from the solution. The solution specification
SHOULD provide guidance to implementors for dealing with elements
not supporting overload control.
<vspace blankLines="1" />
</t>
<t>
It MUST be possible to use the solution between nodes in different
realms and in different administrative domains.
<vspace blankLines="1" />
</t>
<t>
Any explicit overload indication MUST be clearly distinguishable
from other errors reported via Diameter.
<vspace blankLines="1" />
</t>
<t>
In cases where a network node fails, is so overloaded that it
cannot process messages, or cannot communicate due to a network
failure, it may not be able to provide explicit indications of the
nature of the failure or its levels of congestion. The solution
MUST result in at least as much useful throughput as would have
resulted if the solution was not in place.
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
<!-- granular control -->
<section title="Granular Control">
<t>
<list style='format REQ %d:' counter='Requirements'>
<t>
The solution MUST provide a way for a node to throttle the amount
of traffic it receives from a peer node. This throttling SHOULD be
graded so that it can be applied gradually as offered load
increases. Overload is not a binary state; there may be degrees of
overload.
<vspace blankLines="1" />
</t>
<t>
The solution MUST provide sufficient information to enable a load
balancing node to divert messages that are rejected or otherwise
throttled by an overloaded upstream node to other upstream nodes
that are the most likely to have sufficient capacity to process
them.
<vspace blankLines="1" />
</t>
<t>
The solution MUST provide a mechanism for indicating load levels
even when not in an overloaded condition, to assist nodes making
decisions to prevent overload conditions from occurring.
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
<!-- priority and policy -->
<section title="Priority and Policy">
<t>
<list style='format REQ %d:' counter='Requirements'>
<t>
The base specification for the solution SHOULD offer general
guidance on which message types might be desirable to send or
process over others during times of overload, based on
application-specific considerations. For example, it may be more
beneficial to process messages for existing sessions ahead of new
sessions. Some networks may have a requirement to give priority to
requests associated with emergency sessions. Any normative or
otherwise detailed definition of the relative priorities of
message types during an overload condition will be the
responsibility of the application specification.
<vspace blankLines="1" />
</t>
<t>
The solution MUST NOT prevent a node from prioritizing requests
based on any local policy, so that certain requests are given
preferential treatment, given additional retransmission, not
throttled, or processed ahead of others.
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
<!-- security -->
<section title="Security">
<t>
<list style='format REQ %d:' counter='Requirements'>
<t>
The solution MUST NOT provide new vulnerabilities to malicious
attack, or increase the severity of any existing vulnerabilities.
This includes vulnerabilities to DoS and DDoS attacks as well as
replay and man-in-the middle attacks. Note that the
<xref target="RFC6733"> Diameter base specification </xref> lacks
end to end security and this must be considered. Note that this
requirement was expressed at a high level so as to not preclude
any particular solution. Is is expected that the solution will
address this in more detail.
<vspace blankLines="1" />
</t>
<t>
The solution MUST NOT depend on being deployed in environments
where all Diameter nodes are completely trusted. It SHOULD operate
as effectively as possible in environments where other nodes are
malicious; this includes preventing malicious nodes from obtaining
more than a fair share of service. Note that this does not imply
any responsibility on the solution to detect, or take
countermeasures against, malicious nodes.
<vspace blankLines="1" />
</t>
<t>
It MUST be possible for a supporting node to make authorization
decisions about what information will be sent to peer nodes based
on the identity of those nodes. This allows a domain administrator
who considers the load of their nodes to be sensitive information
to restrict access to that information. Of course, in such cases,
there is no expectation that the solution itself will help prevent
overload from that peer node.
<vspace blankLines="1" />
</t>
<t>
The solution MUST NOT interfere with any Diameter compliant method
that a node may use to protect itself from overload from
non-supporting nodes, or from denial of service attacks.
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
<!-- flexibility and extensibility -->
<section title="Flexibility and Extensibility">
<t>
<list style='format REQ %d:' counter='Requirements'>
<t>
There are multiple situations where a Diameter node may be
overloaded for some purposes but not others. For example, this can
happen to an agent or server that supports multiple applications,
or when a server depends on multiple external resources, some of
which may become overloaded while others are fully available. The
solution MUST allow Diameter nodes to indicate overload with
sufficient granularity to allow clients to take action based on
the overloaded resources without unreasonably forcing available
capacity to go unused. The solution MUST support specification of
overload information with granularities of at least "Diameter
node", "realm", and "Diameter application", and MUST allow
extensibility for others to be added in the future.
<vspace blankLines="1" />
</t>
<t>
The solution MUST provide a method for extending the information
communicated and the algorithms used for overload control.
<vspace blankLines="1" />
</t>
<t>
The solution MUST provide a default algorithm that is mandatory to
implement.
<vspace blankLines="1" />
</t>
<t>
The solution SHOULD provide a method for exchanging overload and
load information between elements that are connected by
intermediaries that do not support the solution.
<vspace blankLines="1" />
</t>
</list>
</t>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>
This document makes no requests of IANA.
</t>
</section>
<section title="Security Considerations">
<t>
A Diameter overload control mechanism is primarily concerned with the
load and overload related behavior of nodes in a Diameter network, and
the information used to affect that behavior. Load and overload
information is shared between nodes and directly affects the behavior
and thus is potentially vulnerable to a number of methods of attack.
</t>
<t>
Load and overload information may also be sensitive from both business
and network protection viewpoints. Operators of Diameter equipment want
to control visibility to load and overload information to keep it from
being used for competitive intelligence or for targeting attacks. It is
also important that the Diameter overload control mechanism not
introduce any way in which any other information carried by Diameter is
sent inappropriately.
</t>
<t>
Note that the <xref target="RFC6733"> Diameter base specification
</xref> lacks end to end security, making verifying the authenticity
and ownership of load and overload information difficult for
non-adjacent nodes. Authentication of load and overload information
helps to alleviate several of the security issues listed in this
section.
</t>
<t>
This document includes requirements intended to mitigate the effects of
attacks and to protect the information used by the mechanism. This
section discusses potential security considerations for overload
control solutions. This discussion provides the motivation for several
normative requirements described in <xref target="requirements"/>. The
discussion includes specific references to the normative requirements
that apply for each issue.
</t>
<section title="Access Control">
<t>
To control the visibility of load and overload information, sending
should be subject to some form of authentication and authorization of
the receiver. It is also important to the receivers that they are
confident the load and overload information they receive is from a
legitimate source. REQ 28 requires the solution to work without
assuming that all Diameter nodes in a network are trusted for the
purposes of exchanging overload and load information. REQ 29 requires
the solution to let nodes restrict unauthorized parties from seeing
overload information. Note that this implies a certain amount of
configurability on the nodes supporting the Diameter overload control
mechanism.
</t>
</section>
<section title="Denial-of-Service Attacks">
<t>
An overload control mechanism provides a very attractive target for
denial-of-service attacks. A small number of messages may affect a
large service disruption by falsely reporting overload conditions.
Alternately, attacking servers nearing, or in, overload may also be
facilitated by disrupting their overload indications, potentially
preventing them from mitigating their overload condition.
</t>
<t>
A design goal for the Diameter overload control mechanism is to
minimize or eliminate the possibility of using the mechanism for this
type of attack. More strongly, REQ 27 forbids the solution from
introducing new vulnerabilities to malicious attack. Additionally,
REQ 30 stipulates that the solution not interfere with other
mechanisms used for protection against denial of service attacks.
</t>
<t>
As the intent of some denial-of-service attacks is to induce overload
conditions, an effective overload control mechanism should help to
mitigate the effects of an such an attack.
</t>
</section>
<section title="Replay Attacks">
<t>
An attacker that has managed to obtain some messages from the
overload control mechanism may attempt to affect the behavior of
nodes supporting the mechanism by sending those messages at
potentially inopportune times. In addition to time shifting, replay
attacks may send messages to other nodes as well (target shifting).
</t>
<t>
A design goal for the Diameter overload control solution is to
minimize or eliminate the possibility of causing disruption by using
a replay attack on the Diameter overload control mechanism. (Allowing
a replay attack using the overload control solution would violate REQ
27.)
</t>
</section>
<section title="Man-in-the-Middle Attacks">
<t>
By inserting themselves in between two nodes supporting the Diameter
overload control mechanism, an attacker may potentially both access
and alter the information sent between those nodes. This can be used
for information gathering for business intelligence and attack
targeting, as well as direct attacks.
</t>
<t>
REQs 27, 28, and 29 imply a need to prevent man-in-the-middle attacks
on the overload control solution. A transport using TLS and/or IPSEC
may be desirable for this purpose.
</t>
</section>
<section title="Compromised Hosts">
<t>
A compromised host that supports the Diameter overload control
mechanism could be used for information gathering as well as for
sending malicious information to any Diameter node that would
normally accept information from it. While is is beyond the scope of
the Diameter overload control mechanism to mitigate any operational
interruption to the compromised host, REQs 28 and 29 imply a need to
minimize the impact that a compromised host can have on other nodes
through the use of the Diameter overload control mechanism. Of
course, a compromised host could be used to cause damage in a number
of other ways. This is out of scope for a Diameter overload control
mechanism.
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc6733;
&rfc2914;
&rfc3539;
</references>
<references title="Informative References">
&rfc5390;
&rfc6357;
<reference anchor="TR23.843">
<front>
<title>Study on Core Network Overload Solutions (Work in Progress)</title>
<author >
<organization abbrev="3GPP">
3GPP
</organization>
</author>
<date month="October" year="2012" />
</front>
<seriesInfo name="TR" value="23.843 0.6.0" />
</reference>
<reference anchor="IR.34">
<front>
<title>Inter-Service Provider IP Backbone Guidelines</title>
<author >
<organization abbrev="GSMA">
GSMA
</organization>
</author>
<date month="January" year="2012" />
</front>
<seriesInfo name="IR" value="34 7.0" />
</reference>
<reference anchor="IR.88">
<front>
<title>LTE Roaming Guidelines</title>
<author >
<organization abbrev="GSMA">
GSMA
</organization>
</author>
<date month="January" year="2012" />
</front>
<seriesInfo name="IR" value="88 7.0" />
</reference>
<reference anchor="IR.92">
<front>
<title>IMS Profile for Voice and SMS</title>
<author >
<organization abbrev="GSMA">
GSMA
</organization>
</author>
<date month="March" year="2013" />
</front>
<seriesInfo name="IR" value="92 7.0" />
</reference>
<reference anchor="TS23.002">
<front>
<title>Network Architecture</title>
<author>
<organization abbrev="3GPP">
3GPP
</organization>
</author>
<date month="September" year="2012" />
</front>
<seriesInfo name="TS" value="23.002 12.0.0" />
</reference>
<reference anchor="TS29.272">
<front>
<title>Evolved Packet System (EPS);
Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol</title>
<author >
<organization abbrev="3GPP">
3GPP
</organization>
</author>
<date month="September" year="2012" />
</front>
<seriesInfo name="TS" value="29.272 11.4.0" />
</reference>
<reference anchor="TS29.212">
<front>
<title>Policy and Charging Control (PCC) over Gx/Sd reference point</title>
<author >
<organization abbrev="3GPP">
3GPP
</organization>
</author>
<date month="September" year="2012" />
</front>
<seriesInfo name="TS" value="29.212 11.6.0" />
</reference>
<reference anchor="TS29.228">
<front>
<title>IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents</title>
<author >
<organization abbrev="3GPP">
3GPP
</organization>
</author>
<date month="September" year="2012" />
</front>
<seriesInfo name="TS" value="29.228 11.5.0" />
</reference>
<reference anchor="TS29.002">
<front>
<title>Mobile Application Part (MAP) specification</title>
<author >
<organization abbrev="3GPP">
3GPP
</organization>
</author>
<date month="September" year="2012" />
</front>
<seriesInfo name="TS" value="29.002 11.4.0" />
</reference>
</references>
<section title="Contributors">
<t>
Significant contributions to this document were made by Adam Roach and
Eric Noel.
</t>
</section>
<section title="Acknowledgements">
<t>
Review of, and contributions to, this specification by Martin Dolly,
Carolyn Johnson, Jianrong Wang, Imtiaz Shaikh, Jouni Korhonen, Robert
Sparks, Dieter Jacobsohn, Janet Gunn, Jean-Jacques Trottin, Laurent
Thiebaut, Andrew Booth, and Lionel Morand were most appreciated. We
would like to thank them for their time and expertise.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 16:07:56 |