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

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

Overview

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

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

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

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

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

OTCC Transport API Open Transport Configuration & Control Project https://wiki.opennetworking.org/pages/viewpage.action?pageId=259325960 Subprojects: Transport API (TAPI) – Karthik Sethuraman Open Transport Information Modeling (OT IM) – Kam Lam Wireless Transport (WT) – Giorgio Cazzaniga

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)

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

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)

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)

TAPI UML, YANG and Swagger Mapping

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)

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 in MEF OpenLSO/OpenCS Projects MEF-NRP (MEF-NRM + TAPI)

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

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

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

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

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

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

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.

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

ODU spec

TAPI and MEF

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

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

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

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

OIMT Core Model detail Including P&R

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

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

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

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

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

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

Pruning & refactoring Tooling is currently prototype … "https://registry.npmjs.org/xmlbuilder/-/xmlbuilder-8.2.2.tgz" }, "maintainers": [ { "name": "oozcitak", "email": "oozcitak@gmail.com" } ], "_npmOperationalInternal": { "host": "packages-12-west.internal.npmjs.com", "tmp": "tmp/xmlbuilder-8.2.2.tgz_1460102388901_ 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 work

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