idnits 2.17.1 draft-bernardos-sfc-fog-ran-10.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 (October 22, 2021) is 907 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. Mourad 5 Expires: April 25, 2022 InterDigital 6 October 22, 2021 8 Service Function Chaining Use Cases in Fog RAN 9 draft-bernardos-sfc-fog-ran-10 11 Abstract 13 Fog Radio Access Networks (RAN) refers to the part of the RAN that is 14 virtualized at the very edge of the network, even at the end-user 15 device. Fog RAN support is considered critical for the 5G mobile 16 network architectures currently being developed in various research, 17 standardization and industry forums. Since fog RAN builds on top of 18 virtualization and can involve several virtual functions running on 19 different virtualized resources, Service function chaining (SFC) 20 support for the fog RAN will be critical. This document describes 21 the overall fog RAN approach and also gives some use cases. Finally 22 it proposes some requirements to be considered in the development of 23 the SFC architecture and related protocols. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 25, 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Fog RAN Overview . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Applicability of SFC to Fog RAN . . . . . . . . . . . . . . . 8 63 5. Fog RAN requirements . . . . . . . . . . . . . . . . . . . . 11 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 69 9.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Appendix A. 4G (LTE) . . . . . . . . . . . . . . . . . . . . . . 14 71 Appendix B. 5G . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 74 1. Introduction 76 The telecommunications sector is experiencing a major revolution that 77 will shape the way networks and services are designed and deployed 78 for the next decade. We are witnessing an explosion in the number of 79 applications and services demanded by users, which are now really 80 capable of accessing them on the move. In order to cope with such a 81 demand, some network operators are looking at the cloud computing 82 paradigm, which enables a potential reduction of the overall costs by 83 outsourcing communication services from specific hardware in the 84 operator's core to server farms scattered in data centers. These 85 services have different characteristics if compared with conventional 86 IT services that have to be taken into account in this cloudification 87 process. Also the transport network is affected in that it is 88 evolving to a more sophisticated form of IP architecture with trends 89 like separation of control and data plane traffic, and more fine- 90 grained forwarding of packets (beyond looking at the destination IP 91 address) in the network to fulfill new business and service goals. 93 Virtualization of functions also provides operators with tools to 94 deploy new services much faster, as compared to the traditional use 95 of monolithic and tightly integrated dedicated machinery. As a 96 natural next step, mobile network operators need to re-think how to 97 evolve their existing network infrastructures and how to deploy new 98 ones to address the challenges posed by the increasing customers' 99 demands, as well as by the huge competition among operators. All 100 these changes are triggering the need for a modification in the way 101 operators and infrastructure providers operate their networks, as 102 they need to significantly reduce the costs incurred in deploying a 103 new service and operating it. Some of the mechanisms that are being 104 considered and already adopted by operators include: sharing of 105 network infrastructure to reduce costs, virtualization of core 106 servers running in data centers as a way of supporting their load- 107 aware elastic dimensioning, and dynamic energy policies to reduce the 108 monthly electricity bill. However, this has proved to be tough to 109 put in practice, and not enough. Indeed, it is not easy to deploy 110 new mechanisms in a running operational network due to the high 111 dependency on proprietary (and sometime obscure) protocols and 112 interfaces, which are complex to manage and often require configuring 113 multiple devices in a decentralized way. 115 Network function virtualization (NFV) [etsi_nvf_whitepaper] and 116 software defined networking (SDN) [onf_sdn_architecture] are changing 117 the way the telecommunications sector will deploy, extend and operate 118 their networks. In this document we focus on one particular 119 application of network softwarization: the radio access network 120 (RAN), and in particular, how to run RAN functions on dynamic virtual 121 resources very close to the users, the so-called Fog. We analyze the 122 applicability of the SFC architecture to the Fog RAN use case. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 While [RFC2119] describes interpretations of these key words in terms 131 of protocol specifications and implementations, they are used in this 132 document to describe requirements for the SFC mechanisms to 133 efficiently enable fog RAN. 135 The following terms used in this document are defined by the ETSI NVF 136 ISG, the ONF and the IETF: 138 NFV Infrastructure (NFVI): totality of all hardware and software 139 components which build up the environment in which VNFs are 140 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 6. IANA Considerations 532 N/A. 534 7. Security Considerations 536 TBD. 538 8. Acknowledgments 540 Authors would like to thank Akbar Rahman for his work on previous 541 versions of this document. 543 The work in this draft has been explored under the framework of the 544 H2020 5G-DIVE project (Grant 859881). 546 9. References 548 9.1. Normative References 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, 552 DOI 10.17487/RFC2119, March 1997, 553 . 555 9.2. Informative References 557 [etsi_nvf_whitepaper] 558 ISG, E. N., "Network Functions Virtualisation (NFV). White 559 Paper 2", October 2014. 561 [I-D.aranda-sfc-dp-mobile] 562 Gutierrez, P. A. A., Gramaglia, M., Lopez, D. R., and W. 563 Haeffner, "Service Function Chaining Dataplane Elements in 564 Mobile Networks", draft-aranda-sfc-dp-mobile-04 (work in 565 progress), June 2017. 567 [I-D.ietf-sfc-use-case-mobility] 568 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D. R., 569 and J. Uttaro, "Service Function Chaining Use Cases in 570 Mobile Networks", draft-ietf-sfc-use-case-mobility-09 571 (work in progress), January 2019. 573 [onf_sdn_architecture] 574 (ONF), O. N. F., "SDN Architecture (Issue 1.1), ONF TR- 575 521", February 2016. 577 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 578 Chaining (SFC) Architecture", RFC 7665, 579 DOI 10.17487/RFC7665, October 2015, 580 . 582 Appendix A. 4G (LTE) 584 This annex includes a high level summary of the 3GPP EPS 585 architecture, commonly referred to as 4G (LTE), detailing both the 586 EPC (core) and the RAN (access) parts. 588 The EPS architecture and some of its standardized interfaces are 589 depicted in Figure 5. The EPS provides IP connectivity to user 590 equipment (UE) (i.e., mobile nodes) and access to operator services, 591 such as global Internet access and voice communications. The EPS 592 comprises the core network -- called Evolved Packet Core (EPC) -- and 593 different radio access networks: the 3GPP Access Network (AN), the 594 Untrusted non-3GPP AN and the Trusted non-3GPP AN. There are 595 different types of 3GPP ANs, with the evolved UMTS Terrestrial Radio 596 Access Network (E-UTRAN) as the most advanced one. QoS is supported 597 through an EPS bearer concept, providing bindings to resource 598 reservation within the network. 600 The evolved NodeB (eNB), the Long Term Evolution (LTE) base station, 601 is part of the access network that provides radio resource 602 management, header compression, security and connectivity to the core 603 network through the S1 interface. In an LTE network, the control 604 plane signaling traffic and the data traffic ar handled separately. 605 The eNBs transmit the control traffic and data traffic separately via 606 two logically separate interfaces. 608 The Home Subscriber Server, HSS, is a database that contains user 609 subscriptions and QoS profiles. The Mobility Management Entity, MME, 610 is responsible for mobility management, user authentication, bearer 611 establishment and modification and maintenance of the UE context. 613 The Serving gateway, S-GW, is the mobility anchor and manages the 614 user plane data tunnels during the inter-eNB handovers. It tunnels 615 all user data packets and buffers downlink IP packets destined for 616 UEs that happen to be in idle mode. 618 The Packet Data Network (PDN) Gateway, P-GW, is responsible for IP 619 address allocation to the UE and is a tunnel endpoint for user and 620 control plane protocols. It is also responsible for charging, packet 621 filtering, and policy-based control of flows. It interconnects the 622 mobile network to external IP networks, e.g. the Internet. 624 In this architecture, data packets are not sent directly on an IP 625 network between the eNB and the gateways. Instead, every packet is 626 tunneled over a tunneling protocol - the GPRS Tunneling Protocol (GTP 627 over UDP/IP. A GTP path is identified in each node with the IP 628 address and a UDP port number on the eNB/gateways. The GTP protocol 629 carries both the data traffic (GTP-U tunnels) and the control traffic 630 (GTP-C tunnels). Alternatively Proxy Mobile IP (PMIPv6) is used on 631 the S5 interface between S-GW and P-GW. 633 In addition to the above basic functions and entities, there are also 634 additional features being discussed by the 3GPP that are relevant 635 from a network virtualization viewpoint. One example is the Traffic 636 Detection Function (TDF), which can be used by the P-GW, and in 637 general by the whole transport network, to decide how to forward the 638 traffic. In a virtualized infrastructure, this kinf of information 639 can be used to elastic and dynamically adapt the network capabilities 640 to the traffic nature and volume. 642 +---------------------------------------------------------+ 643 | PCRF | 644 +-----------+--------------------------+----------------+-+ 645 | | | 646 +----+ +-----------+------------+ +--------+-----------+ +-+-+ 647 | | | +-+ | | Core Network | | | 648 | | | +------+ |S|__ | | +--------+ +---+ | | | 649 | | | |GERAN/|_|G| \ | | | HSS | | | | | | 650 | +-----+ UTRAN| |S| \ | | +---+----+ | | | | E | 651 | | | +------+ |N| +-+-+ | | | | | | | x | 652 | | | +-+ /|MME| | | +---+----+ | | | | t | 653 | | | +---------+ / +---+ | | | 3GPP | | | | | e | 654 | +-----+ E-UTRAN |/ | | | AAA | | | | | r | 655 | | | +---------+\ | | | SERVER | | | | | n | 656 | | | \ +---+ | | +--------+ | | | | a | 657 | | | 3GPP AN \|SGW+----- S5---------------+ P | | | l | 658 | | | +---+ | | | G | | | | 659 | | +------------------------+ | | W | | | I | 660 | UE | | | | | | P | 661 | | +------------------------+ | | +-----+ | 662 | | |+-------------+ +------+| | | | | | n | 663 | | || Untrusted +-+ ePDG +-S2b---------------+ | | | e | 664 | +---+| non-3GPP AN | +------+| | | | | | t | 665 | | |+-------------+ | | | | | | w | 666 | | +------------------------+ | | | | | o | 667 | | | | | | | r | 668 | | +------------------------+ | | | | | k | 669 | +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s | 670 | | +------------------------+ | | | | | | 671 | | | +-+-+ | | | 672 | +--------------------------S2c--------------------| | | | 673 | | | | | | 674 +----+ +--------------------+ +---+ 676 Figure 5: EPS (non-roaming) architecture overview 678 Appendix B. 5G 680 TBD. This section will include a description of main 5G building 681 blocks. 683 Authors' Addresses 685 Carlos J. Bernardos 686 Universidad Carlos III de Madrid 687 Av. Universidad, 30 688 Leganes, Madrid 28911 689 Spain 691 Phone: +34 91624 6236 692 Email: cjbc@it.uc3m.es 693 URI: http://www.it.uc3m.es/cjbc/ 695 Alain Mourad 696 InterDigital Europe 698 Email: Alain.Mourad@InterDigital.com 699 URI: http://www.InterDigital.com/