MIP6 R. Jaksa Internet-Draft C. Williams Intended status: Informational B. Sarikaya Expires: January 10, 2008 Huawei USA July 9, 2007 Mobile IPv6 Make Before Break draft-jaksa-mn-mbb-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 January 10, 2008. 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 January 10, 2008 [Page 1] Internet-Draft Mobile IPv6 MBB July 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. MCoA for MBB . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Procedure for Make-before-Break Mobile IPv6 . . . . . . . . . . 4 5. Timeout for the MIPv6 bindings . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative references . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Jaksa, et al. Expires January 10, 2008 [Page 2] Internet-Draft Mobile IPv6 MBB July 2007 1. Introduction MIPv6 is designed to support communication by caching the binding between HoA and CoA of MN, and route the packets addressed to HoA to CoA transparently. The binding cache in MIPv6 records the mapping between HoA and CoA which can be used to reroute the packets directly. Once a handover is complete the mappings between the HoA and CoA changes. However, this update causes a bit of a latency delay and thus results in packet loss. A technique called Make- before-Break (MBB) may be specified as extensions to the Mobile IPv6 protocol to allow for a handoff where service with the target access router (AR) starts before disconnection of the service with the serving access router (AR). There is no explicit support for Make- before-Break in the Mobile IPv6 protocol. A Mobile IPv6 based Make-before-break (MBB) scheme will also 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. The objective of the use of MCoA for implementing a Mobile IPv6 Make-before-Break handoff is to maintain end-to-end connectivity in the dynamically reconfigured network topology. During a handoff, the route of data through the serving AR to the target AR and to the Mobile Node must be updated to pass through this serving AR. 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 by ensuring that the handoff delays are minimal with minimum or no packet loss. 2. Terminology See [2] for mobility terminology used in this document. Jaksa, et al. Expires January 10, 2008 [Page 3] Internet-Draft Mobile IPv6 MBB July 2007 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 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. Procedure for Make-before-Break Mobile IPv6 The MBB type handoff procedure consists of the following steps: 1. The Mobile Terminal will establish a 2nd wireless connection to some base station or access point. The serving AR for this BS or AP shall broadcast information about the network topology using the IPv6 ND. 2. The Mobile IPv6 client will configure a new CoA on this 2nd interface while the 1st interface is still active. The Mobile IPv6 client will then send a MCoA registration to the respective home agent or its peers updating the mapping of the HOA to both CoAs. 3. When the Mobile IPv6 node finds the signal strength of a certain neighbor BS which is called target BS is stronger than that of serving BS, the Mobile IPv6 node shall give notice to the serving BS that it is in the overlapping cell coverage area of two adjacent BSs and that it wants to complete the handoff procedure. Part of the handoff procedure is at the Mobile IPv6 layer. Here the Home Agent or peers should be updated to now begin sending packets to the new interface and the old interface should be disconnected from an Mobile IPv6 perspective. Jaksa, et al. Expires January 10, 2008 [Page 4] Internet-Draft Mobile IPv6 MBB July 2007 4. At the target BS, the Mobile IPv6 client can now register its new CoA to its home agent (HA) and in this way redirect traffic to the target BS. During link layer registration, Mobile IPv6 registration take place in the target BS, but the Mobile IPv6 still has IP connectivity through the serving BS. In this way, the Mobile IPv6 does not suffer any delay or packet loss. 5. When the Mobile IPv6 registration request (MCoA BU) message reaches its home agent, the home agent will begin forwarding packets towards the new CoA of the target BS. 6. The Mobile Node will eventually closes the link with the serving BS after sufficient time has elapsed to ensure with high probability that no packets remain in flight from the home agent to the serving BS, while the serving BS may terminate all connections and discard MAC state machines and the context associated with the MS (i.e. information in queues, ARQ state-machine, counters, timers, etc.). 5. 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). 6. 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. 7. 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 Jaksa, et al. Expires January 10, 2008 [Page 5] Internet-Draft Mobile IPv6 MBB July 2007 lifetime of 0 or allowing this entry to expire within a desired timeframe. 8. References 8.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. 8.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-02.txt, February 2007. [4] Wakikawa, R. and T. Ernst, "Multiple Care-of Addresses Registration", Work In Progress draft-ietf-monami6-multiplecoa-02.txt , March 2007. 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 Jaksa, et al. Expires January 10, 2008 [Page 6] Internet-Draft Mobile IPv6 MBB July 2007 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 January 10, 2008 [Page 7] Internet-Draft Mobile IPv6 MBB July 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 January 10, 2008 [Page 8]