1. TAPI Topology & Connectivity Enhancements Proposal for v3.0
Karthik Sethuraman, NEC
June 5, 2019
*animated

2. Current TAPI 2.x Topology & Connectivity Support

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

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

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

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

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

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

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

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

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

12. TAPI 2.2-RC2 Topology Model Skeleton

13. TAPI 2.2-RC2 Connectivity Model Skeleton

14. TAPI 3.0 Proposal
Under Discussion

15. Proposed Topology model updates
It is possible (and typical) to have multiple Topologies within a single TapiContext
Currently TAPI really only supports “Topology” abstraction (Node groupings)
Calling it topology abstraction since an “abstract” Node in a Topology represents an aggregation (by reference) of NodeEdgePoints exposed by its encapsulated/underlying Topology and (often) belonging to lowest-level Nodes in the Topology hierarchy
To support proper Topology/Node recursive decomposition & component-system pattern
Remove NodeAggregatesNEP association from Node to make Node an opaque entity
Add NEPIsSupportedByNEPsExposedByEncapsulatedTopology (reference) association to NEP
Pros:
Every Node now “owns/contains” its NEPs within its presented abstraction
Cons:
In an “hierarchical multi-level partitioning” abstraction, some NEP information will be duplicated/cloned across multiple copies of edge-NEPs - one per abstraction level (but isn’t that the purpose of having different abstracted views?)

16. Proposed Connectivity-Topology model updates
Currently TAPI Connections are hanging (“owned” by Context), with no direct association to Topology elements
ConnectionEndPoint is “owned” by NodeEdgePoint, but should ideally belong to Connection
Although Connections exist at every level of topology hierarchy, they reference CEPs at the lowest-level Topology Nodes
This requires complete expansion of all of TAPI topologies to trace a Connection’s route (even those at top-most level)
To properly model Connection-CEP relationship & Topology/Node abstraction, & directly associate it with Topology, it is necessary to explicitly model the component-system pattern for Connections as separate classes (Connection Component & Connection-System)
Proposal is to split out topological elements of Connection class as a new class ConnectionTopology (or NetworkConnection)
Augment Topology with ConnectionTopology list (composition)
Add ConnectionHasConnections (composition) association to ConnectionTopology that composes Connection
Move ConnectionHasRoutes (composition) association to ConnectionTopology
Update ConnectionHasLowerLevelConnections (reference) association to point to ConnectionTopology
Update ConnectivityServiceHasTopLevelConnections (reference) association to point to ConnectionTopology
Update ConnectionTerminatesOnCEP association into composition
Add ConnectionHasParentNode (reference) association
Remove the NEP-CEP augmentation
Cons:
In an “hierarchical multi-level partitioning” abstraction, some CEP information will be duplicated/cloned across multiple copies of CEPs associated with different ConnectionTopologies

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

18. TAPI Connectivity-Topology Instances Tree view
Proposed
Current N N
Topology A 01
Node
Connection
Node Edge Point
Connection End Point
Reference/Pointer
Composition A A A A 01 02 01 A 02 A B B 02 B B 03
02` C C 03 01 C C 04
01` C 04 C C1 C1 C1 C1 01 11
01`` 12 11 C3 C3 12 C3 C3 13 14 16 C4 C4 17 C4 C4 04 18
04` 18

19. Proposed UML Topology Updates