| Network Working Group | X. Ma |
| Internet-Draft | J. Zhang |
| Intended status: Informational | J. Jia |
| Y. Liu | |
| Beijing University of Post and Telecommunications | |
| Oct 2011 |
The MANEMO Route Optimization in the Rescue Operation
draft-zhangjie-manemo-ro-00
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.
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."
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 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.
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.
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.
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.
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.
Figure 1 depicts the structure of nested mobile networks.
+---+ +---+ +---+ +--+--+
|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
The proposed modified hello message format is shown as follows:
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)
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.
The proposed modified G-MR list format is shown as follows:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
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.
The scenario of the roaming NEMO communication is described as follows:
+---+ +---+ +---+
|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
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.
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.
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.
This memo includes no request to IANA.
This specification operates in the security constraints and requirements of MIPv6 [RFC6275] and IPSec [RFC4301].
| [RFC6275] | Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. |
| [RFC3963] | Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. |
| [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. |
| [RFC4301] | Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. |
| [RFC3753] | Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. |
| [RFC5340] | Coltun, R., Ferguson, D., Moy, J. and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. |