Network Wroking Group Hewei. Yu Internet-Draft Ziliang. Li Intended status: Informational South China University of Technology Expires: October 18, 2015 April 17,2015 Fast Handover based on Registration in advance for Proxy Mobile IPv6 draft-yu-netext-pmipv6-handover-00 Abstract This memo proposes an alternative handover scheme in Proxy Mobile IPv6(PMIPv6) by making NMAG early registering to LMA before MN attaches to NMAG. Therefore, when MN handover to NMAG, it can sends the Router Advertisement message to MN immediately, because the network-layer handoff has completed already. 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 October 21, 2015. Copyright Notice Copyright (c) 2015 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. 1. Introduction The Proxy Mobile IPv6(PMIPv6) [RFC5213] protocol is a network-based local mobility management which enable IP mobility for a host without requiring its participation. It defines two new mobility entities LMAG and MAG. The LMA is responsible for maintain the MN's reachability state and is the topological anchor point for MN's home network prefix (MN-HNP). The MAG acts as an access router which performs the mobility management on behalf of MN. However, the handover in PMIPv6 still has a undesirable delay to the mobile nodes running real time applications. Fast handover mechanism for PMIPv6 has been proposed in [RFC5949]. Before MN detached from the PMAG, it reports the information of NMAG which is most likely to move to PMAG. It specifies a bidirectional tunnel between the Previous MAG (PMAG) and the New MAG (NMAG) to tunnel packets meant for the mobile node. After decapsulation, those packets should be buffered at NMAG. As soon as MN attaches to NMAG, the NMAG starts to forward packets destined for MN and the uplink packets would be forward to PMAG by NMAG. The PMAG then transfers the packets to the LMA which is serving MN. This process can reduce packet loss, but it doesn't bring significant reduction of handover delay. This is because it starts the proxy registration procedure after MN's attachment which just like the handover in [RFC5213]. This memo proposes an fast handover scheme based on NMAG registration in advance for PMIPv6. Before MN detaches from PMAG, NMAG registers to LMA on behalf of MN. So when MN handover to NMAG, the NMAG could send Router Advertisement(RA) message to MN with MN- HNP immediately. This can minimize handover delay. 2. Terminology The terminology in this document is based on the definitions of PMIPv6[RFC5213], in addition to the ones specified as follows: Mobile Node (MN): The mobile node is an IP host or router and its mobility is managed by the entities in the network. Local Mobility Anchor (LMA): Local Mobility Anchor is the topological anchor point for the MN's home network prefix and is responsible to manage the MN's binding state. Mobile Access Gateway (MAG): The function entity that manages the mobility-related message for MN and initiates binding registrations to the LMA which is currently serving MN. Previous Mobile Access Gateway (PMAG): The MAG that manages mobility -related signaling for mobile node before handover. New Mobile Access Gateway (NMAG): The MAG that manages mobility- related signaling after handover. Mobile Node's Home Network Prefix (MN-HNP): The network prefix assigned to MN by LMA. Every prefix should only be assigned to one host. 3. FPMIPv6 based on Registration in Advance Protocol Overview 3.1 Protocol Overview This memo describes fast handover scheme based on registration in advance for Proxy Mobile IPv6 (PMIPv6) [RFC5213]. To further reduce the handover latency, NMAG registers to LMA while MN is still on the subnet of PMAG. A bi-directional tunnel between PMAG and NMAG would be built to forward packet to NMAG by PMAG. The NMAG decapsulates and buffers them prior MN's attachment. It alleviates the packet loss. In the proposed handover scheme, the MN has made two prediction of handover. One is MN undergoes a handover but not handoff immediately, the other is MN has decided to handoff and start link layer handoff. It is assumed that the interval of these two prediction is long enough for NMAG proceeds the registration procedure ahead of time. In PMIPv6 domain, the MN is not involved with IP mobility management. In order to do the prediction of handover, it is required that the MN has the capability to report link-layer information to MAGs at a short interval. And that message should help PMAG resolving the NMAG to which the MN is most likely moving. The detail of this message are outside the scope of this memo. In order to reduce the packet loss in handover, the downlink packets meant for MN should be buffered at NAMG, as it shows at step (i) of Figure 1. Therefore, it is required that all MAGs are capable of buffering packets for the MN. The buffer zone size and the rate of forwarding buffered packets are outside the scope of this memo. 3.2 Protocol Operation In [RFC5213] or [RFC5949], NMAG's registration proceeds after it detects MN's attachment during handover. This memo presented an fast handover scheme based on registration in advance. When MN undergoes handover but still connected to PMAG, NMAG registers to LMA and sets up the bidirectional tunnel between PMAG and NMAG. Packets destined for MN would be transfered to NMAG by LMA, then NMAG transfers them to PMAG over this tunnel. After MN attaches to NMAG, NMAG sends the Router Advertisement (RA) message which contains MN-HNP to MN quickly, cause the registration process has been completed in advance. The whole signaling call flow of proposed scheme is illustrated in Figure 1. MN PMAG LMA NMAG | | | | (a) |--Report-->| | | | | | | (b) | |---------------HI--------------->| | | | | (c) | | |<---------PBU--------| | | | | (d) | | |----------PBA------->| | | | | | | |<===Bir-Dir Tunnel==>| | | | | | | |=======DL data======>|=# |<==========|<================================| |==UL data=>|==========>| | (e) | |<-------------HAck---------------| | | | | (f) | |<========Bir-Dir Tunnel=========>| | | | | (g) |==UL data=>|================================>|=# | | |<====================| | | | | (h) |---L2 HO-->| | | | | | | (i) | |---------------HI--------------->| \ ~~~ | | | | ~~~ | | | | (j) |----------------Rtr Sol--------------------->| | | | | | | buffering (k) |<---------------Rtr Adv----------------------| | | | | | | (l) IP Address | | | | Configuration | | | / | | | | (m) |<===========deliver packets==================| | | | | UL Uplink DL Downlink Figure 1: Signaling call flow of proposed scheme The detailed description are as follows: (a) MN detects that a handover is imminent and reports to PMAG its identifier(MN-ID) and the New Access Point Identifier[RFC5568] to which the MN is most likely to handover. This step is dependent on access technology, and detail is out of scope. (b) PMAG derives NMAG from the New AP ID , and collects all needed information about MN, such as MN-ID, MN-HoA, MN-HNP, MN's MAC address. Then the PMAG sends a Handover Initiate(HI) message to NMAG with the 'R' flag set. (c) NMAG sets up one tunnel to LMA and another to PMAG. The former is for uplink and the latter is for downlink of MN. Then NMAG sends a Proxy Binding Update(PBU) message to the LMA. (d) Upon receipt of the PBU message, the LMA updates its binding cache entry of MN, then removes the tunnel to PMAG and sets up a tunnel to NMAG. After that, the LMA replies a PBA containing MN-HNP to NMAG. By now, the entire downlink for MN has been established and the process doesn't cost much time, which starts from LMA removing tunnel to PMAG and ends by setting up tunnel to NMAG. Before then, the downlink of MN is through LMA to PMAG. (e) NMAG sends a Handover Acknowledge(HAck) message back to the PMAG with 'T' flag set, which means PMAG should forwards the uplink packets to NMAG after receiving this message. (f) PMAG removes the tunnel to LMA and sets up a new one to NMAG for the uplink of MN. So far, the entire uplink for MN has been established and the process just take a short time, which starts from PMAG removing the tunnel to LMA and ends by setting up the tunnel to NMAG. Before then, the uplink is through PMAG to LMA by the tunnel between them. (g) During processes above, MN is still attaches to PMAG. Packets meant for MN would be transfered to NMAG by LMA, then NMAG transfers them to PMAG. Packets sent by MN would be forwarded to NMAG by PMAG and NMAG forwarded them to LMA. (h) L2 handover would be made immediately, MN sends L2-HO information message to PMAG. The details on LH-HO is outside scope of this memo. (i) PMAG sends a HI message to NMAG with 'U' flag set, and NMAG start buffering packets until MN's attachment. (j) MN detaches from PMAG and attaches to NAMG's access link, and sends a Router Solicitation(RS) message to NMAG. (k) NMAG removes the tunnel to PMAG, updates its routing information and replies a Router Advertisement(RA) message containing MN-HNP. (l) MN configures its interface using HNP received and gets one or more IPv6 addresses. (m) NMAG forwards the buffered packets to MN. As described above, when MN handover to NMAG's access link, NMAG has no need of registration to LMA. What NMAG needs to do is send a RA message to MN after updating router state. Due to the registration in advance, the handover latency can be greatly reduced. 3.3 Handover Latency Analyze We can divide the handover into two parts, link-layer handover and network-layer handover. It would be thought that the proposed handover scheme just proceeds network-layer handover ahead of time and doesn't decrease the entire handover latency. However, it does reduce the handover delay to a great extent. Before step (c), PMAG would forward the downlink packets to MN from LMA. After receiving PBU from NMAG, LMA updates the binding cache and setup a new tunnel to NMAG. From now on, downlink packets would be transferred to NMAG, and NMAG redirects them to PMAG. The first part of proposed handover scheme is the time that LMA processes the PBU message. At this moment, though PMAG hasn't set up a tunnel to NMAG for uplink of MN, PMAG can transfer the uplink packets to LMA by the original tunnel. At step (e), PMAG receives the HAck message. It removes the tunnel to LMA and set up a tunnel to NMAG for the uplink of MN. This is the second part of proposed handover scheme. The last part is the time that NMAG receives RS message and replies RA message to MN, as shown of step (j) and (k). It is important to note that the delay occurs only in step (c) and (e) before MN detaches from PMAG. Outside that, MN can communicate with correspondent node without obstacles. Furthermore, if the NMAG needs to exchange message with AAA Server for authentication of the MN, it wouldn't cause additional handover delay in this proposed scheme. The authentication procedure would be done when NMAG is in the early registration step, while MN can communicate with the correspondent node via PMAG and LMA. 4. Message Format 4.1 Handover Initiate (HI) This definition extents the HI message in [RFC5949]. The detail format is shown 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 # | +-+-+-+-+-------+---------------+-------------------------------+ |S|U|P|F|R|Rsv'd| Code | | +-+-+-+-+-+-----+---------------+ | | | . . . Mobility options . . . | | +---------------------------------------------------------------+ (Note: P=1) Distinguish Flag (R) Registration flag. A new flag (R) is for PMAG to inform NMAG that MN is imminent to handover. And the NMAG should start proxy registration for MN in advance. 4.2 Handover Acknowledge (HAck) This message definition extents the HAck message in [RFC5949].The detail format is shown 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 # | +-+-+-+-+-------+---------------+-------------------------------+ |U|P|F|T|Resv'd | Code | | +-+-+-+-+-+-----+---------------+ | | | . . . Mobility options . . . | | +---------------------------------------------------------------+ (Note: P=1) Distinguish Flag (T) Transfer flag. A new flag (T) to request to transfer the packets from the MN. PMAG should set up a tunnel to NMAG and forward the uplink packets to NMAG after receiving HAck with 'T' flag. This is different from 'F' flag which used to request to forward the downlink packets of MN. 5. Security Consideration Security threats for this memo follow those for PMIPv6 [RFC5213], FMIPv6 [RFC5568] and FPMIPv6 [RFC5949]. Both MAGs and LMA must implement IPsec [RFC4301] for protecting exchanged signaling message. Like PBU and PBA message, the Handover Initiate (HI) and Handover Acknowledge (HAck) must be protected using the mechanism of Encapsulating Security Payload (ESP) [RFC4303] in transport mode, to ensure integrity and data origin authentication. 6. References 6.1 Normative Reference [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009. 6.2 Informative Reference [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 2010. Authors' Addresses Hewei Yu South China University of Technology School of Computer Science & Engineering South China University of Technology, Guangzhou, 510006 P.R. China Email: hwyu@scut.edu.cn Ziliang Li South China University of Technology School of Computer Science & Engineering South China University of Technology, Guangzhou, 510006 P.R. China Email: liziliang1989@gmail.com This Internet-Draft will expire on October 18, 2015.