Kyoungjae Sun Internet Draft Younghan Kim Intended status: Informational Soongsil University Expires: October 2014 April 22, 2014 Use case analysis for supporting flow mobility in DMM draft-sun-dmm-use-case-analysis-flowmob-dmm-02.txt Abstract Distributed Mobility Management (DMM) allows network traffic to distribute among multiple mobility anchors which have mobility functions to solve the existing problems in current centralized mobility protocols. There are many DMM approaches extending network- based mobility protocols (e.g. Proxy Mobile IPv6). In Proxy Mobile IPv6 (PMIPv6) [RFC5213], they allow a mobile node to connect to PMIPv6 domain through different physical interfaces. In this reason, flow mobility that enables movement between physical interfaces of mobile node is proposed. In this document, we present some use cases to support flow mobility in DMM domain and analyze some problems. These use cases are based on scenarios of flow mobility in PMIPv6. In these scenarios, a multi-interface mobile node connects to different distributed mobility access points and move specific flows from one interface to another. These use cases have common issues which will be analyzed in detail. 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 21, 2014. Sun, et al. Expires October 22, 2014 [Page 1] Internet-Draft use-case-analysis-flowmob-dmm April 2014 Copyright Notice Copyright (c) 2013 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 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 ................................................ 2 2. Terminology ................................................. 3 3. Use case scenario ........................................... 4 3.1. Use case 1 ............................................. 5 3.2. Use case 2 ............................................. 7 3.3. Use case 3 ............................................. 9 4. Use case analysis ........................................... 11 4.1. Sharing information between distributed anchors ........ 11 4.2. Mobile node moves physically with multiple interfaces .. 11 5. Considering Control/Data Separation ......................... 12 6. Considering Multicast Routing ............................... 13 6. Security Considerations ..................................... 13 7. IANA Considerations ......................................... 13 8. References .................................................. 14 8.1. Normative References ................................... 14 8.2. Informative References ................................. 14 9. Acknowledgments ............................................. 15 1. Introduction Distributed Mobility Management aims at overcoming limitations of centralized mobility protocol, such as a single point failure, scalability and non-optimal routing. In [draft-ietf-dmm-best- practices-gap-analysis], they distribute existing mobility functions to access network, and show practices to use existing protocols (e.g. MIP, PMIP). When mobile node can use multiple interfaces and connect to network simultaneously or sequentially, flow mobility allows a mobile node Sun, et al. Expires October 22, 2014 [Page 2] Internet-Draft use-case-analysis-flowmob-dmm April 2014 to move specific traffic flows by using network status or policy. In NETEXT WG, [draft-ietf-netext-pmipv6-flowmob] explains about PMIPv6 based flow mobility and proposes some scenarios for supporting that. In this document, we combine PMIPv6 based flow mobility with DMM architecture. [draft-seite-dmm-dma] mentions about multi-interface support for network based DMM but not in detail. This document refers DMM architecture and message flows from [draft-bernardos-dmm- distributed-anchoring] and [draft-seite-dmm-dma]. For supporting flow mobility in DMM, we also make some use cases based on three scenarios in [draft-ietf-netext-pmipv6-flowmob]. From analyzing these use cases, it would incline that multi-interface mobile node can connect to different distributed anchors and move traffic flows between physical interfaces. 2. Terminology 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]. The following terms used in this document are defined in the Proxy Mobile IPv6 [RFC5213]: Proxy Binding Update (PBU) Proxy Binding Acknowledgement (PBA) The following terms are defined in the Proxy Mobile IPv6 Extensions to Support Flow Mobility [draft-ietf-netext-pmipv6-flowmob]: FMI (Flow Mobility Initiate) FMA (Flow Mobility Acknowledgement) FMC (Flow Mobility Cache) The following terms are defined and used in this document: Distributed-Mobile Access Gateway (D-MAG): It provides an IP prefix to each attached mobile node. D-MAG is the topological anchor point of mobile node's prefix. It performs regular IPv6 routing for connecting mobile node directly and when mobile node moves and attaches to another D-MAG, similar to LMA in [RFC5213], it tracks the mobile node location and performs mobility routing to forward packets via D-MAG where mobile node is attached. Sun, et al. Expires October 22, 2014 [Page 3] Internet-Draft use-case-analysis-flowmob-dmm April 2014 3. Use case scenario In PMIPv6-based DMM, distributed mobility anchors have functions of MAG and LMA. As shown in figure 1, distributed mobility anchors called Distributed Mobile Access Gateway (D-MAG) support same or different access technologies so that different physical interfaces of mobile node can access to D-MAG simultaneously or sequentially. When a mobile node attaches to network, the D-MAG may assign prefix and support regular IPv6 routing. When the mobile node moves to another D-MAG, previous D-MAG may perform as a mobility anchor like LMA which exchanges signaling messages (e.g. PBU/PBA) and supports mobility routing(e.g. tunneling). In [I-D.ietf-netext-logical-interface-support], logical interface is defined that allows the mobile node to move different traffic flows to different physical interfaces regardless of the assigned prefixes on those interfaces. By using the logical interface, mobile node can accept incoming packets which is addressed to another interface of mobile node. Flow mobility cache which is separated from the binding cache is defined [draft-ietf-netext-pmipv6-flowmob] to contain all registered flow information. This specification uses the format of flow binding list defined in [RFC6089]. Similarly to [draft-ietf- netext-pmipv6-flowmob], we assume that mobile node have logical interface and D-MAG includes flow cache entry. There are three use cases to support flow mobility in DMM. Sun, et al. Expires October 22, 2014 [Page 4] Internet-Draft use-case-analysis-flowmob-dmm April 2014 CN2 * * flow2 * +--------+ +--------+ | MR | mobility routing | MR | |--------|----------------------|--------| | D-MAG1 |******* tunnel *******| D-MAG2 | flow1 |--------|----------------------|--------| flow3 CN1 ///////| AR | | AR |,,,,,,, CN3 +--------+ +--------+ / | *|` / | *|` / | mobile node *|` / | +-------------------+ *|` / | | IP | *|` / | |-------------------| *|` / | | Logical interface | *|` / | |---------+---------|*****|` / +-----| if1 | if2 |-----+` ////////+---------+---------+``````` Figure 1 3.1. Use case 1 The first possible use case, as shown in Figure 2, assumes that multiple interfaces attach to DMM network sequentially and movement of flow starts from the activation of secondary interface of mobile node. In this case, basic operation may follow normal PMIPv6 protocol as follows: Sun, et al. Expires October 22, 2014 [Page 5] Internet-Draft use-case-analysis-flowmob-dmm April 2014 MN D-MAG2 D-MAG1 Corresponding Nodes | | | | | flow x | flow x | | pref1::mn | pref1::mn | pref1> if1<-------------------------->|<---------------->CN1 | | | | | flow y | flow y | | pref1::mn | pref1::mn | if1<-------------------------->|<---------------->CN2 | | | | | attach | | | If2----------->| | | | | PBU | | | |(D-MAG1, MN-ID)| | | |-------------->| | | make decision for | | | moving flow | | | |====tunnel=====| | | | | | | | PBA | | | |(pref1, flow x)| | | |<--------------| | | | | | | flow x | flow x | flow x | | pref1::mn | pref1::mn | pref1::mn | if2<---------->|<=============>|<---------------->CN1 | | | | | flow y | flow y | | pref1::mn | pref1::mn | if1<-------------------------->|<---------------->CN2 | | | | | flow z | flow z | | pref2::mn | pref2::mn | pref2> if2<---------->|<-------------------------------->CN3 | | | Figure 2 Sun, et al. Expires October 22, 2014 [Page 6] Internet-Draft use-case-analysis-flowmob-dmm April 2014 o When a mobile node initially attaches to the D-MAG1 using the physical interface if1, the D-MAG1 should assign prefix pref1 and support regular IPv6 routing. In this time, no mobility function is used. Mobile node may communicate with one or more corresponding nodes after receiving pref1 from D-MAG1. However, D-MAG1 SHOULD know the information of all flows used by if1 of mobile node. D-MAG1 already has binding cache entry and flow cache entry so it can update its own entries. TS option in the IPv6 header of packet can be used to update flow cache entry. o During the time, mobile node connects to D-MAG1 through the if1, it could enable another interface if2 to attach to D-MAG2. Upon D-MAG2 receives information (discussed about this operation later.), the D-MAG2 may send a PBU message to the D-MAG1 to request mobility routing. In the PBU message, it SHOULD include the mobile node identifier and the address of D-MAG1. It may also include the request for supporting flow mobility because the D- MAG1 does not observe that the mobile node connects to the D-MAG2 by using the another interface. o When the D-MAG1 receives the PBU message, the D-MAG1 SHOULD make a tunnel first with the D-MAG2 and determine what flows will move to the D-MAG2. Decision method or policy for flow mobility is out of scope of this document. After decision, the D-MAG1 updates its binding cache entry and flow cache entry for moving flow. Finally, the D-MAG1 sends a PBA message to the D-MAG2 and forwards moving flows to the D-MAG2via tunnel. In the PBA message, additional contents, such as Flow Identification option [RFC6089] or the service type of flow, are needed to provide the flow information. After receiving the PBA message, the D-MAG2 updates its routing table and delivers packets received from the D-MAG1 to if2. Independently, the D-MAG2 also SHOULD assign a new prefix to if2 for normal IPv6 routing because all D-MAGs have location management and address allocation function in DMM. 3.2. Use case 2 The second possible case, as shown in Figure 3, assumes that multiple interfaces attach to network simultaneously. Each interface has been assigned prefixes from the different D-MAGs. When several flows are already existed through both interfaces, basic operation will be as follows: Sun, et al. Expires October 22, 2014 [Page 7] Internet-Draft use-case-analysis-flowmob-dmm April 2014 MN D-MAG2 D-MAG1 Corresponding Nodes | | | | | flow x | flow x | | pref1::mn | pref1::mn | pref1> if1<-------------------------->|<---------------->CN1 | | | | | flow y | flow y | | pref2::mn | pref2::mn | pref2> if2<---------->|--------------------------------->CN2 | | | | | Use special method to share | | | between D-MAGs| | | | | | | | PBU | | | |(D-MAG1, MN-ID)| | | |-------------->| | | | | | | |=====tunnel====| | | | | | | | PBA | | | | (MN-ID, pref1)| | | |<--------------| | | | | | | | Decide to move | | | | flow x | | | FMI | | | |(MN-ID,flow(x)_info) | | |<--------------| | | | FMA | | | |-------------->| | | flow x | flow x | flow x | | pref1::mn | pref1::mn | pref1::mn | if2<---------->|<=============>|<---------------->CN1 | flow y | flow y | flow y | | pref2::mn | pref2::mn | pref2::mn | if2<---------->|<-------------------------------->CN2 | | | | Figure 3 Sun, et al. Expires October 22, 2014 [Page 8] Internet-Draft use-case-analysis-flowmob-dmm April 2014 o When the mobile node attaches to the different D-MAGs through multiple interfaces, each interface has been assigned different prefixes and managed separately. In this figure, if1 and if2 are connecting to the D-MAG1, D-MAG2 and using the pref1, the pref2, respectively. To support flow mobility, a special method in which both D-MAGs share information of mobile nodes attached to network, activated flows, and network policy (will discuss chapter 4) is needed. o In the certain time, when the network decides to move a specific flow, flow x in this figure, first both D-MAGs exchange PBU/PBA messages to bind prefix of mobile node's interface. However, in this case, the PBU/PBA messages are only for binding prefix. So D-MAG1 just updates binding cache entry but no traffic path is changed. To do this, the modification of PBU/PBA or functions of D-MAG may be needed. After exchanging signaling messages, tunnel is setup between the D-MAG1 and the D-MAG2, but no traffic flow moves through this interface yet. o Considering move a specific flow from the D-MAG1 to the D-MAG2, the D-MAG1 SHOULD send a request message for the D-MAG2 because the flow information is only stored in the D-MAG1. Since the D- MAG1 cannot send a PBA message which has not been triggered in response to a received PBU message, new signaling messages are defined to cover this case. In [draft-ietf-netext-pmipv6-flowmob- 06], they defined a new signaling message, FMI/FMA message, which contains the MN-Identifier, the Flow Identification Mobility option information, and the type of flow mobility operation (add flow). Adjusting the scenario of this document in the DMM, the D- MAG2 may receive the FMI message from the D-MAG1, update the flow cache entry, and send a FMA message to reply. Finally, the flow will move to if2 via the D-MAG2 using mobility routing. 3.3. Use case 3 The last possible case, as shown in Figure 4, the multi interfaces of mobile node attach to network sequentially and flows are moved with a prefix granularity. It means that the flows are moved by moving prefixes among the different D-MAGs the mobile node is attached to. This use case also extends one scenario of [draft-ietf- netext-pmipv6-flowmob]. In this case, mobile node obtains a combination of prefix(es) in use and a new prefix(es). Basic operation will be as follows: Sun, et al. Expires October 22, 2014 [Page 9] Internet-Draft use-case-analysis-flowmob-dmm April 2014 o As shown in Figure 4, initially the mobile node connects to the D-MAG1 using if1 but if2 is not activated yet. When mobile node adds traffic flows which use a different service, each flow are assigned the different sets of prefixes. Since that, the D-MAG1 can perform mobility routing only for specific flow when D-MAG2 requests. After the mobile node turns on if2 and attaches to the D-MAG2, the D-MAG2 sends a PBU message to the D-MAG1 and the D- MAG1 determines what flow should be moved (using network policy, etc.). Since the flow moves with a finer granularity, the operation may complete from the D-MAG1 by making a tunnel and sending a PBA message included the prefix of selected flow (flow x in figure 4.). MN D-MAG2 D-MAG1 Corresponding Nodes | | | | | flow x | flow x | | pref1::mn | pref1::mn | if1<-------------------------->|<---------------->CN1 | | | | | flow y | flow y | | pref2::mn | pref2::mn | if1<-------------------------->|<---------------->CN2 | | | | | | | | | attach | | | if2----------->| PBU | | | |(D-MAG1, MN-ID)| | | |-------------->| | | | | | | | Decide to move | | | flow x to if2 | | | | | | |====tunnel=====| | | | | | | | PBA | | | | (pref1::mn) | | | |<--------------| | | flow x | flow x | flow x | | pref1::mn | pref1::mn | pref1::mn | if2<---------->|<=============>|<---------------->CN1 | flow y | flow y | flow y | | pref2::mn | pref2::mn | pref2::mn | if1<-------------------------->|<----------------->| | | | | | | | | Figure 4 Sun, et al. Expires October 22, 2014 [Page 10] Internet-Draft use-case-analysis-flowmob-dmm April 2014 4. Use case analysis In previous chapter, we describe three use cases of flow mobility in the PMIPv6-based DMM environment. Since these use cases attempts to extend simply existing flow mobility scheme of centralized mobility protocols to the distributed architecture, there are several limitations and unclear points. We will discuss about solutions to overcome limitations if we apply the flow mobility into the network- based DMM architecture. 4.1. Sharing information between distributed anchors In the PMIPv6, LMA which is a centralized anchor could manage all network entities and also all MAGs know location and address of LMA. Therefore, the MAGs can send the PBU packets immediately after detecting the access of the mobile node. However, in the distributed architecture, the D-MAGs have all functions of LMA and MAG in PMIPv6 and manage their network separately. For this reason, a method used to exchange information among D-MAGs is required. In this document, we describe several possible solutions. First, a new signaling message between D-MAGs that shares the address or policy can solve this problem. Another solution is that a centralized database gathers information of D-MAGs (e.g., attached device, traffic flows, etc.), so the D- MAGs access to the database when a mobile node attach to. In [draft- seite-dmm-dma], they already proposed a centralized database to share information between distributed access routers. Since centralized database performs only for sharing information, no data traffic from mobile node forwards to this database. The last solution is that mobile node sends a trigger message to request flow mobility. In this case, the trigger message may include the address of D-MAG which will send packets to another the D-MAG, flow information or another additional function. The trigger message may be defined on the Layer 3, and also be defined on the Layer 2. In previous works, the Handoff Indicator (HI) for fast handover can be used to trigger message for flow mobility. However, the trigger message from mobile node is not appropriate for network-based mobility because a mobile node makes signaling messages. 4.2. Mobile node moves physically with multiple interfaces We assumed that the mobile node moves flow between their physical interfaces without the physical movement of mobile node. However, in the real environment, the mobile node can move physically, so we should consider that interfaces perform physical handoff operation. Sun, et al. Expires October 22, 2014 [Page 11] Internet-Draft use-case-analysis-flowmob-dmm April 2014 When a mobile node moves physically in the DMM domain, each physical interface of the mobile node detaches and attaches to different D- MAGs supporting its access technologies. Traffic flows may move through tunnel between the previous D-MAG and the new D-MAG. As a result, the mobile node using multi-interfaces has two mobility anchors and two tunnels, and four D-MAGs related with one mobile node. It means a lot of network resources are needed to support multi-interface devices. 5. Considering Control/Data Separation For the implementation of distributed and dynamic mobility management solution, it could be considered to separate control and data plane by extending the centralized database mentioned in 4.1. In that case, beside centralized management functions, the database also has policies of network management policies and route decisions, so it can make decision and trigger to move the specific flows. Actually it is not fully distributed architecture but data can be distributed and forwarded without signaling messages between D-MAGs. [Paper-Chan] and several researches are proposed control/data separation schemes based on PMIPv6. In particular, Software-Defined Networking (SDN) has been proposed from [Paper-SDN] to simplify routing entities in the network. In that architecture, the centralized control function knows network topology, so when a device attaches to the network and sends data, the control function catches the packets, makes a path and pushes flow rules to routing entities (e.g. switch, router). Routing entities in that network just forward packets by the rules from the centralized control function. Although the SDN is not fully distributed architecture, it can achieve several requirements of DMM. SDN-based mobility management is expected to be a promising approach which will support mobility management for only moving user and session connectivity continuity for mobile users without the waste of network resources (e.g. tunneling). Moreover, by using SDN concept, we can adjust network policies easily for users and specific flows. Sun, et al. Expires October 22, 2014 [Page 12] Internet-Draft use-case-analysis-flowmob-dmm April 2014 6. Considering Multicast Routing In [I-D.ietf-dmm-requirements], they described that DMM should enable multicast solutions to avoid network inefficiency. In PMIPv6 multicast routing , the MAG perform as MLD proxy which maintains information of subscribers, aggregates MLD report and make multicast tunnel with multicast router. In DMM, similar with PMIPv6, D-MAG may perform MLD proxy function to deliver multicast traffic. Considering flow mobility, unicast traffic should be forwarded by using tunnel between D-MAGs but multicast traffic can be delivered directly through current D-MAG. To do that, however, there should be enhance functionality to perform MLD proxy in D-MAG and extension of protocol similar with PMIPv6 multicast method. 7. Security Considerations TBD 8. IANA Considerations This document makes no request of IANA. Sun, et al. Expires October 22, 2014 [Page 13] Internet-Draft use-case-analysis-flowmob-dmm April 2014 9. References 9.1. Normative References [RFC2119] Brander, 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. [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011. [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011. 9.2. Informative References [I-D.ietf-dmm-requirements] Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", draft- ietf-dmm-requirements-05 (work in progress), June 2013. [I-D.ietf-dmm-best-practices-gap-analysis] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. Bernardos, "Distributed Mobility Management: Current practices and gap analysis", draft-ietf-dmm-best- practices-gap-analysis-01 (work in progress), June 2013. [I.D.ietf-netext-logical-interface-support] Melina, T., and S. Gundavelli, "Logical Interface Support for multi-mode IP Hosts", draft-ietf-netext-logical- interface-support-07 (work in progress), April 2013. [I-D.seite-dmm-dma] Seite, P., Bertin, P., and J. Lee, "Distributed Mobility Anchoring", draft-seite-dmm-dma-06 (work in progress), Jan 2013. [I-D.bernardos-dmm-distributed-anchoring] Bernardos, CJ., and JC. Zuniga, "PMIPv6-based distributed anchoring", draft-bernardos-dmm-distributed-anchoring-02 (work in progress), April 2013. Sun, et al. Expires October 22, 2014 [Page 14] Internet-Draft use-case-analysis-flowmob-dmm April 2014 [Paper-Chan] Chan, H., "Proxy Mobile IP with Distributed Mobility Anchors", GlobeCom 2010 Workshop on Seamless Wireless Mobility, December 2010. [Paper-SDN] Open Networking Foundation White Paper, "Software-Defined Networking: the new norm for networks", ONF, 2012. 10. Acknowledgments Sun, et al. Expires October 22, 2014 [Page 15] Internet-Draft use-case-analysis-flowmob-dmm April 2014 Authors' Addresses Kyoungjae Sun Soongsil University 369, Sangdo-ro, Dongjak-gu, Seoul 156-743, Korea Email: gomjae@dcn.ssu.ac.kr Younghan Kim Soongsil University 369, Sangdo-ro, Dongjak-gu, Seoul 156-743, Korea Email: younghak@ssu.ac.kr Sun, et al. Expires October 22, 2014 [Page 16]