The document provides an overview of the Open Network Automation Platform (ONAP), which is an open source platform for automating virtual network functions (VNFs). ONAP was derived from AT&T's ECOMP platform and can design, create, orchestrate, monitor, and manage the lifecycles of VNFs, SDNs containing VNFs, and higher-level services combining these components. It also discusses network function virtualization (NFV) basics, global traffic trends, proprietary equipment issues, declining revenues, and the call for more agile and flexible software-based networks. Finally, it summarizes ONAP's architecture, including its design time and run time frameworks, and provides a use case

1. Open Network Automation Platform
6th July 2017
Atul Pandey(Technical Specialist)
NEC Technologies India Pvt Ltd.

2. 2
Contents
• ONAP Overview
• NFV Basics
• Global Trend Traffic
• Proprietary Equipment
• Declining Revenue
• Call for Action
• NFV Detailed
• NFV Anticipated Benefits
• Reference Architecture
• VNF and VNF Design Patterns
• NFVI Architecture
• NFVI MANO
• ONAP Architecture
• Design Time Framework
• Run Time Framework
• Use case: vCPE

3. 3
ONAP Overview
• ONAP (Open Network Automation Platform) is an open source software
platform
• Derived from AT&T’s ECOMP
• Delivers capabilities for the design, creation, orchestration, monitoring
• Life cycle management of :
• Virtual Network Functions (VNFs)
• The carrier-scale Software Defined Networks (SDNs) that contain them
• Higher-level services that combine the above

4. 4
NFV(Network Function Virtualization) Basics
• Fast Standard Hardware -> Software Based Devices.
• Function module(Data Planes and Control Planes)
• DHCP,NAT , Rate Limiting.
• Virtual Machine Implementation
• Virtual Appliances.
• All advantages of Virtualization(Quick Provisioning, scalability, mobility, reduced capex,
Reduced OpEx.
• Standard API :
• New ISG(Industry Specification Group) setup in ETSI(European Telecom Standards
Institutes)

5. 5
Global Traffic Trend
• Continuously increasing user requirements: more data, rapidly changing
services: Increased CAPEX
1 Exabyte = 1000000000 gigabytes

6. 6
Proprietary Equipment
• Networks with proprietary equipment, long product development cycles:
Increased OPEX

7. 7
Declining Revenues
• Increased competition among each other (SPs) and from Telco-OTT: No
corresponding increase in Revenue
Data Source: European Telecommunications Network Operators’
Association, Annual Economic Report. 2015.

8. 8
Call for Action
• A joint operator call for the Telecom and IT industry to take action to increase
service agility, network flexibility and reduce CAPEX and OPEX
• Some of the operators selected the European Telecommunications Standards
Institute (ETSI) to be the home of the Industry Specification Group for NFV
• Source : https://portal.etsi.org/NFV/NFV_White_Paper.pdf

9. 9
Network Function Virtualization(NFV)
• Leverages advances in virtualization decouple network function from
dedicated hardware to run them on standard server, storages and switches.
Classical Network model NFV Model: Virtual Appliances

10. 10
NFV Anticipated Benefits
• Architecture
• Reduced number of physical network elements to manage and deploy,
• Service elasticity, agility (increased time to market)
• Capital Expenses (CAPEX)
• Standard x86-based servers considered cheaper than routers/appliances,
• Economies of scale (better resource utilization in large DCs)
• Operating Expenses (OPEX)
• Automated network operations:reduces management requirements, branch visits
• Reduced expenses such as power due to consolidation, efficiency

11. 11
Reference Architecture

12. 12
VNF and VNF design Patterns
• A NF is an Element within a network with well defined external interfaces and
functional behavior e.g.: DHCP, firewall.
• VNF is an implementation of NF that is deployed on virtual resources such as
VM.
• A service is an offering provided by TSP that is composed of one or more
network functions(NFs)
• Design Patterns:
• Internal Structure
• VNF instantiation
• VNFC states
Internal Structure
VNF instantiation VNFC States

13. 13
NFVI Architecture

14. 14
NFV MANO
• Provides functionality required for the provisioning
of VNFs, and the related operations, such as the
configuration of the VNFs and the infrastructure
these functions run on.
• Orchestration and lifecycle management of physical
and/or software resources that support the
infrastructure virtualization, and the lifecycle
management of VNFs,
• Databases that are used to store the information
and data models which define both deployment as
well as lifecycle properties of functions, services,
and resources.

15. 15
NFV vs Cloud vs SDN
Source:RashidMijumbi,JoanSerrat,JuanLuisGorricho,NielsBouten,FilipDeTurck,RaoufBoutaba,“NetworkFunctionVirtualization:State-of-the-
artandResearchChallenges”.IEEECommunicationsSurveysandTutorials.FirstQuarter,2016.

16. 16
SDN and NFV working together
Source:https://www.sdxcentral.com/articles/contributed/nfv-and-sdn-whats-the-difference/2013/03/
Managed Router Service Today

17. 17
SDN and NFV working together
Source:https://www.sdxcentral.com/articles/contributed/nfv-and-sdn-whats-the-difference/2013/03/
Managed Router Service Using NFV Openflow switch packet flow

18. 18
SDN and NFV working together
• An expensive and dedicated appliance is replaced by generic hardware and advanced software.
• The software control plane is moved from an expensive location (in dedicated platform) to an
optimized location (server in a data center or POP).
• The control of the data plane has been abstracted and standardized, allowing for network and
application evolution without the need for upgrades of network devices.
Source:https://www.sdxcentral.com/articles/contributed/nfv-and-sdn-whats-the-difference/2013/03/
Managed Router Service Using NFV and SDN

19. 19
SDN and NFV Comparison
Category SDN NFV
Reason for Being Separation of control and data,
centralization of control and
programmability of network
Relocation of network functions from
dedicated appliances to generic
servers
Target Location Campus, data center / cloud Service provider network
Target Devices Commodity servers and switches Commodity servers and switches
Initial Applications Cloud orchestration and networking Routers, firewalls, gateways, CDN,
WAN accelerators, SLA assurance
New Protocols OpenFlow None yet
Formalization Open Networking Forum (ONF) ETSI NFV Working Group
Source:https://www.sdxcentral.com/articles/contributed/nfv-and-sdn-whats-the-difference/2013/03/

20. 20
OPNFV Objectives
• Open source collaborative project founded and hosted by the Linux Foundation, and composed of
TSPs and vendors.
• Introduced in September 2014 as an outgrowth of the ETSI NFV Industry Specification Group (ETSI
NFV ISG).
• Includes participation of leading end users to validate OPNFV meets the needs of user community
• Develop an integrated and tested open source platform that can be used to build NFV functionality,
accelerating the introduction of new products and services
• Contribute to and participate in relevant opensource projects that will be leveraged in the OPNFV
platform; ensure consistency, performance and interoperability among opensource components

21. 21
ONAP Architecture (1/2)
View of ONAP (Harmonize Framework)
to rapidly create new services
PROJECT
PROJECT
Framework Real Time, Policy Driven, Software Automation of VNFs to enable Developers

22. 22
ONAP Architecture (2/2)
• ECOMP(Enhanced Control, Orchestration, Management & Policy)

23. 23
ONAP Detailed Architecture

24. 24
Design Time Framework
▌Design time framework consists of following subsystems:
• Service Design and Creation (SDC)
• Policy
▌SDC is the ONAP visual modelling and design tool.
▌Manages content of catalog and logical assemblies.
▌SDC manages four level of assets:
• Resource(Infrastructure, Network, Application(Software Capabilities))
• Service(Includes all information about the service to initiate, update, delete and manage the
service.)
• Product(Customer ordering, billing and issue resolution)
• Others(bundling of products with specifics Marketing configurations for selling to
customers.)
• Policy maintains, distributes and operates set of rules.
• Policy provides a centralized environment for the creation and management of easily-updatable conditional
rules.
• Examples:
• VNF placement
• Data and feed management
• Access control
• Trigger conditions and actions
• Interactions

25. 25
Run-Time Framework
▌ Run-time execution framework distributes and executes the rules and policies that are
designed within the design-time framework, and consists of the following subsystems:
• Active and Available Inventory (AAI)
• Controllers
• Dashboard
• Data Collection, Analytics and Events (DCAE)
• Master Service Orchestrator (MSO)
• Security Framework

26. 26
VCPE

27. 27
Use Case: vCPE(1/2)
▌
Source :https://wiki.onap.org/pages/viewpage.action?pageId=3246168

28. 28
Use Case: vCPE (2/2)
• Residential users benefit from subscriber specific cloud services and
automation that does not need truck roll installation, local configuration and
management of LAN/NAT/WAN/VPN networking.
• Authenticated subscribers may access similar broadband services outside the
home residence using other wireline or wireless access networks.
• SPs benefit from a more flexible platform to evolve residential broadband
services that do not depend on the lifecycles of provided home devices (e.g.
STB, WiFi access router, modem etc…)