idnits 2.17.1 draft-bernardos-sfc-fog-ran-07.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 (March 11, 2020) is 1499 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Informational A. Rahman 5 Expires: September 12, 2020 A. Mourad 6 InterDigital 7 March 11, 2020 9 Service Function Chaining Use Cases in Fog RAN 10 draft-bernardos-sfc-fog-ran-07 12 Abstract 14 Fog Radio Access Networks (RAN) refers to the part of the RAN that is 15 virtualized at the very edge of the network, even at the end-user 16 device. Fog RAN support is considered critical for the 5G mobile 17 network architectures currently being developed in various research, 18 standardization and industry forums. Since fog RAN builds on top of 19 virtualization and can involve several virtual functions running on 20 different virtualized resources, Service function chaining (SFC) 21 support for the fog RAN will be critical. This document describes 22 the overall fog RAN approach and also gives some use cases. Finally 23 it proposes some requirements to be considered in the development of 24 the SFC architecture and related protocols. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 12, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Fog RAN Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Applicability of SFC to Fog RAN . . . . . . . . . . . . . . . 8 64 5. Fog RAN requirements . . . . . . . . . . . . . . . . . . . . 11 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 70 9.2. Informative References . . . . . . . . . . . . . . . . . 13 71 Appendix A. 4G (LTE) . . . . . . . . . . . . . . . . . . . . . . 14 72 Appendix B. 5G . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 The telecommunications sector is experiencing a major revolution that 78 will shape the way networks and services are designed and deployed 79 for the next decade. We are witnessing an explosion in the number of 80 applications and services demanded by users, which are now really 81 capable of accessing them on the move. In order to cope with such a 82 demand, some network operators are looking at the cloud computing 83 paradigm, which enables a potential reduction of the overall costs by 84 outsourcing communication services from specific hardware in the 85 operator's core to server farms scattered in data centers. These 86 services have different characteristics if compared with conventional 87 IT services that have to be taken into account in this cloudification 88 process. Also the transport network is affected in that it is 89 evolving to a more sophisticated form of IP architecture with trends 90 like separation of control and data plane traffic, and more fine- 91 grained forwarding of packets (beyond looking at the destination IP 92 address) in the network to fulfill new business and service goals. 94 Virtualization of functions also provides operators with tools to 95 deploy new services much faster, as compared to the traditional use 96 of monolithic and tightly integrated dedicated machinery. As a 97 natural next step, mobile network operators need to re-think how to 98 evolve their existing network infrastructures and how to deploy new 99 ones to address the challenges posed by the increasing customers' 100 demands, as well as by the huge competition among operators. All 101 these changes are triggering the need for a modification in the way 102 operators and infrastructure providers operate their networks, as 103 they need to significantly reduce the costs incurred in deploying a 104 new service and operating it. Some of the mechanisms that are being 105 considered and already adopted by operators include: sharing of 106 network infrastructure to reduce costs, virtualization of core 107 servers running in data centers as a way of supporting their load- 108 aware elastic dimensioning, and dynamic energy policies to reduce the 109 monthly electricity bill. However, this has proved to be tough to 110 put in practice, and not enough. Indeed, it is not easy to deploy 111 new mechanisms in a running operational network due to the high 112 dependency on proprietary (and sometime obscure) protocols and 113 interfaces, which are complex to manage and often require configuring 114 multiple devices in a decentralized way. 116 Network function virtualization (NFV) [etsi_nvf_whitepaper] and 117 software defined networking (SDN) [onf_sdn_architecture] are changing 118 the way the telecommunications sector will deploy, extend and operate 119 their networks. In this document we focus on one particular 120 application of network softwarization: the radio access network 121 (RAN), and in particular, how to run RAN functions on dynamic virtual 122 resources very close to the users, the so-called Fog. We analyze the 123 applicability of the SFC architecture to the Fog RAN use case. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 While [RFC2119] describes interpretations of these key words in terms 132 of protocol specifications and implementations, they are used in this 133 document to describe requirements for the SFC mechanisms to 134 efficiently enable fog RAN. 136 The following terms used in this document are defined by the ETSI NVF 137 ISG, the ONF and the IETF: 139 NFV Infrastructure (NFVI): totality of all hardware and software 140 components which build up the environment in which VNFs are 141 deployed 142 NFV Management and Orchestration (NFV-MANO): functions 143 collectively provided by NFVO, VNFM, and VIM. 145 NFV Orchestrator (NFVO): functional block that manages the Network 146 Service (NS) lifecycle and coordinates the management of NS 147 lifecycle, VNF lifecycle (supported by the VNFM) and NFVI 148 resources (supported by the VIM) to ensure an optimized allocation 149 of the necessary resources and connectivity. 151 OpenFlow protocol (OFP): allowing vendor independent programming 152 of control functions in network nodes. 154 Service Function (SF): a function that is responsible for specific 155 treatment of received packets (e.g., firewall, load balancer). 157 Service Function Chain (SFC): for a given service, the abstracted 158 view of the required service functions and the order in which they 159 are to be applied. This is somehow equivalent to the Network 160 Function Forwarding Graph (NF-FG) at ETSI. 162 Service Function Path (SFP): the selection of specific service 163 function instances on specific network nodes to form a service 164 graph through which an SFC is instantiated. 166 Virtualized Infrastructure Manager (VIM): functional block that is 167 responsible for controlling and managing the NFVI compute, storage 168 and network resources, usually within one operator's 169 Infrastructure Domain. 171 Virtualized Network Function (VNF): implementation of a Network 172 Function that can be deployed on a Network Function Virtualisation 173 Infrastructure (NFVI). 175 Virtualized Network Function Manager (VNFM): functional block that 176 is responsible for the lifecycle management of VNF. 178 3. Fog RAN Overview 180 Virtualization is invading all domains of the E2E 5G network, 181 including the access, as a mean to achieve the necessary flexibility 182 in support of the E2E slicing concept. The ETSI NFV framework is the 183 cornerstone for making virtualization such a promising technology 184 that can be matured in time for 5G. Typically, virtualization has 185 been mostly envisaged in the core network, where sophisticated data 186 centers and clouds provided the right substrate. And mostly, the 187 framework focused on virtualizing network functions, so called VNFs 188 (virtualized network functions), which were somewhat limited to 189 functions that are delay tolerant, typically from the core and 190 aggregation transport. Yet in the access, virtualization of RAN 191 functions could still be envisaged as one step forward for the Cloud- 192 RAN concept, assuming an extremely low latency fronthaul transport 193 (typically over fiber) and again limiting to those RAN functions 194 which delay requirements match for execution in a virtualized 195 environment. 197 As the community has recently been developing the 5G applications and 198 their technical requirements, it has become clear that certain 199 applications would require very low latency which is extremely 200 challenging and stressing for the network to deliver through a pure 201 centralized architecture. The need to provide networking, computing, 202 and storage capabilities closer to the users has therefore emerged, 203 leading to what is known today as the concept of intelligent edge. 204 ETSI has been the first to address this need recently by developing 205 the framework of mobile edge computing (MEC). 207 Such an intelligent edge could not be envisaged without 208 virtualization. Beyond applications, it raises a clear opportunity 209 for networking functions to execute at the edge benefiting from 210 inherent low latencies. Being in close proximity to the access, the 211 edge becomes thus an attractive place for hosting C-RAN functions in 212 particular, which could also be envisaged virtualized thanks to the 213 virtualization capabilities now available at the edge. Transport and 214 core networking functions could also take advantage of such a hosting 215 environment, thus saving bandwidth in their respective domains and 216 offering local breakout options where required. Furthermore, a rich 217 set of context information from the RAN but also from other network 218 domains could be offered as services through the edge for 219 applications to consume and hence optimize their behavior or key 220 performance indicators (KPIs). 222 Whilst it is appreciated the particular challenge for the intelligent 223 edge concept in dealing with mobile users, the edge virtualization 224 substrate has been largely assumed to be fixed or stationary. 225 Although little developed, the intelligent edge concept is being 226 extended further to scenarios where for example the edge computing 227 substrate is on the move, e.g., on-board a car or a train, or that it 228 is distributed further down the edge, even integrating resources from 229 different stakeholders, into what is known as the fog. The 230 challenges and opportunities for such extensions of the intelligent 231 edge remain an exciting area of future research. 233 The computing and virtualization capabilities available down into the 234 fog are of particular advantage to the virtualized-RAN/cloud-RAN, 235 leading to what we refer to as "Fog RAN". Virtual networking 236 functions (VNFs) related to the RAN may execute in the fog. The 237 close proximity of the fog to the end user devices opens new 238 possibilities for extending the scope of virtual RAN (VRAN) functions 239 from just access nodes so far to end user devices, so that functions 240 traditionally running on the end user devices may be moved to the 241 fog. In addition, an additional tier of intelligent VRAN functions 242 could be envisaged to run across other functions of various nodes or 243 devices and from different radio access technologies (RATs), 244 supporting tight coordination between these nodes and devices, and 245 enabling convergence between the RATs. VNFs from the transport and 246 core could also be hosted in the fog so as to save bandwidth in their 247 respective domains. 249 Figure 1 shows a diagram representing the fog RAN concept. The fog 250 is composed by virtual resources on top of heterogeneous resources 251 available at the edge and even further in the RAN and end-user 252 devices. These resources are therefore owned by different 253 stakeholders who collaboratively form a single hosting environment 254 for the VNFs to run. As an example, virtual resources provided to 255 the fog might be running on eNBs, APs, at micro data centers deployed 256 in shopping malls, cars, trains, etc. The fog is connected to data 257 centers deeper into the network architecture (at the edge ir the 258 core). On the top part of the figure, an example of user and control 259 plane VNFs is shown. User plane VNFs are represented as "fx", and 260 control ones as "ctrlx". Depending on the functionality implemented 261 by these VNFs and the service requirements, these VNFs would be 262 mapped (i.e., instantiated) differently to the physical resouces (as 263 described in [I-D.aranda-sfc-dp-mobile]). 265 -------- --------- --------- 266 control | ctr1 |........................| ctrl2 |...| ctrl3 | 267 plane -------- --------- --------- 268 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 269 ------ ------ ------ 270 .| f3 |.........| f5 |.....| f6 | 271 ------ ------ . ------ ------ ------ 272 user | f1 |.......| f2 |. . 273 plane ------ ------ . ------ . 274 .| f4 |............. 275 ------ 276 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 277 +--------------------------------+ +-------------------+ 278 | ------- -------- -------- | | ---------- | 279 | | | | | | | | | ---------- | | 280 | | @UE | | @car | | @eNB | | | ---------- | | | 281 | ------- -------- -------- | | | Data | | | | 282 | | | | Center | | - | 283 | -------- Heterogeneous ------- | | | (DC) |- | 284 phy | | | computing | | | | ---------- | 285 infra | |@train| devices | @AP | |==| ---------- | 286 | -------- forming ------- | | ---------- | | 287 | the fog | | ---------- | | | 288 | --------- ------------ | | | Data | | | | 289 | | | | | | | | Center | | - | 290 | | @mall | | @localDC | | | | (DC) |- | 291 | --------- ------------ | | ---------- | 292 | FOG | | CLOUD | 293 +--------------------------------+ +-------------------+ 294 <--------- fog and edge -----------------> 295 <--- edge & central cloud ---> 297 Figure 1: Fog RAN 299 The fog is also well suited to offer a rich set of context 300 information noticeably (but not only) from the RAN that could be 301 collected from the various RATs co-existing in the same service area. 302 This information can be obtained either from networking resources 303 (e.g., nodes and devices) or functions, some of which might be hosted 304 in the fog. Such information may be exposed through services running 305 in the fog or in the edge, for applications on top to consume and 306 hence optimize their performance or behavior. The fog or edge will 307 therefore be in charge of collecting and publishing context 308 information towards network applications as well as end user/3rd 309 party applications. This is accomplished by the so-called "services" 310 which follow the concept of ETSI MEC ISG services and may run in the 311 fog. Applications may also run directly in the fog and subscribe to 312 one or more services provided in the fog. These fog applications 313 could also offer services to other applications residing inside the 314 fog or outside, e.g., in the edge or central cloud. This enables 315 different kinds of Over-The-Top (OTT) applications to utilize the RAN 316 context information available at the fog. 318 4. Applicability of SFC to Fog RAN 320 For a given service, the abstracted view of the required service 321 functions and the order in which they are to be applied is called a 322 service function chain (SFC), which is called network function 323 forwarding graph (NF-FG) in ETSI. An SFC is instantiated through 324 selection of specific service function instances on specific network 325 nodes to form a service graph: this is called a service function path 326 (SFP). The service functions may be applied at any layer within the 327 network protocol stack (network layer, transport layer, application 328 layer, etc.). 330 [RFC7665] describes the architecture for the specification, creation, 331 and ongoing maintenance of service function chains (SFCs) in a 332 network. The SFC architecture is composed of the following logical 333 components: classifiers, service function forwarders (SFFs), service 334 functions (SFs), and SFC proxies. These components are 335 interconnected using the SFC encapsulation, as shown in Figure 2. 337 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 . +--------------+ +------------------~~~ 339 . | Service | SFC | Service +---+ +---+ 340 . |Classification| Encapsulation | Function |sf1|...|sfn| 341 +---->| Function |+---------------->| Path +---+ +---+ 342 . +--------------+ +------------------~~~ 343 . SFC-enabled Domain 344 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 Figure 2: SFC architecture 348 An overview of how the SFC logical components interact after the 349 initial classification is also shown in Figure 3 (reproduced from 350 [RFC7665] for completeness). 352 +----------------+ +----------------+ 353 | SFC-aware | | SFC-unaware | 354 |Service Function| |Service Function| 355 +-------+--------+ +-------+--------+ 356 | | 357 SFC Encapsulation No SFC Encapsulation 358 | SFC | 359 +---------+ +----------------+ Encapsulation +---------+ 360 |SFC-Aware|-----------------+ \ +------------|SFC Proxy| 361 | SF | ... ----------+ \ \ / +---------+ 362 +---------+ \ \ \ / 363 +-------+--------+ 364 | SF Forwarder | 365 | (SFF) | 366 +-------+--------+ 367 | 368 SFC Encapsulation 369 | 370 ... SFC-enabled Domain ... 371 | 372 Network Overlay Transport 373 | 374 _,....._ 375 ,-' `-. 376 / `. 377 | Network | 378 `. / 379 `.__ __,-' 380 `'''' 382 Figure 3: SFC architecture components 384 There are different use cases for service function chaining in mobile 385 networks. [I-D.ietf-sfc-use-case-mobility] describes in general how 386 to use SFC for mobile networks focusing on the core functions, while 387 [I-D.aranda-sfc-dp-mobile] looks more at RAN aspects. 389 This document focuses on the specific use case of applying SFC 390 concepts to the fog RAN environment, which is characterized mainly 391 by: 393 o The VNFs being chained implement mostly RAN functionality. The 394 Cloud RAN (C-RAN) approach centralizes baseband processing and 395 network resource allocation (which are today functions executed in 396 a distributed way at the access nodes, such as eNBs). The strict 397 latency and bandwidth requirements imposed by C-RAN triggered the 398 evolution of the virtualization of the access infrastructure to 399 the concept of RAN as a Service, where the centralization (i.e. 401 function virtualization in a data center) of processing and 402 management in mobile networks is flexible and adapted to the 403 actual service requirements and the network conditions. This is 404 also referred to as flexible functional split of the radio 405 protocol stack. Up to now, RAN virtualization approaches have 406 only considered offloading of computation tasks in central clouds 407 or regional data centers close to the network aggregation points. 408 With fog RAN, virtualization resources are placed closer to users, 409 from edge computing to fog computing at user devices, leveraging 410 micro data centers at user premises, thus reducing end-to-end 411 latency. 413 o Virtualizing RAN functions at the fog could also enable new 414 optimizations when information of (or available at) the access is 415 used. Examples of this information include: RAN measured 416 parameters, location information, etc. This information can be 417 used for example to jointly optimize multiple RATs. 419 o The fog computing environment can also be used to virtualize 420 functions from the end-user devices, not only from the RAN. This 421 can help facilitating a better convergence of multiple access 422 technologies. 424 Fog RAN implementations will benefit from applying SFC concepts as 425 virtual RAN functions will be executed on virtual resources from 426 different stakeholders, meaning different data centers managed by 427 different entities. In this environment, SFC encapsulation can be 428 used to ensure proper data processing. Figure 4 shows an example of 429 scenario of application of SFC in the fog RAN. On the top part we 430 show a UE connected to the network. The eNB functionality is 431 actually split, so part of it (e.g., RLC, PDCP and RRC) runs 432 virtualized in the fog, while the rest (e.g., MAC and PHY) stay at 433 the remote radio head (RRH). Other mobile network RAN functionality 434 can also be running virtualized in the fog, such as a local virtual 435 MME, multi-RAT authentication and RAT selection mechanisms, 436 offloading solutions (such as local vEPCs), etc. The rest of the 437 mobile network functions (see Appendix A for a short overview) runs 438 in the core. On the bottom part of the figure we show a potential 439 mapping of the virtual functions to the physical resources that 440 compose the fog. SFC mechanisms would be used to interconnect the 441 different functions in the right order and meeting the requirements 442 (latency, compute, etc) needed. 444 +---------------------------------------------+ 445 ------ | FOG -------------- | 446 | UE | | ------------- -------- | RAT selec. | | 447 --+--- | | multi-RAT | | vMME | -------------- | 448 v | | auth. | -------- " | 449 v | ------------- "------- " | 450 | | " .| RRC | " | 451 -+----- | ------- " -------- ."------- ----------- | 452 | RRH |====| | RLC |.".| PDCP |. " " .| offload | | 453 ------- | ------- " ---"---- ." " . ----------- | +-----+ 454 | " " " . " . " " | | | 455 | " " " "..(data)...............==| EPC | 456 | " " " " " " " | | | 457 +----"----"----"------"-----"-------"----"----+ +-----+ 458 " " " " " " " 459 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 460 mapping of " " " " " " " 461 VNFs to phy +----"----"----"------"-----"-------"----"----+ 462 resources | " " " " " " " | 463 | ---"----"----"---- "------"--- ---"----"--- | 464 | | " auth " | | vMME " | | RAT " | | 465 | | RLC PDCP | | RRC | | sel offl | | 466 | | @eNB | | @mall | | @AP | | 467 | ------------------ ----------- ------------ | 468 | | 469 +---------------------------------------------+ 470 <--- phy ---><-------------- fog and edge -----------------><-core-> 472 Figure 4: Fog RAN SFC example scenario 474 Since the virtual resources where virtual functions are potentially 475 hosted on infrastructure managed by different entities, SFC 476 encapsulation is a key tool to enable the fog RAN scenario. In the 477 next section we enumerate some initial requirements to be considered, 478 that will be extended and further developed in subsequent versions of 479 this document. 481 5. Fog RAN requirements 483 The following requirements should be considered during SFC 484 architecture and related protocol design to ensure that SFC can fully 485 support fog RAN functionality: 487 REQ-R01: SFC MUST support user traffic flows with very low delay 488 budgets (e.g., less than 1ms) at the edge of the network. 490 REQ-R02: SFC MUST support mobility of Service Functions (e.g., 491 edge network node containing SF that is located on a high speed 492 train). 494 REQ-R03: SFC MUST support Service Functions (e.g., MEC) that are 495 located at the edge of the network and that perform L7-Application 496 processing very early in the forwarding path. 498 REQ-R04: SFC MUST support metadata used to exchange information 499 about the network and virtual resources status, so it can be used 500 to decide about updates of the service function path. 502 REQ-R05: SFC MUST support metadata with context information (e.g., 503 location, RAN information, etc.) from fog nodes (e.g., access 504 nodes and end user devices) from multiple RATs. 506 REQ-R06: SFC MUST support chaining functions hosted at 507 heterogeneous hosts (in terms of computing resources, 508 availability, mobility, and other policies). 510 REQ-R07: SFC MUST support chaining functions hosted across various 511 geographically spread physical networking and computing resources. 513 REQ-R08: SFC MUST support a secure and dynamic discovery of 514 functions, potentially belonging to different domains. 516 REQ-R09: SFC MUST support dynamic mobility of the hosts where the 517 service functions run, e.g., when the host is a moving device 518 (user terminal, car, train, etc.). 520 REQ-R10: SFC OAM MUST support monitoring of SFs, SFFs and SFC 521 proxies deployed on mobile platforms. 523 REQ-R11: SFC MUST support configuration mechanisms for mobile 524 devices to be part of an SFC. 526 REQ-R12: SFC MUST support volatile resources (SFs), allowing for 527 backup mechanisms in case a SF becomes unavailable due to the 528 volatility of the resource. 530 REQ-RX: More TBD... 532 6. IANA Considerations 534 N/A. 536 7. Security Considerations 538 TBD. 540 8. Acknowledgments 542 The work in this draft will be further developed and explored under 543 the framework of the H2020 5G-DIVE project (Grant 859881). 545 9. References 547 9.1. Normative References 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, 551 DOI 10.17487/RFC2119, March 1997, 552 . 554 9.2. Informative References 556 [etsi_nvf_whitepaper] 557 ISG, E. N., "Network Functions Virtualisation (NFV). White 558 Paper 2", October 2014. 560 [I-D.aranda-sfc-dp-mobile] 561 Gutierrez, P., Gramaglia, M., Lopez, D., and W. Haeffner, 562 "Service Function Chaining Dataplane Elements in Mobile 563 Networks", draft-aranda-sfc-dp-mobile-04 (work in 564 progress), June 2017. 566 [I-D.ietf-sfc-use-case-mobility] 567 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 568 J. Uttaro, "Service Function Chaining Use Cases in Mobile 569 Networks", draft-ietf-sfc-use-case-mobility-09 (work in 570 progress), January 2019. 572 [onf_sdn_architecture] 573 (ONF), O. N. F., "SDN Architecture (Issue 1.1), ONF TR- 574 521", February 2016. 576 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 577 Chaining (SFC) Architecture", RFC 7665, 578 DOI 10.17487/RFC7665, October 2015, 579 . 581 Appendix A. 4G (LTE) 583 This annex includes a high level summary of the 3GPP EPS 584 architecture, commonly referred to as 4G (LTE), detailing both the 585 EPC (core) and the RAN (access) parts. 587 The EPS architecture and some of its standardized interfaces are 588 depicted in Figure 5. The EPS provides IP connectivity to user 589 equipment (UE) (i.e., mobile nodes) and access to operator services, 590 such as global Internet access and voice communications. The EPS 591 comprises the core network -- called Evolved Packet Core (EPC) -- and 592 different radio access networks: the 3GPP Access Network (AN), the 593 Untrusted non-3GPP AN and the Trusted non-3GPP AN. There are 594 different types of 3GPP ANs, with the evolved UMTS Terrestrial Radio 595 Access Network (E-UTRAN) as the most advanced one. QoS is supported 596 through an EPS bearer concept, providing bindings to resource 597 reservation within the network. 599 The evolved NodeB (eNB), the Long Term Evolution (LTE) base station, 600 is part of the access network that provides radio resource 601 management, header compression, security and connectivity to the core 602 network through the S1 interface. In an LTE network, the control 603 plane signaling traffic and the data traffic ar handled separately. 604 The eNBs transmit the control traffic and data traffic separately via 605 two logically separate interfaces. 607 The Home Subscriber Server, HSS, is a database that contains user 608 subscriptions and QoS profiles. The Mobility Management Entity, MME, 609 is responsible for mobility management, user authentication, bearer 610 establishment and modification and maintenance of the UE context. 612 The Serving gateway, S-GW, is the mobility anchor and manages the 613 user plane data tunnels during the inter-eNB handovers. It tunnels 614 all user data packets and buffers downlink IP packets destined for 615 UEs that happen to be in idle mode. 617 The Packet Data Network (PDN) Gateway, P-GW, is responsible for IP 618 address allocation to the UE and is a tunnel endpoint for user and 619 control plane protocols. It is also responsible for charging, packet 620 filtering, and policy-based control of flows. It interconnects the 621 mobile network to external IP networks, e.g. the Internet. 623 In this architecture, data packets are not sent directly on an IP 624 network between the eNB and the gateways. Instead, every packet is 625 tunneled over a tunneling protocol - the GPRS Tunneling Protocol (GTP 626 over UDP/IP. A GTP path is identified in each node with the IP 627 address and a UDP port number on the eNB/gateways. The GTP protocol 628 carries both the data traffic (GTP-U tunnels) and the control traffic 629 (GTP-C tunnels). Alternatively Proxy Mobile IP (PMIPv6) is used on 630 the S5 interface between S-GW and P-GW. 632 In addition to the above basic functions and entities, there are also 633 additional features being discussed by the 3GPP that are relevant 634 from a network virtualization viewpoint. One example is the Traffic 635 Detection Function (TDF), which can be used by the P-GW, and in 636 general by the whole transport network, to decide how to forward the 637 traffic. In a virtualized infrastructure, this kinf of information 638 can be used to elastic and dynamically adapt the network capabilities 639 to the traffic nature and volume. 641 +---------------------------------------------------------+ 642 | PCRF | 643 +-----------+--------------------------+----------------+-+ 644 | | | 645 +----+ +-----------+------------+ +--------+-----------+ +-+-+ 646 | | | +-+ | | Core Network | | | 647 | | | +------+ |S|__ | | +--------+ +---+ | | | 648 | | | |GERAN/|_|G| \ | | | HSS | | | | | | 649 | +-----+ UTRAN| |S| \ | | +---+----+ | | | | E | 650 | | | +------+ |N| +-+-+ | | | | | | | x | 651 | | | +-+ /|MME| | | +---+----+ | | | | t | 652 | | | +---------+ / +---+ | | | 3GPP | | | | | e | 653 | +-----+ E-UTRAN |/ | | | AAA | | | | | r | 654 | | | +---------+\ | | | SERVER | | | | | n | 655 | | | \ +---+ | | +--------+ | | | | a | 656 | | | 3GPP AN \|SGW+----- S5---------------+ P | | | l | 657 | | | +---+ | | | G | | | | 658 | | +------------------------+ | | W | | | I | 659 | UE | | | | | | P | 660 | | +------------------------+ | | +-----+ | 661 | | |+-------------+ +------+| | | | | | n | 662 | | || Untrusted +-+ ePDG +-S2b---------------+ | | | e | 663 | +---+| non-3GPP AN | +------+| | | | | | t | 664 | | |+-------------+ | | | | | | w | 665 | | +------------------------+ | | | | | o | 666 | | | | | | | r | 667 | | +------------------------+ | | | | | k | 668 | +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s | 669 | | +------------------------+ | | | | | | 670 | | | +-+-+ | | | 671 | +--------------------------S2c--------------------| | | | 672 | | | | | | 673 +----+ +--------------------+ +---+ 675 Figure 5: EPS (non-roaming) architecture overview 677 Appendix B. 5G 679 TBD. This section will include a description of main 5G building 680 blocks. 682 Authors' Addresses 684 Carlos J. Bernardos 685 Universidad Carlos III de Madrid 686 Av. Universidad, 30 687 Leganes, Madrid 28911 688 Spain 690 Phone: +34 91624 6236 691 Email: cjbc@it.uc3m.es 692 URI: http://www.it.uc3m.es/cjbc/ 694 Akbar Rahman 695 InterDigital Communications, LLC 696 1000 Sherbrooke Street West, 10th floor 697 Montreal, Quebec H3A 3G4 698 Canada 700 Email: Akbar.Rahman@InterDigital.com 701 URI: http://www.InterDigital.com/ 703 Alain Mourad 704 InterDigital Europe 706 Email: Alain.Mourad@InterDigital.com 707 URI: http://www.InterDigital.com/