Network Working Group H. Yokota Internet-Draft KDDI Lab Intended status: Standards Track S. Gundavelli Expires: February 23, 2009 K. Leung Cisco August 22, 2008 Inter-Technology Handoff support in Mobile Node for Proxy Mobile IPv6 draft-yokota-netlmm-pmipv6-mn-itho-support-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 February 23, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Yokota, et al. Expires February 23, 2009 [Page 1] Internet-Draft PMIPv6 Inter-Tech HO Support August 2008 Abstract Proxy Mobile IPv6 supports a handoff between different access technologies, by which the assigned IP address is preserved regardless of the access technology type. From the perspective of the mobile node, this involves the change of the network interfaces, through which the IP address is assigned and the IP session is established. Some implementations, however, do not assume this interface switching in the middle of the session and it could cause a disconnection by the event of unavailability of the current interface; hence it is not guaranteed to be able to maintain the IP session simply by assigning the same IP address to the new interface. This document analyzes the handling of the network interfaces on the mobile node and presents several measures to avoid a disconnection due to the interface switching. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Handover Scenarios and requirements on the mobile node . . . . 5 4. Operational issues . . . . . . . . . . . . . . . . . . . . . . 6 5. Example solutions for inter-technology handover support. . . . 7 5.1. Virtual interface adaptor . . . . . . . . . . . . . . . . 7 5.2. Direct support . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Yokota, et al. Expires February 23, 2009 [Page 2] Internet-Draft PMIPv6 Inter-Tech HO Support August 2008 1. Requirements notation 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 [1]. Yokota, et al. Expires February 23, 2009 [Page 3] Internet-Draft PMIPv6 Inter-Tech HO Support August 2008 2. Introduction RFC4831[3] addresses the support of an unmodified host as one of the goals for NETLMM; however, it also foresees additional functions in the physical and medium access control layers, typically wireless interface driver, on the mobile node for handover support or movement detection. This issue becomes more visible when Proxy Mobile IPv6 [2] is applied to inter-technology handoff, where the mobile node handles multiple interfaces. When the mobile node hands off from one access technology to another, the corresponding interfaces are also switched. Even if the same IP address (MN-HoA) is assigned to both interfaces, this interface switching could cause some problem. When some application on the mobile node establishes a session, it binds a descriptor to the assigned IP address via the socket interface. When this IP address is internally bound to one network interface, at the time when this interface is detached from the network and/or another interface is attached to the network, this session may lose connectivity. Also, some point-to-point link device is ephemeral, that is, it exists only the link-layer connection is established. If this is the case, the session on that link may not be transferred unless a new connection is established in a timely manner. This document exhibits possible solutions to maintain sessions when inter-technology handover is performed, whereby the network has only to care about the IP address preservation. The scope of this document is limited to the internal behavior of the mobile node and no interaction between the mobile node and network is specified. Yokota, et al. Expires February 23, 2009 [Page 4] Internet-Draft PMIPv6 Inter-Tech HO Support August 2008 3. Handover Scenarios and requirements on the mobile node Suppose the mobile node has two interfaces. Depending on the policy and/or radio environment, the following handover scenarios can be considered. IF#1 IF#2 (a) -----------------| |**************** T1 < T2 IF#1 IF#2 (b) -------------------||****************** T1 = T2 IF#1 (c) ----------------------| IF#2 |********************* T2 < T1 Figure 1: Handoff scenarios (a) There is a gap between the time when IF#1 is detached or deactivated (T1) and the time when IF#2 is attached or activated (T2). During the time segment (T1, T2), the connectivity to the network is lost; however, the mobile node MUST retain all the sessions associated with the MN-HoA. For incoming packets, all that are sent to IF#1 after T1 and all that are sent to IF#2 before T2 will be lost if there is no buffering mechanism on the network side (there is nothing to do on the mobile node side). For outgoing packets, There SHOULD be a buffer on the mobile node and the active interface SHOULD always be detected and selected. (b) Immediately after IF#1 is detached or deactivated, IF#2 is attached or activated. For incoming packets, packet loss can be avoided if the active interface is always detected and selected. For outgoing packets, no buffer is required on the client side since always one interface is active at any point in time. (c) IF#2 is attached or activated (T2) before IF#1 is detached or deactivated (T1). In this case, both interfaces are active during the time segment (T2, T1). For incoming packets, both interfaces SHOULD be able to receive them. For outgoing packets, either one of the two interfaces SHOULD be selected at any given time. Yokota, et al. Expires February 23, 2009 [Page 5] Internet-Draft PMIPv6 Inter-Tech HO Support August 2008 4. Operational issues This section exemplifies several operational issues on the mobile node that can affect the behavior of inter-technology handoff. Some of those issues are attributed to the constraints of hardware and/or software implementations and also dependent on the operating system in use on the mobile node. o Simultaneous use of multiple interfaces: Even if the mobile node has multiple interfaces, there could be some limitation that only one interface can be active at any given time due to the internal radio interferences. This mode of operation is called the "single radio mode" and only scenario (a) (or ideally (b)) is feasible. On the other hand, if multiple interfaces can be active at the same time, which is called the "dual (or multi) radio mode", scenario (c) becomes feasible. o Address binding policy: Some operating system does not allow assigning the same IP address to multiple active interfaces. If this is the case, even if the mobile node can run in dual radio mode, only scenario (a) (or ideally (b)) is feasible. In the worst case, at the time when the current interface is turned down (T1), on-going IP session(s) is/ are terminated. o Relationship between network interfaces: When a point-to-point connection (e.g., PPP) is established for IP session(s), some operating system cannot retain that connection if the underlying interface (e.g., radio) becomes unavailable. If this point-to-point connection is tightly coupled with the underlying interface, neither of the handoff scenarios is feasible. Yokota, et al. Expires February 23, 2009 [Page 6] Internet-Draft PMIPv6 Inter-Tech HO Support August 2008 5. Example solutions for inter-technology handover support. There are multiple ways to retain sessions under the inter-technology handover accompanying the switching of interfaces. This section describes example (non exclusive) solutions. 5.1. Virtual interface adaptor In this solution, an intermediate logical interface called "virtual interface adaptor (VIA)" is used to hide the link movement from the IP layer. The VIA is not bound to any physical interface and the MN- HoA is assigned to this adaptor. Even if the active link is changed or deleted, the transport session is not aware of it. +----------------------------+ | TCP/UDP | Session to IP +->| | address binding | +----------------------------+ +->| IP | IP to VIA +->| | binding | +----------------------------+ +->| Virtual IF Adaptor | VIA to physical +->| (MN-HoA) | IF binding | +----------------------------+ +->| L2 | L2 | | L2 | |(IF#1)|(IF#2)| ..... |(IF#n)| +------+------+ +------+ | L1 | L1 | | L1 | | | | | | +------+------+ +------+ Figure 2: Virtual Interface Adaptor This solution is effective when the operating system tries to bind the assigned IP address to the active interface. Even if that interface is disconnected or deactivated and there is a time gap until a new interface is activated such as the handover scenario (a) in Section 2, the VIA remains active and retains the session. Not only for maintaining IP sessions, the VIA can also be the place to control those network interfaces for scenarios (b) or (c). Synchronizing with the network, the VIA switches from one interface to another and/or selects the outgoing interface among multiple active ones. 5.2. Direct support Some operating system allows one IP address to be assigned to multiple interfaces and to be maintained regardless of the status of Yokota, et al. Expires February 23, 2009 [Page 7] Internet-Draft PMIPv6 Inter-Tech HO Support August 2008 those interfaces. In this case, by quickly switching one interface to another, scenario (b) can be asymptotically realized. If dual radio mode can be assumed, by activating two interfaces, both of which have the same IP address, scenario (c) can be realized. In either case, a proper trigger needs to be provided for the timing of the interface switching and in scenario (c), a proper policy to select the interface for outgoing packets needs to be provided as well. +----------------------------+ | TCP/UDP | Session to IP +->| | address binding | +----------------------------+ +->| IP | IP address to +->| | physical IF | +----------------------------+ binding +->| L2 | L2 | | L2 | |(IF#1)|(IF#2)| ..... |(IF#n)| +----^-+-^----+ +------+ | L1: | :L1 | | L1 | | : | : | | | +----:-+-:----+ +------+ :==>: MN-HoA Figure 3: Direct support Yokota, et al. Expires February 23, 2009 [Page 8] Internet-Draft PMIPv6 Inter-Tech HO Support August 2008 6. Security Considerations This document discusses the internal behavior of the mobile node and no additional security concern is introduced. Yokota, et al. Expires February 23, 2009 [Page 9] Internet-Draft PMIPv6 Inter-Tech HO Support August 2008 7. IANA Consideration This document does not require any assignment by IANA. Yokota, et al. Expires February 23, 2009 [Page 10] Internet-Draft PMIPv6 Inter-Tech HO Support August 2008 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Gundavelli, S., Ed., "Proxy Mobile IPv6", RFC 5213, August 2008. 8.2. Informative References [3] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007. Yokota, et al. Expires February 23, 2009 [Page 11] Internet-Draft PMIPv6 Inter-Tech HO Support August 2008 Authors' Addresses Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama, 356-8502 JP Email: yokota@kddilabs.jp Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 US Email: sgundave@cisco.com Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 US Email: kleung@cisco.com Yokota, et al. Expires February 23, 2009 [Page 12] Internet-Draft PMIPv6 Inter-Tech HO Support August 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Yokota, et al. Expires February 23, 2009 [Page 13]