Open Network Automation Platform (ONAP) Controller Architecture Proposal DRAFT
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 APP-C Policy A&AI VF-C VNFs DCAE