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

Transcription

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 distribution in case of failures. The solution was implemented, and intensive measurements were performed using a SIPbased 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, Multimedia. 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 signaling 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 features for , Web, transactions, and entertainment [4]. SIP is a text-based protocol using elements from the Hyper 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 complexity, 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 H.323 SIP RTSP RSVP RTCP TCP PPP Sonet SDP IPv4, IPv6 AAL ATM UDP Figure 1. Internet Multimedia Stack Ethernet RTP web-based load balancing can be performed to scale SIPbased 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 function of the SIP proxy and SIP registration server. Redirect Server: Provides SIP call routing services. Provisioning Server: Provides GUI configuration and management of users. Feature Server: Provides scripts that run basic telephony features. SIP requests and responses consist of a text header and a MIME body, very similar to the format of HTTP requests. One major difference is that SIP requests can use any transport protocol, including UDP. SIP defines an extensible set of request methods currently included in the base specification: INVITE to initiate a session, ACK to

2 2.2 SIP-based Load Balancing SIP User Agents Marshal Server Redirect Server Provisioning Server Feature Server 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 Figure 2. SIP based VoIP Architecture confirm a session establishment, BYE to terminate a session, 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 architecture 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 distributed 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 balancing 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 considerable attention in the research community, in order to avoid having a web server become a bottleneck in largescale 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 incoming HTTP packets, and decides whether scheduling is needed. Several load balancing techniques, mainly random and Round Robin are tested and their results presented. The goal of this paper is to balance the load in the SIPbased VoIP architecture. The model proposed consists of a Load Balancer proxy at the edge of the SIP-based architecture of the service provider, which role is to select a Marshal Server out of a pool of available Marshal 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 architecture of Figure 2 (Marshal, Redirect). Several Marshal 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 addition 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 robustness to this already scalable solution. 3.2 Load Balancer Proxy Design The proposed solution used is shown in Figure 3. Incoming SIP INVITE requests from the clients go through the Load Balancer proxy, which splits the traffic among several 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 Marshal Server MS-f fails Load Balancer Load Balancer blocks MS-f Marshal Servers Spread Incoming SIP traffic among remaining Marshal Servers Redirect Server Provisioning Server Feature Server Send SIP Packet to MS-f after X sec Yes MS-f Up? No Figure 3. Proposed Solution: Load Balancing Proxy Re-include MS-f in Marshal Servers pool Continue while blocking MS-f 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 divided into two categories: Non-Adaptive Equal and Non- Adaptive Unequal 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 received 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 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 Figure 4. Poll-Based Adaptive Load-Balancing Technique is aimed to provide the administrator with the possibility of routing more calls to the more powerful servers. Packets Distribution: A Marshal Server is chosen based on a packets distribution set by the administrator 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 balancing (PALB), is shown in Figure 4. Note that a way to detect failure at the Load Balancer proxy can be a timeout 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 Marshal Servers from which the subsequent load balancing operations 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 Marshal Servers and a Load Balancer proxy. On the Load Balancer proxy, the command line run by the administrator 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 request 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 because of its availability, its maturity level, and its increasing popularity [8]. VOCAL is an open source, IP centric communication software, development platform and library, which runs on Linux and Solaris operating systems, and uses Intel (I86) based hardware. VOCAL provides SIPbased 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 without 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 D: 220 D: 190 E: 190 M3 Total: 961 Total: 922 Total: 947 A: 321 A: 230 A: 190 B: 320 B: 230 B: 189 C: 320 C: 231 C: 189 D: 231 D: 190 E: 189 M4 Total: 963 Total: 906 Total: 945 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 D: 247 D: 212 E: 338 M6 Total: 868 Total: 856 Total: 804 A: 174 A: 171 A: 81 B: 347 B: 214 B: 81 C: 347 C: 214 C: 121 D: 257 D: 201 E: 320 Percentage Delivered M1 M2 M3 M4 M7 Percentage of SIP Requests Delivered 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 balancing. For M5 and M6, we distribute the load according to the following percentages: Number of Marshal Servers Figure 5. Percentage of successful SIP calls for varying number of Marshal Servers 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 possibility, 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 others 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 packets 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 durations. 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 Percentage Delivered Percentage of SIP Requests Delivered Failure Duration Figure 6. Percentage of successful SIP calls for different failure durations M1 M2 M3 M4 M7

6 Percentage Delivered Percentage of SIP Requests Delivered Failure Probability 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 Marshal 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 duration, 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 architecture. In addition, we note that the static load balancing techniques can be used when the pool of available Marshal 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: M1 M2 M3 M4 M7 For testing purposes, a better/different load generator, which has more options, can be used. Mainly, higher calls per second (cps) generation, a more realistic 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 overloading 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 Recommendation, Jan [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, SIP: Session Initiation Protocol. RFC 2543, Mar [3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, SIP: Session Initiation Protocol. RFC 3261, June [4] H. Sinnreich and A. B. Johnston, Internet Communications Using SIP. New York: Wiley, [5] M. Handley and V. Jacobson, SDP: Session Description Protocol. Internet Draft, IETF Multiparty Multimedia Session Control Working Group, Sept [6] V. Cardellini, M. Colajanni, and P. S. Yu, Dynamic Load Balancing on Web-Server Systems, IEEE Internet Computing, pp , [7] H. Bryhni, E. Klovning, and O. Kure, A Comparison of Load Balancing Techniques for Scalable Web Servers, IEEE Network, pp , July-August [8] Vovida, Vovida: Your source for Open Source Communication. Other adaptive load balancing techniques, which can be based on the history of the failures, on the specificities of the Marshal Servers, or on the traffic model.