Introduction to models, guidelines and tooling from ONF Open Info Modeling project, ONF Transport Config & Control project and IISOMI (Informal Inter-Standards.

Introduction to models, guidelines and tooling from ONF Open Info Modeling project, ONF Transport Config & Control project and IISOMI (Informal Inter-Standards Object Modelling Initiative) Nigel Davis (Ciena)

Agenda Brief context setting
Key ONF model and tooling features highlighting potential relationship to ONAP

Aspects of the projects
Approach Model of semantics independent of implementation Evolvable, extendable interface implementation Focus on code and round trip Focus on agile processes and close working Closing the loop models and realization Focus on tooling and automation of development Elements of the projects The Core Model Canonical models of key areas of the problem space Tooling to assist model transformation and remove mechanical steps Interface definition Reference Implementations Stimulation of, and support for, PoCs

ONF Models and Interfaces IISOMI guidelines and tooling
See slide notes The core model is published as ONF TR-512 TR-512 includes a suite of documents and the XMI-encoded UML information model developed using the open source Papyrus tooling in the Eclipse environment The model structure and tooling usage follow the IISOMI guidelines The core model is an interconnected set of domain canonical models (see details later in this pack). It is intentionally devoid of: Implementation specific details (related to interface encoding) Forwarding technology details (related to the network technology such as IP) To construct an interface model (in UML), the core model is Pruned & Refactored to match the needs of the purpose of the view provided by the targeted interface Pruning and refactoring is a significant intellectual exercise IISOMI Tooling is being developed to support the process (currently prototype) Examples are TAPI (Transport API) and Microwave Interface (sometimes known as WDAPI – Wireless Device API), To add forwarding technology details the technology models from ITU-T etc are Pruned & Refactored to form API augmenting specifications The same IISOMI tooling applies to this process The Interface model is coded using IISOMI tooling that follows appropriate IISOMI mapping guidelines Current tooling produces Yang and JSON from the UML models Developing tooling for Protobuf and considering TOSCA Core model: TR-512 V1.3 (September 2017) V1.3 can be found in in (when in the V1.3 folder select TR-512_v1.3_Publish.zip) TAPI: V2.0 (last call) Microwave model TR-532 documents the model (see UML Modeling Guidelines (IISOMI 514) Last published version  v1.2, Sept. 2016 Latest working draft  v1.3.04, Nov. 2017 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) Latest working draft  v1.3.02, Nov. 2017 UML to YANG Mapping Guidelines (IISOMI 531) Last published version  v1.0, Sept. 2016 Latest working draft  v1.1.05, Nov. 2017 UML to YANG Mapping Tool Githubrepository: UmlYangTools

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. 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.

Canonical physical model
See slide notes Canonical physical model From TR-512.6 Represents truly physical things, i.e. things that can be measured with a ruler Focusses on electronic equipments Any rack based, circuit pack based solutions can use this model Supports a stand-alone equipment Has a representation of physical connector and abstract cable For ONAP: Model for any physical components that are rack/cabinet/shelf based or stand-alone in a data center or telco environment For ONAP: Model for any physical components that are rack/cabinet/shelf based or stand-alone in a data center or telco environment

Model of control function
See slide notes Model of control function From TR-512.8 Focussing on: Generalized control (see above) Configuration and Switch control (see next slide) Initially dealing with protection and restoration schemes Progressing from specific control to model of general control For ONAP: Model for the control functions in the network, for control of those control functions, and modelling of ONAP itself, for control of ONAP. For ONAP: Model for the control functions in the network, for control of those control functions, and modelling of ONAP itself, for control of ONAP.

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

Model of generalized processing and constraint
See slide notes Dealing with non-transport functions covering any functionality in abstraction All functions are emergent and hence all functions are virtual Supporting part of the control model Enabling removal of the faulty concept of NE and replacement with a versatile constraint based model For ONAP: Model for any arbitrary functions/constraint, views of abstractions of functions/constraints, interconnection of functions to networking and relationship of functions to the physical environment. For ONAP: Model for any arbitrary functions/constraint, views of abstractions of functions/constraints, interconnection of functions to networking.

Association between physical and functional model
See slide notes From TR-512.6 Achieved via the generalized processing model Recognizes that all behaviour is emergent and hence all functions are virtual Strongly separates concerns of true physical from true functional Corrects issues with “equipment” protection recognising that: It is not the physical thing that is protected A single physical unit may support several functions where each is involved in a different form of resilience For ONAP: Basis for model for the understanding of the physical realization of functional things (regardless of how “virtual” they are) For ONAP: Basis for model for the understanding of the physical realization of functional things (regardless of how “virtual” they are).

Replacing the NE with a flexible constraint domain model…
See slide notes From TR-512.6 Same model as previous slide This model would apply to all control/controlled devices (EMS, SDN Controller etc) This removes the issues of which ring are the NEs in etc. For ONAP: Basis for modelling/representation paradigm that overcomes many traditional issues with NE and also applies to any physical/functional combination For ONAP: Basis for modelling/representation paradigm that overcomes many traditional issues with NE and also applies to any physical/functional combination

Through-to-about pattern and Model of control interfacing (as part of the MCC)
See slide notes Experimental Draft Provides the interfacing pattern for SDN control functions NOTE that an SDN controller is a virtualized thing, it is NOT physically bound The SDN control functions can be related to the physical equipments in the same way as the network functions Also provides the interfacing pattern for traditional EMSs, NMSs and Nes The EMS/NMS/NE dematerialize and their functions simply become elements of a recursion of control loops Any interfacing to a control element can be represented with this model pattern Implications for operations Operations are only present on the ControlComponentPort and are about the controlled entities in the view This may include the ControlComponents themselves component Operations are related to achieving specific entity state combinations independent of method Legal combinations of states are conveyed with OCL constraints in Spec model (see below) Any outcome combination can be specified For ONAP: Basis for operations paradigm that assumes a controller talks to another controller about the controlled things and modelling of Control hierarchies etc For ONAP: Basis for operations paradigm that assumes a controller talks to another controller about the controlled things and modelling of Control hierarchies etc.

Modelling of generalized message structure
See slide notes Modelling of generalized message structure Simplified form of model From TR As a basis for Outcome-Oriented Constraint Based (OOCB) interfacing style at all levels of control Assumes statement of desired outcome in terms of nouns (things and state of things – where state may be nth order) Provides part of a “grammar” for message structuring Offers “fold-away” structure Enables simple CRUD and complex order to be on a continuous spectrum of definitions Relates to the following (should compared/converged/merged) TMF Order ONF/MEF Intent SUPA TOSCA OOCB is intent-like and order compatible For ONAP: Basis of uniform definition of operations paradigm (that is outcome-oriented constraint-based) and message structure/grammar for all interfaces For ONAP: Basis of uniform definition of operations paradigm (that is outcome-oriented constraint-based) and message structure/grammar for all interfaces

Component-System Pattern as a basis for functional models
See slide notes Component-System Pattern as a basis for functional models From TR-512.A.2 The ONF Core provides a number of views of functionality In addition to functional things there are also physical The broadest functional semantic is the component-system pattern. Any functional thing can be considered as a component All functions are considered as emergent and hence virtual In addition to functional things physical things can also be considered in terms of the component-system pattern The component can be decorated with any properties that fit the semantic of the functional component with no need to re-classify A system is a structure of components and can itself be considered as a component Narrower semantic spaces are provided by the PC/LTP/FC etc These are introduced to ease human understanding and to match the essential granularity current state-of-the-art solutions The ONF model intentionally does not specialize LTP etc further, specific cases are detailed using a decoration approach The Component-system pattern underpins the ONF model and is similar to the TOSCA meta model In the ONF Core model, in most cases a class is defined by its properties, associations and constraints. The class defines a semantic envelope The classes related to the port of the control component also have operations For ONAP: Basis of uniform modelling of functional and physical things. For ONAP: Basis of uniform modelling of functional and physical things.

ONF Specification approach for decoration/augmentation
See slide notes Allows run-time decoration, of instances of generalized classes, with specific details Assumes rich general behaviour can be constructed using the core classes and decouples specialist behaviour from this general behaviour Allows subtle per case variety to be expressed Partial conformance Pre-standard capability Deals with cases of: Termination assemblies and inter-connectability Equipment to function mappings System schemes (such as G.8032 protection) Relates to TOSCA templates (but applied throughout the solution) For ONAP: Basis for definition of template/specification approach for all modelled things

Transformation via pruning and refactoring approach [IISOMI]
See slide notes Emerging rules and tooling for the transformation of one view model into another view model Supports the construction of relevant views and tracking the relationship between the views Is used in ONF to form: TAPI and WDAPI from the ONF Core model Technology specs from ITU-T etc models Scheme spec structures that express legal network structures in terms of the ONF Core model The target is round trip modelling supported by tooling Generation of models via rule-controlled intertwining of pattern models and via rule-controlled recursion of P&R stages For ONAP: Basis a method for traceable transformation between views and tooling to support these transformations For ONAP: Basis a method for traceable transformation between views and tooling to support these transformations.

Generated encoding (UML-Yang etc) [IISOMI]
See slide notes Interface schema and encoding generated from a UML model via a tool chain conformant to mapping guidelines The UML model has complete and proper type definition Intention is that various encodings of the semantics of the model are provided UML-YANG-OpenAPI etc Guidelines and tooling Used by TAPI Target use by WDAPI UML-JSON (for TAPI): Variant of TAPI encoding UML-protobuf: Draft guidelines Target is full round trip Patterns  P&R  Core  P&R  TAPI/WDAPI etc  Generator  Interface where modifications can be made at any stage and implications fed back/forwards For ONAP: Removes need to manually craft the interface realization/implementation definition Eases change in interface and in evolution. For ONAP: Removes need to manually craft the interface realization/implementation definition Eases change in interface and in evolution.

Lifecycle stereotypes [IISOMI]
See slide notes Includes: Experimental, Preliminary, Mature, Obsolete… Applied to each UML artefact including class, property etc Experimental things may conflict and may change (including be deleted) from release to release. Clarity for users of the model Eases review and approval process For ONAP: Fine grained control of maturity/lifecycle For ONAP: Fine grained control of maturity/lifecycle to enable users to understand risk.

Consistent modelling [IISOMI]
See slide notes multi SDO multi SDO Papyrus Guidelines IISOMI 515 UML Modeling Guidelines IISOMI 514 Other candidates: ONAP OIF … Consistent use of UML and tooling is achieved using: Papyrus guidelines UML guidelines IISOMI guidelines applied: In ONF In ITU-T To a degree in MEF To a degree in ETSI-NFV For ONAP: A basis for consistent UML modelling. Members can join IISOM and influence change/advancement. For ONAP: A basis for consistent UML modelling. Members can join IISOM and influence change/advancement.

Microwave IM and interface
See slide notes Essentially a direct use of the Core Model with significant pruning but minimal refactoring Currently applies Wireless specific properties by reverse navigable composition (*_Pacs approach) Is moving to specification approach Currently hand crafts Yang from model Is moving to use IISOMI tooling Applicable to south bound to ONAP PoC has demonstrated working with ONAP TR-532 documents the model (see For ONAP: A South bound interface for the wireless equipments

ONF Transport API (TAPI) and MEF Forum LSO Presto
See slide notes Interface definition/implementation for control of networking Supports three abstractions of forwarding (Link, Connection and ConnectivityService) and corresponding terminations Is derived from the Core via pruning and significant refactoring For ONAP: An interface between controllers and orchestrator in an ONAP context. For ONAP: An interface between controllers and orchestrator and between hierarchical network orchestrators in an ONAP context.

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 of value Network patterns fit all levels from device capability up to delivery to purchaser etc A major industry-wide convergence exercise is required For ONAP: The distinct models of resource and service used today need to be converged onto a single model of capability.

Questions? Thank you 

Background The following slides provide material that supports various points made during the presentation

Drivers: Vision and apparent/necessary trends
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 Trend: To coding for patterns From coding per case To continuums From distinct layers and silos To assemblies of versatile focussed components From branded monolithic “solutions” To modular fluid federation of pattern based models From monolithic static conflicting taxonomical hierarchical models To an Agile Value Fabric of versatile and continually evolving interacting service provider organizations From fixed role slow change market players To evolving open agile standards From boom-bust rigid fragile standards Including for: Patterns: From specialist verb based coded interfaces to grammar-structured Outcome-Oriented Constraint-Based agile interaction Continuums: From silos of distinct management of manual activities (NMS, Orchestrator, Controller…) to a continuum of recursion of uniform automated closed loop control Assemblies: From a single vendor solution market to an app-store-like marketplace of interchangeable components and the opportunity to build assemblies of best-in-breed capabilities (e.g. vendor x PCE with a vendor y provisioning engine in organization c framework) Federation: From the notion of one overarching model to the reality of a federation of many viewpoint models Agile Value Fabric: From telco and cloud operators to providers of value who can reposition their business easily Evolving standards: Shaped to suit the Fractal Innovation Value Lifecycle with continuous Lifecycle Compatibility and accounting for Lifecycle Timeframe Playing into the Agile Value Fabric of the ever-broadening industry Secure dynamic cloud for all but photonics All functions are virtual Separation of concerns Dealing with evolution and change Fractals, continuums, patterns, intertwining, recursions, viewpoints, growing insight

Information Model evolution

(inc. converged network ABE)
ONF Tooling evolution ITU-T Technology IMs TMF SID ONF IM (inc. converged network ABE) ONF Spec Approach NVP extension TMF MTNM / MTOSI Manual P&R Tool Assisted P&R Tool Assisted P&R Mapping Mapping Manual Generation Experience, lessons, insight Manual process CORBA IDL & XSD TMF TIP TAPI Tooled process Model migration Tooled Generation Tooled Generation UML Tool Implementation OssJ Transformation Tooling Java & XSD Yang, REST, TOSCA… IBM RSA (Eclipse, Proprietary) Tooled Generation TigerStripe (Cisco, Open Source) Papyrus (Eclipse, Open Source) Time IISOMI (Java Script, Open Source) Java & XSD 2005 2011 2017

Guidelines evolution UML Modeling Guidelines IISOMI 514
multi SDO UML Modeling Guidelines IISOMI 514 UML Modeling Guidelines ONF TR-514 ITU-T SG15 Modelling Guidelines NGCOR Modelling Requirements Other candidates: ONAP OIF … JWG MA Model Repertoire

Influence Across Standards and Open Source
TAPI FRS Use cases & Requirements TAPI UML Information Model TAPI YANG Data Schema SWAGGER/REST APIs ONF Core Information Model ONF Technology Specification Models UML-YANG Generation Tool YANG-SWAGGER Generation Tool SNOWMASS TAPI SDK EAGLE Modeling Tools Open Model Profile Code OTN (ITU-T G.874.1) ETH (ITU-T G.8052) MPLS-TP (ITU-T G.8152) Python Reference Implementation Python Stub Generation Tool Optical Transport MEF Open CS Implementations Packet WAN Multi-carrier T-SDN Interop Implementation Agreements & Certification OIF Interop Implementations NRM MEF Models NRP ONF OIMT ONF OTCC ITU-T SG15 Technology Generic Core Model (ITU-T G.7711) ONF OTCC

TAPI Design Process Target is software rather than specs
Functional Requirements (ONF TR) Information Model (UML in Papyrus) Data-Schema (JSON/YANG) Prototype Code & Testing Purpose-specific Use cases TAPI Design Process Target is software rather than specs ONF Snowmass Github Site

UML Model (TAPI SDK)

Transport API 2.0 Functions
NE SDN Controller Application Transport API Topology Service Retrieve Topology, Node, Link & Edge- Point details (Across layers) Connectivity Service Retrieve & Request P2P, P2MP, MP2MP connectivity (Across layers) Notification Service Subscription and filtering / Autonomous event notification OAM Service Creation and Activation of Monitoring Points/Sessions Path Computation Service Request for Computation & Optimization of paths Virtual Network Service Create, Update, Delete Virtual Network topologies Topology Service Connectivity Service Path Computation Service Shared Network Information Context Virtual Network Service Notification Service OAM Service NE Network Resource Groups SDN Controller Transport API SBIs (e.g. Openflow Optical)

TR-512.7 Figure 4-19 Relating LTP/LP spec with the class and instance models

ODU spec

Network Resource Model Positioning
MEF Network Resource Info Model MEF Network Resource Provisioning IM Public

MEF Network Resource Model Augmenting ONF TAPI
<<Specify>> relationship indicates the ONF Specification approach, which allows to augment / refine capabilities of referred classes through a more flexible relationship than inheritance or composition. The result is that MEF NRM Class attributes are inserted into TAPI class. Specify MEF NRM Class ConnectivityService Specify MEF NRM Class ConnectivityServiceEndPoint Specify MEF NRM Classes MEF NRM Classes ServiceInterfacePoint MEF NRM Classes MEF NRM Class ONF TAPI Class Public

Forwarding, Termination and Topology
Network Showing layers From TR-512.2 Network Device OR Opaque Network

Forwarding, Termination and Topology
From TR-512.4

Resilience From TR-512.5

Physical From TR-512.6

Emergent behavior From TR-512.6

The Spec Approach From TR-512.7

The control model From TR-512.8

Processing Construct Model
From TR

Control port with operations (sketch)
Early experimental work

Moving away from the traditional NE
The traditional NE is replaced by a combination of the: Control model ProcessingConstruct and ConstraintDomain Physical model Various specific functional models The association between function and physical is defined using the ConstraintDomain and ProcessingConstruct

General Operations Patterns
From TR

Component-System Pattern
From TR-512.A.2

Some observations The Canonical models are built from classes that represent “deep” semantic spaces Each class represents the set of all cases of things that are within the bounds of the definition of that class E.g., the LTP represents all cases of termination including those for technologies that have not yet been developed Each class is extensible and may be extended to cover any case Each case is defined specifically by the combination of properties exposed The classes are extended using referenced specifications of property combinations Each property relates to some functional capability The aim is that each functional capability will be defined formally such that the property itself represents a semantic space etc The specification approach is modelled The Canonical models are derived from the Component-System pattern where: The Component defines the semantic space of all functions Each class in the Canonical Model has a semantic scope narrower than that of the Component Although the classes appear to cover disjoint sets, it is apparent from their substructure that the inner structure of a class may be described by other classes in the canonical model (due to the recursive/fractal nature of the Component-System pattern

Component-System Pattern
From TR-512.A.2

Pruning & refactoring Tooling is currently prototype
… " }, "maintainers": [ { "name": "oozcitak", " ": } ], "_npmOperationalInternal": { "host": "packages-12-west.internal.npmjs.com", "tmp": "tmp/xmlbuilder tgz_ _ Pruning & refactoring Tooling is currently prototype Generalized Core model is pruned to remove elements not necessary for the TAPI view, for example ProcessingConstruct. Pruned Core model is refactored to project familiar named items, for example: ForwardingConstruct in the Core becomes both Connection and ConnectivityService in TAPI. LogicalTerminationPoint in the Core becomes NodeEdgePoint, ConnectionEndpoint and ServiceEndPoint in TAPI. Tooling supports the Pruning and Refactoring process Constructs a clone of the model with multiple interconnected copies of the classes from the source model where requested Highlights differences between models Longer term Tooling will support further refactoring including the merging of classes from several models

Ongoing Core Model work
Some thoughts on collaboration, direction and vision

Core – Work with other bodies
MEF The core model strengthens the rationale behind TAPI which is being used by MEF at the PRESTO interface The aim is to influence the work in the MEF core model on an ongoing basis driving for industry convergence and federation of models OASIS-TOSCA The underpinning component-system pattern appears strongly related to the TOSCA meta-model The ONF specification approach appears to be related to the TOSCA templates The aim is to work towards harmonization with TOSCA (there appear to be insights on both sides that could benefit the other) ONAP Influence release 2 model work in ONAP with the aim to support and foster convergence of the various open source initiatives ITU-T (publish TR-512 as G.7711) Continue to improve alignment and to develop specification models for the specific technologies TMF (in the process of adopting TR-512.2, TR and TR in place of the TMF SID 5LR model) Driving for industry convergence and federation of models

Core – Ongoing work Developing models for: Software OAM
Entity lifecycle Operation Patterns and intent Control functions Processing Construct Scheme Specifications Providing examples for: Layer/protocol/technology and Resilience Examples Enhancing tooling P&R guidelines and tooling Mapping guidelines and tooling for Yang, OAPI, Protobuf, TOSCA Strengthening the model Enhancing the Model Structure

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 Not the approach taken in the ONF IMs 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

Introduction to models, guidelines and tooling from ONF Open Info Modeling project, ONF Transport Config & Control project and IISOMI (Informal Inter-Standards.

Similar presentations

Presentation on theme: "Introduction to models, guidelines and tooling from ONF Open Info Modeling project, ONF Transport Config & Control project and IISOMI (Informal Inter-Standards."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Introduction to models, guidelines and tooling from ONF Open Info Modeling project, ONF Transport Config & Control project and IISOMI (Informal Inter-Standards.

Similar presentations

Presentation on theme: "Introduction to models, guidelines and tooling from ONF Open Info Modeling project, ONF Transport Config & Control project and IISOMI (Informal Inter-Standards."— Presentation transcript:

Similar presentations

About project

Feedback