[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/