Internet Draft Carl Williams Expires: December 2002 Alper Yegin Informational: June 2002 DoCoMo USA Labs Jari T. Malinen John Loughney Nokia Research Center Andrej Mihailovic King's Collge London Micromobility Problem Statement draft-irtf-mm-prob-stmt-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 document is a submission by the Micro-mobility Working Group of the Internet Research Task Force (IRTF). Comments should be submitted to the irtf-rr@nether.net mailing list. Distribution of this memo is unlimited. Abstract Mobile IP [1] has been developed in the IETF for a number of years already. It's simplicity and scalability give it a growing success within the IETF as several Internet drafts are proposed to extend various improvements for Mobile IP and its counterpart designed for IPv6, Mobile IPv6 [2]. Mobile IP suffers from several well-known weaknesses that have led to the definition of the macro/micro-mobility architecture. Such an architecture implies the division of the mobility architecture into two different parts: mobility management at a large scale, between the different domains (macro-mobility), and, on the other hand, at a local scale, inside these domains (micro-mobility). Each type of mobility is then managed by specific mechanisms and protocols. The macro-micro approach results in many advantages that all Carl E. Williams et.al. Expires December 2002 [Page 1] Internet Draft Micro-mobility Problem Space June 2002 micro-mobility protocols will have; thereby effectively addressing weaknesses that plague Mobile IP. This document discusses the micro-mobility problem, and is an attempt to enumerate some of the concepts and approaches defining the micromobility problem space. This draft will serve to document the problem space and definition of micro-mobility for discussion in the IRTF micro-mobility working group. Contents Status of This Memo 1 Abstract 1 1. Introduction...................................................... 2 2. Terminology....................................................... 3 3. The Mobility Landscape: A macro-micro mobility Model.............. 4 4. Micro-mobility Problem Space Issues............................... 7 5. Micro-mobility advantages.........................................11 6. Conclusions.......................................................11 7. Acknowledgements................................................. 13 8, Authors' Addresses............................................... 13 9. Full Copyright Statement......................................... 14 1. Introduction Application of location dependent Internet Protocol (IP) unicast addresses for identifying hosts in the Internet, despite various benefits, creates problems when used for locating mobile hosts since their home address always points to their home subnets thus restricting their movement. Regardless of the mobility limitations, the current state of research into future generation of telecom systems indicates a high probability of having IP-based protocols as the dominant mechanisms for network and related layers. IP-mobility protocols MUST enable maintenance of established sessions without significant service disruption while not restricting the movements of mobile users to single points of attachment or subnets. Mobile IP has been standardized by IETF enabling mobile hosts to maintain established sessions while being able to move between different subnets. However, the general concept of Mobile IP, although providing a robust and simple solution, does not support seamless or near-seamless mobility, which is demanded for the new emerging generation of Internet networks and relevant applications and services (e.g., real time applications). Carl E. Williams et.al. Expires December 2002 [Page 2] Internet Draft Micro-mobility Problem Space June 2002 This weakness of Mobile IP is due mainly to the inefficient location updating during handovers where mobile hosts are updating during handovers where mobile hosts are required to send new location updates to their Home Agents each time they change subnets. In situations with fast moving hosts that change their locations frequently, the frequency of updates is high and, depending on the position of the Home Agent, packet flows can experience significant delays. However, Mobile IP still provides a solid basis for enabling elementary mobility in the Internet and it seems a natural solution for global mobility with its domain for a more efficient alternative local or micro mobility of mobility hosts. Having said that this document makes no assumptions in its discussion of micro-mobility problem space what the protocol or mechanisms is for providing macro or global mobility. This local mobility can be solved by more efficient procedures called local or micro mobility protocols, which should be deployed in scoped networks, called micro-mobility domains in this document, to reduce the delays and the extent of route updating. We will not define the exact physical architecture of a micro-mobility domain since it is dependent on the implementation strategy of different operators. It is worth noting some essential architectural requirements of the micro-mobility domain so that one can understand how the micro-mobility methods work within this physical region. These are explained in Section 2 "The Mobility Landscape: A macro-micro mobility Model". 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. In addition, this document uses the following terms: Macro-mobility Node mobility that does not rely on preserving the the same network-layer access address. Can be deployed with any size of networks, even Internet-wide. Micro-mobility Node mobility when preserving the same network-layer access address possibly using varying transports and providing support for quality of service. Usually deployed within limited topology. The concept is attempted to be refined in this document. Carl E. Williams et.al. Expires December 2002 [Page 3] Internet Draft Micro-mobility Problem Space June 2002 Fixed Node An IP node not capable of changing its point of attachment to the network. A fixed node is capable of sending and receiving packets, that is, being a source or destination of traffic, but not a forwarder of it. Fixed Router A router not capable of moving from its home link to other links. A fixed router is capable of forwarding packets between two or more interfaces, and possibly running a dynamic routing protocol modifying the state by which to do packet forwarding. Mobile Node An IP node capable of changing its point of attachment to the network. The Mobile Node may have routing functionality. Mobile Router A router moving from its home link to other links. A mobile router is capable of forwarding packets between two or more interfaces, and possibly running a dynamic routing protocol modifying the state by which to do packet forwarding. This terminology is intended to conform to those that have been used in IPv6, Mobile IPv6, and other Internet protocols [2, 3]. 3. The Mobility Landscape: A macro-micro mobility Model 3.1 Mobility landscape A general mobility model is depicted in figure 1 as to serve the purpose of defining the micro-mobility problem space. It is not intended to provide a framework for the specification of a protocol. With such a model discussion can proceed in terms of defining the macro-micro mobility architecture and thereby defining the micro-mobility problem statement. [8] The mobility model in figure 1 describes different micro-mobility domains connected with the global Internet via some edge (gateway) router. The different domains are connected with the global wired Internet and with each other through an inter-domain backbone. The micro-mobility protocol will reside in each domain while some global mobility protocol will allow seamless movement between domains. Hosts use all network services and have seamless connectivity with its correspondents anywhere while roaming within a domain but also from a domain to another. Carl E. Williams et.al. Expires December 2002 [Page 4] Internet Draft Micro-mobility Problem Space June 2002 ~~~~~~~~~~~ { } X denotes { } = BS { Internet } +-------- { } ---------+ | { } | | ~~~~~~~~~~~ | +---+ +---+ Domain 1 | | gateway router | | Domain 2 +---+ +---+ / \ / \ / \ / \ +-+ \ +---+ +---+ / +-+ X | | Access | |-| | | | X = +-+ Router +---+ +---+ +-+ = \ \ +-+ +-+ +---+ +---+ +-+ +-+ | | | | | |-| | | | | | +-+ +-+ +---+ +---+ +-+ +-+ X X X = = = Inter-domain X X X Backbone = = = Figure.1 Landscape of Mobility model 3.2 Architectural characteristics of micro-mobility domains For the purpose of understanding how a micro-mobility protocol functions within a domain some essential architectural requirements should be noted. [9] (a) micro-mobility domain: Is an IP based network, which is seen by the rest of the Internet as a single stub domain, meaning: that the traffic that reaches it is only intended for hosts inside the network. (b) micro-mobility domain: Is a collection of subnets. Since the network is to support mobility, access points are wireless base stations, which are IP capable and functioning as mobility-capable IP routers where wireless cells define different subnets inside the domain. (c) micro-mobility domain: has a logical tree-shaped topology routed at the Gateway router and branches toward the access routers. With (c) the micro-mobility method doesn't have to assume a particular physical configuration. Each micro-mobility domain is assumed to be administered under the same administration domain. Carl E. Williams et.al. Expires December 2002 [Page 5] Internet Draft Micro-mobility Problem Space June 2002 3.3. Macro-mobility and Micro-mobility Mobility in the Internet has traditionally meant movement of hosts or routers away from their topologically correct places. As known, topologically correct place is the one into which network-layer address -based aggregated routing æænaturally'' will forward packets. By natural we here mean forwarding table -driven aggregated routing where packet forwarding takes place only as a result of examining aggregated, or non-host-route -based, forwarding state in intermediate nodes. Since the hierarchical addressing scheme in the Internet was designed for fixed routing, routing to a topological place in the network that would not change for a destination node, mobility support resulted in support of separating the encoding of identity and location in the IP address. The macro mobility solution, Mobile IP [5, 4], or Mobile IPv6 [3] separate the access and identity addresses of a mobile node. Hence, the mobile node has a separate unchangeable address for identity and another one for access, the latter changing every time a mobile node moves to a new link. This means that such a macro mobility solution supports the change of the access address, also known as the care-of-address. Hence, one definition for micromobility is the opposite of macromobility in the above sense. By this definition, micromobility is mobility where the access address does not change. This can be viewed as mobility within a subnet. A characterization of micromobility as compared to macro mobility is the ability to restrict registration signaling locally to a domain as compared to global registration in the macro mobility case. One characteristic of micromobility schemes is the scope of their functionality. For example, Fast handoff [6, 7] can be view as micromobility and acts local to a set of access routers where as HMIPv6 [11] acts local to some æævisited'' domain, a set of nodes under one administration not necessarily all access routers. 3.4. Other types of mobility Characteristic to mobility is that a node moves with respect to other nodes, on the network layer between subnets, or on the link-layer between attachment points of a link. In a network following a clean layered strucuture the latter would mean that if with link-layer mobility the network layer does not change, a node stays within a subnet. Related terms for mobility are host and router mobility where the former considers movement of hosts, the latter movement of routers. Other related concepts involve network mobility where one considers the movement of networks. Router mobility with network mobility would consider mobility of whole subnets or islands of the fixed network. If no fixed aggregation is preserved in router mobility, the result is mesh Carl E. Williams et.al. Expires December 2002 [Page 6] Internet Draft Micro-mobility Problem Space June 2002 mobility. A method of managing mesh mobility is host routing in mobile meshs, also called mobile ad hoc routing. 4. Micro-mobility Problem Space Issues A set of issues to solve have been considered for a routing or mobility protocol that considers micro-mobility. [10] 4.1. Identity Selecting the identity used in micromobility protocol needs to consider the following issues. A conventional thinking of micromobility is that it like macromobility considers host or router mobility, not user mobility. Another aspect affecting selection of identity is the layer on which a micromobility protocol operates. As the mobility would be host or router mobility, the identity tends to be the routing identity. Every identity can always have an encoding, e.g., to make management of identities lighter. An example would be flow labels used for abbreviating and speeding up forwarding lookups in network-layer routing. Encoding methods can also be used for setting up different transports, e.g., to forward protocols over incompatible other protocols. 4.2. Transport There are several methods of transport one could consider when forwarding data with a micromobility protocol. First, a protocol moving packets from a topologically correct into a topologically incorrect place often uses some kind of an encapsulation or forwarding to make the packets to go where a node has moved. There can be several types of transports in use for such forwarding. Encapsulation Many different kinds of encapsulations of protocols within other protocols can be considered as a possible transport for the purpose of forwarding data packets along elements of the protocol architecture. Example encapsulation protocols could include IP in IP, or GRE. Host Routes Providing micromobility protocol transport by means of IP forwarding state mostly considers host routing. Other routing state considers aggregation as a means of forwarding and this may not be feasible to be used as a means of managing individual nodes moving while preserving the same access address. Carl E. Williams et.al. Expires December 2002 [Page 7] Internet Draft Micro-mobility Problem Space June 2002 Mobility Bindings A common way of forwarding data when using mobility protocols is by mobility bindings. For example, the home agent uses a proxy ARP or proxy Neighbor Cache entry to forward captured packets to a dislocated destination. Analogically, a micromobility protocol could use mobility binding-driven forwarding as its transport. Overlay Routing Instead of a solution resorting to IP routing on the same level as any neighboring router, the transport architecture may be composed of a set of elements maintaining their connectivity by means of a separate ææoverlay'' routing protocol. E.g., the overlay routing can be embedded to some other protocl, such as the mobility signaling. The resulting forwarding may use this information for encapsulation or for a forwarding mechanism directly applying the overlay routing state. An example of this is Mobile IPv6 Regional Forwarding. Flows Abbreviations of forwarding state can be generated by several tokens. An interesting example is the use of flow labels, e.g., in IPv6 there is a placeholder in every packet's IP header for such a field and any forwarding engine should forward packets based on flows. This gives a fairly unused method for a rather efficient and stateless forwarding. Other Forwarding State Other types of forwarding include e.g. link-address network-address association state maintenance, which can be used for switching-like forwarding. That is, there is a special type of state leading into setting of circuits or paths within the forwarding fabric. These are usually non-robust solutions but can be available as particularly light-weight variants of forwarding. An example of this could be the MPLS protocol. 4.3. Scalability One aspect to consider for further work of micromobility is the types and requirements of scalability for mobility, e.g. should these indicate that a new kind of a mobility protocol would be needed to increase some type of scalability. Route Aggregation A micromobility soluion could be assumed not to adversely affect routing state maintenance. This is a criterium easily leading to deprecating the use of host-based routes even for micromobility. However, one explanation Carl E. Williams et.al. Expires December 2002 [Page 8] Internet Draft Micro-mobility Problem Space June 2002 for micromobility is that it uses host routes in its transport. Service of multiple nodes A scalability issue for micromobility is that it may be assumed to easily serve large numbers of nodes. This can lead to selection of transport methods such as host routes or flows whose setup and use is considered lighter than those of encapsulations. Distribution A possible scalability issue is distribution of functionality to share the processing load and state maintenance resource drain caused by serving of a huge number of nodes. Localization Another scalability issue is the possible localization of mobility and other signaling, e.g., QoS and AAA signaling that otherwise would propagate further, possibly up to the far-end nodes of communication. This also tells that a micromobility protocol has some common aspects to localized mobility protocols in that localization although not the key identifier of a micromobility protocol, unlike localized mobility management (LMM) protocols, still is another important motivator. 4.4. Other Architecture Issues By solution architecture one considers issues such as the following Layer of operation A micromobility solution could operate on application, network, or link layer, or on a combination thereof. A clean solution typically is assumed to work on one layer only, and in case of IP networks, on the network layer Since micromobility typically considers node mobility, the next possible layer to consider is typically the link layer. IP Layer Extension Constraints In case a micromobility protocol is designed defining an extension to the IP layer, is the extensions such that it does not violate IP design principles. Also of interest is whether such an extension would be feasible. What are the signaling implications or network element implications, does this introduce, e.g., a gateway element. Observation of the end-to-end principle The Mobile IP -like macromobility protocols made the endpoints do forwarding decision which is a deviation Carl E. Williams et.al. Expires December 2002 [Page 9] Internet Draft Micro-mobility Problem Space June 2002 from using the middle nodes to do forwarding decision as in æænatural'' routing. However, even though middle nodes would do the routing, if they do not violate mutability rules of packets by changing packets on the fly from wrong places, such routing does not violate the end-to-end principle. Typically a clean solution would not violate this principle. Layer Independence A micromobility protocol would make sense as a common name if commonalities can be found and used to generate a link-layer independent solution or part of a solution. Since layer-dependency affects design of a protocol message and its state behavior, layer independence can be considered a basic design principle. Possibly, optimizations e.g. for Quality of Service (see below) can be considered important enough to motivate layer violations, violations against the princible of layer independence. Mobility Protocol Independence and Interworking A key design principle is to have non-micromobility aware network elements to interoperate with the new elements and to have backward compatibility to existing protocols. This is important in particular to the macro mobility protocols. MN registration is independent of mm protocol operating within a specific domain. The nature of mobility support is therefore very mch dependent on which micro-mobility protocols are deployed. Robustness This principle would call for the use of distributed state maintenance methods such as recovery from failure in network layer routing, and to avoid using static path setup methods which less easily recover from failures. Quality of Service One motivation for micromobility protocols has been that it would be an optimization to provide a more managed transport for a QoS support than a routing protocol on an arbitrary link-layer. For example, QoS support in handoffs could be considered optimization for real-time content support. Handoffs with Micromobility Protocols A micromobility protocol should ideally be self-containing but it also operates with other protocols. A question then would be how handoffs are done with micromobility protocols. How is information exchanged - e.g., between access routers Do we have layer two functions or do we hide the details of lower Carl E. Williams et.al. Expires December 2002 [Page 10] Internet Draft Micro-mobility Problem Space June 2002 layer from upper layers. Or for something that is more proactive - we may take adv of link layer and radio specific information, or have connectivity between the mobile nodes and a Foreign Agent at the link layer. Do we do any host redirect with the protocol when handoff is completed. Security Micromobility protocol needs to address security to prevent unauthorized nodes changing routing state. Without proper security mechanisms, neither the network nor the nodes can truct each other. 5. Micro-mobility advantages The partition of mobility management among micro and macro-mobility provides a good solution to the major problems of Mobile IP. The basic assumption is that wireless networks are grouped in domains under a single administrative authority. All domains are connected to a global network such as the Internet. On this basis, the mobility among the different domains is mangaged by the macro-mobility protocol while a specific protocol deals with mobile hosts movement inside each domain (micro-mobility). The main advantage of this architecture is that the users movements inside a domain is totally opaque to the mobile nodes corresponding peers outside the domain. Specific advantges resident themselves with respect to the areas listed in section 4. For example, providing Quality of Service using RSVP may be more efficient because the path only changes when the Mobile Host moves to a new micro-mobility domain. Such system seems to be the only way to enable the use of RSVP like protocols to provide QoS to roaming users. Another main advantage is that handoff can be optimized considerablely in that the time needed to complete the handoff inside a micro-mobility domain will be significantly reduced as we are no longer forced to deal with global mobility agents everytime the mobile node changes its point of attachment. This will reduce the amount of packet loss due to the handoff process. Any updates to be processed by the network routing entities can be reduced or elimiated if handoff is assumed local to a micro-mobility domain. 6. Conclusions It is expected in the IRTF micro-mobility research design team that robustness and scalability are to be investigated carefully since we can expect that future IP based wireless networks will be very wide and support many users. What is clear is that there exist a lack of numerical data and realistic simulations. This is a major weakness of the current Carl E. Williams et.al. Expires December 2002 [Page 11] Internet Draft Micro-mobility Problem Space June 2002 micro-mobility approaches. It is important to evaluate these protocols in a standard and realistic network model with intensive simulations. Today, such data is not available. To motivate further work in the examination of micromobility protocol problem space, a set of well accepted common elements of micromobility should be further identified, e.g. by generating future versions of this document. Another important result should be to add clarity on the definition of micromobility protocol. For example, do we call IEEE 802.11 roaming support a link-specific micromobility protocol, or do we call it something else. This should be used for an analysis of potential design types calling a survey document as a continuation of this text. If the analysis starts to indicate a link-generic micromobility protocol is feasible and useful, a design round could be recommended for the IETF, possible in a new working group. If not, a result would be to explain why there seems not to be possibility or need to develop new micromobility protocol designs. References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6) Specification. Request for Comments (Draft Standard) 2460, Internet Engineering Task Force, December 1998. [3] D. Johnson and C. Perkins. Mobility support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, November 1998. [4] G. Montenegro. Reverse Tunneling for Mobile IP. Request for Comments (Proposed Standard) 2344, Internet Engineering Task Force, May 1998. [5] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 2002, Internet Engineering Task Force, October 1996. [6] K. El-Malki, et. al., Low Latency Handoff in Mobile IPv4 draft-ietf-mobileip-lowlatencyhandoffs-v4-01.txt. [7] G. Dommety, et. al. Fast Handovers for Mobile IPv6 (work in progress). draft-ietf-mobileip-fast-mipv6-04.txt, March 2002. [8] P. Reinbold et. Olivier Bonaventure, ôA comparison of IP Mobility Protocolsö. IEEE SCVT 2002 Proceedings, 2001. Carl E. Williams et.al. Expires December 2002 [Page 12] Internet Draft Micro-mobility Problem Space June 2002 [9] P. Eardley, Andrej Mihailovic, Tapio Suihko, ôA Framework for the Evaluation of IP Mobility Protocolsö, Proceedings of the eleventh IEEE Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC 2002), September 2000, London UK. [10] J. Malinen, C. Williams, and A. Yegin, ôMicro-mobility Taxonomyö, draft-irtf-mm-taxonomy-00.txt, Novemeber 2001. [11] H. Soliman, C. Castelluccia, K. El-Malki, and L. Bellier, ôHierarchical Mobile IPv6ö, draft-ietf-mobileip-hmipv6-04.txt. 7. Acknowledgements The authors would like to thank other members of the informal irtf-mm group for initial exchange of opinions. 8. Authors' Addresses Carl Williams DoCoMo Communication Laboratories USA, Inc. 181 Metro Drive, Suite 300 San Jose, California 95110 USA Phone: +1 408-451-4741 EMail: carlw@docomolabs-usa.com Fax: +1 408-573-1090 Alper E. Yegin DoCoMo Communication Laboratories USA, Inc. 181 Metro Drive, Suite 300 San Jose, California 95110 USA Phone: +1 408-451-4743 EMail: alper@docomolabs-usa.com Fax: +1 408-573-1090 Jari T. Malinen Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2355 EMail: jmalinen@iprg.nokia.com Fax: +1 650 625-2502 John Loughney Nokia Research Center Itamerenkatu 11-13 00180 Helsinki Finland Phone: +350 50 483 6242 EMail: john.loughney@nokia.com Carl E. Williams et.al. Expires December 2002 [Page 13] Internet Draft Micro-mobility Problem Space June 2002 9. Full Copyright Statement Copyright (C) The Internet Society (2000). 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 assigns. 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Carl Williams et.al. Expires December 2002 [Page 14]