Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Deliver points of interoperability between ONAP and External Systems
  • Focus on ONAP External APIs to BSS/OSS (i.e., MEF Legato)
    • Service Catalog
      • Add notification for serviceCatalog API
        • Description:
          • Allow BSS catalog function to receive service catalog notification as serviceSpec status change or characteristic change (new value in an enum list for example). Could be interesting to track these serviceSpec update to update accordingly productSpec
        • Relevance:
        • Complexity: Easy
        • Prerequisites: It requires to have a notification from SDC because NBI will not pool AAI
        • Resources:
      • Improve ServiceCatalog API for characteristicservice characteristics
        • Description:
          • Expose from NBI json (or other format) file describing the serviceSpec characteristic (same type of file we can retrieve on MEF Git Hub to describe an UNISpec for example)
          • Convert YAML in CSAR to ONAP wide consistent JSON schema for Service Characteristic Input parameters and provide across the ServiceCatalog API
        • Relevance:
        • Complexity: Easy
        • Prerequisites: Need SDC improvements
        • Resources:
    • Service Ordering (including Service Instantiation)
      • Add notification for serviceOrder API
        • Description: 
          • Allow BSS (or any other) system to receive order/OrderItem update. BSS (or any other system) will not have to pool. We can allow several distinct notification (Nice to have: let subscriber specify notification contains). Minimum is to provide ServiceOrderStateChangeNotifications etc to HUB subscriber. After if we’re able to get a notification from SO it will be perfect but initial requirement is only at external API northbound
          • Notifications related to ServiceOrder: - ServiceOrderCreationNotification - ServiceOrderAttributeValueChangeNotification - ServiceOrderStateChangeNotification - ServiceOrderInformationRequiredNotification - ServiceOrderRemoveNotification
        • Relevance:
        • Complexity: Easy
        • Prerequisites: Nothing for basic deliver…SO notifications to have high performance (without SO notification, NBI will pool SO as of today)
        • Resources:
      • Update ServiceOrder to manage Service modification request UC
        • Description: 
          • This will allow BSS system to trigger service modification request. By modification we mean: characteristic value change, status change (other ?). Minimum could be to handle modification that can be managed in SO with a Delete Service and then Add service (this is a change up to nbi but remove/add down to nbi). This is not service order modification butt service modification on existing service instance in the inventory (new service order with action change)
          • Possibly related to CC VPN use case, explore other use cases
        • Relevance:
        • Complexity: Average to High depending on SO capability to handle service modification
        • Prerequisites: could require SO upgrade – Check if some use case can be handle by NBI only (triggering add/remove in SO)
        • Resources:
    • Service Inventory (specification focus) (stretch goal: implementation)
      • Add notification for serviceInventory API
        • Description: Allow BSS (or any other) system to receive service state update.
        • Relevance:
        • Complexity: Easy
        • Prerequisites: It requires to have a notification from AAI because NBI will not pool AAI
        • Resources:
      • Improve ServiceInventory API
        • Description:
          • As of now we retrieve very few information from AAI – Perhaps digging more in the instantiated VNF or VF could allow us to have more information as service state or serviceCharacteristic for example.
        • Relevance:
        • Complexity
        • Prerequisites: Need AAI expertise; Need enhancement to AAI UI to see more topology details across API
        • Resources:
    • Service Topology (stretch goal) (specification focus)
    • License Usage (stretch goal) (specification focus)
    • Integration 
      • Integrate External API/NBI within ONAP MSB
        • Description: May need to consider how External API agent functionality can be decoupled from MSB
        • Relevance:
        • Complexity
        • Prerequisites:
        • Resources:
      • Build End-to-End Use Case
        • Description: Showcase External API from a complete Service Lifecycle perspective. Apply ONAP Use Cases.
        • Relevance:
        • Complexity
        • Prerequisites:
        • Resources:
  • Initial focus specification of ONAP External APIs supporting Inter-Provider (i.e., MEF Interlude)
    • Service Control (specification focus)
    • Service State (operational state) (specification focus)
    • Service Inventory / Details (specification focus)
  • Explore Role-based view of single APIs descriptors for both Legato and Interlude

  • Alignment with MEF Legato, MEF Interlude and TM Forum APIs

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

  • API definition (JSON Swagger) for

    • License Usage

    • Service Modeling and Service Topology

    • Service Inventory

    • Service State Management

    • Service Quality Management

  • Define API Styles to be applied to External APIs (along with Micro-service Bus (MSB) and Modeling Project)

  • 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
  • Architecture for External APIs
    • Identification and involvement of stakeholder ONAP projects
    • Describe key External API foundation functionalitesfunctionalities
    • Work with Architecture and MSB projects
  • Document the role and requirements of External APIs in Model Driven ONAP
    • Work with Modeling project and sub-committee 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 with Modeling Project

...