idnits 2.17.1 draft-partha-dispatch-siploadbalancing-survey-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 : ---------------------------------------------------------------------------- No issues found here. 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 (January 23, 2012) is 4469 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2648' is defined on line 212, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Dispatch Parthasarathi. Ravindran 2 Internet-Draft Sonus Networks, Inc. 3 Intended status: Informational Vijay . Gurbani 4 Expires: July 26, 2012 Bell Labs, Alcatel-Lucent 5 Paul. Erkkila 6 Globalcrossing 7 January 23, 2012 9 Session Initiation Protocol (SIP) Load balancing survey 10 draft-partha-dispatch-siploadbalancing-survey-00 12 Abstract 14 SIP Load balancing across a farm of SIP servers can be done today, 15 but without generally agreed upon principles on how to best do 16 accomplish this. Confounding the problem is that a SIP farm may 17 consist of hosts with varying capabilities, example, a SIP proxy, a 18 back-to-back user agent (B2BUA), a public-switched telephone system 19 (PSTN) gateway, SIP Media servers etc. The capabilities and 20 processing capacity on hosts in the farm may be different, sometimes 21 vastly, from each other. This document present the survey of 22 existing literature and common practice on SIP load balancing. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 26, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Survey of existing mechanism & literature . . . . . . . . . . . 3 61 3.1. Round robin . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.2. Round robin with 503 or 302 or other overload mechanism . . 3 63 3.3. Round robin with option ping . . . . . . . . . . . . . . . 3 64 3.4. DNS based . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.5. Resource availabilty based mechanism . . . . . . . . . . . 4 66 4. Standard open issues . . . . . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 69 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 5 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 Session Initiation protocol [RFC3261] Load balancing across a farm of 78 SIP servers can be done today, but without generally agreed upon 79 principles on how to best do accomplish this. Confounding the 80 problem is that a SIP farm may consist of hosts with varying 81 capabilities, example, a SIP proxy, a back-to-back user agent 82 (B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media 83 servers etc. The capabilities and processing capacity on hosts in 84 the farm may be different, sometimes vastly, from each other. 85 Furthermore, the duration of time that a SIP host requires to process 86 a SIP request may vary. SIP proxies, operating at the transaction 87 layer, may be more efficient at processing transactions than a B2BUA 88 would be, which may need to maintain a long-lived dialogue state in 89 addition to the transaction state. PSTN gateways may have other 90 limitations such as media resources that may be depleted even though 91 the gateway may have enough processing power (i.e., CPU) to handle 92 incoming requests. 94 The goal of this draft is to summarize the contemporary SIP load 95 balancing algorithm as input to the SIP load balancing protocol 96 designers. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. This 103 document only uses these key words when referencing normative 104 statements in existing RFCs." 106 3. Survey of existing mechanism & literature 108 3.1. Round robin 110 Round robin based on DNS is illustrated in [RFC1794]. The focus of 111 this mechanism is load distribution than load balancing. 113 3.2. Round robin with 503 or 302 or other overload mechanism 115 TBD 117 3.3. Round robin with option ping 119 The load balancing device sends OPTIONS ping message to each of its 120 downstream servers to determine if they are available.The return 121 value in the OPTIONS response and in some cases the delay between the 122 sending of the request and the response is tracked by the 123 loadbalancer. If the downstream server does not respond within a 124 certain time window it is marked as down and not used in the round 125 robin selection for the next request. If the OPTIONS ping does 126 respond the result code is often checked for a particular response. 127 For instance a 200 value response will not change the current state 128 of the downstream server while a response in the 5xx/6xx range or 129 specific 4xx values will remove the downstream device from service. 131 An alternate case of OPTIONS pings is to just use them to verify that 132 a SIP UAS of some kind exists at the destination, any SIP response is 133 considered a good response and marks the downstream device as valid. 135 OPTIONS pings are sent to downstream entities even if they are 136 currently marked as down or out of service on the loadbalancer. When 137 the device starts responding to the OPTIONS messages again it can 138 then be placed back into the round robin selection. 140 If the response to an OPTIONS request from a downstream host is 141 successfully returned but is outside of an acceptable range, the 142 loadbalancer can use this to indicate a problem with the downstream 143 device and either remove it from the round robin, or change its 144 portion of round robin traffic. 146 3.4. DNS based 148 Load Balancing based on Load Detection Function section in 3GPP TS 23 149 .812(http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/ 150 23812-115.zip) illustrates DNS based SIP load balancing 152 3.5. Resource availabilty based mechanism 154 The media server load balancing depends upon the resources apart from 155 CPU and Memory of the system. Resource availability mechanism in (ht 156 tp://tools.ietf.org/html/ 157 draft-partha-soc-overload-resource-availability-00) illustrate the 158 way to achieve SIP based load balancing for media servers like PSTN- 159 SIP GW, SBC. Resource availabilty draft provides the mechanism 160 wherein SIP server indicates its resource capability to the prior SIP 161 server by which prior SIP server will be able to perform load 162 balancing. 164 Explicit polling: some protocol (SNMP/SOAP+XML/SIP) is used to 165 actively probe the downstream server for their current resource 166 availability. The response to these polls are used to fill in the 167 availability and resource allocation percentage of the downstream 168 servers. continuous/streaming polling: a resource utilization report 169 is included in each response (or every Nth response) from the 170 downstream server through the load balancing device. In this way no 171 additional polling or protocol is needed to update resource 172 availability, it is kept up to date by constant use. This can easily 173 be combined with OPTIONS pings. note: -multiple resources can be 174 polled/used to figure out constraints. For 1 downstream server might 175 be out of a particular resource (such as transcoding resources), but 176 have ample capacity to provide other services ( for example relaying 177 MESSAGE requests). 179 4. Standard open issues 181 TBD 183 5. Security Considerations 185 This document is a survey of existing literature on SIP load 186 balancing. As such, it does not introduce any new security 187 considerations to be taken into account beyond what is already 188 discussed in each paper surveyed. 190 6. IANA Considerations 192 This is no IANA consideration applicable for this draft. 194 7. Acknowledgement 196 TBD 198 8. References 200 8.1. Normative References 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, March 1997. 205 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 206 A., Peterson, J., Sparks, R., Handley, M., and E. 207 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 208 June 2002. 210 8.2. Informative References 212 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 213 August 1999. 215 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 216 April 1995. 218 Authors' Addresses 220 Parthasarathi Ravindran 221 Sonus Networks, Inc. 222 Prestige Shantiniketan - Business Precinct 223 Whitefield Road 224 Bangalore, Karnataka 560066 225 India 227 Email: pravindran@sonusnet.com 229 Vijay .K Gurbani 230 Bell Labs, Alcatel-Lucent 231 Chicago 232 USA 234 Email: vkg@bell-labs.com 236 Paul Erkkila 237 Globalcrossing 238 Newyork 239 USA 241 Email: Paul.Erkkila@Globalcrossing.com