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]