<?xml version="1.0" encoding="US-ASCII"?>


<?rfc rfcedstyle="yes" ?>
<?rfc toc="yes" ?>
<!-- <?rfc tocompact="no" ?> -->
<!-- <?rfc compact="no" ?> -->
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc number="4885" category="info">

<!---------------------------------------------->
<!-- Front Section                              >
<!---------------------------------------------->
<front>

<title abbrev="NEMO Terminology">
        Network Mobility Support Terminology
</title>

<!-- AUTHORS -->



<author initials="T." surname="Ernst" fullname="Thierry Ernst">
        <organization abbrev="INRIA">
                INRIA   
        </organization>
        <address>
                <postal>
                        <street>Rocquencourt</street>
                        <street>Domaine de Voluceau B.P. 105</street>
                        <code></code>
                        <city>78153 Le Chesnay Cedex</city><region></region>
                        <country>France</country>
                </postal>
                <phone>+33 (0)1 39 63 59 30</phone>
                <facsimile>+33 (0)1 39 63 54 91</facsimile>
                <email>thierry.ernst@inria.fr</email>
                <uri>http://www-rocq.inria.fr/imara</uri>
        </address>
</author>

<author initials="H-Y.L" surname="Lach" fullname="Hong-Yon Lach">
        <organization abbrev="Motorola">
                Motorola        
        </organization>
        <address>
                <postal>
                        <street>Parc les Algorithmes - Saint-Aubin</street>
                        <city>911193 Gif-sur-Yvette Cedex</city><region></region>
                        <code></code>
                        <country>France</country>
                </postal>
                <phone>+33 (0)1 69-35-25-36</phone>
                <email>hong-yon.lach@motorola.com</email>
        </address>
</author>


<date month="June" year="2007" />
<area>Internet</area><workgroup>NEMO Working Group</workgroup>

<abstract>
  <t>
   This document defines a terminology for discussing network mobility
   (NEMO) issues and solution requirements.
  </t>

</abstract>
</front>
<middle>


<!-- ------------------------------------------ -->
<!-- SECTION 1: INTRODUCTION                     >
<!-- ------------------------------------------ -->
<section title="Introduction">
  <t>

  Network mobility support is concerned with managing the mobility of
  an entire network.  This arises when a router connecting a
  network to the Internet dynamically changes its point of attachment
  to the fixed infrastructure, thereby causing the reachability of the entire
  network to be changed in relation to the fixed Internet topology.
  Such a network is referred to as a mobile network.  Without
  appropriate mechanisms to support network mobility, sessions
  established between nodes in the mobile network and the global
  Internet cannot be maintained after the mobile router changes its
  point of attachment. As a result, existing sessions would break and
  connectivity to the global Internet would be lost.

  </t><t>

  This document defines the specific terminology needed to describe
  the problem space, the design goals <xref
  target="RFC4886"/>, and the solutions for
  network mobility support. This terminology aims to be consistent
  with the usual IPv6 terminology <xref target="RFC2460"/>
  and the generic mobility-related terms already defined in the
  Mobility Related Terminology <xref target="RFC3753"/> and in
  the Mobile IPv6 specification <xref target="RFC3775"/>. Some
  terms introduced in this document may only be useful for defining
  the problem scope and functional requirements of network mobility
  support.

  </t><t>

  Note that the abbreviation NEMO stands for either "a NEtwork that is
  MObile" or "NEtwork MObility". The former (see <xref
  target="sec:term-nemo"/>) is used as a noun, e.g., "a NEMO" meaning
  "a mobile network". The latter (see <xref target="sec:support"/>)
  refers to the concept of "network mobility", as in "NEMO Basic
  Support", and is also the working group's name.

  </t><t>
  
  <xref target="sec:archi"/> introduces terms to define the
  architecture, while terms needed to emphasize the distinct
  functionalities of those architectural components are described in
  <xref target="sec:func"/>. <xref target="sec:nested"/>, <xref
  target="sec:multi"/>, and <xref target="sec:home"/> describe terms
  pertaining to nested mobility, multihoming, and different
  configurations of mobile networks at home, respectively. The
  different types of mobility are defined in <xref
  target="sec:support"/>. The last section lists miscellaneous terms
  that do not fit into any other section.

  </t>
</section> <!-- Intro -->
<!---------------------------------------------->
<!-- SECTION: ARCHITECTURE                      >
<!---------------------------------------------->
<section anchor="sec:archi" title="Architectural Components">

<t>

A mobile network is composed of one or more mobile IP-subnets
and is viewed as a single unit. This network unit is
connected to the Internet by means of one or more mobile routers
(MRs). Nodes behind the MR (referred to as MNNs) primarily comprise
fixed nodes (nodes unable to change their point of attachment while
maintaining ongoing sessions), and possibly mobile nodes (nodes able
to change their point of attachment while maintaining ongoing
sessions). In most 
<?rfc needLines="5" ?>
cases, the internal structure of the mobile network
will be stable (no dynamic change of the topology), but this is not
always true.

</t><t>

<xref target="fig:term0"/> illustrates the architectural components
involved in network mobility and are defined in the following paragraphs:
Mobile Router (MR), Mobile Network (NEMO), Mobile Network Node (MNN), "ingress
interface", "egress interface", and Correspondent Node (CN).  The
other terms, "access router" (AR), "Fixed Node (FN)", "Mobile Node
(MN)", "home agent" (HA), "home link", and "foreign link", are not terms
specific to network mobility and thus are defined in <xref
target="RFC3753"/>.
</t>
<figure anchor="fig:term0" title="Mobile Network on the Home Link">
<artwork><![CDATA[    
                  _        
            CN ->|_|-| Internet      
                     |  _____        
                     |-|     |       |<- home link
                    _  |     |-|  _  |  _
                 |-|_|-|_____| |-|_|-|-|_|<- HA (Home Agent)
                 |  \                |  _
  foreign link ->|  ^                |-|_|<- MR (Mobile Router) 
                    .. AR (access    ___|___
                          router)     _|  |_ 
                                     |_|  |_|
                                      ^    ^        
                                   MNN1    MNN2

]]></artwork>
</figure>
<t>

<xref target="fig:term1"/> shows a single mobile subnet. <xref
target="fig:term2"/> illustrates a larger mobile network comprising
several subnets, attached to a foreign link.

</t>
<figure anchor="fig:term1" title="Single Mobile Subnet on a Foreign Link">
<artwork><![CDATA[ 
                          _        
                    CN ->|_|-|      
                             |  _____        
                _  |         |-|     |       |<- home link
               |_|-|  _  |  _  |     |-|  _  |  _
      2 MNNs -> _  |-|_|-|-|_|-|_____| |-|_|-|-|_|<- HA
               |_|-|  .  |  \             \  |
                   |  .  |<- foreign      ^AR 
   mobile subnet ->   .       link         
                      .                    
                      ^ MR
]]></artwork>
</figure>

<figure anchor="fig:term2" title="Larger Mobile Network Made up of 2 Mobile Subnets">
<artwork><![CDATA[ 
                            _        
                       CN->|_|-|      
    mobile subnet->|           |  _____        
                _  |           |-|     |       |<- home link
         MNN1->|_|-|'i'_'e'|  _  |     |-|  _  |  _
                   |--|_|--|-|_|-|_____| |-|_|-|-|_|<- HA
                    'i'|   |  \                |
                   ____|__ |
    mobile subnet-^ _| .   |<- foreign      
                   |_| .       link
             MNN2 -^   .                  
                       ^ 
                       MR       

'i': MR's ingress interface                                                       
'e': MR's egress interface                              
]]></artwork>
</figure>
<t>

At the network layer, MRs get access to the global Internet from an Access Router 
(AR) on a visited link. An MR maintains the Internet
connectivity for the entire mobile network. A given MR has one or more
egress interfaces and one or more ingress interfaces. When forwarding a
packet to the Internet, the packet is transmitted upstream through one
of the MR's egress interfaces to the AR; when forwarding a packet from
the AR down to the mobile network, the packet is transmitted
downstream through one of the MR's ingress interfaces.
 
</t>

  <section anchor="sec:term-nemo" title="Mobile Network (NEMO)">
    <t>

    As defined in <xref target="RFC3753"/>:

    </t><t>
    
    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.

    </t><t>
   
    Rearrangement of the mobile network and changing the attachment
    point of the egress interface to the foreign link are orthogonal
    processes and do no affect each other.
    
    </t>

  </section>
  <section title="Mobile Subnet"><!-- See Issue A16, A18 and A24 -->
    <t>
  
    A link (subnet) that comprises, or is located within, the mobile
    network.

    </t></section>
  <section title="Mobile Router (MR)">
    <t>

    As defined in <xref target="RFC3753"/>:

    </t><t>

    A router capable of changing its point of attachment to the
    Internet, moving from one link to another link.  The MR is capable
    of forwarding packets between two or more interfaces, and possibly
    running a dynamic routing protocol modifying the state by which it
    does packet forwarding.

    </t><t> 

    An MR acts as a gateway between an entire mobile network and the
    rest of the Internet, and has one or more egress interfaces and one
    or more ingress interfaces.  Packets forwarded upstream to the
    rest of the Internet are transmitted through one of the MR's
    egress interfaces; packets forwarded downstream to the mobile
    network are transmitted through one of the MR's ingress interfaces.

    </t>
  </section>
  <section title="Egress Interface">
    <t>
    As defined in <xref target="RFC3753"/>:

    </t><t>

    The network interface of an MR attached to the home link if the MR
    is at home, or attached to a foreign link, if the MR is in a
    foreign network.

    </t></section>
  <section title="Ingress Interface">
    <t>

    As defined in <xref target="RFC3753"/>:
 
    </t><t>
    The interface of an MR attached to a link inside the mobile
    network. 

    </t></section>
  <section title="Mobile Network Prefix (MNP)">
    <t>

    As defined in <xref target="RFC3753"/>:

    </t><t>

    A bit string that consists of some number of initial bits of an IP
    address which identifies the entire mobile network within the
    Internet topology.  All nodes in a mobile network necessarily have
    an address containing this prefix.
   
    </t></section>
   <section title="Mobile Network Node (MNN)">
    <t>

    As defined in <xref target="RFC3753"/>:

    </t><t>
     
    Any node (host or router) located within a mobile network, either
    permanently or temporarily.  A Mobile Network Node may be either a
    fixed node (LFN) or a mobile node (either VMN or LMN).

    </t>
  </section>

  <section title="Correspondent Node (CN)">
   <t>

   Any node that is communicating with one or more MNNs. A CN could
   be either located within a fixed network or within a mobile
   network, and could be either fixed or mobile.

   </t>
  </section>
<!-- ===============================================================-->
  <section title="Correspondent Router (CR)">
    <t>

<!-- 0502, suggested by TJ to remove
   A router topologically close to the CN and on the path from a MNN
   to the CN, that has been extented with
   some mobility support capabilities and that may take special
   actions based on that. Details of the capabilities do not presented
   in the current documents. The CR is said NEMO-enabled if such
   capabilities are defined for network mobility support.
Finaly, added in 0510, following RO drafts:
-->
  
     
      Refers to the entity that is capable of terminating a
      Route Optimization session on behalf of a Correspondent Node
      (see also NEMO Route Optimization in <xref
      target="term:NEMO-RO"/>).
     </t>

  </section>
<!-- ===============================================================-->
   <section title="Correspondent Entity (CE)">
     <t>
      Refers to the entity with which a Mobile Router or Mobile
      Network Node attempts to establish a Route Optimization session.
      Depending on the Route Optimization approach, the
      Correspondent Entity may be a Correspondent Node or Correspondent
      Router (see also NEMO Route Optimization in <xref
      target="term:NEMO-RO"/>).
     </t>
   
  </section>
</section> <!-- Architecture -->
<!---------------------------------------------->
<!-- SECTION: FUNCTIONAL TERMS                  >
<!---------------------------------------------->
<section anchor="sec:func" title="Functional Terms">
  <t>
   Within the term Mobile Network Node (MNN), we can distinguish
   between Local Fixed Nodes (LFN), Visiting Mobile Nodes (VMN), and
   Local Mobile Nodes (LMN). The distinction is a property of how
   different types of nodes can move in the topology and is necessary
   to discuss issues related to mobility management and access
   control; however, it does not imply that network mobility or host
   mobility should be handled differently. Nodes are classified
   according to their function and capabilities with the rationale
   that nodes with different properties may have different
   requirements.

  </t><t>
   <xref target="fig:term3"/> illustrates a VMN changing its point of
   attachment from its home link located outside the mobile network to
   within a mobile network. The figure also illustrates an LMN changing
   its point of attachment within the mobile network.


<figure anchor="fig:term3" title="LFN vs LMM vs VMN">
<artwork>
<![CDATA[

    mobile subnet 1 |  _      +++++++<<<+++++++++++
                    |-|_|-|   +                   +      
           ++<<<LMN-|  \  |   +                 |-MR  
           +              |   +          _____  |  _ HA_MR    
           +        |  _  |   +         |     |-|-|_|       
           + LMN _  |-|_|-|   _   |  _  |     |    _  
           ++++>|_|-|  \  |--|_|--|-|_|-|_____|-|-|_| 
                    |     |   ^   |  \          |    HA_VMN 
             VMN _  |         MR                |  
                |_|-|                           |-VMN  
              ^    mobile subnet 2               +
              +                                  +
              ++++++++<<<+++++++++++++++++++++++++                     
      
+++>>>+++ = changing point of attachment
]]></artwork>
</figure>

  </t><t>
   In a typical-use case of NEMO Basic Support <xref
   target="RFC3963"/>, only the MR and the HA are NEMO-enabled. LFNs
   are not MIPv6-enabled nor NEMO-enabled. On the other hand, a VMN or
   an LMN acting as a mobile router may be NEMO-enabled, whereas a VMN
   or an LMN acting as a mobile node may be MIPv6-enabled.
 
  </t><t>
   For NEMO Extended Support, details of the capabilities are not yet
   known at the time of this writing, but NEMO-enabled nodes may
   be expected to implement some sort of Route Optimization.
  </t>

  <section title="Local Fixed Node (LFN)">
    <t>

    A fixed node (FN), either a host or a router, that belongs to the
    mobile network and is unable to change its point of attachment
    while maintaining ongoing sessions. Its address is taken from
    an MNP.

    </t>
  </section>

  <section title="Visiting Mobile Node (VMN)">
    <t>

    Either a mobile node (MN) or a mobile router (MR), assigned to a
    home link that doesn't belong to the mobile network and that is
    able to change its point of attachment while maintaining ongoing
    sessions. A VMN that is temporarily attached to a mobile subnet
    (used as a foreign link) obtains an address on that subnet (i.e., the
    address is taken from an MNP). 

    </t>
  </section>
<?rfc needLines="10" ?>
  <section title="Local Mobile Node (LMN)">
    <t>
 
    Either a mobile node (MN) or a mobile router (MR), assigned to a home link
    belonging to the mobile network and which is able to change its
    point of attachment while maintaining ongoing sessions. Its
    address is taken from an MNP.

    </t>
  </section>

  <section title="NEMO-Enabled Node (NEMO-node)">
    <t>

    A node that has been extended with network mobility support
    capabilities as described in NEMO specifications.

    </t>
  </section>


<!-- ===============================================================-->
  <section title="MIPv6-Enabled Node (MIPv6-Node)">
    <t>

    A node that has been extended with host mobility support
    capabilities as defined in the Mobile IPv6 specification <xref
    target="RFC3775"/>.

    </t>
 </section>
</section> <!-- Functional Terms -->
<!---------------------------------------------->
<!-- SECTION: NESTED MOBILITY                   >
<!---------------------------------------------->

<section anchor="sec:nested" title="Nested Mobility Terms">

<t> 
Nested mobility occurs when there is more than one level of mobility,
i.e., when a mobile network acts as an access network and allows
visiting nodes to attach to it. There are two cases of nested
mobility:

  <list style="symbols">

    <t>

    The attaching node is a single VMN (see <xref
    target="fig:term3"/>). For instance, when a passenger
    carrying a mobile phone gets Internet access from the public
    access network deployed on a bus.

    </t><t>

    The attaching node is an MR with nodes behind it, i.e., a mobile
    network (see <xref target="fig:nested-sub"/>). For instance, when
    a passenger carrying a PAN gets Internet access from the public
    access network deployed on a bus.

    </t>
  </list>

</t><t>

For the second case, we introduce the following terms:

</t>

    <section title="Nested Mobile Network (nested-NEMO)">
    <t>

    A mobile network is said to be nested when a mobile network
    (sub-NEMO) is attached to a larger mobile network
    (parent-NEMO). The aggregated hierarchy of mobile networks becomes
    a single nested mobile network (see <xref target="fig:nested-sub"/>). 

    </t></section>
    <section title="Root-NEMO">
    <t>

    The mobile network at the top of the hierarchy connecting the
    aggregated nested mobile networks to the Internet (see <xref target="fig:nested-sub"/>).

    </t></section>
    <section title="Parent-NEMO">
    <t>

    The upstream mobile network providing Internet access to another mobile
    network further down the hierarchy (see <xref target="fig:nested-sub"/>).

    </t></section>
    <section title="Sub-NEMO">
    <t>

    The downstream mobile network attached to another mobile network
    up in the hierarchy. It becomes subservient of the parent-NEMO. The
    sub-NEMO is getting Internet access through the parent-NEMO and
    does not provide Internet access to the parent-NEMO (see <xref target="fig:nested-sub"/>).


    </t></section>
    <section title="Root-MR">
    <t>

    The MR(s) of the root-NEMO used to connect the nested mobile
    network to the fixed Internet (see <xref
    target="fig:nested-sub"/>).

    </t></section>
    <section title="Parent-MR">
    <t>

    The MR(s) of the parent-NEMO.

    </t></section>
    <section title="Sub-MR">
      <t>

      The MR(s) of the sub-NEMO, which is connected to a parent-NEMO

      </t>
    </section>
    <section title="Depth">
      <t>
      In a nested NEMO, indicates the number of sub-MRs a packet has to cross
      between a MNN and the root-MR. 
      
      </t><t>
      A MNN in the root-NEMO is at depth 1. If there are multiple
      root-NEMOs, a different depth is computed from each root-MR.
      </t>
    </section>
<?rfc needLines="100" ?>
<figure anchor="fig:nested-sub" title="Nested Mobility: a sub-NEMO attached to a larger mobile network">
<artwork>
<![CDATA[                         
                                            _____        
                          _  |        _    |     |       
                    _  |-|_|-|  _  |-|_|-|-|     |-|        _
              _  |-|_|-|  \  |-|_|-|  \  | |_____| |  _  |-|_|
        _  |-|_|-|     |           |     |         |-|_|-|      
       |_|-|  \  |                                    \  |
           |                            
                                        
       MNN   AR  sub-MR  AR  root-MR AR              AR   HA
                                     
       <--------------><----------><----><---------><-------->       
           sub-NEMO     root-NEMO    fl   Internet   Home Network

]]>
</artwork>
</figure>


</section> <!--Nested-->

<!---------------------------------------------->
<!-- SECTION MULTIHOMING                        >
<!---------------------------------------------->

<section anchor="sec:multi" title="Multihoming Terms">

<t>

Multihoming, as currently defined by the IETF, covers site-multihoming
<xref target="RFC3582"/> and host multihoming. We enlarge this
terminology to include "multihomed mobile router" and "multihomed
mobile network". The specific configurations and issues pertaining to
multihomed mobile networks are covered in <xref
target="NEMO-ISSUES"/>.

</t>

    <section title="Multihomed Host or MNN">
      <t>
  
      A host (e.g., an MNN) is multihomed when it has several
      addresses to choose between, i.e., in the following cases when it
      is:

      <list style="symbols">
         <t>
         Multi-prefixed: multiple prefixes are advertised on the
         link(s) to which the host is attached, or

         </t><t> 
         Multi-interfaced: the host has multiple interfaces to choose
         from, on or not on the same link.

         </t>
      </list>
      </t>
    </section>
    
    <section title="Multihomed Mobile Router">
      <t>
      
      From the definition of a multihomed host, it follows that a
      mobile router is multihomed when it has several addresses
      to choose between, i.e., in the following cases when the MR is:

      <list style="symbols">
         <t>
         Multi-prefixed: multiple prefixes are advertised on the
         link(s) to which an MR's egress interface is attached, or

         </t><t> 
         Multi-interfaced: the MR has multiple egress interfaces to
         choose between, on or not on the same link (see <xref target="fig:multi-egress"/>).
         </t>
      </list>
      </t>
    </section>
<figure anchor="fig:multi-egress" title="Multihoming: MR with multiple E-faces">
<artwork>
<![CDATA[
                                _____
                _           _  |     |
               |_|-|  _  |-|_|-|     |-|        _
                _  |-|_|=|  \  |_____| |  _  |-|_|
               |_|-|     |             |-|_|-|
                                          \  |
               MNNs   MR   AR  Internet   AR    HA
]]>
</artwork>
</figure>

    <section title="Multihomed Mobile Network (multihomed-NEMO)">
     <t>
  
      A mobile network is multihomed when a MR is multihomed or
      there are multiple MRs to choose between (see the corresponding
      analysis in <xref target="NEMO-ISSUES"/>).
  
     </t>
    </section>
<figure anchor="fig:multi-MR" title="Multihoming: NEMO with Multiple MRs">
<artwork>
<![CDATA[
                     MR1
                      _  |
                _  |-|_|-|  _____
               |_|-|     |-|     |
          MNNs  _  |       |     |-|        _
               |_|-|  _  |-|_____| |  _  |-|_|
                   |-|_|-|         |-|_|-|
                         |               |
                     MR2
]]>
</artwork>
</figure>

  <section title="Nested Multihomed Mobile Network">
   <t>

   A nested mobile network is multihomed when either a root-MR is
   multihomed or there are multiple root-MRs to choose between.

   </t>
  </section>

  <section title="Split-NEMO">

     <!--  No def in version-05, added 0611 def proposed by Chan-Wah
     on NEMO ML 051122-->

     <t>

     Split-NEMO refers to the case where a mobile network becomes two
     or more independent mobile networks due to the separation of
     Mobile Routers that are handling the same MNP (or MNPs) in the
     original mobile network before the separation.

     </t>    
   </section>

  <section title="Illustration">

   <t>

   <xref target="fig:multi-egress"/> and <xref target="fig:multi-MR"/>
   show two examples of multihomed mobile networks. <xref
   target="fig:multi-nested"/> shows two independent mobile
   networks. NEMO-1 is single-homed to the Internet through
   MR1. NEMO-2 is multihomed to the Internet through MR2a and
   MR2b. Both mobile networks offer access to visiting nodes and
   networks through an AR.

   </t><t>
   
   Let's consider the two following nested scenarios in <xref
   target="fig:multi-nested"/>:

   </t><t>
 
    <list style="hanging">

     <t hangText="Scenario 1: What happens when MR2a's egress
     interface is attached to AR1?">
     </t>
      <list style="symbols">
       <t>NEMO-2 becomes subservient to NEMO-1</t>

       <t>NEMO-1 becomes the parent-NEMO to NEMO-2 and the
       root-NEMO for the aggregated nested mobile network</t>

       <t>NEMO-2 becomes the sub-NEMO</t>

       <t>MR1 is the root-MR for the aggregated nested mobile network</t>
  
       <t>MR2a is a sub-MR in the aggregated nested mobile network</t>
  
       <t>NEMO-2 is still multihomed to the Internet through AR1 and
       ARz</t>

       <t>The aggregated nested mobile network is not multihomed, since
       NEMO-2 cannot be used as a transit network for NEMO-1</t>

      </list>
  
     <t hangText="Scenario 2: What happens when MR1's egress
     interface is attached to AR2?">
     </t>
      <list style="symbols">
       <t>NEMO-1 becomes subservient to NEMO-2</t>

       <t>NEMO-1 becomes the sub-NEMO</t>

       <t>NEMO-2 becomes the parent_NEMO to NEMO-1 and also the
       root-NEMO for the aggregated nested mobile network </t>

       <t>MR2a and MR2b are both root-MRs for the aggregated nested
       mobile network</t>

       <t>MR1 is a sub-MR in the aggregated nested mobile network</t>
       <t>NEMO-1 is not multihomed</t>
       <t>The aggregated nested mobile network is multihomed</t>
      </list>
    </list>
   </t>
  </section>
<figure anchor="fig:multi-nested" title="Nested Multihomed NEMO">
<artwork>
<![CDATA[
                _  |  _  |
               |_|-|-|_|-|  _   _____
 NEMO-1    MNNs _  | MR1 |-|_|-|     |
               |_|-|       ARx |     |-|        _
            AR1 \  |     |  _  |     | |  _  |-|_|
                      _  |-|_|-|     | |-|_|-|
                _  |-|_|-| ARy |     |       |
               |_|-| MR2a   _  |     |
 NEMO-2    MNNs _  |     |-|_|-|     |
               |_|-|  _  | ARz |_____|
                \  |-|_|-|
            AR2      MR2b   
                     

]]>
</artwork>
</figure>


</section> <!-- Multihomed-->
<!---------------------------------------------->
<!-- SECTION TAKEN FROM HOME NETWORK MODEL      >
<!---------------------------------------------->
<section anchor="sec:home" title="Home Network Model Terms">
  <t>
  The terms in this section are useful to describe the possible
  configurations of mobile networks at the home. For a better
  understanding of the definitions, the reader is recommended to read
  <xref target="RFC4887"/>, where such
  configurations are detailed.

  </t>
  <section title="Home Link">
    <t>

    The link attached to the interface at the Home Agent on which the
    Home Prefix is configured. The interface can be a virtual
    interface, in which case the Home Link is a Virtual Home Link.
   
    </t>
   </section>
   <section title="Home Network">
    <t>
  
   The Network formed by the application of the Home Prefix to the
   Home Link. With NEMO, the concept of Home Network is extended as
   explained below.

     </t>

   </section><section title="Home Address">
     <t>

     With Mobile IPv6, a Home Address is derived from the Home Network
     prefix.  This is generalized in NEMO with some limitations: A
     Home Address can be derived either from the Home Network or from
     one of the Mobile Router's MNPs.
<?rfc needLines="10" ?>
     </t>
   </section><section title="Mobile Home Network">
     <t> 
   
     A Mobile Network (NEMO) that is also a Home Network.  The MR, or
     one of the MR(s), that owns the MNP may act as the Home Agent for
     the mobile nodes in the Mobile Home Network.
    

     </t>
   </section><section title="Distributed Home Network">
     <t>
    
     
     A Distributed Home Network is a Home Network that is distributed
     geographically between sites. The aggregated Home Prefix is
     partitioned between the sites and advertised by all sites.

     </t><t>

     This aggregated Home Prefix can be further aggregated within a
     service provider network or between service providers, to form a
     prefix that is announced into the Internet by the service
     provider(s) from multiple points.

     </t><t>
   
     The sites may be connected using a mesh of private links and
     tunnels. A routing protocol is used within and between sites to
     exchange routes to the subnets associated to the sites and,
     eventually, to Mobile Routers registered off-site.

     </t>
   </section><section title="Mobile Aggregated Prefix">
     <t>

     <!-- Text proposed by Vijay 050712 following TJ concerns
     0510 added
     "that is in turn advertised as the Home Link Prefix."
     but Vijay 060418 proposes to remove this last bit -->

     An aggregation of Mobile Network Prefixes.

     </t>
   </section><section title="Aggregated Home Network">
     <t>

     The Home Network associated with a Mobile Aggregated Prefix. This
     aggregation is advertised as a subnet on the Home Link, and thus
     used as the Home Network for NEMO purposes.

     </t>
   </section><section title="Extended Home Network">
     <t>

     The network associated with the aggregation of one or more Home
     Network(s) and Mobile Network(s). As opposed to the Mobile IPv6
     Home Network that is a subnet, the Extended Home Network is an
     aggregation and is further subnetted.

     </t>
   </section><section title="Virtual Home Network">
     <t>

     <!-- 0510 OLD The Home Network associated with a Virtual
     Network. 
     -->

     An aggregation of Mobile Network Prefixes that is in turn
     advertised as the Home Link Prefix.
     The Extended Home Network and the Aggregated Home Network can be
     configured as Virtual Home Network.

     </t>
   </section>

  
</section>

<!---------------------------------------------->
<!-- SECTION MOBILITY SUPPORT TERMS             >
<!---------------------------------------------->

<section anchor="sec:support" title="Mobility Support Terms">

<section title="Host Mobility Support">
  <t>

  Host Mobility Support is a mechanism that maintains session
  continuity between mobile nodes and their correspondents upon the
  mobile host's change of point of attachment. It can be achieved
  using Mobile IPv6 or other mobility support mechanisms.

  </t>
</section>
<section title="Network Mobility Support (NEMO Support)">
  <t>

  Network Mobility Support is a mechanism that maintains session
  continuity between mobile network nodes and their correspondents
  upon a mobile router's change of point of attachment. Solutions for
  this problem are classified into NEMO Basic Support, and NEMO
  Extended Support.

  </t>
</section>
<section title="NEMO Basic Support">
  <t>

  NEMO Basic Support is a solution to preserve session continuity by
  means of bidirectional tunneling between MRs and their HAs, much
  like what is done with Mobile IPv6 <xref target="RFC3775"/>
  for mobile nodes when Routing Optimization is not used. Only the HA
  and the MR are NEMO-enabled. 

  </t><t>

  RFC 3963 <xref target="RFC3963"/>  is the solution specified by the
  NEMO Working Group for NEMO Basic Support.

  </t>
</section>
<section title="NEMO Extended Support">
  <t>

  NEMO Extended support is to provide performance optimizations,
  including routing optimization between arbitrary MNNs and CNs.

  </t>
</section>
<section anchor="term:NEMO-RO" title="NEMO Routing Optimization (NEMO RO)">

  
  <t>
  The term "Route Optimization" is accepted in a broader sense than
  already defined for IPv6 Host Mobility in <xref
  target="RFC3775"/> to loosely refer to any approach that
  optimizes the transmission of packets between a Mobile Network Node
  and a Correspondent Node.

  </t><t>

  For more information about NEMO Route Optimization in the NEMO
  context, see the problem statement <xref
  target="RFC4888"/> and the solution space
  analysis <xref target="RFC4889"/>.

  </t>
</section>
<section title="MRHA Tunnel">
  <t>

   The bidirectional tunnel between a Mobile Router and its Home
   Agent.
   
  </t>
</section>
  <section title="Pinball Route">
    <t>

       A pinball route refers to the non-direct path taken by packets, 
       which are routed via one or more Home Agents, as they transit
       between a Mobile Network Node and a Correspondent Node.

    </t><t>

        A packet following a pinball route would appear like a ball
        bouncing off one or more Home Agents before reaching its final
        destination.
        
    </t>
  </section>
</section><!-- Mobility Support Terms ->




<!------------------------------------------------------>
<!--    SECTION: SECURIRY                               >
<!------------------------------------------------------>
<section title="Security Considerations">

<t>

   As this document only provides terminology and describes neither a
   protocol, procedure, or an implementation, there are no security
   considerations associated with it.

</t>
</section>

<!------------------------------------------------------>
<!--    SECTION: ACKNOWLEDGMENTS                        >
<!------------------------------------------------------>
<section title="Acknowledgments">



<t>

The material presented in this document takes most of the text from
documents initially submitted to the former MobileIP WG and
MONET BOF and was published as part of a PhD dissertation <xref
target="Thesis.Ernst01"/>. The authors would therefore like to thank
both Motorola Labs Paris and INRIA (PLANETE team, Grenoble, France),
where this terminology originated, for the opportunity to bring it to
the IETF, and particularly Claude Castelluccia for his advice,
suggestions, and direction, Alexandru Petrescu and Christophe
Janneteau. We also acknowledge input from Erik Nordmark, Hesham
Soliman, Mattias Petterson, Marcelo Bagnulo, T.J. Kniveton, Masafumi
Watari, Chan-Wah Ng, JinHyeock Choi, and numerous other people from the
NEMO Working Group. The Home Network Model section is contributed by
Pascal Thubert, Ryuji Wakikawa, and Vijay Devaparalli.

</t>

</section> <!-- Acknowledgments -->

</middle>


<!------------------------------------------------------>
<!-- Back Section                                       >
<!------------------------------------------------------>

<back>

<!------------------------------------------------------>
<!--    REFERENCES                                      >       
<!------------------------------------------------------>
<?rfc needLines="20" ?>

<references title="Normative References">


<reference anchor='RFC3753'>
<front>
<title>Mobility Related Terminology</title>
<author initials='J.' surname='Manner' fullname='J. Manner'>
<organization /></author>
<author initials='M.' surname='Kojo' fullname='M. Kojo'>
<organization /></author>
<date year='2004' month='June' /></front>
<seriesInfo name='RFC' value='3753' />
<format type='TXT' octets='74143' target='ftp://ftp.isi.edu/in-notes/rfc3753.txt' />
</reference>

<reference anchor='RFC3775'>
<front>
<title>Mobility Support in IPv6</title>
<author initials='D.' surname='Johnson' fullname='D. Johnson'>
<organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'>
<organization /></author>
<author initials='J.' surname='Arkko' fullname='J. Arkko'>
<organization /></author>
<date year='2004' month='June' /></front>
<seriesInfo name='RFC' value='3775' />
<format type='TXT' octets='393514' target='ftp://ftp.isi.edu/in-notes/rfc3775.txt' />
</reference>

<reference anchor='RFC3963'>
<front>
<title>Network Mobility (NEMO) Basic Support Protocol</title>
<author initials='V.' surname='Devarapalli' fullname='V. Devarapalli'>
<organization /></author>
<author initials='R.' surname='Wakikawa' fullname='R. Wakikawa'>
<organization /></author>
<author initials='A.' surname='Petrescu' fullname='A. Petrescu'>
<organization /></author>
<author initials='P.' surname='Thubert' fullname='P. Thubert'>
<organization /></author>
<date year='2005' month='January' /></front>
<seriesInfo name='RFC' value='3963' />
<format type='TXT' octets='75955' target='ftp://ftp.isi.edu/in-notes/rfc3963.txt' />
</reference>

<reference anchor='RFC4886'>
<front>
<title>Network Mobility (NEMO) Support Goals and Requirements</title>
<author initials='T' surname='Ernst' fullname='Thierry Ernst'>
    <organization />
</author>
<date month='June' year='2007' /></front>
<seriesInfo name='RFC' value='4886' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-06.txt' />
</reference>

<reference anchor='RFC4887'>
<front>
<title>Network Mobility (NEMO) Home Network Models</title>
<author initials='P.T.' surname='Thubert' fullname='Pascal Thubert'>
<organization /></author>
<author initials='R.W.' surname='Wakikawa' fullname='Ryuji Wakikawa'>
<organization /></author>
<author initials='V.D.' surname='Devarapalli' fullname='Vijay Devarapalli'>
<organization /></author>
<date month='June' year='2007' />
</front>
<seriesInfo name='RFC' value='4887' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-06.txt' />
</reference>

    
<reference anchor='RFC2460'>
<front>
<title>Internet Protocol Version 6 (IPv6)</title>
<author initials='S.' surname='Deering' fullname='Steve Deering'>
<organization /></author>
<author initials='R.' surname='Hinden' fullname='Robert Hinden'>
<organization /></author>
<date year='1998' month='December' /></front>
<seriesInfo name='RFC' value='2460' />
</reference>

<reference anchor='RFC4888'>
<front>
<title>Network Mobility Route Optimization Problem Statement</title>
<author initials='C-W' surname='Ng' fullname='Chan-Wah Ng'> <organization /> </author>
<author initials='P' surname='Thubert' fullname='Pascal Thubert'> <organization /> </author>
<author initials='M' surname='Watari' fullname='Masafumi Watari'> <organization /> </author>
<author initials='F' surname='Zhao' fullname='Fan Zhao'> <organization /> </author>
<date month='June' year='2007' />
</front>
<seriesInfo name='RFC' value='4888' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-03.txt' />
</reference>

<reference anchor='RFC4889'>
<front>
<title>Network Mobility Route Optimization Solution Space Analysis</title>
<author initials='C-W' surname='Ng' fullname='Chan-Wah Ng'> <organization /> </author>
<author initials='F' surname='Zhao' fullname='Fan Zhao'> <organization /> </author>
<author initials='M' surname='Watari' fullname='Masafumi Watari'> <organization /> </author>
<author initials='P' surname='Thubert' fullname='Pascal Thubert'> <organization /> </author>
<date month='June' year='2007' />
</front>
<seriesInfo name='RFC' value='4889' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-03.txt' />
</reference>

</references>

<references title="Informative References">


<reference anchor='NEMO-ISSUES'>
<front>
<title>Analysis of Multihoming in Network Mobility Support</title>
<author initials='C-W' surname='Ng' fullname='Chan-Wah Ng'>
    <organization />
</author>
<author initials='E-K' surname='Paik' fullname='EunKyoung Paik'>
    <organization />
</author>
<author initials='T' surname='Ernst' fullname='Thierry Ernst'>
    <organization />
</author>
<author initials='M' surname='Bagnulo' fullname='Marcelo Bagnulo'>
    <organization />
</author>
<date month='February' year='2007' /></front>
<seriesInfo name='Work in' value='Progress' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-06.txt' />
</reference>

<reference anchor='RFC3582'>
<front>
<title>Goals for IPv6 Site-Multihoming Architectures</title>
<author initials='J.' surname='Abley' fullname='J. Abley'>
<organization /></author>
<author initials='B.' surname='Black' fullname='B. Black'>
<organization /></author>
<author initials='V.' surname='Gill' fullname='V. Gill'>
<organization /></author>
<date year='2003' month='August' /></front>
<seriesInfo name='RFC' value='3582' />
<format type='TXT' octets='17045' target='ftp://ftp.isi.edu/in-notes/rfc3582.txt' />
</reference>


<reference anchor='Thesis.Ernst01'>
<front>
<title>Network Mobility Support in IPv6</title>

<author initials='T.E' surname='Ernst' fullname='Thierry Ernst'>
    <organization> INRIA Rhone-Alpes and Motorola Labs Paris</organization>
    <postal><country>France</country></postal>
</author>
<date month='October' year='2001' />
</front>
<seriesInfo name="PhD's Thesis."  value=""/>
<seriesInfo name="Universite Joseph Fourier, Grenoble, France" value=""/>
<format target='http://www.inria.fr/rrrt/tu-0714.html' type='PDF'/>
</reference>

</references>


<!------------------------------------------------------>
<!-- APPENDIX	      				        >
<!------------------------------------------------------>



</back>

</rfc>
