MEXT Working Group K. Wong Internet-Draft MUST Expires: August 21, 2008 A. Dutta (Ed.) Telcordia H. Schulzrinne Columbia Univ. February 18, 2008 Simultaneous Mobility Problem Statement draft-wong-mext-simultaneous-ps-00 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 August 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Wong, et al. Expires August 21, 2008 [Page 1] Internet-Draft Simultaneous Mobility Problem Statement February 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 IPv6 . . . . . . . . . . . 10 4.2. Simultaneous mobility in SIP-based mobility . . . . . . . 11 5. Occurrence of Simultaneous Mobility Problems . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Wong, et al. Expires August 21, 2008 [Page 2] Internet-Draft Simultaneous Mobility Problem Statement February 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 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 a binding update from a Mobile Host because it 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 the other Mobile Host only from binding updates. In other words, they do not actively seek the location of the other Mobile Host, but Wong, et al. Expires August 21, 2008 [Page 3] Internet-Draft Simultaneous Mobility Problem Statement February 2008 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. 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 the binding updates that they send to each other are both lost through belated arrival, and such that the communications session never returns from interrupted to normal state, but is ended. 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 August 21, 2008 [Page 4] Internet-Draft Simultaneous Mobility Problem Statement February 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. Lost Binding Update: A binding update is lost if it does not arrive at its intended destination. A binding update is "lost through belated arrival" if it makes a belated arrival and is consequently lost. NB: a binding update can be lost not necessarily through belated arrival, but through other possible causes of lost binding updates, r.g., network congestion, node failure, link failure. A binding update that has arrived late may also be retrieved by some other agent in the network without getting lost. Belated Arrival (of Binding Update): A binding update is considered to make a belated arrival at a network if the destination Mobile Host is no longer attached to that network. Wong, et al. Expires August 21, 2008 [Page 5] Internet-Draft Simultaneous Mobility Problem Statement February 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 August 21, 2008 [Page 6] Internet-Draft Simultaneous Mobility Problem Statement February 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 example core network in Figure 1 is comprised of backbone routers, border routers and edge routers. 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 August 21, 2008 [Page 7] Internet-Draft Simultaneous Mobility Problem Statement February 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 August 21, 2008 [Page 8] Internet-Draft Simultaneous Mobility Problem Statement February 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 August 21, 2008 [Page 9] Internet-Draft Simultaneous Mobility Problem Statement February 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. 4.1. 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. Mobility extensions for Internet Protocol v4 (MIPv4) 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 present a problem to MIPv4. Mobile IPv6 however suffers from simultaneous mobility problems because the binding updates are sent directly to the mobile nodes, as part of route optimization. In addition Care-of-Test Init (CTI) and Home-Test Init (HTI) are also sent to the correspondent nodes, as part of return routability. These increase the vulnerability of Mobile IPv6 to simultaneous mobiity problems because it increases the delay before a binding update is sent and before it finally arrives at the other side. Figure 3 shows an example call flow for simultaneous mobility problems when applied to MIPv6. In this case, the return routability procedure for Mobile A is completed before it sends the binding update, but the binding update is lost. It may also be the case that both sides are unable to complete return routability because of simultaneous mobility. Wong, et al. Expires August 21, 2008 [Page 10] Internet-Draft Simultaneous Mobility Problem Statement February 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 | | |\ | | /| | | | | | | | | Register \| | | | +---------+---------X | | | Mobile | | /| | | | A | Care-of-Test Init | \| | moves +---------+---------+---------+----------X | from | Home Test Init \| | \| | domain +---------+---------*---------+----------X | A1 to | | /| | /| | domain |/ | Care-of-Test | | | A2 *---------+---------+---------+----------+ | |X | |/ Home test | |Mobile *---------+---------*---------+----------+ |B |\ | |\ |/ |register |moves | | | X----------+---------+from | | | |\ | |domain B1 | / | | | Care-of-test init |to | X---+---------+---------+----------+---------+domain B2 | \ | | | | | | | / | |/ Home test init | | | X-------+---------*----------+---------+ | | \ | |\ | | | |Binding Update | \ | | +---------+---------+---------+------X | | | | | | / | | Figure 3: Simultaneous Mobility in MIPv6 4.2. 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 Wong, et al. Expires August 21, 2008 [Page 11] Internet-Draft Simultaneous Mobility Problem Statement February 2008 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 4 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. 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 Wong, et al. Expires August 21, 2008 [Page 12] Internet-Draft Simultaneous Mobility Problem Statement February 2008 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. 4, 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 | | | | | | | | | | | | | Figure 4: Simultaneous Mobility in SIP-based environment Wong, et al. Expires August 21, 2008 [Page 13] Internet-Draft Simultaneous Mobility Problem Statement February 2008 5. Occurrence of Simultaneous Mobility Problems 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 meana 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 August 21, 2008 [Page 14] Internet-Draft Simultaneous Mobility Problem Statement February 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 August 21, 2008 [Page 15] Internet-Draft Simultaneous Mobility Problem Statement February 2008 7. IANA Considerations This document has no actions for IANA. Wong, et al. Expires August 21, 2008 [Page 16] Internet-Draft Simultaneous Mobility Problem Statement February 2008 8. Acknowledgments Authors would like to acknowledge anonymous reviewers of the simultaneous mobility papers. Wong, et al. Expires August 21, 2008 [Page 17] Internet-Draft Simultaneous Mobility Problem Statement February 2008 9. References 9.1. Normative References [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. 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 August 21, 2008 [Page 18] Internet-Draft Simultaneous Mobility Problem Statement February 2008 Authors' Addresses 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 August 21, 2008 [Page 19] Internet-Draft Simultaneous Mobility Problem Statement February 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 August 21, 2008 [Page 20]