Internet DRAFT - draft-partha-dispatch-siploadbalancing-survey
draft-partha-dispatch-siploadbalancing-survey
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]
