Network Working Group D. King Internet-Draft Lancaster University Intended status: Standards Track M. Liebsch Expires: August, 2014 NEC P. Willis BT J. Ryoo ETRI February 14, 2014 Virtualisation of Mobile Core Network Use Case draft-king-vnfpool-mobile-use-case-00 Abstract Accessing the Internet via mobile data services using smartphones, tablets, and mobile data USB dongles has increased rapidly, as high-speed packet data networks provide the bandwidth required for today's Internet applications. Mobile operators will continue to evolve their core networks to the Long Term Evolution (LTE) Evolved Packet Core (EPC) to meet the mobility, latency and bandwidth requirements for mobile data users. Network Functions Virtualization (NFV) looks to reduce mobile core network complexity and related operational issues by leveraging standard IT virtualization technologies and consolidate different types of network equipment onto commodity hardware. This use case document provides resiliency requirements for virtualization of the LTE mobile core network, known as virtualized EPC (vEPC). 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 http://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 August, 2014. King, et al. Expires August 1, 2014 [Page 1] Internet-Draft Mobile Core Network Use Case February 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 1.1 Operator Benefits of Virtualization.........................3 2. Terminology....................................................3 3. Virtual Evolved Packet Core (vEPC).............................4 3.1 Mobile Core Network Components..............................4 3.1.1 Mobile Network Nodes...................................5 3.1.2 Mobile Network Functions...............................5 3.2 Resiliency Requirements for the vEPC........................5 3.2.1 Handling Unplanned Traffic Peaks.......................6 3.2.2 Scaling and Load Balancing of Resources and Functions..7 3.2.3 vEPC Failure Handling..................................9 3.3 Reliable vEPC Service Function Chains (SFC).................10 3.4 Applicability of Virtual Network Function Pool (VNFPool)....10 4. IANA Considerations............................................11 5. Security Considerations........................................11 6. References.....................................................11 6.1 Normative References.......................................11 6.2 Informative References.....................................11 Authors' Addresses................................................11 1. Introduction Mobile operators have deploying Long Term Evolution (LTE) Evolved Packet Core (EPC) to meet the mobility, latency and bandwidth requirements for a variety of mobile data users. The EPC is the latest evolution of the [3GPP-R8] core network architecture, and is based on IP. King, et al. Expires August 1, 2014 [Page 2] Internet-Draft Mobile Core Network Use Case February 2014 The EPC architecture is said to have a "flat architecture" with minimal components and functions. Principally the design is intended to minimise the number of function nodes required and protocol conversation of mobile data traffic. However, EPC elements are bespoke stand-alone hardware (i.e., different boxes for different functions). Network operators have identified that this approach costly and inflexible. The ETSI Network Functions Virtualization (NFV) Industry Steering Group (ISG) published a set of use cases [NFV-ISG-UC]. One key use case described the Virtualisation of Mobile Core Network and IP Multimedia Subsystem (IMS), known as the vEPC. The NFV approach takes the EPCs functional elements and runs them as software instances (Virtual Appliances) on high-volume industry- standard generic servers. This approach has number of advantages including: o Reducing: Cost, Power, Space and Complexity. o Increasing: Flexibility, Scalability and Consolidation. This use case document describes the vEPC architecture, functional components and defines the resiliency requirements for the vEPC use case. 1.1 Operator Benefits of Virtualization There are a number of Operator Benefits which can be achieved through virtualization of the EPC, these include: o Economies of scale through common virtualized platform o Enables a Multi-Service (MS) platform o Reducing time to market to offer new services o Uniformity of operations o Simplified high availability o Simplified disaster recovery o Preferred test and diagnostic tools embedded o Simplified in-service software upgrades o Reduced training o Simplified planning and provisioning o Automation of installation o Reduced site visits 2. Terminology Evolved Packet Core (EPC): is an evolution of the 3GPP GPRS system characterized by a higher-data-rate, lower-latency, packet- optimized system. King, et al. Expires August 1, 2014 [Page 3] Internet-Draft Mobile Core Network Use Case February 2014 Home Subscriber Server (HSS): a database that contains user-related and subscriber-related information. It also provides support functions in mobility management, call and session setup, user authentication and access authorization. Mobility Management Entity (MME) provides the signalling related to mobility and security for Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) access. Packet Data Network Gateway (PDN GW): is the point of interconnect between the EPC and the external IP networks. Policy and Charging Rules Function (PCRF): provides policy and service control and the appropriate interfaces towards the mobile charging and billing systems. Serving GW (SGW): is the interconnect between the radio-side and the EPC. The SGW serves the User Equipment (UE) by routing the incoming and outgoing IP packets. 3. Virtual Evolved Packet Core (vEPC) Deploying and operating mobile core network functions on commodity hardware resources may provide significant network usage efficiency and reductions in operational expenditure. Increased automation would also accommodate scaling of voice and mobile data demands. The ETSI NFV use case [NFV-ISG-UC] describes requirements for server and packet gateways used for Packet Data Network (PDN) connections and IP Multimedia Subsystem (IMS) session (see Figure 1: Virtualized mobile core network and IMS). Typically mobile services are typically time dependent and may require a large number of computing resources in proportion to the number of users and/or service requests. Therefore it is desirable to scale them according to their specific computing requirements. The virtualization can be applied to the Evolved Packet Core (EPC) and the IMS to provide end to end service with service availability and resilience. 3.1 Mobile Core Network Components Within the mobile core network a number of nodes and specific functions are currently provided by dedicated hardware and software for mobile voice and data services, these are described in more detail in the following sub-sections. King, et al. Expires August 1, 2014 [Page 4] Internet-Draft Mobile Core Network Use Case February 2014 3.1.1 Mobile Network Nodes The EPC is comprised of a variety of nodes, these include: o Mobility Management Entity (MME); o Serving Gateway (SGW); o Packet Data Network Gateway (PDN-GW); o Home Subscriber Server (HSS). 3.1.2 Mobile Network Functions The EPC provides a number of functions to manage mobile user traffic, these include: o Firewall (FW); o Policy Control (PC); o Network Address Translation (NAT); o Load Balancing (LB); o Deep Packet Inspection (DPI); o TCP Optimization of Traffic Flows; o HTTP Enrichment of Traffic Flows; o Video Stream Optimization; o Video Content Caching. 3.2 vEPC Resiliency Requirements When those virtualized service nodes(e.g., virtualized S/P-GW and IMS functions) are failed or overloaded, dynamic relocation of those VSNs can be performed, the relocation of the managed sessions and/or connections must be accordingly managed. It also should be noted in [NFV-REL-REQ] that the traffic in the original VSN must be routed to the new location and it is desirable that the movement of the VSN is transparent to other VSN and or physical network entities such as client application on the UE. That is to say the other VSNs do not require to take any special action to this movement. King, et al. Expires August 1, 2014 [Page 5] Internet-Draft Mobile Core Network Use Case February 2014 +----------------+ +---------------------------------+ | vEPC | | vIMS | | | | | | +---------+ | | +----------+ | | | | | | | | | | | vP/SGW +---+-+-| +--+ vS-CSCF | | | | | | | | | | | | | +---------+ | | | +--------+ | +----------+ | |Overload/Failure| |-+-| +---| Overload/Failure | | | | | P-CSCF | | | | ++++| +++++ | | +---------+ | + | +--------+ + +----------+ | | | | | + | + | | | | | vP/SGW +++++++ | +++| vS-CSCF | | | | | | | | | | | +---------+ | | +----------+ | | | | | | PDN Connection| | IMS Session | +----------------+ +---------------------------------+ Figure 1: Virtualized Mobile Core Network and IMS In this architecture, the following general resiliency requirements need to be satisfied: o Resource scaling - elastic service aware resource allocation to network functions; o State maintenance - network and network function state management during VSN relocation, replication, and resource scaling; o Monitoring/fault detection/diagnosis/recovery - appropriate mechanism for monitoring/fault detection/diagnosis/recovery of all components and their states after virtualization, e.g. VNF, hardware, hypervisor; o Service Availability - achieving the same level of service availability for the end-to-end virtualized mobile core network as in non-virtualized networks with reduced cost; o Minimum impact on other relevant functions. 3.2.1 Handling Unplanned Traffic Peaks Vendors are currently working with the Japanese Government to demonstrate the capabilities that a vEPC can have in handling unplanned traffic surges due to unforeseen circumstances: King, et al. Expires August 1, 2014 [Page 6] Internet-Draft Mobile Core Network Use Case February 2014 o A recent earthquake in Japan caused the demand for calls to increase to 150% capacity in the effected area. Calls were dropped due to the network capacity. o At the time the capacity in other areas was only 50%. In a vEPC environment the free resources from the other areas could have been used to manage this additional load. 3.2.2 Scaling and Load Balancing of Resources and Functions The Evolved Packet System (EPS) is built from logical network functions, e.g. MME, PDN Gateway, Serving Gateway and Radio Base station (evolved NodeB) which are connected through the specified architectures references points. The 3GPP standard considers load balancing between different logical network functions of the same type. For example, Radio Base stations can choose one out of multiple available MMEs according to load-based weight factors to register an attaching mobile device. Mobile network operators can dimension their network in terms of numbers of required MMEs or data gateways according to statistical figures and thorough network planning, such as busy hour call attempts (BHCA). Virtualization technology enables adding additional resources as logical network functions by means of instantiation of the relevant functions in virtual machines. The instantiation of additional virtualized PDN Gateways or MMEs requires the announcement of their availability to other network components of the EPS. New attachments can then be balanced and distributed between an increased number of available network functions. Such procedure for scale-out suits the adaptation of the EPS resources to an increasing demand with low time constraints, e.g. due to an expected increase in subscribers or traffic volume. Unexpected increase in traffic or subscribers' attempt to request mobile service can result from scheduled events, e.g. festivals, or in particular after disaster events, such as an earthquake. The latter case in particular requires the mobile network to handle service requests and traffic from a huge amount of active mobile subscribers. Communication services during disaster events are essential, not only to provide a communication platform for rescue workers, but also to allow private subscribers to communicate with relatives. Such unexpected increase in active subscribers and traffic volume should not result in dropped connections, e.g. forced disconnects to offload existing subscriber states and traffic volume. It is preferable to scale-out resources internal to a single logical network function, e.g. an MME or a PDN Gateway. The advantage of such network function-internal resources scaling is the in-dependency of and transparency to external network functions and EPC protocols. King, et al. Expires August 1, 2014 [Page 7] Internet-Draft Mobile Core Network Use Case February 2014 Functionality and resources for a virtualized Network Function (vNF) may be provisioned by the interplay of multiple virtualized Network Function Component (vNFC), whose instances map 1:1 to virtual machines. Scale-out internally to a single instance of a vNF can be accomplished by the instantiation of additional vNFC instances. Load on the vNF must then be balanced between the multiple vNFC instances (LB). Such scaling must remain transparent to external network entities. Virtual Network Function +-----------------------------+ | +--+ +----+ | <========>|LB|<--+--->|vNFC| | | +--+ | +----+ | | +----+ | +----+ | | |vNFC|<--+--->|vNFC| | | +----+ +----+ | | | +-----------------------------+ Figure 2: Composition of multiple vNFC instances to build a single vNF. Technology for vNF scaling must also provide means to scale-in and reduce the number of resources in terms of required vNFCs, which build a vNF. Some key requirements for scaling in the view of virtualized EPC network functions: o Transparency and compatibility of network functions virtualization to legacy EPS components; o Support for scale-out of virtualized Network Functions, representing additional logical EPC network functions; o Inter-working with configuration management (OSS) to configure and announce new Network Functions to the EPS; o Automation of scaling and simplified OAM; o Virtualized Network Function-internal scale-out and load balancing; o Support of scale-in and associated shut down of vNFC instances; handling of states associated with vNFCs, which are to be shut down (state depletion vs. state transfer/offload); King, et al. Expires August 1, 2014 [Page 8] Internet-Draft Mobile Core Network Use Case February 2014 o (non-critical: VM aggregation to fewer host servers, e.g. to enable host server power saving). 3.2.3 Failure Handling During vEPC deployment, various failures can occur, for instance virtual machine failure, hypervisor failure, a broken host server, failure in a datacenter's transport network infrastructure, as well as failure of network links which connect a datacenter to the global network infrastructure. It is unlikely that a single solution suits the handling of all kind of failures. Typically for today's products, function redundancy and state synchronization as well as failure detection and failover are function and implementation specific. The detection of VM or hardware failures on a host server, as well as failure of networking equipment may introduce some delay before the system initiates failover to standby or backup resources. It may not be possible for an operator to meet agreed service levels in all cases. Due to the variety of different failure reasons, detection of the failure type may be required to initiate the appropriate procedure for failover handling. Mobile operators have strong requirements to minimize the time of system outage as experiences by subscribers, hence require minimal detection and failover handling latencies. Referring to the architecture of a virtualized Network Function as depicted in Figure 2, some virtualized Network Function Components may require synchronization of states with a standby vNFC of the same kind to introduce redundancy on vNFC level. Others may not require state synchronization but simply a backup vNFC with the same functionality, as in case of failure, states can be recovered and retrieved from a different vNFC, which holds the same or a sub-set of these states. Hence, redundancy management and failover mechanisms can be vNFC- specific. Disaster events, such as an earthquake, can have impact to the availability of a larger vNF set or even to the access to a complete data center in case the data center's links to the global network infrastructure breaks. In such case, even the availability of a backup system in a globally and topologically distant data center can meet the requirement of service continuation. Seamless continuation of subscribers' services is unlikely, as it would require maintenance of state synchronization between functions being instantiated in different data centers. But solely the provisioning of backup vNFs allows subscribers to re-attach to the mobile communication system and place new calls. Handling such failover requires macroscopic indirection of the EPC reference points to a set of backup vNFs in a different data center. King, et al. Expires August 1, 2014 [Page 9] Internet-Draft Mobile Core Network Use Case February 2014 Some key requirements for failure detection and failover handling in the view of virtualized EPC network functions: o Support function-specific redundancy and failover management; o Support different kinds of redundancy for failover (state synchronization between vNFCs, state recovery at backup vNFC, state re-establishment at backup vNFC) ; o Selection of appropriate commodity hardware for backup and failover (resources availability); o Minimize state synchronization- and failover latency; o Detection of failure; o Detection of failure type and level (e.g. vNFC, hypervisor, hardware, network); o Enforcement of failover strategy according to failure type; o Automated detection and failure handling. 3.3 Reliable vEPC Service Function Chains (SFC) To be discussed. [draft-liu-sfc-use-cases-00] [draft-haeffner-sfc-use-case-mobility-00] 3.4 What does that mean for Virtual Network Function Pool (VNFPool)? For VNFPool in the view of EPC, it is to be investigated where an IETF-based generalized functional architecture and common protocol can support vEPC scaling, failure detection and handling. Such common protocol components should allow inter-working with vNFC- specific and possibly proprietary but highly efficient mechanisms for redundancy and fault management. The granularity of a VNF Pool Element (PE) [zong-vnfpool-problem-statement] may be a vNF or a vNFC. The first case assumes that a Pool Manager handles PEs with the granularity of EPC network functions (MME, PDN Gateway), hence may not be aware of vNFCs. The second case implies that vNFCs, from which a vNF is built, distribute between multiple VNF Pools. IN such case, the role of the relevant VNF Pool Managers is to be investigated. King, et al. Expires August 1, 2014 [Page 10] Internet-Draft Mobile Core Network Use Case February 2014 A VNF Pool Manager's role for load balancing between PEs is to be investigated, taking additional and independent load balancing instances for macroscopic (system-wide) load balancing within the EPS and for microscopic load balancing (between multiple vNFCs of a single logical vNF) into account. 4. IANA Considerations This document makes no IANA requests. 5. Security Considerations [To be discussed.] 6. References 6.1. Normative References 6.2. Informative References [3GPP-R8] [NFV-ISG-UC] "Network Function Virtualisation; Use Cases;", ISG NFV Use Case, June 2013. [NFV-REL-REQ] "Network Function Virtualisation Resiliency Requirements", ISG REL Requirements, June 2013. [zong-vnfpool-problem-statement] Zong, N., "Problem Statement for Reliable Virtualized Network Function (VNF) Pool", January 2014. Authors' Addresses Peter Willis British Telecom UK Email: peter.j.willis@bt.com King, et al. Expires August 1, 2014 [Page 11] Internet-Draft Mobile Core Network Use Case February 2014 Daniel King Lancaster University UK Email: d.king@lancaster.ac.uk Jeong-dong Ryoo ETRI Email: ryoo@etri.re.kr Marco Liebsch NEC Laboratories Europe Email: liebsch@neclab.eu King, et al. Expires August 1, 2014 [Page 12] Internet-Draft Mobile Core Network Use Case February 2014