NETEXT WG                                                        S. Jeon
Internet Draft                             Instituto de Telecomunicacoes
Intended status: Standard Track                              B. Sarikaya
Expires: April 16, 2013                                           Huawei
                                                            R. L. Aguiar
                                                  Universidade de Aveiro
                                                        October 15, 2012

   Network Mobility Support using Mobile MAG in Proxy Mobile IPv6 Domain



   This draft specifies IP mobility support protocol for moving network
   including mobile nodes (MNs) over Proxy Mobile IPv6 network by
   introducing a new functional entity, mobile MAG (mMAG) on the moving
   network. The mMAG takes charge of MN's movement detection, binding
   update on behalf of MNs as a mobile access gateway (MAG) does in
   PMIPv6 infrastructure. This protocol also supports IP session
   continuity for a mobile node to move between mobile network and fixed
   MAG. This protocol does not require any modification or extension on
   the MN.

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

   The list of Internet-Draft Shadow Directories can be accessed at

Jeon, et al.           Expires April 16, 2013                 [Page 1]

Internet-Draft      NEMO Support in PMIPv6 Domain         October 2012

   This Internet-Draft will expire on April 16, 2013.

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
   ( 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. Conventions and Terminology.................................. 3
   3. Overview .................................................... 4
      3.1. Initial Attach ......................................... 4
      3.2. mMAG Handoff ........................................... 6
      3.3. Mobile Node Handoff..................................... 6
   4. mMAG Operation .............................................. 7
   5. LMA Operation ............................................... 7
   6. MAG Operation ............................................... 7
   7. MN Operation ................................................ 7
   8. IANA Considerations ......................................... 8
   9. Security Considerations...................................... 8
   10. References ................................................. 8
      10.1. Normative References................................... 8
      10.2. Informative References................................. 8
   Authors' Addresses ............................................. 9

Jeon, et al.          Expires January 16, 2013                [Page 2]

Internet-Draft      NEMO Support in PMIPv6 Domain         October 2012

1. Introduction

   Network mobility is a novel concept for handling a group of nodes
   within a moving vehicular area. It provides an effective way for
   wireless hosts to access the Internet through an intermediate router
   connecting to an external wireless wide access network.

   Proxy Mobile IPv6 (PMIPv6) is a network-based IP mobility protocol,
   taking charge of host movement detection, binding update on behalf of
   mobile nodes (MNs). It does not require any modification on mobile
   node and thus provides better mobility performance compared to host-
   based mobility protocol, e.g. Mobile IPv6 [RFC6275]. However, it does
   not support network mobility in the specification [RFC5213].

   NEMO Basic Support protocol (NEMO-BSP) [RFC3963] addressed this issue
   for allowing a host within a moving vehicle to continue their IP
   sessions when the vehicle is moving between access routers. However,
   NEMO-BSP employs a mobile router (MR), which requires MIPv6 client
   function having host-based mobility protocol feature. According to
   this fact, a MR introduced in NEMO-BSP is not aligned with network-
   based PMIPv6 approach, thus it is not suited to be used in PMIPv6

   This draft describes network mobility support over PMIPv6 domain by
   introducing a new entity, called mobile MAG (mMAG) [N-PMIPv6], which
   is responsible for detecting MN's movement, performing mobility
   management operation on behalf of MNs, and managing binding update
   list as a MAG does.

   This draft is based on stateless IPv6 address configuration for mMAG
   and MNs to configure their IP addresses not by using DHCP. This idea
   does not require any modification or extension on the MN.

2. Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   This document uses the terminology defined in [RFC5213]. In addition
   to, we defined Mobile MAG (mMAG) as follow.

     - Mobile MAG (mMAG): A mobile router, which has a similar function
     to MAG defined in PMIPv6 specification.

Jeon, et al.          Expires January 16, 2013                [Page 3]

Internet-Draft      NEMO Support in PMIPv6 Domain         October 2012

3. Overview

3.1. Initial Attach

   This sub-section describes initial attach of mMAG and MN. The mMAG is
   not a mobile router (MR) having Mobile IPv6 client functionality
   presented in [RFC3963]. The mMAG is the entity that performs the
   mobility management on behalf of MNs within mobile network. It has
   upstream and downstream interfaces; upstream interface is seen as
   normal MN to a MAG and it is connected as a tunnel with a LMA over
   PMIPv6 tunnel between a MAG and a LMA. Downstream interface is seen
   as fixed MAG in PMIPv6 infrastructure to attached MNs. LMA sees mMAG
   as a normal MN and then process initial attach process specified in
   [RFC5213] for normal MN.

             MN           mMAG           MAG           LMA
              |             |             |             |
            *********** mMAG attaches to MAG **************
              |             |             |             |
              |             |---- RS ---->|             |
              |             |             |---- PBU --->|
              |             |             |             |
              |             |             |<--- PBA ----|
              |             |<--- RA -----|             |
              |             |             |             |
              |     mMAG's IP address     |             |
              |       configuration       |             |
              |             |             |             |
              |             |             |             |
            *********** MN attaches to mMAG ***************
              |             |             |             |
              |             |             |             |
              |---- RS ---->|             |             |
              |             |-------- PBU('M')--------->|
              |             |             |             |
              |             |<------- PBA('M')----------|
              |<--- RA -----|             |             |
              |             |             |             |
       MN's IP address      |             |             |
        configuration       |             |             |
              |             |             |             |

           Figure 1 mMAG and MN Attachment - Signaling Call Flow

Jeon, et al.          Expires January 16, 2013                [Page 4]

Internet-Draft      NEMO Support in PMIPv6 Domain         October 2012

   Figure 1 shows the signaling call flow when the mMAG enters the Proxy
   Mobile IPv6 domain. In order to enable network mobility service
   support, the mMAG should be attached first to PMIPv6 domain. The MAG
   on detecting the mMAG performs authentication and authorization
   process as it does normal MN in [RFC5213] and then sends Proxy
   Binding Update message to the LMA.

   The LMA on receiving Proxy Binding Update message creates new Binding
   Cache entry and assigns new prefix and associates mMAG's ID and
   assigned prefix. The LMA sends Proxy Binding Acknowledgement message
   including assigned prefix to the MAG. The mMAG configures its IPv6
   address based on the prefix received from Router Advertisement.

   Subsequently, when a MN enters into wireless range of mobile network,
   the mMAG detects MN's attachment and performs NEMO service
   availability of attached MN through authentication and authorization
   processes. If is verified, the mMAG will be aware of the address of
   the LMA to which it belongs for attached MN. The mMAG then sends
   Proxy Binding Update message with setting 'M' flag to the associated
   LMA. The MAG as intermediate entity between mMG and LMA will treat
   this message as normal packets originated from the mMAG and send it
   after encapsulating the message with destination IP address of LMA.
   On receiving encapsulated Proxy Binding Update message, the LMA will
   decapsulate and processes the message by adding the MN's ID to
   Binding Cache with setting 'M' flag indicating that this node belongs
   to a mobile network and store mMAG's source IP address as Proxy Care-
   of Address in Proxy Binding Update message.

   The LMA then assigns and delivers new prefix to the mMAG by sending
   Proxy Biding Acknowledgement message with setting 'M' flag. The mMAG
   sends Router Advertisement message to the MN. The MN configures its
   stateless IPv6 address based on received prefix in Router
   Advertisement message.

   The MAG is transparent for exchanging signaling messages and data
   packets between mMAG and LMA. 'M' flag is used to let the LMA know
   that additional Binding Cache entry lookup should be allowed when it
   receives packets destined MN's prefix. On receiving Proxy Binding
   Update message, the LMA sets 'M' flag in Binding Cache entry of the
   MN. As a result, when a LMA receives a packet destined MN's prefix
   within mobile network, it performs recursive look up processing. In a
   first look up, the LMA obtains the mMAG to which the MN is attached.
   And in a second look up, the LMA obtains a MAG to which the mMAG of
   the MN is attached. The packets will be tunneled with mMAG's IP
   address and MAG's address to which mMAG belongs, for destination IP
   address in inner/outer tunnel header, respectively.

Jeon, et al.          Expires January 16, 2013                [Page 5]

Internet-Draft      NEMO Support in PMIPv6 Domain         October 2012

3.2. mMAG Handoff

   The mMAG's handoff is assumed that the mMAG moves to the newly
   attached mobile access gateway (n-MAG) from the previously attached
   mobile access gateway (p-MAG).

   The mMAG's handoff process follows normal PMIPv6 handoff specified in
   [RFC5213]. The n-MAG detects mMAG attach and sends Proxy Binding
   Update message to mMAG's associated LMA by following standard PMIPv6

   On receiving Proxy Binding Update message from n-MAG, the LMA will
   change the transport endpoint of the tunnel from p-MAG to n-MAG in
   LMA Binding Cache. The LMA is not required to perform additional
   operations for MNs within mMAG in Binding Cache due to mMAG's handoff
   because each binding of MN and mMAG, mMAG and MAG is managed
   separately. After updating Binding Cache entry of mMAG, the LMA sends
   Proxy Binding Acknowledgment message to the n-MAG. The n-MAG will
   send Router Advertisements containing the mMAG's home network prefix,
   and this will ensure the mMAG will not detect any change with respect
   to layer-3 attachment of its interface.

3.3. Mobile Node Handoff

             MN           mMAG           MAG           LMA
              |             |             |             |
              |             |             |             |
              |             |-De-Registration PBU('M')->|
              |             |             |             |
              |             |<------- PBA('M')----------|
              |             |             |             |
              |      MN's BCE deleted     |             |
              |             |             |             |
              |             |             |             |
              |----------- RS ----------->|             |
              |             |             |---- PBU --->|
              |             |             |             |
              |             |             |<--- PBA ----|
              |<---------- RA ------------|             |
              |             |             |             |

             Figure 2 Mobile Node Handoff - Signaling Call Flow

Jeon, et al.          Expires January 16, 2013                [Page 6]

Internet-Draft      NEMO Support in PMIPv6 Domain         October 2012

   Figure 2 shows the signaling call flow for the MN's handoff from mMAG
   to fixed MAG in same PMIPv6 domain. When the mMAG detects the MN
   detach, it will send de-registration Proxy Binding Update with the
   lifetime value of zero and setting 'M' flag to the LMA. Upon
   receiving the Proxy Binding Update message, the LMA waits for amount
   of time specified in [RFC5213], before it deletes the Binding Cache
   entry. On accepting Proxy Binding Acknowledgment message from the LMA
   the mMAG deletes the MN in the Binding Update List. On detecting new
   MN, the MAG performs initial attach operation following the
   specification in [RFC5213]. The LMA updates MN's Binding Cache entry
   by changing Proxy CoA with the MAG's address and setting 'M' flag to

4. mMAG Operation

   A mMAG, a new functional entity, is responsible for taking charge of
   MNs within mobile network to detect the MN's movements to and from
   the access link and to send the Proxy Binding Update message on
   behalf of the MN to the LMA as a MAG does in this document. The mMAG
   has same data structure of Binding Update List a MAG has and it
   emulates attached MNs by sending Router Advertisements based on each
   MN's home network prefix in the Proxy Binding Update List. But when
   the mMAG sends the Proxy Binding Update message to the LMA, it is
   required to add 'M' flag in Proxy Biding Update message.

5. LMA Operation

   When the LMA receives Proxy Binding Update message, it is not
   required to recognize where the message comes from fixed MAG or mMAG
   and to have knowledge of mMAG list not to extend PMIPv6 specification
   possibly. However, the LMA needs to have additional element called
   'M' flag in Binding Cache to distinguish which kinds of MAG the node
   is attached. This is used to provide efficient mMAG handoff
   management, not requiring the changes of Binding Cache of MNs within
   mobile network due to mMAG's handoff and to forward the packets
   destined the MN that belongs to mMAG.

6. MAG Operation

   A MAG is transparent for providing network mobility support. The mMAG
   attached to the MAG is treated as normal MN. No extension or
   modification is required to the MAG.

7. MN Operation

   No extension is required.

Jeon, et al.          Expires January 16, 2013                [Page 7]

Internet-Draft      NEMO Support in PMIPv6 Domain         October 2012

8. IANA Considerations

   This document makes no request of IANA.

9. Security Considerations


10. References

10.1. Normative References

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, March 1997.

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

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

   [RFC3963] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert,
             "Network Mobility (NEMO) Basic Support Protocol", RFC3963,
             January 2005.

10.2. Informative References

   [N-PMIPv6]I. Sogo, C. J. Bernardos, M. Calderon, A. Banchs, and A.
             Azcorra, "NEMO-Enabled Localized Mobility Support for
             Internet Access in Automotive Scenarios", IEEE Coms. Mag.,
             vol.47, no.5, pp.152-159, May 2009.

Jeon, et al.          Expires January 16, 2013                [Page 8]

Internet-Draft      NEMO Support in PMIPv6 Domain         October 2012

Authors' Addresses

   Seil Jeon
   Instituto de Telecomunicacoes
   Campus Universitario de Santiago
   3810-193 Aveiro, Portugal


   Behcet Sarikaya
   5340 Legacy Dr.
   Plano, TX 75024, USA


   Rui L. Aguiar
   Universidade de Aveiro
   3810-193 Aveiro, Portugal


Jeon, et al.          Expires January 16, 2013                [Page 9]