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 inspiredby TAPI. It will use classes, relationships and constructs from TAPI together with additions that make it what it needs to be.
This diagram shows how the topology model can be integrated with the ONAP IM through use of the Domain class. There was some discussion of this. The general approach is valid. Specifics and thinking are still required, for example, is there a need to a TopologicalService as a class distinct from a Service?
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.
For sure the TAPI model does not deal with services (customer and resource facing) – so I think that we should keep them loosely coupled via this missing class.
So just to play with a name here, lets call it a 'Reosurce'.
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)
This is also missing from the proposal. Again just the concept here – of course it needs to have relationships to FlowDomain and Connectivity. These can be managed from multiple perspectives (LCM; Configuration; Assurance; ...) by different products.
The concept of a management entity as a type of resource
The relationship from any resource to the entity or entities that manage it.
The nature of the management is not part of the topology model. This is captured by a separate model (not in scope of topology, and not for review)
Any 'Resource' may be managed for a variety of arbitrary purposes (extendable list) by different Management resources.
The management reference may refer to an internal (to the ONAP deployment) or external end-point.
The management reference role enables a user of the topology to inter work with management software that respects access control (for example TBAC). A ManagementEntity must have at least one ManagementReferenceRole. The MnagementReferenceRole is unique within a ManagmentReference.
Layer Parameters
I need to get my head around this concept a bit more...
Any resource may contain parameters that are defined outside the abstract topology model.
LayerParameters may be extended through use of the modelBlob. The modelBlob is a more capable version of name tag value pairs.
LayerParameters may also be sub typed explicitly.
The composition relationship avoids always needing to sub-type the Resource to add parameters when extending the the abstract topology with concrete details required to make it useful for a given layer or domain.
