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 SCTP with Mobile IP 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 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 SCTP (Stream Control Transmission Protocol) is a new reliable transport protocol that is featured multi-streaming and multi- homing over TCP. Mobile SCTP (mSCTP) is defined as SCTP with the ADDIP extension. In this document, we discuss the use of mSCTP along with Mobile IP for IP mobile support in the harmonized manner. The use of SCTP with Mobile IP 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. sjkoh, et al Expires August 2003 [Page 1] INTERNET DRAFT Use of SCTP for IP Mobility Support February 2003 1. Introduction The Stream Control Transmission Protocol (SCTP) [1, 2, 3] that provides the multihoming feature. Without support of routers in the networks, the SCTP with the ADDIP extension [4] that is called mobile SCTP (mSCTP) can be used to provide seamless handover for the mobile sessions that are originated by Correspondent Nodes (CN) toward to Mobile Nodes (MN) [5, 6]. The mobile SCTP can also be used for the mobile sessions that are initiated by CN toward MN, if it is used along with the Mobile IP [7, 8]. In this case, the Mobile IP is used for location management, by which the CN finds the location of MN with help of Home Agent. Specifically, Mobile IP will be used only for the CN to find the current location of MN and to establish an SCTP association. Once the SCTP association has been established, the SCTP session will be supported by the mSCTP seamless handover procedures [5, 6]. 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. This document uses the terms defined in Mobile IP (MIP) such as Home Address (HoA), Care-of Address (CoA), Collocated CoA (CCoA), Home Agent (HA), Foreign Agent (FA) and Access Router (AR). 1.2 Acknowledgement The authors would like to give special thanks to the following people in ETRI for their valuable comments: Juyoung Park Jung Soo Park Mee Jung Lee Jae Hong Min sjkoh, et al Expires August 2003 [Page 2] INTERNET DRAFT Use of SCTP for IP Mobility Support February 2003 2. Motivations on Mobile SCTP for IP Mobility Support 2.1 Mobility Management Issues Generically, IP mobility management issues are divided into Location Management and Handover Management. To support the Internet host mobility, the following two functions are required: Location Management and Handover Management. 2.1.1 Location Management Location Management is to identify the current location of a mobile node and keep track of its changes as it moves on. Basically, the location management is done so as to prepare the call setup for the sessions that are requested to mobile nodes (MN) from correspondent nodes (CN). With help of location management, the CN will be able to locate the MN and to establish a session via an appropriate call setup process. In Mobile IPv4 [7], Home Agent (HA) and Foreign Agent (FA) are employed for location management. The Home Address (HoA) is used as a host identifier of an MN, whereas the Care-of Address (CoA) is used as a location identifier of the MN. The HA maintains the information on the current location of each mobile node by binding CoA of FA to HoA of MN. In case that a Collaborated CoA (CCoA) is used instead of CoA, MIPv4 need not use the FA. By this, an external CN will be able to establish a session with an MN. In Mobile IPv6 [8], the HA is employed for location management. Similar to MIPv4, HoA and CoA are used as a host identifier and a location identifier of the MN, respectively. The CoA of MIPv6 is the same as CCoA of MIPv4. By using MIPv6, an external CN will be able to establish a session with an MN. In Mobile IP, it is noted that the HoA is also used by the applications of an MN, since the MN binds its applications to the HoA. In this respect, HoA is also used for IP packet data transport. 2.1.2 Handover Management Handover Management is used to provide mobile hosts for seamless handover, whenever they move into different IP network regions during a session. The main objective of the seamless handover is to minimize the service disruption due to data loss and/or latency during the handover period. In Mobile IP, the Low Latency handover for MIPv4 [9] and Fast Handover for MIPv6 [10] have been designed for handover management. These MIP-based handover schemes rely on the tunneling between old and new Access Routers (ARs). sjkoh, et al Expires August 2003 [Page 3] INTERNET DRAFT Use of SCTP for IP Mobility Support February 2003 2.2 Mobile SCTP in the viewpoint of Mobility Management In terms of mobile Internet services, a session involved by a mobile node can be classified into one of the following two types: a. Session originated from MN toward CN b. Session originated from CN toward MN The mobile sessions in (a) seem to be a natural extension of the classical 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. For this type of session, the location management is not a crucial requirement. Only the seamless handover will be required in terms of IP mobility management. On the other hand, the case (b) requires the location management by which the session originator, CN, can locate the mobile host, MN, as supported in Mobile IP. 2.2.1 For Seamless Handover Mobile SCTP (mSCTP) [5, 6], in its present form, is targeted for mobile sessions that are initiated by MNs toward CNs located in the fixed networks. The mSCTP is used to provide seamless handover for mobile nodes that change their IP addresses by continual moving across different IP subnets. These sessions do not require location management. The detailed schemes for seamless handover using mSCTP are described with some implementation issues in [5, 6]. In this section, we briefly summarize the mSCTP handover procedures. Assuming that an MN established an SCTP session with a CN within Location A, the generic procedures for seamless handover from Location A to Location B are as follows: Step 1. Initially, the MN is single homing in Location A. Step 2. While the MN approaches Location B, it obtains a new IP address from Location B (its AR). The MN is now dual homing by binding the new address to its SCTP association. Step 3. The MN notifies the new IP address to the CN by sending an SCTP Address Configuration Change (ASCONF) chunk to the CN. The MN may also set the new IP address to be the Primary IP address. While the MN is being dual homing in the overlapping region, it will be able to receive the IP packets from the CN, including original data packets and retransmitted packets. sjkoh, et al Expires August 2003 [Page 4] INTERNET DRAFT Use of SCTP for IP Mobility Support February 2003 Step 4. When the MN cannot hear the wireless signal from Location B, it deletes the old IP address from the SCTP association by sending ASCONF chunk to the CN. Steps 1 through 4 described above will be repeated whenever the MN moves on across different IP subnets while the association is active. The mSCTP can be used to provide an alternative scheme for seamless handover instead of the LMIPv4 and FMIPv6 schemes. The basic difference between the MIP-based handover schemes and mSCTP is that the mSCTP intrinsically realizes the handover in the transport layer without any support of network routers, whereas the MIP-based schemes rely on the support of routers support for tunneling between old and new ARs. 2.2.2 For Location Management To support the mobile sessions that are initiated by a CN toward an MN, the mSCTP may be used along with a location management scheme such as Mobile IP. In this scenario, the MIP will be used for a CN to locate an MN and to establish an SCTP association with the MN. After an SCTP association is successfully setup, the mobile SCTP will be used for providing seamless handover for the MN, as described in [5, 6]. 3. Mobile SCTP with Mobile IP for Location Management For the present, the use of SCTP 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 seamless handover procedures [5, 6]. 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. sjkoh, et al Expires August 2003 [Page 5] INTERNET DRAFT Use of SCTP for IP Mobility Support February 2003 3.1 Initiation of an SCTP association over Mobile IP As described in RFC 2960 [1], the SCTP initialization is done from CN and MN as follow (also see Figure 1): a. CN sends INIT chunk to MN for triggering the association setup. INIT chunk contains a list of IP addresses and port number will be used by CN. b. MN responds with INIT-ACK chunk to CN. INIT-ACK chunk contains a list of IP addresses and port number will be used by CN. It can also contain indication about which is the primary address among multiple addresses, if any (See [4]). c. Then, CN and MN exchange COOKIE-ECHO and COOKIE-ACK each other. CN MN | | | INIT | |-------------------->| | | | INIT-ACK | |<--------------------| | | | COOKIE-ECHO | |-------------------->| | | | COOKIE-ACK | |<--------------------| Figure 1. SCTP Initialization As shown in the figure, 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. sjkoh, et al Expires August 2003 [Page 6] INTERNET DRAFT Use of SCTP for IP Mobility Support February 2003 3.2 Usage Scenarios for SCTP over Mobile IPv4 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 # ** ** ############## ** ** [1.1.1.1] *** *** || ******** || || || ####### ####### # 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 sjkoh, et al Expires August 2003 [Page 7] INTERNET DRAFT Use of SCTP for IP Mobility Support February 2003 3.2.1 SCTP Association Initiation 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. 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 (see the Section 4 for more detailed discussion). The source address and destination address of IP packet containing the INIT 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. Then an SCTP association has been established between CN and MN. sjkoh, et al Expires August 2003 [Page 8] INTERNET DRAFT Use of SCTP for IP Mobility Support February 2003 3.2.2 Data Transport and Handover during the 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 seamless 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, as described in 2.2.1. These procedures will be repeated until the association has been completed. 3.3 Usage Scenarios for SCTP 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. 3.4 Comparison of SCTP/MIP with MIP only This section discusses comparison of SCTP/MIP with the MIP-only scheme. Again, this comparison is valid for the mobile sessions that are initiated by CN toward to MN. 3.4.1 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. 3.4.2 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. sjkoh, et al Expires August 2003 [Page 9] INTERNET DRAFT Use of SCTP for IP Mobility Support February 2003 4. Further Issues to be considered 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. 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. 5. Security Considerations This document discusses the use of mobile SCTP for IP mobility support. The concerned security issues will 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 [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] Koh, S. J., Jung, H. Y., Kim, S. H. and Lee, J. S., "Use of SCTP for Seamless Handover", draft-sjkoh-mobile-sctp-handover- 00, February 2003 [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 sjkoh, et al Expires August 2003 [Page 10] INTERNET DRAFT Use of SCTP for IP Mobility Support February 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 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 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]