TAPI Topology & Connectivity Concepts

TAPI Topology & Connectivity Concepts
Karthik Sethuraman, NEC June 1, 2019 *animated

Current TAPI 2.x Topology & Connectivity Support

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

Recursive Connectivity & Topology aspects of Forwarding
Node aspect of FD Topology aspect of FD Observer 01 A FD (Node) Node Edge Point Link 01.1 Service Interface Point FD (Topology) Mapping Connection Topology Connection Connection End Point TAPI Context Top-level “Network” Connection A N 02 01 A 01.1 C C Connection A appears a route of Connections B,C and Link B-C C.3 C.4 C.1 C.2 11 14 16 17 18 12 13 15 04` 01`` Connection C appears as a route of Connections C.1,C.3,C.4 & in-between Links 01` 01.n 04 B 02.1 03 02` 02.n

TAPI Topology & Connectivity Instances Tree view (example1)
Topology w/ Connectivity N N Topology A 01 Node Connection Topology Connection Node Edge Point Connection End Point Reference/Pointer Composition A A A 01 01 01 02 02 02 A A B B B 02 02 02 02 03 03 03 03 C C C 01 01 01 Node A&C Topologies always needs to be fully expanded to access NEPs 01, 02 04 04 04 C C C1 C1 C1 01 01 01 01 11 11 11 10 12 11 C3 C3 C2 13 13 13 12 14 14 14 13 C4 C4 C4 04 04 04 04 18 18 18 05

example1: Single-level Topology, Network-Node (Single) abstraction
Node Edge Point 01 A Node Reference (pointer) Link Topology Node Encapsulates Topology Service Interfc Point Connection End Point Connection End Point Reference (pointer) Connection Connectivity Service Single Node abstraction – for simple TAPI applications/clients that does not want to concern itself with Network topology & routing Ability to expose top-level “Network” Connection only – No way to represent top-level Connection’s route or its lower-level decomposed “cross” connections Node Topology A 01 02 01 02 TAPI Context

example2: Single-level Topology, Network abstraction
Node Edge Point 01 A Node Reference (pointer) Link Topology Node Encapsulates Topology Service Interfc Point Connection End Point Connection End Point Reference (pointer) Connection Connectivity Service Probably not an very useful example, although allowed by TAPI model – serves as a base for following 2 practical sub-cases Exposes “Cross” Connections only – NO top-level Node or top-level “Network” Connection or its Connection-topology/route C.1.1 21 C.1.3 01 01 26 10 22 02 C.1.2 25 23 24 11 C.3 08 C.4 B 06 05 04 03 02 07 12 C.2.1 31 32 33 C.2.3 36 C.2.2 Network Topology 13 34 35 TAPI Context

example2a: Single-level Topology, Network abstraction with implicit Node
Node Edge Point 01 A Node Reference (pointer) Link Topology Node Encapsulates Topology Service Interfc Point Connection End Point Connection End Point Reference (pointer) Connection Connectivity Service Implicit Top-level Singe Node (and its encapsulated Topology) Provides ability to expose top-level “Network” Connection and its Connection-topology/route as well as it decomposed lower-level “Cross” Connections Top-level Connection is NOT bounded by an explicit Node, while lower-level connections have a bounding Node C.1.1 C.1.3 01 21 01 26 10 22 02 C.1.2 25 23 24 11 C.3 08 C.4 B 06 05 04 03 02 07 12 C.2.1 31 32 33 C.2.3 36 C.2.2 Network Topology 13 34 35 TAPI Context

example2b: Single-level Topology, Network abstraction /w multi-level implicit Nodes
Node Edge Point 01 A Node Reference (pointer) Link Topology Node Encapsulates Topology Service Interfc Point Connection End Point Connection End Point Reference (pointer) Connection Connectivity Service A variation of example 2a – but with multiple levels of Implicit Nodes (and their encapsulated Topology hierarchy) Provides ability to expose top-level “Network” Connection and its Connection-topology/route as well as multiple levels of Connection decomposition Top-level Connection as well as intermediate-level connections are NOT bounded by an explicit Node, while lowest-level connections have a bounding Node C.1.1 C.1.3 01 21 01 26 10 22 02 C.1.2 25 23 24 B 11 C.3 08 C.4 03 02 06 05 04 07 12 C.2.1 31 32 33 C.2.3 36 C.2.2 Network Topology 13 34 35 TAPI Context

example3: 2-level Topology, (explicit) Node + Network abstraction
Node Edge Point 01 A Node Reference (pointer) Link Topology Node Encapsulates Topology Service Interfc Point Connection End Point Connection End Point Reference (pointer) Connection Connectivity Service This abstraction emerges from example 2a, with distinction of an Explicit bounding Node for “Network” Connection which allows for clean representation of forwarding capability prior to setting up of connectivity Provides ability to expose top-level “Network” Connection and its Connection-topology/route as well as its decomposed lower-level “Cross” Connections All Connections are bounded by an explicit Node Node Topology A 01 02 01 02 Network Topology C.1.1 C.1.3 01 21 26 10 22 C.1.2 25 23 24 11 C.3 08 C.4 B 06 05 04 03 02 07 12 C.2.1 31 32 33 C.2.3 36 C.2.2 13 34 35 TAPI Context

example4: Multi-level Partitioning Topology abstraction
Node Edge Point 01 A Node Reference (pointer) Link Topology Node Encapsulates Topology Service Interfc Point Connection End Point Connection End Point Reference (pointer) Connection Connectivity Service Node Topology A 01 02 Topology exposes Boundary NEPS 04 03 C B 02 01 01 04 03 02 Topology A Node aggregates NEPs exposed by Encapsulated Topology Topology C 02 01 01 C.1 01 C.4 10 05 04 04 11 C.3 08 C.2 12 06 07 13 C.1.1 21 C.1.3 01 26 10 10 01 22 C.1.2 25 Topology C.1 23 24 Emerges from example 2b - with distinction of multiple levels of Explicit Nodes (and their encapsulated Topology hierarchy) Provides ability to expose multi-level Connections, each bounded by an explicit Node 11 11 12 12 Topology C.2 C.2.1 31 32 33 C.2.2 C.2.3 36 13 34 13 TAPI Context 35

TAPI 2.2-RC2 Topology Model Skeleton

TAPI 2.2-RC2 Connectivity Model Skeleton

Topology “Abstraction” & Forwarding Concepts with ETH-over-OTN Example
Based on slide-decks presented in many public conferences & tutorials past couple of years (OFC, ONS, L123, MEF, OIF, etc)

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

Multi-domain Topology “Abstraction” Concepts & Hierarchical Control Example
Based on slide-decks presented in many public conferences & tutorials past couple of years (OFC, ONS, L123, MEF, OIF, etc)

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

Topology & Forwarding Concepts with an Photonic Example
Based on 2018 ONF Connect presentation

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

TAPI Topology & Connectivity Concepts

Similar presentations

Presentation on theme: "TAPI Topology & Connectivity Concepts"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

TAPI Topology & Connectivity Concepts

Similar presentations

Presentation on theme: "TAPI Topology & Connectivity Concepts"— Presentation transcript:

Similar presentations

About project

Feedback