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]