Internet Draft Seok J. Koh Document: draft-sjkoh-msctp-01.txt Kyungpook National University Expires: April 2006 Qiaobing Xie October 2005 Motorola Soohong Daniel Park Samsung Electronics Mobile SCTP (mSCTP) for IP Handover Support Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents 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 "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. Copyright Notice Copyright (C) The Internet Society (2005). Koh, et al. Expires: April 2006 [Page 1] mSCTP for IP Handover Support October 2005 Abstract This document discusses how to use of SCTP for IP handover support. With the help of the dynamic address reconfiguration, the SCTP with the ADDIP extension (called mSCTP) would provide soft handover for the mobile terminals without any additional support of routers/agents in the networks. For location management, the mSCTP could be used along with Mobile IP, Session Initiation Protocol or Reliable Server Pooling. We also discuss the use of mSCTP along with Mobile IP for Internet mobility support. Table of Contents 1. Introduction...................................................3 2. Motivations....................................................3 2.1 IP Mobility Issues.........................................3 2.2 SCTP Multihoming Feature...................................4 2.3 Session Type considered in Mobile SCTP.....................5 3. mSCTP Handover Procedures......................................5 3.1 Session Initiation by Mobile Client........................6 3.2 Obtaining an IP Address in the New Location................7 3.3 Adding the New IP address to the SCTP Association..........7 3.4 Changing the Primary IP Address............................7 3.5 Deleting the Old IP Address from the SCTP Association......8 3.6 Repeating the mSCTP Handover Procedures....................8 4. Considerations for mSCTP Handover..............................9 4.1 Requirement for mSCTP......................................9 4.2 Number of IP Addresses Used by Fixed Server................9 4.3 Dynamic IP Address Reconfiguration.........................9 4.4 AAA Functionality..........................................9 4.5 Link Layer Support for Multi-homing........................9 5. Location Management for mSCTP.................................10 5.1 Mobile IP.................................................10 5.2 SIP.......................................................10 5.3 RSerPool..................................................11 5.4 Comparisons...............................................12 6. Use of mSCTP with Mobile IP...................................13 6.1 Association Initiation in mSCTP with Mobile IP............13 6.2 Data Transport and Handover during Association............16 6.3 mSCTP with Mobile IPv6....................................16 6.4 Discussion................................................16 Security Considerations..........................................17 References.......................................................17 Acknowledgments..................................................18 Author's Addresses...............................................18 Intellectual Property............................................19 Koh, et al. Expires: April 2006 [Page 2] mSCTP for IP Handover Support October 2005 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 SCTP to be used for IP handover support. In this document, an SCTP implementation with its ADDIP extension [4], is called mobile SCTP (mSCTP). The mSCTP can be used to provide soft handover for mobile hosts that are moving into different IP network regions during the active session [5]. The mSCTP may be used as an alternative scheme against the handover schemes based on Mobile IP [6, 7]. Differently from the Mobile IP based handover schemes, which rely on the support of network agents/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 soft 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, Session Initiation Protocol (SIP), Reliable Server Pooling (RSerPool) [8] or Dynamic DNS (DDNS). This document describes the architecture of SCTP for IP handover support. Specifically, we describe the use of SCTP for soft handover by using the SCTP ADDIP extension [4]. We also discuss how to integrate SCTP with SIP, MIP or RSerPool for location management. 2. Motivations 2.1 IP Mobility Issues IP mobility issues have been 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. 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. Koh, et al. Expires: April 2006 [Page 3] mSCTP for IP Handover Support October 2005 In Mobile IP, 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. Handover Management The handover management is targeted to provide the mobile hosts for soft 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 soft handover. The mSCTP 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 mSCTP provides the handover management at the transport layer without help of routers. 2.2 SCTP Multihoming Feature The SCTP intrinsically provides the multihoming feature, 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. 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). The mSCTP can be used for soft handover while the mobile node is moving into different IP network Koh, et al. Expires: April 2006 [Page 4] mSCTP for IP Handover Support October 2005 regions over the session period. This document aims at discussing the use of mSCTP for soft 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 three types: a. Session originated from mobile host toward fixed host b. Session originated from fixed host toward mobile host c. Session originated from mobile host toward the other 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. It is noted that the case (c) can be an extension of the cases (a) and (b). That is, it can be implemented by combining both cases of (a) and (b). The mSCTP, in the present form, is targeted for soft 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, Mobile IP or RSerPool. 3. mSCTP Handover Procedures 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. Koh, et al. Expires: April 2006 [Page 5] mSCTP for IP Handover Support October 2005 [1.1.1.2] +----+ | FS | +----+ || ########## # Router # ########## || ******* *** *** ** ** ** Internet ** ** ** ** ** *** *** || ******** || || || ####### ####### # AR1 # # AR2 # ####### ####### | | Location A | | Location B | | +----+ +----+ | MC |=========>| MC | +----+ +----+ [2.2.2.2] [3.3.3.2] Figure 1. SCTP for Soft Handover Figure 1 illustrates an example of the use of mobile SCTP for soft handover in IPv4 networks. Based on this figure, the handover procedures are described in the succeeding sections. 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 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. Koh, et al. Expires: April 2006 [Page 6] mSCTP for IP Handover Support October 2005 3.2 Obtaining an IP Address in the 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. 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. 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. 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. Koh, et al. Expires: April 2006 [Page 7] mSCTP for IP Handover Support October 2005 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. c. By using an indication from the upper layer The change of the primary IP address may also be triggered by an indication from the upper layer of the MC. In particular, this scenario may be considered when an MC is in an overlay mobile communication environment where two or more networks are available at the same time, such as the so-called intersystem handover or vertical handover between WLAN and 3GPPs. In this case, a vertical handover of the MC can be triggered from an upper layer indication by considering a trade-off between connection bandwidth, coverage and cost from the concerned systems/locations. 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. 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. 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 mSCTP Handover Procedures The procedural steps for soft handover described above will be repeated whenever the MC moves to a new location, until the SCTP association will be released. Koh, et al. Expires: April 2006 [Page 8] mSCTP for IP Handover Support October 2005 4. Considerations for mSCTP Handover 4.1 Requirement for mSCTP The only requirement for providing the soft handover based on SCTP is that the MC and FS hosts are equipped with the Mobile SCTP implementations, (i.e., SCTP with ADDIP extension.) 4.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. In a certain case, we may need to consider the multi-homed FS. It is noted that there are still many further issues on how to handle the mSCTP handover or which is better in the performance aspect for each of the single-homed and multi-homed FS cases. For more information on this issue, refer to [5]. 4.3 Dynamic IP Address Reconfiguration The basic assumption for soft 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 via DHCP and IPv6 stateless configuration. However, this issue is outside the scope of this document. 4.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. It is noted that Cellular systems are expected to easily support the link-level multi-homing features, whereas the WLAN system case is for further study. Koh, et al. Expires: April 2006 [Page 9] mSCTP for IP Handover Support October 2005 The multi-homing feature enables the mSCTP to support soft 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. 5. 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. 5.1 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. After an SCTP association is successfully setup, the mSCTP will be used for providing soft handover for the mobile host. More detailed discussion is given in Section 6 on the use of mSCTP with Mobile IP. 5.2 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 soft 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. Koh, et al. Expires: April 2006 [Page 10] mSCTP for IP Handover Support October 2005 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. 5.3 RSerPool RSerPool [8] can be used for location management. A mobile server registers a pool handle such that it becomes part of a pool. It is allowed that a pool consists of one pool element only. A client (mobile or not) must know the pool handle of the mobile server it wants to talk to. It sends a name resolution request to one of the ENRP servers and gets back the current IP-addresses. Since the ENRP servers within an operational scope share its state it is not important which ENRP server is contacted. If the MS changes its IP- address it re registers at the home ENRP server. So the pool handles can be used to address a server with changing IP- addresses. If the MC or the MS change their addresses due to handovers mSCTP can be used to handle this, except for the case were the MC and the MS change their addresses simultaneously. In this case mSCTP fails i.e. the SCTP association terminates. The RSerPool session concept can be used to reestablish a new SCTP association using the new addresses and continuing the RSerPool session. Depending on the application the impact of this session failover for the application can be very small. Koh, et al. Expires: April 2006 [Page 11] mSCTP for IP Handover Support October 2005 5.4 Comparisons Table 1 summarizes the comparison of mSCTP with Mobile IP, SIP and RSerPool. Table 1. mSCTP, MIP, SIP and RSerPool for Mobility Support +-------------+------------+-------------+------------+-----------+ | Category | mSCTP | Mobile IP | SIP | RSerPool | +-------------+------------+-------------+------------+-----------+ | Layer | Transport | Network |Application | Session | +-------------+------------+-------------+------------+-----------+ | Location | Not | Supported | Supported | Supported | | Management | Supported | | | | +-------------+------------+-------------+------------+-----------+ | Handover | Supported | FMIP Needed | Supported | Supported | | Management | | | with mSCTP |with mSCTP | +-------------+------------+-------------+------------+-----------+ | Route | Supported | Binding | Not | Provided | |Optimization |(internally)|Update Needed| Provided |with mSCTP | +-------------+------------+-------------+------------+-----------+ | Special | Not | Home Agent, |SIP servers,| ENRP | | Agents | Required |Foreign Agent| Registrar | Server | +-------------+------------+-------------+------------+-----------+ As described in Table 1, the mSCTP can be used for soft 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 an additional support of network routers. 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 soft 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 soft handover. It may be used together with mSCTP for soft handover. Koh, et al. Expires: April 2006 [Page 12] mSCTP for IP Handover Support October 2005 Reliable Server Pooling can be used to provide the location management functionality. Used in combination with mSCTP it provides all functionalities required for a mobility solution. Simultaneous handovers of a MS and a MC will result in a session failover. 6. Use of mSCTP with Mobile IP For the present, the use of mSCTP with MIP is focused on the mobile sessions that are initiated by CN to MN. The sessions initiated by MN can be supported only by mobile SCTP. Specifically, Mobile IP will be used only for location management, by which the CN locates the location of MN and establishes an SCTP association. Once the SCTP association has been established, the on-going SCTP session will be supported by the mSCTP soft handover procedures. A part of the MIP functionality for data transport, will not be used in SCTP with MIP. If once the association is established, the data transport between MN and CN relies on SCTP over IP. The tunneling between HA and MN is not used. Furthermore, the Home Address (HoA) of MN is not used for the data transport. Note that the HoA is used for only the location management. 6.1 Association Initiation in mSCTP with Mobile IP When the CN has the knowledge of the current location of the MN, the basic SCTP initialization, as described in RFC 2960, is done from CN to MN as follow: a. CN sends INIT chunk to MN for triggering the association setup. b. MN responds with INIT-ACK chunk to CN. c. Then, CN and MN exchange COOKIE-ECHO and COOKIE-ACK each other. As described above, the establishment of an SCTP association is ready by exchanging INIT and INIT-ACK and completed by exchanging COOKIE- ECHO and COOKIE-ACK between CN and MN. In Mobile IP, the HA will have information on the current location of an MN, which is updated by Registration or Binding Update procedures of the MN located at a foreign link. The location management of Mobile IP can be used to convey the INIT chunk message of CN to the MN via HA. After receiving the INIT chunk, the MN responds with INIT-ACK chunk directly to CN (not by way of HA) so as to complete the initiation of SCTP association. The responding INIT-ACK must contain the CCoA (in MIPv4) or CoA (in MIPv6), which can be addressable to the MN. Koh, et al. Expires: April 2006 [Page 13] mSCTP for IP Handover Support October 2005 Mobile IPv4 considers two options to represent the location of the foreign link: CoA and CCoA. The CoA is the IP address of FA (possibly a router), whereas the CCoA is dynamically assigned by using an address allocation mechanism such as DHCP. Unfortunately, the CoA in MIPv4 cannot be applicable to SCTP, since it is an address of FA and thus cannot be used within the MN host (for its SCTP association). Note that SCTP is an end-to-end transport layer protocol, not a network-layer one. On the other hand, the CCoA in MIPv4 can be used within the SCTP hosts. Specifically, the SCTP of MN could bind the CCoA to an SCTP association. For this reason, in this document, we focus on the use of SCTP over MIPv4 for the MN hosts with CCoA in a foreign link. The case of using CoA is for further study. Let us consider an example of MIPv4 networks, which consists of CN, MN and HA. The MN is now at Location A (a foreign link), and will then move into Location B, as shown in Figure 2. [1.1.1.2] +----+ | CN | +----+ || ******* *** *** ** ** ############## ** Internet **---# Home Agent # ** ** ############## ** ** HoA=[1.1.1.2] *** *** || ******** || || || ####### ####### # AR1 # # AR2 # ####### ####### | | Location A | | Location B | | +----+ +----+ | MN |=========>| MN | +----+ +----+ CCoA=[2.2.2.2] CCoA=[3.3.3.2] HoA=[1.1.1.2] HoA=[1.1.1.2] Figure 2. SCTP with Mobile IPv4 using CCoA Koh, et al. Expires: April 2006 [Page 14] mSCTP for IP Handover Support October 2005 We assume that the MN has already obtained a CCoA ([2.2.2.2]) from the DHCP server attached to AR1, and also registered the CCoA with HA by using the MIPv4 Registration Procedures. We also assume that the applications of MN can initially bind the CCoA as well as HoA via the socket interface. After initialization of SCTP association, the HoA may be released from the application, as described below. It is noted that the HoA will still be used for MN to update its new CCoAs to HA according to the MIPv4 mechanisms. Now the CN initiates an SCTP association with the MN by sending INIT chunk message over HoA ([1.1.1.2]). The INIT chunk will first be routed to HA, and the HA then forwards the INIT chunk to MN by referring to CCoA ([2.2.2.2]) and using a tunneling mechanism, as shown in the figure below. CN HA MN | | | | INIT | INIT | |-------------------->|-------------------->| | | | | INIT-ACK (CCoA=primary address) | |<------------------------------------------| | | | | COOKIE-ECHO (over CCoA) | |------------------------------------------>| | | | | | COOKIE-ACK | |<------------------------------------------| | | | | SCTP Data Transport | |<----------------------------------------->| | | | Figure 3. SCTP Initiation in SCTP with MIPv4 In response to the INIT chunk, the MN sends INIT-ACK chunk to the CN. The INIT-ACK contains the CCoA address (as the Primary address) and HoA address. Here, the HoA address may only be used for the CN to check whether the responding MN is the authorized host or not (for somewhat security reason). In fact, the HoA will not be referred to by CN. The source address and destination address of IP packet containing the INIT-ACK chunk are CCoA [2.2.2.2] and CN [1.1.1.2], respectively. In turn, the COOKIE-ECHO and COOKIE-ACK chunks will be exchanged between CN and MN. Koh, et al. Expires: April 2006 [Page 15] mSCTP for IP Handover Support October 2005 6.2 Data Transport and Handover during Association After the association is established, the CN transmits data chunks to MN over the CCoA address, and the MN sends data chunks to CN directly. When the MN moves from Location A to Location B, the MN gets a new CCoA address [3.3.3.2] from Location B. According to the MIPv4 mechanism, the MN will update its new location to HA, which is done in the Mobile IP layer regardless of the on-going SCTP association. On the other hand, the MN will perform the soft handover, as it moves into a new IP subnet area, according to the mobile SCTP by adding the new IP address to the on-going association. These procedures will be repeated until the association has been completed. 6.3 mSCTP with Mobile IPv6 The usage scenarios for SCTP with MIPv6 are similar to those for SCTP with MIPv4 that are described so far. In MIPv6, the CoA is used instead of CCoA in MIPv4. The CoA may be obtained from the foreign location via DHCPv6 or stateless address auto-configuration. 6.4 Discussion This section discusses comparison of SCTP/MIP with the MIP-only scheme and some issues. Again, this comparison is valid for the mobile sessions that are initiated by CN toward to MN. Requirements for SCTP over Mobile IP The requirement for using SCTP over Mobile IP is that the CN and MN hosts must be aware of the mobile SCTP. In addition, the MN must be able to bind the CoA as well as HoA to its applications. In MIP, only HoA is bound to the applications of MN. Route Optimization The SCTP intrinsically provides the route optimization for data transport between CN and MN. No additional route optimization procedures are required, differently from MIPv4. No binding update between MN and CN is needed, differently from MIPv6. As a result, the tunneling of data packets between HA and MN is not required too. Other Issues In the proposed scheme for use of SCTP over MIP, the home address (HoA) of MN is not involved in the data transport between CN and MN. Koh, et al. Expires: April 2006 [Page 16] mSCTP for IP Handover Support October 2005 The reason for this is to exploit the intrinsic route optimization feature of mobile SCTP. Note that the additional tunneling or binding update procedures are required in case that the HoA is used in the SCTP association. The HoA may be used as a backup IP address in the event of path failure of the primary address, CCoA or CoA. This is for further study. Security Considerations This document discusses an informational architecture of SCTP handover. The security issues related to mSCTP handover is associated with æauthentication of ASCONF chunks exchanged between FS and MCÆ, which is described in [9]. References [1] Bradner, S., " Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [2] Bradner, S., "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-12, June 2005. [5] Riegel, M. and Tuexen M., "Mobile SCTP", draft-riegel-tuexen- mobile-sctp-05, July 2005. [6] Perkins, C. (ed.), "IP Mobility Support for IPv4", RFC 3344, August 2002. [7] Johnson, D., et al., "Mobility Support in IPv6", RFC 3775, June 2004 [8] Tuexen, M., et al., "Requirements for Reliable Server Pooling", RFC 3237, January 2002. [9] Tuexen, M., et al., "Authenticated Chunks for Stream Control Transmission Protocol (SCTP)", draft-ietf-tsvwg-sctp-auth-00.txt, June 2005. Koh, et al. Expires: April 2006 [Page 17] mSCTP for IP Handover Support October 2005 Acknowledgments The Authors would like to give special thanks to the following people for their valuable contributions: Mee Jeong Lee, Ewha Women University Randall Stewart, Cisco Systems Maximilian Riegel, Siemens AG, Germany Michael Tuexen, University of Applied Science in Muenster, Germany Mary Li Ma, University of British Columbia (UBC), USA Author's Addresses Seok J. Koh Department of Computer Science, Kyungpook National University, KOREA sjkoh@knu.ac.kr Qiaobing Xie Motorola, Inc., USA Qiaobing.Xie@motorola.com Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics, KOREA Department of Computer Science, Kyungpook National University soohong.park@samsung.com Koh, et al. Expires: April 2006 [Page 18] mSCTP for IP Handover Support October 2005 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Koh, et al. Expires: April 2006 [Page 19]