Network Working Group Dong P. Kim Internet Draft Kyungpook National University Intended status: Informational Seok J. Koh Expires: November 2007 Kyungpook National University May 30, 2007 Use of ASCONF Chunk for mSCTP Handover of A Single-Homed Host draft-dpkim-msctp-single-00.txt 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 This Internet-Draft will expire on November 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract SCTP can be used to support soft IP handover between heterogeneous wireless networks with the help of the ADDIP extension and its multi- homing feature. In this document, we describe the issues in SCTP handover between homogeneous wireless networks for a single-homed host that may cause the serious communication delay. Then, we propose the use of the ASCONF chunk with the cumulative ASCONF Parameters for Kim and Koh Expires November 30, 2007 [Page 1] Internet-Draft Use of ASCONF Chunk for A Single-Homed Host May 2007 Add IP Set Primary and Delete IP ASCONF Parameter to support faster IP handover for a single-homed host. Table of Contents 1. Introduction................................................3 2. Motivation..................................................3 3. Use of ASCONF Chunk for SCTP Handover........................4 3.1. ASCONF Chunk with cumulative ASCONF Parameters...........4 3.2. ASCONF Parameters in the ASCONF chunk...................5 3.3. Operations of the ASCONF chunk with the cumulative ASCONF Parameters..................................................6 4. SCTP Handover Procedure for Single-homed Host................7 5. Further Issues..............................................8 5.1. Address Verification....................................8 5.2. Implementation Support..................................8 6. Security Considerations......................................8 7. IANA Considerations.........................................8 8. Acknowledgments.............................................8 9. References..................................................9 9.1. Normative References....................................9 9.2. Informative References..................................9 Author's Addresses.............................................9 Intellectual Property Statement................................10 Disclaimer of Validity........................................10 Kim and Koh Expires November 30, 2007 [Page 2] Internet-Draft Use of ASCONF Chunk for A Single-Homed Host May 2007 1. Introduction SCTP can be used to support IP handover between different subnets with the help of ADDIP extension. It maintains the association during the handover process, by adding the newly obtained address and changing the primary address and deleting the old address in the overlapping region between heterogeneous wireless networks. More specially, SCTP handover can be reasonably defined for heterogeneous wireless networks where the hosts are multi-homed. It may provide better performance than the existing schemes in term of handover delay because the multi-homed host can perform the handover into the new address while the DATA chunks are transmitted through the existing address. However, SCTP handover for homogeneous wireless networks where the host is single-homed may cause the serious communication delay while the address is being renumbered. Differently with the multi-homed host, the single-homed host uses only one IP address. It may cause several reasons for the communication delay. In addition, the host can set the primary address by using the ASCONF chunk containing Set Primary ASCONF Parameter for SCTP handover. However, the single-homed host cannot send the Set Primary ASCONF Parameter according to the limitation of current SCTP ADD-IP extension. In this document, we describe the some issues that can be occurred in SCTP handover for homogeneous wireless networks where the host is single-homed. Then, we propose the use of the ASCONF with the cumulative ASCONF Parameters used for IP handover. 2. Motivation The issues in SCTP handover for homogeneous wireless networks that cause communication delay can be described as the follows: 1) A single-homed host may send the ASCONF chunk including Add IP ASCONF Parameter using new address in IP header to the peer according to the movement into the new subnet region. Then, the peer may reply to the source address of the packet in this case which is the new address that was added by the ASCONF. However, the peer can not send SCTP data using the new destination address to the endpoint until such time as it is confirmed to the address verification procedure for the added address. In this phase, the peer tries to subsequently send SCTP data to the old address of the MN. It may cause that RTO value is considerably increased by the fact that many retransmission failures are occurred. After current RTO expiration, the peer may be able to Kim and Koh Expires November 30, 2007 [Page 3] Internet-Draft Use of ASCONF Chunk for A Single-Homed Host May 2007 send SCTP data to the new address of the singled-homed host. It may cause the serious communication delay during this period. 2) To support smoother and faster IP handover, the host may set the primary address by sending the ASCONF Chunk containing Set Primary ASCONF parameter after adding the IP address. The receiver can change the primary destination to the specified address. However, the single-homed host may not send the ASCONF Chunk containing Set Primary Parameter using the new address as a source address according to the current ADD-IP extension. So, we need to clarify the Set Primary ASCONF Parameter for the single-homed host. 3) After the Set Primary, the endpoints may use the new address as a source and destination address. However, the retransmission or other chunks except ASCONF Chunks can be transmitted to the old address, since the old address is still available from the association. Thus, it is required that ASCONF Chunk containing Delete IP ASCONF Parameter should be sent from the single-homed host. Based on the problems given above, we suggest that the single-homed host can send the ASCONF Chunk cumulatively containing the Add IP and Set Primary and Delete IP to support the smoother and faster IP handover between homogeneous wireless networks. It is noted that the endpoints can transmit all chunks using the new address after the process of ASCONF and ASCONF-ACK Chunks with the cumulative ASCONF Parameters. 3. Use of ASCONF Chunk for SCTP Handover 3.1. ASCONF Chunk with cumulative ASCONF Parameters To support the faster and smoother IP handover for homogeneous wireless networks, we propose that the single-homed host can send the ASCONF chunk containing the Add IP and Set Primary and Delete IP address ASCONF Parameters and receive the ASCONF-ACK chunk with a cumulative ASCONF Parameter Responses as a response. Figure 1 shows the structure of ASCONF chunk with cumulative ASCONF Parameters. Kim and Koh Expires November 30, 2007 [Page 4] Internet-Draft Use of ASCONF Chunk for A Single-Homed Host May 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x80 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Add IP ASCONF Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set Primary ASCONF Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delete IP ASCONF Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 ASCONF chunk Format with Cumulated Parameters. As seen in Figure 1, the structure of the ASCONF chunk is the same with the one specified in SCTP ADDIP extension. Merely, the difference is that the ASCONF chunk can contains the Add IP and Set Primary and Delete IP ASCONF parameters. It may be sent by the single-homed host when it goes into a new subnet region and obtains the new address. In addition, the host may send this ASCONF chunk using the new address in the IP header. It is noted that all chunks are enclosed with the authenticated chunks to ensure the secure signaling process for the SCTP handover. 3.2. ASCONF Parameters in the ASCONF chunk Figure 2 shows the ASCONF Parameters contained in the ASCONF chunk. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xC001 | Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONF-Request Correlation ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| a. Add IP ASCONF Parameter. Kim and Koh Expires November 30, 2007 [Page 5] Internet-Draft Use of ASCONF Chunk for A Single-Homed Host May 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =0xC004 | Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONF-Request Correlation ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ b. Delete IP ASCONF Parameter. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =0xC002 | Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONF-Request Correlation ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c. Delete IP ASCONF Parameter. Figure 2 ASCONF Parameters contained in the ASCONF chunk As seen in Figure 2, the ASCONF Parameters has the same packet format with those defined in the SCTP ADDIP extension. Only, the Address Parameter in each ASCONF Parameter may be differently designated according the Parameter types. The Address Parameters of the Add IP and Set Primary ASCONF Parameters must be specified by the new address of the single-homed host that newly obtained in the new subnet region. On the other hand, the Delete IP ASCONF Parameter should fill into the Address Parameter with the old address of the single-homed host. 3.3. Operations of the ASCONF chunk with the cumulative ASCONF Parameters When the single-homed host obtains the new IP address as it goes into a new subnet, it can send the ASCONF with the Add IP and Set Primary and Delete IP ASCONF parameters using the new address in the IP header. Then, the receiver may reply with the ASCONF Parameter Responses reporting the status of ASCONF processing in the ASCONF-ACK. Kim and Koh Expires November 30, 2007 [Page 6] Internet-Draft Use of ASCONF Chunk for A Single-Homed Host May 2007 If a responding endpoint indicates the success, both two peers may transmit SCTP data each other, using the new address as a source address and destination address. 4. SCTP Handover Procedure for Single-homed Host We consider a single-homed mobile client (MC) that initiates an SCTP association with a fixed server (FS) and then moves from Location A and Location B. The overall SCTP handover procedures for homogeneous wireless networks are performed as follows: 1) When the MC leaves from Location A and goes into Location B, the MC may not transmit SCTP data using the old address in new subnet region. It means that the MC and FS can communication each other during this period. It is called hard handover by L2 level. 2) After the MC obtains or configures from DHCP server or through IPv6 address auto-configuration, it can send the ASCONF chunk to reconfigure the ongoing address for IP handover. More especially, it is noted that ASCONF chunk cumulatively encloses the Add IP and Set Primary and Delete IP ASCONF parameters. In the Add IP and Set Primary ASCONF Parameter, the new address is filled into the Address Parameters of them. 3) When the FS receives the ASCONF with the cumulative ASCONF Parameters, it processes and then reply with ASCONF-ACK containing the correspondent ASCONF Parameter Reponses to the newly address destination address. 4) If ASCONF Parameter Reponses does not include any Error Cause, the MC and FS sends the SCTP data using the new address as a source and destination address. More especially, the retransmission failed during lower layer disconnection is also transmitted by the new address. 5) After then, the SCTP association between two endpoints does not use the old address any more. The procedural steps described above will be repeated any time the MC moves toward the new subnet region. Kim and Koh Expires November 30, 2007 [Page 7] Internet-Draft Use of ASCONF Chunk for A Single-Homed Host May 2007 5. Further Issues This section describes the further issues required to support faster and smoother IP handover between homogeneous wireless networks. 5.1. Address Verification After handover process, the peer host is required to verify the new destination address before it sends DATA chunks using the new address. In other words, the peer host should confirm the reachability of the newly added address by using the address verification procedures. For this purpose, it is necessary that the address verification should be defined. 5.2. Implementation Support To evaluate the proposed scheme, some implementation should be supported. Until now, there is no implementation supporting the IP handover for the single-homed host. More specially, the ASCONF chunk that fills into Address Parameter with the old address should be sent from the new address in the IP header. 6. Security Considerations TBD 7. IANA Considerations TBD 8. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Kim and Koh Expires November 30, 2007 [Page 8] Internet-Draft Use of ASCONF Chunk for A Single-Homed Host May 2007 9. References INFO (REMOVE): Manually insert a page break before this section if after appendices INFO (REMOVE): Authors can use either the auto-numbered references OR the named references; typically, these would not be mixed in a single document. This template includes both examples for illustration of the two variations. 9.1. Normative References [1] Stewart, R., et al., "Stream Control Transmission Protocol", RFC 2960, October 2000. 9.2. Informative References [2] Stewart, R., et al., "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", draft-ietf-tsvwg- addip-sctp-20, April 2007. [3] Koh, S., et al., "Mobile SCTP (mSCTP) for IP Handover Support", draft-sjkoh-msctp-01, October 2005. [4] Honda., M., et al., "Fast Handover with Stream Control Transmission Protocol (SCTP) on Single-home nodes", draft- micchie-tsvwg-fastmsctp-00, February 2007. Author's Addresses Dong Phil Kim Kyungpook National University 1370 Sankyuk-dong Buk-gu Daegu 702-701, Korea Email: dpkim@cs.knu.ac.kr Seok Joo Koh Kyungpook National University, KOREA 1370 Sankyuk-dong Buk-gu Daegu 702-701, Korea Email: sjkoh@knu.ac.kr Kim and Koh Expires November 30, 2007 [Page 9] Internet-Draft Use of ASCONF Chunk for A Single-Homed Host May 2007 Intellectual Property Statement 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, THE IETF TRUST 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 IETF Trust (2007). 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. Kim and Koh Expires November 30, 2007 [Page 10]