| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
General discussion items
Approach
This page is being used to explore concepts related to topology.
Where a concept is understood it needs to be put in the context of the OANP Information Model (Root). This may involve updates to the ONAP Resource IM. It is important that the topology model and the ONAP IM are consistent.
The topology model is inspired by TAPI. It will use classes, relationships and constructs from TAPI together with additions that make it what it needs to be.
Top level construct
I am missing a class that can be used by services that need to include flow domains, connectivity and endpoints. I see it as useful and flexible to allow this.
...
I'm not trying to describe the service model here, just show how it could relate to the resource side of the house, and why the 'Resource' is an elegant way to hide some of the complexity of what a service is really made up of.
The separation of the Service and Resource in the Topology reflects the current ONAP IM split. There is a Resource in the ONAP IM. It has a single sub-type, 'NetworkFunction'. Need to consider how to merge/align. For example a new TopologyEntity as a peer of the NetworkFunction with the FlowDomain, Connectivity and EndPoint as sub-types of the TopologyEntity...
Ownership
The parent page (Abstract Topology Model) describes a requirement for an association of a topology entity to the software that owns it for a given purpose (e.g.: LCM; Configuration)
...
| draw.io Diagram | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
You could put the 'ResponsibleManagerReferenceManagementReference' as attribute(s) of the Resource, but I think it is (1) a type of resource in its own right and (2) potentially structured information required to interface with the actual manager instance.
The need for this is valid and useful. The 'managedBy', relationship may be promoted to the Resource level – to be less proscriptive. Note also that there will be multiple ManagementReference from a single Resource, potentially one for each management domain (e.g. Fault, Configuration, Performance subscription, etc. This also looks like a update to the 'Resource' in the ONAP IM.
Intent and services
The separation of concerns (services and resources) is a principle that should be enshrined in the topology model.
...
| draw.io Diagram | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
This is an alternative to the sketch, "ServiceFlow/Intent". More information is needed on what 'Intent' is. This part of the model will be parked for now.
Specific named classes
ManagedFunction
I think this is a type (specialization) of FlowDomain. Basically it is hierarchical in nature, i.e. value defined by an organization or standard that may be realized by virtual machines and or containers. It will contain termination points
Discussion started. Moved towards atomicity based on perspective. A VNF is atomic from a telecom CM perspective (you may create a rule on a firewall instance), but be decomposed into VNFC and subsequently container instances from a lifecycle or assurance perspective.