Internet DRAFT - draft-yuchi-mip6-mntomn-improve

draft-yuchi-mip6-mntomn-improve



MIP6 WG                                                      Yuzhi Ma 
                                                           Jian Zhang 
Internet Draft                             Huawei Technologies CO.,LTD  
Expires: October 12, 2006                               April 12, 2006 
                                   
 
                                      
                 Improve communication between Mobile Nodes 
                  draft-yuchi-mip6-mntomn-improve-01.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 October 12, 2006. 

Copyright Notice 

      Copyright (C) The Internet Society (2006).  All Rights Reserved. 

    

Abstract 

   Any node communicating with a mobile node in Mobile IPv6 is referred 
   to as a "correspondent node" of the mobile node, and may itself be 
 
 
 
Ma & Zhang             Expires August 12, 2006                [Page 1] 

Internet-Draft    Improve communication between MN          April 2006 
    

   either a stationary node or a mobile node. Communication between 
   mobile nodes has additional complexity. This document specifies a 
   solution to improve communication procedure between mobile nodes. 

 

Table of Contents 

    
   1. Introduction................................................2 
   2. Terminology.................................................3 
   3. Overview of the solution....................................3 
      3.1. Mobile Correspondent Node..............................3 
      3.2. Binding Refresh Request Message........................4 
   4. Protocol Operations.........................................5 
      4.1. Home Agent Operations..................................5 
      4.2. Mobile Correspondent Node Operations...................5 
      4.3. Mobile Node Operations.................................5 
   5. IANA Considerations.........................................5 
   6. Security Considerations.....................................6 
   7. Acknowledgments.............................................6 
   8. Normative References........................................7 
   Author's Addresses.............................................7 
   Intellectual Property Statement................................7 
   Disclaimer of Validity.........................................8 
   Copyright Statement............................................8 
   Acknowledgment.................................................8 
    
    

1. Introduction 

   The Mobile IPv6 base protocol does not specially specify the 
   communication procedure between two mobile nodes. According to the 
   procedure defined for mobile node and correspondent node, the 
   communication between two mobile nodes MN1 and MN2 can be described 
   as follows: 

   o Mode1: Both MN1 and MN2 are at home. They communicate with each 
      other using conventional Internet routing mechanisms. 

   o Mode2: One is at home and one is away from home. Their 
      communication procedure is same as the procedure between a mobile 
      node and a stationary correspondent node. 



 
 
Ma & Zhang            Expires October 12, 2006                [Page 2] 

Internet-Draft    Improve communication between MN          April 2006 
    

   o Mode3: Both MN1 and NM2 are away from home, and finish home 
      registration respectively. If they don't register their care-of 
      address with each other, then they communicate with each other 
      using bidirectional tunneling mode. Packets from MN1 are routed to 
      its home agent, then routed to the home agent of MN2, and finally 
      tunneled to the care-of address of MN2. Packets from MN2 to MN1 
      use the reverse procedure.  

   o Mode4: MN1 is away from home first and finishes home registration, 
      it then initiates a correspondent registration for MN2 which acts 
      as correspondent node now. MN2 moves to foreign link subsequently 
      and finishes home registration, then it may initiate a 
      correspondent registration for MN1. Finally, MN1 and MN2 can 
      communicate using route optimization. 

   A mobile node has dual nature when it communicates with another 
   mobile node. Sometimes its role is mobile node, and sometimes its 
   role is correspondent node. For this reason, the signaling messages, 
   exchanged between mobile nodes, have additional complexity when using 
   the third and fourth modes, as described above. 

   This document specifies a solution to improve signaling messages of 
   the fourth mode. How to improve the third mode is beyond the scope of 
   this specification. 

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

 
   This document uses terminology specific to Mobile IPv6 as defined 
   in section "Terminology" of RFC 3775. 
    

3. Overview of the solution 

3.1. Mobile Correspondent Node 

   In order to differentiate between the two communicating mobile nodes, 
   a new concept called ''mobile correspondent node'' is introduced. The 
   initiator of a correspondent registration acts as a mobile node, and 
   the receiver acts as a mobile correspondent node. The receiver SHOULD 
   NOT initiate a correspondent registration for the initiator, and both 
   sides SHOULD maintain this relationship in future communication.  
 
 
Ma & Zhang            Expires October 12, 2006                [Page 3] 

Internet-Draft    Improve communication between MN          April 2006 
    

   The figure below shows the typical relationship among three node in 
   mobile IPv6 network. 

    
         Node1                            Node2 
   +---------------+           +-------------------------+ 
   |               |-----------|Mobile Correspondent Node| 
   | Mobile Node   |           |                         | 
   |               |           |           Mobile Node   | 
   +---------------+           +-------------------------| 
                                                  | 
                                                  | 
                                                  |  
                               +-------------------------+ 
                               |                         | 
                               |   Correspondent Node    | 
                               |                         | 
                               +-------------------------+ 
                                          Node3 
    
    

   If Node1 initiate a correspondent registration for Node2, then it act 
   as a mobile node for Node2. If Node2 initiate a correspondent 
   registration for Node3, then it act mobile node for Node2, and it act 
   as mobile correspondent node for Node1 at the same time. Node2 should 
   maintain Binding Cash and Binding Update List respectively. 

   A mobile correspondent node SHOULD inform the mobile node of its new 
   address, when its address is changed for some reason. The method for 
   doing this is specified below. 

 
3.2. Binding Refresh Request Message 

   A Binding Refresh Request (BRR) is used by a correspondent node to 
   request a mobile node to re-establish its binding with the 
   correspondent node.  This message is typically used when the cached 
   binding is in active use but the binding's lifetime is close to 
   expiration. In this solution, this message is used to inform the 
   mobile node of a mobile correspondent node's address when its address 
   has changed or will change.  

    The following options are valid in a BRR message: 


 
 
Ma & Zhang            Expires October 12, 2006                [Page 4] 

Internet-Draft    Improve communication between MN          April 2006 
    

    The Home Address option is used to carry home address of the mobile correspondent 
    node and the Alternate Care-of address option is used to carry its Care-of address. 
     
    The encoding and format of these two option are described in [2]. 
     
 
 
4. Protocol Operations 

4.1. Home Agent Operations 

   The home agent's operations are according to [2]. 

4.2. Mobile Correspondent Node Operations 

   Due to movement, reconfiguration, or other reason, a correspondent 
   node's address may change. As a result, the correspondent node SHOULD 
   send a BRR message to the mobile node. If a correspondent node sends 
   BRR message after its address has changed, the Alternate Care-of 
   address option contains its previous address; otherwise this option 
   contains its prospective address. Obtaining a prospective address is 
   according to [3]. 

    

4.3. Mobile Node Operations 

   For delay-insensitive applications, when a mobile node receives a BRR 
   message containing a Alternate Care-of address option and the mobile 
   node has a Binding Update List entry for the address carried by the 
   option, then the mobile node should start the return routability 
   procedure which is sent to the source of the BRR message. If the 
   mobile node has a Binding Update List entry for the source of the BRR, 
   then the mobile node should start the return routability procedure 
   which is sent to the address carried by the Alternate Care-of address 
   option. Other operations of the mobile node are according to [2]. 

   For delay-sensitive applications, the return-routability procedure 
   can lead to a handoff delay unacceptable. Optimizations for reduced 
   signaling overhead between mobile nodes should be considered more 
   detail in future. 

5. IANA Considerations 

   This document has no actions for IANA. 
 
 
Ma & Zhang            Expires October 12, 2006                [Page 5] 

Internet-Draft    Improve communication between MN          April 2006 
    

6. Security Considerations 

   Section 15 of [2] outlines the Mobile IPv6 security considerations.  

   Detailed security considerations will be listed in future.  

7. Acknowledgments 

    

 



































 
 
Ma & Zhang            Expires October 12, 2006                [Page 6] 

Internet-Draft    Improve communication between MN          April 2006 
    

8. Normative References 

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

   [2]  Johnson, D., Perkins, C. and J. Arkko, ''Mobility Support in 
         IPv6'', RFC3775, June 2004. 

   [3]  Koodli, R., ''Fast Handover for Mobile IPv6'', RFC4068, July 2005. 

    

    

Author's Addresses 

   Yuzhi Ma 
   Huawei Bld.,No.3 Xinxi Rd., 
   Shang Di Information Industry Base, 
   Hai-Dian District Beijing P.R.China 
      
   Email: myz@huawei.com 
    
   Jian Li 
   Huawei Bld.,No.3 Xinxi Rd., 
   Shang Di Information Industry Base, 
   Hai-Dian District Beijing P.R.China 
      
   Email: hwzhj@huawei.com 
    
 

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 
 
 
Ma & Zhang            Expires October 12, 2006                [Page 7] 

Internet-Draft    Improve communication between MN          April 2006 
    

   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. 















 
 
Ma & Zhang            Expires October 12, 2006                [Page 8]