You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

1- Brief Project Overview (brief as it should be known)

This use case intends to demonstrate the ETSI-Aligned modeling, package distribution, and orchestration by conforming to ETSI NFV. This use case shall support:

  1. VNF modeling with minimum CNF enhancements from ETSI NFV 4.1.1, by conforming to the ETSI SOL004 Package and SOL001 Modeling standards
  2. automated NSD and VNF/CNF package E2E distribution, by conforming to SOL005 and SOL003 Package Management APIs
  3. NS and VNF Orchestration through a modular architecture and standards-based (ETSI NFV) interfaces, by conforming to SOL005 and SOL003 LCM standards


2- New component capabilities for Honolulu, i.e. the functional enhancements, if applicable

 


  • SO / SO NFVO
    • SO NFVO continues to support the same SOL005 APIs as Guilin: Create NS, Instantiate NS, Terminate NS, Delete NS and Get NS Operation Status.
    • SO NFVO Honolulu Architecture Highlights
      • SO NFVO will be invoked by Curl Commands (as SO NFVO Client) since the SOL005 Adapter enhancements are out of scope
      • SO NFVO NS Workflow BPMNs and business logic will be packaged as a war file and deployed to ONAP SO Standalone/Clustered Camunda Engine
      • SO NFVO and SOL003 Adapter communications will be treated as an internal communication via HTTP
      • SO NFVO interacts with ETSI Catalog Manager thru MSB for NSD subscription and notification
    • Architecture Diagram: ONAP SO Hierarchical Orchestration (SO NFVO) - Honolulu#HonoluluSONFVOTesting


  • ETSI Catalog Manager
    • Enhancements related to direct SDC Package distribution support thru SDCE-6
    • Enhancements related to NSD Subscription and Notification
    • Architectural Relationships and Interfaces support: ARC Modeling Component Description – Honolulu-R8
    • Architecture Diagram:


  • AAI
    • No impacts since the SO NFVO does not support Scaling or Healing
    • AAI impacts will be analyzed for the Istanbul release

3- New or modified interfaces

  • SDC ↔ ETSI Catalog Manager
  • ETSI Catalog Manager ↔ SO NFVO

4- If they are modified, are they backwards compatible?


6- Interface naming (point to an example)


7- Consumed API from other projects

Project

API Dependency

Notes

APi Specs

(Swagger)














































8- Published API

Project

API

Notes

APi Specs

(Swagger)


















9- Reference to the interfaces.

(Reference to the the swagger.json file(s) whenever possible)

10- What are the system limits?

.

11- Involved use cases, architectural capabilities or functional requirements.


12- Listing of new or impacted models used by the project (for information only).

  • Identify any High Level Information Model Requirements.   See: ONAP R8 Modeling High Level Requirements
    • Models based on information exchanges from Use Cases
    • Models documenting existing implementations
    • Forward looking models that may be implemented in future releases
  • Describe how exposed APIs are mapped to information models

(list all the relevant Jira tickets)


13-Test plan/Testing Strategy

  1. Unit Testing
  2. Dev-to-Dev Testing  and
  3. Integration


14- Any other details that are specific to this functional enhancement or UseCase.



  • No labels