Internet DRAFT - draft-tian-netext-flow-mobility-trigger-ps
draft-tian-netext-flow-mobility-trigger-ps
NETEXT Working Group T. Tian
Internet-Draft W. Yan
Intended status: Informational Y. Wei
Expires: April 24, 2012 ZTE
October 22, 2011
Problem Statement of Flow Mobility Triggering
draft-tian-netext-flow-mobility-trigger-ps-00
Abstract
This document is a contribution draft which summaries the potential
approaches for flow mobility triggering and gives analysis of these
trigger methods based on the long-standing active discussion in the
mailing list, which aims to achieve a common consensus on the issues
and the working scope related to flow mobility trigger in Netext WG.
Requirements Language
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 RFC 2119[RFC2119].
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 April 24, 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
Tian, et al. Expires October 22, 2012 [Page 1]
Internet-Draft Abbreviated-Title April 2012
(http://trustee.ietf.org/license-info) in effect on the date of
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. Flow mobility trigger Summary . . . . . . . . . . . . . . . . 3
2.1. Host-based triggering . . . . . . . . . . . . . . . . . . 3
2.2. Network-based triggering . . . . . . . . . . . . . . . . . 5
3. Other main issues . . . . . . . . . . . . . . . . . . . . . . 6
3.1. MN capability discovery . . . . . . . . . . . . . . . . . 6
3.2. Policy synchronization . . . . . . . . . . . . . . . . . . 7
4. Discussion for Decision . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Tian, et al. Expires October 22, 2012 [Page 2]
Internet-Draft Abbreviated-Title April 2012
1. Introduction
With the rapid growth of wireless network technology and the terminal
technology, a mobile node that is equipped with various access
modules has the ability to simultaneously connect to different access
technologies. A definition of flow mobility is quoted from the
mailing list:" In the context of Proxy MIP6 is the switching of a
flow by the LMA from MAGx to MAGy when the MN is attached to the LMA
via multiple interfaces through different MAGs." Flow mobility is
now becoming an important issue to increase the availability of
different network resources and to help to provide better user
experience.
There has been lot of work focusing on supporting flow mobility in
Netext WG, i.e., [I-D.ietf-netext-logical-interface-support], the
"logical interface" defined in this draft makes all physical
interfaces to hide from the network layer and above, which is a
fundamental dependency for flow mobility. Flow mobility depends on
the existence of a logical interface on the host.
"Proxy Mobile IPv6 Extensions to Support Flow Mobility"
[I-D.ietf-netext-pmipv6-flowmob-ob] , this draft defines PMIP6
extensions to support follow mobility over multiple physical
interfaces. It describes how LMA excuses flow mobility based on the
enhanced PMIP6 protocol;
"Multi-access Indicator for Mobility"
[I-D.koodli-netext-multiaccess-indicator], this draft defines a new
EAP attribute to indicate to the network the MN's capability of
simultaneous multil-access and supporting of flow mobility.
But without making the trigger for flow mobility clear, the execution
of flow mobility will be a castle in the air. The triggering issue
has been discussed actively in the mailing list for a long time.
This document summarizes the main ideas, the related analysis and
relevant issues based on the discussion in mailing list, which aims
to achieve a common consensus and make progress for the further work.
2. Flow mobility trigger Summary
The trigger solutions are broadly grouped into two categories,
namely: Host-based triggering and Network-based triggering.
2.1. Host-based triggering
Tian, et al. Expires October 22, 2012 [Page 3]
Internet-Draft Abbreviated-Title April 2012
1. L3-signaling trigger
An example of L3-signaling solution is proposed in
[I-D.ietf-netext-logical-interface-support] section 7.3
regards: "As an example of mobile-based triggers, the LMA
could receive input (e.g.by means of a layer 2.5 function via
L3 signaling [RFC5677]) from the MN detecting changes in the
mobile wireless environment (e.g. weak radio signal, new
network detected, etc.). Upon receiving these triggers, the
LMA can initiate the flow mobility procedures. For instance,
when the mobile node only supports single-radio operation
(i.e. one radio transmitting at a time), only sequential(i.e.
not simultaneous) attachment to different MAGs over different
media is possible. In this case layer 2.5 signaling can be
used to perform the inter-access technology handover and
communicate to the LMA the desired target access technology,
MN-ID, Flow-ID and prefix."
However, specifying a MN/host to a MAG signaling related
to flow mobility at layer 3 has been put explicitly out of the
charter of this WG.
2. Explicit flow trigger
Another host-based solution was proposed in the mailing list:
"The MN can decide (based on policies) to change the flow and
send packets over a new interface. The MAG would forward the
packet with no problem and upon receiving this packet the LMA
would implicitly know that the MN has performed a flow
movement (again, based on policies). At this point the LMA
would just need to change its routing table accordingly and
start sending packets for this flow over the new interface
(similar rule to the one already specified for the mobile)."
This is a lightweight host-centric solution which is suitable
for the cases that the MN sends the UL flow and the MN itself
decides and triggers the flow movement. No extensions to the
existing RFC 5213 are needed, i.e. neither the modification of
data structures nor the addition of new signaling. But for
the case that the network decides the flow mobility based on
the network conditions, this solution is not suitable.
In 3GPP the work TS 23.261 [TS23261] of host-based model for flow
mobility based on MIP6 has been solved, which specifies the Stage
2 system description for IP flow mobility between a 3GPP and a
WLAN. As PMIP6 is a network-based mobility support protocol and
it does not require MNs to be involved in the mobility support
signaling, and there is also requirement to enable network
Tian, et al. Expires October 22, 2012 [Page 4]
Internet-Draft Abbreviated-Title April 2012
controlled flow mobility, for example, to release the traffic
pressure in the network based on network load conditions, the
preference is to develop a network centric (i.e. MAG/LMA
entities) flow mobility solution.
2.2. Network-based triggering
1. L2-signaling trigger (MAG trigger)
This approach is when a MN attaches to a new MAG, the MN uses
the L2 signaling to indicate the attachment is for flow
mobility , for example, with a new HI=FM value, then the MAG
sends the PBU with HI=FM, and the LMA updates an existing
session with the new interface and the new MAG. The old and
new prefixes are shared for the session.
This approach keeps the existing RFC 5213[RFC5213] model.
Advantage of this approach is that, with indication of the
specific L2 signaling, the network will be able to have
knowledge of the MN's capability of supporting flow mobility.
Concern is that, the L2 signaling needs to be extended for
flow mobility trigger purpose. However, L2 signaling is
specified for specific link types in relevant SDOs, the
extension work of specific L2 signaling is out of scope of
IETF and should be done in other relevant SDOs. For example,
3GPP is one of the important potential customers; 3GPP owns
the specific L2 used to access their system. It is possible
that 3GPP may need to add extensions to make this solution
work in their architecture, but even though, relying on
modification of specific layer 2 protocols will let the
solution only works with some technologies. As we are not
chartered to come up with the 3GPP-only solution, both the
cases when either new L2 signaling is available or L2
signaling is unavailable need to be included in our solution.
2. LMA trigger
This approach is now regarded as a pure network-centric
trigger based on the network condition, and it is just up to
the LMA that decides and triggers the flow mobility without
involvement of the MN. Lots of concerns about this approach
are raised on the mailing list.
Firstly, how does the network know whether the MN has the
capability to support flow mobility or not. This issue will
be discussed detailed in the later section.
Tian, et al. Expires October 22, 2012 [Page 5]
Internet-Draft Abbreviated-Title April 2012
Secondly, how does the LMA actually decide to route flows on
one access or the other? This is another major concern raised
on the mailing list is related to how flow mobility would work
when an MN attaches to a wifi access and the LMA switches a
flow(s) to the MAG serving the MN via that wifi. In cellular
networks, the handovers are controlled by the network because
the network always knows the link condition of the MN by the
measurement reports provided by the MN. But in WLAN there is
a huge difference. Others than the MN measurement report
mechanism in the cellular network, the MN has no way of report
the LMA about its connectivity/link status , e.g. the
congestion, or other state of its attachment to a AP. Flows
forwarded by the LMA to the MN via the wifi-MAG could be
dropped if the MN has moved out of that wifi coverage or the
link is congested. There are no existing protocols which can
be used for the external interface between LMA and MN, the LMA
only knows that the MN has attached via a MAG. It also
mentioned in the mailing list that, there are solutions which
allow the owner of the WLAN to know of the quality and status
of the network. Even though, the lack of providing relevant
information to the LMA is still an issue.
One view in the mailing list thought the intent of this work
is on specifying how the traffic associated with a session is
switched to an alternate MAG, the above points are outside the
scope. But without knowing the information and feedback from
the MN side, the LMA is hard to make a correct decision for
flow mobility.
Thirdly, where does the LMA would receive the policies related
to flow mobility, should there be a solution to have policies
in the LMA, should the policy synchronization between LMA and
MN be considered? This will be discussed in the later
section.
3. Other main issues
3.1. MN capability discovery
The network only offers flow mobility to the MN that indicates its
support for the feature. Actually the capability discovery can be
achieved by layer2, 3 or even 7, but within the restriction of
current charter of this work, if this should be done, it has to be
done at layer 2.
Following assumptions are summarized in the mailing list:
Tian, et al. Expires October 22, 2012 [Page 6]
Internet-Draft Abbreviated-Title April 2012
1. MN capabilities are known;
assumption that the indication of capability is achieved by
Layer 3 or Layer 7 which is out of scope here;
2. Possible existence of layer 2 signaling to provide hints (HI =
Flow Mobility);
"Multi-access Indicator for
Mobility"[I-D.koodli-netext-multiaccess-indicator] provides
one way to achieve this; it defines a new EAP attribute which
can be used to indicate the MN's capability during the EAP-AKA
procedure. The purpose of the multi-access indicator ID is
twofold: to enable the MN to indicate its capability and
willingness for flow mobility (through the AT_MA_IND
attribute). Second, to enable AAA to authorize the user for
flow mobility. So, it's the MN which is indicating the device
capability, and the AAA providing the authorization for the
flow mobility service.
3. Possible non-existence of layer-2 signaling to provide hints (HI
= Unknown)
3.2. Policy synchronization
There is a need of policy synchronization between the MN side and the
network side. In [I-D.ietf-netext-pmipv6-flowmob-ob] , it states
that:
"As described in[I-D.ietf-netext-logical-interface-support] , there
should be a local policy in place that ensures that packets are
forwarded coherently. This SHOULD be enforced by the logical
interface engine [I-D.ietf-netext-logical-interface-support]. For
unidirectional outbound communications, there SHOULD also be a policy
at the mobile node defining which physical interface is used to send
the traffic. For bidirectional outbound communications, there SHOULD
be also such a policy, but its content must be consistent with the
policy at the network-side (the details about how this consistency is
ensured are out of the scope of this document)."
The simplest way to do is to statically configure the same policies
on the MN and the LMA, but this is not flexible and not unrealistic
in the practical deployment.
For dynamic configuration of policies, ANDSF defined by 3GPP is
proposed in the mailing list as one solution to help to achieve
policy synchronization between the MN and the network. ANDSF is
designed specific to be a MN-centric solution where policies are
Tian, et al. Expires October 22, 2012 [Page 7]
Internet-Draft Abbreviated-Title April 2012
provisioned in the MN and the MN decides which network technologies
and access networks it needs to connect to, under what conditions,
and which IP traffic needs to be routed on such accesses. ANDSF has
the interface with MN, for example the push model in 3GPP, ANDSF can
send SMS to UE via S14 interface to request MN to update it policy.
The same policies in ANDSF delivered to the MN can be also offered to
the network nodes, i.e. the MAG/LMA. There is neither MN-AR
interface nor ANDSF-MAG/LMA interface in the existing specifications.
To support this ANDSF approach, additional interfaces may be needed.
Alternatively, policies delivery from PCRF to MAG\LMA is another
suggestion. However, PCRF does not have the information to tell the
LMA which policies are used for flow mobility, if the solution may be
used, enhancement of PCC functionality will be needed.
Moreover, a scenario raise on the mailing list shows that, ANDSF
policies may be based also on location of the MN. For example the MN
should prefer WLAN only in a given location. When the MN is attached
over WLAN there is no way for the LMA to verify the location of the
MN and therefore to verify MN actions based on policies. In this
case, this is another reason for the LMA to know the information of
MN in WLAN. The lack of MN-AR interface is surely an issue for
supporting some flow policies.
4. Discussion for Decision
The feature of no involvement of the MN of PMIP6 decides it would not
have the same degree of control in terms of handover flows or the
granularity compared with MIP6. The PMIP6 based flow mobility would
be applicable in deployments which leverage network based mobility,
and the scope of this work is NOT intended to provide the same set of
capabilities that exist in the host-based flow mobility solution.
Could we work on the flow mobility trigger in this WG? If the
solution is related to the common protocol (e.g. EAP) which is used
in specific L2 signaling, could it be discussed in this WG? There is
strong reason for the LMA to obtain the information of MN in access
networks, such as connectivity status, link characteristics and even
the location information, either for the LMA to make a correct
decision for flow mobility or to support some complex flow policies.
Where could the LMA get the policies for flow mobility, and how the
policies are synchronized with the MN's, are these issues still
needed to be considered?
One option suggested in the mailing list is that low mobility for
PMIP6 is applicable only in those access networks wherein the access
network elements are aware of the state of the MNs connection and
congestion state. The MAG can use this information to signal to an
Tian, et al. Expires October 22, 2012 [Page 8]
Internet-Draft Abbreviated-Title April 2012
LMA attachment state and potentially cause flows to be switched to an
alternative MAG. It may be okay to have specific statements about
the limitations of flow mobility for PMIP6 documented as a sort of
disclaimer.
This document aims to make clear about what is in scope of this work
and some of the limitations as well.
5. IANA Considerations
This document makes no request of IANA.
6. References
6.1. 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 RFC 5213,
August 2008.
6.2. Informative References
[I-D.ietf-netext-logical-interface-support]
Melia, T. and S. Gundavelli, "Logical Interface Support
for multi-mode IP Hosts",
draft-ietf-netext-logical-interface-support-03 (work in
progress), September 2011.
[I-D.ietf-netext-pmipv6-flowmob-ob]
Bernardos, CJ., "Proxy Mobile IPv6 Extensions to Support
Flow Mobility", draft-ietf-netext-pmipv6-flowmob-01 (work
in progress), September 2011.
[I-D.koodli-netext-multiaccess-indicator]
Koodli, Rajeev. and Jouni. Korhonen, "Multi-access
Indicator for Mobility",
draft-koodli-netext-multiaccess-indicator-02 (work in
progress), August 2011.
[RFC5677] Melia, T., Bajko, G., Das, S., Golmie, N., and JC. Zuniga,
"IEEE 802.21 Mobility Services Framework Design (MSFD)",
RFC RFC 5677, December 2009.
Tian, et al. Expires October 22, 2012 [Page 9]
Internet-Draft Abbreviated-Title April 2012
[TS23261] "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects;IP flow
mobility and seamless Wireless Local Area Network (WLAN)
offload;", 3GPP 3GPP TS 23.261, September 2010.
Authors' Addresses
Tian Tian
ZTE
No.68 Zijinghua Rd
Nanjing, Yuhuatai District 210012
China.P.R
Phone: +86-25-5287-1267
Email: tian.tian1@zte.com.cn
Wei Yan
ZTE
No.68 Zijinghua Rd
Nanjing, Yuhuatai District 210012
China.P.R
Phone: +86-25-5287-0503
Email: yan.wei8@zte.com.cn
Yuan Wei
ZTE
No.68 Zijinghua Rd
Nanjing, Yuhuatai District 210012
China.P.R
Phone: +86-25-5287-1091
Email: wei.yuan2@zte.com.cn
Tian, et al. Expires October 22, 2012 [Page 10]
