idnits 2.17.1 draft-wakikawa-req-mobile-cp-separation-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 07, 2013) is 3822 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.vandevelde-idr-remote-next-hop' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC5512' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-softwire-map' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'I-D.savolainen-stateless-pd' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'I-D.yokota-dmm-scenario' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC6333' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'RFC6459' is defined on line 456, but no explicit reference was found in the text == Unused Reference: 'RFC6877' is defined on line 461, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-vandevelde-idr-remote-next-hop-03 ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-07 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INT Area R. Wakikawa 3 Internet-Draft Softbank Mobile 4 Intended status: Informational S. Matsushima 5 Expires: May 11, 2014 Softbank Telecom 6 B. Patil 7 Individual 8 B. Chen 9 Sprint 10 D. Joachimpillai(DJ) 11 Verizon Labs 12 H. Deng 13 China Mobile 14 November 07, 2013 16 Requirements and use cases for separating control and user planes in 17 mobile network architectures 18 draft-wakikawa-req-mobile-cp-separation-00 20 Abstract 22 Virtualization and cloud services have evolved significantly in the 23 last few years. Additionally trends in virtualization like Network 24 Function Virtualiztion and Softward Defined Networking are bound to 25 have implications to mobile network architectures of cellular systems 26 (3G/4G), WiFi and others. IETF has developed a number of mobility 27 protocols that are used in the industry today. Mobility network 28 architectures continue to evolve and it is likely that they will 29 embrace virtualization and cloud services trends as well. The IETF 30 can play a role in defining the mobility protocols that support 31 architectures which leverage virtualization and cloud technologies. 32 This document captures several use cases and requirements for a 33 virtualized mobile network architecture. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 11, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Motivation: Virtualization . . . . . . . . . . . . . . . . . 3 70 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Potential of New Mobile Architecture . . . . . . . . . . . . 6 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 8.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 The concept of User- and control- plane are well-known in networking. 83 Especially, the 3rd Generation Partnership Project (3GPP) employs 84 this concept in their mobile network architecture. These two planes 85 are conceptually decoupled in the 3GPP architecture. 87 In the past, IETF has developed tunnel based mechanisms for mobile 88 nodes such as Mobile IPv6 [RFC6275][RFC5555], Proxy Mobile IPv6 89 [RFC5213][RFC5844] and NEMO [RFC3963]. All the mobility protocols 90 discussed in the past are summarized in [RFC6301]. Similarly, 3GPP 91 has developed another tunnel protocol called GPRS Tunneling Protocol 92 (GTP). These tunnel- based protocol creates a data path for a mobile 93 node between the mobile node and an anchor point (s). There is a 94 case where an access router terminates a tunnel instead of a mobile 95 node (ex. Proxy Mobile IP). In the 3GPP architecture, a tunnel is 96 established between Serving Gateway and PDN Gateway per a mobile node 97 by either Proxy Mobile IPv6 or GTP (at s5 interface). The signaling 98 like Binding Update and user's packets are routed along a same path 99 in Evolved Packet Core (EPC). Therefore, the control and the user 100 planes of these mobility protocols are tightly related and cannot be 101 clearly decoupled, although there are several implementation efforts. 103 2. Motivation: Virtualization 105 The recent innovations and trends of Software Defined Networking 106 (SDN) and NFV (Network Function Virtualization) promotes to decouple 107 User and Control planes. SDN consists of two entities named a 108 controller and a vSwitch. The controller is responsible for 109 signaling exchange and the vSwitches handles data forwarding based on 110 the states fed by the controller. There are various controller that 111 user can program vSwitch dynamically to adjust and optimize networks 112 on the fly. Controller are often implemented with Virtualization 113 technology and run as a software on hypervisors. On the other hand, 114 NFV is discussed at the ETSI NFV ISG and is introduced in 115 [NFV-WHITEPAPER]. Operators build its network with variety of 116 proprietary hardware appliances today. If they can get rid of these 117 physical appliances and could shift to a cloud-based service, they 118 will have a lot of benefits, specially CAPEX and OPEX reduction. 119 This document assumes that SDN and NFV will impact our daily network 120 operations and managements. Expected network functions are Mobility 121 Management Entity (MME), Serving Gateway (SGW) PDN Gateway(PGW), etc. 122 With NFV, EPC can be operated onto servers/hyper-visors. We name it 123 virtualized-EPC (vEPC) in this document. NFV will bring networking 124 functions currently run on dedicated hardware onto a cloud network. 126 It is good timing to re-visit the basic architecture of mobility 127 system. Although the tunneling-based protocols are sustaining mobile 128 traffic, SDN and NFV can introduce a new architecture that truly 129 decoupled user- and control planes. This document summarizes 130 requirements of the new architecture and its potential use cases. 132 Benefits of NFV are summarized below. Detailed explanation can be 133 found in [NFV-WHITEPAPER]). As a potential drawback, today's eco- 134 system of mobile appliances might be affected. However, we believe 135 there are various approaches to enhance current eco-system and 136 migrate to new mobility approach. 138 o [Flexible Network Operations]: The control functions are no longer 139 in appliances deployed widely in operator's network and can be run 140 at hypervisor (cloud). It is easier to add and/ or delete 141 functions from the services, because no physical construction is 142 needed. Network operations will be much simpler and easier 143 because complications of today's network are pushed to NFV (i.e. 144 hypervisor). 146 o [Flexible Resource Managements]: The network functions can be run 147 on hypervisor and are now less dependent on proprietary hardware. 148 Adding additional resources is easier in hypervisor, while adding 149 or replacing physical appliances require installation, 150 construction, configuration, and even migration plan without 151 service cutoff. NFV also brings multi-tenancy and allows a single 152 platform for different services and users. The operator can 153 optimize resources and costs to share a NFV platform for multiple 154 customers (ex. MVNO customers) and services (ex. multiple APNs). 156 o [Faster Speed of Time to Market]: When an operator wants a new 157 function to its network and services, the operator needs to 158 negotiate appliance vendors to implement the new functions or to 159 find alternative equipment supporting the new function. It takes 160 a longer time to convince the vendors, or to replace existing 161 hardware. However, if functions can be implemented as a software, 162 it is much faster to implement the functions on NFV. Even the 163 operator may implement them and try the new functions by 164 themselves. Field trial is also getting easier because of no 165 physical installation or replacement. You may turn on a new 166 function in NFV and observe how the new function behaves in your 167 network. NFV can save preparation time and tuning time of the new 168 function. 170 o [Cost Optimization]: Last but not least, Cost is the most 171 important motivation for operators to realize NFV. Operators can 172 remove many of proprietary appliances from its network and replace 173 them with industry standard servers, switches and routers. In 174 addition, it is easy to scale up and down operator's services so 175 that resources can be always tuned to the size of services. In 176 addition, operational costs led by any physical hardware such as 177 power supply, maintenance, installation, construction and 178 replacement can be minimized or even removed. The network design 179 can be simpler, because complicated functions could be handled by 180 NFV. That simple operation may enable automatic configurations 181 and prevent unnecessary trouble-shooting. As a result, CAPEX and 182 OPEX can be always optimized and lowered. 184 3. Requirements 186 What is a role of IETF to discuss mobility architecture? IETF is not 187 the right place to discuss, for instance, how to achieve 188 virtualization or NFV. An important IETF activity must be to 189 decouple the control- and user- planes of mobility protocols. IETF 190 also should design and standardize protocols as building block of the 191 new mobility architecture. In doing so, the new mobility solutions 192 can be easily designed and implemented with interoperability across 193 multiple vendors and platforms. Otherwise, NFV solutions can be 194 easily fragmented due to many proprietary solutions for the protocol 195 separations. As stated in [NFV-WHITEPAPER], interoperability is 196 highly important. 198 This section lists up requirements of the new mobility architecture. 200 Separation of Control- and User- Planes 201 Due to tight relationship of the control- and user- planes in 202 today's mobile architecture, resource increase is always 203 provisioned to both planes at once. It prevents flexible 204 resource arrangement and introduces high capital investment 205 and over-provisioned resources to one of planes. If NFV is 206 deployed, it is expected that computing resources can be 207 independently allocated to the control planes in a flexible 208 manner. 210 Flat Design for Distributed Operation 211 Today's 3GPP architecture introduces PDN gateway (PGW) as a 212 gateway to external networks like the Internet. PGW manages 213 all traffic from and to UEs and could be a bottleneck and 214 single point of failure of network connectivity. In 215 addition, due to recent rapid traffic increase, it is 216 important to perform traffic engineering and to offload 217 traffic to multiple locations (ex. SGW, PGW, eNodeB). For 218 enhancements of traffic engineering capability, more flat 219 design with multiple gateways is expected so that traffic can 220 be distributed to all these gateways. There were proposals 221 how to enable flat design to (Proxy) Mobile IP such as 222 [I-D.wakikawa-mext-haha-interop2008] in IETF. Distributed 223 Mobility Management (DMM) Working Group has also discussed 224 how to extend Mobile IP-based solutions to support traffic 225 distribution in an optimal way by removing centrally deployed 226 anchors that is like a Home Agent. 228 Stateless in User Plane 229 Ultimate goal of vEPC is to remove all mobility specific 230 states from the forwarding nodes in the user-plane of vEPC. 231 If we succeed in this, industry standard routers and switches 232 can be used to forward mobile nodes traffic in the user plane 233 of vEPC. A mobile node's specific states are kept in both an 234 IP header of the mobile node's packets and a routing entry of 235 the mobile node. 237 Shared backbone for fixed and mobile convergence 238 If User plane focus only on packet forwarding, the user plane 239 can be shared for both fixed and mobile services. Most of 240 mobile operators have wired services and could share the 241 backbone. With recent state-of-arts of routing technology, 242 it is reasonable to assume that routing system can 243 dynamically propagate networking state information available 244 on Control plane. Thus, both mobile and fixed packets are 245 routed only on the user plane. No special treatment is 246 needed for packets of mobile nodes and vice verse. 248 Packet Processing Support: DPI, Accounting, Firewall 249 In the today's mobile system like EPC-based cellular system, 250 mobile packets are inspected and examined for various 251 services and accounting such as DPI, FireWall, NAT, AAA, and 252 so on . This is one of the reason that all packets are 253 processed in the control plane. However, these L4-L7 254 services are also expected to be virtualized along with NFV 255 and SDN trends. In IETF, there is an effort of SFC (Service 256 Function Chaining) to discuss this topics. A new mechanism 257 or trigger to provide these network services to mobile 258 packets are needed on the user plane. 260 4. Use Cases 262 Use cases of the new mobility architecture are networks with local 263 mobility support. Global mobility is not target of our activity. 264 Global and local mobility are defined in [RFC3753]. Typical examples 265 of local mobility network are cellular network (EPC: Evolved Packet 266 Core), WiMAX, service provider WiFi and so on. Our use cases should 267 meet the following characteristics. 269 o A same provider conceptually provide access network (i.e. user 270 plane) and mobility support (i.e. control plane). 272 o A provider should be able to setup a route for the mobile node 273 dynamically on the user plane according to the status on control 274 plane. 276 Network access and mobility management are conceptually provided by a 277 same provider. That is to say that a mobile ndoe only moves in the 278 provider's network, i.e. local mobility. 280 5. Potential of New Mobile Architecture 282 [RFC6301] investigates the mobile architecture and classifies into 2 283 approaches such as Routing-Based and Mapping-Based Approaches, 284 described in Figure 1. Both approaches do not take account of 285 control and user planes separation. 287 o Routing-based approach: Mobility is provided by dynamic routing. 288 A mobile node keeps its IP address regardless of its point of 289 attachments. Dynamic routing mechanism keeps track of a mobile 290 node's movements and updates routing tables so as to support 291 continuous reachability. 293 o Mapping-based approach: Mobility is achieved by a mapping between 294 mobile node's identifier and dynamically assigned IP address at an 295 attachment point. This mapping is managed in networks and updated 296 every time a mobile node moves. Packets are first routed to the 297 node managing the mapping and redirected to a mobile node 298 according to the mapping. This redirection is often implemented 299 by a tunneling mechanism. Mobile IP is the most famous protocol 300 of this approach. 302 _+---+_ _ _+---+_ _ _ _+------------+_ _ _ 303 / | M | | L | / / | | / 304 Control / | A | | M | / / | | / 305 Plane /_ _| G |_ _ _| A |__/ /_ _| Routing |__/ 306 | / | | / | | Network | 307 | S | | P | vs. | | 308 _| G |_ _ _| G |_ _ _ _| |_ _ _ 309 / | W | | W | / / | | / 310 User-plane / +---+ +---+ / / +------------+ / 311 /_ _ _ _ _ _ _ _ _ _ / /_ _ _ _ _ _ _ _ __ / 312 Mapping-based approach Routing-based approach 314 2 approaches of Mobile Architecture 316 Figure 1 318 As we mentioned earlier, the most of mobility protocols deployed 319 today uses the mapping-based approach. There is a good reason of 320 adapting mapping and tunneling in mobility protocols , that is global 321 mobility and signaling. A mobile node should be able to move 322 anywhere on the Internet and be reachable from anyone on the 323 Internet. There were routing based global mobility solutions like 324 Boeing global mobility [Boeing-BGP] and WINMO [RFC6301]. In these 325 proposals, BGP was used to propagate forwarding information of mobile 326 nodes to the Internet. Whenever a mobile node changes its point of 327 attachment, the route must be updated. Due to scalability and 328 stability issues of the Internet, this solution was not recommended 329 by IETF [Boeing-BGP]. However, as Boeing showed, it is doable to 330 support global mobility by using BGP routing update. If scalability 331 is not your concern, a routing based approach becomes a candidate of 332 the mobility solution. 334 While global mobility is important, today's "reality" is that your 335 cell phones (i.e. UE or mobile node) are moving just within an 336 operator's network and fully controlled in your local managed domain 337 (ex. EPC). If mobility support can be limited within an operator, 338 we believe a routing based approach is feasible and practical for 339 today's mobile system. 341 If the concept of NFV and SDN were realized and deployed, we could 342 have strong tools to split control and user planes. Figure 2 shows a 343 possibility that nodes on the Control plane are virtualized in 344 generic cloud environment, however user packets won't go through 345 those virtualized nodes. Instead of dedicated proprietary equipment 346 like MAG and LMA to process signaling of mobility support, 347 virtualized software running on hypervisor will take care of 348 signaling on the control plane. After signaling completion, the 349 status is reflected as forwarding information to switches and routes 350 in the user plane. The reflection can be implemented by routing or 351 SDN solutions. As a result, packets to and from mobile nodes are no 352 longer tunneled between MAG and LMA but they are directly routed on 353 the user plane. Figure 2 could relax hyper-visor and data- path 354 capacity requirements. The user plane will be agnostic from sessions 355 and bearers states, of which are generated and maintained in the 356 Control-plane. It forwards the packets based on a destination 357 address of packets and routing entries injected by the control plane. 359 _+---+_ _ _+---+_ _ _ 360 / | M | | L | / 361 Control-plane / | A | | M | NFV 362 /_ _| G |_ _ _| A |__/ 363 +---+ +---+ 364 +-------------+ 365 _| Routing |_ _ _ 366 / | Network | / 367 User-plane / +-------------+ Routing/SDN 368 /_ _ _ _ _ _ _ _ _ _ _/ 370 New Mobility architecture 372 Figure 2 374 6. IANA Considerations 376 This memo includes no request to IANA. 378 7. Security Considerations 380 There are no security considerations specific to this document at 381 this moment. 383 8. References 385 8.1. Normative References 387 [I-D.vandevelde-idr-remote-next-hop] 388 Velde, G., Patel, K., Rao, D., Raszuk, R., and R. Bush, 389 "BGP Remote-Next-Hop", draft-vandevelde-idr-remote-next- 390 hop-03 (work in progress), October 2012. 392 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 393 Subsequent Address Family Identifier (SAFI) and the BGP 394 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 396 8.2. Informative References 398 [Boeing-BGP] 399 Andrew, ., "Global IP Network Mobility using Border 400 Gateway Protocol (BGP)", IAB Plenary IAB Plenary of IETF 401 62nd, March 2005. 403 [I-D.ietf-softwire-map] 404 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 405 Murakami, T., and T. Taylor, "Mapping of Address and Port 406 with Encapsulation (MAP)", draft-ietf-softwire-map-07 407 (work in progress), May 2013. 409 [I-D.savolainen-stateless-pd] 410 Savolainen, T. and J. Korhonen, "Stateless IPv6 Prefix 411 Delegation for IPv6 enabled networks", draft-savolainen- 412 stateless-pd-01 (work in progress), February 2010. 414 [I-D.wakikawa-mext-haha-interop2008] 415 Wakikawa, R., Shima, K., and N. Shigechika, "The Global 416 HAHA Operation at the Interop Tokyo 2008", draft-wakikawa- 417 mext-haha-interop2008-00 (work in progress), July 2008. 419 [I-D.yokota-dmm-scenario] 420 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 421 scenarios for Distributed Mobility Management", draft- 422 yokota-dmm-scenario-00 (work in progress), October 2010. 424 [NFV-WHITEPAPER] 425 Network Operators, ., "Network Functions Virtualization, 426 An Introduction, Benefits, Enablers, Challenges and Call 427 for Action", SDN and OpenFlow SDN and OpenFlow World 428 Congress, October 2012. 430 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 431 RFC 3753, June 2004. 433 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 434 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 435 RFC 3963, January 2005. 437 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 438 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 440 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 441 Routers", RFC 5555, June 2009. 443 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 444 Mobile IPv6", RFC 5844, May 2010. 446 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 447 in IPv6", RFC 6275, July 2011. 449 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 450 Support in the Internet", RFC 6301, July 2011. 452 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 453 Stack Lite Broadband Deployments Following IPv4 454 Exhaustion", RFC 6333, August 2011. 456 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 457 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 458 Partnership Project (3GPP) Evolved Packet System (EPS)", 459 RFC 6459, January 2012. 461 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 462 Combination of Stateful and Stateless Translation", RFC 463 6877, April 2013. 465 Authors' Addresses 467 Ryuji Wakikawa 468 Softbank Mobile 469 1-9-1,Higashi-Shimbashi,Minato-Ku 470 Tokyo 105-7322 471 Japan 473 Email: ryuji.wakikawa@gmail.com 474 Satoru Matsushima 475 Softbank Telecom 476 1-9-1,Higashi-Shimbashi,Minato-Ku 477 Tokyo 105-7322 478 Japan 480 Email: satoru.matsushima@g.softbank.co.jp 482 Basavaraj Patil 483 Individual 485 Email: bpatil1@gmail.com 487 Bonnie Chen 488 Sprint 489 6220 Sprint Parkway 490 Overland Park, KS 66251 491 USA 493 Email: Bonnie.Chen@Sprint.com 495 Damascene Joachimpillai(DJ) 496 Verizon Labs 498 Email: damascene.joachimpillai@verizon.com 500 Hui Deng 501 China Mobile 502 53A, Xibianmennei Ave., Xuanwu District 503 Beijing 100053 504 China 506 Email: denghui02@gmail.com