1. Deploying Network Function Virtualization Experiments on the Virtual Wall

2. Outline PART 1: THEORY PART 2: HANDS ON
Introduction to NFV, SDN and SFC
PART 2: HANDS ON
Introduction to: Fed4FIRE, Virtual Wall and jFed
Experimental setup
Practical Work

3. Network Function Virtualization (NFV)

4. Continuous reduction in ARPU, PROFITABILITY
Problem
Exabytes per month
Continuously increasing user requirements: more data, rapidly changing services
Networks with proprietary equipment
Increased CAPEX and OPEX
Increased competition amoung each other and from O-T-T providers
Limited possibility to raise subscription fees
1 exabyte = 1 000 000 000 gigabytes
Global IP Traffic Trends 1
Source: Cisco VNI Global IP Traffic Forecast, 2014–2019. May 2015.
OTT model contrasts with the purchasing or rental of video or audio content from an Internet service provider (ISP), such as pay television video on demand or an IPTV video service, like AT&T U-Verse. OTT in particular refers to content that arrives from a third party, such as Sling TV, YuppTV, Amazon Instant Video, Mobibase, Dramatize, Presto, DramaFever, Crackle, HBO, Hulu, myTV, Netflix, Now TV, Qello, RPI TV, Viewster, WhereverTV, Crunchyroll or WWE Network, and is delivered to an end-user device, leaving the ISP only the role of transporting IP packets.
OTT refers to delivery of video, audio and other media over the Internet without a traditional pay TV operator or free-to-air broadcaster being involved in the control or distribution of the content. OTT allows a consumer to watch a single program or episode easily.  Originally, OTT video was streamed to PCs. It’s now delivered via set-top  boxes such as Roku, Apple TV, Chromecast, Amazon Fire TV or via game consoles. This move has happened in parallel with increasing consumption of media on mobile devices. 2
Continuous reduction in ARPU, PROFITABILITY

5. 13 Operators Call for Action
October 2012
A joint operator call for the Telecom and IT industry to take advantage of advances in virtualization to increase service agility, network flexibility and reduce CAPEX and OPEX

6. ETSI responds to Call
November 2012
AT&T, BT, Deutsche Telekom, Orange, Telecom Italia, Telefonica and Verizon selected the European Telecommunications Standards Institute (ETSI) to be the home of the Industry Specification Group for NFV
Now 240 individual companies including 37 of the world’s major service providers as well as representatives from both telecoms and IT vendors
1st Phase of work ended at end of 2014, 11 documents: architectural framework, descriptions of the infrastructure, management and orchestration, security and trust, resilience and service quality metrics.

7. So, what is NFV ? NFV Concept
Leverage advances in virtualization to decouple network functions from Hardware
Network Functions Virtualisation aims to transform the way that network operators
architect networks by evolving standard IT virtualisation technology to consolidate
many network equipment types onto industry standard high volume servers, switches
and storage, which could be located in Datacentres, Network Nodes and in the end
user premises. It involves the implementation of network functions in software that
can run on a range of industry standard server hardware, and that can be moved to,
or instantiated in, various locations in the network as required, without the need for
installation of new equipment.
NFV Concept

8. Anticipated Benefits 1 2 3 Reduced capital expenses (CAPEX)
Due to economies of scale and more efficient use of resources (scale up/down),
Reduced operation expenses (OPEX)
Power/energy, space, update/upgrade/maintenance
Flexible, faster deployment, reducing time to market
Minimizing typical operator innovation cycle. Automated, standard deployment 1 2 3
Decoupling software from hardware. As the network element
is no longer a composition of integrated hardware and
software entities, the evolution of both are independent of
each other. This allows separate development timelines and
maintenance for software and hardware.
Flexible network function deployment. The detachment of
software from hardware helps reassign and share the infrastructure
resources, thus together, hardware and software,
can perform different functions at various times. This helps
network operators deploy new network services faster over
the same physical platform. Therefore, components can be
instantiated at any NFV-enabled device in the network and
their connections can be set up in a flexible way.
Dynamic scaling. The decoupling of the functionality of the
network function into instantiable software components provides greater flexibility to scale the actual VNF performance
in a more dynamic way and with finer granularity, for instance,
according to the actual traffic for which the network operator
needs to provision capacity.

9. Some examples: Customer Premises Equipment
The ETSI has proposed a number of use cases for NFV [9].
In this subsection, we will explain how NFV may be applied
to customer premises equipment, and to a core network.
1) Customer Premises Equipment: In Figures 1 and 2, we
use an example of a Customer Premises Equipment (CPE)
to illustrate the economies of scale that may be achieved
by NFV. Fig. 1 shows a typical (current) implementation of
a CPE which is made up of the functions: Dynamic Host
Configuration Protocol (DHCP), Network Address Translation
(NAT), routing, Universal Plug and Play (UPnP), Firewall,
Modem, radio and switching. In this example, a single service
(the CPE) is made up of eight functions. These functions
may have precedence requirements. For example, it may be
required to perform firewall functions before NAT. Currently,
it is necessary to have these functions in a physical device
located at the premises of each of the customers 1 and 2. With
such an implementation, if there is a need to make changes to
the CPE, say, by adding, removing or updating a function, it
may be necessary for a technician from the ISP to individually
talk to or go to each of the customers. It may even require a
complete change in the device in case of additions. This is not
only expensive (operationally) for the ISPs, but also for the
customers.
In Figure 2, we show a possible implementation based on
NFV in which some of the functions of the CPE are transferred
to a shared infrastructure at the ISP, which could also be a
datacenter. This makes the changes described above easier
since, for example, updating the DHCP for all customers
would only involve changes at the ISP. In the same way, adding
another function such as parental controls for all or a subset
of customers can be done at once. In addition to saving on
operational costs for the ISP, this potentially leads to cheaper
CPEs if considered on a large scale.

10. Evolved Packet Core (EPC)
External Networks
External Networks
Evolved Packet Core
Evolved Packet Core (EPC)
Data Centers
VNFs
P-GW
PCRF
P-GW
PCRF
MME
S-GW
S-GW
MME
Access Network
(E-UTRAN)
Access Network
(E-UTRAN)
Virtualizing the Evolved Packet
Core (EPC) is another example of NFV that has attracted a
lot of attention from industry. The EPC is the core network for
Long Term Evolution (LTE) as specified by 3GPP [8]. On the
left side of Fig. 3, we show a basic architecture of LTE without
NFV. The User Equipment (UE) is connected to the EPC over
the LTE access network (E-UTRAN). The evolved NodeB
(eNodeB) is the base station for LTE radio. The EPC performs
essential functions including subscriber tracking, mobility
management and session management. It is made up of four
NFs: Serving Gateway (S-GW), Packet Data Network (PDN)
Gateway (P-GW), Mobility Management Entity (MME), and
Policy and Charging Rules Function (PCRF). The EPC is
connected to external networks, which may include the IP
Multimedia Core Network Subsystem (IMS). In the current
EPC, all its functions are based on proprietary equipment.
Therefore, even minor changes to a given function may require
a replacement of the equipment. The same applies to cases
when the capacity of the equipment has to be changed.
On the right side of Fig. 3, we show the same architecture in
which the EPC is virtualized. In this case, either all functions
in the EPC, or only a few of them are transferred to a shared
(cloud) infrastructure. Virtualizing the EPC has the potential
to lead to better flexibility and dynamic scaling, and hence
allow TSPs to respond easily and cheaply to changes in market
conditions. For example, as represented by the number of
servers allocated to each function in Fig. 3, there might be
a need to increase user plane resources without affecting the
control plane. In this case, VNFs such as a virtual MME
may scale independently according to their specific resource
requirements. In the same way, VNFs dealing with the data
plane might require a different number of resources than those
dealing with signaling only. This flexibility would lead to more
efficient utilization of resources. Finally, it also allows for
easier software upgrades on the EPC network functions, which
would hence allow for faster launch of innovative services.
eNodeB
eNodeB
eNodeB
eNodeB
User Equipment
User Equipment

11. NFV Reference Architecture
Virtual Network Functions 2
VNF 1
VNF 2
VNF 3
VNF N
. . .
NFV
Management & Orchestration
(NFV MANO) 3
Network Function Virtualization Infrastructure
Virtual Resources
Computing, Storage, Network Resources 1
Physical Resources
Computing, Storage, Network Resources

12. A lot of progress, yet many challenges
Automated Chaining of functions to create end-to-end services
Inter-operability
Management and Orchestration
Efficient resource allocation
Standardization
Architectural design
Information and data modeling
Energy efficiency
Performance
NFV
- Chain functions
- Evaluate performance
- Model services, functions
For instance, a service chain may define that all TCP port 80 traffic must pass through a firewall (FW), then intrusion prevention (IPS), and finally server load balancing (SLB).

13. Service Function Chaining (SFC)
SFC provides the ability to set up an ordered list of a Service Functions (e.g. firewall, DPI, etc.) which a set of packets should traverse
DHCP
NAT
Firewall
Parental Controls
Virtual Network Functions
CLOUD
. . .
CLASSIFIER
For instance, a service chain may define that all TCP port 80 traffic must pass through a firewall (FW), then intrusion prevention (IPS), and finally server load balancing (SLB).
Transport

14. Software Defined Networking (SDN)
For instance, a service chain may define that all TCP port 80 traffic must pass through a firewall (FW), then intrusion prevention (IPS), and finally server load balancing (SLB).

15. SDN Definition Adapted from SDN Central (SDN usecases)
SDN addresses the fact that the static architecture of conventional networks is ill-suited for the dynamic computing and storage needs of todays datacenters, campuses, and carrier environments
Decouples networking control from forwarding hardware
Enables the network control to become directly programmable via an open interface (e.g., ForCES, OpenFlow, etc)
The underlying infrastructure becomes simple packet forwarding devices (the data plane) that can be programmed.
The SDN architecture is: Directly programmable, Agile, Centrally managed, Programmatically configured, Open standards-based and vendor-neutral
Directly programmable. Network control is directly programmable
because it is decoupled from forwarding functions.
Agile. Abstracting control from forwarding lets administrators
dynamically adjust network-wide traffic flow to meet
changing needs.
Centrally managed. Network intelligence is (logically) centralized
in software-based SDN controllers that maintain a
global view of the network, which appears to applications and
policy engines as a single, logical switch.
Programmatically configured. SDN lets network managers
configure, manage, secure, and optimize network resources
very quickly via dynamic, automated SDN programs, which
they can write themselves because the programs do not depend
on proprietary software.
Open standards-based and vendor-neutral. When implemented
through open standards, SDN simplifies network design
and operation because instructions are provided by SDN
controllers instead of multiple, vendor-specific devices and
protocols.
Adapted from SDN Central (SDN usecases)

16. SDN Benefits Adapted from SDN Central (SDN usecases)
Directly programmable. Network control is directly programmable
because it is decoupled from forwarding functions.
Agile. Abstracting control from forwarding lets administrators
dynamically adjust network-wide traffic flow to meet
changing needs.
Centrally managed. Network intelligence is (logically) centralized
in software-based SDN controllers that maintain a
global view of the network, which appears to applications and
policy engines as a single, logical switch.
Programmatically configured. SDN lets network managers
configure, manage, secure, and optimize network resources
very quickly via dynamic, automated SDN programs, which
they can write themselves because the programs do not depend
on proprietary software.
Open standards-based and vendor-neutral. When implemented
through open standards, SDN simplifies network design
and operation because instructions are provided by SDN
controllers instead of multiple, vendor-specific devices and
protocols.
Adapted from SDN Central (SDN usecases)

17. Traditional vs Software defined Networks
SDN Controller
Network/Business Applications
Load Balancing
Routing
MAC Learning
Interface e.g. Openflow
Infrastructure Layer
Control Layer
Application Layer
APIs
Forwarding Switches
Network Services
Traditional Network: Distributed Control and Middleboxes (e.g. Firewall, Intrusion Detection, etc.)

18. Controller OpenFlow protocol OpenFlow Switch OpenFlow Interface
Flow Table(s)
OpenFlow is the de facto implementation southbound API (between the controller and forwarding switches) for SDN
In OpenFlow, a forwarding switch has a FlowTable
Each entry in the table is a rule which defines what should be done (output port) for a packet with given characteristics (input port, source address etc.)
The controller is responsible to populating the rules into the table
Dropped

19. OpenFlow table entries
Match Fields
Priority
Counters
Instructions
Timeouts
Cookie
Flags
Write Metadata
Goto Flow Table
Write action(s) to action set
Output: Send packet to specified port
Drop
Set-Queue: Assign packet to specified queue
Set-Field: Modify packet header field(s)
Change-TTL
Match fields
Packet header fields: TCP stack header fields
Pipeline metadata: Used to pass information between tables in a switch
Counters: Updated for each matched packet
Instructions: Modify the action set of pipeline processing
Timeouts: Maximum time or idle time
Cookie: Data value chosen by Flow controller, used by controller to filter flow entries affected by flow statistics, flow modification, and flow deletion requests
Flags: Alter management of flow entries (e.g.,
Ingress port
Packet header fields
Pipeline Metadata

20. Decouples network functions from equipment: Leads to agility, reduced CAPEX and OPEX
Creates network abstractions to enable faster innovation, network flexibility and holistic management
NFV
SDN
Service/Function Abstraction
Networking Abstraction
Automation
Isolation
Agility
Mainly Telecom service providers
Mainly networking software and hardware vendors
Multiple Control Protocols (e.g OpenFlow, SNMP)
OpenFlow
NFV and SDN are highly related and complimentary, combining them may lead to greater value. BUT they are not dependent on each other

21. SDN-based Virtual Network Function Chaining
Controller
Firewall
NAT
For instance, a service chain may define that all TCP port 80 traffic must pass through a firewall (FW), then intrusion prevention (IPS), and finally server load balancing (SLB).
DHCP
Parental Controls

22. Architectural overview of the SFC configuration process
28/04/2017
Architectural overview of the SFC configuration process
Personalized Services
Service Consumption
Service Function Chains
SFC Configuration
Virtual Infrastructure (VNFs)
jFed Embedding
Physical Infrastructure (Virtual Wall)

23. Network Function Implementation
Software-based Click Functions
Bandwidth Shaper
Delay Shaper
Firewall
TCP monitoring
Src
BandwidthShaper
Sink
Src
DelayShaper
Sink
Src
IPClassifier
Sink
Src
IPClassifier (tcp,-)
Queue
Sink
IPPrint

24. Network Function Implementation
Load Balancer
IPv6/IPv4 translation
Src
IPClassifier
Queue
Sink
RoundRobinIPMapper
Src
ProtocolTranslator64
Sink
Src
ProtocolTranslator46
Sink

25. Virtual Network Infrastructure Topology
Open vSwitch
Click kernel

26. SFC Configuration Tool
Can be configured to run any Network Function in Software using CLI

27. SFC Configuration Tool
JavaScript-based front-end
Automatically configured using topology information from geni-get
GUI for interconnecting functions
Translating connections to SFC (client1 -> click1 -> server1)
Python-based SDN controller and back-end
Listening to GUI messages over HTTP
Translating SFC to OVS-ofctl commands
Installing and managing OVS configurations

28. Advanced JFed features
Download & install scripts for OVS node
Specific image for click nodes
Python controller using geni-get and ovs-ofctl