Internet DRAFT - draft-yu-netext-pmipv6-handover

draft-yu-netext-pmipv6-handover



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.