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

Compare with Current View Page History

« Previous Version 2 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

  1. SDC
  2. SO / SO NFVO
  • NSMF enhancements and NSSMF workflow enhancements for all 3 subnets (mainly fixing Guilin gaps and any minor enhancements for RAN, Core, TN for e2e slice stitching)
  • Endpoints related enhancements
  • RAN NSSI related enhancements (RAN)
  • Reuse of TN NSSI (TN)
  • Core NF config updates (Core)
  • Closed Loop related enhancements (RAN)
  • Support of Option 2 in RAN NSSMF
  1. ETSI Catalog Manager
    • NST selection enhancements
    • Use of endpoints for NSSI selection
    • CoverageArea → TA list mapping
    • TN NSSI selection enhancements (if any)
    • Generic functional enhancements (Slice profile generation, etc.)
    • Slice Profile decomposition (in RAN)
    • NSI/NSSI selection based on resource occupancy levels (under discussion)
  2. AAI
    • No impacts
  3. CPS

3- New or modified interfaces

  • Interface to CPS (from OOF, SO, DCAE, SDN-C)
  • SO ↔ OOF
  • OOF ↔ DCAE (under discussion)
  • SO ↔ CCSDK/SDN-C
  • OOF ↔ SDC
  • SDN-C ↔ RAN (O1 interface)
  • SDN-C ↔ RAN (A1 interface)
  • Internal interfaces within SO (NSMF ↔ NSSMF Adaptor ↔ NSSMF)

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 R7 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