future internet chapter 5: network functionvirtualization...

Computer Networks GroupUniversität Paderborn

Future Internet Chapter 5: Network Function Virtualization5a: Basics

Holger Karl

Overview

• Technical trends & motivation • Reference architectures: ETSI, IETF • Problems to solve• Existing projects • Conclusions

2FI - Ch 5a: Network Function Virtualization, Basics SS 19, v 1.2

Traditional network functionality

• Provider networks not only forward packets• Examples: Firewalls, deep

packet inspector, load balancer, content distribution, HTTP header enrichment functions, TCP optimizer, ...

• By necessity distributed inside the network

• Traditionally implemented on expensive, closed boxes• Physical network function,

"network appliance"


Virtualize network functionality?

• Network functions are just computing• Use commmon virtualization techniques to realize them?

• Commercial off-the-shelf hardware• Somewhat optimized for networking performance • Software implementations: Virtual network function (VNF)

=> Network Function Virtualization (NFV) • Hope:

• Improved CAPEX, OPEX (energy!)• Faster deployment• Flexible management

ETSI terminology


Business options?

• Business model: Opened up to external partners?

• Not just the network operator

• Escape route from "just a bit pipe"

• NFVI as a Service: Infrastructure + Network as a Service

• Target?

• Business between network operators

• But: Not just network functions per se

• Even web servers, application servers, ... ?


FI - Ch 5a: Network Function Virtualization, Basics

Some use cases from ETSI

• VNFaaS: Virtualize customer premise equipment into the network• E.g., Enterprise access router, VPN termination, ...

• Mobile Core/IMS functionality, mobile base stations• Virtualized home environment

• Residential gateway (Internet, VoIP, firewall, NAT), set-top box for media services, personal video recorder, ...

• Virtualize content distribution networks• Netflix, Akamai, ... : dynamically provision web caches/streaming

proxies were needed

Network Functions Virtualisation; Use Cases. ESTI GS NFV 001.

6SS 19, v 1.2

Broadening the scope: Distributing data centers

• Common rationale: Economy of scale• Build huge data centers to safe money• But results in only a few centers

• Consequence: data centers far away from users• Fine for many applications• Critical for some: interactive, gaming, content distribution,

streaming, ...

• Have some local functionality close to users?• Smaller centers, widely distributed• More expensive, more suitable?


Distributed Cloud Computing

• DCC pioneered in late 2000s, under different names • Distributed Cloud Computing• Carrier cloud • In-network cloud • Nano data centers• ….

• Many commonalities with NFV • Different emphasis: end-user applications vs. network-oriented

features • Convergence? Open question …


Overview

• Technical trends & motivation • Reference architectures: ETSI, IETF • Problems to solve • Existing projects • Conclusions


First step: Infrastructure for Network Functions

• Suppose network function virtualization takes place• Results in many small data centers in the network• In total: Network Function Virtualisation Infrastructure

(NFVI) • (Using ETSI terminology here, more details to come)


NFV Infrastructure

• ETSI infrastructure definition• “Support deployment and execution of Virtualised Network

Functions” • “Totality of the hardware and software components which build up

the environment in which VNFs are deployed”

• Leverage existing virtualization technology from computing • Enhance with network virtualization

11

Compute domain

Hypervisor domain

Infrastructure networkdomain

Network Functions Virtualisation; Architectural Framework.

ESTI GS NFV 002.

FI - Ch 5a: Network Function Virtualization, Basics SS 19, v 1.2

NFVI vs. VNF

• NFVI executes VNF: Separate description necessary

12

ETSI

ETSI GS NFV-INF 001 V1.1.1 (2015-01) 17

Figure 3: Functional Block Architecture

An inherent property of a functional block is that its operation is autonomous. The behaviour of the function block is determined by:

• The static transfer function of the functional block.

• The dynamic state of the functional block.

• The inputs it received in its interfaces.

If a functional block becomes disconnected from a functional block to which it should be connected, it will continue executing and setting outputs, however, the execution will follow according to the null input.

As stated above, the objective of NFV is to separate software that defines the network function (the VNF) from hardware and generic software that create a generic hosting network functions virtualisation infrastructure (NFVI) which executes the VNF. It is therefore a requirement that the VNFs and the NFVI be separately specified. However, this is a requirement that is not immediately satisfied by the method of functional blocks and associated interfaces a generalization of the technique.

Figure 4 shows the situation when two of the three functional blocks of figure 3 have been virtualised. In each case, the functional block is now implemented as a virtualised network function executing on a host function in the NFVI.

Figure 4: Virtualisation of network function

This process has resulted in the following:

• The division of a functional block between a host function and a virtualised network function.

• The creation of a new container interface between the host function and the VNF it is hosting.

• The division of the interface between the two network functions which are now virtualised between an infrastructure interface and a virtualised interface.

• The interface to the non-virtualised network function appears to be a homogeneous interface at its end with the non-virtualised function. However, at its virtualised end, it appears to be divided between an infrastructure interface and a virtualised interface.

However, in carrying out this process, there are two very important distinctions from the standard functional block description:

• The virtualised network function (VNF) is not a functional block independent of it host function.

• The container interface is not an interface between functional blocks equivalent to other interfaces.

IT-industy/cloud interfaces


NFVI: Recursion

• Recursion allowed between VNF and Host Function!

13

Server blade

Hypervisor

Virtual machine (VM)

Operating system in VM

VNF-implementing

Application

One specific function

Recall your basic

operation systems

class!


NFVI & cloud technologies

• Clouds provide basic technologies

• Hypervisors to virtualize machines/operating systems

• Virtual Ethernet switches (openVswitch, in particular)

• With core functions, e.g., rapid elasticity, resource pooling

• … as well as management interfaces

• Typically, Web-based control of VM operations

• Adopt business model of cloud computing for NFV?

• On-demand self-service?

• Pay-as-you-use? X-as-a-service?


Towards a big-picture architecture

• Which roles do we need?

• Real stuff: computing, networks, external networks

• Virtual stuff: (virtual) functions running “somewhere”, tied together

into virtual networks, realizing an application

• Management and orchestration

• Which interfaces do we need?

• NFV-realized applications: run somewhere, be managed, talk to

networks

• Virtualization interfaces for computing and networking

• Mapping, management, orchestration interfaces


Terminology

• Virtual network function (VNF): • Software implementations of a network function • Packaged and executed inside a virtualisation container (e.g., VM,

Docker container) • Can be decomposed into smaller execution entities, called virtual

deployment units (VDU)• Not part of reference architecture

• Executed on top of the NFVI.• Network service (NS): Multiple interconnected VNFs • Element manager (EM): responsible for functional

management of VNFs• Translates management requests from NFV MANO to (proprietary)

management interfaces of a specific VNF implementation

SS 19, v 1.2 FI - Ch 5a: Network Function Virtualization, Basics 16

Terminology

• NFV infrastructure (NFVI): environment on which VNF are

executed

• Abstracts hardware resources into virtual resources.

• Offer virtual compute/storage/networking resources

• E.g., virtual subnets

• Allows to run complex NS on top of it

• NFV orchestrator (NFVO): end-to-end management and

orchestration of NS

• Includes tasks like scaling, placing, and healing of NS/VNF

• VNF manager (VNFM):Unlike NFVO, focuses on VNF

lifecycle management

• E.g., instantiation, configuration, updating, scaling, and

termination

• Multiple VNFMs can be deployed in an NFVO, allows to build VNF-

specific orchestration solutions


Terminology

• Virtual infrastructure manager (VIM): • Manage virtualised resources provided by NFVI • Typically, NFVO/VNFM connect to multiple VIMs from different

vendors using internal abstraction models, often called VIM drivers

• MANO = NFVI + NFVO + VIM

• Service, VNF, and infrastructure description:• To deploy an NS/VNF, MANO systems needs description of those

artefacts. • Multiple standardised description approaches exist

• Operation/business support system (OSS/BSS): Usually, integrated with existing OSS/BSS of an operator


Overview architecture: ETSI reference architecture


ETSI reference architecture


Manoframework

VIM(e.g.,

OpenStack,VMWare, …

Big-picture architecture

21FI - Ch 5a: Network Function Virtualization, Basics Network Functions Virtualisation; Infrastructure Overview. ESTI GS NFV-INF 001. SS 19, v 1.2

Big-picture architecture: Interfaces


ETSI Compute Domain

• Computational and storage components, typically commodity of-the-shelf (COTS) • CPU, network interface (NIC), storage, chassis, … • Acceleration hardware, e.g., en-/decryption • Combined into an industry-standard “server”


ETSI Hypervisor domain

• Provide an abstract machine (on top of a real server) to virtual network functions • … and to management/orchestration functions, if so desired


ETSI Infrastructure Network domain

• Provide logical connectivity between • components of a virtual network function • different virtual network functions • virtual network functions and their context (management, …)

• Abstracted into “virtual networks” • Infrastructure network must provide

• At least one addressing scheme • Routing • Resource management

• Guaranteed minimum datarate and maximum latency allocation (ideally)

• Or only prioritization


ETSI Infrastructure Network: Relation to VNFs

• Common Header • Think of the infrastructure network as a layer 2 network underneath

the VNFs

• VNF NICs can use MAC addresses to talk to each other!

• Infrastructure network must be able to process that

• Address binding • MAC addresses of virtual NICs not likely to be actual infrastructure

addresses

• Necessitates a binding process between vNIC MAC and actual infrastructure address

• Transparent encapsulation

• VNF packets carried as transparent payload

• E.g., a Virtual LAN, but beware scalability concerns

• Complicated by: multitude of infrastructure network technologies


Interconnecting functions gets complicated


The Virtual Network Functions: High-level framework

28

• VNFs sitting on top of the NFVI • Helped along by management & orchestration functions

FI - Ch 5a: Network Function Virtualization, Basics Network Functions Virtualisation; Architectural Framework. ESTI GS NFV 002. SS 19, v 1.2

Network Services as Forwarding Graphs of VNFs

• In the end, we want to build services meaningful for a user

• In the network, end-to-end

• Examples: virtual private network, mobile voice, …

• This goes beyond the purview of a single VNF

• Goal: combine multiple VNFs into

a network service• Executed by the compute domain,

interconnected by the

network infrastructure domain

• Typically: Order matters!

• A service needs several functions, working on a data flow in a

certain order

• Expressed as a forwarding graph

29FI - Ch 5a: Network Function Virtualization, Basics Network Functions Virtualisation; Architectural Framework.

ESTI GS NFV 002. SS 19, v 1.2

Forwarding graphs: Recursion allowed

• A VNF inside a forwarding graph can be constructed using a forwarding graph!

30FI - Ch 5a: Network Function Virtualization, Basics Network Functions Virtualisation; Architectural Framework. ESTI GS NFV 002. SS 19, v 1.2

Forwarding graphs

• ETSI deliberately talks about forwarding graphs in general

• Not just linear chains

• IETF: service chains

• Specification needs:

• Which NFVs?

• Traversed in which order?

• How much load can one VNF handle?

• At runtime:

• Where does load come from?

• Resource situation?


Forwarding graphs: A specification proposal

• Goal: Express relevant properties of a forwarding graph succinctly• Oriented towards developers

32

• Observation: sometimes, order does NOT matter

CDNDPIFW LB

CDNDPI

FW LB

FW

LBFW

FI - Ch 5a: Network Function Virtualization, Basics S. Mehraghdam, H. Karl: Specification of Complex Structures in Distributed Service Function Chaining Using a YANG Data Model, Netconf 2016.. SS 19, v 1.2

Forwarding graphs: Specification examples


Scaling effects – specification?

• VNF instances can be dynamically created/destroyed depending on load• Recall: cloud computing-like resource scaling

• Question: Consequences for a function graph? • Due to: How much load can one VNF handle? • Simplify: normalized processing speed

• Idea: Template specifications • Annotate edges in a function chain

by multiplicity: VNF instance can handle so many instances of the previous stage

34FI - Ch 5a: Network Function Virtualization, Basics M. Keller, C. Robbert, H. Karl: Template Embedding: Using Application Architecture to Allocate Resources in Distributed Clouds. In 7th International Conference on Utility and Cloud Computing (UCC). (2014)SS 19, v 1.2

IETF: Service Function Chaining

• Essentially, very similar scope and basic approaches; slightly different terminology, architecture details less evolved (or involved?)

• Core working group: Network Working Group • Interesting aspects:

• Explicit mention that service functions can exist at several layers of an ISO/OSI stack; typically network layer up to application layer easy to imagine

• Service Function Chain: partially ordered set of network functions, along with copying, branching, … of the data flows

• Consideration of unidirectional vs. bidirectional chains • E.g., DPI, firewalls might require both flow directions to pass through

same instance of the service functions


Overview

• Technical trends & motivation • Reference architectures: ETSI, IETF • Problems to solve • Existing projects • Conclusions


Look at many functions

• Isolated network functions the exception • Rather: data flows via several network functions• Simplest case: a chain

• E.g.: A firewall, then a DPI, then a CDN • More sophisticated: arbitrary acyclic graph

• Network function forwarding graph


Placement

• Given a forwarding graph: On which actual nodes to execute which function?• Dealing with many graphs? Reuse functions? ...?

?

?


Deployment

• Suppose placement is solved

• How to instantiate VMs, set up paths?• Software-Defined Networking!


Scaling

• Suppose monitoring tells us that KPIs not met• Throughput low, latency high, ...

• Scale: Add virtual network functions, re-route, ...


ETSI reference architecture

41

Placement&

Scaling

Deployment

Monitoring

Specification


Existing projects

SS 19, v 1.2

Overview

• Technical trends & motivation • Reference architectures: ETSI, IETF • Problems to solve • Existing projects• Conclusions



Open source activity: OpNFV

• Initiative for an open-source NFVI/NFVI-Manager (including

Nf-Vi interface)

• Public release available

https://www.opnfv.org/software/technical-overview

43

Initial OpNFVfocus

SS 19, v 1.2

OpenSourceMano (OSM)

• Open-source Management / Orchestration framework • https://osm.etsi.org• Current release:

https://osm.etsi.org/wikipub/index.php/OSM_Release_TWO• Aligned with ETSI reference architecture • UPB: member!


https://osm.etsi.org/

https://osm.etsi.org/wikipub/index.php/OSM_Release_TWO

Overview

• Technical trends & motivation • Reference architectures: ETSI, IETF • Problems to solve • Conclusions


Conclusions

• Network operators pushing NFV a lot

• Network providers (grudgingly?) give in

• Distributed cloud computing so far still mostly academic

• Use cases and business models not really settled

• So far, heavy emphasis on network operator business

• IT industry in general has not yet caught on

• Think broader!?


References, further reading• European Telecommunication Standards Insitute (ETSI), Industrial

Study Group on Network Function Virtualization (ISG NFV), http://www.etsi.org/technologies-clusters/technologies/nfv• With various important white papers on reference architecture, use cases,

terminology (see “Specifications” tab on that web page) • Especially: https://portal.etsi.org/nfv/nfv_white_paper2.pdf

• Vendor-specific white papers: • HP:

http://www.hp.com/hpinfo/newsroom/press_kits/2014/MWC/White_Paper_NFV.pdf,

• Alcatel Lucent: http://www.tmcnet.com/tmc/whitepapers/documents/whitepapers/2013/9377-network-functions-virtualization-challenges-solutions.pdf

• Service chaining surveys• http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6702549• http://www.ewsdn.eu/previous/presentations/Presentations_2013/EWSDN-

2013-v10a.pdf• Papers for this chapter: Two mendeley groups

• https://www.mendeley.com/groups/6764011/distributedcloudcomputing/• https://www.mendeley.com/groups/6763981/networkfunctionvirtualization/


http://www.etsi.org/technologies-clusters/technologies/nfv

https://portal.etsi.org/nfv/nfv_white_paper2.pdf

http://www.hp.com/hpinfo/newsroom/press_kits/2014/MWC/White_Paper_NFV.pdf

http://www.tmcnet.com/tmc/whitepapers/documents/whitepapers/2013/9377-network-functions-virtualization-challenges-solutions.pdf

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6702549

http://www.ewsdn.eu/previous/presentations/Presentations_2013/EWSDN-2013-v10a.pdf

https://www.mendeley.com/groups/6764011/distributedcloudcomputing/

https://www.mendeley.com/groups/6763981/networkfunctionvirtualization/

future internet chapter 5: network functionvirtualization...

Documents