idnits 2.17.1 draft-liu-cloud-mobile-core-02.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 too long lines in the document, the longest one being 1 character in excess of 72. 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 has text resembling RFC 2119 boilerplate text. -- The document date (October 26, 2014) is 3469 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE-802.11.2012' is defined on line 331, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Liu 3 Internet-Draft China Mobile 4 Intended status: Informational K. Yap 5 Expires: April 27, 2015 Google 6 C. Perkins 7 Huawei 8 T. Sun 9 H. Deng 10 China Mobile 11 October 26, 2014 13 Cloud Based Mobile Core Network Problem Statement 14 draft-liu-cloud-mobile-core-02 16 Abstract 18 This document introduces a IP cloud based mobile core network 19 architecture. The motivation and the key problems that need to be 20 further studied by the community are analyzed. The purpose of this 21 document is to call the community's attention and interest to study 22 the key technologies and protocols to realize this cloud based mobile 23 core network. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 27, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 3. The motivation for cloud based mobile core network . . . . . 3 62 4. Cloud based mobile core network architecture overview . . . . 4 63 5. Problem statement of cloud based mobile core architecture . . 5 64 5.1. Control and data plane separation . . . . . . . . . . . . 5 65 5.2. Mobility management . . . . . . . . . . . . . . . . . . . 5 66 5.3. Network slicing . . . . . . . . . . . . . . . . . . . . . 6 67 5.4. Network auto-configuration . . . . . . . . . . . . . . . 7 68 6. Open API . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 12. Normative References . . . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 The mobile network has been evolved from 2G, 3G and now the 4G 80 network is being deployed by many operators. Traditionally, the 81 mobile core network equipment is dedicated telecom equipment, many of 82 them are based on dedicated hardware platform, e.g. CPCI. The core 83 network equipment's software is normally tightly coupled with the 84 hardware. The purpose of this dedicate hardware and software 85 integrated approach is to achieve telecom level high performance and 86 high reliability. But the consequence of this design approach is the 87 lack of flexibility of the network. Current mobile network is facing 88 the challenge of the booming of the mobile Internet. The mobile 89 network not only facing the very fast increasing of the data traffic 90 and also have to face the challenge from OTT applications. Those 91 challenges require the mobile core network having more flexibilitys. 92 This document proposes a cloud based mobile network architecture to 93 meet those challenges. 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 3. The motivation for cloud based mobile core network 103 Current mobile network is facing the following challenge: 105 1. The fast increasing of the data traffic. According to Cisco's 106 visual networking prediction,the mobile Internet traffic will 107 increase 66% CAGR from 2012 to 2017. Such high volume of data 108 traffic will not only put a lot of pressure to the wireless access 109 network side but also give a lot of challenge to the mobile core 110 network side. For example, in current mobility management 111 architecture, both the Mobile IP protocol developed by IETF and the 112 GTP protocol developed by 3GPP share a common idea that there will be 113 one or more IP anchoring points that maintain the home address of the 114 mobile node and its topological routable IP address. The fast 115 increasing of the mobile data traffic will give much pressure to the 116 mobile anchor point. IETF DMM working group was formed to tackle 117 this problem by distributing of the anchor point. A more radical 118 approach is that there is no anchoring point in the network, it will 119 relay on the routing system or SDN to take care of the mobility 120 management. 122 2. The lack of flexibility of network functionality. Although the 123 telecom industry is trying to decouple the service and the network 124 but we still can see that in current mobile network architecture it 125 is very difficult to deploy a new service or upgrade the network's 126 capability. Since currently, most of the mobile core equipment is 127 build on the CPCI hardware platform and the software normally tightly 128 coupled with the hardware platform. It is very difficult to change 129 or upgrade the network equipment's functionality in an agile way. On 130 the other hand, the mobile operators want to provide more intelligent 131 and value added service other than to be a just dumb pipe providers. 132 That will also require the mobile core network has the flexibility. 134 3. The lack of flexibility of service deployment. When the operator 135 wants to deploy a new service, it is needed to make the network 136 upgrade plan carefully and need to do the trial deployment in a small 137 area to guaranty that the new service and network upgrading will not 138 affect the production network. The whole process of a new service to 139 be deployed normally takes several months even years. 141 4. The challenge of reducing the CAPEX and OPEX cost. The mobile 142 operators need to lower both the CAPEX and the OPEX of their network, 143 especially when they are facing the fast increasing of the data 144 traffic. Dedicated hardware and tightly coupled software also makes 145 the CAPEX and OPEX at a high level. 147 4. Cloud based mobile core network architecture overview 149 This section discuss the cloud based mobile core network 150 architecture. 152 Cloud 153 ........... 154 (' ') 155 ( ))) 156 ((( +-----------+ ))) 157 (( |Mobile Core| ))) 158 ((( +-----------+ ))) 159 ('..............') 160 | 161 | IP Transmit 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: Cloud based mobile core network architecture 183 In this architecture, the mobile core network is located in the 184 cloud/data center. That could be the operator's private cloud. The 185 access network is connected to the mobile core network through IP 186 transmit network. The mobile core network could run in a virtualized 187 platform in the cloud/datacenter. 189 5. Problem statement of cloud based mobile core architecture 191 5.1. Control and data plane separation 193 The cloud based mobile core network architecture implies the 194 separation of the control and data plane. The control plane is 195 located in the cloud and the data plane should be distributed. 196 Otherwise, all the data traffic will go through to the cloud which is 197 obviously not optimized for the mobile node to mobile node 198 communication. 200 For the mobile node to Internet communication, the Internet access 201 point normally is located in the metro IP transmit network. In this 202 case, the mobile node to Internet traffic should also go through from 203 the Internet access point instead of go to the mobile core in the 204 cloud. 206 However, in some deployment scenario, the operator may choose to put 207 the mobile core cloud in the convergency layer of IP metro network. 208 In this case, the Internet access point may co-located with the 209 mobile core cloud. In this case, the mobile node to Internet traffic 210 may go through the mobile core cloud. 212 5.2. Mobility management 214 Since the control plane and data plane are separated and the data 215 plane is distributed, traditional mobility management can not meet 216 this requirement. 218 Distributed mobility management or SDN based mobility management may 219 be used in this architecture to meet the traffic routing requirement 220 (e.g. MN to MN and MN to Internet traffic should not go through from 221 the mobile core cloud.). 223 IETF DMM working group is currently specifying distributed mobility 224 management protocol which maybe suitable for this cloud based mobile 225 network architecture. The key features of distributed mobility 226 management are as follows: 228 Seperation of control plane and data plane of mobility management. 229 This feature enable the operator to concentrate the mobile core 230 network's control plane function. Those control plane functions 231 can be virtulized and running on generic cheaper hardware. 232 Data plane distribution. This feature allows the data plane 233 traffic be distributed according to the geographic topology. 235 5.3. Network slicing 237 Network slicing is a technology that can 'slice' a physical network 238 into different pieces. Each piece is logically independent from each 239 other. One example of network slicing technology is FlowVisor. 240 FlowVisor [FlowVisor] is based on open flow protocol, multiple open 241 flow controller could be connected to the FlowVisor and the FlowVisor 242 connect to the physical switches. The FlowVisor can translate the 243 flow control command from the controller above the FlowVisor in to 244 the flow control command specific to the network slice that allocated 245 to this controller. For example, in figure 2, from controller A's 246 perspective, it believes that it has the full control of all the 247 physical network. Also from controller B's perspective, it also 248 believe that it has the full control of all the physical network. 249 Multiple controllers do not interfere from each other.By this way, 250 multiple controller can share the same physical network and the 251 physical network is sliced into multiple pieces. 253 +----------+ +----------+ +----------+ 254 |Controller| |Controller| |Controller| 255 | A | | B | | C | 256 +----------+ +----------+ +----------+ 257 | | | 258 +-----------------------------------------+ 259 | | 260 | Flow Visor | 261 | | 262 +-----------------------------------------+ 263 | 264 +-----------------------------------------+ 265 | | 266 | Physical Network | 267 | | 268 +-----------------------------------------+ 270 Figure 2: FlowVisor 272 Network slicing can provide a flexible network capability for the 273 operator. For example, the operator can deploy a new service in a 274 new network slice without worry about affecting the production 275 network's service. 277 FlowVisor is only one example for network slicing and network 278 virtualization. Furthermore, how to combine network slicing and 279 mobility management in the cloud based mobile core architecture is an 280 important topic need to be further studied. 282 5.4. Network auto-configuration 284 Network auto-configuration is a way to simplify the network operation 285 and reduce the network OPEX. In an ideal case, the mobile access 286 network should be registered automatically to the mobile core network 287 without manual configuration. IETF has defined CAPWAP for wireless 288 access point control and configuration. However, how to keep the 289 auto-configuration protocol compatible with existing mobile network 290 protocols need to be further studied. 292 6. Open API 294 The cloud based mobile core network can provide open API to the 295 service provider and other third party developers. This feature will 296 faciliate the developers to use the ability of the network. 298 7. Conclusion 300 This document discusses the motivation and challenges of the cloud 301 based mobile core network. There are several key points that need to 302 be further studied by the community. 304 1. Innovative mobility management scheme that fulfils with the 305 distributed data plane traffic routing and network slicing 306 requirement. 308 2. Network slicing. FlowVisor is one example of network slicing 309 technology that based on openflow. Further study should be made 310 regarding how to virtualize the mobile core network. 312 3. Network auto-configuration. How to define a mobile network auto- 313 configuration protocol while keeps the backward compatibility with 314 current mobile network need to be further studied. 316 8. Security Considerations 318 Security should be studied when design the cloud based mobile core 319 network. 321 9. IANA Considerations 323 10. Contributors 325 11. Acknowledgements 326 12. Normative References 328 [FlowVisor] 329 "FlowVisor: A Network Virtualization Layer", 2009. 331 [IEEE-802.11.2012] 332 March 2012. 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, March 1997. 337 [openflow] 338 "OpenFlow Switch Specification", 2012. 340 Authors' Addresses 342 Dapeng Liu 343 China Mobile 344 No.32 Xuanwumen West Street 345 Beijing 100053 346 China 348 Email: liudapeng@chinamobile.com 350 Kok-kiong Yap 351 Google 353 Email: yapkke@gmail.com 355 Charles E. Perkins 356 Huawei 358 Email: charliep@computer.org 360 Tao Sun 361 China Mobile 362 No.32 Xuanwumen West Street 363 Beijing 100053 364 China 366 Email: suntao@chinamobile.com 367 Hui Deng 368 China Mobile 369 No.32 Xuanwumen West Street 370 Beijing 100053 371 China 373 Email: denghui@chinamobile.com