Virtualisation of Mobile Core Network Use Case
draft-king-vnfpool-mobile-use-case-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Daniel King , Marco Liebsch , Peter Willis , Jeong-dong Ryoo | ||
| Last updated | 2014-02-14 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-king-vnfpool-mobile-use-case-00
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