idnits 2.17.00 (12 Aug 2021) /tmp/idnits8791/draft-jones-sip-overload-sce-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 1, 2010) is 4335 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 209, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Jones 3 Internet Draft G. Salgueiro 4 Intended status: Standards Track Cisco Systems 5 Expires: January 1, 2011 V. Pascual 6 Acme Packet 7 July 1, 2010 9 Transmission of a Session Capacity Estimate (SCE) to Prevent Session 10 Initiation Protocol (SIP) Server Overload 11 draft-jones-sip-overload-sce-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on January 1, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. 48 Abstract 50 This memo describes a method of preventing overload of Session 51 Initiation Protocol (SIP) servers through the calculation, 52 conveyance, and usage of a value referred to as the Session Capacity 53 Estimate (SCE), a value that summarily represents the capacity of a 54 SIP server. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Conventions used in this document..............................3 60 3. Session Capacity Estimate......................................3 61 4. Computing the Session Capacity Estimate........................3 62 5. Conveyance of the Session Capacity Estimate....................4 63 6. Utilizing the Session Capacity Estimate........................4 64 7. Security Considerations........................................4 65 8. IANA Considerations............................................4 66 9. Acknowledgments................................................5 67 10. References....................................................5 68 10.1. Normative References.....................................5 69 Author's Addresses................................................5 71 1. Introduction 73 Traditionally, reporting resource capacity has entailed reporting 74 information related to discrete resources, such as available DS0s, 75 free memory, or CPU utilization. The problem with this approach is 76 that, more often than not, the only useful information is the number 77 of available DS0s, as that equates to physical components in a 78 system that are clearly a limited resource. Exhaustion of such 79 tangible resources has definite meaning, unlike changes in the 80 reported values of memory or CPU utilization. While there is 81 clearly a point at which memory or CPU utilization will have an 82 effect on the ability of a network element to process communication 83 requests, it is impossible for other entities in the network to 84 effectively use that information directly, since 90% CPU 85 utilization, for example, does not necessarily mean that the device 86 has more or less capacity than a device reporting 50% CPU 87 utilization. 89 Herewith, we introduce a different method for reporting capacity. 90 This method is one that, at a high level, entails reporting an 91 estimation of the number of additional communication sessions a 92 device can accept. This value may be used by other SIP devices to 93 facilitate the selection of a SIP server to which to direct traffic 94 in an attempt to avoid overloading a server. 96 2. Conventions used in this document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [2]. 102 3. Session Capacity Estimate 104 Any element within a communication network has the ability to 105 determine when it is nearing an overloaded state. That 106 determination might be based on, as examples, CPU utilization, 107 memory utilization, bandwidth, or a combination of all of these. 109 Rather than reporting raw values for discrete elements of the 110 system, a better method for reporting capacity and preventing system 111 overload is to report an estimated value of the number of additional 112 communication sessions a network element can accept. This 113 calculation would be locally computed based on these discrete values 114 and is most useful for network elements that do not have a fixed 115 number of resources, such as SIP proxies or Session Border 116 Controllers (SBCs). We refer to this calculation as the Session 117 Capacity Estimate (SCE). 119 4. Computing the Session Capacity Estimate 121 This Session Capacity Estimate (SCE) value might be computed using a 122 variety of input variables, usually based on measurements of 123 discrete resources. A SIP server may locally monitor memory 124 utilization, CPU usage, and bandwidth, as examples, and use that 125 data to arrive at an estimate for the number of additional sessions 126 it can accept. 128 A means of computing the Session Capacity Estimate (SCE) might be to 129 observe how much of any given resource is consumed based on the 130 resources already consumed for the currently active sessions. For 131 example, assume each communication session consumes 5% of available 132 resources, whatever those resources might be. In this case, the 133 maximum number of sessions that could be supported would be 20. 134 With each additional session, the SCE value would be reduced by one. 136 Most of the time, however, a given session consumes more or less 137 resources than another session and, as such, the SCE value is 138 dynamic in nature. For example, an SBC that processes media may be 139 able to processes fewer video sessions than voice sessions, perhaps 140 due to bandwidth restrictions or perhaps DSP resources required to 141 perform transcoding of media. As each new session is introduced in 142 the system, a new SCE value can be computed that reflects the 143 element's best guess as to how much capacity remains, taking into 144 consideration measurable resources like memory, CPU, bandwidth, etc. 146 5. Conveyance of the Session Capacity Estimate 148 The SCE value is conveyed through normal SIP signaling exchanges 149 between devices. 151 The SCE value reported by the SIP entity sending a response upstream 152 is included in the Via header as a new parameter called "sce". For 153 example, a SIP server might include a Via header like the following 154 to indicate that it is capable of accepting an additional 275 155 sessions: 157 Via: SIP/2.0/UDP 192.168.1.10:5060; 158 branch=z9hG4bK776asdhds;sce=275 160 During periods when no other SIP exchanges take place between two 161 servers, a SIP User Agent might send an OPTIONS "ping" message to a 162 peer entity to determine the status of that peer as per draft-jones- 163 sip-options-ping-02 [1]. The response to that OPTIONS message would 164 include the SCE value in addition to other information that might be 165 returned. 167 6. Utilizing the Session Capacity Estimate 169 A SIP server or SIP User Agent attempting to identify a next hop to 170 which it may direct a session can use the SCE information collected 171 from its peers in order to select a next hop that has the highest 172 likelihood of successfully accepting the sessions. To do this, it 173 merely compares the SCE values reported by its peers. 175 The actual selection might be based on the highest SCE value 176 reported by peer elements. Alternatively, the server might use a 177 round-robin approach to cycle through peer elements that report an 178 SCE value at or above some minimum value or above the average value 179 reported by peer entities. 181 Whatever method is used is a matter for implementation. In any 182 case, the objective is to identify a device that is least likely to 183 return a 503 "Service Unavailable" status code, indicating the peer 184 device has exceeded capacity limits. 186 7. Security Considerations 188 TBD 190 8. IANA Considerations 192 There are no IANA considerations associated with this document. 194 9. Acknowledgments 196 This document was prepared using 2-Word-v2.0.template.dot. 198 10. References 200 10.1. Normative References 202 [1] Jones, et al., "Using OPTIONS to Query for Operational Status 203 in the Session Initiation Protocol (SIP)", draft-jones-sip- 204 options-ping-02, July 2010. 206 [2] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 207 3261, June 2002. 209 [3] Bradner, S., "Key words for use in RFCs to Indicate 210 Requirement Levels", BCP 14, RFC 2119, March 1997. 212 Author's Addresses 214 Paul E. Jones 215 Cisco Systems, Inc. 216 7025 Kit Creek Rd. 217 Research Triangle Park, NC 27709 218 USA 220 Phone: +1 919 476 2048 221 Email: paulej@packetizer.com 222 IM: xmpp:paulej@packetizer.com 224 Victor Pascual 225 Acme Packet, Inc. 226 Anabel Segura 10, Madrid 28108 227 Spain 229 Phone: +34 911 75 32 28 230 Email: vpascual@acmepacket.com 231 IM: xmpp:victor.pascual.avila@gmail.com 232 Gonzalo Salgueiro 233 Cisco Systems, Inc. 234 7025 Kit Creek Rd. 235 Research Triangle Park, NC 27709 236 USA 238 Phone: +1 919 392 3266 239 Email: gsalguei@cisco.com 240 IM: xmpp:gsalguei@cisco.com