Network Working Group M. Honda Internet Draft Keio Univ. Y. Nishida Sony CSL Inc. M. Kozuka Kyoto Univ. Expires August 26, 2007 Feb 26, 2007 Fast Handover with Stream Control Transmission Protocol (SCTP) on Single-home nodes Status of this Memo Distribution of this memo is unlimited. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Providing transport layer mobility is one of the features of SCTP [RFC2960]. By using Dynamic Address Reconfiguration extension, SCTP can accomplish handover between different subnets. However, due to some issues in the current SCTP, serious performance degradation will happen during the handover process. The problem arises especially when a mobile node has only one network interface. This document describes the issues of current SCTP handover mechanism and proposes three functions to achieve smooth and fast handover. Table of Contents 1. Introduction ....................................................2 2. Issues in SCTP Handover Mechanism ...............................2 3. Proposed Solutions for Fast Handover ............................3 3.1. Source and Destination Based Congestion Control ............3 3.2. Definition of Set Primary reception ........................4 3.3. Recommend Retransmission ASCONF parameter ..................4 3.3.1. New Parameter Type ....................................5 3.3.2. Recommend Retransmission ..............................5 3.4. General rules for immediate retransmission .................6 4. IANA Considerations .............................................6 5. References ......................................................6 1. Introduction Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration [ADD-IP] can support mobility among different subnets by reconfiguration of addresses in existing SCTP associations. When a mobile node (MN) moves and obtains or configures a new IP address, the MN-side SCTP endpoint is notified of the new address from the lower layer. Then, the MN sends an ASCONF Chunk containing Add IP Address parameter to notify a correspondent node (CN) of the new address, and the MN and the CN can maintain an existing SCTP association. Additionally, the MN can make the CN change a primary destination to the new address by sending an ASCONF Chunk containing Set Primary parameter [ADD-IP]. Therefore, the MN can make the CN send DATA Chunks to the new address. However, due to some issues in the current SCTP, serious communication delay arises during the SCTP handover process, especially, when the MN is single-homed, which has only one available network interface. The single-homed MN loses the reachability during it connects to a new wireless base station and obtains or configures a new IP address. However, the MN tries to transmit or retransmit packets. These data transmissions cause Retransmission Time Out (RTO) expirations and increase the RTO value. In some cases, the increased RTO value exceeds 30 seconds and causes serious performance degradation on data transfer. In this document, we describe the issues of the current SCTP handover mechanism and propose a solution to achieve smooth and fast handover. Our solution consists of three proposals. First, we propose an optional congestion control policy, which is source and destination based congestion control, while destination based congestion control used in the current specification of SCTP. Second, we propose to clarifies the SCTP behavior when SCTP endpoints receive an ASCONF Chunk that contains Set Primary parameter. Third, we propose a new ASCONF parameter: Recommend Retransmission that requests immediate retransmissions to a specified address to a peer endpoint. 2. Issues in SCTP Handover Mechanism The issues in SCTP Handover Mechanism that cause communication delay can be categorized into the following four parts. If the MN is multi-homed, the MN may be able to keep the reachability to the CN by using other network interfaces during the handover process in some cases. Thus, following issues might not be serious for multi-homed MNs. A) A single-homed MN cannot transmit an ASCONF Chunk right after it is notified of an IP address from the lower layer. Although the ASCONF Chunk can be transmitted from the new address, the transmission is delayed until the current RTO expires. When the RTO value is increased by the failures of data transmission during the lower layer disconnection caused by connecting to a new wireless base station and obtaining or configuring a new IP address, the delay might be fairly long in some cases. This issue indicates that an SCTP endpoint does not regard the change of a source address as the change of communication path. B) A CN transmits an ASCONF-ACK Chunk when it receives an ASCONF Chunk containing Add IP Address parameter from the MN. By receiving the ASCONF-ACK, the MN can confirm that the CN is notified of the new IP address and it can transmit data from the new source address. However, when the MN fails data transmissions from the previous source address during the lower layer disconnection and A), these DATA Chunks are not retransmitted from the new source address until the next RTO expiration. Moreover, when many retransmission failures are occurred, the RTO value is materially increased. C) A CN cannot start data transmissions to the new address of the MN right after the handover process. When the CN receives an ASCONF Chunk containing Add IP Address parameter, it marks the new destination address as unconfirmed and sends a HEARTBEAT Chunk in order to confirm the reachability of the destination as specified in Section 4.3 of [ADD-IP]. After the CN receives a HEARTBEAT-ACK Chunk for the HEARTBEAT, it can transmit DATA Chunks to the new destination. Hence, even if the CN fails to transmit DATA Chunks to MN's old destination by the RTO expirations, the CN can retransmit them to the newly confirmed destination. However, when the CN fails retransmission many times before the reception of the HEARTBEAT-ACK, the RTO value is fairly increased. In this case, the CN cannot retransmit DATA Chunks until the next RTO expiration. D) For smooth handover, the MN should transmit an ASCONF Chunk containing Set Primary parameter for the new address in order to make a CN change the primary address expressly. Otherwise, the CN might transmit DATA Chunks to the old destination until the number of retransmissions exceeds the protocol parameter 'Path.Max.Retrans'. When the CN receives an ASCONF Chunk containing Set Primary parameter, it changes the primary destination to the specified address. However, some implementations do not apply this specified primary destination to the DATA Chunks that are already inserted to send queue or retransmission queue, since the current specification is not clear at this point. This might cause several unnecessary retransmission failures and lead long communication delay in some cases. 3. Proposed Solutions for Fast Handover We propose following three solutions to solve the issues described in Section 2. These solutions are especially effective when the mobile node is single-homed. 3.1. Source and Destination Based Congestion Control We propose that SCTP MAY use an optional congestion control policy when the handover process, which is source and destination based congestion control, while destination based congestion control used in the current SCTP. This means that SCTP endpoints can recognize communication paths by a pair of source and destination addresses. This enables that SCTP endpoints consider change of the source address as change of the communication path when the handover process. In some cases, the change of source address does not indicate the change of the communication path, such as renumbering source addresses. However, this rarely happens while handover in wireless networks happens frequently. Additionally, in the mobile environment, the congestion in wireless links that are located as edge networks is more frequently happens than wired networks that are located as the backbone networks. Therefore, if the change of source address is not considered as change of communication path, it might aggravate the congestion when the MN's visited link is congested. Based on this concept, we propose all the congestion control parameters, such as (cwnd, ssthresh, RTO) related to a path should be reset to the initial values when the source or destination address of the path has been changed. Besides that, the endpoint MUST start sending DATA Chunks with slow-start algorithm. According to this, an SCTP endpoint MAY send an ASCONF Chunk containing Add IP Address parameter from a newly obtained or configured address without waiting for the RTO expiration. In addition, we propose an SCTP endpoint MAY retransmit DATA Chunks from the new source address without waiting for the RTO expiration when they are sent from the new source address. In some cases, the CN might receive several duplicated TSN DATA Chunks, such as when the handover process is completed during especially short time or the MN is multi-homed. Hence, minimum waiting time or rules for the retransmission might be needed. 3.2. Definition of Set Primary reception We propose to clarify the SCTP behavior when endpoints receive an ASCONF containing Set Primary parameter. In the current specification[ADD-IP], it depends on the implementation whether endpoints apply the newly specified primary address to DATA Chunks which are already copied to the SCTP stack or inserted to the send queue. However, since this can affect the handover latency for single- home nodes seriously, we propose that an endpoint SHOULD apply the new primary destination to all DATA Chunks that are not sent yet and not specified the destination by user application when it receives Set Primary parameter. Note that this is not applied to the DATA Chunks in the retransmission queue. 3.3. Recommend Retransmission ASCONF parameter To avoid data retransmissions to the old primary address when SCTP endpoints receive an ASCONF Chunk containing Set Primary parameter, this document defines a new ASCONF parameter: Recommend Retransmission. This parameter requests immediate data retransmissions to the specified address. When an endpoint receives an ASCONF containing Recommend Retransmission parameter, it MAY retransmit all unacknowledged DATA Chunks to the specified address without waiting RTO expiration. This means that the endpoints modify the destination of DATA Chunks in the retransmission queue to the specified destination, and retransmit them immediately. 3.3.1 New Parameter Type The one new parameter added follow the format defined in section 3.2.1 of [RFC2960]. Table 1 describes the parameter. Address Configuration Parameters Parameter Type -------------------------------------------------- Recommend Retransmission 0xC007 Table 1: Parameters used in ASCONF Parameter 3.3.2 Recommend Retransmission 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 = 0xC007 | Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONF-Request Correlation ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ASCONF-Request Correlation ID: 32 bits This is an opaque integer assigned by the sender to identify each request parameter. It is in host byte order and is only meaningful to the sender. The receiver of the ASCONF Chunk will copy this 32 bit value into the ASCONF Response Correlation ID field of the ASCONF-ACK response parameter. The sender of the ASCONF can use this same value in the ASCONF-ACK to find which request the response is for. Address Parameter: TLV This field contains an IPv4 or IPv6 address parameter as described in 3.3.2.1 of [RFC2960]. The complete TLV is wrapped within this parameter. It requests the receiver to retransmit DATA Chunks that are not acknowledged by SACK to the specified address. If the address 0.0.0.0 or ::0 is provided, the receiver MAY use the source address of the packet as a destination for the retransmission. An example TLV requesting to make receiver retransmit unacknowledged DATA Chunks to an IPv4 address 10.1.1.1. +--------------------------------+ | Type=0xC007 | Length = 16 | +--------------------------------+ | C-ID = 0x01023479 | +--------------------------------+ | Type=5 | Length = 8 | +----------------+---------------+ | Value=0x0a010101 | +----------------+---------------+ 3.4 General rules for immediate retransmission. Recommend Retransmission is MUST accepted only when the specified address is confirmed and reachable state. Additionally, these retransmissions MUST be performed with SCTP congestion control mechanism and flow control mechanism that are described Section 7 of [RFC2960]. Therefore, when there are some Chunks that are previously sent to the destination and not acknowledged by SACKs, retransmissions by this parameter are started with the current congestion state of the destination. In some cases, the CN might receive several duplicated TSN DATA Chunks, such as when the handover process is completed during especially short time or the MN is multi-homed. Hence, same as MN's retransmission described in Section 3.1, minimum waiting time or rules for the retransmission might be needed. 4. IANA Considerations This document defines the following new SCTP parameters, Chunks and errors. o One parameter type This parameter type must come from the range of types whare the upper two bits are set, we recommend 0xC007, as specified in this document. The suggested parameter type is listed in Table 1. 6. References [RFC2960] 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. [ADD-IP] Stewart, R., Xie, Q., Thuexen, Q., Maruyama, S., Kozuka., M "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", draft-ietf-tsvwg-sctp-addip- sctp-17 (work in progress), November 28 2006. Authors' Addresses Michio Honda Keio University 5322 Endo Fujisawa Kanagawa Japan Email: micchie@sfc.wide.ad.jp Yoshifumi Nishida Sony CSL Inc. 3-14-13 Higashigotanda Shinagawa-ku Tokyo Japan Email: nishida@csl.sony.co.jp Masahiro Kozuka Kyoto University Yoshida-Honmachi Sakyo-ku Kyoto Japan Email: ma-kun@kozuka.jp Full Copyright Statement Copyright (C) The IETF Trust (2006). 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, 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. 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.