Internet Draft Seok Joo Koh Internet Engineering Task Force Hee Young Jung Category: Informational Sung Han Kim February 2003 Jun Seob Lee Expires August 2003 ETRI Use of SCTP for Seamless Handover Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as a "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Stream Control Transmission Protocol (SCTP) is a new reliable transport protocol that provides the multihoming feature. Without support of routers in the networks, the SCTP with the ADDIP extension (called mobile SCTP) can be used to provide seamless handover for the mobile host that is changing its IP subnetworks during the session. In the present form, the use of mobile SCTP is targeted for handover of the mobile sessions that are originated from the mobile clients (located in mobile networks) toward the fixed servers (located in the fixed networks). The support for the opposite directional session (initiated by fixed node to mobile node) requires an additional location management scheme such as Mobile IP. In this document, we discuss the generic procedures for seamless handover of mobile SCTP and the concerned implementation issues. sjkoh, et al Expires August 2003 [Page 1] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 1. Introduction SCTP (Stream Control Transmission Protocol), as defined in RFC 2960 [1, 2, 3], is a reliable transport layer protocol. The SCTP is featured multi-streaming and multihoming, differently from TCP. It is noted that the multihoming feature of SCTP enables the SCTP to support the IP mobility. More specifically, the SCTP with the ADDIP extension [4], which is called mobile SCTP (mSCTP) in this document, can be used to provide seamless handover for mobile hosts that are moving into different IP network regions during the active session [5, 6]. The mobile SCTP may be used as an alternative scheme against the handover schemes based on Mobile IP [7, 8, 9, 10]. Differently from the Mobile IP based handover schemes, which rely on the support of network routers for tunneling between access routers, the mobile SCTP provides the handover management at the transport layer without help of routers. The mobile SCTP, in the present form, is targeted for the client- server service model, in which the mobile client initiates an SCTP session with the fixed server. To be applicable for the peer-to- peer model, in which a fixed node is allowed to initiate an SCTP session with a mobile node, the mSCTP must be used along with an additional location management scheme such as Mobile IP, which is discussed in [11]. This document is intended to continue a discussion to explore the use of SCTP for IP mobility support. Please send comments to the mailing list . To subscribe to this mailing list, please send a mail to . 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1.2 Acknowledgement The authors would like to give special thanks to the following people in ETRI for their valuable comments: Jae Hong Min Jung Soo Park Juyoung Park Mee Jung Lee sjkoh, et al Expires August 2003 [Page 2] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 2. Use of Mobile SCTP for IP Mobility Support In this section, we discuss motivations on the use of SCTP for IP mobility support, in the viewpoint of IP mobility management issues and SCTP multihoming feature. 2.1 IP Mobility Management Issues At the time of the fixed-mobile convergence trends, the IP mobility management issues have been focused and are regarded as a core technology required for providing seamless mobility in the wireless mobile networks such as WLAN, 3G Cellular. IP mobility management issues can be classified into Location Management and Handover Management as follows: a. Location Management Location Management is used to identify the current location of mobile nodes and also to keep track of the their location changes as they move on. In Mobile IP [7, 8], the mobility agents such as Home Agent (HA) and Foreign Agent (only for IPv4) are employed for location management as well as data transport. In the schemes, Home Address (HoA) and Care-of Address (CoA) are used for a terminal identifier and a location identifier of the IP host, respectively. For location management, the Mobile IP uses the binding update messages, in which a mobile node has to inform its current location (CoA) to its HA. b. Handover Management The handover management is targeted to provide the mobile hosts for seamless handover whenever they change their point of attachment to IP networks (as represented by cell regions or IP subnets). The main objective of the handover management is to minimize the service disruption due to data loss and/or handover latency during handover. In Mobile IP, the Low Latency handover for MIPv4 (LMIPv4) [9] and Fast Handover for MIPv6 (FMIPv6) [10] schemes have been designed for handover management. These schemes rely on the tunneling between old and new access routers for seamless handover. The mobile SCTP can be used as an alternative scheme against LMIPv4 and FMIPv6 for seamless handover. Differently from the Mobile IP handover schemes that rely on the help of network routers for tunneling between access routers, the mobile SCTP provides the handover management at the transport layer without help of routers. sjkoh, et al Expires August 2003 [Page 3] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 2.2 SCTP Multihoming Feature The SCTP intrinsically provides the multihoming feature [1, 2, 3], in which a mobile node is allowed to simultaneously bind multiple IP addresses to its network interface. The recent works on the SCTP include the ADDIP extension [4]. The ADDIP extension enables the SCTP to add, delete and change the IP addresses during active SCTP association. In this document, the SCTP implementation with the ADDIP extension is called the mobile SCTP (mSCTP) [5]. The mSCTP can be used for seamless handover while the mobile node is moving into different IP network regions over the session period. This document aims at discussing the use of mSCTP for seamless handover, which includes the specific handover procedures and associated implementation issues. 2.3 Session Type considered in Mobile SCTP Sessions considered in mobile communications can be classified into the following two types: a. Session originated from mobile host toward fixed host b. Session originated from fixed host toward mobile host The mobile sessions in (a) seem to be a natural extension of the client-server model, in which the mobile host originating the session can be viewed as a client, while the counter endpoint will function as a server. On the other hand, the case (b) requires the additional location management functionality for the session originator to find the current location of the mobile host and to keep track of the location changes, which has so far been addressed by Mobile IP [7, 8]. The mobile SCTP, in the present form, is targeted for seamless handover of mobile session associated with the case (a). To support the session type of the case (b), the mSCTP must be used along with an additional location management scheme such as Mobile IP, which is discussed in [11]. sjkoh, et al Expires August 2003 [Page 4] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 3. Generic Procedures for Seamless Handover The mobile SCTP (mSCTP) can be used to provide seamless handover for mobile client who is roaming between two different IP networks characterized by different IP address prefixes. In this section, we describe the generic algorithm of mobile SCTP for handover in the procedural manner, which is designed based on the scheme in [5]. More specifically, we consider a mobile client (MC) that initiates an SCTP association with a fixed server (FS), and then moves from Location A (2.2.2.x domain) to Location B (3.3.3.x domain), as shown in Figure 1. Figure 1 illustrates an example of the use of mobile SCTP for seamless handover in IPv4 networks. Based on this figure, the handover procedures are described in the succeeding sections. [1.1.1.2] +----+ | FS | +----+ || ########## # Router # [1.1.1.1] ########## || ******* *** *** ** ** ** Internet ** ** ** ** ** *** *** || ******** || || || ####### ####### [2.2.2.1] # AR1 # # AR2 # [3.3.3.1] ####### ####### | | Location A | | Location B | | +----+ +----+ | MC |=========>| MC | +----+ +----+ [2.2.2.2] [3.3.3.2] Figure 1. Example of Mobile SCTP for Seamless Handover sjkoh, et al Expires August 2003 [Page 5] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 3.1 Session Initiation by Mobile Client We assume that the MC initiates an SCTP association with the FS. The resulting SCTP association has the set of IP addresses with [2.2.2.2] for MC and [1.1.1.2] for FS. It is also assumed that the MC can get an IP address ([2.2.2.2]) with help of a suitable address configuration mechanism such as DHCP or stateless address auto-configuration (in IPv6). Note that the FS is in the single homing with [1.1.1.2], which will be discussed later more in details. The MC is also in single homing state, in which the IP address [2.2.2.2] is set to its primary IP address in the SCTP initiation process. 3.2 Obtaining an IP address for a new location Let us assume that the MC moves from Location A to Location B. In this phase, we also need to assume that the MC can obtain a new IP address belonging to the Location B, which may be possible with help of the DHCP or IPv6 address auto-configuration capability in the Location B. Obtaining a new IP address may also rely on the support of the wireless signaling control at the physical layer, in order for the MC to get the IP address information via IP control packets from the Location B. By SCTP implementations, the newly obtained IP address ([3.3.3.2] in the example) MUST be signaled or informed to the SCTP protocol stack, and then the SCTP will bind the new IP address to the existing IP address list managed by the SCTP association. 3.3 Adding the new IP address to the SCTP association After obtaining a new IP address, the SCTP of MC MUST inform the Fixed Server about the new IP address by sending Address Configuration Change (ASCONF) Chunk to the FS. The MC may receive the corresponding ASCONF-ACK Chunk from the FS. The MC is now in the dual homing state. The old IP address is still used as the primary address ([2.2.2.2] in the example), while the new IP address ([3.3.3.2] in the example) will be used as the backup path against the data losses by the SCTP in the FS side. 3.4 Changing the Primary IP address While the MC continues to move toward the Location B, it needs to change its primary IP address to the new IP address according at an appropriate rule. Actually, the configuration of a specific rule for changing the primary IP address is a challenging issue of the mobile SCTP. sjkoh, et al Expires August 2003 [Page 6] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 Some of the possible rules for triggering the primary IP address change are listed below: a. As soon as a new IP address is detected When a new IP address is detected, the MC may trigger the primary IP address change by sending the ASCONF Chunk containing the parameter. This choice may be preferred in terms of the handover latency, in particular, for the fast-moving MC. However, it is less suitable when the MC shows a so-called oscillation (or ping-pong) behavior across those two locations. b. By using a threshold of the data losses experienced This rule is applied when the SCTP of MC has a pre- configured threshold on data loss. If the number or rate of the lost data chunks is greater than the threshold value, and if the MC is in the multi-homing state, then it can trigger the primary address change toward the FS. The selection of an appropriate threshold value is for further study, and may depend on implementations and the mobility behavior considered. c. By using an explicit indication from the underlying layer (e.g., by comparison of strength of the detected wireless signals) If the underlying physical layer can detect and compare the signal strength of the physical media, and also inform the SCTP about a certain indication (possibly by using a up- call), then the MC may trigger the primary address change according to the indication. This rule is a more preferred choice, but seems to depend on the wireless system concerned and its implementations. If once the primary address is changed, the FS will send the upcoming data over the new primary IP address, while the backup (old) address may be used to recover the lost data chunks. 3.5 Deleting the old IP address from the SCTP association As the MC progresses to move toward the Location B, if the old IP address gets inactive, the MC MUST delete the IP address from the address list. sjkoh, et al Expires August 2003 [Page 7] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 The rule for determining that the IP address is inactive may also be implemented by using additional information from the underlying network or physical layer, as done in the previous step (for changing the primary address.) 3.6 Repeating the handover procedures The procedural steps for seamless handover described above, from 3.1 through 3.5, will be repeated whenever the MC moves to a new location, until the SCTP association will be released. 4. Implementation Issues on Mobile SCTP 4.1 Requirement for Mobile SCTP The only requirement for providing the seamless handover based on SCTP is that the MC and FS hosts are equipped with the Mobile SCTP implementations, (i.e., SCTP with ADDIP extension.) All the others issues described below depend on implementations. 4.2 Number of IP addresses used by Fixed Server In this document, we assume that the FS is in the single homing. As an alternative, the FS may assign two or more IP addresses to the network interface, so as to enable easy distinction of the two links at the MC. This allows SCTP to represent different links by different entries in the host routing table of the MC. For more information on this issue, please refer to [mSCTP] and [SCTP-Multi]. 4.3 Dynamic IP address configuration The basic assumption for seamless handover to a new IP subnet region is that the MC is able to obtain a new IP address from the new location. Typically, this will be implemented by using DHCP in IPv4 networks and DHCPv6 or Stateless address auto-configuration in IPv6 networks. The handover latency incurred for obtaining the new IP address via DHCP or IPv6 needs to be examined by experiments. The concerned handover latency also includes the delay required for the handover delay between the wireless links. 4.4 AAA Functionality It is envisioned that the deployment of mSCTP will be done along with the appropriate AAA server in the respective access network domains. The AAA server is used to authenticate and the MC in the locations, and also to authorize the new IP address configuration sjkoh, et al Expires August 2003 [Page 8] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 via DHCP and IPv6 stateless configuration. However, this issue is outside the scope of mSCTP. 4.5 Link Layer Support of Multi-homing It is noted that the multi-homing capability for Mobile Client is not easy to support, which actually depends on the characteristics of the wireless links considered such as Wireless LAN (WLAN) or 3G Cellular. In a certain system such as WLAN, it may not be allowed for an MC to simultaneously bind two different Access Points (APs), in which the multi-homing is not easy to support. On the other hand, the wireless links used in Cellular systems are expected to easily support the link-level multi-homing features. The multi-homing feature enables the mSCTP to support seamless handover by simultaneous binding of two different addresses while staying the overlapping region. Time interval for an MC to stay in the overlapping region will give impact on the performance of the handover procedures. 4.6 Measuring the Wireless Signal Strength at the Physical Layer Part of seamless handover based on mSCTP depends on the support of the underlying physical and link layers to measure the wireless signal strength. The measured signal strength information can helpfully used for the SCTP to trigger the addition and deletion of IP addresses, and the change of the primary address. The handover performance will depend on such capability in terms of data loss and delay during handover. 5. Security Considerations This document discusses the use of mobile SCTP for seamless handover. The concerned security issues may be identified as the further works go on. 6. References [1] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000 [2] Ong, L. and Yoakum, J., "An Introduction to the Stream Control Transmission Protocol (SCTP)", RFC 3286, May 2002 [3] Coene, L., "Stream Control Transmission Protocol Applicability Statement", RFC 3257, April 2002 sjkoh, et al Expires August 2003 [Page 9] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 [4] Stewart, R., "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", draft-ietf-tsvwg-addip-sctp- 05, May 2002 [5] Riegel, M. and Tuexen M., "Mobile SCTP", draft-riegel-tuexen- mobile-sctp-01, August 2002 [6] Coene, L. (ed.), "Multihoming issues in the SCTP", draft-coene- sctp-multihome-03, February 2002 [7] Perkins, C. (ed.), "IP Mobility Support for IPv4", RFC 3344, August 2002 [8] Johnson, D., et al., "Mobility Support in IPv6", draft-ietf- mobileip-ipv6-20, January 2003 [9] Malki, K. L., et al., "Low Latency Handoffs in Mobile IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-04, June 2002 [10] Koodli, R., et al., "Fast Handovers for Mobile IPv6", draft- ietf-mobileip-fast-mipv6-05, September 2002 [11] Koh, S. J., Jung, H. Y., Kim, S. H. and Lee, J. S., "SCTP with Mobile IP for IP Mobility Support", draft-sjkoh-mobile-sctp- mobileip-00, February 2003 Authors' Addresses Seok Joo Koh sjkoh@etri.re.kr 361 Kajung-Dong Yusung-Gu, Taejon 305-350, Korea Hee Young Jung hyjung@etri.re.kr 361 Kajung-Dong Yusung-Gu, Taejon 305-350, Korea Sung Han Kim sh-kim@etri.re.kr 361 Kajung-Dong Yusung-Gu, Taejon 305-350, Korea Jun Seob Lee juns@etri.re.kr 361 Kajung-Dong Yusung-Gu, Taejon 305-350, Korea sjkoh, et al Expires August 2003 [Page 10] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." sjkoh, et al Expires August 2003 [Page 11]