...
Network Service Instance
Inherit from ServiceComponentInstance
ETSI IFA013 (NS) | Confirmed | Descripion |
| flavourId | Reference to the flavour of the NSD used to instantiate this NS. | |
| vnffgInfo | Information on the VNFFGs of this NS. | |
| sapInfo | Information on the SAPs of this NS. | |
| nestedNsInfoId | Reference to information on nested NSs of this NS. | |
| nsScaleStatus | Represents for each NS scaling aspect declared in the applicable DF, how "big" the NS instance has been scaled w.r.t. that aspect. | |
| additionalAffinityOrAntiAffinityRule | Information on the additional affinity or anti-affinity rule from NS instantiation operation. Shall not conflict with rules already specified in the NSD. |
- ServiceComponent Instance - WAN Service
TBD
ServiceCatalogItem vs ServiceComponentCatalogItem
ServiceInstance vs ServiceComponentInstance
In the current Ecomp IM the Service model includes ONAP Service 2017-11-08.docx, Service and ServiceComponent models either classes are defined either at run and design time .IM UML used as input is not complete. For example, it does not show the details of IM for Service and Service Component(i.e ServiceComponentDesc/ServiceComponentCatalogItem, ServiceComponentInstance, ServiceInstance, ServiceDesc/ServiceCatalogItem) even if no attribute is defined (to be added).
According to the tables above, both SDC and A&AI do not differ Service and ServiceComponent.
Do we need to split a Service as an aggregation of ServiceComponent in the IM? Considering that a Service may be also a composition of Services as well.
NfVirtualLink, LinkPort, VirtualNetwork
InECOMP IM UML documentation: ONAP Resource 2017-11-08.docx and ONAP Service 2017-11-08.docx no class definition about Virtual Link, NSVirtualLInk, LinkPort, VirtualNetwork defined in ETSI IFA.