Transport Area WG Seok Joo Koh, ETRI Internet Draft Mee Jeong Lee, EWU Internet Engineering Task Force Maximilian Riegel, Siemens AG Expires December 2003 Mary Li Ma, UBC June 2003 Architecture of Mobile SCTP for IP Mobility Support Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. 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 This document discusses the architecture of mobile SCTP (mSCTP) for IP mobility support. The SCTP is the third transport layer protocol next to TCP/UDP. It can also be used for IP mobility from the multi- homing features. The SCTP with the ADDIP extension (or mSCTP) would provide seamless or soft handover for the mobile host without support of routers or agents in the networks. For location management, the mSCTP could be used along with Mobile IP or Session Initiation Protocol. Koh, Lee, Riegel, Ma [Page 1] INTERNET DRAFT Use of SCTP for IP Mobility June 2003 Table of Contents 1. Introduction..................................................3 2. Terminology...................................................3 3. Motivations on Mobile SCTP....................................4 3.1 IP Mobility Issues........................................4 3.2 SCTP Multihoming Feature..................................5 3.3 Session Type considered in Mobile SCTP....................5 4. Procedures for mSCTP Handover.................................6 4.1 Session Initiation by Mobile Client.......................7 4.2 Obtaining an IP address for a new location................7 4.3 Adding the new IP address to the SCTP association.........7 4.4 Changing the Primary IP address...........................7 4.5 Deleting the old IP address from the SCTP association.....8 4.6 Repeating the handover procedures.........................9 5. Further Considerations for mSCTP Handover.....................9 5.1 Requirement for Mobile SCTP...............................9 5.2 Number of IP addresses used by Fixed Server...............9 5.3 Dynamic IP address configuration.........................10 5.4 AAA Functionality........................................10 5.5 Link Layer Support for Multi-homing......................11 6. Location Management for mSCTP................................11 6.1 Use of mSCTP with Mobile IP..............................11 6.2 Use of SCTP with SIP.....................................12 7. Comparison of mSCTP with SIP and Mobile IP...................13 8. Security Considerations......................................14 9. Acknowledgement..............................................14 10. References..................................................14 Author's Addresses..............................................15 Full Copyright Statement........................................16 Koh, Lee, Riegel, Ma [Page 2] INTERNET DRAFT Use of SCTP for IP Mobility June 2003 1. Introduction SCTP (Stream Control Transmission Protocol), as defined in RFC 2960 [3], is the third transport layer protocol following TCP and UDP. 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 mSCTP may be used as an alternative scheme against the handover schemes based on Mobile IP [7, 8]. 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 mSCTP can be used to provide seamless handover for mobile hosts that are moving in to different IP networks. In other words, the mSCTP is targeted for the client-server services, in which the mobile client initiates an SCTP session with the fixed server. For supporting the peer-to-peer services, in which a session is terminated at the mobile host, the mSCTP must be used along with an additional location management scheme such as Mobile IP [9],Session Initiation Protocol (SIP) or Dynamic DNS (DDNS). This document describes the architecture of SCTP for IP mobility support. Specifically, we describe the use of SCTP for seamless handover by using the SCTP ADDIP extension [5]. We also discuss how to integrate SCTP with SIP or MIP for location management. This document is intended to continue 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 . 2. 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 [2]. In this document, "mSCTP" is short for "mobile SCTP". Koh, Lee, Riegel, Ma [Page 3] INTERNET DRAFT Use of SCTP for IP Mobility June 2003 3. Motivations on Mobile SCTP In this section, we discuss motivations on the use of SCTP for IP mobility support, in the viewpoint of IP mobility management issues. 3.1 IP Mobility Issues IP mobility 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 issues can be classified into Location Management and Handover Management. 3.1.1 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. SIP can also be used for location management. In SIP, a UA registers its new location with the location database via SIP Registrar server by sending an SIP Register message containing a Contact Header. So far, the Dynamic DNS (DDNS) has also been discussed as one of the candidate approaches for location management, which would not require special servers or procedures for mSCTP client. 3.1.2 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 or Fast handover schemes have been designed for handover management. These schemes rely on the tunneling between old and new access routers for seamless handover. Koh, Lee, Riegel, Ma [Page 4] INTERNET DRAFT Use of SCTP for IP Mobility June 2003 The mobile SCTP can be used as an alternative scheme against such Mobile IP based handover schemes. 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. 3.2 SCTP Multihoming Feature The SCTP intrinsically provides the multihoming feature [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. 3.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 SIP or Mobile IP, which is discussed in [9]. Koh, Lee, Riegel, Ma [Page 5] INTERNET DRAFT Use of SCTP for IP Mobility June 2003 4. Procedures for mSCTP Handover 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]. The mSCTP handover needs to be triggered by MC because only the MC knows the movement of itself and the signal strength from the old and new ARs. 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. [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. SCTP for Seamless Handover Koh, Lee, Riegel, Ma [Page 6] INTERNET DRAFT Use of SCTP for IP Mobility June 2003 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. 4.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 DHCP or IPv6 stateless address auto-configuration. Note that the FS is in the single homing with [1.1.1.2], and 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. 4.2 Obtaining an IP address for a new location Let us assume that the MC moves from Location A to 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, the newly obtained IP address ([3.3.3.2] in the figure) MUST be signaled or informed to the SCTP protocol stack, and then the SCTP will bind the new IP address to the existing SCTP association. 4.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. 4.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. Koh, Lee, Riegel, Ma [Page 7] INTERNET DRAFT Use of SCTP for IP Mobility June 2003 Actually, the configuration of a specific rule for changing the primary IP address is a challenging issue of the mobile SCTP. 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 the MC receives the ASCONF-ACK from FS, it sends another ASCONF with ôAddress Configuration Parameterö set to ôSet Primary Addressö. FS sends back ASCONF-ACK once receives the second ASCONF to confirm the handover successfully. 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 an explicit indication from the underlying layer In this case, the underlying PHY layer of MC detects and compares the signal strength, and determines the time on when the SCTP sends an ASCONF with ôSet Primary Addressö. 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. There is still a further issue on how the MC should handle the data packets queued in the outgoing buffer with the source IP address of the old primary IP address. 4.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. The rule for determining that the IP address is inactive may also be implemented by using additional information from Koh, Lee, Riegel, Ma [Page 8] INTERNET DRAFT Use of SCTP for IP Mobility June 2003 the underlying network or physical layer, as done in the previous step (for changing the primary address.) 4.6 Repeating the handover procedures The procedural steps for seamless handover described above will be repeated whenever the MC moves to a new location, until the SCTP association will be released. 5. Further Considerations for mSCTP Handover 5.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.) 5.2 Number of IP addresses used by Fixed Server In this document, we assume that the FS is in the single homing, i.e. the FS and MC are in a 1-to-2 asymmetric multi-homing configuration [10]. In such a case, the performance of providing fault resilience to the communication may possibly be degraded, because the following routing tables are in use: o Before Handover: ----------------------- ------------------------- MC FS ======================= ========================= Destination AR1 Destination AR ======================= ========================= 1.1.1.0 2.2.2.1 2.2.2.0(Primary) 1.1.1.1 3.3.3.0 1.1.1.1 ----------------------- -------------------------- o After Handover: ------------------------ -------------------------- MC FS ======================== ========================== Destination AR2 Destination AR ======================== ========================== 1.1.1.0 3.3.3.1 2.2.2.0 1.1.1.1 3.3.3.0(Primary) 1.1.1.1 ------------------------ --------------------------- Koh, Lee, Riegel, Ma [Page 9] INTERNET DRAFT Use of SCTP for IP Mobility June 2003 This particular routing arrangement of MC tends to prevent the association from taking advantage of the existence of the second interface. This is because the number of possible different paths, which can be used to route data between two endpoints, can never be larger than the minimum of IP addresses used by the endpoint. There are 2 possible solutions to this problem: 1) Once MC issues the second ASCONF with ôAddress Configuration Parameterö setting to ôSet Primary Addressö to request FS to perform the change-over, the MC transfers the sending buffer of the old link to the new link. Once MC receives the ASCONF_ACK from FS which confirms the handover success, the MC starts to sending buffered data on the new network. 2) As an alternative of this asymmetric multi-homing configuration, the FS may assign two IP addresses to the network interface to let both MC and FS in the dual homing state 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. The handover is beneficial in terms of fault resilience for both MC and FS to use all the IP addresses available to them when handover is performed. For more information on this issue, please refer to [5, 6]. 5.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. 5.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 via DHCP and IPv6 stateless configuration. However, this issue is outside the scope of mSCTP. Koh, Lee, Riegel, Ma [Page 10] INTERNET DRAFT Use of SCTP for IP Mobility June 2003 5.5 Link Layer Support for Multi-homing To support the multi-homing capability for Mobile Client, we need to consider the characteristics of the wireless links such as WLAN and Cellular systems. In the legacy WLAN systems, 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. Accordingly, to enable mSCTP in the WLAN networks, a special driver to WLAN NIC will be required to realize the concurrent binding to two different APs belonging to different IP access networks. On the other hand, the 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. It is also noted that the 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. 6. Location Management for mSCTP The mSCTP can provide only the handover for mobile hosts or the sessions initiated by mobile hosts. To support the mobile sessions that are terminated at mobile hosts, the mSCTP needs to be used along with a location management scheme such as Mobile IP or SIP. 6.1 Use of mSCTP with Mobile IP In this scenario, Mobile IP will be used to locate a mobile host and then for Home Agent to forward the data packet (SCTP INIT chunk) to the mobile host. The succeeding process for SCTP association initiation, including SCTP INIT-ACK, COOKIE-ECHO, and COOKIE-ACK, will be done directly between the mobile host and the peering host, not via Home Agent. Koh, Lee, Riegel, Ma [Page 11] INTERNET DRAFT Use of SCTP for IP Mobility June 2003 After an SCTP association is successfully setup, the mSCTP will be used for providing seamless handover for the mobile host. Details of SCTP with MIP are described in [9]. 6.2 Use of SCTP with SIP In this scenario, each host uses SCTP instead of TCP/UDP as the transport protocol. After the call setup by SIP signaling, the SCTP will be used for data transport and seamless handover. The SIP provides location management functionality by using SIP REGISTER messages. When a mobile host moves into a visiting network, it will update its current location (e.g., IP address or SIP URL) by sending a SIP Register (with a Contact Header) to the (home) SIP Registrar server. The Registrar server will then update the location database as indicated by the REGISTER message. When a call setup is requested with a mobile host, the (home) SIP proxy server will interrogate the location database to locate the mobile host and then relay the SIP INVITE message to the (visiting) SIP Proxy server up to the mobile host. If once the SCTP association is established via the SIP signaling, the data transport between two concerned hosts will be done according to the mSCTP handover mechanisms. Koh, Lee, Riegel, Ma [Page 12] INTERNET DRAFT Use of SCTP for IP Mobility June 2003 7. Comparison of mSCTP with SIP and Mobile IP Table 1 summarizes the comparison of mSCTP with Mobile IP and SIP. Table 1. mSCTP, MIP and SIP for Mobility Support +------------------+--------------+---------------+---------------+ | Category | mSCTP | Mobile IP | SIP | +------------------+--------------+---------------+---------------+ | Protocol Layer | Transport | Network | Application | +------------------+--------------+---------------+---------------+ | Location Mgt. |Not Supported | Supported | Supported | +------------------+--------------+---------------+---------------+ | Handover Mgt. | Supported |FMIP is needed | Not Supported | +------------------+--------------+---------------+---------------+ | Route |Intrinsically | Provided by | Not Provided | | Optimization | Provided |Binding Update | | +------------------+--------------+---------------+---------------+ | Network Support | Not Required | Required | Not Required | +------------------+--------------+---------------+---------------+ | Special Agents | Not Required | Home Agent, | SIP Proxy, | | Required | | Foreign Agent |Registrar, etc | +------------------+--------------+---------------+---------------+ As described in Table 1, the mSCTP can be used for seamless handover in the transport layer. To use mSCTP, it is required that the CN and MN hosts should be aware of the mobile SCTP. Instead, mSCTP does not need the support of network routers for seamless handover. Furthermore, the mSCTP intrinsically provides the Route Optimization without using any additional Binding Update procedures. For location management, the mSCTP may be used along with MIP or SIP. In case of using MIP for location management, only the MN needs to be aware of MIP, whereas the CN need not use MIP. Using mSCTP with MIP, the MN must also be able to bind the CoA as well as HoA to its applications. The HoA will be used only for location management. After establishment of an SCTP session, the HoA will not be used for data transport. Instead, the CoA is employed for the SCTP data transport. On the other hand, in MIP, only HoA is bound to the applications of MN regardless of the different CoAs. The MIP provides the location and management in the network layer, and it can support seamless handover with help of neighboring routers such as tunneling between old and new ARs. On the other hand, SIP is an application signaling protocol that supports the location management for user or personal mobility. SIP itself does not provide seamless handover. It may be used together with mSCTP for seamless handover. Koh, Lee, Riegel, Ma [Page 13] INTERNET DRAFT Use of SCTP for IP Mobility June 2003 8. Security Considerations This document discusses architecture of SCTP mobility support. The associated security issues will be identified as further works go on. 9. Acknowledgement The Authors would like to give special thanks to the following people for their valuable contributions: Jun Seob Lee, ETRI Moon Jeong Chang, Ewha Womans University Michael Tuexen, University of Applied Science in Muenster Randall Stewart, Cisco Systems Hee Young Jung, ETRI Sung Han Kim, ETRI 10. References [1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP, RFC 2026, October 1996. [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP, RFC 2119, March 1997. [3] Stewart, R., et al., "Stream Control Transmission Protocol", RFC 2960, October 2000 [4] Stewart, R., "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", draft-ietf-tsvwg-addip-sctp-07, February 2003 [5] Riegel, M. and Tuexen M., "Mobile SCTP", draft-riegel-tuexen- mobile-sctp-02, February 2003 [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 Koh, Lee, Riegel, Ma [Page 14] NTERNET DRAFT Use of SCTP for IP Mobility June 2003 [8] Johnson, D., et al., "Mobility Support in IPv6", draft-ietf- mobileip-ipv6-21, May 2003 [9] Koh, S. J., et al., "SCTP with Mobile IP for IP Mobility Support", draft-sjkoh-mobile-sctp-mobileip-01, June 2003 [10]Stewart, R. Xie, Q., ôStream Control Transmission Protocol û A Reference Guideö, Addison Wesley Longman, 2001. Author's Addresses Seok Joo Koh sjkoh@etri.re.kr ETRI, Korea Mee Jeong Lee lmj@ewha.ac.kr Ewha Womans University (EWU), Korea Maximilian Riegel Maximilian.Riegel@icn.siemens.de Siemens AG, Germany Mary Li Ma maryma@interchange.ubc.ca University of British Columbia (UBC) Koh, Lee, Riegel, Ma [Page 15] NTERNET DRAFT Use of SCTP for IP Mobility June 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." Koh, Lee, Riegel, Ma [Page 16]