OpenFlow-based Routing Mechanism for Call Session State Migration in the IMS

-based Routing Mechanism for Call Session State Migration in the IMS MANABU ITO, SATOSHI KOMORITA, YOSHINORI KITATSUJI, and HIDETOSHI YOKOTA KDDI R&D Laboratories, Inc. 2-1-15 Ohara, Fujimino-shi, Saitama, 356-8502 JAPAN {mn-itou, sa-komorita, kitaji, yokota}@kddilabs.jp Abstract: - Mobile broadband and the shift to All-IP network lead the integration of mobile network services and over-the-top (OTT) services. Increasing and unpredictable traffic caused by this trend make it important for the IMS (IP multimedia subsystem), which is the call control system, to be flexible and reliable. With that goal, the authors have focused on call migration, which allows the IMS to distribute call sessions so as to minimize the number of servers and/or restore call sessions dependent on a halted server. This paper proposes a mechanism to enable call migration without modifying the standard procedure in the IMS. The proposed mechanism maps a SIP URI (uniform resource identifier), which identifies communication resources such as the user, to a flow routed by switches. When the call migrates, this mechanism changes the mapping for proper SIP message routing. This paper implements the proposal and shows that the proposal routing mechanism has insignificant impact on call session establishment unless the large number of call s are migrated. Key-Words: - IMS, SIP, Call migration, and. 1 Introduction In order to provide Voice over IP service, mobile network operators (MNOs) are developing the IMS (IP multimedia subsystem) [1], which is adopted as a call control system in GSMA [2] to ensure interconnectivity between MNOs around the world. MNOs plan to launch the RCS (rich communication suite), [3] which will enable mobile phone users to use instant messaging, live video sharing, and file transfer over the IMS. In addition, through leveraging their IMS development, MNOs are now looking into the possibility of integrating over-thetop (OTT) services (e.g., Google services, Facebook, and Skype). The support of these future services in addition to legacy services (e.g., voice and SMS (short message service)) has resulted in an increase in signaling traffic in the IMS. It is difficult to estimate the required system capacity for the increase because OTT services are created by third parties outside MNO's conscious awareness. To continue to deal with increasing and unpredictable traffic without investing in extra capacity, an enhanced flexibility is desirable in the operation of the CSCFs (call session control functions) of which the IMS is composed. Here, we define flexibility as reconfigurable functionality of CSCFs process assignments on physical servers. In case of server failure or disaster, it is also desirable to ensure reliability by continuing the processing of CSCFs on other physical servers, thus preventing service disruption. Studies [4][5] and a concept [6] have been published on the realization of flexibility and reliability by using virtualization technologies. Virtualization can flexibly assign and distribute available hardware resources to CSCFs as required. To optimize hardware resources and cope with server failure or disaster, virtual machines (VMs) can migrate among the available physical servers. However, this approach has two shortcomings: 1) it may cause service disruption, and 2) it may produce insufficient optimization in reducing the number of physical servers. Regarding 1), VM migration takes a long time when the VM treating a CSCF maintaining a large number of sessions. Although it may be a solution to have many VMs maintain a small number of sessions in a single physical server, this requires a large overhead of computational resources and makes it difficult to minimize the number of physical servers. As a result, this leads to issue 2). There is a trade-off among these issues in the VM migration approach. In order to realize more flexibility, we have focused on call migration [7][8], which allows active call sessions to continue to be processed on another CSCF. We propose a routing mechanism in the IMS for call ISBN: 978-1-61804-150-0 60

migration without extensions to the standard procedure for control of a call/service session. Our routing mechanism is realized by utilizing [9], which provides an open standard protocol to program flow tables (that run at line-rate to implement firewalls, NAT, QoS, and to collect statistics) in different switches and routers [10]. Furthermore, we implement our proposal on real systems and verify its behavior and impact of call migration. The rest of this paper is organized as follows. Section 2 describes the IMS architecture and the requirements of call migration. Section 3 proposes our -based routing mechanism in the IMS. Section 4 shows how much this mechanism affects the call session establishment. Finally, Section 5 concludes the paper. Other MNO IMS Mobile Network Operator (MNO) IMS Originating Terminating IBCF (SBC) SBC I-CSCF2 SBC UE2 UE: User Equipment SBC: Session Border Controller P-CSCF: Proxy Call Function S-CSCF: Serving Call Function I-CSCF: Interrogating Call Function IBCF: interconnection border control function : Home Subscriber Server Fig. 1 Basic IMS Architecture 2 Call Session State Migration 2.1 IMS Architecture and Call Session Control Figure 1 shows basic IMS architecture. The IMS is composed of CSCFs that control call/service sessions for UE (user equipment), an (home subscriber server) that is a database server for managing subscriber information, an IBCF (interconnection border control function) that is an entry/exit point for other IMSs, and SBCs (session border controllers) that provide a variety of functions for security and connectivity (e.g., access control, topology hiding, NAT traversal, protocol interworking, and media monitoring). These functions of the SBC are often integrated into the P- CSCF (described later) and the IBCF. There are three types of CSCF: an S-CSCF (Serving CSCF) that is the representative SIP server primarily dealing with call/service control and management, a P-CSCF (Proxy CSCF) that communicates with UE directly and establishes a secure connection to it, and an I-CSCF (Interrogating CSCF) that routes signaling messages to the S-CSCF managing the terminating UE. In the IMS, SIP (session initiation protocol) [11] is used for call control between the CSCFs and UE. First, a UE registers with the IMS before obtaining IMS services. The UE conducts its registration with the S-CSCF via the P-CSCF and the I-CSCF. The S- CSCF assigned by the I-CSCF verifies the UE based on its authentication information stored in the. After that, the UE uses IMS services by sending and receiving SIP messages to and from a correspondent UE via the P-CSCF, S-CSCF, and I-CSCF. For example, when the UE makes a call, the UE sends an message to the correspondent UE and establishes an active session to communicate the required information. The exchanged SIP messages take, as shown in Fig. 1, the following path: (caller),,,, I-CSCF2,,, and UE2 (callee). Note that the messages need not be forwarded through the I- CSCF () within the originating network. Basically, if the originating network operator desires to keep its configuration hidden, it forwards the messages through to an entry point (I- CSCF2) in the terminating network. Once CSCFs begin to handle the active session in making through terminating a call of UE, it is not changed for the CSCFs to process the session because the CSCFs have the states regarding the session. However, to cope with server failure and dynamically change the number of physical servers to match the network and resource usage situation, it is desirable that the call can migrate to another CSCF and continue to be processed (hereinafter called call migration ). The migration of a call at a CSCF creates an issue. From the standpoint of the counterpart CSCF or UE, the destination IP address generally changes when a call migrates from its original CSCF to another. Even in this situation, SIP messages must be forwarded to the new CSCF to which the call is migrated. The counterpart CSCF or UE still directs SIP messages for the call session to the original CSCF. This is because the information such as IP address in SIP headers (e.g., Route header and Via Header), which is the basis of SIP message routing, cannot be changed after establishment due to the SIP specification. ISBN: 978-1-61804-150-0 61

2.2 Requirements of Call Session State Migration A key requirement for producing call migration into the IMS is a limited modification only in the IMS of a single MNO and within the standard procedures. In other words, we avoid changing, from the standards, the procedures for interoperation between the IMS and UE, and between the MNOs. Although the SBC provides the protocol for interoperation by eliminating mismatches between parameters in SIP messages, the SBC does not always deal with mismatches between the procedures. Introducing this requirement gives our proposed IMS the interoperability needed for roaming UE and the other MNOs without any changes in them. In addition, it is desirable to involving new functions in the IMS by utilizing technologies based on open standards rather than proprietary technologies, to gain interoperability, reliably implement the functions, simplify their management, and avoid being locked into one particular vendor s proprietary product [12]. 2.3 Related Work Studies dealing with call migration into the IMS have been published. In our study [7], an efficient mutual complementarity mechanism between P-CSCF and S-CSCF was proposed. This can support IMS reconfiguration with service continuity and cope with a single CSCF failure without backup servers. However, this coping mechanism may not work well in roaming case where the call of roaming UE is processed on P-CSCF and S-CSCF located on different MNOs. This is because the call session states need to be mutually transferred between the S-CSCF and P-CSCF over the proprietary protocol. Y. Liu et al. [13] have proposed a mechanism to ensure reliability by restoring the register and session information, as backed-up in a standby server. This mechanism can reduce the load on backup servers and produce a rapid restore by storing only necessary information. They focus on call migration only between S-CSCFs. In our other study [8], a restore mechanism for the entire IMS was proposed. This mechanism stores call s in backup servers with proper timing and restores the states to other CSCFs. However, in order to maintain IP connectivity and forward SIP messages to the new CSCF after call migration, it is necessary to use a specific packet forwarding mechanism that requires a proprietary tunneling technology. IP#S IP addr: IP#P Update of the label tables when the call migrates IP#I Backup/restoring call s I-CSCF2 IP#I IP#S IP#P Cache and insertion of labels SIP URI Label in MAC dst Label in MAC src @ims.com P1 S1 I1 P2 S2 I2 1 2 3 4 5 6 7 8 Label assignment and insertion into MAC addr field SIP URI Label @ims.com P1 S1 I1 UE2@ims.com P2 S2 I2 3 Proposal of -based Routing Method for Call Session Control Message 3.1 Approaches In order to maintain IP connectivity, we consider assigning the same IP address to the same type of CSCF and forwarding SIP messages by using an identifier other than the IP address on networking equipment (e.g., switch or router), not CSCFs. When the call migrates to the new CSCF, the networking equipment needs to change the destination CSCF corresponding to the identifier by modifying the forwarding-tables so that the SIP messages are forwarded to the new CSCF. Alternatively, the identifier mapping of the SIP message needs to be changed. In this way, the CSCFs need not dynamically change forwarding destinations of SIP messages in accordance with call migration. In this paper, we propose a routing method that uses, which can flexibly change the flow-tables or the mapping. A point using is that a traffic flow is granularly distinguished and, a variety of fields in a MAC header of Ethernet through a transport header of TCP or UDP can be used to identify the flow. 3.2 Proposed Architecture for Migration of Call Session Information Figure 2 shows the proposed architecture where new functions are introduced for routing SIP messages by using an switch. For the UE2 IMS Fig. 2 Proposed Architecture SIP messages routing based on flow identification Matching Fields Action MAC dst IP dst P1 S1 I1 IP#P Out port1 P1 S1 I1 IP#S Out port2 P1 S1 I1 IP#I Out port3 P2 S2 I2 IP#S Out port5 ISBN: 978-1-61804-150-0 62

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 01234567890 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 Not used P-CSCF ID I-CSCF ID S-CSCF ID Fig. 3 Field assignments of P/I/S-CSCF IDs in MAC address field switch to be able to identify the SIP messages as the flows, the SBC is extended ( in Fig.2). When the receives a SIP message from a UE, it retrieves the SIP URIs of the UE included From/To headers and inserts the labels corresponding to the SIP URIs in specific fields recognized at the switch. The labels represent the combination of P/I/S-CSCFs admitting the UE. In our proposal, the labels are inserted in the MAC address fields because the original values (the MAC address) in the fields are not used as identifiers of the flows at the switch and the field has an ample length. Here, labels corresponding to the originating and terminating SIP URI are inserted in the destination and source MAC address fields. The switch forwards the SIP messages by identifying the flows with the label in the destination MAC address field and the destination IP address. In order to maintain the labels in the MAC address field when CSCFs send or receive the SIP messages, an Interface module (hereinafter called ) is newly introduced in CSCFs. This module caches the labels in destination and source MAC address fields when the CSCFs receive the SIP message. Next, it inserts the same labels into MAC address fields when the CSCFs send SIP messages. A session controller has a copy of the call s on CSCFs and restores the states to the other CSCF when that CSCF halts. When the call migrates, the session controller updates the label table in the and CSCFs by using the protocol. The following subsections describe the label assignment solution and the detailed call flow of registration, call session establishment, and the call migration. 3.3 Label Assignment Solution As described in the previous subsection, the label represents the combination of P/I/S-CSCF, as shown in Fig. 3. In this solution, the mapping information base in the and the switch become O(S P S I S S ) in size, where S P, S I and S S denote the number of P/I/S-CSCFs. For instance, the mapping information base in the is one million where there are 100 individual CSCFs. Our solution also specifies the field assignment of MAC addresses to distinguish the P/I/S-CSCFs. The individual CSCFs have IDs that are 13 bits or less long. The most 4. REGISTER 5. Assign label and insert it into MAC addr field 7. REGISTER 8. REGISTER 9. REGISTER 16. 401 17. Remove the label 18. 401 19. REGISTER 20. REGISTER 21. REGISTER 22. REGISTER 2. Send the flow entries 3. Send the label table 6. Notify the map of assigned label and SIP URI 11. REGISTER 13. 401 14. 401 15. 401 24. REGISTER 26. 200 OK 27. 200 OK 29. 200 OK 28. 200 OK 30. 200 OK 10. UAR/UAA 23. UAR/UAA Fig.4 Registration Flow 12. MAR/MAA 25. SAR/SAA 1. Generate a flow entries and labels Store call significant nine bits are not used, to retain bits 6 and 7 for the global unique/local administrator and unicast/multicast flags defined by IEEE 802.3, respectively. An alternative label assignment solution could be for each SIP URI to have a label. However, this increases the number of labels when the CSCFs already have a large number of UEs. With this solution, the required mapping information base becomes O(N) in size, where N denotes the number of SIP URIs. E.g., if each CFCS can admit the same number of UEs and more than SIP URIs, our label assignment solutions have a smaller mapping information base than the naive (latter) solution. (State-of-the-art CSCF products admit five hundred thousand or more UEs.) Additionally, our solution allows the switch to hardly update the flow entry even when the call sessions state migrates. (When the CSCF halts and is removed from, or a new CSCF is installed in the IMS core network, the needs to update a large number of flow entries, e.g., five hundreds thousands flow entries in the case of the aforementioned CSCF product.) 3.4 Call Flow of Registration Figure 4 shows the call flow of Registration through the switch. The system starts the initial settings. The session controller generates flow entries, composed of matching fields and their corresponding actions, and labels which represent ISBN: 978-1-61804-150-0 63

1. 2. Insert the labels 3. 4. 5. 6. 8. 7. Reverse labels in dst/src MAC addr field UE2 Remove labels I-CSCF2 UE2 16. 200 OK 13. 14. Remove the labels 15. 10. 11. 12. 17. 200 OK 18. 200 OK 19. 200 OK 20. 200 OK I-CSCF2 9. LIR/LIA 183 / PRACK / 200 OK / UPDATE / 200 OK / 180 / PRACK 200 OK Insert labels 200 OK 200 OK 200 OK 200 OK Server failure or burden Store call 1. Determine the call migration from P- CSCF2 to 2. Restore the call 3. update the labels Store call 21. Reverse labels in dst/src MAC addr field 22. 200 OK 23. 200 OK Store call Insert labels 26. 200 OK 27. 200 OK 24. 200 OK 25. 200 OK ACK Fig.6 Call Session State Migration from to PCSCF1 Fig.5 Call Session Establishment Flow the combinations of P/I/S-CSCFs admitting the UE (step 1). The session controller adds the flow entries to the flow table in the and the labels to the label table in the by using the protocol (steps 2 and 3). When a REGISTER message enters the (step 4), it first tries to retrieve the label corresponding to the SIP URI, included in the From header of the message. If there is none, the assigns a label that represents the combinations of P/I/S-CSCFs (step 5). The notifies the mapping information to the session controller (step 6). This is done only if the label is newly assigned. Here, the session controller prepares to store the new call coming later (at steps 26 and 28). The inserts the label into the destination MAC address field and sends the REGISTER message (step 7). The switch forwards the REGISTER message to P- CSCF1 admitting the by retrieving the destination IP address and the label in the destination MAC address field (step 8). The destination IP address specifies the type of CSCF server (P-CSCF), and the label specifies the CSCF ID () to which the message forwards. When receives the REGISTER message, it first caches the label to be able to supply the same label to other CSCFs. Next, when sends the REGISTER message to the I-CSCFs (step 9), it inserts the same label into the destination MAC address fields. The IP header has P-CSCF and I- CSCF as the source and destination IP addresses, respectively. In this way, the REGISTER message and the response message (401 Unauthorized) are forwarded to CSCFs through the switch. When the 401 Unauthorized message returns to, the removes the label from the message (step 17) and forwards it toward through IP routing (step 18). sends the REGISTER message again with the authentication information (step 19), which is included in the 401 Unauthorized message, and the inserts the same label as at step 7 (step 20). The second REGISTER message and the response message (200 OK) are forwarded to CSCFs through the switch in a same way (steps 21-29). Finally, the removes the label from the 200 OK and forward it towards (step 30). 3.5 Call Flow of Call Session Establishment After registration, the UE establishes a call session in Fig. 5. In this figure, makes a call to UE2. First, sends an message to UE2 (step 1). The SBC inserts two labels corresponding to the originating () and terminating (UE2) SIP URIs, which are retrieved from the From and To headers, to the destination and source MAC address fields, respectively (step 2). Note that the label ISBN: 978-1-61804-150-0 64

IMS S-CSCF4 S-CSCF3 P-CSCF4 P-CSCF3 Table 1 Experimental Network Components Node P-CSCF, I-CSCF, S-CSCF,, UE Simulator Spec Hardware CPU Memory OS EPSON Core2Duo E8600 4 Endeavor 3.33GHz GByte AT970 Generic PC Generic PC Xeon E5450 3GHz Core2Duo E8400 3GHz 12 GByte 8 GByte Ubuntu 10.04 LTS NEC UNIVERGE PF5240 ( Ver.1.0.0) UE Simulator Fig.7 Experimental Network Configuration represents a combination of the P/I/S-CSCF admitting the UEs. When the message is processed by the originating CSCFs (steps 3-6), the label corresponding to the caller s SIP URI should be referred by the switch, but when the message is processed by the callee-side CSCF servers (steps 8-13), the label corresponding the callee s SIP URI is referred instead. For this purpose, the in Fig. 4 reverses the labels in the destination/source MAC address field (step 7). In the response message (steps 16-27), I-CSCF2 reverses the labels in the same manner as the request messages when the messages are forwarded from terminating-side to originating-side (step 21). The call is stored in the response with proper timing [8]. After sending ACK, they can communicate with each other like a VoIP. 3.6 Procedure of Call Session State Migration Call migration is triggered when availability monitoring detects a CSCF failure or burden. Figure 6 shows the procedures by which the call s on migrate to. The migration takes the following steps: 1. The session controller chooses the available CSCF (e.g., ) to which the call s are restored. 2. restores the call s from the provided data. 3. The session controller notifies the new labels corresponding the restored session s SIP URIs to and the. After the migration, the message (e.g., 200 OK) related to the call is forwarded by the insertion of the new labels on. The message (e.g., ) from UE is on the. There are various monitoring methods to monitor the availability of CSCFs, including periodic workload querying, network availability check, and monitoring error and/or warning logs. The workload and/or number of admitted sessions of each CSCF can be used in choosing the available CSCF. This depends on what is monitored at the session controller according to network operator policy. 4 Implementation and Evaluation 4.1 Experimental Configuration Figure 7 shows our experimental network configuration for verifying the behavior of the proposal on real system. In the IMS network, CSCFs and an are connected via an switch. A UE simulator connects to the IMS through the. A session controller connects to the CSCFs, switch, and via a switch. An also connects to the CSCFs via the switch. Table 1 shows the network components. The P/I/S-CSCFs and were built based on the Open IMS core [14], which is an open-source SIP server. We implemented the required modules of the CSCFs for our proposed mechanism and the required software for the session controller and. We simulated a large UE load by using SIPp [15], which is also open-source load testing software for the SIP. 4.2 Measurement method We verified how much the routing mechanism based on labels and call migration affect call session establishment. Multiple UEs randomly registered with four S-CSCFs through four P-CSCFs, and The UEs made a given number of call initiations per second. In the first experiment, we increased a call initiation rate and measured the CPU usage of the and CSCFs. In the second experiment, we increased the number of call session states which migrated from a P-CSCF () and measured the time for updating the labels at. After call session establishment, we performed call migration by halting P- ISBN: 978-1-61804-150-0 65

The Avg. of CPU Usage [%] 100 80 60 40 20 0 PCSCF1 0 100 200 300 400 Call Initiation Rate [/s] Fig.8 Average of CPU Usage at Call Session Establishment CSCF1. Regarding the call migration strategy, all the sessions in the halted were randomly distributed over the remaining (three) P-CSCFs. 4.3 Results and Discussion Figure 8 shows the one-second average of CPU usage while increasing the call initiation rate. Note that the CPU usage of P-CSCFs was higher than the other types of CSCF and four P-CSCFs were similar in behavior. The CPU usage of (solid line) was lower than (dotted line). This indicates that introducing does not become a bottleneck at the call session establishment. Figure 9 shows the amount of time for updating the label table caused by call migration. This indicates that call migration gives some influence on the call session establishment when the large number of call s migrates. SIP messages sent from the UE before this update of label table are forwarded to the old CSCFs, which the call s migrate from. This results in retransmissions of SIP messages and the call session establishment time will increase. In the above experiments, we verified the behavior and showed the effect of call migration. When the large number of states migrates caused by server failure, the takes a long time to update of the bulk labels. It is necessary to distribute the processing across multiple s to prevent the from becoming a bottleneck. In the case of multiple s deployment, all s are required to synchronize the labels. To do this without overload of the session controller or, it is considered that multicast or broadcast functions in switches, which are added to the version 1.1.0 specification, offers a solution to synchronize all s. When an receives information of new labels from the session controller, it sends the same information to an The Amount of Time [ms] 1000 800 600 400 200 0 0 1000 2000 3000 4000 5000 The number of Migrated Call Session States Fig.9 Amount of Time for Updating the Label Table in at Call Session State Migration switch. The switch clones the packets and sends them to each using the group table which is one component of flow table. 5 Conclusion We have proposed a mechanism that can dynamically change the forwarding destinations of SIP messages by using together with call migration into the IMS. This provides the IMS to involve greater flexibility and reliability without modifying the standard procedure in the IMS. By implementation and actual measurement, we showed that the proposed routing mechanism has insignificant impact on the call session establishment and how much call migration gives influence on the call session establishment. Regarding a large number of routing label updates occurred at an, we also discussed how to distribute a large amount of its processing workload among mufltiple SBCs, and indicated that it is doable. Acknowledgment: - This work has been supported by the Japanese Ministry of Internal Affairs and Communications funded project, High-Reliability Cloud Services Control Platform Technologies. References: [1] 3GPP TS 24.229 V9.13.0, IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3, 2012. [2] Global System for Mobile communications Association: www.gsma.com [3] GSMA, Rich Communication Suite 5.1 Advanced Communications Services and Clients specification, 2012 ISBN: 978-1-61804-150-0 66

[4] M. Fakhfakh, O. Cherkaoui, I.L. Bedhiaf, and M. Frikha, High availability in IMS virtualized network, First International Conference on Communications and Networking, 2009, pp.1-6. [5] B.L. Asma, H. Amel, J. Maha, and T. Sami, State of the Art and Research Challenges of new services architecture technologies: Virtualization, SOA and Cloud Computing, International Journal of Grid and Distributed Computing, Vol.3, No.4, 2010, pp. 69-88. [6] Nokia Siemens Networks, Virtualization achieves extreme flexibility and efficiency in open core networks, Open Core System White Paper, 2012. [7] S. Komorita, H. Yokota, C. Makaya, S. Das, D. Chee, F.J. Lin, A. Dutta, and H. Schulzrinne, User-transparent reconfiguration method for self-organizing IP multimedia subsystem, IEEE Symposium on Computers and Communications, 2011, pp. 1137-1144. [8] T. Usui, N. Nishinaga, Y. Kitatsuji, and H. Yokota, Restoring CSCF by Leveraging Feature of Retransmission Mechanism in Session Initiation Protocol, The Third International Conference on Emerging Network Intelligence, 2011, pp. 50-56. [9] Specification Version 1.1.0 Implemented, 2011. [Online]. Available at: http://www.openflow.org/documents/openflowspec-v1.1.0.pdf [10] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, : Enabling Innovation in Campus Networks, ACM SIGCOMM Computer Communication Review, vol.38, No.2, 2008, pp. 69-74. [11] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson,, R. Sparks, M. Handley, and E. Schooler, SIP: Session Initiation Protocol, Internet Engineering Task Force, RFC 3261, 2002. [12] C.J. Sher Decusatis, A. Carranza, C.M. Decusatis, Communication within clouds: open standards and proprietary protocols for data center networking, IEEE Communications Magazine, Vol.50, No.9, 2012, pp. 26-33. [13] Y. Liu, Y.H. Liu, X. Wang, Reliability Mechanism for the Core Control Network- Element S-CSCF in IMS, International Conference on Network Computing and Information Security, vol.1, 2011, pp. 57-61. [14] The Open Source IMS Core Project, [online]. Available at: http://www.openimscore.org/ [15] SIPp, [online]. Available at: http://sipp.sourceforge.net/ ISBN: 978-1-61804-150-0 67