1. TAPI NBI specification based on common Topology and Service abstraction models for Multi-layer WDM/OTN networks
Arturo Mayoral, Victor López, Oscar Gonzalez de Dios, Telefonica
May 7, 2019

2. Ambition
Telefonica GCTIO has designed the most significant use cases for service provisioning and configuration management in the optical layer.
The objective of Telefonica is to achieve the goal of introducing an standard Northbound interface (NBI) based on RESTCONF (RFC 8040) and ONF T-API (release version 2.1) models, in its production networks in the short term.
For that, the level of interoperability among different suppliers solutions need to be the higher as possible and the simpler statement of supporting TAPI v2.1.1 plus RESTCONF is not sufficient for fully interoperable solutions.
This presentation includes the Telefonica proposal for topology and services abstraction model designed for WDM and OTN networks which defines a set of guidelines for describing multi-layer network at both topology and service levels.
The intention of this document is share current Telefonica proposal with ONF audience towards the definition of a ONF topology and service abstraction model which can serve the following: improve common understanding of TAPI models, increase model gaps awareness and anticipate potential vendor interoperability issues.

3. Protocol considerations

4. ONF TAPI v2.1 Specification
Information Model
ONF Transport API version 2.1, released on October 16th, 2018, is the version proposed in current proposal.
This is the complete list of YANG models for this specification:
Model
Version
Revision (dd/mm/yyyy)
tapi-common.yang
2.1.1
10/12/2018
tapi-connectivity.yang
tapi-eth.yang
tapi-dsr.yang
tapi-notification.yang
tapi-oam.yang
tapi-odu.yang
tapi-photonic-media.yang
tapi-path-computation.yang
tapi-topology.yang
tapi-virtual-network.yang

5. ONF TAPI v2.1 Specification (2)
RESTCONF Implementation
TAPI RESTCONF specification consists of the following resources:
{+restconf}/data (Data API): CRUD based RESTCONF API for the entire data tree defined in the TAPI YANG files.
{+restconf}/operations (Operations API): RPC based RESTCONF API consisting on a small set of operations defined as RPCs in the TAPI YANG files.
{+restconf}/yang-library-version: This mandatory leaf identifies the revision date of the "ietf-yang-library" YANG module that is implemented by this server.
{+restconf}/streams (Notifications API): Notifications implementation of RESTCONF protocol are defined in
The solution implementing the RESTCONF server must expose its supported notification streams by populating the "restconf-state/streams" container definition in the "ietf-restconf-monitoring" module defined in Section 9.3 of [RFC 8040]. The streams resource can be found at:
{+restconf}/data/ietf-restconf-monitoring:restconf-state/streams
The solution must support the “filter” Query Parameter, as defined in Section of [RFC 8040], to indicate the target subset of the possible events being advertised by the RESTCONF server stream. The "filter" query parameter URI SHALL be listed in the "capability" leaf-list, located at:
{+restconf}/data/ietf-restconf-monitoring:restconf-state/capabilties
,as defined in Section 9.3 of [RFC 8040]

6. ONF TAPI v2.1 Specification (3)
RESTCONF Implementation
It is proposed the following level of compliancy for the first integration phase (Pack SDNC_1).
Operations API: Not mandatory support
Data API: Mandatory FULL Create, Retrieve, Update, Delete (CRUD) support of all the following objects is requested.
/tapi-common:context/
/tapi-common:context/service-interface-point/
/tapi-common:context/service-interface-point={uuid}/
/tapi-common:context/tapi-topology:topology-context/nw-topology-service/
/tapi-common:context/tapi-topology:topology-context/topology/
/tapi-common:context/tapi-topology:topology-context/topology={uuid}/
/tapi-common:context/tapi-topology:topology-context/topology/node/
/tapi-common:context/tapi-topology:topology-context/topology/node={uuid}/
/tapi-common:context/tapi-topology:topology-context/topology/link/
/tapi-common:context/tapi-topology:topology-context/topology/link={uuid}/
/tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-edge-point/
/tapi-common:context/tapi-topology:topology-context/topology/node/owned-node-edge-point={uuid}/
/tapi-common:context/tapi-topology:topology-context/tapi-topology:topology/tapi-topology:node/tapi-topology:owned-node-edge-point/tapi-connectivity:cep-list/
/tapi-common:context/tapi-topology:topology-context/tapi-topology:topology/tapi-topology:node/tapi-topology:owned-node-edge-point/tapi-connectivity:cep-list/tapi-connectivity:connection-end-point/
/tapi-common:context/tapi-topology:topology-context/tapi-topology:topology/tapi-topology:node/tapi-topology:owned-node-edge-point/tapi-connectivity:cep-list/tapi-connectivity:connection-end- point={uuid}/
/tapi-common:context/tapi-connectivity:connectivity-context/
/tapi-common:context/tapi-connectivity:connectivity-context/tapi-connectivity:connectivity-service/
/tapi-common:context/tapi-connectivity:connectivity-context/tapi-connectivity:connectivity-service={uuid}/
/tapi-common:context/tapi-connectivity:connectivity-context/tapi-connectivity:connectivity-service/connection/
/tapi-common:context/tapi-connectivity:connectivity-context/connection/
/tapi-common:context/tapi-connectivity:connectivity-context/connection={uuid}/
/tapi-common:context/tapi-path-computation:path-computation-context/
/tapi-common:context/tapi-path-computation:path-computation-context/path-comp-service/
/tapi-common:context/tapi-path-computation:path-computation-context/path-comp-service={uuid}/
/tapi-common:context/tapi-path-computation:path-computation-context/path/
/tapi-common:context/tapi-path-computation:path-computation-context/path={uuid}/
/tapi-common:context/tapi-common:context/tapi-notification:notification-context/
/tapi-common:context/tapi-common:context/tapi-notification:notification-context/notification
/tapi-common:context/tapi-common:context/tapi-notification:notification-context/notif-subscription/
/tapi-common:context/tapi-common:context/tapi-notification:notification-context/notif-subscription/notification

7. ONF TAPI v2.1 Specification (4)
RESCONF implementation:
SSE vs Websockets transport protocol for RESTCONF notifications:
Server Sent Events (SSE) [W3C.REC-eventsource ] is the current standard mechanism defined by RESTCONF to stream notifications.
However due to the current high support of Websocket technology in previous OIF TAPI interop activities, there is a debate on which standard to accept.
OAS TAPI specification is considered a possible candidate as RESTCONF 8040 Reference Implementation.
TAPI OAS is considered as a valuable reference implementation which may serve for early adoption of TAPI concepts and first Proofs of Concepts (PoCs) but the present specification states that the standard RESTCONF protocol described in the previous section must prevail over any other implementation.
Thus, any deviation of the standard included in the TAPI OAS will be precluded in real deployments, in other words, in case of a conflict in integration between two implementations, the RESTCONF standard will always prevail over TAPI OAS or any other REST-alike implementation.

8. ONF TAPI v2.1 Specification (5)
RESCONF implementation:
Notifications implementation of RESTCONF protocol are defined in however tapi-notification.yang defines a specific API entry to create/delete/retrieve notification-subscription services:
/tapi-common:context/tapi-common:context/tapi-notification:notification- context/notif-subscription/
, and also an specific leaf object to specify the streaming address of each notification-subscription service:
/tapi-common:context/tapi-common:context/tapi-notification:notification- context/notif-subscription/notification-channel/stream-address/

9. OTN/WDM network topology modeling

10. Scenario 1: WDM/OTN network with OTN switches
Components View 1
OTN Matrix + Client and Line
OTN Matrix + Client and Line
OTN
Line 100G
Client 10x10GE
OTN
Line 100G
Client 10x10GE
OTN Matrix + Client and Line
Client 10x1GE
Client 10x1GE
Line 100G
Line 100G

11. OTN/WDM network topology modeling
TAPI Topology Flat Abstraction model
The first TAPI Topology model presented is based on a single flat topology view which collapses all network layers into a single topology. The T0 – Multilayer topology MUST include:
ODU/DSR forwarding domains represented as multi-layer and multi-rate tapi-topology:node, allowing the representation of the internal mapping between DSR and ODU NEPs (multi-layer) and the multiplexing/de- multiplexing across different ODU rates (multi-rate). ODU-OTSi transitions MUST be represented as transitional links.
OTSi forwarding domains: represent the optical side of the optical terminals (transponders/muxponders). They are represented by single-layer tapi-topology:node, allowing the representation of the logical aggregation of OTSi connections into OTSiA aggregation and the mapping of OTSiA to ODU connections as. OTSI to Photonic-Media node connectivity MUST be represented as OMS links.
Photonic-Media forwarding domains: represents the Photonic Media (Open Line System (OLS)) network. This forwarding domains can be mapped to OLP, ROADM/FOADM and ILA network elements which connectivity is always represented as OMS or OTS links. These forwarding domains SHALL expose the capability of create Media Channel connection and connectivity services between its endpoints.

12. TAPI Topology Flat Abstraction view
Topology #1: Flat topology (DSR+ODU+OTSi+OMS+OTS)
61.D1
67.D1
73.D1
77.D1
71.D1
65.D1
Topology #0
62.D1
68.D1
74.D1
78.D1
72.D1
66.D1
Transponder / ODU switch Node
Transponder / OTSi switch Node
PHTN NODE
PHTN NODE
Transponder / ODU switch Node
Transponder / OTSi switch Node
ODU
OTSi
NMC/OMS
PHTN Node
(ILA)
OTSi
OTS
OTS
OTS
OTS
ODU
2.D1
x10
OTSI/OMS
NMC/OMS
41.D1
50.D1
10.D1
ODU
OTSI/OMS
ODU
DSR
DSR/ODU
x10
x10
NMC/OMS
NMC/OMS
OMS
OMS
DSR/ODU
51.D1
11D1
OTSI/OMS
PHTN NODE
OTSI/OMS
DSR
x10
60.D1
20.D1
Transponder / OTSi switch Node
OMS
OMS
ODU
Transponder / OTSi switch Node
ODU
NMC/OMS
ODU
OTSi
OTSi
ODU
Transponder
OTSi
OTSI/OMS
Transponder
OTSi
OTSi
OTSi
76.D1
75.D1
70.D1
69.D1
ODU
ODU
ODU
ODU
64.D1
63.D1
x10
x10
DSR
DSR
21.D1
30.D1
31.D1
40.D1

13. TAPI Topology Flat Abstraction view
Topology #1: Flat topology (DSR+ODU+OTSi+OMS+OTS)
61.D1
67.D1
73.D1
77.D1
71.D1
65.D1
ODU/DSR Node
62.D1
68.D1
74.D1
78.D1
72.D1
66.D1
OTSi Node
Photonic Node
Transponder / ODU switch Node
Transponder / OTSi switch Node
PHTN NODE
PHTN NODE
Transponder / ODU switch Node
Transponder / OTSi switch Node
ODU
OTSi
NMC/OMS
OTS
PHTN Node
(ILA)
OTS
OTSi
ODU
2.D1
x10
OTSI/OMS
OTS
OTS
NMC/OMS
41.D1
OTSI/OMS
50.D1
10.D1
ODU
ODU
DSR
DSR/ODU
x10
x10
NMC/OMS
NMC/OMS
OMS
OMS
DSR/ODU
51.D1
11D1
OTSI/OMS
PHTN NODE
OTSI/OMS
DSR
x10
60.D1
20.D1
Transponder / OTSi switch Node
OMS
OMS
ODU
Transponder / OTSi switch Node
ODU
NMC/OMS
ODU
OTSi
OTSi
ODU
Transponder
OTSi
OTSI/OMS
Transponder
OTSi
OTSi
OTSi
76.D1
75.D1
70.D1
69.D1
ODU
ODU
ODU
ODU
63.D1
x10
x10
64.D1
DSR
DSR
Device
21.D1
30.D1
31.D1
40.D1

14. OTN/WDM network topology modeling
TAPI Topology Layered Abstraction model
Based on the previous topology model a four-level abstraction model is required to simplify the customer usage of the network data provided by the TAPI server. A general guidelines the model proposes:
The network logical abstraction is divided in four-level abstraction topologies differentiating the DSR/ODU client layer, the DSR/ODU server layer, the OTSi/OTSiA and Photonic Media (Media Channels, OMS, and OTS) layers. Each topology MUST be presented as a tapi-topology:topology object within the TAPI context.
Each topology (except the DSR/ODU abstracted topology which does not have further client layer) MUST represent explicitly the client layer and the connectivity with the server layer through Transitional Links. The server topology in every level topology is presented as a single node abstraction.
The first design principle is representing each forwarding domain at every layer as an aggregated tapi- topology:node object. At every layer, an abstract/aggregated node MUST be included to represent the potential forwarding between client network endpoints (SIPs + associated NEPs) at that layer.
Each aggregated node MUST include a reference to the next level topology by tapi-topology:encap-topology attribute.
Each aggregated node which include a list of NEPs as elements of the tapi-topology:owned-node-edge-point list, which need tobe identified as tapi-topology:node/tapi-topology:aggregated-node-edge-point , to be referenced by the NEPs of the underlying explicit topology.

15. OTN/WDM network topology modeling
TAPI Topology Layered Abstraction model
Topology T1 - DSR/ODU: represents the client DSR/ODU layers. In this topology,
This topology MUST include only a DSR/ODU aggregated topology representing the potential forwarding between client/service network endpoints (SIPs + associated NEPs). From the HW perspective, in this topology these NEPs/SIPs represent the client ports of all transponder/muxponders, connected through WDM mesh networks or through point-to-point optical links.
The NEPs layer qualifications allowed T1 level topology are:
layer-protocol-name=DSR, ODU
supported-cep-layer-protocol-qualifier=[DIGITAL_SIGNAL_TYPE, ODU_TYPE]
NEPs forwarding capabilities within this node SHALL be constrained by using node-rule-group/rules/forwarding-rules. The NEPs can be segmented according to the following conditions:
Different layer-protocol-qualifier: In case multiple the aggregated node includes NEPs with different layer-protocol-qualifier types (i.e., between different DSR_SIGNAL_TYPEs or ODU_TYPE), each group SHALL be segmented with a node-rule-group, including:
forwarding-rule=MAY_FORWARD_ACROSS_GROUP
Not forwarding between same device ports: . In some cases it might be relevant to restrict the forwarding between client ports at the same network device (e.g., transponder). In this case ALL NEPs related to client ports at the same device SHALL be segmented with a node-rule-group, including:
forwarding-rule=CANNOT_FORWARD_ACROSS_GROUP

16. OTN/WDM network topology modeling
TAPI Topology Layered Abstraction model
Topology T2 - DSR/ODU-OTSi: represent DSR/ODU explicitly and its connectivity with the OTSi network layers. In this topology:
This topology includes the ODU/DSR as a client layer and the OTSi/OTSiA as a server layer.
The ODU/DSR layer network, as the client layer, MUST be represented explicitly, i.e., each ODU/DSR forwarding domain MUST be represented as a single tapi-topology:node
ODU/DSR forwarding domains are multi-layer and multi-rate, allowing the representation of the internal mapping between DSR and ODU signals (multi-layer) and the multiplexing/de-multiplexing across different ODU rates.
The NEPs layer qualifications allowed T2 level client layer topology are:
layer-protocol-name=DSR, ODU
supported-cep-layer-protocol-qualifier=[DIGITAL_SIGNAL_TYPE, ODU_TYPE]
The ODU NEPs representing the line side transmission and OTSi NEPs are 1:1 transitional relations expressed as transitional links.
The OTSi/OTSiA layer network represents the potential forwarding capabilities between OTSi/OTSiA service endpoints. These NEPs/SIPs represents the line ports of all transponder/muxponders connected to the WDM mesh network
The NEPs layer qualifications allowed T2 level server layer topology are:
layer-protocol-name=PHOTONIC_MEDIA
supported-cep-layer-protocol-qualifier= [PHOTONIC_LAYER_QUALIFIER_OTSi/OTSiA]
OTU layer is intentionally not included in the model as ODU->OTSiA/OTSi representation is enough to cover all our defined use cases.

17. OTN/WDM network topology modeling
TAPI Topology Layered Abstraction model
Topology T3 - OTSi/Photonic Media : represents OTSi/Photonic Media layer networks. In this topology:
The client layer topology consists of nodes representing the mapping and multiplexing of OTSi signals. It consists of nodes including OTSi client endpoints representing the Trail Termination Points (TTPs) of the OTSi connections and OTSi/OMS endpoints representing the physical connectivity with ROADM/FOADM add/drop ports.
The connectivity between transponder/muxponder line ports and ROADM/FOADM’s add/drop ports are expressed by tapi- topology:links between OMS PHOTONIC_MEDIA NEPs.
The NEPs layer qualifications allowed T3 level client layer topology are:
layer-protocol-name= PHOTONIC_MEDIA
supported-cep-layer-protocol-qualifier=[PHOTONIC_LAYER_QUALIFIER_OTSi/OTSiA], [PHOTONIC_LAYER_QUALIFIER_OMS]
Generally transponder/muxponder line ports and ROADM/FOADM’s add/drop ports are 1:1 relations, in case Optical Line Protection (OLPs) are present, OLP complexity shall be always represented in the Topology T4-Server Photonic Media OLS topology.

18. OTN/WDM network topology modeling
TAPI Topology Layered Abstraction model
Topology T4 - Server Photonic Media (Open Line System - OLS):
The Photonic Media layer is actually an aggregation of multiple network layers (OTS, OMS, NMC, NMCA, SMC, SMCA). The purpose of L3-Server topology is to represent explicitly each NMC forwarding domain as a Photonic Media node. These nodes might represent ROADM/FOADM sites in a WDM mesh. The NEPs at this layer are:
layer-protocol-name= PHOTONIC_MEDIA
supported-cep-layer-protocol-qualifier=[PHOTONIC_LAYER_QUALIFIER_NMC/NMCA]
tapi-photonic-media:media-channel-node-edge-point-spec will represent the media channel pool resources supportable, available and occupied.
NMC NEPs MUST be present on top of OMS NEPs/CEPs to represent the adjacency between OTSi signals and NMCs over the OMS link between Transponder Line Ports and ROADM Add/Drop ports.
Each NMC/NMCA NEP MUST include the tapi-photonic-media:media-channel-node-edge-point-spec to represent the media channel pool resources supportable, available and occupied.
It is assumed at minimum, the lower layer forwarding constructs (tapi-topology:link) between forwarding domains which need to be represented in this topology should be OMS links. OTS layer links and intermediate OMS forwarding domains (In Line Amplifier sites) might be represented or not depending on vendor.
In case OLP constructs are present for OMS protection, this should be represented in TAPI by using tapi-topology:resilience- type/tapi-topology:protection-type link’s attribute. Underlying switch control for OMS protection is out of the scope of this modelling.
From now this layer topology does not include associated service interface points to be selected by users for the creation of services at the NMC/NMCA layers and it will only connection generated by the TAPI server will be represented.

19. TAPI Topology Layered Abstraction view
x10
x10
x10
x10
5.D2
2.D2
DSR/ODU
DSR/ODU Node
DSR/ODU
6.D2
DSR/ODU
1.D3
x10
x10
Topology #2
5.D3
2.D3
6.D3
Photonic Media (OTSi/OTSiA Node)
OTSi/ OTSiA Node
OTSi/ OTSiA Node
OTSiNode
3.D3
OTSi Node
OTSi/ OTSiA Node
OTSi Node
4.D3
Topology #3
Photonic Media (OTSiMC, OMS, OTS) OLS Node
OMS Link
ROADM
Node
ROADM Node
OTS Link
ILA
Node
OTS Link
OMS Link
OMS Link
ROADM Node
Topology #4

20. TAPI Topology Layered Abstraction view
x10
x10
x10
x10
5.D2
2.D2
DSR/ODU
DSR/ODU Node
DSR/ODU
6.D2
DSR/ODU
1.D3
x10
x10
Topology #2
5.D3
2.D3
6.D3
Photonic Media (OTSi/OTSiA Node)
OTSi/ OTSiA Node
OTSi/ OTSiA Node
OTSiNode
3.D3
OTSi Node
OTSi/ OTSiA Node
OTSi Node
4.D3
Topology #3
Photonic Media (OTSiMC, OMS, OTS) OLS Node
OMS Link
ROADM
Node
ROADM Node
OTS Link
ILA
Node
OTS Link
OMS Link
OMS Link
ROADM Node
Topology #4

21. Scenario 2: Point-to-point DWDM link + Mesh WDM/OTN network with OLPs
Transponder
100GE
Transponder
100GE
OLP
Transponder 10GE
OLP
Transponder 10GE
Mux-ponder
10x10GE
Mux-ponder
10x10GE
Mux-ponder
10x10GE

22. TAPI Topology Flat Abstraction view
Topology #5, #6, #7: Flat topology (DSR+ODU+OTSi+OMS+OTS)
36.D1
45.D1
44.D1
52.D1
43.D1
35.D1
53.D1
44.D1
50.D1
41.D1
37.D1
46.D1
49.D1
40.D1
51.D1
42.D1
Topology #0
Transponder / ODU switch Node
Transponder / OTSi switch Node
PHTN NODE
PHTN NODE
Transponder / ODU switch Node
Transponder / OTSi switch Node
33.D1
34.D1
DSR
ODU
OMS/NMC
OTSI/OMS
ODU
OMS/NMC
OTS
PHTN Node
(ILA)
OTS
PHTN Node
(ILA)
DSR
OTSi
OTS
OTS
OTS
OTSI/OMS
OTSi
Transponder / ODU switch Node
Transponder / OTSi switch Node
OLP NODE
Transponder / OTSi switch Node
PHTN NODE
OLP NODE
Transponder / ODU switch Node
PHTN NODE
OTSI/OMS
1.D1
ODU
OMS/ NMC
OMS/ NMC
OTSI/OMS
OTSi
OMS/
NMC
OMS/
NMC
ODU
22.D1
DSR/ODU
OMS/ NMC
PHTN Node
(ILA)
OMS/ NMC
OTSi
DSR
OTS
OTS
OTS
OTS
OTS
Transponder / ODU switch Node
Transponder / OTSi switch Node
OMS/ NMC
OMS/ NMC
Transponder / OTSi switch Node
Transponder / ODU switch Node
OMS/ NMC
OMS/ NMC
2.D1
x10
ODU
OTSI/OMS
OMS
PHTN NODE
OMS
OTSI/OMS
ODU
x10
11.D1
OTSi
32.D1
OTSi
DSR/ODU
OMS
OTSI/OMS
OMS
OMS/ NMC
OTSI/OMS
DSR
ODU
OTSi
Transponder OTSi
OTSi
ODU
OTSI/OMS
OTSi
47.D1
48.D1
38.D1
ODU
x10
39.D1
21.D1
DSR

23. TAPI Topology Flat Abstraction view
Topology #5, #6, #7: Flat topology (DSR+ODU+OTSi+OMS+OTS)
36.D1
45.D1
44.D1
52.D1
43.D1
35.D1
ODU/DSR Node
Device
53.D1
44.D1
50.D1
41.D1
OTSi Node
37.D1
46.D1
49.D1
40.D1
51.D1
42.D1
Photonic Node
Transponder / ODU switch Node
Transponder / OTSi switch Node
PHTN NODE
PHTN NODE
Transponder / ODU switch Node
Transponder / OTSi switch Node
33.D1
34.D1
DSR
ODU
OMS/NMC
OTSI/OMS
ODU
OMS/NMC
OTS
PHTN Node
(ILA)
OTS
PHTN Node
(ILA)
DSR
OTSi
OTS
OTS
OTS
OTSI/OMS
OTSi
Transponder / ODU switch Node
Transponder / OTSi switch Node
OLP NODE
Transponder / OTSi switch Node
PHTN NODE
OLP NODE
Transponder / ODU switch Node
PHTN NODE
OTSI/OMS
1.D1
ODU
OMS/ NMC
OMS/ NMC
OTSI/OMS
OMS/
NMC
ODU
22.D1
DSR/ODU
OTSi
OMS/
NMC
OMS/ NMC
OTS
OTS
PHTN Node
(ILA)
OTS
OMS/ NMC
OTSi
DSR
OTS
OTS
Transponder / OTSi switch Node
OMS/ NMC
Transponder / ODU switch Node
OMS/ NMC
Transponder / OTSi switch Node
Transponder / ODU switch Node
OMS/ NMC
OMS/ NMC
2.D1
x10
ODU
OTSI/OMS
OMS
PHTN NODE
OMS
OTSI/OMS
ODU
x10
11.D1
OTSi
32.D1
OTSi
DSR/ODU
OMS
OTSI/OMS
OMS
OMS/ NMC
OTSI/OMS
DSR
ODU
OTSi
Transponder OTSi
OTSi
ODU
OTSI/OMS
OTSi
47.D1
48.D1
38.D1
ODU
x10
39.D1
21.D1
DSR

24. TAPI Topology Layered Abstraction view
Topology #1: Client topology representation (DSR + ODU)
22.D1
1.D1
12.D1
23.D1
2.D1
34.D1
33.D1
Topology #1
DSR/ODU Node 1
DSR/ODU Node 2
ODU
ODU
x10
ODU
x10
ODU
ODU
ODU
ODU
x10
Topology #2
Topology #5

25. TAPI Topology Layered Abstraction view
Topology #2, #3: Server topology (ODU + OTSi)
32.D1
1.D2
2.D2
11.D1
1.D1
4.D2
5.D2
6.D2
12.D2
22.D2
21.D1
31.D1
33.D2
42.D1
2.D2
7.D2
3.D2
x10
ODU
ODU
x10
8.D2
ODU
ODU
ODU
6.D3
1.D3
x10
x10
Topology #2
7.D3
2.D3
3.D3
Photonic Media (OTSi/OTSiA Node)
8.D3
OTSi Node
OTSiNode
OTSiNode
OTSi Node
OTSi Node
5.D3
4.D3
Topology #3
ROADM
Node
ROADM
Node
OMS Link
OLP
Node
Photonic Media (OTSiMC, OMS, OTS) OLS Node
OMS Connection
OLP
Node
ILA
Node
OMS Link
OMS Link
OTS Link
OTS Link
OMS Link
ROADM
Node
OMS Link
Topology #4
x10

26. TAPI Topology Layered Abstraction view
Topology #4: Server topology (Photonic Media - OLS)
OTSiNode
OTSiNode
OTSiNode
OTSiNode
OTSi
Node
ROADM
Node
ROADM
Node
OLP
Node
OMS Link
OLP
Node
OMS Link
OMS Link
OMS Connection
ILA
Node
OMS Link
OMS Link
OTS Link
OTS Link
Topology #4
ROADM
Node
OMS Link
OMS Link

27. TAPI Topology Layered Abstraction view
Topology #7: Server topology (Photonic Media - OLS)
33.D1
34.D1
2.D5
1.D5
ODU
ODU
2.D6
1.D6
Topology #5
Photonic Media (OTSi/OTSiA Node)
OTSiNode
OTSiNode
Topology #6
FOADM
Node
OMS Link
FOADM
Node
OMS Connection
ILA
Node
ILA
Node
OTS Link
OTS Link
OTS Link
Topology #7

28. OTN/WDM network connectivity service modeling

29. OTN/WDM network connectivity service modeling
Based on ONF TAPI 2.1 models a network model is proposed for vendor agnostic integration on the systems. The assumptions made so far for the connectivity service model are the following:
Service Interface Points (SIPs):
All the network managed by an SDN-C should be contained in a single context which will include the list of available SIPs for all layers (except of OLS Network Media Channel layer which only applies to scenarios where partially disaggregation is implemented).
A SIP is logically mapped to two topology NEPs: to the aggregated NEP of the server layer aggregated node of the upper level topology and the explicit NEP in the client layer node of the next level topology
tapi-common:service-interface-points (SIPs) must be included at least for three layers: DSR, ODU, OTSiA/OTSi, for the development of the UCs included in the first phase (Pack SDNC_1). The following tapi objects must be included, e.g. for OTSiA/OTSi SIPs:
layer-protocol-name = PHOTONIC_MEDIA
supported-layer-protocol-qualifier = [PHOTONIC_LAYER_QUALIFIER_OTSi/OTSiA]
OTSiA/OTSi SIPs must be augmented with the following photonic-media extensions.
ODU and DSR SIPs does not include any specific extensions yet.
Connectivity-service and connections:
Each tapi-connectivity:connectivity-service will always include at least a reference to one “Top Connection” tapi-connectivity:connection object within its connection list.
The “Top Connection” object is intended to represent the service end-to-end within a layer and it will include the tapi- connectivity:connection/route object including the list of connection-end-points (CEPs) traversed by the service at that layer.
The “Top Connection” may additionally include a reference to the connections created at the same layer to support the end-to-end in the tapi-connectivity:connection/lower-connection list.

30. TAPI LTP Template – Basic Arrangements
Service Interface Point
ODU (10x10G)
ETH, SDH, LO-ODU…
(10G)
ODU
Node Edge Point p n m
Node Edge Point Group
ODU (100G)
ODU (100G)
Connection End Point (TTP only)
ODU (10G)
Connection End Point (CTP only)
NEP Aggregates NEPs
(same layer, capacity pool)
CEP has-server NEP
(same layer)
Connection End Point (TTP + CTP)
CEP has-client NEP
(same-layer or different layers)
Connection End Point (Inverse mux CTP only)
Connection
Media Channel CEP
{lowerFreq, upperFreq}
NEP connects-to NEP in another Node via Link
(same layer)
Media Channel Assembly
[{lowerFreq, upperFreq},
{lowerFreq, upperFreq}, ..]
(b)
(a) F
Link
Transitional Link
CEP connects-to-peer CEP via switched Connection
(same layer) flexible cases with exposed CP
MIP
Down MEP
Up MEP
OPM
NEP connects-to NEP in another Node via Transitional Link
(different layer) F
(a)
(b)
Non Intrusive Monitoring
No Specific OAM signaling
Optical Power Monitoring   F F F
CEP connects-to CEP in another Node via Link Connection
(same layer)
CEP connects-to-peer CEP via Encapsulated XC
(same layer) fixed-mapping cases
* Top (Link) Connection is not explicitly modeled in TAPI

31. CASE 1: 10GE client signal over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation)

32. Topology #1 DSR/ODU T1 DSR/ODU Node x10 x10 DSR Node ODU Node
10GE/DSR Connectivity Service
11.D1
51.D1
x10
20.D1
60.D1
T2 DSR/ ODU switch Node
T2 DSR/ ODU switch Node
10GE/DSR Top Connection
x10
10GE
10GE
10GE
10GE
DSR
DSR
DSR
DSR
ODU2
ODU2
Layer=DSR
Total Capacity=10G
Supported CTP Rates= 10GigE,
Max # CTP instances=1
ODU Link
ODU
ODU
Transponder / ODU switch Node
ODU
ODU
T1 DSR/ODU Node
Pool = yes
Layer=ODU4 (TTP rate)
Total Capacity=200G
Supported CTP Rates=ODU2, ODU2e, ODU3
Max # TTP instances=2
Max # CTP per TTP instances=10, 10, 2
Layer=ODU4 (TTP rate)
Total Capacity=100G
Supported CTP Rates=ODU4
Max # TTP instances=1
Max # CTP per TTP instances=1

33. Topology #1 DSR/ODU T1 DSR/ODU Node x10 x10 DSR Node ODU Node
10GE/DSR Connectivity Service
11.D1
51.D1
20.D1
60.D1
x10
T2 DSR/ ODU switch Node
T2 DSR/ ODU switch Node
10GE/DSR Top Connection
x10
10GE
10GE
10GE
10GE
DSR
DSR
DSR
ODU4 Top Connection
DSR
ODU2
ODU2
ODU
ODU
Layer=DSR
Total Capacity=10G
Supported CTP Rates= 10GigE,
Max # CTP instances=1
ODU4
ODU4
ODU4
ODU4
ODU Link
ODU
ODU
Transponder / ODU switch Node
ODU
ODU
T1 DSR/ODU Node
Pool = yes
Layer=ODU4 (TTP rate)
Total Capacity=200G
Supported CTP Rates=ODU2, ODU2e, ODU3
Max # TTP instances=2
Max # CTP per TTP instances=10, 10, 2
Layer=ODU4 (TTP rate)
Total Capacity=100G
Supported CTP Rates=ODU4
Max # TTP instances=1
Max # CTP per TTP instances=1

34. Topology #1 DSR/ODU T1 DSR/ODU Node x10 x10 DSR Node ODU Node
10GE/DSR Connectivity Service
11.D1
51.D1
60.D1
x10
20.D1
T2 DSR/ ODU switch Node
T2 DSR/ ODU switch Node
10GE/DSR Top Connection
x10
10GE
10GE
10GE
10GE
ODU2 Top Connection
DSR
DSR
ODU2
ODU4 Top Connection
ODU2
DSR
DSR
ODU2
ODU2
ODU
ODU
Layer=DSR
Total Capacity=10G
Supported CTP Rates= 10GigE,
Max # CTP instances=1
ODU4
ODU4
ODU4
ODU4
ODU Link
ODU
ODU
Transponder / ODU switch Node
ODU
ODU
T1 DSR/ODU Node
Pool = yes
Layer=ODU4 (TTP rate)
Total Capacity=200G
Supported CTP Rates=ODU2, ODU2e, ODU3
Max # TTP instances=2
Max # CTP per TTP instances=10, 10, 2
Layer=ODU4 (TTP rate)
Total Capacity=100G
Supported CTP Rates=ODU4
Max # TTP instances=1
Max # CTP per TTP instances=1

35. Topology #2 ODU/OTSi DSR/ODU Node OTSi Node Photonic Node OTSi Node
ODU/DSR Topology
OTSi Node
DSR/ODU Node
Transponder / ODU switch Node
Transponder / ODU switch Node
ODU2 Top Connection
DSR
OTSi Node
DSR
ODU2
ODU2
Transponder / OTSi switch Node
Transponder / OTSi switch Node
ODU
ODU4 Top Connection
ODU
ODU4
ODU Link
ODU4
ODU
ODU
OTSi Top Connection
OTSi
OTSi
OTSi
OTSi
Photonic Link
OTSi
OTSi
ODU
OTSi
Transitional Link
Photonic Node
ODU
OTSi
Transitional Link

36. Topology #3,#4 OTSi/Photonic
ODU4 Top Connection
ODU2Top Connection
Transponder / ODU switch Node
ROADM Node
OTSi Top Connection
Transponder / OTSi switch Node
OTSi Link
DSR
NMC Top Connection
ODU2
ODU
OTSi
NMC
NMC
ODU4
Photonic Node
NMC
ODU
OTSi
OTSi
NMC
OMS-O
OMS 1 1 1
OMS
OMS Link
OMS
OTS
Line Port
Add/Drop Port
OTSi/PHTN
Node
(ILA)
OTS
OTS Link
ODU
NMC
NMC
OMS-O 1
OMS
DSR/
ODU Node
OTSi Node
OTS
OMS Link
OTS
OTSi/PHTN
Node
OTS Link

37. CASE 2: 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation)

38. Topology #1 DSR/ODU
DSR Node
CASE 2: 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation)
ODU Node
DSR/ODU Node
x10
51.D1
60.D1
11.D1
x10
20.D1
DSR/ ODU switch Node
1GE/DSR Top Connection
DSR/ ODU switch Node
1GE
1GE
1GE
1GE
DSR
DSR
DSR
ODU0
ODU0
DSR
Layer=ODU0
Total Capacity=1G
Supported CTP Rates= ODU0
Max # CTP instances=1
ODU
ODU
ODU4 Top Connection
ODU4
ODU4
ODU
Transponder / ODU switch Node
ODU
ODU
Pool = yes
Layer=ODU2 (TTP rate)
Total Capacity=100G
Supported CTP Rates= ODU0, ODU1
Max # TTP instances=10
Max # CTP per TTP instances= 10, 4
Pool = yes
Layer=ODU4 (TTP rate)
Total Capacity=200G
Supported CTP Rates= ODU2, ODU2e, ODU3
Max # TTP instances=2
Max # CTP per TTP instances= 10, 4
x10
21.D1
30.D1

39. Topology #1 DSR/ODU
DSR Node
CASE 2: 1GE client signal over ODU0 over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation)
ODU Node
DSR/ODU Node
x10
51.D1
60.D1
11.D1
x10
20.D1
DSR/ ODU switch Node
1GE/DSR Top Connection
DSR/ ODU switch Node
1GE
1GE
1GE
ODU0 Top Connection
1GE
DSR
DSR
DSR
ODU0
ODU0
ODU2 Top Connection
ODU0
ODU
ODU
ODU2
ODU2
DSR
Layer=ODU0
Total Capacity=1G
Supported CTP Rates= ODU0
Max # CTP instances=1
ODU2
ODU2
ODU
ODU
ODU4 Top Connection
ODU4
ODU4
ODU
ODU
ODU
Transponder / ODU switch Node
ODU
Pool = yes
Layer=ODU2 (TTP rate)
Total Capacity=100G
Supported CTP Rates= ODU0, ODU1
Max # TTP instances=10
Max # CTP per TTP instances= 10, 4
Pool = yes
Layer=ODU4 (TTP rate)
Total Capacity=200G
Supported CTP Rates=ODU2, ODU2e, ODU3
Max # TTP instances=2
Max # CTP per TTP instances=10, 10, 2
x10
21.D1
30.D1

40. CASE 3: 1GE client signal over ODU 0 over ODU2 over ODU4 (with intermediate ODU0 switching)

41. Topology #1 DSR/ODU Flexible Structure
DSR Node
ODU Node
x10
51.D1
x10
60.D1
60.D1
51.D1
ODU/DSR Node
DSR/ ODU switch Node
DSR/ ODU switch Node
1GE Top Connection
ODU0 Top Connection
ODU0 Top Connection
1GE
1GE
1GE
1GE
DSR
DSR
ODU0
ODU2 Top Connection
DSR
ODU0
ODU0
ODU2 Top Connection
ODU0
DSR
ODU
ODU
DSR
ODU
ODU2
ODU2
ODU2
ODU4 Top Connection
ODU2
ODU
ODU4 Top Connection
ODU
ODU
ODU
ODU4
ODU4
ODU4
ODU4
ODU
ODU
ODU
ODU
ODU
ODU
DSR/ ODU switch Node

42. Case 4: 10GE client signal over ODU2 over ODU4 (Fixed DSR-ODU mapping, flexible ODU allocation) with intermediate transponder regeneration.

43. Topology #1 DSR/ODU Flexible Structure
DSR Node
ODU Node
x10
ODU/DSR Node
51.D1
x10
60.D1
60.D1
51.D1
DSR/ ODU switch Node
DSR/ ODU switch Node
1GE Top Connection
ODU2 Top Connection
1GE
1GE
1GE
1GE
DSR
ODU/DSR Transponder Node
DSR
DSR
ODU2
ODU2
DSR
ODU
ODU
ODU4 Top Connection
ODU4 Top Connection
ODU4
ODU4
ODU4
ODU4
ODU4 Link
ODU4 Link
ODU
ODU
ODU
ODU

44. Case 5: 10GE client signal over ODU0 over ODU2 over ODU4 with Line Side OLP Protection

45. Topology #3,#4 OTSi/Photonic
ODU4 Top Connection
ODU2Top Connection
Transponder / ODU switch Node
ROADM Node
OTSi Top Connection
Transponder / OTSi switch Node
NMC Top Connection - A
DSR
ODU2
NMC Top Connection - B
OLP NODE
ODU
OTSi
NMC
NMC1
NMC
NMC
ODU4
NMC2
Photonic Node
NMC
ODU
OTSi
NMC
OTSi
NMC
NMC
OMS-O
OMS
OMS 1 1 1
OMS
OMS Link
OMS
OMS
OTS
Line Port
Add/Drop Port
OTSi/PHTN
Node
(ILA)
OTS
OTS Link
ODU
NMC
NMC
NMC
Swtich-control= yes
selected-connection-end-point: NMC-1,NMC-2
selected-route: NMC Top Connection - A
resilience-type:ONE_FOR_ONE_PROTECTION
NMC
NMC
NMC
OMS-O
OMS
OMS
OMS 1 1
OMS
DSR/
ODU Node
OTSi Node
Add/Drop Port
OMS Link
OTS
OTS
OTSi/PHTN
Node
OTS Link

46. Use Cases

47. Use cases (I) Discovery use cases: Provisioning use cases:
Use case 0: Topology and services discovery.
Provisioning use cases:
Use case 1: Unconstrained E2E Service Provisioning (Digital Signal Rate (DSR) Service i.e., GE, 10GbE, STM-X, fiberchannel…)
Use case 2: Unconstrained with channel or slot selection
2a: OCH/OTSi (channel selection)
2b:ODU (time slot selection) Service Provisioning
Use case 3: Constrained service provisioning.
3a: Include/exclude a node or group of nodes.
3b: Include/exclude a link or group of links.
3c: Include/exclude the path used by other service.
Use case 4: Manual unconstrained E2E Service Provisioning. Step by step.

48. Use cases (II) Resilience use cases:
Use case 5: 1+1 Diverse Service Provisioning for any of the previous cases (1, 2, 3a, 3b, 3c, 4)
5a: 2 transponders (Y cable)
5b: OLP
5c: (eSNCP)
Use case 6: Dynamic restoration for unconstrained and constrained use cases (1, 2, 3a, 3b, 3c, 4)
Use case 7: Restoration and protection 1+1 for use cases (1, 2, 3a, 3b, 3c, 4)
Use case 8: Permanent protection 1+1 for use cases (1, 2, 3a, 3b, 3c, 4)
Use case 9: Reverted protection for use cases (5a, 5b, 5c, 6, 7 and 8)

49. Use cases (III) Service maintenance use cases: Planning use cases:
Use case 10: Service deletion (applicable to all previous use cases)
Use case 11: Modification of service characteristics.
11a: Modification of service path
11b: Modification of service nominal path to secondary (protection) path for maintenance operations. (Only valid for resiliency use cases)
11c Modification or upgrade of service capacity. (Only valid for electrical services)
Planning use cases:
Use case 12:
12a: Pre-calculation of the optimum path (applicable to all previous use cases)
12b: Simultaneous pre-calculation of two disjoint paths.
12c: Multiple simultaneous path computation (Bulk request processing)
12d: Physical impairment validation of an pre-calculated Och trail path.