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]