Internet DRAFT - draft-dpkim-msctp-single
draft-dpkim-msctp-single
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]
