Network Working Group M. Honda
Internet Draft Keio Univ.
<draft-micchie-tsvwg-fastmsctp-00.txt> 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
<draft-micchie-tsvwg-fastmsctp-00.txt>
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.