draft-ietf-dime-overload-reqs-03.txt   draft-ietf-dime-overload-reqs-04.txt 
Network Working Group E. McMurry Network Working Group E. McMurry
Internet-Draft B. Campbell Internet-Draft B. Campbell
Intended status: Standards Track Tekelec Intended status: Standards Track Tekelec
Expires: July 19, 2013 January 15, 2013 Expires: August 26, 2013 February 22, 2013
Diameter Overload Control Requirements Diameter Overload Control Requirements
draft-ietf-dime-overload-reqs-03 draft-ietf-dime-overload-reqs-04
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 3 are not sufficient for this Diameter mechanisms, listed in Section 3 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 1, line 38 skipping to change at page 1, line 38
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 July 19, 2013. This Internet-Draft will expire on August 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 30 skipping to change at page 2, line 30
2.3. Interconnect Scenario . . . . . . . . . . . . . . . . . . 12 2.3. Interconnect Scenario . . . . . . . . . . . . . . . . . . 12
3. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 13 3. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 13
4. Issues with the Current Mechanisms . . . . . . . . . . . . . . 14 4. Issues with the Current Mechanisms . . . . . . . . . . . . . . 14
4.1. Problems with Implicit Mechanism . . . . . . . . . . . . . 15 4.1. Problems with Implicit Mechanism . . . . . . . . . . . . . 15
4.2. Problems with Explicit Mechanisms . . . . . . . . . . . . 15 4.2. Problems with Explicit Mechanisms . . . . . . . . . . . . 15
5. Diameter Overload Case Studies . . . . . . . . . . . . . . . . 16 5. Diameter Overload Case Studies . . . . . . . . . . . . . . . . 16
5.1. Overload in Mobile Data Networks . . . . . . . . . . . . . 16 5.1. Overload in Mobile Data Networks . . . . . . . . . . . . . 16
5.2. 3GPP Study on Core Network Overload . . . . . . . . . . . 17 5.2. 3GPP Study on Core Network Overload . . . . . . . . . . . 17
6. Extensibility and Application Independence . . . . . . . . . . 18 6. Extensibility and Application Independence . . . . . . . . . . 18
7. Solution Requirements . . . . . . . . . . . . . . . . . . . . 19 7. Solution Requirements . . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 24 9.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 24
9.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 25 9.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 24
9.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 25 9.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 25
9.5. Compromised Hosts . . . . . . . . . . . . . . . . . . . . 25 9.5. Compromised Hosts . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 26
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
When a Diameter [RFC6733] server or agent becomes overloaded, it When a Diameter [RFC6733] server or agent becomes overloaded, it
needs to be able to gracefully reduce its load, typically by needs to be able to gracefully reduce its load, typically by
informing clients to reduce sending traffic for some period of time. informing clients to reduce sending traffic for some period of time.
Otherwise, it must continue to expend resources parsing and Otherwise, it must continue to expend resources parsing and
responding to Diameter messages, possibly resulting in congestion responding to Diameter messages, possibly resulting in congestion
collapse. The existing mechanisms provided by Diameter are not collapse. The existing mechanisms provided by Diameter are not
sufficient for this purpose. This document describes the limitations sufficient for this purpose. This document describes the limitations
of the existing mechanisms, and provides requirements for new of the existing mechanisms, and provides requirements for new
overload management mechanisms. overload management mechanisms.
This document draws on the work done on SIP overload control This document draws on the work done on SIP overload control
([RFC5390], [RFC6357]) as well as on experience gained via overload ([RFC5390], [RFC6357]) as well as on experience gained via overload
handling in Signaling System No. 7 (SS7) networks and studies done by handling in Signaling System No. 7 (SS7) networks and studies done by
the Third Generation Partnersip Project (3GPP) (Section 5). the Third Generation Partnership Project (3GPP) (Section 5).
Diameter is not typically an end-user protocol; rather it is Diameter is not typically an end-user protocol; rather it is
generally used as one component in support of some end-user activity. generally used as one component in support of some end-user activity.
For example, a SIP server might use Diameter to authenticate and For example, a SIP server might use Diameter to authenticate and
authorize user access. Overload in the Diameter backend authorize user access. Overload in the Diameter backend
infrastructure will likely impact the experience observed by the end infrastructure will likely impact the experience observed by the end
user in the SIP application. user in the SIP application.
The impact of Diameter overload on the client application (a client The impact of Diameter overload on the client application (a client
skipping to change at page 9, line 5 skipping to change at page 9, line 5
server 1, but should not divert any application B requests. This server 1, but should not divert any application B requests. This
requires server 2 to be able to distinguish between applications when requires server 2 to be able to distinguish between applications when
it indicates an overload condition to the client. it indicates an overload condition to the client.
On the other hand, it's possible that the servers host many On the other hand, it's possible that the servers host many
applications. If server 2 becomes overloaded for all applications, applications. If server 2 becomes overloaded for all applications,
it would be undesirable for it to have to notify the client it would be undesirable for it to have to notify the client
separately for each application. Therefore it also needs a way to separately for each application. Therefore it also needs a way to
indicate that it is overloaded for all possible applications. indicate that it is overloaded for all possible applications.
+----------------------------------------------+ +---------------------------------------------+
| Application A +------------------------+----------------------+ | Application A +----------------------+----------------------+
|+------------------+ | +------------------+ | +------------------+| |+------------------+ | +----------------+ | +------------------+|
|| | | | | | | || || | | | | | | ||
|| | | | | | | || || | | | | | | ||
|| Server 1 | | | Server 2 | | | Server 3 || || Server 1 | | | Server 2 | | | Server 3 ||
|| | | | | | | || || | | | | | | ||
|+--------+---------+ | +--------+---------+ | +-+----------------+| |+--------+---------+ | +-------+--------+ | +-+----------------+|
| | | | | | | | | | | | | |
+---------+-----------+-----------+------------+ | | +---------+-----------+----------+-----------+ | |
| | | | | | | | | |
| | | | Application B | | | | | Application B |
| +-----------+-----------------+-----------------+ | +----------+----------------+-----------------+
``-.._ | | ``-.._ | |
`-..__ | _.-'' `-..__ | _.-''
`--._ | _.-'' `--._ | _.-''
``-.__ | _.-'' ``-._ | _.-''
+------`-.-''------+ +-----`-.-''-----+
| | | |
| | | |
| Client | | Client |
| | | |
+------------------+ +----------------+
Figure 3: Multiple Application Peer to Peer Scenario Figure 3: Multiple Application Peer to Peer Scenario
2.2. Agent Scenarios 2.2. Agent Scenarios
This section describes scenarios that include a Diameter agent, This section describes scenarios that include a Diameter agent,
either in the form of a Diameter relay or Diameter proxy. These either in the form of a Diameter relay or Diameter proxy. These
scenarios do not consider Diameter redirect agents, since they are scenarios do not consider Diameter redirect agents, since they are
more readily modeled as end-servers. more readily modeled as end-servers.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
Figure 5: Multiple Server Agent Scenario Figure 5: Multiple Server Agent Scenario
Figure 6 shows a scenario where an agent routes requests to a set of Figure 6 shows a scenario where an agent routes requests to a set of
servers for more than one Diameter realm and application. In this servers for more than one Diameter realm and application. In this
scenario, if server 1 becomes overloaded or unavailable, the agent scenario, if server 1 becomes overloaded or unavailable, the agent
may effectively operate at reduced capacity for application A, but at may effectively operate at reduced capacity for application A, but at
full capacity for application B. Therefore, the agent needs to be full capacity for application B. Therefore, the agent needs to be
able to report that it is overloaded for one application, but not for able to report that it is overloaded for one application, but not for
another. another.
+----------------------------------------------+ +--------------------------------------------+
| Application A +------------------------+----------------------+ | Application A +----------------------+----------------------+
|+------------------+ | +------------------+ | +------------------+| |+------------------+ | +----------------+ | +------------------+|
|| | | | | | | || || | | | | | | ||
|| | | | | | | || || | | | | | | ||
|| Server 1 | | | Server 2 | | | Server 3 || || Server 1 | | | Server 2 | | | Server 3 ||
|| | | | | | | || || | | | | | | ||
|+---------+--------+ | +--------+---------+ | +--+---------------+| |+---------+--------+ | +-------+--------+ | +--+---------------+|
| | | | | | | | | | | | | |
+----------+----------+-----------+------------+ | | +----------+----------+----------+-----------+ | |
| | | | | | | | | |
| | | | Application B | | | | | Application B |
| +-----------+------------------+----------------+ | +----------+-----------------+----------------+
| | | | | |
``--.__ | _. ``--.__ | _.
``-.__ | __.--'' ``-.__ | __.--''
`--.._ | _..--' `--.._ | _..--'
+-----``-+.-''-----+ +----``-+.''-----+
| | | |
| | | |
| Agent | | Agent |
| | | |
+--------+---------+ +-------+--------+
| |
| |
+--------+---------+ +-------+--------+
| | | |
| | | |
| Client | | Client |
| | | |
+------------------+ +----------------+
Figure 6: Multiple Application Agent Scenario Figure 6: Multiple Application Agent Scenario
2.3. Interconnect Scenario 2.3. Interconnect Scenario
Another scenario to consider when looking at Diameter overload is Another scenario to consider when looking at Diameter overload is
that of multiple network operators using Diameter components that of multiple network operators using Diameter components
connected through an interconnect service, e.g. using IPX. IPX (IP connected through an interconnect service, e.g. using IPX. IPX (IP
eXchange) [IR.34] is an Inter-Operator IP Backbone that provides eXchange) [IR.34] is an Inter-Operator IP Backbone that provides
roaming interconnection network between mobile operators and service roaming interconnection network between mobile operators and service
providers. The IPX is also used to transport Diameter signaling providers. The IPX is also used to transport Diameter signaling
between operators [IR.88]. Figure 7 shows two network operators with between operators [IR.88]. Figure 7 shows two network operators with
an interconnect network in-between. There could be any number of an interconnect network in-between. There could be any number of
these networks between any two network operator's networks. these networks between any two network operator's networks.
+-------------------------------------------+ +-------------------------------------------+
| Interconnect | | Interconnect |
| | | |
| +--------------+ +--------------+ | | +--------------+ +--------------+ |
| | Server 3 |------| Server 4 | | | | Server 3 |------| Server 4 | |
| +--------------+ +--------------+ | | +--------------+ +--------------+ |
| .' `. | | .' `. |
+------.-'--------------------------`.------+ +------.-'--------------------------`.------+
.' `. .' `.
.-' `. .-' `.
------------.'-----+ +----`.--------------- ------------.'-----+ +----`.-------------
+----------+ | | +----------+ +----------+ | | +----------+
| Server 1 | | | | Server 2 | | Server 1 | | | | Server 2 |
+----------+ | | +----------+ +----------+ | | +----------+
| | | |
Network Operator 1 | | Network Operator 2 Network Operator 1 | | Network Operator 2
-------------------+ +--------------------- -------------------+ +-------------------
Figure 7: Two Network Interconnect Scenario Figure 7: Two Network Interconnect Scenario
The characteristics of the information that an operator would want to The characteristics of the information that an operator would want to
share over such a connection are different from the information share over such a connection are different from the information
shared between components within a network operator's network. shared between components within a network operator's network.
Network operators may not want to convey topology or operational Network operators may not want to convey topology or operational
information, which limits how much overload and loading information information, which limits how much overload and loading information
can be sent. For the interconnect scenario shown, Server 2 may want can be sent. For the interconnect scenario shown, Server 2 may want
to signal overload to Server 1, to affect traffic coming from Network to signal overload to Server 1, to affect traffic coming from Network
skipping to change at page 19, line 44 skipping to change at page 19, line 44
discovery or manual configuration. The mechanism MUST work discovery or manual configuration. The mechanism MUST work
consistently without regard to how peers are determined. consistently without regard to how peers are determined.
REQ 6: The mechanism designers SHOULD seek to minimize the amount REQ 6: The mechanism designers SHOULD seek to minimize the amount
of new configuration required in order to work. For of new configuration required in order to work. For
example, it is better to allow peers to advertise or example, it is better to allow peers to advertise or
negotiate support for the mechanism, rather than to require negotiate support for the mechanism, rather than to require
this knowledge to be configured at each node. this knowledge to be configured at each node.
REQ 7: The overload control mechanism and any associated default REQ 7: The overload control mechanism and any associated default
algorithm(s) MUST ensure that the system remains stable. algorithm(s) MUST ensure that the system remains stable. At
When the offered load drops from above the overall capacity some point after an overload condition has ended, the
of the network to below the overall capacity, the throughput mechanism MUST enable capacity to stabilize and become equal
MUST stabilize and become equal to the offered load. Note to what it would be in the absence of an overload condition.
that this also requires that the mechanism MUST allow nodes Note that this also requires that the mechanism MUST allow
to shed load without introducing oscillations. nodes to shed load without introducing oscillations during
or after an overload condition.
REQ 8: Supporting nodes MUST be able to distinguish current REQ 8: Supporting nodes MUST be able to distinguish current
overload information from stale information, and SHOULD make overload information from stale information, and SHOULD make
decisions using the most currently available information. decisions using the most currently available information.
REQ 9: The mechanism MUST function across fully loaded as well as REQ 9: The mechanism MUST function across fully loaded as well as
quiescent transport connections. This is partially derived quiescent transport connections. This is partially derived
from the requirements for stability and hysteresis control from the requirement for stability in REQ 7.
above.
REQ 10: Consumers of overload state indications MUST be able to REQ 10: Consumers of overload information MUST be able to determine
determine when the overload condition improves or ends. when the overload condition improves or ends.
REQ 11: The overload control mechanism MUST be able to operate in REQ 11: The overload control mechanism MUST be able to operate in
networks of different sizes. networks of different sizes.
REQ 12: When a single network node fails, goes into overload, or REQ 12: When a single network node fails, goes into overload, or
suffers from reduced processing capacity, the mechanism MUST suffers from reduced processing capacity, the mechanism MUST
make it possible to limit the impact of this on other nodes make it possible to limit the impact of this on other nodes
in the network. This helps to prevent a small-scale failure in the network. This helps to prevent a small-scale failure
from becoming a widespread outage. from becoming a widespread outage.
skipping to change at page 20, line 46 skipping to change at page 20, line 45
increase of traffic with little time between normal levels increase of traffic with little time between normal levels
and overload inducing levels. The mechanism SHOULD provide and overload inducing levels. The mechanism SHOULD provide
for rapid feedback when traffic levels increase. for rapid feedback when traffic levels increase.
REQ 15: The mechanism MUST NOT interfere with the congestion control REQ 15: The mechanism MUST NOT interfere with the congestion control
mechanisms of underlying transport protocols. For example, mechanisms of underlying transport protocols. For example,
a mechanism that opened additional TCP connections when the a mechanism that opened additional TCP connections when the
network is congested would reduce the effectiveness of the network is congested would reduce the effectiveness of the
underlying congestion control mechanisms. underlying congestion control mechanisms.
REQ 16: The mechanism MUST operate without malfunction in an REQ 16: The overload control mechanism is likely to be deployed
environment with a mix of nodes that do, and nodes that do incrementally. The mechanism MUST support a mixed
not, support the mechanism. environment where some, but not all, nodes implement it.
REQ 17: In a mixed environment with nodes that support the overload REQ 17: In a mixed environment with nodes that support the overload
control mechanism and that do not, the mechanism MUST result control mechanism and that do not, the mechanism MUST result
in at least as much useful throughput as would have resulted in at least as much useful throughput as would have resulted
if the mechanism were not present. It SHOULD result in less if the mechanism were not present. It SHOULD result in less
severe congestion in this environment. severe congestion in this environment.
REQ 18: In a mixed environment of nodes that support the overload REQ 18: In a mixed environment of nodes that support the overload
control mechanism and that do not, the mechanism MUST NOT control mechanism and that do not, the mechanism MUST NOT
preclude elements that support overload control from preclude elements that support overload control from
skipping to change at page 21, line 32 skipping to change at page 21, line 32
different realms and in different administrative domains. different realms and in different administrative domains.
REQ 20: Any explicit overload indication MUST distinguish between REQ 20: Any explicit overload indication MUST distinguish between
actual overload, as opposed to other, non-overload related actual overload, as opposed to other, non-overload related
failures. failures.
REQ 21: In cases where a network node fails, is so overloaded that REQ 21: In cases where a network node fails, is so overloaded that
it cannot process messages, or cannot communicate due to a it cannot process messages, or cannot communicate due to a
network failure, it may not be able to provide explicit network failure, it may not be able to provide explicit
indications of the nature of the failure or its levels of indications of the nature of the failure or its levels of
congestion. The mechanism MUST properly function in these congestion. The mechanism MUST result in at least as much
cases. useful throughput as would have resulted if the overload
control mechanism was not in place.
REQ 22: The mechanism MUST provide a way for an node to throttle the REQ 22: The mechanism MUST provide a way for an node to throttle the
amount of traffic it receives from an peer node. This amount of traffic it receives from an peer node. This
throttling SHOULD be graded so that it can be applied throttling SHOULD be graded so that it can be applied
gradually as offered load increases. Overload is not a gradually as offered load increases. Overload is not a
binary state; there may be degrees of overload. binary state; there may be degrees of overload.
REQ 23: The mechanism MUST enable a supporting node to minimize the REQ 23: REMOVED
chance that retries due to an overloaded or failed node
result in additional traffic to other overloaded nodes, or
cause additional nodes to become overloaded. Moreover, the
mechanism SHOULD provide unambiguous directions to clients
on when they should retry a request and when they should not
considering the various causes of overload such as avalanche
restart.
REQ 24: The mechanism MUST provide sufficient information to enable REQ 24: The mechanism MUST provide sufficient information to enable
a load balancing node to divert messages that are rejected a load balancing node to divert messages that are rejected
or otherwise throttled by an overloaded upstream node to or otherwise throttled by an overloaded upstream node to
other upstream nodes that are the most likely to have other upstream nodes that are the most likely to have
sufficient capacity to process them. sufficient capacity to process them.
REQ 25: The mechanism MUST provide a mechanism for indicating load REQ 25: The mechanism MUST provide a mechanism for indicating load
levels even when not in an overloaded condition, to assist levels even when not in an overloaded condition, to assist
nodes making decisions to prevent overload conditions from nodes making decisions to prevent overload conditions from
occurring. occurring.
REQ 26: The base specification for the overload control mechanism REQ 26: The base specification for the overload control mechanism
SHOULD offer general guidance on which message types might SHOULD offer general guidance on which message types might
be desirable to send or process over others during times of be desirable to send or process over others during times of
overload, based on application-specific considerations. For overload, based on application-specific considerations. For
example, it may be more beneficial to process messages for example, it may be more beneficial to process messages for
existing sessions ahead of new sessions, or to give priority existing sessions ahead of new sessions. Some networks may
to requests associated with emergency sessions or with high have a requirement to give priority to requests associated
priority users. Any normative or otherwise detailed with emergency sessions. Any normative or otherwise
definition of the relative priorities of message types detailed definition of the relative priorities of message
during an overload condition will be the responsibility of types during an overload condition will be the
the application specification. responsibility of the application specification.
REQ 27: The mechanism MUST NOT prevent a node from prioritizing REQ 27: The mechanism MUST NOT prevent a node from prioritizing
requests based on any local policy, so that certain requests requests based on any local policy, so that certain requests
are given preferential treatment, given additional are given preferential treatment, given additional
retransmission, not throttled, or processed ahead of others. retransmission, not throttled, or processed ahead of others.
REQ 28: The overload control mechanism MUST NOT provide new REQ 28: The overload control mechanism MUST NOT provide new
vulnerabilities to malicious attack, or increase the vulnerabilities to malicious attack, or increase the
severity of any existing vulnerabilities. This includes severity of any existing vulnerabilities. This includes
vulnerabilities to DoS and DDoS attacks as well as replay vulnerabilities to DoS and DDoS attacks as well as replay
and man-in-the middle attacks. Note that the Diameter base and man-in-the middle attacks. Note that the Diameter base
specification [RFC6733] lacks end to end security and this specification [RFC6733] lacks end to end security and this
must be considered. must be considered.
REQ 29: The mechanism MUST provide a means to match an overload REQ 29: REMOVED
indication with the node that originated it. In particular,
the mechanism MUST allow a node to distinguish between
overload at a next-hop peer from overload at a node upstream
of the peer. For example, in Figure 5, the client must not
mistake overload at server 1 for overload at the agent,
whether or not the agent supports the mechanism.( see REQ
4).
REQ 30: The mechanism MUST NOT depend on being deployed in REQ 30: The mechanism MUST NOT depend on being deployed in
environments where all Diameter nodes are completely environments where all Diameter nodes are completely
trusted. It SHOULD operate as effectively as possible in trusted. It SHOULD operate as effectively as possible in
environments where other nodes are malicious; this includes environments where other nodes are malicious; this includes
preventing malicious nodes from obtaining more than a fair preventing malicious nodes from obtaining more than a fair
share of service. Note that this does not imply any share of service. Note that this does not imply any
responsibility on the mechanism to detect, or take responsibility on the mechanism to detect, or take
countermeasures against, malicious nodes. countermeasures against, malicious nodes.
skipping to change at page 23, line 36 skipping to change at page 23, line 19
attacks. attacks.
REQ 33: There are multiple situations where a Diameter node may be REQ 33: There are multiple situations where a Diameter node may be
overloaded for some purposes but not others. For example, overloaded for some purposes but not others. For example,
this can happen to an agent or server that supports multiple this can happen to an agent or server that supports multiple
applications, or when a server depends on multiple external applications, or when a server depends on multiple external
resources, some of which may become overloaded while others resources, some of which may become overloaded while others
are fully available. The mechanism MUST allow Diameter are fully available. The mechanism MUST allow Diameter
nodes to indicate overload with sufficient granularity to nodes to indicate overload with sufficient granularity to
allow clients to take action based on the overloaded allow clients to take action based on the overloaded
resources without forcing available capacity to go unused. resources without unreasonably forcing available capacity to
The mechanism MUST support specification of overload go unused. The mechanism MUST support specification of
information with granularities of at least "Diameter node", overload information with granularities of at least
"realm", "Diameter application", and "Diameter session", and "Diameter node", "realm", and "Diameter application", and
SHOULD allow extensibility for others to be added in the MUST allow extensibility for others to be added in the
future. future.
REQ 34: The mechanism MUST provide a method for extending the REQ 34: The mechanism MUST provide a method for extending the
information communicated and the algorithms used for information communicated and the algorithms used for
overload control. overload control.
REQ 35: The mechanism SHOULD provide a method for exchanging REQ 35: The mechanism SHOULD provide a method for exchanging
overload and load information between elements that are overload and load information between elements that are
connected by intermediaries that do not support the connected by intermediaries that do not support the
mechanism. mechanism.
REQ 36: The mechanism MUST provide a default algorithm that is
mandatory to implement.
8. IANA Considerations 8. IANA Considerations
This document makes no requests of IANA. This document makes no requests of IANA.
9. Security Considerations 9. Security Considerations
A Diameter overload control mechanism is primarily concerned with the A Diameter overload control mechanism is primarily concerned with the
load and overload related behavior of nodes in a Diameter network, load and overload related behavior of nodes in a Diameter network,
and the information used to affect that behavior. Load and overload and the information used to affect that behavior. Load and overload
skipping to change at page 27, line 24 skipping to change at page 27, line 11
Appendix A. Contributors Appendix A. Contributors
Significant contributions to this document were made by Adam Roach Significant contributions to this document were made by Adam Roach
and Eric Noel. and Eric Noel.
Appendix B. Acknowledgements Appendix B. Acknowledgements
Review of, and contributions to, this specification by Martin Dolly, Review of, and contributions to, this specification by Martin Dolly,
Carolyn Johnson, Jianrong Wang, Imtiaz Shaikh, Jouni Korhonen, Robert Carolyn Johnson, Jianrong Wang, Imtiaz Shaikh, Jouni Korhonen, Robert
Sparks, Dieter Jacobsohn, Janet Gunn, Jean-Jacques Trottin, Laurent Sparks, Dieter Jacobsohn, Janet Gunn, Jean-Jacques Trottin, Laurent
Thiebaut, and Lionel Morand were most appreciated. We would like to Thiebaut, Andrew Booth, and Lionel Morand were most appreciated. We
thank them for their time and expertise. would like to thank them for their time and expertise.
Authors' Addresses Authors' Addresses
Eric McMurry Eric McMurry
Tekelec Tekelec
17210 Campbell Rd. 17210 Campbell Rd.
Suite 250 Suite 250
Dallas, TX 75252 Dallas, TX 75252
US US
 End of changes. 22 change blocks. 
125 lines changed or deleted 114 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/