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]