<Network Working Group>                                  Kyoungjae Sun
Internet Draft                                            Younghan Kim
Intended status: Informational                     Soongsil University
Expires: September 2015                                  March 9, 2015


           Use case analysis for supporting flow mobility in DMM
             draft-sun-dmm-use-case-analysis-flowmob-dmm-04.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), 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 September 9, 2015.


Sun, et al.             Expires September 9, 2015              [Page 1]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015

Copyright Notice

   Copyright (c) 2014 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 in fully DMM architecture ................. 4
      3.1. Use case 1 ............................................. 5
      3.2. Use case 2 ............................................. 6
      3.3. Use case 3 ............................................. 8
      3.4. Use case analysis ...................................... 9
   4. Use case scenario in partially DMM architecture ............. 11
      4.1. Use case 4 ............................................. 12
      4.2. Use case 5 ............................................. 13
   5. Considering Multicast Routing ............................... 13
   6. IP Address Type Considerations............................... 14
   7. Security Considerations ..................................... 14
   8. IANA Considerations ......................................... 14
   9. References .................................................. 15
      9.1. Normative References ................................... 15
      9.2. Informative References ................................. 15
   10. Acknowledgments ............................................. 16


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 [I-D.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 September 9, 2015              [Page 2]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015

   to move specific traffic flows by using network status or policy. In
   NETEXT WG, [I-D.ietf-netext-pmipv6-flowmob] explains about PMIPv6
   based flow mobility and proposes some scenarios for supporting that.

   In this document, we consider PMIPv6 based flow mobility with DMM
   architecture. [I-D.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 [I-D.bernardos-dmm-
   distributed-anchoring] and [I-D.seite-dmm-dma]. For supporting
   flow mobility in DMM, we consider two approaches; fully and
   partially distributed approaches. 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 [I-D.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 September 9, 2015              [Page 3]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015


   Centralized Database (CDB): It is a centralized entity proposed in
   the partially distributed mobility approach. CDB can store location
   information of mobile nodes in the DMM domain. When a mobile node 
   attaches to the D-MAG, D-MAG firstly request to the CDB whether
   information of mobile node is existing. If there is information of
   previous location of mobile node, D-MAG perform the mobility routing
   between a mobile node and previous D-MAG.
       
3. Use case scenario in fully DMM architecture
     
   In the fully distributed approach, as shown in figure 1, each
   distributed mobility anchor has functions of MAG and LMA.
   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. Tunnel). 
   
                | D-MAG1 |                          | D-MAG2 | 
           +-------------------+                +-------------------+
           |Location management|                |Location management|
           |     of MN-if1     |                |     of MN-if2     |
           +-------------------+                +-------------------+
           |Binding/Flow Cache | Binding update |Binding/Flow Cache |
           +-------------------+<-------------->+-------------------+
           |  Policy and Flow  |   Signaling    |  Policy and Flow  |
           |  Decision Maker   |                |  Decision Maker   |
           +-------------------+                +-------------------+
           |  Mobility routing |<==============>|  Mobility routing |
           |    for MN-if1     | Traffic Tunnel |    for MN-if2     |
           +-------------------+                +-------------------+
                      |                               |
                      |          mobile node          |
                      |     +-------------------+     |
                      |     |        IP         |     |
                      |     +---------+---------+     | 
                      +-----|   if1   |   if2   |-----+
                            +---------+---------+

                   Figure 1 <Flow mobility scenario in the
                       fully distributed architecture>
	
	
Sun, et al.             Expires September 9, 2015              [Page 4]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015

   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 [I-D.ietf-netext-pmipv6-flowmob] to contain all
   registered flow information. This specification uses the format of
   flow binding list defined in [RFC6089]. Similarly to [I-D.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.

     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:

   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


Sun, et al.             Expires September 9, 2015              [Page 5]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015

      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.

           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 <Use case 1 operation>

     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 September 9, 2015              [Page 6]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015

           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 <Use case 2 operation>

   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.


Sun, et al.             Expires September 9, 2015              [Page 7]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015

   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 [I-D.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 [I-D.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:

   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.).

	  
Sun, et al.             Expires September 9, 2015              [Page 8]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015

           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 <Use case 2 operation>

     3.4. Use case analysis
     
   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. 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. 

   
Sun, et al.             Expires September 9, 2015              [Page 9]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015
   
   One possible solution is that a new signaling message between D-MAGs
   and they share the address or policy. Another 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.


Sun, et al.             Expires September 9, 2015             [Page 10]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015

4. Use case scenario in partially DMM architecture

   In the partially distributed DMM architecture, as shown figure 5, 
   a Centralized Database(CDB) gathers information of all users in the
   domain (e.g., IP address, traffic flows, etc.), so each D-MAG can
   access to the database and get information when a mobile node attach
   to. In [I-D.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.
         
                            |Centralized Database| 
                        +---------------------------+
                        | Location Management of MN |
                        +---------------------------+
                   +--->| Interface Management of MN|   
                   |    +---------------------------+
                   |    | Binding/Flow Cache Entry  |<---+
                   |    +---------------------------+    |
    Location/Interface  | Policy/Flow Decision Maker|    |
          Update   |    +---------------------------+    |
                   |                              Binding Update/
                   |                               Flow Signaling
                   V                                     V
               | D-MAG1 |                           | D-MAG2 | 
           +-------------------+                +-------------------+
           |Binding/Flow Cache |                |Binding/Flow Cache |
           +-------------------+                +-------------------+
           |  Mobility routing |<==============>|  Mobility routing |
           |    for MN-if1     | Traffic Tunnel |    for MN-if2     |
           +-------------------+                +-------------------+
                      |          mobile node          |
                      |     +-------------------+     |
                      |     |        IP         |     |
                      |     +---------+---------+     | 
                      +-----|   if1   |   if2   |-----+
                            +---------+---------+

                   Figure 5 <Flow mobility scenario in the
                         partially distributed architecture>

   For the implementation of distributed and dynamic mobility
   management solution, it could be considered to separate control and
   data plane. In that case, besides centralized management functions,
   the CDB 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.

Sun, et al.             Expires September 9, 2015             [Page 11]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015

     4.1. Use case 4

   Possible use case in the partially distributed mobility approach is
   shown in figure 6. When mobile node attaches to the network, D-MAG
   should updates information of identifier (e.g. MAG, IP address) as
   well as interface (e.g. Access technology type). Basic operation
   will be as follows:
   
           MN       D-MAG2      D-MAG1       CMD       Corresponding
           |           |           |          |            Nodes
           |  Connect to network   |          |              |
          if1--------------------->| Update Info (MN-ID, MN-if1)
           |           |           |--------->|              |
           |   flow X (pref1::mn)  |     flow X (pref1::mn)  |
          if1<-------------------->|<---------------------->CN1
           |           |           |          |              |
           |  Connect to network   |          |              |
          if2--------------------->| Update Info (MN-ID, MN-if2)
           |           |           |--------->|              |
           |   flow Y (pref2::mn)  |     flow Y (pref2::mn)  |
          if2<-------------------->|<---------------------->CN2
           |           |           |          |              |
           |           |           |     Make Decision       |
           |           |           |   for flow mobility     |
           |           |           |          |              |
           |           |           |<---------|              |
           |           |         Binding Update (MN_flow x to D-MAG2)
           |           |<---------------------|              |
           |           |    Binding Update (MN_flow x to D-MAG2)
           |           |           |          |              |
           |           |<=========>|          |              |
           |          Traffic Tunnel          |              |
           |           |           |          |              |
           |           |--Binding Ack-------->|              |
           |           |    Binding Ack------>|              |
           |           |           |          |              |
          if1<-------------------->|          |              |
           |           |<=========>|  flow X (pref1::mn)     |
           |           |<---------------------------------->CN1
           |           |         flow Y (pref2::mn)          |
          if2<-------->|<---------------------------------->CN2
           |           |           |          |              |

                      Figure 6 <Use case operation>
	
	
Sun, et al.             Expires September 9, 2015             [Page 12]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015
				  
   o  When the mobile node attaches to the different D-MAGs through
      multiple interfaces, simultaneously or sequentially, each
      interface may be assigned different prefixes by each connected
      D-MAG. After making a connection between mobile node and D-MAG,
      Each D-MAG should send update message to the CDB. Since the CDB
      may have a database for mobile nodes in the domain as well as
      interface of each mobile node, it can inform to the D-MAG whether
      connected mobile node were making connection before.

   o  For flow mobility decision based on policy, the CDB may determine
      to move specific flow by using location and flow information in
      the database. If the CDB decide to move flow X to if2, it may
      send Binding Update messages to both D-MAG1 and D-MAG2. When both
      D-MAGs receive Binding Update message, they may modify their
      binding cache/flow cache entry and make traffic tunnel between
      each other. After receiving Binding Ack message from D-MAGs, the
      CDB may update its database.

     4.2. Use case 5 

   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) via specific
   interface (e.g. OpenFlow). 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.	  

5. Considering Multicast Routing

   In [RFC 7333], 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.

Sun, et al.             Expires September 9, 2015             [Page 13]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015

6. IP address type consideration

   In [dmm-on-demand-mobility], they described IP address types that
   depend on IP session continuity and IP address reachability,
   including Fixed, Sustained, and Nomadic IP addresses. For each
   address type, an application can request the appropriate IP address
   type that supports a mobility management mechanism. In the existing
   flow method mobility scheme, the IP address assigned to the mobile
   node is assumed Fixed/Sustained IP address which guarantee IP
   session continuity. In other words, the IP address is assigned by
   the network regardless of characteristics of application. However,
   in consideration of the type of IP address, a particular type of
   IP address is requested by specific application and this address may
   not provide session continuity. For example, such application that
   has the Nomadic IP address may be used through one of interface of
   the mobile node and, at the same time, such application that has the
   Fixed IP address may be used through other interface of the mobile
   node. In this case, access networks that are connected to each
   interface of mobile node should determine the possibility of
   supporting flow mobility in consideration of the IP address type of
   the specific flow. If the IP address type requested by the
   application is the Nomadic IP address which does not support IP
   session continuity, the distributed anchor in the access network
   does not need to consider mobility support for that flow at all.
   On the other hand, if the IP address type requested by the
   application needs to be provide IP session continuity, such as
   fixed/sustained address, the anchor should determine for the flow
   mobility support through the mobility anchor. To determine flow
   mobility support based on the IP address type, the mechanism which
   makes decision for flow mobility according to flow information and
   address type is required.   

7. Security Considerations

   TBD

8. IANA Considerations

   This document makes no request of IANA.   
   
   
Sun, et al.             Expires September 9, 2015             [Page 14]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015

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.

   [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.

   [I-D.ietf-netext-pmipv6-flowmob] Bernardos, CJ., "Proxy Mobile IPv6
             Extensions to Support Flow Mobility", draft-ietf-netext-
             pmipv6-flowmob-11 (work in progress), July 2014.
			 
   [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-10 (work in progress), September 2014.

   [dmm-on-demand-mobility] Yegin, A., Kweon, K., Lee, J. and J. Park,
             "On Demand Mobility Management", draft-yegin-dmm-ondemand-
	     mobility-03 (work in progress), March 2015.

     9.2. Informative References

   [RFC 7333]
             Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
             "Requirements for Distributed Mobility Management",
             RFC 7333, August 2014.

   [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-08 (work in progress), September
             2014.

   [I-D.seite-dmm-dma]
             Seite, P., Bertin, P., and J. Lee, "Distributed Mobility
             Anchoring", draft-seite-dmm-dma-07 (Expired),
             August 2014.

   [I-D.bernardos-dmm-distributed-anchoring]
             Bernardos, CJ., and JC. Zuniga, "PMIPv6-based distributed
             anchoring", draft-bernardos-dmm-distributed-anchoring-04
             (work in progress), May 2014.


Sun, et al.             Expires September 9, 2015             [Page 15]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015

   [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 September 9, 2015             [Page 16]

Internet-Draft        use-case-analysis-flowmob-dmm          March 2015

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 September 9, 2015             [Page 17]