idnits 2.17.1 draft-liu-dmm-deployment-scenario-03.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 10 has weird spacing: '...agement deplo...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 8, 2015) is 3327 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE-802.11.2012' is defined on line 292, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Liu 3 Internet-Draft China Mobile 4 Intended status: Informational H. Chan 5 Expires: September 9, 2015 Huawei Technologies 6 H. Deng 7 China Mobile 8 March 8, 2015 10 Distributed mobility management deployment scenario and architecture 11 draft-liu-dmm-deployment-scenario-03 13 Abstract 15 This document discusses the deployment scenario of distributed 16 mobility management. The purpose of this document is to trigger the 17 discussion in the group to understnad the DMM deployment scenario and 18 consideration from the operator's perspective. 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). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 9, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions used in this document . . . . . . . . . . . . . . . 3 56 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Deployment Scenario and Model of DMM . . . . . . . . . . . . . 4 58 4. Network Function Virtualization Scenario . . . . . . . . . . . 4 59 4.1. Network function virtualization deployment architecture . . 4 60 4.2. Control and data plane separation . . . . . . . . . . . . . 5 61 4.3. Mobility management architecture . . . . . . . . . . . . . 6 62 5. SIPTO deployment scenario . . . . . . . . . . . . . . . . . . . 7 63 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 66 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 11. Normative References . . . . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Distributed mobility management aims at solving the centralized 74 mobility anchor problems of the traditional mobility management 75 protocol. The benefit of DMM solution is that the data plane traffic 76 does not need to traverse the centralized anchoring point. This 77 document discusses the potential deployment scenario of DMM. The 78 purpose of this document is to help the group to reach consensus 79 regarding the deployment model of DMM and then develop the DMM 80 solution based on the deployment model. 82 2. Conventions used in this document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2.1. Terminology 90 All the general mobility-related terms and their acronyms used in 91 this document are to be interpreted as defined in the Mobile IPv6 92 base specification [RFC6275], in the Proxy mobile IPv6 specification 93 [RFC5213], and in Mobility Related Terminology [RFC3753]. These 94 terms include the following: mobile node (MN), correspondent node 95 (CN), and home agent (HA) as per [RFC6275]; local mobility anchor 96 (LMA) and mobile access gateway (MAG) as per [RFC5213], and context 97 as per [RFC3753]. 99 In addition, this draft introduces the following terms. 101 Location information (LI) function 103 is the logical function that manages and keeps track of the 104 internetwork location information of a mobile node which may 105 change its IP address as it moves. The information may associate 106 with each session identifier, the IP routing address of the MN, or 107 of a node that can forward packets destined to the MN. 109 Forwarding management (FM) 111 is the logical function that intercepts packets to/from the IP 112 address/prefix delegated to a mobile node and forwards them, based 113 on internetwork location information, either directly towards 114 their destination or to some other network element that knows how 115 to forward the packets to their ultimate destination. With data 116 plane and control plane separation, the forwarding management may 117 be separated into a data-plane forwarding management (FM-DP) 118 function and a control-plane forwarding management (FM-CP) 119 function. 121 3. Deployment Scenario and Model of DMM 123 As discussed in the DMM requirement document, the centralized 124 mobility management has several drawbacks. The main problem of the 125 centralized mobility management protocols is that all the traffic 126 need to anchor to a centralized anchor point. This approach does not 127 cause any problem in current mobile network deployment but in the 128 scenario that will be discussed later in this document, centralized 129 mobility management protocols will have many drawbacks and it is 130 believed that DMM is more suitable in that scenario. 132 The main deployment scenario discussed in this document is divided 133 into two types. The first one is the network function virtualization 134 scenario. In this scenario, the mobile core network's control plane 135 function is centralized in the mobile cloud. Apparently, deploying 136 the data plane function also in the same centralized mobile cloud is 137 not optimized from the traffic forwarding's perspective. Another 138 deployment scenario is the SIPTO/LIPA scenario which is discussed in 139 3GPP. In this scenario, DMM can provide optimized traffic offloading 140 solution. 142 4. Network Function Virtualization Scenario 144 This section discusses network function virtualization scenario, the 145 associated control - data plane separation and the possible mobility 146 management functions to support this scenario. 148 4.1. Network function virtualization deployment architecture 150 The network function virtualization scenario is shown in Figure 1. 152 Mobile Cloud 153 ........... 154 (' ') 155 ( ))) 156 ((( +-----------+ ))) 157 (( |Mobile Core| ))) 158 ((( +-----------+ ))) 159 ('..............') 160 | 161 | IP Transit Network 162 (.........) 163 ( )) MN-Internet communication 164 ( ^ )) 165 ^ > > >( ^ ))> > > > > > > > > 166 ^ (( ^ ) v 167 ^ (.........^.) v 168 ^ +-------| | ^| v 169 ^ | | ^+--------------+ v 170 ^ | | < < | v MN-MN communication 171 ^ | | ^ | v 172 +--------------+ +--------------+ +--------------+ 173 |Access Network| |Access Network| |Access Network| 174 +--------------+ +--------------+ +--------------+ 175 ^ ^ v 176 ^ ^ v 177 +---------+ +---------+ +---------+ 178 | MN | | MN | | MN | 179 +---------+ +---------+ +---------+ 181 Figure 1: Network function virtualization deployment architecture 183 In this architecture, the mobile core network is located in the cloud 184 /data center, which can be the operator's private cloud. The access 185 network is connected through an IP transit network. The mobile core 186 network can run in a virtualized platform in the cloud/datacenter. 188 4.2. Control and data plane separation 190 The cloud based mobile core network architecture implies separation 191 of the control and data planes. The control plane is located in the 192 cloud and the data plane should be distributed. Otherwise, all the 193 data traffic will go through the cloud which is obviously not 194 optimized for the mobile node to mobile node communication. 196 For the mobile node to Internet communication, the Internet access 197 point is normally located in the metro IP transit network. In this 198 case, the mobile node to Internet traffic should also go through the 199 Internet access point instead of the mobile core in the cloud. 201 However, in some deployment scenario, the operator may choose to put 202 the mobile core cloud in the convergence layer of IP metro network. 203 In this case, the Internet access point may co-located with the 204 mobile core cloud. In this case, the mobile node to Internet traffic 205 may go through the mobile core cloud. 207 4.3. Mobility management architecture 209 Since the control plane and data plane are separated and the data 210 plane is distributed, traditional mobility management cannot meet 211 this requirement. 213 Distributed mobility management or SDN based mobility management may 214 be used in this architecture to meet the traffic forwarding 215 requirement (e.g. MN to MN and MN to Internet traffic should not go 216 through from the mobile core cloud.). 218 The traditional mobility management functions is not separating the 219 data plane from the control plane. Basic mobility management 220 functions include location information (LI) function and Forwarding 221 management (FM). The former is a control plane function. The latter 222 can be separated into data plane forwarding management (FM-DP) and 223 control plane forwarding management (FM-CP). 225 The data plane function is FM-DP, while the control plane functions 226 include FM-CP and LI. Then the control plane functions in the cloud- 227 based mobile core includes LI and FM-CP. They are of cause other 228 functions in the control plane such as policy function. The 229 distributed data plane may have multiple instances of FM-DP in the 230 network. 232 core network controller 233 +---------+ 234 |LI, FM-CP| 235 +---------+ 237 +-------+ +-------+ +-------+ 238 | FM-DP | | FM-DP | | FM-DP | 239 +-------+ +-------+ +-------+ 241 Figure 2: Mobility management functions with data plane - control 242 plane separation under one controller 244 When the control of the access network is separate from that of the 245 core, there will be separate controllers as shown in Figure 3. 247 Access network controller Core network controller 248 +---------+ +---------+ 249 |LI, FM-CP| |LI, FM-CP| 250 +---------+ +---------+ 252 +-------+ +-------+ +-------+ +-------+ 253 | FM-DP | | FM-DP | | FM-DP | | FM-DP | 254 +-------+ +-------+ +-------+ +-------+ 256 Figure 2: Mobility management functions with data plane - control 257 plane separation with separate control in core and in access 258 networks. 260 5. SIPTO deployment scenario 262 Another deployment scenario is the SIPTO scenario which is discussed 263 in 3GPP. DMM is believed to be able to provide dynamic anchoring. 264 It allows the mobile node to have several anchoring points and to 265 change the anchoring point according to the application requirement. 266 In SIPTO scenario, the gateway function is located very near to the 267 access network and to the user. If using current centralized 268 mobility management, the traffic will need to tunnel back to the 269 previous anchor point even when the mobile node has changed the point 270 of attachment to a new one. 272 6. Conclusion 274 This document discusses the deployment scenario of DMM. Two types of 275 deployment scenario is discussed in this document. Further types of 276 deployment scenario can be added to this document according to the 277 progress of the group's discussion. 279 7. Security Considerations 281 N/A. 283 8. IANA Considerations 285 N/A. 287 9. Contributors 288 10. Acknowledgements 290 11. Normative References 292 [IEEE-802.11.2012] 293 "", March 2012. 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 299 RFC 3753, June 2004. 301 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 302 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 304 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 305 in IPv6", RFC 6275, July 2011. 307 Authors' Addresses 309 Dapeng Liu 310 China Mobile 311 No.32 Xuanwumen West Street 312 Beijing 100053 313 China 315 Email: liudapeng@chinamobile.com 317 H Anthony Chan 318 Huawei Technologies 319 5340 Legacy Dr. Building 3 320 Plano, TX 75024 321 USA 323 Email: h.a.chan@ieee.org 324 Hui Deng 325 China Mobile 326 No.32 Xuanwumen West Street 327 Beijing 100053 328 China 330 Email: denghui@chinamobile.com