...
- SO
- SO Catalog DB for SOL001/SOL004 support
- BPMN Workflows and Recipes
- VNFM Adapter
- SDC
- Support SOL001/SOL004
- VF Module deduction based on SOL001
- SDNC
- VNF-level Network Assignment, instead of VF-Module
- A&AI
- VNF-level Inventory Update
- VNFM location
- Policy (Stretch goal) - not for Dublin
- Scale-Out support for ETSI-based scaling
- Modeling
- Support SOL001/SOL004
- ETSI vs. ONAP-compliant VNFD
- SO
Open Items
SDC transformation between ETSI and ONAP internal output and storing the original CSAR package.
VNF Application Configuration thru VNFM Adapter and VNFM is under discussion
Architecture subcommittee is defining orchestration scenarios for application configuration
Better mechanism for VNFM Adaptor Adapter to locate VNFMs (two methods are suggested)
How do we identify which VNFM to use?
Modelling for VNF and VF Modules; mapping between VF Modules and VNF
Assigning Network resources to SDNC; do we use preload data?
Continue to support existing non-ETSI SO workflows along with ETSI-based workflows
VNFM Adaptor Adapter architectural direction; should it work as a thin layer or should it be evolved as a full-fledge fledged NFVO in the future, e.g., handling grant by itself, updating resources in A&AI and SDNC?
After the VNF Instantiation, which component does update VNF resources in A&AI? VNFM Adapter or SO?
SOL001/SOL004 SO Representation (for Dublin, the second option was chosen)
SDNC Preload VNF TopologyEnhance SO Catalog Database?
VNF_Package (vnfdid, vnfm_info, version, vnf_provider, product, vendor, etc.)
VNF_Package_Artifact (child database for VNF_Package, VNFD_URL, SoftwareImage_URL, Additional Files etc)
Store minimum reference in TOSCA_CSAR database table?
SOL001 Package management
SO VNFM Adapter supports VNF Package (VnfPkgInfo, VNFD, Artifact) for VNFM
This was chosen for Dublin
MultiCloud use (not for Dublin)