NETEXT Working Group Y. Tu Internet-Draft C. Zhu Intended status: Standards Track ZTE Expires: January 10, 2013 CJ. Bernardos UC3M C. Williams MCSR Labs July 9, 2012 MN Status Option for Proxy Mobile IPv6 draft-tu-netext-mn-status-option-02 Abstract IP flow mobility enables the ability of movement of selected flows from one access technology to another. This document extends the Proxy Mobile IPv6 signaling to convey mobile node's status information that can be used by the network to decide when and how perform flow mobility. It also defines options allowing the network getting information about different mobile node capabilities, which might be considered to decide how to tackle the node's 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 January 10, 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 (http://trustee.ietf.org/license-info) in effect on the date of Tu, et al. Expires January 10, 2013 [Page 1] Internet-Draft MN Status Option for PMIPv6 July 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. New MN status and capabilities options for PMIPv6 . . . . . . . 3 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Use case scenarios . . . . . . . . . . . . . . . . . . . . 4 3.3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. MAG considerations . . . . . . . . . . . . . . . . . . 5 3.3.2. LMA considerations . . . . . . . . . . . . . . . . . . 5 3.4. Mobile Node Status and Capabilities Options . . . . . . . . 6 3.4.1. Mobile Node Capability Status Option . . . . . . . . . 6 3.4.2. Mobile Node Connectivity Status Option . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Tu, et al. Expires January 10, 2013 [Page 2] Internet-Draft MN Status Option for PMIPv6 July 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 mobile node (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 when and how to perform flow mobility. It is therefore helpful to provide the LMA with additional information from the MN, so the LMA can 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 anchor, and by enabling the mobile access gateway to update that information as needed. It is also useful to support the mobile access gateway to convey information to the local mobility anchor about specific capabilities of attached mobile nodes. These capabilities may include, for example, the support of a logical interface (to hide from the IP stack the existence of multiple physical interfaces, which may be simultaneously attached to different MAGs), the availability of a dual IPv4/IPv6 stack at the mobile node, etc. This document defines two new mobility options, the MN Capability Status option and the MN Connectivity Status option for Proxy Mobile IPv6 (PMIPv6), that can be used by the mobile access gateway (MAG) for carrying information to the local mobility anchor about the MN status with the correspondent access network and its capabilities. 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. New MN status and capabilities options for PMIPv6 3.1. Overview In some Proxy Mobile IPv6 deployments, a mobile network (e.g., the one defined by the 3GPP) needs to support multiple access Tu, et al. Expires January 10, 2013 [Page 3] Internet-Draft MN Status Option for PMIPv6 July 2012 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 piece of information to help the LMA is the current mobile node status at the different access networks it might be attached to. The mobile access gateway is the right PMIPv6 network entity to detect the mobile node status using, in addition to the mechanisms defined in RFC5213 [RFC5213], any access network specific mechanism that is available to detect the connectivity status of the attached mobile node. The MAG can provide the mobile node status information to the LMA as part of the signaling exchange between MAG and LMA. Namely, the MAG can periodically, or triggered by a particular event, 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 simultaneously attached and accessing some services from both WLAN and 3GPP networks, 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. Triggered by that event, there are two choices the LMA can take to reallocate these IP flows, either to switch the affected flows to the 3GPP access, or to switch the flows to another WLAN access (if available). Without updated information about the status of the MN, the LMA can trigger an erroneous flow mobility decision (leading to a long delay and/or data losses), for example if a flow is moved to an network interface that is currently in idle state or perceiving a low signal quality. (b) At residential areas, during night there are more people using WLAN, and less people using a cellular access, hence for the VoIP service it might be better to switch some users to the cellular access. On the other hand, during the day, there are less people on WLAN and more people using cellular, so it might be better to use the WLAN to offload the cellular network. The LMA can move flows according to policies, but without accurate knowledge of the MN status the flow handoff may suffer from delays, data loss or other performance problems. Tu, et al. Expires January 10, 2013 [Page 4] Internet-Draft MN Status Option for PMIPv6 July 2012 (c) The user is accessing some services from both WLAN and cellular, 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 the WLAN to the 3GPP access according to the operator polices and other factors (e.g., user preferences). If the LMA only has information about which networks the MN is connected, but not the real status/quality of each of them, it might be that the LMA incorrectly decides to move a flow (e.g., if the 3GPP radio link connecting between MN and MAG is poor) resulting in then long delay or data loss. 3.3. Solution 3.3.1. MAG considerations The MAG can retrieve the Mobile Node status from some other network elements, such as the Mobility Management Entity (MME) in 3GPP, the Paging controller in WiMAX, or the Access Point in WLAN. The MAG may periodically, or triggered by a specific event, 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. In particular, the MAG can also retrieve the radio quality of the MAG-MN link from other network elements (e.g., the eNB in 3GPP), and a threshold can be configured locally or downloaded (e.g., from the network management system) as the operator policies. As soon as the radio quality of the MAG-MN link drops below this threshold, the MAG updates this event to the LMA as a part of Mobile Node status information, which helps the LMA making the best decision of performing flow mobility. In addition, some Mobile Node capabilities information, such as logical interface support or dual-stack availability, can also be carried from the MAG to the LMA, helping to make a flow mobility decision. How the MAG obtains this capabilities information is out of scope of this document. 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 uses 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 Tu, et al. Expires January 10, 2013 [Page 5] Internet-Draft MN Status Option for PMIPv6 July 2012 WLAN. One example of possible prioritized list could be the following: 1. 3GPP access with MN status set to "connected". 2. Another available WLAN access infrastructure. 3. 3GPP access with MN status set to "idle". In this case, if the MN status is "idle" in the 3GPP access network, the LMA will hand off the mobile node to another WLAN access without trying to wake up the mobile node and re-establish the link connecting the MN and the MAG. Another example is the following, in which the priority of each access network is set in a different way: 1. 3GPP access with MN status set to "connected". 2. 3GPP access with MN status set to "idle". 3. Another available 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 the MN and the MAG. If this procedure can be done successfully, the LMA will not attempt to hand off the mobile node to another WLAN access, but it will initiate the flow mobility to the 3GPP access. 3.4. Mobile Node Status and Capabilities Options This section defines extensions to the Proxy Mobile IPv6 [RFC5213] Protocol messages. 3.4.1. Mobile Node Capability Status Option A new option, called Mobile Node Capability Status Option, is defined to be included in the PMIPv6 signaling (e.g., PBU and PBA messages) exchanged between a local mobility anchor and a mobile access gateway. This option is used for conveying the mobile node's features support capability information. Its format is the following: 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-Ca-St Type |MN-Ca-St Lngth | Reserved |L|D|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: MN Capability Status Option Tu, et al. Expires January 10, 2013 [Page 6] Internet-Draft MN Status Option for PMIPv6 July 2012 MN-Ca-St Type To be assigned by IANA. MN-Ca-St Lngth 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. L 1-bit unsigned integer indicating the capability of supporting the logical interface feature by the mobile node. The value is set to 1 when logical interface is supported by the mobile node, otherwise it is set to 0. D 1-bit unsigned integer indicating the IPv6/IPv4 Dual Stack support of the mobile node. The value is set to 1 when IPv6/IPv4 Dual Stack is supported by the mobile node, otherwise it is set to 0. M 1-bit unsigned integer indicating the Mobile IPv6 support of the mobile node. The value is set to 1 when Mobile IPv6 stack is supported by the mobile node, otherwise it is set to 0. 3.4.2. Mobile Node Connectivity Status Option A new option, called Mobile Node Connectivity Status Option, is defined to be included in the PMIPv6 signaling (e.g., PBU and PBA messages) exchanged between a local mobility anchor and a mobile access gateway. This option is used for conveying to the network the mobile node's air link connectivity status information. Its format is the following: 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-Co-St Type | MN-Co-St Lngth| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | MN status |R Q| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tu, et al. Expires January 10, 2013 [Page 7] Internet-Draft MN Status Option for PMIPv6 July 2012 Figure 2: MN Connectivity Status Option MN-Co-St Type To be assigned by IANA. MN-Co-St Lngth 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. RQ This field is used to indicate when the radio quality of the MAG-MN link dropped below a certain threshold configured by the operators. The value can be set as follow: 00: the radio quality of the MAG-MN link does not drop below the threshold, 01: the radio quality of the MAG-MN link drops below the threshold. All other values are reserved. 4. Security Considerations TBD 5. IANA Considerations TBD Tu, et al. Expires January 10, 2013 [Page 8] Internet-Draft MN Status Option for PMIPv6 July 2012 6. Contributors The following people contributed to this document (in no specific order): Yifeng Bi ZTE bi.yifeng@zte.com.cn Tricci So ZTE USA tso@zteusa.com 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 January 10, 2013 [Page 9] Internet-Draft MN Status Option for PMIPv6 July 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 January 10, 2013 [Page 10]