Session Initiation Protocol (SIP) Load balancing survey

Session Initiation protocol 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.

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 . This document only uses these key words when referencing normative statements in existing RFCs."

Round robin based on DNS is illustrated in . The focus of this mechanism is load distribution than load balancing.

TBD

The load balancing device sends OPTIONS ping message to each of its downstream servers to determine if they are available.The return 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.

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

The media server load balancing depends upon the resources apart from CPU and Memory of the system. Resource availability mechanism in (http://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 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).

TBD

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.

This is no IANA consideration applicable for this draft.

TBD