INTERNET-DRAFT                                                  H. Jiang
Intended Status: Proposed Standard                                Huawei
Expires: December 31, 2012                                 June 29, 2012


   Fault Tolerant Support for The Multihomed MN in Proxy Mobile IPv6
                     draft-jiang-netext-ft-pmip-00


Abstract

   Proxy Mobile IPv6 (PMIPv6) is standardized by IETF to supply mobility
   management for mobile nodes (MN) in a local small area. If the
   multihomed MN attaches to multiple MAGs by multiple links, then the
   mobility session in each link is independent. As the ongoing
   communication interface breaking down, the mobility session in the
   link is also broke and the traffic packets are lost. This document
   mainly proposes a fault tolerant scheme. When an interface of the
   multihomed MN broke down, the fault tolerant scheme can be used to
   handover the interface and realize the flow migration and maintain
   the integrity of data transmission During the handover process.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the



H. Jiang               Expires December 31, 2012                [Page 1]


INTERNET DRAFT      Fault Tolerant Scheme for PMIPv6       June 29, 2012


   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 and Terminology  . . . . . . . . . . . . . . . . .  3
     2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2 Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Fault Tolerant Scheme  . . . . . . . . . . . . . . . . . . . .  4
     3.1 LMA Operation  . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2 Fault Tolerant Handover  . . . . . . . . . . . . . . . . . .  4
   4  Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   5  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  6
   6  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     6.1  Normative References  . . . . . . . . . . . . . . . . . . .  6
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  6























H. Jiang               Expires December 31, 2012                [Page 2]


INTERNET DRAFT      Fault Tolerant Scheme for PMIPv6       June 29, 2012


1. Introduction

   With the development of the Internet business, the customer cannot
   obtain the consecutive and high quality communication service as
   adopting one access technology to join the network. The emerging of
   the new technologies results in the situation that the Mobile Node
   (MN) can use multiple interfaces to access the network with multiple
   technologies, which can be summarized as multihoming. Especially in
   the future network, multihoming will absolutely be the necessary
   technology and be used to increase the reliability of the network
   application. In order to promoting the widespread deployment of the
   MN, mobile operators should consider the mobility management in the
   network. Thus the network based mobility management protocol - Proxy
   Mobile IPv6 (PMIPv6) was proposed to fulfill the mobility management
   requirements.

   PMIPv6 network mainly includes two function entities: Mobile Access
   Gateway (MAG) and Local Mobility Anchor (LMA). MAG takes the place of
   MN to deal with the mobility relating signaling. Generally the first
   hop router which MN is attaching takes this role. In the meanwhile
   MAG SHOULD track the MN in the PMIPv6 domain. The number of MAGs in a
   single domain is not limited. LMA SHOULD be responsible for
   associating MN with MAG and storing all the routing information to
   reach each MN. The Tunnel between LMA and MAG is used by MN to
   transmit the traffic flow.

   In PMIPv6, Binding Cache Entry (BCE) is created in LMA to binding the
   MAG with MN. Each BCE entry is only corresponding to one mobility
   session of the MN. If the multihomed MN attaches to multiple MAGs by
   multiple links, then the mobility session in each link is
   independent. When the ongoing communication interface breaking down,
   the mobility session in the link is also broke and the traffic
   packets are lost. LMA will remove the BCE entry that corresponding to
   the interface, thus the multihomed MN cannot receive data packets
   from this interface. Because MN does not involve in the signaling
   handover, MAG is unable to distinguish whether the handover was
   occurred between the two interfaces of the MN.

   Based on the problem stated above, this document proposes a fault
   tolerant scheme focusing on the multihomed MN in the PMIPv6 network.
   Two aspects are considered: 1) when an interface of the multihomed MN
   breaks down, the fault tolerant scheme can be used to handover the
   interface; 2) the fault tolerant scheme can realize the flow
   migration and maintain the integrity of data transmission in the
   process of interface handover.

2. Requirements and Terminology




H. Jiang               Expires December 31, 2012                [Page 3]


INTERNET DRAFT      Fault Tolerant Scheme for PMIPv6       June 29, 2012


2.1 Requirements

   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 RFC 2119 [RFC2119].

2.2 Terminology

   All of the terminology used in this document are already defined in
   [RFC5213].



3.  Fault Tolerant Scheme

3.1 LMA Operation

   In order to achieve the interface handover for the multihomed MN
   without transmission interruption, the data structure of the original
   BCE table SHOULD be extended as follows: the multihoming flag and the
   Status flag SHOULD be included in the new BCE entry. The multihoming
   flag is used to identify if the MN is the multihomed. When the
   multihomed MN joins the network, MAG is used to communicate with LMA
   to register the location information for MN and sends the Proxy
   Binding Update (PBU) message to LMA. LMA creates a BCE entry for each
   interface of MN. If the received PBU messages from different MAGs
   with the same MN-ID, the multihoming flag is set as 1; otherwise the
   value is set as 0. The status flag is used to identify whether the
   interface that the BCE entry corresponds is available, or whether the
   state of the interface is in use. The value is set as 1 when the
   interface is available; otherwise the value is set as 0.


3.2 Fault Tolerant Handover

   Considering that the multihomed MN attaches MAG1 and MAG2 through
   interface IF1 and IF2 respectively to join the PMIPv6 domain. After
   the access authentication, LMA allocates the same HNP (HNP1) for IF1
   and IF2.  Then LMA creates the BCE entries Entry1 and Entry2. By
   comparing the MN-ID of Entry1 and Entry2, LMA identifies that the MN-
   ID of Entry1 and Entry2 is the same, which implies that Entry1 and
   Entry2 belonging to the same MN. Then LMA associates Entry1 with
   Entry2 by MN-ID to facilitate the lookup and storage. After that two
   bi-direction data tunnel Tunnel1 and Tunnel2 are setup from LMA to
   MAG1 and MAG2. LMA respectively send PBA messages to inform MAG1 and
   MAG2. Afterwards MAG1 and MAG2 all send the Router Advertisement
   messages to inform IF1 and IF2 to configure the IP address. Then the
   multihomed MN actively communicates with Corresponding Node (CN)



H. Jiang               Expires December 31, 2012                [Page 4]


INTERNET DRAFT      Fault Tolerant Scheme for PMIPv6       June 29, 2012


   through IF1.

   When IF1 is breaking down, the data of CN sent from LMA to MAG1
   cannot reach the MN, and then MAG1 begins to cache the data for MN;
   At the same time MAG1 sends the DeReg PBU message to LMA for
   informing the IF1 fault; After receiving the DeReg PBU message, LMA
   begins to update the BCE entry; then LMA sends the PBA message to
   MAG1; MAG1 forwards the cached data to LMA by Tunnel; then LMA checks
   the BCE table and finds out that IF2 is available, so the cached data
   are sent to MAG2 by Tunnel2; then CN will communicates with the
   multihomed MN by Tunnel2. The detailed process is shown in Figure 1.


   +----+----+       +------+       +------+        +------+        +----+
   | IF1| IF2|       | MAG1 |       | MAG2 |        | LMA  |        | CN |
   +----+----+       +------+       +------+        +------+        +----+
     |    |             |              |               |               |
     |IF1 is unreachable|   CN sends packets to IF1 of MN by Tunnel1   |
     |<-----------------|<---------------------------------------------|
     |    |             |              |               |               |
     |    |    Caching data for MN     |               |               |
     |    |             |              |               |               |
     |    |             | MAG1 sends DeReg PBU to LMA  |               |
     |    |             |----------------------------->|               |
     |    |             |              |               |               |
     |    |             |              | Updating the BCE entry for MN |
     |    |             |              |------------------------------>|
     |    |             |              |               |               |
     |    |             |    LMA sends PBA to MAG1     |               |
     |    |             |<-----------------------------|               |
     |    |             |              |               |               |
     |    |             | MAG1 sends cached data to LMA|               |
     |    |             |----------------------------->|               |
     |    |             |              |               |               |
     |    |  MAG2 forwards the cached  |LMA sends cached               |
     |    |     data to IF2 of MN      |  data to MAG2 |               |
     |    |<---------------------------|<--------------|               |
     |    |             |              |               |               |
     |    |       CN communicates with the IF2 of MN by Tunnel2        |
     |    |<-----------------------------------------------------------|
     |    |             |              |               |               |
     |    |             |              |               |               |
         Figure 1: the signaling process of interface handover

   (1)  CN sends the data packets to MN through the bi-direction Tunnel
   between LMA and MAG1;

   (2)  MAG1 detects that IF1 is unreachable and begins to cache data



H. Jiang               Expires December 31, 2012                [Page 5]


INTERNET DRAFT      Fault Tolerant Scheme for PMIPv6       June 29, 2012


   for MN;

   (3)  MAG1 sends the DeReg PBU message to LMA (see RFC5213) to
   feedback;

   (4)  After receiving the DeReg PBU message, LMA updates the BCE entry
   for the multihomed MN;

   (5)  LMA sends the PBA message to MAG1 for confirmation;

   (6)  MAG1 sends the cached data to LMA;

   (7)  The cached data from LMA will be forwarded to MAG2 through
   Tunnel2 and reach the destination MN;

   (8)  CN keeps on sending data packets to MN through Tunnel2 between
   LMA and MAG2.


4  Security Considerations

   This document raises no new security issues for PMIPv6 network.

5  IANA Considerations

   None

6  References

6.1  Normative References

   [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC5213, August 2008.

   [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC6275, July 2011.


Authors' Addresses


              Haisheng Jiang
              Huawei Building, No.156 Beiqing Rd.
              Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District,
              Beijing 100095 P.R. China


              EMail: haisheng.jiang@huawei.com



H. Jiang               Expires December 31, 2012                [Page 6]


INTERNET DRAFT      Fault Tolerant Scheme for PMIPv6       June 29, 2012





















































H. Jiang               Expires December 31, 2012                [Page 7]