Internet Draft M. J. Chang/EWU Document:draft-chang-mobile-sctp- M. J. Lee/EWU address-mgt-00.txt S. J. Koh/ETRI Expires: September 2004 March 2004 Address Management for Mobile SCTP Handover Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document describes an address management module for mobile Stream Control Transmission Protocol (mSCTP). The module is used for a mobile node to manage the IP addresses associated with an mSCTP association. The address management module utilizes the link layer signal strength information in order to determine when to add or delete end-point IP addresses of a mobile node and how to change the primary path from the mSCTP association when a handover happens. MJCHANG Expires - September 2004 [Page 1] Address Management for Mobile SCTP Handover March 2004 Table of Contents 1. Introduction...................................................2 2. Terminoloby....................................................2 3. Address Management for mSCTP...................................3 3.1 Communication between AMM and the other modules............3 3.2 Operation of AMM...........................................6 Security Considerations...........................................7 References........................................................8 Author's Addresses................................................8 1. Introduction The multi-homing feature of Stream Control Transmission Protocol (SCTP)[2] can be used to provide mobility support. Recently, the mobile SCTP(mSCTP)[3] has been proposed as a transport layer mobility solution. For mSCTP handover, a Mobile Node(MN) can send an ADDIP ASCONF chunk to the Correspondent Node(CN) to ensure that a newly obtained IP address is added to the SCTP association. The MN may also request the CN to delete an existing IP address from the SCTP association by sending a DELETEIP ASCONF chunk. The primary data path for an SCTP association may also be changed to the other IP address by using a Set-primary ASCONF chunk. In this way, the MN can perform mSCTP handover to a new location without aid of the network. The current specification of mSCTP specifies the basic requirements and suggestions to utilize Dynamic Address Reconfiguration Extension[4] to support session mobility. Some essential issues, such as when and by which criteria the primary path to be changed or the addition and deletion of the IP addresses mapped to the SCTP association should occur in order to deal with handover seamlessly, are not specified yet. In this document, we describe a logical block named Address Management Module(AMM), which determines when to trigger ADDIP, DELETEIP, and Set-primary ASCONF chunk utilizing the signal strength of the underlying link and informs it to the mSCTP at MN. 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. MJCHANG Expires - September 2004 [Page 2] Address Management for Mobile SCTP Handover March 2004 3. Address Management for mSCTP When handover happens, mSCTP at MN should perform ADDIP for the new IP address DELETEIP for the old one, and Set-primary for the current primary path. Therefore, we define Address Management Module(AMM) which determines when to trigger ADDIP, DELETEIP, and Set-primary ASCONF chunk utilizing the signal strength of the underlying link and informs it to the mSCTP at MN. When AMM triggers mSCTP, mSCTP at MN interacts with peer mSCTP at CN to change the end point mapping or the primary path for the SCTP association. In order to determine when to trigger ADDIP and DELETEIP, AMM uses L2 radio signal strength information. AMM triggers mSCTP to perform ADDIP as soon as the signal strength of the new access router exceeds the signal strength threshold value that enables communications (hereinafter, it is called L2-TH). Once an IP address is added, DELETEIP for that address is not triggered until the signal strength from the corresponding access router becomes lower than the L2-TH. With these policies, an SCTP association maintains the MN's IP address corresponding to all of the accessible subnets. Furthermore, an accessible IP address is added to the SCTP association as early as possible. The main purpose of these policies regarding adding or deleting end point IP addresses is to maximize the change that an end point IP address is ready when it is needed for handover. In order to determine when to trigger the primary path change, AMM also uses L2 radio signal strength information. If the radio signal strength of the primary path becomes lower than a certain threshold (hereinafter, it is called Primary-TH), primary path is replaced. The value of Primary-TH is set slightly higher than L2-TH in order to have the primary path change occur before deleting the primary path. While satisfying this condition, the Primary-TH should be as low as possible in order to reduce the number of unnecessary primary path changes. In addition, we suggest that AMM selects a new primary path utilizing the L2 radio signal strength information of the wireless subnet, the one providing strongest radio signal is selected as the new primary path in order to minimize the possible oscillation. 3.1 Communication between AMM and the other modules Figure 1 presents the interaction between AMM and the rest of mSCTP, IP address acquisition module, and link layer respectively. Receiving signals from the link layer and the IP address acquisition module, AMM determines when to trigger ADDIP, DELETEIP, and Set-primary ASCONF chunk and informs it to mSCTP. mSCTP at MN then interacts with peer mSCTP at CN to change the end point mapping or the primary path for the SCTP association. MJCHANG Expires - September 2004 [Page 3] Address Management for Mobile SCTP Handover March 2004 Triggering -ADDIP -DELETEIP -Set-primary +-------------+ +-------+ | mobile SCTP |<------- | AMM | +-------------+ +-------+ ^ ^ ^ IPAC| | | +----+ +-----------------------+ | IP | | IP address | | | | acquisition time | +----+ +-----------------------+ L2HC | | L2SS/ | | Max-IN +--------------------------------+ | Link Layer | +--------------------------------+ Figure 1 Signaling between components and AMM As shown in figure 1, link layer sends out following three types of signals to AMM in order to inform AMM about an L2 handover completion or changes of link signal strength: (1)L2HC(L2 Handover Completion): the L2 handover is completed for the interface specified in the signal (2)Max-IN(Interface with Maximum signal strength): the interface providing maximum signal strength has been changed to the one specified in the signal (3)L2SS(L2 Signal Strength): one of the L2 signal strength changes shown in figure 2 has occurred for a certain interface; L2SS specifies the interface for which the change has occurred and the types of signal strength change(S). MJCHANG Expires - September 2004 [Page 4] Address Management for Mobile SCTP Handover March 2004 L2-TH Primary-TH <--------------------------------------> | | (1)-------------> | | -------------->(2) (3)--------------------------------> | <------------- (4) (5) <------------ | <------------------------------ (6) | | <--------------------------------------> Figure 2 L2 signal strength change IP address acquisition module sends out IPAC(IP address Acquisition Completion) signal when an IP address acquisition for an interface is completed. The IPAC signal indicates the interface ID and the acquired IP address for that interface. In order to store the information collected from the signals from the link layer and the IP address acquisition module as shown in figure 1, AMM maintains an Address Table as shown in figure 3. The SS(Signal Strength) field of the address table indicates the current signal strength of the interface, and the meaning of the value of this field is shown in table 2. The H flag in the address table indicates whether the L2 handover is completed for the corresponding interface. Receiving L2HC signal for a certain interface, H flag of corresponding entry in the address table can be set. The IP address field of the address table is filled when IPAC signal for the corresponding entry comes in from the IP address acquisition module. In addition to address table, AMM also maintains information such as the interface corresponding to the current primary path and the interface with maximum signal strength. +-------------------------------------------+ | Interface ID | SS | H flag | IP address | +-------------------------------------------+ | : | : | : | : | +--------------+------+--------+------------+ Figure 3 Address Table in AMM MJCHANG Expires - September 2004 [Page 5] Address Management for Mobile SCTP Handover March 2004 Table 1 The values of the SS field in the address table +-----------------------------+ | SS | Signal Strength p | +----+------------------------+ | 0 | p < L2-TH | +----+------------------------+ | 1 | L2-TH < p < Primary-TH | +----+------------------------+ | 2 | Primary-TH < p | +----+------------------------+ Table 2 The value of the SS field that mapped by the S value of L2SS signal +---------------------------+ | S field | SS field in | | in L2SS | Address Table | +---------+-----------------+ | 5, 6 | 0 | +---------+-----------------+ | 1, 4 | 1 | +---------+-----------------+ | 2, 3 | 2 | +---------+-----------------+ 3.2 Operation of AMM mSCTP at MN sends ADDIP ASCONF chunk for a certain IP address when both the L2 handover and the IP address acquisition of the corresponding interface are competed. That is, by receiving either an L2HC or an IPAC signal, if both the IP address field and the H flag are set for a certain entry of the address table, AMM triggers mSCTP to send ADDIP ASCONF chunk for the corresponding interface. When AMM receives L2SS with S=4 or 6 for the current primary path interface, the primary path should be replaced. AMM first checks whether there is an alternative interface ready to be used as the new primary path. If one is found, it immediately triggers mSCTP to send Set-primary ASCONF chunk in order to replace the primary path with that alternative interface. In order for an interface to be a primary path interface, it should satisfy the following three conditions: MJCHANG Expires - September 2004 [Page 6] Address Management for Mobile SCTP Handover March 2004 (1)It is the interface with maximum signal strength and the signal strength is greater than the æPrimary-TH? Note that even the interface with the maximum signal strength may not provide the signal strength higher than the Primary-TH. (2)Link layer handover for the interface is completed. (3)IP address acquisition for the interface is completed. If there is no such interface, AMM postpones triggering mSCTP to send Set-primary ASCONF chunk until a path which satisfies all three of the above conditions appears. In order to avoid frequent changes of primary path during handover, the primary path is not replaced until a path which is stable enough is found even though the current one becomes inadequate. In the proposed scheme, a stable path is defined as the path that satisfies the above three conditions. The status of an interface may be transformed to being stable by incoming L2SS, L2HC, or IPAC signals. Having SS being equal to 0 or 1 for the current primary path indicates that the current primary path has become inadequate. Therefore, in this case, AMM triggers mSCTP to send Set-primary ASCONF chunk as soon as interface satisfying all three conditions of the primary path interface shows up. If AMM receives an L2SS signal with S=5 or 6 for a certain interface, AMM triggers mSCTP to send DELETEIP ASCONF chunk in order to delete that interface. If the interface happens to be the current primary path interface, AMM searches an alternative interface to serve as the primary path. If there is no interface ready to replace the primary path, triggering mSCTP to send DELETEIP ASCONF chunk should be postponed. In this case, whenever mSCTP to send Set-primary ASCONF chunk is triggered afterwards, sending DELETEIP ASCONF chunk for the current primary path interface should be triggered together. Security Considerations This document discusses architecture of SCTP mobility support. The associated security issues will be identified as further works go on. MJCHANG Expires - September 2004 [Page 7] Address Management for Mobile SCTP Handover March 2004 References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP, RFC 2026, October 1996. [2] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [3] M. Riegel, M. Tuxen, "Mobile SCTP" Internet Draft, Internet Engineering Task Force, August 2003. [4] R.Stewart, "Stream Control Transmission Protocol(SCTP) Dynamic Address Reconfiguration" Internet Draft, Internet Engineering Task Force, September 2003. Author's Addresses Moon Jeong Chang mjchang@ewha.ac.kr Ewha Womans Univ., Korea Mee Jeong Lee lmj@ewha.ac.kr Ewha Womans Univ., Korea Seok Joo Koh sjkoh@etri.re.kr ETRI, Korea MJCHANG Expires - September 2004 [Page 8] Address Management for mSCTP support March 2004 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." MJCHANG Expires - September 2004 [Page 9]