Network Working Group Y. Cui Internet-Draft Tsinghua University Intended status: Standards Track X. Xu Expires: April 5, 2013 WD. Wang XM. Li Beijing University of Posts and Telecommunications YZ. Huo W. Luo ZTE Corporation October 2, 2012 Seamless Handover for Multiple-Access Mobile Node in PMIPv6 draft-cui-netext-pmipv6-shpmipv6-00 Abstract Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provide a mobile node(MN) which requires no additional modification to MN with IP mobility. Fast Handover for Proxy Mobile IPv6 (FHPMIPv6), specified in[RFC5949], proposed two modes of fast handover, both of them use single interface to transmate packets during handover, which requires it to buffer packets in MAGs when interface performs handover. Buffer packets in MAGs result in additional overhead, and increase packets transmission delay. Unlike FHPMIPv6, this document proposed a seamless handover scheme for multi-access mobile node with IP mobility when one of MN's network interface performs handover from one MAG to another. This scheme uses some other interface of the multi-access mobile node to help process packets while handovering. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 5, 2013. Cui, et al. Expires April 5, 2013 [Page 1] Internet-Draft SHPMIPv6 October 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 5 4.2. Mobile Node considerations . . . . . . . . . . . . . . . . 7 4.3. Mobile Access Gateway considerations . . . . . . . . . . . 7 4.4. Local Mobility Anchor considerations . . . . . . . . . . . 8 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Streamless Handover Initiate (SHI) message . . . . . . . . 8 5.2. Streamless Handover Acknowledge (SHAck) message . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Cui, et al. Expires April 5, 2013 [Page 2] Internet-Draft SHPMIPv6 October 2012 1. Introduction With the development of internet access technologies and mobile terminal equipment, more and more hosts are operating in multiple- interfaces, thus a terminal having access to multiple heterogeneous network domain simultaneously has become possible. Proxy Mobile IPv6 is a network-based mobility protocol, it provids mobility support for mobile node and requires no additional modification. RFC 5949 FHPMIPv6 is a fast handover extension for PMIPv6, the document proposed two modes of fast handover: reactive mode and predictive mode. The main idea of the two modes of operations is to establish a bi-directional tunnel between the Previous Mobile Access Gateway (PMAG) and the New Mobile Access Gateway (NMAG). So, packets destined for the Mobile Node are forward from the PMAG to the NMAG over this tunnel. Both of the two modes of fast handover improve the handover performance in terms of packet loss and latency, while none of them takes full advantage of multi-access features of the mobile node, as in both of the two handover modes, packets transmission on the handover interface should be buffered at the PMAG or NMAG which increases the requirement of storage volume forthe MAG. When there are many MNs are handovering within the coverage area of the same MAG, some packets may be lost due to cache insufficiency. The two modes adopt cached and forwarded to deal with the packet while handover will greatly increase the transmission delay, that may be deadlly to delay-sensitive applications. This document propose a seamless handover scheme for multiple-access mobile node in PMIPv6, compared with the two kinds of handover modes mentioned above.This seamless handover scheme doesn't need to buffer the packets in MAG, which reduces the requirements on the MAG cache, while reducing the transmission delay at the same time. 2. Requirements Language 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]. 3. Terminology The following terminologys used in this document are define in RFC5213: Local Mobility Anchor (LMA). Mobile Access Gateway (MAG). Cui, et al. Expires April 5, 2013 [Page 3] Internet-Draft SHPMIPv6 October 2012 Proxy Mobile IPv6 Domain (PMIPv6-Domain). The following terminologys used in this document are define in RFC5949: Previous Mobile Access Gateway (PMAG). New Mobile Access Gateway (NMAG). The following terminologys are define and used in this document: Stable Mobile Access Gateway (SMAG) while one of MN's interface is handovering, The MAGs that connect with some other interface of MN are called SMAG. 4. Protocol overview +----------+ | LMA | +----------+ | | +-----------+ | Router | +-----------+ / | \ / | \ / | \ / | \ / | \ +-----------+ +-----------+ +-----------+ | PMAG | | SMAG | | NMAG | +-----------+ +-----------+ +-----------+ \ / \ / \ / \ / \ / \ / \ / \ / IF1 | | IF2 IF2 | | IF1 +-----------+ +-----------+ | MN |---->| MN | +-----------+ +-----------+ Figure 1 reference network for Multiple-Access Mobile Node handover In order to alleviate the packet loss during handover, RFC5949 propsoed two kinds of fast handover schemes. In both of the two handover scheme, the downlink packets need to be buffered either at Cui, et al. Expires April 5, 2013 [Page 4] Internet-Draft SHPMIPv6 October 2012 the PMAG or NMAG, depending on when the packet forwarding is performed. This buffer and forwarding mechanism increase the cache overhead in MAG and increase the data transmission delay. In this document, we assume that mobile node have multiple network interface access different MAG in the same PMIPv6-Domain and support weak host model,that means MN can receive any locally destined packet regardless of the network interface on which the packet was received. The deployment scenario is illustrated in Figure 1. In order to improve the performance during handover and reduce the demand of the MAG buffer capacity, this document specifies a bi- directional tunnel between the PMAG and SMAG to forward packets for mobile node. If an interface is handovering, the packets transmission on this interface was forwarded to SMAG then forwarded to some other interface of MN. In order to build a bi-directional tunnel between the PMAG and the SMAG, a new message called Streamless Handover Initiate(SHI) and Streamless Handover Acknowledge (SHIA) was define in Section 5. When multi-interface MN attach to MAG, MAG will send PBU register message to LMA, then recevie a PBA message if register succeeded, MAG will send SHI message to MAGs that connect with MN's interface. Necessary extensions to LMA and MAG need to support this handover scheme and the extentions are define in section 4.3 and section 4.4. 4.1. Protocol Operation Unlike Predictive Fast Handover and Reactive Fast Handover, this protocol build a bi-directional tunnel between MAGs that different interfaces of the mobile node connects to. The sequence of event for the seamless handover scheme for Multiple-Access Mobile Node is illustrated in Figure 2. +-----+ +------+ +------------+ +------+ +----+ | MN | | PMAG | | SMAG | | LMA | | CN | +-----+ +------+ +------------+ +------+ +----+ IF1 IF2 | | | | | | | | Flow X | | |<--------------->|<--------------------------- --->|<-------->| | | | | | | | |------Router Solicitation-->| | | | | | |---PBU(MN-ID)--->| | | | | | | | | | | | +----------------------+| | | | | |Detect whether the MN || | | | | |have other interface || | | | | |has registered || | | | | +----------------------+| | | | | | | Cui, et al. Expires April 5, 2013 [Page 5] Internet-Draft SHPMIPv6 October 2012 | | | |<-PBA(PMAG-Addr)-| | | | | | | | | |<----Router Advertisement---| | | | | | |==Bi-Dir Tunnel==| | | | | | | | | | |<---SHI(MN-ID)-| | | | | | | | | | | |------SHIA---->| | | | | | | | | | | |=Bi-Dir Tunnel=| | | +--------+| | | | | |handover|| |<----------------------Flow X---------------| +--------+| +-----------------------+| | | | | | detection IF1 is || | | | | | unreachable forword || | | | | | Flow X to SMAG || | | | | +-----------------------+| | | | | | | | | | | |-----Flow X--->| | | | | | | | | | |<---------Flow X------------| | | | | | | | | | | |------------PBU(dereg)---------->| | | | | | | | | | | | +----------------+ | | | | | |forword Flow X | | | | | | |to MAG2 | | | | | | +----------------+ | | | | | | | | | | |<------------Flow X---------| | |<---------Flow X------------| | | | | | | | | | | |<--------------PBA---------------| | | | | | | | Figure 2 the signaling process of streamless handover scheme for Multiple-Access Mobile Node The detailed descriptions are as follows: o In the proxy mobile ipv6 network domain, MN has multiple interface as illustrated in Figure 1, assumes that interface 1(IF1) has already accessed PMIPv6 domain and data flow X transmitted through the interface. o IF2 accesses SMAG, and SMAG sends PBU message to LMA. If register success, LMA send back PBA message to SMAG. Cui, et al. Expires April 5, 2013 [Page 6] Internet-Draft SHPMIPv6 October 2012 o When SMAG receives PBA message, it sends SHI message to PMAG, noticing that the SHI message must include the MN-ID option. when PMAG receives SHI message and finds that the MN connects to it, PMAG sends a SHIA message to SMAG, otherwise PMAG send back MN not attached SHIA message. When all this done, PMAG and SMAG detect whether there exists any tunnel between them, if not, it will build a bi-directional tunnel between them.notice that the tunnel between MAGs are per-MAG-MAG. o When IF1 performs a handover, first, if PMAG detects IF1 is unreachable, it change the router and forwords the packet that destination address is IF1 to SMAG. In this case , the transmission path of flow X is LMA->PMAG->SMAG->IF2. Then PMAG sends the DeReg PBU message to LMA. o LMA receives the DeReg PBU message, first it changes the router and forwards the packet of destination address IF1 to SMAG,.In this case, the transmission path of flow X is LMA->SMAG->IF2. Then LMA sends back DeReg PBA message to PMAG. 4.2. Mobile Node considerations In this document, we assume that mobile node has multiple network interfaces, and those interfaces access to the same PMIPv6-domain. and all of the MN's network interfaces configuration the same home network prefix. In order to support MNs that receive any locally destined packet regardless of the network interface on which the packet is received, the mobile node must support the weak host model. While interface is handovering, it may re-config its IP address and MN may not accept the packet that the destination address is the handover interface, in this document, we assume MN can accept the packet that the destination address is the handover interface's IP address emporarily while the interface is handovering(details are out of the scope of this document). 4.3. Mobile Access Gateway considerations In the seamless handover scheme, when MAG receive a PBA message, it need to send SHI message to some other MAGs that connect to MN, in this document we assume that MAG knows the ip address of those MAG. Notice that the SHI message at least includes MN-Id option. When MAG receives SHI message, it detects whether the MN has a interface connected with it, if so, MAG sends SHIA response message, and bulids a bi-directional tunnel, otherwise, sends the response message of no such node. When MAG detects the departure of the MN's network interface, it configures routing manner, the packets that sent to the interface are Cui, et al. Expires April 5, 2013 [Page 7] Internet-Draft SHPMIPv6 October 2012 forwarded through to SMAG through tunnels. As all the network interfaces of MN's configured the same home network prefix, MAG can forward packets to MN by prefix match. 4.4. Local Mobility Anchor considerations When LMA receives a PBU message, it needs to detect wehther the MN has another interface accessed the PMIPv6-domain, and associate all MN's interface, in this document, we assume that LMA support flow mobility, as [I-D.ietf-netext-pmipv6-flowmob] described 5. Message Formats This section defines new mobility header messages for seamless handover . 5.1. Streamless Handover Initiate (SHI) message This message is created to bulid associate between MAGs that different interfaces of MN connect to. The format of the Message Data field in the Mobility Header is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Mobility options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence # Must be set by the sender so replies can be matched to this message. 'A' flag The Acknowledge (A) bit is set to request a Streamless Handover Acknowledge be returned upon receipt of the SHI message. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver Cui, et al. Expires April 5, 2013 [Page 8] Internet-Draft SHPMIPv6 October 2012 Lifttime 16-bit unsigned integer. It represents the tunnel survival time. Mobility Option Same as [RFC5213] 5.2. Streamless Handover Acknowledge (SHAck) message The Streamless Handover Acknowledge is used to acknowledge receipt of a SHI message. The format of the Message Data field in the Mobility Header is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Status | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Mobility options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence# The Sequence Number in the Streamless Handover Acknowledge is copied from the Sequence Number field in the SHI message. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Lifetime 16-bit unsigned integer. It represents the tunnel survival time. Status 0: successed 128: Reason unspecfied 129: MN not attached Cui, et al. Expires April 5, 2013 [Page 9] Internet-Draft SHPMIPv6 October 2012 6. IANA Considerations TBD 7. Security Considerations TBD 8. Normative References [I-D.ietf-netext-pmipv6-flowmob] Bernardos, C., "Proxy Mobile IPv6 Extensions to Support Flow Mobility", draft-ietf-netext-pmipv6-flowmob-04 (work in progress), July 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 2010. Authors' Addresses Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6260-3059 EMail: cuiyong@tsinghua.edu.cn Xin Xu Beijing University of Posts and Telecommunications Tsinghua University FIT Building 4-103 Beijing 100084 P.R.China Cui, et al. Expires April 5, 2013 [Page 10] Internet-Draft SHPMIPv6 October 2012 EMail: xuxin1988@gmail.com Wendong Wang Beijing University of Posts and Telecommunications Room 609, teaching building 3,BUPT Beijing 100876 P.R.China EMail: wdwang@bupt.edu.cn XiMing Li Beijing University of Posts and Telecommunications Tsinghua University FIT Building 4-103 Beijing 100084 P.R.China EMail: xml@bupt.edu.cn Yuzhen Huo ZTE Corporation No.68 Zijinghua Rd.,Yuhuatai District Nanjing 210012 P.R.China EMail: huo.yuzhen@zte.com.cn Wen Luo ZTE Corporation No.68 Zijinghua Rd.,Yuhuatai District Room 609, teaching building 3,BUPT 210012 P.R.China EMail: EMail:luo.wen@zte.com.cn Cui, et al. Expires April 5, 2013 [Page 11]