Internet DRAFT - draft-cho-nemo-ro-expected-properties

draft-cho-nemo-ro-expected-properties







NEMO Working Group                                                H. Cho
Internet-Draft                                                   T. Kwon
Expires: January 19, 2007                      Seoul National University
                                                                 E. Paik
                                                                      KT
                                                           July 18, 2006


   Route Optimization Expected Properties and Performance Metrics for
                         Nested Mobile Networks
              draft-cho-nemo-ro-expected-properties-00.txt

Status of this Memo

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

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

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

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

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

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

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo categorizes the route optimization problem of NEMO and
   clarifies the expected properties of the route optimization
   protocols.  The route optimization can be classified into NEMO
   optimization and nested NEMO optimization.  Since NEMO basic support
   protocol is based on bi-directional tunneling, the packets from the



Cho, et al.             Expires January 19, 2007                [Page 1]

Internet-Draft           RO expected properties                July 2006


   CN to the MNN are suffer from inefficient routing all the cases.
   This routing inefficiency is getting worse when a number of MRs are
   nested.  This memo is especially interested in nested NEMO
   optimization.  To solve the routing inefficiency problem, there were
   several proposals.  However, those proposals could not be compared or
   evaluated properly since there was no consensus on the expected
   properties of nested mobile networks.  This memo is willing to
   suggest the expected properties of nested mobile networks, so as to
   help coming route optimization proposals find their strength and
   weakness according to the commonly accepted desirable properties.


Table of Contents

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

   2.  NEMO optimization and nested NEMO optimization . . . . . . . .  4
     2.1.  NEMO optimization  . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Nested NEMO optimization . . . . . . . . . . . . . . . . .  5

   3.  Mobility awareness to mobile nodes in NEMO . . . . . . . . . .  5
     3.1.  When we hold the mobility transparency . . . . . . . . . .  5
       3.1.1.  Reduced signaling  . . . . . . . . . . . . . . . . . .  5
       3.1.2.  Long handoff disruption time . . . . . . . . . . . . .  5
       3.1.3.  Loose location privacy . . . . . . . . . . . . . . . .  6
     3.2.  When we discard the mobility transparency  . . . . . . . .  6
       3.2.1.  Flexible route optimization  . . . . . . . . . . . . .  6
       3.2.2.  Reduced handoff disruption time  . . . . . . . . . . .  6
       3.2.3.  Strong location privacy  . . . . . . . . . . . . . . .  6

   4.  Expected properties and Performance metrics  . . . . . . . . .  6
     4.1.  Efficient routing  . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Location privacy . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Mobility transparency  . . . . . . . . . . . . . . . . . .  7
     4.4.  Handoff disruption time  . . . . . . . . . . . . . . . . .  7
     4.5.  Inter-NEMO routing . . . . . . . . . . . . . . . . . . . .  7
     4.6.  Security . . . . . . . . . . . . . . . . . . . . . . . . .  8

   5.  Relationship among expected properties . . . . . . . . . . . .  8

   6.  Security consideration . . . . . . . . . . . . . . . . . . . .  9

   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9

   Appendix A.  Case studies of existing proposals  . . . . . . . . .  9
     A.1.  Access Router Option (ARO) . . . . . . . . . . . . . . . . 10
     A.2.  Recursive Binding Update (RBU+)  . . . . . . . . . . . . . 10
     A.3.  Reverse Routing Header (RRH) . . . . . . . . . . . . . . . 10



Cho, et al.             Expires January 19, 2007                [Page 2]

Internet-Draft           RO expected properties                July 2006


     A.4.  Nested Path Info (NPI) . . . . . . . . . . . . . . . . . . 10
     A.5.  HMIP based route optimization (HMIP-RO)  . . . . . . . . . 11

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13














































Cho, et al.             Expires January 19, 2007                [Page 3]

Internet-Draft           RO expected properties                July 2006


1.  Introduction

   Mobile IP [1] is the basic solution to provide host mobility whereas
   network mobility [2] refers to the concept of collective mobility of
   a set of nodes.  In the simplest scenario, a mobile network moves as
   a single unit with one mobile router (MR) that connects it to the
   global Internet.

   A mobile network can have a hierarchical structure, e.g. a mobile
   network within another mobile network.  This situation is referred to
   as a nested mobile network.  For example, a personal digital
   assistant and a mobile phone might be organized together to form a
   user's personal area network (PAN).  A PAN may travel a vehicle,
   which also contains a mobile network of larger scale.

   In a nested mobile network, multiple MRs form a tree hierarchy in
   which the root MR is called the top-level mobile router (TLMR).
   Nested mobile networks exhibit the inefficient routing problem, which
   becomes worse in proportion to the number of nested levels in the
   hierarchy.  This is the so-called pinball routing problem.

   To solve the pinball problem, there were several proposals.  However,
   those proposals could not be compared or evaluated properly since
   there was no consensus on the expected properties of nested mobile
   networks.  This memo is willing to suggest the expected properties of
   nested mobile networks, so as to help coming route optimization
   proposals find their strength and weakness according to the commonly
   accepted desirable properties.  All terminologies used in this memo
   follow [3].


2.  NEMO optimization and nested NEMO optimization

   The routing optimization in NEMO context can be divided into NEMO
   optimization and nested NEMO optimization.

2.1.  NEMO optimization

   As the NEMO basic support protocol adopts the tunneling based
   mechanism, there exists a routing inefficiency naturally.  NEMO
   optimization is focused on how the routing path in the NEMO protocol
   can be optimized.  One possible solution is to adopt mobile IPv6
   style route optimization by sending BU to CN.  However, this approach
   can result in the massively occurred binding update messages at the
   same time, so called binding update storm (BU storm) since there will
   be many MNNs inside the NEMO.  As preventing the BU storm while a
   group of nodes are moving was the basic concept of NEMO, mobile IPv6
   style route optimization is not desirable.  Furthermore, since some



Cho, et al.             Expires January 19, 2007                [Page 4]

Internet-Draft           RO expected properties                July 2006


   NEMO optimization schemes might be opposed to the already
   standardized NEMO basic support protocol, this memo will not deal
   with NEMO optimization.

2.2.  Nested NEMO optimization

   The nested NEMO optimization does not seek to solve the inefficiency
   of the NEMO basic support protocol.  In the nested NEMO, the
   inefficiency is proportional to the nested level of the NEMO without
   any measure.  The nested NEMO can have arbitrary levels of nesting.
   It is thought that there are two types of nesting: physical nesting
   and logical nesting. physical nesting means a NEMO getting into
   another NEMO (e.g. a PAN inside a vehicle).  On the other hand, the
   logical nesting is not assuming the physical containing relation
   between the NEMOs.  For example, in an area where a NEMO cannot
   access to the Internet like a tunnel, the NEMO may be attached to its
   neighbor NEMO to access to the Internet.  This situation will cause
   logical nesting of NEMOs.  Therefore, the degree of nesting can be
   increased to more than two levels, and nested NEMO optimization
   should be achieved for commercial deployment of NEMO.  This memo is
   especially interested in nested NEMO optimization.


3.  Mobility awareness to mobile nodes in NEMO

   One of the basic concept of network mobility is the mobiltity
   transparency.  The mobility transparency means that an MR hides its
   movement to the MNNs.  The only entity that knows the movement of
   NEMO is MR and it aggregate the location registration of underlaying
   VMNs and sub-MRs.  However, as we take care of the nested NEMO, the
   mobility transparency makes the route optimization of nested NEMO too
   difficult.  Therefore, it is needed to compare the pros and cons
   about holding the mobilty transparency.

3.1.  When we hold the mobility transparency

3.1.1.  Reduced signaling

   As the top-level MR only knows the movement of the NEMO, the mobility
   transparency will prevent the BU storm while a mass group of nodes
   are moving.

3.1.2.  Long handoff disruption time

   If a route optimization scheme makes a short-cut to the nested
   tunnel, the MR should register the current location of nested NEMO as
   soon as possible to reduce the handoff disruption time.  As the
   mobility transparency hinder the fact that it move to the MR, there



Cho, et al.             Expires January 19, 2007                [Page 5]

Internet-Draft           RO expected properties                July 2006


   will exist long handoff disruption time.

3.1.3.  Loose location privacy

   The location privacy means that an MR hides its and thus all MNNs'
   current location to the CNs.  For an example, in the route
   optimization scheme in mobile IPv6, an MN can send a BU to a CN to
   let the CN know the current location (CoA) of the MN.  As the CN
   knows the CoA of the MN, packets toward the MN will be routed
   directly to the MN without visiting the HA of the MN.  In this case,
   the location privacy is neglected for efficient routing.  For the
   NEMO case, the same rule could be applied.

3.2.  When we discard the mobility transparency

3.2.1.  Flexible route optimization

   As the nested bi-directional tunnel could be skewed or omitted, the
   route optimization schemes will have more flexibility.

3.2.2.  Reduced handoff disruption time

   All the MRs and the VMNs in the NEMO can know the movement of the
   whole nested NEMO.  It will help the fast location update and the
   handoff disruption time will be shorten.

3.2.3.  Strong location privacy

   Violating both the mobility transparency and the location privacy at
   the same time will cause the potential BU storm.  When MRs or VMNs
   let the CNs know the current point of attachment of the TLMR, if the
   MRs and VNNs can know the movement of the TLMR, all MRs and VMNs are
   willing to update their location simultaneously.


4.  Expected properties and Performance metrics

   Besides the mobility transparency and the location privacy mentioned
   in the previous section, there are several expected properties and
   performance metrics for route optimization schemes.  Following
   sections will explain about the properties and show there exist
   trade-off relationships among those properties.

4.1.  Efficient routing

   Nested mobile networks exhibit the pinball routing problem.  In the
   NEMO basic support protocol, each mobile node (MR or VMN) has its own
   HA.  In the worst case, when a CN sends a packet to the MNN which is



Cho, et al.             Expires January 19, 2007                [Page 6]

Internet-Draft           RO expected properties                July 2006


   located at the bottom level of the nested mobile network, the packet
   has to visit the HAs of all the MRs.  As the pinball routing cause
   long latency and packet overhead, how short the routing path is is
   important.  As this memo is concentrated in only nested NEMO
   optimization, the minimum routing path will be triangular routing
   (visiting only one HA).  The routing efficiency will be measured by
   the round trip time (RTT) from CN to MNN.  The increasing factor of
   RTT as the degree of nesting increases is matter.  The constant RTT
   will be desirable regardless of the depth of nesting.

4.2.  Location privacy

   The information about the location of a node (e.g.  CoA) is a matter
   of privacy, and ideally should not be exposed to a non-administrative
   domain (e.g. a CN).  However, the location privacy is not mandatory,
   since the mobile IPv6 protocol already permits a binding update to
   the CN for the route optimization.  As many entities involved in the
   routing know the location of a destination node, the routing path can
   be shorten, however the location information might be abused by
   malicious entity.

4.3.  Mobility transparency

   The NEMO basic support protocol uses a bi-directional tunnel between
   the HA and the MR to keep MNNs from sending all their location
   registrations simultaneously when the MR changes its point of
   attachment.  This characteristic is called mobility transparency,
   which is a desirable feature for the route optimization scheme, as
   preventing the BU storm while a group of nodes are moving was the
   basic concept of NEMO.  The mobility transparency can be measured by
   the number of messages per changing its location.

4.4.  Handoff disruption time

   The handoff latency is composed with the sum of a movement detection
   time and a location registration time.  The movement detection is
   achieved by very fast router advertisement.  To shorten the
   registration time, each MRs should update their location as soon as
   possible.  However, reducing the registration time might potentially
   cause the BU storm and violate the mobility transparency.  Coming
   route optimization scheme should take care of both mobility
   transparency and seamless handoff.

4.5.  Inter-NEMO routing

   A inter-NEMO routing and a intra-NEMO routing designate the same
   situation ironically in the nested NEMO context since a NEMO can have
   another NEMO and a communication between sub-NEMOs is intra-NEMO



Cho, et al.             Expires January 19, 2007                [Page 7]

Internet-Draft           RO expected properties                July 2006


   communication as well as inter-NEMO communication.  Usually, the
   route to be optimized is taken to be the path between the MNN and the
   CN, which is outside the nested mobile network.  As peer-to-peer
   applications proliferate, communication inside a mobile network must
   also be considered.

4.6.  Security

   As the NEMO basic support protocol is based on bi-directional
   tunneling between HA and MR, many security concerns are shifted to
   the IPsec or secured tunnel mechanism.  Once the tunnel established,
   all signaling messages and data traffics was safe from malicious
   entity.  However, in the case of route optimization, most approaches
   skew the nested tunneling to shorten the routing path.  In this
   situation, the security considerations are mostly responsible to
   protocol designers.  Especially, for the intra-NEMO routing,
   intermediate MR laying in the routing path may look into the packets
   pass through to redirect their forwarding.  The security associations
   among entities are necessary.


5.  Relationship among expected properties


        Mobility     |      /  Location
        transparency |     /   privacy
                     |    /
                     |   /
                     |  /
                     | /
                     |/
       --------------+----------------
     Inter-NEMO     /|         Security
     routing       / |
                  /  |
                 /   |
                /    |
      Optimal  /     | Seamless
      routing /      | handoff

   Figure 1. Relationship among expected properties

   As shown in Figure 1, mobility transparency and handoff disruption
   time are in relation of tradeoff.  "Location privacy and routing
   efficiency" and "inter-NEMO routing and security" properties show
   contrary characteristics to each other.  When designing a new route
   optimization scheme, each expected properties should be considered.
   A route optimization schemes inclined to one property will lose



Cho, et al.             Expires January 19, 2007                [Page 8]

Internet-Draft           RO expected properties                July 2006


   another property.  Finding balanced point is essential.


6.  Security consideration

   We do not consider any security issues in this draft.

7.  References

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

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

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

   [4]  Ng, C. and J. Hirano, "Securing Nested Tunnels Optimization with
        Access Router Option", draft-ng-nemo-access-router-option-01
        (work in progress), July 2004.

   [5]  Cho, H., Paik, E., and Y. Choi, "RBU+: Recursive Binding Update
        for End-to-End Route Optimization in Nested Mobile Networks",
        LNCS Vol. 3079, pp.468-478, June 2004.

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

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

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

   [9]  Soliman, H., Castelluccia, C., El-Malki, K., and L. Bellier,
        "Hierarchical Mobile IPv6 mobility management (HMIPv6)",
        draft-ietf-mobileip-hmipv6-08 (work in progress), June 2003.


Appendix A.  Case studies of existing proposals




Cho, et al.             Expires January 19, 2007                [Page 9]

Internet-Draft           RO expected properties                July 2006


A.1.  Access Router Option (ARO)

   ARO [4] is based on the route optimization mechanism of Mobile IPv6,
   which is then extended with an access router option.  In this
   approach, the home agents of the MRs collect binding information from
   upper-level mobile routers one by one and deduce the optimal route
   recursively.  This approach is simple and needs minimum changes in
   the existing NEMO basic support protocol.  However, since the route
   is optimized step by step, the process needs a long convergence time,
   which is proportional to the degree of nesting.  In ARO, the whole
   binding cache in the HA has to be searched recursively to find the
   optimal path to the MNN and the number of recursive steps for each
   packet is proportional to its degree of nesting.  Furthermore, since
   the correspondent node also participates in the route optimization
   mechanism, location privacy is not guaranteed.

A.2.  Recursive Binding Update (RBU+)

   RBU+ [5] is a modification of ARO, in which the optimal route is
   found when the binding update messages are received by the HAs.  This
   recursive binding update allows the HAs to maintain the binding
   information for the CoA of the TLMR.  To handle a packet that arrives
   at the TLMR, RBU+ adopts ad hoc network routing inside the mobile
   network.  MRs can maintain a routing table (proactive) or construct a
   routing path on demand (reactive).  However, the extensive handoff
   disruption caused by a long convergence time, and weak location
   privacy, are still problems in RBU+.

A.3.  Reverse Routing Header (RRH)

   RRH [6] uses new extension headers to inform an MR's home agents of
   the nested structure of a mobile network and route the packets
   optimally.  In RRH, when a packet is sent from an MNN, each
   intermediate MR inserts its HoA into the reverse routing header of
   the packet.  This means that, when a packet arrives at its
   destination, that node can determine the optimal route back to the
   MNN.  RRH has the problem that this header modification needs to be
   performed for every outgoing packet.

A.4.  Nested Path Info (NPI)

   In NPI [7], the binding update message is updated so that it informs
   the HAs (of the MRs) of the nested path information.  However, when
   the TLMR moves to another site, the new nested path information will
   be propagated to the whole nested mobile network.  After receiving
   this new information, every MR and VMN in the nested mobile network
   will send BUs at the same time; this may cause binding update storm.




Cho, et al.             Expires January 19, 2007               [Page 10]

Internet-Draft           RO expected properties                July 2006


A.5.  HMIP based route optimization (HMIP-RO)

   HMIP-RO [8] borrows the concept of a mobility anchor point (MAP) from
   Hierarchical MIPv6 [9], and uses it to separate routing between the
   CN and the MAP (outside the NEMO) and routing inside the NEMO.
   HMIP-RO uses a modified version of HMIPv6 to propagate MAP
   advertisement messages.  So an MR has two care-of addresses, as it
   would in HMIPv6 by listening to the MAP advertisement and router
   advertisement messages; one is the regional CoA from the MAP and
   another is the on-link CoA from its closest MR.  By informing the HA
   of the MR of the regional CoA and the MAP of the on-link CoA,
   respectively, packets for the MR can be routed via the MAP.  However,
   when the MR moves to the domain of another MAP, a similar problem may
   occur with NPI





































Cho, et al.             Expires January 19, 2007               [Page 11]

Internet-Draft           RO expected properties                July 2006


Authors' Addresses

   Hosik Cho
   Seoul National University
   Multimedia Communications Lab., Seoul National Univ.
   Shillim-dong, Kwanak-gu
   Seoul  151-744
   Korea

   Phone: +82-2-880-9147
   Fax:   +82-2-876-7170
   Email: hscho@mmlab.snu.ac.kr
   URI:   http://mmlab.snu.ac.kr/~hscho/


   Taekyoung Kwon
   Seoul National University
   Multimedia Communications Lab., Seoul National Univ.
   Shillim-dong, Kwanak-gu
   Seoul  151-744
   Korea

   Phone: +82-2-880-9105
   Fax:   +82-2-872-2045
   Email: tk@mmlab.snu.ac.kr
   URI:   http://mmlab.snu.ac.kr/~tk/


   Eunkyoung Paik
   KT
   Advanced Technology Lab. KT
   17 Woomyeon-dong, Seocho-gu
   Seoul  137-792
   Korea

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












Cho, et al.             Expires January 19, 2007               [Page 12]

Internet-Draft           RO expected properties                July 2006


Intellectual Property Statement

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

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

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


Disclaimer of Validity

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


Copyright Statement

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


Acknowledgment

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




Cho, et al.             Expires January 19, 2007               [Page 13]