The table bellow describes the problem and how it is or isn’t addressed today
Scenario | External system to be provisioned | Baseline approach | Reflections | Project PTL |
|---|---|---|---|---|
Connection to cloud infra | Address and capabilities of VIM managers (e.g. openstack port) | Mult-VIM: will register infrastructure site/location/region and their attributes and capabilities in A&AI, including compute, storage, networking (including local and vendor SDN controllers) etc. | ||
| VID: manually input the VIM addresses and connection information to the portal, and sent this info to MSO which later call controllers which interact with all of these systems (VNFMS , VIM , EMS) | ||||
| VF-C: Integration with multi VIMs via Multi-VIM. | ||||
| SO: ? | ||||
Connection to transport | SDN controller address’s and capabilities | vendor sdn controler which managed by VIM is not in the scope of ESR. How about the vendor sdn controller managed by ONAP SDN-C? ONAP SDN-C: ? | ||
Connecting to S-VNFM | S-VNFM and capabilites | VF-C: query S-VNFM addresses from ESR | Could be part of the tosca/heat template | |
EMS (Element Management System) | EMS address and capabilities | APP-C: ? | ||
| Other |
...
ESR will supplies both portal and API to manage(register/query/delete/update) the external system, but will not deploy the external system. (Here external system means that the systems already exsist somewhere, but not included in ONAP, such as VIM/VNFM/EMS/vendor SDN controller)
ESR will check whether the external systems are reachable, but will not do the fault analysis.
...