Network Working Group B. Sarikaya Internet-Draft F. Xia Expires: December 5, 2008 Huawei USA June 3, 2008 Proxy Mobile IPv6 Inter-Technology Handover Issue draft-sarikaya-netlmm-itho-00 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 December 5, 2008. Sarikaya & Xia Expires December 5, 2008 [Page 1] Internet-Draft PMIP Inter-Technology Handovers June 2008 Abstract Proxy Mobile IPv6 (PMIPv6) is a mobile node agnostic mobility management protocol, that is, a mobile node does not take part in any mobility signaling. In inter-technology handovers, mobile node input is required in moving IP sessions from one interface to the other. This document discusses the impact of the mobile node involvement during inter-technology handover. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 4 5. Multi-homing Issues . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative references . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Sarikaya & Xia Expires December 5, 2008 [Page 2] Internet-Draft PMIP Inter-Technology Handovers June 2008 1. Introduction Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] supports multi-homing and therefore enables inter-technology handovers. Prefixes assigned to the mobile node (MN) on one interface can be transferred to the other interface thus achieving session continuity is only possible if the new Mobile Access Gateway (MAG) sets the handoff indicator (HI) parameter in the Proxy Binding Update (PBU) correctly. So far two approaches have been proposed in order to help MAG set the parameter correctly: MAG gets the link layer support during handover and MN directly signals its willingness to move its sessions to the new interface. However there are concerns that MN signaling which is needed for MAG to do this contradicts PMIPv6 design principle of no MN involvement. Link layer support proposals include using the same interface identifier in [I-D.ietf-netlmm-mn-ar-if] and handover extensions to PMIPv6, e.g. using Fast Mobile IPv6 in [I-D.yokota-mipshop-pfmipv6]. [I-D.premec-netlmm-intertech-handover] proposes a solution for MN signaling to enable session continuity in inter-technology handovers. [I-D.soliman-netlmm-harmful] states that the use of one technology over the other is a policy decision and MN should make such a decision. Since PMIPv6 singles out any MN involvement, PMIPv6 can not help MN to use the different technologies properly. Issues related to supporting IPv4 [I-D.ietf-netlmm-pmip6-ipv4-support] during inter-technology handover are discussed in [I-D.premec-netlmm-intertech-handover]. 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 [RFC2119]. The terminology in this document is based on the definitions in [I-D.ietf-netlmm-proxymip6], in addition to the ones specified in this section: Single-Radio MN: Consider MN with two interfaces. These interfaces are implemented in such a way that MN can keep one radio module on at a given time. Sarikaya & Xia Expires December 5, 2008 [Page 3] Internet-Draft PMIP Inter-Technology Handovers June 2008 Dual/multiple-Radio MN: Consider MN with two interfaces. These interfaces are implemented in such a way that both radio modules can receive and transmit simultaneously. Inter-technology handover: Sometimes called vertical handover. A multi-homed MN communicates with one interface at any time to conserve power. Each interface can support different access technology. Inter-technology handover occurs when MN moves out of coverage of one technology and moves into the coverage area of another technology which will result in switching of the communicating interface on MN [I-D.irtf-mobopts-mpa-framework]. 3. Problem Statement When MN does an inter-technology handover, the new MAG sends a Proxy Binding Update (PBU) message to the local mobility anchor (LMA) to register the new care-of address. In the PBU, MAG sets the access technology type (ATT) and handoff indicator (HI) values. If ATT is different from the one stored in the existing binding cache entry for this MN and if HI is set to 2 (Handoff between two different interfaces of the mobile node), LMA concludes that an inter- technology handover happened and assigns the same home network prefix(es) to MN which enables IP session continuity. Setting the access technology type correctly might prove easier for MAGs that are connected to a single technology. Currently this could be the most popular case. However with the advent of fixed mobile convergence this is likely to change. MAGs in the future are expected to serve more than one access technologies. Setting the handoff indicator correctly is also not so easy. Most MAGs would tend to set HI to 1 (Attachment over a new interface) which would result in LMA setting new prefix(es) to MN. 4. Proposed Solutions There are two categories of solutions: link layer input and MN input. One of the link layer based solutions suggests using the same interface identifier, i.e. MAC address on the new interface. Previous MAG (PMAG) can then send MN's interface identifier to the new MAG using context transfer. Also the access technology type could be sent by the previous MAG. This together with the access technology type being different enables the new MAG to conclude that MN is capable and has intention to move its IP sessions to the new interface. NMAG then sets the parameters correctly enabling IP session continuity [I-D.ietf-netlmm-mn-ar-if]. Sarikaya & Xia Expires December 5, 2008 [Page 4] Internet-Draft PMIP Inter-Technology Handovers June 2008 Using the same interface identifier on a different interface means changing the MAC address of that interface. MAC addresses in some technologies like WiMAX [802.16e] are tied to certificates and thus can not be changed. In [I-D.yokota-mipshop-pfmipv6], the new MAG (NMAG) can receive MN interface identification (IID) information and based on the values received NMAG sets correctly the handoff indicator parameter. Fast Mobile IPv6 allows MAGs to receive link layer data about the MN during handoff from the access nodes (AN) such as base stations. NMAG receives MN IID on the new interface. [I-D.yokota-mipshop-pfmipv6] defines context transfer from PMAG to NMAG which includes MN IID of the previous interface. This value is compared with IID value received of the new interface and set HI value to 2 if the two values are different. The values could be different but MN may be connecting simultaneously to another network. This case is detected by NMAG if there was no context transfer because no handoff happened. In this case NMAG sets HI to 1. This scenario is valid for a dual-radio MN. This link layer input based solution does not require any changes on the link layer addresses. However an additional handover protocol needs to be used in order for MAGs to receive the link layer data for MNs during handover. The use of a different handover protocol could invalidate the solution. MN input based solution is proposed in [I-D.premec-netlmm-intertech-handover]. Router solicitation (RS) message is modified to include two bits, C flag which is set by MN to indicate that MN is capable of performing itw own mobility management and P flag which is set by MN to indicate that MN is willing to move its IP sessions accross interfaces. MAG first waits until it receives an RS message from MN and then sends an initial PBU message. If P flag is set in RS, MAG will set HI to 2. This will result in LMA assigning the same prefix(es) to MN which are returned in PBA. MAG will advertise the same prefix(es) in its router advertisement message to MN. MN will move its IP sessions to the new interface. MN input-based solution is better than link layer input based solutions because MAG knows what MN wants and acts accordingly. However the requirement for MN input defeats the purpose of PMIPv6 which is a mobility solution that does not involve MN in any mobility signaling. Also the solution is based on a single bit input from MN. As discussed later in Section 5 such a simple input is hardly enough for MN to convey its needs in case of multi-homing. Sarikaya & Xia Expires December 5, 2008 [Page 5] Internet-Draft PMIP Inter-Technology Handovers June 2008 5. Multi-homing Issues Multiple/dual radio MNs require simultaneous operations of radios which is more complex than single-radio operation. When the radio frequencies are close to each other single-radio could be the only mode of operation due to the interference. However in other cases multiple/dual mode of operation increases MN's capabilities to communicate. For single-radio MNs or when the coverage of two radios is not overlapping the inter-technology handover is simpler to handle. It is clear that IP sessions need to be moved to the new interface. [I-D.soliman-netlmm-harmful] points out several deficiences of netlmm (in this document called PMIPv6) in case of multiple/dual radio operation. If the networks are operated by different companies, i.e. inter- domain handover and both networks support PMIPv6 then in case of inter-technology handover the current network will try to keep IP sessions rather than moving them to the next network. In case of link layer input solutions discussed in Section 4 PMAG can simply refuse to context transfer the required interface identifier and access technology type information to NMAG. Only MN input can enable NMAG to move IP sessions to the new interface. For multiple/dual radio MNs, inter-technology handover brings the possibility of partially moving IP sessions to each interface even in intra-domain handover where the networks are operated by the same company. MN should be able to use different links for different applications depending on link quality/capabilities. Recent work, e.g. [I-D.ietf-monami6-multiplecoa] and [I-D.ietf-mext-flow-binding] shows how this can be done. The main component of these solutions is that MN input is required which is singled out in PMIPv6. For multiple/dual radio MNs, in inter-technology handover the use of one interface or the other becomes a policy decision. Leaving this decision to MN is the right thing to do because MN knows the applications that it wants to run and MN can best decide which link layer is best to run each application. Using PMIPv6, such a possibility would totally disappear. PMIPv6 protocol operation will not encounter any difficulties if MN has a single interface or if MN is single-radio and the coverage of different radios is not overlapping. For multiple/dual mode MNs it is better to use host mobility protocols [RFC3775] in order to fully utilize its interface capabilities to run the applications and manage the flows by itself. Using PMIPv6 even if MN input is allowed, the Sarikaya & Xia Expires December 5, 2008 [Page 6] Internet-Draft PMIP Inter-Technology Handovers June 2008 amount of data that can be passed to MAG will be very limited. 6. Security Considerations This document is informational and does not define any new messages. PMIPv6 security procedures apply. 7. IANA considerations None. 8. Acknowledgements TBD. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-18 (work in progress), May 2008. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [I-D.yokota-mipshop-pfmipv6] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for PMIPv6", draft-yokota-mipshop-pfmipv6-02 (work in progress), February 2008. [I-D.ietf-netlmm-mn-ar-if] Laganier, J., Narayanan, S., and P. McCann, "Interface between a Proxy MIPv6 Mobility Access Gateway and a Mobile Node", draft-ietf-netlmm-mn-ar-if-03 (work in progress), Sarikaya & Xia Expires December 5, 2008 [Page 7] Internet-Draft PMIP Inter-Technology Handovers June 2008 February 2008. [I-D.premec-netlmm-intertech-handover] Premec, D. and T. Savolainen, "Inter-technology handover in netlmm domain", draft-premec-netlmm-intertech-handover-00 (work in progress), April 2008. [I-D.irtf-mobopts-mpa-framework] Dutta, A., Fajardo, V., Ohba, Y., Taniuchi, K., and H. Schulzrinne, "A Framework of Media-Independent Pre- Authentication (MPA) for Inter- domain Handover Optimization", draft-irtf-mobopts-mpa-framework-02 (work in progress), February 2008. [I-D.soliman-netlmm-harmful] Soliman, H., "Network-based mobility considered harmful", draft-soliman-netlmm-harmful-00 (work in progress), May 2006. [I-D.ietf-monami6-multiplecoa] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-08 (work in progress), May 2008. [I-D.ietf-mext-flow-binding] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-ietf-mext-flow-binding-00 (work in progress), May 2008. [802.16e] Institute of Electrical and Electronics Engineer, "Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", IEEE 802.16e/D12. 9.2. Informative references [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-03 (work in progress), May 2008. Sarikaya & Xia Expires December 5, 2008 [Page 8] Internet-Draft PMIP Inter-Technology Handovers June 2008 Authors' Addresses Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Sarikaya & Xia Expires December 5, 2008 [Page 9] Internet-Draft PMIP Inter-Technology Handovers June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Sarikaya & Xia Expires December 5, 2008 [Page 10]