idnits 2.17.1 draft-sun-dmm-use-case-analysis-flowmob-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance 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 date (March 9, 2015) is 3336 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-dmm-best-practices-gap-analysis' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'I-D.bernardos-dmm-distributed-anchoring' is defined on line 677, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-netext-pmipv6-flowmob-11 == Outdated reference: A later version (-14) exists of draft-ietf-netext-logical-interface-support-10 == Outdated reference: A later version (-09) exists of draft-ietf-dmm-best-practices-gap-analysis-08 == Outdated reference: A later version (-09) exists of draft-bernardos-dmm-distributed-anchoring-04 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Kyoungjae Sun 2 Internet Draft Younghan Kim 3 Intended status: Informational Soongsil University 4 Expires: September 2015 March 9, 2015 6 Use case analysis for supporting flow mobility in DMM 7 draft-sun-dmm-use-case-analysis-flowmob-dmm-04.txt 9 Abstract 11 Distributed Mobility Management (DMM) allows network traffic to 12 distribute among multiple mobility anchors which have mobility 13 functions to solve the existing problems in current centralized 14 mobility protocols. There are many DMM approaches extending 15 network-based mobility protocols (e.g. Proxy Mobile IPv6). 17 In Proxy Mobile IPv6 (PMIPv6), they allow a mobile node to 18 connect to PMIPv6 domain through different physical interfaces. In 19 this reason, flow mobility that enables movement between physical 20 interfaces of mobile node is proposed. 22 In this document, we present some use cases to support flow mobility 23 in DMM domain and analyze some problems. These use cases are based 24 on scenarios of flow mobility in PMIPv6. In these scenarios, a 25 multi-interface mobile node connects to different distributed 26 mobility access points and move specific flows from one interface to 27 another. These use cases have common issues which will be analyzed 28 in detail. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. It is inappropriate to use Internet-Drafts as 43 reference material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 9, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction ................................................ 2 65 2. Terminology ................................................. 3 66 3. Use case scenario in fully DMM architecture ................. 4 67 3.1. Use case 1 ............................................. 5 68 3.2. Use case 2 ............................................. 6 69 3.3. Use case 3 ............................................. 8 70 3.4. Use case analysis ...................................... 9 71 4. Use case scenario in partially DMM architecture ............. 11 72 4.1. Use case 4 ............................................. 12 73 4.2. Use case 5 ............................................. 13 74 5. Considering Multicast Routing ............................... 13 75 6. IP Address Type Considerations............................... 14 76 7. Security Considerations ..................................... 14 77 8. IANA Considerations ......................................... 14 78 9. References .................................................. 15 79 9.1. Normative References ................................... 15 80 9.2. Informative References ................................. 15 81 10. Acknowledgments ............................................. 16 83 1. Introduction 85 Distributed Mobility Management aims at overcoming limitations of 86 centralized mobility protocol, such as a single point failure, 87 scalability and non-optimal routing. In [I-D.ietf-dmm-best- 88 practices-gap-analysis], they distribute existing mobility functions 89 to access network, and show practices to use existing protocols 90 (e.g. MIP, PMIP). 92 When mobile node can use multiple interfaces and connect to network 93 simultaneously or sequentially, flow mobility allows a mobile node 94 to move specific traffic flows by using network status or policy. In 95 NETEXT WG, [I-D.ietf-netext-pmipv6-flowmob] explains about PMIPv6 96 based flow mobility and proposes some scenarios for supporting that. 98 In this document, we consider PMIPv6 based flow mobility with DMM 99 architecture. [I-D.seite-dmm-dma] mentions about multi-interface 100 support for network based DMM but not in detail. This document 101 refers DMM architecture and message flows from [I-D.bernardos-dmm- 102 distributed-anchoring] and [I-D.seite-dmm-dma]. For supporting 103 flow mobility in DMM, we consider two approaches; fully and 104 partially distributed approaches. From analyzing these use cases, it 105 would incline that multi-interface mobile node can connect to 106 different distributed anchors and move traffic flows between 107 physical interfaces. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC-2119 [RFC2119]. 115 The following terms used in this document are defined in the Proxy 116 Mobile IPv6 [RFC5213]: 118 Proxy Binding Update (PBU) 120 Proxy Binding Acknowledgement (PBA) 122 The following terms are defined in the Proxy Mobile IPv6 Extensions 123 to Support Flow Mobility [I-D.ietf-netext-pmipv6-flowmob]: 125 FMI (Flow Mobility Initiate) 127 FMA (Flow Mobility Acknowledgement) 129 FMC (Flow Mobility Cache) 131 The following terms are defined and used in this document: 133 Distributed-Mobile Access Gateway (D-MAG): It provides an IP prefix 134 to each attached mobile node. D-MAG is the topological anchor point 135 of mobile node's prefix. It performs regular IPv6 routing for 136 connecting mobile node directly and when mobile node moves and 137 attaches to another D-MAG, similar to LMA in [RFC5213], it tracks 138 the mobile node location and performs mobility routing to forward 139 packets via D-MAG where mobile node is attached. 141 Centralized Database (CDB): It is a centralized entity proposed in 142 the partially distributed mobility approach. CDB can store location 143 information of mobile nodes in the DMM domain. When a mobile node 144 attaches to the D-MAG, D-MAG firstly request to the CDB whether 145 information of mobile node is existing. If there is information of 146 previous location of mobile node, D-MAG perform the mobility routing 147 between a mobile node and previous D-MAG. 149 3. Use case scenario in fully DMM architecture 151 In the fully distributed approach, as shown in figure 1, each 152 distributed mobility anchor has functions of MAG and LMA. 153 Distributed mobility anchors called Distributed Mobile Access 154 Gateway (D-MAG) support same or different access technologies so 155 that different physical interfaces of mobile node can access to 156 D-MAG simultaneously or sequentially. When a mobile node attaches to 157 network, the D-MAG may assign prefix and support regular IPv6 158 routing. When the mobile node moves to another D-MAG, previous D-MAG 159 may perform as a mobility anchor like LMA which exchanges signaling 160 messages (e.g. PBU/PBA) and supports mobility routing(e.g. Tunnel). 162 | D-MAG1 | | D-MAG2 | 163 +-------------------+ +-------------------+ 164 |Location management| |Location management| 165 | of MN-if1 | | of MN-if2 | 166 +-------------------+ +-------------------+ 167 |Binding/Flow Cache | Binding update |Binding/Flow Cache | 168 +-------------------+<-------------->+-------------------+ 169 | Policy and Flow | Signaling | Policy and Flow | 170 | Decision Maker | | Decision Maker | 171 +-------------------+ +-------------------+ 172 | Mobility routing |<==============>| Mobility routing | 173 | for MN-if1 | Traffic Tunnel | for MN-if2 | 174 +-------------------+ +-------------------+ 175 | | 176 | mobile node | 177 | +-------------------+ | 178 | | IP | | 179 | +---------+---------+ | 180 +-----| if1 | if2 |-----+ 181 +---------+---------+ 183 Figure 1 186 In [I-D.ietf-netext-logical-interface-support], logical interface is 187 defined that allows the mobile node to move different traffic flows 188 to different physical interfaces regardless of the assigned prefixes 189 on those interfaces. By using the logical interface, mobile node can 190 accept incoming packets which is addressed to another interface of 191 mobile node. Flow mobility cache which is separated from the binding 192 cache is defined [I-D.ietf-netext-pmipv6-flowmob] to contain all 193 registered flow information. This specification uses the format of 194 flow binding list defined in [RFC6089]. Similarly to [I-D.ietf- 195 netext-pmipv6-flowmob], we assume that mobile node have logical 196 interface and D-MAG includes flow cache entry. There are three use 197 cases to support flow mobility in DMM. 199 3.1. Use case 1 201 The first possible use case, as shown in Figure 2, assumes that 202 multiple interfaces attach to DMM network sequentially and movement 203 of flow starts from the activation of secondary interface of mobile 204 node. In this case, basic operation may follow normal PMIPv6 205 protocol as follows: 207 o When a mobile node initially attaches to the D-MAG1 using the 208 physical interface if1, the D-MAG1 should assign prefix pref1 and 209 support regular IPv6 routing. In this time, no mobility function 210 is used. Mobile node may communicate with one or more 211 corresponding nodes after receiving pref1 from D-MAG1. However, 212 D-MAG1 SHOULD know the information of all flows used by if1 of 213 mobile node. D-MAG1 already has binding cache entry and flow 214 cache entry so it can update its own entries. TS option in the 215 IPv6 header of packet can be used to update flow cache entry. 217 o During the time, mobile node connects to D-MAG1 through the if1, 218 it could enable another interface if2 to attach to D-MAG2. Upon 219 D-MAG2 receives information (discussed about this operation 220 later.), the D-MAG2 may send a PBU message to the D-MAG1 to 221 request mobility routing. In the PBU message, it SHOULD include 222 the mobile node identifier and the address of D-MAG1. It may also 223 include the request for supporting flow mobility because the 224 D-MAG1 does not observe that the mobile node connects to the 225 D-MAG2 by using the another interface. 227 o When the D-MAG1 receives the PBU message, the D-MAG1 SHOULD make 228 a tunnel first with the D-MAG2 and determine what flows will move 229 to the D-MAG2. Decision method or policy for flow mobility is out 230 of scope of this document. After decision, the D-MAG1 updates its 231 binding cache entry and flow cache entry for moving flow. 232 Finally, the D-MAG1 sends a PBA message to the D-MAG2 and 233 forwards moving flows to the D-MAG2via tunnel. In the PBA 234 message, additional contents, such as Flow Identification option 235 [RFC6089] or the service type of flow, are needed to provide the 236 flow information. After receiving the PBA message, the D-MAG2 237 updates its routing table and delivers packets received from the 238 D-MAG1 to if2. Independently, the D-MAG2 also SHOULD assign a new 239 prefix to if2 for normal IPv6 routing because all D-MAGs have 240 location management and address allocation function in DMM. 242 MN D-MAG2 D-MAG1 Corresponding Nodes 243 | | | | 244 | flow x | flow x | 245 | pref1::mn | pref1::mn | 246 pref1> if1<-------------------------->|<---------------->CN1 247 | | | | 248 | flow y | flow y | 249 | pref1::mn | pref1::mn | 250 if1<-------------------------->|<---------------->CN2 251 | | | | 252 | attach | | | 253 If2----------->| | | 254 | | PBU | | 255 | |(D-MAG1, MN-ID)| | 256 | |-------------->| | 257 | make decision for | | 258 | moving flow | | 259 | |====tunnel=====| | 260 | | | | 261 | | PBA | | 262 | |(pref1, flow x)| | 263 | |<--------------| | 264 | | | | 265 | flow x | flow x | flow x | 266 | pref1::mn | pref1::mn | pref1::mn | 267 if2<---------->|<=============>|<---------------->CN1 268 | | | | 269 | flow y | flow y | 270 | pref1::mn | pref1::mn | 271 if1<-------------------------->|<---------------->CN2 272 | | | | 273 | flow z | flow z | 274 | pref2::mn | pref2::mn | 275 pref2> if2<---------->|<-------------------------------->CN3 276 | | | 278 Figure 2 280 3.2. Use case 2 282 The second possible case, as shown in Figure 3, assumes that 283 multiple interfaces attach to network simultaneously. Each interface 284 has been assigned prefixes from the different D-MAGs. When several 285 flows are already existed through both interfaces, basic operation 286 will be as follows: 288 MN D-MAG2 D-MAG1 Corresponding Nodes 289 | | | | 290 | flow x | flow x | 291 | pref1::mn | pref1::mn | 292 pref1> if1<-------------------------->|<---------------->CN1 293 | | | | 294 | flow y | flow y | 295 | pref2::mn | pref2::mn | 296 pref2> if2<---------->|--------------------------------->CN2 297 | | | | 298 | Use special method to share | 299 | | between D-MAGs| | 300 | | | | 301 | | PBU | | 302 | |(D-MAG1, MN-ID)| | 303 | |-------------->| | 304 | | | | 305 | |=====tunnel====| | 306 | | | | 307 | | PBA | | 308 | | (MN-ID, pref1)| | 309 | |<--------------| | 310 | | | | 311 | | Decide to move | 312 | | | flow x | 313 | | FMI | | 314 | |(MN-ID,flow(x)_info) | 315 | |<--------------| | 316 | | FMA | | 317 | |-------------->| | 318 | flow x | flow x | flow x | 319 | pref1::mn | pref1::mn | pref1::mn | 320 if2<---------->|<=============>|<---------------->CN1 321 | flow y | flow y | flow y | 322 | pref2::mn | pref2::mn | pref2::mn | 323 if2<---------->|<-------------------------------->CN2 324 | | | | 326 Figure 3 328 o When the mobile node attaches to the different D-MAGs through 329 multiple interfaces, each interface has been assigned different 330 prefixes and managed separately. In this figure, if1 and if2 are 331 connecting to the D-MAG1, D-MAG2 and using the pref1, the pref2, 332 respectively. To support flow mobility, a special method in which 333 both D-MAGs share information of mobile nodes attached to 334 network, activated flows, and network policy. 336 o In the certain time, when the network decides to move a specific 337 flow, flow x in this figure, first both D-MAGs exchange PBU/PBA 338 messages to bind prefix of mobile node's interface. However, in 339 this case, the PBU/PBA messages are only for binding prefix. So 340 D-MAG1 just updates binding cache entry but no traffic path is 341 changed. To do this, the modification of PBU/PBA or functions of 342 D-MAG may be needed. After exchanging signaling messages, tunnel 343 is setup between the D-MAG1 and the D-MAG2, but no traffic flow 344 moves through this interface yet. 346 o Considering move a specific flow from the D-MAG1 to the D-MAG2, 347 the D-MAG1 SHOULD send a request message for the D-MAG2 because 348 the flow information is only stored in the D-MAG1. Since the 349 D-MAG1 cannot send a PBA message which has not been triggered in 350 response to a received PBU message, new signaling messages are 351 defined to cover this case. In [I-D.ietf-netext-pmipv6-flowmob- 352 06], they defined a new signaling message, FMI/FMA message, which 353 contains the MN-Identifier, the Flow Identification Mobility 354 option information, and the type of flow mobility operation (add 355 flow). Adjusting the scenario of this document in the DMM, the 356 D-MAG2 may receive the FMI message from the D-MAG1, update the 357 flow cache entry, and send a FMA message to reply. Finally, the 358 flow will move to if2 via the D-MAG2 using mobility routing. 360 3.3. Use case 3 362 The last possible case, as shown in Figure 4, the multi interfaces 363 of mobile node attach to network sequentially and flows are moved 364 with a prefix granularity. It means that the flows are moved by 365 moving prefixes among the different D-MAGs the mobile node is 366 attached to. This use case also extends one scenario of [I-D.ietf- 367 netext-pmipv6-flowmob]. In this case, mobile node obtains a 368 combination of prefix(es) in use and a new prefix(es). Basic 369 operation will be as follows: 371 o As shown in Figure 4, initially the mobile node connects to the 372 D-MAG1 using if1 but if2 is not activated yet. When mobile node 373 adds traffic flows which use a different service, each flow are 374 assigned the different sets of prefixes. Since that, the D-MAG1 375 can perform mobility routing only for specific flow when D-MAG2 376 requests. After the mobile node turns on if2 and attaches to the 377 D-MAG2, the D-MAG2 sends a PBU message to the D-MAG1 and the 378 D-MAG1 determines what flow should be moved (using network 379 policy, etc.). Since the flow moves with a finer granularity, the 380 operation may complete from the D-MAG1 by making a tunnel and 381 sending a PBA message included the prefix of selected flow (flow 382 x in figure 4.). 384 MN D-MAG2 D-MAG1 Corresponding Nodes 385 | | | | 386 | flow x | flow x | 387 | pref1::mn | pref1::mn | 388 if1<-------------------------->|<---------------->CN1 389 | | | | 390 | flow y | flow y | 391 | pref2::mn | pref2::mn | 392 if1<-------------------------->|<---------------->CN2 393 | | | | 394 | | | | 395 | attach | | | 396 if2----------->| PBU | | 397 | |(D-MAG1, MN-ID)| | 398 | |-------------->| | 399 | | | | 400 | | Decide to move | 401 | | flow x to if2 | 402 | | | | 403 | |====tunnel=====| | 404 | | | | 405 | | PBA | | 406 | | (pref1::mn) | | 407 | |<--------------| | 408 | flow x | flow x | flow x | 409 | pref1::mn | pref1::mn | pref1::mn | 410 if2<---------->|<=============>|<---------------->CN1 411 | flow y | flow y | flow y | 412 | pref2::mn | pref2::mn | pref2::mn | 413 if1<-------------------------->|<----------------->| 414 | | | | 415 | | | | 417 Figure 4 419 3.4. Use case analysis 421 Since these use cases attempts to extend simply existing flow 422 mobility scheme of centralized mobility protocols to the distributed 423 architecture, there are several limitations and unclear points. In 424 the PMIPv6, LMA which is a centralized anchor could manage all 425 network entities and also all MAGs know location and address of LMA. 426 Therefore, the MAGs can send the PBU packets immediately after 427 detecting the access of the mobile node. However, in the distributed 428 architecture, the D-MAGs have all functions of LMA and MAG in PMIPv6 429 and manage their network separately. For this reason, a method used 430 to exchange information among D-MAGs is required. 432 One possible solution is that a new signaling message between D-MAGs 433 and they share the address or policy. Another solution is that 434 mobile node sends a trigger message to request flow mobility. In 435 this case, the trigger message may include the address of D-MAG 436 which will send packets to another the D-MAG, flow information or 437 another additional function. The trigger message may be defined on 438 the Layer 3, and also be defined on the Layer 2. In previous works, 439 the Handoff Indicator (HI) for fast handover can be used to trigger 440 message for flow mobility. However, the trigger message from mobile 441 node is not appropriate for network-based mobility because a mobile 442 node makes signaling messages. 444 4. Use case scenario in partially DMM architecture 446 In the partially distributed DMM architecture, as shown figure 5, 447 a Centralized Database(CDB) gathers information of all users in the 448 domain (e.g., IP address, traffic flows, etc.), so each D-MAG can 449 access to the database and get information when a mobile node attach 450 to. In [I-D.seite-dmm-dma], they already proposed a centralized 451 database to share information between distributed access routers. 452 Since centralized database performs only for sharing information, no 453 data traffic from mobile node forwards to this database. 455 |Centralized Database| 456 +---------------------------+ 457 | Location Management of MN | 458 +---------------------------+ 459 +--->| Interface Management of MN| 460 | +---------------------------+ 461 | | Binding/Flow Cache Entry |<---+ 462 | +---------------------------+ | 463 Location/Interface | Policy/Flow Decision Maker| | 464 Update | +---------------------------+ | 465 | Binding Update/ 466 | Flow Signaling 467 V V 468 | D-MAG1 | | D-MAG2 | 469 +-------------------+ +-------------------+ 470 |Binding/Flow Cache | |Binding/Flow Cache | 471 +-------------------+ +-------------------+ 472 | Mobility routing |<==============>| Mobility routing | 473 | for MN-if1 | Traffic Tunnel | for MN-if2 | 474 +-------------------+ +-------------------+ 475 | mobile node | 476 | +-------------------+ | 477 | | IP | | 478 | +---------+---------+ | 479 +-----| if1 | if2 |-----+ 480 +---------+---------+ 482 Figure 5 485 For the implementation of distributed and dynamic mobility 486 management solution, it could be considered to separate control and 487 data plane. In that case, besides centralized management functions, 488 the CDB also has policies of network management policies and route 489 decisions, so it can make decision and trigger to move the specific 490 flows. Actually it is not fully distributed architecture but data 491 can be distributed and forwarded without signaling messages between 492 D-MAGs. [Paper-Chan] and several researches are proposed 493 control/data separation schemes based on PMIPv6. 495 4.1. Use case 4 497 Possible use case in the partially distributed mobility approach is 498 shown in figure 6. When mobile node attaches to the network, D-MAG 499 should updates information of identifier (e.g. MAG, IP address) as 500 well as interface (e.g. Access technology type). Basic operation 501 will be as follows: 503 MN D-MAG2 D-MAG1 CMD Corresponding 504 | | | | Nodes 505 | Connect to network | | | 506 if1--------------------->| Update Info (MN-ID, MN-if1) 507 | | |--------->| | 508 | flow X (pref1::mn) | flow X (pref1::mn) | 509 if1<-------------------->|<---------------------->CN1 510 | | | | | 511 | Connect to network | | | 512 if2--------------------->| Update Info (MN-ID, MN-if2) 513 | | |--------->| | 514 | flow Y (pref2::mn) | flow Y (pref2::mn) | 515 if2<-------------------->|<---------------------->CN2 516 | | | | | 517 | | | Make Decision | 518 | | | for flow mobility | 519 | | | | | 520 | | |<---------| | 521 | | Binding Update (MN_flow x to D-MAG2) 522 | |<---------------------| | 523 | | Binding Update (MN_flow x to D-MAG2) 524 | | | | | 525 | |<=========>| | | 526 | Traffic Tunnel | | 527 | | | | | 528 | |--Binding Ack-------->| | 529 | | Binding Ack------>| | 530 | | | | | 531 if1<-------------------->| | | 532 | |<=========>| flow X (pref1::mn) | 533 | |<---------------------------------->CN1 534 | | flow Y (pref2::mn) | 535 if2<-------->|<---------------------------------->CN2 536 | | | | | 538 Figure 6 540 o When the mobile node attaches to the different D-MAGs through 541 multiple interfaces, simultaneously or sequentially, each 542 interface may be assigned different prefixes by each connected 543 D-MAG. After making a connection between mobile node and D-MAG, 544 Each D-MAG should send update message to the CDB. Since the CDB 545 may have a database for mobile nodes in the domain as well as 546 interface of each mobile node, it can inform to the D-MAG whether 547 connected mobile node were making connection before. 549 o For flow mobility decision based on policy, the CDB may determine 550 to move specific flow by using location and flow information in 551 the database. If the CDB decide to move flow X to if2, it may 552 send Binding Update messages to both D-MAG1 and D-MAG2. When both 553 D-MAGs receive Binding Update message, they may modify their 554 binding cache/flow cache entry and make traffic tunnel between 555 each other. After receiving Binding Ack message from D-MAGs, the 556 CDB may update its database. 558 4.2. Use case 5 560 In particular, Software-Defined Networking (SDN) has been proposed 561 from [Paper-SDN] to simplify routing entities in the network. In 562 that architecture, the centralized control function knows network 563 topology, so when a device attaches to the network and sends data, 564 the control function catches the packets, makes a path and pushes 565 flow rules to routing entities (e.g. switch, router) via specific 566 interface (e.g. OpenFlow). Routing entities in that network just 567 forward packets by the rules from the centralized control function. 568 Although the SDN is not fully distributed architecture, it can 569 achieve several requirements of DMM. SDN-based mobility management 570 is expected to be a promising approach which will support mobility 571 management for only moving user and session connectivity continuity 572 for mobile users without the waste of network resources (e.g. 573 tunneling). Moreover, by using SDN concept, we can adjust network 574 policies easily for users and specific flows. 576 5. Considering Multicast Routing 578 In [RFC 7333], they described that DMM should enable multicast 579 solutions to avoid network inefficiency. In PMIPv6 multicast 580 routing, the MAG perform as MLD proxy which maintains information 581 of subscribers, aggregates MLD report and make multicast tunnel with 582 multicast router. In DMM, similar with PMIPv6, D-MAG may perform MLD 583 proxy function to deliver multicast traffic. Considering flow 584 mobility, unicast traffic should be forwarded by using tunnel 585 between D-MAGs but multicast traffic can be delivered directly 586 through current D-MAG. To do that, however, there should be enhance 587 functionality to perform MLD proxy in D-MAG and extension of 588 protocol similar with PMIPv6 multicast method. 590 6. IP address type consideration 592 In [dmm-on-demand-mobility], they described IP address types that 593 depend on IP session continuity and IP address reachability, 594 including Fixed, Sustained, and Nomadic IP addresses. For each 595 address type, an application can request the appropriate IP address 596 type that supports a mobility management mechanism. In the existing 597 flow method mobility scheme, the IP address assigned to the mobile 598 node is assumed Fixed/Sustained IP address which guarantee IP 599 session continuity. In other words, the IP address is assigned by 600 the network regardless of characteristics of application. However, 601 in consideration of the type of IP address, a particular type of 602 IP address is requested by specific application and this address may 603 not provide session continuity. For example, such application that 604 has the Nomadic IP address may be used through one of interface of 605 the mobile node and, at the same time, such application that has the 606 Fixed IP address may be used through other interface of the mobile 607 node. In this case, access networks that are connected to each 608 interface of mobile node should determine the possibility of 609 supporting flow mobility in consideration of the IP address type of 610 the specific flow. If the IP address type requested by the 611 application is the Nomadic IP address which does not support IP 612 session continuity, the distributed anchor in the access network 613 does not need to consider mobility support for that flow at all. 614 On the other hand, if the IP address type requested by the 615 application needs to be provide IP session continuity, such as 616 fixed/sustained address, the anchor should determine for the flow 617 mobility support through the mobility anchor. To determine flow 618 mobility support based on the IP address type, the mechanism which 619 makes decision for flow mobility according to flow information and 620 address type is required. 622 7. Security Considerations 624 TBD 626 8. IANA Considerations 628 This document makes no request of IANA. 630 9. References 632 9.1. Normative References 634 [RFC2119] Brander, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, March 1997. 637 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 638 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 640 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 641 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 642 Network Mobility (NEMO) Basic Support", RFC 6089, January 643 2011. 645 [I-D.ietf-netext-pmipv6-flowmob] Bernardos, CJ., "Proxy Mobile IPv6 646 Extensions to Support Flow Mobility", draft-ietf-netext- 647 pmipv6-flowmob-11 (work in progress), July 2014. 649 [I-D.ietf-netext-logical-interface-support] 650 Melina, T., and S. Gundavelli, "Logical Interface Support 651 for multi-mode IP Hosts", draft-ietf-netext-logical- 652 interface-support-10 (work in progress), September 2014. 654 [dmm-on-demand-mobility] Yegin, A., Kweon, K., Lee, J. and J. Park, 655 "On Demand Mobility Management", draft-yegin-dmm-ondemand- 656 mobility-03 (work in progress), March 2015. 658 9.2. Informative References 660 [RFC 7333] 661 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 662 "Requirements for Distributed Mobility Management", 663 RFC 7333, August 2014. 665 [I-D.ietf-dmm-best-practices-gap-analysis] 666 Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 667 Bernardos, "Distributed Mobility Management: Current 668 practices and gap analysis", draft-ietf-dmm-best- 669 practices-gap-analysis-08 (work in progress), September 670 2014. 672 [I-D.seite-dmm-dma] 673 Seite, P., Bertin, P., and J. Lee, "Distributed Mobility 674 Anchoring", draft-seite-dmm-dma-07 (Expired), 675 August 2014. 677 [I-D.bernardos-dmm-distributed-anchoring] 678 Bernardos, CJ., and JC. Zuniga, "PMIPv6-based distributed 679 anchoring", draft-bernardos-dmm-distributed-anchoring-04 680 (work in progress), May 2014. 682 [Paper-Chan] 683 Chan, H., "Proxy Mobile IP with Distributed Mobility 684 Anchors", GlobeCom 2010 Workshop on Seamless Wireless 685 Mobility, December 2010. 687 [Paper-SDN] 688 Open Networking Foundation White Paper, "Software-Defined 689 Networking: the new norm for networks", ONF, 2012. 691 10. Acknowledgments 692 Authors' Addresses 694 Kyoungjae Sun 695 Soongsil University 696 369, Sangdo-ro, Dongjak-gu, 697 Seoul 156-743, Korea 699 Email: gomjae@dcn.ssu.ac.kr 701 Younghan Kim 702 Soongsil University 703 369, Sangdo-ro, Dongjak-gu, 704 Seoul 156-743, Korea 706 Email: younghak@ssu.ac.kr