Project Name:

  • Proposed name for the project: External API Framework
  • Proposed name for the repository: externalapi

Project description:

  • This project will describe and define the APIs between ONAP and External Systems, including ONAP interfaces targeted on BSS/OSS, peering, B2B, etc.
  • Proposed initial focus may be on the Common APIs between ONAP and BSS/OSS.

  • Common APIs between ONAP and BSS/OSS allow Service Providers to utilize the capabilities of ONAP using their existing BSS/OSS environment with minimal customization.

Scope:

  • Deliver points of interoperability between ONAP and External Systems
  • Initial focus on ONAP APIs to BSS/OSS
  • May support the following capabilities:
    • Service feasibility; 
    • Service provisioning configuration & activation; 
    • Usage events & metrics; 
    • License accounting; 
    • Service performance & quality; 
    • Service Trouble management;
    • Service policy; 
    • Capacity engineering;
    • Address allocation management

  • initial focus is likely to be: “Service provisioning configuration & activation”, "License management", and “Address allocation management”

  • Definition of Use Cases, Interactions, and Information Model engaging service providers and BSS/OSS vendors

  • API development (in conjunction with specific ONAP component projects)
    • Well defined specifications for the NB APIs (e.g., JSON Swagger). 
    • ONAP implementation of these APIs
  • Work with Modeling project to explore a Model Driven approach: a cohesive way to have a shared view of information across ONAP external interfaces that can be used for or be input into a model driven process whereby the cost of delivering platform functionality is drastically reduced and the time to delivery is dramatically decreased.
  • Explore use of Model Driven Tool Chain to automatically generate APIs based on models
  • Main deliverables of this project may include: User Stories; Use Cases and Interactions (e.g., UML); Information Models (e.g., UML); Data Models (e.g., JSON); Interface Profiles and Functional Definition; ONAP Component Mapping and Functional Analysis.

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?

    • What other ONAP projects does this project depend on?
      • This project will also analyze the functionality of the implemented set of APIs in ONAP components that are relevant to providing the described external interface functionality. Mapping and alignment between this project and the ONAP components implementing the supporting APIs is essential since functional API gaps and potential enhancements will be identified based on the functional analysis. This project also allows the pertinent ONAP component specific external API artifacts (e.g., JSON/Swagger) to be collected and referenced. 
      • Define external API capabilities to support the Change Management project
      • Will work with the Modeling project to: identify overall modeling guidelines and approaches, determine modeling tools and tool chaining, and identification of industry standard models (e.g., TMF SID, ONF TAPI, etc.) that may be applied to the APIs
      • Service Orchestrator: Will work closely with the Service Orchestrator team to gather information about the relevant Service Orchestrator APIs (particularly the Service Instantiation API). Will collaborate with Service Orchestrator team to ensure that APIs remain consistent for R1.
      • External APIs team will work closely with the Standards Coordinator as there will be related activities in the TM Forum, MEF, etc.
      • Align with ONAP Use Cases
      • A&AI
      • DCAE
      • SD&C
      • Controllers
      • DMaaP
      • Reference VNFs (related Use Cases)
  • How does this align with external standards/specifications?
    • Work with Modeling project to determine base service abstraction Information Model on best in breed standard models (e.g., MEF 7.3 Service Info Model, etc.)
    • MEF LSO Legato (MEF 7.3 Service Info Model)
    • TM Forum Zoom effort and related TM Forum APIs where applicable. TM Forum APIs to consider include:
      • Service Catalog (TMF633)
      • Service Order (TMF641)
      • Resource Order (TMF652)
      • Service & Resource Activation & Configuration (TMF640)
      • Service Inventory (TMF638)
  • Are there dependencies with other open source projects?
    • TBD

Resources:

Other Information:

  • link to seed code (if applicable)
    • Potentially the Service Orchestrator's Service Instantiation API
  • Vendor Neutral
      • This project is vendor neutral and open-sourced under the Apache license from the OPEN-O project
  • Meets Board policy (including IPR)

Use the above information to create a key project facts section on your project page

Key Project Facts

Project Name:

  • JIRA project name: externalapi
  • JIRA project prefix: externalapi

Repo name: 

  • org.onap.externalapi/nbi


Lifecycle State: incubation
Primary Contact: Andy Mayer, AT&T, am803u@att.com 
Project Lead: Andy Mayer, AT&T, am803u@att.com
mailing list tag [externalapi] 
Committers for release 1:

*Link to TSC approval: 
Link to approval of additional submitters: 



  • No labels

11 Comments

  1. Dhananjay Pavgi

    How does this work in conjunction with TMF Open APIs? Suggest reusing as much as we can from TMF. Also, Brijesh Khandelwal How does this relate to Microservices Framework? 

    1. Andy Mayer

      Good suggestion on exploring the TM Forum APIs Dhananjay Pavgi. In the proposal, we identified the TM Forum APIs as a related external standards activity. In addition another related activity, MEF LSO, is currently partnering with the TM Forum in applying the TM Forum APIs within the MEF LSO reference architecture context.

      1. Tony Lo

        LSO Reference Architecture does give a very logical way of dividing up different APIs grouping , e.g. Business Application, Service Orchestration etc.

  2. Alexander Vul

    Andy, we should consider not only the northbound interfaces for interoperability and integration, but also east-west interfaces for P2P integration and southbound interfaces for infrastructure ingestion and on-boarding. I don't think northbound interfaces are going to be enough...


    1. Andy Mayer

      Alex, thanks for the review. In the project description it states that the project will describe and define the APIs between ONAP and External Systems. However, the proposed initial focus may be on the Common APIs between ONAP and BSS/OSS. 

  3. Sandeep Shah

    what is a mechanism to interface with BSS systems in the current ONAP instance made available? Thank you.

  4. Karan Wadhwani

    As I understand, you can come to the ONAP PORTAL and submit the provisioning order vIa BSS systems and inturn involve SO/MSO APIs to provision the network services.

  5. Earle West

    Does this exclude APIs used by controllers (e.g. ONAP-OM) having adapters to Openstack, etc.?

  6. Manoj Nair

    If I understand correctly the Service orchestration, change management is done through the VID project in ONAP. So External API is going to align with VDI project as well? and define the requirements for VID ? This is missing in the dependencies above. 

  7. Chris Sommers

    May I humbly suggest that the API schema use YANG (possibly derived from UML if that is your canonical definition of choice)? Then YANG can be translated into XML or JSON using well-defined IETF standards. Starting with JSON/Swagger is too concrete a starting point IMO. Notice that in ONAP, VNF APIs must be specified in YANG. Declaring the API in YANG allows use of NetConf or RestConf or gNMI or whatever transport you want. The schema is what counts. It is the trend that service abstraction to be defined in YANG. Thanks.

  8. Laurentiu Soica

    For the current ONAP codebase (R1.0.0, seed code) are there any BSS/OSS interfaces available or it is a new feature planned for the Amsterdam Release ?