Network Working Group P. Jones Internet Draft G. Salgueiro Intended status: Standards Track Cisco Systems Expires: January 1, 2011 V. Pascual Acme Packet July 1, 2010 Transmission of a Session Capacity Estimate (SCE) to Prevent Session Initiation Protocol (SIP) Server Overload draft-jones-sip-overload-sce-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 1, 2011. Copyright Notice Copyright (c) 2010 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 document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Jones, et al. Expires January 1, 2011 [Page 1] Internet-Draft SCE to prevent SIP Server Overload July 2010 Abstract This memo describes a method of preventing overload of Session Initiation Protocol (SIP) servers through the calculation, conveyance, and usage of a value referred to as the Session Capacity Estimate (SCE), a value that summarily represents the capacity of a SIP server. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. Session Capacity Estimate......................................3 4. Computing the Session Capacity Estimate........................3 5. Conveyance of the Session Capacity Estimate....................4 6. Utilizing the Session Capacity Estimate........................4 7. Security Considerations........................................4 8. IANA Considerations............................................4 9. Acknowledgments................................................5 10. References....................................................5 10.1. Normative References.....................................5 Author's Addresses................................................5 1. Introduction Traditionally, reporting resource capacity has entailed reporting information related to discrete resources, such as available DS0s, free memory, or CPU utilization. The problem with this approach is that, more often than not, the only useful information is the number of available DS0s, as that equates to physical components in a system that are clearly a limited resource. Exhaustion of such tangible resources has definite meaning, unlike changes in the reported values of memory or CPU utilization. While there is clearly a point at which memory or CPU utilization will have an effect on the ability of a network element to process communication requests, it is impossible for other entities in the network to effectively use that information directly, since 90% CPU utilization, for example, does not necessarily mean that the device has more or less capacity than a device reporting 50% CPU utilization. Herewith, we introduce a different method for reporting capacity. This method is one that, at a high level, entails reporting an estimation of the number of additional communication sessions a device can accept. This value may be used by other SIP devices to facilitate the selection of a SIP server to which to direct traffic in an attempt to avoid overloading a server. Jones, et al. Expires January 1, 2011 [Page 2] Internet-Draft SCE to prevent SIP Server Overload July 2010 2. Conventions used in this document 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 RFC 2119 [2]. 3. Session Capacity Estimate Any element within a communication network has the ability to determine when it is nearing an overloaded state. That determination might be based on, as examples, CPU utilization, memory utilization, bandwidth, or a combination of all of these. Rather than reporting raw values for discrete elements of the system, a better method for reporting capacity and preventing system overload is to report an estimated value of the number of additional communication sessions a network element can accept. This calculation would be locally computed based on these discrete values and is most useful for network elements that do not have a fixed number of resources, such as SIP proxies or Session Border Controllers (SBCs). We refer to this calculation as the Session Capacity Estimate (SCE). 4. Computing the Session Capacity Estimate This Session Capacity Estimate (SCE) value might be computed using a variety of input variables, usually based on measurements of discrete resources. A SIP server may locally monitor memory utilization, CPU usage, and bandwidth, as examples, and use that data to arrive at an estimate for the number of additional sessions it can accept. A means of computing the Session Capacity Estimate (SCE) might be to observe how much of any given resource is consumed based on the resources already consumed for the currently active sessions. For example, assume each communication session consumes 5% of available resources, whatever those resources might be. In this case, the maximum number of sessions that could be supported would be 20. With each additional session, the SCE value would be reduced by one. Most of the time, however, a given session consumes more or less resources than another session and, as such, the SCE value is dynamic in nature. For example, an SBC that processes media may be able to processes fewer video sessions than voice sessions, perhaps due to bandwidth restrictions or perhaps DSP resources required to perform transcoding of media. As each new session is introduced in the system, a new SCE value can be computed that reflects the element's best guess as to how much capacity remains, taking into consideration measurable resources like memory, CPU, bandwidth, etc. Jones, et al. Expires January 1, 2011 [Page 3] Internet-Draft SCE to prevent SIP Server Overload July 2010 5. Conveyance of the Session Capacity Estimate The SCE value is conveyed through normal SIP signaling exchanges between devices. The SCE value reported by the SIP entity sending a response upstream is included in the Via header as a new parameter called "sce". For example, a SIP server might include a Via header like the following to indicate that it is capable of accepting an additional 275 sessions: Via: SIP/2.0/UDP 192.168.1.10:5060; branch=z9hG4bK776asdhds;sce=275 During periods when no other SIP exchanges take place between two servers, a SIP User Agent might send an OPTIONS "ping" message to a peer entity to determine the status of that peer as per draft-jones- sip-options-ping-02 [1]. The response to that OPTIONS message would include the SCE value in addition to other information that might be returned. 6. Utilizing the Session Capacity Estimate A SIP server or SIP User Agent attempting to identify a next hop to which it may direct a session can use the SCE information collected from its peers in order to select a next hop that has the highest likelihood of successfully accepting the sessions. To do this, it merely compares the SCE values reported by its peers. The actual selection might be based on the highest SCE value reported by peer elements. Alternatively, the server might use a round-robin approach to cycle through peer elements that report an SCE value at or above some minimum value or above the average value reported by peer entities. Whatever method is used is a matter for implementation. In any case, the objective is to identify a device that is least likely to return a 503 "Service Unavailable" status code, indicating the peer device has exceeded capacity limits. 7. Security Considerations TBD 8. IANA Considerations There are no IANA considerations associated with this document. Jones, et al. Expires January 1, 2011 [Page 4] Internet-Draft SCE to prevent SIP Server Overload July 2010 9. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. 10. References 10.1. Normative References [1] Jones, et al., "Using OPTIONS to Query for Operational Status in the Session Initiation Protocol (SIP)", draft-jones-sip- options-ping-02, July 2010. [2] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Addresses Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA Phone: +1 919 476 2048 Email: paulej@packetizer.com IM: xmpp:paulej@packetizer.com Victor Pascual Acme Packet, Inc. Anabel Segura 10, Madrid 28108 Spain Phone: +34 911 75 32 28 Email: vpascual@acmepacket.com IM: xmpp:victor.pascual.avila@gmail.com Jones, et al. Expires January 1, 2011 [Page 5] Internet-Draft SCE to prevent SIP Server Overload July 2010 Gonzalo Salgueiro Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA Phone: +1 919 392 3266 Email: gsalguei@cisco.com IM: xmpp:gsalguei@cisco.com Jones, et al. Expires January 1, 2011 [Page 6]