1. ONAP External APIs Possible Enhancements / Roadmap R3+
Date : 11/06/2018
Adrian O’Sullivan Huawei

2. Importance of ONAP External Open API Framework
The Open Network Automation Platform must unlock the capabilities of the hybrid network and enable an ecosystem of Business Partners, Enterprises and Customers through the use of well defined, standardised open APIs.
The use of Open APIs will allow each of the actors that interact with the ONAP to benefit from the Agility of Automation.

3. TMF Open API Program Summary
TM Forum have crowd sourced a series of business management APIs through its members and aims to become the standard for Open APIs that enable rapid, repeatable, and flexible integration among operations and management systems
TM Forum announced that 42 of the world’s leading service providers and technology ecosystem participants have signed the Open API Manifesto publicly demonstrating their endorsement of TM Forum’s suite of Open APIs
These Service Providers have committed to:
adopt TMF Open APIs as a foundational component of their IT architectures;
promote global adoption of the API suite by their partners;
expect vendors and systems integrators to support these APIs in their products and cloud-based services. 
these Service Providers will include requirements in all future RFPs for support of these TMF Open APIs
ONAP Beijing Introduced the TMF 641 Service Order, TMF 633 Service Catalog and TMF 638 Service Inventory APIs

4. MEF LSO – Management Interface Reference Points (MIRP)
ONAP Beijing has focused on the LEGATO (BUS:SOF) reference point using the TM Forum Open APIs for Service Catalog, Ordering and Inventory. The goal of LEGATO is to open up the capabilities of Service Orchestration for ease of Integration with the BSS.
Future Releases of ONAP will try to also cater for inter ONAP communication across the INTERLUDE MIRP. INTERLUDE shall cater for APIs that will allow sharing data like Service Faults & Policies between ONAP Instances or other Orchestrator Platforms in Partner Domains.
The Communication between SO and the ONAP Controllers ( SDNC/VF-C/APP-C) & Mult-VIM maps to the MEF LSO PRESTO MIPR. These particular PRESTO APIS may be considered as ONAP Internal APIs.
Southbound of ONAP there is a mixture of PRESTO ( e.g. when SDN-C communicates to External SDN Controllers) and ADAGIO (e.g. when SDN-C communicates to Elements Control and Management via NETCONF ).

5. Mapping ONAP API Architecture With MEF LSO MIRPs
ALLEGRO (CUS:SOF)
Customer Application Coordinator Communication to ONAP for Customer Service Control, Service Performance/fault monitoring etc
LEGATO (BUS:SOF)
BSS - ONAP communication to support Service Catalog, Ordering, billing, Service inventory via TMF Open APIs etc
INTERLUDE (SOF:SOF)
To allow ONAP –> ONAP/3rd Party inter Partner or OpCo Domain Orchestrator communication
ADAGIO (ICM:ECM)
For Controllers layer direct communication to Element Control & Management, e.g. SDN-C via NETCONF/RESTCONF to Network Elements or the VF-C’s GVNFM to VNFs
PRESTO (SOF:ICM)
For Service Orchestrator Communication to ONAP Controllers ( SO -> VF-C/SND-C/APP-C ).Also for Controller layer communication to other External Controllers e.g. External SDN Controller or a SVNFM

6. Business Support Systems
ONAP External Open APIs
Operator
Partner
Enterprise
Consumer
Other Orchestration Platforms
Business Support Systems
Northbound Open APIs
East/West APIs
Other ONAP Instances
Southbound Open APIs
Note- trusted providers of a service
(e.g. operator owned transport, or cloud infrastructure)
do not need to pass through External API Framework
Legacy OSS
External Controllers
vEPC
vMSE
vSDM
GSM
UMTS
LTE
vIMS
ADSL
VDSL
G.Fast
Telco apps SMS/IPTV…
IT apps (XaaS)
vNE
vCDN

7. Categorizing ONAP External Open APIs ( non-exhaustive list)
Service Catalog APIs
Service Qualification / Service Feasibility APIs
Service Ordering & Activation APIs
Service Inventory / Topology / Operational State APIs
License Management APIs
Billing Management / Service Consumption / Usage APIs
Security Management / Privacy Management APIs
Service Quality Management / Service Level Agreement APIs
Service Test Management/Service Monitoring APIs
Resource Reservation / Address Allocation Management APIs
Service Trouble Ticketing APIs
Change Management APIs
Service Policy Management APIs
Service Instantiation/Configuration/Activation Inter Domain APIs
Service Policy Management/Distribution APIs
Service Event Sharing APIs
Service State Sharing APIs
Service Performance Sharing APIs
Service Fault Sharing APIs
Inter-Domain e-2-e Service Test APIs
License Management Inter Domain APIs
Inter Domain Resource Reservation APIs
Inter Domain Service Consumption/Usage APIs
Inter Domain Service Trouble Ticketing APIs
Legacy OSS/EMS Adapter APIs
External Controller APIs
Data Collection APIs ( Performance, Fault , Usage)
External Inventory / Topology Discovery APIs
Multi-VIM Southbound APIs / SVNFM Adapter APIs
Policy Management/Distribution APIs
Network Adapter APIs ( RESTCONF / NETCONF / BGP-LS / PCEP … )
Configuration Adapter APIs ( Chef , Ansible, Puppet … )

8. ONAP R2 External API Framework APIs Current Picture
ONAP external API component features 3 APIs & operations delivered by Orange:
serviceCatalog – only serviceSpecification resource – operations GET byList and GET byId
serviceInventory – service resource – operations GET byList and GET byId
serviceOrder - serviceOrder resource - operations POST, GET byList & GET byId for serviceOrder

9. Summary of ONAP API Development Effort
API Category
Delivery Status
Effort Needed
Comments
Northbound
(LEGATO / ALEGRO)
Partially Delivered
Development required to integrate Delivered APIs to ONAP Use Cases to allow e-2-e Service Management including Service Modification.
Design & Dev required to extend scope with new APIs
These APIs need to be expanded to ease the integration between BSS and ONAP for Commercial Deployments
East/West
(INTERLUDE)
Not Delivered
Design and Development of both the APIs and cooperation policies necessary for communication with other Orchestration Platforms or ONAP Instances
New ONAP Use Case Requirements need to drive the INTERLUDE APIs Design and Development e.g. CC VPN Connectivity Use Case
Southbound
(PRESTO/ADAGIO)
Delivery of further Southbound Adapters for Control, Inventory Discovery and Data Collection of the Hybrid Network.
New Legacy Adapters to be provided including external Inventory Discovery

10. Scope of ONAP Northbound APIs
Objective/Goals:
The ONAP Northbound Open APIs should be proficient at unlocking the capabilities of the Hybrid Network and exposing it to the Business Support Systems layer with the minimum of Integration Costs. The ONAP Services and capabilities should be discoverable, allowing the BSS Systems to incorporate ONAP Services into Product Offerings. The control and self-serviceability of these Services are required to be exposed through well defined APIs. The ONAP Northbound Clients such as the Enterprise and Consumers Clients should have the ability to both understand how their Service is Performing and how it can be self-customized to their needs.
ONAP Northbound Open APIs ( non-exhaustive list) :
Service Catalog APIs : To expose the Service Capabilities of ONAP for inclusion in Product Offerings
Service Qualification/Service Feasibility APIs : To establish pre-order that a particular Service flavor can be delivered
Service Ordering & Activation APIs : To allow northbound client to order, activate and modify the ONAP Services
Service Inventory/Topology APIs : To provide Clients access to their Service Inventory views within their allowed scope.
Service Monitoring APIs: To allow Clients to create Service Quality/Performance/Fault views of their ONAP Services
Licensing Management APIs : To link the Licensing constraints of the ONAP Services to Product Offering License agreements
Service Policy Management APIs : To allow Client Service Policies to be Managed
Billing Management/Service Consumption/Usage APIs : To allow northbound clients access to Service usage & consumption metrics
Security/Privacy Management APIs : To allow the Clients to adjust security/data retention levels of the data associated with their services
Service Quality Management/Service Level Agreement APIs : To allow SLA/SLS adjustment, monitoring & reporting
Service Test Management APIs : To allow clients to test services and view test result reports e.g. service activation tests
Resource Reservation APIs : To allow clients to reserve specific resources for future use.
Service Trouble Ticketing APIs : Enable the Auto generation/management of Service Trouble tickets based on Service fault data
Change Management APIs : Enable co-ordination with BSS/Customers on planned changes to Service Infrastructure and Networks.

11. Beijing Delivered ONAP Northbound APIs Summary
Category
Description
Delivery Status
Effort
Service Catalog APIs
Allows the Service Specification Capabilities of the ONAP Services to be discovered for inclusion in Product Offerings in the BSS
Delivered in ONAP Beijing Release
Need to include a TOSCA REST Toolset in SDC, to allow using new SDC apiSchema in Service Catalog API. Potential addition of Notification and complex Input Parameters types support
Service Ordering & Activation APIs
To allow northbound clients to order, activate and modify the ONAP Services that are exposed from the ONAP Service Catalog
Effort to connect SO APIs for full E2E service creation/activation and add service modification support. Also require the ability to track Service Order Items related Service State via notifications
Service Inventory / Topology APIs
To provide access to the clients of Service Inventory views within their domains
Development needed to support better Service State management via notifications and more comprehensive Topology traversal capability in the APIs. Add support for depth and expand directives from TMF API Design guideline 3.0 on Service Inventory API.

12. Service Catalog API Enhancement Proposal
TMF/MEF LEGATO External Open APIs
Business Support Systems
Business Support Systems
ONAP Platform
Internal APIs
Query L2 Service Catalog (TMF633)
HTTP GET
Query L2 Service Catalog (TMF633)
HTTP GET
Currently : ONAP External API Framework
Uploads the full TOSCA CSAR file from SDC to extract ServiceCharacteristics from the TOSCA.
This uploading of the full CSAR to extract the Service Characteristics is repeated everytime the Service Catalog API is called which is a waste of resources as a Designed Service Charaterisitic definition does not change.
Proposal : ServiceSpecification ServiceCharacteristics are extracted from the TOSCA Service Topology at Design time and stored for use by the RunTime Components. In the case of External API Framework, the ServiceCatalog API can simply learn the ServiceCharacteristics in Swagger format directly from SDC using a new URL.
External API Framework
External API Framework
CSAR
GET {{url}}/sdc/v1/catalog/services/{id}/apiSchema
GET {{url}}/sdc/v1/catalog/services/{id}/toscaModel
SDC
SDC
ONAP Beijing Flow
Proposed ONAP Casablanca Flow

13. YAML(TOSCA) parser to Swagger Schema addition within SDC
After reading the CSAR from Catalog-UI SDC (catalog-ui/src/app/services/components/component-service.ts)
YAML parser code (jackson JSON lib) (./src/main/java/org/onap/nbi/apis/servicecatalog/ToscaInfosProcessor.java) can be moved from NBI to SDC to (catalog-be\src\main\java\org\openecomp\sdc\be\components\impl\ServiceBusinessLogic.java)
Generate Swagger api Schema for at least Service Characteristics (i.e. Service Topology TOSCA “Inputs” and their associated datatypes into Swagger “definitions” for "parameters“ for “post” of new Service ) see MEF SONATA example from
Stretch goal to also generate Swagger Schema for all interfaces or operations allowed on the Service, i.e. use of “path” for allowed interfaces , e.g. modify
Swagger JSON (or YAML) moved as a bean into Cassandra back-end (openecomp-be\lib\openecomp-sdc-model-lib\openecomp-sdc-model-core\src\main\java\org\openecomp\sdc\model\impl\AbstractServiceModelDao.java)
Swagger JSON Schema .json (or YAML) can be accessed through a new RESTful GET {{url}}/sdc/v1/catalog/services/{uuid}/apiSchema

14. Simplification of Service Catalog API
apiSchema
ServiceCatalog
ServiceOrder
Referenced In
Populated In

15. Simplification of Service Catalog API continued
Current
Proposed
Remove Internal SDC URL and Resources
from the ONAP External facing API?
Wrap ServiceCharacteristics into
an Object valueType and pass on
Swagger Schema of Characteristics
For the Service Object in one file.

16. ONAP Northbound APIs Potential Enhancements
Provide support for more than just simple Input Types (Integer, String & Boolean) for Service Characteristics in both Service Catalog and Service Ordering APIs, this will involve support of other projects also ( SDC, SO, APP-C, VF-C and SDN-C ) e.g. in support of passing L2 Connectivity Bandwidth Profiles as an example.
Update ServiceOrder API to manage Service modification requests, i.e. a ServiceOrderItem with an action of “modify” on an existing Service Instance, support needed from SO to handle modify requests. Potentially this could be used by CC VPN use case to allow the Customer to modify the configured EPL Bandwidth for example ( e.g. BoD) via a self service portal.
Have a use case such as the CC VPN or VoLTE use the ONAP External APIs in ONAP R3 Casablanca
Add Notification Support to all 3 APIs. According to the TMF, support is enabled via add a “hub”.
e.g. POST /api/hub
Accept: application/json
{"callback": "
Service Order API : Allow northbound clients such as the BSS to receive Order/OrderItems updates. For example to provide ServiceOrderStateChangeNotifications to HUB subscriber, which negates mandating the Client for unnecessary polling
Service Catalog API : Allow ONAP northbound clients to receive service catalog notifications such as Service Specification Service characteristics changes, thus allowing for northbound clients such as self-service Ordering portals to learn the required changes to input parameters.
Service Inventory API : Allow External systems to receive service state update notifications.
Provide a more comprehensive Service Order Item Tracking capability. Updates are also needed to consolidate and enhance the SO APIs to allow for better Service State tracking via Notifications.
Work to enhance A&AI Schema, for example to establish if Customer & Service Subscription are required in a Service Order?. Once an agreed A&AI Schema is enhanced, then updates may be required to the Service Ordering processes e.g. potential updates to CreateAAIServiceTypeManager

17. ONAP Northbound APIs Potential Updates
Potential to add an ONAP API Store to the External API Gateway ( to provide BSS developers a sandbox to test ONAP APIs/ Subscribe )
Tighter integration for External API Framework APIs with the MSB ( External API Gateway ) and AAF.
Register the External APIs URLs with the MSB External Gateway using either the kubemsb method with OOM ( updating the yaml) or using the msb sdk code within the ExtAPI Framework
Allow ExtAPI to use MSB Discovery to discover SO, SDC and A&AI endpoints. This depends on SO , SDC & A&AI all utilizing the MSB which may be at risk in Casablanca.
Extra Security on External APIs at the External Gateway, such as OAuth subscriptions.
Improve External API Transaction Logging , for example using the OpenResty External Gateway logging with DCAE analytics or utilize other open source tooling capable of giving API transaction logging, Real-time analytics and log monitoring, exposing any potential API problems

18. A Potential Role for External API Framework in CC VPN ( Initial focus on APIs 1-4 below i.e. LEGATO/INTERLUDE)
API
Description
Impact
Service Catalog
Expose the CC VPN Service Model Specification to external BSS/CRM for inclusion in Product Offerings.
Can utilise the External API Framework Service Catalog API to show external facing service specification data model.
Service Inventory
Allow for the BSS/CRM visibility into the ordered CC VPN Service Instance. This may allow the BSS/CRM the ability to show a Customer facing self service display of the Customers Service Topology, and potentially link it to Service Monitoring metric displays
Extending API of AAI and External API for a more comprehensive Service Inventory Topology Traversal
Service Order
Allow for the Creation of a Self-Service Customer Service Ordering portal to allow CRUD operations on the Customer CC VPN service
Requires linking the capabilities of the CC VPN UUI-> SO into external API framework
Partner Service
CRUD
Allow the Access (OVC) Service to be order from Partners ONAP ( SOF:SOF)
Impacts to SDC/SO/Policy to accomplish this
SDC SO
AAI
SDNC
External API
Service Catalog
Service Order
Service Inventory
Partner Service
CRUD 1 4 3 2
CMCC
VDF
TMF 633
TMF 638
TMF 641
ONAP
ONAP

19. Service Order API E2E Support
TMF/MEF LEGATO External Open APIs
Business Support Systems
Business Support Systems
ONAP Platform
Internal APIs
Create Service Order (TMF641)
HTTP POST
Create Service Order (TMF641)
HTTP POST
Currently : ONAP External API Framework
In Beijing uses the VID orientated API to instantiate a Service Instance. However there was no E2E Use Case provisioning using External APIs, i.e. to create a Service and the underlying resources and connectivity like in VoLTE. However to instantiate VoLTE service in SO uses {{url}}/e2eServiceInstances/v3 API.
Proposal : To allow a Service Order instantiate both an E2E Service like VoLTE or a Service Instance like vFW/vCPE the External API Framework either needs SO to consolidate these 2 APIs together (More Optimal Long Term Option) or else the ExtAPI needs to be updated to allow also calling the {{url}}/e2eServiceInstances/v3 API
External API Framework
External API Framework
POST {{url}}/e2eServiceInstances/v3
&&
POST {{url}}/ecomp/mso/infra/serviceInstances/v4 OR
New Consolidated POST {{url}}/serviceInstances/v5
POST {{url}}/ecomp/mso/infra/serviceInstances/v4 SO SO
ONAP Beijing Flow
Proposed ONAP Casablanca Flow

20. CC VPN – Impacts on ONAP to Support INTERLUDE
LEGATO (SOF:SOF)
Simplest approach is for the Service Orchestrator to request the Access Service from a Partner using Partners ONAP External API Framework. The Service Order TMF 641 API could create the Access Service request and register a listener for ServiceOrderStateChangeNotifications . The CMCC SO could retrieve any service attributes it needs from the Partner VDF Domain using Service Inventory API TMF 638
SDC
Will need to be able to model the E2E Service. How will Service Composition include the Partner Domains Catalog for the Partner Access Part
Partner Policy
For the Service Orchestrator to know which Partners it can communicate with and for which Services. Policy Framework will need to provide control

21. MEF INTERLUDE - Policy Framework Enhancements
“INTERLUDE (SOF:SOF): The Management Interface Reference Point that provides for the coordination of a portion of LSO services within the partner domain that are managed by a Service Provider’s Service Orchestration Functionality within the bounds and policies defined for the service.”
ONAP Current Policy Framework consists of a Policy Administration Point (PAP) and two Policy Decision Points consisting of a Drools based PDP-D for Operational Polices and an XACML based PDP-X for Guard Policies.
Enhancement to Policy may include defining Partner Services that can be delivered via INTERLUDE. This may involve registering the Partner Domain External API framework endpoints, identifying Partner Service Specification IDs for which this Service Provider can utilize in SDC for E2E Service Design. Perhaps XAMCL can be utilized for defining INTERLUDE Service “Access” Policies
Additionally Policies need to be defined between Partner on what Service Event ( FM/PM etc ) can be shared between the Domains. i.e. Possible extension of DMaaP to support external publishing of events to external Consumer within Policy Constraints

22. Potential Future ONAP Northbound APIs (LEGATO / ALLEGRO)
Category
Description
Delivery Status
Effort
Service Monitoring APIs
To allow Clients to create Service Quality/Performance/Fault views of the ONAP Services
Not Delivered
Work needed to expose Service Performance data as collected in DCAE to the BSS layer e.g. as shared to the UUI for VoLTE Use Case
Service Qualification / Service Feasibility APIs
To establish pre-order that a Service flavor can be delivered. Pre-Oreder verification there is available capacity and topology to support a specific set of service parameters
Effort in Service Orchestrator to support service feasibility checking. E.g. BPMN workflows to support Resource Availability & Capabilities checks ( e.g. what is the available bandwidth/number of connections left on a UNI )
License Management APIs
To expose Client facing Licensing constraints of the ONAP Services e.g. specific VNFs licensing constraints incorporated into Product Offering License agreements created for Customers
Efforts to link from SDC Licensing modules from on-boarding/VSP design to external BSS facing licensing management APIs

23. Potential Future ONAP Northbound APIs (LEGATO / ALLEGRO)
Category
Description
Delivery Status
Effort
Security Management / Privacy Management APIs
To cater for security management and control mechanisms. Allow Clients to adjust of their data retention level and the use of their data
Not Delivered
Effort needed with MSB (External Gateway) & AAF in terms of security hardening. Potential adjustments to DCAE to controls Customer data retention and allowed analytics
Billing Management / Service Consumption / Usage APIs
To allow northbound clients access to Services usage ( e.g. bandwidth consumption ) for use in Billing or SLS/SLA analysis
Efforts needed to discover consumption via data collection and analytics ( DCAE ) and expose northbound standard Customer usage of Services via APIs
Service Trouble Ticketing APIs
Allow for correlating faults from DCAE into auto trouble ticket generation or auto update Customer initiatedTrouble Tickets
Effort needed to link DCAE and Closed Loop Automation to trouble ticketing. E.g. if a Closed Loop Automation fails, auto generate trouble tickets for effected customers

24. Potential Future ONAP Northbound APIs (LEGATO / ALLEGRO)
Category
Description
Delivery Status
Effort
Service Quality Management / Service Level Agreement APIs
Management of SLA/SLS. The ability to ompare the service performance metrics with the service quality objectives described in the SLA/SLS. Create a link to maintain configured SLA/SLS through these APIs with Service Policies.
Not Delivered
Effort to maintain SLA/SLS configuration /Activation/enforcement, SLA Operations, SLA violation / consequence handling, SLA reporting. Create link between SLA and Service Policies
Service Test Management APIs
Management of Service Activation and Customer Acceptance Testing & Reporting. Each service test can be a process intended to check the quality, performance, or reliability of the service. Once the Service Test is completed, these APIs allow for Clients to obtain the test reports
Effort needed to be added in Service Orchestrator & the Controller layer to support the ordering of the activation of Service Testing. Also coordination with DCAE for result analysis & test report generation.

25. Potential Future ONAP Northbound APIs (LEGATO / ALLEGRO)
Category
Description
Delivery Status
Effort
Resource Reservation / Address Allocation Management APIs
These APIs allow for the reservation of resources for future use in Service delivery.
e.g. reserving specific service related resources for a given period of time until the initiating Customer order is confirmed, or until the reservation period expires.
Not Delivered
Effort to Service orchestrator to relay/manage resource reservation requests to controller/multi-vim layer. Also updates to support A&AI maintaining Customer Address allocations and associated pooling available allocation for related services
Service Policy Management
Allow for a Customer / Service Provider to adjust Customer specific or Service Specific Policies within the limits allowed to them.
Effort to link to CLAMP/Policy/DCAE on adjusting Service Policies ( e.g. Customer Specific ) via external BSS requests within the limit/scope defined by security policies
Change Management APIs
Ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to Service Infrastructure and Network
Potential External facing API to link to VID Change Management

26. Scope of ONAP East/West APIs (INTERLUDE)
Objective/Goals
The ONAP East/West Open APIs allows ONAP to cooperate with other Service Orchestration Platforms ( perhaps in another partners domain or in another OpCo ). These cooperating Service Orchestrations Platforms may be other instances of ONAP or another open source or Vendor specific Service Orchestration Platforms. The East/West Open APIs of ONAP need to allow Service Information like Service Faults, Performance, Policies to be shareable ( within the Sharing Policies defined SOF:SOF ) with other Orchestration Platforms. These East/West APIs may also allow sub components of a Service to be delivered via another partners/OpCo Orchestration Platform. This feature is accomplished by allowing Orchestrator to Orchestrator platform cooperation through a new set of East/West Open APIs.
ONAP East/West Open APIs ( non-exhaustive list) :
Service Instantiation/Activation/Configuration APIs : To expose the Service Capabilities of ONAP for including in Product Offerings that cross multiple domains e.g. a Service needing a Partners Network in addition to the Service Providers Network like an EVC comprised of 2 or more OVCs for L2 Connectivity
Service Event Sharing APIs : To allow Events from the ONAP DMaaP to be shared across domains to allow for full Closed Loop Automation.
Service Performance Sharing APIs : To allow Service Performance Data to be shared across ONAP instances or partner domains
Service Sharing Fault APIs : To allow Service Fault Data to be shared across ONAP instances or partner domains e.g. OpCo -> OpCo
Service Policy Management/Distribution APIs : To enable the ability to share federated Policies from one domain to another.
Inter-Domain e-2-e Service Test APIs : To allow for e-2-e Service Testing for Service, e.g. Service Activation Testing of an e-2-2 L2 EVC Connectivity service delivered as 2 OVCs, where each UNI is in separate Operator CEN.
License Management Inter Domain APIs : Create the ability for Licensing Constaints on Service Resources to be shared between cooperating domains
Inter Domain Resource Reservation APIs : The Ability for a Service Provider to reserve resources in the Partner Domain or vice versa.
Inter Domain Service Consumption/Usage APIs : To allow full e-2-e service comsumption to be known, for example in the inclusion of usage policies.

27. Potential Future ONAP East/West APIs (INTERLUDE)
Category
Description
Delivery Status
Effort
Service Instantiation / Configuration/Activation Inter Domain APIs
These APIs allow inter domain ONAP -> ONAP/External Service Orchestration Platform Service Creation and Activation within the Policies defined between the Domains. E.g. An EVC needing an OVC from Partner Domain, linked via SOF:SOF policies
Not Delivered
Need to compose Services using Service Components/Specification from other domains. This implies a federated Service Catalog, which effort needed in Policy to control the partners scope. Domains may be Geographical regions within one Service Provider or may be separate Partner Domains. Impacts to SDC & SO also.
Service Policy Management/Distribution APIs
Service Policies may need to be shared to other Domains, e.g. Policy on how to maintain a bandwidth CoS. Policy Conflict Management is also required with Partner
Effort to introduce a policy broker for all interaction between policy domains, which includes policy language translation (e.g. DROOLS, XAMCL++, RUBY, etc.) to handle the exchange of policy and related knowledge with other Domain Orchestation Platforms
Service Event Sharing APIs
Allows Specific Events on the DMaaP to be propagated externally and vice versa
Effort involves interaction to allow INTERLUDE Event sharing to/from DMaaP with external Domains controlled via Policy

28. Potential Future ONAP East/West APIs (INTERLUDE)
Category
Description
Delivery Status
Effort
Service State Sharing APIs
These API’s support the sharing of Service Component State between Domains, e.g. to allow a partner domain to notify the operating state of a OVC, so as to allow the Service Provider the ability to report the overall EPL Service Operational State
Not Delivered
Effort to allow notification listeners of state changes in another domain for subcomponents of the Service that resided in that domain. Likewise, the ability within configured policies to share Service operation state externally
Service Performance Sharing APIs
To allow for Performance data to be shared between domains to enable e-2-e Closed Loop / Performance Correlation capabilities for Service traversing multiple domain Orchestration platforms
Effort in DCAE, DMaaP to be configured to allow external publishing and subscriptions to relevant topics for e-2-e Performance monitoring
Service Fault Sharing APIs
To allow for Fault data to be shared between domains to enable e-2-e Closed Loop / Fault Correlation capabilities for Services traversing multiple domain Orchestration platforms
Effort in DCAE, DMaaP to be configured to allow external publishing and subscriptions to relevant topics for e-2-e Fault monitoring

29. Potential Future ONAP East/West APIs (INTERLUDE)
Category
Description
Delivery Status
Effort
Inter-Domain e-2-e Service Test APIs
To allow for the orchestration of Service Tests such as Activation Tests or Customer Acceptance to be coordinated across multiple domains. E.g. in the delivery of an e-2-e EPL Activation test between 2 UNIs across 2 OVCs
Not Delivered
Effort to allow coordination of Service Testing from one domain to another domain, this may involve sharing test attributes via these APIs with external domains, activating the tests and the coordination of test result reporting.
License Management Inter Domain APIs
To allow federation of licenses of Service subcomponents to allow for the generation of e-2-e license agreements that can be exposed to the BSS layer. E.g. expose licensing constraints of a VNF in a partners domain
Effort to create the management of exchange of licensing information from one Service Orchestration platform to another.
Inter Domain Resource Reservation APIs
These APIs allow for the reservation of resources in another domain, and also to allow other domain Orchestration Platforms to reserve resources in ONAP
Effort required to support a Resource Reservation Management system with external orchestration domains.

30. Scope of ONAP Southbound APIs (PRESTO / ADAGIO)
Objective/Goals
The ONAP Southbound Open APIs supports the interchange of metadata between ONAP components such as the VF-C/APP-C/SDN-C/Multi-Vim to External Infrastructure Control and Management systems ( such as external SDN Controllers, SVNFMs, EMS… ) and directly to Element Control and Management for network elements( such as Routers , CPEs, PNFs .. ). Southbound APIs also cover the Data Collection APIs needed to monitor the hybrid Network elements and the network elements that are under the control of the External Systems. Note- Trusted providers of a southbound service
(e.g. operator owned transport, or cloud infrastructure) do not need to pass through the ONAP External API Framework
ONAP Southbound Open APIs ( non-exhaustive list)
Legacy OSS/EMS Adapter APIs : Adapters to legacy OSS systems and EMS APIs, to utilize existing Network assets and provide through Hybrid Network Orchestration capabilities.
External Controller APIs : To allow access to external controllers such as 3rd party SDN Controllers or other Open Source SDN Controllers. Data Collection APIs : To allow standard ways of importing data from disparate Hybrid Network elements to be utilized in driving closed loop automation within ONAP.
Multi-Vim Southbound APIs : To enable a standard way to communicate with multiple different IaaS layers including OpenStack, Azure, VmWare, WindRiver….
Network Adapter APIs : Which shall enable communication with ECM layer for configuring network element using for example RESTCONF / NETCONF / BGP-LS / PCEP
SVNFM Adapter APIs : To allow communication with Specific vendor VNFMs
Configuration Adapter APIs : Shall enable the communication necessary for the configuration of VNFs and PNFs ( Chef , Ansible, Puppet … )
External Inventory / Topology Discovery APIs : To enable the ability to discover external Inventory under the control of external systems to maintain A&AI as the source of truth for resources within the ONAP domain.

31. ONAP Southbound APIs (PRESTO / ADAGIO)
Category
Description
Delivery Status
Effort
Legacy OSS / EMS Adapter APIs
These API’s support the necessary adaption layer to existing legacy systems. These API s will be formed as a suite of adaptation modules to transform the ONAP Information Model into data Models / encodings that can be understood by the existing Legacy OSS and EMS
Not Delivered
Effort needed into having a common adaption sdk/layer that Controllers can use to transform from internal ONAP Information models into data models/necessary encodings of the various legacy OSS & EMS. These Adapters should be possible to build into Controller BPMN & Directed Graphs in a common manner
External Controller APIs
The External Controller APIs allow for a common framework to interface to external SDN Controllers. They link from SDN-C SLI logic via a common library to pass model driven data models ( e.g. Yang ) configuration information southbound ( e.g. RESTCONF ) and also allow External Controller Service/resource discovery
Required enhancement to have a common External Controller interface that can be used as a base to build specific external Controller interfaces to. For example interface to external vendor or other Open Source SDN Controllers ( e.g. ONOS )

32. ONAP Southbound APIs (PRESTO / ADAGIO)
Category
Description
Delivery Status
Effort
Data Collection APIs ( Performance, Fault , Usage)
This set of Open APIs is to cover the ingestion of Performance, Fault and Usage data into the ONAP Platform. These APIs can be an extension to the VES Collector to be expanded to support more hybrid Network data sources
Partially Delivered in ONAP Beijing
Work is required to extend the capabilities around the VES Collectors with additional collectors for data sources such as PNFs and existing OSS/EMS data collector, SNMP Trap Collectors,Syslogs and Netflow etc and their conversion into ONAP Data/Information Model.
External Inventory/Topology Discovery APIs
Create a suite of Discovery APIs allow for model driven methods to extend the Inventory discovery capabilities of A&AI. These APIs should be capable of linking to external Inventory systems and importing relevant topology into A&AI for use within ONAP to be a true source of truth for Service & Resources.
Not
Delivered
Work on extending External Inventory Discovery will involve first the Controller Layer & Multi-Vim having the capability to use APIs from the external system ( e.g. an external SDC Controller ) to discover relevant Inventory in the domain of these external systems. Effort is also required in A&AI to support schema enhancements to cater for an increased Topology view, with synchronization via APIs or Notifications from External Systems, e.g. via DMaaP to notify when External inventory changes occur

33. ONAP Southbound APIs (PRESTO / ADAGIO)
Category
Description
Delivery Status
Effort
Multi-VIM APIs
To support a cloud Mediation Layer supporting multiple infrastructures and network backends.
Partially Delivered in ONAP Beijing Release
Effort needed to expand the list of APIs that can interface to multiple Infrastrucure layers such as (Openstack, Azure, VmWare, Wind River , FushionSphere etc ).Also need to link VNF Onboarding & Orchestration processes to utilize Multi-VIM to for example use create image API to distribute VNF Images to VIM
SVNFM Adapter APIs
These APIs are used to interface with Specfic VNFMs such as the Huawei CSM from VF-C. They offer the control from the NFV-O to request VNF lifecycle managements
Enhancement needed to create a common Adapter API framework for integrating SVNFMs into the ONAP environment
Policy Management / Distribution APIs
APIs suite needed to delegate Policies to the External Southbound Systems like External Controllers, SVNFMs, OpenStack. Also enable Policy reporting in terms of actions taken, back to ONAP by external systems
Not Delivered
Effort needed to handle distribution and delegation of Policies defined in ONAP to External Systems, ( i.e. the ability to delegate Closed Loop Actions to external southbound systems for the most efficient processing ).

34. ONAP Southbound APIs (PRESTO / ADAGIO)
Category
Description
Delivery Status
Effort
Network Adapter APIs
These APIs allow a Network adaption layer southbound of the APP-C & SDN-C to communicate with Network Elements
Partially Delivered in ONAP Beijing
Extend the capabilities of adaption layer for NETCONF/RESTCONF, BGP – PCEP to include any relevant adaptation needed.
Configuration Adapter APIs
These APIs allow configuration of the VNF after it has been Instantiated. This API Adaption layer is included southbound of APP-C in the form of Chef, Puppet, Ansible adapters. Also could extend the scope to cover PNFs , where configurable interfaces exist.
Extend the capabilities of adaption layer for ansible, chef , puppet, …. to include any relevant adaptation module/APIs needed