Page History

General discussion items

Approach

...

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

26 Jul 2021 

...

You could put the 'ManagementReference' 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.

12 Jul 2021 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

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 Service classes.

12 Jul 2021 Makes sense, aligns with ONAP IM separation to date.

26 Jul 2021 Agreed to remove the ServiceEndPoint and ServiceFlow/Intent from the sketch.

Intent

...

The topology model includes:

1. The concept of a management entity as a type of resource
2. 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.

Topology Grouping

12 Jul 2021 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

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;

Image Added12 Jul 2021 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.