ONF presentations to ETSI NFV m-SDO IM/DM Workshop Proposal for way forward – Interconnecting ONF and NFV work January 2016.

ONF presentations to ETSI NFV m-SDO IM/DM Workshop Proposal for way forward – Interconnecting ONF and NFV work January 2016

Topics in scope for cross SDO alignment
(timing for 40 min presentation, 20 min presentation) (some slides will not be presented in detail) Topics in scope for cross SDO alignment Functional model interrelationship (12 min, 8 min) Presents a proposal for interconnect of the NFV and ONF models to provide a single federated model, highlights model adjustments necessary and provides rationale Challenge of Nested Recursions (5 min, 3 min) Highlights that NFV builds on SDN and SDN builds on NFV. Discuss the implications. Model development and interactions (4 min, 2 min) Explores peer and hierarchical interaction approaches (umbrella/federation) and makes a proposal for a particular way forward Responsibility partitioning and cooperative working (4 min, 1 min) Based on the discussions above proposes a division of work across the bodies Control Model interrelationships (3 min, 1 min) Presents proposals for unification of the management/control following the principles of Management-Control Continuum and a related proposal for refactoring the NE Sharing patterns (3 min, 1 min) Provides a list of patterns that underpin the network model and suggest that at least some of these would appear to underpin the NFV model and hence should be commonly used. Other model fragments that may benefit from sharing (2 min, 1 min) Highlights other areas that may benefit from collaboration and convergence Generating interfaces (3 min, 1 min) Explains the ONF process to development of interfaces from the model and exposes open source tooling to generate schema (inc Yang) from UML Tooling and process interworking (3 min, 1 min) Discusses further alignment of tooling and guidelines to ease sharing and interconnecting of models IPR and copyright (0 min, 0 min) Touch on IPR, copyright, open source and other related topics highlighting key challenges Conclusions (1 min, 1 min)

Functional model interrelationship: Analysis and proposal
Brief analysis of the NFV model and approach to attachment to the ONF model Considered: Key focus of the two bodies of work Positioning as identified in various previous activities across the industry Further evaluation required after Clarification of definitions of NFV classes Potential refinements of definitions Recent update to NFV model is accounted for (appears to be no impact at this level of analysis) Strawman proposal (depicted in detail in later slide) Summary: Use ONF network model capabilities to join NFV VNF model ports (choice depends upon NFV definition) With two alternative forms (depending upon whether there is a layer protocol aspect in the VnfExternalConnectionPoint or not) Option 1: Derive the VnfExternalConnectionPoint from the ONF LTP Option 2: Attach the port of the VNF (VnfExternalConnectionPoint) to an ONF LTP With two types of join (both can be used in combination) Adjacency of some VNF protocol – ONF Link Forwarding of transport protocol – ONF FC Actions: Addition to ONF CIM: Make some NFV classes part of an enhanced ONF Core IM Derive some NFV model elements from ONF CIM: Use either prune/refactor or inheritance Removal of some classes: Directly link the NFV and ONF models and remove redundant classes Next steps Validate rationale for choice of attachment and make choices from above Identify changes to NFV model and ONF model and act on those changes Coordinate work on-going

Functional model interrelationship: Rationale
There is one problem space being covered by several specification bodies Networking is not new and there is a model already in place What is new is coherent representation of the virtual functions The problem can be divided neatly between modelling of specialist virtual functions and modelling of networking The ONF CIM Core Information Model is built on many years of networking experience as noted in the model overview TMF SID Converged Network ABE (Abstract Business Entity) Info Architecture section TMF TR215 Component System pattern etc. ITU-T G.800

Functional model interrelationship: Detailed proposal
ONF/MEF/ITU-T Class To be refined to align with current iteration of NFV model (late December version) NFV Class NFV Class to be replaced by ONF/MEF/ITUT class NFV model ONF model

Functional model interrelationship: Extract for latest NFV model

Challenge of Nested Recursion: Rationale and data points
As a context for this discussion, consider two distinct services: A transfer (forwarding) service where the intention is that “what goes in comes out” so the input information is unchanged (ONF focus) A transform (processing) service where the intention is that “information is assimilated and used to provide some result” so the input information is transformed (NFV focus) In a real environment Transfer service Achieved by transforming the representation of the information to enable it to be conveyed To determine whether transfer has been successful processing is carried out Transform service Achieved by transfering information between transform points All aspects can be considered as components in a Component – System recursion A system is an assembly of components that can itself be viewed as a component Modelling practice leads to encapsulation of lesser parts in parts that focus on the critical emergent behaviour The outer most view focuses on the key emergent behaviour Considering existing forwarding models there are clearly processing aspect encapsulated Decision to throw a protection switch Decision to discard a packet (various reasons) Forwarding is itself a somewhat dull processing function The user may primarily need information to be transferred or may primarily need information to be transformed Information transfer necessarily has as its outer most representation a Forwarding construct Information transform necessarily has as it outer most representation a Processing construct There appear to be essentially three distinct behaviour, transfer/forwarding, transform/processing and storage (the last being ignored here)

Challenge of Nested Recursion: Implication
The presentation should match the users expectations If the user has requested a forwarding service then a forwarding model should be presented If the user has requested a processing service then a processing model should be presented Forwarding requires processing and processing requires forwarding There is a deep intertwining of the two Forwarding can be encapsulated into a processing representation and processing into a forwarding representation (given the right circumstances). Hence: An ONF FC/LTP can encapsulate processing functions The LTP is a representation of the necessary protocol access stack An ETSI NFV VNF can encapsulate forwarding functions Neither are necessarily at the top or at the bottom of the stack and both may be intertwined at many levels of recursion There is benefit in converging the modelling approaches, styles and patterns to maximise the opportunity for appropriate intertwined usage It is proposed that figures be drawn that emphasize this recursion to better explain the positioning of ONF and ETSI NFV work

Challenge of Nested Recursion: Illustrative sketch
Extracts from ONF intent work (reference provided in original input) The figure below shows network function connected by Forwarding Constructs with the assembly forming a ForwardingConstruct The figure below shows processing function where the effect is a processing service Key ForwardingDomain LTP (Connection) Processing Function (VNF) LTP (physical or floating) ForwardingConstruct

Model development and interaction
Two distinct approaches Peering of models in a federation where There is no specific hierarchy and no overarching model Work is done jointly by members of two or more bodies at touch-points Where touch points become an overlap a new domain of work is created with clear ownership Hierarchy of models with an umbrella where The umbrella model provides a light weight representation of relationships between models The umbrella may stay as a light weight form or may deepen to become a core model for all domains and where that umbrella model is enriched as models converge An umbrella model approach was used between 3GPP and TM Forum The specific approach had challenges with ownership and the need for detailed re-approval of work in the participating bodies It is proposed that a distributed federation of peer domain focus activities be the approach rather than a shared umbrella (hierarchy) Each domain focus has clear ownership Convergence leads to new arrangements of domain focusses As the approach matures some domains may have very broad influence (covering patterns etc)

Responsibility partitioning and cooperative working
Position focuses ONF: Forwarding (encapsulating Processing) Simple processing (and complex processing with a simple emergent effect) is subsumed (e.g. packet discard) Network lifecycle management and control Note that it is intended that this be joint work by MEF, TMF and ONF (and ITU-T) NFV: Processing (encapsulating Forwarding) Simple Forwarding is subsumed (e.g. some local wiring) VNF lifecycle management MEF: Ethernet specific services and operations, general service specification TMF: Operations practices (FMO (Future Mode of Operation) and MCC) and business operations models ITU-T: Network technology specific models (OTN, Ethernet, MPLS-TP etc) Generalizable items that may warrant their own focus (work is underway in ONF on each item below) Massive Functional Component (i.e. anything that is a complex emergent function such as a word processor) Physical Component (i.e. that can be measured with a ruler) Management-Control Specifications and specification pattern Related… Architecture needs to be converged between ONF, TMF, MEF, ITU-T, NFV etc Proposal: A recursive, component-system pattern based architecture Note that convergence of architecture will point to deeper convergence of the information models and improvement in joint working

Control model interrelationships
The traditional network element is a hybrid of physical, functional, control scope/view and control access considerations There are many issues with the current form Separation of concerns brings clarity Functional aspects are essentially virtual within the physical boundary Control scope/view and control aspects are common with all other controller/manager entities There would appear to be a generalized form of control scope/view/access model that applies to all cases of management-control This model recurses through layers of management-control Management is control (consider Management Control Continuum (MCC)) We should have the same patterns for management/control/orchestration at all levels of abstraction There is an opportunity to develop vision in this space and to work to eliminate historic problematic practices This should be collaborative across all bodies Work is proceeding in the ONF on a generalized control model to apply to the controller and the Network Element There may be an opportunity for closer working with ETSI NFV in this area Propose that current modelling work be shared with a view to alignment etc

Sharing patterns We should align on common patterns that are generally advantageous: Use TMF TR-215 liaised to ONF and provided by TMF to ETSI-NFV for the meeting Hypergraph: A graph with multi-pointed edges (hyperedge) Component-System Encapsulation (illustrated in Component-System and Hypergraph) Transfer-Transform Specification to constrain a model that exposes variety via conditional composition rather than inheritance Recursive/nested control loops

Notes on hyper-edge

Notes on System of components viewed as a component (animated)
A component with ports Function Function Function Function Function Function

Other model fragments for potential convergence
Specifications, descriptors and templates Equipment and physical constructs Naming and Identifiers State machines Dependency graph

Generating interfaces
Use essentially the prune/refactor process as identified and used in ONF The ONF-CIM provides Canonical models for domains of interest relevant to ONF For any particular purpose, a view of the domains will be required A view model must abide by the Canonical models but will be a subset of the models covering a narrower scope and capability set Pruning is the process used to derive a model with the appropriate narrower scope for the view As the view is narrower it could benefit from restructuring A view may also benefit from relabeling to make it compatible with the viewers terminology This may also include sub-classing (to apply different labels to different cases of a single core model class) Refactoring is the process used to restructure and re-label things in the model The primary purpose of a view is for presentation over an interface to enable interoperable interaction between controllers and other devices The view will be oriented towards a relevant presentation and the encoding of that presentation Share development of tooling to support the prune/refactor process Use auto-generation of interface schema from appropriate UML model Tooling available (and evolving) in ONF Open Source project (Eagle)

Tooling and process interworking
Tooling and model generation/usage approaches should be aligned ONF and NFV have exchanged guidelines but these are not fully aligned UML Modeling Guidelines Papyrus Guidelines (also covers approach to parallel working, use of gendoc and used of git) ONF and NFV should target alignment by end 2016 There is detailed material on this in the background of this slide pack and it is proposed that this be used (ideally whilst in this face to face meeting) to identify areas for focus on alignment (target for alignment end 2016) Noted that MEF and ONF share aligned guidelines ONF is developing mapping guidelines and associated tooling (in open source Eagle community) UML  YANG UML  JSON etc It is proposed that the mapping guidelines and tooling be used by ETSI-NFV

Interface Creation Process
Current ONF model structure, documents and process Core model fragment (TR-512) module-1 module-2 …. module-n Data schema for interface 1 Application 1 model fragment (e.g. from NBI project) Technology (e.g. OTN) model fragment (e.g. from OT project) Guidelines Interface specific TR513 Common process Common Information Model xxx model fragment (from yyy project) Map Prune/refactor View of the common IM for a particular purpose TR515 Papyrus tool and GitHub Model structure TR514 UML Interface instance 1 Interface instance 2 Interface Creation Process

Opportunity to align IPR and copyright
Not the focus here but a critical aspect Challenges IPR modes Copyright agreements Use of open source Integration of standard processes with Open Source processes Will require updates to current agreements Revise the agreements so we can joint work and cross deliver

Conclusions We can act now to leverage the key significant opportunity to not duplicate effort Consistent tooling – we should ensure we maintain this One relatively obvious touch point between the two models identified (as per Core Proposal Sketch) Some areas identified where future joint working or collaboration would benefit There are significant challenges to joint work we need to be aware of and deal with Next steps whilst we are face to face Validate the functional model interrelationship Agree the approach Plan for first federated deliverable Use backup material to agree improved tooling and methodology alignment Agree how to proceed to find further areas for joint/collaborative federated/delegated work

THANK YOU

Background material UML Guidelines

UML Modeling Guidelines References
ETSI NFV UML Modeling Guidelines (v0.0.4, )  NFV-IFA015v010 ONF UML Modeling Guidelines (v1.1)  TR-514_v1.1_UML_Modeling_Guidelines (November 2015) Detailed Comparison (includes also MEF) 

UML Modeling Guidelines: Differences
ETSI NFV ONF Title ETSI has “NFV” in the title Object Classes multiple inheritance not supported Choice not supported Attributes Ordered not used Unique not used Read Only not used Default Value not used Type can be empty to indicate it would be specified in stage 3 valueRange not supported Title Neutral title Object Classes multiple inheritance supported Choice supported Attributes Ordered used Unique used Read Only used Default Value used Type must not be empty valueRange supported

UML Modeling Guidelines: Differences
ETSI NFV ONF Associations Non-navigable Associations not used Dependency Relationships not used Realization relationship not used Abstract not used Additional annotations on associations not supported Interfaces not used Operations not used Operation Parameters not used Notifications Inheritance not used C (Conditional) qualification not supported Associations Non-navigable Associations used Dependency Relationships used Realization relationship used Abstract used Additional annotations on associations supported Interfaces used Operations used Operation Parameters used Notifications Inheritance used C (Conditional) qualification supported

UML Modeling Guidelines
Questions Does ETSI NFV need Interfaces/Operations in future? Summary Common used artifact properties are applied in the same way Many differences exist due to ETSI NFV not using / not supporting artifact properties  Single “instance” of UML Modeling Guidelines could be used by both SDOs (with restrictions on ETSI NFV side)

Background material Papyrus Guidelines

Papyrus Guidelines References
ETSI NFV Papyrus Guidelines (v0.0.4, )  NFV-IFA015v010 ONF Papyrus Guidelines (v1.1)  TR-515_v1.1_Papyrus_Guidelines (November 2015) Detailed Comparison (includes also MEF) 

Papyrus Guidelines: Differences
ETSI NFV ONF Title contains “NFV” Software versions eclipse 4.5.0 Papyrus 1.1.0 Gendoc ? Model development in teams Contributions ? Data extraction from Papyrus Model Gendoc No installation guide Brief tutorial Papyrus tables? Stereotypes How to apply stereotypes How to change property values Importing RSA Models not described Title is SDO neutral Software versions eclipse (Mars SR1 or Mars.1) Papyrus 1.1.2 Gendoc 0.5.1 Model development in teams GitHub Model splitting during development Data extraction from Papyrus Model Gendoc Installation guide Extensive tutorial Papyrus tables explained Stereotypes How to apply not described How to change not described Importing RSA Models

Papyrus Guidelines Questions Software version management necessary?
Model and Profile in one project or separate projects? How to make the guidelines “SDO agnostic”? Summary No substantial difference Modeling in teams is different

Mapping Guidelines (driving tooling)
Background material Mapping Guidelines (driving tooling)

UML  YANG Mapping Guidelines and Tooling Simple Mapping Example

UML  YANG Mapping Guidelines and Tooling Simple Mapping Example
Mapping XMI  YANG Mapping within XMI

UML  YANG Mapping Guidelines and Tooling
Questions Which data schema language is of most importance to ETSI NFV? Does ETSI NFV plan to specify a complete UML model? Note: A complete UML model is prerequisite for tool mapping. Summary Just one of the many potential mappings of UML to interface data schema languages Describe how to map UML artifacts to YANG statements including: Object Classes, Attributes, Data Types, Associations Interfaces, Operations, Parameters, Notifications Not all properties of the UML artifacts are relevant to interface generation UML and YANG don’t easily match (UML is Object-Oriented supporting a rich meshing of artifacts, YANG is Tree-Oriented) Handling UML Recursion UML Conditional Pacs Intention to develop the Papyrus tooling to enable automatic generation of interface data schema from a UML model (including the generation of Yang) Project EAGLE: Open Source Community for UML  YANG Mapping First draft version of mapping tool already available

Interworking Tooling Proposal
Papyrus Work using the same (latest) version across the bodies Join the Papyrus community to assist progression Gendoc As per Papyrus UML-Yang Prune and Refactor tooling (not yet started) Git Branches and Forks usage Eagle Joint (not yet created) ONF Etc. Guidelines To be enhanced in the final version to provide key details

Background material Encapsulation

Encapsulation (animated)
NEs with ports ForwardingConstructs between ports in NEs Forms a network connection Which forms a Trail Which forms a Link This is a conceptual port. But all ports are conceptual! Note: Where the client support at each end of a multi-ended Trail is not the same the Link for each client is a subset of the Trail ForwardingConstruct.

Information Modelling rationale and approach
Background material Information Modelling rationale and approach

Information modelling
We all do at least informal information modelling in our day to day work Information modelling is simply the process of identifying, defining, consistently labelling and recording, from some viewpoint: The key concepts/things in the problem space The interrelationships between those key concepts/things When we analyse a problem we develop/use terminology and develop structure But there is always a challenge of colliding terms and apparently contradictory structure A key purpose of the ONF work is to provide “enabling constraints” and an appropriate degree of normalisation Enabling constraints prevent errors and unnecessary excursions Normalisation remove unnecessary variety, emphasises only inherent complexity, allows attention to be focussed on areas requiring exploration and improves interoperability The key is the right degree of normalisation so as to not stifle innovation but instead to enable it Formal Information Modelling is a technique that supports this purpose for things to be discussed in the solution especially over interfaces

Key considerations (1/5)
To what degree should we normalize each area/domain/concept? ONF focus has been the domain of networking and forwarding which is a mature domain Within that domain there is an opportunity to have deep normalization of concepts based upon ITU-T G.80x and the related TM Forum Converged Network model This model is within the Core Information Model There is very deep pattern normalization but still some terminology challenges In general the degree of normalization depends upon the maturity of the domain (see next slide) Which views are important to focus on? ONF focus has been on several views An interface oriented information architecture (G.805/800 work has inspired a more pure information architecture in TM Forum – this was liaised to ONF) that is network technology agnostic that provides The essential model of the problem space The rationale for various interface views A bridge between those interface views A generalized model of naming and identity Specific technology additions via a compositional extension approach A number of interface views for specific purposes where those views are derived from the Core Information Model In general the focus depends upon purpose but for standardisation initiatives where interfaces and reference points are the key interoperability output the above focus would appear to apply

Problem space view (abstraction)
Initial attempt Raw Reality Models Normalization Subsequent attempts Crude Initial Classification Models Architected Information Model Principle Pattern Architecture Domain Application Implementation Specific Code Problem space view (abstraction) Instance Example Mappings between models Normalisation opportunity Mature Classification Model Unnecessary variety decreases over time Increasing maturity with time To what degree should we normalize each area/domain/concept? Depends upon maturity of the area/domain/concept Depends upon relevance of the area/domain/concept Depends upon the lifecycle timeframe of the area/domain/concept Networking control/management is a highly relevant mature long lived domain and hence many things related to networking can be normalized Consider implications of Innovation Value Lifecycle stage Which views are important to focus on? Domain analysis Identifying the types of things in the overall domain Application specific Profiles of interface views etc for specific applications Various abstractions and representation of virtualisations Implementation neutral interface definitions per interface point Capturing the types of things as they should be expressed over particular interfaces Definition reflects solution viewpoint There are multiple interface points in the solution and therefore multiple solution views Definition may be oriented towards a particular representational form independent of specific implementation technology (e.g. Tabular style, Class-Association style) There are potentially several representational views of a particular solution view Allows for various implementation forms Implementation specific Captures implementation technology driven choices Example Capturing representations of instances (or partial instances) defined in any of the views Mappings including mappings between Various model views (e.g. the architecture view and the domain view) Various solution views (e.g. a nodal view and a network view) Various representational views (e.g. OF-Wire and the ONF ITU-T/TMF derived models) ONF models and models from other bodies/groups (e.g. an ONF model fragment to a DMTF model fragment) A specific solution and the model (e.g. a hackfest output and the preferred model) Architecture and patterns (only extensive in the most mature areas) Provides the rationale for choices and provides deep explanation of the problem space Resolves to only the inherent complexity

What approach should we use to develop & to apply the Information Model? ONF has used an agile architecture approach The model development takes on insights from the industry in the context of the SDN vision The deliverable includes both formalized and agreed model as well as preliminary and experimental parts The deliveries occur every 3 to 6 months The interface models are being developed by appropriate pruning and refactoring of the core model The interfaces are being validated via practical application with the results being fed back into the model evolution process In general an agile approach is recommended with the delivery including preliminary work to help decision making in forward looking development enabling intercepts to be developed and that deliver enhancements rapidly as they emerge (see next slide) What are the inputs to the modelling process? ONF has drawn from existing work in the industry, from SDN definitions and from SDN vision Drawing insights from ITU-T, TM Forum, OIF, MEF etc and collaborating in that work Appling the recursive control architecture and the need for abstraction of the network to client views Supporting Openflow needs Validating with interface use cases In general successful solutions emerge from development approaches that take advantage of a conjunction of theory and practical deployment experience. Clearly the model should be positioned to match the vision, architecture and interface needs

Agile architecture Recognise Insights Identify Use cases
Raw Reality Evaluate Standards and best practices Extract Insights Consider Vision Feedback Analysis Implementation Specific Domain Application Specific Mappings Example Architecture Patterns Prototyping Hackfests Plugfest Product Implementation “Fully” Rationalized Model capture Bounded by Practical constraints Scenario Validation What approach should we use to develop and apply the Information Model? An agile architecture approach blending rigor and insight with prototyping and practical application A pragmatically holistic approach balancing implications of longer term targets with short term needs What are the inputs to the modelling process? For networking it is the deep insights from other SDOs (there has been excellent normalisation work carried out already in ITU-T and TMF) along with inputs from practical deployments. The aim is to: Take advantage of past insight Account for, explore and develop model in areas that are genuinely new Take care to not reinvent Use cases and scenarios both current and longer term Vision, target scope and expectations How much should we formalize the activity of Information Modelling? Varies but in mature areas the activity can and should be formalized We should use the same approach in all areas where we think formal Information Modelling is beneficial The approach needs to be defined and documented as we progress Who uses the Information Model, when is it used and how? People developing further model build on/in the existing model People coding interfaces “compile” the model People doing prototypes and working in hackfests use interfaces “compiled” from the model and draw inspiration from the model Code may be generated directly from the model in some cases or may be constructed manually using the model as a guide for key structures etc depending upon the maturity and completeness of the model TM Forum have a program of model driven interface generation Who develops the Information Model, when and how? Various teams dealing with rationalisation of specific domains Evaluate examples Many overlaid asynchronous cycles at different phases with different lifecycle timeframes Focus on specific Current needs

How much should we formalize the activity of Information Modelling? ONF has chosen to strongly formalize information models for both the essential problem and the interfaces using UML It was concluded that complex meshy problems benefit from a strong model and that UML provides an appropriate environment To formalize the model it is necessary to use suitable tooling and in ONF Papyrus (free open source Eclipse platform tool) has been chosen. Incidentally this is also used in ITU-T and MEF Formalization means consistent application of UML and to ensure this guidelines have been developed In general it is recommended that complex areas (and most actually turn out to be) should be modelled with UML. The ONF guidelines provide a good basis for Information Modelling in any complex problem space Who develops the Information Model, when and how? ONF has chosen to set up an Information Modelling team to own the Core model on an on-going basis and to coordinate other modelling activities. There are also separate teams working on the interface models and on network technology enhancements Interface development uses a pruning and refactoring approach to develop interface that allows loose coupling between the Core team and the Interface development teams Modelling can occur in parallel in the various teams as each has been allocated a suitable branch in Git The model ownership has been clearly demarked In general it is recommended that an ownership approach that partitions the work to minimize dependencies is developed and for work on solutions similar to that of ONF an approach similar to that chosen in ONF is recommended

Who uses the Information Model, when is it used and how? In ONF the: Core model is used when advancing the understanding of the problem space. Development is done incrementally drawing from expertise and industry insight as well as from feedback from the interface work Core model is used when developing interface definitions As noted before by pruning and refactoring Interface models are used when developing interface schemas (e.g. JSON or Yang) Currently manual but to specific guidelines and aiming at automation In general it is important that the role of each aspect of the model and the relationships between each aspect is explained well and understood. It is expected that a similar approach would be valid for any other body developing interfaces How should we represent the formalized Information Model? The ONF model is provided in both a Papyrus UML model form and a document form. It is supported by pictorial representations in a domain specific language In general it is suspected that a similar approach of tooled model, documentation and supporting material would be applicable

How do we deal with variety, extensibility and change? The ONF model uses several approaches: The lifecycle of extensions/changes are indicated using the Lifecycle stereotypes Changes are coordinated by the Information Model team with the aim of maintaining stability and fostering convergence Variety is allowed between views where it is driven by external need but each view needs to relate to the common core model Network technology specific attributes are added in conditional packages by the network technology experts There is a recognition that there is unnecessary variety between network technologies and there is work underway to help remove that variety Coordination using git It should be noted that the model is an on-going development In general it is recommended that a similar approach with lifecycle stereotypes, model governance and partitioned ownership is followed How many Information Models? ONF essentially have one model made of many model modules, some of which are stand-alone and could be considered as models in their own right Hence it is both one model and many models… or all are fragments of one model In general a model is in many fragments. Where there are fragments the key is to coordinate/collaborate Apply consistent terminology defined in terms of structure of a model Collect domain experts to cover each area Be pragmatically holistic

Benefits of the core model
Help to reduce unnecessary variety in the industry A major and essentially removable cost is that of integration of solution elements that use unnecessarily different ways to represent what are essentially common concepts. Assist in sharing of the fundamental concepts to enable linkage between management and control environments Because of the linkage to traditional models the Core Model Fragment will enable relatively easy integration into existing management/control environments Assist driving mappings between OF and Service level abstractions (with the Core Model as an intermediary) improving coherence and enabling the necessary bridge between OF and Application models The key concepts in the Core Model Fragment can be related through defined specification classes in the Core Model Fragment to the TTPs (as principles behind the TTPs are similar to those behind the core model) Provide a formal base for the work of the NBI /Transport API teams improving ONF internal coherence Through this model assist in the rationalization across the industry of the representation of networks for the purpose of management-control

ONF presentations to ETSI NFV m-SDO IM/DM Workshop Proposal for way forward – Interconnecting ONF and NFV work January 2016.

Similar presentations

Presentation on theme: "ONF presentations to ETSI NFV m-SDO IM/DM Workshop Proposal for way forward – Interconnecting ONF and NFV work January 2016."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

ONF presentations to ETSI NFV m-SDO IM/DM Workshop Proposal for way forward – Interconnecting ONF and NFV work January 2016.

Similar presentations

Presentation on theme: "ONF presentations to ETSI NFV m-SDO IM/DM Workshop Proposal for way forward – Interconnecting ONF and NFV work January 2016."— Presentation transcript:

Similar presentations

About project

Feedback