ONF Specification Class Pattern Some items for discussion Implementing the Specification Class Pattern – IISOMI Mapping Guidelines Andrea Mazzini 15-03-2017 Public

Introduction: Capabilities & Constraints A specification class can be defined to either augment and/or refine the definition of an entity class another specification class (or is it assumed to use a different spec class?)   Augmentation: add attributes to a class (e.g. like GDMO conditional packages, like MTNM/MTOSI layered parameters in additional info) Refinement: constrain attributes of a class (or is it assumed to use a different spec class?) (e.g. extending/reducing value ranges or enumerations) Two classical applications: Technology specific: add OTN ODU Trace Identifier attribute add Ethernet ceVlanIdList, sVlanIdList attributes Vendor specific: constraint ODU Trace Identifier attribute to a single format remove sVlanIdList attribute - by adopting spec class without such attribute? Public

Introduction: Template/Profile A specification class can be defined to specify set of attributes together with their values, to be applied to provisioning scenarios involving an entity class another specification class   Typical application examples regard FM and PM provisioning, where a big number of parameters shall be provisioned most of the cases with same values Note: sometimes “template” and “profile” are used as synonyms. Possible distinction is that template “overlaps”, i.e. assigns values to attributes already defined in involved class profile “concentrates”, i.e. assign values to attributes not defined in involved class (but modeling real properties of involved class) Profiles are more likely to be actually provisioned through management interfaces, while templates are not. Public

From TR-512.7 “The aim of all specification definitions is that they be rigorous definitions of specific cases of usage and enable machine interpretation where traditional interface designs would only allow human interpretation.“ “It is assumed that text documents that set out in loose form the functional dependency graph and related flow semantics will be required for a significant period of time to augment the specifications to enable development of code with significant behavior. The work here is for interface definition and driving of simple systematic behavior.” “Lesson: Work in other standardization activities has suffered from the burden of maintaining alignment between their redefined technology properties and the properties defined by the technology specification body” “Specific rules that define the layer protocol mapping opportunities and also set out the interactions between layer protocols This will allow the definition of the port layer stacks and link capacity etc Layering is assumed and coded but to best enable innovative deployments layering should be explicitly stated The method must provide a rich enough rule structure to allow definition of all currently understood layer protocol interactions” Public

From TR-512.7 (continued) Work is progressing slowly on dependency graph (and flow semantic) modelling. Does this deal with machine readable specification of complex behaviours, e.g. protection schemes, ODU hierarchy, etc.? E.g. pros and cons of systematic micro-connectivity description of an FC (MultiSwitchedUniFlow) vs. MTNM “connection type” approach. “Clearly it is important that a standard form of specification of constraints emerges so as to prevent unnecessary decoding complexity.” In a traditional system the entire schema has been coded prior to compile. The specification reference can be ignored run time and instead the content of the specification can be compiled into the systems on both sides of the interface. I guess this is applicable to more generic specification classes, e.g. standard ODUk LP specs. Can we think of a recursive application of specification pattern, e.g. an ODUk_reduced LP spec which redefines some ODUk LP spec attributes? From Figure 7-17 seems yes – see next slide. Public

TR-512.7 - Figure 7-17 Relating LTP/LP spec with the class and instance models Public

Items for discussion Associations/pointers between entity and specification classes, between specification classes Modeling pattern to identify which specification/subclasses classes are enhancing which entity/super-classes Map object classes to “identity” statements and apply “refine” sub-statements to “augment” and “uses” YANG statements, Config and state, etc. Not covered in this version Public

Associations/pointers between entity and specification classes <Change information classification in footer>

MEF 7.3 model example Public

ENNI Service: static-conceptual view “conceptual” in the sense of “indicating required behavior”, not necessarily coincident with proper UML definition ONF TAPI Entity Class ServiceInterfacePoint ONF TAPI Entity Class ConnectivityServiceEndPoint attrib_1 attrib_2 attrib_x attrib_y ENNI Port/PTP/LTP supports n flow points. There is the need to identify subsets of these n flow points which share some properties (managed by different Service Providers/ Super Operators and this is reflected in different queuing, profiles, etc.) MEF Entity Class (with key) EnniService MEF Spec Class EnniSpec 1 1..* MEF Spec Class OvcEndPoint attrib_i attrib_j pointerTo attrib_k 0..1 * attrib_a attrib_b Note that both relationships shall be bidirectional – but pointing from a spec class to a keyed class should not be an issue Public

Outgoing pointer from Spec onf2017.028_SpecAssociations.01.pptx

ENNI Service : instance view Class Instance ConnectivityServiceEndPoint NE1_PTP3_FP1 It seems not possible to point to a “thing” which is absorbed in the class instance! attrib_x attrib_y Class Instance ConnectivityServiceEndPoint NE1_PTP3_FP2 Spec Class OvcEndPoint attrib_i attrib_j attrib_x attrib_y Class Instance EnniService SP_telecom123 Class Instance ServiceInterfacePoint NE1_PTP3 Spec Class OvcEndPoint attrib_i attrib_j attrib_1 attrib_2 pointerTo attrib_k Class Instance ConnectivityServiceEndPoint NE1_PTP3_FP3 Spec Class EnniSpec attrib_a attrib_b Class Instance EnniService SP_telecomXYZ attrib_x attrib_y Spec Class OvcEndPoint attrib_i attrib_j pointerTo attrib_k

Incoming pointer to Spec onf2017.028_SpecAssociations.01.pptx

ENNI Service: static-UML view ONF TAPI Entity Class ServiceInterfacePoint ONF TAPI Entity Class ConnectivityServiceEndPoint How to specify that the pointer applies to “only ConnectivityServiceEndPoint which will include EnniSpec class”? 1 * attrib_1 attrib_2 attrib_x attrib_y MEF Entity Class EnniService MEF Spec Class EnniSpec MEF Spec Class OvcEndPoint attrib_i attrib_j _ServiceInterfacePoint/EnniSpec _ConnectivityServiceEndPoint/OvcEndPoint attrib_k 1..* attrib_a attrib_b 0..1

ENNI Service : instance view (2) Class Instance ConnectivityServiceEndPoint NE1_PTP3_FP1 attrib_x attrib_y Class Instance EnniService SP_telecom123 Spec Class OvcEndPoint attrib_i attrib_j _ServiceInterfacePoint/EnniSpec _ConnectivityServiceEndPoint/OvcEndPoint attrib_k Class Instance ServiceInterfacePoint NE1_PTP3 Class Instance ConnectivityServiceEndPoint NE1_PTP3_FP2 attrib_1 attrib_2 Class Instance ConnectivityServiceEndPoint NE1_PTP3_FP3 Class Instance EnniService SP_telecomXYZ attrib_x attrib_y Spec Class EnniSpec attrib_a attrib_b Spec Class OvcEndPoint attrib_i attrib_j attrib_x attrib_y _ServiceInterfacePoint/EnniSpec _ConnectivityServiceEndPoint/OvcEndPoint attrib_k Spec Class OvcEndPoint attrib_i attrib_j

Incoming pointer to Spec – sparse form onf2017.028_SpecAssociations.01.pptx

Modeling pattern to identify which specification/subclasses classes are enhancing which entity/super-classes <Change information classification in footer>

Instances of Entity Classes including Specification Classes ONF TAPI Entity Class ConnectivityServiceEndPoint Class Instance ConnectivityServiceEndPoint NE1_PTP3_FP1 ONF TAPI Entity Class ServiceInterfacePoint Class Instance ServiceInterfacePoint NE1_PTP3 attrib_1 attrib_2 attrib_1 attrib_2 attrib_x attrib_y attrib_x attrib_y Spec Class EnniSpec attrib_a attrib_b Spec Class OvcEndPoint attrib_i attrib_j MEF Spec Class EnniSpec MEF Spec Class OvcEndPoint attrib_i attrib_j attrib_a attrib_b Run time the Specification Classes “disappear” inside proper Entity Class instances. Hence how to reference to them? How to know which Spec classes have been instantiated into Entity Class instance? Run time: the data structures and contents as e.g. replied by a get operation.