Hesham Soliman INTERNET-DRAFT Expires: November 2006 Qualcomm-Flarion May, 2006 Network-based mobility considered harmful draft-soliman-netlmm-harmful-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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is a submission of the IETF MIP6 WG. Comments should be directed to the IPv6 WG mailing list, mip6@ietf.org. Abstract Over the last six years the IETF has developed a number of protocols that are expected to be useful for localized mobility management (LMM), both for IPv4 and IPv6. All of these protocols were designed as extensions to Mobile IPv4 and Mobile IPv6. However, more recently, the IESG has approved the formation of the NETLMM WG, which aims to develop a network-based localized mobility management protocol. This memo discusses the impacts of a network-based mobility management protocol on the Internet and the IETF. The aim of this memo is to generate discussion in this area in order to better critique the network-based approach and show its impacts. Soliman [Page 1] INTERNET-DRAFT NETLMM October, 2005 Table of Contents 1. Introduction.....................................................3 2. Problems in the problem statement................................3 3. Problems with the NETLMM approach................................4 3.1. Applicability to different link layers......................5 3.2. Networks with multiple access technologies..................5 3.3. The robustness argument for end-to-end signaling............6 3.4. Mobile Vs Network Control...................................7 3.5. Network dimensioning........................................7 4. Non-technical impacts............................................8 5. Security Considerations..........................................9 6. Acknowledgements.................................................9 7. References.......................................................9 Authors' Addresses.................................................10 Soliman [Page 2] INTERNET-DRAFT NETLMM October, 2005 1. Introduction [MIPv6] and [MIPv4] were produced by the IETF to address mobility management for IPv6 and IPv4, respectively. In the last 6 years, it became evident that neither protocol is sufficient for managing frequent mobility in a fast and efficient manner. In order to improve the performance of Mobile IP handovers, a large effort started in the Mobile IP WG to address what was then referred to as Localized mobility management (LMM) for IPv4 and IPv6. In order to improve the handover performance, two main components were addressed: 1) Reducing the time it takes for the mobile node to detect that it has moved to a new link, and reducing the resulting address configuration time (specifically for IPv6); and 2) minimizing the amount of signaling required to re-route packets to the mobile node's new location. As a result of this effort the following specifications were produced: [LOWLAT], [HMIPv6] and [FMIPv6]. Other supporting protocols were also produced by the Seamoby WG: [CT] and [CARD]. Recently, the IESG has chartered the NETLMM WG to develop a network- based approach to mobility management. The NETLMM approach excludes the mobile node from any IP mobility decision, which is a distinct departure from all of the mobility protocols mentioned above. This memo critiques the approach used by the NETLMM WG and highlights some of the problems that it can cause. This memo begins by analyzing the problem statement that led to the establishment of the WG then proceeds to discuss the technical impacts of such protocol on the deployments. 2. Problems in the problem statement The problem statement used to motivate the NETLMM effort has, in the author's opinion, a number of factually incorrect statements. This memo addresses the perceived problems with the current LMM approach developed in IETF, i.e. the solutions mentioned above. The draft lists four problems with the current approach. The first perceived problem is that current approaches require updates to the host software, which, however small, limit the broad deployment of those protocols. If this concern were used as a basis for protocol design, we would have to minimize the addition of any new software to hosts in order to ensure wide deployment of new features. As a result, we would maximize the dependency on new features in the network, creating the inevitable, and sad, result of "smart networks and dumb hosts", which is diametrically opposed to the past and current design philosophy used in IETF. Moreover, it is not clear why some software is acceptable in the host (e.g. the entire TCP/IP stack, resource reservation, session control, security) while other software is not. Finally, what proof exists today that Soliman [Page 3] INTERNET-DRAFT NETLMM October, 2005 relying on adding software to a host limits the deployment of new features? The problem statement does not address these questions. The second perceived problem with current approaches is that other global mobility management protocols may be used in future; therefore relying on Mobile IP extensions may not be appropriate because there is an underlying assumption that Mobile IP will be used for global mobility. The authors of the problem statement cite Mobike, which is not a mobility management protocol, and HIP. Regardless of the merits of those protocols cited as candidates for global mobility, the argument is fundamentally flawed. The entire premise of the existing mobility management protocols (in IPv6) is that they are completely decoupled from the global mobility protocol. It is true that both local and global protocols use [MIPv6], however, the current LMM protocol [HMIPv6] does not require the use of MIPv6 for global mobility. The same can be said for MIPv4-based approaches that use a local HA. The third perceived problem is that existing LMM solutions do not support both IPv4 and IPv6. This is simply wrong. The MIP6 WG has adopted [DSMIPv6] for this purpose and MIPv4 WG is considering an equivalent approach [DSMIPv4]. The fourth and final perceived problem is that the current LMM protocols require complex security mechanisms. One cannot argue with this point since complexity, like beauty, is in the eye of the beholder. However, it is worth noting that FMIPv6 does not yet have a security mechanism defined, and HMIPv6 relies on IPsec, which happens to be widely deployed and also used for MIPv6. 3. Problems with the NETLMM approach The NETLMM approach is described on a high level in the current charter. Simply put, NETLMM expects to place a mobility anchor point in the visited network, which acts like a home agent. The mobile node will be configured with an address on the anchor point's link and keep it for the time it is located in the NETLMM domain. The anchor point binds the mobile node's address to its current default router (or Access Router, AR). Hence, whenever the mobile node moves, the new AR will bind its address to the one allocated to the mobile node. Tunneling is done between the anchor point and the AR. Therefore, the AR's address can be seen as a Care-of address for the mobile node. On a more detailed level, several minor changes can be made; however, the overview above gives the general idea. This approach raises a number of problems that were not discussed in the process of establishing the WG. Some of these concerns are presented in this section. Soliman [Page 4] INTERNET-DRAFT NETLMM October, 2005 3.1. Applicability to different link layers The NETLMM WG charter states that the protocol will be link-layer agnostic by running over IP. This is not completely accurate. It is certainly true that running over IP provides some independence from the link layer technology. However, when it comes to mobility management, simply running over IP is not sufficient for link-layer independence. A mobility management protocol that improves handover performance needs to be able to adapt a sequence of events depending on the capabilities of the link layer. For instance, Fast handovers in IPv4 and IPv6 (FMIP) will run in different modes depending on the underlying link layer. Broadly speaking, in the context of mobility management, there are two types of link-layers: 1) Link-layers that allow the network to be aware of the mobile node's next AR and anticipating its movement. Examples of such link- layers include most cellular networks in existence today (but not all). 2) link-layers that do not provide the knowledge of the mobile node's next AR to the network. Examples of such link-layers include the widely deployed WLAN technologies and some cellular link-layers. Where the network is aware of the mobile node's next AR, the network may be able to do the signaling on behalf of the mobile in order to perform a predictive handover (more problems with network signaling are discussed in the following sections). However, if the network is not aware of the mobile node's next AR, it will not be able to perform a predictive handover, which leaves it with reactive handovers as the only option, which would typically result in worse performance. Independently of the performance issue, it is important to note that NETLMM is not link-layer agnostic when it comes to mobility management issues. 3.2. Networks with multiple access technologies The NETLMM problem statement document defines local mobility as follows: Local Mobility is mobility over a restricted area of the network topology. Note that, although the area of network topology over which the mobile node moves may be restricted, the actual geographic area could be quite large, depending on the mapping between the network topology and the wireless coverage area. According to this definition, local mobility may take place between two ARs connected to two different radio technologies. This poses a serious problem for any network-based mobility management scheme. A mobile node may wish to move some or all of its traffic to one access technology. However, a network-based mobility management scheme cannot be aware of the mobile node's preferences and may force one Soliman [Page 5] INTERNET-DRAFT NETLMM October, 2005 technology for all of the mobile node's ongoing, and possibly future, connections. This situation can also cause operators to force a node to be connected to a particular technology, which may not be the preferred choice for the mobile node. This situation is not addressed in the current charter or work done so far in the NETLMM WG. A network-based mobility management scheme cannot handle this situation in a reliable or deterministic manner. The flaws with a network-based approach in this situation are: (a) If one accepts that global mobility management is going to be Mobile IP based then one accepts the idea that the end node should be able to select between links to different administrative domains (or network operators). Links to different operators can of course be of the same or different technology. If this is a good thing, why do we not want to provide the host with the same flexibility when different links/technologies are available under the same local domain? (b) Multi-homed end nodes will at some point be able to use different links for different applications depending on link quality/capabilities. It is easy to see that the level of complexity increases significantly when taking into account flow movement. The proliferation of applications and possibility that the end node is enabled with interfaces unknown to any given network-based mobility scheme makes this a difficult problem. How would a network based mobility management system know which flows to move to which link? (c) Since the coverage area of different technologies is likely to overlap, the decision to use one technology or the other becomes a policy decision. The end nodes will have to deal with making such policy decisions between different networks and they should be able to make the same decisions between different technologies. The network operator should define metrics (like cost, loading etc) but it should let the end host decide what to do. This is not a philosophical point; there are concrete reasons why the host needs to make this policy decision. For instance, the host is most knowledgeable about the applications it runs and what radio technologies are best suited to those applications. 3.3. The robustness argument for end-to-end signaling End to end signaling is important and necessary in order to maintain the end to end design philosophy of the Internet. When it comes to localized mobility management, the end to end concept remains crucial to the robustness of the mobility management mechanism. Handovers are uncertain by nature and in some cases the new attachment point may change during the handover process. This is due to the volatile nature of the radio link at cell borders, which is typically the case in most cellular technologies. It is also known that mobile nodes can experience ping-pong movement, or cellular thrashing, during handovers; i.e. the mobile node may quickly move back and forth between two different access points for a short period of time. A Soliman [Page 6] INTERNET-DRAFT NETLMM October, 2005 network-based mobility management protocol can cause the mobile node's traffic to be routed to the wrong AR, i.e. the AR that the mobile node was expected to move to, but did not. This can result in packet losses. In contrast, if the IP mobility signaling is initiated from the mobile node, it would be able to discover that the next AR has changed and inform the network of its new choice. When the action is taken by the mobile node it can be done in a quicker manner for predictive or reactive handovers. 3.4. Mobile Vs Network Control One of the unwritten motivations of NETLMM is that some operators and vendors "believe" that the network must control the handover. Lets explore this belief a bit more. Specifically, what does network control mean? Why is it needed? And how does a network-based mobility management mechanism allow for more control? One can interpret the words "Network control" to mean that the network needs to authorize the handover of a mobile node to another location. In fact, what is really meant by increasing "Network control" is increasing "Operator control". There maybe reasons why the operator needs to authorize, or at least be informed of such move. The current LMM mechanisms do not eliminate this step. In all of the Mobile IP-based solutions, the mobile node sends a message to a mobility agent that responds positively or negatively to the mobile node. Hence, it is fair to say that current LMM approaches do in fact allow for network control of the handover. Mobile IP-based approaches have gone further; Fast handovers for IPv4 and IPv6 allow the access router/FA to suggest a new link for the mobile node. Hence, a "smarter" network can suggest that a mobile node move to another link, e.g. to better utilize its radio interface resources. Eliminating the message from the mobile node does not increase the network control it merely eliminates the ability of the mobile node to request to move to a particular location. 3.5. Network dimensioning Network dimensioning can be more difficult in the case where a network-based approach is adopted. In a large network with millions of mobile nodes, the network is expected to be broken down into several local mobility domains under the same administrative domain. Each local mobility domain would consist of several mobility anchors (i.e. MAPs in IPv6). This is done in order to cope with the amount of signaling and traffic generated by each mobile node. Therefore, a form of load sharing is needed between the mobility anchor points within each mobility domain. One of the factors involved in dimensioning the network must be the number of users that each anchor point can handle. This can be estimated by the amount of bandwidth available to each anchor point, the rate of signaling it can handle, and the number of tunnels available. Soliman [Page 7] INTERNET-DRAFT NETLMM October, 2005 When moving between two different mobility domains, it is strongly recommended that the handover disruption be minimized in a similar manner to intra mobility-domain handovers. This is especially true for mobile nodes with ongoing sessions. Hence, it is indeed likely that mobile nodes may continue to be attached to an anchor point in a different mobility domain for some time after leaving that domain. The above situation is more difficult to support when a network-based mobility management mechanism is adopted. In particular, the following problem arises. An anchor point may be required to setup a security association with any access router in the network at any time. A network administrator is suddenly forced to consider the impacts on memory capacity and the speed of the security association establishment at the critical handover time. This situation does not arise when the signaling is done end-to-end because in this case only one security association is needed, regardless of the mobile node's location. Furthermore, the security association does not need to be established during the critical handover time. 4. Non-technical impacts The endorsement of more than one alternative for the same problem needs to be strongly justified. Unfortunately this was not the case for the NETLMM work in IETF. Both NETLMM BoFs clearly stated that the WG will exclude the mobile node from the IP mobility management signaling, which is not a typical requirement related to a problem, but one designed around a solution. This premise was challenged in both BoFs. Despite lack of clear consensus, the IESG decided to form the WG. The problem here is two-fold: How do we decide on new WGs? And what is the impact of solving the same problem in two different standards? Both questions are not specific to the NETLMM WG, however, this WG illustrates the need for a uniform and predictable process. Developing more than one solution to solve the same problem in different scenarios is certainly possible. However, alternatives need to be strongly justified. In this case, the reasons are not accurate and in most cases factually incorrect. Furthermore, the downside of the NETLMM approach was not even discussed. This is clearly a recipe for a bad outcome. When justifying alternatives one needs to at least answer the following questions to the satisfaction of the community: - What is the problem with the current approach? - Can this problem be solved by extending the current approach? - What is the alternative? - What are the pros and cons of such alternative? As this document states, the first question was inadequately answered and the others were not answered at all. Soliman [Page 8] INTERNET-DRAFT NETLMM October, 2005 5. Security Considerations The author was using a complex, host-based, IP layer security mechanism called IPsec while writing this draft. 6. Acknowledgements A lot of the points made in this document were discussed with, inspired by, or produced during discussions with (in alphabetical order): Scott Corson, Vince Park, Geroge Tsirtsis. Their input has significantly improved the quality of this document. 7. References [CARD] CARD Design team, Liebsch, M., Singh, A., Chaskar H. and D. Funato, "Candidate Access Router Discovery", RFC 4066 March 2003. [CT] Loughney, J. Ed., Nakhjiri, M., Perkins, C. and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067 July 2005. [DSMIPv4] Tsirtsis, G., Soliman, H., and V. Park, " Dual Stack Mobile IPv4 ", draft-tsirtsis-v4v6-mipv4-01/ [DSMIPv6] H. Soliman et al, " Mobile IPv6 for Dual Stack Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-01. [HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. [IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6) specification", RFC 2460 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [LOWLAT] K. ElMalki, Ed., "Low Latency handovers for Mobile IP" [MIP-PB] Tsirtsis, G., and H. Soliman, "Mobility management for Dual stack mobile nodes, A Problem Statement", draft-ietf-mip6-dsmip-problem-01.txt, July 2005. [MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344 [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [NEMO] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support protocol", RFC 3963, January 2005. Soliman [Page 9] INTERNET-DRAFT NETLMM October, 2005 [SEC] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protoect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", RFC 3776, June 2004. [SNRIO] Larsson, T., Gustafsson, E., and H. Levkowetz, "Use of MIPv6 in IPv4 and MIPv4 in IPv6 networks", draft-larsson-v6ops- mip-scenarios-01.txt, February 2004. Authors' Addresses Hesham Soliman Qualcomm-Flarion Technologies E-mail: Hesham@Qualcomm.com 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 IETF's procedures with respect to rights in IETF Documents can be found in RFC 3667 (BCP 78) and RFC 3668 (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. Full 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. Disclaimer of Validity Soliman [Page 10] INTERNET-DRAFT NETLMM October, 2005 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. This Internet-Draft expires September, 2006. Soliman [Page 11]