Consideration of Modeling Evolution in ONAP Michela Bevilacqua Peter Wörndle and Tara Cummings 13 December , 2017 2 Contents Model Landscape Information Model(s) in ONAP and in SDOs Model Driven API Model Driven API: MEF experience Model
"Consideration of Modeling Evolution in ONAP" is the property of its rightful owner. Permission is granted to
download and print the materials on this website for personal, non-commercial use only, and to display it
on your personal computer provided you do not modify the materials and that you retain all copyright
notices contained in the materials. By downloading content from our website, you accept the terms of this
agreement.
Presentation Transcript
01
Consideration of Modeling Evolution in ONAP Michela Bevilacqua Peter Wörndle and Tara Cummings 13 December , 2017<br>
02
2 Contents Model Landscape
Information Model(s) in ONAP and in SDOs
Model Driven API
Model Driven API: MEF experience
Model Driven API: ETSI MANO
ONAP Modeling Evolution Priorities<br>
03
3 ONAP: a model driven platform for automation Service Providers aim to reduce service delivery time, automate resource/service lifecycle management, enable zero-touch.
Model driven implies a number of things
from modelling the resources and services under the control of ONAP.
via the modelling of the interfaces between the components that comprise ONAP
through to modelling “directives” that control all life-cycle aspects so as to enable zero-touch, fully automated operations.
Models are used to describe resources, service, products, the relationships and actions (processes, policy, operations) on these<br>
04
Model Driven Approach ONAP is not the only industry effort working with model based approaches, others are as well.
Models defined at design time can then be executed at run time
Models used to communicate functional capabilities for any architecture
Using models as the start of a toolchain to generate meta-data and/or working code is referred to as model-driven<br>
05
Model Driven API Model Driven API VNFD Resource and Service artifacts, DM Closed Loop directives BPMN flows DM Policy rules Analytic rules flows TOSCA descriptors<br>
06
Model Landscape in ONAP and alignment needs Model Landscape is already extensive in ONAP
Alignment needs… in ONAP
Common Information Model
Integrated and Consistent Management of the Models in ONAP
A service is not only a TOSCA descriptor for the deployment but need to address all the directives to control service operations across several ONAP components and even architectural boundaries
… around ONAP
Models traditionally provided by SDOs and open-source have been un-coordinated, creating near impossible integration scenarios
How ONAP can address this challenge?
Engage in SDO alignment
Address Interoperability: API key role in ONAP, Internal/external SDO touchpoints<br>
07
ONF: Modeling alignment need across SDOs<br>
08
ONF, MEF, TMF, ETSI-NFV, OASIS-TOSCA, and ITU-T have partnered to collaborate and define a common model-driven approach that advances interoperability
Open Information Modeling and Tooling led by IISOMI
More groups are joining the discussions…IETF, IEEE, OIF SDOs Modeling alignment<br>
09
Tool Chain UML YANG JSON xxx.uml xxx.yang UML YANG Mapping Validation Tree √ xored YANG Viewer xxx.json YANG JSON Mapping Swagger JSON API Documentation different<br>
10
IISOMI Guidelines<br>
11
IISOMI Model Driven API Methodology Models in UML with supporting documentation tool
ONF TR 512: Core Information Model, ONF TR 513: Common Information Model
Guidelines that promote normalized use of UML, shared tooling use and tool driven standardized language mappings
ONF TR 514: UML Modeling Guidelines, ONF TR 515: Papyrus Guidelines [maintained by IISOMI)
Tooling software that converts an appropriate UML model into an interface schema such as Yang, JSON
ONF TR 531: UML to YANG Mapping Guidelines [maintained by IISOMI)
IISOMI EAGLE-Open-Model-Profile-and-Tools [https://github.com/OpenNetworkingFoundation/EAGLE-Open-Model-Profile-and-Tools)
Yang Swagger JSON/RestConf Generation Tool is already available
https://github.com/OpenNetworkingFoundation/EAGLE-Open-Model-Profile-and-Tools/tree/ToolChain/UmlYangTools
Others like UML JSON, UML Swagger, UML TOSCA being discussed<br>
12
Model Driven API: MEF 17 Experience<br>
13
13 MEF 17 – LSO SOF TE PoC SOF-TE PoC demonstrates a working implementation of SOF sub-functional components and interface points defined by LSO in order to provide SOF with topology information.
SOF-TE demonstrates open software microservices of a number of SOF-sub components.
SOF sub-function Composer can leverage SOF-TE topology for cross-vendor SDN path computation. It can also be leveraged for service chaining in a hybrid network of SDN, NFV and legacy networks.
SOF-TE PoC includes:
Implementation of PRESTO to extract and “stitch” ICM layer topology into a Graph database.
Visualization of topology and connectivity services.
Alignment of MEF with ONF TAPI model.
Open source code developed in Python.<br>
14
14 MEF 17 LSO SOF-Te PoC: Focus on Model prospective Design First Approach for APIs
Model -> Swagger (Eagle tool generated)
Topology model defined in UML
Topology model defined in Swagger Specification
TAPI open source tools to convert UML -> YANG -> swagger
Swagger tools used for API codegen
Swagger generated server and client templates, as well as test cases
Implementation of swagger generated templates.
MEF and TAPI model alignment<br>
15
Model Driven - ETSI MANO experience 15<br>
16
ETSI Information model and specifications IFA xx Interface & Descriptor Requirements SOL xx Interface & Descriptor Specifications Update model based on agreed interface changes API and Descriptor specifications follow the IFA requirements Update IFA requirements to improve Interface implementation details Overall interface consistency checks across different reference points and documents UML TOSCA OpenAPI UML Other Organizations<br>
17
IM is a good tool to check consistency across paper specifications
IM is a good tool to create formal relationships also with technical work in other communities
Lose coupling between Stage 3 specifications, interface requirements and IM requires significant coordination efforts
Only few people contribute to the model as the model is not a mandatory part of the process, i.e. interface changes can be driven without a model update
Minor divergences and risk for additional divergence between the deliverables Experiences from the ETSI modeling approach<br>
18
Common Information Model
Integrated and Consistent Management of the Models
Engagement in the SDO alignment: Interoperability
Model driven Tools ONAP Modeling Evolution Priorities Key Take Away<br>
19
Common Information Model
Terminology
UML version of the CIM, CIM repo
WoW for :
CIM evolution:
input provided by different ONAP components, architecture team or others,
unique CIM backlog in a agile way.
CIM mapping to DMs in ONAP and retro-feedbacks ONAP Modeling Evolution Priorities Key Take Away<br>
20
Common Information Model
Integrated and Consistent Management of the Models
Engagement in the SDO alignment: Interoperability
Model driven Tools ONAP Modeling Evolution Priorities Key Take Away<br>
21
Common Information Model
Integrated and Consistent Management of the Models
Engagement in the SDO alignment: Interoperability
Define the touchpoints per SDO
External API Interoperability
Internal API interoperability, starting with standard touchpoints
Model driven Tools ONAP Modeling Evolution Priorities Key Take Away<br>
22
Common Information Model
Integrated and Consistent Management of the Models
Engagement in the SDO alignment: Interoperability
Model driven Tools
Improve TOSCA guidelines
Monitor and collaborate with industry initiatives about tool chains ONAP Modeling Evolution Priorities Key Take Away<br>
23
Common Information Model
Integrated and Consistent Management of the Models
Engagement in the SDO alignment: Interoperability
Model driven Tools ONAP Modeling Evolution Priorities Key Take Away<br>
