Internet DRAFT - draft-iaydin-cshen-cellular-sctp
draft-iaydin-cshen-cellular-sctp
Network Working Group I. Aydin
Internet-Draft C. Shen
Expires: April 25, 2004 University of Delaware
October 26, 2003
Cellular SCTP: A Transport-Layer Approach to Internet Mobility
draft-iaydin-cshen-cellular-sctp-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 April 25, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes a transport-layer mobility solution for the
Internet termed Cellular SCTP, or cSCTP for short, based on the
emerging Stream Control Transmission Protocol (SCTP). We suggested to
use `two primary addresses simultaneously' by duplicating the packet
transmissions (while halving the transmission rate) during handoff to
provide `soft' handover. Moreover, we described the inter-working of
cSCTP with Session Initiation Protocol (SIP) to facilitate location
management function when Correspondent Nodes (CNs) initiate the
associations and need to locate Mobile Nodes (MNs).
Aydin & Shen Expires April 25, 2004 [Page 1]
Internet-Draft Cellular SCTP October 2003
Table of Contents
1. Conventions & Terminology . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Cellular SCTP (cSCTP) . . . . . . . . . . . . . . . . . . . 4
3.1 Cellular SCTP Components . . . . . . . . . . . . . . . . . . 5
3.2 Cellular SCTP Handover Mechanism . . . . . . . . . . . . . . 6
3.2.1 Detecting and Obtaining a New IP Address . . . . . . . . . . 6
3.2.2 Adding the New IP Address into the Association . . . . . . . 6
3.2.3 Data Transfer During Handover . . . . . . . . . . . . . . . 7
3.2.4 Deleting Old IP Address from the Association . . . . . . . . 8
4. Inter-operation of cSCTP and SIP for Location Management . . 9
5. Further Considerations for cSCTP Mechanisms . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . 11
Normative References . . . . . . . . . . . . . . . . . . . . 11
Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12
A. Finite State Machine Diagrams . . . . . . . . . . . . . . . 12
B. Changes in the Finite State Machine Diagrams to Reflect
Inter-operation with SIP . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 16
Aydin & Shen Expires April 25, 2004 [Page 2]
Internet-Draft Cellular SCTP October 2003
1. Conventions & Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
RFC2119 [1].
In this document `cSCTP' is short for `Cellular SCTP'.
For formal definitions of Mobile Node (MN), Correspondent Node (CN),
Access Router (AR), refer to [5].
Handover (or handoff) are used interchangeably in this document.
During a handover, Mobile Node (MN) changes its point of attachment
to the Internet. But it should still be possible for the MN to
transmit and receive packets with minimum service disruption.
2. Introduction
Wide spread use of mobile computing and wireless communication
devices has signified the need of `host mobility' support in the
Internet.
Traditionally, Mobile IP [5] supports host mobility at the network
layer by deploying special functioning routers (Home and/or Foreign
Agents) into the network to keep track of current location of the
mobile host, and hence be able to route the packets destined for the
mobile host to its current location (usually by means of tunelling).
In contrast, Mobile SCTP [6], or mSCTP for short, has proposed a
`transport' layer approach to host mobility based on the Stream
Control Transmission Protocol (SCTP), RFC 2960 [2].
SCTP is a new, general-purpose transport layer protocol originally
designed to transport telephony signaling messages over IP networks.
Like TCP, SCTP provides a connection oriented, reliable service.
Moreover, SCTP provides two core features that benefit not only
telephony signaling applications but also other Internet and wireless
networking applications: `multi-homing' and `multi-streaming'.
SCTP multi-homing allows a transport layer connection (an association
in SCTP terminology) to be defined between a set of local IP
addresses and a set of remote IP addresses. If connectivity is lost
on the primary IP address being used for the association, the
association seamlessly fails over to an alternate IP address. SCTP
multi-streaming allows data to be partitioned into multiple streams,
and each stream to be sequentially delivered to the destination end
point independently of the other streams. Hence, a packet loss in one
Aydin & Shen Expires April 25, 2004 [Page 3]
Internet-Draft Cellular SCTP October 2003
stream does not incur head-of-line blocking to other streams.
In particular, mSCTP extends the base SCTP to facilitate mobility in
the Internet at the transport layer.
Basically, mSCTP states that both Mobile Node (MN) and Correspondent
Node (CN) need to support the `Dynamic Address Reconfiguration'
extension [3] to SCTP for seamless handover.
The base SCTP protocol allows a set of IP addresses at both source
and destination end points to be decided in the association
establishment phase. However, Dynamic Address Reconfiguration
extension allows two SCTP end-points to add new IP addresses into and
delete IP addresses from an active association as well as to set the
primary IP address of the association with the help of newly defined
ASCONF (Address Configuration Change) and ASCONF-ACK (Address
Configuration Acknowledgment) chunks.
In this document, we propose another SCTP-based approach for Internet
host mobility support termed Cellular SCTP, or cSCTP for short,for a
better handoff performance. We define and describe the components and
the handover mechanism of Cellular SCTP. We also describe the
inter-working of cSCTP with SIP (Session Initiation Protocol) [4] to
let the Correspondent Nodes (CNs) locate the Mobile Nodes (MNs), in
case CNs want to initiate associations with MNs.
This document is intended to continue discussion to explore the use
of SCTP for host mobility support in the Internet. Please send
comments to the mailing list <mobile@sctp.de>. To subscribe to this
mailing list, please send an e-mail to <mobile-request@sctp.de>.
3. Cellular SCTP (cSCTP)
In the following subsections we will describe the components and the
handover mechanisms of Cellular SCTP.
Figure 1 shows a sample scenario. In the figure, handover happens
when MN is moving from Access Router 1 (AR1) to AR2 while
communicating with the CN.
+=========================+
########## | Correspondent Node (CN) |
# Router #---- +=========================+
########## | layer5: SIP User Agent |
****************** || |_________________________|
*** *** || | layer4: cSCTP |
** *** |_________________________|
** the Internet ** | . |
Aydin & Shen Expires April 25, 2004 [Page 4]
Internet-Draft Cellular SCTP October 2003
** ** | . |
** ** | . |
*** **** |_________________________|
|| ****************** ||
|| ||
####### #######
# AR1 # # AR2 #
####### #######
|
|
|
+========================+
| Mobile Node (MN) |
+========================+
| layer5: SIP User Agent |
|________________________|
| layer4: cSCTP |=====> moving to AR2
|________________________|
| layer3: Host-Agent |
|________________________|
| . |
| . |
| . |
|________________________|
Figure 1
3.1 Cellular SCTP Components
As depicted in Figure 1, a Cellular SCTP-equipped MN has three main
components:
o The Host-Agent component operating in Layer 3, communicates with
ARs mainly to help the cSCTP component learn about reaching a new
AR and/or leaving the previous AR. The Host-Agent component can
also help cSCTP to obtain physical layer information such as the
strength of the wireless signal to be used for change of the
primary IP address(es) to the MN.
o The cSCTP component in Layer 4 is basically an SCTP protocol
entity with the dynamic address reconfiguration extension [3] plus
the handover procedure described in Section 3.2.
o Finally at the application layer, a SIP User Agent is executed to
facilitate the location management functionality (later described
in Section 4).
Aydin & Shen Expires April 25, 2004 [Page 5]
Internet-Draft Cellular SCTP October 2003
A Cellular SCTP-equipped CN will also have a corresponding cSCTP
component and a SIP User Agent running at the transport layer and the
application layer, respectively. In addition, each AR will need to
support a neighbor discovery protocol such as in [7].
3.2 Cellular SCTP Handover Mechanism
Following four subsections describe the handover mechanism of
Cellular SCTP.
3.2.1 Detecting and Obtaining a New IP Address
The Host-Agent component of MN and ARs communicate via a neighbor
discovery protocol, such as in [7].
The Host-Agent sends ROUTER SOLICITATION messages and ARs send
ROUTER ADVERTISEMENT messages. With the help of DHCP or Stateless
Address Auto-configuration, the Host-Agent component eventually
obtains a new IP address in the new point of attachment (AR2
according to Figure 1).
3.2.2 Adding the New IP Address into the Association
After obtaining a new IP address in the new point of attachment, the
Host-Agent component informs the cSCTP component of MN about the new
IP address.
cSCTP introduces a new boolean variable per SCTP association, termed
`handoff_mode'. After cSCTP of the MN learns the existence of the new
IP address, handover starts, and the cSCTP component of MN performs
the following.
o sets its handoff_mode to TRUE.
o sends an ADD-IP ASCONF chunk to the CN to inform the CN about the
start of the handoff mode, and to let the CN add the new IP
address into the association.
To do so, we used one of the `Chunk Flags' of the ASCONF (and also
of the corresponding ASCONF-ACK) chunk to notify the CN about the
start of the handoff mode at the MN. We use one bit (H) of the
Chunk Flags to indicate the start of handoff mode as shown in
Figure 2.
o adds the new IP address into the association.
Aydin & Shen Expires April 25, 2004 [Page 6]
Internet-Draft Cellular SCTP October 2003
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 = 0xC1 | Chunk Flags |H| Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ .... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
Upon receiving the ADD-IP chunk with handoff_mode flag set, CN does
the following.
o sets its handoff_mode to TRUE.
o adds the new IP address into the association.
o both the old IP address of MN and the newly added IP address are
considered as primary addresses to MN. (At this point CN sees the
MN as a multi-homed endpoint).
Congestion window value (cwnd) for each of these primary addresses
is set to be `half' of the cwnd value of the old primary IP
address to the MN. Note that SCTP maintains a separate set of
congestion control parameters for each path if host is
multi-homed.
3.2.3 Data Transfer During Handover
(Direction of data transfer is assumed to be from CN to MN to
simplify explanation.)
CN duplicates and sends packets to `both' of the primary addresses
for MN in the rate of newly calculated, reduced cwnd value.
Therefore, the same data will be transferred to the MN `via two
different paths', to reduce the probability that MN would miss the
data packets sent by the CN.
Aydin & Shen Expires April 25, 2004 [Page 7]
Internet-Draft Cellular SCTP October 2003
There are two motivations/scenarios to advocate the duplicates:
1. In the case where the old and the new attachment points of MN to
the Internet are close to each other (i.e., both access routers
are within the same ISP, for instance), most likely only the last
hop (i.e., the wireless hop) to the MN would change.
If (as in Mobile SCTP [6]) either the old or the new IP address
is used as the primary address to the MN at a time, before MN
sets the new IP address to be the primary IP address of the
association, data packets would be sent to the old IP address.
However, if MN is not reachable by the old IP address anymore,
cwnd of the old IP address would be set to one MTU (due to
timeout, and hence back to slow start at the old IP address), and
then the retransmissions would be sent to the newly added IP
address in the rate of a newly growing cwnd value for the new IP
address. This situation would result in delays and decrease the
performance of the SCTP association unnecessarily because the
reason for retransmissions would not be due to the congestion in
the path from CN to MN but due to MN's moving from one access
point to another.
2. Furthermore, in the case where MN moves to access point B from
access point A, stays in access point B for a little time, moves
back to access point A again, and repeats this movement pattern,
each handoff would degrade the transmission rate of the CN due to
timeouts and re-transmissions.
Whereas, by duplicating the data transfer during the handoff mode in
cSCTP, we aim to mitigate these negative effects. However, some
related issues arise. Discussions on these issues are given in
Section 5.
3.2.4 Deleting Old IP Address from the Association
When finally MN decides that the old IP address is inactive (by means
of not receiving any data from the CN via the old IP address or
Host-Agent informing the cSCTP at the MN about not receiving any
Router Advertisements from the old Access Router, etc.), MN exits the
handoff mode by performing the following actions.
o sets its handoff_mode to FALSE.
o removes the old IP address from the association.
o sends a DELETE-IP ASCONF chunk with handoff_mode flag set to
FALSE, to the CN.
Aydin & Shen Expires April 25, 2004 [Page 8]
Internet-Draft Cellular SCTP October 2003
Upon receiving the DELETE-IP ASCONF chunk, CN performs the following.
o also exists the handoff mode by setting handoff_mode to FALSE.
o removes the old IP address from the association.
o uses the new IP address as the primary address to the MN.
Appendix A depicts the finite-state-machine diagrams that summarize
the steps during the cSCTP handover process.
4. Inter-operation of cSCTP and SIP for Location Management
One key design objective of cSCTP is have a transport layer mobility
solution that is completely independent of network layer support such
as Mobile IP. To facilitate location management when CNs initiate the
associations and need to locate MNs, the location management function
of SIP [4] can be used by the CN to retrieve the (current)
location(s)/address(es) of the callee (MN in our case).
The main components of SIP include `User Agents' (which initiates the
requests and produces corresponding responses on behalf of the
users),`Proxy Servers',`Redirect Servers', and `Registrar Servers'.
The ways Proxy and Redirect servers process the (INVITE) requests by
callers differ. For our purpose of locating the callee (i.e., MN),
the redirect server would be sufficient. Registrars are the servers
that users register their current location(s) with.
The inter-working of cSCTP and SIP to locate a MN is as follows.
o Each MN runs a SIP User Agent at its application layer. Whenever
the MN obtains a new IP address, the SIP User Agent registers the
new IP address with the local Registrar server(s) by using SIP
REGISTER request (For the details of how the local registrar
server(s) are located by User Agent, see Section 4.2.6 of [4].).
The two important fields of the REGISTER's request-header for the
purpose of location registration are `To' and `Contact'.
`Objects' in SIP are addressed as `users at hosts' similar to an
email address, identified by SIP URLs, such as user@host. Hence,
the `To' and `Contact' fields of the REGISTER's request-header
needs to be filled with such a proper SIP syntax. The `To' field
will contain the "name" of the MN and the `Contact' field will
contain the new IP address of the MN.
For instance, the MN in Figure 1, can be given a name
<sip:MN1@adhocNetwork.org> in the `To' field. Note that the value
Aydin & Shen Expires April 25, 2004 [Page 9]
Internet-Draft Cellular SCTP October 2003
of user and the host parts of the name of the MN is not important
for our purpose. We just want to "name" the MN in a SIP-suitable
way.
If MN moves to the network of AR2, and receives a new IP address,
let's say 10.1.2.3, then the `Contact' field of the REGISTER
request could contain address <sip:MN1@10.1.2.3>. Again, the value
of the user part of the address is not important for our purpose.
o CNs will also run SIP User Agents at the application layer. A CN,
who wants to initiate an association with a MN, will send a SIP
INVITE request to the local redirect server for MN. For the
details of how a caller (CN in our case) locates a SIP server,
refer to Section 1.4.2 of [4].
CN will need to give the "name" of MN in the `Request-URI' (and
the `To' field) of the SIP INVITE request. Continuing with the
same example, CN will write <sip:MN1@adhocNetwork.org> into the
`Request-URI' of the INVITE request. Then, eventually the redirect
server, contacting with the location service, will return the
current location(s) of the MN to the CN (i.e., only
<sip:MN1@10.1.2.3> in this case). SIP User Agent at the CN
receiving the response from redirect server, will send the
response to the cSCTP layer, where the response is processed
further and finally the current location(s) of the MN is decided.
Then, the cSCTP layer of the CN will use the current location(s)
of MN to initiate an association with the MN.
Appendix B shows the complete finite-state-machine diagrams after
changes to the finite-state-machine diagrams of Appendix A are added
to describe the mechanisms to support location management as
explained in this section.
5. Further Considerations for cSCTP Mechanisms
o In cSCTP, the transmission rate during handover is NOT cut less
than half of the cwnd for the old IP address of MN. If the new and
the old access points are NOT close to each other (for instance,
in the same ISP) as in scenario (1) of Section 3.2.3, the policy
of NOT reducing the cwnd value less than half of the cwnd for the
old IP address, would be a little "aggressive". Therefore, we
should figure out a way to see access points are close enough to
each other to apply policy.
o Because of the policy of duplicating the data transfer during
handover, MN can get the data from either old, new, or both IP
addresses. Therefore, we need to elaborate the mechanism on how MN
would progress its cwnd value(s) and TSN for such cases.
Aydin & Shen Expires April 25, 2004 [Page 10]
Internet-Draft Cellular SCTP October 2003
o During the handover management, Cellular SCTP uses the
multi-homing property of SCTP; however, a combination of
multi-homing and multi-streaming during handover with better load
balancing techniques would bring benefit and requires further
investigation.
o Cellular SCTP handles associations initiated from MN to CN and
vice versa. But for a complete solution, associations initiated
from a MN to another MN needs to be considered.
6. Security Considerations
This document discusses Cellular SCTP mechanisms for seamless
handover and location management (by inter-operating with SIP). The
related security issues will be identified and addresses in the
future.
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., Rytina, I.,
Belinchon, M. and P. Conrad, "Stream Control Transmission
Protocol (SCTP) Dynamic Address Reconfiguration,
draft-ietf-tsvwg-addip-sctp-08.txt", September 2003.
[4] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
Informative References
[5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6, draft-ietf-mobileip-ipv6-24.txt", June 2003.
[6] Riegel, M. and M. Tuexen, "Mobile SCTP,
draft-riegel-tuexen-mobile-sctp-03.txt", August 2003.
[7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
Aydin & Shen Expires April 25, 2004 [Page 11]
Internet-Draft Cellular SCTP October 2003
Authors' Addresses
Ilknur Aydin
University of Delaware
Department of Computer & Information Sciences
103 Smith Hall
Newark, DE 19716
USA
Phone: +1 302 831 1131
EMail: aydin@cis.udel.edu
URI: http://www.cis.udel.edu/~aydin
Chien-Chung Shen
University of Delaware
Department of Computer & Information Sciences
103 Smith Hall
Newark, DE 19716
USA
Phone: +1 302 831 1951
EMail: cshen@cis.udel.edu
URI: http://www.cis.udel.edu/~cshen
Appendix A. Finite State Machine Diagrams
Figure 3 and Figure 4 show the Finite State Machine (FSM) diagrams
for MN and CN respectively. Dotted (....>) arrows in the FSM diagrams
show some other paths from one state to another.
In both Figure 3 and Figure 4, before any handoff occurs (i.e.,
ESTABLISHED mode entered by following the dotted arrow), the
association is defined by {[m1],[c1]} (i.e., both MN and CN are
single-homed and primary address for MN is m1 and primary address for
CN is c1).
.
.
association:{[m1],[c1]}
.
. +-----------------+
..............> | ESTABLISHED |
+-----------------+
^ |
| |
old IP address m1 | | new IP address m2
Aydin & Shen Expires April 25, 2004 [Page 12]
Internet-Draft Cellular SCTP October 2003
became inactive | | is obtained
-------------------------- | | ---------------------
o handoff_mode = FALSE | | o handoff_mode = TRUE
o send DELETE-IP(m1) | | o send ADD-IP(m2)
with H flag FALSE, | | with H flag TRUE,
to CN | | to CN
o association:{[m2],[c1]} | | o association:{[m1,m2],[c1]}
| v
+-----------------+
| HANDOFF |
+-----------------+
Figure 3
.
.
association:{[m1],[c1]}
.
. +-----------------+
...........> | ESTABLISHED |
+-----------------+
^ |
| |
receive DELETE-IP(m1) | | receive ADD-IP(m2)
with H flag FALSE, from MN | | with H flag TRUE, from MN
--------------------------- | | ----------------------------
o handoff_mode = FALSE | | o handoff_mode = TRUE
o association:{[m2],[c1]} | | o set m1 and m2 as primary IP
| | addresses for MN
| | o association:{[m1,m2],[c1]}
| | o cwnd = cwnd(m1)/2
| | o cwnd(m1) = cwnd(m2) = cwnd
| v
+-----------------+
| HANDOFF |
+-----------------+
Figure 4
Appendix B. Changes in the Finite State Machine Diagrams to Reflect
Inter-operation with SIP
Figure 5 and Figure 6 shows the completed FSM diagrams after changes
to the FSM diagrams of Appendix A is added to reflect inter-operation
of cSCTP and SIP as described in Section 4.
Aydin & Shen Expires April 25, 2004 [Page 13]
Internet-Draft Cellular SCTP October 2003
.
.
association:{[m1],[c1]}
.
. +-----------------+
..............> | ESTABLISHED |
+-----------------+
^ |
| |
old IP address m1 | | new IP address m2
became inactive | | is obtained
-------------------------- | | ---------------------
o handoff_mode = FALSE | | o handoff_mode = TRUE
o send DELETE-IP(m1) | | o send ADD-IP(m2)
with H flag FALSE, | | with H flag TRUE,
to CN | | to CN
o association:{[m2],[c1]} | | o association:{[m1,m2],[c1]}
o de-register with SIP | | o register with a SIP registrar
| |
| v
+-----------------+
| HANDOFF |
+-----------------+
Figure 5
+---------------+ SIP INVITE for MN +-----------------+
| CLOSED |------------------------------> | WAIT_LOCATION |
+---------------+<----------------------------- +-----------------+
. response from SIP registrar server
.
association:{[m1],[c1]}
.
. +-----------------+
...........> | ESTABLISHED |
+-----------------+
^ |
| |
receive DELETE-IP(m1) | | receive ADD-IP(m2)
with H flag FALSE, from MN | | with H flag TRUE, from MN
--------------------------- | | ----------------------------
o handoff_mode = FALSE | | o handoff_mode = TRUE
o association:{[m2],[c1]} | | o set m1 and m2 as primary IP
| | addresses for MN
| | o association:{[m1,m2],[c1]}
| | o cwnd = cwnd(m1)/2
Aydin & Shen Expires April 25, 2004 [Page 14]
Internet-Draft Cellular SCTP October 2003
| | o cwnd(m1) = cwnd(m2) = cwnd
| v
+-----------------+
| HANDOFF |
+-----------------+
Figure 6
Aydin & Shen Expires April 25, 2004 [Page 15]
Internet-Draft Cellular SCTP October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
Aydin & Shen Expires April 25, 2004 [Page 16]
Internet-Draft Cellular SCTP October 2003
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Aydin & Shen Expires April 25, 2004 [Page 17]
