[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Mobile IPv6 Working Group                                  Rajeev Koodli
INTERNET DRAFT                                     Nokia Research Center
27 February 2006                                        Syam Madanapalli
                                                                 Samsung

                     FMIPv6 Usage with DNA Protocol
                     draft-ietf-dna-fmip-00.txt

   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 document is a submission of the IETF DNA WG. Comments should be
   directed to the DNA WG mailing list, dna@eng.monash.edu.au.


   Abstract

   In this document, we describe how the Fast Mobile IPv6 Handovers
   (FMIPv6) protocol can work where DNA protocol support is available,
   but the neighborhood information, which is part of the FMIPv6
   operation, is not available.














Koodli                  Expires 27 August 2006                  [Page i]


Internet Draft           FMIPv6 and DNA Usage           27 February 2006




                                 Contents


Abstract                                                               i

 1. Introduction                                                       1

 2. FMIPv6 Operating Modes                                             2

 3. FMIPv6 with DNA                                                    2

 4. Protocol Operation                                                 3

 5. IANA Considerations                                                4

 6. Security Considerations                                            4

Intellectual Property Statement                                        4

Disclaimer of Validity                                                 5

Copyright Statement                                                    5

Acknowledgment                                                         5


   1. Introduction

   The Fast Handovers for Mobile IPv6 [1] defines a protocol to
   reduce delay and packet loss from IP protocol operations during a
   handover.  These protocol operations include movement detection,
   IP configuration and location update with a distant mobility
   agent such as a Home Agent.  When route optimization is used, the
   location update could be higher.  The FMIPv6 protocol is designed
   to effectively eliminate the delays due to movement detection and
   IP configuration latencies, while disengaging the location update
   latency from the time-critical path so that applications such as
   Voice over IP are provided real-time mobility support.

   The Detecting Network Attachment (DNA) WG is designing protocols to
   quickly detect movement and establish IP connectivity as soon as
   a mobile node is attaches to a new subnet.  DNA protocols provide
   faster and reliable mechanisms for determining the link identity
   and router discovery on the new subnet.  A DNA host uses the link
   identifier or landmark to check for the subnet change.  DNA routers
   provide FastRA without Random Delay for hosts to discover new
   router address and prefixes on the subnet.  A host implementing DNA



Koodli                  Expires 27 August 2006                  [Page 1]


Internet Draft           FMIPv6 and DNA Usage           27 February 2006


   mechanisms determines the subnet change and configures new care of
   address significantly faster than non-DNA (unmodified) hosts on
   networks with DNA support.

   The purpose of this document is to illustrate how the FMIPv6 protocol
   could make use of the DNA protocol to retain the desired handover
   performance in certain circumstances.  In order to do that, some
   background on the two operating modes of the FMIPv6 protocol is
   necessary.


   2. FMIPv6 Operating Modes

   The FMIPv6 protocol can effectively eliminate the movement detection
   and IP configuration latencies when knowledge of the neighborhood
   access points and their subnet affiliation is available.  For
   instance, a Mobile Node can query its access router to provide the
   subnet prefix, IP address and MAC address of a target router attached
   to a neighboring access point.  With this information, it builds
   a neighborhood map of Access Point Identifier to Access Router
   Information.  So, a conceptual neighborhood data structure consists
   of [AP-ID, AR-Info] tuples, with each AR-Info structure consisting of
   a router's IP address, MAC address and subnet prefix corresponding
   to the interface to which the Access Point is attached to.  Such a
   neighborhood data structure serves two purposes:  First, it allows
   a MN to map an association to a new radio connection to subnet
   information immediately, which allows it to bypass router discovery.
   Second, it allows a MN to use a new IP address on the new subnet link
   immediately, which allows it to send data packets immediately.

   There are two modes of operation assuming neighborhood information.
   In the "predictive mode", a MN is able to effect a local route update
   before departing from its current link.  That is, a MN updates its
   access router's route table to forward packets to the new IP address
   before the MN departs the current link.  In the "reactive" mode, the
   MN effects such a route update after it regains radio connectivity
   on the new link.  In both the cases, the latencies due to movement
   detection and IP configuration are eliminated.  In some cases
   however, neighborhood information may not be available.  We discuss
   this in the following section.


   3. FMIPv6 with DNA

   There are scenarios where DNA protocol operation could be beneficial
   for FMIPv6.  For instance, an access network may not be able to
   provide neighborhood information for whatever reasons, or a MN
   may end up on an unanticipated Access Point for which it has no
   neighborhood information available.  In another scenario, the



Koodli                  Expires 27 August 2006                  [Page 2]


Internet Draft           FMIPv6 and DNA Usage           27 February 2006


   neighborhood information maintained could be marked as stale using
   some measure.  Under these scenarios, if DNA protocol is available,
   it can expedite FMIPv6 handover.

   When a MN with no neighborhood information regains link connectivity,
   it performs DNA movement detection to verify roaming to a new subnet.
   If it has moved to a new subnet, it performs DNA router discovery
   to learn new subnet prefix and router addresses.  Subsequently, it
   runs Optimistic DAD [], and sends the FMIPv6 Fast Binding Update
   (FBU) message to its previous access router.  This special-case of
   reactive handover is expected to be faster than having to perform
   these operations in the absence of DNA protocol enhancements.


   4. Protocol Operation

   The following are the steps that take place when an MN with no
   neighborhood information attaches to an AP.

    1. MN (re)associates with an Access Point (AP) and gets the AP-ID
       (BSSID)

    2. The MN Looks for [AP-ID, AR info] Tuple and corresponding FMIPv6
       state.  If [AP-ID AR info] is available, MN proceeds with the
       rest of the FMIPv6 protocol.  If the tuple info is not available,
       it invokes the DNA protocol (see below).

    3. The MN sends a Router Solicitation with DNA options (if any) to
       determine if there is a subnet change and to acquire new prefixes
       on the subnet.

    4. The MN receives a Fast Router Advertisement, determines change
       in subnet, configures new care of address and makes the address
       optimistic [2].

    5. The MN sends a Fast Binding Update (FBU) to the Previous Access
       Router (PAR) directly without being encapsulated in FNA.

    6. The PAR should send a Handover Initiate (HI) message to the New
       Access Router (NAR).

    7. The NAR should send a Handover Acknowledge (HAck) message to the
       PAR.

    8. The PAR sends a Fast Binding Acknowledgement (FBack) message to
       the MN on the new link.

    9. The PAR starts tunneling the packets to the MN's new CoA.




Koodli                  Expires 27 August 2006                  [Page 3]


Internet Draft           FMIPv6 and DNA Usage           27 February 2006


   5. IANA Considerations

   There are no IANA considerations introduced by this draft.


   6. Security Considerations

   This draft is informational.  Nevertheless, the security
   considerations of the FMIPv6 protocol and the DNA protocol must be
   taken into account.  For instance, the FBU message mentioned above
   needs to be protected using a security association between the MN and
   the PAR. Similar considerations apply for the DNA protocol.


   References

   [1] R. Koodli (Editor).  Fast Handovers for Mobile IPv6 (work in
       progress).  Internet Draft, Internet Engineering Task Force.
       draft-ietf-mipshop-fast-mipv6-03.txt, October 2005.

   [2] N. Moore.  Optimistic DAD for IPv6 (work in progress).  Internet
       Draft, Internet Engineering Task Force.
       draft-iesg-http-cookies-02.txt, February 2005.


   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.




Koodli                  Expires 27 August 2006                  [Page 4]


Internet Draft           FMIPv6 and DNA Usage           27 February 2006


   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.






























Koodli                  Expires 27 August 2006                  [Page 5]