TAPI Overview* Karthik Sethuraman, NEC May 5, 2019 *animated.

TAPI Overview* Karthik Sethuraman, NEC May 5, 2019 *animated

Introduction & Overview
ONF TAPI Introduction & Overview

Transport API – Simple Problem Statement
Network Orchestrator APP Open Standard T-API ONOS APIs ODL APIs Proprietary APIs ONOS ODL Proprietary

ONF Transport API (TAPI): Functional Architecture
Application SDN Controller NE NE NE NE Transport API or Other NBIs Topology Service Connectivity Service OAM Service Path Computation Service Virtual Network Service Notification Service Shared Network Information Context Transport API or Other SBIs Network Elements SDN Controller NE NE NE

TAPI RI - Prototyping Controller-agnostic API
TAPI Client (Python) Transport API Topology Service Connectivity Service OAM Service Path Computation Service Virtual Network Service Notification Service ONOS NBI Mapper ODL NBI Mapper TAPI Server Backend TAPI Server (Python) Network Domain (ODTN) Network Domain (UniMgr) TAPI Reference Network DB (JSON) Available / Shortly Available

OIF Transport API Interop Demo (2014, 2016, 2018)
OSS/App/Orchestrator Test Carriers TAPI Agent Multi-Domain Controller Transport API Common Abstraction model TAPI Agent Multi-Domain Controller Transport API TAPI Agent TAPI Agent TAPI Agent Technology, Vendor Specific models Domain Controller Domain Controller Domain Controller Test Vendors

MEF 3.0 Optical Transport Implementation Project

ONF ODTN (Open Disaggregated Transport) Architectures
With OLS Controller (Current Ph 1.5) TAPI ONOS TAPI OLS Controller Has topology OpenConfig OpenConfig TRN MUX WSS AMP WSS MUX TRN Open Line System (OLS) Without OLS Controller (Future Ph 2.0) TAPI ONOS TBD OpenConfig OpenConfig TRN MUX WSS AMP WSS MUX TRN Open Disaggregated System

Confluence of Standards and Open Source
ONF OTCC TAPI FRS Use cases & Requirements TAPI UML Information Model ONF OIMT Open Model Profile ONF Core Information Model UML-YANG Generation Tool TAPI YANG Data Schema ONF Technology Specification Models YANG-OpenAPI Generation Tool ONF TAPI SDK OpenAPI (RESTConf) Schema Python Stub Generation Tool Code OTN (ITU-T G.874.1) ETH (ITU-T G.8052) Photonic (ITU-T G.807.1*) EAGLE Modeling Tools Python Reference Implementation Technology Generic Core Model (ITU-T G.7711) ITU-T SG15 MEF MEF 3.0 Implementations OIF Interop Implementations NRM NRP Optical Transport Packet WAN Multi-carrier T-SDN Interop Implementation Agreements & Certification MEF Models

TAPI Feature Set Topology Service Node Constraints
TAPI SDK 1.x (H2 2016) TAPI SDK 2.x (H2 2018) Topology Service Logical (abstract/virtual) Topology, Node, Link & Edge-Point (Across al layers) Connectivity Service Retrieve & Request P2P, P2MP, MP2MP connectivity (Across all layers) Path Computation Service Request for Computation & Optimization of paths Virtual Network Service Create, Update, Delete Virtual Network topologies Notification Framework Subscription and filtering Autonomous/Push mechanism Node Constraints Ability to specify connectivity/blocking constraints Resilience & Protection Multi-layer, Multi-Domain OAM/Monitoring/PM Consistent Multi-layer abstraction and model – L0-L2 Alarm/TCA/Counter Equipment Inventory Equipment, Holders (Rack/Shelf, etc), Connectors, Fiber, etc Multi-Technology Photonic Media spec models ETH & OTN enhancements TR-527 FRD 1.0 – June 2016 SDK 1.0 – September 2016

Transport API Summary General Benefits TAPI Next Steps
Provides functions necessary for multi-domain orchestration Topology view and abstraction Connectivity establishment Hierarchical Abstraction Migration path for legacy systems Different types of topology abstraction Abstract Node (single, edge, sliced, etc) Abstract Link Complete (1-to-1) internal topology Supports multiple transport technologies Packet Transport (Ethernet, MPLS-TP) Optical Transport (OTN, DWDM) Interoperability on North-South Orchestrator/Controller interface TAPI 2.x fixes & enhancements Photonic Model updates based on ODTN feedback ETH, L1 & OAM alignment due to interaction with MEF (NRM-OAM/SOAM, L1) projects Equipment (Physical) Inventory TAPI 3.0 Items (Current) Further tune the application of component-system pattern for Topology & Connectivity Incl. IETF Network/Topology Alignment Topology Pacs/Datatypes (Capacity, Cost, Latency, Risk parameters) enhancements Routing and Resilience Constraint enhancements YANG & OpenAPI/RESTConf Enhancements RPCs v/s Action v/s REST Constraints (WHEN, MUST, etc)

Topology & Forwarding Concepts with an Photonic Example
ONF TAPI Topology & Forwarding Concepts with an Photonic Example

Simple Physical Network Example to illustrate T-API
UNI1 (200G) NNI1 (200G) TPD1 RDM1 UNI3 (200G) RDM3 RDM4 RDM5 TPD3 NNI3 (400G) TPD2 RDM2 UNI4 (200G) UNI2 (200G) NNI2 (200G) OLS Domain TPD Domain Abbreviations TPD – Transponder Node RDM – ROADM Node UNI – User-Network Interface NNI – Network-Network Interface OTSi – Optical Tributary Signal OTSiA – OTSi Assembly MC – Media Channel MCA – Media Channel Assembly Node Edge Point (Network Internal) Node Edge Point (Network Edge) Service Interface Point Logical Termination Points shown Connectivity Service End Point A Network Provider with 2 operator domains : Transponder domain OLS/ROADM domain And with two Customers (Red and Green) connected to Transponders No Switching on TPD Nodes - DSRs are mapped into ODU into OTSi Only Photonic switching assumed on ROADMs

Example T-API Contexts from the TPD Domain Controller Perspective
(based on ONF Architecture v1.1) Client Application RED Client Controller GREEN TPD Controller Admin APP Blue Resource Group Resource Group Client TAPI TAPI TAPI Customer Context RED Customer Context GREEN Admin Context BLUE.Admin Resource Group Resource Group Resource Group Server TAPI Provider Internal Context Resource Groups TAPI Provider SDN Controller Orchestration / Virtualization Other Admin Interfaces Client Device Context TPD1 Device Context TPD2 Device Context TPD3 Controller Context OLS TPD-1 TPD2 TPD3 OLS Server

Example 1: Hierarchical TAPI Control Domains & Abstracted OLS Topology
Customer(s) view TAPI Context-R TAPI Context-G Transponder Domain Controller UNI 1 UNI 3 UNI2 UNI 4 Abstraction & Orchestration Network Provider View UNI1 UNI2 TPD3 TPD1 TPD2 TPD Domain UNI4 UNI3 NNI1 NNI2 NNI3 OLS Domain OLS Node OLS Domain Controller OLS TAPI Context NNI 1 NNI 2 NNI 3 Abstraction & Orchestration OLS Operator View Node Edge Point (Network Internal) Node Edge Point (Network Edge) Service Interface Point Logical Termination Points shown Connectivity Service End Point Abbreviations TPD – Transponder Node RDM – ROADM Node UNI – User-Network Interface NNI – Network-Network Interface OTSi – Optical Tributary Signal OTSiA – OTSi Assembly MC – Media Channel MCA – Media Channel Assembly RDM2 RDM1 RDM4 RDM3 RDM5 OLS Domain NNI2 NNI1 NNI3

Example 1: E2E Connectivity Request Flow (Omnipotent view)
DSR Connectivity Service 1 OTSi-MCA Connectivity Service 1 DSR1 100G OTSiA1 UNI1 TPD1 NNI1 RDM1 UNI3 OTSi 1-1 OTSi-MC1 RDM3 RDM4 RDM5 NNI3 TPD3 OTSi 1-2 OTSi-MC2 TPD2 RDM2 OTSiA2 OTSi 2-1 OTSi-MC3 OTSi 2-2 OTSi-MC4 DSR2 100G UNI4 UNI2 NNI2 OLS Domain TPD Domain OTSi-MCA Connectivity Service 2 DSR Connectivity Service 2 Abbreviations TPD – Transponder Node RDM – ROADM Node UNI – User-Network Interface NNI – Network-Network Interface OTSi – Optical Tributary Signal OTSiA – OTSi Assembly MC – Media Channel MCA – Media Channel Assembly Node Edge Point (Network Internal) Node Edge Point (Network Edge) Service Interface Point Logical Termination Points shown Connectivity Service End Point

Example 1: E2E Connectivity Request Flow (actual TAPI Contexts view)
Customer(s) view TAPI Context-G UNI 1 UNI 3 TAPI Context-R UNI2 UNI 4 DSR Connectivity Service 1 DSR Connectivity Service 2 Network Provider View DSR Connectivity Service 1 Transponder Domain Controller DSR Connectivity Service 2 UNI1 UNI2 TPD3 TPD1 TPD2 TPD Domain UNI4 UNI3 NNI1 NNI2 NNI3 OLS Domain OLS Node OLS TAPI Context NNI 1 NNI 2 NNI 3 Photonic Connectivity Service 1 OLS Operator View Photonic Connectivity Service 2 Photonic Connectivity Service 1 Node Edge Point (Network Internal) Node Edge Point (Network Edge) Service Interface Point Logical Termination Points shown Connectivity Service End Point Photonic Connectivity Service 2 RDM2 RDM1 RDM4 RDM3 RDM5 OLS Domain NNI2 NNI1

Example 1: Connectivity Request Flow /w provisioned Connectivity Resources
Customer(s) view TAPI Context-G UNI 1 UNI 3 TAPI Context-R UNI2 UNI 4 DSR Connectivity Service 1 DSR Connectivity Service 2 Network Provider View DSR Connectivity Service 1 DSR Connectivity Service 2 Transponder Domain Controller UNI1 UNI2 TPD3 TPD1 TPD2 UNI4 UNI3 DSR1 100G OTSiA1 OTSi 1-1 NNI1 NNI2 NNI3 OLS Domain OLS Node OTSi-MC1 OTSi 1-2 OTSi-MC2 OTSiA2 OTSi 2-1 OTSi-MC3 OTSi 2-2 OTSi-MC4 DSR2 100G OLS TAPI Context NNI 1 NNI 2 NNI 3 Photonic Connectivity Service 1 OLS Operator View Photonic Connectivity Service 2 Photonic Connectivity Service 1 Node Edge Point (Network Internal) Node Edge Point (Network Edge) Service Interface Point Logical Termination Points shown Connectivity Service End Point Photonic Connectivity Service 2 RDM2 RDM1 RDM4 RDM3 RDM5 OLS Domain NNI2 NNI1 OTSi-MC1 OTSi-MC2 OTSi-MC3 OTSi-MC4

Example 2: Alternate TAPI Control Domains – Orchestration architecture
Customer(s) view TAPI Context-R TAPI Context-G Service Orchestrator UNI 1 UNI 3 UNI2 UNI 4 Abstraction & Orchestration Network Provider View TPD3 TPD1 TPD2 UNI3 UNI4 UNI1 UNI2 RDM2 RDM1 RDM4 RDM3 RDM5 NNI1 NNI2 NNI3 TPD Domain Controller TPD TAPI Context NNI 1 NNI 2 NNI 3 Abstraction & Orchestration UNI 1 UNI 2 UNI 3 UNI 4 OLS Domain Controller OLS TAPI Context NNI 1 NNI 3 NNI 2 Abstraction & Orchestration Operators View TPD3 UNI4 UNI3 UNI1 UNI2 TPD1 TPD2 NNI2 TPD Domain NNI3 NNI1 RDM2 RDM1 RDM4 RDM3 RDM5 OLS Domain NNI2 NNI1 NNI3

Example 2: Alternate TAPI Control Domains – E2E Connectivity Request Flow
Customer(s) view TAPI Context-G UNI 1 UNI 3 TAPI Context-R UNI2 UNI 4 DSR Connectivity Service 1 DSR Connectivity Service 2 Network Provider View TPD3 TPD1 TPD2 UNI3 UNI4 UNI1 UNI2 RDM2 RDM1 RDM4 RDM3 RDM5 NNI1 NNI2 NNI3 TPD TAPI Context UNI 1 NNI 1 UNI 2 NNI 2 NNI 3 UNI 3 UNI 4 DSR CS 1-1 DSR CS 1-2 DSR CS 2-1 DSR CS 2-2 Operators View OLS TAPI Context NNI 1 NNI 2 NNI 3 Photonic Connectivity Service 1 TPD3 UNI4 UNI3 UNI1 UNI2 TPD1 TPD2 NNI2 TPD Domain NNI3 NNI1 Photonic Connectivity Service 2 RDM2 RDM1 RDM4 RDM3 RDM5 OLS Domain NNI2 NNI1 NNI3

Topology “Abstraction” & Forwarding Concepts with ETH-over-OTN Example
ONF TAPI Topology “Abstraction” & Forwarding Concepts with ETH-over-OTN Example

Recursive Node & Topology aspects of TAPI Forwarding Domain
TAPI Context  Network Domain View Node aspect of the FD Topology aspect of the FD Observer Link Mapping A FD (Node) 01.1 LTP (Service Interface Point) A FD (Topology) Context appears as a Topology of one Node B and SIPs (off-network relationships/Links) 01 LTP (Node Edge Point) B B A A A.1 Node-B appears a Topology of Nodes A & C and Link A-C 01 11 A.4 13 12 17 05 A.3 19 01.1 18 02.1 14 A.5 20 01.n A.2 16 C C 02.n 15 03 02 04 Node-C appears as a Topology with NULL elements Node-A appears a Topology of Nodes A.1 - A.5 & Links between them

Recursive Node & Topology aspects of Forwarding Domain
Top-most Topology B Topology B A C Topology A A.1 A.4 Topology C A.3 A.2 A.5 A.1.1 A.1.3 A.1.2 Topology A.1 A.2.1 Topology A.2 A.2.2 A.2.3

Recursive Connectivity decomposition of TAPI Forwarding Construct
TAPI Context  Network Domain View Node aspect of the FD Topology aspect of the FD Observer Link Mapping A FD (Node) 01.1 LTP (Service Interface Point) A FD (Topology) LTP (Node Edge Point) Context appears as a Topology of one Node B and a Connection (01-02) 01 B B A A A.1 Node-B appears a Topology of Nodes A & C and Link A-C. Connection (01-02) decomposes into 2 lower-level Connections (01-04) & (03-02) 01 11 A.4 13 12 17 05 A.3 19 01.1 18 02.1 14 01.n A.2 A.5 20 16 C 02.n 15 03 02 04 Node-A appears a Topology of Nodes A.1 - A.5 & Connection (01-04) further decomposes into 3 lowest-level connections (01-12), (17-18) & (20, 04)

Simple Physical Network Example to illustrate T-API
Node Edge Point (Network Internal) Node Edge Point (Network Edge) Service Interface Point Logical Termination Points CE2 CE5 CE – Customer Edge PE – Provider Edge P - Provider UNI PE2 CE3 CE1 PE1 PE3 CE4 CE6 P4 UNI UNI A Network Provider (Blue) with two Customers (Red and Green) All UNI interfaces are ETH (e.g. 10GE), I-NNI interfaces are OTU (e.g. 100G OTN) All PE-NE are ODU/ETH switch capable, while P-NE is only ODU switch capable

T-API Contexts for the Simple Network Example
(based on ONF Architecture v1.1) Application RED SDN Controller GREEEN Admin APP Blue Resource Group Resource Group Client TAPI TAPI TAPI Shared Context RED Shared Context GREEN Shared Context BLUE.Admin Resource Group Resource Group Resource Group Server Provider Internal Context Resource Groups Provider SDN Controller Orchestration / Virtualization Other Admin Interfaces Client Server Context PE1 Server Context PE2 Server Context PE3 Server Context P Resource Group - PE1 Resource Group - PE2 Resource Group - PE3 Resource Group - P Server

T-API Shared Context Shared Context – entire context for the T-API Provider & Client interaction Context for Topology, Connectivity, Path Computation, Virtual Network, Notification, Equipment Inventory Service APIs Defined by set of Service-End-Points Includes one or more top-level Topologies within the shared context that are Either statically assigned by the Provider Or dynamically created by the Client using Virtual Network Service API A Node can encompass an internal Topology and be recursively decomposed into its lower-level Nodes and Links Provides scope for control (create/update/delete) of Connections (and its Connection-End-Points) using Connectivity Service APIs Utilizes one or more shared namespace Setup & requirements of shared context depends on offline negotiation/agreement between TAPI provider & its client Determines type and degree of abstraction that is provided Must not be confused with TAPI provider’s or client’s internal context

TAPI Resource : Topology Constructs
(API) Context – defines the scope of control and naming that a particular T-API provider or its client application has with respect to the information exchanged over the interface. This Context is shared between the API provider and its client and determines the makeup of the network resource abstractions over which the API operates. Topology – representation of the transparent topological-aspects of a Forwarding-Domain (FD) Topology describes the underlying topological network of Nodes and Links that enable the forwarding function provided by the FD. Topology may be statically assigned by an TAPI Provider – is referenced by (belongs to) Network Topology Service Or dynamically created by an TAPI Client – is referenced by (belongs to) Virtual Network Service Node – representation of the opaque forwarding-aspects of the Forwarding-Domain (FD) Node describes the edge ports of the FD (Node-Edge-Point) and the forwarding capabilities between those edge ports. Link – representation of the effective adjacency between two or more associated Nodes in a Topology. Node and Link express their characteristics via the topology-pacs Capacity, Risk, Cost, Latency, Validation, Transition Node-Edge-Point has one or more Layer-Protocols TAPI currently supports following Layer-Protocols: OTSi, ODU, OTU, ETH, ETY & MPLS-TP

Example Topology Abstractions in a Shared Context
Red Shared Context Node Edge Point (NW Internal) Service Interface Point Node Edge Point (NW Edge) Link Topology Node Transitional Link Mapping P PE1 PE2 PE3 Blue Internal Context G1 G2 G3 Green Shared Context

Recursive Topology Decomposition within Context
Red Shared Context Node Edge Point (NW Internal) Service Interface Point Node Edge Point (NW Edge) Link Mapping Topology Node Red Shared Context R1 R1.2 R1.1 R1.3

Topology & Node Decomposition
TAPI supports Topology decomposition which allows for information hiding and abstraction and allows to recursively decompose a top-level Topology down to the lowest-level Nodes and Links TAPI supports multiple top-level Topologies which can be used to model many abstract/virtual topological representations of the Provider’s view of its owned/internal “actual” Network Topology One of the exposed top-level Topology could be the provider’s own internal Topology (1-1 mapping) TAPI does NOT provide (yet) the interfaces to map the relationship between top-level Topologies Just providing a relationship between 2 or more Topologies is pretty meaningless other than in the complete containment case (Topology contains lower-level Topology). Inter Topology view relationship is best represented by exposing the mapping between the NodeEdgePoints in different Topologies. In TAPI, Node is simply an opaque view of a Topology wherein just the edge ports (NodeEdgePoints) on the boundary are exposed. Hence it can be recursively be decomposed over the API to expose its “internal” Topology, if allowed by the policies. The lowest-level Node is simply just an abstraction wherein the policy does not allow exposure of its internal details - it could be that a Node cannot be further decomposed due to physical constraints (Switch Matrix) So in TAPI, TopologycontainsTopologies is represented as TopologycontainsNodes containsTopology

TAPI Resource : Forwarding Constructs
Connectivity Service - represents an “intent-like” request for connectivity between two or more ServiceEndPoints. Service is a container for connectivity request details and is distinct from Connection that realizes the request They refer to different aspects of information exchanged over T-API interface, but within provider they could be modeled by the same instance if there is one-to-one mapping. Connection - represents an enabled (provisioned) potential for forwarding (including all circuit and packet forms) between two or more Node-Edge-Points of a Node. Connection is a container for provisioned connectivity that tracks the state of the allocated resources and is distinct from the connectivity Service request. Connection can be recursively decomposed into lower-level connections Route - represents the path of a Connection through the lower-level Nodes in the underlying Topology Route is described as a list of ConnectionEndPoints.

Client1 (Red) Shared Context: with empty Topology
Shared Context defined by the set of ServiceEndPoints No Topology exposed - Retrieving topology will return empty ConnectivityService can be requested between ServiceInterfacePoints Client provides input ConnectivityConstraints – Capacity/BW is the only required input Associated Connection representing network resources is created/returned to Client Node Edge Point (Internal) Node Edge Point (Edge) Service End Point Link Transitional Link Mapping Topology Node Connection EndPoint Connection Service Interface Point Shared Context Connection Connectivity Service

Client-1 (Red) Shared Context: Single Node Topology
Single Node abstraction example Node and its NodeEdgePoints provide some approximation of the network capabilities ConnectivityService can be requested between ServiceInterfacePoints Connections appear as cross-connections across node, no visibility of underlying route Shared Context Node Edge Point (Internal) Node Edge Point (Edge) Service End Point Link Transitional Link Mapping Topology Node Connection EndPoint Connection Service Interface Point Connection Connectivity Service ETH

Client 2 (Green) Shared Context: Multi-Node Topology
Multiple Nodes (PEs) Topology example Node and its NodeEdgePoints provide reasonable information of their capabilities ConnectivityService can be requested between ServiceInterfacePoints Top-level Connection is recursively decomposed into lower-level Connections, 1 per Node Connection route can be traced over the exposed Topology Node Edge Point (Internal) Node Edge Point (Edge) Service End Point Link Transitional Link Mapping Topology Node Connection EndPoint Connection Service Interface Point Shared Context PE2 ETH Connection PE1 PE3 Connectivity Service

Admin (Blue) Shared Context: Multi-layer Topology
Each physical device is represented by a separate Node per supported layer (ETH & ODU) Node and its NodeEdgePoints provide information of their capabilities at that layer Transitional Links interconnect the NodeEdgePoints at different layers Top-level Connection is recursively decomposed into lower-level Connections, 1 per Node Top-level Connections at lower (server) layer result in Links at upper (client) layer Node Edge Point (Internal) Node Edge Point (Edge) Service End Point Link Transitional Link Mapping Topology Node Connection EndPoint Connection Service Interface Point TAPI Context PE2e 1 2 PE1e PE3e 3 PE2o 2 1 PE1o PE3o P4o 3

Client-1 (Green) Shared Context: Virtual Network
Client requests VN Topology between ServiceInterfacePoints within its Shared Context Provider creates a Topology based on the input Topology constraints (e.g. traffic matrix) Single Node or Multiple Node abstraction of Topology Node and its NodeEdgePoints provide some approximation of the network capabilities ConnectivityService can be requested between ServiceInterfacePoints Node Edge Point (Internal) Node Edge Point (Edge) Service End Point Link Transitional Link Mapping Topology Node Connection EndPoint Connection Service Interface Point Shared Context PE2 VN Topology Service PE1 PE3 Connectivity Service ETH

ONF TAPI Multi-domain Topology “Abstraction” Concepts & Hierarchical Control Example

TAPI Reference Hierarchical Control Example
3 Provider admin domains (Blue) 2 Customer domains (Red and Green) All UNI interfaces are ETH (e.g. 10GE) NNI interfaces are OTU (e.g. 100G OTN) All UNI devices are ODU+ETH switch capable Internal devices are only ODU switch capable 1.G TAPI Context-G 10.G 2.R TAPI Context-R 9.R Node Edge Point (Network Internal) 1 Service Interface Point Node Edge Point (Network Edge) 3.G 11.G 4.R 12.R Multi-Domain Controller Abstraction & Orchestration 1.D1 TAPI Context-1 5.D1 5.D2 TAPI Context-2 7.D2 7.D3 TAPI Context-3 11.D3 2.D1 6.D1 6.D2 8.D2 8.D3 12.D3 3.D1 4.D1 9.D3 10.D3 Domain-1 Controller Domain-2 Controller Domain-3 Controller Abstraction & Orchestration Abstraction & Orchestration Abstraction & Orchestration Domain-1 Domain-2 Domain-3 G-1 D1-4 D3-4 G-2 1 5 D2-1 D2-3 7 11 D1-1 D3-1 D1-3 D3-3 R-1 2 12 R-2 D1-2 6 D2-2 8 D3-2 UNI UNI 3 4 NNI NNI 9 10 UNI UNI G-3 R-3 R-4 G-4

Domain-1 TAPI Context Topology
This slide depicts the complete Topology exposed by domain-controller 1 to the multi-domain-controller* It is assumed that the exposed TAPI-Context Topology is a 2 Node abstraction (1 per layer) of domain-controller ‘s network It is assumed that no Connectivity has been setup in the entire domain and this is the initial Topology view Node Edge Point (Internal) Node Edge Point (Edge) Service End Point Link Transitional Link Mapping Topology Node Connection EndPoint Connection Service Interface Point TAPI Context-1 Physical Box View (internal) D1 Domain-1 1.D1 D1-e UNI NNI 2.D1 D1-4 G-1 3.D1 1 D1-1 D1-3 5 4.D1 R-1 2 D1-2 6 D1-o UNI 3 4 5.D1 G-3 R-3 6.D1 *The multi-domain controller may have to invoke more than one retrieval API operation to get this view

This slide depicts the complete Topology exposed by domain-controller 2 to the multi-domain-controller* It is assumed that the exposed TAPI Context Topology contains one Node per device in the domain controllers' network. It is assumed that no Connectivity has been setup in the entire domain and this is the initial Topology view Node Edge Point (Internal) Node Edge Point (Edge) Service End Point Link Transitional Link Mapping Topology Node Connection EndPoint Connection Service Interface Point TAPI Context-2 Physical Box View (internal) Domain-2 NNI NNI D2-1 D2-3 5 7 D2 6 8 D2-2 D2-1o D2-3o 5.D2 7.D2 6.D2 8.D2 D2-2o *The multi-domain controller may have to invoke more than one retrieval API operation to get this view

This slide depicts the complete Topology internal to the multi-domain-controller* It is assumed that the exposed TAPI Context Topology contains one Node per layer per device in the domain controller’s network It is assumed that no Connectivity has been setup in the entire domain and this is the initial Topology view Node Edge Point (Internal) Node Edge Point (Edge) Service End Point Link Transitional Link Mapping Topology Node Connection EndPoint Connection Service Interface Point TAPI Context-3 Physical Box View (internal) D3-1e 11.D3 12.D3 Domain-3 UNI D3-2e 9.D3 NNI D3-4 10.D3 G-2 11 7 D3-3 D3-1 D3 D3-2o 8 D3-2 12 R-2 D3-3o 7.D3 D3-1o 9 10 UNI 8.D3 D3-4o R-4 G-4 *The multi-domain controller may have to invoke more than one retrieval API operation to get this view

Domain-3 TAPI Context Hierarchical Topology
This slide depicts complete Topology exposed to multi domain-controller as 2-Level hierarchy* It is assumed that the exposed TAPI Context top-level Topology is an 2 Node abstraction of domain-controller‘s internal Context This view is constructed by recursively traversing/expanding the internal Topology of top-level Nodes It is assumed that no Connectivity has been setup in the entire domain and this is the initial Topology view Node Edge Point (Internal) Node Edge Point (Edge) Service End Point Link Transitional Link Mapping Topology Node Connection EndPoint Connection Service Interface Point TAPI Context-3 Physical Box View (internal) D3-1e 11.D3 D3e 12.D3 Domain-3 UNI D3e D3-2e 9.D3 NNI D3-4 10.D3 G-2 11 D3-3 D3-1 7 D3 D3-2o 8 R-2 D3-2 12 7.D3 D3-3o D3o D3-1o 9 10 UNI 8.D3 D3o D3-4o R-4 G-4 *The multi-domain controller may have to invoke more than one retrieval API operation to get this view

MD Controller Local Resource Pool (Internal)
This slide depicts the complete Topology internal to the multi-domain-controller in terms of TAPI-like constructs* This view is not exposed to the applications over TAPI. The abstraction mapping is maintained internally by the MD domain controller The MD controller is responsible for matching-up and mapping service-interface-points of different domains It is assumed that no Connectivity has been setup in the entire domain and this is the initial internal Topology view MD Controller Internal View D1 D3 1.G 1.D1 D1-e D3-1e 11.D3 11.G 2.R 2.D1 12.D3 12.R 3.G 3.D1 D3-2e 10.D3 10.G 4.R 4.D1 9.D3 9.R D2 D1-o D3-2o D2-1o D2-3o 5.D1 5.D2 7.D2 7.D3 D3-3o D3-1o 8.D2 8.D3 6.D1 6.D2 D2-2o D3-4o * An controller internal model may not be based on TAPI

Green TAPI Context Topology: single-layer, single Node
This slide depicts the complete Topology exposed by the multi-domain-controller to the Green application It is assumed that exposed TAPI-Context Topology is a single Node abstraction of multi-domain-controller ‘s internal Context It is assumed that this is an ETH layer Topology The LayerProtocol of NodeEdgePoints contain attributes specified by the Ethernet extension schema It is also possible that no layer information is exposed and layer specific information is implicitly known to client and provider It is assumed that no Connectivity has been setup in the entire domain and this is the initial Topology view Node Edge Point (Internal) Node Edge Point (Edge) Service End Point Link Transitional Link Mapping Topology Node Connection EndPoint Connection Service Interface Point Green TAPI Context G 1.G G1.e 11.G 3.G 10.G *The application may have to invoke more than one retrieval API operation to get this view

Green TAPI Context Topology: single layer, edge-Node
This slide depicts an alternate Topology exposed by the multi-domain-controller to the Green application It is assumed that exposed TAPI-Context Topology is an edge-Node abstraction of multi-domain-controller ‘s internal Context It is assumed that this is an ETH layer Topology The LayerProtocol of NodeEdgePoints contain attributes specified by the Ethernet extension schema It is assumed that no Connectivity has been setup in the entire domain and this is the initial Topology view The ETH layer Links are an abstraction of the potential connectivity at this layer TAPI Capacity pac is used to represent all the potential, provisioned and available capacity information Node Edge Point (Internal) Node Edge Point (Edge) Service End Point Link Transitional Link Mapping Topology Node Connection EndPoint Connection Service Interface Point Green TAPI Context G R3.e 11.G 1.G R1.e 3.G R2.e 10.G *The application may have to invoke more than one retrieval API operation to get this view

Red TAPI Context Topology: multi-layer
This slide depicts a multilayer Topology exposed by the multi-domain-controller to the Red application It is assumed that exposed TAPI-Context Topology is per-layer-Node abstraction of multi-domain-controller’s internal Context It is assumed that this is an ETH + ODU layer Topology It is assumed that no Connectivity has been setup in the entire domain and this is the initial Topology view Initially there no Links in the ETH layer The ODU layer Links are an abstraction of the potential connectivity at this layer Node Edge Point (Internal) Node Edge Point (Edge) Service End Point Link Transitional Link Mapping Topology Node Connection EndPoint Connection Service Interface Point Red TAPI Context R R3.e 12.R 2.R R1.e 9.R 4.R R1.o R2.o R3.o *The application may have to invoke more than one retrieval API operation to get this view

Red TAPI Context Topology: multi-layer
This slide depicts an alternate Topology exposed by the multi-domain-controller to the Red application It is assumed that exposed TAPI-Context Topology is an edge-Node abstraction of multi-domain-controller ‘s internal Context It is assumed that this is an ETH + ODU layer Topology It is assumed that no Connectivity has been setup in the entire domain and this is the initial Topology view Initially there no Links in the ETH layer The ODU layer Links are an abstraction of the potential connectivity at this layer Node Edge Point (Internal) Node Edge Point (Edge) Service End Point Link Transitional Link Mapping Topology Node Connection EndPoint Connection Service Interface Point Red TAPI Context R 2.R R1.e R3.e 12.R 4.R R2.e 9.R R1.o R3.o R2.o *The application may have to invoke more than one retrieval API operation to get this view

Service Example 10G EPL Multi-Domain Controller Domain-1 Controller
Node Edge Point (Internal) Service End Point Node Edge Point (Edge) Link Transitional Link Connection EndPoint Service Interface Point 1 13 1.G TAPI Context-G 10.G 2.R TAPI Context-R 9.R 3.G 11.G 4.R 12.R Multi-Domain Controller 2 12 3 5 6 8 9 11 1.D1 TAPI Context-1 5.D1 5.D2 TAPI Context-2 7.D2 7.D3 TAPI Context-3 11.D3 2.D1 6.D1 6.D2 8.D2 8.D3 12.D3 3.D1 4.D1 9.D3 10.D3 4 Domain-1 Controller 7 Domain-2 Controller 10 Domain-3 Controller Domain-1 Domain-2 Domain-3 UNI NNI UNI NNI D1-4 D3-4 G-1 G-2 1 D2-1 D2-3 11 D1-1 D1-3 5 7 D3-3 D3-1 R-1 2 D1-2 6 8 R-2 D2-2 D3-2 12 UNI 3 4 9 10 UNI G-3 R-3 R-4 G-4

10G EPL Service Setup Sequence
Green-app requests 10G EPL ConnectivityService between SEPs (1.G, 11.G) MD-controller computes & provisions E2E connectivity within its internal topology MD-controller requests 10G ConnectivityService between SEPs (1.D1, 5.D1) Domain1-controller computes & provisions ODU+ETH Connections in its domain Domain1-controller returns provisioned Connections in terms of Context-1 topology MD-controller requests 10G ConnectivityService between SEPs (5.D2, 7.D2) Domain2-controller computes & provisions ODU Connections in its domain Domain2-controller returns provisioned Connections in terms of Context-2 topology MD-controller requests 10G ConnectivityService between SEPs (7.D3, 11.D3) Domain3-controller computes & provisions ODU+ETH Connections in its domain Domain3-controller returns provisioned Connections in terms of Context-3 topology MD Controller updates its internal Topology and resource pool capacity/usage metrics MD-controller returns provisioned Connections in terms of Context-G topology MD-controller updates capacity/usage metrics in Context-G topology 1 2 3 4 5 6 parallel requests 7 8 9 10 11 12 13

10G EPL Service setup: Green Context
Node Edge Point (Internal) Service End Point Node Edge Point (Edge) Link Transitional Link Mapping Topology Node Connection EndPoint Connection Connectivity Service Service Interface Point Green TAPI Context 1 13 R3.e 11.G 1.G R1.e 3.G R2.e G 10.G *The application may have to invoke more than one retrieval API operation to get this view

10G EPL Service setup: MD Controller Internal view
MD Controller Internal View (not exposed) 2 12 1.G 1.D1 D1-e D3-1e 11.D3 11.G 9 2.R 2.D1 11 12.D3 12.R 3.G 3.D1 5 D3-2e 10.D3 10.G 3 12 4.R 4.D1 9.D3 9.R D3 D1 6 8 D1-o D3-2o D2-1o D2-3o 5 5.D1 5.D2 7.D2 7.D3 D3-3o D2 D3-1o 8.D2 8.D3 6.D1 6.D2 D2-2o D3-4o 11 * An controller internal model may not be based on TAPI

10G EPL Service setup: DC1/Context1 view
Node Edge Point (Internal) Service End Point Node Edge Point (Edge) Link Transitional Link Mapping Topology Node Connection EndPoint Connection Connectivity Service Service Interface Point TAPI Context-1 Physical Box View (internal) D1 Domain-1 1.D1 D1-e UNI NNI 2.D1 4 D1-4 G-1 3.D1 5 1 D1-1 3 D1-3 5 4.D1 R-1 2 D1-2 6 D1-o UNI 3 4 5 5.D1 G-3 R-3 6.D1 *The multi-domain controller may have to invoke more than one retrieval API operation to get this view

Node Edge Point (Internal) Service End Point Node Edge Point (Edge) Link Transitional Link Mapping Topology Node Connection EndPoint Connection Connectivity Service Service Interface Point TAPI Context-2 Physical Box View (internal) Domain-2 NNI NNI 7 D2-1 D2-3 5 7 6 8 6 8 D2-2 D2-1o D2-3o 5.D2 D2 7.D2 6.D2 8.D2 D2-2o *The multi-domain controller may have to invoke more than one retrieval API operation to get this view

TAPI Context-3 Physical Box View (internal) D3-1e 11.D3 9 11 12.D3 Domain-3 UNI D3-2e 9.D3 NNI 10 D3-4 10.D3 G-2 11 D3-1 7 D3-3 D3 D3-2o 8 R-2 D3-2 12 7.D3 D3-3o D3-1o 9 10 UNI 8.D3 D3-4o R-4 G-4 11 *The multi-domain controller may have to invoke more than one retrieval API operation to get this view

References Thank you 

Links…. TAPI Wiki: TAPI SDK Core model: TR-512 V1.4 (November 2018)
TAPI SDK Core model: TR-512 V1.4 (November 2018) UML, Papyrus, YANG Guidelines TR 514/515 (July 2018) Last published version  Latest working draft UML to YANG & YAMG-OpenAPI Mapping Tools Github repository: Github repository:

TAPI Overview* Karthik Sethuraman, NEC May 5, 2019 *animated.

Similar presentations

Presentation on theme: "TAPI Overview* Karthik Sethuraman, NEC May 5, 2019 *animated."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

TAPI Overview* Karthik Sethuraman, NEC May 5, 2019 *animated.

Similar presentations

Presentation on theme: "TAPI Overview* Karthik Sethuraman, NEC May 5, 2019 *animated."— Presentation transcript:

Similar presentations

About project

Feedback