1. Introduction to the Model
TR-512.P.2
Introduction to the Model

2. Presentation Goals
By the end of this presentation you should be able to understand
Why we use models
How to use the model tooling
How to read a model diagram
How the core model can be extended for specific protocols and features
If you think of anything during the presentation that you think we have missed, note it for the Q&A section

3. Why We Model

4. A model is an Abstraction for a Purpose
“A conceptual model is an abstract representation of reality defined in terms of semantic abstractions.
Abstraction is a mental process where some characteristics of a set of objects are selected for analysis and where other characteristics that are not relevant are excluded.”
“Models are not right or wrong; they are more or less useful” (“for the job at hand”) [Fowler – Analysis Patterns]
“This is not a pipe." René Magritte (1928)

5. We model to create a common language
Formal modelling provides a framework where understanding about managing networks can be stored
It provides a common language for network management domain experts to use when they interact
It allows consistency across protocol and feature management representations, simplifying understanding of the functionality
It stops the formation of semantic silos which would hinder implementations interacting
It allows the generation of consistent artefacts in languages like Yang and JSON
And we use UML because a graphical modelling language highlights the underlying patterns

6. The Design Goals of the ONF CIM are
To provide a well defined representation of managed network functionality
To leverage industry best-practices, patterns, tools… where appropriate
To provide a practical, useful and scalable modeling environment
To produce a lightweight (“slim”) core model, that is technology and technique agnostic
To promote reuse and extension of the CIM model by having a modular architecture

7. Patterns allow us to reuse experience gained
It’s easier to reuse a cake recipe than a cake (reverse engineering is hard – how long was it baked for and at what temperature ? – the result is likely a guess)
Model structures that were useful in other models can be identified and reused
Patterns highlight deeper understandings and insight gained – this is where the real value is, not in ‘throwing boxes on a diagram’
For example - if we were to design a new network protocol model, what learnings from existing protocol models would we use ? What things would we avoid (anti-patterns) ?

8. How we model – UML and tooling

9. The ONF CIM uses a form of the industry standard UML modelling language
UML is a graphical modelling language
There are many books and online references that can be used to understand UML, so it won’t be covered in detail here
The document ONF TR-514 “UML Modeling Guidelines” details how UML is used for the ONF CIM models

10. The ONF CIM uses Papyrus as its UML tool
Papyrus is based on the Eclipse framework
The document ONF TR-515 ”Papyrus Guidelines” explains how to download and install the tooling and download the ONF CIM model from GitHub

11. The ONF CIM uses a custom UML Profile
UML profiles are used to extend the standard UML definitions
The ONF CIM profile adds support for types needed for network management similar to those provided by the Yang language and the IETF and Openconfig types yang files
The profile also defines Stereotypes that can be used in the ONF CIM and any extending models
Add some primitives in the profile

12. The ONF CIM uses these UML artifacts
Entities are similar to a Java class. They have identity (and hence an identifier). They also have attributes (and methods
, but they are not used in the CIM. ). Entity attributes may be of simple types, Datatypes or Enumerations. Entities may also map in some way to a database table in an implementation. Note that Entities may be abstract and then their name will be in italics. Abstract entities can’t be instantiated (like abstract Java classes).
Attributes
Datatypes represent value objects. They are represented by their value only (and are best to be immutable). They can be thought of as groups of attributes. Datatype attributes may be of simple types, (other) Datatypes or Enumerations. Datatypes may also have methods, but they are not used in the CIM.
Enumerations represent a list of constant values which are called literals.
Enumerations are used as Entity or Datatype attribute types. They are similar to a Java enum.
Literals

13. The ONF CIM uses these UML relationships
Inheritance / Subclassing is similar to Java inheritance. Note that preferably only the leaves of the inheritance tree (those classes with no children) are concrete
Note that UML defines a third type of relationship ‘AssociationClass’ which is not used in the ONF CIM model.
Associations allow Entities to be related (using their identifier). An Association can be unidirectional or bidirectional. It can also have a composition (black diamond) at one end, that implies the composed (other) end has the same lifetime as the composing end. Navigable association ends will generate Java attributes in the class at the other end.
AssociationEnd
Bothway Navigability (Bidirectional)
Navigability from AB only (Unidirectional)
Multiplicity
Composite Association
(A composes B)
Composition Diamond

14. UML Multiplicity and its relationship to generated collections
Multiplicity is used for attributes and association ends
Don’t use options 0 or 0..*
0 means none, so not useful
0..* and * have the same meaning, but 0..* clogs up the class diagrams
The useful multiplicity Options
The type of collection generated
Multiplicity
Lower Bound
Upper Bound
Generates
Meaning
0..1 1
Scalar
Zero or one *
Many
Collection
Zero, one or more
One
1..*
One or More
isOrdered
isUnique
UML Standard Collection Type
False
Bag
True
Set
Sequence
OrderedSet

15. Other UML Terms used in the Model
Stereotypes are shown as <<Stereotype>>
Abstract Entities have their name in italics
Self-Join Association
Note that self joins need not be direct to the same class but may be to a parent class in the hierarchy

16. Every artifact in the ONF CIM is given a lifecycle stereotype
The stereotype indicates where the artifact is in the design process and its level of maturity

17. The ONF CIM Documentation Set
TR-512.1
Overview
TR-512.x Model Descriptions and
TR-512.A.x
Examples
Start Here
UML Modeling Guidelines
TR-514
Papyrus Guidelines
TR-515

18. The Common Model Framework Design

19. The ONF CIM separates functionality from physical inventory
The key starting point in the model design is to separate physical inventory from (logical) functionality.
All functionality is treated as being logical
In the software model the same distinction is made – between installed software inventory and functionality arising from running software
This allows the ONF CIM to represent functionality consistently, whether it is implemented via hardware only, software only or a mixture of the two
TR – Physical Model, TR – Software Model

20. Processing and Transport Functions
It is useful to categorize the parts of a network in terms of the type of functions that they provide. Two key function types are processing and transport of information.
A Processing Function processes (transforms) information without transporting it. This also includes creating and terminating information.
A Transport Function transports (existing) information without changing it
Most higher level functions do both transport and processing to varying degrees, but can be broken down into a combination of these two primitives
If a function does mainly information processing, the very small portion of transport functionality can often be ignored and if doing mainly information transport, the processing function can often be ignored

21. Operational and Knowledge Layers
In networking, common ‘building blocks’ are often repeatedly assembled to implement functionality but with varying configurations
Separating out the invariant mechanisms from the varying configurations allows a model implementation to dramatically reduce the stored data at the expense of a slightly more complex model.
The varying classes form the operational layer and the invariant classes which we call Specification classes, form the knowledge layer
In effect, the ONF CIM model defines classes that can be used to build a library of specification information
This model layering also allows a greater level of detail to be stored than would be practical without use of this pattern
Note that operational and knowledge layers shouldn’t be confused with structural and behavioral features. From TR514, “The structural modeling is using Attributes (Properties) contained in Classes and the behavioral modeling is using Operations contained in Interfaces.”

22. Operational and Knowledge Layers Example
Logical Termination Point (LTP) and Layer Protocol (LP) {which will be explained later} reuse common building blocks such as adaption, multiplexing / de-multiplexing and termination
Rather than representing this common detail for every LTP, it makes sense to normalize out the information into specification classes
Also the specifications themselves often reuse other specification objects as the Optical example on the right shows

23. There are 8 key classes in the ONF CIM Core Model

24. Functions of CIM Core Model v1.4 Key Classes
Processing Function
Transport Function
Constraint
LTP
 - protocol stack termination (Transform) -
 - client creation
Forwarding Construct
 - forwarding (Transfer)
 - bounded forwarding
Forwarding Domain
 - FC creation, LTP creation
Link
Control Construct
 - management-control plane (communications)
Configuration and Switch Control (CASC)
 - management-control plane (control)
Constraint Domain
 - general constraints (augmenting above)
Processing Construct
 - any hybrid functions and any other function not above
- = insignificant (may be non-zero – e.g. all Processing Functions are bound to encapsulate some forwarding and it can be argued that forwarding is a form of processing)
Both ProcessingConstruct and ControlConstruct perform processing functions, but while a ProcessingConstruct just processes its information, a ControlConstruct processes information to control other functions (such as ProcessingConstructs, Forwarding constructs etc.). It is this additional controlling responsibility that means that it makes sense to have a separate model entity for ControlConstruct.
There is a 3rd function , Storage that isn’t supported by any of these

25. Why the Component-Port pattern is important
If a component is ‘symmetric’ then the connectivity is between the components. If a component is ‘asymmetric’ and the asymmetry is relevant to the connectivity, then the component needs to have ports defined and the connectivity is between the ports.
A simplified analogy using shapes S4 S3 S3 S4 S1 S2 S5 S5 S3
The shape core and the faces have been separated out, allowing for both shape – shape and face – face connectivity. Note that the faces (ports) are now also ‘symmetric’ and hence this pattern can be applied recursively
The green face of S3 is connected to the green face of S4 and the red face of S4 is connected to the grey face of S5
S1 is connected to S2 but not S3
The Component Port pattern is discussed in more detail in TR-512.A.2 : Appendix – Model Structure, Patterns and Architecture
By symmetric, we mean that we can consider the component to expose a single uniform interface.
The slide attempts to use a picture of a circle / sphere as an analogy

26. Core Model v1.4 Key Classes Connectivity Options
Symmetric Option
Asymmetric Option
Refer to Document
LTP 
- #
TR : Forwarding and Termination TR : Topology
Forwarding Construct -
TR : Forwarding and Termination
Forwarding Domain
Link
TR : Topology
Control Construct
TR : Control
Configuration and Switch Control (CASC)
Constraint Domain
TR : Processing Construct
Processing Construct
# - will be added when LTP Port is added in a future model release

27. Core Model v1.4 Key Specification Classes Options
Spec can use Spec (R=Recursive)
Key Spec Class
LTP LP FC FD
Flow
Link CC
CASC CD PC - 
LP [LTP] R
Forwarding Construct
Flow [FC]
Forwarding Domain
Control Construct
Configuration and Switch Control (CASC)
Constraint Domain
Processing Construct ?

28. A Note on the Following Definitions
They have been deliberately simplified for clarity
All the concepts represent network management abstractions of the functions, not the actual functions
There are a number of challenges in drawing the diagrams so that they are reasonably clear and representative of the concepts. Be aware of some of the limitations of the diagram format and don’t try and infer too much from them. For example don’t expect everything to be to scale.

29. Forwarding Domain (FD)
A Forwarding Domain constrains transport of information by constraining enclosed Forwarding Constructs, Links and other ForwardingDomains, by limiting their extent and connections to LTP
A Forwarding Domain may have many ports, each of which can be associated to a Logical Termination Point
For example, a Forwarding Domain could enforce that certain Forwarding Constructs only lie ‘within’ the FD
A FD can be partitioned into two or more FD connected via one or more Links

30. Link
A Link constrains the creation of Forwarding Constructs between two or more ForwardingDomains (FD), by associating a set of LTP on one FD with an equivalent set of LTP on another FD.
A Link may have two ports (point-point) or more than two (to represent broadcast adjacencies) and each port can be associated to a Logical Termination Point
Like the FC, the Link has ports (LinkPort) which take roles relevant to the constraints on flows offered by the Link (e.g., Root role or leaf role for a Link that has a constrained Tree configuration).
Note that a Link doesn’t actually forward information

31. Forwarding Domain & Link Example
In this example there is a Forwarding Domain FD-B, which can be decomposed into FD-A and FD-C connected by Link-1.
Note that for the Link – FD termination there are two cases :
When the FD is symmetric, the Link can be directly associated to the FD
When the FD is asymmetric, then the asymmetry will be shown on its ports. Then the LinkPorts will be associated to the appropriate FD port via a LTP
FD-A
FD-C
Topology B A1 A2 A5 A4 A3
Topology A
Topology C
FD-B
The same link shown twice
More abstract
Less abstract
Single layer view
(i.e. all FDs/Links are for the same layer-protocol)
Link-1
Link-1
Further decomposition is possible, but not shown

32. Forwarding Construct (FC)
Transports information (forwarding) between its ports
A Forwarding Construct may have two ports (point-point) or more than two (to represent broadcast forwarding) and each port can be associated to a Logical Termination Point
A FC has ports (FcPort) which take roles relevant to how the Forwarding Construct transports information
Note that a FC is NOT the actual flow of information

33. Forwarding Construct (FC) Example
FC-Y
FD-A
FD-B
FC-X
FC-Z
FC-W
Link-J 1
Link-L
FD-C A
Link-K
FC-U
FC-V Z 2
The example shows how FC-U which is enabled by Link-K, forwards between FD-A and FD-C.
Note that the relationship is via the FC ports, that is port A of FC-U is bound to FD-A, LTP-1 and port Z of FC-U is bound to FD-C, LTP-2

34. Logical Termination Point (LTP) and Layer Protocol (LP)
LTP provides a common place to represent the termination of protocol layer information and the adaption between protocol layers
LTP also provides an interconnection point in the model that allows the seven key classes and their ports to be interconnected without needing a large number of associations (n2 = 49)
LP represents protocol layer specific information within the LTP

35. LR x
LR z
LR y
LR w
LTP-2
LTP-1 ‘
LTP n LP F
LP Spec explains LP internal structure
LTP and LP Example
LR = Layer Rate
FD-A 3 4
FC-X Z A 1 2
FD-B 7 8
FC-Z 5 6
FC-Y
Link-L
The left figure shows the relationship between LTP and LP in the protocol stack
The top figure shows how the LTP relate to ForwardingDomain (FD) and ForwardingConstruct (FC).
For example, port Z of FC-X and port A of FC-Y are both bound to LTP-3.
ITU-T G.800 symbol set
Need to update this when we have LTP Port in the model

36. Constraint Domain (CD)
A Constraint Domain is a general grouping, scoping and constraining concept.
It is used to group network functionality and then constraints can be applied to the group if required (the constraint model will be added to the ONF CIM in a future release)
Constraint Domain doesn’t represent any transport or processing functionality
Constraint Domains can be related, they can overlap and they don't need to form a hierarchy.
Note that there is some overlap with other CIM model artifacts that also do some specialized constraining, such as Forwarding Domain

37. Constraint Domain Examples
Common uses for a Constraint Domain include :
To represent a physical boundary that affects functionality (such as a ‘chassis’ boundary)
To represent a traditional Network Element boundary for interworking with legacy systems
To represent a control domain (the scope of control of a Control Construct)
To represent an ERPS ring
Precision Time Protocol (PTP) clock domain

38. Processing Construct (PC)
A ProcessingConstruct takes information arriving at one or more of its ports, processes it and then sends it out of one or more of its ports.
A PcPort may be associated with another PcPort or with an LTP at a specific layer protocol.
A PC may be:
Symmetric, such that it offers the same function(s) to any attached entity. The function(s) can be accessed directly from the PC and hence PcPorts are not needed.
Asymmetric, such that it offers all or a specific subset of function(s) to different attached entities through its ports.

39. Processing Construct Example
This example shows a Constraint Domain (CD) boundary representing a traditional Network Element (NE) boundary.
Within the Constraint Domain is a running software process that implements two Processing Constructs (PC), each providing an Ethernet Bridge function. Bridge 1 has four ports, with port 1 being bound to LTP Eth0.
Each bridge also contains a Forwarding Domain (FD) with ports bound to the Bridge ports. 1 2

40. Control Construct (CC)
A Control Construct processes information to control other network functions (such as Processing Constructs, Forwarding Constructs etc.)
The ONF CIM can represent generic management and control networks :
By representing the binding between Control Constructs via their ports and the roles at each end of the binding
By the nesting of Control Constructs in a Constraint Domain that is controlled by another Control Construct (in this case, the Constraint Domain is playing the role of a control domain)

41. Control Construct Example
ControlConstruct 1 is controlling the functions in ConstraintDomain ‘A’.
ControlConstruct 1 has a port ‘x’ playing the ‘master’ role that is semantically bound to a ‘slave’ port ‘y’ of ControlConstruct 2.
The ports ‘x’ and ‘y’ may communicate via a transport network, shown via their binding to a LTP.
ControlConstruct 2 is controlling two Processing Constructs (PC) within Constraint Domain ‘B’. A 1 x 2 y
Note that there is some overlap between Control Construct 1 controlling Constraint Domain ‘A’ and the roles in the binding between ports ‘x’ and ‘y’.
It relates to the steps in the construction of the control network where the port binding would be done later and hence would conform to the imposed constraints B

42. Network Element no more
Rather than trying to ‘decompose’ a network element black-box concept, the ONF CIM ‘turns the network element inside-out’, focussing on the network functions and their relationships and allows these functions to be grouped as required using ConstraintDomains (CD). Network Functions can be bound directly to show semantic relationships. The connectivity through LogicalTerminationPoint (LTP) allows for the port- port bindings to be related to any underlying transport objects.
Modern networking devices perform multiple functions and communicate via multiple protocols forming multiple network topologies

43. No more ‘virtual’ Network Elements
With the decoupling of network functions from the physical inventory, the ONF CIM can consistently represent device partitioning, distributed devices and ‘virtualization’
If required (e.g. for backward compatibility with legacy systems), a Constraint Domain can be used to represent a traditional Network Element boundary
If required, Constraint Domains can also be used to represent any physical boundaries that constrain the extent of logical functionality

44. More Advanced Topics

45. Second principle of OOD
“Favour object composition over class inheritance” [GoF], p.20 (published 1995)
To avoid confusion (such as thinking this means to use composition associations instead of inheritance), this can be re-phrased as “Favour assembling objects over class inheritance”
Object composition is often implemented in code using method delegation
Subclassing is often called ‘white-box reuse” and object assembly ‘black-box reuse”

46. The Decoration Pattern provides an alternative to Inheritance
The Decoration pattern allows inheritance to be replaced with a directed 0..1  1 association
Having a <<Decorates>> stereotype in the profile will help to clarify the intent of the association
Decoration :
Allows options to be ‘assembled’ avoiding the need for mixed subclasses (BlueGreen  Blue + Green instances)
Allows the model to scale by reducing coupling (as per the next two slides)
Has the same dependency direction as the inheritance relationship, supporting model modularity
Abstract
Concrete
Refer contribution onf

47. Coupling of UML Relationships within a Module
Inheritance (unidirectional coupling)
Composition Association (bidirectional)
Bothway Association (bidirectional)
One way association (unidirectional)
Decreasing coupling
The association end multiplicity also has an impact on coupling. Restrictive multiplicities (0..1, 1, 1..*) imply more coupling than an unrestricted multiplicity (*)
If the module is chosen with a reasonable scope, then the overuse of inheritance and / or composition within the module is unlikely to get out of hand. High coupling within a module leads to a cohesive module.

48. Coupling of UML Relationships between Modules must be unidirectional
Inheritance (unidirectional coupling) 1
Composition Association (unidirectional) 2
One way association (unidirectional)
Decreasing coupling
Module A
Module B
UML Dependency relationship, showing A depends on B
Note that coupling BETWEEN modules should be unidirectional and the direction must match the module dependency direction. Also we can’t allow module dependency loops to form.
1 Using Abstract classes designed as extension points allows us to reduce the inheritance coupling, making it suitable for use between modules.
2 We need to decide if composition associations between modules is allowed or not. Aggregation associations are just treated as normal associations.
The association end multiplicity also has an impact on coupling. Restrictive multiplicities (0..1, 1, 1..*) imply more coupling than an unrestricted multiplicity (*)

49. The ONF CIM defines the Minimum Required Coupling
The ONF CIM defines a model suitable to be used to define a management interface
The proposed dependency rules can be thought of as defining a MINIMUM set of required dependencies, that allow these interface definitions to grow and be maintained
It would be a folly to define a maximally dependent model and have implementers needing to arbitrarily chose which dependencies to remove
An implementation can add reverse dependencies as they retrieve data via the management interface and then discard any surplus dependencies when writing back to the management interface. For example in a relational database, foreign key references are created based on association multiplicity which may not match the defined association navigability – perhaps even resulting in a dependency reversal

50. A UML model needs to adhere to good OOD principles just like code does
Copyright © TM Forum All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to TM FORUM, except as needed for the purpose of developing any document or deliverable produced by a TM FORUM Collaboration Project Team (in which case the rules applicable to copyrights, as set forth in the TM FORUM IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by TM FORUM or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and TM FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Direct inquiries to the TM Forum office:
240 Headquarters Plaza,
East Tower – 10th Floor,
Morristown, NJ  USA
Tel No. 
Fax No. 
TM Forum Web Page:
Corrected dependencies drive the correct model dependencies
A Typical initial design – Do NOT use
ADP
The Acyclic Dependencies Principle
The dependency graph of packages must have no cycles.
SDP
The Stable Dependencies Principle
Depend in the direction of stability.
SAP
The Stable Abstractions Principle
Abstractness increases with stability.
From TMF TR-225

51. Extending the CIM Model

52. How an ERPS model can be added to the ONF CIM
The ERP concepts are defined in their own module.
The module dependency needs to be into the more abstract core model.
Using decoration rather than inheritance reduces the coupling into the core model.

53. How a PTP Clock model can be added to the ONF CIM
The PTP Clock concepts are defined in their own module.
The module dependency needs to be into the more abstract core model.
Using decoration rather than inheritance reduces the coupling into the core model.

54. Common Protocol / Feature Structure
Decoration association used instead of inheritance
Key Component #
Key Component Port # 1 1
<<Decorates>>
<<Decorates>>
Feature Module
Port attributes for the protocol
0..1
0..1
Component Properties
Port Properties
Feature ConceptA
Protocol specific concepts
Feature ConceptC
Feature ConceptB
# the Key Components defined in the ONF CIM core model are : LTP, FC, FD, Link, Control Construct, CD and PC

55. How the Protocols / Features add up
ERPS Module
PTP Clock Module
PTP ConceptB
<<Decorates>>
<<Decorates>>
ERPS Properties
Key Component #
PTP Properties
ERPS ConceptA
ERPS ConceptB
<<Decorates>>
<<Decorates>>
PTP ConceptA
ERPS Port Properties
Key Component Port #
PTP Port Properties
# the Key Components defined in the ONF CIM core model are : LTP, FC, FD, Link, Control Construct, CD and PC

56. Q&A