with Whitebox Transponder ‘Cassini’ ODTN and TIP Collaboration · ODTN Implementation Framework: •ONOS YANG compiler, runtime •Dynamic config subsystems Features: •NBI(RESTCONF)

Copyright © NTT Communications Corporation. All rights reserved.

ntt.com

Transform your business, transcend expectations with our technologically advanced solutions.

ODTN and TIP Collaboration with Whitebox Transponder ‘Cassini’

2018.12.5Hiroki Okui

NTT Communications


Disaggregated Transport Network

Copyright © NTT Communications Corporation. All rights reserved. 3

ODTN (Open Disaggregated Transport Network)

Optical telemetry

Protection/restoration

CalendaringPower

Management

WSS

TAPI

Open Line System (OLS)

OpenConfig OpenConfig

MUX WSSAMP MUX

xponder

ODTN Controller

TAPI

xponder

xponder

Edge Cloud

xponder

xponder

xponder

WAN

Transponders frommultiple vendors

Book-endedtransponders

OLS Controller


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


Target of this presentation

WSS

TAPI



MUX WSSAMP MUX

xponder

ODTN Controller

TAPI

xponder

xponderEdge Cloud

xponder

xponderxponder

WAN

OLS Controller

Cassini Cassini

Phase 1.0 (P2P, only transponder)

Phase 1.0 w/ OLS(P2P, transponder + OLS)

Phase 2.0(mesh, transponder + OLS)

Jul. 2018

Mar. 2019

Jan. 2018

w/ Cassini


Cassini & TAI


Whitebox packet transponder “Cassini”

• Broadcom Tomahawk+ ASIC(3.2T) • 100Gbit/s QSFP28 x16• 200Gbit/s CFP2-ACO x8

ACO line card (NTT Electronics)

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:

○ https://github.com/Telecominfraproject/oopt-tai○ https://github.com/Telecominfraproject/oopt-tai-implementations

HW IndependentApplication X

TAI

libtai.so(for vendor A)

Transponder A

HWIndependentApplication X

TAI

libtai.so(for vendor B)

Transponder B

Same codebase

HWIndependentApplication Y

TAI


Transponder B

Multiple NOS choices

Disaggregated

Same codebaseMultiple transponder choices

https://github.com/Telecominfraproject/oopt-tai

https://github.com/Telecominfraproject/oopt-tai-implementations

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

Application

TAI


Transponder A

Application

TAI


Transponder B

Application

Transponder C

Application

Transponder D

YANG model YANG model YANG model YANG model

Operation Support Systems / SDN Controller / OrchestratorOperator

Software

TransportComponent

Transponders with TAI Transponders without TAI


Collaboration with ODTN

• Provision through OpenConfig common model• IP Infusion provides OpenConfig NBI interface to us with OcNOS (Thanks!)

Application

TAI


Transponder A

Application

TAI


Transponder B

YANG model YANG model

SDN Controller / OrchestratorOperator

Software

TransportComponent

OcNOS

TAI


Transponder A

TAI


Transponder B

OpenConfig

ODTN


Development & Test


Device setup and TAPI representation

transceiver(CFP2_ACO)

transceiver(QSFP28)

logical-channel logical-channel

xe1

xe2

xe3

xe4

xe5

xe6

xe1/1

xe2/1

xe3/1

xe4/1

xe5/1

xe6/1

100G

100G

200G

oe1oe1/1

oe1/2

oe2oe2/1

oe2/2

oe3oe3/1

oe4/2

10101

20101

2010210201

.

.

10301

20201

2020210401

10501

20301

2030210601

transceiver(CFP2_ACO)

transceiver(QSFP28)

logical-channellogical-channel

xe1

xe2

xe3

xe4

xe5

xe6

xe1/1

xe2/1

xe3/1

xe4/1

xe5/1

xe6/1

100G

100G

200G

oe1oe1/1

oe1/2

oe2oe2/1

oe2/2

oe3oe3/1

oe4/2

10101

20101

20102 10201

10301

20201

20202 10401

10501

20301

20302 10601

Transponder1

Link (100G)DSR DSR

Connection

Connectivity Service

x12 x12

x12 x12

x12

x12

1..1 1..1

OTSi layer(ignored)

11 2111 21

121 221

111 211

.

...

.

...

SIP

NEPNEP

CEP

TAPI

Cassini


Mapping from TAPI to OpenConfig

<logical-channels> <channel> <logical-channel-assignments> <assignment> <index>10101</index> <config> <index>10101</index> <assignment-type>LOGICAL_CHANNEL</assignment-type> <logical-channel>20101</logical-channel> <allocation>100.0</allocation> </config> </assignment> </logical-channel-assignments> </channel>

Transponder1

DSR

x12

x12

x12

Link (100G)

1..1

1111

121

111

lower connection

<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> <connection-end-point> <topology-id>...-100000000000</topology-id> <node-id>...-100000000000</node-id> <owned-node-edge-point-id>...-111000000000</owned-node-edge-point-id> <connection-end-point-id>...-111000000000</connection-end-point-id> </connection-end-point> <layer-protocol-name>DSR</layer-protocol-name></connection>

client side

line side

tapi-sample-step2-intermediate.xml sbi-openconfig-sample-infinera.xml

xe1

xe2

xe1/1

xe2/1

100G

100G

200G

oe1oe1/1

oe1/2

10101

20101

2010210201

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

ODTN Implementation

Framework:

• ONOS YANG compiler, runtime

• Dynamic config subsystems

Features:

• NBI(RESTCONF) auto-generation

• SBI(NETCONF) auto-generation

• Java library which enable easy

implementation of Service Application

• Distributed config store of NBI service

configuration and device configuration

15

Device DeviceDevice

JSON / XML

(5) Data Plane

*.yangService Design Orchestrator

(1) Service Model

TAPI

*.yang

(3) Device Model

OpenConfig

JSON / XML

(4) ProtocolgRPC / RESTCONF / NETCONF SB

YANG Runtime

Dynamic Config Subsystem

ODTN App

YANG Compiler

model.jar

Distributed Config Store

/services/devices

(6) Framework(2) NB ProtocolREST / gRPC / RESTCONF / NETCONF NB


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

Transponder1


Takeaways

• ODTN and TIP collaboration

• ODTN and Cassini is a good starting point to realize whitebox transponder/controller

• Come and join us!

Transponder1


Thank you


Backup Slides


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”

- Target Domain- metropolitan- DC/Cloud Interconnect

DC/Cloud Interconnect

Transport

Packet

Transport NWController

E2E Orchestrator

Other domain Controller

OSS/BSS

DC/Cloud DC/Cloud

From All-in-One to Disaggregation


Open Communities EffortsOpen Line Systems OpenConfig

http://www.openconfig.net/projects/models/

Transport API

Topology Connectivity Path Computation

Shared Network Information Context

Virtual Network Notification

NENetwork Resource Groups NENESDN Controller

NENESDN ControllerNENEApplication

Transport API

Transport API

Other SBIs

http://photonics-complete.eu/wp-content/uploads/2018/01/

https://www.opennetworking.org/open-transport/


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

Open NBI

SDN Controller

Open SBI

Open Ctrl

Open Device

Orchestrator

Open Line System

Transport API

Vendor Controller

<As-Is> <To-Be>Proprietary NBI

Proprietary SBI

Vendor Proprietary Device


ODTN (Open Disaggregated Transport Network)

Optical telemetry

Protection/restoration

CalendaringPower

Management

WSS

TAPI



MUX WSSAMP MUX

xponder

ODTN Controller

TAPI

xponder

xponder

Edge Cloud

xponder

xponder

xponder

WAN

Transponders frommultiple vendors

Book-endedtransponders

OLS Controller


ODTN Members

- 5 operators

- 12 vendors


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

Phase 1.0P2P, only transponder

Phase 1.5P2P, transponder + OLS

Phase 2.0mesh, transponder + OLS

Jun. 2018 Jan. 2019We are hereJan. 2018


Challenges

- The journey to Software Integration of multi-vendor dis-aggregated devices is long and difficult

- Lots of features to be realized among multi-vendor devices- Discovery, path computation, power control, protection, monitoring, etc..

- Common Open API is needed - 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

Documents

with Whitebox Transponder ‘Cassini’ ODTN and TIP Collaboration · ODTN Implementation Framework: •ONOS YANG compiler, runtime •Dynamic config subsystems Features: •NBI(RESTCONF)