Internet DRAFT - draft-maxiaolei-manemo-ro

draft-maxiaolei-manemo-ro






Network Working Group                                              X. Ma
Internet-Draft                                                  J. Zhang
Intended status: Informational                                    J. Jia
Expires: April 3, 2012                                            Y. Liu
                                          Beijing University of Post and
                                                      Telecommunications
                                                                Oct 2011


         The MANEMO Route Optimization in the Rescue Operation
                      draft-maxiaolei-manemo-ro-00

Abstract

   Network Mobility Basic Support Protocol (NEMO BS) is the protocol
   proposed for the mobility management of mobile networks.  However,
   NEMO BS cannot deal with the problem of pinball routing in the nested
   mobile network.  And the related solutions are not yet considered and
   discussed in the IETF.  MANEMO (MANET for NEMO) is designed to solve
   this problem.  This article puts forward a novel MANEMO route
   optimization solution to solve the pinball routing in nested NEMO.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 3, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Ma, et al.                Expires April 3, 2012                 [Page 1]

Internet-Draft              Abbreviated Title                   Oct 2011


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  NEMO-OLSR scheme description . . . . . . . . . . . . . . . . .  3
     3.1.  Protocol extensions  . . . . . . . . . . . . . . . . . . .  4
     3.2.  Local MANET Communication  . . . . . . . . . . . . . . . .  4
       3.2.1.  Modified Hello Message Format  . . . . . . . . . . . .  5
       3.2.2.  G-MR List Format . . . . . . . . . . . . . . . . . . .  6
       3.2.3.  Communication Process  . . . . . . . . . . . . . . . .  7
     3.3.  Roaming NEMO communication . . . . . . . . . . . . . . . .  8
     3.4.  The advantages of the proposed scheme  . . . . . . . . . . 10
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11


























Ma, et al.                Expires April 3, 2012                 [Page 2]

Internet-Draft              Abbreviated Title                   Oct 2011


1.  Introduction

   With the mobile technology rapidly developing, more and more mobile
   devices come into our life in recent years.  Sometimes a group of
   mobile devices will move as a whole subnet, for example, the
   passengers will use mobile devices in the train or on the bus.  The
   subnet needs a mobile access support to the Internet.  To meet this
   demand, the NEMO working group of Internet Engineering Task Force
   (IETF) extended the Mobile Internet Protocol Version 6 (MIPv6) and
   put forward NEMO BS.  NEMO BS can ensure the session continuity of a
   whole mobile network when it changes the access point to the
   Internet.  However, NEMO BS has not considered the route optimization
   in the nested network, so the problem of pinball routing will be more
   serious with the nesting level increasing.  It will lead to multiple
   encapsulations of messages and communication delay which impair the
   quality of communication seriously.

   This draft is aimed at using the idea of MANEMO to deal with the sub-
   optimal routing problem in nested NEMO.  The draft introduces the
   modified MANET routing protocol OLSR into the NEMO BS to route the
   messages inside and outside the mobile network.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119.

   Readers are expected to be familiar with all the terms defined in the
   RFC 6275 and the NEMO Terminology draft

   Nested NEMO The Nested NEMO is a network configuration where one more
   mobile router access the Internet through other mobile routers.  The
   mobile routers are connected in a nested formation.

   MANEMO MANET for NEMO.  The network architecture of MANEMO can be
   described as a nested NEMO.  MANEMO network is integrated by MANET
   and NEMO.  The two kinds of network can extend each other's
   capability to construct a stronger network system.


3.  NEMO-OLSR scheme description

   In the proposed NEMO-OLSR scheme, the MRs that have the same AR
   property will form a MANET network.  The scheme is described in two
   scenarios: the local MANET communication and the roaming NEMO
   communication.



Ma, et al.                Expires April 3, 2012                 [Page 3]

Internet-Draft              Abbreviated Title                   Oct 2011


3.1.  Protocol extensions

   This article changes the mobile communications within the network to
   optimize the route in nested NEMO network.  So the extensions focus
   on the MR, which are described as follows:

   1 The MR manages all the communication in the mobile subnet.  And the
   MRs under the same AR compose a MANET network.  A module called OLSR
   MODULE is added to every MR to support the OLSR protocol.  It sends
   HELLO message periodically to build the topology of the mobile
   network.  The "AR Address" field is added to the Hello message to be
   the mark of a specified MANET network.

   2 The "Grounded Router flag" is added in the OLSR-Hello message to
   indicate whether the MR is G-MR or not.  If the MR is G-MR, it will
   be the gateway of the MANET.  Otherwise, it will keep the address of
   its G-MR, and send the data packets to the G-MR firstly every time
   when it communicates with the nodes in the Internet.

   3 A G-MR List is added in every MR.  When the status of an MR is non-
   G-MR, it will record the information of the G-MR in this list.  The
   information of G-MR is taken from the Hello messages the MR receives.
   There can be a lot of G-MR information in the G-MR list.  The MR will
   choose an optimized one according to the related parameters.  We will
   describe the procedure in detail later.

3.2.  Local MANET Communication

   Figure 1 depicts the structure of nested mobile networks.






















Ma, et al.                Expires April 3, 2012                 [Page 4]

Internet-Draft              Abbreviated Title                   Oct 2011


                              +---+   +---+    +---+   +--+--+
                              |HA2|   |HA3|    |HA4|---| CN  |
                              +---+   +---+    +---+   +--+--+
                                |2::    |3::     |4::
                                |       |        |
                 +-----+1::   +------------------------+
                 | HA1 |------|         Internet       |
                 +-----+      ++-----------------------+
                                         |
                                       +---+
                                       |AR1|
                                       +---+
                                         |1::
                                       +---+
                                       |MR1|
                                       +---+
                                         |
                                    -+---+---+-
                                     |2::    |3::
                                   +---+   +---+
                                   |MR2|   |MR3|
                                   +---+   +---+
                                             |4::
                                           +---+
                                           |MR4|
                                           +---+
                                             |
                                           +---+
                                           |MNN|
                                           +---+

                  The structure of nested mobile networks

                                 Figure 1

3.2.1.  Modified Hello Message Format

   The proposed modified hello message format is shown as follows:













Ma, et al.                Expires April 3, 2012                 [Page 5]

Internet-Draft              Abbreviated Title                   Oct 2011


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Grounded Router flag|AR Address|     Htime     |  Willingness  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Link Code   |   Reserved    |       Link Message Size       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Neighbor Interface Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Neighbor Interface Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                             .  .  .                           :
      :                                                               :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Link Code   |   Reserved    |       Link Message Size       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Neighbor Interface Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Neighbor Interface Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                                                               :
     (etc)

                                 Figure 2

   The format of the modified hello message is based on the OLSR hello
   message.  The difference is that, we add the "Grounded Router flag"
   field and the "AR Address" field at the place of the original
   "Reserved" field.  In MR1, the value of this flag is 1.  It means
   that MR1 is a G-MR.

3.2.2.  G-MR List Format

   The proposed modified G-MR list format is shown as follows:














Ma, et al.                Expires April 3, 2012                 [Page 6]

Internet-Draft              Abbreviated Title                   Oct 2011


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Grounded MR Address                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Hop Count               |       Life Time (Second)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                 Figure 3

   There are three items in the G-MR list.  The items are described as
   follows:

   - G-MR: This field includes the CoA of the G-MR.  The function of
   this filed is to record the G-MRs which the MR can access.

   - Hop_count: This field includes the number of hops between the MR
   and the G-MR.  It is calculated by the OLSR protocol in the MANET.
   The MANET is composed by the MRs which have the same AR-CoA as the
   "AR Address" of the G-MR in this record.  The Hop_count is an
   important parameter to choose the optimized G-MR.  Generally, we
   choose the G-MR with the smallest Hop_count.

   - Life_time: This field includes the life time of the corresponding
   G-MR.  And the unit of the field is second.  When the MR receives the
   G-MRs hello message, the initial life time of this record is 16
   seconds, and the time decreases secondly.  When the life time gets to
   zero, this record is invalid, and it will be discarded.  This field
   is another important parameter to choose the G-MR.  Generally, we
   prefer the one with the longer life time.

3.2.3.  Communication Process

   1 the ARs broadcast its ID information.

   2 the MRs which can receive the AR broadcast set their status as G-MR
   and broadcast its modified OLSR hello message.  For example, in
   Fig.1, MR1 receives the AR broadcast, and sets the "Grounded Router
   flag" as 1.

   the MRs which cannot receive the AR broadcast will access the
   Internet through the G-MRs.  For example, in Fig.1, MR_2-MR_4 can
   receive the hello message of MR1.  Then, they choose MR1 as the
   gateway to the Internet.  The value of the "Grounded Router flag" in
   their hello message is 0, and they will put the information of MR1 in
   the G-MR list.



Ma, et al.                Expires April 3, 2012                 [Page 7]

Internet-Draft              Abbreviated Title                   Oct 2011


   When choosing the G-MR, we will consider the Hop_count and the
   Life_time together.  Then, the non-G-MR will make its hello message.
   It will set the "Grounded Router flag" as 0, and set the "AR Address"
   as the AR-CoA of the chosen G-MR.

   4 the MRs that have the same "AR address" will compose a MANET.  And
   the OLSR protocol is used in the MANET to route the messages.

   When an MNN wants to transmit message to the corresponding node in
   the Internet, it will firstly send the message to the MR.  Secondly,
   the MR further sends the message to the G-MR it has chosen using the
   OLSR protocol.  Thirdly, the G-MR transmits the message to its HA
   through the MR-HA bi-directional tunnel.  Fourthly, the HA of the
   G-MR will send the message to the HA of the source MR through the
   HA-HA bi-directional tunnel.  And finally, the HA of the source MR
   sends the message to the destination node in the Internet.  Then the
   MNN and the corresponding node in the Internet can communicate
   through the established path.

3.3.  Roaming NEMO communication

   The scenario of the roaming NEMO communication is described as
   follows:




























Ma, et al.                Expires April 3, 2012                 [Page 8]

Internet-Draft              Abbreviated Title                   Oct 2011


                            +---+   +---+    +---+
                            |HA2|   |HA3|    |HA4|
                            +---+   +---+    +---+
                              |2::    |3::     |4::
                              |       |        |
               +-----+1::   +---------------------+ 5::  +-----+
               | HA1 |------|     Internet        |------| HA5 |
               +-----+      ++--------------------+      +-----+
                            |                     |
                          +---+                 +---+
                          |AR1|                 |AR2|
                          +---+                 +---+
                            |1::                  |
               AR:AR1     +---+                   :
               G-MR:MR1   |MR1|                   |5::
                          +---+                 +-+-+
                            |                   |MR5|  G-MR:MRn
                       -+---+---+-             /+-+-+  AR:AR2
                        |2::    |3::          /
             AR:AR1   +---+   +---+          /
             G-MR:MR1 |MR2|   |MR3|         /
                      +---+   +---+        /
                        |4::              /
             AR:AR1   +---+              /
             G-MR:MR1 |MR4|             /
                      +---+


                    Roaming NEMO communication scenario

                                 Figure 4

   1 The NEMO with MR5 roams from AR2 to AR1, when MR5 exchanges hello
   message with the MRs under AR1, it will find the AR information is
   different from the neighbor MRs.  So, MR5 changes its AR address, set
   MR1 as its G-MR and reconfigure its CoA.

   2 MR5 sends the Binding Update (BU) request to its HA to register its
   new CoA.  The BU request will come to its G-MR firstly, so MR1
   receives the request via the route established by OLSR protocol.

   3 MR1 sends the BU request to HA1 through the MR-HA bi-direction
   tunnel.  Then HA1 looks up the destination HA address in the packet
   and further sends the request to HA5.

   4 HA5 receives the BU request, gets the new CoA of MR5, and maps it
   with the HoA of MR5 in the mapping table.  Then, HA5 sends the BU_ack
   to HA_1 according to the reverse route record.



Ma, et al.                Expires April 3, 2012                 [Page 9]

Internet-Draft              Abbreviated Title                   Oct 2011


   5 HA1 sends the BU_ack to MR1, and MR1 further sends the message to
   MR5 according to the OLSR protocol.  Finally, the procedure of the
   binding update has been finished.

3.4.  The advantages of the proposed scheme

   In the proposed scheme, the problem of pinball routing can be well
   prevented, and the transmission delay can be largely reduced.  The
   NEMO network self organizes as a MANET according to the same access
   router.  Under this condition, the communication within the NEMO can
   be directly routed via OLSR protocol, and the communication between
   the NEMO and the corresponding node in the Internet can also be more
   efficient.  Because the messages will be routed to the G-MR by OLSR
   protocol regardless of the number of the MRs nested level.  The
   messages will be sent to the destination node through the bi-
   directional tunnel between the G-MR and its HA.  So, the largest
   number of the encapsulation is two.  And when the roaming NEMO
   communicate in the range of new access point, the improved situation
   is the same as the communication between the NEMO and the Internet.


4.  IANA Considerations

   This memo includes no request to IANA.


5.  Security Considerations

   This specification operates in the security constraints and
   requirements of MIPv6 [RFC6275] and IPSec [RFC4301].


6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3626]  Clausen, T. and P. Jacquet, "Optimized Link State Routing
              Protocol (OLSR)", RFC 3626, October 2003.

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

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.



Ma, et al.                Expires April 3, 2012                [Page 10]

Internet-Draft              Abbreviated Title                   Oct 2011


6.2.  Informative References

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

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, July 2008.


Authors' Addresses

   Ma Xiaolei
   Beijing University of Post and Telecommunications
   Xi Tu Cheng Road
   Beijing, HaiDian  100876
   China

   Phone: +86 010 6228 1300
   Email: horsedavid@163.com


   Zhang Jie
   Beijing University of Post and Telecommunications
   Xi Tu Cheng Road
   Beijing, HaiDian  100876
   China

   Email: lindalary@163.com


   Jia Jintao
   Beijing University of Post and Telecommunications
   Xi Tu Cheng Road
   Beijing, HaiDian  100876
   China

   Email: jiajintao1987@163.com











Ma, et al.                Expires April 3, 2012                [Page 11]

Internet-Draft              Abbreviated Title                   Oct 2011


   Liu Yuanan
   Beijing University of Post and Telecommunications
   Xi Tu Cheng Road
   Beijing, HaiDian  100876
   China

   Email: yuliu@bupt.edu.cn












































Ma, et al.                Expires April 3, 2012                [Page 12]