Open Network Automation Platform (ONAP)
Controller Architecture Proposal
Where we agree
 Common
use of the ONAP architecture framework
 Common view of service orchestrator
 Follow common set of VNF Guidelines and packaging
 Combined from OPEN-O and Open ECOMP
 Data model
 Present the same view/requirements to outside world
regardless of which path is selected
 Common mediation layer -> OpenStack, VMWare, cloud,
etc.
Areas of disagreement

Different operators have different requirements
 Workflows for controlling VNFs may take different paths based
on operator requirements
 (runtime instantiation)
 ETSI MANO
 VNFM functionality
 VNF characteristics (e.g., complex vs. simple)
 Network/operating region characteristics
 Need flexibility to meet operator requirements
ONAP Controller Proposal
Pros:
•Flexible
•APIs already
exists
•Easier initial
integration
Cons:
•May need 2x
feature
development
•Functional
overlap
Service Orchestrator
Policy
APP-C
VF-C
VNFs
DCAE
A&AI