| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...
|
| draw.io 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.
Relation to the ONAP Information Model
| draw.io Diagram | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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.
...
| draw.io Diagram | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 'ResponsibleManagerReference' 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.
Intent, plans and services
The separation of concerns (services and resources) is a principle that should be enshrined in the topology model.
By its nature a service is a simplified abstraction of what is used to realize it. The implementation details typically do not matter to a customer as long as the SLA is met. Bundling the service concepts into a resource model is going to make life more complex. Where there are service specific modeling needs, lets add them to the CFS/RFS classes.
Planning can be covered by a separate instance of the model – different type of separation. Application logic is responsible for the state transition (and the update of plan and actual topology models)
...
|
The topology model includes:
- 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...
| draw.io Diagram | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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.
Topology Grouping
| draw.io Diagram | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Specific named classes
ManagedFunction
|
Any aggregation of connectivity related construct meaningful from a network architecture perspective and not from a logical human based aggregation.
Grouping: to represent the way topology elements can be grouped in a topology E.g: Geographical area; vendor; ORD;
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