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

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

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

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

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

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

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

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

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

10. ODTN Phase 1.0

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

12. 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)
Line Port
Line Port

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

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

15. ODTN Phase 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

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

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

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

19. Mapping from TAPI to OpenConfig11 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> </uuid>
<connection-end-point>
<topology-id> </topology-id>
<node-id> </node-id>
<owned-node-edge-point-id> </owned-node-edge-point-id>
<connection-end-point-id> </connection-end-point-id>
</connection-end-point>
<owned-node-edge-point-id> </owned-node-edge-point-id>
<connection-end-point-id> </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

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

21. ODTN Phase 1.5

22. 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)
Open Line System (OLS)
* Under progress

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

24. Transponders from multiple vendors Book-ended transponders
ODTN Phase 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

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

26. 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:
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)

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

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

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

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

31. ODTN Phase 2.0

32. 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 (?)

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

34. Next Steps

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

36. Takeaways

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

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

39. Useful Info
ODTN Wiki:
Technical Weekly Meeting: Every Tuesday at 8 AM PST
Questions ?

40. Phase 1.0
Phase 1.0 Blogpost
events/blog/odtn_phase1_results/
Phase 1.0 Demo with NTT and Infinera
Phase 1.0 Demo with Telefonica and NOKIA