Use case analysis for supporting flow mobility in DMM
draft-sun-dmm-use-case-analysis-flowmob-dmm-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | KJ Sun , Younghan Kim | ||
| Last updated | 2013-10-21 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sun-dmm-use-case-analysis-flowmob-dmm-01
<Network Working Group> Kyoungjae Sun
Internet Draft Younghan Kim
Intended status: Informational Soongsil University
Expires: April 2014 October 21, 2013
Use case analysis for supporting flow mobility in DMM
draft-sun-dmm-use-case-analysis-flowmob-dmm-01.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 April 21, 2014.
Sun, et al. Expires April 21, 2014 [Page 1]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
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. Security Considerations ..................................... 12
7. IANA Considerations ......................................... 12
8. References .................................................. 13
8.1. Normative References ................................... 13
8.2. Informative References ................................. 13
9. Acknowledgments ............................................. 14
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 April 21, 2014 [Page 2]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
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 April 21, 2014 [Page 3]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
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 April 21, 2014 [Page 4]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
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 <Basic structure in Flow mobility scenario>
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 April 21, 2014 [Page 5]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
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>
Sun, et al. Expires April 21, 2014 [Page 6]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
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 April 21, 2014 [Page 7]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
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>
Sun, et al. Expires April 21, 2014 [Page 8]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
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 April 21, 2014 [Page 9]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
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 <Use case 2 operation>
Sun, et al. Expires April 21, 2014 [Page 10]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
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 April 21, 2014 [Page 11]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
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.
6. Security Considerations
TBD
7. IANA Considerations
This document makes no request of IANA.
Sun, et al. Expires April 21, 2014 [Page 12]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
8. References
8.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.
8.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 April 21, 2014 [Page 13]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
[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.
9. Acknowledgments
Sun, et al. Expires April 21, 2014 [Page 14]
Internet-Draft use-case-analysis-flowmob-dmm October 2013
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 April 21, 2014 [Page 15]