Internet DRAFT - draft-sun-dmm-use-case-analysis-flowmob-dmm
draft-sun-dmm-use-case-analysis-flowmob-dmm
<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]