[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-ietf-nemo-ro-problem-statement

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.


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/