ONF Project leader: Andrea Campanella andrea@opennetworking.org ODTN Project at ONF OIMT & OTCC Meeting Reference Implementations of Open Disaggregated Transport Networks ONF Project leader: Andrea Campanella andrea@opennetworking.org

Outline Requirements from Network Infrastructure Operators ONOS as a Network Control Platform Project phases Phase 1.0: control TRPD – TRPD Connections Phase 1.5: TRPD - OLS – TRPD Connectivity services Phase 2.0: OLS devices and TRPD directly controlled Testing and Trials Takeaways Mention what the project is not: standards, software-only, research, demo

Requirements from Infrastructure Operators Simplify and Automate Transport Network Operations Focused on Standard APIs for Openness – Modularity - Evolution Integrating Rapid cycles of innovations happening in Optical Network equipment Transponders and OLS systems Transponder Behaviors interworking with Optical Line Systems (OLS) Flexible OLS Configuration capabilities for any OTSi: Alien Wavelengths Network Services rapidly created, prototyped, deployed, tested … and validated from Transport Network Control Platforms delivered as ready Production Platforms Continuous delivery pipeline of Network Control Apps to DevOps environment Openness is an enabler for Network Infrastructure Operators to be Vendor Neutrals

Why ONOS ? … For Simplification & Automation Modular Architecture Support for multiple standard protocols Support for multiple device data & information models ease of extensibility Resiliency in case of failures Multi instance Device Mastership handling Dynamic Configuration Subsystem (DCS) Performance thanks to benchmarking & improvements to … Target Network Production ready and proven source codes Mention what the project is not: standards, software-only, research, demo

Southbound Interface Protocols ODTN Southbound protocol current needs NETCONF + YANG → Yang tools + Dynamic Configuration Subsystem REST and RESTCONF gRPC → gNMI

ONOS Device Drivers Device specific driver <company>-drivers.xml e.g microsemi <driver name="microsemi-netconf" extends="netconf" manufacturer="Microsemi" hwVersion="EA1000"> <behaviour api=InterfacePath impl=ImpementationPath /> </driver> Device specific driver Is collection of behaviors Activation on-demand Encapsulate device specific logic and code ports, controller, flowrule, power… models Integrate different vendor device drivers with their Yang models with no change to ONOS core and Northbound API

Dynamic Configuration Subsystem Components *.yang YANG Compiler Device Config App JSON / XML model.jar REST / gRPC / RESTCONF / NETCONF NB Distributed Config Store YANG Runtime Dynamic Configuration Subsystem /devices /services *.yang model.jar RESTCONF / NETCONF SB JSON / XML Device Device Device Device Device Device Device Device Device

ODTN incremental approach ODTN gets developed one step at a time through: Definition of use-cases Selection of common API(s) to achieve given use-case Implementation, review & integration in ONOS master Trials and demonstrations Several phases with well-defined milestones + demonstration Mention what the project is not: standards, software-only, research, demo

High Level Design TAPI over RESTCONF Northbound Service handling Understand semantics of TAPI services request NB API mediation layer TAPI Service Handler Abstract network topology Control network Connections wrt resources Generate device configurations Control logic Device behavior calls Map computed configuration semantics to procedures to device control agents SB driver layer Transponder OLS Transponder Driver X Driver Y Driver Z OpenConfig over NETCONF or TAPI over RESTCONF

ODTN Phase 1.0

ODTN Phase 1.0 - Use Case and APIs Use Cases Point to point connection made of 2 transponders and an optional Open Line system Directly connected transponders, OLS configured out-of-band Enable cross-connection between line-side and client side ports of the transponder APIs Northbound Transport API (TAPI) through RESTCONF Transponders configuration: OpenConfig over NETCONF

Service Application + Pairs of Transponders – ODTN Phase 1 Integration & lab demonstration completed – August 2018 T-API based service request (Connectivity service request) Transport API / REST Service Application translates Transport-API Connectivity service request into NETCONF/OpenConfig <edit-config> to configure transponder devices ONOS Controller Service Application Dynamic Config Subsystem NETCONF/OpenConfig to configure transponders Client Port Client Port 100G 100G Transponder_1 Transponder_2 Optical Channel (OCh) https://github.com/opennetworkinglab/onos/blob/master/drivers/odtn-driver/src/main/java/org/onosproject/drivers/odtn/NokiaOpenConfigDeviceDiscovery.java Line Port Line Port

Why OpenConfig for TX Well structured and extensible API Supported already by many vendors Proper abstraction model for transponder devices capabilities and information Defines capabilities at correct level for programmability but also abstraction from physical details Capability and Flexibility to support vendor specific features Can represent both multi-layer w/ and w/o OTN Open Source

Why TAPI for ONOS Northbound and OLS ? Well know API Extensible and Open Source Tested and deployed (See Interop Testing) Proper abstraction for high level optical domain programming Can represent both multi-layer end to end provisioning with optical parameters Great community of vendors and Service Providers

ODTN Phase 1.0 - Topology Transponders on either side of one p2p connection must be of same vendor OLS, if present, is configured out of band to carry alien wavelengths across Transponders → Infinera XT3300, NOKIA 1830PSSECX, NEC, Edge-core CASSINI TAPI OpenConfig OpenConfig Client Network Interfaces Open Line System (OLS) Client Network Interfaces xponder xponder xponder MUX WSS AMP WSS MUX xponder xponder xponder Out of Band configuration of OLS Transponders from multiple vendors Book-ended transponders

ODTN Phase 1.0 - Implementation Auto-generated RESTCONF ONOS northbound based on TAPI yang models through DCS ODTN Application for end to end control with TAPI model integration Implementation of an Openconfig ONOS driver supporting standard version of Openconfig Specific device drivers were developed when needed (Infinera XT-3300) due to deviances from the model

ODTN Phase 1.0 - Transponder discovery OCh pre-configured between transponder line ports in OLS JSON with OLS endpoints are sent to ONOS ONOS Initial reach out and OpenConfig/NETCONF get topology request Transponder returns device information and Service Interface Points (SIPs) ONOS Stores TRX IP and port identifiers in distributed configuration store 2 IP: 192.168.56.1 Port: 5001 Driver: ols Transponder Device and Ports 5 netcfg.json OpenConfig/NETCONF exchanges 3 & 4 3 & 4 Client Network Interfaces Client Network Interfaces Open Line System (OLS) xponder MUX WSS AMP WSS MUX xponder NETCONF <get>, <edit-config> 1 Out of Band configuration of OLS

ODTN Phase 1.0 - Transponder provisioning OSS/BSS sends TAPI connectivity Request to ONOS with two SIPs (SIP1, SIP4) ONOS computes OpenConfig Payload to create cross-connect in each device (e.g. SIP1-SIP2) and sends it to devices Transponder creates cross connection ONOS stores configuration of Transponders and can return it via TAPI NB tapi-connectivity Transponder Device and Ports 1 4 OpenConfig <local-channel-assignment> tag 2 2 Open Line System (OLS) SIP2 SIP3 SIP1 SIP4 xponder MUX WSS AMP WSS MUX xponder 3 cross connection between SIP1 and SIP2

Mapping from TAPI to OpenConfig 11 11 x12 121 100G 10101 lower connection xe1 xe1/1 20101 200G 111 x12 1..1 100G oe1/1 20102 oe1 10201 xe2 xe2/1 oe1/2 DSR x12 Link (100G) Transponder1 tapi-sample-step2-intermediate.xml sbi-openconfig-sample-infinera.xml <connection xmlns="urn:onf:otcc:yang:tapi-connectivity"> <uuid>00000000-0000-3000-0001-111000000000</uuid> <connection-end-point> <topology-id>...-100000000000</topology-id> <node-id>...-100000000000</node-id> <owned-node-edge-point-id>...-121000000000</owned-node-edge-point-id> <connection-end-point-id>...-121000000000</connection-end-point-id> </connection-end-point> <owned-node-edge-point-id>...-111000000000</owned-node-edge-point-id> <connection-end-point-id>...-111000000000</connection-end-point-id> <layer-protocol-name>DSR</layer-protocol-name> </connection> <logical-channels> <channel> <logical-channel-assignments> <assignment> <index>10101</index> <config> <assignment-type>LOGICAL_CHANNEL</assignment-type> <logical-channel>20101</logical-channel> <allocation>100.0</allocation> </config> </assignment> </logical-channel-assignments> </channel> client side line side

CASSINI white-box TX Integration ODTN OpenConfig OcNOS Transponder Abstraction Interface TAI TAI libtai.so (for vendor A) libtai.so (for vendor B) Transponder A Transponder B Client Network Interfaces Client Network Interfaces OpenConfig TAPI OpenConfig xponder xponder xponder MUX WSS AMP WSS MUX xponder xponder Open Line System (OLS) xponder Cassini Cassini

ODTN Phase 1.5

Partially Open Disaggregated Network Control Platform Architecture ODTN Project Phase 1.5* T-API service request (Connectivity & Topology services) Network Service Orchestrator Transport API / RESTCONF (ver. 2.1) Service Application translates T-API Connectivity service to OLS Controller and to NETCONF/OpenConfig for terminal devices (Transponders) ONOS Controller Service Application Dynamic Config Subsystem Provide connectivity service NETCONF/OpenConfig to configure transponders Transport API / REST (Connectivity & Topology services) ver. 2.1 OLS Controller* Provide topology service Client Port Client Port 100G 100G ROADM ROADM ILAMP ROADM ROADM Transponder_1 Transponder_2 Line Port ROADM ROADM Line Port Alien wavelength mode OLS Controller could be based on NOKIA NSP (NFM-T) https://wiki.onosproject.org/display/ODTN/ODTN Open Line System (OLS) * Under progress

ODTN Phase 1.5 - Use Cases and APIs Point to point connection between 2 TRPDs and thru OLS Enable OCh provisioning with TRPDs and OLS control APIs Northbound: Transport API (TAPI) through RESTCONF Transponders configuration: OpenConfig models over NETCONF OLS configuration: T-API 2.1 models over REST

Transponders from multiple vendors Book-ended transponders ODTN Phase 1.5 - Topology Same as Phase 1.0 but OLS discovered and controlled by ONOS Open Line System is exposed as a single node (big-switch) OLS Vendors → ADVA, Coriant/Infinera, NOKIA, Juniper TAPI OpenConfig TAPI OpenConfig Client Network Interfaces Client Network Interfaces xponder OLS Controller xponder xponder MUX WSS AMP WSS MUX xponder xponder Open Line System (OLS) xponder Transponders from multiple vendors Book-ended transponders

ODTN Phase 1.5 - Implementation Done: Augmented transponder drivers with Line Side port configuration for wavelength trough OpenConfig Extend Northbound TAPI to 2.1 Driver for discovery of OLS device and Ports as SIPs (Service Interface Points) through TAPI 2.1 on Southbound (Working with ADVA OLS) In Progress: connectivity service request for OLS through TAPI in SB Power negotiation and configuration Other OLS integration

ODTN Phase 1.5 - OLS Discovery OSS/BSS or Operator sends JSON with OLS endpoints to ONOS ONOS Initial reach out and TAPI topology request OLS returns basic device information and Service Interface Points (SIPs) ONOS stores device and SIPs as Ports in distributed store 1 IP: 192.168.56.1 Port: 5001 Driver: ols OLS Device SIP 1-6 PORTS 4 netcfg.json 2 3 GET Tapi-Topology TAPI REPLY Tapi-Topology SIP1 SIP4 OLS Controller SIP2 SIP5 MUX WSS AMP WSS MUX SIP3 SIP6 Open Line System (OLS)

ODTN Phase 1.5 - OLS Provisioning ONOS creates an Optical Connectivity Intent and Identifies two SIPs (1,4) as ports required to pass through the OLS (Optional) wavelength request on given ports to OLS TAPI Connectivity request between SIP 1 and 4 on wavelength (if needed) OLS sets up internal path and returns OK Intent is installed and ONOS knows if OLS is properly provisioned 1 State is OK 5 OpticalConnectivityIntent 4 POST TAPI Connectivity Request 2 3 GET Wavelength TAPI OLS sets up path between SIP1 and SIP4 SIP1 SIP4 OLS Controller SIP2 SIP5 MUX WSS AMP WSS MUX SIP3 SIP6

ODTN Phase 1.5 - end to end provisioning OSS/BSS requests optical layer provisioning through TAPI ONOS creates OpticalConnectivityIntent OLS is provisioned through TAPI Line side of the transponder is provisioned through OpenConfig over NETON OSS/BSS requests for end to end L3 connectivity Cross-connect line side to client side is setup through OpenConfig over NETCONF End to end OCh path is provisioned Operator OSS/BSS 1 5 2 6 4 3 4 6 7 OLS Controller xponder MUX WSS AMP WSS MUX xponder

TBD: ADVA, INFINERA, OTHERS ? Lab Trial Plans Transponders Open Line System TBD: ADVA, INFINERA, OTHERS ? Interoperability of software layer across different vendors Start building true multi-vendor trials

Phase 1.0 (P2P, only transponder) Timeline Jan. 2018 Jul. 2018 Mar. 2019 Phase 1.0 (P2P, only transponder) Phase 1.0 w/ OLS (P2P, transponder + OLS)

ODTN Phase 2.0

ODTN Phase 2.0 – Fully Disaggregated Optical Networks Use Case Mesh ROADM network made of N ROADMS and N transponders (N>=2) Enable end to end path provisioning with direct Transponder and ROADM configuration and control APIs Northbound: Transport API (TAPI) through RESTCONF Transponders configuration: OpenConfig models over NETCONF ROADM configuration: OpenConfig, OpenROADM (?)

ODTN Phase 2.0 TAPI services OpenConfig OpenConfig OpenConfig Client Network Interfaces Client Network Interfaces xponder ROADM ROADM xponder xponder xponder xponder xponder OpenConfig Transponders from multiple vendors Book-ended transponders Client Network Interfaces xponder ROADM xponder xponder Transponders from multiple vendors

Next Steps

@@@ Deployment NEEDS Transponder efforts: Integration with CASSINI: EDGECORE white box Transponder OLS integration efforts: Coriant/Infinera ADVA Nokia

Takeaways

Takeaways ODTN is the first (and only) project to build open source software stack for control and management of optical networks ODTN Uses standard and open device APIS (OpenConfig for Transponders, TAPI for OLS) ODTN uses TAPI as a standard and open API on the northbound ODTN leverages architecture, performance e scalability of ONOS ODTN integrates a wide variety of vendors for network equipment. Incremental approach towards production readiness Lab trials with major operators → feedback loop of requirements and enhancements

Great Community, Thanks you! Still lots to do, come and join us! Takeaways Great Community, Thanks you! Still lots to do, come and join us! odtn@opennetworking.org

Useful Info ODTN Wiki: https://wiki.onosproject.org/display/ODTN/ODTN Technical Weekly Meeting: Every Tuesday at 8 AM PST Questions ? andrea@opennetworking.org

Phase 1.0 Phase 1.0 Blogpost https://www.opennetworking.org/news-and- events/blog/odtn_phase1_results/ Phase 1.0 Demo with NTT and Infinera https://wiki.onosproject.org/pages/viewpage.action?pageId=23335851 Phase 1.0 Demo with Telefonica and NOKIA https://wiki.onosproject.org/pages/viewpage.action?pageId=27590874

https://www.opennetworking.org