[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
NEMO Working Group                                                 C. Ng
Internet-Draft                                  Panasonic Singapore Labs
Expires: August 25, 2005                                      P. Thubert
                                                           Cisco Systems
                                                              H. Ohnishi
                                                                     NTT
                                                                 E. Paik
                                                                      KT
                                                       February 21, 2005


       Taxonomy of Route Optimization models in the NEMO Context
                   draft-thubert-nemo-ro-taxonomy-04

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

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

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

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

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

   This Internet-Draft will expire on August 25, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   With current Network Mobility (NEMO) Basic Support, all



Ng, et al.               Expires August 25, 2005                [Page 1]


Internet-Draft                 RO-Taxonomy                 February 2005


   communications to and from Mobile Network Nodes must go through the
   MR-HA tunnel when the mobile network is away.  This results in
   increased length of packet route and increased packet delay.  To
   overcome these limitations, one might have to turn to Route
   Optimization (RO) for NEMO.  This memo documents various types of
   Route Optimization in NEMO, and explores the benefits and tradeoffs
   in different aspects of NEMO Route Optimization.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Statement of NEMO Route Optimization . . . . . . . . .  5
     2.1   Sub-Optimality with NEMO Basic Support . . . . . . . . . .  5
     2.2   Nesting of Mobile Networks . . . . . . . . . . . . . . . .  6
     2.3   MIPv6 Host in Mobile Networks  . . . . . . . . . . . . . .  8
     2.4   Communications within a Mobile Network . . . . . . . . . .  8
   3.  Benefits of NEMO Route Optimization  . . . . . . . . . . . . .  9
   4.  Solution Space of NEMO Route Optimization  . . . . . . . . . . 10
     4.1   MR-to-CN Optimization  . . . . . . . . . . . . . . . . . . 10
     4.2   Infrastructure Optimization  . . . . . . . . . . . . . . . 10
     4.3   Nested Tunnels Optimization  . . . . . . . . . . . . . . . 12
     4.4   MIPv6-over-NEMO Optimization . . . . . . . . . . . . . . . 13
     4.5   Intra-NEMO Optimization  . . . . . . . . . . . . . . . . . 14
   5.  Issues of Route Optimization . . . . . . . . . . . . . . . . . 16
     5.1   Additional Signaling Overhead  . . . . . . . . . . . . . . 16
     5.2   Increased Protocol Complexity  . . . . . . . . . . . . . . 17
     5.3   Mobility Awareness . . . . . . . . . . . . . . . . . . . . 17
     5.4   New Functionalities  . . . . . . . . . . . . . . . . . . . 17
     5.5   Other Considerations . . . . . . . . . . . . . . . . . . . 19
   6.  Analysis of Solution Space . . . . . . . . . . . . . . . . . . 20
     6.1   MR-to-CN Optimization  . . . . . . . . . . . . . . . . . . 20
     6.2   Infrastructure Optimization  . . . . . . . . . . . . . . . 22
     6.3   Nested Tunnels Optimization  . . . . . . . . . . . . . . . 22
     6.4   MIPv6-over-NEMO Optimization . . . . . . . . . . . . . . . 24
     6.5   Intra-NEMO Optimization  . . . . . . . . . . . . . . . . . 25
   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
   A.  Proposed Route Optimizations . . . . . . . . . . . . . . . . . 32
     A.1   MR-to-CN Optimizations . . . . . . . . . . . . . . . . . . 32
     A.2   Infrastructure Optimizations . . . . . . . . . . . . . . . 32
     A.3   Nested Tunnel Optimizations  . . . . . . . . . . . . . . . 33
     A.4   MIPv6-over-NEMO Optimizations  . . . . . . . . . . . . . . 35
     A.5   Intra-NEMO Optimizations . . . . . . . . . . . . . . . . . 36
       Intellectual Property and Copyright Statements . . . . . . . . 37





Ng, et al.               Expires August 25, 2005                [Page 2]


Internet-Draft                 RO-Taxonomy                 February 2005


1.  Introduction

   With current Network Mobility (NEMO) Basic Support [1], all
   communications to and from nodes in a mobile network must go through
   the bi-directional tunnel established between the Mobile Router (MR)
   and its Home Agent (HA) when the mobile network is away.  Although
   such an arrangement allows Mobile Network Nodes (MNNs) to reach and
   be reached by any node on the Internet, there are associated
   limitations which might be unacceptable for certain applications.  In
   particular, voice over IP has strict requirements on packet jotter
   and latency.  To substantially improve on NEMO Basic Support, one
   might have to turn to Route Optimization (RO) for NEMO.  Here, we use
   the term "Route Optimization" to loosely refer to any approach that
   optimize the transmission of packets between a Mobile Network Node
   and Correspondent Node (CN).

   This document explores limitations inherent in NEMO Basic Support,
   and analyze the possible approaches to Route Optimization with NEMO.
   It is expected for readers to be familiar with general terminologies
   related to mobility in [2] and [3], and NEMO related terms defined in
   [4].  In addition, it is beneficial to keep in mind the design
   requirements of NEMO [5].  A point to note is that since this
   document discusses aspects of Route Optimization, the readers may
   assume that a mobile network or a mobile host is away when they are
   mentioned throughout this document, unless it is explicitly specified
   that they are at home.

   It is the objective of this document to address the need for a Route
   Optimization analysis in the NEMO Working Group.  To quote the
   charter of the NEMO Working Group:

      "...  The WG will work on: ...  ...  [an] informational document
      which specifies a detailed problem statement for Route
      Optimization and looks at various approaches to solving this
      problem.  This document will look into the issues and tradeoffs
      involved in making the network's movement visible to some nodes,
      by optionally making them 'NEMO aware'.  The interaction between
      Route Optimization and IP routing will also be described in this
      document.  Furthermore, security considerations for the various
      approaches will also be considered.  ..."

   To such end, this document first describes the problem of Route
   Optimization in NEMO in Section 2.  Next, Section 3 discusses the
   benefits route optimization might bring to NEMO.  Follwing this,
   Section 4 explores possible approaches to solve Route Optimization
   problems.  Section 5 then discusses general considerations concerning
   a Route Optimization solution, and Section 6 goes into detail
   considerations of each specific approach described in the solution



Ng, et al.               Expires August 25, 2005                [Page 3]


Internet-Draft                 RO-Taxonomy                 February 2005


   space.  Finally, Section 7 concludes this memo.  In addition, we
   attempt to list various proposed solutions for Route Optimization in
   Appendix A, and classify them according to the solution space
   described in Section 4.















































Ng, et al.               Expires August 25, 2005                [Page 4]


Internet-Draft                 RO-Taxonomy                 February 2005


2.  Problem Statement of NEMO Route Optimization

   In essence, the goal of Route Optimization in NEMO is to reduce
   limitations, or sub-optimality, introduced by the bi-directional
   tunnel between a Mobile Router and its Home Agent (also known as the
   MR-HA tunnel).  In the following sub-sections, we will describe the
   effects of sub-optimal routing with NEMO Basic Support, and how they
   get amplified with nesting of mobile networks.  We will also look
   into the nesting of a Mobile IPv6 (MIPv6) host in a mobile network.
   In addition, we will explore the impact of MR-HA tunnel on
   communications between two Mobile Network Nodes (MNNs) on different
   links of the same mobile network.

   Readers might be interested to note the availability of [6] which
   also discusses the problem statement of NEMO Route Optimization.

2.1  Sub-Optimality with NEMO Basic Support

   With NEMO Basic Support, all packets sent between a Mobile Network
   Node and its Correspondent Node are forwarded through the MR-HA
   tunnel.  This results in a sub-optimal routing, also known as
   "dog-leg routing", with NEMO Basic Support.  This sub-optimality has
   the following undesirable effects:

   o  Longer route leading to increased delay

      Because a packet must transit from a mobile network to the Home
      Agent then to the Correspondent Node, the transit time of the
      packet is always higher than if the packet were to go straight
      from the mobile network to the Correspondent Node.  In the best
      case, where the Correspondent Node resides near the Home Agent,
      the increase in packet delay is minimal.  In the worst case, where
      both the mobile network and the Correspondent Node are located at
      a point furthest away from the Home Agent on the Internet, the
      increase in delay is tremendous.  Applications such as real-time
      multimedia streaming may not be able to tolerate such increase in
      packet delay.

   o  Increased packets overhead

      The encapsulation of packets in the MR-HA tunnel results in
      increased packet size due to addition of an outer packet.  This
      reduces the bandwidth efficiency, as IPv6 header can be quite
      substantial (at least 40 bytes).

   o  Increased processing delay

      The encapsulation of packets in the MR-HA tunnel also results in



Ng, et al.               Expires August 25, 2005                [Page 5]


Internet-Draft                 RO-Taxonomy                 February 2005


      increased processing delay at the points of encapsulation and
      decapsulation.

   o  Increased chances of packet fragmentation

      The increased in packet size due to packet encapsulation may
      increase the chances of the packet being fragmented along the
      MR-HA tunnel.  This can occur if there is no prior path MTU
      discovery conducted, or if the MTU discovery mechanism did not
      take into account the encapsulation of packets.  Packets
      fragmentation will result in a further increase in packet delays,
      and further reduction of bandwidth efficiency.


2.2  Nesting of Mobile Networks

   With nesting of mobile networks, the use of NEMO Basic Support
   further amplifies the sub-optimality of routing.  We call this the
   amplification effect of nesting, where the (undesirable) effects of
   sub-optimal routing with NEMO Basic Support are amplified with each
   level of nesting of mobile networks.  This is best illustrated by an
   example shown in Figure 1.

                                HAofMR1
                       +-----------|---------+
             HAofMR2 --|      Internet       |---CN
                       +---------------|-----+
                        /         Access Router
                   HAofMR3             |
                              ====?========
                                 MR1
                                  |
                    ====?===========?===========?===
                       MR5         MR2         MR6
                        |           |           |
                  ==|=======   ===?======    ======|==
                   LFN2          MR3             LFN3
                                  |
                            ==|=========?==
                             LFN1      MR4
                                        |
                                    =========

             Figure 1: An example of nested Mobile Network

   Using NEMO Basic Support, the flow of packets between a Local Fixed
   Node LFN1 and a Correspondent Node CN would need to go through three
   separate tunnels, illustrated in Figure 2 below.



Ng, et al.               Expires August 25, 2005                [Page 6]


Internet-Draft                 RO-Taxonomy                 February 2005


                               ----------.
                      --------/         /----------.
             -------/        |         |          /-------
   CN ------( -  - | -  -  - | -  -  - | -  -  - |  -  - (------- LFN
      HAofMR3-------\        |         |          \-------MR3
               HAofMR2--------\         \----------MR2
                         HAofMR1---------MR1

              Figure 2: Nesting of Bi-Directional Tunnels

   This leads to the following problems:

   o  'Pinball' routing

      Both inbound and outbound packets will flow via the HAs of all the
      MRs on their path within the NEMO, with increased latency, less
      resilience and more bandwidth usage.  To illustrate this effect,
      Figure 3 below shows the route taken by a packet sent from LFN1 to
      CN:

                   +--> HAofMR3 ---------------------+
                   |                                 |
                   +----------------- HAofMR2 <--+   |
                                                 |   |
                                 +---------------+   |
                                 |                   V
                              HAofMR1 <------+       CN
                                             |
                                             |
                   LFN1 --> MR3 --> MR2 --> MR1

                      Figure 3: 'Pinball' Routing

       For more illustration of the pinball routing, see [7].

   o  Increased Packet Size

      An extra IPv6 header is added per level of nesting to all the
      packets.  The header compression suggested in [8] cannot be
      applied because both the source and destination (the intermediate
      MR and its HA), are different hop to hop.










Ng, et al.               Expires August 25, 2005                [Page 7]


Internet-Draft                 RO-Taxonomy                 February 2005


2.3  MIPv6 Host in Mobile Networks

   When a MIPv6 mobile node joins a mobile network, it becomes a
   Visiting Mobile Node (VMN) of the mobile network.  Packets sent to
   and from the Visiting Mobile Node will have to be routed not only to
   the Home Agent of the Visiting Mobile Node, but also to the Home
   Agent of the Mobile Router in the mobile network.  This suffers the
   same amplification effect of nested Mobile Router mentioned in
   Section 2.2.

   In addition, although Mobile IPv6 [2] allows a mobile host to perform
   Route Optimization with its Correspondent Node to avoid tunneling
   with its Home Agent, the "optimized" route is no longer optimized
   when the mobile host is attached to a mobile network.  This is
   because the route between the mobile host and its Correspondent Node
   is subjected to the sub-optimality introduced by the MR-HA tunnel.
   Interested readers may refer to [7] for examples of how the routes
   will appear with nesting of MIPv6 hosts in mobile networks.


2.4  Communications within a Mobile Network

   The reliance on the MR-HA tunnel has its implications on MNNs in a
   nested mobile network communicating with each other.  Let us consider
   the previous example illustrated in Figure 1.  Suppose LFN1 and LFN2
   are communicating with each other.  With NEMO Basic Support, a packet
   sent from LFN1 to LFN2 will follow the path of: LFN1 -> MR3 -> MR2 ->
   MR1 -> HAofMR1 -> HAofMR2 -> HAofMR3 -> HAofMR5 -> HAofMR1 -> MR1 ->
   MR5 -> LFN2.  A round-about trip indeed where the direct path would
   be LFN1 -> MR3 -> MR2 -> MR5 -> LFN2.

   The consequences of increase packet delay and packet size have been
   discussed in previous sub-sections.  Here, there is an additional
   effect that is undesirable: should MR1 loses its connection to the
   global Internet, LFN1 and LFN2 can no longer communicates with each
   other, even though the direct path from LFN1 to LFN2 is unaffected!















Ng, et al.               Expires August 25, 2005                [Page 8]


Internet-Draft                 RO-Taxonomy                 February 2005


3.  Benefits of NEMO Route Optimization

   To address the problems discussed in Section 2, one can incorporate
   Route Optimization into NEMO.  This is also known as the NEMO
   Extended Support.  Although a standardized NEMO Extended Support has
   yet to materialize, one can expect it to show some of the following
   benefits:

   o  Shorter Delay

      Route optimization involves the selection and utilization of a
      shorter (or faster) route to be taken for traffic between a Mobile
      Network Nodes and Correspondent Node.  Hence, Route Optimization
      should improve the latency of the data traffic between the two end
      nodes.  This may possibly in turn leads to better overall Quality
      of Services characteristics, such as reduced jitter and packet
      loss.

   o  Reduced Consumption of Overall Network Resources

      Through the selection of a shorter route, the total link
      utilization for all links used by traffic between the two end
      nodes should be much lower than that used if Route Optimization is
      not carried out.  This would result in a lighter network load with
      reduced congestion.

   o  Less Susceptibility to Link Failure

      If a link on the MR-HA path is disrupted, all traffic to and from
      the mobile network will be affected until IP routing recovers from
      the failure.  An optimized route would conceivably utilize a
      lesser number of links between the two end nodes.  Hence, the
      probability of a loss of connectivity due to a single point of
      failure at a link should be lower as compared to the longer
      non-optimized route.

   o  Greater Data Efficiency

      Depending on the actual solution for NEMO Extended Support, the
      data packets exchanged between the two end nodes may not require
      as many levels of encapsulation as required by NEMO Basic Support.
      This would mean less packet overheads, and higher data efficiency.
      In particular, avoiding packet fragmentation that may be induced
      by the multiple levels of tunneling is critical for end to end
      efficiency from the viewpoints of buffering and transport
      protocols.





Ng, et al.               Expires August 25, 2005                [Page 9]


Internet-Draft                 RO-Taxonomy                 February 2005


4.  Solution Space of NEMO Route Optimization

   There are multiple proposals for providing various forms of route
   optimizations for NEMO (see Appendix A).  In the following
   sub-sections, we describe the solution space of Route Optimization by
   listing different types of approach to Route Optimization.  Readers
   might be interested to take note of a Route Optimization model
   described in [9] which describes route optimization model based on
   the variations of tunnel end-points.

4.1  MR-to-CN Optimization

   o  Binding Update with Network Prefix

      A straight-forward approach to Route Optimization in NEMO is for
      the Mobile Router to attempt Route Optimization with Correspondent
      Node.  This can be viewed as a logical extension to NEMO Basic
      Support, where the Mobile Router would send binding updates
      containing one or more Mobile Network Prefix options to the
      Correspondent Node.  The Correspondent Node having received the
      binding update, can then set up a bi-directional tunnel with the
      Mobile Router at the current care-of address of the Mobile Router,
      and inject a route to its routing table so that packets destined
      for addresses in the mobile network prefix will be routed through
      the bi-directional tunnel.

      This approach is particularly useful when a lot of MNNs in a
      mobile network is communicating with a few corresponding nodes.
      In such cases, a single Binding Update can optimize the routes of
      many flows between the Correspondent Node and the MNNs.

   o  MR as a Proxy

      A somewhat similar approach is for the Mobile Router to act as a
      "proxy" for the MNNs in its mobile network.  In this case, The MR
      uses standard MIPv6 Route Optimization procedure to bind the
      address of a MNN to its care-of address.  This has the advantage
      of keeping the implementations of MNNs and correspondent nodes
      unchanged.


4.2  Infrastructure Optimization

   There are two known approaches to achieve infrastructure
   optimization.  The first approach involves the introduction of an
   entity known as a correspondent-side router (C-side Router), or
   sometimes known simply as a Correspondent Router (CR) within the
   routing infrastructure.  As long as the Correspondent Router is



Ng, et al.               Expires August 25, 2005               [Page 10]


Internet-Draft                 RO-Taxonomy                 February 2005


   located "closer" to the Correspondent Node than the Home Agent of the
   Mobile Router, the route between MNN and the Correspondent Node can
   be said to have optimized.  This is illustrated in Figure 4.

               ************************** HAofMR
             *                            #*#
           *                            #*#     +---------------------+
         CN                           #*#       |       LEGEND        |
           o                        #*#         +---------------------+
            o   ###############   #*#           | #: Tunnel           |
             CR ooooooooooooooo MR              | *: NEMO Basic route |
                ###############  |              | o: Optimized route  |
                                MNN             +---------------------+

                 Figure 4: Infrastructure Optimization

   This form of optimization can take place independently for the 2
   directions of the traffic:

   o  From MNN to CN

      The Mobile Router locates the Correspondent Router, establishes a
      tunnel with that correspondent router and sets a route to the
      Correspondent Node via the Correspondent Router over the tunnel.
      After this, traffic to the Correspondent Node does not flow
      through the Home Agent anymore.

   o  From CN to MNN

      The Correspondent Router is on the path of the traffic from the
      Correspondent Node to the Home Agent.  In addition, it has an
      established tunnel with the current care-of address of the Mobile
      Router and is aware of the mobile network prefix(es) managed by
      the Mobile Router.  The Correspondent Router can thus intercept
      packets going to the mobile network, and forward them to the
      Mobile Router over the established tunnel.

   The advantage of this approach is that no additional functionality is
   required for the Correspondent Node and Mobile Network Nodes.

   The second approach is to have optimizations carried out fully in
   infrastructure.  One example is to make use of mobile anchor points
   (MAP) in HMIPv6 [10] to optimize routes between themselves.  Another
   example is to make use of the global HAHA protocol [11].  In this
   case, proxy Home Agents are distributed in the infrastructure and
   Mobile Routers bind to the closest proxy.  The proxy performs, in
   turn, a primary binding with a real Home Agent for that Mobile
   Router.  Then, the proxy might establish secondary bindings with



Ng, et al.               Expires August 25, 2005               [Page 11]


Internet-Draft                 RO-Taxonomy                 February 2005


   other Home Agents or proxies in the infrastructure, in order to
   improve the end-to-end path.  In this case, the proxies discover each
   other, establish a tunnel and exchange the relevant mobile network
   prefix information in the form of explicit prefix routes.  There is
   no need for return routability test or its like since the security is
   built in the infrastructure, one way or an other, and the proxies
   belong to the infrastructure.

4.3  Nested Tunnels Optimization

   Nested tunnels optimization is targeted at nested mobile networks,
   where there will be multiple levels of MR-HA tunnels with NEMO Basic
   Support.  Such a solution will seek to minimize the number of
   tunnels, possibly by collapsing the amount of tunnels required
   through some form of signaling between Mobile Routers, or between
   Mobile Routers and their Home Agents.  This limits the consequences
   of the amplification effect of tunnel nesting, and at best, the
   performance of a nested mobile network will be the same as though
   there were no nesting of mobile networks.

   There have been various proposals on nested tunnels optimization, and
   we can model them according to:

   o  Sending Information of Upstream Mobile Routers

      This involves sending information on upstream Mobile Router(s) to
      the Home Agent of a nested Mobile Router, thereby enabling the
      Home Agent to forward tunneled packets directly to the nested
      Mobile Router via the upstream Mobile Router(s), skipping the Home
      Agents of upstream Mobile Router(s).  This usually involves the
      use of a routing header to route packets through the upstream
      Mobile Router(s).

      The information of upstream Mobile Router (for simplicity, we
      refer to it as "upstream information") may contain information on
      the entire chain of upstream Mobile Routers, or it may only
      contain information on the immediate parent mobile router.  For
      the former, the Home Agent can build a multihop routing header
      from a single transmission of the information.  For the latter,
      each upstream mobile router may have to send Binding Update to the
      Home Agent of the nested Mobile Router, thereby enabling the Home
      Agent of the nested Mobile Router to build a multihop routing
      header recursively.

   o  Prefix Delegation

      An alternative approach to nested tunnels optimization is to use
      prefix delegation.  Here, each Mobile Router in a nested mobile



Ng, et al.               Expires August 25, 2005               [Page 12]


Internet-Draft                 RO-Taxonomy                 February 2005


      network is delegated a mobile network prefix from the access
      router using DHCP Prefix Delegation [12].  Each Mobile Router also
      autoconfigures its care-of address from this delegated prefix.  In
      this way, the care-of addresses of each Mobile Router are all from
      an aggregatable address space starting from the access router.
      This may be used to eliminate any nesting of tunnels.  It may also
      be used to achieve MIPv6-over-NEMO optimization (see Section 4.4)
      if MIPv6 hosts autoconfigure their care-of addresses from the
      prefix as well.

   o  Mobile Home

      This model applies to a category of problems where the mobile
      networks share a same administration and consistently move
      together (e.g.  a fleet at sea).  In this model, there is a
      cascade of Home Agents.  The main Home Agent is fixed in the
      infrastructure, and advertises an aggregated view of all the
      mobile networks.  This aggregation is actually divided over a
      number of mobile routers, the root-MRs.  The root-MRs subdivide
      some of their address space to the other Mobile Routers forming
      their fleet, for which they are Home Agent.  As Home Agents, the
      root-MRs terminate tunnels from the inside of the mobile network.
      As Mobile Router, they also terminate their home tunnels.  As
      routers, they forward packets between the 2 tunnels.

   o  MANET Routing

      It is possible for nodes within a mobile network to use MANET
      routing for packets forwarding between nodes in the same mobile
      network.  An approach of doing so might involves a router acting
      as a gateway for connecting nodes in the mobile network to the
      global Internet.  All nodes in the mobile network would configure
      their care-of addresses from a prefix advertised by that gateway.
      Packets are transferred between the gateway and other Mobile
      Network Nodes using MANET routing.  Such a gateway may be the
      top-level Mobile Router, or a fixed access router.


4.4  MIPv6-over-NEMO Optimization

   MIPv6-over-NEMO optimization involves providing optimization for a
   Visiting Mobile Node within a mobile network.  There are two aspects
   to MIPv6-over-NEMO optimization:

   o  Nested Tunnels

      This aims to reduce the amplification effect of nested tunnels due
      to the nesting of the tunnel between the Visiting Mobile Node and



Ng, et al.               Expires August 25, 2005               [Page 13]


Internet-Draft                 RO-Taxonomy                 February 2005


      its Home Agent within the tunnel between the Mobile Router of the
      mobile network and the Home Agent of the Mobile Router.

      This is very similar to "Nested Tunnels Optimization" described in
      Section 4.3.  Thus, a possible approach is to extend the solution
      for nested tunnels optimization to Visiting Mobile Node as well.

   o  MIPv6 Route Optimization

      This aims to remove the sub-optimality of a MR-HA tunnel from the
      MIPv6 Route Optimization established between a Visiting Mobile
      Node and Correspondent Node.  One approach is to simply extend the
      solution for nested tunnels optimization to Correspondent Node.
      Another (arguably "evil") approach is for the Mobile Router to
      "play some trick" to the MIPv6 Route Optimization, such as
      altering messages exchanged during the return routability
      procedure between the Visiting Mobile Node and Correspondent Node,
      so that packets sent from Correspondent Node to the Visiting
      Mobile Node will be routed to the care-of address of the Mobile
      Router once Route Optimization is established (see Section 4.1:
      "MR as a Proxy").  Alternatively, the Mobile Router can perform
      return routability procedure on behalf of the Visiting Mobile
      Node.  This would most likely require some signaling protocol
      between the Visiting Mobile Node and the Mobile Router, but may be
      able to keep the functionality of the Correspondent Node
      unchanged.


4.5  Intra-NEMO Optimization

   A Route Optimization solution may seek to improve the communications
   between two Mobile Network Nodes within a nested mobile network.  An
   example will be the optimization of packets route taken between LFN1
   and LFN2 of Figure 1.

   One may be able to extend a well-designed solution for MR-to-CN
   optimization to provide Intra-NEMO optimization, where, for example
   in Figure 1, LFN1 is treated as a Correspondent Node in the view of
   MR5, and LFN2 is treated as a Correspondent Node in the view of MR3.

   Another possibility is for the infrastructure optimization technique
   to be applied here.  Using the same example of communication between
   LFN1 and LFN2, MR3 may treat MR5 as a Correspondent Router for LFN2,
   and MR5 treats MR3 as a Correspondent Router for LFN1.

   Yet a different approach would be the use of MANET routing within a
   mobile network, as described in Section 4.3.  In such an approach,
   the Mobile Routers expose their Mobile Network Prefix over a



Ng, et al.               Expires August 25, 2005               [Page 14]


Internet-Draft                 RO-Taxonomy                 February 2005


   prefix-enabled MANET protocol.  MANET based IP routing establishes
   the route between the LFNs within the same nested structure.

















































Ng, et al.               Expires August 25, 2005               [Page 15]


Internet-Draft                 RO-Taxonomy                 February 2005


5.  Issues of Route Optimization

   Although Route Optimization, or NEMO Extended Support, can bring
   benefits as described in previous section, it does so with some
   tradeoffs.  The actual type and degree of tradeoffs depend greatly on
   the solution; however, in general, one would expect the costs
   described in the following sub-sections to be incurred.

5.1  Additional Signaling Overhead

   The nodes involved in performing Route Optimization would be expected
   to exchange additional signaling information in order to establish
   Route Optimization.  The cost of such signaling may be high,
   depending on the actual solution.  Such a cost may scale to
   unacceptable height when the number of mobile network nodes and/or
   Correspondent Nodes is increased.

   This signaling overhead is often in the form of Binding Update sent
   to Home Agents or Correspondent Nodes.  One issue that may impact
   Route Optimization solution is known as the phenomenon of "Binding
   Update Storm".  This occurs when a change in point of attachment of
   the mobile networks is accompanied with a sudden burst of Binding
   Update messages being generated, resulting in temporary congestion,
   packet delays or even packet lost.

   There has been argument that Binding Update storm may not be as
   significant as it seems.  For instance, consider a mobile network
   where Mobile Network Nodes is receiving x video stream at 25 packets
   per seconds.  On the average, the mobile network is handling a total
   traffic of 25*x packets per second.  Assuming one Binding Update has
   to be sent for each video stream server, a change in point of
   attachment would result in at most 6*x signaling messages (if we
   include the return routability procedure messages and a binding
   acknowledgment).  Thus the signaling overhead is small compared to
   the normal data traffic that the mobile network is handling, and
   hence the effect of Binding Update storm is small.  On the other
   hand, if the normal data rate is small, the effect of Binding Update
   storm may have a greater impact.  From this discussion, it appears
   that the significance of Binding Update storm may depend on the
   application type (eg.  high or low data rate, tolerance on packets
   delay, etc).

   It is also possible to further moderate the effect of Binding Update
   Storm by having some sort of "exponential back-off" mechanism in
   place for the sending of binding updates.  Such a scheme aims to
   spread the burst of Binding Update transmissions over a longer period
   of time, thereby reducing possibility of congestion and packet drops.




Ng, et al.               Expires August 25, 2005               [Page 16]


Internet-Draft                 RO-Taxonomy                 February 2005


5.2  Increased Protocol Complexity

   Some nodes will be required to have additional functionalities in
   order to incorporate NEMO Extended Support.  This increases the node
   complexity.  It may not be feasible to implement new functionalities
   on legacy nodes.  If such nodes are mobile, this may prove to be a
   significant cost     due to the limited memory resources such devices
   usually have.

   Coupled with the increased in protocol complexity, nodes that are
   involved in the establishment and maintenance of Route Optimization
   will have to bear increased processing load.  If such nodes are
   mobile, this may prove to be a significant cost due to the limited
   power and processing resources such devices usually have.

5.3  Mobility Awareness

   One advantage of NEMO Basic Support is that the Correspondent Nodes
   and mobile network nodes need not be aware of the actual location and
   mobility of the mobile network.  With Route Optimization, it might be
   necessary to reveal the current care-of address and any change of
   point of attachment of the Mobile Router to other nodes, such as the
   Mobile Network Nodes or Correspondent Node.  This may mean a tradeoff
   between location privacy and Route Optimization.  In MIPv6, the
   mobile node can decide whether or not to perform Route Optimization
   with a given Correspondent Node.  Thus, the mobile node is in control
   of whether to trade location privacy for an optimized route.  It will
   be desirable that such control is also available in a route optimized
   solution of NEMO should the solution contain the same tradeoff.
   However, for solutions where Route Optimization decision is made by
   Mobile Router, it will be difficult for Mobile Network Nodes to
   control the decision of having this tradeoff.

5.4  New Functionalities

   All Route Optimization approaches require some sort of new
   functionalities be implemented on some nodes.  In general, it is
   desirable to keep the number of nodes that require new
   functionalities as small as possible.  This allows for easier
   adoption of the solution, and also creates less impact on the
   existing infrastructure.

   In addition, if Route Optimization solution requires new
   functionalities on the part of some other nodes other than nodes
   within the mobile network, a mechanism for other nodes (such as
   Mobile Router) to detect if support for the new functionalities are
   available should also be provided.  Furthermore, it is desirable for
   there to be a graceful fall back procedure the required



Ng, et al.               Expires August 25, 2005               [Page 17]


Internet-Draft                 RO-Taxonomy                 February 2005


   functionalities are unavailable.

   Possible nodes that are required to be changed includes:

   o  Local Fixed Nodes

      It is generally undesirable to affect local fixed nodes.  However,
      some approaches require Mobile Network Nodes to implement new
      functionalities to enjoy benefits of route optimizations.

   o  Visiting Mobile Nodes

      Visiting mobile nodes in general should already have implemented
      MIPv6 functionalities, and since MIPv6 is a relatively new
      standard, there is still a considerable window to allow mobile
      devices to implement new functionalities.

   o  Mobile Routers

      It is expected for Mobile Routers to implement new functionalities
      in order to enable route optimizations.

   o  Access Routers

      Some approaches require access routers, or nodes in the access
      network to implement some new functionalities.  A clear example
      will be prefix delegation approach.

   o  Home Agents

      Although it is likely that vendors and operators would not mind
      having new functionalities in Home Agents, few route optimizations
      approaches would impact the Home Agents.

   o  Correspondent Nodes

      It is generally undesirable for Correspondent Nodes to be required
      to implement new functionalities.

   o  Correspondent Routers

      Correspondent Routers are new entity to be deployed in the
      infrastructure.  Such addition would generally cause the least
      disruption to the existing routing infrastructure.







Ng, et al.               Expires August 25, 2005               [Page 18]


Internet-Draft                 RO-Taxonomy                 February 2005


5.5  Other Considerations

   There are other considerations when analyzing the Route Optimization
   solution space.  These may not be a 'tradeoff" so to speak, but are
   beneficial to keep in mind when considering a Route Optimization
   solutions.

   o  Compatibility with NEMO Basic Support

      It will be beneficial to vendors if a route optimized solution for
      NEMO is compatible with NEMO Basic Support.  This reduces the
      complexity and achieves greater reuse of existing functionalities.

   o  In-Plane Signaling versus Off-Plane Signaling

      There is also considerations of whether Route Optimization
      signaling should be done in-plane and off-plane.  In-plane
      signaling involves embedding signaling information into headers of
      data packets (a good example would be the Reverse Routing Header
      [13]).  Off-plane signaling involves separating the signaling
      packets from the data packets.  Most proposals involving sending
      of binding updates fall within this category.





























Ng, et al.               Expires August 25, 2005               [Page 19]


Internet-Draft                 RO-Taxonomy                 February 2005


6.  Analysis of Solution Space

   Many of the tradeoffs discussed previously in Section 5 are dependent
   on the actual Route Optimization approach.  In the following
   sub-sections, we will explore deeper into the issues involved in each
   specific type of Route Optimization approach.

6.1  MR-to-CN Optimization

   One approach of MR-to-CN optimization involves the Mobile Router
   sending binding update messages with mobile network prefix
   information to the Correspondent Node.  This raised several issues:

   o  Security Considerations

      With Mobile Router sending Binding Update containing network
      prefix information to Correspondent Node, there is a question on
      the additional risk imposed on the Correspondent Node.  Although
      return routability procedure allows the correspondent node to
      verify that the care-of and home addresses of the Mobile Router
      are indeed collocated, it does not allow the Correspondent Node to
      verify the validity of the network prefix.  If the Correspondent
      Node accepts the binding without verification, it will be exposed
      to a class of attacks where the attacker tricks the Correspondent
      Node into forwarding packets destined for a mobile network to the
      attacker.

      Hence, MR-to-CN optimization would most likely require an extended
      return routability procedure to be developed for Correspondent
      Node to authenticate the validity of the mobile network prefix.
      This require additional functionality on the correspondent node,
      and a mechanism must be provided for the Mobile Router to check if
      the correspondent node has such functionality implemented.

   o  Mobility Awareness

      By sending Binding Update with mobile network prefix to the
      Correspondent Node, the Mobile Router is effectively revealing the
      location and mobility of the mobile network to the Correspondent
      Node.  Hence this is a case of trading location privacy for Route
      Optimization.  However, since Route Optimization in this case is
      initiated by the Mobile Router, the Mobile Network Nodes may not
      have an influence to the decision of whether the tradeoff should
      be made.

   o  Binding Update Storm

      If the Mobile Network Nodes in a mobile network are communicating



Ng, et al.               Expires August 25, 2005               [Page 20]


Internet-Draft                 RO-Taxonomy                 February 2005


      with a lot of Correspondent Nodes, whenever the Mobile Router
      changes its point of attachment, it needs to send out a large
      number of binding updates to Correspondent Nodes.  This is further
      worsen by the fact that the Mobile Router has to perform the
      return routability procedure prior to sending binding updates.

   Another approach involves the Mobile Router acting as a proxy for
   MNNs behind it.  This has the following issues:

   o  Security Considerations

      Having the Mobile Router alters packets (such as inserting home
      address destination option and removing type 2 routing header)
      raise considerable security concerns.  Such a scheme may break
      existing IPSec protocols, and cause packets to be dropped.

   o  Complexity

      This also greatly increases the complexity of a Mobile Router, as
      it needs to look beyond the standard IPv6 headers for
      ingress/egress packets, and performs hacks appropriately.  The
      Mobile Router is also required to maintain some form of state
      information for each pair of MNN and CN, resulting in scaling
      issues.  This scheme also places all processing burden on the
      Mobile Router, which may be undesirable for mobile device with
      limited power and processing resources.

   o  Binding Update Storm

      Whenever the Mobile Router changes its point of attachment, it
      needs to perform binding updates with every Correspondent Node.
      Some CN selection scheme may be required to moderate the effect of
      Binding Update storm and processing burden on the Mobile Router.

   o  A Hack of Existing Protocol

      There have been comments on the NEMO WG mailing list that such an
      approach is essentially a hack of the existing return routability
      procedure.  The disadvantages of it being a hack is that firstly a
      change/extension in the current return routability procedure would
      render this hack broken, and secondly, it might be very difficult
      to accommodate other protocols that are not aware of such hacks
      (IPSec being an excellent example).

   o  Nesting of Mobile Routers

      Should one Mobile Router be attached to another Mobile Router, it
      is unclear how this solution will work if both Mobile Routers try



Ng, et al.               Expires August 25, 2005               [Page 21]


Internet-Draft                 RO-Taxonomy                 February 2005


      to perform Route Optimization on behalf of the same Mobile Network
      Nodes.  Using Figure 1 as an example, if MR5 perform Route
      Optimization on behalf of LFN2, and then MR1 again tries to act as
      a proxy to MR5, the results might be messy without any
      co-ordination between these Mobile Routers.


6.2  Infrastructure Optimization

   An infrastructure optimization approach using correspondent routers
   may face the following issues:

   o  Security Considerations

      The first security-related issue is how do the Mobile Router
      verify the validity of a Correspondent Router.  In other words,
      the Mobile Router needs some mechanism to ascertain that the
      Correspondent Router is indeed a valid correspondent router
      capable of forwarding packets to and from the Correspondent Node.

      A second security-related issue is how can the Correspondent
      Router verify the validity of a Mobile Router.  In other words,
      the Correspondent Router needs some mechanism to ascertain that
      the Mobile Router is indeed managing the mobile network prefix it
      claims to be managing.  This is related to the issues discussed in
      Section 6.1.

   o  Mobility Awareness

      Infrastructure optimization requires the Correspondent Router to
      be informed of the location and mobility of the mobile network.
      Correspondent nodes and mobile network nodes remain ignorant of
      the mobile network's mobility.

   o  Discovery of Correspondent Routers

      How should a Mobile Router discover a Correspondent Router given a
      particular Correspondent Node?  The discovery mechanism may have
      impact on the security issue discussed earlier.


6.3  Nested Tunnels Optimization

   Nested tunnels optimization usually involves the nested Mobile Router
   sending information of upstream Mobile Router(s).

   o  Security Considerations




Ng, et al.               Expires August 25, 2005               [Page 22]


Internet-Draft                 RO-Taxonomy                 February 2005


      One issue for consideration is whether the Home Agent should trust
      the upstream information supplied by the nested Mobile Router.  If
      the upstream information falsely points to a victim node, the Home
      Agent may unconsciously flood the victim with packets intended for
      the nested mobile network.

      This risk can be minimized if the upstream information is
      protected by security association between the nested Mobile Router
      and its Home Agent (e.g.  the upstream information may be
      transmitted in a Binding Update that is protected from tampering).
      However, this does not protect against a malicious Mobile Router
      intentionally supplying false upstream information to its Home
      Agent, with the intent of launching a flooding attack against a
      victim node.

   o  Mobility Awareness

      Usually, nested tunnels optimization involves the nested Mobile
      Router sending upstream information to its Home Agent.  This
      implies that the upstream Mobile Router will have to reveal some
      information to sub-Mobile Routers.  Such information may reveal
      the location and mobility of the upstream Mobile Router.

   o  Binding Update Storm

      Depending on the specifics of a solution for nested tunnels
      optimization, the upstream information may be the care-of address
      of the upstream Mobile Router.  This will leads to the a burst of
      Binding Update messages whenever an upstream Mobile Router changes
      its point of attachment, since all its sub-MRs must send binding
      updates to their Home Agents to update the new upstream
      information.

   o  Complexity

      Sending of upstream information for nested tunnels optimization
      requires the Home Agent to store the upstream information in order
      to build a routing header.  Complexity of the Home Agent is
      further increased if the upstream information is sent individually
      by all upstream Mobile Routers, requiring the Home Agent to
      recursively build a routing header.

   Alternatively, a prefix delegation approach may be used to achieve
   nested tunnel optimization by eliminating the need for nesting.  This
   approach may face the following issues:

   o  Protocol Complexity




Ng, et al.               Expires August 25, 2005               [Page 23]


Internet-Draft                 RO-Taxonomy                 February 2005


      This approach requires the access router (or some other entity
      within the access network)        to possess prefix delegation
      functionality, and also maintains information on what prefix is
      delegated to which node.

   o  Binding Update Storm

      A change in the point of attachment of the root Mobile Router will
      require every nested Mobile Router (and possibly Visiting Mobile
      Nodes) to change their care-of addresses and delegated prefixes.
      These will cause a burst of Binding Update and prefix delegation
      activities where every Mobile Routers and Visiting Mobile Nodes
      start sending binding updates to their Home Agents and possibly
      Correspondent Nodes.


6.4  MIPv6-over-NEMO Optimization

   If MIPv6 Route Optimization is not used, the optimization for
   MIPv6-over-NEMO is very similar to nested tunnels optimization, where
   the MIPv6 mobile node acts like a visiting Mobile Router.  The
   analysis of such optimization is thus similar to those discussed in
   Section 6.3, and hence will not be repeated here.  In this section,
   we explore the issues if MIPv6 Route Optimization is used.

   As described in Section 4.4, MIPv6-over-NEMO optimization can be
   achieved using various approaches.  One approach involves including
   upstream information (see nested tunnels optimization) in the Binding
   Update sent from the Visiting Mobile Node to the Correspondent Node.
   This approach has the following considerations:

   o  Security Considerations

      A security-related issue is how can the Correspondent Node verify
      the validity of the supplied upstream information.  See also
      Section 6.3.

   o  Mobility Awareness

      The Visiting Mobile Node will need to acquire the upstream
      information, most likely including the mobility and location
      information of the upstream Mobile Routers.

   On the other hand, the Mobile Router can perform some hacks on the
   return routability messages exchanged between the Visiting Mobile
   Node and Correspondent Node to achieve MIPv6-over-NEMO optimization.
   This, is generally undesirable due to:




Ng, et al.               Expires August 25, 2005               [Page 24]


Internet-Draft                 RO-Taxonomy                 February 2005


   o  Security Considerations

      Such a scheme may break existing security related protocols, as it
      requires the Mobile Router to make changes to contents of a packet
      that is not originated by the Mobile Router.

   Alternatively, the Mobile Router can perform return routability
   procedure on behalf of the Visiting Mobile Node.  Here the issues
   are:

   o  Security Considerations

      Such a scheme require the Visiting Mobile Node to place
      considerable trust on the Mobile Router, as the mobility
      management key is now transfered to the Mobile Router.

   o  Mobility Awareness

      This approach aims to keep the functionality of the Correspondent
      Node to be identical as those required by MIPv6 Route
      Optimization.  The expense will be that a new form of signaling
      between the Visiting Mobile Node and mobile router would most
      likely be required.

   o  Processing Burden

      This approach also increases the processing burden of the Mobile
      Router, as it needs to maintain information necessary for Route
      Optimization to work for every Correspondent Node that is
      communicating with each visiting mobile node.  This may not scale
      very well when one consider, for example, a train network, where
      there are hundreds of Visiting Mobile Nodes in one mobile network.


6.5  Intra-NEMO Optimization

   As mentioned in Section 4.5, it is likely that any MR-to-CN
   optimization may be able to fulfill the role of an intra-NEMO
   optimization.  Such solutions will face the same issues as described
   in Section 6.1, as well as the following:

   o  Reliance on Outside Infrastructure

      Most MR-to-CN optimization rely on the operations of Home Agent in
      one way or another.  For instance, the return routability
      procedure requires a Home Test (HoT) or Home Test Init (HoTI)
      messages be forwarded by the Home Agent.  This means that should
      the path to the Internet be broken, such optimization techniques



Ng, et al.               Expires August 25, 2005               [Page 25]


Internet-Draft                 RO-Taxonomy                 February 2005


      can no longer be used (and thus LFN1 can no longer communicates
      with LFN2 in the example of Figure 1).

















































Ng, et al.               Expires August 25, 2005               [Page 26]


Internet-Draft                 RO-Taxonomy                 February 2005


7.  Conclusion

   The problem space of Route Optimization in the NEMO context is
   multifold and can be split into several work areas.  It will be
   critical, though, that the solution to a given piece of the puzzle be
   compatible and integrate smoothly with the others.

   This memo explored into various problems of sub-optimality of NEMO
   Basic Support, and discussed different aspects of a route optimized
   solution in NEMO.  The intent of this document is to trigger fruitful
   discussions that in turn will enhance our common understanding of the
   Route Optimization problem and solution space.







































Ng, et al.               Expires August 25, 2005               [Page 27]


Internet-Draft                 RO-Taxonomy                 February 2005


8.  Acknowledgments

   The authors wish to thank: Greg Daley, Thierry Ernst, Erik Nordmark,
   T.J.  Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa
   and Patrick Wetterwald for their various contributions.  In addition,
   the authors would also like to extend their heart-felt gratitude to
   Marco Molteni, who was a co-author for the earlier versions of this
   document.

9.  References

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

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

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

   [4]   Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         Internet-Draft draft-ietf-nemo-terminology-02, October 2004.

   [5]   Ernst, T., "Network Mobility Support Goals and Requirements",
         Internet-Draft draft-ietf-nemo-requirements-03, October 2004.

   [6]   Zhao, F., "NEMO Route Optimization Problem Statement,
         Requirements and Evaluation  Considerations",
         Internet-Draft draft-zhao-nemo-ro-ps-00, October 2004.

   [7]   Ernst, T., "Route Optimization with Nested Correspondent
         Nodes", Internet-Draft draft-watari-nemo-nested-cn-00, October
         2004.

   [8]   Deering, S. and B. Zill, "Redundant Address Deletion when
         Encapsulating IPv6 in IPv6",
         Internet-Draft draft-deering-ipv6-encap-addr-deletion-00,
         November 2001.

   [9]   Na, J., "Generic Route Optimization Model for NEMO Extended
         Support", Internet-Draft draft-na-nemo-gen-ro-model-00, July
         2004.

   [10]  Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
         "Hierarchical Mobile IPv6 mobility management (HMIPv6)",
         Internet-Draft draft-ietf-mipshop-hmipv6-04, December 2004.




Ng, et al.               Expires August 25, 2005               [Page 28]


Internet-Draft                 RO-Taxonomy                 February 2005


   [11]  Thubert, P., "Global HA to HA protocol",
         Internet-Draft draft-thubert-nemo-global-haha-00, October 2004.

   [12]  Droms, R. and O. Troan, "IPv6 Prefix Options for DHCPv6",
         Internet-Draft draft-troan-dhcpv6-opt-prefix-delegation-01, May
         2002.

   [13]  Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
         its application to Mobile Networks",
         Internet-Draft draft-thubert-nemo-reverse-routing-header-05,
         June 2004.

   [14]  Ng, C., "Extending Return Routability Procedure for Network
         Prefix (RRNP)", Internet-Draft draft-ng-nemo-rrnp-00, October
         2004.

   [15]  Bernardos, C., Bagnulo, M. and M. Calderon, "MIRON: MIPv6 Route
         Optimization for NEMO", ASWN 2004,
         Online: http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf.

   [16]  Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization
         with Access Router Option",
         Internet-Draft draft-ng-nemo-access-router-option-01, July
         2004.

   [17]  Na, J., "Route Optimization Scheme based on Path Control
         Header", Internet-Draft draft-na-nemo-path-control-header-00,
         April 2004.

   [18]  Wakikawa, R., "Optimized Route Cache Protocol (ORC)",
         Internet-Draft draft-wakikawa-nemo-orc-01, November 2004.

   [19]  Na, J., "Secure Nested Tunnels Optimization using Nested Path
         Information", Internet-Draft draft-na-nemo-nested-path-info-00,
         September 2003.

   [20]  Kang, H., "Route Optimization for Mobile Network by Using
         Bi-directional Between Home  Agent and Top Level Mobile
         Router", Internet-Draft draft-hkang-nemo-ro-tlmr-00, June 2003.

   [21]  Ohnishi, H., "HMIP based Route optimization method in a mobile
         network", Internet-Draft draft-ohnishi-nemo-ro-hmip-00, October
         2003.

   [22]  Paakkonen, P. and J. Latvakoski, "Mobile Network Prefix
         Delegation extension for Mobile IPv6",
         Internet-Draft draft-paakkonen-nemo-prefix-delegation-00, March
         2003.



Ng, et al.               Expires August 25, 2005               [Page 29]


Internet-Draft                 RO-Taxonomy                 February 2005


   [23]  Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
         Internet-Draft draft-droms-nemo-dhcpv6-pd-01, February 2004.

   [24]  Lee, K., "Route Optimization for Mobile Nodes in Mobile Network
         based on Prefix  Delegation",
         Internet-Draft draft-leekj-nemo-ro-pd-02, February 2004.

   [25]  Jeong, J., "ND-Proxy based Route Optimization for Mobile Nodes
         in Mobile Network",
         Internet-Draft draft-jeong-nemo-ro-ndproxy-02, February 2004.

   [26]  Perera, E., "Extended Network Mobility Support",
         Internet-Draft draft-perera-nemo-extended-00, July 2003.


Authors' Addresses

   Chan-Wah Ng
   Panasonic Singapore Laboratories Pte Ltd
   Blk 1022 Tai Seng Ave #06-3530
   Tai Seng Industrial Estate
   Singapore  534415
   SG

   Phone: +65 65505420
   Email: cwng@psl.com.sg


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

   Email: pthubert@cisco.com


   Hiroyuki Ohnishi
   NTT network service systems laboratories, NTT cooperation
   9-11, Midori-Cho 3-Chome
   Musashino-shi
   Tokyo  180-8585
   JAPAN

   Email: ohnishi.hiroyuki@lab.ntt.co.jp





Ng, et al.               Expires August 25, 2005               [Page 30]


Internet-Draft                 RO-Taxonomy                 February 2005


   Paik, Eun Kyoung
   KT
   Portable Internet Team, Convergence Lab., KT
   17 Woomyeon-dong, Seocho-gu
   Seoul  137-792
   Korea

   Phone: +82-2-526-5233
   Fax:   +82-2-526-5200
   Email: euna@kt.co.kr
   URI:   http://mmlab.snu.ac.kr/~eun/








































Ng, et al.               Expires August 25, 2005               [Page 31]


Internet-Draft                 RO-Taxonomy                 February 2005


Appendix A.  Proposed Route Optimizations

   Here, we attempt to list the numerous proposed solutions according to
   the solution space defined in Section 4.  Although we made effort in
   listing all possible solutions, sincere apology is extended to
   authors of solutions that we might have missed out.

A.1  MR-to-CN Optimizations

   Most MR-to-CN optimizations proposals are implicitly achieved by
   sending mobile network prefixes to Correspondent Nodes.  The Return
   Routability procedure with Network Prefix (RRNP) [14] proposed an
   extension to return routability procedure for verifying the validity
   of mobile network prefixes.

   One approach that uses the Mobile Router as a proxy for establishing
   Route Optimization on behalf of Mobile Network Nodes can be found in
   [15].

   In addition, various nested tunnel optimizations proposals (see
   Appendix A.3) can also be extended to correspondent node, thus
   enabling the MR-to-CN optimizations.  Example includes the Reverse
   Routing Header (RRH) [13], Access Router Option (ARO) [16].

A.2  Infrastructure Optimizations

   All known infrastructure optimization proposals defines the entity
   known as correspondent router capable of terminating bi-directional
   tunnels from Mobile Routers on behalf of Correspondent Nodes, thereby
   achieving Route Optimization.  The difference between these proposals
   is mainly the way correspondent routers are discovered.  Proposals
   include:

   o  Path Control Header (PCH) [17]

      The PCH approach requires the Home Agent to piggyback a Path
      Control Header on the packet when forwarding packets arriving from
      a bi-directional tunnel to a Correspondent Node.  Because PCH is a
      hop-by-hop option header, all intermediate routers lying between
      the Home Agent and the Correspondent Node will inspect the PCH.
      If a Correspondent Router exists among these intermediate router,
      it can contact the Mobile Router (identified in the PCH) and
      establish a optimized tunnel with the Mobile Router.

   o  Optimized Routing Cache (ORC) [18]

      The ORC approach defines the functionality of a Correspondent
      Router able to terminate bi-directional tunnels from Mobile



Ng, et al.               Expires August 25, 2005               [Page 32]


Internet-Draft                 RO-Taxonomy                 February 2005


      Routers.  Mobile routers discover correspondent routers by sending
      a query message to a multicast address corresponding to "all
      Correspondent Router" address.  The query message contains the
      address of the Correspondent Node for which the Mobile Router
      wishes to send packets to.  The Correspondent Router managing the
      network within which the Correspondent Node resides will responds
      to this query.  The proposal also suggest Correspondent Router to
      inform Mobile Routers the prefix information of the network it is
      capable of managing, so that any other traffic flows that
      originate and end at the mobile network and the network the
      Correspondent Router is managing can also enjoy Route
      Optimization.


A.3  Nested Tunnel Optimizations

   Many proposed solutions for NEMO Extended Support targets the nested
   tunnel optimization.  Most of these involves sending of upstream
   information to the Home Agent of a nested Mobile Router, including

   o  Reverse Routing Header (RRH) [13]

      The RRH approach avoids the multiple encapsulation of the traffic
      but maintains the home tunnel of the first Mobile Router on the
      egress path.  The first Mobile Router on the way out (egress
      direction) encapsulates the packet over its reverse tunnel, using
      a form of Record Route header, the RRH.

      The upstream Mobile Routers simply swap their care-of address and
      the source of the packet, saving the original source in the RRH.
      The Home Agent transforms the RRH in a Routing Header to perform
      source routing across the nested mobile network, along the ingress
      path to the target Mobile Router.

   o  Access Router Option (ARO) [16]

      The ARO approach is somewhat similar to the RRH in that only the
      home tunnel of the first nested Mobile Router in the egress path
      is maintained.  This is done by having the nested Mobile Router to
      send an ARO       in Binding Update to inform its Home Agent the address
      of its access router (i.e.  an upstream Mobile Router).  Using
      this information, the Home Agent can build a Routing Header to
      source-route a packet to the nested Mobile Router within in a
      nested mobile network.  Upstream Mobile Routers can also send
      Binding Update messages to the Home Agent of the nested Mobile
      Router, thus allowing a complete routing header be built
      recursively by the Home Agent.




Ng, et al.               Expires August 25, 2005               [Page 33]


Internet-Draft                 RO-Taxonomy                 February 2005


   o  Nested Path Info (NPI) [19]

      The NPI approach is somewhat similar to the ARO approach, except
      that instead of sending only the home address of the upstream
      Mobile Router to its Home Agent, a nested Mobile Router send a
      nested information on the care-of addresses of all upstream Mobile
      Routers.  Using this information, the Home Agent can build a
      Routing Header to source-route a packet to the nested Mobile
      Router within in a nested mobile network.

   o  Top Level Mobile Router (TLMR) [20]

      In TLMR, each visiting Mobile Router obtains the address of the
      root-MR through router advertisement messages.  This information
      is passed to its Home Agent in a Binding Update message.  The
      visiting Mobile Router also registers with the root-MR.  With
      these registrations, the root-MR maintains a topology of the
      mobile network.  In addition, the root MR also establish tunnels
      with the Home Agents of every visiting Mobile Router.  This way,
      packet to and from each nested mobile network will be relayed
      through the root-MR, through an additional tunnel between the
      root-MR and the Home Agent of the nested mobile network.

   o  Hierarchical Mobile IP (HMIP) [21]

      This approach proposes an adaptation of HMIPv6 [10] for NEMO.
      Here, information on the root-MR (acting as a Mobile Anchor Point,
      MAP) is passed to nested Mobile Routers in the MAP option of a
      router advertisement.  Nested Mobile Routers then register their
      regional and local care-of address with the root-MR.  Packets are
      then transfered to and from a nested Mobile Router through two
      separate tunnels: one between the nested Mobile Router and the
      root-MR, the other between the root-MR and the Home Agent of the
      nested Mobile Router.

   Other approaches that does not really require the sending of upstream
   information to Home Agent includes:

   o  Prefix Delegation [22][23][24]

      The prefix delegation approach is somewhat to HMIPv6 what NEMO is
      to MIPv6.  The Access Router of the nested structure is both a
      NEMO Home Agent and a DHCP-PD server, for an aggregation that it
      owns and advertises to the infrastructure.  When visiting the
      nested structure, each Mobile Router is delegated a mobile network
      prefix from the access router using DHCP-Prefix Delegation.  The
      Mobile Router registers this delegated prefix to the access router
      that is acting as a NEMO Home Agent.  The Mobile Router also



Ng, et al.               Expires August 25, 2005               [Page 34]


Internet-Draft                 RO-Taxonomy                 February 2005


      autoconfigures an address from the delegated prefix and uses it as
      a care-of address to register its own mobile network prefix(es) to
      its own Home Agent using NEMO Basic Support.  It is possible for a
      Mobile Router to protect its own mobile network prefixes while
      advertising in the clear the local prefix for other Mobile Routers
      to roam into.  This allows a strict privacy of visited and
      visitors, and enables some specific policies in each Mobile
      Router.

   o  Neighbor Discovery Proxy (ND-Proxy) [25]

      The ND-Proxy approach achieves Route Optimization by having Mobile
      Routers to act as neighbor discovery proxy.  Mobile router will
      configure a care-of address from the network prefix advertised by
      its access router, and also relay this prefix to its subnets.  As
      ND-Proxy, Mobile Routers will also handle neighbor discovery on
      behalf of Visiting Mobile Nodes in its subnets.  As such, the
      entire mobile network and its access network forms a logical
      multilink subnet, thus eliminating any nesting.  This solution
      also lends itself well to achieve MIPv6-over-NEMO optimization.


A.4  MIPv6-over-NEMO Optimizations

   Some solutions proposed for nested tunnels optimization can be
   extended for MIPv6-over-NEMO optimization, including Access Router
   Option (ARO) [16], Top Level Mobile Router (TLMR) [20], Prefix
   Delegation approaches [22][23][24], and Neighbor Discovery Proxy
   (ND-Proxy) [25].  One solution that caters specifically for
   MIPv6-over-NEMO optimization is:

   o  Extended Network Mobility Support [26]

      This approach is somewhat similar to the Prefix Delegation in
      which the Mobile Router would obtain a prefix from its access
      network, and allows visiting mobile network nodes to autoconfigure
      their care-of addresses from this prefix.  By doing so, packets
      destined to any MIPv6 node within the mobile network will not go
      through the Home Agent of the Mobile Router, thereby achieving
      MIPv6-over-NEMO optimization.  This solution also allows the
      Mobile Router to act as Home Agent for local fixed nodes and local
      mobile nodes within the mobile network in an attempt to allow
      these nodes to achieve Route Optimization (using standard MIPv6
      techniques).







Ng, et al.               Expires August 25, 2005               [Page 35]


Internet-Draft                 RO-Taxonomy                 February 2005


A.5  Intra-NEMO Optimizations

   Currently, there are no proposals that specifically target intra-NEMO
   optimization, though as explained previously, most solutions that
   achieves MN-to-CN optimizations can also achieve intra-NEMO
   optimization.













































Ng, et al.               Expires August 25, 2005               [Page 36]


Internet-Draft                 RO-Taxonomy                 February 2005


Intellectual Property Statement

   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.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Ng, et al.               Expires August 25, 2005               [Page 37]