DNA Working Group R. Koodli
Internet-Draft Nokia Research Center
Expires: January 9, 2006 S. Madanapalli
Samsung ISO
July 8, 2005
FMIPv6 Usage with DNA Protocol
draft-koodli-dna-fmip-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 January 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
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 & Madanapalli Expires January 9, 2006 [Page 1]
Internet-Draft FMIPv6 Usage with DNA Protocol July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. FMIPv6 Operating Modes . . . . . . . . . . . . . . . . . . . . 3
3. FMIPv6 with DNA . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . 7
Koodli & Madanapalli Expires January 9, 2006 [Page 2]
Internet-Draft FMIPv6 Usage with DNA Protocol July 2005
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
between cells or points of attachment. These protocol operations
include movement detection, IP configuration and location update with
a distant mobility agent such as a Home Agent. 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 link changes and enable establishment of IP
connectivity as soon as a mobile node is attached to a new subnet.
Compared to existing IPv6 router discovery mechanisms, DNA protocols
provide faster and reliable mechanisms for determining the link
identity and router discovery on the new subnet. DNA routers send
augmented Router Advertisement information which uniquely identifies
a link. These RAs are sent without delay providing rapid
notification of link change. A host implementing DNA mechanisms
determines the subnet change and configures new care of address
significantly faster than non-DNA (unmodified) hosts on networks with
DNA support, if post arrival link change detection is required.
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.
Koodli & Madanapalli Expires January 9, 2006 [Page 3]
Internet-Draft FMIPv6 Usage with DNA Protocol July 2005
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
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 check if it has changed IP
subnet. DNA performs router discovery, and in the process learns new
subnet prefixes and router addresses. Subsequently, it runs address
configuration, and uses Optimistic DAD [2], and sends the FMIPv6 Fast
Binding Update (FBU) message to its previous access router (PAR).
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 searches for the [AP-ID, AR info] Tuple in its
neighborhood data structure corresponding to the AP-ID of the
Access Point it just (re)associated. 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).
Koodli & Madanapalli Expires January 9, 2006 [Page 4]
Internet-Draft FMIPv6 Usage with DNA Protocol July 2005
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 DNA 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.
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 protocols which
may be able to take advantage of SEND for Router Discovery, if
available [3].
7. Acknowledgements
The authors would like to thank Greg Daley for his initiative, and
suggestions to improve this draft.
8. References
[1] Koodli, R., "Fast Handovers for Mobile IPv6,
draft-ietf-mipshop-fast-mipv6-03.txt (work in progress)",
October 2004.
[2] Moore, N., "Optimistic Duplicate Address Detection for IPv6,
draft-ietf-ipv6-optimistic-dad-05.txt (work in progress)",
February 2005.
[3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
Koodli & Madanapalli Expires January 9, 2006 [Page 5]
Internet-Draft FMIPv6 Usage with DNA Protocol July 2005
Authors' Addresses
Rajeev Koodli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043 USA
Phone: +1 650 625 2359
Email: Rajeev.Koodli@nokia.com
Syam Madanapalli
Samsung ISO
No. 3/1 Millers Road
Bangalore-560 052, India
Phone: +91 80 51197777
Email: syam@samsung.com
Koodli & Madanapalli Expires January 9, 2006 [Page 6]
Internet-Draft FMIPv6 Usage with DNA Protocol July 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.
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 (2005). 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 & Madanapalli Expires January 9, 2006 [Page 7]