MIP6 R. Jaksa
Internet-Draft C. Williams
Intended status: Informational B. Sarikaya
Expires: September 1, 2007 Huawei USA
February 28, 2007
Mobile IPv6 Make Before Break
draft-jaksa-mn-mbb-00.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 September 1, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This draft documents the use of MCoA (Multiple Care-of Address)
method defined in [4] in order to facilitate a Make Before Break
within the Mobile IPv6 protocol [1] . This draft is intended to
document the usage of MCoA for achieving Make Before Break behavior.
The current base Mobile IPv6 specification [1] doesn't include MCoA.
With that draft currently under consideration it is possible to use
these extensions for MBB.
Jaksa, et al. Expires September 1, 2007 [Page 1]
Internet-Draft Mobile IPv6 MBB February 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MCoA for MBB . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Timeout for the MIPv6 bindings . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative references . . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
Intellectual Property and Copyright Statements . . . . . . . . . . 6
Jaksa, et al. Expires September 1, 2007 [Page 2]
Internet-Draft Mobile IPv6 MBB February 2007
1. Introduction
Make before break (MBB) schemes are likely to depend on the viability
of receiving packets over multiple communications links during the
handover. In a make-before-break scenario, the MN is, for a given
period of time, reachable at both the old and the new IP address. A
way to achieve this is through the use of registering Multiple
Care-of Addresses simultaneously [3] . A method already exists in
MCoA [4] to register more than one care-of address.
As has been discussed IEEE Std 802.16e-2005 defines a make-before-
break HO as a HO where service with the target BS starts before
disconnection of the service with the previous serving BS. In this
standard different HO options are specified including macro diversity
handover (MDHO) which should allow for the make-before-break feature
as during HO in the downlink two or more BSs are transmitting the
same MAC/PHY protocol data unit PDU) and in the uplink (UL) two or
more BSs are receiving the same PDU from the MS, such that diversity
combining of the received PDU can be performed as well at the MS as
among the BSs.
Make-before-break connections deliver seamless mobile networking for
voice, video and data applications
2. Terminology
See [2] for mobility terminology used in this document.
3. MCoA for MBB
Mobile IPv6 [1] defines a process during which a mobile node sends a
Binding Update to its home agent or a correspondent node, causing a
binding for the mobile node to be registered. To achieve an inherit
Make Before Break Algorithm within the core Mobile IPv6 protocol, the
HA needs to be able to continue to receive packets from the old and
new points of attachment (CoA in MIP) at the IP level, for which
multiple bindings are required. Note that this is different from bi-
casting - there is no need to send duplicate packets down multiple
interfaces (that could be an option, but certainly not required). A
draft already exist to register multiple care-of addresses for Mobile
IPv6 [1] [4] . With MBB it is required to have 2 interfaces active
at the same time. MCoA With MCoA draft [4] the MN registers its
Care-of Addresses by sending a Binding Update with a Binding Unique
Identifier sub-option This means that during handoff, a mobile node
maintains two independent conversations with two access routers at
the same time. Even after what can be lengthy outages, Mobile IPv6
Jaksa, et al. Expires September 1, 2007 [Page 3]
Internet-Draft Mobile IPv6 MBB February 2007
will ensure that IP connectivity is reestablished. Using Mobile IPv6
with MBB will allow operators can build a single network to support
several different wireless technologies that use the same mobility
management system and MBB handoff throughout.
4. Timeout for the MIPv6 bindings
The Home Agent needs to know which binding to forward the continued
traffic flow to. This amounts to begin forwarding to the new CoA
once the new interface is up and connected. The old binding should
time-out once this connection is up and running. This can be done by
sending a binding update with lifetime 0 to the HA for the old
interface once it is no longer required or to find an appropriate
time-out to allow this binding entry to expire naturally when the
continued traffic flow is moved to the new CoA (or new interface).
5. Security Considerations
If a MCoA is used for achieving MBB, then identity spoofing and
injecting traffic may occur since an adversary can use a nearly
arbitrary endpoint identifier to achieve the desired result.
6. Conclusion
This document uses MCoA [4] as a recipe for adding Make Before Break
to the core Mobile IPv6 specification. Make Before Break is used as
a technique used to non-intrusively alter the path of a Mobile IPv6
flow. Existing Mobile IP based mobility algorithms not sufficient
for make-before-break handoff mechanisms. MCoA and the unique
Binding Identifier suboption provides a recipe for achieving MBB in
the base Mobile IPv6 protocol. Tear down of the binding cache entry
for the previous interface can be done through sending a BU with
lifetime of 0 or allowing this entry to expire within a desired
timeframe.
7. References
7.1. Normative references
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
Jaksa, et al. Expires September 1, 2007 [Page 4]
Internet-Draft Mobile IPv6 MBB February 2007
7.2. Informative References
[3] Montavont, N., Wakikawa, R., and T. Ernst, "Analysis of
Multihoming in Mobile IPv6", Work In
Progress draft-ietf-monami6-mipv6-analysis-00.txt,
February 2006.
[4] Wakikawa, R. and T. Ernst, "Multiple Care-of Addresses
Registration", Work In
Progress draft-ietf-monami6-multiplecoa-01.txt , October 2006.
Authors' Addresses
Robert Jaksa
Huawei USA
1700 Alma Dr., Suite 102
Plano, Tx 75075
USA
Phone: 1 972 509 5599
Email: rjaksa@futurewei.com
Carl Williams
Huawei USA
Consultant, Palo Alto, CA 94306
USA
Phone: +1.650.279.5903
Email: carlw@mcsr-labs.org
Bechet Sarikaya
Huawei USA
1700 Alma Dr., Suite 102
Plano, Tx 75075
USA
Phone: 1 972 509 5599
Email: bsarikaya@huawei.com
Jaksa, et al. Expires September 1, 2007 [Page 5]
Internet-Draft Mobile IPv6 MBB February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Jaksa, et al. Expires September 1, 2007 [Page 6]