Internet DRAFT - draft-huang-tsai-mmp-sctp
draft-huang-tsai-mmp-sctp
Network Working Group C.M. Huang
Internet-Draft C.H. Tsai
National Cheng Kung University
Octobor 2006
Mobile Multi-path Transmission using SCTP
draft-huang-tsai-mmp-sctp-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 Month Day, Year.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
In this draft, MMP-SCTP (MMP: Mobile Multi-Path) is proposed to allow
a host to improve the transmission throughput in wireless mobile
networks using simultaneous multi-path transmission of Stream Control
Transmission Protocol. Relevant mobility issues of MMP-SCTP included
are: (1) data transmission modes and path selection, (2) multi-path
handover, and (3) location management. Two transmission modes of MMP-
Huang and Tsai Expires April 20, 2007 [Page 1]
Internet-Draft MMP-SCTP Octobor 2006
SCTP, i.e., the "Data-duplicating Mode" and "Data-striping Mode", and
the switching mechanism, are designed to enhance transmission
throughput for different wireless link status. Since the transmission
paths used for MMP-SCTP may differ when an MMP-SCTP host moves, the
multi-path handover problem is defined, and a multi-path handover
mechanism for MMP-SCTP is proposed. Additionally, a location
management scheme is also designed in this draft to tackle the
locating of an MMP-SCTP host.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. SCTP mobility . . . . . . . . . . . . . . . . . . . . . 2
1.2. SCTP multi-path transmission . . . . . . . . . . . . . . 3
1.3. Mobile multi-path transmission using SCTP . . . . . . . 3
2. Transmission modes and path selection of MMP-SCTP . . . . . 3
2.1. Data-striping and data-duplicating . . . . . . . . . . . 3
2.2. Calculation of transmission errors . . . . . . . . . . . 4
2.3. Path selection . . . . . . . . . . . . . . . . . . . . . 5
2.4. MMP-SCTP architecture . . . . . . . . . . . . . . . . . 6
3. Multi-path handover . . . . . . . . . . . . . . . . . . . . 7
3.1. Path handover . . . . . . . . . . . . . . . . . . . . . 7
3.2. Issues related to path handover . . . . . . . . . . . . 7
3.2.1. Spurious retransmissions . . . . . . . . . . . . . . 7
3.2.2. Retransmissions of lost data . . . . . . . . . . . . 8
3.2.3. Reordering problem . . . . . . . . . . . . . . . . . 9
3.3. Modifications to SCTP . . . . . . . . . . . . . . . . . 10
3.4. Multi-path handover procedure . . . . . . . . . . . . . 12
4. Location management of MMP-SCTP . . . . . . . . . . . . . . 13
5. Further considerations . . . . . . . . . . . . . . . . . . . 15
6. Security considerations . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . 18
1. Introduction
1.1. SCTP mobility
Stream Control Transmission Protocol (SCTP) [1] is a transport layer
protocol that supports multihoming in nature. The SCTP ADDIP
Extension [2] enables an SCTP endpoint to dynamically add a new IP
address, delete unnecessary IP addresses, and change the primary IP
address used for the association without terminating the
corresponding association. A new SCTP chunk that the SCTP ADDIP
Extension introduces is the SCTP ASCONF (Address Configuration
Huang and Tsai Expires April 20, 2007 [Page 2]
Internet-Draft MMP-SCTP Octobor 2006
Change) chunk. The SCTP ASCONF chunk is used to notify the
corresponding event to the remote endpoint when one of the events
such as ADD (to add a new IP address), DELETE (to delete an
unnecessary IP address), or CHANGE (to change the primary path)
occurs in an ongoing association. With the functions provided by SCTP
ADDIP Extension, SCTP becomes more powerful when it is adopted in
wireless mobile networks. Some researches of mobile SCTP (mSCTP),
which is based on the SCTP ADDIP Extension, are also proposed to
enable the mobility support of SCTP [3][4].
1.2. SCTP multi-path transmission
Currently, some researches are proposed to enable SCTP to transmit
data through multiple paths to improve transmission throughput, e.g.,
SCTP CMT (Concurrent Multipath Transfer), IPCC-SCTP, LS-SCTP, and
Westwood SCTP. Some experiments and evaluations are done on these
works to prove the value of transmitting data through multiple paths
concurrently.
1.3. Mobile multi-path transmission using SCTP
The main scope of this draft is to investigate relevant issues of
multi-path transmission using SCTP in wireless mobile networks, and
try to propose a protocol extension of SCTP, namely, MMP-SCTP. MMP-
SCTP has two kinds of transmission modes, i.e., data-striping mode
and data duplicating mode. In this draft, a transmission mode
switching mechanism is proposed to improve the throughput under
different wireless network status. Furthermore, a possible path
selection policy that is used to select the paths used by MMP-SCTP is
also proposed in this draft.
The scope of this draft also includes the mobility managments, i.e.,
handover management and location management of MMP-SCTP. We define
"path handover", investigates its relevant issues, and modify SCTP to
resolve the issues. As the extended work of path handover, the
procedures of "multi-path handover" are proposed. Addtionally,
according to the requirements of MMP-SCTP, a location management
scheme is also proposed in this draft to tackle the locating of an
MMP-SCTP host.
2. Transmission modes and path selection of MMP-SCTP
2.1. Data-striping and data-duplicating mode
The data-striping mode is designed to greedily improve the throughput
if the status of the wireless network is good, e.g., the multihomed
host stays in a fixed place and signal strengths of wireless links
Huang and Tsai Expires April 20, 2007 [Page 3]
Internet-Draft MMP-SCTP Octobor 2006
used for multi-path transmission are strong. On the other hand, the
data-duplicating mode is designed to improve the reliability when (i)
the status of the wireless network is bad, e.g., the multihomed host
is about to handover from one BS (Base Station) to another one, (ii)
signal strengths of all wireless links used for multi-path
transmission are weak, or (iii) some wireless links are congested.
The way of deciding which mode to adopt is based on the status of the
links used for MMP-SCTP. The status of MMP-SCTP is on the basis of an
SCTP association. MMP-SCTP determines the status of an association by
calculating the amount of transmission errors of all paths used for
mobile multi-path transmission. A data duplicating threshold is used
by MMP-SCTP to switch from the data-striping mode to the data-
duplicating mode. However, since the number of accessible networks
may be changed when the host moves, the number of transmission paths
used for MMP-SCTP may also vary. When more transmission paths are
used, the data duplicating threshold should be larger. Thus, the
threshold should vary according to the number of transmission paths
used for MMP-SCTP. In our design, a configurable threshold is used to
represent the tolerable transmission errors for a single path. The
multiplication of the threshold and the number of transmission paths
used for MMP-SCTP is the data duplicating threshold.
2.2. Calculation of transmission errors
On the calculation of the amount of transmission errors of all paths,
the use of the SCTP error counter is adopted in our design. An SCTP
endpoint keeps an association-based counter on the total number of
consecutive retransmissions to it peer, including retransmissions to
all the destination transport addresses of the peer if it is
multihomed. When the value of the error counter exceeds the data
duplicating threshold, it means that the status of the wireless
network is bad and thus the data-duplicating mode should be triggered
to improve transmission reliability.
The association-based error counter calculates the summation of the
path-based error counter. In base SCTP, the path-based error counter
is kept by an endpoint for each of the destination transport
addresses of the peer endpoint. The path-based error counter
increments when a retransmission occurs, or when an HEARTBEAT sent to
an idle address is not acknowledged within one RTO (retransmission
timeout). Since the support of PR-SCTP (Partial Reliability SCTP)
makes it possible for an SCTP association to transmit partially
reliable data within an SCTP association, the calculation of
transmission errors must consider both reliable and unreliable
transmissions of SCTP. SCTP uses SACKs for its reliable transmission.
Let the data be transmitted using reliable transmission when a packet
is lost, retransmission of the packet will be processed when the
Huang and Tsai Expires April 20, 2007 [Page 4]
Internet-Draft MMP-SCTP Octobor 2006
transmission timer expires or when 4 consecutive SACKs reporting the
data are missed. On the contrary, since SCTP unreliable transmission
does not do retransmission when the data is lost, it will lack the
knowledge about the status of the link. Thus, in our design, HB
(Heartbeat) chunks are sent periodically on the paths that apply
unreliable data transmission. Although the unreliable transmission
is per-stream-based and multiple streams can reside within a single
path, the transmission of HBs are per-path-based. Thus, for
unreliable transmission, the transmission error counter increases
when an HB is sent but non HBack is received when the RTO expires.
2.3. Path selection
When the total number of available transmission paths is larger than
the number of paths/network interfaces that needs to be used for MMP-
SCTP, a path selection mechanism is needed to select which paths
should be used. The path selection mechanism can be triggered in the
following conditions:
1. Association initiation: the initial setup of an association in a
multihomed host to start the data transmission.
2. New path added: a new path is discovered as available and added
into the association.
3. Path inactive: A path that is used by MMP-SCTP is determined as
"inactive" by the association.
In condition "Association Initiation", when the multihomed host is
going to setup an association, the multihomed host connects to its
peer endpoint using one of its available addresses. Then the
multihomed host exchanges the information of all available IP
addresses with its peer endpoint in initialization. When the
initialization is complete, MMP-SCTP triggers the path selection
mechanism to select the paths to use for the following transmission.
Condition "New path added" occurs when the multihomed host moves and
discovers a new AP/AR of a different domain that is accessible.
Therefore, the multihomed host can obtain a new address via DHCP or
IPv6 address auto-configuration and add the new transmission path
into the association. In order to aggressively improve transmission
throughput, the path selection mechanism can be triggered to
determine whether the newly added transmission path is better than
the one/ones that is/are currently used. Condition "Path inactive"
occurs when one of the transmission paths that is used for MMP-SCTP
repeatedly fails in transmitting data and determined as "inactive" by
the association. Thus, MMP-SCTP triggers the path selection mechanism
to select another transmission path to replace the failed one.
Huang and Tsai Expires April 20, 2007 [Page 5]
Internet-Draft MMP-SCTP Octobor 2006
The definition of primary path in original SCTP is the destination
and source address that will be put in the packet outbound to the
peer endpoint by default. Our proposed MMP-SCTP transmits data using
multiple primary paths at the same time. Thus the path selection
mechanism of MMP-SCTP evaluates all source-destination address pairs
and select the better ones to transmit data. As for the metrics to
evaluate transmission paths, one possible solution for the path
selection problem is to refer to the round trip delay values of paths
in an SCTP association (a smaller round trip delay possibly implies
better link status). An SCTP association monitors the the status of
all transmission paths, including the primary path that is used to
transmit data and the paths that are not currently used to transmit
data. In our proposed MMP-SCTP, multiple primary paths are allowed
within an SCTP association to simultaneously transmit data either in
data-striping mode or data-duplicating mode. The round trip delay
values of the primary paths of MMP-SCTP can be calculated with the
received SACK chunks sent by the peer host. For the paths that are
not currently used to transmit data, HEARTBEAT chunks are sent to
determine whether these paths are active or inactive. Therefore, the
round trip delays of the paths that are active but not currently in
used can be calculated with the received HEARTBEAT-ACK chunks sent by
the peer endpoint. When all round trip delays of active paths are
calculated, better transmission paths can be determined after a
simple comparison, and thus these paths can be selected for the
further data transmission of MMP-SCTP.
2.4. MMP-SCTP architecture
According to the aforementioned functions and the path selection
conditions, some modifications are made on base SCTP to support the
capabilities, i.e., mobile multi-path transmission and path
selection, of MMP-SCTP. Modifications made on base SCTP are (1) a
data dispatcher at the sender, (2) a path selector ar the sender, and
(3) virtual buffers at both the sender and the receiver. The data
dispatcher at the sender is responsible for the assignments of
striped data that are to be transmitted to the paths selected by the
path selector in an MMP-SCTP association. As it is defined in
RFC2960, CWND (Congestion Control Window), SSTHRESH (Slow-start
Threshold), and RTO (Retransmission Timeout) of MMP-SCTP are
maintained on a per-destination address basis. The data that are to
be transmitted through a specific path will be assigned to the
virtual buffer of the path by indexing the tsn with a path ID. Thus,
when a tsn in the association buffer is being to be transmitted, the
path ID of the tsn will be checked first and then the tsn will be
transmitted through the specified path.
Huang and Tsai Expires April 20, 2007 [Page 6]
Internet-Draft MMP-SCTP Octobor 2006
3. Multi-path handover
3.1. Path handover
While the path selection mechanism is triggered, a specific number of
paths will be selected for the subsequent transmission ofMMP-SCTP.
Since the path selection mechanism may be triggered in an ongoing
association, a path handover mechanism is needed if the selected
path(s) differ from the previously used ones. When an MMP-SCTP host,
which formerly uses transmission path-1 and transmission path- 2,
uses transmission path-1 and transmission path-3 after the path
selection mechanism is triggered, transmission path-3 will replace
transmission path-2 to transmit data thereafter. In other words,
there is a "path handover" between transmission path-2 and
transmission path-3. When path handover takes place, the path
handover mechanism terminates the transmission of the path being
replaced. Then the newly selected path inherits the "virtual buffer"
of the old path to tackle the further transmission.
Let's consider the following circumstance. An MMP-SCTP host
originally uses path-1 and path-2 to transmit data to its peer host
simultaneously, and then the path selection mechanism is triggered.
If the selected two paths are both other than path-1 and path-2,
i.e., path-3 and path-4, both path-1 and path-2 have to handover to
path-3 and path-4. We define this condition as "Multi-path Handover".
A new term "Multi-path Handover Pair" is defined as the handover
relationship of the path that is originally used, and the path that
is newly selected by the path selection mechanism. We use "PHP =
[original path-1 -> new path-1, original path-2 -> new path-2, ...]"
to denote the relationship between path handover pairs. For example,
in the previously given example, the path handover pair can be "PHP =
[path-1 -> path-3, path-2 -> path-4]", or "PHP = [path-1 -> path-4,
path-2 -> path-3]". "PHP = [path-1 -> path-3, path-2 -> path-4"
denotes that after the multi-path handover, path-3 will replace
path-1 and path-2 will replace path-4 to transmit data. In MMP-SCTP,
each path is represented with a source-destination address pair. Thus
one clearer example for the multi-path handover relationship can be
"PHP = [(addr s1, addr d1) -> (addr s3, addr d3), (addr s2, addr d2)
-> (addr s4, addr d4)]".
3.2. Issues related to path handover
3.2.1. Spurious retransmissions
Let's consider an example of PHP = [(ip0, ip1) -> (ip0, ip2)], in
which the IP address "ip0" belongs to CN (Corresponding Node) while
Huang and Tsai Expires April 20, 2007 [Page 7]
Internet-Draft MMP-SCTP Octobor 2006
"ip1" and "ip2" belong to the MN (Mobile Node). (For the convenience
of explanation, we assume that each packet carries one data chunk in
the following illustrated examples.) Before path handover occurs at
the sender, a packet (tsn1) is transmitted through the path (ip0,
ip1) and not yet acknowledged when the path handover between (ip0,
ip1) and (ip0, ip2) occurs. According to RFC2960, which states "An
endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
etc.) to the same destination transport address from which it
received the DATA or control chunk to which it is replying." and
"When its peer is multi-homed, the SCTP endpoint SHOULD always try to
send the SACK to the same destination address from which the last
DATA chunk was received.", CN should transmit the SACK for tsn1 to
ip0, that is, through the old path. However, after sender's path
handover, SACKs may not be transmitted through the old path
successfully due to two reasons, i.e., (a) the network interface is
bound to the new path after path handover (currently most of the
802.11 NICs cannot connect to two Access Points to transmit data at
the same time), and (b) the status of the old path may become too bad
to transmit data (this usually happens when the MN moves away from
the originally used AP/AR). Although tsn1 does arrive at CN, tsn1
will still be retransmitted by MN after the retransmission timer
expires due to the loss of the SACK for tsn1, which causes the
spurious retransmission problem of path handover and consequently
causes unnecessary CWND reductions to path destination ip0. To solve
the spurious problem of path handover, SACKs are sent to the MN
through the new path after path handover occurs in MMP-SCTP.
Although transmitting SACK through the new path can solve the
spurious retransmission problem of path handover, it may also cause
another problem. RFC2960 states that "if an endpoint receives a SACK
that advances its Cumulative TSN Ack Point, then it should update its
cwnd (or cwnds) apportioned to the destination addresses to which it
transmitted the acknowledged data.". However, the SACK sent through
the new path after path handover should not be used to credit the
CWND growth of the path destination , or the CWND of the path
destination may overgrow if there are a lot of outstanding packets
transmitted before the path handover occurs. This side effect exists
when the path handover occurs at the sender side. Thus, in MMP-SCTP,
the CWND updating mechanism is also modified to prevent the CWND
overgrowth problem that may possibly be caused by the SACKs of the
data that are transmitted through the old path before path handover.
3.2.2. Retransmissions of lost data
Let's consider another example of PHP = [(ip0, ip1) -> (ip0, ip2)].
Let the packet (tsn1) be originally transmitted through the old path
and be lost, and then a path handover occurs at the sender. Then, the
MN starts to transmit further data (tsn2, tsn3, ...) through the new
Huang and Tsai Expires April 20, 2007 [Page 8]
Internet-Draft MMP-SCTP Octobor 2006
path. When the retransmission timer expires without receiving the
SACK for tsn1, tsn1 should be retransmitted. After path handover, due
to the same two reasons depicted before, i.e., (a) the network
interface is bound to the new path after path handover and (b) the
status of the old path may become too bad to transmit data, the data
that were lost before the path handover may not be retransmitted
successfully through the same (old) path.
In our design, RTO-triggering retransmissions for the packets that
are transmitted through the old paths before path handover are sent
through new paths after path handover. A specific retransmission
policy, e.g., the "RTX-SSTHRESH" policy, which retransmits the data
through the path that has the largest SSTHRESH, can be used to select
one from the new paths for the retransmissions after path handover.
Another issue rises when path handover occurs at the sender. Let's
consider the following situation. MN transmits data using source
address ip1 before path handover and using source address ip2 after
the path handover, to the same destination address ip0. MN surely
also keeps a CWND to destination ip0. When MN transmits tsn1 (which
is lost eventually), a retransmission timer starts. Then path
handover occurs at MN and retransmission timer expires. According to
RFC2960, when the retransmission timer expires, the CWND will be set
to 1 MTU. However, since tsn1 is transmitted through the old path,
the loss of tsn1 should not cause the reduction of CWND after path
handover occurs. In MMP-SCTP, when path handover occurs at the
sender, the mechanisms applied on retransmission timer expiration are
modified to prevent the unnecessary CWND reduction which may cause
serious degradation to transmission efficiency.
3.2.3. Reordering problem
One essential idea of MMP-SCTP is to replace the congested/high-delay
path with the path that has better transmission efficiency. Thus, the
data that are transmitted through the old path before path handover
may arrive at the receiver later than the data that are transmitted
through the new path after path handover, which causes the reordering
problem. The reordering problem then causes further negative side
effect, e.g., unnecessary fast retransmissions at the sender due to
the 4-SACK rule.
Let's consider an example in which three packets (tsn1, tsn2, and
tsn3) are transmitted from MN to CN through a seriously congested
path (ip0, ip1) before the path handover PHP = [(ip0, ip1) -> (ip0,
ip2)] occurs. After the path handover, the MN transmits further
packets (tsn4 and tsn5) through the new path (ip0, ip2), of which the
status is much better than the old path (ip0, ip1). Therefore,
Huang and Tsai Expires April 20, 2007 [Page 9]
Internet-Draft MMP-SCTP Octobor 2006
packets carrying tsn4 and tsn5 arrived at CN sooner than packets
carrying tsn1, tsn2, and tsn3 did, which will cause the reordering
problem. Four consecutive SACKs sent by MN to report the GAP
information will then cause MN to fast retransmit the three tsns
(tsn1, tsn2, and tsn3) immediately and also reduce the CWND as a
result. However, since the gaps are resulted from the transmission
through the old path before the path handover, the GAP report should
not cause the reduction to the CWND of the new path. In MMP-SCTP, the
missing report count updating mechanism is modified to prevent the
unnecessary CWND reductions that may possibly be caused by the
reordering problem induced by path handover.
3.3. Modifications to SCTP
On the basis of the aforementioned issues and design, some
modifications must be made to SCTP to solve the problems and support
the new features of MMP-SCTP. When path handover occurs at MN, MN
must inform its CN of the relationship of the path handover pair
because of the following cases. (1) If MN is the data sender when
path handover occurs, CN must know the relationship of the path
handover pair to transmit SACKs to the new destination address. (2)
If MN is the data receiver when path handover occurs, CN must know
the relationship of the path handover pair to transmit further data
to the new destination address.
The SCTP ADDIP Extension allows an SCTP host to dynamically add,
delete, and change the primary address without terminating the
ongoing association. It introduces two new chunk types, i.e., the
Address Configuration Change Chunk (ASCONF) and the Address
Configuration Acknowledgment (ASCONF-ACK). However, the SCTP ADDIP
Extension is based on one primary path, not for multiple primary
paths. Although the SCTP ADDIP Extension can add newly obtained
address, set the new address as the primary path, and delete the old
address from the association, there is no explicit way to get any
idea of the relationship of the path handover pair if there are
multiple primary paths. Thus, to make the SCTP ADDIP Extension
support multi-path handover of MMP-SCTP, we add a new parameter type,
namely "Path Handover" (Parameter Type code: 0xC007), to the Address
Configuration Parameters of the SCTP ADDIP Extension's ASCONF chunk.
The following figure shows an example of the Path Handover ASCONF
chunk that is transmitted from MN to CN. The Path Handover ASCONF
chunk depicted in Figure 1 is to inform the CN that a path handover
between addresses "10.1.1.1" (Address Parameter #1) and "10.1.2.1"
(Address Parameter #2) occurs at MN. On reception of the Path
Handover ASCONF chunk illustrated in Figure 9, CN should send an
ASCONF-ACK to MN, and then send further SACKs/data to destination
"10.1.2.1", instead of destination "10.1.1.1".
Huang and Tsai Expires April 20, 2007 [Page 10]
Internet-Draft MMP-SCTP Octobor 2006
+-----------------+-----------------+
| Type=0xC007 | Length=20 |
|-----------------+-----------------+
| C-ID=0x01123479 |
|-----------------+-----------------+
| Type=5 | Length=8 |
|-----------------+-----------------+
| Value=0x0a010101 |
| (Address parameter #1) |
|-----------------------------------+
| Value=0x0a010201 |
| (Address parameter #2) |
|-----------------------------------+
Figure 1. An example of "path handover" ASCONF chunk
Additionally, some other modifications must be done to SCTP to solve
the aforementioned problems. We summarize the problems of each issue
as follows:
(I) To eliminate spurious retransmissions, SACKs must be sent to the
new destination address after the path handover occurs at the sender.
(II) The sender's CWND should not grow when receiving the
acknowledgements of the tsns that are transmitted through the old
path before the path handover occurs at the sender.
(III) The retransmissions of the tsns that are transmitted before
path handover should be transmitted through the new paths according
to a specific policy, e.g., the "RTX-SSTHRESH" policy suggested in
[19].
(IV) In the circumstance that path handover occurs at the sender, the
retransmission timer expiration of the data that are transmitted
through the old path before path handover should not cause the CWND
reduction to the path destination after path handover occurs.
(V) The missing report count updating mechanism should be modified to
prevent the consequently unnecessary CWND reduction caused by fast
retransmissions due to the packet reordering problem after path
handover.
The use of the newly introduced Path Handover ASCONF chunk can
resolve (I) and (III), in conjunction with the standard ASCONF chunks
of the SCTP ADDIP Extension. To resolve (II), (IV) and (V), following
modifications to SCTP are made.
(1) The sender marks all outstanding tsns using the additional
Huang and Tsai Expires April 20, 2007 [Page 11]
Internet-Draft MMP-SCTP Octobor 2006
variable "ph_outstanding" defined by MMP-SCTP when it receives a Path
Handover ASCONF/ASCONFACK chunk.
(2) Modifications are made to CWND updating algorithm used by MMP-
SCTP to avoid unfair growth of CWND when receiving a SACK. Variable
"num_acked_tsn" is used to calculate the amount of tsns that are
transmitted to a specific destination and acknowledged by the current
SACK. Variable "num_pho_tsn" is used to calculate how many of the
outstanding tsns, which are transmitted to a specific destination
before path handover occurs, are acknowledged by the the current
SACK. Then, since there are num pho tsn tsns transmitted successfully
through the old path of which the acknowledgements should not be used
to credit the growth of CWND, the sender should increment CWND with
either "num_acked_tsn - num_pho_tsn" or path MTU, whichever is less.
(3) Modifications are made to the actions taken by MMP-SCTP when the
retransmission timer expires. When the retransmission timer expires,
prior to applying the rules stated in RFC2960, MMP-SCTP checks
whether all of the outstanding tsns are transmitted before path
handover occurs or not. Then a new variable "ph_rto" is used to label
whether the retransmission timer expiration is "exactly" caused by
the earliest tsns that are transmitted through the old path before
path handover occurs or not. If "ph_rto" is TRUE, only
retransmissions of the outstanding tsns are done; other rules stated
in RFC2960 to handle RTO are skipped. On the other hand, if "ph_rto"
is FALSE, it means (ano)other tsn(s) is/are missing at the new path
after path handover occurs. All the rules stated in RFC2960 will be
applied.
(4) Modifications are made to tackle the missing report count
updating of MMP-SCTP. When the sender receives a SACK containing GAP
reports, it checks each tsn that is reported as missing to see if the
tsn was transmitted through the old path before path handover occurs,
and then decides whether to increment the missing report for the tsn
or not. In this way, possibly unnecessary fast retransmissions and
consequently unnecessary CWND reductions can thus be avoided.
3.4. Multi-path handover procedure
Except condition "association initiation", in which the multihomed
host selects transmission paths while the association is startup,
both condition "new path added" and condition "path inactive" may be
accompanied with a path handover, or multi-path handover if multiple
paths have to be changed according to the result of the host's path
selection mechanism. For condition "new path added", the MMP-SCTP
multi-path handover procedure is as follows.
Huang and Tsai Expires April 20, 2007 [Page 12]
Internet-Draft MMP-SCTP Octobor 2006
1. The MMP-SCTP host obtains new address(es) from the new AP/AR,
e.g., through IPv6 stateless auto-configuration or DHCP.
2. The host adds the newly formed transmission paths, i.e., the
source-destination address pairs, into the MMP-SCTP association.
3. The MMP-SCTP host triggers the path selection mechanism to select
new paths for transmission.
4. The MMP-SCTP host sends the modified ASCONF chunks to its peer
host, and receives the ASCONFACKs from its peer host.
5. For each path handover pair, the path handover mechanism ofMMP-
SCTP along with the algorithms of MMP-SCTP are executed between the
sender and receiver.
6. The MMP-SCTP host deletes the old path(s) from the association if
it (they) is (are) determined as inactive by the association.
The multi-path handover procedure for condition "Path inactive" is as
follows.
1. The MMP-SCTP association determines one or more specific path(s)
as inactive.
2. The MMP-SCTP host triggers the path selection mechanism to select
new paths for transmission.
3. The MMP-SCTP host sends the modified ASCONF chunks to its peer
host, and receives the ASCONFACKs from its peer host.
4. For each path handover pair, the path handover mechanism of MMP-
SCTP along with the algorithms of MMP-SCTP are executed between the
sender and receiver.
5. The MMP-SCTP host deletes the old path(s) that is(are) determined
as inactive from the association.
4. Location management of MMP-SCTP
The other main issue of IP mobility is location management. Since
SCTP was not originally designed for mobile use, a location
management scheme is needed for a host to locate the peer host that
it wants to set up an association with. However, unlike Mobile IP,
since the ADDIP Extension of SCTP allows an SCTP host to dynamically
Huang and Tsai Expires April 20, 2007 [Page 13]
Internet-Draft MMP-SCTP Octobor 2006
add, delete, and set a new primary path without terminating the
ongoing association, and use the ASCONF chunks to notify the remote
endpoint, SCTP does not need its location management scheme to
provide binding update mechanisms. SCTP only needs the location
management scheme to provide the locating service on SCTP association
initiation. In this Section, a location management scheme that adopts
the DDNS (Dynamic DNS) technique is designed for the proposed MMP-
SCTP.
DDNS is a service that maps Internet domain names to IP addresses.
DDNS serves a similar purpose to DNS: DDNS allows a host to advertise
a public name to prospective users. Unlike DNS that only works with
static IP addresses, DDNS works with dynamic IP addresses, such as
those assigned by an ISP or other DHCP servers. For the following
reasons, we select DDNS as the location management scheme for the
proposed MMP-SCTP.
(1) DNS is a popular technique. It is straight-forward for a host to
initialize its connection by sending a domain name query to locate
its peer host.
(2) Similar to DNS, multiple addresses can be mapped to a single
domain name. Thus DDNS can handle the location information of a
multihomed host without introducing extra identifier for the host.
(3) DDNS is a matured, simple, and easy-to-deploy method.
DDNS is only used to locate the peer host on association
initialization because after the association is setup, MMP-SCTP
itself can manipulate the addition, deletion, and change of the used
addresses between the two peer hosts with the SCTP ADDIP Extension.
What DDNS needs to do is to accept the domain name query from the
host, and reply the addresses mapped to the domain name.
Since the idea of MMP-SCTP is to transmit data through multiple paths
simultaneously, an MMP-SCTP host is multihomed and thus multiple
addresses are configured. Therefore, multiple addresses are mapped to
the MMP-SCTP's host name in the DDNS server's record. When a host
sends a query of the MMP-SCTP host name to the DDNS server, the DDNS
server replies all addresses to the host after matching its domain
name records. To have the the host be able to connect to the MMP-SCTP
host as soon as possible, the longest prefix match principle is
adopted to decide the order of addresses returned to the host. That
is, when the DDNS server receives the domain name query from the
host, it will do a longest prefix match comparison between the
address of the host and the addresses of the MMP-SCTP host. Since the
longest prefix matched address implies that it should be the nearest
one to the host's address, the DDNS server replies the MMP-SCTP
Huang and Tsai Expires April 20, 2007 [Page 14]
Internet-Draft MMP-SCTP Octobor 2006
host's addresses in the order of the longest prefix match degree.
After the host receives the reply, it sends the SCTP INIT chunk to
the first address of the returned ones in the reply. If the host does
not receive an INIT-ACK from the address, the host tries the second
one of the returned addresses to initialize the association. In this
way, the host shall connect to the MMP-SCTP host in an efficient way.
The procedure of manipulating location management using DDNS is as
follows.
1. MMP-SCTP host-A moves in wireless mobile networks and forms its
addresses through the DHCP server or IPv6 address auto-configuration.
2. MMP-SCTP host-A sends a DNS update message to the DDNS server to
update its locations.
3. Another host, namely, MMP-SCTP host-B, wants to communicate with
the MMP-SCTP host-A and sends a name resolution query to the DDNS
server.
4. The DDNS server replies the addresses of the MMP-SCTP host-A after
mapping its DNS records. The order of the returned addresses is
based on the longest prefix match policy.
5. MMP-SCTP host-B initializes the association with MMP-SCTP host-A,
and changes the address in the order of the returned addresses to
send the INIT chunk to, if it is necessary.
6. The association between MMP-SCTP host-A and MMP-SCTP host-B is
setup, and the two MMP-SCTP hosts can transmit data through multiple
paths simultaneously.
7. If MMP-SCTP host-A leaves the coverage of a specific wireless
network, it sends a DNS update message to the DDNS server to discard
the record of the corresponding address.
8. Repeating the above steps.
5. Further considerations
For the practical implementation of MMP-SCTP, path selection should
be performed for each type of the wireless access technology (WAT)
respectively to avoid selecting the link that is not connectable with
the host's network interface. For example, the host equipped with a
802.11g WLAN interface and a 3G/UMTS cellular network interface
should select one WLAN link and one 3G/UMTS link, not two WLAN links
Huang and Tsai Expires April 20, 2007 [Page 15]
Internet-Draft MMP-SCTP Octobor 2006
or two 3G/UMTS links. However, since SCTP is a transport layer
protocol, it cannot determine over what link type of WAT each of the
transmission path is, e.g., the 802.11 WLAN or 3G/UMTS cellular
network. A possible solution is to use the cross layer control
mechanism to cooperate with the path selection mechanism of MMP-SCTP.
In condition "Association initiation", the SCTP association obtains
the type information of each available transmission path through the
network layer and theMAC/PHY layers. Then the association can
categorize the available transmission paths into proper WATs and thus
the path selection mechanism can be successfully performed. In
condition "New path added", when the host detects a new AP/AR, a
notification can be sent to the SCTP association to notify that there
may be new available transmission paths. Then the host disconnects
from the AP/AR that is currently used and connects to the new AP/AR
to determine whether the AP/AR belongs to the same domain. If it
belongs to the same domain, the host can connect to the one that has
the better signal strength; if it belongs to a different domain, the
host forms the IP address for the domain as a new available
transmission path. Then the path selection mechanism can be triggered
to determine if the new path is better than the one that is
originally used, and then use the better one. Condition "Path
inactive" is similar to condition "Association Initiation" because
one or more paths should be evaluated again and selected to replace
the transmission path(s) that is/are determined as "inactive".
6. Security Considerations
Security considerations ane not discussed in this memo.
7. References
[1] R. Stewart, Q. Xie et. al., "Stream Control Transmission
Protocol," RFC 2960, IETF, October 2000.
[2] R. Stewart, M. Ramalho, and Q. Xie et. al., "Stream Control
Transmission Protocol (SCTP) Dynamic Address Reconfiguration," draft-
ietf-tsvwgaddip-sctp-15.txt, May 2006.
[3] M. Riegel, M. Tuexen, "Mobile SCTP," draft-riegel-tuexen-mobile-
sctp-06.txt, October 2004.
[4] S. J. Koh, et al., "Architecture of Mobile SCTP for IP Mobility
Support," draft-sjkoh-sctp-mobility- 02.txt, June 2003
Huang and Tsai Expires April 20, 2007 [Page 16]
Internet-Draft MMP-SCTP Octobor 2006
Author's Address:
Chung-Ming Huang
Dept. of Computer Science and Information Engineering
National Cheng Kung University
Tainan, Taiwan
R.O.C.
Email: huangcm@locust.csie.ncku.edu.tw
Ching-Hsien Tsai
Dept. of Computer Science and Information Engineering
National Cheng Kung University
Tainan, Taiwan
R.O.C.
Email: tsaich@locust.csie.ncku.edu.tw
Huang and Tsai Expires April 20, 2007 [Page 17]
Internet-Draft MMP-SCTP Octobor 2006
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 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 Internet Society (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.
Huang and Tsai Expires April 20, 2007 [Page 18]
