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]