Jari T. Malinen Internet Draft Nokia Research Center Expires: May 2002 Carl Williams Informational: November 2001 Alper Yegin DoCoMo USA Labs Micromobility Taxonomy draft-irtf-mm-taxonomy-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 Mobile IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobileip@sunroof.eng.sun.com mailing list. Distribution of this memo is unlimited. Abstract This document discusses the micromobility problem, and is an attempt to enumerate some of the concepts and approaches defining micromobility. A set of concepts is defined for discussing the problem, and approaches taken to solve related problems are examined. At end, a discussion applying the concepts aims at giving input to decide if the problem area would benefit from further work. Jari T. Malinen et.al. Expires May 2002 [Page 1] Internet Draft Micromobility Taxonomy November 2001 Contents Status of This Memo 1 Abstract 1 1. Terminology 2 2. Concepts 3 2.1. Macromobility and Micromobility . . . . . . . . . . . . . 3 2.2. Other types of mobility . . . . . . . . . . . . . . . . . 4 2.3. Mobility Identity . . . . . . . . . . . . . . . . . . . . 5 3. Solution Space Issues 6 3.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Other Architecture Issues . . . . . . . . . . . . . . . . 8 4. Discussion 10 4.1. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Further Work . . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements 12 Authors' Addresses 12 Full Copyright Statement 13 1. 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: Fixed Node A host not capable moving from its home link to other links. 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 Jari T. Malinen et.al. Expires May 2002 [Page 2] Internet Draft Micromobility Taxonomy November 2001 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. Macromobility 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. Micromobility 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. Mobile Node A host moving from its home link to other links. A mobile node is capable of sending and receiving packets, that is, being a source or destination of traffic, but not a forwarder of it. 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]. 2. Concepts Definition micromobility consists of a set of properties associated with the concept in different contexts discussed below. 2.1. Macromobility and Micromobility 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. Jari T. Malinen et.al. Expires May 2002 [Page 3] Internet Draft Micromobility Taxonomy November 2001 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, as discussed in [?]. A characterization of micromobility as compared to macro mobility is the ability to perform 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 [?, ?] can be view as micromobility and acts local to a set of access routers where as HMIPv6 [?] acts local to some ``visited'' domain, a set of nodes under one administration not necessarily all access routers. 2.2. 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 mobility. A method of managing mesh mobility is host routing in mobile meshs, also called mobile ad hoc routing. Jari T. Malinen et.al. Expires May 2002 [Page 4] Internet Draft Micromobility Taxonomy November 2001 2.3. Mobility Identity A node can be identified many ways where typical identities include Routing Identity The routing identity by which a given node is addressed is usually the network layer IP address, used for packets sent towards the node. This is needed when this routing identity is used in end-nodes to identify state of a session preserved while on the move. Examples for routing identity are the IP address for network-layer routing and the link-layer address for link-layer routing. Reachability Identity This identity can be used for reaching the node with an immutable name. If the session preservation is not needed, there is no need for routing identity, immutability of the DNS name is all needed. This kind of identity can be called reachability identity. A mobility scenario using reachability identity is dynamic DNS by which a moving node updates its topological location by updating its DNS name to IP address mapping while on the move. Registration Identity This identity can be used for authenticating and authorizing access of a mobile node. An example of this category is the Network Access Identity (NAI) used with some security protocols. Node identity This identity refers to the link-layer or network-layer identity of a node and examples of this type of identity are routing and reachability identities. Characteristic to this type of identity is that it identifies the whole node and not only some component of it even though it can be associated only to a component of the node such as a single network interface. An example would be IP address for the network layer or a MAC address for the link-layer. User identity This identity refers to one above the network-layer, where there can be more than one identity for a host identifying a part of the host, typically an application or a service. Such an identity can be e.g. a port number or a string representation of a service identity. When we have network layer mobility, we can have user Jari T. Malinen et.al. Expires May 2002 [Page 5] Internet Draft Micromobility Taxonomy November 2001 mobility where mobile endpoints are services moving with/within or between nodes. An example would be SIP URL. A micromobility protocol is not commonly believed to deal with user identities. 3. Solution Space Issues A set of issues to solve have been considered for a routing or mobility protocol that considers micromobility. 3.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. 3.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 Jari T. Malinen et.al. Expires May 2002 [Page 6] Internet Draft Micromobility Taxonomy November 2001 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. 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. Jari T. Malinen et.al. Expires May 2002 [Page 7] Internet Draft Micromobility Taxonomy November 2001 3.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 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. 3.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. Jari T. Malinen et.al. Expires May 2002 [Page 8] Internet Draft Micromobility Taxonomy November 2001 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 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 Jari T. Malinen et.al. Expires May 2002 [Page 9] Internet Draft Micromobility Taxonomy November 2001 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 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. 4. Discussion In order to discuss what aspects of micromobility are of interest for further study we consider some rather random examples and discuss whether they can be considered micromobility protocols or not. If one considers immutability of access network-layer address and the possible use of protocol-specific transport, GPRS architecture can be considered to provide a micromobility protocol. Excluding possible GPRS roaming, a node does not change its access network-layer address once it has attached to a GGSN. A tunneling and signaling protocol, GTP, is used to provide transport and manipulate mobility management state within the protocol. The protocol seems to provide a virtual lower-layer with micromobility protocol characteristics below the user-visible network layer. Jari T. Malinen et.al. Expires May 2002 [Page 10] Internet Draft Micromobility Taxonomy November 2001 A roaming support in IEEE 802.11 between access points provide a protocol where the point of attachment changes while the node preserves its networ-layer access address. This can be said to fulfill some of the attributes of a micromobility protocol, but there is no layer independence since IEEE 802.11 is a link-layer protocol. To address benefits of layer-independent micromobility design, combinations of possible layer-independent components of micromobility protocol design should be identified and their scalability discussed. 4.1. Conclusions This text attempts to enumerate and classify some attributes of micromobility protocol designs to give tools for a cost-benefit analysis of existing and imagined micromobility protocol designs. 4.2. Further Work 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. A work item could be to consider the performance issues of various existing proposals in a conceptual level to get better understanding on whether a micromobility protocol would be useful. Issues such as time and space complexity, latency and bandwidth usage, as well as signalling load aspects in particular could be elements in such analyses. 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. Jari T. Malinen et.al. Expires May 2002 [Page 11] Internet Draft Micromobility Taxonomy November 2001 [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. 5. Acknowledgements The authors would like to thank other members of the informal irtf-mm group for initial exchange of opinions. Authors' Addresses 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 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 Jari T. Malinen et.al. Expires May 2002 [Page 12] Internet Draft Micromobility Taxonomy November 2001 Alper 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 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. Jari T. Malinen et.al. Expires May 2002 [Page 13]