Use Case: Multi vendor domain OMS interworking Disaggregated OMS

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

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

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

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

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

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

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

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

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

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

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

ROADM LTPs and path

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

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

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

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

(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

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: