Design Considerations for Session Initiation Protocol (SIP) Overload Control (RFC6357)
Publication Date: 2011-Dec-01
The IP.com Prior Art Database
V. Hilt: AUTHOR [+4]
AbstractAs with any network element, a Session Initiation Protocol (SIP) [RFC3261] server can suffer from overload when the number of SIP messages it receives exceeds the number of messages it can process. Overload occurs if a SIP server does not have sufficient resources to process all incoming SIP messages. These resources may include CPU, memory, input/output, or disk resources.
Internet Engineering Task Force (IETF) V. Hilt Request for Comments: 6357 Bell Labs/Alcatel-Lucent Category: Informational E. Noel ISSN: 2070-1721 AT&T Labs C. Shen Columbia University A. Abdelal Sonus Networks August 2011
Design Considerations for Session Initiation Protocol (SIP) Overload Control
Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6357.
Hilt Informational [Page 1]
RFC 6357 Overload Control Design August 2011
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this docu...