MULTI-DOMAIN VoIP PEERING USING OVERLAY NETWORK

Transcription

1 116 MULTI-DOMAIN VoIP PEERING USING OVERLAY NETWORK Herry Imanta Sitepu, Carmadi Machbub, Armein Z. R. Langi, Suhono Harso Supangkat School of Electrical Engineering and Informatics, Institut Teknologi Bandung Jl. Ganesha 10, Bandung, Indonesia ABSTRACT Multi-domain VoIP network requires peering to allow call routing from one domain to other domains. The problem with current VoIP peering solution is because it uses client/server architecture. The DNS server is usually used to provide services to lookup domain and locate the switching server in a domain. In this paper we propose a distributed architecture to provide lookup services using overlay network. This particular application requires an efficient Distributed Hash Table (DHT) protocol as the overlay layer. We also present an efficient DHT with one hop lookup performance and show some simulation results that highlight the performance of the protocol under join and leave events. functions in the proposed architecture. The Lookup Function (LUF) provides the mechanism to reply a signaling request with the target domain, the Location Routing Function (LRF) determines the Signaling Function (SF) at the target domain, the Signaling Function (SF) performs SIP call routing, and the Media Function (MF) that performs media related function such as transcoding. The standard suggests that the lookup function and location routing function should use DNS-based lookup service such as ENUM to resolve a request into its target domain and the signaling function that serve that target domain. ATA IP Phone IP Phone ATA Keywords: overlay network, peer-to-peer, distributed hash table, VoIP peering. Softphone SIP Domain A SIP Domain C Softphone INTRODUCTION Most of the current internet telephony systems are using client/server architecture. Certain number of clients such as gateways, softphones, or IP phones are grouped together into one service domain and served by a service provider. Figure 1 shows the typical multi-domain internet telephony deployment using Session Initiation Protocol (SIP) as the signaling protocol [1]. The similar concept also exists in network with different signaling protocols such as H.323, IAX2, or MGCP. The service provider for a domain provides the switching function (softswitch) to route calls. The switching function is able to route the call originated from its clients to the destinations in other domains only if it has preconfigured the routes to reach those domains. Those routes between domains are built through VoIP peering, which is the interconnection of two service provider (by agreement) for the purpose of routing call signaling between their respective customers [3]. The standard for VoIP peering (SPEERMINT) is currently developed by IETF. It uses Layer-5 peering which employs ENUM as the lookup service and SIP as the signaling protocol [3]. According to the standard [4] there are four main Registrar/DB SIP Proxy ATA Softphone IP Phone SIP Domain B Registrar/DB SIP Proxy SIP Peering SIP Proxy Registrar/DB PSTN/ Mobile Network Gateway Figure 1. Multi-domain VoIP peering using SIP as signaling protocol The problem with client/server protocol such as DNS-based ENUM lookup service is that the DNS server becomes the bottleneck and creates single point of failure. This paper proposes architecture for VoIP peering using distributed approach to address the scalability issue that come with the client/server architecture. Instead of using client/server architecture to provide lookup function (LUF) and location routing function (LRF), we propose a distributed lookup and routing function by leveraging the overlay network that constructed

2 019 Multi-Domain Voip Peering Using Overlay Network - Herry Imanta Sitepu 117 by switching servers that act as the nodes in the overlay network. Overlay network is the logical network that runs on top of physical network. The logical network, which is the peer-to-peer network is constructed by some peers that running a particular protocol which allows each peer to communicate with each other and allowing access and sharing their resources (such as CPU or storage) directly [1]. Distributed Hash Table (DHT) algorithm is the infrastructure that builds the structured overlay network. DHT allows mapping keys to nodes and provides hash-table-like lookup interface. This paper present a simple yet efficient DHT algorithm with O(1) lookup performance, which means a key lookup can be solved by contacting one node (one hop lookup). The simulation results show that the DHT algorithm is efficient in term of the events distribution latency. The events distribution latency is time duration between the detection of events and the distribution of those events to all nodes in the network. Thus, the DHT is suitable for our application to provide lookup services for VoIP peering. With the architecture that we propose, the VoIP peering can be simpler to deploy as adding new domain to the network will be noticed by other domains without additional configuration. DISTRIBUTED HASH TABLE The interest among researchers in the area of DHT development, analysis, or comparison is increasing because the potential applications that may leverage the DHT algorithm are enormous [2][5][6][7]. Ubiquitous file sharing applications have shown the popularity of peer-to-peer (p2p) application among the user. Nevertheless, the potential application is not limited only to file sharing application, but to DNS services, mobile p2p, content distribution, instant messaging, distributed computing, and many more. DHT algorithm assigned keys to nodes by employing a predefined procedure. A node may lookup for a key and expects to get the address of the node that responsible for that key. The address of the node is used for final retrieval of the data that related with the key from the target node. This lookup interface is similar with common hash-table algorithms. In this section we describe UnoHop protocol, which is a DHT with O(1) lookup performance, which means that the lookup can be resolved by contacting one node (one hop). This lookup performance can be achieved because DHTs with O(1) lookup performance require each node maintain a routing table with complete information about all nodes in the network. UnoHop protocol is the distributed algorithm that allows upper layer application to publish data (which represented as keys) and to lookup data. UnoHop Protocol The main problem that have to be addressed by DHTs with O(1) lookup performance is how to detect and distribute events (nodes join or leave) efficiently. When a node detects that an event has occurred, it must notify other segments of the network about the event, thus the routing table entries in all nodes can be updated and corrected according to the network latest condition. OneHop [7] uses the division of ring into contiguous segments called slices and a slice is further divided into smaller contiguous segments called units s 1 1 Figure 2. Events distribution mechanism 4 f Slice leader Unit leader Ordinary node Each slice is represented by a slice leader, which is a node that collects the events from other slices and notifies its unit leaders. Finally, a unit leader piggybacks the events to its ping messages to its predecessor and successor. With this scheme the ordinary nodes bandwidth usage is decreased but with the consequence of the increased bandwidth usage at the slice leaders. UnoHop protocol uses the similar ring division into segments called slices and units. Instead choosing the fixed slice leader (the successor of mid-point identifier of a slice) and unit leader (the successor of mid-point identifier of a unit) as in OneHop, our algorithm chooses the slice leaders and unit leaders dynamically according the closeness factor. Because each node maintain complete information about all nodes in the network, the

3 118 4 th International Conference Information & Communication Technology and System UnoHop can not employs Proximity Neighbor Selection (PNS) as described by Saroiu et al. [9]. Instead, it uses the Proximity Route Selection (PRS) [9]. By selecting the next hop as the closest node to the sender, then the communication latency can be reduced. The simple approach we use to characterizing closeness between nodes is the communication latency between the sender node and the target node. A slice leader is selected as the closest node in the slice, which has the lowest latency from the node that detects an event. A unit leader is selected as the closest node in the unit from its slice leader. To detect events each node runs stabilization procedure by send ping message to its predecessor and successor periodically at a predefined time interval (t stab ) When the ping is time out, the sender will detect that its predecessor or successor has been leaved the network. The node that detects the events must notify other nodes in the network or the lookup from those nodes to the failed node will return incorrect result. The mechanism to distribute events is depicted by Figure 2. The network contains 10 nodes and divided into 3 slices. Each slice is further divided into 3 units. When a node s detect an event (node f has leaved the network) by running its stabilization procedure (step 1), next it must notify all segments about the event including its own segment. To distribute the event to its own slice, it select a node that act as the slice leader that will further distribute the event. The slice leader is chosen as the closest node in the slice to node s. After found a node that act as its slice leader, then the event is sent to it (step 2). Next, node s distributes its event to other slices. By choosing the slice leader of a slice as the closest node at each slice from node s, then node s sends the event to those slices leaders. Upon receiving an event notification, a slice leader has to distribute the event to all units in its slice. Each unit is represented by a node (unit leader) that has the lowest latency from the node that acts as the slice leader and has received the events sent by the source node s. The slice leader sends the event to all its unit leaders (step 3). When the node that represent a unit (unit leader) receive the events, then it aggregates the events. The aggregated events are piggybacked in the ping message to its predecessor and successor (step 4). The events then piggybacked in ping message from one node to other node in one direction until it reaches the unit border. If a node receives the events from its predecessor then it will piggyback the events in its ping message to the successor. If a node receives the events from its successor then it will piggyback the events in its ping message to the predecessor. With this mechanism there is no duplication in communication. ARCHITECTURE Each node that joins in the overlay network is the switching function that serves a domain. A domain consists of VoIP clients such as gateways, softphones, or IP phones. If a client originates a call to other clients in one domain, then the switching function can directly route the call to the destination. Figure 3 shows the distributed architecture for multi-domain VoIP peering. As the example, we choose that provides switching function in one domain. This is because s usually serve domain with up to hundreds of clients. The architecture gives simple yet powerful solution for enterprises that run multiple s serving branch offices. Internet Telephony Service Providers (ITSPs) that runs larger switching function such as SIP proxies or softswitches may use the architecture as the VoIP peering solution between them. get_route(destination) Internet DHT store_route(destination) Figure 3. Architecture of VoIP peering between using overlay network. When a domain joins the VoIP peering system, its switching function should publish all the E.164 numbers of its clients. By calling store_route() procedure and passing the client s number as the parameter The DHT layer will distribute the information (through the overlay network) related with the number such as its domain name and the location information of the switching function that is responsible to route the call in the domain. Each join events then distributed to other nodes in the overlay network, thus other switches

4 019 Multi-Domain Voip Peering Using Overlay Network - Herry Imanta Sitepu 119 recognize that there is a new domain has join the VoIP peering system. If a client in a domain request its switching function that serve its domain to make a call to the destination which not existed in its domain, then the switch must route call to other switch that serve the target domain. Before route the call to another domain, the switch call get_route() procedure and passing the destination number. The DHT layer then send lookup with the destination number as the key through the overlay network. With a successful lookup, the requesting node receives the address of the node that responsible for the key. Next, the node retrieves the information such as the domain name and the location of the switch that serve that domain. The information that received through the lookup is used by the switch to route the call to the switch at the target domain. Figure 4 shows the software layer that is required to implement the functionalities for publishing and lookup telephone number. Extension logic is the function within that route calls. If the extension logic finds out that the destination number is outside its service domain, then it will send Remote Procedure Call (RPC) to the DHash layer [10]. DHash is actually the layer that provides block storage system. It provides a simple put and get interface to store and retrieve objects. Extension Logic DHash UnoHop DHT get_route(destination) Extension Logic DHash UnoHop DHT the destination domain through the switch that serve the domain. ENVIRONMENTAL SETUP We use p2psim [8] packet level simulator to simulate UnoHop algorithm. The simulator only focus on the lookup performance described by lookup latency and lookup failure rate and bandwidth usage of the routing table maintenance procedure, thus it is appropriate to analyze the routing performance of a DHT. The simulator can collect some important data such as total number of lookup, total number of lookup failures, bandwidth usage per node, and other data for further analysis. As the protocol parameters we use slice with size 10 and unit with size 5. The stabilization interval is chosen as 1 second. We use some network topologies for the simulation. First, our simulation uses network that consists of 1024 nodes. The latency matrix of 1024 nodes is collected using King s technique that uses recursive DNS queries to approximate the latency between nodes [9]. Second, our simulation uses network that consists of 400, 600, and 3000 nodes where each node has the Euclidean coordinate that chosen randomly. The latency between nodes is calculated as the Euclidean distance between nodes. Both network topology have round trip delay with mean 178 ms. We also generate lookup events for each node to lookup random key at interval that chosen randomly. The lookup interval is calculated by following exponential distribution with mean 1 lookup per second. TCP/IP Lookup message Lookup response TCP/IP Internet Figure 4. Architecture of VoIP peering between using overlay network. DHash layer may use different routing protocol. For our particular application we use UnoHop DHT to provide routing and lookup in the overlay network. A Lookup message is constructed by the DHT layer and sent across the internet. If the DHT protocol return a successful result, then the requesting node receive the address of the destination node. That address is used to construct the message to retrieve the information that stored at that node. DHash layer translate the retrieved data into the information that can processed by the extension logic. Extension logic layer will look for domain name and the location of the switch that serve that domain. Next the switch route the call to Figure 5. Fraction of one hop lookup failure of 1024 nodes running UnoHop protocol.

5 120 4 th International Conference Information & Communication Technology and System SIMULATION RESULTS To show how efficient the events distribution mechanism that used by both algorithms when some nodes crash, we generate crash events at time 200 second from the start of the simulation that trigger 40% of the nodes in the network to leave the network (crashed). The nodes are chosen randomly and one node is crashed at a time every 1 ms. For network topology consists of 1024 nodes, all 40% randomly chosen nodes completely crashed after 410 ms. After that crashes all lookup to those nodes will fail thus increasing failure rate of the system and decreasing lookup performance. To show how efficient each algorithm to distribute join events, we generate rejoin events for nodes that previously crashed. One node is rejoined at a time with interval 1 ms at time around 1000 second. After rejoin, there are also some movements of the keys which some keys are reassigned to the newly joined nodes. Because all other nodes still have old entries in the routing table and do not know about newly joined nodes, then the fraction of one hop lookup failure will increase again. Figure 5 shows the increase of one hop lookup failure at time 200 second and 1000 second. At 200 second 40% of randomly chosen nodes are crashed one at a time. The other nodes in the network that still have entries about those crashed nodes in their routing table will get failed lookup result. The increase of one hop lookup failure is the impact of the inaccuracy of the routing table. After the event distribution procedure is running, and then the lookup failure rate is decreasing gradually. The efficiency of the event distribution mechanism is shown by the time that required by the protocol to update the routing table at all other nodes. The faster the distribution delay the more efficient the distribution algorithm that used. UnoHop requires 50 seconds for decreasing the one hop lookup failure from 35% to 0.5%. Figure 6. Average of maintenance bandwidth per node of 1024 nodes running UnoHop protocol When all the nodes that have been crashed are rejoined back at time 1000 second, the lookup failure rate is increasing again. This is because of the movements of some keys to the newly joined nodes. UnoHop distribute join event aggressively and requires 10 seconds for decreasing the one hop lookup failure rate from 13% back to 0.6%. The performance that comes with UnoHop algorithm is increasing the average bandwidth requirement per node. Figure 6 shows the significant increase of bandwidth usage (929.5 bytes/s) for distributing join events compared with the increase of bandwidth usage (251.5 bytes/s) to propagate routing table update at crash events. This significant different of bandwidth usage is because we design the protocol that have the capability to update all nodes in the network when adding new node to the system. At real deployment, 410 nodes addition is rare and for lower size concurrent nodes join the network then the bandwidth requirement will be much lower. Figure 7 shows different number of crashed nodes. Proportional with the increase of the fraction of crashed nodes, the one hop lookup failure is increasing too. Nevertheless, the distribution delay that required by UnoHop is not increase significantly. With crashing 20%, 30%, 40%, and 50% of nodes, the distribution delay is increase slowly. We also simulate different network size with 400, 600, 1024, and 3000 nodes. In all of these simulations, we generate events to crashed 40% of nodes. Figure 7 shows that despite the increase of network size, the distribution delay only shows a slight variation. This behavior is required for our application to allow the application become scalable with network size up to thousands of nodes.

6 019 Multi-Domain Voip Peering Using Overlay Network - Herry Imanta Sitepu 121 Figure 7. Fraction of one hop lookup failure of 1024 nodes with different number of crashed nodes. Figure 8. Fraction of one hop lookup failure with different network size. All use the same fraction of crashed nodes (40%). CONCLUSION AND FUTURE WORK VoIP peering requires some client/server architecture for lookup function that process call requests and retrieve the domain and next hop destination to process call. The client/server architecture requires the server having redundancy and high availability mechanisms. Otherwise, the server will become the bottleneck and single point of failure. In this paper we propose a distributed architecture to process lookup in VoIP peering. Before route the call to other domains, the switching function in a domain may perform lookup the overlay network using destination number as the key. The result from lookup contains information about the domain where the destination is served and the switching function that responsible to route the call to the destination. This simple architecture provide a distributed and robust mechanism for VoIP peering. DHT is the layer that provides routing mechanism at the overlay network. A key that represent data is assigned to a node that responsible to store the key. We present an efficient one hop DHT that can be used as the distributed layer. UnoHop has low latency for distributing events such as nodes join or leave. Our simulation results also show that UnoHop is scalable for larger network size up to 3000 nodes. The variation is not significant as the network size is growing. As the future work we will minimize the bandwidth requirement, which can be done by aggregating some events at predefined interval before distributing those events further. Another work is to test the application on the real network and collecting some statistic data to be compared with the simulation results. REFERENCE [1] S. Androutsellis-Theotokis, dan D. Spinellis, A survey of peer-to-peer con-tent distribution technologies. ACM Computing Surveys (CSUR) 36: , [2] Stoica, I., Morris, R., Karger, D., Kaashoek, F. M. dan Balakrishnan, H. Chord: A scalable peer-to-peer lookup service for internet applications. In SIGCOMM 01: Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, 31. New York, NY, USA: ACM Press, [3] [4] [5] P. Maymounkov and D. Maziã res. Kademlia: A peer-to- peer information system based on the xor metric. First InternationalWorkshop, IPTPS 2002 Cambridge, MA, USA, March 7-8, [6] B. Y. Zhao, L. Huang, J. Stribling, S. C. Rhea, A. D. Joseph, and J. D. Kubiatowicz. Tapestry: A resilient global-scale overlay for service deployment. IEEE Journal on Selected Areas in Communications,22(1):41 53,2004. [7] A. Gupta, B. Liskov, and R. Rodrigues. Efficient routing for peer-to-peer overlays. In Proc. First Symposium on Networked Systems Design and Implementation (NSDI 04), March [8] J. Li, J. Stribling, R. Morris, M. F. Kaashoek, and T. M. Gil. A performance vs. cost framework for evaluating dht design tradeoffs under churn. In

7 122 4 th International Conference Information & Communication Technology and System Proceedings of the 24th INFOCOM, Miami, FL, March,2005. [9] K. Gummadi, R. Gummadi, S. Gribble, S. Ratnasamy, S. Shenker, and I. Stoica. The impact of dht routing geometry on resilience and proximity. In SIGCOMM 03: Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications, pages , New York, NY, USA, ACM Press. [10] F. Dabek, A Distributed Hash Table. Ph.D. thesis, Massachusetts Institute of Technology