One document matched: draft-jaehwoon-autoconf-mmbr-02.txt

Differences from draft-jaehwoon-autoconf-mmbr-01.txt


autoconf Working Group                                    Jaehwoon Lee 
Internet-Draft                                      Dongguk University 
Intended status: Informational                            Sanghynn Ahn
Expires: August 27, 2010                           University of Seoul                                                         
                                                          Younghan Kim
                                                   Soongsil University
                                                     February 28, 2010
                                   
                                       
          Address Autoconfiguration for MANET with Multiple MBRs 
                   draft-jaehwoon-autoconf-mmbr-02.txt 

Abstract 

   In order to allow the subordinate MANET to be connected to the 
   external network, the MANET border router (MBR) has been defined. For 
   providing scalability and reliability to the subordinate MANET, 
   multiple MBRs may be deployed. One of the issues on the subordinate 
   MANET with multiple MBRs is which network prefixes are to be 
   advertised by MBRs. In the case when MBRs advertise different network 
   prefixes, if a MANET node changes its default MBR to a new one, the 
   node may have to transmit packets via non-optimal paths to keep using 
   the existing connection to the previous MBR, or change its address by 
   using the network prefix information from the new MBR. 
   In the former case, the MANET node may not communicate with the MBR 
   due to MANET partitioning. In the latter case, on-going sessions can 
   be terminated because of the address change. In this draft, we define 
   a PMIPv6 based address autoconfiguration mechanism that enables MANET 
   nodes to operate properly when all MBRs advertise the same network 
   prefix in the subordinate MANET.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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.




Jaehwoon Lee, et al.        Expires Aug. 27, 2010           [Page 1]

Internet-Draft Address Autoconfiguration for multiple MBRs Feb. 28, 2010


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

   This Internet-Draft will expire on August 27, 2010.

Copyright Notice

   Copyright (c) 2010 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 BSD License.



Table of Contents 

    
   1. Introduction..................................................3 
   2. Terminology...................................................4 
   3. Message format................................................4
      3.1 Registration Request message..............................4
      3.2 Registration Confirmation message.........................4
   4. Protocol operation............................................4 
   5. Security Considerations.......................................7 
   6. IANA Considerations...........................................7 
   References.......................................................7 
   Author's Addresses...............................................8 
















Jaehwoon Lee, et al.        Expires Aug. 27, 2010           [Page 2]

Internet-Draft Address Autoconfiguration for multiple MBRs Feb. 28, 2010


1. Introduction 

   The mobile ad hoc network (MANET) enables mobile nodes to communicate 
   via multiple wireless hops without the need of any wired 
   infrastructure. In a MANET, two nodes not within transmission 
   range have to deliver data to each other through other intermediate 
   nodes. For forwarding packets destined to other nodes, each node must 
   have the routing capability, i.e., the mechanism for establishing 
   data delivery routes between any pair of source and destination 
   nodes. The IETF MANET working group has defined route setup 
   mechanisms for delivering data between MANET nodes. Especially for an 
   ad hoc network such as the MANET, the mechanism that can allow 
   nodes to configure their addresses autonomically is more desirable 
   than the static address configuration mechanism since the former has 
   less configuration and management overhead due to its omission of 
   manual intervention.

   MANETs can be classified into the subordinate MANET or the 
   autonomous MANET depending on whether it is connected to the external 
   network or not [1]. The MANET border router (MBR) which is a gateway 
   device connecting the MANET with the external network has been 
   defined for the subordinate MANET. As the number of nodes in the 
   MANET increases, the amount of traffic between the MANET and the 
   Internet increases, so the MBR gets overloaded, resulting in the 
   overall network performance degradation. To overcome this problem, 
   multiple MBRs can be used for the Internet connectivity [2]. 
   Mechanisms in which each MBR advertises a different network prefix 
   have been proposed for the MANET with multiple MBRs [3-4]. However, 
   in these mechanisms, if a node moves to another place, it sends 
   packets via non-optimal paths to maintain its connection to the 
   previous MBR, or it changes its address by using the network prefix 
   delivered from the new MBR. An on-going session may get terminated 
   because of MANET partitioning in the formal case or the address 
   change in the latter case.

   In this draft, we define an address autoconfiguration mechanism for
   the subordinate MANET with multiple MBRs which advertise the same
   network prefix. In the proposed mechanism, since all MBRs advertise
   the same network prefix, even a node moves it can still use its
   preconfigured address. That means that no address reconfiguration
   is needed in case of node movement, so the proposed mechanism has
   the advantage of keeping on maintaining its existing session(s).
   Furthermore, under node movement, a node can still find an optimized
   path without changing its address because it can choose the MBR
   that can be reached via the minimum number of hops. 





 
Jaehwoon Lee, et al.        Expires Aug. 27, 2010           [Page 3]

Internet-Draft Address Autoconfiguration for multiple MBRs Feb. 28, 2010


2. Terminology
   TBD.

3. Message Format

3.1 Registration Request (RR) Message
   TBD
   
3.2 Registration Confirmation (RC) Message
   TBD

4. Protocol Operation



      MN       MBR1(MAG1)          MBR2(MAG2)      LMA   (Internet)   CN
       |           |                |                  |              |
       |<----------|                |                  |              |
      ICMP SERA message             |                  |              |
 (Configure IPv6 address to MANET interface)           |              |
       |<--------->|                |                  |              |
 (DHCP with prefix delegation)      |                  |              |
       |---------->|                |                  |              |
       |RR message |                |                  |              |
       |           |---------------------------------->|              |
       |           |        PBU message  (Create Binding Cache Entry) |
       |           |<----------------------------------|              |
       |           |        PBAck message              |              |
       |<----------|                |                  |              |
       |RC message |                |                  |              |
       |<--------->|<=================================>|<------------>|
       |    Data packet transfer between MN and CN via MBR1 and LMA   |
 (MN changes its default gateway from MBR1 to MBR2)    |              |
       |<---------------------------|                  |              |
       |     ICMP SERA message      |                  |              |
       |--------------------------->|                  |              |
       |        RR message          |                  |              |
       |           |                |----------------->|              |
       |           |                |   PBU message    |              |
       |           |                |   (Update Binding Cache Entry   |
       |           |                |<-----------------|              |
       |           |                |   PBAck message  |              |
       |<---------------------------|                  |              |
       |         RC message         |                  |              |
       |<-------------------------->|<================>|<------------>|
       |    Data packet transfer between MN and CN via MBR2 and LMA   | 
       |           |                |                  |              |
                  Figure 1: Message exchange scenario



Jaehwoon Lee, et al.        Expires Aug. 27, 2010           [Page 4]

Internet-Draft Address Autoconfiguration for multiple MBRs Feb. 28, 2010


   The message exchange scenario considered in this draft is depicted
   in figure 1. The network is composed of the external network such as
   the global Internet, a PMIPv6 domain and a MANET. The operation of
   the PMIPv6 protocol is defined in [5]. In the PMIPv6 domain, a local
   mobility anchor (LMA) is located and acts as a kind of home agent
   (HA). The MANET can be connected to the PMIPv6 domain through a
   multiple number of mobility access gateways (MBRs) and an MBR
   operates as a mobility access gateway (MAG) in the PMIPv6 domain.
   One network prefix is assigned to the MANET, and each MBR
   periodically advertises scope-extended Router Advertisement
   (SERA) messages to the entire MANET [6]. The SERA message is defined 
   to resolve the duplicate packet reception problem which can occur in 
   a multi-hop wireless network such as the MANET. The network prefix 
   assigned to the MANET and the address of the MBR originating the 
   SERA message are included in the message. Even though the different 
   MBR address information is included in the SERA message sent by 
   different MBR, the network prefix that can be delived by subnet 
   masking the MBR address with the prefix length is the same. In other 
   words, the MBRs connecting the MANET and the global Internet 
   advertise the same network prefix.

   When a MANET node (MN) connects to the MANET for the first
   time, it waits for a SERA message from a MBR. Assume that the SERA 
   message from MBR1 arrives at the MN first. Then the MN configures 
   the IPv6 address of its MANET interface by utilizing the stateless 
   address autoconfiguration mechanism based on its MAC address and 
   the network prefix obtained from the MBR1 address and the network 
   prefix length [7]. After that, the MN sets the MBR1 address in the 
   SERA message as the address of its default gateway, and stores the 
   distance to MBR1 which can be calculated with
   '255 - the Cur Hop Limit in the scope-extended RA message + 1'
   in its routing table. In addition to that, the MN sets the value in
   the source IP address field of the IP packet having the received
   SERA message as the next-hop address to its default gateway and 
   records this information in its routing table. Then, the MN decreases
   the Cur Hop Limit value in the received SERA message by 1 and 
   broadcasts the modified SERA message. Also, the MN sends a 
   Registration Request (RR) message to MBR1. Upon receiving the RR 
   message, MBR1 sends a Proxy Binding Update (PBU) message with the 
   MN address to the LMA. The LMA stores the binding information for 
   the MN and MBR1 and sends a Proxy Binding Acknowledgement (PBAck)   
   message to MBR1. After that, a tunnel between the LMA and MBR1 is 
   established for the MN. After receiving the PBAck message from the 
   LMA, MBR1 sends a Registration Confirmation (RC) message to the MN.
   Now, MBR1 becomes the default gateway for the node and the MN can 
   communicate with any host in the global Internet. The MN uses the 
   IP-in-IP encapsulation or routing header in order for the traffic
   sent from the MN to be delivered to the default gateway of the node.



Jaehwoon Lee, et al.        Expires Aug. 27, 2010           [Page 5]

Internet-Draft Address Autoconfiguration for multiple MBRs Feb. 28, 2010


   If MBR1 receives a packet from the MN, it transmits the packet to the
   LMA via the established tunnel which, in turn, forwards it to the 
   destination host in the global Internet.

   Since SERA messages are periodically advertised by each MBR, a node
   can receive multiple SERA messages advertised by other MBRs even 
   after it has configured an IPv6 address of is interface. The 
   operation of a MN receiving a SERA message is as follow. Once a 
   MN receives a SERA message broadcasted by the neighbor node which is 
   set as the next-hop node to its default gateway, the MN updates its 
   corresponding routing table entry using the information in the 
   received SERA message. That is, the MN determines the distance to its 
   default gateway based on the Cur Hop Limit value in the SERA message.
   
   If the MBR address (i.e., MBR2) in the SERA message is different from 
   its current default gateway, the MN sends a RR message to MBR2 and 
   broadcasts the SERA message throught the MANET. If the MN receives a 
   RC message from MBR2, it updates its routing table entry related to 
   the default gateway information.
   
   If the MN receives a SERA message from another neighbor node which is 
   not the next-hop node to the default gateway, the MN compares the 
   distance to the MBR having sent the SERA message (which can be 
   computed from the CUR Hop Limit valued in the SERA message) and that 
   to its default gateway. If the fomer one is larger than or equal to 
   the latter, it discards the received SERA message. Otherwise, after 
   broadcasting the SERA message, it updates its corresponding routing
   table entry based on the information in the received SERA mesage as 
   follows. At first, the MN checks the MBR address in the SERA message. 
   If the MBR address in the SERA message is the same as its current 
   default gateway, the MN changes the distance to the default gateway 
   to the distance value obtained from the SERA message and sets the 
   node sending the SERA message as the next-hop node to the default 
   gateway.
   
   If the MBR address (i.e., MBR2) in the SERA message is different from 
   the address of its default gateway, the MN sends a RR message to 
   MBR2. If the MN receives a RC message for MBR2, it updates its 
   routing table entry related to the default gateway information. In 
   this case, even when the default gateway is changed, the network 
   prefix for the MANET is kept the same, so the MN can keep on 
   maintaining its on-going session(s) because it can still use its 
   IPv6 address configured on its MANET interface. Furthermore, even if 
   the MN changes its default gateway, the IPv6 address configured on 
   its MANET interface is kept the same. Thus, if the packets from a 
   host in the Internet arrive at the MBR chosen as its previous default 
   gateway before the registration process is completed, they can be 
   delivered to the MN via the previous default gateway, so no packet 
   loss due to address changes will happen.


Jaehwoon Lee, et al.        Expires Aug. 27, 2010           [Page 6]

Internet-Draft Address Autoconfiguration for multiple MBRs Feb. 28, 2010



   If the MN does not receive a SERA message from its next-hop node to 
   the default gateway for some time duration or it determines that the 
   next-hop node is no more its neighbor node, the MN deletes the 
   default gateway related entry from its routing table.
      

   
5. Security Consideration

   TBD.


6. IANA Considerations

   TBD.

   
References

   [1] E. Baccelli et al., "Address Autoconfiguration for MANET:
       Terminology and Problem Statement", draft-ietf-autoconf-
       statement-04, Work in progress, Feb. 2008.

   [2] S. Ruffino, P. Stupar and T. Clausen, "Autoconfiguration in a 
       MANET: connectivity scenarios and technical issues", draft-
       ruffino-manet-autoconf-scenarios-00, work in progress, Oct. 2004.

   [3] S. Ruffino and P. Stupar, "Automatic configuration of IPv6 
       addresses for MANET with multiple gateways (AMG)",
       draft-ruffino-manet-autoconf-multigw-03, work in progress,
       June 2006.
       
   [4] C. Jelger, T. Noel and A. Frey, "Gateway and address 
       autoconfiguration for IPv6 adhoc networks", draft-jelger-manet-
       gateway-autoconf-v6-02, work in progress, apr. 2004.

   [5] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and 
       B. Patil, "Proxy Mobile IPv6", RFC 5213, Aug. 2008.

   [6] J. H. Lee, S. Ahn, Y. Kim, Y. Kim and S. Kim, "Scope-Extended
       Router Advertisement for Connected MANETs", draft-jaehwoon-
       autoconf-sera-00, Work in progress, July 2008.
          
   [7] S. Thomson and T. Narten, "IPv6 Stateless Address A
       utoconfiguration", RFC 2462, Dec. 1998.





Jaehwoon Lee, et al.        Expires Aug. 27, 2010           [Page 7]

Internet-Draft Address Autoconfiguration for multiple MBRs Feb. 28, 2010


Author's Addresses

   Jaehwoon Lee 
   Dongguk University
   26, 3-ga Pil-dong, Chung-gu
   Seoul 100-715, KOREA  
   Email: jaehwoon@dongguk.edu

   Sanghyun Ahn
   University of Seoul
   90, Cheonnong-dong, Tongdaemun-gu
   Seoul 130-743, KOREA
   Email: ahn@uos.ac.kr

   Younghan Kim
   Soongsil University
   11F Hyungnam Engineering Bldg. 317, Sangdo-Dong,
   Dongjak-Gu, Seoul 156-743 Korea
   E-main: yhkim@dcn.ssu.ac.kr   
































Jaehwoon Lee, et al.        Expires Aug. 27, 2010           [Page 8]


PAFTECH AB 2003-20262026-04-24 01:23:15