Policy-based Orchestration of NFV Services in Software-Defined Networks Kostas Giotis , Yiannos Kryftis, Vasilis Maglaris Network Management & Optimal Design Laboratory (NETMODE) School of Electrical & Computer Engineering National Technical University of Athens 1 st IEEE Conference on Network Softwarization (NetSoft 2015) April 15th, 2015 London, UK
15
Embed
Policy-based Orchestration of NFV Services in Software- Defined Networks Kostas Giotis, Yiannos Kryftis, Vasilis Maglaris Network Management & Optimal.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Policy-based Orchestration of NFV Services in Software-Defined Networks
NFV Services consist of one or more VNFs, and:• Deliver tailor-made Business Applications• Interact with Diverse VNFs• Implement Forwarding Graphs (VNF-FGs)
Policy Engine:• Policy-based management of substrate
resources• VNF Lifecycle Management• 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 high-level 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 user-extensible 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)
Monitoring and N.E. VNFs are 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
NFV Service: Role-based Traffic Engineering
CDN Providers deploy Caching Nodes inside the premises of other operators
CDN Providers are treated as clients
An Operator might host multiple Caching Nodes of different CDN providers
Case Study
WAN
CDNCache
Node B
Home User A
Switch 1
Switch 2
Switch 3
Switch 4
CDN Cache
Node A
Virtual Link 1Virtual Link 2Virtual Link 3
Telecom Operator
EP-1
EP-2
EP-3
Traffic Engineering for CDN Caching Nodes
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.