Network Working Group T. Asveren
Internet-Draft Ulticom Inc.
Intended status: Informational V. Fajardo
Expires: April 28, 2007 October 25, 2006
Diameter Congestion Signaling
draft-asveren-dime-cong-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 28, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Diameter base protocol defines the network layer functionality to be
used by applications. This document adds hop-to-hop congestion
notification mechanism to that functionality.
Asveren & Fajardo Expires April 28, 2007 [Page 1]
Internet-Draft Diameter Congestion Signaling October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Congestion of Intermediaries . . . . . . . . . . . . . . . 4
3.2. Multiple Applications On the Same Node . . . . . . . . . . 4
3.3. Congestion Detection Time . . . . . . . . . . . . . . . . . 4
3.4. Notification of Congestion Abatement . . . . . . . . . . . 5
3.5. Multiple Congestion Levels . . . . . . . . . . . . . . . . 5
4. Hop-To-Hop Congestion Notification Mechanism . . . . . . . . . 5
4.1. Congestion Signaling Procedures . . . . . . . . . . . . . . 5
4.2. Congestion Message . . . . . . . . . . . . . . . . . . . . 6
4.3. Congestion-Level AVP . . . . . . . . . . . . . . . . . . . 7
4.4. DIAMETER_CONGESTED Result Code . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Asveren & Fajardo Expires April 28, 2007 [Page 2]
Internet-Draft Diameter Congestion Signaling October 2006
1. Introduction
Diameter base protocol defines the network layer functionality to be
used by applications. Requests are routed based on Destination-Host
AVP, Destination-Realm AVP, Application-Id values and the status of
Diameter connections to neighboring peers.
This document defines a new message to be used by peers to notify
their neighbors about its congestion status, so that this information
can be used while routing requests. The signaling defined in this
document describes a common method of congestion state notification
among peers. It is left up to the implementation on how to comply
with the suggested actions defined by each congestion level if it is
capable of doing so.
2. Terminology
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 described in [2].
The following terms defines the functionality used in describing
entities in this document.
Congestion level
A numeric value used to quantify the general capacity of a
diameter node to process request and/or answers. This value is
generalized in this document and not meant to be an exhaustive
indicator of all possible variables that can define congestion.
The possible numeric values for congestion level is defined in
Section 4.3.
Congestion state
Congestion state pertains to the congestion level and other
relevant information that a diameter node keeps about each of its
neighboring peers.
3. Motivation
When routing Diameter messages, it is preferable to consider the
congestion status of peers to increase the response time of answers
and to prevent overloading on nodes. A method of signaling the
congestion state of among adjacent peers independent of any
applications will allow for a more real-time, self correcting method
Asveren & Fajardo Expires April 28, 2007 [Page 3]
Internet-Draft Diameter Congestion Signaling October 2006
of reducing and or distributing load among diameter neighbors.
There are several scenarios where relying on an application level
result code is not efficient to notify peers about congestion status
changes. The succeeding sections provides applicability scenarios
for requiring per hop congestion status signaling.
3.1. Congestion of Intermediaries
In a Diameter network, intermediate nodes such as relay agents,
proxies, may be present. Such nodes may get congested and it is
desirable to consider their congestion status when selecting the next
hop node.
Intermediate nodes do not host the application logic to process a
request and do not generate answers except routing failures for the
requests they receive. Generating a result code of "TOO_BUSY_HERE"
to notify about intermediate congestion is not appropriate because it
indicates congestion of the server specified in the Destination-Host
AVP or in general the logical application service identified by
Destination-Realm AVP and Application-Id. It is therefore limited to
diameter application end-points and does not consider the congestion
state of intermediaries and other application traffic routed through
them.
3.2. Multiple Applications On the Same Node
A Diameter node may host multiple applications simultaneously.
Although it is possible to aggregate congestion status of the node on
application logic level, it may be preferable to do this on a
centralized logical entity like the Diameter base protocol in a
layered architecture. A hop-to-hop message generated and consumed by
base protocol layer would be more suitable for such a task split
between different layers.
3.3. Congestion Detection Time
Relying on congestion notification via application level result code
is inherently a reactive mechanism. This requires that an
application level request needs to be received for congestion
notification to be sent on the answer. This problem can be
aggravated in configurations such as diameter servers which are
communicating with multiple peers. A highly congested server can
only signal its congestion state to other peers only when those peers
send a request to the server.
Asveren & Fajardo Expires April 28, 2007 [Page 4]
Internet-Draft Diameter Congestion Signaling October 2006
3.4. Notification of Congestion Abatement
Currently, there is no existing method of signaling an end of
congestion. Peers may probe the congested node periodically with new
requests and can decide based on the result code of the corresponding
answer whether congestion has abated. However, such method is not
effective if peers have no application level request to send and
therefore suffers the same drawbacks as Section 3.3. A hop-to-hop
congestion indication message could provide notification of
congestion abatement immediately.
3.5. Multiple Congestion Levels
A congestion result code provides only a single congestion level of
"congested." For certain configurations it may be desirable to
provide multiple congestion levels.
4. Hop-To-Hop Congestion Notification Mechanism
4.1. Congestion Signaling Procedures
A diameter node sends a Congestion Message (CM) to its adjacent
neighbors to indicate its current congestion level. A node's
congestion level SHOULD fall into one of the congestion levels
defined in Section 4.3. A diameter node SHOULD send a CM to its
neighboring peers when it determines that its congestion level
changes. A peer receiving a CM SHOULD create and maintain congestion
state for the sender identified by the Origin-Host AVP in the initial
Capabilities-Exchange if it has not already done so. The congestion
state should at least contain the currently advertised congestion
state of the peer. Since the CM is intended to be a notification, it
does not require a corresponding response message.
The receiver of the CM should react accordingly to the congestion
level hints provided by the Congestion-Level AVP. It is left up to
the implementation on how a peer will react to adverse congestion
level changes such as going from CONGESTION_LEVEL_0 to
CONGESTION_LEVEL_2 or CONGESTION_LEVEL_3 (See Section 4.3).
Intermediaries such as relays and proxies can react by re-routing new
and pending request to alternate peers if they exists. Other well
know techniques on congestion control may also be employed such as
source throttling or per hop queuing, though these are out of scope
of this document. It is expected that Nodes MAY advertise congestion
levels non-sequentially, e.g. a node may first advertise
CONGESTION_LEVEL_1 and then CONGESTION_LEVEL_3. Therefore, any
congestion control scheme that a receiving node deploys MUST be able
to accommodate such changes.
Asveren & Fajardo Expires April 28, 2007 [Page 5]
Internet-Draft Diameter Congestion Signaling October 2006
For sender of the CM, it is also left up to the implementation on
determining the current congestion level of a diameter node. The
implementation may rely on the traffic rate, processing load, backend
call latency, storage/resource availability etc. or any such
combinations to determine the appropriate congestion level. Deciding
when congestion level changes on a node is also implementation
dependent but nodes SHOULD provide hysteresis between onset and
abatement values of the congestion levels. Note that schemes to
determine congestion level changes should not be very sensitive so as
not to trigger sending many CM message causing congestion control
flapping among neighboring peers. It is recommended that triggering
of onset and abatement levels should be deterministic. Also note
that, nodes MAY also choose to use only a subset of the defined
congestion level values, e.g. a node MAY use only CONGESTION_LEVEL_0
and CONGESTION_LEVEL_3 values to indicate a binary state of congested
or not congested.
In the case where a new peer attempts to connect to an existing node
supporting congestion control signaling, the Congestion-Level AVP
Section 4.3 may also be sent by the node in the CEA message to
immediately indicate to the new peer of the nodes congestion state.
This is in the case where the existing peer is already experiencing
high levels of congestion and would want to notify any new peer
immediately rather than sending a CM which has an inherent latency.
If sent with the CEA, the Congestion-Level AVP MUST be sent as an
optional AVP and can be easily ignored by diameter nodes that does
not support congestion control signaling.
In the case where an adjacent peer does not support congestion
control signaling, the sender of the congestion message Section 4.2
should expect to receive an error answer message specified in Section
7.2 of [1] with a result code DIAMETER_COMMAND_UNSUPPORTED. This
should be a hint to the node that the neighbor does not support
congestion control signaling and therefore it should not send any
subsequent CM.
When a node receives a request and the load on the node is above a
threshold, i.e. the node already sent a CM with CONGESTION_LEVEL_2,
the node MAY silently drop the request or MAY send back an error
answer with result code DIAMETER_CONGESTED.
4.2. Congestion Message
Congestion message (CM) is used by a node to notify neighboring peers
about a change in the congestion status of the node.
Asveren & Fajardo Expires April 28, 2007 [Page 6]
Internet-Draft Diameter Congestion Signaling October 2006
Congestion-Message ::= < Diameter Header: XYZ, REQ >
{ Congestion-Level }
* [ AVP ]
Figure 1: Congestion Message Definition
4.3. Congestion-Level AVP
Congestion-Level AVP is of type Enumerated and indicates the
congestion level of a node. The following values are defined for
Congestion-Level AVP:
CONGESTION_LEVEL_0 0
This value indicates that the load on the sender node is below the
manageable limit and the node are ready to handle new messages.
CONGESTION_LEVEL_1 1
This value indicates that the node can still handle messages but
if there is an alternative node, it SHOULD be preferred when
sending requests.
CONGESTION_LEVEL_2 2
This value indicates that no new requests SHOULD be sent to the
node. A node in this state MAY drop request messages. However,
answer messages still SHOULD be sent to the node.
CONGESTION_LEVEL_3 3
This value indicates that no new messages (neither requests nor
answers) SHOULD be sent to the node. A node in this state MAY
drop any received message.
4.4. DIAMETER_CONGESTED Result Code
This document defines a new result code of protocol error class:
DIAMETER_CONGESTED 3011 A request has been received and the
congestion state of the receiver node is not suitable to process
the request.
5. IANA Considerations
IANA is to assign new command codes for the Congestion Message
command defined in Section 4.2. In addition, IANA is to assign new
Asveren & Fajardo Expires April 28, 2007 [Page 7]
Internet-Draft Diameter Congestion Signaling October 2006
AVP codes for Congestion-Level AVP defined in Section 4.3.
6. Security Considerations
This document does not contain a security protocol; it describes
extensions to the existing Diameter protocol. All security issues of
DIAMETER protocol must be considered in implementing this
specification. This extension does not add any unique concerns.
7. Normative References
[1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Tolga Asveren
Ulticom Inc.
1020 Briggs Road
Mount Laurel, NJ, 08054
USA
Email: asveren@ulticom.com
Victor Fajardo
One Telcordia Drive
Piscataway, NJ 08854
USA
Email: vfajardo@tari.toshiba.com
Asveren & Fajardo Expires April 28, 2007 [Page 8]
Internet-Draft Diameter Congestion Signaling October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Asveren & Fajardo Expires April 28, 2007 [Page 9]