Internet Draft M. J. Chang/EWU Document:draft-chang-mobile-sctp-address-mgt-01.txt M. J. Lee/EWU S. J. Koh/KNU Expires: March 2005 October 2004 Address Management for Mobile SCTP Handover <draft-chang-mobile-sctp-address-mgt-01.txt> Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. 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 - March 2005 [Page 1]
Address Management for Mobile SCTP Handover October 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............4 3.2 Operation of AMM...........................................7 Security Considerations...........................................8 References........................................................9 Author's Addresses................................................9 1. Introduction The multi-homing feature of Stream Control Transmission Protocol (SCTP)[1] can be used to provide mobility support. Recently, the mobile SCTP(mSCTP)[2] 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[3] 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[4]. MJCHANG Expires - March 2005 [Page 2]
Address Management for Mobile SCTP Handover October 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. Minimum signal strength that enables communication is the signal strength measured at the boundary of transmission range, and is determined by radio propagation model. For Two-Ray Ground Reflection model, which is the radio propagation model assumed in our simulation experiment, the minimum signal strength that enables communication (i.e., L2-TH) is computed by the following formula: Pt*Gt*Gr*ht**2hr**2 / d**4*L (1) , where Pt, Gt, Gr, ht, hr, d and L denote transmit power, transmit antenna gains, receiver antenna gains, transmit antenna height, receive antenna height, diameter of transmission range, and system loss, respectively. When handover happens, the primary path also needs to be changed. The current mSCTP does not specifically mention about how to change the primary path for handovers. In SCTP, sender is in charge of changing the primary path and it changes the primary path if the primary path experiences repetitive losses over a certain threshold. If it is adopted in mSCTP, therefore, CN should experience multiple data packet losses for each handover before it finally determines to change the primary path and it will lead to significantly long handover latency. MJCHANG Expires ?March 2005 [Page 3]
Address Management for Mobile SCTP Handover October 2004 In order to prevent this, the proposed scheme makes MN, which is the receiver, be in charge of the primary path change, and trigger Set- Primary toward CN when handover happens. Set-Primary from MN notifies CN to change the primary path. In order to determine when to trigger Set-Primary, MN 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 should be higher than L2- TH at the minimum in order for MN to trigger Set-Primary before DELETEIP of the primary path. Furthermore, it is desirable for Set- Primary to arrive at CN before MN completely moves out of the transmission range of the old access point. In order to satisfy this condition, the signal strength corresponding to Primary-TH should be at least the signal strength at the boundary of transmission range with diameter (d-d'), where d is the transmission range of the access router and d' is the distance that MN can move during the time for which Set-Primary is delivered from MN to CN. Therefore, based on the formula in (1), the minimum signal strength for Primary-TH that can satisfy the condition is obtained as follows: 1/[{(d-d'/d}**4]*L2-TH (2) Note that the value determined by (2) depends on the moving speed of MN and the delay from MN to CN. Actually, the Primary-TH value computed by (2) is an optimal one since increasing Primary-TH value any further would only increase the chance of unnecessary primary path changes. The proposed scheme also let MN select a new primary path utilizing the L2 radio signal strength information of the wireless subnet, and inform it to CN. Among the accessible subnets, 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 - March 2005 [Page 4]
Address Management for Mobile SCTP Handover October 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: L2HC(L2 Handover Completion): the L2 handover is completed for the interface specified in the signal Max-IN(Interface with Maximum signal strength): the interface providing maximum signal strength has been changed to the one specified in the signal 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 - March 2005 [Page 5]
Address Management for Mobile SCTP Handover October 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 - March 2005 [Page 6]
Address Management for Mobile SCTP Handover October 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 - March 2005 [Page 7]
Address Management for Mobile SCTP Handover October 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 - March 2005 [Page 8]
Address Management for Mobile SCTP Handover October 2004 References [1] 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. [2] M. Riegel, M. Tuxen, "Mobile SCTP", Internet Draft, Internet Engineering Task Force, August 2003. [3] R.Stewart, "Stream Control Transmission Protocol(SCTP) Dynamic Address Reconfiguration", Internet Draft, Internet Engineering Task Force, September 2003. [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels",RFC 2119, March 1997. 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@cs.knu.ac.kr Kyungbook National Univ., Korea Full Copyright Statement Copyright (C) The Internet Society (2004). 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. "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." MJCHANG Expires - March 2005 [Page 9]