MEXT Working Group K. Wong
Internet-Draft MUST
Expires: January 11, 2009 A. Dutta (Ed.)
Telcordia
H. Schulzrinne
Columbia Univ.
July 10, 2008
Simultaneous Mobility Problem Statement
draft-wong-mext-simultaneous-ps-01
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 January 11, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Wong, et al. Expires January 11, 2009 [Page 1]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
Abstract
This document provides a problem statement for simultaneous mobility
in an infrastructure-based mobility environment. It considers what
the simultaneous mobility problem is and describes the conditions
under which it may occur. It also illustrates the occurrence of the
simultaneous mobility problem in the context of different mobility
protocols such as Mobile IPv6. The simultaneous mobility problem
defined here is strictly applied to scenarios when the intermediary
nodes in the core are not mobile.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What is simultaneous mobility? . . . . . . . . . . . . . . 3
1.2. Likelihood of Simultaneous Mobility . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Simultaneous Mobility Scenarios . . . . . . . . . . . . . . . 7
4. Applicability of simultaneous mobility . . . . . . . . . . . . 10
4.1. Simultaneous Mobility in Mobile IPv4 . . . . . . . . . . . 10
4.2. Simultaneous Mobility in Mobile IPv6 . . . . . . . . . . . 10
4.3. Simultaneous mobility in SIP-based mobility . . . . . . . 14
5. Occurrence of Simultaneous Mobility Problems . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Wong, et al. Expires January 11, 2009 [Page 2]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
1. Introduction
We consider mobility of end (or terminal) hosts in an infrastructure-
based network like the global Internet. Simultaneous mobility is the
special case when two end hosts are mobile and in communications with
each other, and each moves away from one attachment point in the
network to another at, or at about, the same time (we give a more
precise definition in Section 1.1). Although it may not be typical
(more typical would be the case when one of the two hosts moves and
the other hosts within the network remain stationary during that
time), such an event will occur in from time to time, and this must
be handled properly by mobility protocols. The simultaneous mobility
problem, when it occurs, results in the loss of either a binding
update from a Mobile Host, or of some other control message prior to
the sending of the binding update, because the binding update or
prior control message is sent to a previous address of the other
Mobile Host that is also moving at around the same time. Without the
introduction of additional measures to rescue the communications
session, this would be expected to result in the interruption of the
communications session.
1.1. What is simultaneous mobility?
We begin by defining some terms that we will use to define the
simultaneous mobility problem.
Two Mobile Hosts attached to two different points of attachment in
the network are said to be in a communication session if they are
actively exchanging data. A communication session may be in a normal
state or an interrupted state. A session is in a normal state when
data from one Mobile Host is arriving at the right location for the
other Mobile Host, and vice versa. It is in an interrupted state
otherwise. A handoff is a movement of a Mobile Host from a previous
attachment point to a new attachment point, such that the old IP
address does not route to the new attachment point, but a new IP
address is needed to route there. The handoff time is the moment in
time when it changes from being reachable at the previous attachment
point to being not reachable at the previous attachment point. Given
that time is continuous, it is assumed that only one handoff can
occur at any given moment in time, i.e, that handoff times are
unique. Two handoffs are consecutive if neither of the Mobile Hosts
performs another handoff in between the two handoffs. Consecutive
handoffs can be at the same mobile host or between two different
mobile nodes.
We assume that binding updates do not contain information about
future moves of the sending Mobile Host. While two Mobile Hosts are
in a communication session, they get information on the location of
Wong, et al. Expires January 11, 2009 [Page 3]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
the other Mobile Host only from binding updates. In other words,
they do not actively seek the location of the other Mobile Host, but
only passively accept binding updates. Binding updates are sent
directly to the most current known address (known by the sender) of
the intended recipient Mobile Host. In general, the latency for
binding updates to arrive is assumed to be much smaller than the
average inter-handoff time, therefore, it is extremely unlikely that
a binding update would be sent and the recipient Mobile Host would
move twice before the binding update arrives at the previous network
of the recipient. In some mobility protocols, there might be other
control signaling prior to the sending of binding updates, e.g., for
security purposes.
Then, the simultaneous mobility problem occurs when there are two
Mobile Hosts in a communications session in normal state, and they
both move such that one, or both, of the binding updates that they
send to each other are lost through belated arrival, or if one or
both of the binding updates do not even get sent because of the loss
(through belated arrival) of some other control message prior to the
sending of binding updates, and such that the return from interrupted
to normal state is significantly delayed, or never happens.
For convenience, we also list some of these definitions in Section 2.
1.2. Likelihood of Simultaneous Mobility
Analysis in [simultaneous-mob4] shows that the likelihood of the
simultaneous mobility problem occuring may be non-trivial, depending
on the handoff latencies involved, and the frequency of handoffs.
Wong, et al. Expires January 11, 2009 [Page 4]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
2. Terminology
Communication session: Two Mobile Hosts attached to two different
points of attachment in the network are said to be in a
communication session if they are actively exchanging data. NB:
We do not attempt to define here what "actively exchanging data"
means. This may depend on the applications, and may be related to
a timer set since the last received packet.
Normal state (of a communication session): A session is in a normal
state when data from one Mobile Host is arriving at the right
location for the other Mobile Host, and vice versa.
Interrupted state (of a communication session): A session is in
interrupted state when it is not in normal state
Handoff: A handoff is a movement of a Mobile Host from a previous
attachment point to a new attachment point, such that the old IP
address does not route to the new attachment point, but a new IP
address is needed to route there. NB: this is sometimes known as
layer-3 handoff, in contrast to so-called layer-2 handoff
Handoff Time: The handoff time of a handoff is the moment in time
when it changes from being reachable at the previous attachment
point to not reachable at the previous attachment point.
Belated Arrival (of Binding Update or other control message): A
binding update (or other control message) is considered to make a
belated arrival at a network if the destination Mobile Host is no
longer attached to that network.
Lost (Binding Update or other control message): A binding update or
other control message is lost if it does not arrive at its
intended destination. A binding update or other control message
is "lost through belated arrival" if it makes a belated arrival
and is consequently lost. NB: a binding update or other control
message can be lost not necessarily through belated arrival, but
through other possible causes of lost messages, e.g., network
congestion, node failure, link failure. A binding update or other
control message that has arrived late may also be retrieved by
some other agent in the network without necessarily getting lost.
Wong, et al. Expires January 11, 2009 [Page 5]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
Consecutive Handoff:
Two handoffs are consecutive (with respect to a pair of mobile
nodes) if neither of the Mobile Hosts performs another handoff in
between the two handoffs.
Wong, et al. Expires January 11, 2009 [Page 6]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
3. Simultaneous Mobility Scenarios
In this section, we describe general simultaneous mobility scenarios
in an infrastructure-based evironment.
Figure 1 depicts the simultaneous mobility scenario of two mobile
hosts in an infrastructure based network. The simultaneous mobility
problem arises when Mobile Host 1 (MH 1) moves from one attachment
point in domain 1 to another attachment point in domain 2 for
example, while at the same (or nearly the same) time communicating
Mobile Host 2 (MH 2) moves from one attachment point to another
attachment point. The binding update information that must be passed
between Mobile Host 1 and Mobile Host 2 will not reach the other
prior to their movement.
Wong, et al. Expires January 11, 2009 [Page 7]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
+--+
| | +--+
|AP| | |
| | Domain B1 | |
| |\ Domain A1 /|AP|
+--+ \ / +--+
/--\ \ / /-\
| | \ /--\ ---/ / \
| MH1| \ | / \ |MH2|
\--/ | R |\ | R | \ /
| /\--/ \ / \ / \+/
| +---+ / \ / --\ |
| | | / \ / \\ |
| |AP | / \----- /----X \ +--+ |
\|/ | |/ //\ \\ // \\ \\| | \|/
x +---+ | R +-----+ R | |AP| X
+---+ \\ // \\ // +--+ --
| | /---- \----X +--+ / \
/-\ | |\ / \ | | | |
/ \ |AP | \ / \ / AP MH2
|MH1| | | \\ /--\ / \ // +--+ | |
\ / +---+ \ |/ \ ---/ \ /
\-/ | R | \ / \ --
/\--/ | R |
/ \ | Domain B2
+---+ / --- \
| |/ Domain A2 \ +--+
| | \| |
|AP | |AP|
+---+ | |
+--+
Figure 1: Simultaneous Mobility Scenario
Figure 2 shows the binding updates between two communicating hosts in
an infrastructure-based environment. In the figure, Host A moves
from domain A1 to domain A2 while host B moves from domain B1 to
Domain B2 giving rise to the simultaneous mobility scenario. Under
certain conditions, the mobiles may lose the binding updates from
each other giving rise to problems encountered by simultaneous
mobility.
Wong, et al. Expires January 11, 2009 [Page 8]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
Domain A2 Domain A1 Domain B1 Domain B2
+------+ +------+ +------+ +------+
| | | | | | | |
| A | |A | |B | |B |
| 2nd | |1st | |1st | |2nd |
+---+--+ +---+--+ +---+--+ +---+--+
| | | |
| | | |
| | IP data traffic| |
| |/ \| |
| X-----------------* |
Mobile | |\ /| |
A | |Binding Update\ | |
moves +-----------+---------------X | | Mobile
| | / | | B
| |Binding Update | | moves
| | / | |
| X----------------+-----------+
| | \ | |
| | | |
| | | |
| | | |
| | | |
Figure 2: Simultaneous Mobility Flow: General Scenario
Wong, et al. Expires January 11, 2009 [Page 9]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
4. Applicability of simultaneous mobility
In this section, we describe how general simultaneous mobility arises
for two different mobility protocols, such as MIPv6 [RFC3775] and
SIP-based mobility [SIPMM] are used in an infrastructure-based
environment. Both the protocols exhibit certain common features,
such as the ability to send binding updates directly to the
correspondent nodes.
4.1. Simultaneous Mobility in Mobile IPv4
Mobility extensions for Internet Protocol v4 (Mobile IPv4) does not
have a problem with simultaneous mobility. By design, non-moving
Correspondent Hosts are unaware of the mobility of Mobile Hosts. The
home agent of the Mobile Host functions as an anchor point for the
Mobile Host. No matter where the Mobile Host moves, packets for it
always go first to its home network for interception and tunneling by
its home agent. If it turns out that the Correspondent Host is also
mobile, it will also have a home agent and packets from the Mobile
Host will similarly be intercepted and tunneled to the appropriate
network by its home agent. Since both home agents are stationary and
can always be reached through IP routing simultaneous mobility does
not present a problem to Mobile IPv4.
4.2. Simultaneous Mobility in Mobile IPv6
In this section, we describe how and under what conditions,
simultaneous mobility affects the smooth operation of Mobile IPv6
protocol. In this current version of this draft, we consider only
Mobile IPv6 as specified in RFC 3775 [RFC3775]. We do not currently
consider low latency handoff mechanisms, such as in RFC 4068
[RFC4068].
Unlike Mobile IPv4, Mobile IPv6 has simultaneous mobility problems.
The simultaneous mobility problem of Mobile IPv6, however, is
somewhat subtle because of an in-built defense against the
simultaneous mobility problem. As part of route optimization,
binding updates are sent directly to Correspondent Hosts after a
handoff. If a binding update is sent to the care-of address of a
mobile Correspondent Host, then it is straightforward to see how this
binding update might be lost through belated arrival, and how the
simultaneous mobility problem would occur. In reality, as a Mobility
Header message, the binding update MUST NOT be sent to any care-of
address that the Mobile Host might have for a mobile Correspondent
Host, but must be sent to the permanent home address of the mobile
Correspondent Host. This binding update can then be forwarded by the
mobile Correspondent Host's home agent to its current location.
Similarly, Care-of-Test Init (CTI) and Home-Test Init (HTI), when
Wong, et al. Expires January 11, 2009 [Page 10]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
sent to a Correspondent Host that is also mobile, MUST NOT be sent to
the care-of address for that Correspondent Host, but both go to the
home address, and thus, are forwarded to the Correspondent Host by
the home agent of the Correspondent Host. Thus, this serves as an
in-built defense against the simultaneous mobility problem, since the
home agent of the receiving host is involved. The defense, however,
is only partial, because it needs the Home Agent registration of the
receiving host to be successfully completed before the control
message can be properly forwarded to the receiving host. Therefore,
the interval of time in which the receiving Mobile Host is vulnerable
to the simultaneous mobility problem is from when it transitions to
interrupted state, until it can obtain a care-of address and complete
successful home registration.
Figure 3 shows an example call flow for simultaneous mobility
problems when applied to MIPv6. In this example, one side is unable
to complete return routability because of simultaneous mobility. In
particular, A is unable to initiate return routability with the HTI
and CTI messages, because these arrive at B's home agent before B's
home agent has received B's latest care-of address. Thus, these
arrive at B's previous network shortly after B has moved to it latest
network. Meanwhile, B performs its own return routability procedure,
and this is successful, for the following reasons: (a) since A has
attempted to initiate its own return routability procedure, A has
already successfully registered its latest care-of address with its
home agent; (b) B's CTI and HTI messages as usual are sent to A's
home address and are correctly forwarded by A's home agent to A; (c)
A sends the Home Test message to B's home address, and A sends the
Care-of Test message to B's care-of address that is obtained from the
source address of the CTI (as implied by RFC 3775).
In the worst case, A does not retransmit its lost CTI and HTI
messages, and the communications session is broken. In the best
case, the Mobile IPv6 implementation in A implements a retransmission
scheme. RFC 3775 suggests that such a retransmission might initially
use a 1 second timeout (INITIAL_BINDACK_TIMEOUT). Longer timeouts
might result in applications timing out and communication sessions
thus breaking, even if both Mobile Hosts eventually receive the
latest Binding Updates from each other.
Wong, et al. Expires January 11, 2009 [Page 11]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
Home Home
Domain A Domain B
Domain Domain Domain Domain
A2 A1 +-----+ +-----+ B1 B2
+------+ +------+ |Home | |Home | +------+ +------+
| | | | |Agent| |Agent| | | | |
|A 2nd | |A 1st | |A | |B | | B 1st| |B 2nd |
+------+ +------+ | | | | +---|--+ +---|--+
| | +-----+ +-----+ | |
| | | | | |
| |/ | | \| |
| X------------------------------X |
| |\ | | /| |
| | | | | |
Mobile >| Register \| | | |
A +---------+---------X | | |
moves | | /| | | |
from | Care-of-Test Init \| \| |< Mobile
domain +---------+---------+---------X----------X |B
A1 to | Home Test Init \| \| \| |moves
domain +---------+---------*---------X----------X |from
A2 | | /| /| /| |domain B1
| | | |/ |register |to
| | | X----------+---------+ domain B2
| | | |\ | |
|/ | Normal return routability for B \|
X---------+---------+---------+----------+---------X
|\ | | | | /|
| | | | | |
| | | | | |
| | | | | |
Figure 3: Simultaneous Mobility in MIPv6
In the same scenario, another possible manifestation of the
simultaneous mobility problem may occur, where A's binding update is
lost instead of its CTI and HTI messages. In this case, B moves a
little later, so A's return routability procedure completes as
normal, while B is still reachable at its previous network. Then, B
moves to the new network, but before B's binding update to its home
agent has reached the home agent, A's binding update (to B) arrives
at B's home agent, and is forwarded to the previous network where B
is no longer reachable, and thus it is lost.
Wong, et al. Expires January 11, 2009 [Page 12]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
Home Home
Domain A Domain B
Domain Domain Domain Domain
A2 A1 +-----+ +-----+ B1 B2
+------+ +------+ |Home | |Home | +------+ +------+
| | | | |Agent| |Agent| | | | |
|A 2nd | |A 1st | |A | |B | | B 1st| |B 2nd |
+------+ +------+ | | | | +---|--+ +---|--+
| | +-----+ +-----+ | |
| | | | | |
| |/ | | \| |
| X------------------------------X |
| |\ | | /| |
| | | | | |
Mobile >| Register \| | | |
A +---------+---------X | | |
moves | | /| | | |
from | Care-of-Test Init \| \| |
domain +---------+---------+---------X----------X |B
A1 to | Home Test Init \| \| \| |moves
domain +---------+---------X---------X----------X |from
A2 | | /| /| /| |domain B1
|/ Care-of Test | | | |
X---------+---------+---------+----------+ |
|\ | | | | |
|/ Home Test |/ | | |
X---------+---------X---------+----------+ |
|\ | |\ | | |< Mobile
| Binding update | \| \| |B moves
+---------+---------+---------X----------X |from
| | | /| /| |domain B1
| | | |/ |register |to
| | | X----------+---------+ domain B2
| | | |\ | |
|/ | Normal return routability for B \|
X---------+---------+---------+----------+---------X
|\ | | | | /|
| | | | | |
| | | | | |
| | | | | |
Figure 4: Simultaneous Mobility in MIPv6: another occurrence
Wong, et al. Expires January 11, 2009 [Page 13]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
4.3. Simultaneous mobility in SIP-based mobility
In this section we illustrate how simultaneous mobility problem also
affects the SIP. Session Initiation Protocol (SIP) is a protocol
that enables setting up voice calls, two-way multimedia sessions,
teleconferencing, instant messaging and other types of communication
using the Internet. SIP is a protocol in the Application Layer of
the OSI Reference Model to enable the establishment, management and
termination of such real-time communications sessions over an
Internet Protocol (IP) network. SIP is defined by RFC 3261 of the
Internet Engineering Task Force (IETF). SIP negotiates the features
and capabilities of a communication session at establishment of the
session reducing time necessary for setting up communication
sessions. Mobility of the end host is handled very naturally by SIP
using existing SIP signaling mechanisms. For example, to initiate a
session, the SIP INVITE message is sent by the initiating device to
the other device. The extension of SIP to handle mid-session
mobility specifies that when one of the two devices moves, it sends a
re-INVITE message to the other device, informing it of its new
location (e.g., its new IP address). In addition to the re-INVITE
message sent directly to the device that moved (Mobile Host) to the
other device (Correspondent Host), the Mobile Host also registers its
presence in the new network with a SIP server in its home network.
This allows other potential Correspondent Hosts to find the Mobile
Host.
Figure 5 is depicts the flow of data resulting from a mishandling of
simultaneous mobility in SIP. In the basic SIP mobility scheme, when
a Mobile Host moves to a new network, it sends a re-INVITE message to
the Correspondent Host, as well as a REGISTER message to its home
network SIP server. There are two options for the part of the re-
INVITE, i.e., it could go through the inbound proxy of the
Correspondent Host, or it could go directly to the Correspondent
Host. This second option will not work properly if there is
simultaneous mobility of the Mobile Host and the Correspondent Host.
Clearly, if the Correspondent Host moves at the same time, the re-
INVITE may be lost (and similarly, the re-INVITE from the
Correspondent Host to the Mobile Host could also be lost). As the
home SIP severs for both are stationary and always reachable through
IP routing, the registrations are not affected by simultaneous
mobility. It would appear the both hosts could now obtain the new
location of the other party through the SIP servers, analogous to how
the home agent provides such information in MIP. However, in MIP,
the home agent quickly discovers that the Correspondent Host needs
the updated binding information, because data packets from the
Correspondent Host are routed to the home network and intercepted by
the home agent.
Wong, et al. Expires January 11, 2009 [Page 14]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
In the SIP case, on the other hand, the Correspondent Host may not
immediately contact the SIP sever. Instead the re-INVITE may time-
out and may be tried again several more times to the wrong network by
virtue of its built-in retransmission mechanism. The crucial
difference is that the data path and signaling path are separate in
the case of SIP, unlike that of MIP. For simplicity, automatic
retransmissions of lost re-INVITE messages are not shown and neither
are messages like ACK that acknowledge the SIP OK. Simultaneous
mobility of two end-hosts is not usually an issue for pre-session
mobility in SIP. However, during a transition before a SIP session
set-up is complete, simultaneous mobility may present problems. As
shown in FIG. 5, it may so happen that one of the signaling messages
(INVITE, OK, ACK) does not reach the other party and gets lost,
despite the SIP server keeping an up-to-date registration for both
parties.
Home Home domain 2a domain 2b
domain 1B domain1A domain 1 domain 2
+------+ +------+ +------+ +------+ +-----+ +------+
| | | | | | | | | | | |
|MH1 | |MH1 | |SIP1 | |SIP2 | |MH2 | |MH2 |
|2nd | |1st | |Server| |Server| |1st | |2nd |
+---|--+ +---|--+ +---|--+ +---|--+ +--|--+ +---|--+
| | | | | |
| | | | | |
| |/ | | \| |
MH1 | X-------------------------------X/ |
Moves | |\ | | /| |
| |re-INVITE | \| |
+-----------+----------+----------+---------* |
| | | | /| |
| REGISTER | \\| | | |
+-----------+----------* | | |MH2
| | /| | | |Moves
| | / |re-INVITE | | |
| | X--------+----------+---------+---------+
MH1 | | \ | |/ REGISTER |
Moves | | | *---------+---------+
| | | |\ | |
| |Both hosts cannot find each other due to |
| |simultaneous mobility |
| | | | | |
| | | | | |
Wong, et al. Expires January 11, 2009 [Page 15]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
Figure 5: Simultaneous Mobility in SIP-based environment
Wong, et al. Expires January 11, 2009 [Page 16]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
5. Occurrence of Simultaneous Mobility Problems
(THIS SECTION IS TO BE REVISED SOON)
In this section, we consider when the simultaneous mobility problem
may or may not occur, and we state some of the results of the
analysis in [simultaneous-mob2]. In these results, the term
"location proxy" shall be used (applied to a Mobile Host) in a broad
sense, to mean a network function that is used to locate the Mobile
Host. Different categories of location proxies are described in
[simultaneous-mob2], but the categorization is not needed in this
present draft.
In an infrastructure-based environment, given a pair of consecutive
handoffs, one for each of two mobile nodes in a communications
session in normal state (up till the first handoff), in the absence
of location proxies for either mobile node (or there might be
location proxies but they are not used/involved), any binding update
sent by the earlier moving mobile node will be lost through belated
arrival, if and only if the binding update does not arrive at the
other mobile node before it moves.
Given a pair of consecutive handoffs, one for each of two mobile
nodes in a communications session in normal state (up till the first
handoff), in the absence of location proxies for either mobile node
(or there might be location proxies but they are not used/involved),
if the binding update from the node that moved first is lost through
belated arrival, the binding update from the node that moved second
will also be lost through belated arrival.
Given a pair of consecutive handoffs, one for each of two mobile
nodes in a communications session in normal state (up till the first
handoff), in the absence of location proxies for either mobile node
(or there might be location proxies but they are not used/involved),
the simultaneous mobility problem does not occur if and only if the
binding update from the node that moved earlier reaches the other
node before that node moves.
Simultaneous mobility problem does not occur in MIP if it does not
use Route Optimization. No binding updates are sent directly to
mobile nodes. So, there are none to be lost through belated
arrivals. Instead, Home Agents serve as up-to-date intercepting
location proxies that forward data to the right location as soon as
Mobile IP registration occurs after each handoff.
Wong, et al. Expires January 11, 2009 [Page 17]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
6. Security Considerations
The mobility protocols MIPv6 or SIP can use the existing security
mechanisms designed for each of the protocols for any related
extension.
Wong, et al. Expires January 11, 2009 [Page 18]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
7. IANA Considerations
This document has no actions for IANA.
Wong, et al. Expires January 11, 2009 [Page 19]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
8. Acknowledgments
Authors would like to acknowledge anonymous reviewers of the
simultaneous mobility papers, and Rute Sofia and Kilian Weniger for
helpful comments on the first version of this draft.
Wong, et al. Expires January 11, 2009 [Page 20]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
9. References
9.1. Normative References
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
9.2. Informative References
[simultaneous-mob1]
Wong, K. and A. Dutta, "Simultaneous Mobility in MIPv6",
Proceedings of EIT 2005 May 2005.
[simultaneous-mob2]
Wong, K., Dutta, A., and H. Schulzrinne, "Simultaneous
Mobility: Analytical Framework, Theorems and Solutions",
Journal of Wireless Communications and Mobile
Computing June 2007.
[simultaneous-mob3]
Kravets, R., Carter, C., and L. Magalhaes, "A cooperative
approach to user mobility", ACM Computer Communications
Review October 2001.
[simultaneous-mob4]
Wong, K. and W. Woon, "Analysis of Simultaneous Mobility
under Asymmetric Conditions", Proceedings of Milcom
2007 October 2007.
[SIPMM] Schulzrinne, H. and E. Wedlund, "Application Layer
Mobility Using SIP", ACM MC2R.
Wong, et al. Expires January 11, 2009 [Page 21]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
Authors' Addresses
K. Daniel Wong
Malaysia University of Science and Technology
GL 33, Block C, Kelana Square, 17 SS 7/26, Kelana Jaya
Petaling Jaya, Selangor 47400
Malaysia
Phone: +603 7880 1777 x282
Email: dwong@must.edu.my
Ashutosh Dutta
Telcordia Technologies
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 3130
Email: adutta@research.telcordia.com
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
Wong, et al. Expires January 11, 2009 [Page 22]
Internet-Draft Simultaneous Mobility Problem Statement July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Wong, et al. Expires January 11, 2009 [Page 23]