Use case Analysis for Supporting Flow Mobility in DMM
draft-sun-dmm-use-case-analysis-flowmob-dmm-00
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-07-15 | ||
| 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-00
DMM Working Group Kyoungjae Sun
Internet-Draft Younghan Kim
Intended status: Informational Soongsil University
Expires: January 2014 July 15, 2013
Use case Analysis for Supporting Flow Mobility in DMM
draft-sun-dmm-use-case-analysis-flowmob-dmm-00.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. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
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 working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Sun, et al. Expires January 15, 2014 [Page 1]
Internet-Draft use-case-analysis-flowmob-dmm July 2013
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 January 15, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................3
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 anchor ..........11
4.2. Mobile node moves physically with multiple interfaces....11
5. Security Considerations.......................................12
6. IANA Considerations...........................................12
7. References....................................................12
7.1. Normative References.....................................12
7.2. Informative References...................................13
8. Acknowledgments...............................................13
Sun, et al. Expires January 15, 2014 [Page 2]
Internet-Draft use-case-analysis-flowmob-dmm July 2013
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
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)
Sun, et al. Expires January 15, 2014 [Page 3]
Internet-Draft use-case-analysis-flowmob-dmm July 2013
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.
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 [draft-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 January 15, 2014 [Page 4]
Internet-Draft use-case-analysis-flowmob-dmm July 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 January 15, 2014 [Page 5]
Internet-Draft use-case-analysis-flowmob-dmm July 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 January 15, 2014 [Page 6]
Internet-Draft use-case-analysis-flowmob-dmm July 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 January 15, 2014 [Page 7]
Internet-Draft use-case-analysis-flowmob-dmm July 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 January 15, 2014 [Page 8]
Internet-Draft use-case-analysis-flowmob-dmm July 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],
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 January 15, 2014 [Page 9]
Internet-Draft use-case-analysis-flowmob-dmm July 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 January 15, 2014 [Page 10]
Internet-Draft use-case-analysis-flowmob-dmm July 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 anchor
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 three 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
Sun, et al. Expires January 15, 2014 [Page 11]
Internet-Draft use-case-analysis-flowmob-dmm July 2013
should consider that interfaces perform physical handoff operation.
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. Security Considerations
TBD
6. IANA Considerations
This document makes no request of IANA.
7. References
7.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.
Sun, et al. Expires January 15, 2014 [Page 12]
Internet-Draft use-case-analysis-flowmob-dmm July 2013
7.2. Informative References
[draft-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.
[draft-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.
[draft-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.
[draft-seite-dmm-dma]
Seite, P., Bertin, P., and J. Lee, "Distributed Mobility
Anchoring", draft-seite-dmm-dma-06 (work in progress), Jan
2013.
[draft-bernardos-dmm-distributed-anchoring]
Bernardos, CJ., and JC. Zuniga, "PMIPv6-based distributed
anchoring", draft-bernardos-dmm-distributed-anchoring-02
(work in progress), April 2013.
8. Acknowledgments
Sun, et al. Expires January 15, 2014 [Page 13]
Internet-Draft use-case-analysis-flowmob-dmm July 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 January 15, 2014 [Page 14]