INTERNET-DRAFT Thomas Clausen
IETF NEMO Working Group Emmanuel Baccelli
Expiration: 15 April 2005 LIX, Ecole Polytechnique, France
Ryuji Wakikawa
Keio University/WIDE
15 October 2004
NEMO Route Optimisation Problem Statement
draft-clausen-nemo-ro-problem-statement-00.txt
Status of this Memo
This document is a submission to the Network Mobility Working Group
of the Internet Engineering Task Force (IETF). Comments should be
submitted to the nemo@ietf.org mailing list.
Distribution of this memo is unlimited.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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 NEMO working group has developed a protocol suite, extending the
notion of edge-mobility on the Internet to include that of network
mobility. This implies that a set of nodes, along with their mobile
router, change their point of attachment and that traffic to these
nodes is tunneled to be delivered through their new point of
Clausen, Baccelli, Wakikawa [Page 1]
INTERNET-DRAFT RO Problem Statement 15 October 2004
attachment. This mechanism is transparent to applications in that
existing traffic to a node is being encapsulated and tunneled,
regardless of where the network containing the destination node is
attached.
The NEMO specification is not limited to a single level of mobile
networks, attaching to the stationary Internet. Rather, arbitrary
levels of nested mobile networks are supported, employing for each
level of nesting the same encapsulation and tunneling mechanisms.
With arbitrarily deep nested mobile networks, the overhead incurred
through tunneling and encapsulation of data traffic can, however,
become large. As a consequence, a number of different proposals
exist, which aim at performing "route optimization" for nested mobile
networks.
This document aims at describing the different scenarios in which
route-optimization is desired, as well as the different proposed
solutions for achieving route-optimization in nested mobile networks.
Clausen, Baccelli, Wakikawa [Page 2]
INTERNET-DRAFT RO Problem Statement 15 October 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. NEMO-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Internet-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . 6
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. NEMO-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Route Optimization Mechanisms Within Nested NEMO . . . . . . 9
3.1.2. Ad-hoc Network of Mobile Routers . . . . . . . . . . . . . . 9
3.2. Internet-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. Route Optimization Mechanisms Initiated by MR or MNN . . . . 11
3.2.2. Route Optimization Initiated by a Non-Mobile Router . . . . . 12
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Clausen, Baccelli, Wakikawa [Page 3]
INTERNET-DRAFT RO Problem Statement 15 October 2004
1. Introduction
The NEMO protocol suite extends Mobile IP in enabling a set of nodes,
along with their mobile router, to change their point of attachment
to the Internet. NEMO enables the traffic to these nodes to be tun-
neled for delivery through their new point of attachment. The use of
tunneling makes this mechanism transparent to applications, wherever
the new point of attachement, even in case of several layers of
nested mobility (i.e. mobile nodes, or mobile routers, indirectly
accessing the Internet through other mobile routers).
However, this approach is not without a certain cost: with arbitrar-
ily deep nested mobile networks, the overhead due to tunneling, dog-
leg routing and encapsulation of data traffic can become large. A
number of different solutions have been proposed in order to optimize
this routing in some of these cases.
A review of some of these solutions is provided in this document, as
well as the discussion of which cases and to what extent route opti-
mization is desireable with NEMO.
1.1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [5].
It is assumed that readers are familiar with NEMO terminology as
described and employed in [1] and [8].
1.2. Applicability
This document aims at discussing scenarios where route optimization
is desirable in a NEMO environment, and what level of route optimiza-
tion is desired in those cases. A review of some existing solutions
and ideas is thereby provided.
2. Scenarios
At least two distinct scenarios exist, where route optimization is
desireable. Those are, respectively, when a node in a NEMO network
wishes to communicate with a node in another NEMO network which is
part of the same nesting, and when a node from the Internet wishes to
communicate with a node in a nested NEMO network.
Clausen, Baccelli, Wakikawa [Page 4]
INTERNET-DRAFT RO Problem Statement 15 October 2004
While the scenarios may have commonalities, their possible solution-
space differs and they are therefore described seperately below.
2.1. NEMO-to-NEMO
In this scenario, a number of NEMO networks are nested to one
another, and nodes in the different NEMO networks are communicating
with one another. For the purpose of this scenario description, refer
to the schematics below:
---------- ---------- ----------
| | | | | |
| NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet
| | | | | | |
---------- ---------- ---------- |
| ----------
---------- | | |
| | |----| HA 2 |
| HA 1 |---------| | |
| | | ----------
---------- |
----------
| |
| HA 3 |
| |
----------
Figure 1: Nested NEMO networks -- NEMO-to-NEMO communication
We assume that each box labeled "NEMO x" refers to a Mobile Router
(MR), running the NEMO protocol, as well as the nodes attached to
that mobile router. We further assume, that each line indicates a
direct connection between routers -- i.e. the mobile router in "NEMO
1" has a direct connection to the mobile router in "NEMO 2". Each box
labeled "HA x" refers to the Home Agent for the NEMO network x --
i.e. that HA 1 is the Home Agent for the mobile network NEMO 1.
If a node from NEMO 3 wishes to communicate with a node from "NEMO
1", then the data traffic would first be sent to the Home Agent of
NEMO 1 -- i.e. to HA 1. At HA 1, a binding would exist, identifying
NEMO 1 as being attached to the network of NEMO 2. Thus, the traffic
would be encapsulated, and sent to the HA of NEMO 2, i.e. HA 2. At HA
2, a binding would exist, identifying that, indeed, NEMO 2 is
attached to the network of NEMO 3. Another encapsulation would
ensure, and the traffic sent to HA 3. At HA 3, a binding would
Clausen, Baccelli, Wakikawa [Page 5]
INTERNET-DRAFT RO Problem Statement 15 October 2004
identify the point of attachment of NEMO 3 to the internet, and the
data traffic would be encapsulated one final time prior to being
delivered to NEMO 3 -- where decapsulation and handoff to NEMO 2,
then NEMO 1 occurs.
In this scenario, short path between NEMO 1 and NEMO 3, without
transversing the Internet and HA1-3, exists, however is not used in
the current NEMO specification.
More generally, assume a set of NEMO networks forming a connected
network via their mobile routers without transversing the Internet.
For communication between nodes in these NEMO networks, a solution
should exist, which provides routes between the nodes without
transversing the Internet and without incuring excessive nested
encapsulations.
2.2. Internet-to-NEMO
In this scenario, a number of NEMO networks are nested to one
another, and a node in the Internet wishes to communicate to a node
in one of the NEMO networks. For the purpose of this scenario
description, refer to the schematics below:
---------- ---------- ---------- ----------
| | | | | | | |
| NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet--| Node 1 |
| | | | | | | | |
---------- ---------- ---------- | ----------
| ----------
---------- | | |
| | |----| HA 2 |
| HA 1 |---------| | |
| | | ----------
---------- |
----------
| |
| HA 3 |
| |
----------
Figure 2: Nested NEMO networks -- Internet-to-NEMO communication
The node labeled "Node 1" wishes to communicate with a node in NEMO
1. Similarly to the previous scenario, this will happen through con-
necting to HA 1, then encapsulation and tunneling data to HA 2 and
HA3 before the data arrives at the edge of our nested NEMO network.
Clausen, Baccelli, Wakikawa [Page 6]
INTERNET-DRAFT RO Problem Statement 15 October 2004
Only then can decapsulation and transmission via NEMO 3, NEMO 2 and
NEMO 1 happen.
In this scenario, while no direct link exists between Node 1 and the
node in NEMO 1, triple encapsulation and transmission via HA1-3
occurs.
More generally, a path between a node in the Internet and the edge of
the nested NEMO networks exists, which does not necessarilly involve
any of the Home Agents for the NEMO networks. For such communication,
a solution should exist which avoids nested encapsulations (i.e.
allows data to be encapsulated only once, in order to arrive at the
edge of the nested NEMO networks), and which does not force a path
which involves all the Home Agents of the nested NEMO networks on the
path to the destination.
In addition, nested encapsulation brings a limitation to the number
of nested levels, due to MTU size. For example, the current NEMO
basic support specification does not allow a level higher than 40 in
nesting in NEMO (with usual MTU = 1500 bytes), due to the size of the
40 IPv6 headers, i.e. 40 bytes x 40 > MTU. In this case IP fragmen-
tation does not help, since the total size of IPv6 headers exceeds
the MTU. Thus, the avoidance of nested encapsulations also eliminates
the limitation on the level of nesting in NEMO.
3. Solutions
Common for the scenarios from the previous section is, that the
encapsulation and tunneling is due to the facts that:
- the node which originates data traffic does not know where the
destination node is located and therefore assumes that the
node is at its Home Network;
- no router knows the full path to the destination, which in
particular means that:
- no router knows the topology of the nested NEMO network(s).
As a concequence, each logical hop (from source to Home Agent of des-
tination, or from Home Agent to Home Agent of the nested NEMO net-
works) adds layers of encapsulation, until the point of attachment
between the Internet and the NEMO edge, the Access Router (AR) is
reached.
Concequently, if the source node, or any intermediate node, had addi-
tional information about the network topology, more beneficial
Clausen, Baccelli, Wakikawa [Page 7]
INTERNET-DRAFT RO Problem Statement 15 October 2004
tunnels could be created, and less encapsulation would be required.
For example if, in figure 2 above, Node 1 knew directly that the
gateway from the Internet to "the network where nodes from NEMO 1 are
attached" was the Access Router of NEMO 3, and if the mobile router
in NEMO 3 knew the topology of the nested NEMO network, a tunnel
could be directly created from Node 1 to NEMO 3, with assurance that
the mobile router in NEMO 3 would be able to route data packets cor-
rectly to the destination.
3.1. NEMO-to-NEMO
The NEMO-to-NEMO problem, as described in section 2.1, is one of how
to avoid transversing the Internet in order to communicate between
two nodes which are part of the same nested NEMO network. More gener-
ally, this can be expressed as "how traffic is routed within the NEMO
network".
NEMO basic support [1] specifies that traffic be routed via Home
Agents, indicating an assumption of limited depth of nested networks
and traffic patterns being predominantly traffic of the Internet-to-
NEMO type. Each mobile router in a NEMO network knows only of its
attachments, i.e. its access router and the nodes within its own
mobile network. A mobile router in NEMO does not know about any nest-
ings, i.e. it does not know the topology of the nested NEMO network
-- and as such, can only provide routes to the Home Agents on the
Internet.
In order to avoid the scenario described in section 2.1, where data
packets for delivery within the nested NEMO network are routed
through the Internet and the nested networks Home Agents, when a more
localized aproach would have been possible, additional state can be
maintained in the nested NEMO networks. A number of approaches for
maintaining state in mobile routers and/or Home Agents of mobile net-
works have been discussed, including [3], [4], [9], [10], [11], [12],
[13], in which techniques such as route caching are discussed. These
techniques can be deployed in Home Agents, in routers, specifically
designated as aggregation points for NEMO tunnels, as well as within
the mobile routers in order to optimize routes within a nested NEMO
network. This is detailed in section 3.1.1.
Essentially, however, the issue of route optimization within a nested
NEMO network is one of routing: maintaining state in each mobile
router such that an intelligent forwarding decision can be made.
I.e., if the destination can be detected to be "local" to the nest of
NEMO networks, a route to the destination can be constructed directly
Clausen, Baccelli, Wakikawa [Page 8]
INTERNET-DRAFT RO Problem Statement 15 October 2004
through the NEMO mobile routers without passing through the Home
Agents. Alternatively, if the destination is not local, data are
routed to the Home Agent, where basic NEMO tunneling and encapsula-
tion take effect. Deploying a routing protocol for maintaining suffi-
cient state in the nodes in the nested NEMO network is detailed in
section 3.1.2.
3.1.1. Route Optimization Mechanisms Within Nested NEMO
Some approaches have been proposed to tackle the problem of route
optimization inside nested NEMO networks. For instance, Nested NEMO
Tree Discovery [4] offers a mechanism that aims at avoiding routing
loops by organizing and maintaining a tree structure within the net-
work of nested NEMOs, the root being the Access Router or the Mobile
Router directly connected to the Access Router (the Top Level Mobile
Router).
Source routing is also proposed to be used in this environment.
Approaches like RRH [12] use the recording of the sequences of tra-
versed Mobile Routers on the way out of the nested NEMO network (to
the Internet, say, to bind) in order to forward traffic efficiently
in the nested NEMO network.
On the other hand, approaches like ORC (Optimized Route Cache Proto-
col [3]) could be adapted to serve the purpose of insuring some level
of optimized routing inside nested NEMO networks. Some router, say
the top level mobile router, could be configured to play a role simi-
lar to a correspondent router, organizing the forwarding of packets
inside the nested NEMO network. This special router could be dynami-
cally discovered inside the nested NEMO network.
A more general form of this mechanism would be to have each MR in the
nested NEMO network possess this extended information about the
nested NEMO network. This does then, de-facto, become a situation
where each MR knows the entire topology of the nested NEMO network,
and will be able to act in the capacity of router for such traffic.
This generalized mechanism is described in more details in section
3.1.2.
3.1.2. Ad-hoc Network of Mobile Routers
A NEMO network consists of a mobile router, to which a set of nodes
are (statically) attached. The mobile router communicates with (i.e.
has direct links with) other mobile routers, and possibly with the
Internet at large. As such, a NEMO network is not much different from
Clausen, Baccelli, Wakikawa [Page 9]
INTERNET-DRAFT RO Problem Statement 15 October 2004
any other network. What makes NEMO networks different from other net-
works is, that they may change their point of attachment at will --
i.e. the topology formed by NEMO mobile routers is dynamic.
Thus, in order to provide routes between any two nodes in the nested
NEMO network, a mechanism must be in place which ensures that the
dynamic topology of the nested NEMO network can be accurately tracked
and used for routing table calculations.
The IETF MANET working group has been developing routing protocols
for dynamic ad-hoc networks, such as OLSR [2] and AODV [6] (both
RFC), with the characteristics that the developed protocols should be
light-weight, able to react to rapid topology changes and limit the
signalling overhead. An approach to route optimization within the
NEMO-to-NEMO scenario could therefore be to consider the mobile
routers of the nested NEMO networks as nodes in an ad-hoc network,
and run an ad-hoc routing protocol to ensure that each mobile router
would be able to determine if data could be locally (i.e. within the
nested NEMO network) delivered, or had to be tunneled back to the
Home Agent.
OLSR [2], for example, provides light-weight OSPF-like [7] routing
functionality. This includes efficient maintenance of the topology
spanned by the links between the mobile routers in the face of net-
work dynamics, as well as the ability for a mobile router to adver-
tize associated nodes which do not run the OLSR routing protocol
(e.g. nodes associated to a mobile router, which are not themself
mobile routers). It is also possible for Mobile Network Nodes to
obtain global connectivity, as described in [16].
Employing a protocol such as OLSR among the mobile routers in a
nested NEMO network would yield the ability for any mobile router to
determine if a destination can be reached through a path local to the
nested NEMO network, or if forwarding to the Home Agent is required.
Additionally, this would also ease the Internet-to-NEMO scenario. In
order to deliver an IP datagram to a node in the nested NEMO network,
only a path to the access router between the nested NEMO network and
the Internet would be required: once an IP datagram arrives in the
nested NEMO network, the routing tables in the mobile routers, as
provided by OLSR, would allow direct routing to the destination.
Thus, there would no longer be a requirement to do nested encapsula-
tion on each logical hop (i.e. each transversal of a Home Agent) in
order to be able to decapsulate and correctly forward IP datagrams in
the nested NEMO network.
Thus even if no route optimizations are performed in the Internet-to-
NEMO scenario, an overhead reduction can still be achieved through
much lower encapsulation requirements.
Clausen, Baccelli, Wakikawa [Page 10]
INTERNET-DRAFT RO Problem Statement 15 October 2004
3.2. Internet-to-NEMO
The goal here is, again, to avoid unnecessary encapsulation and dog-
leg routing. Indeed, it is desirable to avoid letting the level of
nested mobility on the edges of the network dictating the number of
Home Agents (and therefore the amount of encapsulation) the packets
have to go through. There should be a way to limit the level of tun-
neling to only one encapsulation IP in IP, and at the same time, min-
imize the traffic relayed by Home Agents.
Existing solution to route optimization problems in NEMO therefore
aim at, basically, minimizing the required amount of tunneling in
various nested mobility cases. They can be categorized as follows:
- route optimization initiated by Mobile Routers (MR) or Mobile
Network Nodes (MNN);
- route optimization initiated by intermediate non-mobile
routers on the path to Corresponding Nodes.
The following sub-sections briefly review these solutions.
3.2.1. Route Optimization Mechanisms Initiated by MR or MNN
In case of nested mobility (i.e. a mobile router attaches to another
mobile router, or a visiting mobile node attaches to a mobile
router), several encapsulations will occur on top of each other, and
a sub-optimal path will be used to reach the destination, going
through each and every Home Agent. In order to slim this down, sev-
eral nested tunnel optimizations have been discussed.
The HMIP-like mechanisms suggested in [15] or the TLMR (Top Level
Mobile Router [11]) approach use one or more Mobile Routers chosen
for their location (closest to the Access Router) to act as proxy for
Mobile IP, and/or act as Home Agents for other mobile nodes inside
the attached mobile networks, like proposed in [14]. Instead of
adding another layer encapsulation, those TLMR switch between ingress
and egress tunnels and can reduce the amount of binding.
Similarily, ARO (Access Router Option [13]) proposes nested tunnel
optimizations based on the registration of the top level Access
Router of any nested NEMO to the Home Agent in order to bypass the
HAs of all the MR on the way to the Access Router.
On the other hand, source routing approaches like RRH (Reverse
Clausen, Baccelli, Wakikawa [Page 11]
INTERNET-DRAFT RO Problem Statement 15 October 2004
Routing Header [12]) or Path Control Header [9] use loose source
routing in order to avoid IP encapsulation. However, source routing
is not always desirable, and might not be widely accepted.
3.2.2. Route Optimization Initiated by a Non-Mobile Router
Some approaches such as ORC (Optimized Route Cache Protocol [3]) or
other proposals using so called Anchor Routers or Correspondent side
routers (see [10] for further references), advocate the adding of new
functionalities in some routers that are ideally chosen to be opti-
mally placed with respect to traffic flows between ASs. Those routers
intercept and terminate the tunneling on behalf of the Correspondent
Node, therefore optimizing the route from then on. However, this is
not easy to deploy, and the optimization is partial.
4. Acknowledgements
The authors would like to thank Hitachi Labs Europe for their support.
5. Authors' Addresses
Thomas Heide Clausen,
Project PCRI
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Email: T.Clausen@computer.org
Emmanuel Baccelli
HITACHI Labs Europe/ Project PCRI,
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Email: Emmanuel.Baccelli@inria.fr
Ryuji Wakikawa
Keio University and WIDE
Clausen, Baccelli, Wakikawa [Page 12]
INTERNET-DRAFT RO Problem Statement 15 October 2004
5322 Endo Fujisawa Kanagawa
252 JAPAN
Phone: +81-466-49-1394
EMail: ryuji@sfc.wide.ad.jp
Fax: +81-466-49-1395
6. References
[1] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Nemo
Basic Support Protocol (work in progress). Internet Draft (draft-
ietf-nemo-basic-support-02), Internet Engineering Task Force,
December 2003.
[2] T. Clausen, P. Jacquet, Optimized Link State Routing Protocol.
Request for Comments (Experimental) 3626, October 2003.
[3] R. Wakikawa, M. Watari. Optimized Route Cache Protocol (ORC) (work
in progress). Internet Draft (draft-wakikawa-nemo-orc-00.txt),
Internet Engineering Task Force, July 2004.
[4] P. Thubert, N. Montavont. Nested Nemo Tree Discovery (work in
progress). Internet Draft (draft-thubert-tree-discovery-00.txt),
Internet Engineering Task Force, May 2004.
[5] S. Bradner. Key words for use in RFCs to Indicate Requirement Lev-
els. Request for Comments (Best Current Practice) 2119, Internet
Engineering Task Force, March 1997.
[6] C. Perkins, E. Belding-Royer, S. Das. Ad hoc On-Demand Distance Vec-
tor (AODV) Routing, Request for Comments (Experimental) 3561, July
2003
[7] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[8] T. Ernst, H-Y. Lach. Network Mobility Support Terminology (work in
progress). Internet Draft (draft-ietf-nemo-terminology-01), Inter-
net Engineering Task Force, February 2004.
[9] Jongkeun Na et al. Route Optimization Scheme based on Path Control
Header (work in progress). Internet Draft (draft-na-nemo-path-con-
trol-header-00), Internet Engineering Task Force, April 2004.
[10] P. Thubert et al. Taxonomy of Route Optimization models in the Nemo
Context (work in progress). Internet Draft (draft-thubert-nemo-ro-
taxonomy-02), Internet Engineering Task Force, February 2004.
[11] H. Kang et al. Route Optimization for Mobile Network by Using Bi-
directional Between Home Agent and Top Level Mobile Router (work in
Clausen, Baccelli, Wakikawa [Page 13]
INTERNET-DRAFT RO Problem Statement 15 October 2004
progress). Internet Draft (draft-hkang-nemo-ro-tlmr-00.txt), Inter-
net Engineering Task Force, June 2003.
[12] P. Thubert et al. IPv6 Reverse Routing Header and its application
to Mobile Networks (work in progress). Internet Draft (draft-thu-
bert-nemo-reverse-routing-header-05), Internet Engineering Task
Force, June 2004.
[13] C. Ng et al. Securing Nested Tunnels Optimization with Access
Router Option (work in progress). Internet Draft (draft-ng-nemo-
access-router-option-01), Internet Engineering Task Force, July
2004.
[14] E. Perera et al. Extended Network Mobility Support (work in
progress). Internet Draft (draft-perera-nemo-extended-00.txt),
Internet Engineering Task Force, July 2003.
[15] H. Ohnishi et al. HMIP based Route Optimization Method in a Mobile
Network (work in progress). Internet Draft (draft-ohnishi-nemo-ro-
hmip-00.txt), Internet Engineering Task Force, April 2003.
[16] R. Wakikawa et al. Global Connectivity for IPv6 Mobile Ad Hoc Net-
works (work in progress). Internet Draft (draft-wakikawa-manet-
globalv6-03.txt), Internet Engineering Task Force, October 2003.
7. Changes
This is the initial version of this specification.
8. IANA Considerations
This document does currently not specify IANA considerations.
9. Security Considerations
This document does not specify any security considerations.
10. Copyright
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
Clausen, Baccelli, Wakikawa [Page 14]
INTERNET-DRAFT RO Problem Statement 15 October 2004
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.