Internet DRAFT - draft-tu-netext-mn-status-option
draft-tu-netext-mn-status-option
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]
