Internet DRAFT - draft-yang-dmm-sdn-dmm
draft-yang-dmm-sdn-dmm
DMM Working Group Hyunsik Yang
Internet Draft Kyoungjae Sun
Intended status: Infomational Younghan Kim
Expires: July 2016 Soongsil University
January 7, 2016
Routing Optimization with SDN
draft-yang-dmm-sdn-dmm-05.txt
Abstract
DMM is a mobility protocol which has mobility functions to solve the
existing problems in the current centralized ones. However, when a
mobile node moves to another anchor, the previous flow is forwarded
by the previous router. For this reason, the routing optimization
could be an issue. This draft proposes a routing optimization method
in distributed anchor architecture. In this draft, we applied the
SDN concept to DMM architecture for routing optimization.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 7, 2016.
Yang, et al. Expires July 7, 2016 [Page 1]
Internet-Draft draft-yang-dmm-sdn-dmm January 2016
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. Motivation of DMM Optimization .............................. 3
4. DMM architecture with SDN concept for routing Optimization .. 4
4.1. Handover process and potential optimization routing .... 5
4.2. Advantage of DMM architecture with SDN ................. 6
4.3. Optimization routing ................................... 6
4.4. The Function of DMM Service ............................ 8
4.5. Mobility support for Multi domain ...................... 9
5. Security Considerations .................................... 11
6. IANA Considerations ........................................ 11
7. References ................................................. 11
7.1. Normative References .................................. 11
7.2. Informative References ................................ 11
1. Introduction
DMM is a technology for distributed network-based mobility
management protocol, which has been proposed to solve the problems
in the centralized mobility protocols such as PMIPv6 [RFC5213],
MIPv6 [RFC6275]. In the current research of distributed mobility
management, there are two methods for mobility management.
One is the fully distributed mobility management method. The other
is the partially distributed mobility method.
In partially distributed method, it decouples the control plane and
data plane. It uses a centralized method for control plane and uses
a distributed method for data plane. In fully distributed method, it
uses a distributed method for both control plane and data plane.
Yang, et al. Expires July 7, 2016 [Page 2]
Internet-Draft draft-yang-dmm-sdn-dmm January 2016
In Partially Distributed, there is one entity which that stores the
BCEs allocated for the MNs in the mobility domain. In the current
network, when mobile node moves to a new anchor, tunneling must be
used between the P-MAAR and a new anchor and the previous flow is
forwarded from the P-MAAR to the new anchor until the flow is
finished. Therefore, routing may not be optimized in term of
bandwidth overhead.
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].
Software Defined Networking (SDN)
The following terms are defined and used in this document:
DMM service (distributed mobility management service)
Function that store the BCEs and support mobility management, it's
running on controller.
The following terms used in this document are defined in A PMIPv6-
based solution for Distributed Mobility Management [draft-bernardos-
dmm-pmip-03]
Mobility Anchor and Access Router (MAAR)
Central Mobility Database (CMD)
Previous MAAR (P-MAAR)
Serving MAAR (S-MAAR)
CN MAAR (CN-MAAR)
3. Motivation of DMM Optimization
In current distributed mobility management, mobile node is allocated
IP from initiate anchor. if mobile node moves to another router,
mobile node received data through the tunneling between P-MAAR and
S-MAAR. that is, tunneling is necessary to receive data from
previous router and this method has still optimization routing
Yang, et al. Expires July 7, 2016 [Page 3]
Internet-Draft draft-yang-dmm-sdn-dmm January 2016
problem. In this draft, we propose a routing optimization scheme
that applied SDN concept to DMM architecture.
4. DMM architecture with SDN concept for routing Optimization
The purpose of this draft is to make optimized routing path from the
DMM architecture. If data path is controlled by SDN controller in
the DMM architecture with a DMM service that stored mobile node
status, mobile node data path is possible to set up by optimized
path. Moreover, tunneling is not necessary when receiving data from
previous router. The architecture of proposed method is shown in the
figure 1.
+------+
| CN |////////////Optimization routing/////////////
+------+ /
* + /
* + /
* + +--------------+ /
* + ##########| DMM Service |######### /
* + # +--------------+ # /
* + # +--------------+ # /
* + # |SDN Controller| # /
* + # +--------------+ # /
* + flow table flow table /
* + # # /
* + # # /
+--*-+-####### #----/-+
|P-MAAR|+++++++++++++++++data flow+++++++++++++|S-MAAR|
+------+ +------+
+----+
| MN |-----------------move----------------------->
+----+
Figure 1. DMM architecture with SDN
In current distributed mobility management, Upon the MN's attachment
to initiate router, the binding update message is sent to CMD that
stored mobile node status and session DB replies to initiate router
with PBA including prefix. When the mobile node moves from its
current router to new router, new router sends a binding update
message to CMD. CMD sends to update information related to mobile
node. The previous router that received update information from CMD
establishes a tunnel with the new router to transmit data.
Yang, et al. Expires July 7, 2016 [Page 4]
Internet-Draft draft-yang-dmm-sdn-dmm January 2016
4.1. Handover process and potential optimization routing
In proposed architecture, mobile node is supported mobility
management by binding update to controller with DMM service.
Moreover, data path can be set up without data tunneling in our
method. because data path is set up by flow table which made by SDN
controller. That is, mobile node can be supported optimized path by
flow table, without tunneling. There are several benefits and
potential ways to support routing optimization.
MN P-MAAR Controller S-MAAR CN-MAAR CN
(with DMM service)
| | | | | |
| |---Packet in --->| | | |
| | Message | | | |
| | BCE Creation | | |
| | | | | |
| |<---Flow Modify--| | | |
| |<-Packet out-----| | | |
| | Message | | | |
| | | | | |
|<------->|<--------Flow 1 Data-------------------->|<--->|
| | | | | |
MN move | | | | |
to S-MAAR | |<-Packet in-----| | |
| | | Message with | | |
| | |(MN'sID,prefix1)| | |
| | | location) | | |
| | | | | |
| | BCE check / update | | |
| | | | | |
| |<--Flow Modify --|--Flow Modify-->| | |
| | | | | |
| Route update | Route update | |
| | | | | |
| | |--Packet Out--->| | |
|---------|---------Flow 1 Data------------->| | |
| |<--------Flow 1 Data--------------| | |
| |-----------------|----Flow 1 Data-|----->|---->|
| | | | | |
| | | | | |
| | | | | |
Figure 2. Procedure of DMM with SDN
Yang, et al. Expires July 7, 2016 [Page 5]
Internet-Draft draft-yang-dmm-sdn-dmm January 2016
As a Figure2, When mobile node attach initiate router , MAAR1 sends
a Packet in Message with MN's ID, for registration to the controller.
Upon accepting this Packet in Message, the controller sends a Packet
out Message including the mobile node's prefix1 and controller
stored mobile node information in Binding cache entry.
For set up the data path, the controller sends a Flow Modify message
to set up the flow table in the P-MAAR.
If the mobile node moves to the S-MAAR, the S-MAAR sends a Packet in
Message with mobile node's ID, prefix1, new location of mobile
node(S-MAAR). The controller which receives packet in message will
check and update BCE.
Upon receiving this Packet in Message, the Controller sends Flow
Modify message to P-MAAR, S-MAAR to set up the new data path. On
receiving flow modify messages, the S-MAAR and P-MAAR will update
their routing tables. Then the data session will flow from P-MAAR to
new S-MAAR and finally to the mobile node.
4.2. Advantage of DMM architecture with SDN
SDN which has a flexible way to set up data flow can provide a
solution to support efficient route in the DMM architecture. If the
mobile node moves to another router, this method can solve the
routing optimization problem by modifying flow tables. Besides, the
SDN doesn't only allow us to control the data path but also the
other kinds of messages between routers.
4.3. Optimization routing
As a Figure2, When mobile node attach new router, the data session
Will flow from P-MAAR to new S-MAAR. Even mobile node Move to
another router, data path will be formed through the P-MAAR.
It will be occur delay and make the non-optimization path. However,
In the SDN based DMM, the controller can modify flow table to make
the optimization data path.
Yang, et al. Expires July 7, 2016 [Page 6]
Internet-Draft draft-yang-dmm-sdn-dmm January 2016
MN P-MAAR Controller S-MAAR CN-MAAR CN
(with DMM service)
| | | | | |
|-------|---------Flow 1 Data------------->| | |
| |<------- Flow 1 Data -------------| | |
| |-------- Flow 1 Data ----------------------->|-------->|
| | | | | |
| | |------ Flow Modify ------->| |
| | | | | |
| | | | | |
| | | | Route update |
| | | | | |
|<---------------- Flow 1 Data ----------->|<-------->|<------->|
| | | | | |
| | | | | |
| | | | | |
Figure 3.Procedure of path optimization
As a Figure3, After packet redirecting, controller send the flow
Modify message to CN-MAAR for routing optimization. Flow modify
Message has information that stored flow table between CN-MAAR and
S-MAAR. After Receiving Flow modify message, CN-MAAR send packet
to S-MAAR directly.
Yang, et al. Expires July 7, 2016 [Page 7]
Internet-Draft draft-yang-dmm-sdn-dmm January 2016
4.4. The Function of DMM Service
As a Figure3, When mobile node attach new router, Previous CMD
can't support optimization path since it has only Binding
cache information and session information. However, DMM Service
function can support optimization path since it can know all
current network status and calculate optimization path with Binding
cache information.
+-------------------------------------+
| DMM Service |
| +-------------------------+ |
| | Mobility Control-Plane | |
| | | |
| |+--------[API]----------+| |
| || FPC Client Function || |
| |+----------^------------+| |
| +-----------|-------------+ |
| | DMM FPC protocol |
| +-----------|-------------+ |
| |+----------v------------+| |
| || FPC Agent Function || |
| |+-----------------------+| |
| | | |
| | DPN Configuration API | |
| | (SDN Northbound API) | |
| +-----------^-------------+ |
+-----------------+-------------------+
|
+---------------v-----------------+
| SDN Controller |
+---^^------------^^----------^^--+
SDN protocol || || ||
(i.e. OpenFlow)+---vv---+ +---vv---+ +---vv---+
| MAAR-D | | MAAR-D | | MAAR-D |
+--------+ +--------+ +--------+
Figure 4. Functional Architecture for Supporting
FPC Protocol in SDN-based DMM
To deploy DMM service on the SDN controller, policy-based network
control model which is defined in [DMM FPC Protocol] can be used.
FPC protocol is a semantic protocol for forwarding policy
configuration between control and data plane of mobility management
functions. In the SDN-based DMM environment, as a Figure 4,
DMM service entity includes mobility control plane.
FPC protocol may be used between SDN controller and DMM control
plane. Mobility management policy which received via FPC agent
should be translated for SDN Controller as an interpretable way.
Yang, et al. Expires July 7, 2016 [Page 8]
Internet-Draft draft-yang-dmm-sdn-dmm January 2016
4.5. Mobility support for Multi domain
In this section, we describe mobility management for multi domain.
it is required to support multi domain with mobility management. In
the previous draft[I-D.ietf-dmm-distributed-anchoring],they describe
the solution to support inter-domain operation for mobility
management. However, tunneling and new entity(such as new LMA) are
necessary to support mobility management for multi domain since CMD
doesn't have any information of other domain. In this draft,
controllers can communicate via East/Westbound interfaces to make
a path between edge routers in each different domain.
+---------------+ +---------------+
| SDN Controller|---East/West interface-----| SDN Controller|
+---------------+ +---------------+
(Domain 1) | | (Domain 2)
| |
+---------------+ | | +---------------+
| Edge Router |######################| Edge Router |
+---------------+ | | +---------------+
# | | #
+----+ # | | # +----+
| MN |###### | | ###| CN |
+----+ | | +----+
| |
Figure 5. Data flow in Different Domains
As a figure5, data path is set up to send data packet from router in
the domain1 to router in the domain2. Therefore, this architecture
can support mobility management in multi domain.
+---------------+ +---------------+
| DMM Service |<---Mobility Signaling---->| DMM Service |
+-------^-------+ +--------^------+
+------------SDN Northbound API--------------+
+-------v-------+ +--------v------+
| SDN Controller|----East/West interface----| SDN Controller|
+---------------+ +---------------+
(Domain 1) | | (Domain 2)
| |
+---------------+ | | +---------------+
| Edge Router |######################| Edge Router |
+---------------+ | | +---------------+
# | | #
+----+ # | | # +----+
| MN |###### | ==========>> | ###| MN |
+----+ | move | +----+
| |
Figure 6. Mobility Supports in Different Domains
Yang, et al. Expires July 7, 2016 [Page 9]
Internet-Draft draft-yang-dmm-sdn-dmm January 2016
To support mobility, when MN moves to another domain where managed
by another SDN controller, such interfaces described in Figure 6 are
needed. DMM services which perform over each SDN controllers may
exchange mobility signaling messages such as Proxy Binding Update
(PBU) messages, similar with communication between DMM control plane
entities. After the rules which is changed by DMM service is sent to
SDN controller via Northbound API. SDN controller may find edge
router in different domain using East/West interfaces to establish
inter-domain forwarding path.
4.6. Optimization routing in multi domain
As a figure 6, data path is set up to send control packet from
controller in the domain1 to controller in the domain2.
However, after finishing the route setup, previous domain should
redirect packet to the new domain until session disconnected.
It will be occur delay and make an non-optimization path.
Therefore, after packet redirecting, path should be changed by
the controllers. At this time, DMM service controlled path setup
for optimization path.
Yang, et al. Expires July 7, 2016 [Page 10]
Internet-Draft draft-yang-dmm-sdn-dmm January 2016
5. Security Considerations
TBD
6. IANA Considerations
This document makes no request of IANA.
7. References
7.1. Normative References
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury,
K.,and B. Patil, "Proxy Mobile IPv6", RFC 5213, August
2008.
[RFC6275] Perkins, C ,Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, June 2004.
[DMM FPC Protocol]
Liebsch, M., Matsushima, S., Gundavelli, S., Moses, D.,
"Protocol for Forwarding Policy Configuration (FPC) in
DMM", draft-ietf-dmm-fpc-cpdp-00, May 2015.
[I-D.ietf-dmm-distributed-anchoring]
Bernardos, CJ., Zuniga, JC., "PMIPv6-based distributed
anchoring", draft-bernardos-dmm-distributed-anchoring-05,
March 2015.
7.2. Informative References
[draft-bernardos-dmm-pmip]
CJ. Bernardos, A. de la Oliva, F. Giust, ''A PMIPv6-based solution
for Distributed Mobility Management'', draft-bernardos-dmm-pmip-03
(work in progress), July 2013.
[SDN 2013]
Sezer, S.; Scott-Hayward, S.; Chouhan, P.K.; Fraser, B.; Lake, D.;
Finnegan, J.; Viljoen, N.; Miller, M.; Rao, N., "Are we ready for
SDN? Implementation challenges for software-defined networks,"
Communications Magazine, IEEE , vol.51, no.7, pp.36,43, July 2013.
Yang, et al. Expires July 7, 2016 [Page 11]
Internet-Draft draft-yang-dmm-sdn-dmm January 2016
Authors' Addresses
Hyunsik Yang
Soongsil University
369, Sangdo-ro, Dongjak-gu,
Seoul 156-743, Korea
Email : yangun@dcn.ssu.ac.kr
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
Yang, et al. Expires July 7, 2016 [Page 12]
