1. Use Case: Multi vendor domain OMS interworking
Disaggregated OMS

2. Multi vendor domain optical networkλ
CD: colorless directionless
Amplifier (uni)
Transponder (bidi)
Disaggregated-OTSi λ λ λ λ
ROADMCD
ROADMCD λ
ROADM CD
ROADM CD λ λ
Idea:
Split the optical domain into subdomains
ROADM domain vendor A
ROADM domain vendor 1
Transponder domain vendor A
Transponder domain vendor 1
Interdomain Transponder-ROADM (OTSi)
Interdomain OMS
ROADM CD
ROADM CD
Disaggregated-OMS λ λ λ λ

3. Control Architecture Photonic Cloud 1 Photonic Cloud A
Orchestration / Multi Domain Controller 1A
Path computation and validation
TAPI v2.0.1 (+)
TAPI v2.0.1 (+)
Domain Controller 1
Domain Controller A λ λ
Photonic Cloud 1
Photonic Cloud A λ λ
OMS λ λ
OMS λ λ
OTSi
OTSi λ λ

4. Use Cases 100G Service (C1) with primary path secondary pathλ
CD: colorless directionless
Amplifier (uni)
Transponder (bidi) λ λ λ λ
ROADMCD
ROADMCD
ROADM CD
ROADM CD λ λ λ λ
ROADM CD
ROADM CD
100G Service (C1) with
primary path
secondary path
restauration path λ λ λ λ

5. Use Cases 100G Service (C1) with primary path secondary path λ λ λ λ λ
CD: colorless directionless
Amplifier (uni)
Transponder (bidi) λ λ λ λ
ROADMCD
ROADMCD
ROADM CD
ROADM CD λ λ λ λ
ROADM CD
ROADM CD
100G Service (C1) with
primary path
secondary path λ λ λ λ

6. Node
NodeEdgePoint
Device
ConnectivityServiceEndPoint X
ServiceInterfacePoint
ConnectivityService
Connection
Link
Transitional Link
ConnectionEndPoint A
CTP and CTP
CTP and TTP
TTP
CTP

7. Photonic Domain Vendor Aλ
CD: colorless directionless
Amplifier (uni)
Transponder (bidi)
ROADM CD
ROADM CD
ROADM CD

8. Photonic Domain Vendor 1λ
CD: colorless directionless
Amplifier (uni)
Transponder (bidi)
ROADM CD
ROADM CD
ROADM CD

9. OTSi Domain Vendor A Service via own Photonic domainλ
CD: colorless directionless
Amplifier (uni)
Transponder (bidi) λ λ
Service via own Photonic domain λ
Service via two Photonic domains λ
>> 3 use cases
Service via foreign Photonic domain λ λ

10. OTSi Domain Vendor 1 Service via own Photonic domainλ
CD: colorless directionless
Amplifier (uni)
Transponder (bidi) λ λ
Service via own Photonic domain
Service via two Photonic domains λ λ
>> 3 use cases
Service via foreign Photonic domain λ λ

11. Transponder with ETH connection with ODU4 connection T1.A T1.A ETH-FC
ODU4-FC
SIP-ETY
ETH-CTP
OTU4-TTP
ODU4-TTP
OTU4-TTP
ETY-TTP
ETH-CTP
T1.A
ODU4-TTP
OTSi-TTP
SIP-OTSiA
SIP-ETY
ODU4-TTP
OTSi-TTP
SIP-OTSiA
ETY-TTP
ETH-CTP
T1.A
NEP
NEP
NEP
NEP

12. OTSi Domain Vendor X ONF CoreModel/TAPI instance model
ETH-CTP
ODU4-CTP
ODU4-FC
OTU4-TTP
OTSI-TTP
ETY-TTP T3
ETH-CTP
ODU4-CTP
ODU4-FC
OTU4-TTP
OTSI-TTP
ETY-TTP
Forwarding Domain
OTSi-TTPs T1
ETH-CTP
ODU4-CTP
ODU4-FC
OTU4-TTP
OTSI-TTP
ETY-TTP T4
ETH-CTP
ODU4-CTP
ODU4-FC
OTU4-TTP
OTSI-TTP
ETY-TTP
OTSi-FC
OTSi-FC
OTSi-FC T5
ETH-CTP
ODU4-CTP
ODU4-FC
ODU4-TTP
OTU4-CTP
OTSI-TTP
ETY-TTP T6
ODU-CTP

13. ROADM LTPs and path

14. Multivendor ROADM-Domain
Rule!
Connection-end-points will be created/deleted together with the service.
Note:
This figures and also the following figures show also connection-end-points where no service exists.
OMS-TTP
5x OTSi-CTP A3 C1
OTSi-FCs 1 C2 A2
OMS-FC C3 A1
This ROADM representation does not distinguish between Add/Drop directions and Line (network) directions.
This may change, see page 11 and 12.
5x OTSi-CTP
OMS-TTP

15. Orchestrator Instance Model for add/drop
ROADM with 5 channels (OTSi-CTPs)
in 3 directions
One direction for colorless add/drop
2x FC
Multi vendor Domain
Layer: OTSi
2x 100G client / OTU4 Transponder
colorless mux/demux (bidi)
SIP-OTSiA
SIP-OTSiA
Interdomain (transponder, WSS) port connections between transponder line port and filter client port
SIP-OTSiA
SIP-OTSiA
Transponder-Domain-Vendor-B
ROADM-Domain-Vendor-A

16. Instance Model for add/drop
ROADM with up to 5 channels (OTSi-CTPs)
in 2 OMS directions and
colorless directionless add/drop
2x FC
Multi vendor Domain
Layer: OTSi
2x 100G client / OTU4 Transponder
colorless mux/demux (bidi)
Transponder-Domain-Vendor-A
5x OTSi-CTP
ODU4-FC
SIP-ETY
ODU4-TTP
OTU4-CTP
SIP-OTSiA
T1.A
ODU4-CTP
OTSi-TTP
ETY-TTP
ETH-CTP
SIP-OTSiA
A.2
Interdomain physical port connetions (transponder, ROADM) port connections between transponder line port and filter client port
ODU4-FC
SIP-OTSiA
SIP-ETY
ODU4-TTP
ODU4-CTP
OTU4-CTP
OTSI-TTP
ETY-TTP
ETH-CTP
T1.1
SIP-OTSiA
Owned Node Edge Points
Exists always and can be used to represent physical port connections
OTSiCTPS are created together as result to the service creation.
Transponder-Domain-Vendor-B
ROADM-Domain-Vendor-A
Contention
otsi-node-edge-point-spec
- available frequency slot
- occupied Frequency slot

17. Connection to show cross connect in WDM
connection end point
CTP to indicate specific channel available on client port of filter module
otsi-connection-end-point-spec
- otsi-ctp
- selected frequency slot
connection end point
CTP to indicate specific channel in use (only exposed when channel is created)
otsi-connection-end-point-spec
- otsi-ctp
- selected frequency slot
Owned Node Edge Point
(Client Port of Filter module)
OMS Termination
otsi-node-edge-point-spec
- available frequency slot
- occupied Frequency slot
Owned Node Edge Point
(Network port of WSS)
OMS Termination
otsi-node-edge-point-spec
- available frequency slot
- occupied Frequency slot 1 A2

18. (Owned-node-edge-point)
Transponder ODU4 (fixed backplane) connection
T1A
ETH-CTP
ODU4-TTP
ODU4-FC
ODU4-CTP
OTU4-CTP
OTSi-TTP
ETY-TTP
ODU4 TTP
ODU4 CTP
ETH CTP
OTU4 TTP
OTSi CTP
OTSi (OCH) Connection
ETY TTP
OTSi TTP
(Service end point)
Owned Node Edge Point
(Client Port of Transponder) – Mapped to a service Interface point
Owned Node Edge Point
(Network port of Transponder)
Owned Node Edge Point
(Network port of WSS)
OMS Termination
otsi-node-edge-point-spec
- available frequency slot
- occupied Frequency slot
OAM tree of TAPI for ROADM
Reference to NEP
rx power level per channel
tx power level per channel
Service End-point
Service End-point
Filter Client Port
(Owned-node-edge-point)
Physical
Service End-point

19. Proposed TAPI extension
module “tapi-otsi” {
[...]
augment "/tapi-common:context/tapi-connectivity:connectivity-service" {
uses optical-constraint;
description "Augments the base connectivity-service with optical
routing constraint"; }
grouping optical-constraint {
description “none";
list include-optical-channel-characteristic {
key 'local-id';
uses tapi-common:local-class;
uses frequency-slot;
description
“List of optical channel frequency that must be used when
calculating the optical route.”
list exclude-optical-channel-characteristic {
“List of optical channel frequency that must not be used when
In order to create an OTSi service in a “Transponder only” domain (see page 5 and 6) and in order to configure the frequency by the domain controller on the transponders an “optical-constraint” object class is proposed: