[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 4889

NEMO Working Group                                                 C. Ng
Internet-Draft                                  Panasonic Singapore Labs
Intended status: Informational                                   F. Zhao
Expires: March 19, 2007                                         UC Davis
                                                               M. Watari
                                                           KDDI R&D Labs
                                                              P. Thubert
                                                           Cisco Systems
                                                      September 15, 2006


      Network Mobility Route Optimization Solution Space Analysis
                  draft-ietf-nemo-ro-space-analysis-03

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on March 19, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).









Ng, et al.               Expires March 19, 2007                 [Page 1]

Internet-Draft           NEMO RO Space Analysis           September 2006


Abstract

   With current Network Mobility (NEMO) Basic Support, all
   communications to and from Mobile Network Nodes must go through the
   MRHA tunnel when the mobile network is away.  This results in
   increased length of packet route and increased packet delay in most
   cases.  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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Benefits of NEMO Route Optimization  . . . . . . . . . . . . .  5
   3.  Different Scenarios of NEMO Route Optimization . . . . . . . .  7
     3.1.  Non-Nested NEMO Route Optimization . . . . . . . . . . . .  7
     3.2.  Nested Mobility Optimization . . . . . . . . . . . . . . .  9
       3.2.1.  Decreasing the Number of Home Agents on the Path . . .  9
       3.2.2.  Decreasing the Number of Tunnels . . . . . . . . . . . 10
     3.3.  Infrastructure based Optimization  . . . . . . . . . . . . 10
     3.4.  Intra-NEMO Optimization  . . . . . . . . . . . . . . . . . 11
   4.  Issues of NEMO Route Optimization  . . . . . . . . . . . . . . 13
     4.1.  Additional Signaling Overhead  . . . . . . . . . . . . . . 13
     4.2.  Increased Protocol Complexity and Processing Load  . . . . 14
     4.3.  Increased Delay during Handoff . . . . . . . . . . . . . . 14
     4.4.  Extending Nodes with New Functionalities . . . . . . . . . 14
     4.5.  Detection of New Functionalities . . . . . . . . . . . . . 16
     4.6.  Scalability  . . . . . . . . . . . . . . . . . . . . . . . 16
     4.7.  Mobility Transparency  . . . . . . . . . . . . . . . . . . 16
     4.8.  Location Privacy . . . . . . . . . . . . . . . . . . . . . 16
     4.9.  Security Consideration . . . . . . . . . . . . . . . . . . 17
     4.10. Support of Legacy Nodes  . . . . . . . . . . . . . . . . . 17
   5.  Analysis of Solution Space . . . . . . . . . . . . . . . . . . 18
     5.1.  Which Entities are Involved? . . . . . . . . . . . . . . . 18
       5.1.1.  Mobile Network Node and Correspondent Node . . . . . . 18
       5.1.2.  Mobile Router and Correspondent Node . . . . . . . . . 19
       5.1.3.  Mobile Router and Correspondent Router . . . . . . . . 19
       5.1.4.  Entities in the Infrastructure . . . . . . . . . . . . 20
     5.2.  Who and When to Initiate Route Optimization? . . . . . . . 20
     5.3.  How to Detect Route Optimization Capability? . . . . . . . 21
     5.4.  How is the Address of Mobile Network Node Represented? . . 22
     5.5.  How is Mobile Network Node's Address Bound to Location?  . 22
       5.5.1.  Binding to the Location of Parent Mobile Router  . . . 23
       5.5.2.  Binding to a Sequence of Locations of Upstream
               Mobile Routers . . . . . . . . . . . . . . . . . . . . 25



Ng, et al.               Expires March 19, 2007                 [Page 2]

Internet-Draft           NEMO RO Space Analysis           September 2006


       5.5.3.  Binding to the Location of Root Mobile Router  . . . . 26
     5.6.  How is Signaling Performed?  . . . . . . . . . . . . . . . 28
     5.7.  How is Data Transmitted? . . . . . . . . . . . . . . . . . 29
     5.8.  What are the Security Considerations?  . . . . . . . . . . 30
       5.8.1.  Security Considerations of Address Binding . . . . . . 30
       5.8.2.  End-to-End Integrity . . . . . . . . . . . . . . . . . 32
       5.8.3.  Location Privacy . . . . . . . . . . . . . . . . . . . 32
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 34
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 34
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 35
     10.2. Informative References . . . . . . . . . . . . . . . . . . 35
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 40
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
   Intellectual Property and Copyright Statements . . . . . . . . . . 43


































Ng, et al.               Expires March 19, 2007                 [Page 3]

Internet-Draft           NEMO RO Space Analysis           September 2006


1.  Introduction

   Network Mobility Route Optimization Problem Statement [1] describes
   operational limitations and overheads incurred in a deployment of
   Network Mobility (NEMO) Basic Support [2], which could be alleviated
   by a set of NEMO Route Optimization techniques to be defined.  For
   this purpose of NEMO, the term "Route Optimization" is accepted in a
   broader sense than already defined for IPv6 Host Mobility in [3], to
   loosely refer to any approach that optimizes the transmission of
   packets between a Mobile Network Node and a Correspondent Node.

   Solutions that would fit that general description were continuously
   proposed since the early days of NEMO, even before the Working Group
   was formed.  Based on that long standing stream of innovation, this
   document classifies, at a generic level, the solution space of the
   possible approaches that could be taken to solve the Route
   Optimization related problems for NEMO.  The scope of the solutions,
   the benefits, and the impacts to the existing implementations and
   deployments are analyzed.  This work should serve as a foundation for
   the NEMO WG to decide where to focus its Route Optimization effort,
   with a deeper understanding of the relative strength and weaknesses
   of each approach.

   It should be beneficial for readers to keep in mind the design
   requirements of NEMO [4].  A point to note is that since this
   document discusses aspects of Route Optimization, the reader 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.

1.1.  Terminology

   It is expected for readers to be familiar with terminologies related
   to mobility in [3] and [5], and NEMO related terms defined in [6].
   In addition, the following Route Optimization specific terms are used
   in this document:

   Correspondent Router (CR)

      This refers to the router which is capable of terminating a Route
      Optimization session on behalf of a Correspondent Node.

   Correspondent Entity (CE)

      This refers to the entity which a Mobile Router or Mobile Network
      Node attempts to establish a Route Optimization session with.
      Depending on the Route Optimization approach, the Correspondent
      Entity maybe a Correspondent Node or Correspondent Router.



Ng, et al.               Expires March 19, 2007                 [Page 4]

Internet-Draft           NEMO RO Space Analysis           September 2006


2.  Benefits of NEMO Route Optimization

   NEMO Route Optimization addresses the problems discussed in [1].
   Although a standardized NEMO Route Optimization solution 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
      lesser cost (thus generally shorter and faster) route to be taken
      for traffic between a Mobile Network Node and its Correspondent
      Node.  Hence, Route Optimization should improve the latency of the
      data traffic between the two end nodes.  This may possibly in turn
      lead to better overall Quality of Service 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  Reduced Susceptibility to Link Failure

      If a link along the bi-directional tunnel 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 smaller 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 Route Optimization, the
      data packets exchanged between two end nodes may not require as
      many levels of encapsulation as that in 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 March 19, 2007                 [Page 5]

Internet-Draft           NEMO RO Space Analysis           September 2006


   o  Reduced Processing Delay

      In a nested mobile network, the application of Route Optimization
      may eliminate the need of multiple encapsulations required by NEMO
      Basic Support, which may result in less processing delay at the
      points of encapsulation and decapsulation.

   o  Avoiding Bottleneck in the Home Network

      NEMO Route Optimization allows traffic to by-pass the Home Agents.
      Apart from having a more direct route, this also avoids routing
      traffic via the home network, which may be a potential bottleneck
      otherwise.

   o  Avoid the Security Policy Issue

      Security policy may forbid a Mobile Router from tunneling traffic
      of Visiting Mobile Nodes into the home network of the Mobile
      Router.  Route Optimization can be used to avoid this issue by
      forwarding traffic from Visiting Mobile Nodes directly to their
      destinations without going through the home network of the Mobile
      Router.

      It should however be taken into consideration that a Route
      Optimization mechanism may not be an appropriate solution since
      the Mobile Router may still be held responsible for illegal
      traffic sent from its Mobile Network Nodes even when Route
      Optimization is used.  In addition, there can be a variety of
      different policies which might conflict with the deployment of
      Route Optimization for Visiting Mobile Nodes.  Being a policy
      issue, solving this with a protocol at the policy plane might be
      more appropriate.

   o  Avoid the Instability and Stalemate

      [1] described a potential stalemate situation when a Home Agent is
      nested within a Mobile Network.  Route Optimization may circumvent
      such stalemate situations by directly forwarding traffic upstream.
      However, it should be noted that certain Route Optimization
      schemes may require signaling packets to be first routed via the
      Home Agent before an optimized route can be established.  In such
      cases, a Route Optimization solution cannot avoid the stalemate.









Ng, et al.               Expires March 19, 2007                 [Page 6]

Internet-Draft           NEMO RO Space Analysis           September 2006


3.  Different Scenarios of NEMO Route Optimization

   There are multiple proposals for providing various forms of Route
   Optimization in the NEMO context.  In the following sub-sections, we
   describe the different scenarios which would require a Route
   Optimization mechanism and list the potential solutions which have
   been proposed in that area.

3.1.  Non-Nested NEMO Route Optimization

   The Non-Nested NEMO Route Optimization involves a Mobile Router
   sending binding information to a Correspondent Entity.  It does not
   involve nesting of Mobile Routers nor Visiting Mobile Nodes.  The
   Correspondent Entity can be a Correspondent Node or a Correspondent
   Router.  The interesting case is when the Correspondent Entity is a
   Correspondent Router.  With the use of Correspondent Router, Route
   Optimization session is terminated at the Correspondent Router on
   behalf of the Correspondent Node.  As long as the Correspondent
   Router is located "closer" to the Correspondent Node than the Home
   Agent of the Mobile Router, the route between Mobile Network Node and
   the Correspondent Node can be said to be optimized.  For this
   purpose, Correspondent Routers may be deployed to provide an optimal
   route as illustrated in Figure 1.


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

                       Figure 1: MR-CR Optimization

   This form of optimization can carry traffic in both directions or
   independently for the 2 directions of traffic:

   o  From MNN to CN

      The Mobile Router locates the Correspondent Router, establishes a
      tunnel with that Correspondent Router and sets up a route to the
      Correspondent Node via the Correspondent Router over the tunnel.
      Traffic to the Correspondent Node would no longer flow through the
      Home Agent anymore.




Ng, et al.               Expires March 19, 2007                 [Page 7]

Internet-Draft           NEMO RO Space Analysis           September 2006


   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.

   A straight-forward approach to Route Optimization in NEMO is for the
   Mobile Router to attempt Route Optimization with a Correspondent
   Entity.  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 Entity.  The Correspondent Entity 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.

   The definition of Correspondent Router does not limit it to be a
   fixed router.  Here we consider the case where the Correspondent
   Router is a Mobile Router.  Thus Route Optimization is initiated and
   performed between a Mobile Router and its peer Mobile Router.  Such
   solutions are often posed with a requirement to leave the Mobile
   Network Nodes untouched, as with the NEMO Basic Support protocol, and
   therefore Mobile Routers handle the optimization management on behalf
   of the Mobile Network Nodes.  Thus, providing Route Optimization for
   Visiting Mobile Node is often out of scope for such scenario because
   such interaction would require extensions to the Mobile IPv6
   protocol.  This scenario is illustrated in Figure 2.


   HAofCR ********************************** HAofMR
     #*#                                     #*#
       #*#                                 #*#   +---------------------+
         #*#                             #*#     |       LEGEND        |
           #*#                         #*#       +---------------------+
             #*#   ###############   #*#         | #: Tunnel           |
                CR ooooooooooooooo MR            | *: NEMO Basic route |
                |  ###############  |            | o: Optimized route  |
               MNN2                MNN1          +---------------------+

                       Figure 2: MR-CR Optimization





Ng, et al.               Expires March 19, 2007                 [Page 8]

Internet-Draft           NEMO RO Space Analysis           September 2006


   This form of optimization can carry traffic for both directions
   identically:

   o  MNN1 to/from MNN2

      The Mobile Router locates the Correspondent Router, establishes a
      tunnel with that Correspondent Router and sets up a route to the
      Mobile Network Node via the Correspondent Router over the tunnel.
      Traffic to the Mobile Networks Nodes would no longer flow through
      the Home Agents.

   Examples of this approach include Optimized Route Cache (ORC) [7][8]
   and Path Control Header (PCH) [9].


3.2.  Nested Mobility Optimization

   Optimization in Nested Mobility targets scenarios where a nesting of
   mobility management protocols is created (i.e.  Mobile IPv6 enabled
   host inside a mobile network or multiple Mobile Routers that attach
   behind one another creating a nested mobile network).  Note that
   because Mobile IPv6 defines its own Route Optimization mechanism in
   its base protocol suite as a standard, collaboration between this and
   NEMO protocols brings various complexities.

   There are two main aspects in providing optimization for Nested
   Mobility and they are discussed in the following sub-sections.

3.2.1.  Decreasing the Number of Home Agents on the Path

   The aim is to remove the sub-optimality of paths caused by multiple
   tunnels established between multiple Mobile Nodes and their Home
   Agents.  Such a solution will seek to minimize the number of Home
   Agents along the path, by bypassing some of the Home Agent(s) from
   the original path.  Unlike the scenario where no nesting is formed
   and only a single Home Agent exists along the path, bypassing one of
   the many Home Agents can still be effective.

   Solutions for Nested Mobility scenarios can usually be divided into
   two cases based on whether the nesting involves Mobile IPv6 hosts or
   only involves Mobile Routers.  Since Mobile IPv6 defines its own
   Route Optimization mechanism, providing optimal path for such hosts
   will require interaction with the protocol and may require an
   altering of the messages exchanged during the Return Routability
   procedure with the Correspondent Node.

   Example of this approach include Reverse Routing Header (RRH) [10].




Ng, et al.               Expires March 19, 2007                 [Page 9]

Internet-Draft           NEMO RO Space Analysis           September 2006


3.2.2.  Decreasing the Number of Tunnels

   The aim is to reduce the amplification effect of nested tunnels due
   to the nesting of tunnels between the Visiting Mobile Node and its
   Home Agent within the tunnel between the parent Mobile Router and the
   parent Mobile Router's Home Agent.  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 Nodes,
   or between Mobile Nodes and their Home Agents, or by using routing
   headers to route packets through a discovered path.  These limit the
   consequences of the amplification effect of nested tunnels, and at
   best, the performance of a nested mobile network will be the same as
   though there were no nesting at all.

   Examples of this approach include the Reverse Routing Header (RRH)
   [10], Access Router Option (ARO) [11], and Nested Path Info (NPI)
   [12].


3.3.  Infrastructure based Optimization

   An infrastructure based optimization is an approach where
   optimization is carried out fully in the infrastructure.  One example
   is to make use of Mobility Anchor Points (MAP) such as defined in
   HMIPv6 [13] to optimize routes between themselves.  Another example
   is to make use of proxy Home Agent such as defined in the global HAHA
   protocol [14].  A proxy Home Agent acts as a Home Agent for the
   Mobile Node, and acts as a Mobile Node for the Home Agent,
   Correspondent Node, Correspondent Router, and other proxies.  In
   particular, the proxy Home Agent terminates the MRHA tunnel and the
   associated encryption, extracts the packets, and re-encapsulates them
   to the destination.  In this case, proxy Home Agents are distributed
   in the infrastructure and each Mobile Router binds to the closest
   proxy.  The proxy, in turn, performs a primary binding with a real
   Home Agent for that Mobile Router.  Then, the proxy might establish
   secondary bindings with 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 using some form of Next Hop
   Resolution Protocol, establish a tunnel and exchange the relevant
   mobile network prefix information in the form of explicit prefix
   routes.

   Alternatively, another approach is to use prefix delegation.  Here,
   each Mobile Router in a nested mobile network is delegated a mobile
   network prefix from the access router using DHCP Prefix Delegation
   [15].  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 formed from an aggregatable address space



Ng, et al.               Expires March 19, 2007                [Page 10]

Internet-Draft           NEMO RO Space Analysis           September 2006


   starting from the access router.  This may be used to eliminate the
   multiple tunnels caused by nesting of Mobile Nodes.


3.4.  Intra-NEMO Optimization

   A Route Optimization solution may seek to improve the communications
   between two Mobile Network Nodes within a nested mobile network.
   This would avoid traffic being injected out of the nested mobile
   network and route them within the nested mobile network.  An example
   will be the optimized route taken between MNN1 and MNN2 of Figure 3
   below.


                  +--------+  +--------+  +--------+  +--------+
                  | MR2_HA |  | MR3_HA |  | MR4_HA |  | MR5_HA |
                  +------+-+  +---+----+  +---+----+  +-+------+
                          \       |           |        /
           +--------+    +------------------------------+
           | MR1_HA |----|          Internet            |-----CN
           +--------+    +--------------+---------------+
                                        |
                                   +----+----+
                                   |   MR1   |
                                   +----+----+
                                        |
                         ---+-----------+-----------+---
                            |           |           |
                        +---+---+   +---+---+   +---+---+
                        |  MR5  |   |  MR2  |   |  MR4  |
                        +---+---+   +---+---+   +---+---+
                            |           |           |
                         ---+---    +---+---+    ---+---
                           MNN2     |  MR3  |      MNN3
                                    +---+---+
                                        |
                                    ----+----
                                       MNN1

               Figure 3: An example of nested Mobile Network


   One may be able to extend a well-designed NEMO Route Optimization for
   "Nested Mobility Optimization" (see Section 3.2) to provide for such
   kind of Intra-NEMO optimization, where, for example in Figure 3, MNN1
   is treated as a Correspondent Node by MR5/MNN2, and MNN2 is treated
   as a Correspondent Node by MR3/MNN1.




Ng, et al.               Expires March 19, 2007                [Page 11]

Internet-Draft           NEMO RO Space Analysis           September 2006


   Another possibility is for the "Non-Nested NEMO Route Optimization"
   technique (see Section 3.1) to be applied here.  Using the same
   example of communication between MNN1 and MNN2, both MR3 and MR2 can
   treat MR5 as Correspondent Routers for MNN2, and MR5 treats MR3 and
   MR2 as Correspondent Routers for MNN1.  An example of this approach
   is [16] which has the Mobile Routers announce their Mobile Network
   Prefixes to other Mobile Routers in the same nested Mobile Network.

   Yet another approach is to flatten any nested Mobile Network so that
   all nested Mobile Network Nodes appear to be virtually on the same
   link.  Examples of such approaches include delegating a single prefix
   to the nested Mobile Network, having Mobile Routers to perform
   Neighbor Discovery on behalf of their Mobile Network Nodes, and
   exposing a single prefix over the entire mobile network using a
   Mobile Ad-Hoc (MANET) protocol.  In particular, it might prove useful
   to develop a new type of MANET, specialized for the NEMO problem, a
   MANET for NEMO (MANEMO).  The MANEMO will optimize the formation of
   the nested NEMO and maintain inner connectivity, whether a connection
   to the infrastructure can be established or not.
































Ng, et al.               Expires March 19, 2007                [Page 12]

Internet-Draft           NEMO RO Space Analysis           September 2006


4.  Issues of NEMO Route Optimization

   Although Route Optimization can bring benefits as described in
   Section 2, the scenarios described in Section 3 do so with some
   tradeoffs.  This section explores some general issues that may impact
   a NEMO Route Optimization mechanism.

4.1.  Additional Signaling Overhead

   The nodes involved in performing Route Optimization would be expected
   to exchange additional signaling messages in order to establish Route
   Optimization.  The required amount of signaling depends on the
   solution, but is likely to exceed the amount required in the home
   binding update procedure defined in NEMO Basic Support.  The amount
   of signaling is likely to increase with the increasing number of
   Mobile Network Nodes and/or Correspondent Nodes, and may be amplified
   with nesting of mobile networks.  It may scale to unacceptable height
   especially to the resource-scarce mobile node which typically has
   limited power, memory and processing capacity.

   This may lead to an issue that impacts NEMO Route Optimization, known
   as the phenomenon of "Binding Update Storm", or more generally,
   "Signaling Storm".  This occurs when a change in point of attachment
   of the mobile network is accompanied with a sudden burst of signaling
   messages, resulting in temporary congestion, packet delays or even
   packet loss.  This effect will be especially significant for wireless
   environment where bandwidth is relatively limited.

   It is possible to moderate the effect of Signaling Storm by
   incorporating mechanisms such as spreading the transmissions burst of
   signaling messages over a longer period of time, or aggregating the
   signaling messages.

   Even so, the amount of signaling required might be overwhelming,
   since a large mobile network (such as those deployed on a train or
   plane) may potentially have a large number of flows with a large
   number of Correspondent Nodes.  This might suggest a need to have
   some adaptive behavior that depends on the amount of signaling
   required versus the effort needed to tunnel home.












Ng, et al.               Expires March 19, 2007                [Page 13]

Internet-Draft           NEMO RO Space Analysis           September 2006


4.2.  Increased Protocol Complexity and Processing Load

   It is expected for NEMO Route Optimization to be more complicated
   than NEMO Basic Support.  Thus, complexity of nodes that are required
   to incorporate new functionalities to support NEMO Route Optimization
   would be higher than those required to provide NEMO Basic Support.

   Coupled with the increased complexity, nodes that are involved in the
   establishment and maintenance of Route Optimization will have to bear
   the 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.


4.3.  Increased Delay during Handoff

   Due to the diversity of locations of different nodes that Mobile
   Network Node may signal with and the complexity of NEMO Route
   Optimization procedure that may cause several rounds of signaling
   messages, a NEMO Route Optimization procedure may take a longer time
   to finish its handoff than that in NEMO Basic Support.  This may
   exacerbate the overall delay during handoffs and further cause
   performance degradation of the applications running on Mobile Network
   Nodes.

   Another NEMO specific delay during handoff is that in a nested mobile
   network, a child Mobile Network Node may need to detect or be
   notified of the handoff of its parent Mobile Router so that it can
   begin signaling its own Correspondent Entities.  Apart from the
   compromise of mobility transparency and location privacy (see
   Section 4.7 and Section 4.8), this mechanism also increases the delay
   during handoffs.

   Some of the solutions for Mobile IPv6, such as Fast Handoff for
   Mobile IPv6 [17], may be able to alleviate the increase in handoff
   delay.


4.4.  Extending Nodes with New Functionalities

   In order to support NEMO Route Optimization, some nodes need to be
   changed or upgraded.  Smaller number of nodes required to be changed
   will allow for easier adoption of NEMO Route Optimization solution in
   the Internet and create less impact on existing Internet
   infrastructure.  The number and the types of nodes involved with new
   functionalities also affect how much of the route is optimized.  In
   addition, it may also be beneficial to reuse existing protocols (such
   as Mobile IPv6) as much as possible.



Ng, et al.               Expires March 19, 2007                [Page 14]

Internet-Draft           NEMO RO Space Analysis           September 2006


   Possible nodes that may be required to change include:

   o  Local Fixed Nodes

      It may prove to be difficult to introduce new functionalities at
      Local Fixed Nodes, since by definition, any IPv6 node can be a
      Local Fixed Node.  This might mean that only those Local Fixed
      Nodes that are modified can enjoy the benefits of Route
      Optimization.

   o  Visiting Mobile Nodes

      Visiting Mobile Nodes in general should already implement Mobile
      IPv6 functionalities, and since Mobile IPv6 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 support route optimization.

   o  Access Routers

      Some approaches require access routers, or nodes in the access
      network, to implement some new functionalities.  It may prove to
      be difficult to do so, since access routers, are in general,
      standard IPv6 routers.

   o  Home Agents

      It is relatively easier for new functionalities to be implemented
      in Home Agents.

   o  Correspondent Nodes

      It may prove to be difficult to introduce new functionalities at
      Correspondent Nodes, since by definition, any IPv6 node can be a
      Correspondent Node.  This might mean that only those Correspondent
      Nodes that are modified can enjoy the benefits of Route
      Optimization.

   o  Correspondent Routers

      Correspondent Routers are new entities introduced for the purpose
      of Route Optimization, and therefore new functionalities can be
      defined as needed.




Ng, et al.               Expires March 19, 2007                [Page 15]

Internet-Draft           NEMO RO Space Analysis           September 2006


4.5.  Detection of New Functionalities

   One issue that is related to the need for new functionalities as
   described in Section 4.4 is the need to detect the existence of such
   functionalities.  In these cases, a detection mechanism might be
   helpful to allow the initiator of Route Optimization to detect if
   support of the new functionalities are available.  Furthermore, it
   might be advantageous to have a graceful fall back procedure if the
   required functionalities are unavailable.


4.6.  Scalability

   Given the same number of nodes, the number of route optimization
   sessions would usually be more than the number of NEMO Basic Support
   tunnels.  If all route optimization sessions of a mobile network are
   maintained by a single node (such as the Mobile Router), this would
   means that the single node has to keep track of the states of all
   route optimization sessions.  This may leads to scalability issues
   especially when that single node is a mobile device with limited
   memory and processing resources.

   A similar scalability issue may be faced by Correspondent Entity as
   well if it maintains many route optimized sessions on behalf of
   Correspondent Node(s) with a large number of Mobile Routers.


4.7.  Mobility Transparency

   One advantage of NEMO Basic Support is that the Mobile Network Nodes
   need not be aware of the actual location and mobility of the mobile
   network.  With some approaches for Route Optimization, it might be
   necessary to reveal the point of attachment of the Mobile Router to
   the Mobile Network Nodes.  This may mean a tradeoff between mobility
   transparency and Route Optimization.


4.8.  Location Privacy

   Without Route Optimization, the Correspondent Nodes are not aware of
   the actual location and mobility of the mobile network and its Mobile
   Network Nodes.  To achieve Route Optimization, it might be necessary
   to reveal the point of attachment of the Mobile Router to the
   Correspondent Nodes.  This may mean a tradeoff between location
   privacy [18] and Route Optimization.

   In Mobile IPv6, a mobile node can decide whether or not to perform
   Route Optimization with a given Correspondent Node.  Thus, the mobile



Ng, et al.               Expires March 19, 2007                [Page 16]

Internet-Draft           NEMO RO Space Analysis           September 2006


   node is in control of whether to trade location privacy for an
   optimized route.  In NEMO Route Optimization, if the decision to
   perform Router Optimization is made by the Mobile Router, it will be
   difficult for Mobile Network Nodes to control the decision of having
   this tradeoff.


4.9.  Security Consideration

   As Mobile Router and Home Agent usually belong to the same
   administration domain, it is likely that there exists a security
   association between them, which is leveraged by NEMO Basic Support to
   conduct the home binding update in a secure way.  However, NEMO Route
   Optimization usually involves nodes from different domains (for
   example, Mobile Router and Correspondent Entity), thus the existence
   of such a security association is not a valid assumption in many
   deployment scenarios.  Thus the security protection of NEMO Route
   Optimization signaling message is considered as "weaker" than that in
   NEMO Basic Support.  It is expected that some additional security
   mechanisms are needed to achieve the same or similar level of
   security as in NEMO Basic Support.

   When considering security issues of NEMO Route Optimization, it might
   be useful to keep in mind some of the security issues considered when
   Mobile IPv6 Route Optimization was designed as documented in [19].

4.10.  Support of Legacy Nodes

   NEMO Basic Support is designed so that all legacy Mobile Network
   Nodes (such as those who are not aware of the mobility of the network
   they are in, and those that do not understand any mobility protocols)
   can still reach and be reached from the Internet.  Some Route
   Optimization schemes, however, require that all Mobile Routers to
   implement the same Route Optimization scheme in order for them to
   operate.  Thus, a nested Mobile Router may not be able to achieve
   Route Optimization if it is attached to a legacy Local Fixed Router.















Ng, et al.               Expires March 19, 2007                [Page 17]

Internet-Draft           NEMO RO Space Analysis           September 2006


5.  Analysis of Solution Space

   As described in Section 3, there are various different approaches to
   achieve Route Optimization in Network Mobility Support.  In this
   section, we attempt to analyze the vast solution space of NEMO Route
   optimization by asking the following questions:

   1.  Which entities are involved?

   2.  Who and when to initiate signaling?

   3.  How to detect Route Optimization capabilities?

   4.  How is the address of Mobile Network Node represented?

   5.  How is the address of Mobile Network Node bound to location of
       mobile network?

   6.  How is signaling performed?

   7.  How is data transmitted?

   8.  What are the security considerations?

5.1.  Which Entities are Involved?

   There are many combinations of entities involved in Route
   Optimization.  When considering the role each entity plays in Route
   Optimization, one has to bear in mind the considerations described in
   Section 4.4 and Section 4.5.  Below is a list of combinations to be
   discussed in the following subsections:

   o  Mobile Network Node and Correspondent Node

   o  Mobile Router and Correspondent Node

   o  Mobile Router and Correspondent Router

   o  Entities in the Infrastructure

5.1.1.  Mobile Network Node and Correspondent Node

   A Mobile Network Node can establish Route Optimization with its
   Correspondent Node, possibly the same way as a Mobile Node
   establishes Route Optimization with its Correspondent Node in Mobile
   IPv6.  This would achieve the most optimal route, since the entire
   end-to-end path is optimized.  However, there might be scalability
   issues since both the Mobile Network Node and the Correspondent Node



Ng, et al.               Expires March 19, 2007                [Page 18]

Internet-Draft           NEMO RO Space Analysis           September 2006


   may need to maintain many Route Optimization sessions.  In addition,
   new functionalities would be required for both the Mobile Network
   Node and Correspondent Node.  For the Mobile Network Node, it needs
   to be able to manage its mobility, and possibly be aware of the
   mobility of its upstream Mobile Router(s).  For the Correspondent
   Node, it needs to be able to maintain the bindings sent by the Mobile
   Network Nodes.

5.1.2.  Mobile Router and Correspondent Node

   Alternatively, the Mobile Router can establish Route Optimization
   with a Correspondent Node on behalf of the Mobile Network Node.
   Since all packets to and from the Mobile Network Node must transit
   the Mobile Router, this effectively achieves an optimal route for the
   entire end-to-end path as well.  Compared with Section 5.1.1, the
   scalability issue here may be remedied since it is possible for
   Correspondent Node to maintain only one session with the Mobile
   Router if it communicates with many Mobile Network Nodes associated
   with the same Mobile Router.  Furthermore, with the Mobile Router
   handling Route Optimization, there is no need for Mobile Network
   Nodes to implement new functionalities.  However, new functionality
   is likely to be required on the Correspondent Node.  An additional
   point of consideration is the amount of state information the Mobile
   Router is required to maintain.  Traditionally, it has been generally
   avoided to have state information in the routers to increase
   proportionally with the number of pairs of communicating peers.

5.1.3.  Mobile Router and Correspondent Router

   Approaches involving Mobile Routers and Correspondent Routers are
   described in Section 3.1.  The advantage of this approach is that no
   additional functionality is required for the Correspondent Node and
   Mobile Network Nodes.  In addition, location privacy is relatively
   preserved, since the current location of the mobile network is only
   revealed to the Correspondent Router and not to the Correspondent
   Node (please refer to Section 5.8.3 for more discussions).
   Furthermore, if the Mobile Router and Correspondent Router exchange
   prefix information, this approach may scale well since a single Route
   Optimization session between the Mobile Router and Correspondent
   Router can achieve Route Optimization between any Mobile Network Node
   in the mobile network, and any Correspondent Node managed by the
   Correspondent Router.

   The main concern with this approach is the need for a mechanism to
   allow the Mobile Router to detect the presence of the Correspondent
   Router (see Section 5.3 for details), and its security impact.  Both
   the Mobile Router and the Correspondent Router need some means to
   verify the validity of each other.  This is discussed in greater



Ng, et al.               Expires March 19, 2007                [Page 19]

Internet-Draft           NEMO RO Space Analysis           September 2006


   detail in Section 5.8.

   A deployment consideration with respect to the use of Correspondent
   Router is the location of the Correspondent Router relative to the
   Correspondent Node.  On one hand, deploying the Correspondent Router
   nearer to the Correspondent Node would result in a more optimal path.
   On the other hand, a Correspondent Router that is placed further away
   from the Correspondent Node can perform Route Optimization on behalf
   of more Correspondent Nodes.

5.1.4.  Entities in the Infrastructure

   Approaches using entities in the infrastructure are described in
   Section 3.3.  The advantages of this approach include firstly not
   requiring new functionalities to be implemented on the Mobile Network
   Nodes and Correspondent Nodes, and secondly having most of the
   complexity shifted to nodes in the infrastructure.  However, one main
   issue with this approach is how the Mobile Router can detect the
   presence of such entities, and why the Mobile Router should trust
   these entities.  This may be easily addressed if such entity is a
   Home Agent of the Mobile Router (such as in global HAHA [14]).
   Another concern is that the resulting path may not be a true
   optimized one, since it depends on the relative positions of the
   infrastructure entities with respect to the mobile network and the
   Correspondent Node.

5.2.  Who and When to Initiate Route Optimization?

   Having determined the entities involved in the Route Optimization in
   the previous sub-section, the next question is which of these
   entities should initiate the Route Optimization session.  Usually,
   the node that is moving (i.e.  Mobile Network Node or Mobile Router)
   is in the best position to detect its mobility.  Thus, in general, it
   is better for the mobile node to initiate the Route Optimization
   session in order to handle the topology changes in any kind of
   mobility pattern and achieve the optimized route promptly.  However,
   when the mobile node is within a nested mobile network, the detection
   of the mobility of upstream Mobile Routers may need to be conveyed to
   the nested Mobile Network Node.  This might incur longer signaling
   delay as discussed in Section 4.3.

   Some solution may enable the node on the correspondent side to
   initiate Route Optimization session in certain situations.  For
   instance, when the Route Optimization state that is already
   established on the Correspondent Entity is about to expire but the
   communication is still active, depending on the policy, the
   Correspondent Entity may initiate a Route Optimization request with
   the mobile node side.



Ng, et al.               Expires March 19, 2007                [Page 20]

Internet-Draft           NEMO RO Space Analysis           September 2006


   There is also the question of when Route Optimization should be
   initiated.  Because route optimization would certainly incur
   tradeoffs of various forms, it might not be desirable for Route
   Optimization to be performed for any kind of traffic.  This is,
   however, implementation specific and policy driven.

   A related question is how often signaling messages should be sent to
   maintain the Route Optimization session.  Typically, signaling
   messages is likely to be sent whenever there is topological changes.
   The discussion in Section 4.1 should be considered.  In addition, a
   Lifetime value is often used to indicate the period of validity for
   the Route Optimization session.  Signaling messages would have to be
   sent before the Lifetime value expires in order to maintain the Route
   Optimization session.  The choice of Lifetime value needs to balance
   between different considerations.  On one hand, a short Lifetime
   value would increase the amount of signaling overhead.  On the other
   hand, a long Lifetime value may expose the Correspondent Entity to
   the risk of having an obsolete binding cache entry, which creates an
   opportunity for an attacker to exploit.

5.3.  How to Detect Route Optimization Capability?

   The question here is how the initiator of Route Optimization knows if
   the Correspondent Entity supports the functionality required to
   established a Route Optimization session.  The usual method is for
   the initiator to attempt Route Optimization with the Correspondent
   Entity.  Depending on the protocol specifics, the initiator may
   receive (i) a reply from the Correspondent Entity indicating its
   capability, (ii) an error message from the Correspondent Entity, or
   (iii) no response from the Correspondent Entity within a certain time
   period.  This serves as an indication of whether the Correspondent
   Entity supports the required functionality to establish Route
   Optimization or not.  This form of detection may incur additional
   delay as a penalty when the Correspondent Entity does not have Route
   Optimization capability, especially when the Route Optimization
   mechanism is using in-band-signaling.

   When the Correspondent Entity is not the Correspondent Node but a
   Correspondent Router, an immediate question is how its presence can
   be detected.  One approach is for the initiator to send an Internet
   Control Message Protocol (ICMP) message containing the address of the
   Correspondent Node to a well-known anycast address reserved for all
   Correspondent Routers [7][8].  Only the Correspondent Router that is
   capable of terminating Route Optimization session on behalf of the
   Correspondent Node will respond.  Another way is to insert a Router
   Alert Option (RAO) to a packet sent to the Correspondent Node [9].
   Any Correspondent Router en route will process the Router Alert
   Option, and send a response to the Mobile Router.



Ng, et al.               Expires March 19, 2007                [Page 21]

Internet-Draft           NEMO RO Space Analysis           September 2006


   Both approaches need to consider the possibility of multiple
   Correspondent Routers responding to the initiator, and both
   approaches will generate additional traffic or processing load to
   other routers.  Furthermore, both approaches have yet to consider how
   the initiator can verify the authenticity of the Correspondent
   Routers that responded.

5.4.  How is the Address of Mobile Network Node Represented?

   Normally, Route Optimization would mean that a binding between the
   address of a Mobile Network Node and the location of the mobile
   network is registered at the Correspondent Entity.  Before exploring
   into different ways of binding (see Section 5.5), one must first ask
   how the address of the Mobile Network Node is represented.
   Basically, there are two ways to represent the Mobile Network Node's
   address:

   o  inferred by the use of the Mobile Network Prefix, or

   o  explicitly specifying the address of the Mobile Network Node.

   Using the Mobile Network Prefix would usually mean that the initiator
   is the Mobile Router, and has the benefit of binding numerous Mobile
   Network Nodes with one signaling.  However, it also means that if
   location privacy is compromised, the location privacy of an entire
   Mobile Network Prefix would be compromised.

   On the other hand, using the Mobile Network Node's address would mean
   that the initiator is either the Mobile Network Node itself, or the
   Mobile Router is initiating Route Optimization on behalf of the
   Mobile Network Node.  Initiation by the Mobile Network Node itself
   means that the Mobile Network Node must have new functionalities
   implemented, while initiation by the Mobile Router means that the
   Mobile Router must maintain some Route Optimization states for each
   Mobile Network Node.

5.5.  How is Mobile Network Node's Address Bound to Location?

   In order for route to be optimized, it is generally necessary for the
   Correspondent Entity to create a binding between the address and the
   location of the Mobile Network Node.  This can be done in the
   following ways:

   o  binding the address to the location of the parent Mobile Router;

   o  binding the address to a sequence of locations of upstream Mobile
      Routers; and




Ng, et al.               Expires March 19, 2007                [Page 22]

Internet-Draft           NEMO RO Space Analysis           September 2006


   o  binding the address to the location of the root Mobile Router

   These are described in the following sub-sections.

5.5.1.  Binding to the Location of Parent Mobile Router

   By binding the address of Mobile Network Node to the location of its
   parent Mobile Router, the Correspondent Entity would know how to
   reach the Mobile Network Node via the current location of the parent
   Mobile Router.  This can be done by:

   o  Binding Update with Mobile Network Prefix

      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 Entity.
      The Correspondent Entity 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 would be routed through the bi-directional
      tunnel.

      Note that in this case, the address of the Mobile Network Node is
      implied by the Mobile Network Prefix (see Section 5.4).

   o  Sending Information of Parent Mobile Router

      This involves the Mobile Network Node sending the information of
      its Mobile Router to the Correspondent Entity, thus allowing the
      Correspondent Entity to establish a binding between the address of
      the Mobile Network Node to the location of the parent Mobile
      Router.  An example of such an approach would be [11].

   o  Mobile Router as a Proxy

      Another approach is for the parent Mobile Router to act as a
      "proxy" for its Mobile Network Nodes.  In this case, the Mobile
      Router uses standard Mobile IPv6 Route Optimization procedure to
      bind the address of a Mobile Network Node to the Mobile Router's
      care-of address.  For instance, when the Mobile Network Node is a
      Local Fixed Node without Mobile IPv6 Route Optimization
      functionality, the Mobile Router may initiate the Return
      Routability procedure with a Correspondent Node on behalf of the
      Local Fixed Node.  An example of such an approach would be
      [20][21].

      On the other hand, if the Mobile Network Node is a Visiting Mobile



Ng, et al.               Expires March 19, 2007                [Page 23]

Internet-Draft           NEMO RO Space Analysis           September 2006


      Node, it might be necessary for the Visiting Mobile Node to
      delegate the rights of Route Optimization signaling to the Mobile
      Router (see [22] for an example of such delegation).  With this
      delegation, either the Visiting Mobile Network Node or the Mobile
      Router can initiate the Return Routability procedure with the
      Correspondent Node.  For the case where the Return Routability
      procedure is initiated by the Visiting Mobile Node, the Mobile
      Router will have to transparently alters content of the Return
      Routability signaling messages so that packets sent from the
      Correspondent Node to the Visiting Node will be routed to the
      care-of address of the Mobile Router once Route Optimization is
      established.  The case where the Return Routability procedure is
      initiated by the Mobile Router is similar to the case where the
      Mobile Network Node is a Local Fixed Node.

   For all of the approaches listed above, when the Mobile Network Node
   is deeply nested within a Mobile Network, the Correspondent Entity
   would need to gather Binding Updates from all the upstream Mobile
   Routers in order to build the complete route to reach the Mobile
   Network Node.  This increases the complexity of the Correspondent
   Entity, as the Correspondent Entity may need to perform multiple
   binding cache look-ups before it can construct the complete route.

   Other than increasing the complexity of the Correspondent Entity,
   these approaches may incur extra signaling overhead and delay for a
   nested Mobile Network Node.  For instance, every Mobile Router on the
   upstream of the Mobile Network Node needs to send Binding Updates to
   the Correspondent Entity.  If this is done by the upstream Mobile
   Routers independently, it may incur additional signaling overhead.
   Also, since each Binding Update takes a finite amount of time to
   reach and be processed by the Correspondent Entity, the delay from
   the time an optimized route is changed till the time the change is
   registered on the Correspondent Entity will increase proportionally
   with the number of Mobile Routers on the upstream of the Mobile
   Network Node (i.e. the level of nesting of the Mobile Network Node).

   For "Binding Update with Mobile Network Prefix" and "Sending
   Information of Upstream Mobile Router", new functionality is required
   at the Correspondent Entity, whereas "Mobile Router as a Proxy" keeps
   the functionality of the Correspondent Entity to be the same as a
   Mobile IPv6 Correspondent Node.  However, this is done at an expense
   of the Mobile Routers, since in "Mobile Router as a Proxy", the
   Mobile Router must maintain state information for every Route
   Optimization session its Mobile Network Nodes have.  Furthermore, in
   some cases, the Mobile Router needs to look beyond the standard IPv6
   headers for ingress and egress packets, and alter the packet contents
   appropriately.




Ng, et al.               Expires March 19, 2007                [Page 24]

Internet-Draft           NEMO RO Space Analysis           September 2006


   One advantage shared by all the approaches listed here is that only
   mobility protocol is affected.  In other words, no modification is
   required on other existing protocols (such as Neighbor Discovery).
   There is also no additional requirements on existing infrastructure
   (such as the access network).

   In addition, having upstream Mobile Routers send Binding Updates
   independently means that the Correspondent Entity can use the same
   binding cache entries of upstream Mobile Routers to construct the
   complete route to two Mobile Network Nodes that have common upstream
   Mobile Routers.  This may translate to lower memory consumption since
   the Correspondent Entity need not store one complete route per Mobile
   Network Node when it is having Route Optimizations sessions with
   multiple Mobile Network Nodes from the same mobile network.

5.5.2.  Binding to a Sequence of Locations of Upstream Mobile Routers

   For a nested Mobile Network Node, it might be more worthwhile to bind
   its address to the sequence of points of attachment of upstream
   Mobile Routers.  In this way, the Correspondent Entity can build a
   complete sequence of points of attachment from a single transmission
   of the binding information.  Examples using this approach are [10]
   and [12].

   Different from Section 5.5.1, this approach constructs the complete
   route to a specific Mobile Network Node at the mobile network side,
   thus offering the opportunity to reduce the signaling overhead.
   Since the complete route is conveyed to the Correspondent Entity in a
   single transmission, it is possible to reduce the delay from the time
   an optimized route is changed till the time the change is registered
   on the Correspondent Entity to its minimum.

   One question that immediately comes to mind is how the Mobile Network
   Node gets hold of the sequence of locations of its upstream Mobile
   Routers.  This is usually achieved by having such information
   inserted as special options in the Router Advertisement messages
   advertised by upstream Mobile Routers.  To do so, not only must a
   Mobile Router advertise its current location to its Mobile Network
   Nodes, it must also relay information embedded in Router
   Advertisement messages it has received from its upstream Mobile
   Routers.  This might imply a compromise of the mobility transparency
   of a mobile network (see Section 4.7).  In addition, it also means
   that whenever an upstream Mobile Router changes its point of
   attachment, all downstream Mobile Network Nodes must perform Route
   Optimization signaling again, possibly leading to a "signaling storm"
   (see Section 4.1).

   A different method of conveying locations of upstream Mobile Routers



Ng, et al.               Expires March 19, 2007                [Page 25]

Internet-Draft           NEMO RO Space Analysis           September 2006


   is used in [10] where upstream Mobile Routers insert their current
   point of attachment into a Reverse Routing Header embedded within a
   packet sent by the Mobile Network Node.  This may raise security
   concerns that will be discussed later in Section 5.8.2.


   In order for a Correspondent Entity to bind the address of a Mobile
   Network Node to a sequence of locations of upstream Mobile Routers,
   new functionalities need to be implemented on the Correspondent
   Entity.  The Correspondent Entity also needs to store the complete
   sequence of locations of upstream Mobile Routers for every Mobile
   Network Node.  This may demand more memory compared to Section 5.5.1
   if the same Correspondent Entity has a lot of Route Optimization
   sessions with Mobile Network Nodes from the same nested Mobile
   Network.  In addition, some amount of modifications or extension to
   existing protocols is also required, such as a new type of IPv6
   routing header, or a new option in Router Advertisement message.

5.5.3.  Binding to the Location of Root Mobile Router

   A third approach is to bind the address of the Mobile Network Node to
   the location of the root Mobile Router, regardless of how deeply
   nested the Mobile Network Node is within a nested Mobile Network.
   Whenever the Correspondent Entity needs to forward packet to the
   Mobile Network Node, it only needs to forward the packet to this
   point of attachment.  The mobile network will figure out how to
   forward the packet to the Mobile Network Node by itself.  This kind
   of approach can be viewed as flattening the structure of a nested
   Mobile Network, so that it seems to the Correspondent Entity that
   every node in the Mobile Network is attached to the Internet at the
   same network segment.

   There are various approaches to achieve this:

   o  Prefix Delegation

      Here, each Mobile Router in a nested mobile network is delegated a
      Mobile Network Prefix from the access router (such as using DHCP
      Prefix Delegation [15]).  Each Mobile Router also autoconfigures
      its care-of address from this delegated prefix.  In this way, the
      care-of addresses of Mobile Routers are all from an aggregatable
      address space starting from the access router.  Mobile Network
      Nodes with Mobile IPv6 functionality may also autoconfigure its
      care-of address from this delegated prefix, and use standard
      Mobile IPv6 mechanism to bind its home address to this care-of
      address.

      Examples of this approach includes [23] and [24][25].



Ng, et al.               Expires March 19, 2007                [Page 26]

Internet-Draft           NEMO RO Space Analysis           September 2006


      This approach has the advantage of keeping the implementations of
      Correspondent Nodes unchanged.  However, it requires the access
      router (or some other entity within the access network) and Mobile
      Router to possess prefix delegation functionality, and also
      maintain information on what prefix is delegated to which node.
      How to efficiently assign a subset of Mobile Network Prefix to
      child Mobile Routers could be an issue because Mobile Network
      Nodes may dynamically join and leave with an unpredictable
      pattern.  In addition, a change in the point of attachment of the
      root Mobile Router will also 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 Updates and prefix delegation activities where every
      Mobile Router and every Visiting Mobile Node start sending Binding
      Updates to their Correspondent Entities.

   o  Neighbor Discovery Proxy

      This approach (such as [26][27]) achieves Route Optimization by
      having Mobile Router to act as a Neighbor Discovery [28] proxy for
      its Mobile Network Nodes.  The 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.  When a Mobile
      Network Node configures an address from this prefix, the Mobile
      Router will act as a Neighbor Discovery proxy on its behalf.  In
      this way, the entire mobile network and its access network form a
      logical multilink subnet, thus eliminating any nesting.

      This approach has the advantage of keeping the implementations of
      Correspondent Nodes unchanged.  However, it requires the root
      Mobile Router to act as a Neighbor Discovery proxy for all the
      Mobile Network Nodes that are directly or indirectly attached to
      it.  This increases the processing load of the root Mobile Router.
      In addition, 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.
      Not only will this cause a burst of Binding Updates where every
      Mobile Router and every Visiting Mobile Node start sending Binding
      Updates to their Correspondent Entities, it will also cause a
      burst of Duplicate Address Discovery messages to be exchanged
      between the mobile network and the access network.  Furthermore,
      route optimization for Local Fixed Nodes is not possible without
      new functionalities implemented on the Local Fixed Nodes.

   o  Hierarchical Registrations

      Hierarchical Registration involves Mobile Network Nodes (including
      nested Mobile Routers) to register themselves with either their



Ng, et al.               Expires March 19, 2007                [Page 27]

Internet-Draft           NEMO RO Space Analysis           September 2006


      parent Mobile Routers, or the root Mobile Router itself.  After
      registrations, Mobile Network Nodes would tunnel packets directly
      to the upstream Mobile Router they register with.  At the root
      Mobile Router, packets tunneled from sub-Mobile Routers or Mobile
      Network Nodes are tunneled directly to the Correspondent Entities,
      thus avoiding nested tunneling.

      One form of such approach uses the principle of Hierarchical
      Mobile IPv6 [13], where the root Mobile Router acts as a Mobility
      Anchor Point.  It is also possible for each parent Mobile Router
      to act as Mobility Anchor Points for their child Mobile Routers,
      thus forming a hierarchy of Mobility Anchor Points.  One can also
      view these Mobility Anchor Points as local Home Agents, thus
      forming a cascade of mobile Home Agents.  In this way, each Mobile
      Router terminates its tunnel at its parent Mobile Router.  Hence,
      although there are equal number of tunnels as the level of
      nestings, there is no tunnel encapsulated within another.

      Examples of this approach includes [29], [30] and [31][32].

      An advantage of this approach is that the functionalities of the
      Correspondent Nodes are unchanged.

   o  Mobile Ad-Hoc Routing

      It is possible for nodes within a mobile network to use Mobile Ad-
      hoc routing for packet-forwarding between nodes in the same mobile
      network.  An approach of doing so might involve 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 one or more prefixes advertised by that
      gateway, while their parent Mobile Routers use Mobile Ad-hoc
      routing to forward packets to that gateway or other destinations
      inside the mobile network.

   One advantage that is common to all the approaches listed above is
   that local mobility of a Mobile Network Node within a nested Mobile
   Network is hidden from the Correspondent Entity.

5.6.  How is Signaling Performed?

   In general, Route Optimization signaling can be done either in-plane,
   off-plane, or both.  In-plane signaling involves embedding signaling
   information into headers of data packets.  A good example of in-plane
   signaling would be Reverse Routing Header [10].  Off-plane signaling
   uses dedicated signaling packets rather than embedding signaling
   information into headers of data packets.  Proposals involving the
   sending of Binding Updates fall into this category.



Ng, et al.               Expires March 19, 2007                [Page 28]

Internet-Draft           NEMO RO Space Analysis           September 2006


   The advantage of in-plane signaling is that any change in the mobile
   network topology can be rapidly propagated to the Correspondent
   Entity as long as there is a continuous stream of data to be
   transmitted.  However, this might incur a substantial overhead on the
   data packets.  Off-plane signaling, on the other hand, sends
   signaling messages independently from the data packet.  This has the
   advantage of reducing the signaling overhead in situations where
   there are relatively less topological changes to the mobile network.
   However, data packets transmission may be disrupted while off-plane
   signaling takes place.

   An entirely different method of signaling makes use of upper layer
   protocols to establish the bindings between the address of a Mobile
   Network Node and the location of the mobile network.  Such binding
   information can then be passed down to the IP layer to insert the
   appropriate entry in the Binding Cache or routing table.  An example
   of such mechanism is [33] which uses the Session Initiation Protocol
   (SIP) to relay binding information.

5.7.  How is Data Transmitted?

   With Route Optimization established, one remaining question to be
   answered is how data packets can be routed to follow the optimized
   route.  There are the following possible approaches:

   o  Encapsulations

      One way to route packets through the optimized path is to use IP-
      in-IP encapsulations [34].  In this way, the original packet can
      be tunneled to the location bound to the address of the Mobile
      Network Node using the normal routing infrastructure.  Depending
      on how the location is bound to the address of Mobile Network
      Node, the number of encapsulations required might vary.

      For instance, if the Correspondent Entity knows the full sequence
      of points of attachment, it might be necessary for there to be
      multiple encapsulations in order to forward the data packet
      through each point of attachment.  This may lead to the need for
      multiple tunnels and extra packet header overhead.  It is possible
      to alleviate this by using Robust Header Compression techniques
      [35][36] [37] to compress the multiple tunnel packet headers.

   o  Routing Headers

      A second way to route packets through the optimized path is to use
      routing headers.  This is useful especially for the case where the
      Correspondent Entity knows the sequence of locations of upstream
      Mobile Routers, (see Section 5.5.2), since a routing header can



Ng, et al.               Expires March 19, 2007                [Page 29]

Internet-Draft           NEMO RO Space Analysis           September 2006


      contain multiple intermediate destinations.  Each intermediate
      destination corresponds to a point of attachment bound to the
      address of the Mobile Network Node.

      This requires the use of a new Routing Header type, or possibly an
      extension of the Type 2 Routing Header as defined by Mobile IPv6
      to contain multiple addresses instead of only one.

   o  Routing Entries in Parent Mobile Routers

      Yet another way is for parent Mobile Routers to install routing
      entries in their routing table that will route Route Optimized
      packets differently, most likely based on source address routing.
      This usually applies to approaches described in Section 5.5.3.
      For instance, the Prefix Delegation approach [23][24][25] would
      require parent Mobile Routers to route packets differently if the
      source address belongs to the prefix delegated from the access
      network.

5.8.  What are the Security Considerations?

5.8.1.  Security Considerations of Address Binding

   The most important security consideration in Route Optimization is
   certainly the security risks a Correspondent Entity is exposed to by
   creating a binding between the address of a Mobile Network Node and
   the specified location(s) of the Mobile Network.  Generally, it is
   assumed that Correspondent Entity and Mobile Network Node do not
   share any pre-existing security association.  However, the
   Correspondent Entity must have some ways of verifying the
   authenticity of the binding specified, else it will be susceptible to
   various attacks described in [19], such as snooping (sending packets
   meant for a Mobile Network Node to an attacker) or denial-of-service
   (flooding a victim with packets meant for a Mobile Network Node)
   attacks.

   When the binding is performed between the address of the Mobile
   Network Node and one care-of address (possibly of the Mobile Router,
   see Section 5.5.1 and Section 5.5.3), the standard Return Routability
   procedure specified in Mobile IPv6 might be sufficient to provide a
   reasonable degree of assurance to the Correspondent Entity.  This
   also allows the Correspondent Entity to re-use existing
   implementations.  But in other situations, an extension to the Return
   Routability procedure might be necessary.

   For instance, consider the case where the Mobile Router sends Binding
   Update containing Mobile Network Prefix information to Correspondent
   Entity (see Section 5.5.1).  Although the Return Routability



Ng, et al.               Expires March 19, 2007                [Page 30]

Internet-Draft           NEMO RO Space Analysis           September 2006


   procedure allows the Correspondent Entity to verify that the care-of
   and home addresses of the Mobile Router are indeed collocated, it
   does not allow the Correspondent Entity to verify the validity of the
   Mobile Network Prefix.  If the Correspondent Entity accepts the
   binding without verification, it will be exposed to attacks where the
   attacker tricks the Correspondent Entity into forwarding packets
   destined for a mobile network to the attacker (snooping) or victim
   (DoS). [38] discusses this security threat further.

   The need to verify the validity of network prefixes is not
   constrained to Correspondent Entities.  In approaches that involve
   the Correspondent Routers (see Section 5.1.3), there have been
   suggestions for the Correspondent Router to advertise the network
   prefix(es) of Correspondent Nodes the Correspondent Router is capable
   of terminating Route Optimization on behalf of to Mobile Network
   Nodes.  In such cases, the Mobile Network Nodes also need a mechanism
   to check the authenticity of such claims.  Even if the Correspondent
   Routers do not advertise the network prefix, the Mobile Network Nodes
   also have the need to verify that the Correspondent Router is indeed
   a valid Correspondent Router for a given Correspondent Node.

   In Section 5.5.2, the signaling of Route Optimization involves
   sending the location of one or more upstream Mobile Routers.  The
   Correspondent Entity must also have the means to verify such
   information.  Again, the standard Return Routability procedure is
   inadequate here.  An extension such as attaching a routing header to
   the Care-of Test (CoT) message to verify the authenticity of the
   locations of upstream Mobile Routers is likely to be needed.  The
   risk, however, is not confined to the Correspondent Entities.  The
   Mobile Network Nodes are also under the threat of receiving false
   information from their upstream Mobile Routers, which they might pass
   to the Correspondent Entities.  There are some considerations that
   this kind of on-path threat exists in the current Internet anyway
   especially when no (or weak) end-to-end protection is used.

   All these concerns over the authenticity of addresses might suggest
   that perhaps a more radical and robust approach is necessary.  This
   is currently under extensive study in various Working Groups of the
   IETF, and many related documents might be of interest here.  For
   instance, in Securing Neighbor Discovery (SEND) [39], the use of
   Cryptographically Generated Addresses (CGA) [40] could be used to
   establish the ownership of care-of addresses and network prefixes.
   [41] employs the Home Agent to check the signaling messages sent by
   Mobile Routers to provide a way for Correspondent Entities to verify
   the authenticity of Mobile Network Prefixes specified. [42] documents
   various proposed enhancements to the Mobile IPv6 Route Optimization
   mechanism which might be applied to NEMO Route Optimization as well,
   such as [43] which allows the Correspondent Entity to authenticate a



Ng, et al.               Expires March 19, 2007                [Page 31]

Internet-Draft           NEMO RO Space Analysis           September 2006


   certain operator's Home Agent by verifying the associated
   certificate.  The Host Identity Protocol (HIP) [44] with end-host
   mobility considerations [45] may also be extended for NEMO Route
   Optimization as well.

   In addition, interested readers might want to refer to [46] that
   discussed the general problem of making Route Optimization in NEMO
   secure and explored some possible solution schemes.  There is also a
   proposed mechanism for Mobile Network Node to delegate some rights to
   their Mobile Routers in [22], which may be used to allow the Mobile
   Routers to prove their authenticities to Correspondent Entities when
   establishing Route Optimization sessions on behalf of the Mobile
   Network Nodes.

5.8.2.  End-to-End Integrity

   In some of the approaches, such as "Mobile Router as a Proxy" in
   Section 5.5.1, the Mobile Router sends messages using the Mobile
   Network Node's address as the source address.  This is done mainly to
   achieve zero new functionalities required at the Correspondent
   Entities and the Mobile Network Nodes.  However, adopting such a
   strategy may interfere with existing or future protocols, most
   particularly security-related protocols.  This is especially true
   when the Mobile Router needs to make changes to packets sent by
   Mobile Network Nodes.  In a sense, these approaches break the end-to-
   end integrity of packets.  A related concern is that this kind of
   approach may also require the Mobile Router to inspect into packet
   contents sent to/by Mobile Network Nodes.  This may prove to be
   difficult or impossible if such contents are encrypted.

   The concern over end-to-end integrity arises for the use of Reverse
   Routing Header (see Section 5.5.2) too, since Mobile Routers would
   insert new contents to the header of packets sent by downstream
   Mobile Network Nodes.  This makes it difficult for Mobile Network
   Nodes to protect the end-to-end integrity of such information with
   security associations.

5.8.3.  Location Privacy

   Another security related concern is the issue of location privacy.
   This draft currently does not consider the location privacy threats
   caused by an on path eavesdropper.  For more information on that
   aspect, please refer to [18].  Instead, we consider the following
   three aspects to location privacy:

   o  Revelation of Location to Correspondent Entity

      Route optimization is achieved by creating a binding between the



Ng, et al.               Expires March 19, 2007                [Page 32]

Internet-Draft           NEMO RO Space Analysis           September 2006


      address of the Mobile Network Node and the current location of the
      Mobile Network.  It is thus inevitable that the location of Mobile
      Network Node be revealed to the Correspondent Entity.  The concern
      may be alleviated if the Correspondent Entity is not the
      Correspondent Node, since this implies that the actual traffic
      end-point (i.e. the Correspondent Node) would remain ignorant of
      the current location of the Mobile Network Node.

   o  Degree of Revelation

      With network mobility, the degree of location exposure varies,
      especially when one considers nested mobile networks.  For
      instance, for approaches that bind the address of the Mobile
      Network Node to the location of the root Mobile Router (see
      Section 5.5.3), only the topmost point of attachment of the mobile
      network is revealed to the Correspondent Entity.  Whereas for
      approaches such as those described in Section 5.5.1 and
      Section 5.5.2, more information (such as Mobile Network Prefixes
      and current locations of upstream Mobile Routers) is revealed.

   o  Control of the Revelation

      When Route Optimization is initiated by the Mobile Network Node
      itself, it is in control of whether or not to sacrifice location
      privacy for an optimized route.  However, if it is the Mobile
      Router that initiates Route Optimization (e.g.  "Binding Update
      with Mobile Network Prefix" and "Mobile Router as a Proxy" in
      Section 5.5.1), then control is taken away from the Mobile Network
      Node.  Additional signaling mechanism between the Mobile Network
      Node and its Mobile Router can be used in this case to prevent the
      Mobile Router from attempting Route Optimization for a given
      traffic stream.



















Ng, et al.               Expires March 19, 2007                [Page 33]

Internet-Draft           NEMO RO Space Analysis           September 2006


6.  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 integrated smoothly with others.  With this in mind,
   this document attempts to present a detailed and in depth analysis of
   the NEMO Route Optimization solution space by first describing the
   benefits a Route Optimization solution is expected to bring, then
   illustrating the different scenarios in which a Route Optimization
   solution applies to, and next presenting some issues a Route
   Optimization solution might face.  We have also asked ourselves some
   of the basic questions about a Route Optimization solution.  By
   investigating different possible answers to these questions, we have
   explored different aspects to a Route Optimization solution.  The
   intent of this work is to enhance our common understanding of the
   Route Optimization problem and solution space.



7.  IANA Considerations

   This is an informational document and does not require any IANA
   action.



8.  Security Considerations

   This is an informational document that analyzes the solution space of
   NEMO Route Optimization.  Security considerations of different
   approaches are described in the relevant sections throughout this
   document.  Particularly, please refer to Section 4.9 for a brief
   discussion of the security concern with respect to Route Optimization
   in general, and Section 5.8 for a more detailed analysis of the
   various Route Optimization approaches.



9.  Acknowledgments

   The authors wish to thank the co-authors of previous drafts from
   which this draft is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki
   Ohnishi, Felix Wu, and Souhwan Jung.  In addition, sincere
   appreciation is also extended to Jari Arkko, Carlos Jesus Bernardos,
   Greg Daley, Thierry Ernst, T.J. Kniveton, Erik Nordmark, Alexandru
   Petrescu, Hesham Soliman, Ryuji Wakikawa and Patrick Wetterwald for
   their various contributions.



Ng, et al.               Expires March 19, 2007                [Page 34]

Internet-Draft           NEMO RO Space Analysis           September 2006


10.  References

10.1.  Normative References

   [1]  Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility
        Route Optimization Problem Statement",
        draft-ietf-nemo-ro-problem-statement-03 (work in progress),
        September 2006.

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

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

   [4]  Ernst, T., "Network Mobility Support Goals and Requirements",
        draft-ietf-nemo-requirements-05 (work in progress),
        October 2005.

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

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

10.2.  Informative References

   [7]   Wakikawa, R., Koshiba, S., Uehara, K., and J. Murai, "ORC:
         Optimized Route Cache Management Protocol for Network
         Mobility", 10th International Conference on Telecommunications,
         vol 2, pp 1194-1200, February 2003.

   [8]   Wakikawa, R. and M. Watari, "Optimized Route Cache Protocol
         (ORC)", draft-wakikawa-nemo-orc-01 (work in progress),
         November 2004.

   [9]   Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo, "Route
         Optimization Scheme based on Path Control Header",
         draft-na-nemo-path-control-header-00 (work in progress),
         April 2004.

   [10]  Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
         its application to Mobile Networks",
         draft-thubert-nemo-reverse-routing-header-05 (work in
         progress), June 2004.

   [11]  Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization



Ng, et al.               Expires March 19, 2007                [Page 35]

Internet-Draft           NEMO RO Space Analysis           September 2006


         with Access Router Option",
         draft-ng-nemo-access-router-option-01 (work in progress),
         July 2004.

   [12]  Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo,
         "Secure Nested Tunnels Optimization using Nested Path
         Information", draft-na-nemo-nested-path-info-00 (work in
         progress), September 2003.

   [13]  Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
         "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)",
         RFC 4140, August 2005.

   [14]  Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA to HA
         protocol", draft-thubert-nemo-global-haha-01 (work in
         progress), October 2005.

   [15]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
         Configuration Protocol (DHCP) version 6", RFC 3633,
         December 2003.

   [16]  Baek, S., Yoo, J., Kwon, T., Paik, E., and M. Nam, "Routing
         Optimization in the same nested mobile network",
         draft-baek-nemo-nested-ro-00 (work in progress), October 2005.

   [17]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
         July 2005.

   [18]  Koodli, R., "IP Address Location Privacy and Mobile IPv6:
         Problem Statement", draft-irtf-mobopts-location-privacy-ps-00
         (work in progress), July 2005.

   [19]  Nikander, P., "Mobile IP version 6 Route Optimization Security
         Design Background", draft-ietf-mip6-ro-sec-03 (work in
         progress), May 2005.

   [20]  Bernardos, C., Bagnulo, M., and M. Calderon, "MIRON: MIPv6
         Route Optimization for NEMO", 4th Workshop on Applications and
         Services in Wireless Network,
         Online: http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf,
         August 2004.

   [21]  Bernardos, C., Bagnulo, M., Calderon, M., and I. Soto, "Mobile
         IPv6 Route Optimisation for Network Mobility (MIRON)",
         draft-bernardos-nemo-miron-00 (work in progress), July 2005.

   [22]  Ylitalo, J., "Securing Route Optimization in NEMO", Workshop
         of 12th Network and Distributed System Security Syposuim, NDSS



Ng, et al.               Expires March 19, 2007                [Page 36]

Internet-Draft           NEMO RO Space Analysis           September 2006


         Workshop 2005, online: http://www.isoc.org/isoc/conferences/
         ndss/05/workshop/ylitalo.pdf, February 2005.

   [23]  Perera, E., Hsieh, R., and A. Seneviratne, "Extended Network
         Mobility Support", draft-perera-nemo-extended-00 (work in
         progress), July 2003.

   [24]  Lee, K., Park, J., and H. Kim, "Route Optimization for Mobile
         Nodes in Mobile Network based on Prefix  Delegation", 58th IEEE
         Vehicular Technology Conference, vol 3, pp 2035-2038,
         October 2003.

   [25]  Lee, K., Jeong, J., Park, J., and H. Kim, "Route Optimization
         for Mobile Nodes in Mobile Network based on Prefix
         Delegation", draft-leekj-nemo-ro-pd-02 (work in progress),
         February 2004.

   [26]  Jeong, J., Lee, K., Park, J., and H. Kim, "Route Optimization
         based on ND-Proxy for Mobile Nodes in IPv6 Mobile Network",
         59th IEEE Vehicular Technology Conference, vol 5, pp 2461-2465,
         May 2004.

   [27]  Jeong, J., Lee, K., Kim, H., and J. Park, "ND-Proxy based Route
         Optimization for Mobile Nodes in Mobile Network",
         draft-jeong-nemo-ro-ndproxy-02 (work in progress),
         February 2004.

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

   [29]  Kang, H., Kim, K., Han, S., Lee, K., and J. Park, "Route
         Optimization for Mobile Network by Using Bi-directional Between
         Home  Agent and Top Level Mobile Router",
         draft-hkang-nemo-ro-tlmr-00 (work in progress), June 2003.

   [30]  Lee, D., Lim, K., and M. Kim, "Hierarchical FRoute Optimization
         for Nested Mobile Network", 18th Int'l Conf on Advance
         Information Networking and Applications, vol 1, pp 225-229,
         2004.

   [31]  Takagi, Y., Ohnishi, H., Sakitani, K., Baba, K., and S.
         Shimojo, "Route Optimization Methods for Network Mobility with
         Mobile IPv6", IEICE Trans. on Comms, vol E87-B, no 3, pp 480-
         489, March 2004.

   [32]  Ohnishi, H., Sakitani, K., and Y. Takagi, "HMIP based Route
         optimization method in a mobile network",
         draft-ohnishi-nemo-ro-hmip-00 (work in progress), October 2003.



Ng, et al.               Expires March 19, 2007                [Page 37]

Internet-Draft           NEMO RO Space Analysis           September 2006


   [33]  Lee, C., Zheng, J., and C. HUang, "SIP-based Network Mobility
         (SIP-NEMO) Route Optimization", draft-ming-nemo-sipnemo-00
         (work in progress), October 2005.

   [34]  Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
         Specification", RFC 2473, December 1998.

   [35]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
         Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
         Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
         Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
         Framework and four profiles: RTP, UDP, ESP, and uncompressed",
         RFC 3095, July 2001.

   [36]  Jonsson, L-E., "RObust Header Compression (ROHC): Terminology
         and Channel Mapping Examples", RFC 3759, April 2004.

   [37]  Minaburo, A., Paik, E., Toutain, L., and J. Bonnin, "ROHC
         (Robust Header Compression) in NEMO network",
         draft-minaburo-rohc-nemo-01 (work in progress), July 2005.

   [38]  Ng, C. and J. Hirano, "Extending Return Routability Procedure
         for Network Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in
         progress), October 2004.

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

   [40]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         RFC 3972, March 2005.

   [41]  Zhao, F., "Extensions to Return Routability Test in MIP6",
         draft-zhao-mip6-rr-ext-01 (work in progress), February 2005.

   [42]  Arkko, J. and C. Vogt, "A Taxonomy and Analysis of Enhancements
         to Mobile IPv6 Route Optimization",
         draft-irtf-mobopts-ro-enhancements-08 (work in progress),
         May 2006.

   [43]  Bao, F., Deng, R., Qiu, Y., and J. Zhou, "Certificate-based
         Binding Update Protocol (CBU)",
         draft-qiu-mip6-certificated-binding-update-03 (work in
         progress), March 2005.

   [44]  Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-06
         (work in progress), June 2006.

   [45]  Nikander, P., "End-Host Mobility and Multihoming with the Host



Ng, et al.               Expires March 19, 2007                [Page 38]

Internet-Draft           NEMO RO Space Analysis           September 2006


         Identity Protocol", draft-ietf-hip-mm-04 (work in progress),
         June 2006.

   [46]  Calderon, M., Bernardos, C., Bagnulo, M., and I. Soto,
         "Securing Route Optimization in NEMO", Third International
         Symposium on Modeling and Optimization in Mobile, Ad Hoc, and
         Wireless Networks, WIOPT 2005, pages 248-254, April 2005.












































Ng, et al.               Expires March 19, 2007                [Page 39]

Internet-Draft           NEMO RO Space Analysis           September 2006


Appendix A.  Change Log

   o  draft-ietf-nemo-ro-space-analysis-03:

      *  Keepalive release

   o  draft-ietf-nemo-ro-space-analysis-02:

      *  Changed title of Sect 3.1 from "Basic NEMO Route Optimization"
         to "Non-Nested NEMO Route Optimization"

      *  Added "Terminology" Sub-section [Issue #17]

      *  Modifications to Sect 3.1 and 5.1.1 [Issues #18, #20]

      *  Break "Mobility Transparency and Location Privacy" into Sect
         4.7 and 4.8 [Issue #19]

      *  Updated References [Issue #21]

   o  draft-ietf-nemo-ro-space-analysis-01:

      *  Changed the term "Correspondent Agent" to "Correspondent
         Entity" [Issue #13]

      *  Added clarifying text to some benefits listed in Sect 2 [Issue
         #14]

      *  Added clarifying text to Sect 4.1, 4.3 and 4.4 [Issues #5, #6,
         #16]

      *  Added Section 4.9 [Issue #3]

      *  Added clarifying text to various parts of Sect 5 [Issues #7,
         #8, #9, #11, and #16]

      *  Combined "MR as a Proxy" and "MR as a Transparent Proxy" in
         Sect 5.5.1 [Issue #11]

      *  Changed the term "identity of MNN" to "address of MNN" in Sect
         5.5 [Issue #12]

      *  Added text on signaling using upper layer protocols in Sect 5.6

      *  Added more security consideration to Sect 5.8 [Issue #15]






Ng, et al.               Expires March 19, 2007                [Page 40]

Internet-Draft           NEMO RO Space Analysis           September 2006


   o  draft-ietf-nemo-ro-space-analysis-00:

      *  Adapted from Sections 3, 4 & 5 of
         'draft-thubert-nemo-ro-taxonomy-04.txt' into:

         +  Section 3 - "Different Scenarios of NEMO Route Optimization"

         +  Section 4 - "Issues of NEMO Route Optimization"

      *  Included various parts from 'draft-zhao-nemo-ro-ps-01.txt'

      *  Re-vamped Section 5 - "Analysis of Solution Space"







































Ng, et al.               Expires March 19, 2007                [Page 41]

Internet-Draft           NEMO RO Space Analysis           September 2006


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: chanwah.ng@sg.panasonic.com


   Fan Zhao
   University of California Davis
   One Shields Avenue
   Davis, CA  95616
   US

   Phone: +1 530 752 3128
   Email: fanzhao@ucdavis.edu


   Masafumi Watari
   KDDI R&D Laboratories Inc.
   2-1-15 Ohara
   Fujimino, Saitama  356-8502
   JAPAN

   Email: watari@kddilabs.jp


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

   Email: pthubert@cisco.com











Ng, et al.               Expires March 19, 2007                [Page 42]

Internet-Draft           NEMO RO Space Analysis           September 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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


Intellectual Property

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

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

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


Acknowledgment

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





Ng, et al.               Expires March 19, 2007                [Page 43]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/