Internet DRAFT - draft-wakikawa-manemoarch

draft-wakikawa-manemoarch






No Working Group                                             R. Wakikawa
Internet-Draft                                           Keio University
Expires: January 2, 2008                                      T. Clausen
                                                LIX, Ecole Polytechnique
                                                             B. McCarthy
                                                    Lancaster University
                                                             A. Petrescu
                                                           Motorola Labs
                                                            July 1, 2007


              MANEMO Topology and Addressing Architecture
                    draft-wakikawa-manemoarch-00.txt

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 January 2, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).









Wakikawa, et al.         Expires January 2, 2008                [Page 1]

Internet-Draft             MANEMO Architecture                 July 2007


Abstract

   This document outlines the MANEMO architecture including possible
   topology configuration and addressing assignment.  The issues of
   MANEMO (previously known as nested NEMO) are already summarized in
   several documents.  However, there are several ways how to comprehend
   what is MANEMO.  The MANEMO problems are related to several existing
   working groups.  This document provides the MANEMO architecture model
   and differences of existing solutions so that IETF can classify the
   problems and start working on the solutions.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  What is Network Mobility (NEMO) Basic Support  . . . . . . . .  4

   3.  MANEMO Topologies  . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  MANEMO Basic Topologies  . . . . . . . . . . . . . . . . .  7
     3.2.  MANEMO Advanced Topologies . . . . . . . . . . . . . . . .  9

   4.  Addressing Architecture of MANEMO  . . . . . . . . . . . . . . 11
     4.1.  NEMO Addressing Approach (MANEMO Architecture) . . . . . . 11
     4.2.  AUTOCONF Approach (MANET Architecture) . . . . . . . . . . 14
     4.3.  Comparison of Two Approaches . . . . . . . . . . . . . . . 18

   5.  Solution Guideline . . . . . . . . . . . . . . . . . . . . . . 20

   6.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 21

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22

   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     9.1.  Normative reference  . . . . . . . . . . . . . . . . . . . 23
     9.2.  Informative Reference  . . . . . . . . . . . . . . . . . . 23

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 26










Wakikawa, et al.         Expires January 2, 2008                [Page 2]

Internet-Draft             MANEMO Architecture                 July 2007


1.  Introduction

   When mobile routers and mobile nodes converge at the edge of the
   Internet using wireless interfaces, they can form a wireless network
   cloud 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, sub-optimal route,
   redundant tunnels, multiple exit routers selection, and HA dependency
   of the NEMO Basic Support.  While fixed routers provide connectivity
   constantly, mobile routers can experience intermittent connectivity
   to the Internet due to their movement.  When the 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 sub-optimal route that can become a considerable problem
   when mobile routers form a nested topology.  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 utilize any available
   connectivity with a degree of Intelligence.  Unfortunately, MANEMO is
   still not yet clearly defined and understood by IETF community, this
   draft attempts to address that problem by identifying the topologies
   that arise with MANEMO and analyzing their requirements.

   It is still uncertain whether MANEMO configurations can be suitably
   supported by MANET/AUTOCONF approaches.  In order to determine
   whether the MANEMO problem can be addressed by existing solutions, we
   must analyze the expected topology formations, wireless technologies,
   addressing, etc.  We believe there are also missing pieces for MANEMO
   in IETF.  This draft is aimed at helping identify what are those
   missing pieces.  This document describes first the whole idea of the
   NEMO Basic Support.  Then, possible MANEMO topologies are given.
   Finally we consider a typical MANEMO addressing scheme.  We feel that
   analyzing the problem area in this detail can help the reader's
   understanding of what MANEMO is and its relationship with existing
   activity.














Wakikawa, et al.         Expires January 2, 2008                [Page 3]

Internet-Draft             MANEMO Architecture                 July 2007


2.  What is Network Mobility (NEMO) Basic Support

   This section provides brief explanation of Network Mobility Basic
   Support protocol.  If readers are familiar with RFC3753 [1], RFC3775
   [2], RFC3963 [3], draft-ietf-nemo-ro-problem-statement [6], please
   skip this section.

   A mobile network is defined in RFC3753 [1], "An entire network,
   moving as a unit, which dynamically changes its point of attachment
   to the Internet and thus its reachability in the topology.  The
   mobile network is composed of one or more IP-subnets and is connected
   to the global Internet via one or more Mobile Routers (MR).  The
   internal configuration of the mobile network is assumed to be
   relatively stable with respect to the MR.".  A mobile network is seen
   as just IPv6 subnet by any nodes except for Mobile Routers.
   According to RFC3963, Figure 1 is the common interpretation of a
   mobile router.  Each Mobile Router has an egress interface(s) to
   reach the home agent through the Internet and also an ingress
   interface(s) attaching to the Mobile Network.  A mobile router
   obtains its care-of address at the egress interface and establishes a
   bi-directional tunnel to the home agent.  It routes all the packets
   intercepted at the ingress interface to the bi-directional tunnel.
   The packet's source address must belong to the mobile network prefix.
   Only the packets sent to and from a mobile network are routed to the
   tunnel by the mobile router.


             Access Network
                  |
                +-+-+
                |AR |
                +-+-+
                  | <-egress interface(s)
                +-+-+
                |MR1|
                +-+-+
                  | <-ingress interface(s)
             -+-+-+-+-+- Mobile Network
              | | | | |
              H H H H H  Mobile Network Nodes (MNNs)


                   Figure 1: Mobile Router Configuration

   Some known remarks from this NEMO Basic Support are:

   o  Unless a node (host or router) is connected to a mobile network,
      NEMO guarantees the session continuity to the node.



Wakikawa, et al.         Expires January 2, 2008                [Page 4]

Internet-Draft             MANEMO Architecture                 July 2007


   o  Any nodes attached to the mobile network are unaware of the mobile
      router's changing attachment point.  The mobile network can be
      seen as just an IPv6 network.

   o  An access router at the visiting network is not aware of a mobile
      network existence behind a mobile router.

   According to draft-ietf-nemo-terminology [4], several different
   entities can be attached to the mobile network such as Fixed Router
   in a mobile network and Mobile Network Node including Local Fixed
   Node, Visiting Mobile Node and Local Mobile Node.  In Figure 2, an
   IPv6 router called Fixed Router is deployed in a mobile network.  The
   fixed router has a dedicated mobile network prefix.  The dedicated
   prefix can be delegated from the mobile network prefix of its mobile
   router like Figure 2-a.  The mobile router sends a binding update for
   the aggregated mobile network prefix (2001:1::/48).  Alternatively,
   it can be configured with non-aggregated prefix as shown in
   Figure 2-b.  The mobile router sends a binding update containing two
   mobile network prefix options for both mobile network prefixes (2001:
   a::/64 and 2001:b::/64).

   The Fixed Router sends ICMP route advertisements, in order to reach
   other nodes in the moving network it needs to have routes installed,
   and this can be achieved by static routes or by running a routing
   protocol.  The Mobile Router has to have a route towards the mobile
   network prefix owned by the Fixed Router through Fixed Router's IP
   address.  That route can be manually installed, manually configured
   in a routing protocol configuration file, or dynamically delegated
   with DHCP Prefix Delegation.


              Access Network                 Access Network
                   | <--- egress interface(s) ---> |
                 +-+-+                           +-+-+
                 |MR |       Mobile Router       |MR |
                 +-+-+                           +-+-+
                   | <--  ingress interface(s) --> |
             ------+------+-----             ------+------+-----
        Mobile Network/48 |             Mobile Network/64 |
        2001:1::/48     +-+-+           2001:a::/64     +-+-+
                        |FR |                           |FR |
                        +-+-+  <--  Fixed Router -->    +-+-+
                          |                               |
                    ------+------                   ------+------
                  Mobile Network-FR/64         Mobile Network-FR/64
                    2001:1:1::/64                 2001:b::/64
                  a)                                 b)




Wakikawa, et al.         Expires January 2, 2008                [Page 5]

Internet-Draft             MANEMO Architecture                 July 2007


          Figure 2: Mobile Router Configuration with Fixed Router

   When a visiting mobile node is attached to a mobile network, we call
   this network formation as nested NEMO.  Figure 3 shows the two cases
   where either a mobile node or a mobile router is attached to a mobile
   network.  Specially, if a visiting mobile node is a mobile router,
   the number of nested level goes longer (Figure 3-b)).  Several issues
   are raised when Nested NEMO is occurred.  The nested NEMO issues are
   already introduced in several documents [6], [7]


             Access Network            Access Network
                  |                          |
                +-+-+                      +-+-+
                |AR |                      |AR |
                +-+-+                      +-+-+
                  |                          |
                +-+-+                      +-+-+
                |MR |                      |MR1|
                +-+-+                      +-+-+
                  |                          |
             -+---+---+-                -----+---+-
              |       |                          |
            +-+-+   +-+-+                      +-+-+
            |MN1|   |MN2|                      |MR2|
            +---+   +---+                      +-+-+
                                                 :
                   a)                            :
                                               +-+-+
                                               |MRn|
                                               +-+-+
                                                 |

                                                 b)


                    Figure 3: Nested NEMO Configuration














Wakikawa, et al.         Expires January 2, 2008                [Page 6]

Internet-Draft             MANEMO Architecture                 July 2007


3.  MANEMO Topologies

   The NEMO Basic Support protocol introduces two different interfaces
   on a mobile router known as the egress interface and the ingress
   interface.  In MANEMO, several topologies can be expected by
   attachment combination of these two interfaces.

3.1.  MANEMO Basic Topologies

   When considering MANEMO, following topology can be logically
   possible.

   1.  Egress and Ingress (E-I) attachment

   2.  Egress and Egress (E-E) attachment

   3.  *Ingress and Ingress (I-I) attachment

   4.  **Egress/Ingress and Egress/Ingress (EI-EI) attachment

   [*MANEMO does not consider this case.  The reasons are given later in
   this section.]

   [**EI-EI is another configuration of E-E attachment.  While the NEMO
   Basic Support does not assume using single interface for both egress
   and ingress, MANEMO consider this special configuration, too.  See
   Section 3.2 for details.]

   The E-I attachment is the most common configuration of the NEMO Basic
   Support.  A mobile router connects to the other mobile routers'
   mobile network by its egress interface.  Figure 4 shows the example
   topology. (e) and (i) in all the figures in this section indicate
   egress and ingress interfaces.


















Wakikawa, et al.         Expires January 2, 2008                [Page 7]

Internet-Draft             MANEMO Architecture                 July 2007


              |e                         |e
           +-----+                    +-----+
           | MR  |                    | MR  |
           +-----+                    +-----+
              |i                         |i
              |                +---------+
              |e               |         |e
           +-----+          +-----+   +-----+
           | MR  |          | MR  |   | MR  |
           +-----+          +-----+   +-----+
              |i                         |i
              |                          |
              |e                         |e
           +-----+                    +-----+
           | MR  |                    | MR  |
           +-----+                    +-----+
              |i                         |i


                Figure 4: Egress-Ingress (E-I) attachments.

   Figure 5 shows the two (E-E and I-I) scenarios.  The E-E attachment
   is the case when a mobile router uses ad-hoc type of interfaces such
   as 802.11b ad-hoc mode or 802.11s as its egress interface.  Each
   mobile router connects with egress interface.  In MANEMO, this
   scenario is also considered for inter vehicle networks, etc. (see
   ref).  On the other hand, although the ingress and ingress attachment
   is logically possible, it is slightly unrealistic.  First of all,
   when ingress interfaces of different mobile routers are connected ,
   two different mobile networks are merged in the single mobile
   network.  A mobile network node will obtain multiple IP addresses
   from different mobile routers.  For instance, in Figure 5, a mobile
   network node of MR1 obtains an address of mobile network prefixes of
   all the mobile routers (MR1, MR2 and MR3).  Whenever a mobile router
   leaves, the addresses of the entire mobile network node generated
   from the mobile network prefix of leaved mobile router will go
   unreachable.  This configuration may break the fundamental features
   of the NEMO Basic Support protocol (lack of movement transparency).
   Thus, we do not consider I-I attachment scenario in MANEMO.












Wakikawa, et al.         Expires January 2, 2008                [Page 8]

Internet-Draft             MANEMO Architecture                 July 2007


          e+-----+i                  e+-----+i
        +--| MR  |--                --| MR1 |--+
        |  +-----+                    +-----+  |
        |                                      |
        | e+-----+i                  e+-----+i |
        +--| MR  |--                --| MR2 |--+
        |  +-----+                    +-----+  |
        |                                      |
        | e+-----+i                  e+-----+i |
        +--| MR  |--                --| MR3 |--+
           +-----+                    +-----+


                     Figure 5: E-E and I-I Attachment

3.2.  MANEMO Advanced Topologies

   In MANEMO, the different scenarios from the basic topologies are also
   considered.  First, a mobile router only equips with single wireless
   interfaces and utilizes it conceptually as both egress and ingress
   interface.  In the NEMO Basic Support, a mobile router is assumed to
   have physically two different interfaces.  However, in this context,
   the ingress and egress interfaces are roles over the same physical
   interface.  A mobile router exposes its mobile network prefix to the
   interface and also obtains a care-of address at the same interface
   (named EI-EI attachment).  Figure 6 shows the example topology.


         e/i+-----+
        +---| MR  |
        |   +-----+
        |
        |e/i+-----+
        +---| MR  |
        |   +-----+
        |
        |e/i+-----+
        +---| MR  |
            +-----+


                        Figure 6: EI-EI attachment

   Another scenario is that a mobile router has a fixed router(s) in its
   mobile network so that another visiting mobile router (a mobile
   network node) connects to the mobile network through the fixed
   router.  Figure 7 gives two examples.  There are several links where
   a mobile network node can attach.  In Figure 7-b), a mobile router



Wakikawa, et al.         Expires January 2, 2008                [Page 9]

Internet-Draft             MANEMO Architecture                 July 2007


   attaches to the link between the mobile router (MR) and the fixed
   router (FR).  This topology is possible only if a mobile router
   allows mobile network nodes to attach to this link.  It totally
   depends on the admission control of each mobile network.  When
   deploying the NEMO Basic Support protocol, it is necessary to
   consider this fixed router availability in a mobile network.


        ......|......
        :     |e    :                    |e
        :  +-----+  :                 +-----+
        :  | MR  |  :                 | MR  |
        :  +-----+  :                 +-----+
        :     |i    :                    |i
        :     |     :          +---------+
        :     |     :          |         |
        :  +-----+  :       +-----+   +-----+
        :  | FR  |  :       | MR  |   | FR  |
        :  +-----+  :       +-----+   +-----+
        :     |i    :                    |
        :.....|......                    |
              |e                         |e
           +-----+                    +-----+
           | MR  |                    | MR  |
           +-----+                    +-----+
              |i                         |i
             a)                        b)


                      Figure 7: Use of Fixed Routers





















Wakikawa, et al.         Expires January 2, 2008               [Page 10]

Internet-Draft             MANEMO Architecture                 July 2007


4.  Addressing Architecture of MANEMO

   After the formation of the Nested NEMO, the argument is how to assign
   an address to each mobile node and mobile router.  There are two
   different approaches today in IETF, 1) NEMO addressing approach and
   2) AUTOCONF addressing approach.  This section briefly explains the
   two approaches and discusses their pros and cons.

4.1.  NEMO Addressing Approach (MANEMO Architecture)

   According to the NEMO Basic Support, an attached node to a mobile
   network will get an address from the mobile network.  Figure 8 gives
   the simplest case.  MR1 obtains an IP address (ANP::MR1 as CoA) from
   the access router that advertised prefix is ANP::/64.  The MR2
   attached to a mobile network of MR1 generates its CoA from the
   MNP1::/64.  This is what the NEMO basic support is assumed in the
   protocol design. (e) and (i) in all the figures in this section
   indicate egress and ingress interfaces, too.


          Access Network
              |
            +-+-+
            |AR |
            +-+-+
              |
        ------+------ ANP::/64
             e| ANP::MR1
            +-+-+
            |MR1|
            +-+-+
             i|
        ------+------ MNP1::/64
             e| MNP1::MR2
            +-+-+
            |MR2|
            +-+-+
             i|
         -----+------ MNP2::/64


           Figure 8: NEMO Address Assignment for E-I attachment

   Alternatively, Figure 9 gives another address assignment when a
   mobile network is formed with a mobile router and a fixed router(s).
   As discussed with Figure 2, two possible prefix assignment to the
   fixed router is considered, (1) the mobile network prefix can be
   divided into sub-prefixes that can be aggregated and one of the sub-



Wakikawa, et al.         Expires January 2, 2008               [Page 11]

Internet-Draft             MANEMO Architecture                 July 2007


   prefixes can be assigned to a Fixed Router, (2) the mobile network
   prefix and the Fixed Router's prefix can be totally different and not
   necessarily aggregated.  In both cases it's the administrator who
   decides this addressing architecture, it is not the mobile router who
   divides and assigns.  In this Figure, the mobile router (MR1) owns
   the mobile network prefix (MNP1::/48) and assigns sub-prefixes of the
   mobile network to a fixed router (FR1).  A mobile network node is
   attached to a link of FR1 (MNP1:1::/64) and maybe not to a link of
   MR1 (MNP1::/48).  If a node is attached to the link of MR1, it turns
   to the same configuration of Figure 8.  In this example, MR2 is
   attached to a link of FR1 and acquires the MNP1:1::MR2 address as its
   CoA.


          Access Network
               |
             +-+-+
             |AR |
             +-+-+
               |
         ------+------ ANP::/64
              e| ANP::MR1
             +-+-+
             |MR1|
             +-+-+
              i|
         ------+------ MNP1::/48
               |
             +-+-+
             |FR1|
             +-+-+
             i'|
          -----+------ MNP1:1::/64
              e| MNP1:1::MR2
             +-+-+
             |MR2|
             +-+-+
              i|
          -----+------ MNP2::/64


      Figure 9: NEMO Address Assignment when Fixed Router is employed

   According to Section 3, the other possible topology of the nested
   NEMO are E-E and EI-EI attachments described in Figure 10.  The
   egress interface of each MR is connected in ad-hoc fashion by using
   802.11b in ad-hoc mode.  This is not originally assumed in the NEMO
   Basic Support Protocol.  Figure 10 is just an example which was



Wakikawa, et al.         Expires January 2, 2008               [Page 12]

Internet-Draft             MANEMO Architecture                 July 2007


   discussed in the MANEMO mailing list.  In this case, MR reveals its
   mobile network prefix to its egress interface so that the attached MR
   (MR2 for MR1) can obtain an IPv6 address (MNP1::MR2) from the upper
   Mobile Router.  The definition of egress interface is extended to
   support some role of ingress interface.  As shown in , two possible
   scenarios can be given whether the mobile router has its physically
   available ingress interface or not.

   In the Scenario-1 (E-E attachment), each mobile router owns its
   physically available ingress interface.  Therefore, the mobile
   network prefix is advertised to both ingress interface and egress
   interface by using ICMP Router Advertisement, while the mobile router
   acquires its care-of address from the upper router (ex.  AR for MR1,
   MR1 for MR2).  Note that the NEMO Basic Support does not allow for a
   mobile router to send ICMP router advertisements for its own mobile
   network prefix from the egress interface.  The mobile router must
   support bridge functionality between the ingress interface and egress
   interface.  MNN1 (MNP1::MNN) and MR2's egress interface (MNP1::MR2)
   must be located at the same link, otherwise the multilink subnet
   issue [8] is occurred.  However, this bridge functionality is not
   currently supported by the NEMO Basic Support protocol.

   On the other hand, the scenario-2 is simpler than the the scenario-1.
   A mobile router does not necessarily support the bridge functionality
   because it does not have an ingress interface.  The mobile router
   uses a single interface as an egress and ingress interfaces.  A
   mobile router must check the source address of all the packets to
   decide whether the packets should be routed to the bi-directional
   tunnel or not.  In the packet's source address is the CoA of a mobile
   router, it MUST NOT tunnel the packet.  But the source address of a
   packet is an address of its mobile network prefix, the packet MUST be
   tunneled to the home agent.  Again, this configuration is also not
   considered by the NEMO Basic Support protocol and needs some
   modifications to the NEMO Basic Support protocol.

















Wakikawa, et al.         Expires January 2, 2008               [Page 13]

Internet-Draft             MANEMO Architecture                 July 2007


      Scenario-1(E-E attachment)        Scenario-2 (EI-EI attachment)

          Access Network              Access Network
               |                            |
             +-+-+                        +-+-+
             |AR | ANP::/64               |AR | ANP::/64
             +-+-+                        +-+-+
               |                            |
         ------+------ ANP::/64       ------+------ ANP::/64
               |                            |
     ANP::MR1 e+----            ANP::MR1 ei +-----
             +-+-+   \                    +-+-+   \
             |MR1|    \                   |MR1|    \
             +-+-+     \                  +---+     \
              i|        \                          __|
         -+----+----  __|                         /ei|MNP1::MR2
          |          / e|MNP1::MR2         ______/ +-+-+
        MNN1  ______/ +-+-+               /        |MR2|
   MNP1::MNN /        |MR2|              /         +---+
            /         +-+-+              |
            |          i|              ei|MNP2::MR3
            |       ----+-+-+-         +-+-+
            |             | |          |MR3|
           e|MNP2::MR3   MNN MNN       +---+
          +-+-+         (MNP2::MNNi)
          |MR3|
          +-+-+
           i|
       -+-+-+-+-+--
        | | | | |
          MNNs (MNP3::MNNi)


     Figure 10: NEMO Address Assignment for E-E and EI-EI attachments

4.2.  AUTOCONF Approach (MANET Architecture)

   The Ad-hoc Network Autoconfiguration (AUTOCONF) working group
   summarizes the MANET Architecture in [9].  This section gives brief
   explanation how to apply the MANET architecture to the nested NEMO
   topology.  Figure 11 shows the case where each mobile router is
   connected by its egress interface in ad-hoc fashion.  This scenario
   is very similar to what MANET is expected.  Each mobile router
   obtains an IPv6 address on its egress interface from the access
   router called internet gateway in the MANET community.  Thus, each
   mobile router, at the end, obtains an address derived from the access
   router's prefix (ANP::/64).  Note that the egress interface can be
   treated as a manet interface in this case.  Thus, the address



Wakikawa, et al.         Expires January 2, 2008               [Page 14]

Internet-Draft             MANEMO Architecture                 July 2007


   assigned to the manet interface must be unique as stated in [9]. [9]
   suggests link-local addresses, IPv6 address/128, and unique prefix/n
   (n < 128) per a manet interface.  Although the link-local address
   (LL-MRn-e/128) can be used for the MANET purpose at the manet
   interface, each mobile router MUST obtain at least one global address
   for sending a binding update.  We will not discuss the use of link
   local address in further section.  Either ANP::MRn/128 or ANP:n::
   MRn/64 can be possible for the address on the egress interface (i.e.
   manet interface) as shown in Figure 11.  When each mobile router
   obtains a unique prefix from the access router, the access router
   should manage the several prefixes in order to assign individual
   prefix to every mobile router.

   The mobile router uses the address (ANP::MRn/128 or ANP:n::MRn/64 in
   Figure 11) as a care-of address and registers its binding to the home
   agent.  Note that in AUTCONF approach, E-E and EI-EI attachments can
   be treated as a same, because a mobile router does not advertise its
   mobile network prefix to the egress interface.  Each mobile router
   only obtains an IPv6 address from access router and not from
   neighbors (other mobile routers).


                 Access Network
                       |
                     +-+-+
                     |AR | ANP::/64 or /48
                     +-+-+
                       |
                       +-----
   ANP::MR1/128 or --> |e    |
   ANP:1::MR1/64 or  +-+-+   \
   LL-MR1-e/128      |MR1|    |
                     +-+-+    \
                      i|       \
                  -----+----  __|
                             / e| <-- ANP::MR2/128 or
                       _____/ +-+-+   ANP:2::MR2/64 or
                      /       |MR2|   LL-MR2-e/128
                     /        +-+-+
                     |         i|
                     |      ----+-----
                    e|<-- ANP::MR3/128 or
                   +-+-+  ANP:3::MR3/64 or
                   |MR3|  LL-MR3-e/128
                   +-+-+
                    i|
                -----+------




Wakikawa, et al.         Expires January 2, 2008               [Page 15]

Internet-Draft             MANEMO Architecture                 July 2007


       Figure 11: AUTOCONF addressing assignment for E-E attachment

   Figure 12 shows the AUTOCONF model when mobile routers are formed in
   the E-I attachment.  According to the MANET architecture [9], MR2 in
   Figure 12 can obtain an address from the access router (ANP::MR2/128
   or ANP:2::MR2/64), even in this configuration.  Alternatively, MR2
   can run the address autoconfiguration [5] at the attached link
   (mobile network of MR1) and obtains the MNP1::MR2/64 on its egress
   interface as a regular IPv6 address autoconfiguration.  Thus, a
   mobile router may obtain two different addresses such as one from the
   access router and one from its upper mobile router.  For example, the
   mobile router (MR1) directly attached to the access router only
   obtains an IPv6 address from the access router, because there are no
   other upper mobile routers.  On the other hand, MR2 gets two
   addresses from upper mobile router (MR1) and the access router.  The
   mobile router should always select the address assigned from the
   access router as a care-of address and registers it to the home
   agent.  By doing so, any of tunnel overhead issues raised in the
   MANEMO problem statement are merely occurred.  The loop issue can
   also be avoided by running a manet routing protocol on its manet
   interface.  However, there is one big issue that the upper mobile
   router's movement causes the effect to the attached nodes.  For
   example, if MR1 moves change its point of attachment, MR2 also
   detects movement.  This is not what the NEMO Basic Support protocol
   is aimed for.  The movement of a mobile router must be hidden from
   any nodes in its mobile network.  We discuss this in Section 4.3.


         Access Network
              |
            +-+-+
            |AR | ANP::/48 or /64
            +-+-+
              |
             e| <-- ANP::MR1/128 or ANP:1::MR1/64
            +-+-+
            |MR1|
            +-+-+
             i| MNP1::/64
        ------+------
              | <-  MNP1::MR2/64 (NOT AUTOCONF address)
             e| <-- ANP::MR2/128 or ANP:2::MR2/64
            +-+-+
            |MR2|
            +-+-+
             i|
         -----+-----




Wakikawa, et al.         Expires January 2, 2008               [Page 16]

Internet-Draft             MANEMO Architecture                 July 2007


    Figure 12: AUTOCONF Addressing Assignment for the basic Nested NEMO

   Another problem of this configuration is explained with Figure 13.
   If a fixed router (FR1) is located in the mobile network, the MANET
   architecture treats this case as two separate manets inter-connecting
   by a fixed router.  Thus, conceptually, MR2 cannot obtain an address
   from the access router because the fixed router separates MR1 and
   MR2.  Even if we extend the concept of the MANET architecture [9] in
   order for the access router to deliver the global unique prefix to
   the MR2, another problem can be caused.  FR1 must have a route of the
   MR2's prefix assigned by the access router.  However, FR1 is just an
   IPv6 router (i.e. supporting neither the NEMO Basic Support nor
   AUTOCONF), there is no way that FR1 has a route of the access
   router's prefix.  FR1 cannot route the packet which destination is
   MR2's address (ANP::MR2/128 or ANP:2::MR2/64) unless the route of
   MR2's assigned address/prefix is installed in FR1.


          Access Network
               |
             +-+-+
             |AR | ANP::/48 or /64
             +-+-+
               |
              e|<-- ANP::MR1/128 or ANP:1::MR1/64
             +-+-+
             |MR1|
             +-+-+
              i| MNP1::/48
         ------+------
               |
             +-+-+  <-- it should have routes of either one of
             |FR1|                  [ANP:1::/64 & ANP:2::/64] or
             +-+-+                  [ANP::MR1/128 & ANP::MR2/128]
             i'|MNP1:1::/64
          -----+------
               |<---MNP1:1::MR2 (NOT AUTOCONF address)
              e|<--- ANP::MR2/128 or ANP:2::MR2/64 <-- how??
             +-+-+
             |MR2|
             +-+-+
              i|
          -----+------


      Figure 13: AUTOCONF Addressing Assignment when Fixed Router is
                                 employed




Wakikawa, et al.         Expires January 2, 2008               [Page 17]

Internet-Draft             MANEMO Architecture                 July 2007


4.3.  Comparison of Two Approaches

   Before discussing the two approaches, the known MANEMO problems [10]
   are listed here.

   o  Sub-optimal Route and Redundant tunnel

   o  Network Loop

   o  Multiple Exit Routers (Exit Router selection)

   o  No Communication capability without Home Agent Reachability

   If the AUTOCONF approach (Section 4.2) is taken, every mobile router
   may be expected to run a manet routing protocol such as DYMO, OLSR,
   AODV.  Although AUTOCONF approach may not apply to the MANEMO
   scenarios without modification, MANET + AUTOCONF combination can
   solve some of MANEMO issues.  The sub-optimal route can be easily
   solved because each mobile router can registers its care-of address
   generated from the access network prefix.  The packets are routed to
   the access router by IP routing and then routed to the correspondent
   mobile router by the manet routing.  Thus, suboptimal route and
   redundant tunnel are even not happened in this case.  The loop free
   topology formation is essential of a manet routing protocol, too.
   The multiple exits may be solved if a manet routing protocol carries
   additional information of exit routers along with the route
   information.  Finally, if manet routes between mobile routers are
   established, mobile routers can communicate without reaching to the
   home agent.

   If the NEMO addressing approach is selected, None of the issues are
   solved, because the MANEMO activity is begun on the assumption of the
   NEMO addressing approach.

   One thing we have to discuss here is the movement pattern.  There are
   two movement patterns in MANEMO, mobile router's alone movement and
   grouped movement.  For the mobile router's alone movement, a mobile
   router just leaves its MANEMO and goes somewhere.  Therefore, this
   movement pattern is similar to what MANET is addressing (ex. random-
   way point).  On the other hand, the grouped mobility is very NEMO
   specific movement pattern.  When considering the use case such as
   passenger's PAN enters in the train, all the mobile routers move all
   together.  We discuss the grouped mobility in further section.

   Figure 14 shows an example of MANEMO topology.  The arrows of the
   left side of Figure 14 shows the extent of the impact when MR1
   changes its attachment from AR1 to AR2 with grouped mobility pattern.
   If the NEMO approach is used, the impact of MR1 change is hidden by



Wakikawa, et al.         Expires January 2, 2008               [Page 18]

Internet-Draft             MANEMO Architecture                 July 2007


   MR1.  In the AUTOCONF approach, the impact is propagated to entire
   mobile routers that are located behind MR1.  What the NEMO Basic
   Support guarantees is movement transparency of a mobile router.
   Thus, even if MR1 changes its point of attachment, this change is
   perfectly hidden from MR2, MR3 and MR4.  Even if MR1 changes its
   attachment, the topology relationship among MR1 , MR2, MR3 and MR4 is
   not changed.  This movement transparency should be supported also in
   nested NEMO formation because this is essential feature of the NEMO
   Basic Support protocol.  In the AUTOCONF and the MANET approach, this
   feature is missed due to the AUTOCONF addressing assignment.  A
   mobile router obtains an address not from the upper mobile network,
   but directly from the access router.  If MR1 changes its attachment
   to MR2, all the mobile routers behind MR1 (MR2, MR3 and MR4) are
   affected by the change of MR1.  MR2, MR3 and MR4 should obtain a new
   address from AR2 after MR1 changes its attachment to AR2.


                           Access Networks
                         |                  |
                       +-+-+              +-+-+
                       |AR1|              |AR2|
                       +-+-+              +-+-+
                         |       --->       :
   NEMO AUTOCONF         |..................:
   /|\   /|\           +-+-+
   \|/    |            |MR1|
          |            +-+-+
          |              |
          |         -----+-----
          |              |
          |            +-+-+
          |            |MR2|
          |            +-+-+
          |              |
          |      -+------+------+-
          |       |             |
          |     +-+-+         +-+-+
          |     |MR3|         |MR4|
          |     +-+-+         +-+-+
          |       |             |
         \|/ -----+-----   -----+-----


             Figure 14: Extent of the Impact from MR1 movement







Wakikawa, et al.         Expires January 2, 2008               [Page 19]

Internet-Draft             MANEMO Architecture                 July 2007


5.  Solution Guideline

   This section classifies existing and proposed solutions for the
   MANEMO scenarios.  We isolated 2 families:

   1.  Nested NEMO Route Optimization (NEMO centric approach): This is
       the initial root problem of MANEMO.  NEMO mobile routers attach
       to one another, and MANEMO should optimize the resulting topology
       for access to the infrastructure, provide a safe model for mobile
       routers to help one another, some degree of inner routing etc.
       As shown in Section 4.1, the topology of Nested NEMO becomes
       tree.  For this approach, Tree Discovery [11] has been proposed
       to form a loop-free tree in MANEMO and NINA [12] provides some
       routing in that space.  Reverse Routing Header (RRH) [13] is a
       solution how to bypass the number of home agents when mobile
       routers form the nested NEMO.

   2.  Mobile ad hoc (MANET centric): This is when NEMO mobile routers
       form a MANET.  We found 3 categories:

       1.  "1 hop away" A mobile router only discovers a neighbor mobile
           router(s) and communicate with them directly.  The example
           use case is the car 2 car.  NANO [14] provides a very simple
           solution.

       2.  "2 hops away" This is where the NHDP [15] could be inserted,
           still no use of a real routing protocol.  A mobile router
           manages routes for 2-hop neighbor mobile routers.

       3.  "General MANET" In this case, we need a routing protocol of
           the MANET family.  MANEMO could still help in several
           fashion, for instance provide scalability by splitting the
           larger network in a number of more manageable islands,
           interconnected by NEMO over the infrastructure.

















Wakikawa, et al.         Expires January 2, 2008               [Page 20]

Internet-Draft             MANEMO Architecture                 July 2007


6.  IANA considerations

   This document does not require any IANA action.
















































Wakikawa, et al.         Expires January 2, 2008               [Page 21]

Internet-Draft             MANEMO Architecture                 July 2007


7.  Security Considerations

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














































Wakikawa, et al.         Expires January 2, 2008               [Page 22]

Internet-Draft             MANEMO Architecture                 July 2007


8.  Acknowledgments

   We would like to thank Teco Boot, Jim Bound, Jari Arkko and Lim Hyung
   Jin for their comments on this document.  We would also like to thank
   all the people involved in MANEMO activity.


9.  References

9.1.  Normative reference

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

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

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

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

   [5]   Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

9.2.  Informative Reference

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

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

   [8]   Thaler, D., "Multilink Subnet Issues",
         draft-iab-multilink-subnet-issues (work in progress),
         January 2007.

   [9]   Chakeres, I., "Mobile Ad hoc Network Architecture",
         draft-ietf-autoconf-manetarch-01 (work in progress),
         March 2007.

   [10]  Wakikawa, R., "MANEMO Problem Statement",



Wakikawa, et al.         Expires January 2, 2008               [Page 23]

Internet-Draft             MANEMO Architecture                 July 2007


         draft-wakikawa-manemo-problem-statement-00 (work in progress),
         February 2007.

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

   [12]  Thubert, P., "Network In Node Advertisement",
         draft-thubert-nina-00 (work in progress), February 2007.

   [13]  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.

   [14]  Petrescu, A. and C. Janneteau, "The NANO Draft (Scene Scenario
         for Mobile Routers and MNP in RA)",
         draft-petrescu-manemo-nano-00 (work in progress), March 2007.

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






























Wakikawa, et al.         Expires January 2, 2008               [Page 24]

Internet-Draft             MANEMO Architecture                 July 2007


Authors' Addresses

   Wakikawa Ryuji
   Keio University
   Department of Environmental Information, Keio University.
   5322 Endo
   Fujisawa, Kanagawa  252-8520
   Japan

   Phone: +81-466-49-1100
   Fax:   +81-466-49-1395
   Email: ryuji@sfc.wide.ad.jp
   URI:   http://www.wakikawa.org/


   Thomas Clausen
   LIX, Ecole Polytechnique

   Phone: +33 6 6058 9349
   Email: T.Clausen@computer.org


   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/


   Alexandru Petrescu
   Motorola Labs
   Parc les Algorithmes Saint Aubin
   Gif-sur-Yvette  91193
   France

   Email: Alexandru.Petrescu@motorola.com









Wakikawa, et al.         Expires January 2, 2008               [Page 25]

Internet-Draft             MANEMO Architecture                 July 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 January 2, 2008               [Page 26]