...
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 | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
The management reference role enables a userof the topology to inter work with management software that respects access control (for example TBAC). A ManagementReference must have at least one ManagementReferenceRole. The MnagementReferenceRole is unique within a ManagmentReference.
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.
Makes sense, aligns with ONAP IM separation to date.
Agreed to remove the ServiceEndPoint and ServiceFlow/Intent from the sketch.
Intent
Layer Parameters
I need to get my head around this concept a bit more..Intent is a wonderful new buzzword. It is only as good as the interpreter is. Eventually the intent needs to be translated into configuration of endpoints, connectivity and flow domains. Intent is also hierarchical, it will be evolved by layers of interpreters. Of course we need to keep the reference back to the intent for traceability (and possibly in scheduling). This can be achieved by having a simple hierarchical element that is referenced by the 'Resource'. So the participation of any resource in an 'intent' can be traced and interrogated regardless of the interpreter.
| 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
Any resource may contain parameters that are defined outside the abstract topology model.
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 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.