[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03                                                   
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]