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]