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:
- VNF modeling with minimum CNF enhancements from ETSI NFV 4.1.1, by conforming to the ETSI SOL004 Package and SOL001 Modeling standards
- automated NSD and VNF/CNF package E2E distribution, by conforming to SOL005 and SOL003 Package Management APIs
- 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
- SDC
- Enhancements related to ETSI 3.3.1 SOL004 compliant VNF / CNF package onboarding and distribution
- Supports ETSI 3.3.1 VNF with minimum CNF enhancements from 4.1.1
- VNF/CNF Data Model Based on ETSI v3.3.1 SOL001 plus CNF Enhancements
- CSAR Models: ETSI-Alignment VNFD and Example(s)
- Enhancements related to ETSI 3.3.1 SOL007 compliant NSD package Design and Distribution
- Enhancements related to ETSI 3.3.1 SOL004 VNF and SOL007 NS package security
- Architecture Diagram
- 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.
- In addition, It will support NSD subscription and notification
- However, SO NFVO will upgraded ETSI v3.3.1 SOL005 LCM APIs from ETSI v2.7.1 SOL005 LCM APIs
- SO NFVO and SOL003 Adapter CSIT will be supported
- Epics and User Stories: ONAP SO Hierarchical Orchestration (SO NFVO) - Honolulu#EpicandUserStory
- 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
- SO NFVO continues to support the same SOL005 APIs as Guilin: Create NS, Instantiate NS, Terminate NS, Delete NS and Get NS Operation Status.
- 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
- Unit Testing
- Dev-to-Dev Testing and
- Integration