[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
No Working Group                                             R. Wakikawa
Internet-Draft                                           Keio University
Expires: August 9, 2007                                       P. Thubert
                                                                   Cisco
                                                                 T. Boot
                                                       Infinity Networks
                                                                J. Bound
                                                                      HP
                                                             B. McCarthy
                                                    Lancaster University
                                                        February 5, 2007


                        MANEMO Problem Statement
                draft-wakikawa-manemo-problem-statement-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 9, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).







Wakikawa, et al.         Expires August 9, 2007                 [Page 1]


Internet-Draft          MANEMO Problem Statement           February 2007


Abstract

   This document outlines the fundamental problems and approach
   rationale of MANEMO.  When mobile nodes converge at the edge of the
   Internet using wireless interfaces, they can form a network in an ad-
   hoc fashion and are able to provide Internet connectivity to one
   another.  This type of network is called a MANEMO Fringe Stub (MFS).
   Several issues exist in the MFS such as network loop, un-optimized
   path and multiple exit routers to the Internet.  While fixed routers
   provide connectivity constantly, mobile routers can experience
   intermittent connectivity to the Internet due to their movement.
   When NEMO Basic Support is used in this context, network loops
   naturally occur.  NEMO forces the packets to always travel through
   the home agent, which in turn causes an un-optimized path that can
   become a considerable problem when mobile routers form a nested
   topology.  Multicast support introduces emphasized inefficiency.
   Different types of routers are able to provide Internet connectivity
   in the MFS, including both mobile routers and fixed access routers.
   Any node requiring Internet connectivity has to select the best exit
   router toward the Internet, therefore it is necessary for mobile
   nodes to maintain a local topology in the MFS and to utilise any
   available connectivity with a degree of Intelligence.





























Wakikawa, et al.         Expires August 9, 2007                 [Page 2]


Internet-Draft          MANEMO Problem Statement           February 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6

   3.  Use cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Layer 3 Mesh Network . . . . . . . . . . . . . . . . . . .  9
     3.2.  Layer 3 Sensor Network . . . . . . . . . . . . . . . . . .  9
     3.3.  Fleet at sea . . . . . . . . . . . . . . . . . . . . . . . 10
     3.4.  Crowd of Personal Mobile Router  . . . . . . . . . . . . . 10
     3.5.  Deployable and Mobile networks . . . . . . . . . . . . . . 11
     3.6.  Disaster-Ready municipal network . . . . . . . . . . . . . 11
     3.7.  Various Access Points Discovery (beyond 802.21)  . . . . . 12

   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13

   5.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . . 15
     5.1.  Network Loop . . . . . . . . . . . . . . . . . . . . . . . 15
     5.2.  Un-optimized Route . . . . . . . . . . . . . . . . . . . . 16
     5.3.  Multiple Exit Routers  . . . . . . . . . . . . . . . . . . 18

   6.  Approach Rationale . . . . . . . . . . . . . . . . . . . . . . 20
     6.1.  Layer 2 (mesh, spanning tree) based approach . . . . . . . 20
     6.2.  802.21 based approach  . . . . . . . . . . . . . . . . . . 20
     6.3.  MANET based approach . . . . . . . . . . . . . . . . . . . 21
     6.4.  Neighbor Discovery based approach  . . . . . . . . . . . . 22
       6.4.1.  MANEMO ND and other MANET protocols  . . . . . . . . . 23
       6.4.2.  MANEMO ND and AUTOCONF . . . . . . . . . . . . . . . . 23

   7.  Related Information  . . . . . . . . . . . . . . . . . . . . . 25

   8.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 26

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27

   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28

   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     11.1. Normative reference  . . . . . . . . . . . . . . . . . . . 28
     11.2. Informative Reference  . . . . . . . . . . . . . . . . . . 29

   Appendix A.  Change Log From Previous Version  . . . . . . . . . . 31

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
   Intellectual Property and Copyright Statements . . . . . . . . . . 33





Wakikawa, et al.         Expires August 9, 2007                 [Page 3]


Internet-Draft          MANEMO Problem Statement           February 2007


1.  Introduction

   With routers and access points now being priced as a commodity, a
   cloud of nodes connected by wireless technology is being created at
   the edge of the Internet.  This cloud is called a MANEMO Fringe Stub
   (MFS) in this document.  The definition of all the terms used in this
   document can be found in Section 2.  Examples of these wireless
   technologies used within a MFS are wireless metropolitan and local
   area network protocols (WiMAX, WLAN, 802.20, etc), short distance
   wireless technology (bluetooth, irDA, UWB), and radio mesh networks
   (ex. 802.11s).  As the MFS extends to the consumer market and into
   the homes, it's ease of use should become comparable to that of
   existing electrical appliances and extension cords, i.e. highly user
   friendly with little or no user interaction required.  As a result,
   networking in the MFS will be highly unmanaged and ad-hoc, but at the
   same time will need to offer excellent service availability.

   In particular, NEMO basic support [1] could be used to provide global
   reachability for a mobile access network within the MFS.  However,
   when Mobile Nodes attach randomly to one another in this model (to
   form what is termed a nested NEMO) the overall structure can become
   highly suboptimal and loops can also possibly occur.

   Therefore, there is a need for additional information to be made
   available to Mobile Nodes to help them select an interface and an
   attachment router over that interface in order to reach the Internet
   (possibly indirectly) in a fashion avoiding network loops.  The aim
   of MANEMO is to enable this to happen in the MFS through the design
   of a specific MANET, tailored for the needs of nested NEMO that can
   form an optimized acyclic graph directed to the to the outside
   infrastructure and the Internet when it is reachable.

   MANEMO enables a Mobile Router to install one or more default
   route(s) towards the Internet and be globally reachable using NEMO.

   MANEMO may also be required to install backward routes towards
   prefixes owned by a Mobile Router in each of the intermediate routers
   from the selected Exit Router down to that Mobile Router.

   Finally, Internet connectivity in mobile scenarios can be costly,
   limited or unavailable, therefore there is a need to enable local
   routing between the Mobile Routers within a portion of the MFS.  This
   form of local routing is useful for route optimization between Mobile
   Routers that are communicating directly in a portion of the MFS.

   This type of local communication is especially an efficiency
   improvement for multicast, as MANEMO multicast traffic could be
   distributed in the MFS without the overhead of nested tunnels and



Wakikawa, et al.         Expires August 9, 2007                 [Page 4]


Internet-Draft          MANEMO Problem Statement           February 2007


   pseudo-broadcasting.


















































Wakikawa, et al.         Expires August 9, 2007                 [Page 5]


Internet-Draft          MANEMO Problem Statement           February 2007


2.  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 RFC 2119 [2]

   Readers are expected to be familiar with all the terms defined in the
   RFC3753 [3] and the NEMO Terminology draft [4]

   Directed Graph  A graph whose edges are ordered pairs of vertices.
      That is, each edge can be followed from one vertex to another
      vertex.

   Directed Acyclic Graph (DAG)  Directed graph with no path that starts
      and ends at the same vertex - in other words, loopless.

   Capability, Innocuousness and Anonymity (CIA)  Concepts which might
      replace the traditional AAA model in some circumstances in the
      MFS:

      Capability:  Capability explores whether an Attachment Router can
         actually provide the requested services (reach back to Home,
         bandwidth...)

      Innocuousness:  Innocuousness guarantees that giving a service to
         a peer (forwarding) or using a service from a peer (attaching)
         is harmless to itself.

      Anonymity:  Anonymity ensures that peers are unable to identify
         one another.  This concept might contradict that of rating
         peers which can be useful for peer to peer policing (tit for
         tat).

   Exit Router  The Exit Router is a router which provides Internet
      connectivity and acts as a layer-3 sink for the MFS.  The Exit
      Router can be a fixed Access Router supporting MANEMO or a mobile
      router (root-MR) connected directly to the Internet.  Multiple
      Exit Routers may be available in an MFS.

   Exit Route  An Exit Route is a next hop on a Mobile Router towards an
      Exit Router

   Local Communication  Local Communication is communication between
      nodes in the same MFS without going through the Internet.







Wakikawa, et al.         Expires August 9, 2007                 [Page 6]


Internet-Draft          MANEMO Problem Statement           February 2007


   Local Routing  Local Routing is a routing scheme inside a MFS.
      MANEMO is used for arranging a tree structure towards the
      Internet.  In addition, other MANET protocols can be used to
      optimise Local Communication.

   MANEMO  MANET for NEMO.  MANEMO provides the necessary additions to
      existing protocols (IPv6, ND, NEMO), for nested Mobile Routers to
      find the most suited exit towards the infrastructure.  MANEMO
      enables some internal connectivity within the nested NEMO whether
      the infrastructure is reachable or not.  MANEMO is not MANET +
      NEMO.  MANET + NEMO could suggest a MANET protocol reuse whereas
      MANET for NEMO suggests the development of a new protocol.

   MANEMO Fringe Stub (MFS)  The MANEMO Fringe Stub is a cloud of Mobile
      Routers connected by wireless or wired links.  Any type of link
      supporting IPv6 connectivity can be used, including partly meshed
      wireless topologies.  An MFS is a stub at the edge of the
      Internet, interconnecting various types of devices which discover
      each other and form a network in an ad-hoc fashion to provide
      Internet connectivity to one another.  Many disjunctive MFS can be
      connected to the Internet.  An MFS can also be floating, which
      means the cloud is not connected to the Internet.

   MANEMO Link  A MANEMO Link is a MANEMO enabled Mobile Router
      interface and the data link layer transmission medium connected to
      it.  Via the link, other nodes can be reached, called the 1st hop
      neighbors.

   MANEMO Path  A MANEMO Path is a network path between a Mobile Router
      and the root of the MANEMO Tree, the Exit Router.  For Local
      Communication, an up-tree and down-tree path provides connectivity
      within a MANEMO tree.

   MANEMO Tree  A MANEMO Tree is the simplest network topology
      connecting Mobile Routers within a MFS to a single Exit Router.
      The Exit Router is the root of the MANEMO Tree.  In case of a
      floating MFS, a Mobile Router shall be elected as root of the
      MANEMO Tree.

   Wireless Node  A Wireless Node is a node that has a wireless link to
      access the Internet.  Example Wireless Nodes are a Mobile Node
      (Mobile Host or Mobile Router) and a normal IPv6 node [5] with a
      wireless link.

   Nested NEMO  The Nested NEMO is a network configuration where one or
      more mobile routers are connected in nested formation.  The
      detailed issues can be found in [13] and [14].




Wakikawa, et al.         Expires August 9, 2007                 [Page 7]


Internet-Draft          MANEMO Problem Statement           February 2007


   Self Optimizing  A Self-Optimizing network is a self-forming, self-
      healing network that adapts its topology dynamically in order to
      optimize some metrics.
















































Wakikawa, et al.         Expires August 9, 2007                 [Page 8]


Internet-Draft          MANEMO Problem Statement           February 2007


3.  Use cases

3.1.  Layer 3 Mesh Network

   A layer 3 mesh network is a specific case of nested NEMO with very,
   very slow inner movements of Mobile Routers relative to one another.
   Change of attachment will be triggered by node additions and
   interference, rather than actual displacement.

   The mesh network is self-forming and self-healing.  It forms a tree
   that is rooted at the nearest Exit Router (wire access).  The tree
   will self-heal should a node fail, a radio link become unavailable
   (for a temporary interference), or a node or a wire access be added
   to the network.

   In order to deploy a mesh network easily, the inner addressing should
   be independent of the wire accesses.  The MANEMO protocol should
   enable packets transmitted from Mobile Routers visiting the mesh to
   enter the Internet via an Exit Router with a topologically correct
   address even though the inner mesh addresses may be only unique local
   addresses.

3.2.  Layer 3 Sensor Network

   A Sensor Network is an extreme form of a MANET in terms of the amount
   of devices and of their highly limited capabilities.  Sensors can be
   low cost, mass produced devices operating for years on a pair of AAA
   batteries.  A sensor dust can be spread over a monitored location,
   and from that moment on, the sensors are fixed and operate for the
   lifetime of their batteries, which are their most critical resource.

   Around a Sensor Network, sinks are deployed in order to collect the
   measurements from the sensors and relay the commands from the
   controllers.  Thus, sensors automatically form a structure to forward
   unicast packets from the sensors to the sinks, and to propagate
   broadcast packets across the network from the sinks.

   The sensors act as a community, relaying packets for one another; but
   the model reaches its limits due in one hand to the operational cost
   on the batteries for listening to asynchronous packets from other
   sensors and for forwarding, and in the other hand to the complexity
   involved in forming an ad-hoc network over a large area.

   In order to establish a routing infrastructure and scale to a large
   geography, Mobile Routers can be deployed to form a mesh and act as
   default gateways to backhaul and aggregate the sensor data.  In that
   case, most sensors could be either plain IPv6 hosts or at least be
   optimized to relay over a limited area towards the nearest Mobile



Wakikawa, et al.         Expires August 9, 2007                 [Page 9]


Internet-Draft          MANEMO Problem Statement           February 2007


   Router.

   The Mobile Routers themselves might be actually fixed and well-
   distributed across the monitored location, with a few of them
   equipped with a backhaul capability to the Infrastructure.  They
   could also be in fact mobile and appear, move and disappear, for
   instance as a drone passes over the sensor field to sweep a
   perimeter.  The MANEMO protocol must ensure that the Exit Route(s) is
   found and maintained as quickly as possible.

   Finally, a possible flow in sensor networking is the polling of the
   sensors by an application.  The application request is multicast to
   all sensors, and the sensors reply in a synchronized fashion.  In
   that flow, the command might interfere with itself as it is repeated
   over the radios.  Also, the sensor responses might interfere with one
   another.  The MANEMO protocol should aim at minimizing interference
   with itself and could provide extensions to transport and aggregate
   sensor data.

3.3.  Fleet at sea

   In the case of a fleet at sea, the MFS is moving together, with maybe
   temporary splits and merges.  Also, when the fleet is at sea, the
   communications to the outside can be costly.

   In this use case, some ships may have well defined roles (like
   admiral ship, communications ships etc...) and therefore some
   additional engineering maybe required when considering the routing.
   For example, it may be desirable that certain specific ships be
   identified as preferred Exit Routers (root-MR) for the MANEMO.

   As opposed to the mesh networking and sensor networking cases, the
   fleet at sea involves inner movements within the fleet as demanded by
   the missions.  As a result, some part of the fleet might split from
   the rest but still maintain local connectivity using MANEMO, as well
   as connectivity with the rest of the fleet using NEMO.  In
   particular, it is possible that the comms ship may act as a Mobile
   Home for the fleet aggregation.

3.4.  Crowd of Personal Mobile Router

   Another use case is a crowd of personal Mobile Routers.  In this use
   case, people do not know each other but need to forward each others
   packets to the nearest Exit Router in order for the whole system to
   operate for everyone.  Also, in this situation people may move quite
   rapidly relative to one another therefore the density of the crowd
   may be of significance.




Wakikawa, et al.         Expires August 9, 2007                [Page 10]


Internet-Draft          MANEMO Problem Statement           February 2007


   In this sort of unmanaged environment we cannot rely on a traditional
   (AAA, trust based) mechanism.  Instead, the MANEMO protocol must
   enable MRs to obtain the required Capabilities in an Innocuous
   fashion.  MANEMO has to enable and optimize the trade-off between
   ensuring some reciprocity (TIT for TAT) and maintaining a safe degree
   of Anonymity between the peer Mobile Routers.

3.5.  Deployable and Mobile networks

   A task-group could perform activities in a planned matter in an area
   that lacks a capable data communication infrastructure.  In such a
   case, the infrastructure would be embedded in the task-group itself.
   The used infrastructure would be heterogeneous; using whatever
   wireless or wired technology that is allowed, applicable, affordable
   and available.

   During their task, elements such as ships, vehicles, airborne
   elements and temporally used buildings, tents or other setups mostly
   have fixed locations, but elements can relocate in a planned or
   unplanned manner.  During relocation, the data communication
   facilities can be shut down or kept active.  Shut down data
   communication facilities would be classified as "on the hold" or "on
   the pause".  Data communication facilities that are active during
   relocation are classified as "on the move".  Networks with a high
   degree of stationary elements are called "Deployable networks";
   relocation would normally be planned.  Networks with a high degree of
   mobility are called "Mobile Networks" and planning activities would
   be minimal.  Deployed Mobile Networks have both ingredients.

   Deployable and Mobile networks are being used by military forces, oil
   and mineral recovery undertakings and large scale events.  They can
   also be added to Disaster-Ready municipal networks.

3.6.  Disaster-Ready municipal network

   Several Groups like MetroNet6 in the US and U-2010 in Europe are
   considering solutions which would enable a quick restoration of
   communications after a disaster.  This kind of problem has many
   facets, and MANEMO aims at solving implied the connectivity issues to
   provide a Disaster-Ready municipal network or a fast deployable
   mobile network.

   A municipal Network is Disaster Ready if the networking operations
   can be restored quickly during the normally chaotic phase that
   follows a disaster (earthquake, flood, tsunami, volcano).  Though a
   large part of the municipal network might be utterly destroyed, the
   goal is to leverage whatever infrastructure is left to restore
   connectivity as soon as possible.



Wakikawa, et al.         Expires August 9, 2007                [Page 11]


Internet-Draft          MANEMO Problem Statement           February 2007


   This requires a municipal network with self-forming, self-healing
   characteristics.  In addition, this requires the ability to support
   the dynamic reintroduction of additional/replacement materials that
   will recombine with the surviving infrastructure in an effort to
   complete it and further bolster the available coverage.  In other
   words the municipal network must collaborate with the emergency
   Mobile Routers, which will be automatically supported if the mesh
   network technology is compatible with that of the Mobile Routers.

   For the MANEMO protocol, this means that Mobile Routers (in trucks,
   Personal Mobile Routers, etc...) can be deployed within the disaster
   area and restore connectivity in the part(s) of the city mesh that
   are still operational but isolated, and extend the connectivity in
   the areas that are not covered.

3.7.  Various Access Points Discovery (beyond 802.21)

   IEEE 802.21 working group has been developing a mechanism to support
   optimized handover and interoperability between heterogeneous
   networks.  The current set of 802.21 standards are not well designed
   to support mobile wireless access networks, though the 802.21 Working
   Group has not excluded supporting mobile access networks in the
   future.

   Once Mobile Routers are well deployed in vehicles, personal devices,
   etc., it is expected that we will begin to see access networks that
   are on the move.  Within the current 802.21 standards, this moving
   access network is not considered.  The 802.21 Information Service
   (IS) system cannot provide complete information of neighboring
   networks to users, because the IS basically deals with static types
   of information.  Therefore, a user will obtain information of static
   neighboring networks from IS and acquire information about possible
   mobile access networks (Exit Routers) by using MANEMO.

   The best access network for users might depend on more than layer 2
   and location knowledge.  For instance, a passenger in a vehicle (i.e.
   bus/train) should stick to the access provided by that vehicle while
   a stationary passenger located in the station should get access from
   a fixed resource.  Some of the required information to make the
   proper decision is available from layer 3 and above, as well as from
   the user himself.

   MANEMO should define and utilize means for discovering and selecting
   the best access network for users.







Wakikawa, et al.         Expires August 9, 2007                [Page 12]


Internet-Draft          MANEMO Problem Statement           February 2007


4.  Requirements

   MANEMO has the following requirements:

   R1:  The MANEMO protocol must enable the discovery of multihop
      topologies at layer 3 from mere reachability and elaborate links
      for IPv6 usage, regardless of the wired or wireless media.

   R2:  The MANEMO protocol must enable packets transmitted from Mobile
      Routers visiting the MFS to reach the Internet via an optimized
      path towards the nearest Exit Router, and back.

   R3:  MANEMO must enable IP connectivity within the nested NEMO
      whether the infrastructure is reachable or not.

   R4:  The MANEMO protocol must enable packets transmitted from Mobile
      Routers visiting the MFS to reach the Internet with a
      topologically correct address.

   R5:  The MANEMO protocol should aim at minimizing radio interference
      with itself as the control messages get propagated in the MFS.

   R6:  MANEMO protocol must enable inner movements within MFS to occur,
      and ensure details of this movement are not propagated beyond the
      MFS.

   R7:  An MFS may split to become two separate MFSs, in this case
      MANEMO will continue to maintain local connectivity within the
      separate MFSs and connectivity between the MFSs will be restored
      once a NEMO connection becomes available.

   R8:  The MANEMO protocol should enable and optimize the trade-off
      between ensuring some reciprocity between MFS peers and
      maintaining a safe degree of CIA (see Paragraph 3 in the
      terminology section (Section 2)) properties between the peer
      Mobile Routers.

   R9:  The MANEMO protocol should enable that Mobile Routers be
      deployed to restore connectivity in parts of an MFS went isolated,
      or extend the connectivity in the areas that are not covered.

   R10:  The solution MUST not require modifications to any node other
      than nodes that participates to the MFS.  It must support fixed
      nodes, mobile hosts and mobile routers in the NEMOs that form the
      MFS, and ensure backward compatibility with other standards
      defined by the IETF.





Wakikawa, et al.         Expires August 9, 2007                [Page 13]


Internet-Draft          MANEMO Problem Statement           February 2007


   R11:  The MANEMO protocol shall enable multicast communication, for
      nodes within the MFS and on the Internet.  Translation of MANEMO
      multicast signaling and multicast signaling on the Internet shall
      take place on the Exit Router.

   R12:  The MANEMO protocol shall optimize the path to the Internet
      using cross-layer metrics.












































Wakikawa, et al.         Expires August 9, 2007                [Page 14]


Internet-Draft          MANEMO Problem Statement           February 2007


5.  Problem Statement

   Radio connectivity and movement have disrupted the concept of a link
   as we know it in the wired environment.  Specific modes for specific
   radios are proposed to restore that concept, which is essential for
   IP operations, as single hop (802.11 infrastructure mode) or multihop
   (802.11S, 802.15.5, 802.16J).  MANEMO aims a proposing a unified
   solution to reconstruct a minimum topological abstraction at layer 3
   for the use of NEMO.

   The MANEMO problem is already observed in several Working Groups and
   some are specified in [15][14].

   The MANEMO is possibly related to following on-going work in IETF

   o  Existing Routing Protocols (MANET, OSPF)

   o  Network Mobility Support (NEMO)

   o  Mobile Ad-hoc Network and Auto Configuration (AUTOCONF)

   o  Mobile Ad-hoc Sensor Network (6LOWPAN)

   o  Mobile Nodes and Multiple Interfaces in IPv6 (Monami6)

   The main problems are "Network Loop", "Un-optimized Route", and
   "Multiple Exit Routers" .

5.1.  Network Loop

   A network loop can occur when multiple mobile routers are nested and
   suddenly the Exit Router (root-MR, i.e.  MR1) looses connectivity to
   the Internet and connects to the mobile network of lower MR (i.e.
   MR2 in the figure)

   In this case, the loop is observed between MRs.  Each mobile network
   is designed to have movement transparency by NEMO Basic Support
   Protocol.  Any node connecting to a mobile network cannot know
   whether the access network is a mobile network or not.  Moreover, it
   is impossible to know whether a connecting mobile router has managed
   Internet connectivity or not.  The mobile router may loose Internet
   Connectivity, temporarily.

   Knowing the topology of MFS is highly important to prevent this
   network loop issue.






Wakikawa, et al.         Expires August 9, 2007                [Page 15]


Internet-Draft          MANEMO Problem Statement           February 2007


                +---+               +---+
                |AR |               |AR |
                +-+-+               +---+
                  |
                  |
                +-+-+               +---+
                |MR1|     -->       |MR1+--+
                +-+-+               +-+-+  |
                  |                   |    |
                  |                   |    |
                +-+-+               +-+-+  |
                |MR2|               |MR2|--+
                +---+               +---+


                          Figure 1: Network Loop

5.2.  Un-optimized Route

   This is well known issue of Nested NEMO.  The problem is described in
   Section 2.3 of [13].  The NEMO Working Group suggests not to prevent
   support for nested NEMO. [6].  Figure 2 shows a typical example of
   nested NEMO.  Even if the destination is in the same MFS, the packets
   are always traveled through multiple home agents.  There are several
   proposal in the NEMO Working Group.


























Wakikawa, et al.         Expires August 9, 2007                [Page 16]


Internet-Draft          MANEMO Problem Statement           February 2007


       +---+  +---+  +---+  +---+
       |HA1|  |HA2|  |HA3|  |HA4|
       +-+-+  +-+-+  +-+-+  +-+-+
         |      |      |      |
         |      |      |      |
       +. . . . . . . . . . . . .+
       :                         :
       :     The Internet        :
       :                         :
       +. . . . . . . . . . . . .+
                  |
                +-+-+        The Path From MR1 to MR4
                | AR|        [MR1->AR->HA1->HA4->HA2->HA1->AR->
                +-+-+                     MR1->MR2->MR4]
                  |
                +-+-+        The Path From MR3 to MR4
                |MR1|        [MR3->MR2->MR1->AR->HA1->HA2->HA3->
                +-+-+         HA4->HA2->HA1->AR->MR1->MR2->MR4]
                  |
       +---+    +-+-+    +---+
       |MR3|----+MR2+----+MR4|
       +---+    +---+    +---+



                           Figure 2: Nested NEMO

   Figure 3 shows the another example of un-optimized path.  This
   redundant path is also occurred in no nested NEMO scenario.  In this
   example, two mobile routers are not directly connected.  Most of the
   nested solution proposed in NEMO working group cannot solve this
   case.  MANEMO solution should be able to solve this case, too.



















Wakikawa, et al.         Expires August 9, 2007                [Page 17]


Internet-Draft          MANEMO Problem Statement           February 2007


       +---+               +---+      +---+              +---+
       |HA1|               |HA2|      |HA1|              |HA2|
       +-+-+               ++--+      +-+-+              ++--+
         |                  |           |                 |
         |                  |           |                 |
       +.+. . . . . . . . ..+.+       +.+. . . . . . .  ..+.+
       .                      .       .                     .
       .     The Internet     .       .     The Internet    .
       .                      .       .                     .
       +. . . . . . . . . . . +       +. . . . .+. . . .. . +
                  |                             |
                +-+-+                      +----R-----+
            +---+ AR+---+                  |           |
            |   +-+-+   |                +-+-+       +-+-+
            |           |            +---+AR1|       |AR2+---+
            |           |            |   +---+       +---+   |
          +-+-+       +-+-+        +-+-+                   +-+-+
          |MR1|       |MR2|        |MR1|                   |MR2|
          +-+-+       +-+-+        +-+-+                   +-+-+

     MR1->AR->HA1->HA2->AR->MR2    MR1->AR1->R->HA1->HA2->R->AR2->MR2



                        Figure 3: Unoptimized Route

5.3.  Multiple Exit Routers

   This problem occurs when a mobile node obtains multiple Exit Routers
   toward the Internet.  In the illustrated case, the mobile node should
   attempt to obtain some information about each Exit Router in order to
   more efficiently utilize them.  MANEMO may carry this information
   about each Exit Router and present it to the connected mobile node.


















Wakikawa, et al.         Expires August 9, 2007                [Page 18]


Internet-Draft          MANEMO Problem Statement           February 2007


               . . . . . . . . . . . ..
               .                      .
               .     The Internet     .
               .                      .
               .. . . . . . . . . . . .
                  |             |
                  |             |
                +-+-+         +-+-+
                |AR1|         |AR2+--+
                +-+-+         +-+-+  |
                  |     +---+    |   |
                  +-----|MR1|----+   |
                        +-+-+        |
                          |        +-+-+
                          +--------+MR2|
                                   +---+


                      Figure 4: Multiple Exit Routers
































Wakikawa, et al.         Expires August 9, 2007                [Page 19]


Internet-Draft          MANEMO Problem Statement           February 2007


6.  Approach Rationale

   MANEMO aims at extending IPv6 Neighbor Discovery [7] to form and
   maintain an optimized nested NEMO.  This section covers the rationale
   behind this approach.

6.1.  Layer 2 (mesh, spanning tree) based approach

   Arguably, an existing layer 2 technology such as a spanning tree of
   802.11s could be used to establish a tree towards the nearest Exit
   Router.  This falls short when the nodes are mobile routers for a
   number of reasons:

      In a L2 based solution, the MRs would end up bridging for the
      nested routers while routing for their own (attached) Mobile
      Network Prefixes.

      A L3 based solution could span over multiple radio types, such as:
      802.16 or 11a for backhaul, 802.11a or 11b/g for edge and 802.11
      b/g or 802.15.4 for access.  It also could span wired links.

      In an L3 solution, you control the broadcast domain and limit the
      multicast troubles without snooping.  In particular, you segment
      the ND broadcast operations.

      NEMO operation is better if the MANEMO operation is done in ND at
      L3, because NEMO already interfaces with ND.  A L2 solution would
      require NEMO to understand L2/2.5 protocols such as like 802.11s
      or 802.21.

      There can be value in integration between the NEMO and the MANET
      aspects of the mobility problem.  For instance, if the Reverse
      Routing Header technique [16] is used to solve the pinball routing
      problem, then the RRH can be compressed dynamically if routes down
      the tree (or the DAG) are installed by the MANEMO protocol in the
      intermediate routers.

      And then you get all the IP value that is not necessarily there or
      homogeneous at L2, like QoS, SNMP, RSVP, aggregation, etc...

6.2.  802.21 based approach

   In some scenarios, the information service approach may be taken.
   For example, trains are run on a regular schedule and a system can
   preempt the movement of mobile routers on each train.  In such a
   case, the operator can dynamically update the information of routers
   in a train to the information service (IS).  The mobile node can
   retrieve information about the neighboring access networks from IS in



Wakikawa, et al.         Expires August 9, 2007                [Page 20]


Internet-Draft          MANEMO Problem Statement           February 2007


   some scenarios.  Unless the IS supports dynamic updates of access
   routers and provides certain topology of mobile access routers, it is
   difficult to solve all the problems of MANEMO.  For instance, it does
   not enable us to structure the nested NEMO in an optimal fashion for
   reaching the infrastructure.

6.3.  MANET based approach

   The Mobile Ad-hoc Network Architecture [17] provides an overview of
   the MANET problem and scope.

   MANEMO is about designing a specific MANET that is tailored for the
   needs of nested NEMO, with a strong focus on finding the way to the
   outside infrastructure when it is reachable.  In that sense, MANEMO
   specializes on a specific area of MANET by adding a set of
   constraints that narrow the problem down.

   Arguably, an existing MANET protocol could be used to enable routing
   between the Mobile Router within a nested NEMO.  But existing MANET
   are not optimized for the following requirements:

   Default Route:  Because it is used by Mobile Routers to find a way
      out and bind to their Home Agent, the MANEMO protocol focuses on
      building, maintaining and optimizing a default path to the exit of
      the nested NEMO.  With MANET, the default route is usually an
      addition, and in any case it is just another route, not the focus
      of the protocol.

   Prefix Routing:  Subnet (prefix) routing is a secondary concern for
      the MANEMO protocol.  Such routes are considered when conditions
      permit, but might be maintained in a Least Overhead Routing
      Approach (LORA) as opposed to an Optimized Routing Approach (ORA)
      which is used for the Default Route.  Host Routes are not of
      concern since MANEMO deals with Mobile Routers.  Note that DYMO
      and OLSR are capable of the prefix routing.

   Group Management:  When forming a nested NEMO, the Mobile Routers
      need a selection of information that is not present in traditional
      MANET approaches.  Notions such as group, depth, free bandwidth
      towards the exit, etc... impact the formation of the nested NEMO
      and the way it optimizes itself overtime.

   On the other hand, existing MANET protocols could be integrated or
   adapted for the following cases:







Wakikawa, et al.         Expires August 9, 2007                [Page 21]


Internet-Draft          MANEMO Problem Statement           February 2007


   On-demand Routing:  When a node needs to discover Exit Routers, on-
      demand fashion may reduce the overhead of discovery procedure.
      Some MANET routing protocols such as AODV and DYMO has the on-
      demand mechanism to discover a route towards the destination.

   Neighborhood Routing:  Because the MANEMO protocol provides only a
      minimized view of the local network, it might be missing a short
      path to a neighborhood destination over an alternate radio link.
      A collaboration with a MANET protocol would improve short-distance
      routing.  As an example, internal connectivity between NEMOs
      within the local network may improve by Mobile Routers running a
      MANEMO routing protocol and discovering more optimal routes to the
      MNPs reachable within the local network.  Mechanisms specific to
      MANEMO should also be developed to ensure this optimisation is
      safe.

   Global Reachability for a MANET  In the MANET working group, an
      Internet Gateway is introduced to provide Internet connectivity to
      MANET.  In this case, the gateway of a MANET network is also a
      NEMO Mobile Router.  Using NEMO, The gateway registers the MANET
      prefix(es) to a Home Agent, enabling the MANET network to move as
      a whole.  The Mobile Router can also act as a Mobile Home for the
      whole MANET, providing Home Agent services such as mobility and
      prefix delegation.  In particular, the Mobile Home can maintain
      connectivity with Mobile IP6/NEMO enabled MANET Nodes that would
      stray away from the mobile MANET.

   For these reasons, MANET could contribute in optimizing a deployment,
   but a specific protocol has to be engineered to match the MANEMO
   requirements.

6.4.  Neighbor Discovery based approach

   Neighbor Discovery (ND) [7] provides the means to discover neighbors
   and the prefix on a link, which are pervasive across IPv6 nodes and
   link types.  Mobile IPv6 [8] and NEMO [1] rely heavily on ND for
   roaming and Home Link activities.  Considering that NEMO already uses
   ND for Router Discovery, it makes sense to extend ND in MANEMO as
   opposed to providing a second peering mechanism.

   ND has already been extended to expose some layer 3 information, such
   as router selection hints [9].  ND is consistently being improved for
   mobility, in particular with Mobile IPv6 [8] and DNA, and for
   security with Secure ND [10].  ND operates on bidirectional links,
   whereas this is a restriction from the MANET standpoint, this
   condition enables simpler solutions for MANEMO.

   Neighbor Discovery is well suited for providing hints for composing a



Wakikawa, et al.         Expires August 9, 2007                [Page 22]


Internet-Draft          MANEMO Problem Statement           February 2007


   path to the Internet access router.  The hits could include Layer 2
   information as well as application layer information, needed for
   providing optimal and stable paths to Exit Routers.  The Exit Routes
   connect the MANEMO Fringe Stub to the Internet.  Path maintaining
   towards an Exit Router is suggested in a nested NEMO tree discovery
   protocol [18].

   Multicast support could be provided by using the loop-free MANEMO
   Tree to forward packets to the Internet.  Down-tree forwarding would
   use MLD-proxy[19], either with native MLD [11][12] / ICMP packets or
   send with the ND extensions to increase efficiency.  Multicast
   forwarding rules should be validated, mechanisms like RPF-check and
   duplicate packet detection [20] would be used to eliminate multicast
   looped packets.  Forwarding rules on the Exit Router is to be worked
   out.

   The MANEMO work will thus focus on an ND based solution that is
   required to provide multihop reachability while supporting inner
   movements in the nested NEMO.

6.4.1.  MANEMO ND and other MANET protocols

   The MANEMO ND provided information can be used by other MANET
   protocols.  Other MANET protocols could be used for optimize local
   connectivity or used for other reasons.

   MANEMO ND may provide IP link and address topology vectors to the
   nodes next hop neighbors.  Then that topology information at each
   next hop neighbor would be propagated to an OLSRv2 [21] / NHDP [22]
   symmetric 2-hop neighborhood and Multipoint Relay, or OSPF-MANET [23]
   / [24] MANET Designated Router (most likely Parent and Routable
   characteristics) who then can flood that topology to other Multipoint
   Relays or MANET Designated Routers down to other neighbors.  This
   also could be accomplished using NEMO/MANEMO Access Routers to the
   NEMO Clusterhead using the proposed tree discovery protocol [18].
   The diameter of the topology would span a single ad hoc link.  This
   would provide an IP layer 3 solution and the topology information
   could be placed in new ND options.

6.4.2.  MANEMO ND and AUTOCONF

   The use of ND for IP link and address topology could also foster a
   discussion with IETF AUTOCONF Working Group to analyze if ND could be
   used as defined above to support ND stateless autoconfiguration.  The
   design center for such a solution would be to place this ND link and
   IP topology enhancement below current MANET routing protocols and
   could reduce latency for ad hoc links whether within a MESH or Radio
   Network link.  ND extensions could assist greatly below MANET routing



Wakikawa, et al.         Expires August 9, 2007                [Page 23]


Internet-Draft          MANEMO Problem Statement           February 2007


   protocols to discover neighbors, verify two way communications,
   exchange link state information, and provide update information
   between neighbors and ingress/egress point to MANET Mobile Routers.
   These extensions could also be applied as enhancements to the tree
   discovery protocol that would support MANEMO, thus adding these
   extensions to tree discovery protocol is a suggestion or it could be
   its own specification.












































Wakikawa, et al.         Expires August 9, 2007                [Page 24]


Internet-Draft          MANEMO Problem Statement           February 2007


7.  Related Information

   Related Documents can be found in the Informative Reference section

   Solutions are already proposed at IETF such as [16] and [18].  The
   NEMO Working Group has the analysis document [25] for the nested NEMO
   issue.












































Wakikawa, et al.         Expires August 9, 2007                [Page 25]


Internet-Draft          MANEMO Problem Statement           February 2007


8.  IANA considerations

   This document does not require any IANA action.
















































Wakikawa, et al.         Expires August 9, 2007                [Page 26]


Internet-Draft          MANEMO Problem Statement           February 2007


9.  Security Considerations

   This document is a problem statement and does not create any security
   threat.  It discusses the concepts of Capability, Innocuousness and
   Anonymity in a nested NEMO.














































Wakikawa, et al.         Expires August 9, 2007                [Page 27]


Internet-Draft          MANEMO Problem Statement           February 2007


10.  Acknowledgments

   We would like to thank all the people who have provided comments on
   this draft, and also co-authors of earlier documents in which authors
   of this present document have been engaged.  As such, we would like
   to thank Niko A. Fikouras, Yoshihiro Ohba, Emmanuel Baccelli, Hesham
   Soliman, Carlos Jesus Bernardos Cano and many others.


11.  References

11.1.  Normative reference

   [1]   Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
         "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
         January 2005.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   Manner, J. and M. Kojo, "Mobility Related Terminology",
         RFC 3753, June 2004.

   [4]   Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         draft-ietf-nemo-terminology-06 (work in progress),
         November 2006.

   [5]   Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
         Specification", RFC 2460, December 1998.

   [6]   Ernst, T., "Network Mobility Support Goals and Requirements",
         draft-ietf-nemo-requirements-06 (work in progress),
         November 2006.

   [7]   Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
         for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [8]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [9]   Draves, R. and D. Thaler, "Default Router Preferences and More-
         Specific Routes", RFC 4191, November 2005.

   [10]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
         Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [11]  Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
         Discovery (MLD) for IPv6", RFC 2710, October 1999.



Wakikawa, et al.         Expires August 9, 2007                [Page 28]


Internet-Draft          MANEMO Problem Statement           February 2007


   [12]  Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
         (MLDv2) for IPv6", RFC 3810, June 2004.

11.2.  Informative Reference

   [13]  Ng, C., "Network Mobility Route Optimization Problem
         Statement", draft-ietf-nemo-ro-problem-statement-03 (work in
         progress), September 2006.

   [14]  Clausen, T., Baccelli, E., and R. Wakikawa, "NEMO Route
         Optimisation Problem Statement",
         draft-clausen-nemo-ro-problem-statement-00 (work in progress),
         October 2004.

   [15]  Ng, C., "Analysis of Multihoming in Network Mobility Support",
         draft-ietf-nemo-multihoming-issues-06 (work in progress),
         June 2006.

   [16]  Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
         its application to Mobile Networks",
         draft-thubert-nemo-reverse-routing-header-06 (work in
         progress), September 2006.

   [17]  Chakeres, I., "Mobile Ad hoc Network Architecture",
         draft-chakeres-manet-arch-01 (work in progress), October 2006.

   [18]  Thubert, P., "Nested Nemo Tree Discovery",
         draft-thubert-tree-discovery-04 (work in progress),
         November 2006.

   [19]  Janneteau, C., "IPv6 Multicast for Mobile Networks with MLD-
         Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work in
         progress), April 2004.

   [20]  Macker, J., "Simplified Multicast Forwarding for MANET",
         draft-ietf-manet-smf-03 (work in progress), October 2006.

   [21]  Clausen, T., "The Optimized Link-State Routing Protocol version
         2", draft-ietf-manet-olsrv2-02 (work in progress), June 2006.

   [22]  Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)",
         draft-ietf-manet-nhdp-00 (work in progress), June 2006.

   [23]  Spagnolo, P. and R. Ogier, "MANET Extension of OSPF using CDS
         Flooding", draft-ogier-manet-ospf-extension-08 (work in
         progress), October 2006.

   [24]  Roy, A. and M. Chandra, "Extensions to OSPF to Support Mobile



Wakikawa, et al.         Expires August 9, 2007                [Page 29]


Internet-Draft          MANEMO Problem Statement           February 2007


         Ad Hoc Networking", draft-chandra-ospf-manet-ext-04 (work in
         progress), January 2007.

   [25]  Ng, C., "Network Mobility Route Optimization Solution Space
         Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in
         progress), September 2006.













































Wakikawa, et al.         Expires August 9, 2007                [Page 30]


Internet-Draft          MANEMO Problem Statement           February 2007


Appendix A.  Change Log From Previous Version

   o  Initial Documentation


Authors' Addresses

   Ryuji Wakikawa
   Keio University and WIDE
   5322 Endo Fujisawa Kanagawa
   252-8520
   JAPAN

   Email: ryuji@sfc.wide.ad.jp


   Pascal Thubert
   Cisco Systems
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410
   FRANCE

   Phone: +33 4 97 23 26 34
   Email: pthubert@cisco.com


   Teco Boot
   Infinity Networks B.V.
   Elperstraat 4
   Schoonloo  9443TL
   Netherlands

   Phone: +31 592 50 12 66
   Email: teco@inf-net.nl


   Jim Bound
   Hewlett-Packard
   PO BOX 570
   Hollis, NH  03049
   USA

   Phone: +603 465 3130
   Email: jim.bound@hp.com





Wakikawa, et al.         Expires August 9, 2007                [Page 31]


Internet-Draft          MANEMO Problem Statement           February 2007


   McCarthy Ben
   Lancaster University
   Computing Department, Lancaster University.
   InfoLab 21, South Drive
   Lancaster, Lancashire  LA1 4WA
   UK

   Phone: +44-1524-510-383
   Fax:   +44-1524-510-492
   Email: b.mccarthy@lancaster.ac.uk
   URI:   http://www.network-mobility.org/








































Wakikawa, et al.         Expires August 9, 2007                [Page 32]


Internet-Draft          MANEMO Problem Statement           February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Wakikawa, et al.         Expires August 9, 2007                [Page 33]