ONF Document Name: Core Information Model version 1.4 Draft
THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE.
Any marks and brands contained herein are the property of their respective owners.
©2018 Open Networking Foundation. All rights reserved.
Open Networking Foundation, the ONF symbol, and OpenFlow are registered trademarks of the Open Networking Foundation, in the United States and/or in other countries. All other brands, products, or service names are or may be trademarks or service marks of, and are used to identify, products or services of their respective owners.
This Technical Recommendations has been approved by the Project TST, but has not been approved by the ONF board. This Technical Recommendation is an update to a previously released TR specification, but it has been approved under the ONF publishing guidelines for 'Informational' publications that allow Project technical steering teams (TSTs) to authorize publication of Informational documents. The designation of '-info' at the end of the document ID also reflects that the project team (not the ONF board) approved this TR.
Table of Contents
List of Figures
Description of Change
Appendix material was not published prior to Version 1.4
This document is an appendix of the addendum to the TR-512 ONF Core Information Model and forms part of the description of the ONF-CIM. For general overview material and references to the other parts refer to TR-512.1 .
For a full list of references see TR-512.1 .
For a full list of definition see TR-512.1 .
See TR-512.1 for an explanation of:
Some of the UML diagrams are very dense. To view them either zoom (sometimes to 400%) or open the associated image file (and zoom appropriately) or open the corresponding UML diagram via Papyrus (for each figure with a UML diagram the UML model diagram name is provided under the figure or within the figure).
Figures showing fragments of the model using standard UML symbols and also figures illustrating application of the model are provided throughout this document. Many of the application-oriented figures also provide UML class diagrams for the corresponding model fragments (see TR-512.1 for diagram symbol sets). All UML diagrams depict a subset of the relationships between the classes, such as inheritance (i.e. specialization), association relationships (such as aggregation and composition), and conditional features or capabilities. Some UML diagrams also show further details of the individual classes, such as their attributes and the data types used by the attributes.
This document is part of the Appendix to TR-512. An overview of the Appendix is provided in TR-512.A.1 .
This document provides various examples of the use of the ONF CIM to model control and interaction between control systems.
The examples in this document are built from descriptions in other documents. The examples are supported by a combination of ControlConstruct, ControlPort (as described in TR-512.8 ) and ConstraintDomain (as described in TR-512.11 ) as well as ExposureContext (as described in TR-512.8 ) which is generally represented in the examples as a control domain.
In most examples, relationships between ControlPorts are shown as direct. In a majority of real cases, the actual relationship will be supported by normal networking which will be represented by FCs, LTPs etc. Some of example figures show an abstract FC, but in a majority of cases this has been omitted to reduce diagram clutter. Further information on the relationship between the Control Construct and the forwarding model can be found in TR-512.8 .
The separation of concerns of Control from other aspects of a device is in line with the general trend to "disaggregate" functions. The ONF model provides a forward-looking representation of Control that can cover all device assemblies from the traditional simple "physical NE" through white box through virtualized to full cloud considerations.
Considering the wide spread of applicability, it is only possible to cover a limited number of cases in the examples at this early stage of evolution. These examples have been focused on current and near future solution needs. It is expected that further examples will be provided in later releases to better illustrate the breadth of applicability as the need arises.
The first few examples are for relatively basic "NEs" but later examples cover the generalized nature of control via more complex cases. The document works briefly through the ONF architecture team view of an SDN controller then embarks on a description of the use of the model to represent a more generalized control solution.
The current examples only explore the surface presentation of a control solution and do not dig into the essential control loop behavior behind the presentation. This deep view will be covered in later releases.
A majority of the the current examples in this document provide a static structural view. The Control model in TR-512.8 also begins to unpick interactions via the Operations model section which introduces the specific interfaces and the ControlTask and the via the Operations Pattern work in TR-512.10 which explores a generalize interaction pattern and messaging structure. Examples in section 3.3 Generalized Control Function on page 18 begin to tackle this area. More detailed consideration of messaging interaction will be covered in a later release.
This document uses a simple self-explanatory symbol set.
During the work to break apart the network element concept, the logical network functions were split off into ProcessingConstruct and ConstraintDomain. What was left was the network element control function.
The two things needed to represent the control function are:
The decision was made to create a separate control function class ControlConstruct and reuse the ConstraintDomain class for the control scope representation. Reusing ConstraintDomain simplified the resulting model (otherwise a lot of associations would have needed to be duplicated).
It then became apparent that this general model could also be used to model other functional groupings e.g. an SDN controller, giving a consistent view of the different elements in the control network.
The text below will start with the device case and work up to the control network cases.
On the left of the figure below is the representation of a simple 'device' as defined in the ProcessingConstruct document. Note, to keep the diagrams simple, ProcessingConstruct (PC) is used to represent all of the functions PC, LTP, FC, FD, SoftwareProcess …
ConstraintDomain (CD) is used to group the network functions and may also constrain them in various ways. For example, in the diagrams, a ConstraintDomain being used as a network element boundary is shown as CD=NE, a ConstraintDomain representing a physical chassis boundary is shown as CD=Physical(Chassis) and a ConstraintDomain representing a control domain scope is shown as CD=control domain.
On the right of the figure below, a ControlConstruct (CC) has been added and another ConstraintDomain to represent the scope of control (control domain). The ControlConstruct and ConstraintDomain are related by an association in the model "CdConstrainsControlConstruct".
The next step is to be able to show a control network. ControlConstruct (CC) has ports (using the component-port pattern) and the ports can be bound together to show the logical binding. An attribute in ControlPort is used to show the type of relationship, client-server, master-slave or peer-peer. Also, because ControlPort is associated to LTP, it can be related to any transport functions of interest (see TR-512.8 for more details).
The control function layering within a constrain domain is represented by having a ControlConstruct inside of a ConstraintDomain (CD) that is controlled by another ControlConstruct as shown in Figure 3-2.
Note that we should not allow control loops or ControlConstructs to control themselves. This is not represented in the model and would be enforced by the constraints attached to the ConstraintDomains.
The instance diagram below shows how the example above can be represented in the model
It is possible to add control ports to every network function and then bind these to the control construct ports.
This makes sense architecturally and provides a nice consistency, but:
So it is recommended not to instantiate the network function control port bindings within a device, but to rely on the implied binding from the ControlConstruct (CC) to the ConstraintDomain (CD) that it is controlling.
The remainder of this section describes how other common, but more complex, cases can be modelled.
The model is not limited to supporting just these cases, but it is not practicable to try and cover every possible case.
By covering the general partitioning and aggregation cases, it should be easy to determine a suitable representation for other cases.
Note also that we haven't covered 'virtualization' here, but the same principles apply.
For an example of ControlConstruct controlling software, see TR-512.A.13 .
A common case is where a physical device can be partitioned into more than one logical device. This may be done in a number of ways, with varying degrees of partition autonomy. Note that there may only be one physical management agent, but it is likely that each partition will appear to have its own logical management function.
There is no need to change the model for this case, all that is needed is to create the required ControlConstructs and ConstraintDomains and to relate them.
Another common case is where many physical devices are aggregated to behave as a single logical device. There may be a number of variants on this and two of these are explored below.
In this example, we will consider a single logical device where each physical device is managed separately. Here MC = ManagementContext and MA = Management Agent.
Again, the same model represents this case. Note that there may be distributed ProcessingConstructs that cross the physical device boundaries (such as PC-3 in the diagram below).
In the single management agent option, the main difference is that there is only one management access point and the remote chassis ControlConstructs are slaved from the master chassis ControlConstruct.
Again, we see how the general model elements can be arranged to support this option too.
The last case, which does occur in real life, shows the versatility of this approach without having to resort to odd workarounds. In effect it is a hybrid of the partitioned chassis and the distributed device cases that were covered earlier.
The ONF architecture document [ONF TR-521] defines an SDN controller structure as shown in the figure below.
The rest of this section will show how the control model can represent this case.
ConstraintDomain is used to represent ResourceGroup so no additional class is needed for that concept.
ConstraintDomain is also used to represent ClientContext and ServerContext.
Note that there is a ControlConstruct instance per ServerContext (S) and per ClientContect (C), giving a total of 1 + S + C ControlConstructs.
The ControlConstruct Mn in the diagram above, will need S + C ports to bind to the internal ControlConstructs, plus any ports required for external access.
The model doesn't constrain how control functions can be assembled into a control network.
In this section a possible representation of a general control function will be explored.
We will assume that a ControlConstruct can control many other ControlConstructs, with a dedicated port at each end.
We will also assume that a ControlConstruct can interact with many other peer ControlConstructs  , with a dedicated port at each end.
We will also assume that a ControlConstruct can only be controlled by a single other ControlConstruct (ignoring high availability for now)  .
A general control function:
First we will define a ManagementContext (MC) as a type of ConstraintDomain that can enclose a ControlConstruct.
A ManagementContext scope could be:
Now we will define a ConstraintRequest (CR) as a request that is in terms of constraints and a ResourceResponse (RR) that is in terms of network functions (PC, FC, FD, LTP, Link …).
A ControlConstruct can send and receive both ConstraintRequests and ResourceResponses.
ConstraintRequests originate from Needs and ResourceResponses are designed to fulfil the Need.
These can all be linked together into the ONF CIM model framework as shown below.
The best way of showing how the model can be used is through an example.
We will assume that our focus is on MC2 and it has neighbors MC1, 3 and 4.
CC-2 receives a ConstraintRequest from CC-1 (Note that in the diagram above the messages are just shown as being directly related, as drawing them all passing through the ControlConstructs would be too difficult to draw).
CC-2 creates a Need and attaches the request to it.
CC-2 determines that it cannot fulfil the request itself, but that CC-3 and CC-4 can each help with part of the request, so it creates two outgoing CR and attaches these to the Need.
If CC-2 doesn't know which ControlConstruct to send the requests to then it could just broadcast the requests and then see what responses it receives (if any).
CC-3 and CC-4 reply with ResourceResponses that match the request they were sent. Note that we don't know if they actually fulfilled it themselves or passed it onwards again (and we don't really need to know).
CC-2 attaches these responses to the corresponding NeedEntry forming request – response pairs.
CC-2 can now check that it has all the resources needed to fulfil the original request.
It now creates a ResourceResponse and attaches it to the original NeedEntry and sends a response back to CC-1.
A similar set of steps could be used to tear down the allocations when a need is no longer required.
Note that CC-1 may not be the 'final' CC and CC-1 may have partitioned the 'original' request before sending it to CC-2.
Also it is possible that CC-1 had broadcast the request to a number of ControlConstructs and will choose between the response from CC-2 and the other responses it received.
An identifier is needed to make sure that the requests don't loop around and that a ControlConstruct can identify if one of its outward requests has been received as an inward request, which it can then ignore or reject.
As can be seen from this simple example, the intention is to support ControlConstructs being able to negotiate with each other to fulfil a customer request in a way that requires minimal or no manual intervention.
The result is also consistent with the management of newer architectures such as microservices and a 'service mesh'.
Having looked at how a single ControlConstruct can interact with its neighbors, we now need to look at how they can be combined into an overall control network.
Rather than having a hierarchy formed of individual ControlConstructs, it seems to make more sense to form them into layers.
The ControlConstructs would have peer control relationships within a layer and use master-slave or client-server control relationships between layers. The ControlConstructs would also have a master-slave or client-server relationship any network devices that they are controlling.
For high availability needs, ControlConstructs could be pooled (using ConstraintDomains to represent the pool groupings).
The control architecture:
The following two diagrams show how this could be applied.
The preceding model doesn't cover how a remote ControlConstruct will access the resources assigned to it.
An "ExposureSession" concept could be defined to create a proxy with ports and addresses that can be used to control and restrict access to the resources.
One last example that is worth considering is that a ControlConstruct may control a 'network' scope.
Consider ERPS G.8032 (hereafter just called ERPS).
Each Ethernet switch may be performing other normal switching functions as well as an ERPS node function. A ControlConstruct can be created for every ERPS node that receives and processes control information from other nodes.
We could also consider that this distributed control also creates a logical network level ControlConstruct. Once again, the building block nature of the model also allows for this case to be represented in a sensible manner.
End of Document
 In a peer relationship the role bias will be defined for each interaction, transaction, session etc.
 This does not preclude another controller controlling the underlying resources via some other access. This is simply a statement of access to control the things in the view presented via the ExposureContext. This does not preclude one controller controlling the things controlled by another ControlConstruct via one ExposureContext and another controller controlling the ControlConstruct itself via another ExposureContex. This does not preclude changes of role.
 Another way of looking at this is in terms of the Component-System pattern as set out in TR-512.A.2 . A Component has ports related to its purposeful behaviour and ports related to control of its behaviour (Operations ports). A ControlConstruct has the purpose of controlling other components, hence its purposeful port have the purpose of controlling other things. These are connected to the Operations ports of other Components.
[A1] To the reviewer
- Hypertext document references “TR-512…” will not work at this point (as they reference the .pdf files that have not yet been generated).
- There are some comments in some documents please consider the comments as you review.
- If you have proposals to change text (typos or small rewordings for grammar errors), please modify the text with change tracking enabled.
- If you have major concerns or questions or general comments please use word comments (like this)
This is a new document.