Upload
trannhan
View
235
Download
2
Embed Size (px)
Citation preview
Virtualization techniques for network functions
Fabrice Guillemin, Orange Labs, OLN/CNC/NCA September 14, 2015
Virtualization and cloud 2
Introduction
Network functions are today hosted by dedicated hardware, typically high performance servers
– Evolved Packet Core function (HSS, MME, etc.) for mobile networks – Broadband access servers for fixed networks
Advantages: – high performance and reliability – centralized functions easier to monitor – the equipment provider for assistance
Drawbacks – vulnerable points in the architecture (cf. HLR breakdown in Orange
mobile network) – lack of flexibility (a few functions per server) – dependence on the equipment provider for upgrade (extra costs)
Virtualization: a possible evolution to make the architecture more flexible and less expensive (?)
Virtualization and cloud 3
Virtualization today and further possibilities for operators
Many initiatives for network function virtualization (ETSI NFV, commercial solutions by many equipment/software providers:
– virtual Evolved Packet Core (vEPC) – virtualized IMS – RAN sharing – virtualized monitoring – …
Target applications: – network function packages “hosted in the cloud”: an IMS core or a
vEPC dedicated to a client (e.g., a company) – RAN sharing between several (virtual) mobile operators – …
Solutions are provided by “usual” equipment manufacturers – software testing and bug reporting … – … but virtuous iteration loops
A more challenging approach: open source solutions
network control functions
functions impacting the data plane
Virtualization and cloud 4
An example: The Convergent Gateway (under development by BCOM)
WiFi Hotspot (public or private)
Convergent GW
Home Gateway
eNodeB
IP collect Network Internet
Backhaul Network
IP traffic, no GI functions (e.g., DPI) services in OTT mode
same address pool for the APs connected to the CGW
need for a connection between addresses and AP
pure IP, IP/MPLS, L2 or L1 possible colocation with NGPoPs
Backhaul all access technologies (fixed, WiFi, cellular) through the same gateway
all-IP design
Virtualization and cloud 5
The functional blocks of the CGW
DHCP Server
AAA
MME (LISP PxTR)
L-ANDSF1
Monitoring
vEPC
WiFi controller
switch/router (OVS) forwarding
plane
control plane
all the functions are hosted by virtual machines or containers (NFV) and are based on open source software
address allocation
authentication
mobility management
choice of the best AP
supervision of the AP
termination of GTP tunnels
Control of the WiFi AP
CGW
1ANDSF (Access Network Detection and Selection function): standardized by 3GPP (centralized version), assists the terminal to select the best AN depending upon user’s subscription (WiFi offloading)
all the functions are coupled
Virtualization and cloud 6
Some critical issues in the design of virtualization
vEPC used by BCOM: OpenAir Interface – bugs have to be progressively fixed (to be compliant with 3GPP spec) – traffic goes through VM – because of GTP tunnels
Next steps (proposed for 5G): separate control and data planes in cellular networks
– GTP-U should be handled by the data plane only – GTP-C should be hosted by separate VMs – need for a convergence function in the data plane and possibly for an
interface to configure the data plane
Same problems with WiFi controllers (openCAPWAP)
Extend to BBU (and BBU hostelling) when CGW are collocated with NGPoP (hosting OLT and BBU functions)
Need for neatly delineating control plane (GTP-C termination, access
control, etc.) and data plane (switching, packet dropping, etc.) functions
Virtualization and cloud 7
IP collect Network
Ideal design/cloud
CGW-data plane
cloud (centralized data
centers)
CGW-control plane
WiFi Hotspot (public or private)
eNodeB
eNodeB
BBU (hostel)
NGPoP
which API? (OF is too poor)
more than 200 NGPoP in Orange/France
Virtualization and cloud 8
IP collect Network
Ideal design/fog computing
CGW-data plane
fog computing (distributed data centers)
CGW-control plane
WiFi Hotspot (public or private)
eNodeB
eNodeB
BBU (hostel)
NGPoP
NGPoP enriched with CDN and other services (TURN servers, etc.) in the fog
cloud
Virtualization and cloud 9
IP collect Network
Global view of the network
WiFi Hotspot (public or private)
eNodeB
eNodeB
fog computing
facility
fog computing
facility
fog computing
facility
fog computing
facility
fog computing
facility
data centers in fog computing facilities are smaller than those in
clouds
cloud
NGPoP
Virtualization and cloud 10
Back to the CGW: “on the fly” instantiation
CGWs should be instantiated on the fly on data centers (OpenStack) distributed at network edges (fog computing)
– there is hence a need for a tool capable of configuring such elements (typically OpenStack)
– But CGWs should be interconnected, sometimes with bandwidth constraints
– OpenStack is not sufficient by itself, there is a need for a tool able to configure the network in order to interconnect CGW (e.g., OpenDaylight), typically when used to backhaul an enterprise network
OpenDayLight and Openstack have been developed for given purposes, there is a need for a tool with a global view of the network in terms of storage, computing and bandwidth
GlobalOS under study at OrangeLabs
Virtualization and cloud 11
Configuration of a CGW (OpenStack – centralized view)
L3/L2 tunnel tunnel
OpenStack
Nova
Neutron [ceilometer]
network
configuration of CGW
Network tunnel configuration.
VM (AAA)
Switch/router (e.g. OVS)
Neutron agent
VM (vEPC)
CGW
Neutron agent
VM (AAA)
Switch/router (e.g. OVS)
VM (vEPC)
CGW
Openstack can control and configure a CGW from the edge (nothing in the network)
configuration of CGW
Network tunnel configuration.
Data center Data center
Virtualization and cloud 12
Configuration of a CGW (OpenStack + ODL)
configuration of CGW
L3/L2 tunnel tunnel
network
configuration of CGW
Network tunnel configuration.
OpenStack
Nova
Neutron [ceilometer]
VM (AAA)
Switch/router (e.g. OVS)
Neutron agent
VM (vEPC)
CGW
Neutron agent
VM (AAA)
Switch/router (e.g. OVS)
VM (vEPC)
CGW
Network tunnel configuration.
Data center Data center
OpenDaylight
Neutron service
OpenStack
Nova
Neutron [ceilometer]
Node config.
Node config.
Virtualization and cloud 13
Configuration of CGW (orchestration)
configuration of CGW
L3/L2 tunnel tunnel
network
configuration of CGW
Network tunnel configuration.
OpenStack
Nova
Neutron [ceilometer]
VM (AAA)
Switch/router (e.g. OVS)
Neutron agent
VM (vEPC)
CGW
Neutron agent
VM (AAA)
Switch/router (e.g. OVS)
VM (vEPC)
CGW
Network tunnel configuration.
Data center Data center
OpenDaylight
Neutron service
OpenStack
Nova
Neutron [ceilometer]
Node config./monitoring Node config./monitoring
orchestrator (network
abstraction) request for VM configuration resource reporting
request for VM configuration resource reporting
network configuration requests/ network abstraction
Virtualization and cloud 14
Global OS: first view
Openstack OpenDayLight
orchestration by using network abstraction (topology, resources, etc.), scheduling, etc.
network
data center
data center
data center
configuration and monitoring (openflow, netconf, etc.)
Services Security …
API
Global OS
(network programming language)
Virtualization and cloud 15
Basic questions to be solved (for network valorization)
the network (Global OS) receives requests either from
services or for internal usage (e.g., on the fly deployment of convergent gateways)
requests require: bandwidth, storage and computing resources
request can be decomposed as a set of elementary functions which can be instantiated on several VM (or containers) – correlated allocation of resources, chaining
large number of data centers with limited capacities (when fog computing)
requests are of different types: – assignment of tasks – some tasks can be scheduled (e.g., book ahead reservations)
Resource allocation
optimization vs. stochastic analysis (complexity of resource demand, large number of facilities)
Virtualization and cloud 16
Network programming language
Very active domain of research Many languages have been proposed so far
– static approach – NetKAT (Kleen Algebra with Test): express network procedures
into an equational system (for formally proving properties of procedures)
– NICE – MERLIN
– dynamic approach – Kinetic – VeryFlow
Most languages are packet based and do not include resource allocation aspects (except Merlin)
scaling aspect: more than 1000 – 2000 nodes to configure