Information Model & Tooling from OIMT, OTCC and IISOMI Resource/Service/Capability considerations Nigel Davis (Ciena) 20180325 OIMT (ONF Open Information.

Information Model & Tooling from OIMT, OTCC and IISOMI Resource/Service/Capability considerations
Nigel Davis (Ciena) OIMT (ONF Open Information Model & Tooling) project – see OTCC (Open Transport Configuration & Control project) – see IISOMI (Informal Inter-Standards Object Modelling Initiative) – see

Recap: Aspects of the projects
Approach Model of semantics independent of implementation (in UML) Development of, and use of, domain patterns Evolvable, extendable interface implementation Focus on UML model to code and round trip, closing the loop Focus on agile processes Focus on tooling and automation of development process Assumes a federation of domain models with no single overarching model Elements of the projects The Core model, which is a set of canonical models defining the patterns/rules in key areas/domains of the problem space Guidelines for modelling and tooling Tooling to assist model transformation and remove manual mechanical steps Interface definition models, i.e. TAPI and WDAPI (where WDAPI is essentially a lightly pruned Core model) Reference Implementations Stimulation of, and support for, PoCs Presentation from December 2017 IntroductionOpenModelingAndOpenTransportProjects pptx

Recap: Applicability for ONAP – key structural models
Network model [TR-512.2] Model for any networking/forwarding, for any transport network technology, with any degree of virtualization, at any scale, at any abstraction and in any interrelated views. Can be seen as a model of patterns/rules defining the essence of transport Physical model (including relationship to functional models, replacing the NE model) [TR-512.6] Model for any physical components that are rack/cabinet/shelf based or stand-alone in a data center or telco environment Provides a model of the pattern/rules defining the essence of physical things and the realization of functional things (regardless of how “virtual” they are) Resilience [TR-512.5] Model for any networking, for any transport network technology, with any degree of virtualization, at any scale, at any abstraction and in any interrelated view. Provides a model of the patterns/rules defining the essence of a resilient solution. The essential pattern is now also being applied to control resilience. Generalized Processing model [TR ] Model for any arbitrary functions/constraint, views of abstractions of functions/constraints, interconnection of functions to networking. Control model [TR-512.8] Model for the control functions in the network, for control of those control functions, and modelling of a controller/orchestrator itself (e.g. ONAP), for control of the controller/orchestrator Provides a model of the patterns/rules defining a management/control solution. Basis for modelling/representation paradigm that replaces the traditional model of an NE and that overcomes many traditional issues with NE and also applies to any physical/functional combination Generalized Operations model [TR ] Basis for uniform operations paradigm that assumes a controller talks to another controller (including an NE) about the controlled things (Through-To-About pattern) and modelling of Control hierarchies etc. The paradigm is outcome-oriented constraint-based (intent+) with a message structure/grammar for all interfaces Provides a model of control interfacing (as part of the MCC)

Recap: Applicability to ONAP (continued)
Component-System pattern [TR-512.A.2] Basis of uniform modelling of functional and physical things. Relates strongly to the TOSCA metamodel Specification approach for decoration/augmentation [TR-512.7] Basis for definition of template/specification approach for all modelled things Provides a mechanism for constraining and augmenting the key structure models Includes scheme/system specs for definition of the constraints in specific network schemes, e.g. G.8032 ring (relates to TOSCA) To acquire technology specific parameters and apply to interface run time via spec method. (e.g. ODU spec in TAPI) Model rules and constraints UML patterns with OCL simplified via definition of DSLs Transformation via Pruning and Refactoring [IISOMI] Basis a method for traceable transformation between views and tooling to support these transformations This approach provides a mechanism for deriving model views and for interrelating/interconnecting models in a federation of models (dealing with different semantic “granularity” and semantic “boundary positioning”) – going beyond touchpoints UML-Yang tooling [TR-531 (IISOMI)] Removes need to manually craft the interface realization/implementation definition and eases change in interface and in evolution In general, the IISOMI tooling is targeted at model driven implementation with a focus on development of interfaces (as opposed to functional capability) Lifecycle Sterotypes [TR-514 (IISOMI)] Fine grained control of maturity/lifecycle to enable users to understand risk. Provides a basis for improved clarity of maturity and compatibility

Component-System pattern (essence)
ComponentHasPorts Component-system pattern from TMF IG1118 (the simplified diagram) Strong relationship to TOSCA metamodel Component-system pattern from ONF

Recap: Applicability to ONAP (continued)
Consistent UML modelling [TR-514 and TR-515 (IISOMI)] Open project to influence/change/advancement UML modelling approaches using Papyrus Specific interface data models [TAPI and WDAPI] Refined models for interaction with controllers and devices Working with other bodies such as MEF (MEF Presto is a profile of TAPI), OIF (have done PoCs with TAPI) and various operators (WDAPI and TAPI PoCs) Microwave, Photonic, OTN and Ethernet modelling [via TAPI and WDAPI] Technology specific models for various equipments (working with relevant other bodies (e.g., ITU-T, IEEE etc) Model rationalization The distinct models of resource and service used today need to be converged onto a single model of capability Component-System pattern and TOSCA metamodel Approaches to model federation Mapping models via pruning and refactoring with support tooling (experimental)

Emphasis (and a few extras)
Domain patterns Component-System TM Forum’s Management-Control Continuum Through-to-about (related to definition of interfaces) Domain constraints UML patterns with OCL simplified via definition of DSLs Model Federation Augmentation specification Use of tooling Forming a view via Pruning and Refactoring

Core – Ongoing work Developing/evolving models for:
Software in a controller (but generalized) Operation Patterns (intent) for controller interaction (but generalized) Control functions in the controller and at the controller boundary (but generalized) Processing Construct as a generalized functional element Scheme/System Specifications to define rules for deployments (relates to TOSCA) OAM (with ITU-T, MEF and IEEE) Entity lifecycle Providing examples for: Layer/protocol/technology and Resilience Examples Enhancing tooling Pruning & Refactoring guidelines and tooling Mapping guidelines and tooling for Yang, OAPI, Protobuf, TOSCA Strengthening the model and architecture Enhancing the Model Structure Developing approaches for Lifecycle Compatibility (asynchronous evolution with 24x7 operation at IoT scale)

Resource and Service  Capability
Emerging notion that current models of service are actually models of capability as are the models of resource and hence there is a need for unification A true service is an outcome or experience perceived to be of value by the recipient Function patterns fit all levels from device capability up to delivery to purchaser etc All functions are essentially emergent/logical/virtual A major industry-wide convergence exercise is required The distinct models of resource and service used today need to be converged onto a single model of capability.

Based on ONF modelling work
ONAP WAN IM Proposal Based on ONF modelling work

Network Device OR Opaque Network
Canonical network model (virtualized/functional): Forwarding, Termination and Topology See slide notes Network Showing layers From TR-512.2 Network Device OR Opaque Network A general pattern for all networking focussing on transport Any capability with the purpose of transferring information is transport IP is transport Essential concepts are forwarding, termination and adaptation Pure functional, independent of physical environment but relateable at the port and as below All forwarding/termination can use this model whether it is implemented in a traditional form or virtual/cloudified Deals with “apparent” adjacency (Link) Support Stacking of layer-protocols and network layering Navigation between views For ONAP: Model for any networking for any transport network technology, with any degree of virtualization, at any scale, at any abstraction and in any interrelated view. Model for any networking, for any transport network technology, with any degree of virtualization, at any scale, at any abstraction and in any interrelated view.

Model of Control Function (considering resilience)
From TR-512.5 Model for the control functions in the network, for control of those control functions, and modelling of ONAP itself, for control of ONAP.

TAPI Connectivity model

ONAP WAN IM Proposal CTP

Comments and proposed improvements to ONAP WAN model
Modelling Construct the model in Papyrus Show navigability Model Link connection and XC are FCs in the core model Node is (probably) FD (but could be CD if node is NE) FcPort is not related to FD 1.4 enhancements ControlComponent and its ports and CD replace NE

WAN IM Proposal – Core Overlay… step 1
ForwardingConstruct ForwardingConstruct

WAN IM Proposal – Core Overlay… step 2
Note: Link is missing from the model A similar refactoring as performed by TAPI (FcPort and LTP merged into CEP) Note: Layering is not shown fully here. There is more capability in the core. Note: Node is not an NE. FcPort Ltp ForwardingDomain ONF Core does not have a distinct LinkConnection and XC. You could prune and refactor FC to create an LinkConnection and XC but it is not clear why this would be done. ForwardingConstruct ForwardingConstruct FcPort Ltp FcPort

LinkConnection Can determine that FC is the lowest layer as the FcHasLowerLevelFcs pointer is null.

WAN IM Proposal – TAPI overlay
Note: Link is missing from the model Connection CEP NEP Topology X CEP Route CEP X X CEP Connection Connection CEP CEP NEP

ONAP WAN IM Proposal – M.3100 overlay
SN CTP SNC SNCRoute CTP

Core model: TR-512 V1.3.1 (January 2018)
V1.3.1 can be found at TAPI: V2.0 (last call) Microwave model TR-532 documents the model (see UML Modeling Guidelines (IISOMI 514) Last published version  (September 2016) Latest working draft  Draft_IISOMI-514_UML_Modeling_Guidelines_v docx (February 2018) UML Profiles and Style Sheets OpenModelProfile, v0.2.13 OpenInterfaceModelProfile, v0.0.8 ProfileLifecycleProfile, v0.0.4 Style sheet for class diagrams Github repository: UmlProfiles Papyrus Guidelines (IISOMI 515) Last published version  Latest working draft  Draft_IISOMI-515_Papyrus_Guidelines_v docx (February 2018) UML to YANG Mapping Guidelines (IISOMI 531) Last published version  Latest working draft  Draft_IISOMI-531_UML-YANG_Mapping_Gdls_v docx (February 2018) UML to YANG Mapping Tool Githubrepository: UmlYangTools

Questions? Thank you 

Some thoughts on collaboration, direction and vision
Vision and direction Some thoughts on collaboration, direction and vision

ONF IM team Interface Vision
General Goal: Automation of “everything”, taking people out of the loop but not out of the equation To deal with pace, scale, complexity and need for efficiency/consistency Implications, assumptions and expectations: A cloud oriented future, with cloudified controllers, where inter-controller communication (and some intra-controller communications) will be via native cloud interface encodings Cloud presents true APIs in a programming language Mapping to the communication infrastructure is provided by the cloud infrastructure (perhaps using dynamic encoding such as Apache Avro) Interface interaction will benefit from normalization of interaction patterns and a messaging grammar that unifies the variety of interaction complexities (CRUD, Intent etc) in a single sophisticated structure The key is modelling the message content structure… work is underway in ONF on such a model The structure definition will enable folding away of capability that is unnecessary for any specific interaction Essential to any interaction is the provision of information about the desired outcome in terms of constraints and potentially in the context of some expected initial system state The content of any message will differ per interaction The key to content opportunity for the viewpoint shared between the parties at the interface is determined by the properties of the attributes in that viewpoint (read only, read-write etc) The information about any particular context or outcome can be a flat structure of things and their attributes that is as simple as possible for the specific interaction The structure can vary from interaction to interaction As understood from various activities over the past decade or so the concept of an NE as a thing is broken The NE dematerialized into at least a geographical physical aspect, controlled functions aspect and controlling functions aspect The part of the NE that the controller communicates with is the controlling functions aspect, this is just another controller Emergence of white box NE points to cloudification of the controller functions in the NE In future interface to controller directly attached to the network functionality will via cloud native interfaces as for any other controller In the above environment interfaces generated from canonical models via tooling will be the norm The same interface approach is used at all points in the system including down at the device level

Interpretation of previous two slides
Definition of semantics of exchange independent of the encoding is the key Encoding should be dynamic per case There is a general need for constraint based interactions Potentially to the degree that all interactions are all in terms of constraints It may be possible to define a single representation structure that has a “fold-away” nature (as for the operations pattern) that applies to any request/response/notification where the structure sets out a system of constraint changes

Some notes on “Service” and “Outcome”
Service: An outcome/experience, considered as valuable/desirable by the recipient, that is achieved for the recipient by a provider, where there is an agreement between provider and recipient for this. An experience could be, for example Apparent adjacency To achieve that experience requires information transfer with some performance characteristics that will “fool” the recipient The recipient perceived another party (or thing) as if in the same location as the recipient Notice that each recipient has a very skewed and “personal” view or what is the true service here The service is not the thing providing it. Ethernet Private Line is a thing, the service is the experience of apparent adjacency. Another service is the set-up of the Ethernet Private Line Apparent intelligence To achieve that experience requires a processing that will… When we talk of Outcome Oriented with respect to the interaction between control systems, the presence of the necessary structure achieved by the provider is the Outcome. The service is provided by the control system taking action to achieve the desired outcome. This then results in an outcome of the “apparent adjacency experience” for the user of the resource that has be instantiated

Outcome-oriented constraint-based interaction
Consider the following states and activities: Potential Client needs and potential provider capabilities intersect Both have shared understanding of some semantics in a space where the provider has capabilities and the client needs Both have (or agree) a common representation of the semantics (which may be a mapping from their preferred internal views) The potential provider does not expose all aspects of all capabilities (e.g., “how” may be vague or opaque) The potential client does not expose all aspects of the need (e.g., “why” may be vague or opaque) Potential client and provider negotiate This process may increase the semantic intersection and may refine the representation

Outcome-oriented constraint-based interaction
Consider the following states and activities (continued): An agreement is reached (provider intention and client expectation) The agreement will be expressed in terms of what will be achieved and not how it will be achieved Where the client and provider have limited semantic overlap the agreement may be in terms of experience (e.g., apparent adjacency experience) where many of the parameters will be in client terms and potentially as a client oriented profile (e.g., performance). The service is the experience (and the experience is the outcome) Where the client and provider have an extensive overlap, e.g., as the provider is sub-contracting, then the agreement may be more in terms of an abstract realization outcome (e.g., an Ethernet Connection). The service is the realizing (delivery) of the connection, the connection is a resource The agreement should never have elements of “how” There may be elements of “with what” (i.e., subordinate piece parts) rather than by doing what (i.e., not in terms of activity). The “with what” will be abstract constraints Note: the client should never be interested in the activity required to achieve the outcome, however, it does seem that there is an expectation that there will be an activity based instruction, e.g., “set up the connection” and then perhaps an expectation that the client will observe the activity, in the example connection being set up. There is no clear purpose for such a observation This does not exclude the possibility of updating the client on progress and of allowing the client to suspend activity In all cases the agreement is in terms of achieving some state (e.g., apparent adjacency, connectivity) where that state is specified in terms of constraints It is not necessary to impose the process used to achieve the Outcome/Experience (as this is the responsibility of the provider), so verbs such as “Create” and “Set” are not necessary/relevant

Making changes (intent-style at all levels)
Request in terms of desired outcome/experience Entities of the controlled system are not acted on directly For example, an LTP (Logical Termination Point) does not provide operations for control Entities provided in the view are not acted on directly For example, a NodeEdgePoint does not provide operations for control “Superior” controller requests desired outcome from “overseeing” controller where the outcome is in terms of a structure of the system of components, exposed by the “overseeing” controller, and the state of those components forming that system This is purely in terms of data, for example, LTP-123 associated to FcPort-1092 etc The components, represented as objects, do not offer any operations. Instead the desired outcome infers operations for the underlying systems. If the desired outcome indicates that traffic should flow between two points it is clear that those points need to exist. If those points do not exist then it can be inferred that the points will need to be created. There is no need to explicitly ask for creation (and other terminology may be used in the domain to convey the “creation” semantics).

Management-Control Continuum
Experience/Outcome Expectation ContractIntent Experience/Outcome Opinion Achievement Compliance Controller View Recursion of control levels Essentially the same at all levels Including the device  Automated management is control A “layer” of control revolves round a model of the controlled things A control layer will have a repository reflecting: Intent to support a contract/agreement with or request from a client Expected and current state of the controlled things in the context of the chosen realization A control “layer” will present, to its clients, in client terminology, an abstracted view of what it controls where that view aligns with the current contract in terms of: Potential for providing capability Actual provided capability The provided capability will be in terms of constraints Transform/ Mapping Transform Transform Comms (Through) Request Inform Controller (To) View Transform Transform/ Mapping Transform Controlled stuff (About)

Control System View provided to a client

Dynamic demand pattern
One structure with grammar that is essentially extensible but over time stabilizes Like human language grammar, it provides the “invariant” structure that enables a range of interaction sophistications Expressed communication capability i.e. how much of the grammar is understood Infinitely extensible semantics Noun set (simple extension by adding nouns Interpretable constraint set (dynamic extension) Expressed semantic coverage Opportunity for sophisticated expression of delegated interdependent outcome structure Per exchange-set encoding choices, negotiated and supported by the infrastructure (e.g., Apache Avro) allowing on-the-fly encoding optimization I.e., dynamic encoding

Overview of Operations pattern (summary sketch)
It is envisaged that a single compositional structure can describe all degrees of interaction from simple CRUD to complex multi- task constraint delegation This single structure is designed such that 1of1 composed parts are folded into the parent on a case by case basis This yields a message that is compact for a simple case but sophisticated for a complex case A basic controller could offer a limited range of operational capability and provide a schema that is a sub-set of the full pattern (explicitly explaining what it can do (in terms of operations pattern schema) – not what it can’t) An advanced controller could offer the full range The advanced controller could communicate with the basic controlled without adjusting its full schema definition as it limits the usage to the narrower capability of the basic controller As an analogy consider human language grammar where an adult talks to a child

Considering TOSCA OASIS TOSCA has a focus on Cloud
However, there appears to be a potential for a general solution for a broad swathe of cases including cloud where they TOSCA provides a cloud oriented sub-set ONF IM work applies to TOSCA as well as that broader context Component-System Pattern Management-Control Continuum Canonical models of networking, control, processing, physical, software Approach to interfacing The next two slides try to illustrate the difference between Taxonomy/classification and the approach taken in ONF

Progression of Classification – Adding semantics
Thing has the common properties Info Component Equipment Thing Controller PC LTP

Progression of sub-setting – Constraining Semantics
Thing has all possible properties. Specific semantics relate to the specific modelled thing and are a narrowing of thing. The definitions do NOT need to be orthogonal although the intersections should be minimised. Thing Component PC LTP Equipment Controller Information

Adding capability detail
The detailed capability of a thing is expressed by decorating with parts that themselves have constrained semantics that fit within the definition of the thing This is essentially a process of exposing previously obscured semantics The capabilities may be expressed in terms of apparent subordinate parts where these parts can be positioned on the constrained semantic map An LTP may have controllers within it but those controllers only emerges when the LTP is dismantled or its behaviour is expressed.

Spec approach Defines the decoration that details, for a particular case, part of the semantic space covered by the class This allows for a dynamic extension (and reduction) of exposed capability which interplays with intent The scheme spec describes a system structure in terms of classes of the model and in terms of constraints The same grammar for systems of constraints would appear to apply here The scheme spec provides the constraints on what outcomes can be requested

The component and the system - reminder
Any functionality can be considered in terms of a system of components Where the system can be viewed as a component Any view of functionality offered by a component can be considered in terms of a system of components The system will usually be an abstraction of the system that “actually” supports the Component

Components and views of components in terms of components

Development Process Many overlaid asynchronous cycles with different phases & different lifecycle timeframes Assess feedback Feedback Evaluate standards and best practices Identify broad use cases Consider real need Extract Insight Consider vision Extract Insight Analyse Develop Insight Analyse ONF Core IM Products Measure PoC Develop Structure Dev Ops Plugfest Use/Exercise Develop Architecture Prototypes Develop Patterns Analyse Develop Canonical Models Model Vision Develop usage examples Running System Identify specific application Integration Create Mapping models Open Source Prune & Refactor Example models Implementation Proprietary Interface Viewpoint models Specific technology models Develop Scenario Implementation generation ONF TAPI, ONF WDAPI, MEF Presto etc Validation Identify specific use cases Focus on specific current needs Interface Code Validated examples

Information Model & Tooling from OIMT, OTCC and IISOMI Resource/Service/Capability considerations Nigel Davis (Ciena) 20180325 OIMT (ONF Open Information.

Similar presentations

Presentation on theme: "Information Model & Tooling from OIMT, OTCC and IISOMI Resource/Service/Capability considerations Nigel Davis (Ciena) 20180325 OIMT (ONF Open Information."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Information Model & Tooling from OIMT, OTCC and IISOMI Resource/Service/Capability considerations Nigel Davis (Ciena) 20180325 OIMT (ONF Open Information.

Similar presentations

Presentation on theme: "Information Model & Tooling from OIMT, OTCC and IISOMI Resource/Service/Capability considerations Nigel Davis (Ciena) 20180325 OIMT (ONF Open Information."— Presentation transcript:

Similar presentations

About project

Feedback