Policy-based Orchestration of
NFV Services in SoftwareDefined Networks
Kostas Giotis, Yiannos Kryftis, Vasilis Maglaris
Network Management & Optimal Design Laboratory (NETMODE)
School of Electrical & Computer Engineering
National Technical University of Athens
1st IEEE Conference on Network Softwarization (NetSoft 2015)
April 15th, 2015
London, UK
Trends in Telcos Industry
 Telco networks demonstrate:



Significant growth of traffic volumes
Increased data rates
Plethora of diverse network services
 SDN and NFV architectures promise:



Increased business agility (speed up services
deployment)
Decreased operational costs
Decoupling of services from the physical substrate
SDN and NFV overlook
SDN Protocols
 Multiple SDN protocols (OF,
ForCES, Cisco OpFlex)

OF is still dominant
 Delivers:



Network programmability
Decouple Data & Control
Plane
Listen & Handle Network
Events
NFV Architectures
 No standardized protocols

All approaches are based on
the ETSI specification
 Delivers:



Agile placement of
networking services
Service-driven virtual
Networks
Optimized usage of COTS
Hardware devices
Delivery of agile services through
SDN and NFV synergies
Motivation
 Formulate a baseline
architecture to facilitate
policy-driven dynamic
methods for:



management of SDN
resources
lifecycle management of VNFs
and the associated data
orchestration of multiple
diverse VNFs to deliver
Business Applications as NFV
Services (i.e. Service Chains)
Design Principles
 Modular design that decouples:




Hardware elements
VNFs
Business (NFV) Services
Orchestration
 Information Model to uniformly
describe network resources and
functions
 Instantiate and Manage NFV
Services, governed by policies
Architectural
Components
 Physical Infrastructure


Nodes
Controllers
 VNF Pool


Diverse VNFs
“Templates”
 NFV Services


Business Applications
Service Chains
 NFV Orchestrator


Mgmt Functions
Information Model
This schema permits:
• Selection of VNFs from a VNF Pool
• Use Policy-Engines to manipulate VNFs
• Combine Diverse VNFs to deliver NFV
Services
Architectural
Components
 Physical Infrastructure


Nodes
Controllers
 VNF Pool


Diverse VNFs
“Templates”
 NFV Services


Business Applications
Service Chains
 NFV Orchestrator


Mgmt Functions
Information Model
Policy
Engine:consist
Uniquely-identified
Use
abstracted
physical
substrate
resources
for:
NFV
Services
of one
orobjects:
more
VNFs, and:
Policy-based
management
ofApplications
substrate
Managed
Programmable
in an
Network
abstracted
Functions
manner
templates
• Deliver
tailor-made
Business
Agnosticwith
Isolated
instances
to the
actualVNFs
substrate
• resources
Interact
Diverse
•• VNF
Lifecycle
Management
Implement
Forwarding
Graphs (VNF-FGs)
• Orchestration of NFV Services
Policy-based NFV Orchestrator
 The management environment is divided in three layers



The lower layer concerns policy based management for OF substrate
resources, providing management enforcement methods on MOs
representing them
The middle layer deals with VNF lifecycle management. All VNF
components are represented as MOs and their methods may include
policy-based management actions to be executed on lower layer MOs
The higher layer provides policy-based Orchestration of NFV Services.
Each NFV Service extends the Managed Object Class and it includes
the methods for capturing and creating events, and performing
management actions on VNF components in the pool, based on highlevel policies
Types of Policies
 Event-Condition-Action(ECA) Policies: They enforce control and
management actions upon certain events within the managed
environment, possibly causing reconfiguration of the system
 Authorization Policies: They define what actions Users with specific Roles
can perform on Target MOs
 Role Assignment Policies: They are used to define different classes of
Users, receiving different access privileges and usage priority on specific
services provided by VNFs
Graphical overview of the classes in the
Ontology
The Policy Engine residing in the NFV Orchestrator stands for the
management environment that encompasses a collection of Managed
Objects (MOs) in hierarchical order, representing:




Policies (i.e. Event-Condition-Action (ECA), authorization, role assignment)
OF resources (i.e. Controller, Switch, Link, Port)
VNF components and
NFV services
Ponder2 Policy Framework
 For the development of VNF
Orchestrator’s policy engine, the
Ponder2 policy framework was
selected:
 It supports all aforementioned
policy types and it uses userextensible management
objects


It was extended to represent
the substrate resources, and
the NFV Services as Managed
Objects able to be managed
by the policies
Conflict Resolution
Prototype VNFs
Monitoring VNF
 Instruct for the acquisition of
flow statistics


Statistics are initially collected
at the Controller
Flow-stats request/reply event
 Capable to interface with
different types of monitoring
data managers

E.g. sFlow Collector
Network Embedder VNF
 Map virtual paths to the
physical substrate


Upon User request
Create e2e virtual links
 Clients are considered to be
large scale customers


e.g. content or alternate
providers
Do not require significant
number of identifiers (we
user VLANs)
NFV Service:
Role-based Traffic
 Monitoring and N.E. VNFs are
Engineering
chained to create RbTE instances as
a Business Application
 Client receives different type and
quality of services
 2 client tiers in prototype, regarding
traffic routing:


Tier 1: path with least utilized links (best
effort)
Tier 2: Shortest path – high priority
Case Study
Traffic Engineering for CDN Caching Nodes
 CDN Providers deploy
Caching Nodes inside
the premises of other
operators
 CDN Providers are
treated as clients
Virtual Link 1
Virtual Link 2
Virtual Link 3
CDN
Cache
Node B
CDN
Cache
Node A
Switch 1
Switch 2
s
bp
1G
EP-2
1G
bp
s
WAN
EP-1
 An Operator might
host multiple Caching
Nodes of different CDN
providers
10
0M
bp
s
Telecom
Operator
Switch 4
s
bp
0M
10
Switch 3
EP-3
Home
User A
Experimental Results
 Proof-of-concept
demonstration

Indicative Role-based
services functionality
 Future Work:


Avoid path switching for
Tier 1 clients when the
link is not saturated
Integrate a virtualization
layer through a network
hypervisor (e.g.
OpenVirtex) for isolated,
Policy-based Control
Plane management.
THANK YOU!
Kostas Giotis
coyiotis@netmode.ntua.gr