1. 11:00 – 12:00 Introduction to Open Info Modeling and Transport Config & Control
Presenters: Nigel Davis, Kam Lam, Lyndon Ong, Karthik Sethuraman, Bernd Zeuner, Andrea Mazzini

2. Agenda Overview of the projects and purpose TAPI detail
Drivers: Vision and trends
Aspects of the projects
Evolution of each area of work
TAPI detail
The model and UML – Yang tooling
Core model detail
The model and P&R tooling
Ongoing work

3. Overview

4. 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. a BP PCE with an Ericsson provisioning engine in a common 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

5. Aspects of the project Approach Elements of the projects
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

6. Information Model evolution

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

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

9. Interface Evolution OLD NEW
Reinvention of new models for every new use case
Focus on Spec development as the end goal
Use protocol stack vendors to implement and make changes Example: RSVP (1997)
NEW
Model-driven with common base model across use cases
Focus on model/software development with Specs following
Automated tools for mapping from model to implementation
Example: TAPI

10. ONF IM team Interface Vision
Assuming 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
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 ONF work activity mentioned earlier “Removal of the NE” will address this using insights gained in those various activities
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 (the controller model is under development)
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

11. OTCC Transport API Open Transport Configuration & Control Project
Subprojects:
Transport API (TAPI) – Karthik Sethuraman
Open Transport Information Modeling (OT IM) – Kam Lam
Wireless Transport (WT) – Giorgio Cazzaniga

12. TAPI Driver: TAPI as Transition Path to SDN
Multi-Domain/Multi-Vendor
Greenfield/Brownfield
Goal of integrated control
OSS
T-API
SDTN Controller
Common
abstraction
model
T-API
RESTCONF TAPI
RESTCONF TAPI
RESTCONF TAPI
RESTCONF TAPI
Vendor A - NMS
Vendor B - NMS
Vendor C - NMS
Vendor D - NMS
Proprietary
configuration
Slide courtesy of Telefonica (OFC 2017)

13. What Can TAPI Do For CORD?
Many Operators With This Concern
Many operators have expressed interest in TAPI testing
Some built TAPI Orchestrators, e.g., China Mobile, China Telecom/Unicom, SKT
Potentially larger community of CORD Users
Large Community of Involved Vendors
Carriers can drive vendor implementation and deployment
Testing has been done with, e.g., ADVA, Ciena, Coriant, Fiberhome, Huawei, Infinera, ...
CORD potentially can extend to broader range of controllable systems
Power of Standards and Commonality
Single API development can address many vendors and carriers
Adaptability of CORD to different carrier environments
Adds to scope of CORD interconnection and XOS orchestration

14. Transport API 2.0 FunctionsNE
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)

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

16. UML Model (TAPI SDK)

17. TAPI UML, YANG and Swagger Mapping

18. TAPI Snowmass Reference Implementation (TAPI SDK)
TAPI Client (Python)
Transport API
Topology Service
Connectivity Service
OAM Service
Path Computation Service
Virtual Network Service
Notification Service
ONOS NBI Mapper
TAPI Server Backend
ODL TAPI Plug-In
TAPI Server (Python)
Network Domain (mininet)
Network Domain (mininet)
Plug-in of TAPI-based MEF NRP API
Simple mapping in the reference Implementation
TAPI Reference Network DB (JSON)

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

20. TAPI in MEF OpenLSO/OpenCS Projects
MEF-NRP (MEF-NRM + TAPI)

21. OIF TAPI 1.0 Testing (2016 OIF Demo)
Traffgen
Optical Controller
Provisioning app
MD Orchestrator
Remote MD Orchestrator
Other Labs:
China Telecom
China Unicom
SKT
Verizon
Other Vendors:
Fiberhome
Huawei
Juniper
ZTE
TAPI
Telefonica Lab

22. OIF TAPI 2.0 2018 Interop Test In planning by OIF
Interop testing of TAPI 2.0 for targeted Use Cases
Carrier survey found several interested in participation + highest priority Use Cases
Vendor survey in progress
Currently open to participation, will close in January after contracts/NDAs signed
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
2017
2018
Tech Spec Start
Contract/NDA
Test start
Test end
Readouts
4Q OIF
ONF
1Q OIF
OFC
ONS
2QOIF
BTE
NGON
3QOIF
ECOC
L123

23. OTCC Information Modeling Sub-Project - Spec Model Work
Kam Lam, Fiberhome

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

25. OT-IM sub-project How: Spec model approach (TR-512.7)
ONF OTCC TAPI
ONF OIMT
ONF Core Information Model
(TR-512 / G.7711)
Pruning & Refactoring (P&R)
TAPI UML Information Model
ONF Technology Specification Models
How: Spec model approach (TR-512.7)
What: Technology IMs
OTIM sub-project:
In OTCC, the OTIM sub-project has as its goal to facilitate knowledge transfer of the base technology specifications (such as the ITU-T Recommendations for Media, OTN, Ethernet, MPLS-TP, Synchronization, Resilience/Protection, etc.) to be applied by the OTCC interface sub-projects such as TAPI and WT.
OTN
(G.874.1)
ETH
(G.8052)
MPLS-TP
(G.8152)
SYNC
(G.sync-mgmt)
Media
(G.media-mgmt)
ITU-T SG15
Technology IMs

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

27. TR-512.7 Figure 4-21 Sketch of Ethernet OAM spec case
The ITU-T models have a different granularity of TP modelling where the LP is modelled as several separate equal parts (TTP, CTP etc.). The ONF specification model is at a finer granularity than the ITU-T model.

28. TR-512.7 Figure 4-22 Sketch of Ethernet OAM spec case in context of LP Case and LP Spec model

29. ODU spec

30. TAPI and MEF

31. MEF defines the Lifecycle Service Orchestration Reference Architecture
NBI of SDN Controller
of WAN Controller
of NFV Orchestrator
of NMS, Subnetwork Managers
Public

32. MEF defines the Network Resource Model
The MEF NRM scope is the definition of a generic Network Resource Management Information Model, applicable to LSO RA PRESTO IRP, for the management of the Network Infrastructure, through SDN Controllers, WAN Controllers, OTN Subnetwork Managers, and other legacy Network Management Systems.
The NRM IM models the management features defined by MEF Service Information Model (MEF 7.3) in a resource oriented view at network level, i.e. potentially spanning more technology domains supporting the service.
NRM is a static model, specified in Papyrus UML, mainly composed by specification classes which augment ONF TAPI entity classes.
NRM is input to MEF Network Resource Provisioning Project (NRP), which adds operations and automatically generates YANG modules from Papyrus UML definitions
Public

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

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

35. End-to-End Orchestrated Connectivity Service
managed object classes at MEF Service level
ONF TAPI managed object classes
MEF NRM managed object classes augmenting TAPI
EVC (the end-to-end CarrierEthernetService)
OVC
OVC
MEF NRM Class
ConnectivityService
ConnectivityService
ConnectivityService
Connection
Connection
Connection
UNI
Node
UNI
Node
Node
E-NNI
MEF NRM Class
SIP
SIP
I-NNI-N
I-NNI-N
ServiceInterfacePoint
CSEP
CSEP
ServiceInterfacePoint
SIP
ServiceInterfacePoint
ConnectivityServiceEndPoint
NEP
NEP
CSEP
CSEP
ConnectivityServiceEndPoint
NodeEdgePoint
CEP
CEP
NEP
CEP
NodeEdgePoint
ConnectionEndPoint
CEP
NEP
ConnectionEndPoint
MEF NRM Class
MEF NRM Class
MEF NRM Class
Public

36. OIMT Core Model detail
Including P&R

37. Core model and the Pruning &Refactoring tooling
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 latest version is V1.3
The core model is an interconnected set of canonical models dealing with:
Forwarding, Termination, Topology and Resilience
Physical (i.e., can be measured with a ruler)
Control Functionality
Advanced Operation Patterns
Generalized Processing
Naming and identity
State
Extension via the Specification approach
The core model defines the domain
It is intentionally devoid of implementation specific details (related to interface encoding)
It is intentionally devoid of forwarding technology details (related to the network technology such as IP)
To construct an interface model 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 exercise
Tooling is being developed to support the process (see Science Fair)
To add forwarding technology details the technology models from ITU-T etc are Pruned & Refactored to form augmenting specifications
The same tooling applies to this process

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

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

40. Forwarding, Termination and Topology
From TR-512.4

41. Resilience
From TR-512.5

42. Physical
From TR-512.6

43. Emergent behavior
From TR-512.6

44. The Spec Approach
From TR-512.7

45. The control model
From TR-512.8

46. Processing Construct Model
From TR

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

48. General Operations Patterns
From TR

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

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

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

52. Ongoing work

53. 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 specification mechanism 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

54. 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, TOSCA
Strengthening the model
Relating IETF and ONF work
Enhancing the Model Structure