Dispatch Parthasarathi. Ravindran Internet-Draft Sonus Networks, Inc. Intended status: Informational Vijay . Gurbani Expires: July 26, 2012 Bell Labs, Alcatel-Lucent Paul. Erkkila Globalcrossing January 23, 2012 Session Initiation Protocol (SIP) Load balancing survey draft-partha-dispatch-siploadbalancing-survey-00 Abstract SIP Load balancing across a farm of SIP servers can be done today, but without generally agreed upon principles on how to best do accomplish this. Confounding the problem is that a SIP farm may consist of hosts with varying capabilities, example, a SIP proxy, a back-to-back user agent (B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media servers etc. The capabilities and processing capacity on hosts in the farm may be different, sometimes vastly, from each other. This document present the survey of existing literature and common practice on SIP load balancing. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 26, 2012. Copyright Notice Copyright (c) 2012 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 Ravindran, et al. Expires July 26, 2012 [Page 1] Internet-Draft SIP Load balancing survey January 2012 (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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Survey of existing mechanism & literature . . . . . . . . . . . 3 3.1. Round robin . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Round robin with 503 or 302 or other overload mechanism . . 3 3.3. Round robin with option ping . . . . . . . . . . . . . . . 3 3.4. DNS based . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.5. Resource availabilty based mechanism . . . . . . . . . . . 4 4. Standard open issues . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Ravindran, et al. Expires July 26, 2012 [Page 2] Internet-Draft SIP Load balancing survey January 2012 1. Introduction Session Initiation protocol [RFC3261] Load balancing across a farm of SIP servers can be done today, but without generally agreed upon principles on how to best do accomplish this. Confounding the problem is that a SIP farm may consist of hosts with varying capabilities, example, a SIP proxy, a back-to-back user agent (B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media servers etc. The capabilities and processing capacity on hosts in the farm may be different, sometimes vastly, from each other. Furthermore, the duration of time that a SIP host requires to process a SIP request may vary. SIP proxies, operating at the transaction layer, may be more efficient at processing transactions than a B2BUA would be, which may need to maintain a long-lived dialogue state in addition to the transaction state. PSTN gateways may have other limitations such as media resources that may be depleted even though the gateway may have enough processing power (i.e., CPU) to handle incoming requests. The goal of this draft is to summarize the contemporary SIP load balancing algorithm as input to the SIP load balancing protocol designers. 2. Terminology 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 [RFC2119]. This document only uses these key words when referencing normative statements in existing RFCs." 3. Survey of existing mechanism & literature 3.1. Round robin Round robin based on DNS is illustrated in [RFC1794]. The focus of this mechanism is load distribution than load balancing. 3.2. Round robin with 503 or 302 or other overload mechanism TBD 3.3. Round robin with option ping The load balancing device sends OPTIONS ping message to each of its downstream servers to determine if they are available.The return Ravindran, et al. Expires July 26, 2012 [Page 3] Internet-Draft SIP Load balancing survey January 2012 value in the OPTIONS response and in some cases the delay between the sending of the request and the response is tracked by the loadbalancer. If the downstream server does not respond within a certain time window it is marked as down and not used in the round robin selection for the next request. If the OPTIONS ping does respond the result code is often checked for a particular response. For instance a 200 value response will not change the current state of the downstream server while a response in the 5xx/6xx range or specific 4xx values will remove the downstream device from service. An alternate case of OPTIONS pings is to just use them to verify that a SIP UAS of some kind exists at the destination, any SIP response is considered a good response and marks the downstream device as valid. OPTIONS pings are sent to downstream entities even if they are currently marked as down or out of service on the loadbalancer. When the device starts responding to the OPTIONS messages again it can then be placed back into the round robin selection. If the response to an OPTIONS request from a downstream host is successfully returned but is outside of an acceptable range, the loadbalancer can use this to indicate a problem with the downstream device and either remove it from the round robin, or change its portion of round robin traffic. 3.4. DNS based Load Balancing based on Load Detection Function section in 3GPP TS 23 .812(http://www.3gpp.org/ftp/Specs/archive/23_series/23.812/ 23812-115.zip) illustrates DNS based SIP load balancing 3.5. Resource availabilty based mechanism The media server load balancing depends upon the resources apart from CPU and Memory of the system. Resource availability mechanism in (ht tp://tools.ietf.org/html/ draft-partha-soc-overload-resource-availability-00) illustrate the way to achieve SIP based load balancing for media servers like PSTN- SIP GW, SBC. Resource availabilty draft provides the mechanism wherein SIP server indicates its resource capability to the prior SIP server by which prior SIP server will be able to perform load balancing. Explicit polling: some protocol (SNMP/SOAP+XML/SIP) is used to actively probe the downstream server for their current resource availability. The response to these polls are used to fill in the availability and resource allocation percentage of the downstream servers. continuous/streaming polling: a resource utilization report Ravindran, et al. Expires July 26, 2012 [Page 4] Internet-Draft SIP Load balancing survey January 2012 is included in each response (or every Nth response) from the downstream server through the load balancing device. In this way no additional polling or protocol is needed to update resource availability, it is kept up to date by constant use. This can easily be combined with OPTIONS pings. note: -multiple resources can be polled/used to figure out constraints. For 1 downstream server might be out of a particular resource (such as transcoding resources), but have ample capacity to provide other services ( for example relaying MESSAGE requests). 4. Standard open issues TBD 5. Security Considerations This document is a survey of existing literature on SIP load balancing. As such, it does not introduce any new security considerations to be taken into account beyond what is already discussed in each paper surveyed. 6. IANA Considerations This is no IANA consideration applicable for this draft. 7. Acknowledgement TBD 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Ravindran, et al. Expires July 26, 2012 [Page 5] Internet-Draft SIP Load balancing survey January 2012 8.2. Informative References [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995. Authors' Addresses Parthasarathi Ravindran Sonus Networks, Inc. Prestige Shantiniketan - Business Precinct Whitefield Road Bangalore, Karnataka 560066 India Email: pravindran@sonusnet.com Vijay .K Gurbani Bell Labs, Alcatel-Lucent Chicago USA Email: vkg@bell-labs.com Paul Erkkila Globalcrossing Newyork USA Email: Paul.Erkkila@Globalcrossing.com Ravindran, et al. Expires July 26, 2012 [Page 6]