2.2 SIP-based Load Balancing. 3 SIP Load Balancing. 3.1 Proposed Load Balancing Solution. 2 Background Research. 2.1 HTTP-based Load Balancing

(1)

SIP TRAFFIC LOAD BALANCING

Ramy Farha

School of Electrical and Computer Engineering University of Toronto

Toronto, Ontario

ABSTRACT

This paper presents a novel solution to load balancing in a VoIP architecture using the Session Initiation Protocol (SIP) as a signaling protocol. With the emergence of SIP as a prominent candidate for signaling in future packet-based multimedia networks, an issue with service providers is to accommodate a larger number of subscribers in order to maximize revenues. This work is an attempt to propose a solution based on inserting a load balancer at the edge of the service provider’s network, which distributes calls in a desired manner between a pool of available Marshal Servers (MS), while automatically adapting the load distri-bution in case of failures. The solution was implemented, and intensive measurements were performed using a SIP-based VoIP testbed which was built at the University of Toronto’s Nortel Institute of Technology (NIT) labs for this purpose.

KEY WORDS

Session Initiation Protocol (SIP), Voice over IP (VoIP), Load Balancing, Marshal Servers (MS), Signaling, Mul-timedia.

1 Introduction

The Internet has recently become the most important, most popular way of communication. A significant new feature of Internet is its support of telephony. Figure 1 shows the Internet Multimedia Stack. Two main competing signal-ing protocol standards have been proposed for this purpose: H.323 [1], backed by ITU, and SIP [2, 3], backed by IETF. Since its introduction in 1997, SIP is gaining increasing support in the marketplace, namely because of its ability to combine features of Intelligent Networks from the telecom world for fixed and mobile telephony, with Internet fea-tures for email, Web, transactions, and entertainment [4]. SIP is a text-based protocol using elements from the Hy-per Text Transport Protocol (HTTP) and the Simple Mail Transport Protocol (SMTP), and following a client-server transaction model. SIP offers easier extensibility, provides more support for Internet features, operates with less com-plexity, and possesses a more efficient addressing scheme, referred to as Uniform Resource Identifier (URI).

The main idea of this paper is the following: Since SIP uses HTTP-style stateless transactions, analogies to

UDP PPP H.323 RTCP SDP SIP RSVP RTP Sonet ATM Ethernet IPv4, IPv6 TCP AAL RTSP

Figure 1. Internet Multimedia Stack

web-based load balancing can be performed to scale SIP-based architectures. A VoIP SIP-based architecture is shown in Figure 2. This architecture is composed of the following elements:

• SIP User Agents: Clients initiating SIP-based calls by

contacting the nearest Marshal Server, which handles the call from there. These agents can be SoftPhones (VoIP Software running on a computer), SIP Phones.

• Marshal Server: Provides the first contact point for all

external devices with the SIP-based infrastructure. It constitutes a trusted boundary for calls entering and leaving the network. In fact, it plays the logical func-tion of the SIP proxy and SIP registrafunc-tion server.

• Redirect Server: Provides SIP call routing services. • Provisioning Server: Provides GUI configuration and

management of users.

• Feature Server: Provides scripts that run basic

tele-phony features.

SIP requests and responses consist of a text header and a MIME body, very similar to the format of HTTP re-quests. One major difference is that SIP requests can use any transport protocol, including UDP. SIP defines an ex-tensible set of request methods currently included in the base specification: INVITE to initiate a session, ACK to

(2)

SIP User Agents

Marshal Server

Redirect Server Provisioning Server Feature Server

Figure 2. SIP based VoIP Architecture

confirm a session establishment, BYE to terminate a ses-sion, OPTIONS to determine capabilities, and CANCEL to terminate a session that has not been established yet. The session itself is typically described using the Session Description Protocol [5] that lists media stream addresses, ports and the encodings supported.

In a real-life scenario, the SIP-based VoIP architec-ture might need to support a large number of users, in which case the SIP servers will need to scale accordingly. The main contributions of this paper are building a dis-tributed SIP-based architecture and studying its scalability by looking at several load-balancing methods for the case where several ingress Marshal Servers are used. Some of these methods will be similar to instances of load balanc-ing on Web Servers [6, 7] and other static and adaptive load balancing algorithms for SIP traffic will be proposed.

2 Background Research

2.1 HTTP-based Load Balancing

Load balancing on Web Servers [6, 7] has received con-siderable attention in the research community, in order to avoid having a web server become a bottleneck in large-scale networks. These studies looked at several approaches to load balancing, namely: DNS-based, client-based, and server-based. These methods showed less scalability than the dispatcher-based approach (also referred to as HTTP scheduler), proposed in [6]. The scheduler parses the in-coming HTTP packets, and decides whether scheduling is needed. Several load balancing techniques, mainly random and Round Robin are tested and their results presented.

2.2 SIP-based Load Balancing

The emergence of SIP is recent. Hence, it has received little interest in the academia before a few years. Since then, SIP was proposed as an alternative for several applications and services, such as mobility, instant messaging, and location based services [4]. However, the study of load balancing in SIP-based multimedia networks has received no attention so far. To our best knowledge, this paper is a first attempt to look at this problem, which can arise in large-scale future real-life VoIP networks using SIP signaling.

3 SIP Load Balancing

3.1 Proposed Load Balancing Solution

The goal of this paper is to balance the load in the SIP-based VoIP architecture. The model proposed consists of a Load Balancer proxy at the edge of the SIP-based architec-ture of the service provider, which role is to select a Mar-shal Server out of a pool of available MarMar-shal Servers and to send incoming SIP requests to one of them, based on one of several possible load balancing algorithms.

The choice of this solution is motivated by the fact that load balancing at the edge of the SIP-based service architecture prevents bottlenecks in the servers of the ar-chitecture of Figure 2 (Marshal, Redirect). Several Mar-shal Servers will be able to communicate with one or more Redirect Servers, easing the load even further if needed.

In addition, it is easier for callers to send their SIP requests to a single URI, that of the Load Balancer proxy, whenever they would like to contact the SIP service provider in order to establish a multimedia session. The Load Balancer proxy can be chosen by the service provider as the most powerful of the available servers. But in ad-dition to its load balancing capabilities, this solution can offer redundancy by having several Load Balancer proxies running simultaneously, and users can always contact other proxies in case they receive no response from a failed one given that an adaptive load-balancing mechanism is used. This provides scalability, as no constraints on the number of such Load Balancer proxies exist. Fault-tolerance in case of a Marshal Server failure will be remedied to by using an adaptive load balancing scheme, which adds ro-bustness to this already scalable solution.

3.2 Load Balancer Proxy Design

The proposed solution used is shown in Figure 3. Incom-ing SIP INVITE requests from the clients go through the Load Balancer proxy, which splits the traffic among sev-eral available Marshal Servers. The Load Balancer proxy parses the SIP INVITE request header, and changes it to the URI of the chosen Marshal Server. The Marshal Server responds to the Load Balancer proxy with a 180 Trying status message, and then a 200 OK status message which

(3)

SIP User Agents

Load Balancer

Redirect Server Provisioning Server Feature Server Marshal Servers

Figure 3. Proposed Solution: Load Balancing Proxy

are forwarded to the caller. The media session will then be opened directly between the clients and the marshal servers without further intervention from the Load Balancer proxy. The load balancing techniques explored are di-vided into two categories: Adaptive Equal and Non-Adaptive Unequal.

3.2.1 Non-Adaptive Equal Techniques

• Random: A Marshal Server is chosen at random

among the set of available Marshal Servers.

• Round-Robin: A Marshal Server is chosen in a Round

Robin fashion among the set of available Marshal Servers.

• Least-Bytes: A Marshal Server is chosen if it has

re-ceived the least amount of bytes that were routed so far among the set of available Marshal Servers.

• Least-Packets: A Marshal Server is chosen if it has

received the least amount of packets that were routed so far among the set of available Marshal Servers.

3.2.2 Non-Adaptive Unequal Techniques

• Bytes Distribution: A Marshal Server is chosen based

on a bytes distribution preset by the administrator when running the Load Balancer proxy. This method

Marshal Server MS-f fails Load Balancer blocks MS-f Spread Incoming SIP traffic among remaining Marshal Servers

Send SIP Packet to MS-f after X sec

Re-include MS-f in Marshal Servers pool

Continue while blocking MS-f MS-f

Up?

Yes No

Figure 4. Poll-Based Adaptive Load-Balancing Technique

is aimed to provide the administrator with the possibil-ity of routing more calls to the more powerful servers.

• Packets Distribution: A Marshal Server is chosen

based on a packets distribution set by the adminis-trator when running the Load Balancer proxy. This method is aimed to provide the administrator with the possibility of routing more calls to the more powerful servers.

The methods described so far are not well suited to accidental failures that might occur at the Marshal Servers, which can be a common situation in real life scenarios. For this purpose, we propose yet another load balancing method, which, in contradiction to the aforementioned load balancing techniques, is adaptive.

The algorithm, called poll-based adaptive load bal-ancing (PALB), is shown in Figure 4. Note that a way to detect failure at the Load Balancer proxy can be a time-out for receiving the ”180 Trying” status message from the Marshal Server to which the INVITE SIP request is sent, or any other mechanism that can convey the information to the Load Balancer proxy. Upon detection of a failure, the Load Balancer proxy will block transfer to the failed Marshal Server, and then periodically, will attempt to route traffic back to this Marshal Server. If success is reported,

(4)

the Marshal Server is inserted back into the pool of Mar-shal Servers from which the subsequent load balancing op-erations will choose.

3.3 Load Balancing Proxy Operation

The proposed proxy is such that the administrator of the service provider’s SIP-based network sets up several Mar-shal Servers and a Load Balancer proxy. On the Load Balancer proxy, the command line run by the administra-tor to start balancing the incoming SIP traffic specifies the available Marshal Servers using the -marshalProxy option, which specifies the IP address of the Marshal Server, and the port number on which the Marshal Server will receive the incoming SIP traffic.

The administrator can add as many Marshal Servers as deemed necessary (of course as many as the service provider has). These servers’ information will be added to an information base at the Load Balancer proxy.

The Load Balancer proxy opens a socket to receive packets from the users on the unique SIP URI of the service provider. By default, the port number for incoming SIP traffic is 5060, but can be changed dynamically using the command line option -reqPort.

The Load Balancer proxy parses the SIP INVITE re-quest header, modifies the IP address and port number of the receiver (initially set to the Load Balancer proxy by the clients) to those of the chosen Marshal Server. The packets are forwarded to the corresponding Marshal Server, and the load is therefore balanced.

4 VoIP Implementation

The major implementation step was to find an open-source library based on SIP. One such possibility, VOCAL (Vovida Open Communication Library) was chosen, namely be-cause of its availability, its maturity level, and its increas-ing popularity [8]. VOCAL is an open source, IP cen-tric communication software, development platform and li-brary, which runs on Linux and Solaris operating systems, and uses Intel (I86) based hardware. VOCAL provides SIP-based call control and switching, and the ability to create features and applications. The VOCAL architecture was deployed over several machines. The load balancer proxy was designed to integrate with the VOCAL architecture. The SIP load generator provided by VOCAL was used to test the different load balancing approaches. Note that the call generation rate is depended on many parameters, such as the processing power of the computers used to run the experiments.

5 Experimental Results

The VOCAL load generator send around 15 calls per second (cps). This rate is arbitrarily chosen because it is not relevant to our experiments, as our purpose is to show

Table 1. SIP Request Packets Equal Load Balancing with-out Failure

Methods 3 MSs 4 MSs 5 MSs

M1 Total: 889 Total: 955 Total: 926

A: 311 A: 236 A:180

B: 267 B: 239 B: 184

C: 311 C: 248 C: 185

D: 232 D: 182 E: 195 M2 Total: 893 Total: 881 Total: 951

A: 297 A: 220 A: 190

B: 298 B: 221 B: 191

C: 298 C: 220 C: 190

A: 321 A: 230 A: 190

B: 320 B: 230 B: 189

C: 320 C: 231 C: 189

A: 321 A: 227 A: 189

B: 321 B: 227 B: 189

C: 321 C: 226 C: 189

D: 226 D: 189 E: 189

the traffic balancing methods’ comparative performance. We ran the experiments for 60 seconds, so we should expect around 900 packets to be sent for each run. For simplicity, we will use the following notation to refer to the load-balancing methods:

Non-Adaptive Equal Load Balancing

• Random: M1 • Round Robin: M2 • Least-Bytes: M3 • Least-Packets: M4

Non-Adaptive Unequal Load Balancing

• Bytes Distribution: M5 • Packets Distribution: M6

Adaptive Load Balancing

• Poll-based Adaptive Load Balancing (PALB):M7

The first experiment looks at an increasing number of Marshal Servers, and checks that the proposed methods function correctly. We used three, four, and five Marshal

(5)

Table 2. SIP Request Packets Unequal Load Balancing without Failure

Methods 3 MSs 4 MSs 5 MSs

M5 Total: 872 Total: 826 Total: 848

A: 175 A: 165 A: 85

B: 349 B: 207 B: 85

C: 348 C: 207 C: 128

A: 174 A: 171 A: 81

B: 347 B: 214 B: 81

C: 347 C: 214 C: 121

D: 257 D: 201 E: 320

Servers, without any failure, and computed the number of packets sent to each Marshal Server. Table 1 shows the results for the non-adaptive techniques with equal load bal-ancing. For M5 and M6, we distribute the load according to the following percentages:

• 3 MSs: 20% for A, 40% for B, 40% for C.

• 4 MSs: 20% for A, 25% for B, 25% for C, 30% for D. • 5 MSs: 10% for A, 10% for B, 15% for C, 25% for D,

40% for E.

Table 2 shows the results for the non-adaptive techniques with unequal load balancing.

The second set of experiments we ran looked at the possibility of Marshal Server failure. This is a realistic pos-sibility, and can often occur in real-life scenarios. First, the number of Marshal Servers in the pool to choose from is changed from 2 to 5. One Marshal Server has a 10% failure probability (chosen for illustrative purposes), while the oth-ers are failure-free. Results show the percentage of packet requests delivered versus the number of Marshal Servers. Second, the failure probability is again fixed to 10% vs. 0% for two Marshal Servers, and the failure duration is varied for 1 to 10 seconds. Results show the percentage of packet requests delivered versus the fail duration of the Marshal Server. Third, the number of Marshal Servers of fixed to two (chosen for illustrative purposes), and the error failure probability on one of them is increased from 0% to 40%. Results show the percentage of packet requests versus the failure probability. Figure 5 shows the percentage of pack-ets delivered for a different number of Marshal Servers, where one has a 10% failure probability. Figure 6 shows the percentage of packets delivered for different failure du-rations. Figure 7 shows the percentage of packets delivered for two proxies, one of which is failing with a probability going from 0% to 40%.

The common notion of failure represents frustration at the poor service offered, and for the provider, represents

2 2.5 3 3.5 4 4.5 5 75 80 85 90 95 100

Percentage of SIP Requests Delivered

Number of Marshal Servers

Percentage Delivered M1 M2 M3 M4 M7

Figure 5. Percentage of successful SIP calls for varying number of Marshal Servers

1 2 3 4 5 6 7 8 9 10 60 65 70 75 80 85 90 95 100

Failure Duration Percentage Delivered M1 M2 M3 M4 M7

Figure 6. Percentage of successful SIP calls for different failure durations

(6)

0 5 10 15 20 25 30 35 40 60 65 70 75 80 85 90 95 100

Failure Probability Percentage Delivered M1 M2 M3 M4 M7

Figure 7. Percentage of successful SIP calls for different failure probabilities

lost income as a potential caller has been dropped. Note that the X seconds duration is flexible, and can be set by the administrator accordingly, if, for instance, the failed Mar-shal Server diagnostic indicates a lengthy failure.

The results are as expected, showing that the adaptive technique always delivers a very high ratio of the incoming SIP requests (over 99.5%), dropping only few packets till it readjusts its delivery method to exclude the failed nodes. Note that the adaptive method performs well regardless of the number of Marshal Servers available, of the failure du-ration, and of the failure probability.

6 Conclusion

The proposed technique can be a starting point for more elaborate load balancing algorithms in a SIP-based VoIP ar-chitecture. In addition, we note that the static load balanc-ing techniques can be used when the pool of available Mar-shal Servers increases, as the percentage of SIP requests dropped will decrease. However, we argue that a call lost is still frustration and lost income for both the client and the service provider, hence the need for an adaptive and fault-tolerant load balancing technique.

This paper is the first attempt to look at load balancing in a SIP-based VoIP network. Therefore, more elaborate work can focus on many possible improvements, namely:

• Other adaptive load balancing techniques, which can

be based on the history of the failures, on the speci-ficities of the Marshal Servers, or on the traffic model.

• For testing purposes, a better/different load

genera-tor, which has more options, can be used. Mainly, higher calls per second (cps) generation, a more

re-alistic traffic model (exponential, self-similar) can be considered.

• More realistic failure models can be used, other than

the static and elementary model we used where a node fails for a constant duration with a given probability. The failure timing and duration can be related to some other factors in a large-scale network.

Finally, the technique proposed in this paper (proxy load balancer) can be made more scalable to avoid the over-loading or the single point of failure that the load balancer constitutes by using redundancy to specify multiple proxy load balancers available to users to send their calls to. The ultimate goal of this design should be to yield the 5-nines reliability of telephony systems.

References

[1] ITU-T, “H.323 version 5 draft.” ITU-T Recommenda-tion, Jan. 2004.

[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosen-berg, “SIP: Session Initiation Protocol.” RFC 2543, Mar 1999.

[3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. John-ston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, “SIP: Session Initiation Protocol.” RFC 3261, June 2002.

[4] H. Sinnreich and A. B. Johnston, Internet Communica-tions Using SIP. New York: Wiley, 2002.

[5] M. Handley and V. Jacobson, “SDP: Session Descrip-tion Protocol.” Internet Draft, IETF Multiparty Multi-media Session Control Working Group, Sept. 1997. [6] V. Cardellini, M. Colajanni, and P. S. Yu, “Dynamic

Load Balancing on Web-Server Systems,” IEEE Inter-net Computing, pp. 28–39, 1999.

[7] H. Bryhni, E. Klovning, and O. Kure, “A Compari-son of Load Balancing Techniques for Scalable Web Servers,” IEEE Network, pp. 58–64, July-August 2000. [8] Vovida, “Vovida: Your source for Open Source