Use of SCTP for IP Handover Support Dong Phil Kim, Jong Shik Ha, Sang Tae Kim, Seok Joo Koh Department of Computer Science Kyungpook National University {dpkim, mugal1, sainpaul1978}@cs.knu.ac.kr Abstract This paper describes the experimental analysis of SCTP handover for the dual-homing and singlehoming mobile terminals based on Linux platform. From the experiments, it is shown that the SCTP handover latency of the dual-homing mobile terminal only depends on the Round Trip Time between two SCTP endpoints, possibly with a negligible latency time. On the other hand delay of the underlying link and network layer. 1. Introduction Stream Control Transmission Protocol (SCTP) is the new transport-layer protocol that is featured by multi-streaming and multi-homing [1]. In particular, the multi-homing feature of SCTP can be used to provide the handover capability for the mobile terminals (MT) by adding a new IP address and deleting the old IP address during the association [2]. Some related studies recently made [3, 4] include the performance analysis of the SCTP handover by using the Network Simulator (ns-2) [5]. In the study, the handover performance of the SCTP was analyzed for test scenarios using the signal strengths of the underlying wireless link layer. In this paper, we perform the analysis of the SCTP handover for the mobile terminal (MT) over Linux platforms. In particular, this paper is mainly purposed to compare the handover latency of the MT for the single-homing and dual-homing cases. First, we briefly describe the procedures of SCTP handover and the use of Application Programming Interfaces (API) for SCTP handover. Then, we perform the experimental analysis of the SCTP handover for the dual-homing and single-homing MT over Linux testbed networks. 2. APIs for SCTP Handover Figure 1 shows the sketch of the SCTP handover between two different IP network regions, where the MT is moving from Base Station (BS) A to B. Figure 1. SCTP Handover In the figure, we assume that an MT initiates an SCTP association with a Fixed Server (FS). For the SCTP association, FS has IP address 1, whereas MT uses IP address 2. Then, the overall SCTP handover procedures could be performed as follows: (1) Adding a new IP address to SCTP association When the MT is moving toward B, it is now in the overlapping region. In this phase, the MT obtains a new address IP address 3 from the BS B by using an address configuration scheme such as Dynamic Host Configuration Protocol (DHCP). After obtaining a new IP address, the MT informs FS that it will use a new IP address. This will be done by sending SCTP ASCONF chunk to FS. The MT may receive the responding ASCONF-ACK chunk from the FS. The MT is now in the dual homing state. (2) Changing the primary IP address While the MT continues to move toward BS B, it will set the new IP address as the primary address. Once the primary address is changed, the FS sends the outgoing data packets over the new primary IP address of MT.
(3) Deleting the old IP address from SCTP association As the MT progresses to move toward B, it will delete the old IP address from the association. The procedural steps described above will be repeated each time the MT moves to a new BS. On the other hand, the following SCTP Application Programming Interfaces (APIs) are used for the handover operations over Linux Platforms [6, 7]. 1 sctp_bindx(add) : adding the new IP address to SCTP association (Add-IP) 2 sctp_bindx(remove) : deleting the old IP address from SCTP association (Delete-IP) 3 setsockopt(primary_peer_addr) : changing the primary IP address (Primary- Change) Figure 2 illustrates the use of SCTP APIs over Linux platforms in order to implement the SCTP handover procedures. 3. Experimental Analysis of SCTP Handover This section describes the experimental analysis of SCTP based on Linux platforms. 3.1 Test Environment To perform the experimentation of the SCTP handover, a small test network is constructed, which consist of one router and two hosts (FS and MT). Each host support Linux Kernel 2.6.8 together with LK- SCTP tool [7]. The MT is equipped with two different Network Interface Cards (NICs) to support the SCTP dual-homing feature. We have experimented the following two test scenarios, as also shown in Figure 3. Scenario A: dual-homing MT (Fig. 3(a)) The dial-homing MT uses two different NICs in the overlapping region. That is, the MT can transmit and receive the data packets by using the two interfaces at the same time. This dual-homing MT can be applied to the vertical handover in heterogeneous networks, as seen in the handover between 3G and WLAN. Scenario B: single-homing MT (Fig. 3(b)) Figure 2. APIs for SCTP Handover As shown in the figure, when the MT moves to the new region, the Link-up signal will be detected, and a new IP address is allocated at the IP layer. When SCTP performs the Add-IP operation by calling the sctp_bindx(add) function, an ASCONF chunk will be delivered to FS, and the FS then replies with an ASCONF-ACK chunk to the MT. When the signal strength of the new link is increased, the MT performs the Primary-Change operation by calling the setsockopt() function. If the old link is down, the old IP address will be deleted from the association by calling the sctp_bindx(remove) function. The single-homing MT activates only a single NIC at a time. That is, the MT performs data transport in the single-homing state. This scenario could be applied to the horizontal handover within homogenous networks. In this case, the Link-Up of a new link and Link-Down of the old link will occur at the same time at the underlying link and network layers. Figure 3. Two Scenarios for SCTP Handovoer
Figure 4. Results of SCTP Handover for single-homing MT In the experiments, an FS has the IP address 192.168.0.100, whereas an MT uses two IP addresses: 192.168.0.200 and 192.168.0.201. In Fig. 3(a), the dual-homing MT activates the two NICs the same time in the overlapping region. On the other hand, the single-homing MT uses a single NIC at a time in Fig. 3(b). For those two handover scenarios, we commonly applied the following procedures: 1) First, the MT with IP address 192.168.0.200 connects to the FS with 192.168.0.100. 2) The MT adds a new IP address 192.168.0.201 to the association using scto_bindx(). 3) The MT requests Primary-Change to the FS using setsockopt(). 4) The MT deletes the old IP address 192.168.0.200 from the association using sctp_bindx(). 5) When the data transport is completed, the MT shotdown the sctp_bindx(). In the experiment, FS transmits data packets of 1,000 bytes to the MT periodically, and the MT also send a few data to the FS. By using the etheral [8], we captured the trace of the packets that have been exchanged between FS and MT. From the packet trace, we measured the handover latency as a performance metric of SCTP [3, 4]. More specially, the handover latency is defined as the gap between the time that the MT has received the last DATA chunk over the old IP address, and the time that the MT has received the first DATA chunk over the new IP address. 3.2 Results and Discussion Figure 4 shows the results of SCTP handover for the dual-homing MT. Form the figure, we see that the FS (192.168.0.100) and MT (192.168.0.200) establish an SCTP association through the 1 st 4 th packets. At packet 10, the MT sends an ASCONF chunk to the FS in order to add the new IP address 192.168.0.201. The MT responds with an ASCONF-ACK to the MT at Packet 11. Then, the MT sends ASOCNF for Primary- Change to the FS at Packet 15, and the FS replies with
Figure 5. Results of SCTP Handover for Single-homing MT ASCONF-ACK to the MT at Packet 19. It is noted that the FS transmits all DATA packets to the new IP address of MT, after the primary IP address is changed. When the existing link is down, the MT sends ASCONF chunk for Delete-IP to delete the old IP address 192.168.0.200 at Packet 28. The FS then replies with ASCONF-ACK to MT at Packet 29. From the results, we note that even after Primary- Change, the MT still uses its old IP address as the source IP address of the DATA packets (see Packets 21, 22 and 24). This is because the Primary-Change operations is only applied to the FS, rather than MT. That is, the source IP address of DATA packets transmitted by MT is not affected by the Primary- Change operation. After the Delete-IP operation, the MT uses the new IP address as its source IP address (Packets 30 and 32). The handover latency for the dual-homing MT is measured as the time gap between Packet 16 and 20, 0.07439 0.07398 = 0.00041 (second) = 0.41 (ms). It is noted that this handover latency is roughly equal to the Round Trip Time (RTT) between MT and FS for exchanging the ASCONF and ASCONF-ACK chunks for Primary-Change (Packets 15 and 19), 0.074321 0.073841 = 0.00048 = 0.48 (ms). The kernel processing time at FS for handling the associated control chunks can be negligible, compared to the RTT. Accordingly, we see that the overall SCTP handover latency depends on the RTT for Primary-Change between two SCTP endpoints in the network. Figure 5 shows the results of SCTP handover for the single-homing MT. Figure 5 shows almost the same result as Figure 4, except the following differences: a) After the Add-IP operation (Packet 13), the MT uses the new IP address (192.168.0.201) as its source IP address of all the DATA packets. This is because the Link-Down of the old link occurs at the same time with the Add-IP operation in the singlehoming test scenario. b) From the figure, the SCTP handover latency is measured as the time gap between Packet 10 and 21, 2.780 0.023 = 2.757 (second), which is extremely larger than that of the dual-homing MT. In fact, this handover latency approximately corresponds to the time taken for processing Link- Down (old link) and Link-Up (new link) at MT (note that these events occur at Packet 11 and 12 in this experiment). Accordingly, we see that the handover latency for the single-homing MT is
severely affected by the processing time of the linkdown and link-up at the underlying layers. Another interesting point from Figure 5 is that the FS cannot send any DATA packets to MT over the new IP address until the Primary0Change is completed (Packet 19), since the old IP address is not available by Link- Down event at Packet 12. Accordingly, it is concluded that the single-homing MT had better perform the Primary-Change operation just after the Add-IP operation (hopefully at the same time). This will be helpful to reduce the handover latency of SCTP. On the other hand, figure shows the result of SCTP handover with much more data packet for the dualhoming and single-homing MTs. In the experiment, we measured the amount of packets exchanged between MT and FS for each handover scenario. 4. Conclusions In this paper, we have described that experimental analysis of SCTP handover for the dual-homing and single-homing MTs over Linux platform. From the result, we can see that the handover latency of the dual-homing MT depends on the RTT between two SCTP endpoints, possibly with a negligible latency time. On the other hand, the handover latency of the single-homing MT may be severely affected by the processing time of the underlying link and network layer. 5. References [1] Stewart, R., et al., Stream Control Transmission Protocol, IETF RFC 2960, October 2000 [2] Stewart, R., et al., Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration, IETF Internet Draft, draft-ietf-tsvwg-addip-sctp-10.txt, February 2005 [3] Chang, M., et al., Transport Layer Mobility Support Utilizing Link Signal Strength Information, IEICE Transactions on Communications, Vol. E87-B, No.9, pp. 2548-2556, September 2004. [4] Koh, S., et al., "msctp for Soft Handover in Transport Layer", IEEE Communications Letters, Vol. 8, No. 3, pp. 189-191, March 2004. Figure 6. Results of SCTP Handover From the figure, we see that the handover latency of the dual-homing MT is negligible, compared to that of the single-homing MT (0.3 ~ 1.9 second). We also note that the dual-homing MT has completed all the data transmissions (at 3.3 second) earlier than the single-homing MT. This is because the single-homing MT requires larger handover latency due to the processing of link-down and link-up at the underlying layers, compared to the dual-homing MT. [5] Network Simulator 2, Available from http://www.isi.edu/nsnam/ns [6] Stewart, R., et al., Sockets API Extensions for Stream Control Transmission Protocol, IETF Internet Draft, draft ietf-tsvwg sctpsocket-09.txt, September 2004. [7] Linux Kernel SCTP Project, Available from http://lksctp.sourcforge.net/ [8] Ethereal, Available from http:// www.ethereal.com.