idnits 2.17.1 draft-matsushima-stateless-uplane-vepc-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 == Line 688 has weird spacing: '... type fun...' -- The document date (July 10, 2013) is 3944 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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 (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Group S. Matsushima 3 Internet-Draft Softbank Telecom 4 Intended status: Informational R. Wakikawa 5 Expires: January 11, 2014 Softbank Mobile 6 July 10, 2013 8 Stateless user-plane architecture for virtualized EPC (vEPC) 9 draft-matsushima-stateless-uplane-vepc-00 11 Abstract 13 We envision a new mobile architecture for the future Evolved Packet 14 Core (EPC). The new architecture is designed to support the 15 virtualization scheme called NFV (Network Function Virtualization). 16 In our architecture, the user plane of EPC is decoupled from the 17 control-plane and uses routing information to forward packets of 18 mobile nodes. Although the EPC control plane will run on hypervisor, 19 our proposal does not modify the signaling of the EPC control plane. 20 The benefits of our architecture are 1) scalability, 2) flexibility 21 and 3) Manageability. How to run the EPC control plane on NFV is out 22 of our focus in this document. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 11, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. The Benefits of NFV . . . . . . . . . . . . . . . . . . . 3 60 2. Motivations and Requirements, - Why IETF? - . . . . . . . . . 4 61 2.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Stateless user-plane architecture for virtualized EPC . . . 7 64 3.1. Architecture Overview . . . . . . . . . . . . . . . . . . 7 65 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9 66 3.3. Control-plane awareness of stateless user-plane . . . . . 13 67 3.4. Routing mechanism . . . . . . . . . . . . . . . . . . . . 13 68 3.5. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . 16 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 73 6.2. Informative References . . . . . . . . . . . . . . . . . 17 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction 78 3GPP introduces Evolved Packet Core (EPC) that is fully IP based 79 mobile system for LTE and -advanced in their Release-8 specification 80 and beyond. Operators are now deploying EPC for LTE services and 81 encounter rapid LTE traffic growth. There are various activities to 82 offload mobile traffic in 3GPP and IETF such as LIPA, SIPTO and DMM. 83 The concept is similar that traffic of OTT (Over The Top) application 84 is offloaded at entity that is closer to the mobile node (ex. eNodeB 85 or closer anchor). 87 Likewise, overload of signaling (control plane) is also increasing 88 day by day. Network operators expect recent innovation and trends of 89 NFV (Network Function Virtualization) to solve this overloaded 90 control plane. NFV is discussed at the ETSI NFV ISG and is 91 introduced in [NFV-WHITEPAPER]. Mobile operator's network is built 92 with variety of proprietary hardware appliances today. If we can get 93 rid of these physical appliances and could shift to a cloud-based 94 service, we will have a lot of benefits explained in the next 95 section. This document assumes that NFV will push networking 96 functions currently run on dedicated hardwares onto a cloud network. 98 Expected network functions are Mobility Management Entity (MME), 99 Serving Gateway (SGW) PDN Gateway(PGW), etc. With NFV, EPC can be 100 operated onto servers/hyper-visors. We name it virtualized-EPC 101 (vEPC) in this document. 103 This document uses a lot of 3GPP specific terms. These terms can be 104 found mostly at [RFC6459]. 106 1.1. The Benefits of NFV 108 This section briefly explains the benefits of NFV. The detailed 109 benefits can be found in [NFV-WHITEPAPER]. Although today's eco- 110 system of EPC appliances might be affected, we believe there are 111 various approaches to enhance current eco-system and migrate to new 112 NFV approaches. For example, operators could pay monthly recurring 113 charges for the NFV services and operations to vendors, instead of 114 one-time purchase and a little maintenance cost. 116 o [Flexible Network Operations]: The control functions of EPC are no 117 longer in appliances deployed widely in operator's network and can 118 be run at hypervisor (cloud). It is easier to add and/ or delete 119 functions from the services, because no physical construction is 120 needed. Network operations will be much simpler and easier 121 because complications of today's network are pushed to NFV (i.e. 122 hypervisor). 124 o [Flexible Resource Managements]: The EPC functions can be run on 125 hypervisor and are now less dependent on proprietary hardwares. 126 Adding additional resources is easier in hypervisor, while adding 127 or replacing physical appliances require installation, 128 construction, configuration, and even migration plan without 129 service cutoff. A hypervisor can be also shared across various 130 functions such as PGW, SGW and MME. NFV also brings multi-tenancy 131 and allows a single platform for different services and users. 132 The operator can optimize resources and costs to share a NFV 133 platform for multiple customers (ex. MVNO customers) and services 134 (ex. multiple APNs). 136 o [Faster Speed of Time to Market]: When an operator wants a new 137 function to its network and services, the operator needs to 138 negotiate appliance vendors to implement the new functions or to 139 find alternative equipment supporting the new function. It takes 140 a longer time to convince the vendors, or to replace existing 141 hardwares. However, if functions can be implemented as a 142 software, it is much faster to implement the functions on NFV. 143 Even the operator may implement them and try the new functions by 144 themselves. Field trial is also getting easier because of no 145 physical installation or replacement. You may turn on a new 146 function in NFV and observe how the new function behaves in your 147 network. NFV can save preparation time and tuning time of the new 148 function. 150 o [Cost Optimization]: Last but not least, Cost is the most 151 important motivation for operators to realize NFV. Operators can 152 remove many of proprietary appliances from its network and replace 153 them with industry standard servers, switches and routers. In 154 addition, it is easy to scale up and down operator's services so 155 that resources can be always tuned to the size of services. In 156 addition, operational costs led by any physical hardware such as 157 power supply, maintenance, installation, construction and 158 replacement can be minimized or even removed. The network design 159 can be simpler, because complicated functions could be handled by 160 NFV. That simple operation may enable automatic configurations 161 and prevent unnecessary trouble-shooting. As a result, CAPEX and 162 OPEX can be always optimized and lowered. 164 2. Motivations and Requirements, - Why IETF? - 166 2.1. Motivations 168 What is a role of IETF to realize vEPC in the future? IETF is not 169 the right place to discuss, for instance, how to run MME on 170 hypervisor. An important IETF activity must be to decouple the 171 control- and user- planes of mobility protocols used in EPC. In 172 doing so, NFV-enabled solutions can be easily designed and 173 implemented with interoperability across multiple vendors and 174 platforms. Otherwise, NFV solutions can be easily fragmented due to 175 many proprietary solutions for the protocol separations. As stated 176 in [NFV-WHITEPAPER], interoperability is highly important. 178 In the past, IETF has developed tunnel based mechanisms for mobile 179 nodes such as Mobile IPv6 [RFC6275][RFC5555], Proxy Mobile IPv6 180 [RFC5213][RFC5844] and NEMO [RFC3963]. Similarly, 3GPP has developed 181 tunnel protocols called GPRS Tunneling Protocol (GTP). These tunnel- 182 based protocols establish a data path for a mobile node between the 183 mobile node and an anchor point (s). There is a case where an access 184 router terminates a tunnel instead of a mobile node (ex. Proxy 185 Mobile IP). In 3GPP, a tunnel is established between SGW and PGW per 186 a mobile node by either Proxy Mobile IPv6 or GTP. The control and 187 the user planes of these mobility protocols are tightly related and 188 cannot be decoupled. The signaling like Binding Update and user's 189 packets are routed along a same path in EPC. It might be necessary 190 to extend these mobility protocols for the user- and control- planes 191 separation. The protocol separation of Mobile IP is discussed in 192 [I-D.yokota-dmm-scenario]. 194 Alternatively, if vEPC was realized, we should have an opportunity to 195 re-visit the basic architecture of mobility system. Instead of 196 tunneling packets on today's EPC, why can't we just route packets to 197 a mobile node? Since a role of the user plane is "routing", BGP and 198 other routing protocols could be used to forward UE's traffic. This 199 document introduces a BGP-based solution. Software Defined 200 Networking (SDN) can be an alternative solution. Open Flow and other 201 relevant protocols can setup the forward path dynamically according 202 to UE's states available in the control plane. 204 We have to remember that there is a good reason of adapting tunneling 205 in Mobile IP based solutions, that is global mobility. A mobile node 206 should be able to move anywhere on the Internet and be reachable from 207 anyone on the Internet. There were routing based global mobility 208 solutions like Boeing global mobility [Boeing-BGP] and WINMO 209 [RFC6301]. In these proposals, BGP was used to propagate forwarding 210 information of mobile nodes to the Internet. Whenever a mobile node 211 changes its point of attachment, the route must be updated. Due to 212 scalability and stability issues of the Internet, this solution was 213 not recommended by IETF [Boeing-BGP]. However, as Boeing showed, it 214 is doable to support global mobility by using BGP routing update. If 215 scalability is not your concern, a routing based approach becomes a 216 candidate of the mobility solution. 218 While global mobility is important, the "reality" is that your cell 219 phones (i.e. UE/mobile node) are moving just within an operator's 220 network and fully controlled in your local EPC. If mobility is 221 limited within an operator, we believe a routing based approach is 222 feasible and practical for today's mobile system. Instead of 223 dedicated proprietary equipment like SGW and PGW to manage a tunnel 224 path for a mobile node, multiple industry standard routers and 225 switches are configured in the user plane. These switches and 226 routers receive mobile nodes' forwarding information from the control 227 plane of vEPC by routing update. 229 2.2. Requirements 231 Requirements of our stateless user plane for vEPC are followings. 233 NFV Support 234 The future EPC architecture must support NFV capability. The 235 control plane of EPC operated on NFV framework is named 236 "virtualized EPC (vEPC)" in this document. The control plane 237 of vEPC should keep backward compatibility with the today's 238 EPC's control plane. It means this document doesn't modify 239 the control plane at all. It only assumes software-based 240 MME, SGW, and PGW run on hypervisor. 242 Separation of Control- and User- Planes 243 Due to tight relationship of the control- and user- planes in 244 today's EPC, resource increase is always provisioned to both 245 planes at once. It prevents flexible resource arrangement 246 and introduces high capital investment and over-provisioned 247 resources to one of planes. If NFV is deployed, it is 248 expected that computing resources can be independently 249 allocated to the control planes of the vEPC in a flexible 250 manner. 252 _+---+_ _ _+---+_ _ _ 253 EPC / | S | | P | / 254 Control-plane / | G | | G | / 255 /_ _| W |_ _ _| W |__/ 256 +---+ +---+ | | | | 257 | | | e | | | | | 258 | U | | N | _| |_ _ _| |_ _ _ 259 EPC | E | | B | / | | | | / 260 User-plane +---+ +---+ / +---+ +---+ / 261 /_ _ _Existing EPC_ _/ 263 _+---+_ _ _+---+_ _ _ 264 vEPC / | S | | P | / 265 Control-plane / | G | | G | / 266 /_ _| W |_ _ _| W |__/ 267 | | | | 268 +---+ +---+ +---+ +---+ 269 | | | e | +----------+ 270 | U | | N | _|IP Routing|_ _ _ 271 Stateless | E | | B | / | Network | / 272 User-plane +---+ +---+ / +----------+ / 273 /_ _ _ _ _ _ _ _ _ / 275 NFV enabled EPC architecture 277 Figure 1 279 Figure 1 shows a possibility that the entities of EPC 280 Control- plane are virtualized in generic cloud environment, 281 however user packets won't go through those virtualized EPC 282 nodes. Decoupling User-plane from the Control-plane entities 283 will be made virtualized Control-plane nodes relax hyper- 284 visor data- path capacity requirements. On the other hand, 285 decoupled User-plane into IP routing network will be agnostic 286 from sessions and bearers states, of which are generated and 287 maintained in the Control-plane. In terms of IP routing, 288 forwarding packets through the networks is based on the 289 destination address of the packets evaluated with network 290 reachable information in the routing table that accommodated 291 in the routing nodes. To forward EPC User-plane packets 292 correctly, those states must be indicated by network 293 reachable information. 295 Flat Design for Distributed Operation 296 Today's 3GPP architecture introduces PDN gateway (PGW) as a 297 gateway to external networks like the Internet. PGW manages 298 all traffic from and to UEs and could be a bottleneck and 299 single point of failure of network connectivity. In 300 addition, due to recent rapid traffic increase, it is 301 important to perform traffic engineering and to offload 302 traffic to multiple locations (ex. SGW, PGW, eNodeB). For 303 enhancements of traffic engineering capability, more flat 304 design with multiple gateways is expected so that traffic can 305 be distributed to all these gateways. There were proposals 306 how to enable flat design to (Proxy) Mobile IP such as 307 [I-D.wakikawa-mext-haha-interop2008] in IETF. Distributed 308 Mobility Management (DMM) Working Group has also discussed 309 how to extend Mobile IP-based solutions to support traffic 310 distribution in an optimal way by removing centrally deployed 311 anchors that is like a Home Agent. 313 Stateless in User Plane 314 Ultimate goal of vEPC is to remove all mobility specific 315 states from the forwarding nodes in the user-plane of vEPC. 316 If we succeed in this, industry standard routers and switches 317 can be used to forward mobile nodes traffic in the user plane 318 of vEPC. A mobile node's specific states are kept in both an 319 IP header of the mobile node's packets and a routing entry of 320 the mobile node. The detail is described in Section 3.2 322 3. Stateless user-plane architecture for virtualized EPC 324 This section explains our solution that is the stateless user-plane 325 architecture for vEPC. This solution is basically a combination of 326 existing protocols defined in IETF. A minor extension might be 327 needed but it should be easily addressed in IETF. We first introduce 328 our architecture and then protocol overview. 330 3.1. Architecture Overview 331 Figure 2 shows the user plane of the current EPC architecture. A 332 tunnel is established between SGW and PGW by either Proxy Mobile IP 333 or GTP. PGW is an anchor point of UE for incoming packets. All the 334 packet destined to UE is routed first to PGW. The UE's packets are 335 intercepted by PGW and tunneled to SGW. SGW then forwards the packet 336 to UE via access points (i.e. eNodeB) over Radio Area Network (RAN). 338 .--. 339 _( `)_ 340 _( `) 341 +---+ +---+ ( EPC-NW ) +---+ 342 [UE]~~~~|RAN|====|SGW|===================|PGW| -> the Internet 343 +---+ +---+ `--(______)---' +---+ 344 <--------Tunneling------> 346 ~~~ Wireless Link 347 === GTP Tunnel (PMIP tunnel) 348 --- IP link 350 User plane of the current EPC 352 Figure 2 354 Figure 3 is our proposed user plane of vEPC. The control plane is 355 not shown in this figure. 357 [EPC-E anycast address] 358 | .--. 359 | _( `)_ 360 | +---+ _( `) 361 +---+ \ |EPC| ( IPv6 Core ) +---+ 362 [UE]~~~~|RAN|====| -E|-( ` NW )-|RTR| --> the Internet 363 +---+ +---+ ( ` ) ) +---+ 364 (eNodeB) `--(_____)--' 365 <--------Routing--------> 367 User plane of vEPC 369 Figure 3 371 We introduce two new entities such as 372 EPC Edge Router (EPC-E) 373 EPC-E is located at the same place of today's SGW and terminates 374 GTP tunnel established with eNodeB (RAN). EPC-E supports the user 375 plane functions of SGW and PGW. EPC-E is configured an anycast 376 address to the network interface facing to eNodeB. The eNodeB 377 establishes a GTP tunnel per UE with this anycast address. Thanks 378 for anycast address, UE's traffic forwarded by eNodeB is always 379 routed to the closest EPC-E of UE. EPC-E is a router and 380 maintains routing information of every UE that is notified by the 381 control plane. Detail of routing mechanism can be found in 382 Section 3.4. 384 Router (RTR) 385 It is a regular IP router. The control plane of vEPC distributes 386 routing information of every UE by a routing protocol like BGP. 387 Therefore any additional protocols other than routing protocols 388 are not needed for RTR. Multiple RTRs can be configured anywhere 389 in the user plane of vEPC. RTRs announce UE's routing information 390 to the external network (ex. The Internet). 392 As you see in Figure 3, we omit a tunneling mechanism originally 393 established between SGW and PGW for routing UE's packets. By 394 removing this tunnel, UE's packets are forwarded to and from the 395 Internet according to routing tables on routers in the core network. 396 Note that, although we remove the tunnel for UE's traffic, the 397 control-plane signaling stays same. If Proxy Mobile IP is used for 398 this tunnel, Proxy Binding Update and Acknowledgment are exchanged 399 between PGW and SGW that are managed by NFV on servers/hyper-visor. 400 Instead of a tunnel setup, states created by Proxy Mobile IP are 401 distributed to all routing entities (EPC-E and RTR) by a routing 402 protocol. From the user plane point of view, these states are just 403 seen as routing entries. EPC-E and RTR are not involved in any 404 signaling of the control plane. The control plane just injects 405 routing information to EPC-E and RTR to setup routing paths to and 406 from UEs. 408 Although this architecture just uses IPv6 core network, it supports 409 both IPv4 and IPv6 packets. The detailed operation of IPv4 support 410 will be discussed in Section 3.5. 412 A mobile node can still use a global mobility solution like Mobile IP 413 when it moves out an operator's network. We should keep backward 414 compatibility for the control plane of EPC and should be able to fall 415 back to the tunneling based packet forwarding for non-operator's 416 network and roaming scenarios. 418 3.2. Protocol Overview 419 This section gives an example of protocols used for vEPC. Figure 5 420 is the procedure of the PDN connection setup in vEPC. This figure is 421 copied from the section 3 of [RFC6459]. All the steps from (1) to 422 (13) are same as the original except for NFV-based MME, SGW, PGW, 423 HSS, and AAA. 425 The vEPC introduces two new steps, (14) and (15), to setup paths in 426 the user-plane after finishing all the signaling on the control- 427 plane. (16) and (17) are the steps to assign IP address to the mobile 428 node. 430 In (14), vEPC advertises a routing information of UE whose next hop 431 is set to GTP tunnel between eNodeB and UE in RAN. To do this, we 432 will introduce two existing solutions as the key to build vEPC and 433 also show potential modification required for vEPC. 435 o "Stateless IPv6 Prefix Delegation for IPv6 enabled networks" 436 [I-D.savolainen-stateless-pd] can be used as the algorithm to 437 generate UE's prefix. 439 In the case of an UE's prefix length is equal, or shorter than /64, 440 the generated prefix is consisted as follow: 442 | n bits | o bits (=< 16)|64-n-o bits| 443 +---------------------------+---------------+-----------+ 444 | PDN Prefix | TEID | subnet ID | 445 +---------------------------+---------------+-----------+ 446 <---------------------------64bits----------------------> 448 Stateless-pd Prefix 450 Figure 4 452 Each PDN is assumed to have single or several prefixes (called PDN 453 prefix) used to generate UE's address. Followed by the PDN prefix in 454 Figure 4, there is 16-bit TEID assigned for a UE's session at SGW on 455 the control plane. TEID is 16 bits identifier in GTP header to 456 distinguish each bearer. The remaining bits are filled by subnet ID. 457 The prefix is allocated per UE and used for address assignment by 458 SLAAC or DHCPv6. 460 o [I-D.vandevelde-idr-remote-next-hop] can be used to carry end 461 points information of GTP tunnel over BGP. 463 In order to distribute a route entry of the UE's generated prefix of 464 UE from vEPC to all EPC-E, BGP is one of suitable routing protocol. 466 [I-D.vandevelde-idr-remote-next-hop] enables BGP to carry tunnel 467 information as Network Layer Reachability Information (NLRI) within 468 BGP route. In our document, we use GTP tunnel endpoint information 469 as a next-hop of the route entry of UE's prefix. The GTP information 470 is a combination of SI-U address and TEID of UE's attaching eNodeB. 472 BGP has already been extended for BGP speakers to advertise tunneling 473 information to its peers [RFC5512], but [RFC5512] does not support 474 GTP as a tunnel type. Moreover, it assumes only a single tunnel 475 between a pair of BGP speakers although there are multiple tunnels 476 between RAN and vEPC in cellular system. To keep compatibility to 477 RAN architecture, it is not possible for eNodeB to act as a BGP 478 speaker. Some mechanism will thus be required to advertise and to 479 reflect tunnel endpoint routes to EPC-E instead of eNodeB. 480 [I-D.vandevelde-idr-remote-next-hop] will be dealt with these issues. 482 In step (15), EPC-E can aggregate multiple UE's prefixes into less 483 BGP routes as a part of normal routing operation within operator's 484 network. 486 When tunnel endpoint is updated by an UE hand-over between eNode, 487 vEPC must refresh the route of UE with updated tunnel endpoint as a 488 remote next-hop. The updated route should be immediately advertised 489 to EPC-Es. In the case of UE detachment, vEPC simply removes the 490 detached UE route. 492 vEPC(MME/SGW 493 UE eNodeB PGW/HSS/AAA) EPC-E RTR 494 | | | | | 495 |---------->|(1) | | | 496 | |---------->|(1) MME | | 497 |/---------------------\| | | 498 | Authentication |(2) AAA | | 499 |\---------------------/| | | 500 | | |--+SGW/PGW | | 501 | | | |(3)(4) |(4)SGW's TEID is configured 502 | | |<-+ | and notified to MME 503 | |<----------|(5) MME | | 504 |/---------\| | | | 505 | RB setup |(6) | | | 506 |\---------/| | | | 507 | |---------->|(7) MME | | 508 |---------->|(8) | | | 509 | |---------->|(9) MME |(9)eNodeB TEID is configured 510 | | | | and sent to MME 511 |= = = = = = = Uplink Data = = = = =>= = = = ==>|(10) 512 | The uplink is not yet built here | 513 | | | | | 514 | | |--+SGW/MME | | 515 | | | |(11,12) | | 516 | | |<-+ | | 517 |<= = = = = = Downlink Data = = = = <= = = = = =|(13) 518 | The downlink is not yet built here | 519 | | | | | 520 | | |---------->|(14) Route Update 521 | | | [Dst: UE-prefix, 522 | | | NxtHop: S1-U addr and TEID of enodeB 523 | | | | | 524 | | | |---------->|(15)Route update 525 | | | |[Dst: UE-prefix, 526 | | | | NxtHop: EPC-E address] 527 | | | | | 528 |---------RS or DHCP Request------->|(16) | 529 |<--------RA or DHCP Reply----------|(17) | 531 Extended PDN Connection Setup Procedure (copied Figure 8 of RFC6459) 533 Figure 5 535 UE requests an IPv6 prefix for its address assignment in the step 536 (16). In our architecture, instead of PDN-GW, EPC-E is responsible 537 to allocate an IPv6 prefix to UE. 539 When EPC-E receives a packet of either Router Solicitation or DHCPv6 540 request message, it looks up the remote next-hop field of its routing 541 information base (RIB) with the source IP address and the TEID of the 542 received packet. A route entry matched for this search is the route 543 entry created for the requesting UE. Therefore, EPC-E simply uses 544 the destination prefix of the route entry as an assigned UE's prefix. 545 In (17), EPC-E simply returns the prefix to UE by either Router 546 Advertisement or DHCPv6 reply message. UE now creates an configures 547 an address(es) from the received prefix. It is important to 548 highlight that UE can obtain the same prefix information from any 549 EPC-E all the time because the same UE's route information is 550 available on all the EPC-E. 552 3.3. Control-plane awareness of stateless user-plane 554 Control-plane nodes in vEPC must be aware that anycast address 555 assigned to EPC-E is the S1-U address of SGW. They must use the 556 anycast address for any control-plane signaling packets on vEPC. By 557 doing this, packets from RAN are correctly forwarded to an 558 appropriate EPC-E. Due to anycast nature, every SGW have the same 559 address as the S1-U address. It means there is no hand-off procedure 560 between SGWs because all eNodeB in the RAN send packets to the 561 anycast address are covered by all EPC-E of which sharing same routes 562 set. 564 3.4. Routing mechanism 566 Figure 6 shows a packet forwarding mechanism of our stateless user 567 plane. As an example, there are four eNodeB (illustrated as eNB-x) , 568 three EPC-Edge routers(shown as EPC-Ex) and two routers (RTRx) in 569 Figure 6. UE is first connected to eNB-C and then moves to eNB-D. 570 The UE at the new location is illustrated as UE'. Routing entry for 571 UE is also illustrated at the right side in Figure 6. 573 EPC-E has two interfaces facing either RAN or CORE networks. An 574 anycast address (shown as X) is configured to the interface facing 575 RAN of all EPC-E. EPC-E assigns an individual IPv6 address to 576 another interface (illustrated "a" to "d" in the figure). It is 577 important to mention that the anycast address X can be treated as the 578 SGW's S1-U address. 580 Since RTRs are a gateway to the Internet, they advertise routes of an 581 operator's prefix to the Internet. After one of RTR receives a 582 packet of UE from the Internet, it needs to routing it to UE in the 583 user plane. RTR has a simple routing entry for PDN prefix whose next 584 hop points to the EPC-E. One of RTR (let's say RTR2 in this case) 585 looks up a routing table with UE's address and matched it with a 586 routing entry of PDN prefix. Since multiple EPC-Es advertise a route 587 for the same PDN prefix, RTR2 should forward the packet to one of 588 EPC-E according to the routing entry. This routing is known as hot- 589 potato routing. In this example, the RTR2 uses EPC-E2-b as a nexthop 590 of PDN prefix. 592 When the UE's packet is arrived at EPC-E2, EPC-E2 needs to forwards 593 them to UE via eNodeB to which UE is connecting by using GTP tunnel. 594 For this operation, EPC-E2 has a routing entry that destination is 595 UE's prefix and that next hop points to GTP tunnel between eNB-C and 596 the EPC-Es. In order to identify the GTP tunnel for UE, EPC-E needs 597 S1-U address and Tunnel Endpoint ID (TEID) of eNB-C that is eNB-C-3 598 in Figure 6. The eNB-C TEID for UE is illustrated as TEID[eNB-C]. 599 The SGW assigned TEID is utilized to generate the UE's prefix as we 600 explained in Section 3.2. These TEID are assigned per UE. The TEID 601 and S1-U address of eNodeB are retrieved from the next hop field of 602 the routing entry of the mobile node. By using the GTP information, 603 every EPC-E can now forward the UE's packets to right eNodeB. 605 Routing outgoing packets from UE is much simpler. The packets from 606 UE are always routed to the closest EPC-E to UE because of anycast 607 routing. In Figure 6, when UE sends a packet to a destination, the 608 packet is reached to eNB-C and tunneled to EPC-E's anycast address. 609 The GTP-tunneled packet is routed to the closest EPC-E that is EPC-E2 610 in this case. The packet is decapsulated by EPC-E2 and then 611 forwarded to one of RTR according to the routing table. Since the 612 decapsulated packet is regular IPv6 packet, no extra control other 613 than routing is necessary. 615 When UE moves to a new location (UE'), it updates its location on the 616 control plane. After signaling completion for location update, vEPC 617 needs to update the UE's routing entry of all EPC-E so that vEPC 618 advertises updated route with new location to all EPC-Es by a routing 619 protocol. The routing entry should be updated with the new eNodeB's 620 address that is eNB-D-4. During handover, there might be some 621 traffic arriving to the older eNodeB (eNB-C). These packets can be 622 re-routed to the new eNodeB (eNB-D) via X2-U interface in RAN. 624 The UE's address isn't changed when UE changes its attachment. In 625 our scenario, SGW run on hypervisor and is independent from network 626 topology. Therefore, logically we don't have handover across 627 different SGWs. UE can stay connected with the same SGW all the time 628 and can keep using the same TEID after handover. Thus, UE's address 629 is unchanged even after handover. 631 +--------------------+ 632 | Correspondent Node | 633 +--------------------+ 634 | 635 .--. [Route on the Internet] 636 _(. `) Destination: Operator's Prefix 637 _( `)_ NextHop: RTR-1/2 638 ( Internet `) 639 ( ` . ) ) 640 `--(_______)---' 641 / \ [Route at RTR] 642 +----+ +----+ Destination: PDN Prefix 643 |RTR1| |RTR2| NextHop: EPC-E2-b 644 +----+ +----+ 645 \ .--. / 646 _( IP `. 647 ( CORE NW ) 648 ___( ` . ) )__ 649 / `--(___.--' \ 650 / | \ 651 |a |b |c [Route at EPC-E] 652 +---+--+ +---+--+ +---+--+ Destination: UE's Prefix *1 653 |EPC-E1| |EPC-E2| |EPC-E3| NextHop: GTP tunnel (eNB-C) *2 654 +---+--+ +---+--+ +---+--+ 655 |X |X |X 656 \ .--. / 657 \_____( RAN `.____/ 658 ( ACCESS ) 659 ____( ` NW ) )_______ 660 / `--(___.--' \ 661 / | | \ 662 |1 |2 |3 |4 663 +--+--+ +--+--+ +--+--+ +--+--+ 664 |eNB-A| |eNB-B| |eNB-C| |eNB-D| 665 +--+--+ +--+--+ +--+--+ +--+--+ 666 : : : : 667 UE --> UE' 668 *1 TEID used at EPC-E for the UE is included in this UE's prefix. 669 see Figure 4. 670 *2 GTP tunnel state is stored in the next hop field. The state 671 information is the combination of eNB-C S1 address that is 672 eNB-C-3 and TEID(eNB-C) assigned for the UE. 674 Routing Mechanism Overview 676 Figure 6 678 3.5. IPv4 Support 680 Recent IPv6 transition mechanisms enable IPv6-only network to forward 681 IPv4 packet with encapsulation or translation techniques. By using 682 one of mechanisms, we can use IPv6 for our stateless user-plane 683 network for transporting both IPv4 and IPv6 packets. Figure 7 shows 684 available solutions of IPv4 support for each bearer type to deal with 685 that requirement. 687 Bearer UE EPC-E Gateway 688 type function function function 689 -------------------------------------------- 690 IPv4 - B4 AFTR 691 IPv4 - CLAT PLAT 692 IPv6 MAP-CE - MAP-BR 693 IPv6 B4 - AFTR 694 IPv6 CLAT - PLAT 696 Solutions and functions for IPv4 support 698 Figure 7 700 In the case of a UE only support IPv4 bearer, B4 function of DS-Lite 701 [RFC6333] or CLAT function of 464XLAT [RFC6877] may be implemented in 702 a EPC-E. Both functions are stateless therefore EPC-E isn't required 703 to maintain any tunneling or translation state. 705 Figure 8 shows how to support IPv4 on IPv6 core network in our vEPC. 706 Instead of using RqTR as a gateway to the Internet, DS-LITE AFTR or 707 464XLAT PLAT is installed as a gateway to the IPv4 Internet. 709 .--. 710 EPC-E _( `)_ Gateway 711 +----+ _( `) +------+ 712 | B4 | ( IPv6 Core ) | AFTR | 713 [UE]==IPv4-only==| or |-( ` NW )-| or | --> Internet 714 bearer |CLAT| ( ` ) ) | PLAT | (IPv4) 715 +----+ `--(_____)--' +------+ 716 <-----IPv4 over IPv6-----> 717 or 718 v4v6 translation 720 IPv4 User plane of vEPC 722 Figure 8 724 If UE supports IPv6 capable bearer, IPv6 transition function may be 725 implemented in the UE such as MAP-CE [I-D.ietf-softwire-map], B4 or 726 CLAT. That means an EPC-E receives IPv6 packets from UE in this case 727 so that the EPC-E does not need to be involved in the part of IPv4 728 support functions. 730 4. IANA Considerations 732 This memo includes no request to IANA. 734 5. Security Considerations 736 There are no security considerations specific to this document at 737 this moment. 739 6. References 741 6.1. Normative References 743 [I-D.savolainen-stateless-pd] 744 Savolainen, T. and J. Korhonen, "Stateless IPv6 Prefix 745 Delegation for IPv6 enabled networks", draft-savolainen- 746 stateless-pd-01 (work in progress), February 2010. 748 [I-D.vandevelde-idr-remote-next-hop] 749 Velde, G., Patel, K., Rao, D., Raszuk, R., and R. Bush, 750 "BGP Remote-Next-Hop", draft-vandevelde-idr-remote-next- 751 hop-03 (work in progress), October 2012. 753 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 754 Subsequent Address Family Identifier (SAFI) and the BGP 755 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 757 6.2. Informative References 759 [Boeing-BGP] 760 Andrew, ., "Global IP Network Mobility using Border 761 Gateway Protocol (BGP)", IAB Plenary IAB Plenary of IETF 762 62nd, March 2005. 764 [I-D.ietf-softwire-map] 765 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 766 Murakami, T., and T. Taylor, "Mapping of Address and Port 767 with Encapsulation (MAP)", draft-ietf-softwire-map-07 768 (work in progress), May 2013. 770 [I-D.wakikawa-mext-haha-interop2008] 771 Wakikawa, R., Shima, K., and N. Shigechika, "The Global 772 HAHA Operation at the Interop Tokyo 2008", draft-wakikawa- 773 mext-haha-interop2008-00 (work in progress), July 2008. 775 [I-D.yokota-dmm-scenario] 776 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 777 scenarios for Distributed Mobility Management", draft- 778 yokota-dmm-scenario-00 (work in progress), October 2010. 780 [NFV-WHITEPAPER] 781 Network Operators, ., "Network Functions Virtualization, 782 An Introduction, Benefits, Enablers, Challenges and Call 783 for Action", SDN and OpenFlow SDN and OpenFlow World 784 Congress, October 2012. 786 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 787 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 788 RFC 3963, January 2005. 790 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 791 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 793 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 794 Routers", RFC 5555, June 2009. 796 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 797 Mobile IPv6", RFC 5844, May 2010. 799 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 800 in IPv6", RFC 6275, July 2011. 802 [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility 803 Support in the Internet", RFC 6301, July 2011. 805 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 806 Stack Lite Broadband Deployments Following IPv4 807 Exhaustion", RFC 6333, August 2011. 809 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 810 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 811 Partnership Project (3GPP) Evolved Packet System (EPS)", 812 RFC 6459, January 2012. 814 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 815 Combination of Stateful and Stateless Translation", RFC 816 6877, April 2013. 818 Authors' Addresses 820 Satoru Matsushima 821 Softbank Telecom 822 1-9-1,Higashi-Shimbashi,Minato-Ku 823 Tokyo 105-7322 824 Japan 826 Email: satoru.matsushima@g.softbank.co.jp 828 Ryuji Wakikawa 829 Softbank Mobile 830 1-9-1,Higashi-Shimbashi,Minato-Ku 831 Tokyo 105-7322 832 Japan 834 Email: ryuji.wakikawa@gmail.com