IETF INTERNET-DRAFT Thierry Ernst
WIDE Project / INRIA
Hong-Yon Lach
Motorola Labs
February 2002
"Network Mobility Support Requirements"
draft-ernst-monet-requirements-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.
Abstract
The purpose of traditional mobility support is to provide continuous
Internet connectivity to mobile hosts (host mobility support). In
contrast, network mobility support is concerned with situations where
an entire network changes its point of attachment to the Internet and
thus its reachability in the topology. We shall refer to such a
network as a mobile network (MONET). This document tries to identify
what constraints limit the implementation and the deployment of a
potentially and ideally good solution, and what requirements
solutions must comply to. Our main aim is to raise the discussion on
the mailing list.
Ernst and Lach Expires August 2002 [Page 1]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
Contents
Status of This Memo
Abstract
1. Introduction
2. Important Disclaimer
3. Design Requirements
3.1. Migration Transparency (Permanent Connectivity)
3.2. Operational Transparency
3.3. Performance Transparency (Seamless Mobility)
3.4. Layers Independence
3.5. Mobility Management Transparency for MNNs
3.6. Scalability
3.7. Minimum Signaling Overload
3.8. Routing Optimization in 6 3.9. Nested Mobility
3.10. Backward Compatibility
3.11. Minimum Impact on Existing Protocols and Infrastructure
3.12. No impact on CNs or Internet routing
3.13. Security
3.13.1. Confidentiality
3.13.2. Authentication
3.13.3. Authorization
3.13.4. Location Privacy
3.14. Access Control
3.14.1. Access Control for VMNs
3.14.2. Access Control Architecture
3.14.3. Access Control in the Fixed Network
3.15. Wide-Area Mobility
3.16. Unified Solution
3.17. Mobile CNs
3.18. Addressing Constraints
Acknowledgments
References
Author's Addresses
Ernst and Lach Expires August 2002 [Page 2]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
1. Introduction
This document assumes that the reader is familiar with the
terminology defined in [TERMINOLOGY] while reading [SCOPE] for a
description of the problems is recommended.
The purpose of traditional mobility support is to provide continuous
Internet connectivity to mobile hosts (host mobility support). In
contrast, network mobility support is concerned with situations where
an entire network changes its point of attachment to the Internet and
thus its reachability in the topology. We shall refer to such a
network as a mobile network (MONET). Cases of mobile networks include
networks attached to people (Personal Area Networks or PAN), and
networks of sensors deployed in aircrafts, boats, busses, cars,
train, etc that need a permanent Internet connection. Those mobile
networks may also provide Internet access to devices carried by
people (laptop, camera, mobile phone, etc, and PAN).
As exhibited by the scenarios depicted in [TERMINOLOGY] and [SCOPE],
there is a desire to achieve two levels of mobility: node mobility
and network mobility. A passenger is a mobile node which visits a
mobile network (VMN in a MONET), and passengers may themselves be
mobile IP-subnets (MONET in a MONET), for example when carrying a
PAN. Since people move from a MONET to another, and since instances
of MONETs like trains, car, aircrafts cross country boundaries, both
VMNs and MONETs are also most likely to cross ISP boundaries and
therefore to move between topologically distant parts of the
Internet. This means we must allow VMNs belonging to potentially
different administrative domains to visit the MONET. The instances
highlighted above also justify the need to consider potentially large
MONETs containing hundreds of hosts and several routers. The train
example highlights that the number of correspondent nodes could also
be very large, and that these may be sparsely distributed in the
Internet. It also justifies the need for true worldwide mobility in
the Internet. A MONET may attach to very distant parts of the
Internet topology, provided it is granted access to it, therefore
requiring both Local-Area Mobility support and Wide-Area Mobility
support.
The problems that need to be addressed are illustrated in [SCOPE]
while the purpose of this document is to raise discussion in order to
identify what constraints limit the implementation and the deployment
of a potentially and ideally good solution, and what requirements
solutions must comply to. Most constraints and requirements that we
have listed are equally applicable to host mobility support and
network mobility support. Some of them have been debated in the
literature as far as host mobility support was concerned; we have
extended this list to include those related to network mobility
Ernst and Lach Expires August 2002 [Page 3]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
support.
The material presented in this document is based on [Ernst01] and on
our former internet-draft that was submitted in July 2001 [OLD-draft]
for the consideration of the Mobile IP Working Group. This former
draft was defining the terminology that is now found in [TERMINOLOGY]
and a list of requirements and issues as an attempt to clarify the
problem caused by networks in motion and now found in this present
document. It was also mentioning a number of issues (impact on
addressing, routing, and existing network protocols). We have decided
to split this former document in two because requirements are more
subject to discussion and disagreements that the terminology on which
we must agree on to base our discussions. More information may be
found on the MONET web page [WEB-MONET]. Note that this list of
requirements is primarily targeted to IPv6 [RFC2460], but is not
limited to it, and that the already existing network mobility support
proposals [MONET-PSBU], [HMIPv6], and [MOBRTR] don't necessarily meet
these requirements.
2. Important Disclaimer
The stated opinions in this draft come from various sources and are
not necessarily the opinions of the authors. The purpose of this
draft is for open discussions.
3. Design Requirements
This section details what requirements MUST or SHOULD be fulfilled by
solutions, and what constraints may limit the deployment of a
potentially good solution. Most requirements discussed for host
mobility support, like for instance [Bhagwat96], [Myles93],
[Castelluccia97] or [Caceres96], are equally applicable to network
mobility support. However, they must be extended and refined to
comply with the specific characteristics. All requirements we have
listed may not be satisfied by a single solution. For the sake of
modularity, we may decide to use separate solutions for different
aspects of the problem space. Moreover, some of them are
controversial and are subject to discussions on the mailing list
[WEB-MONET]. It is assumed that the reader has read [TERMINOLOGY].
3.1. Migration Transparency (Permanent Connectivity)
Network mobility support MUST provide permanent and continuous
Internet connectivity to all MNNs without disruption of service
for MNNs. This means that all MNNs MUST always be reachable
regardless of the point of attachment of the MONET.
Ernst and Lach Expires August 2002 [Page 4]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
3.2. Operational Transparency
The network layer MUST be able of supporting connectivity of the
MONET in an absolute transparent manner to the application or the
user.
3.3. Performance Transparency (Seamless Mobility)
Network mobility support SHOULD exhibit low latency, incur little
or no data loss, minimum delays, minimum signaling load, and
minimum bandwidth consumption for packet delivery. In other words,
network mobility support SHOULD be as seamless as host mobility is
supported (no abrupt degradation of service).
3.4. Layers Independence
Handover of IP sessions is performed at the network layer. With
respect to the layer separation of the Internet protocol suite,
handover MUST be managed at the network layer only and
transparently to upper layers, despite the migration of the MONET
in the network topology. Therefore, a change of topological
location MUST not have an impact on layers above the network layer
other than a transient loss of performance, as depicted in the
above paragraph. If this is respected, compatibility with existing
transport and application layers is maintained. In practice, the
identifiers used at the transport layer should be independent from
the physical IP addresses used at the network layer for routing.
If upper layer protocols require a location independent and
invariant identifier, the network layer MUST provide it with an
identifier irrespective of the actual topological location.
3.5. Mobility Management Transparency for MNNs
We have seen in [TERMINOLOGY] that MNNs don't change their own
point of attachment as a result of the MONET's displacement in the
Internet topology. Mobility management of a MONET SHOULD therefore
be performed transparently to MNNs, at least to LFNs. LFNs SHOULD
(MUST ?) better have no responsibility in network mobility
management, whereas LMNs and VMNs SHOULD only be concerned about
managing their own mobility if they themselves appear to change
their point of attachment. However, MNNs may encounter variable
delays of transmission and loss with their respective CNs as the
network is moving. [WE WANT TO DISCUSS THIS REQUIREMENT IN THE
MAILING LIST]
3.6. Scalability
Scalability has always been an important concern in the design of
Ernst and Lach Expires August 2002 [Page 5]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
new protocols. As far as host mobility is concerned, mobility
support has to take into consideration a growing number of mobile
hosts and should even assume that a major part of the nodes
composing the Internet are mobile in the near future. This means
that signaling load and memory consumption should scale to an
important number of mobile nodes. However, network mobility
support is concerned by scalability differently, and in three
ways:
o large number of MONETs (e.g. PAN comprising a few devices and
carried by every human being).
o large MONETs comprising several subnetworks and a large
number of MNNs on each subnetwork (e.g. a train)
o the number of CNs is somewhat a function of the size of the
MONET; the more MNNs a MONET has, the more CNs the MONET is
most likely to have. (e.g. each MNN in a train communicating
with a few CNs)
Network mobility support MUST thus be able to support large
MONETs, a very large number of small MONETs, and a large number of
CNs. Scaling to a large number of CNs may indeed deserves more
consideration than scaling to a large number of MONETs. This has
never been considered in host mobility support, to the contrary of
the ability to support a large number of mobile nodes.
3.7. Minimum Signaling Overload
Mobility management is usually performed at the cost of control
traffic. Network mobility support MUST minimize this control
traffic, all the more for the reasons outlined in section
"scalability".
3.8. Routing Optimization
Network mobility support SHOULD optimize routing. Non-optimal
routing increases bandwidth consumption and transmission delays.
The amount of traffic intended for the MONET is understandably
more significant than in the case of a single mobile node (see
section "scalability"), then non-optimal routing SHOULD be
considered with more care than for host mobility support. However,
efficient routing is usually performed at the expense of increased
signaling. Thus, the gain of optimal routing MUST be balanced
against the incurred signaling cost.
3.9. Nested Mobility
Ernst and Lach Expires August 2002 [Page 6]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
Network mobility support MUST support nested mobility. It MUST at
least allow single VMNs to enter the MONET, single LMNs to leave
the MONET, and single mobile IP-subnet attach the MONET (instance
of a PAN in a train). Network mobility support must therefore
consider both MONETs and mobile nodes, otherwise it may hardly
interact with host mobility support. In practice, it should handle
VMNs as optimally as if networks were fixed. The working group
needs to agree if it MUST support any number of levels or be
limited to only two levels.
3.10. Backward Compatibility
Network mobility support is constrained by backward compatibility
with existing and forthcoming IPv6 standards. As such, it MUST not
prevent MNNs to operate any standardized protocol. This
particularly includes but is not limited to Mobile IPv6 (host
mobility) and IGMP (multicast group membership):
o Host Mobility Support Constraints: host mobility support in
IPv6 is achieved by Mobile IPv6 which is a compulsory component
of any IPv6 implementation. This means that network mobility
support MUST not prevent LMNs and VMNs from operating Mobile
IPv6 once located in a MONET.
o Multicast Constraints: any IPv6 router is supposed to allow
hosts on its attached subnetworks to participate in multicast
sessions. Group membership is gathered by the IGMP protocol.
Network mobility support MUST not prevent this.
In both cases, the network mobility support MUST provide the
necessary extensions to maintain backward compatibility with
existing protocols.
3.11. Minimum Impact on Existing Protocols and Infrastructure
Minimum impact on the already deployed infrastructure was an
important issue as far as IPv4 was concerned since it was not
possible to require all hosts to implement new features. On the
other hand, the emergence of IPv6 is an opportunity for making
changes, if necessary. An important number of specifications has
already been defined, but there is still scope for adding new
capabilities if needed since IPv6 deployment is only dawning.
However, in order to provide a quickly deployable solution,
network mobility support SHOULD better make use of the existing
protocols whenever possible and impose minimum changes or
extensions on the existing ones. It is also desirable to minimize
infrastructure installation costs and complexity.
Ernst and Lach Expires August 2002 [Page 7]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
3.12. No impact on CN or Internet routing
To be able successfully deploy the final solution, session
continuity between a MNN and a CN anywhere in the Internet SHOULD
NOT assume any changes to existing CNs or the Internet routing
architecture. On the other hand, optimizations for performance
enhancement MAY involve some changes to CNs, provided that such
optimizations would not cause any disruption to ongoing sessions,
if not supported by CNs (i.e. backward compatible). [THIS
REQUIREMENT IS TO BE DISCUSSED (in light of the observation made
in section "Minimum Impact on the Existing Protocols and
Infrastructure" here above) BECAUSE IT WOULD PREVENT POTENTIALLY
INTERESTING AND ORTHOGONAL SOLUTIONS TO BE PROPOSED].
3.13. Security
Network mobility support must comply with usual IPv6 security
policies and standardized protocols. In addition, and unlike fixed
nodes, MNNs are more exposed to security threats, particularly
identity usurpation. Network mobility support must provide MNNs
and their CNs with at least as good security as for fixed nodes
and mobile hosts. It particularly shouldn't leave more room for
intruders to usurp an identify nor to perpetrate any kind of
attack against the MNNs nor the CNs. In practice, all control
messages required by network mobility support must be exchanged in
a secure manner and must ensure the following:
3.13.1. Confidentiality
All control messages transmitted in the network MUST ensure
MNNs' confidentiality. Only the recipient of the control
message may be able to decrypt the content of the datagram.
3.13.2. Authentication
All control messages MUST be authenticated by recipients in
order to prevent intruders to usurp the identity of a MNN.
3.13.3. Authorization
The recipient of a control message MUST ensure that the sender
is effectively authorized to perform the mobility support
operation indicated in the control message.
3.13.4. Location Privacy
Network mobility support may provide means for MNNs to hide
their location to any third party. It shouldn't be possible to
Ernst and Lach Expires August 2002 [Page 8]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
determine the succession of topological location of a MONET or
a particular MNN by monitoring the exchange of control
messages. In practice, MNNs may wish to hide their location to
some or all of their CNs, or anyone else but the CNs. It may
also be desirable to hide the location of the entire MONET to
all CNs without discrimination between MNNs.
3.14. Access Control
3.14.1. Access Control for VMNs
Mobile Networks MUST be able to authenticate and authorize VMNs to
gain access to the Internet via the mobile network infrastructure
(MRs).
3.14.2. Access Control Architecture
To be able to comply with the current access control mechanisms
and achieve a scalable solution, the final solution MUST NOT
assume that the fixed network would authenticate VMNs. VMN
authentication and authorization MUST be the responsibility of the
mobile network.
3.14.3. Access Control in the Fixed Network
AAA solutions MUST allow for authenticating an entire network.
This MAY simply be done by ensuring that the Authentication and
Authorization is not necessarily performed for a single IP
address. This is particularly important for IPv6 as each node may
configure multiple addresses. [THIS MAY BE SUGGESTING A SOLUTION
BUT WE WANT IT TO BE DISCUSSED ON THE MAILING LIST].
3.15. Wide-Area Mobility
Network mobility support MUST provide means for a MONET to move
between heterogeneous networks, i.e. Wide-Area Mobility. This is
required in order to ensure permanent and uninterrupted world-wide
mobility. Nothing but administrative and security policies should
prevent a MONET to attach anywhere in the Internet topology. In
practice, a given MONET MUST be able to roam between
administratively distinct access networks (between Internet
Service Providers and corporate networks) and via any available
access technology (802.11b WLAN, Bluetooth, satellite link, GSM,
...). In addition, network mobility support must also accommodate
to CNs deployed in distinct administrative domains.
3.16. Unified Solution
Ernst and Lach Expires August 2002 [Page 9]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
Should different schemes be proposed, a unified mobility support
scheme is required. We must avoid a situation where distinct
network mobility support schemes are deployed and unable to inter-
operate with each other.
3.17. Mobile CNs
Network mobility support MUST be optimized to handle the case
where the CN is itself a MN (as defined by [MIPv6]) or located in
a MONET (particularly if it is a VMN). It must perform efficiently
in both cases.
3.18. Addressing Constraints
The IP address is used for routing and to identify the subnetwork
where an interface is attached to. Each interface on a subnetwork
must therefore be configured with the network prefix of that
subnetwork.
Ernst and Lach Expires August 2002 [Page 10]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
Acknowledgments
The first author would like to thank both Motorola Labs Paris and
INRIA Rhône-Alpes, for the opportunity to bring this topic to the
IETF and more particularly Claude Castelluccia (INRIA) for its
advices, suggestions, and direction. In addition, we acknowledge
Alexandru Petrescu (Motorola), Mattias Petterson (Ericsson), Hesham
Soliman (Ericsson) and the NACM people from WIDE (Keio University)
for their comments and suggestions on this draft.
References
[Bhagwat96] Pravin Bhagwat, Satish Tripathi, and Charles Perkins.
Network Layer Mobility: an Architecture and Survey. IEEE Personal
Communications, 3(3):54, June 1996.
[Caceres96] Ramon Caceres and Venkata N. Padmanabhan. "fast and
scalable handoffs for wireles internetworks". In Proc. of the Second
ACM/IEEE International Conference on Mobile Computing and Networking
(MobiCom), Rye, New York, USA, November 1996. Bell Laboratories and
University of California at Berkeley.
[Castelluccia98] Claude Castelluccia. A Hierarchical Mobility
Management Scheme for IPv6. Third Symposium on Computers and
Communications (ISCC'98), Athens, Greece, June 1998.
http://www.inrialpes.fr/planete
[Ernst01] Thierry Ernst "Network Mobility Support in IPv6", PhD
Thesis, University Joseph Fourier Grenoble, France. October 2001.
[HMIPv6] H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier,
"Hierarchical MIPv6 mobility management", draft-ietf-mobileip-
hmipv6-05.txt. Work in progress
[MIPv6] David B. Johnson and C. Perkins. Mobility Support in IPv6.
draft-ietf-mobileip-ipv6-14.txt, July 2001. Work in progress.
[MOBRTR] T.J. Kniveton, J. J. Malinen, V. Devarapalli and C. E.
Perkins, "Mobile router support in Mobile IP", draft-kniveton-
mobrtr-00.txt. Work in progress.
[Myles93] Andrew Myles and David Skellern. Comparing Four IP Based
Mobile Host Protocols. In Joint- European Networking Conference.
Macquarie University, Sydney, Australia, May 1993.
[OLD-draft] Thierry Ernst, Hong-Yon Lach, Claude Castelluccia
"Network Mobility Support in IPv6: Problem Statement and
Requirements", draft-ernst-mobileip-monetv6-00.txt, July 2001.
Ernst and Lach Expires August 2002 [Page 11]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
Expiration pending.
[MONET-PSBU] T. Ernst, L. Bellier, A. Olivereau, C. Castelluccia,
H.-Y. Lach, "Mobile Networks Support in Mobile IPv6 (Prefix Scope
Binding Updates)" draft-ernst-mobileip-v6-network-02.txt, June 2001.
Work in progress
[RFC1122] R. Braden (editor). Requirements for Internet Hosts -
Communication Layers. Request For Comments 1122, Internet
Engineering Task Force (IETF), October 1989.
[RFC2460] S. Deering and R. Hinden. Internet Protocol Version 6
(IPv6) Specification. Request For Comments 2460, Internet
Engineering Task Force (IETF), December 1998.
[SCOPE] Hesham Soliman "Problem Scope" IETF internet-draft draft-
soliman-monet-scope-00.txt, Work in progress.
[TERMINOLOGY] Thierry Ernst "Terminology for Network Mobility
Support", draft-ernst-monet-terminology-00.txt, February 2002. Work
in progress.
[WEB-MONET] MONET web page http://www.nal.motlabs.com/monet
Ernst and Lach Expires August 2002 [Page 12]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
Author's Addresses
Questions about this document can be directed to the authors:
Thierry Ernst,
WIDE Project
Jun Murai lab. Faculty of Environmental Information,
Keio University.
5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan.
Phone : +81-466-49-1100
Fax : +81-466-49-1395
E-mail: ernst@sfc.wide.ad.jp
Web: http://www.sfc.wide.ad.jp/~ernst/
Hong-Yon Lach
Motorola Labs Paris, Lab Manager,
Networking and Applications Lab (NAL)
Espace Technologique - Saint Aubin
91193 Gif-sur-Yvette Cedex, France
Phone: +33-169-35-25-36
Email: Hong-Yon.Lach@crm.mot.com
Ernst and Lach Expires August 2002 [Page 13]