MN Status Option for Proxy Mobile IPv6
draft-tu-netext-mn-status-option-01
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yangwei Tu , Chunhui Zhu , Carlos J. Bernardos , Carl Williams | ||
| Last updated | 2012-04-13 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
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]