idnits 2.17.1 draft-yang-dmm-sdn-dmm-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 11) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 6, 2015) is 3217 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 104, but not defined == Unused Reference: 'SDN 2013' is defined on line 434, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-bernardos-dmm-distributed-anchoring-05 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DMM Working Group Hyunsik Yang 2 Internet Draft Kyoungjae Sun 3 Intended status: Infomational Younghan Kim 4 Expires: January 2016 Soongsil University 5 July 6, 2015 7 Routing Optimization with SDN 8 draft-yang-dmm-sdn-dmm-04.txt 10 Abstract 12 DMM is a mobility protocol which has mobility functions to solve the 13 existing problems in the current centralized ones. However, when a 14 mobile node moves to another anchor, the previous flow is forwarded 15 by the previous router. For this reason, the routing optimization 16 could be an issue. This draft proposes a routing optimization method 17 in distributed anchor architecture. In this draft, we applied the 18 SDN concept to DMM architecture for routing optimization. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on January 5, 2016. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction ................................................ 2 61 2. Terminology ................................................. 3 62 3. Motivation of DMM Optimization .............................. 3 63 4. DMM architecture with SDN concept for routing Optimization .. 4 64 4.1. Handover process and potential optimization routing .... 5 65 4.2. Advantage of DMM architecture with SDN ................. 6 66 4.3. Optimization routing ................................... 6 67 4.4. The Function of DMM Service ............................ 8 68 4.5. Mobility support for Multi domain ...................... 9 69 5. Security Considerations .................................... 11 70 6. IANA Considerations ........................................ 11 71 7. References ................................................. 11 72 7.1. Normative References .................................. 11 73 7.2. Informative References ................................ 11 75 1. Introduction 77 DMM is a technology for distributed network-based mobility 78 management protocol, which has been proposed to solve the problems 79 in the centralized mobility protocols such as PMIPv6 [RFC5213], 80 MIPv6 [RFC6275]. In the current research of distributed mobility 81 management, there are two methods for mobility management. 83 One is the fully distributed mobility management method. The other 84 is the partially distributed mobility method. 86 In partially distributed method, it decouples the control plane and 87 data plane. It uses a centralized method for control plane and uses 88 a distributed method for data plane. In fully distributed method, it 89 uses a distributed method for both control plane and data plane. 91 In Partially Distributed, there is one entity which that stores the 92 BCEs allocated for the MNs in the mobility domain. In the current 93 network, when mobile node moves to a new anchor, tunneling must be 94 used between the P-MAAR and a new anchor and the previous flow is 95 forwarded from the P-MAAR to the new anchor until the flow is 96 finished. Therefore, routing may not be optimized in term of 97 bandwidth overhead. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC-2119 [RFC2119]. 105 Software Defined Networking (SDN) 107 The following terms are defined and used in this document: 109 DMM service (distributed mobility management service) 111 Function that store the BCEs and support mobility management, it's 112 running on controller. 114 The following terms used in this document are defined in A PMIPv6- 115 based solution for Distributed Mobility Management [draft-bernardos- 116 dmm-pmip-03] 118 Mobility Anchor and Access Router (MAAR) 120 Central Mobility Database (CMD) 122 Previous MAAR (P-MAAR) 124 Serving MAAR (S-MAAR) 126 CN MAAR (CN-MAAR) 128 3. Motivation of DMM Optimization 130 In current distributed mobility management, mobile node is allocated 131 IP from initiate anchor. if mobile node moves to another router, 132 mobile node received data through the tunneling between P-MAAR and 133 S-MAAR. that is, tunneling is necessary to receive data from 134 previous router and this method has still optimization routing 135 problem. In this draft, we propose a routing optimization scheme 136 that applied SDN concept to DMM architecture. 138 4. DMM architecture with SDN concept for routing Optimization 140 The purpose of this draft is to make optimized routing path from the 141 DMM architecture. If data path is controlled by SDN controller in 142 the DMM architecture with a DMM service that stored mobile node 143 status, mobile node data path is possible to set up by optimized 144 path. Moreover, tunneling is not necessary when receiving data from 145 previous router. The architecture of proposed method is shown in the 146 figure 1. 148 +------+ 149 | CN |////////////Optimization routing///////////// 150 +------+ / 151 * + / 152 * + / 153 * + +--------------+ / 154 * + ##########| DMM Service |######### / 155 * + # +--------------+ # / 156 * + # +--------------+ # / 157 * + # |SDN Controller| # / 158 * + # +--------------+ # / 159 * + flow table flow table / 160 * + # # / 161 * + # # / 162 +--*-+-####### #----/-+ 163 |P-MAAR|+++++++++++++++++data flow+++++++++++++|S-MAAR| 164 +------+ +------+ 166 +----+ 167 | MN |-----------------move-----------------------> 168 +----+ 170 Figure 1. DMM architecture with SDN 172 In current distributed mobility management, Upon the MN's attachment 173 to initiate router, the binding update message is sent to CMD that 174 stored mobile node status and session DB replies to initiate router 175 with PBA including prefix. When the mobile node moves from its 176 current router to new router, new router sends a binding update 177 message to CMD. CMD sends to update information related to mobile 178 node. The previous router that received update information from CMD 179 establishes a tunnel with the new router to transmit data. 181 4.1. Handover process and potential optimization routing 183 In proposed architecture, mobile node is supported mobility 184 management by binding update to controller with DMM service. 185 Moreover, data path can be set up without data tunneling in our 186 method. because data path is set up by flow table which made by SDN 187 controller. That is, mobile node can be supported optimized path by 188 flow table, without tunneling. There are several benefits and 189 potential ways to support routing optimization. 191 MN P-MAAR Controller S-MAAR CN-MAAR CN 192 (with DMM service) 193 | | | | | | 194 | |---Packet in --->| | | | 195 | | Message | | | | 196 | | BCE Creation | | | 197 | | | | | | 198 | |<---Flow Modify--| | | | 199 | |<-Packet out-----| | | | 200 | | Message | | | | 201 | | | | | | 202 |<------->|<--------Flow 1 Data-------------------->|<--->| 203 | | | | | | 204 MN move | | | | | 205 to S-MAAR | |<-Packet in-----| | | 206 | | | Message with | | | 207 | | |(MN'sID,prefix1)| | | 208 | | | location) | | | 209 | | | | | | 210 | | BCE check / update | | | 211 | | | | | | 212 | |<--Flow Modify --|--Flow Modify-->| | | 213 | | | | | | 214 | Route update | Route update | | 215 | | | | | | 216 | | |--Packet Out--->| | | 217 |---------|---------Flow 1 Data------------->| | | 218 | |<--------Flow 1 Data--------------| | | 219 | |-----------------|----Flow 1 Data-|----->|---->| 220 | | | | | | 221 | | | | | | 222 | | | | | | 224 Figure 2. Procedure of DMM with SDN 226 As a Figure2, When mobile node attach initiate router , MAAR1 sends 227 a Packet in Message with MN's ID, for registration to the controller. 228 Upon accepting this Packet in Message, the controller sends a Packet 229 out Message including the mobile node's prefix1 and controller 230 stored mobile node information in Binding cache entry. 231 For set up the data path, the controller sends a Flow Modify message 232 to set up the flow table in the P-MAAR. 233 If the mobile node moves to the S-MAAR, the S-MAAR sends a Packet in 234 Message with mobile node's ID, prefix1, new location of mobile 235 node(S-MAAR). The controller which receives packet in message will 236 check and update BCE. 237 Upon receiving this Packet in Message, the Controller sends Flow 238 Modify message to P-MAAR, S-MAAR to set up the new data path. On 239 receiving flow modify messages, the S-MAAR and P-MAAR will update 240 their routing tables. Then the data session will flow from P-MAAR to 241 new S-MAAR and finally to the mobile node. 243 4.2. Advantage of DMM architecture with SDN 245 SDN which has a flexible way to set up data flow can provide a 246 solution to support efficient route in the DMM architecture. If the 247 mobile node moves to another router, this method can solve the 248 routing optimization problem by modifying flow tables. Besides, the 249 SDN doesn't only allow us to control the data path but also the 250 other kinds of messages between routers. 252 4.3. Optimization routing 254 As a Figure2, When mobile node attach new router, the data session 255 Will flow from P-MAAR to new S-MAAR. Even mobile node Move to 256 another router, data path will be formed through the P-MAAR. 257 It will be occur delay and make the non-optimization path. However, 258 In the SDN based DMM, the controller can modify flow table to make 259 the optimization data path. 261 MN P-MAAR Controller S-MAAR CN-MAAR CN 262 (with DMM service) 263 | | | | | | 264 |-------|---------Flow 1 Data------------->| | | 265 | |<------- Flow 1 Data -------------| | | 266 | |-------- Flow 1 Data ----------------------->|-------->| 267 | | | | | | 268 | | |------ Flow Modify ------->| | 269 | | | | | | 270 | | | | | | 271 | | | | Route update | 272 | | | | | | 273 |<---------------- Flow 1 Data ----------->|<-------->|<------->| 274 | | | | | | 275 | | | | | | 276 | | | | | | 277 Figure 3.Procedure of path optimization 279 As a Figure3, After packet redirecting, controller send the flow 280 Modify message to CN-MAAR for routing optimization. Flow modify 281 Message has information that stored flow table between CN-MAAR and 282 S-MAAR. After Receiving Flow modify message, CN-MAAR send packet 283 to S-MAAR directly. 285 4.4. The Function of DMM Service 287 As a Figure3, When mobile node attach new router, Previous CMD 288 can't support optimization path since it has only Binding 289 cache information and session information. However, DMM Service 290 function can support optimization path since it can know all 291 current network status and calculate optimization path with Binding 292 cache information. 294 +-------------------------------------+ 295 | DMM Service | 296 | +-------------------------+ | 297 | | Mobility Control-Plane | | 298 | | | | 299 | |+--------[API]----------+| | 300 | || FPC Client Function || | 301 | |+----------^------------+| | 302 | +-----------|-------------+ | 303 | | DMM FPC protocol | 304 | +-----------|-------------+ | 305 | |+----------v------------+| | 306 | || FPC Agent Function || | 307 | |+-----------------------+| | 308 | | | | 309 | | DPN Configuration API | | 310 | | (SDN Northbound API) | | 311 | +-----------^-------------+ | 312 +-----------------+-------------------+ 313 | 314 +---------------v-----------------+ 315 | SDN Controller | 316 +---^^------------^^----------^^--+ 317 SDN protocol || || || 318 (i.e. OpenFlow)+---vv---+ +---vv---+ +---vv---+ 319 | MAAR-D | | MAAR-D | | MAAR-D | 320 +--------+ +--------+ +--------+ 322 Figure 4. Functional Architecture for Supporting 323 FPC Protocol in SDN-based DMM 325 To deploy DMM service on the SDN controller, policy-based network 326 control model which is defined in [DMM FPC Protocol] can be used. 327 FPC protocol is a semantic protocol for forwarding policy 328 configuration between control and data plane of mobility management 329 functions. In the SDN-based DMM environment, as a Figure 4, 330 DMM service entity includes mobility control plane. 331 FPC protocol may be used between SDN controller and DMM control 332 plane. Mobility management policy which received via FPC agent 333 should be translated for SDN Controller as an interpretable way. 335 4.5. Mobility support for Multi domain 337 In this section, we describe mobility management for multi domain. 338 it is required to support multi domain with mobility management. In 339 the previous draft[I-D.ietf-dmm-distributed-anchoring],they describe 340 the solution to support inter-domain operation for mobility 341 management. However, tunneling and new entity(such as new LMA) are 342 necessary to support mobility management for multi domain since CMD 343 doesn't have any information of other domain. In this draft, 344 controllers can communicate via East/Westbound interfaces to make 345 a path between edge routers in each different domain. 347 +---------------+ +---------------+ 348 | SDN Controller|---East/West interface-----| SDN Controller| 349 +---------------+ +---------------+ 350 (Domain 1) | | (Domain 2) 351 | | 352 +---------------+ | | +---------------+ 353 | Edge Router |######################| Edge Router | 354 +---------------+ | | +---------------+ 355 # | | # 356 +----+ # | | # +----+ 357 | MN |###### | | ###| CN | 358 +----+ | | +----+ 359 | | 361 Figure 5. Data flow in Different Domains 363 As a figure5, data path is set up to send data packet from router in 364 the domain1 to router in the domain2. Therefore, this architecture 365 can support mobility management in multi domain. 367 +---------------+ +---------------+ 368 | DMM Service |<---Mobility Signaling---->| DMM Service | 369 +-------^-------+ +--------^------+ 370 +------------SDN Northbound API--------------+ 371 +-------v-------+ +--------v------+ 372 | SDN Controller|----East/West interface----| SDN Controller| 373 +---------------+ +---------------+ 374 (Domain 1) | | (Domain 2) 375 | | 376 +---------------+ | | +---------------+ 377 | Edge Router |######################| Edge Router | 378 +---------------+ | | +---------------+ 379 # | | # 380 +----+ # | | # +----+ 381 | MN |###### | ==========>> | ###| MN | 382 +----+ | move | +----+ 383 | | 385 Figure 6. Mobility Supports in Different Domains 387 To support mobility, when MN moves to another domain where managed 388 by another SDN controller, such interfaces described in Figure 6 are 389 needed. DMM services which perform over each SDN controllers may 390 exchange mobility signaling messages such as Proxy Binding Update 391 (PBU) messages, similar with communication between DMM control plane 392 entities. After the rules which is changed by DMM service is sent to 393 SDN controller via Northbound API. SDN controller may find edge 394 router in different domain using East/West interfaces to establish 395 inter-domain forwarding path. 397 5. Security Considerations 399 TBD 401 6. IANA Considerations 403 This document makes no request of IANA. 405 7. References 407 7.1. Normative References 409 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, 410 K.,and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 411 2008. 413 [RFC6275] Perkins, C ,Johnson, D., and J. Arkko, "Mobility Support 414 in IPv6", RFC 6275, June 2004. 416 [DMM FPC Protocol] 417 Liebsch, M., Matsushima, S., Gundavelli, S., Moses, D., 418 "Protocol for Forwarding Policy Configuration (FPC) in 419 DMM", draft-ietf-dmm-fpc-cpdp-00, May 2015. 421 [I-D.ietf-dmm-distributed-anchoring] 422 Bernardos, CJ., Zuniga, JC., "PMIPv6-based distributed 423 anchoring", draft-bernardos-dmm-distributed-anchoring-05, 424 March 2015. 426 7.2. Informative References 428 [draft-bernardos-dmm-pmip] 430 CJ. Bernardos, A. de la Oliva, F. Giust, ''A PMIPv6-based solution 431 for Distributed Mobility Management'', draft-bernardos-dmm-pmip-03 432 (work in progress), July 2013. 434 [SDN 2013] 436 Sezer, S.; Scott-Hayward, S.; Chouhan, P.K.; Fraser, B.; Lake, D.; 437 Finnegan, J.; Viljoen, N.; Miller, M.; Rao, N., "Are we ready for 438 SDN? Implementation challenges for software-defined networks," 439 Communications Magazine, IEEE , vol.51, no.7, pp.36,43, July 2013. 441 Authors' Addresses 443 Hyunsik Yang 444 Soongsil University 445 369, Sangdo-ro, Dongjak-gu, 446 Seoul 156-743, Korea 448 Email : yangun@dcn.ssu.ac.kr 450 Kyoungjae Sun 451 Soongsil University 452 369, Sangdo-ro, Dongjak-gu, 453 Seoul 156-743, Korea 455 Email : gomjae@dcn.ssu.ac.kr 457 Younghan Kim 458 Soongsil University 459 369, Sangdo-ro, Dongjak-gu, 460 Seoul 156-743, Korea 462 Email: younghak@ssu.ac.kr