SFC WG CJ. Bernardos Internet-Draft UC3M Intended status: Informational A. Rahman Expires: March 7, 2019 A. Mourad InterDigital September 3, 2018 Service Function Chaining Use Cases in Fog RAN draft-bernardos-sfc-fog-ran-04 Abstract Fog Radio Access Networks (RAN) refers to the part of the RAN that is virtualized at the very edge of the network, even at the end-user device. Fog RAN support is considered critical for the 5G mobile network architectures currently being developed in various research, standardization and industry forums. Since fog RAN builds on top of virtualization and can involve several virtual functions running on different virtualized resources, Service function chaining (SFC) support for the fog RAN will be critical. This document describes the overall fog RAN approach and also gives some use cases. Finally it proposes some requirements to be considered in the development of the SFC architecture and related protocols. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 7, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Bernardos, et al. Expires March 7, 2019 [Page 1] Internet-Draft Fog RAN SFC September 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Fog RAN Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Applicability of SFC to Fog RAN . . . . . . . . . . . . . . . 8 5. Fog RAN requirements . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. 4G (LTE) . . . . . . . . . . . . . . . . . . . . . . 14 Appendix B. 5G . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The telecommunications sector is experiencing a major revolution that will shape the way networks and services are designed and deployed for the next decade. We are witnessing an explosion in the number of applications and services demanded by users, which are now really capable of accessing them on the move. In order to cope with such a demand, some network operators are looking at the cloud computing paradigm, which enables a potential reduction of the overall costs by outsourcing communication services from specific hardware in the operator's core to server farms scattered in data centers. These services have different characteristics if compared with conventional IT services that have to be taken into account in this cloudification process. Also the transport network is affected in that it is evolving to a more sophisticated form of IP architecture with trends like separation of control and data plane traffic, and more fine- grained forwarding of packets (beyond looking at the destination IP address) in the network to fulfill new business and service goals. Virtualization of functions also provides operators with tools to deploy new services much faster, as compared to the traditional use Bernardos, et al. Expires March 7, 2019 [Page 2] Internet-Draft Fog RAN SFC September 2018 of monolithic and tightly integrated dedicated machinery. As a natural next step, mobile network operators need to re-think how to evolve their existing network infrastructures and how to deploy new ones to address the challenges posed by the increasing customers' demands, as well as by the huge competition among operators. All these changes are triggering the need for a modification in the way operators and infrastructure providers operate their networks, as they need to significantly reduce the costs incurred in deploying a new service and operating it. Some of the mechanisms that are being considered and already adopted by operators include: sharing of network infrastructure to reduce costs, virtualization of core servers running in data centers as a way of supporting their load- aware elastic dimensioning, and dynamic energy policies to reduce the monthly electricity bill. However, this has proved to be tough to put in practice, and not enough. Indeed, it is not easy to deploy new mechanisms in a running operational network due to the high dependency on proprietary (and sometime obscure) protocols and interfaces, which are complex to manage and often require configuring multiple devices in a decentralized way. Network function virtualization (NFV) [etsi_nvf_whitepaper] and software defined networking (SDN) [onf_sdn_architecture] are changing the way the telecommunications sector will deploy, extend and operate their networks. In this document we focus on one particular application of network softwarization: the radio access network (RAN), and in particular, how to run RAN functions on dynamic virtual resources very close to the users, the so-called Fog. We analyze the applicability of the SFC architecture to the Fog RAN use case. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. While [RFC2119] describes interpretations of these key words in terms of protocol specifications and implementations, they are used in this document to describe requirements for the SFC mechanisms to efficiently enable fog RAN. The following terms used in this document are defined by the ETSI NVF ISG, the ONF and the IETF: NFV Infrastructure (NFVI): totality of all hardware and software components which build up the environment in which VNFs are deployed Bernardos, et al. Expires March 7, 2019 [Page 3] Internet-Draft Fog RAN SFC September 2018 NFV Management and Orchestration (NFV-MANO): functions collectively provided by NFVO, VNFM, and VIM. NFV Orchestrator (NFVO): functional block that manages the Network Service (NS) lifecycle and coordinates the management of NS lifecycle, VNF lifecycle (supported by the VNFM) and NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity. OpenFlow protocol (OFP): allowing vendor independent programming of control functions in network nodes. Service Function (SF): a function that is responsible for specific treatment of received packets (e.g., firewall, load balancer). Service Function Chain (SFC): for a given service, the abstracted view of the required service functions and the order in which they are to be applied. This is somehow equivalent to the Network Function Forwarding Graph (NF-FG) at ETSI. Service Function Path (SFP): the selection of specific service function instances on specific network nodes to form a service graph through which an SFC is instantiated. Virtualized Infrastructure Manager (VIM): functional block that is responsible for controlling and managing the NFVI compute, storage and network resources, usually within one operator's Infrastructure Domain. Virtualized Network Function (VNF): implementation of a Network Function that can be deployed on a Network Function Virtualisation Infrastructure (NFVI). Virtualized Network Function Manager (VNFM): functional block that is responsible for the lifecycle management of VNF. 3. Fog RAN Overview Virtualization is invading all domains of the E2E 5G network, including the access, as a mean to achieve the necessary flexibility in support of the E2E slicing concept. The ETSI NFV framework is the cornerstone for making virtualization such a promising technology that can be matured in time for 5G. Typically, virtualization has been mostly envisaged in the core network, where sophisticated data centers and clouds provided the right substrate. And mostly, the framework focused on virtualizing network functions, so called VNFs (virtualized network functions), which were somewhat limited to functions that are delay tolerant, typically from the core and Bernardos, et al. Expires March 7, 2019 [Page 4] Internet-Draft Fog RAN SFC September 2018 aggregation transport. Yet in the access, virtualization of RAN functions could still be envisaged as one step forward for the Cloud- RAN concept, assuming an extremely low latency fronthaul transport (typically over fiber) and again limiting to those RAN functions which delay requirements match for execution in a virtualized environment. As the community has recently been developing the 5G applications and their technical requirements, it has become clear that certain applications would require very low latency which is extremely challenging and stressing for the network to deliver through a pure centralized architecture. The need to provide networking, computing, and storage capabilities closer to the users has therefore emerged, leading to what is known today as the concept of intelligent edge. ETSI has been the first to address this need recently by developing the framework of mobile edge computing (MEC). Such an intelligent edge could not be envisaged without virtualization. Beyond applications, it raises a clear opportunity for networking functions to execute at the edge benefiting from inherent low latencies. Being in close proximity to the access, the edge becomes thus an attractive place for hosting C-RAN functions in particular, which could also be envisaged virtualized thanks to the virtualization capabilities now available at the edge. Transport and core networking functions could also take advantage of such a hosting environment, thus saving bandwidth in their respective domains and offering local breakout options where required. Furthermore, a rich set of context information from the RAN but also from other network domains could be offered as services through the edge for applications to consume and hence optimize their behavior or key performance indicators (KPIs). Whilst it is appreciated the particular challenge for the intelligent edge concept in dealing with mobile users, the edge virtualization substrate has been largely assumed to be fixed or stationary. Although little developed, the intelligent edge concept is being extended further to scenarios where for example the edge computing substrate is on the move, e.g., on-board a car or a train, or that it is distributed further down the edge, even integrating resources from different stakeholders, into what is known as the fog. The challenges and opportunities for such extensions of the intelligent edge remain an exciting area of future research. The computing and virtualization capabilities available down into the fog are of particular advantage to the virtualized-RAN/cloud-RAN, leading to what we refer to as "Fog RAN". Virtual networking functions (VNFs) related to the RAN may execute in the fog. The close proximity of the fog to the end user devices opens new Bernardos, et al. Expires March 7, 2019 [Page 5] Internet-Draft Fog RAN SFC September 2018 possibilities for extending the scope of virtual RAN (VRAN) functions from just access nodes so far to end user devices, so that functions traditionally running on the end user devices may be moved to the fog. In addition, an additional tier of intelligent VRAN functions could be envisaged to run across other functions of various nodes or devices and from different radio access technologies (RATs), supporting tight coordination between these nodes and devices, and enabling convergence between the RATs. VNFs from the transport and core could also be hosted in the fog so as to save bandwidth in their respective domains. Figure 1 shows a diagram representing the fog RAN concept. The fog is composed by virtual resources on top of heterogeneous resources available at the edge and even further in the RAN and end-user devices. These resources are therefore owned by different stakeholders who collaboratively form a single hosting environment for the VNFs to run. As an example, virtual resources provided to the fog might be running on eNBs, APs, at micro data centers deployed in shopping malls, cars, trains, etc. The fog is connected to data centers deeper into the network architecture (at the edge ir the core). On the top part of the figure, an example of user and control plane VNFs is shown. User plane VNFs are represented as "fx", and control ones as "ctrlx". Depending on the functionality implemented by these VNFs and the service requirements, these VNFs would be mapped (i.e., instantiated) differently to the physical resouces (as described in [I-D.aranda-sfc-dp-mobile]). Bernardos, et al. Expires March 7, 2019 [Page 6] Internet-Draft Fog RAN SFC September 2018 -------- --------- --------- control | ctr1 |........................| ctrl2 |...| ctrl3 | plane -------- --------- --------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ------ ------ ------ .| f3 |.........| f5 |.....| f6 | ------ ------ . ------ ------ ------ user | f1 |.......| f2 |. . plane ------ ------ . ------ . .| f4 |............. ------ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +--------------------------------+ +-------------------+ | ------- -------- -------- | | ---------- | | | | | | | | | | ---------- | | | | @UE | | @car | | @eNB | | | ---------- | | | | ------- -------- -------- | | | Data | | | | | | | | Center | | - | | -------- Heterogeneous ------- | | | (DC) |- | phy | | | computing | | | | ---------- | infra | |@train| devices | @AP | |==| ---------- | | -------- forming ------- | | ---------- | | | the fog | | ---------- | | | | --------- ------------ | | | Data | | | | | | | | | | | | Center | | - | | | @mall | | @localDC | | | | (DC) |- | | --------- ------------ | | ---------- | | FOG | | CLOUD | +--------------------------------+ +-------------------+ <--------- fog and edge -----------------> <--- edge & central cloud ---> Figure 1: Fog RAN The fog is also well suited to offer a rich set of context information noticeably (but not only) from the RAN that could be collected from the various RATs co-existing in the same service area. This information can be obtained either from networking resources (e.g., nodes and devices) or functions, some of which might be hosted in the fog. Such information may be exposed through services running in the fog or in the edge, for applications on top to consume and hence optimize their performance or behavior. The fog or edge will therefore be in charge of collecting and publishing context information towards network applications as well as end user/3rd party applications. This is accomplished by the so-called "services" which follow the concept of ETSI MEC ISG services and may run in the fog. Applications may also run directly in the fog and subscribe to one or more services provided in the fog. These fog applications Bernardos, et al. Expires March 7, 2019 [Page 7] Internet-Draft Fog RAN SFC September 2018 could also offer services to other applications residing inside the fog or outside, e.g., in the edge or central cloud. This enables different kinds of Over-The-Top (OTT) applications to utilize the RAN context information available at the fog. 4. Applicability of SFC to Fog RAN For a given service, the abstracted view of the required service functions and the order in which they are to be applied is called a service function chain (SFC), which is called network function forwarding graph (NF-FG) in ETSI. An SFC is instantiated through selection of specific service function instances on specific network nodes to form a service graph: this is called a service function path (SFP). The service functions may be applied at any layer within the network protocol stack (network layer, transport layer, application layer, etc.). [RFC7665] describes the architecture for the specification, creation, and ongoing maintenance of service function chains (SFCs) in a network. The SFC architecture is composed of the following logical components: classifiers, service function forwarders (SFFs), service functions (SFs), and SFC proxies. These components are interconnected using the SFC encapsulation, as shown in Figure 2. o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . +--------------+ +------------------~~~ . | Service | SFC | Service +---+ +---+ . |Classification| Encapsulation | Function |sf1|...|sfn| +---->| Function |+---------------->| Path +---+ +---+ . +--------------+ +------------------~~~ . SFC-enabled Domain o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2: SFC architecture An overview of how the SFC logical components interact after the initial classification is also shown in Figure 3 (reproduced from [RFC7665] for completeness). Bernardos, et al. Expires March 7, 2019 [Page 8] Internet-Draft Fog RAN SFC September 2018 +----------------+ +----------------+ | SFC-aware | | SFC-unaware | |Service Function| |Service Function| +-------+--------+ +-------+--------+ | | SFC Encapsulation No SFC Encapsulation | SFC | +---------+ +----------------+ Encapsulation +---------+ |SFC-Aware|-----------------+ \ +------------|SFC Proxy| | SF | ... ----------+ \ \ / +---------+ +---------+ \ \ \ / +-------+--------+ | SF Forwarder | | (SFF) | +-------+--------+ | SFC Encapsulation | ... SFC-enabled Domain ... | Network Overlay Transport | _,....._ ,-' `-. / `. | Network | `. / `.__ __,-' `'''' Figure 3: SFC architecture components There are different use cases for service function chaining in mobile networks. [I-D.ietf-sfc-use-case-mobility] describes in general how to use SFC for mobile networks focusing on the core functions, while [I-D.aranda-sfc-dp-mobile] looks more at RAN aspects. This document focuses on the specific use case of applying SFC concepts to the fog RAN environment, which is characterized mainly by: o The VNFs being chained implement mostly RAN functionality. The Cloud RAN (C-RAN) approach centralizes baseband processing and network resource allocation (which are today functions executed in a distributed way at the access nodes, such as eNBs). The strict latency and bandwidth requirements imposed by C-RAN triggered the evolution of the virtualization of the access infrastructure to the concept of RAN as a Service, where the centralization (i.e. Bernardos, et al. Expires March 7, 2019 [Page 9] Internet-Draft Fog RAN SFC September 2018 function virtualization in a data center) of processing and management in mobile networks is flexible and adapted to the actual service requirements and the network conditions. This is also referred to as flexible functional split of the radio protocol stack. Up to now, RAN virtualization approaches have only considered offloading of computation tasks in central clouds or regional data centers close to the network aggregation points. With fog RAN, virtualization resources are placed closer to users, from edge computing to fog computing at user devices, leveraging micro data centers at user premises, thus reducing end-to-end latency. o Virtualizing RAN functions at the fog could also enable new optimizations when information of (or available at) the access is used. Examples of this information include: RAN measured parameters, location information, etc. This information can be used for example to jointly optimize multiple RATs. o The fog computing environment can also be used to virtualize functions from the end-user devices, not only from the RAN. This can help facilitating a better convergence of multiple access technologies. Fog RAN implementations will benefit from applying SFC concepts as virtual RAN functions will be executed on virtual resources from different stakeholders, meaning different data centers managed by different entities. In this environment, SFC encapsulation can be used to ensure proper data processing. Figure 4 shows an example of scenario of application of SFC in the fog RAN. On the top part we show a UE connected to the network. The eNB functionality is actually split, so part of it (e.g., RLC, PDCP and RRC) runs virtualized in the fog, while the rest (e.g., MAC and PHY) stay at the remote radio head (RRH). Other mobile network RAN functionality can also be running virtualized in the fog, such as a local virtual MME, multi-RAT authentication and RAT selection mechanisms, offloading solutions (such as local vEPCs), etc. The rest of the mobile network functions (see Appendix A for a short overview) runs in the core. On the bottom part of the figure we show a potential mapping of the virtual functions to the physical resources that compose the fog. SFC mechanisms would be used to interconnect the different functions in the right order and meeting the requirements (latency, compute, etc) needed. Bernardos, et al. Expires March 7, 2019 [Page 10] Internet-Draft Fog RAN SFC September 2018 +---------------------------------------------+ ------ | FOG -------------- | | UE | | ------------- -------- | RAT selec. | | --+--- | | multi-RAT | | vMME | -------------- | v | | auth. | -------- " | v | ------------- "------- " | | | " .| RRC | " | -+----- | ------- " -------- ."------- ----------- | | RRH |====| | RLC |.".| PDCP |. " " .| offload | | ------- | ------- " ---"---- ." " . ----------- | +-----+ | " " " . " . " " | | | | " " " "..(data)...............==| EPC | | " " " " " " " | | | +----"----"----"------"-----"-------"----"----+ +-----+ " " " " " " " - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mapping of " " " " " " " VNFs to phy +----"----"----"------"-----"-------"----"----+ resources | " " " " " " " | | ---"----"----"---- "------"--- ---"----"--- | | | " auth " | | vMME " | | RAT " | | | | RLC PDCP | | RRC | | sel offl | | | | @eNB | | @mall | | @AP | | | ------------------ ----------- ------------ | | | +---------------------------------------------+ <--- phy ---><-------------- fog and edge -----------------><-core-> Figure 4: Fog RAN SFC example scenario Since the virtual resources where virtual functions are potentially hosted on infrastructure managed by different entities, SFC encapsulation is a key tool to enable the fog RAN scenario. In the next section we enumerate some initial requirements to be considered, that will be extended and further developed in subsequent versions of this document. 5. Fog RAN requirements The following requirements should be considered during SFC architecture and related protocol design to ensure that SFC can fully support fog RAN functionality: REQ-R01: SFC MUST support user traffic flows with very low delay budgets (e.g., less than 1ms) at the edge of the network. Bernardos, et al. Expires March 7, 2019 [Page 11] Internet-Draft Fog RAN SFC September 2018 REQ-R02: SFC MUST support mobility of Service Functions (e.g., edge network node containing SF that is located on a high speed train). REQ-R03: SFC MUST support Service Functions (e.g., MEC) that are located at the edge of the network and that perform L7-Application processing very early in the forwarding path. REQ-R04: SFC MUST support metadata used to exchange information about the network and virtual resources status, so it can be used to decide about updates of the service function path. REQ-R05: SFC MUST support metadata with context information (e.g., location, RAN information, etc.) from fog nodes (e.g., access nodes and end user devices) from multiple RATs. REQ-R06: SFC MUST support chaining functions hosted at heterogeneous hosts (in terms of computing resources, availability, mobility, and other policies). REQ-R07: SFC MUST support chaining functions hosted across various geographically spread physical networking and computing resources. REQ-R08: SFC MUST support a secure and dynamic discovery of functions, potentially belonging to different domains. REQ-R09: SFC MUST support dynamic mobility of the hosts where the service functions run, e.g., when the host is a moving device (user terminal, car, train, etc.). REQ-R10: SFC OAM MUST support monitoring of SFs, SFFs and SFC proxies deployed on mobile platforms. REQ-R11: SFC MUST support configuration mechanisms for mobile devices to be part of an SFC. REQ-R12: SFC MUST support volatile resources (SFs), allowing for backup mechanisms in case a SF becomes unavailable due to the volatility of the resource. REQ-RX: More TBD... 6. IANA Considerations N/A. Bernardos, et al. Expires March 7, 2019 [Page 12] Internet-Draft Fog RAN SFC September 2018 7. Security Considerations TBD. 8. Acknowledgments The work in this draft will be further developed and explored under the framework of the H2020 5G-CORAL project (Grant 761586). 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 9.2. Informative References [etsi_nvf_whitepaper] "Network Functions Virtualisation (NFV). White Paper 2", October 2014. [I-D.aranda-sfc-dp-mobile] Gutierrez, P., Gramaglia, M., Lopez, D., and W. Haeffner, "Service Function Chaining Dataplane Elements in Mobile Networks", draft-aranda-sfc-dp-mobile-04 (work in progress), June 2017. [I-D.ietf-sfc-use-case-mobility] Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and J. Uttaro, "Service Function Chaining Use Cases in Mobile Networks", draft-ietf-sfc-use-case-mobility-08 (work in progress), May 2018. [onf_sdn_architecture] "SDN Architecture (Issue 1.1), ONF TR-521", February 2016. [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . Bernardos, et al. Expires March 7, 2019 [Page 13] Internet-Draft Fog RAN SFC September 2018 Appendix A. 4G (LTE) This annex includes a high level summary of the 3GPP EPS architecture, commonly referred to as 4G (LTE), detailing both the EPC (core) and the RAN (access) parts. The EPS architecture and some of its standardized interfaces are depicted in Figure 5. The EPS provides IP connectivity to user equipment (UE) (i.e., mobile nodes) and access to operator services, such as global Internet access and voice communications. The EPS comprises the core network -- called Evolved Packet Core (EPC) -- and different radio access networks: the 3GPP Access Network (AN), the Untrusted non-3GPP AN and the Trusted non-3GPP AN. There are different types of 3GPP ANs, with the evolved UMTS Terrestrial Radio Access Network (E-UTRAN) as the most advanced one. QoS is supported through an EPS bearer concept, providing bindings to resource reservation within the network. The evolved NodeB (eNB), the Long Term Evolution (LTE) base station, is part of the access network that provides radio resource management, header compression, security and connectivity to the core network through the S1 interface. In an LTE network, the control plane signaling traffic and the data traffic ar handled separately. The eNBs transmit the control traffic and data traffic separately via two logically separate interfaces. The Home Subscriber Server, HSS, is a database that contains user subscriptions and QoS profiles. The Mobility Management Entity, MME, is responsible for mobility management, user authentication, bearer establishment and modification and maintenance of the UE context. The Serving gateway, S-GW, is the mobility anchor and manages the user plane data tunnels during the inter-eNB handovers. It tunnels all user data packets and buffers downlink IP packets destined for UEs that happen to be in idle mode. The Packet Data Network (PDN) Gateway, P-GW, is responsible for IP address allocation to the UE and is a tunnel endpoint for user and control plane protocols. It is also responsible for charging, packet filtering, and policy-based control of flows. It interconnects the mobile network to external IP networks, e.g. the Internet. In this architecture, data packets are not sent directly on an IP network between the eNB and the gateways. Instead, every packet is tunneled over a tunneling protocol - the GPRS Tunneling Protocol (GTP over UDP/IP. A GTP path is identified in each node with the IP address and a UDP port number on the eNB/gateways. The GTP protocol carries both the data traffic (GTP-U tunnels) and the control traffic Bernardos, et al. Expires March 7, 2019 [Page 14] Internet-Draft Fog RAN SFC September 2018 (GTP-C tunnels). Alternatively Proxy Mobile IP (PMIPv6) is used on the S5 interface between S-GW and P-GW. In addition to the above basic functions and entities, there are also additional features being discussed by the 3GPP that are relevant from a network virtualization viewpoint. One example is the Traffic Detection Function (TDF), which can be used by the P-GW, and in general by the whole transport network, to decide how to forward the traffic. In a virtualized infrastructure, this kinf of information can be used to elastic and dynamically adapt the network capabilities to the traffic nature and volume. +---------------------------------------------------------+ | PCRF | +-----------+--------------------------+----------------+-+ | | | +----+ +-----------+------------+ +--------+-----------+ +-+-+ | | | +-+ | | Core Network | | | | | | +------+ |S|__ | | +--------+ +---+ | | | | | | |GERAN/|_|G| \ | | | HSS | | | | | | | +-----+ UTRAN| |S| \ | | +---+----+ | | | | E | | | | +------+ |N| +-+-+ | | | | | | | x | | | | +-+ /|MME| | | +---+----+ | | | | t | | | | +---------+ / +---+ | | | 3GPP | | | | | e | | +-----+ E-UTRAN |/ | | | AAA | | | | | r | | | | +---------+\ | | | SERVER | | | | | n | | | | \ +---+ | | +--------+ | | | | a | | | | 3GPP AN \|SGW+----- S5---------------+ P | | | l | | | | +---+ | | | G | | | | | | +------------------------+ | | W | | | I | | UE | | | | | | P | | | +------------------------+ | | +-----+ | | | |+-------------+ +------+| | | | | | n | | | || Untrusted +-+ ePDG +-S2b---------------+ | | | e | | +---+| non-3GPP AN | +------+| | | | | | t | | | |+-------------+ | | | | | | w | | | +------------------------+ | | | | | o | | | | | | | | r | | | +------------------------+ | | | | | k | | +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s | | | +------------------------+ | | | | | | | | | +-+-+ | | | | +--------------------------S2c--------------------| | | | | | | | | | +----+ +--------------------+ +---+ Figure 5: EPS (non-roaming) architecture overview Bernardos, et al. Expires March 7, 2019 [Page 15] Internet-Draft Fog RAN SFC September 2018 Appendix B. 5G TBD. This section will include a description of main 5G building blocks. Authors' Addresses Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Akbar Rahman InterDigital Communications, LLC 1000 Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 Canada Email: Akbar.Rahman@InterDigital.com URI: http://www.InterDigital.com/ Alain Mourad InterDigital Europe Email: Alain.Mourad@InterDigital.com URI: http://www.InterDigital.com/ Bernardos, et al. Expires March 7, 2019 [Page 16]