ODTN and TIP Collaboration with Whitebox Transponder Cassini

Size: px

Start display at page:

Download "ODTN and TIP Collaboration with Whitebox Transponder Cassini"

Junior Clark
5 years ago
Views:

ntt.com ODTN and TIP Collaboration with Whitebox Transponder Cassini 2018.12.

1 ntt.com ODTN and TIP Collaboration with Whitebox Transponder Cassini Hiroki Okui NTT Communications Transform your business, transcend expectations with our technologically advanced solutions.

2 Disaggregated Transport Network

ODTN (Open Disaggregated Transport Network) TAPI Optical telemetry Power Management Protection/ restoration Calendaring ODTN Controller TAPI

3 ODTN (Open Disaggregated Transport Network) TAPI Optical telemetry Power Management Protection/ restoration Calendaring ODTN Controller TAPI OpenConfig Edge Cloud Transponders from multiple vendors OpenConfig OLS Controller MUX WSS AMP WSS Open Line System (OLS) MUX WA N Book-ended transponders 3

4 Open Line Systems Traditional optical line systems are integrated systems with a single vendor s transponder, mux/demux, amp, ROADM Open Line Systems are disaggregated systems composed of multi-vendor transponders Possible to use preferred vendor s transponder every time of wavelenth expansion 4

5 Target of this presentation TAPI ODTN Controller TAPI OpenConfig Edge Cloud MUX Cassini Jan WSS AMP (P2P, only transponder) WSS Open Line System (OLS) MUX WA N Cassini Jul Phase 1.0 Mar w/ Cassini Phase 1.0 w/ OLS (P2P, transponder + OLS) OpenConfig OLS Controller Phase 2.0 (mesh, transponder + OLS)

6 Cassini & TAI

7 Whitebox packet transponder Cassini Broadcom Tomahawk+ ASIC(3.2T) 100Gbit/s QSFP28 x16 200Gbit/s CFP2-ACO x8 ACO line card (NTT Electronics)

8 What is TAI? TAI is an interface between optical transponders and system software Allows system software to operate with any TAI-compliant transponders Allows transponders to operate in any system which supports TAI By decoupling the transponders from the rest of the system, it allows each to innovate independently Available here: HW Independent Application X Same codebase TAI libtai.so (for vendor A) Transponder A HW Independent Application X Multiple NOS choices TAI TAI Multiple transponder choices libtai.so (for vendor B) Transponder B HW Independent Application Y Same codebase libtai.so (for vendor B) Transponder B Disaggregated

9 What is not TAI? TAI is not an API for operators like YANG models TAI is not trying to become a de jure standard or standardization body Operation Support Systems / SDN Controller / Orchestrator Operator Software Transport Component YANG model YANG model Application Application TAI TAI libtai.so (for vendor A) libtai.so (for vendor B) Transponder A Transponder B Transponders with TAI YANG model YANG model Application Application Transponder C Transponder D Transponders without TAI

10 Collaboration with ODTN Provision through OpenConfig common model IP Infusion provides OpenConfig NBI interface to us with OcNOS (Thanks!) Operator Software Transport Component SDN Controller / Orchestrator ODTN YANG model YANG model OpenConfig Application Application OcNOS TAI TAI TAI TAI libtai.so (for vendor A) libtai.so (for vendor B) libtai.so (for vendor A) libtai.so (for vendor B) Transponder A Transponder B Transponder A Transponder B

11 Development & Test

Device setup and TAPI representation Cassini 100G 10101 xe1 20101 oe1/1 20102 oe1/2 10201 100G xe2 xe2/1 200G oe1 xe1/1 20101 oe1/1 20102 oe1/2 200G oe1 xe1 10201 100G xe2 xe2/1 10301

. transceiver logical-channel (QSFP28) logical-channel transceiver (CFP2_ACO) transceiver (CFP2_ACO) xe4/1 xe4 10501 xe5/1 xe5 10601 xe6/1 xe6 logical-channel transceiver (QSFP28)

12 Device setup and TAPI representation Cassini 100G xe oe1/ oe1/ G xe2 xe2/1 200G oe1 xe1/ oe1/ oe1/2 200G oe1 xe G xe2 xe2/ oe2/ oe2/2 xe5 xe xe6/ oe3/ oe4/2 oe3.. transceiver logical-channel (QSFP28) logical-channel transceiver (CFP2_ACO) transceiver (CFP2_ACO) xe4/1 xe xe5/1 xe xe6/1 xe6 logical-channel transceiver (QSFP28) logical-channel Connectivity Service TAPI SIP 21 x12 CEP x12 Connection NEP DSR x NEP 1..1 x12 Link (100G) OTSi layer(ignored) x xe oe3/ oe4/2 oe3.. xe4/ xe5/1 xe3/ oe2/ oe2/2 oe2.. xe4 oe2.. xe3/ xe3 100G xe1/1 x12 DSR

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

14 Model-driven controller in ONOS: DCS Subsystem to support NETCONF/YANG ecosystem Launched in 2016 and has been developed to realize model-driven ctrl. 14

15 ODTN Implementation (1) Service Model Framework: TAPI YANG Compiler *.yang Service Design ONOS YANG compiler, runtime Dynamic config subsystems Orchestrator JSON / XML (6) Framework REST / grpc / RESTCONF / NETCONF NB (2) NB Protocol Distributed Config Store YANG Runtime Dynamic Config Subsystem model.jar /devices /services ODTN App *.yang grpc / RESTCONF / NETCONF SB Open Config NBI(RESTCONF) auto-generation SBI(NETCONF) auto-generation Java library which enable easy implementation of Service Application JSON / XML Distributed config store of NBI service Device (3) Device Model (4) Protocol Features: Device Device configuration and device configuration (5) Data Plane 15

16 Test Result Made all component work together successfully Mapping between OpenAPIs: TAPI => OpenConfig => TAI Got confidence that Cassini/OcNOS/TAI are promising devices/nos/api as transport whitebox Still work in progress Some features of TAI are not implemented as of now Exposed configurations are limited as well Will be able to have a full capability of TAI in a year Some critical issues are found in DCS Should be addressed from its design Good requirement for next DCS

17 Takeaways ODTN and TIP collaboration ODTN and Cassini is a good starting point to realize whitebox transponder/controller Come and join us!

18 Thank you

19 Backup Slides

OSS/BSS From All-in-One to Disaggregation E2E Orchestrator Transport NW Controller Other domain

20 Our Expectation for Disaggregated Transport Networks - Flexibility and agility - Integration from in hardware to in software - Innovations and upgrades from per all-in-one nodes to per each component OSS/BSS From All-in-One to Disaggregation E2E Orchestrator Transport NW Controller Other domain Controller - Target Domain - metropolitan - DC/Cloud Interconnect Packet Transport DC/Cloud DC/Cloud Interconnect DC/Cloud

Open Communities Efforts Open Line Systems OpenConfig http://www.

eu/wp-content/uploads/2018/01/ Transport API Application NE NE SDN

Virtual Network Notification Shared Network Information Context Other SBIs

21 Open Communities Efforts Open Line Systems OpenConfig Transport API Application NE NE SDN Controller NE NE Transport API Topology Connectivity Path Computation Virtual Network Notification Shared Network Information Context Other SBIs Network Resource Groups NE Transport API SDN Controller NE NE 2 1

Towards Full Open Architecture - Existing communities are focused on each specific target - No Integrated Solution in open source community Build a reference implementation by using those communities

22 Towards Full Open Architecture - Existing communities are focused on each specific target - No Integrated Solution in open source community Build a reference implementation by using those communities outputs Orchestrator Proprietary NBI SDN Controller Vendor Controller Proprietary SBI Vendor Proprietary Device <To-Be> <As-Is> Open NBI Transport API Open Ctrl Open SBI Open Device Open Line System 2 2

23 ODTN (Open Disaggregated Transport Network) TAPI Optical telemetry Power Management Protection/ restoration Calendaring ODTN Controller TAPI OpenConfig Edge Cloud Transponders from multiple vendors OpenConfig OLS Controller MUX WSS AMP WSS Open Line System (OLS) MUX WA N Book-ended transponders 23

24 ODTN Members - 5 operators - 12 vendors

25 Current progress and next step - Current progress - - Implementation and testing for Transponder provisioning with OpenConfig: Done Design OLS and optical media layer provisioning with latest TAPI and OpenConfig: On going Next step - Implement path and config computation feature with leveraging onos optical-intent Design mesh solution towards Phase 2.0 Jan Phase 1.0 P2P, only transponder Jun We are here Phase 1.5 P2P, transponder + OLS Jan Phase 2.0 mesh, transponder + OLS

26 Challenges - The journey to Software Integration of multi-vendor dis-aggregated devices is long and difficult - - Common Open API is needed - - Lots of features to be realized among multi-vendor devices Discovery, path computation, power control, protection, monitoring, etc.. TAPI is the most possible candidate, but there are some missing parts from the software integration perspective ODTN is collaborating with OTCC/TAPI and growing into each other Multi-device transaction and config state management features are needed - But there are no candidates in current Open SDN controllers Now considering to implement these features in ONOS

ODTN An Open Controller for the Disaggregated Optical Network

ODTN An Open Controller for the Disaggregated Optical Network Andrea Campanella andrea@opennetworking.org An Operator Led Consortium Outline Clear ask from Operators ONOS as a Platform Incremental steps