idnits 2.17.1 draft-liu-dmm-deployment-scenario-05.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 are 5 instances of too long lines in the document, the longest one being 63 characters in excess of 72. ** There are 3 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 == Line 27 has weird spacing: '... months and ...' == Line 28 has weird spacing: '... at any time...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (October 19, 2015) is 3105 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'VNFO' is mentioned on line 311, but not defined == Missing Reference: 'VNFM' is mentioned on line 328, but not defined == Missing Reference: 'PNF' is mentioned on line 328, but not defined == Unused Reference: '1' is defined on line 436, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 446, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'Fab1999' is defined on line 468, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. -- Duplicate reference: RFC2234, mentioned in 'RFC2234', was also mentioned in '2'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 3753 Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group V.Liu 2 Internet Draft ChinaMobile 3 Intended status: Standards Track D.Liu 4 Expires: Mar 18, 2016 Alibaba 5 H. Chan 6 Huawei Technologies 7 H. Deng 8 China Mobile 9 X.Wei 10 Huawei Technologies 11 October 19, 2015 13 Distributed mobility management deployment scenario and architecture 14 draft-liu-dmm-deployment-scenario-05 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 This Internet-Draft will expire on March 19,2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. 56 Abstract 58 This document discusses the deployment scenario of distributed 59 mobility management. The purpose of this document is to trigger the 60 discussion in the group to understnad the DMM deployment scenario 61 and consideration from the operator's perspective. 63 Table of Contents 65 Table of Contents ................................................ 2 66 1. Introduction .................................................. 2 67 2. Conventions used in this document.............................. 3 68 2.1. Terminology .............................................. 3 69 3. Deployment Scenario and Model of DMM........................... 3 70 4. Network Function Virtualization Scenario....................... 4 71 4.1. Network function virtualization deployment architecture... 4 72 4.2. Control and data plane separation......................... 6 73 4.3. Mobility management architecture.......................... 6 74 4.4 NFV based deployment architecture......................... 7 75 5. SIPTO deployment scenario...................................... 8 76 6. WLAN deployment scenario....................................... 9 77 7. Conclusion ................................................... 10 78 8. Security Considerations....................................... 10 79 9. IANA Considerations .......................................... 10 80 10. Normative References......................................... 11 81 11. Informative References....................................... 11 82 12. Acknowledgments ............................................. 11 83 Authors' Addresses .............................................. 12 84 1. Introduction 86 Distributed mobility management aims at solving the centralized 87 mobility anchor problems of the traditional mobility management 88 protocol. The benefit of DMM solution is that the data plane traffic 89 does not need to traverse the centralized anchoring point. This 90 document discusses the potential deployment scenario of DMM. The 91 purpose of this document is to help the group to reach consensus 92 regarding the deployment model of DMM and then develop the DMM 93 solution based on the deployment model. 95 2. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2.1. Terminology 103 All the general mobility-related terms and their acronyms used in 104 this document are to be interpreted as defined in the Mobile IPv6 105 base specification [RFC6275], in the Proxy mobile IPv6 specification 106 [RFC5213], and in Mobility Related Terminology [RFC3753]. These 107 terms include the following: mobile node (MN), correspondent node 108 (CN), and home agent (HA) as per [RFC6275]; local mobility anchor 109 (LMA) and mobile access gateway (MAG) as per [RFC5213], and context 110 as per [RFC3753]. 112 In addition, this draft introduces the following terms. 114 Location information (LI) function 116 is the logical function that manages and keeps track of the internet 117 work location information of a mobile node which may change its IP 118 address as it moves. The information may associate with each session 119 identifier, the IP routing address of the MN, or of a node that can 120 forward packets destined to the MN. 122 Forwarding management (FM) 124 is the logical function that intercepts packets to/from the IP 125 address/prefix delegated to a mobile node and forwards them, based 126 on internetwork location information, either directly towards their 127 destination or to some other network element that knows how to 128 forward the packets to their ultimate destination. With data plane 129 and control plane separation, the forwarding management may be 130 separated into a data-plane forwarding management (FM-DP) function 131 and a control-plane forwarding management (FM-CP) function. 133 3. Deployment Scenario and Model of DMM 135 As discussed in the DMM requirement document, the centralized 136 mobility management has several drawbacks. The main problem of the 137 centralized mobility management protocols is that all the traffic 138 need to anchor to a centralized anchor point. This approach does not 139 cause any problem in current mobile network deployment but in the 140 scenario that will be discussed later in this document, centralized 141 mobility management protocols will have many drawbacks and it is 142 believed that DMM is more suitable in that scenario. 144 The main deployment scenario discussed in this document is divided 145 into three scenarios. The first one is the network function 146 virtualization scenario. In this scenario, the mobile core network's 147 control plane function is centralized in the mobile cloud. 148 Apparently, deploying the data plane function also in the same 149 centralized mobile cloud is not optimized from the traffic 150 forwarding's perspective. For the control plane The MME and PGW-F 151 are implemented by NFV. For the dataplane the PGW-F/SGW-F can 152 weither be implemented by NFV or lagacy devices. The second 153 deployment scenario is the SIPTO/LIPA scenario which is discussed in 154 3GPP. In this scenario, DMM can provide optimized traffic offloading 155 solution. The Third deploy scenario is the WLAN scenario. In this 156 scenario, the AC is implemented in the cloud and the authentication 157 status can maintained as the terminal move from one AP to another. 159 4. Network Function Virtualization Scenario 161 This section discusses network function virtualization scenario, the 162 associated control - data plane separation and the possible mobility 163 management functions to support this scenario. 165 4.1. Network function virtualization deployment architecture 167 The network function virtualization scenario is shown in Figure 1. 169 Mobile Cloud 170 ........... 171 (' ') 172 ( ))) 173 ((( +-----------+ ))) 174 (( |Mobile Core| ))) 175 (( |MME+P/SGW-C| ))) 176 ((( +-----------+ ))) 177 ('..............') 178 | 179 | IP Transit Network 180 (.........) 181 ( )) MN-Internet communication 182 ( ^ )) 183 ^ > > >( ^ ))> > > > > > > > > 184 ^ (( ^ ) v 185 ^ (.........^.) v 186 ^ +-------| | ^| v 187 ^ | | ^+--------------+ v 188 ^ | | < < | v MN-MN communication 189 ^ | | ^ | v 190 +--------------+ +--------------+ +--------------+ 191 |Access Network| |Access Network| |Access Network| 192 | PGW-F/SGW-F | | PGW-F/SGW-F | | PGW-F/SGW-F | 193 +--------------+ +--------------+ +--------------+ 194 ^ ^ v 195 ^ ^ v 196 +---------+ +---------+ +---------+ 197 | MN | | MN | | MN | 198 +---------+ +---------+ +---------+ 200 Figure 1: Network function virtualization deployment architecture 202 In this architecture, the mobile core include MME and PGW-F is 203 located in the cloud data center, which can be the operator's 204 private cloud using NFV. The access network cantains PGW-F/SGW-F is 205 connected through an IP transit network. The PGW-F/SGW-F may also 206 implement by NFV of small data center in convergence layer. The 207 architecture of NFV based Mobile Core is shown in Figure 2. 209 --------------------------------- ------------------- 210 | ----------------------------- | | MANO LAYER | 211 | | OSS/BSS LAYER | | | | 212 | ----------------------------- | | ------------- | 213 | | | | |Orchestrator| | 214 | ----------------------------- | | ------------- | 215 | | VNF LAYER | | | | | 216 | | --------- ------ | | | ------------- | 217 | | |P/SGW-C| | MME | | |-----| | VNFM | | 218 | | --------- ------ | | ------------- | 219 | ----------------------------- | | | | 220 | | | | | | 221 | ----------------------------- | | ------------- | 222 | | NFVI LAYER | |-----| | VIM | | 223 | ----------------------------- | | ------------- | 224 --------------------------------- ------------------- 225 Figure 2: NFV based Mobile Core Architecture 227 In Figure 2, the MANO layer contains Orchestrator, VNFM and VIM. The 228 Orchestrator is in charge of top-down service and source monitor and 229 fulfillment. VNFM is incharge of manage the VNFs. And VIM normally is 230 the Openstack which provide management of the whole virtualization 231 layer. 233 4.2. Control and data plane separation 235 The cloud based mobile core network architecture implies separation 236 of the control and data planes. The control plane is located in the 237 cloud and the data plane should be distributed. Otherwise, all the 238 data traffic will go through the cloud which is obviously not 239 optimized for the mobile node to mobile node communication. For the 240 mobile node to Internet communication, the Internet access point is 241 normally located in the metro IP transit network. In this case, the 242 mobile node to Internet traffic should also go through the Internet 243 access point instead of the mobile core in the cloud. 245 However, in some deployment scenario, the operator may choose to put 246 the mobile core cloud in the convergence layer of IP metro network. 247 In this case, the Internet access point may co-located with the 248 mobile core cloud. In this case, the mobile node to Internet traffic 249 may go through the mobile core cloud. 251 4.3. Mobility management architecture 253 Since the control plane and data plane are separated and the data 254 plane is distributed, traditional mobility management cannot meet 255 this requirement. Distributed mobility management or SDN based 256 mobility management may be used in this architecture to meet the 257 traffic forwarding requirement (e.g. MN to MN and MN to Internet 258 traffic should not go through from the mobile core cloud.). The 259 traditional mobility management functions is not separating the data 260 plane from the control plane. Basic mobility management functions 261 include location information (LI) function and Forwarding management 262 (FM). The former is a control plane function. The latter can be 263 separated into data plane forwarding management (FM-DP) and control 264 plane forwarding management (FM-CP). 266 The data plane function is FM-DP, while the control plane functions 267 include FM-CP and LI. Then the control plane functions in the cloud- 268 based mobile core includes LI and FM-CP. They are of cause other 269 functions in the control plane such as policy function. The 271 distributed data plane may have multiple instances of FM-DP in the 272 network. 274 core network controller 276 +---------+ 277 |LI, FM-CP| 278 +---------+ 280 +-------+ +-------+ +-------+ 281 | FM-DP | | FM-DP | | FM-DP | 282 +-------+ +-------+ +-------+ 284 Figure 2: Mobility management functions with data plane - control 285 plane separation under one controller When the control of the access 286 network is separate from that of the core, there will be separate 287 controllers as shown in Figure 3. 289 Access network controller Core network controller 291 +---------+ +---------+ 292 |LI, FM-CP| |LI, FM-CP| 293 +---------+ +---------+ 295 +-------+ +-------+ +-------+ +-------+ 296 | FM-DP | | FM-DP | | FM-DP | | FM-DP | 297 +-------+ +-------+ +-------+ +-------+ 299 Figure 2: Mobility management functions with data plane - control 300 plane separation with separate control in core and in access 301 networks. 303 4.4. NFV based deployment architecture 305 Here is the deployment architecture in NFV. 307 ------------- ------------ 308 | Yang Model | | Tosca Model| 309 ------------- ------------ 310 ------------------------------------------------------------------------- 311 | [VNFO] -------------------------------------------------- | 312 | ------------ | -------------------- ------------------------ || 313 | | NBI | | | ----- ----- ----- | | ---------------------- ||| 314 | ------------ | | |NSD| |FGD| |VLD| | ||VNFD(LI,FM-CP)(FD-DP) |||| 315 | | | ----- ----- ----- | | ---------------------- ||| 316 | ------------ | -------------------- ------------------------ || 317 | | API Router| | DataBase || 318 | ------------ ---------------------------------------------------| 319 | | 320 | ------------ | 321 | |Core Engine| | 322 | ------------ | 323 ------------------------------------------------------------------------- 324 ------------ ------------ ------------ 325 |VNFM Driver| |VIM Driver| |PNF Driver| 326 ------------ ------------ ------------ 327 ---------------------------------------------- ----------------- 328 | [VNFM] | |[PNF] | 329 | VNF Life cycle management; | | ------------ | 330 | VNF configuration; | | | OVS | | 331 | VNF update; | | ------------ | 332 | VNF status monitor; | ----------------- 333 | VNF Auto healing/Scale in/Scale out | 334 ---------------------------------------------- 335 ----------------------------------------------------------------- 336 | Vim | 337 ----------------------------------------------------------------- 338 -------------------------------------------------- 339 |[VNF] LI Slicing ; FM-CP Slicing; FD-DP Slicing | 340 -------------------------------------------------- 341 Figure 3 Deployment architecture 342 5. SIPTO deployment scenario 344 The Second deployment scenario is the SIPTO scenario which is 345 discussed in 3GPP. DMM is believed to be able to provide dynamic 346 anchoring. It allows the mobile node to have several anchoring 347 points and to change the anchoring point according to the 348 application requirement. In SIPTO scenario, the gateway function is 349 located very near to the access network and to the user. If using 350 current centralized mobility management, the traffic will need to 351 tunnel back to the previous anchor point even when the mobile node 352 has changed the point of attachment to a new one. Figure 3 shows the 353 architecture of SIPTO. 355 +---------+ 356 | GGSN | 357 +---------+ 358 | 359 | 360 ------------------------------------------ 361 | | | | 362 +---------+ +---------+ +---------+ +---------+ 363 | MSC | | SGSN | | MSC | | SGSN | 364 +---------+ +---------+ +---------+ +---------+ 365 | | | | | | 366 ------------ ---------- --------- 367 | | | 368 <<<<<<<<<| <<<<<<<| |>>>>>>>> 369 +---------+ +---------+ +---------+ 370 | GGSN | | GGSN | | GGSN | 371 | RNC | | RNC | | RNC | 372 +---------+ +---------+ +---------+ 373 ^| |^ ^| 374 ^| |^ ^| 375 --------------- |^ ^| 376 ^| |^ |^ ^| 377 +---------+ +---------+ +---------+ +---------+ 378 | NodeB | | NodeB | | NodeB | | NodeB | 379 +---------+ +---------+ +---------+ +---------+ 380 ^| ^| ^| 381 +---------+ +---------+ +---------+ 382 | Terminal| -> | Terminal| -> -> | Terminal| 383 +---------+ +---------+ +---------+ Figure 4 SIPTO Scenario 385 6. WLAN deployment scenario 387 The Third deployment scenario is the WLAN scenario. DMM can enable 388 the AC in the cloud. The cloud AC and maintain the authentication 389 and connection status. As the terminal move from one AP to another, 390 it still can have the connection. 392 ........... 393 (' ') 394 ((( +-----------+ ))) 395 (( | Mobile AC | ))) 396 ((( +-----------+ ))) 397 ('..............') 398 | 399 | IP Transit Network 400 (.........) 401 ( )) 402 ( )) 403 ( )) 404 (( ) 405 (..........) 406 +-----------------------------------+ 407 | | | 408 | | | 409 | | | 410 +----------+ +-----------+ +----------+ 411 | AP | | AP | | AP | 412 +----------+ +-----------+ +----------+ 413 | | | 414 +---------+ +---------+ +---------+ 415 | Terminal| -> | Terminal| -> | Terminal| 416 +---------+ +---------+ +---------+ 417 Figure 5 WLAN deployment scenario 419 7. Conclusion 421 This document discusses the deployment scenario of DMM. Three types 422 of deployment scenario is discussed in this document. Further types 423 of deployment scenario can be added to this document according to 424 the progress of the group's discussion. 426 8. Security Considerations 428 N/A 430 9. IANA Considerations 432 N/A 434 10. Normative References 436 [1] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, March 1997. 439 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 440 Syntax Specifications: ABNF", RFC 2234, Internet Mail 441 Consortium and Demon Internet Ltd., November 1997. 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, March 1997. 446 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 447 Syntax Specifications: ABNF", RFC 2234, Internet Mail 448 Consortium and Demon Internet Ltd., November 1997. 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, March 1997. 453 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 454 RFC 3753, June 2004. 456 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 457 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 459 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 460 in IPv6", RFC 6275, July 2011. 462 11. Informative References 464 [3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP 465 and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- 466 1583. 468 [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in 469 TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 470 1573-1583. 472 12. Acknowledgments 474 This document was prepared using 2-Word-v2.0.template.dot. 476 Authors' Addresses 478 Vic Liu 479 China Mobile 480 32 Xuanwumen West AVE, Xicheng, Beijing 481 Email: liuzhiheng@chinamobile.com 483 Dapeng Liu 484 Alibaba 486 Email: max@dotalks.com 488 H Anthony Chan 489 Huawei Technologies 490 5340 Legacy Dr. Building 3 491 Plano, TX 75024 492 USA 493 Email: h.a.chan@ieee.org 495 Hui Deng 496 China Mobile 497 32 Xuanwumen West AVE, Xicheng, Beijing 498 Email: denglingli@chinamobile.com 500 Xinpeng Wei 501 Huawei Technologies 503 Email: Xinpengwei@huawei.com