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]
