MN Status Option for Proxy Mobile IPv6
draft-tu-netext-mn-status-option-01

NETEXT Working Group                                               Y. Tu
Internet-Draft                                                    C. Zhu
Intended status: Standards Track                                     ZTE
Expires: October 15, 2012                                  CJ. Bernardos
                                                                    UC3M
                                                             C. Williams
                                                               MCSR Labs
                                                          April 13, 2012

                 MN Status Option for Proxy Mobile IPv6
                  draft-tu-netext-mn-status-option-01

Abstract

   The NETEXT Working Group is working on Proxy Mobile IPv6 extensions
   to support flow mobility, i.e., the ability of movement of selected
   flows from one access technology to another.

   This document extends the Proxy Binding Update signaling to convey
   mobile node's status information, that can be used by the local
   mobility anchor to decide when and how perform flow mobility.

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 15, 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

Tu, et al.              Expires October 15, 2012                [Page 1]
Internet-Draft         MN Status Option for PMIPv6            April 2012

   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 used in this document . . . . . . . . . . . . . . . 3
   3.  MN status option for PMIPv6 . . . . . . . . . . . . . . . . . . 3
     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.2.  Use case scenarios  . . . . . . . . . . . . . . . . . . . . 4
     3.3.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . 4
       3.3.1.  MAG considerations  . . . . . . . . . . . . . . . . . . 4
       3.3.2.  LMA considerations  . . . . . . . . . . . . . . . . . . 5
     3.4.  Mobile Node Status Option . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

Tu, et al.              Expires October 15, 2012                [Page 2]
Internet-Draft         MN Status Option for PMIPv6            April 2012

1.  Introduction

   There are several use cases where it would be useful that the local
   mobility anchor (LMA) can decide to perform flow mobility from one
   access network to another, e.g. from 3GPP to WLAN or from WLAN to
   WiMAX.  With current Proxy Mobile IPv6 specification [RFC5213], the
   LMA can only know the different access technologies the MN is
   attached to (this information is conveyed from the mobile access
   gateway to the local mobility anchor in the Access Technology Type
   option).  No accurate information about the mobile node status (e.g.,
   if it is in idle/power saving mode or experiencing low radio quality)
   is available at the LMA to aid it in the decision of performing flow
   mobility.  It is therefore helpful to provide the LMA with additional
   information, so it can take trigger flow mobility actions with a
   lower risk of failure/data loss.  This can be done by including
   mobile node status information in the signaling between the mobile
   access gateway and the local mobility anchore, and by enabling the
   mobile access gateway to update that information as needed.

   This document defines a new mobility option, MN Status option for
   Proxy Mobile IPv6 (PMIPv6), that can be used by mobile access gateway
   (MAG) for carrying the MN status with the correspondent access
   network to the local mobility anchor.

2.  Conventions used in this document

   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.  MN status option for PMIPv6

3.1.  Overview

   In some deployments, the network (e.g. 3GPP) needs to support
   multiple access technologies, and the local mobility anchor can be
   triggered to decide which access technology will be used to move a
   particular IP flow according to the operator preferences and local
   policy.  To guarantee the success of the flow mobility procedure from
   one access technology to another, a critical piede of information
   that should be obtained by the LMA is the current mobile node status
   with the correspondent access network.

   The mobile access gateway is the right PMIPv6 netork entity to detect
   the mobile node status using, in additon to the mechanisms defined in
   RFC5213 [RFC5213], any access network specific mechanism that is

Tu, et al.              Expires October 15, 2012                [Page 3]
Internet-Draft         MN Status Option for PMIPv6            April 2012

   available to detect the connectivity status of the attached mobile
   node.

   The mobile node status can be carried in the signaling exchange
   between the MAG and LMA.  Namely, the MAG can periodically, or event
   triggered, update the MN status to the LMA.  How the LMA use this
   information is outside the scope of this document.

3.2.  Use case scenarios

   The approach specified in this document provides additional benefits
   to some use cases involving flow mobility among multiple access
   technologies.  These use case scenarios are illustrated next:
   (a)  The user is accessing some services from both WLAN and 3GPP, and
        for some time the network link connecting to the WLAN access
        network is going to be released for some purposes, such as
        scheduled maintenance.  Then there are two choices for the LMA
        to change these IP flows, either switch the flows to the 3GPP
        access, or switch the flows to another WLAN access if possible.
        Without updated information about the status of the MN, the LMA
        can trigger an erroneous flow mobility decision (causing a long
        delay or data loss), for example if a flow is moved to an
        network interface that is currently in idle state.
   (b)  At residential areas during the night there are more people on
        WLAN and less people using cellular access, hence for the voip
        service is better to switch to cellular.  On the other hand,
        during the day, there are less people on WLAN and more people
        using cellular, so it is better to use the WLAN to offload the
        cellular network.  The LMA can change the flows according to the
        policies and the MN status, but it should reflect accurate
        information, as otherwise the flow handoff will suffer from long
        delays or data loss.
   (c)  The user is accessing some services from both WLAN and 3GPP, and
        an FTP IP flow is initiated which may cause the bandwidth
        resources to be insufficient.  The LMA may consider changing the
        flows for VoIP service from WLAN to 3GPP access according to the
        operator polices and other factors (e.g., user preferences).  If
        the LMA only knows that the MN is connected, but the real status
        of the 3GPP radio link connecting MN and MAG is poor, then long
        delay or data loss may be introduced if the LMA moves the flow
        to the 3GPP access.

3.3.  Solution

3.3.1.  MAG considerations

   The MAG can retrieve the Mobile Node status from some other network
   elements, such as MME in 3GPP or Paging controller in WiMAX.  And the

Tu, et al.              Expires October 15, 2012                [Page 4]
Internet-Draft         MN Status Option for PMIPv6            April 2012

   MAG may periodically or event triggered update this information to
   the LMA, so that this information can be used as one of the factors
   to make the decision of flow mobility by the LMA.

3.3.2.  LMA considerations

   The LMA receives the mobile node status information from the MAG, and
   makes the decision of flow mobility for a specific IP flow according
   to the operator policies and other factors (e.g., user preferences
   and MN status).  How the LMA use this information is outside the
   scope of this document.

   We consider next the use case (a) of Section 3.2 as an example.  If
   the WLAN infrastructure is scheduled for maintenance, the LMA can
   check the operator policies with other factors to decide which is the
   best candidate access network to move the flows that were using the
   WLAN.  One example of possible prioritized list could be the
   following:
   1.  3GPP access with MN status set to "connected".
   2.  Another WLAN access infrastructure.
   3.  3GPP access with MN status set to "idle".

   In this case, if the MN status is "idle" in 3GPP access network, the
   LMA will handoff the mobile node to another WLAN access without
   trying to wake up the mobile node and re-establish the link
   connecting between MN and MAG.

   If the priority of each access network assumes to be set in a
   different way, as for example the following:
   1.  3GPP access with MN status set to "connected".
   2.  3GPP access with MN status set to "idle".
   3.  Another WLAN access infrastructure.

   In this case, the LMA will first try to wake up the mobile node in
   the 3GPP access and re-establish the link connecting between the MN
   and the MAG.  If this procedure can be done successfully, the LMA
   will not attempt to handoff the mobile node to another WLAN access,
   but will initiate the flow mobility in the 3GPP access.

3.4.  Mobile Node Status Option

   A new option, called Mobile Node Status Option, is defined for using
   it in messages (e.g., PBU and PBA) exchanged between a local mobility
   anchor and a mobile access gateway.

Tu, et al.              Expires October 15, 2012                [Page 5]
Internet-Draft         MN Status Option for PMIPv6            April 2012

      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
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |MN-status Type |MN-StatusLength|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Reserved                     |   MN status   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 1: MN Status Option

   MN-status Type
      To be assigned by IANA.

   MN-status Length
      8-bit unsigned integer indicating the length in octets of the
      option, excluding the type and length fields.

   Reserved
      This field is unused for now.  The value MUST be initialized to 0
      by the sender and MUST be ignored by the receiver.

   MN status
      The status of the mobile node attached from a specific access
      network, such as WiFi, WiMAX and 3GPP.  Currently the value of the
      MN status can be as follows:

      1: connected,

      2: disconnected,

      3: idle/power saving mode

      4: reserved.

4.  Security Considerations

   TBD

5.  IANA Considerations

   TBD

Tu, et al.              Expires October 15, 2012                [Page 6]
Internet-Draft         MN Status Option for PMIPv6            April 2012

6.  Contributors

   The following people contributed to this document (in no specific
   order):

      Yifeng Bi
      ZTE
      bi.yifeng@zte.com.cn

7.  Normative References

   [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.

Authors' Addresses

   Yangwei Tu
   ZTE
   Nanjing
   Nanjing
   China

   Email: tu.yangwei@zte.com.cn

   Chunhui Zhu
   ZTE
   Nanjing
   Nanjing
   China

   Email: zhu.chunhui@zte.com.cn

Tu, et al.              Expires October 15, 2012                [Page 7]
Internet-Draft         MN Status Option for PMIPv6            April 2012

   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 6236
   Email: cjbc@it.uc3m.es
   URI:   http://www.it.uc3m.es/cjbc/

   Carl Williams
   MCSR Labs
   USA

   Phone:
   Email: carlw@mcsr-labs.org
   URI:

Tu, et al.              Expires October 15, 2012                [Page 8]