Network Working Group H. Yokota Internet-Draft KDDI Lab Intended status: Informational S. Gundavelli Expires: April 29, 2010 K. Leung Cisco October 26, 2009 Inter-Technology Handoff support in Mobile Node for Proxy Mobile IPv6 draft-yokota-netlmm-pmipv6-mn-itho-support-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Yokota, et al. Expires April 29, 2010 [Page 1] Internet-Draft PMIPv6 Inter-Tech HO Support October 2009 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Yokota, et al. Expires April 29, 2010 [Page 2] Internet-Draft PMIPv6 Inter-Tech HO Support October 2009 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 . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Handover Scenarios and requirements on the mobile node . . . . 6 4. Operational issues . . . . . . . . . . . . . . . . . . . . . . 8 5. Example solutions for inter-technology handover support. . . . 9 5.1. Virtual interface adaptor . . . . . . . . . . . . . . . . 9 5.2. Direct support . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Yokota, et al. Expires April 29, 2010 [Page 3] Internet-Draft PMIPv6 Inter-Tech HO Support October 2009 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 [RFC2119]. Yokota, et al. Expires April 29, 2010 [Page 4] Internet-Draft PMIPv6 Inter-Tech HO Support October 2009 2. Introduction RFC4831[RFC4831] 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 [PMIP6] 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. More detailed issues on network-based inter-technology handovers are described in [ITHO-PS]. 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 April 29, 2010 [Page 5] Internet-Draft PMIPv6 Inter-Tech HO Support October 2009 3. Handover Scenarios and requirements on the mobile node PMIPv6 ensures all the mobile access gateways (MAGs) in the Proxy Mobile IPv6 domain to use the same link-local and link-layer addresses on any of their access links. Therefore, no matter which MAG the mobile node attaches to, it sees the same Router Advertisements, which prevents the mobile node from detecting the change of the network and the default router. However, when the mobile node has two or more interfaces and the handover involves the change in the attached interface, it will raise an issue that would not occur in the case of a single interface. 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 Yokota, et al. Expires April 29, 2010 [Page 6] Internet-Draft PMIPv6 Inter-Tech HO Support October 2009 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 April 29, 2010 [Page 7] Internet-Draft PMIPv6 Inter-Tech HO Support October 2009 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 April 29, 2010 [Page 8] Internet-Draft PMIPv6 Inter-Tech HO Support October 2009 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 April 29, 2010 [Page 9] Internet-Draft PMIPv6 Inter-Tech HO Support October 2009 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 April 29, 2010 [Page 10] Internet-Draft PMIPv6 Inter-Tech HO Support October 2009 6. Security Considerations This document discusses the internal behavior of the mobile node and no additional security concern is introduced. Yokota, et al. Expires April 29, 2010 [Page 11] Internet-Draft PMIPv6 Inter-Tech HO Support October 2009 7. IANA Consideration This document does not require any assignment by IANA. Yokota, et al. Expires April 29, 2010 [Page 12] Internet-Draft PMIPv6 Inter-Tech HO Support October 2009 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [PMIP6] Gundavelli, S., Ed., "Proxy Mobile IPv6", RFC 5213, August 2008. 8.2. Informative References [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007. [ITHO-PS] Krishnan, S., Yokota, H., Melia, T., and C. Bernardos, "Issues with network based inter-technology handovers", draft-krishnan-netext-intertech-ps-02.txt, July 2009. Yokota, et al. Expires April 29, 2010 [Page 13] Internet-Draft PMIPv6 Inter-Tech HO Support October 2009 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 April 29, 2010 [Page 14]