One document matched: draft-ernst-nemo-requirements-00.txt
IETF INTERNET-DRAFT Thierry Ernst, WIDE and INRIA
October 2002
"Network Mobility Support Requirements"
draft-ernst-nemo-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 only (host mobility support).
In contrast, network mobility support (NEMO support) deals with
situations where an entire network changes its point of attachment to
the Internet and thus its reachability in the topology. In this
situation, mobility support is to provide continuous Internet
sessions not only to the router connecting the mobile network to the
global Internet, but also to nodes behind the mobile router. 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 with. Our main aim is to
raise the discussion on the mailing list.
Ernst Expires May 2003 [Page 1]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
Contents
Status of This Memo
Abstract
1. Introduction
2. Overview
2.1. Potential Configurations
2.2. Observations and Constraints
O1: Structure of the mobile network
O2: Mobile Router is a transit point
O3: Dog-leg Routing
O4: Ad-Hoc Network
O5: Scalability
O6: Deployment and Backward Compatibility
O7: Routers in the Mobile Network
O8: Addressing Constraints
3. High-Level Requirements
3.1. Migration Transparency
3.2. Operational Transparency
3.3. Performance Transparency (Seamless Mobility)
3.4. Layers Independence
3.5. NEMO Support Transparency for MNNs
3.7. Minimum Signaling Overload
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. Internet-wide Mobility
3.16. Unified Solution
3.17. Mobile CNs
3.18. Addressing Constraints
4. Basic Support Requirements
5. Extended Support Requirements
Acknowledgments
References
Author's Addresses
Ernst Expires May 2003 [Page 2]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
1. Introduction
Traditional work on mobility support is to provide continuous
Internet connectivity to mobile hosts only (host mobility support).
In contrast, network mobility support (NEMO support) deals with
situations where an entire network changes its point of attachment to
the Internet and thus its reachability in the topology. In this
situation, mobility support is to provide continuous Internet
sessions not only to the router connecting the mobile network to the
global Internet, but also to nodes behind the mobile router.
The purpose of the present 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 support. Other requirements are discussed in
[REQUIREMENTS-1], [REQUIREMENTS-2}, [REQUIREMENTS-3] and
[REQUIREMENTS-4]. All requirements 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. Note that most
requirements discussed for host mobility support, like for instance
in [Bhagwat96], [Myles93], [Castelluccia97], [Caceres96] or many
other papers, are equally applicable to NEMO support. However, they
must be extended and refined to meet the needs of NEMO support.
We assume that the reader is familiar with the terminology defined in
[TERMINOLOGY]. In order to understand the rationale that drives to
the requirements, in section 2, we describe potential network
mobility configurations and we make a number of observations that may
constraint the forthcoming solutions. In section 3, we list some high
level requirements. In section 4 and 5, the high-level requirements
are refined in a more explicit manner for basic support and extended
support. This list is not exhaustive and should be combined with the
requirements found in the other drafts.
Ernst Expires May 2003 [Page 3]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
2. Overview
2.1 Potential Configurations
Network mobility support deals with entire networks of computers
that change their point of attachment to the global Internet and
need to maintain continuous Internet connectivity.
Cases of mobile networks include networks attached to people
(Personal Area Networks or PAN), and networks of sensors and
access networks deployed in vehicles (aircrafts, boats, cars,
trains, etc).
A PAN may be connected to the Internet via a 802.11b WLAN (e.g.
user in a shopping mall) and is likely to change its point of
attachment very frequently, while an aircraft or a boat may be
connected to the Internet via the same satellite link for a couple
of hours. Some mobile networks may not move at all or may be kept
in some sort of home network for a large amount of time
In case mobile networks are access networks providing Internet
access, IP devices carried by people (laptop, camera, mobile
phone, etc) would get access to the Internet via the mobile
network they are located in. In some cases, PANs may also be
carried in the mobile network, in which case there are mobile
networks visiting a larger mobile network. There is thus a need to
achieve two levels of mobility: node mobility and network
mobility.
As people would by definition move from bus to train, thus from a
mobile network to another, mobile nodes and mobile networks
belonging to potentially different administrative domains would
get attached to a mobile network.
Since cases of mobile networks suck like trains, cars, aircrafts
are themselves most likely to cross country boundaries, they are
to move between topologically distant parts of the Internet thus
between ISP boundaries. A mobile network may attach to very
distant parts of the Internet topology, provided it is granted
access to it. In this situation, an Internet-wide mobility scheme,
providing both intra-domain and inter-domain mobility, would be
requested.
The train example is particularly interesting because it shows we
need to consider potentially large mobile networks containing
hundreds of hosts and several routers. Since each mobile network
node (MNN) may be communicating with a few correspondent nodes
(CNs), the total number of CNs could be several times as large as
Ernst Expires May 2003 [Page 4]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
the number of MNNs and scale up to a few thousands. Not to say, a
single server deployed in a vehicle may itself have thousands of
CNs, or even more. Moreover, whatever the situation, CNs are also
most likely to be sparsely distributed in the Internet.
From the above scenarios, at least the following configurations of
mobile networks seem to be desirable:
- mobile networks of any size, ranging from a sole subnet with a
few IP devices to a collection of subnets with hundreds of IP
devices.
- mobile networks with a potentially large number of correspondent
nodes, sparsely distributed in different administrative domains,
- simultaneous access to the Internet provided via distinct
(likely wireless),
- distinct cases of mobile networks moving with distinct mobility
frequencies,
- mobile networks displaced within a domain boundary (intra-domain
mobility) or between domain boundaries (inter-domain mobility),
- foreign mobile nodes that attach to the mobile network,
- nodes that change their point of attachment within the mobile
network,
- nested mobile networks
2.2. Observations and Constraints
In order to drive the discussion on the requirements, this section
lists a number of observations that may constraint or limit the
deployment of a solution which looks potentially good on the
paper.
O1: Structure of the mobile network
A MR changing its point of attachment does not **cause** the MNNs
behind the MR to change their own physical point of attachment.
MNNs MAY appear to move from the point of view of an observer in
the Internet, but their point of attachment in the mobile network
is not modified as a **result** of the mobile network changing its
own point of attachment. In most cases, the internal structure of
the mobile network will in effect be relatively stable (no dynamic
change of the topology), but this is not a general assumption (see
Ernst Expires May 2003 [Page 5]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
section "Ad-hoc networks")
O2: Mobile Router is a transit point
All packets sent between MNNs and a CN outside the mobile network
necessarily transit through one of the MRs of the mobile network.
In the case of nested mobility, packets transit through the root-
NEMO, thus through one of the TLMRs.
O3: Dog-leg Routing
As a result of mobility, routing between a CN in the global
Internet and a mobile node may not be optimal. Packets usually
transit via the home link of the mobile node if no routing
optimization is explicitly performed. In network mobility,
multiple dog-leg routing may be introduced by nested mobility. In
this case, packets intended to a VMN may first transit by the
VMN's home link, then being rerouted to the MR's home link.
Non-optimal routing increases bandwidth consumption and
transmission delays. The amount of traffic intended for the mobile
network is understandably more significant than in the case of a
single mobile node (see section "scalability"), then non-optimal
routing is to 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
has to be balanced against the incurred signaling cost.
O4: Ad-Hoc Network
A mobile network as defined in the IETF NEMO Working Group is not
to be confused with an Ad-hoc network as defined in the IETF MANET
Working Group.
In the MANET WG, an ad-hoc network is an autonomous system made of
mobile nodes (i.e. routers) connected by wireless links. The
routers are free to move randomly and to organize themselves
arbitrary. Topologies are highly dynamic and there is no fixed
infrastructure. Solutions produced by the MANET WG aim at
maintaining routes between highly dynamic nodes. The MANET WG is
also considering how to provide Internet access to the mobile
nodes in the ad-hoc network, but the gateway between the ad-hoc
network and the Internet does not change its point of attachment,
so the MANET WG is not concerned with the mobility management of
an entire network changing its point of attachment.
In the NEMO WG, some routers may effectively move arbitrary, but
this is not a common case. NEMO aims at providing Internet
Ernst Expires May 2003 [Page 6]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
reachability to nodes in the mobile network and at maintaining
session continuity after the mobile network has changed its point
of attachment in the topology.
Thus, the NEMO WG and the MANET WG do not have the same
objectives. However, an Ad-hoc network which gateways to the
Internet would change their point of attachment is likely to be
considered as a special instance of a mobile network and would
thus rely on NEMO solutions to manage the change of the point of
attachment, while routing within the mobile network is only to be
considered by MANET.
O5: Scalability
Scalability has always been considered in the design of new
protocols. This particularly includes signaling load and memory
consumption which must thus be minimized.
For single hosts, host mobility support had to take into
consideration a growing number of mobile hosts and should even
assume that a major part of the nodes composing the Internet would
be mobile in the near future. Thus, it has to scale to an
important number of mobile nodes.
The scalability parameters in NEMO support differ from host
mobility. NEMO support has to scale to:
o a large number of mobile networks (e.g. each vehicle, each
person carrying a PAN)
o a large mobile networks comprising several subnetworks and a
large number of MNNs on each subnetwork (e.g. a train)
o the number of CNs, which is somewhat a function of the size
of the mobile network; the more MNNs a mobile network has, the
more CNs the mobile network is most likely to have. (e.g. each
MNN in a train communicating with a few CNs)
O6: Deployment and Backward Compatibility
In IPv4, minimizing the impact on the already deployed
infrastructure was an important issue since it was not possible to
require all hosts to implement new features. On the other hand, in
IPv6, an important number of specifications has for sure already
been defined, but IPv6 deployment is only dawning, so, it's
theoretically still possible to impose new capabilities on all
hosts. However, it is not desirable. The rule of thumb for any
new protocol is to make use of the existing ones whenever
Ernst Expires May 2003 [Page 7]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
possible, to require no changes on them, and to impose extensions
only when necessary.
The solution for NEMO support must thus be backward compatible
with all existing IPv6 standards. If necessary, it will have to
provide the necessary extensions to maintain backward
compatibility with existing protocols. So, for instance:
o Mobile IPv6: host mobility support in IPv6 is achieved by
Mobile IPv6. NEMO support MUST not prevent the proper operation
of Mobile IPv6.
o IGMP (Mutlticast group membership): 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.
It is also desirable to minimize infrastructure installation costs
and complexity. So, the solution cannot be orthogonally different.
O7: Routers in the Mobile Network
All routers in the Internet are considered to run a number of
protocols such as a routing protocol, Neighbor Discovery, ICMP,
and others. This seems also to apply to routers deployed in mobile
networks, but we have to figure out to what extend, and how.
O8: 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.
3. High Level Requirements
This section details a number of high level requirements that should
be met by the solutions.
3.1. Migration Transparency
In order to provide migration transparency, a permanent and
continuous Internet connectivity must be provided to all MNNs,
without disruption of service. MNNs must always be reachable
regardless of the point of attachment of the MR, and sessions must
be maintained after the MR has changed its point of attachment.
Ernst Expires May 2003 [Page 8]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
3.2. Operational Transparency
In order to be transparent to the applications and the users, NEMO
support must be performed at the network layer.
3.3. Performance Transparency (Seamless Mobility)
NEMO support SHOULD exhibit low latency, incur little or no data
loss, minimum delays, minimum signaling load, and minimum
bandwidth consumption for packet delivery. It should be performed
as seamlessly 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 mobile
network 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. NEMO Support Transparency for MNNs
In section "observation O1", we have seen that "MNNs don't change
their own point of attachment as a result of the mobile network's
displacement in the Internet topology. NEMO support SHOULD
therefore be performed transparently to MNNs and keep them away
from participating in NEMO support. Although MNNs may encounter
variable delays of transmission and loss with their respective CNs
as the network is moving. This is not considered a lack of
transparency. However, receiving movement information may be
useful to hosts able to understand it, so this could be allowed as
an option, and LMNs and VMNs, which are able to change their own
point of attachment must manage their own mobility.
3.7. Minimum Signaling Overload
Mobility management is usually performed at the cost of control
Ernst Expires May 2003 [Page 9]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
traffic. In order to be scalable, NEMO support MUST minimize this
control traffic.
3.12. No impact on CN or Internet routing
Session continuity between a MNN and arbitrary CNs 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 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
NEMO 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. NEMO 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 NEMO
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
Ernst Expires May 2003 [Page 10]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
NEMO support may provide means for MNNs to hide their location
to any third party. It shouldn't be possible to determine the
succession of topological location of a mobile network 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 mobile network 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.
3.15. Internet-wide mobility
In order to ensure permanent and uninterrupted Internet-wide
mobility, mobile network should be able to roam between access
networks belonging to distinct ISPs and corporate networks
(distinct administrative domains, i.e. inter-domain mobility) and
via any available access technology (distinct technologies:802.11b
WLAN, Bluetooth, satellite link, GSM, i.e. heterogeneous
mobility). Indeed, nothing but administrative and security
policies should prevent a mobile network to attach anywhere in the
Internet topology. So, the solution must technically allow this
kind of scenario. In addition, NEMO support must also accommodate
to CNs deployed in distinct administrative domains.
3.16. Unified Solution
Ernst Expires May 2003 [Page 11]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
Should different schemes be proposed, a unified mobility support
scheme is required. A situation where distinct NEMO support
schemes are deployed and unable to inter-operate with each other
must be avoided.
3.17. Mobile CNs
NEMO support MUST be optimized to handle the case where the CN is
MIPv6-enabled and/or itself located in a mobile network
(particularly if it is a VMN). It must perform efficiently in both
cases.
4. Requirements for Basic Support
In this section, the high-level requirements are refined in a more
explicit manner for basic support. This list is not exhaustive and
should be combined with the requirements found in the other drafts.
Requirements follow from our observations and high-level requirements
in section 2 and 3.
Basic support is to maintain session continuity between nodes in the
mobile network and nodes in the global Internet. The solution will
have to meet the following requirements [TO BE DISCUSSED ON THE LIST
- THIS IS A PROPOSITION - AT THAT POINT DON'T TAKE THINGS FOR
GRANTED]:
R1: The solution MUST provide permanent Internet connectivity and
reachability to all nodes behind the MR
R2: The solution MUST maintain continuous sessions between nodes
behind the MR and arbitrary CNs after IP handover of the MR
R3: All the potential configurations MUST be treated the same way
(any number of subnets and MNN, nested mobile networks,
multihomed
mobile networks)
R4: The solution MUST support LFNs, VMNs, and LMNs.
R5: CNs and MNNs must comply with the requirements for IPv6 nodes
defined in [IPv6-NODE]
R6: MNNs MUST NOT be NEMO-enabled (i.e. do not impose changes to
MNNs)
R7: CNs MUST not be NEMO-enabled (i.e. do not impose changes to CNs)
R8: A VMN that gets attached to a link within the mobile network
Ernst Expires May 2003 [Page 12]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
obtains an address on that link.
R9: The solution MUST support nested mobile networks with any number
of mobility levels
R10: The solution MUST support multi-homed mobile network
R10.1 : The solution MUST support mobile networks with multiple
MRs
R10.2: The solution MUST support MR with multiple interfaces
R11: The solution MUST NOT prevent the use of existing protocols
R11.1: The solution MUST allow MNNs to operate the "CN
functionality" of Mobile IPv6
R11.2: The solution MUST support MIPv6-enabled VMNs and LMNs
R11:3: The solution will ensure that mechanisms related to
multi-homing
(defined within other WGs in IETF) will be useful for
NEMO"
R12: The solution MUST support a large number of mobile networks
R12: The solution MUST support a large number of CNs
R13: The solution MUST support vertical handoff
R14: The solution MUST support horizontal handoff
R15: The solution SHOULD support fast handoff
R16: The solution MUST support inter-domain mobility
R17: The solution MUST support heterogeneous mobility
R18: The solution MUST minimize control traffic
5. Requirements for Extended Support
In this section, the high-level requirements are refined in a more
explicit manner for extended support. This list is not exhaustive and
should be combined with the requirements found in the other drafts.
Ernst Expires May 2003 [Page 13]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
Extended support is to optimize routing between CNs and arbitrary
MNNs and must support the following requirements (non exhaustive
list, to be completed later)
R1: The solution for Extended support must seat on top of Basic
support.
This means it must comply with the requirements defined under
"Basic support" and co-exist with it without disturbing it or any
of the nodes that do not need/understand it.
R2: MNNs and CNs MAY be NEMO-enabled as a means to improve routing.
As
such be notified and take action upon the change of point of
attachment of the MR.
R3: The solution must preserve route aggregation in the Internet
R4: The solution must minimize control traffic.
RXXXX: To be continued. Many more to be added later.
Ernst Expires May 2003 [Page 14]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
Acknowledgments
The material presented in this document takes most of the text from
our former internet-drafts submitted to MobileIP WG and to the former
MONET BOF, co-authored with Hong-Yon Lach, which where themselves
based on original text from [Ernst01]. The author would therefore
like to thank both Motorola Labs Paris and INRIA (PLANETE team,
Grenoble, France), for the opportunity to bring this topic to the
IETF since 2000, and particularly Hong-Yon Lach (Motorola) and Claude
Castelluccia (INRIA) for their advices, suggestions, and direction.
We also acknowledge the contribution from Alexandru Petrescu
(Motorola), Christophe Janneteau (Motorola), Hesham Soliman
(Ericsson), Mattias Petterson (Ericsson) and Keisuke Uehara (Keio
University). We are grateful to people in the InternetCAR team (Keio
University) and all the people on the NEMO (formerly MONET) mailing
list for their comments and suggestions on the NEMO ML which helped
to improve this draft (Greg Daley, Pascal Thubert, James Kempf, TJ
Kniveton, and other we may have forgot to include here)
References
[Bhagwat96] P. Bhagwat, S. Tripathi, and C. Perkins.
"Network Layer Mobility: an Architecture and Survey"
IEEE Personal Communications, 3(3):54, June 1996.
[Caceres96] R. Caceres and V.N. Padmanabhan.
"Fast and scalable handoffs for wireles
internetworks"
In Proc. of the Second ACM/IEEE MOBICOM,
New-York, USA, November 1996.
[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. http://www.inria.fr/rrrt/tu-0714.html
[IPv6-NODE] John Loughney
"IPv6 Node Requirements"
draft-ietf-ipv6-node-requirements-01.txt
July 2002, Work in progress.
Ernst Expires May 2003 [Page 15]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
[MIPv6] David B. Johnson and C. Perkins.
"Mobility Support in IPv6"
draft-ietf-mobileip-ipv6-18.txt,
July 2002. 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.
[PSBU] T. Ernst et al.
"Mobile Networks Support in Mobile IPv6
(Prefix Scope Binding Updates)"
draft-ernst-mobileip-v6-network-03.txt,
March 2002. Work in progress
[RFC1122] R. Braden (editor).
"Requirements for Internet Hosts - Communication
Layers". IETF RFC 1122, October 1989.
[RFC2460] S. Deering and R. Hinden.
"Internet Protocol Version 6 (IPv6) Specification"
IETF RFC 2460, December 1998.
[REQUIREMENTS-1] Hesham Soliman
"Problem Scope",
Internet-Draft draft-soliman-monet-scope-00.txt,
February 2002. Expired
[REQUIREMENTS-2] H.-Y. Lach, C. Janneteau, A. Petrescu
"Mobile Network Scenarios, Scope and Requirements",
draft-lach-nemo-requirements-00.txt,
October 2002.
[REQUIREMENTS-3] T.J. Kniveton, A. Yegin
"Problem Scope and Requirements for Mobile Networks
Working Group"
draft-kniveton-monet-requirements.txt,
February 2002. Expired
[REQUIREMENTS-4] C. W. Ng, and T. Tanaka
"Usage Scenario and Requirements for AAA in Network
Mobility Support"
draft-ng-nemo-aaa-use-00.txt October
2002. Work in progress
[TERMINOLOGY] Thierry Ernst and Hong-Yon Lach
"Terminology for Network Mobility Support",
Ernst Expires May 2003 [Page 16]
INTERNET-DRAFT Network Mobility Support Requirements February 2002
draft-ernst-nemo-terminology-00.txt,
October 2002. Work in progress.
Author's Addresses
Questions about this document can be directed to the authors:
Thierry Ernst,
WIDE Project and INRIA
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/
Ernst Expires May 2003 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-22 22:58:01 |