ODTN- Open and Disaggregated Transport Networks -Toru Furusawa
NTT Communications

Agenda• Technology Trends of Disaggregated Transport Networks• Introduction of ODTN Project• Project Scope• Members & Teams• Schedule• Software Design• Current Project Status & Next Steps2

Technology Trends of Disaggregated Transport Networks■From All-in-One to Disaggregation■ Innovations and upgradesfrom “per all-in-one nodes”
to “per each component”■ Integration from “in hardware”
to “in software”

Orchestrator■Active Open communities
for disaggregated transportnetworks■ Open Line Systems■ OpenConfig■ TAPIetc…

From All-in-One to Disaggregation

REST API

Transport NW Controller
NETCONF

VNF
MPLS

OTN / WDM

VLAN/OTN
Packet & Optical Transport Domain

Access Domain

3

Open Line Systems•

Traditional optical line systems areintegrated systems with a single
vendor’s transponder, mux/demux,
amp, ROADM

4•Open Line Systems are disaggregatedsystems composed of multi-vendor
transponders•

Possible to use preferred vendor’stransponder every time of wavelenthexpansion

4

OpenConfig
Google-Driven community to define vendor neutral data models for device
configuration and telemetry● Covering multiple layers (L1-L3)● Out of scope: Data Plane interoperability, controller software & southboundprotocolSDN Ctrl
Model: OpenConfig
Protocol: NETCONF/gNMI(out of scope)
YANG

5

ONF TAPI
Transport APITAPIONF Driven API used for NBI ofTransport Network Controllers

6Towards Full Open Architecture with existing activities
Existing communities are focused on each specific target
No “Integrated Solution” in open source community-> Build a reference implementation by using those communities outputs<As-Is><To-Be>Orchestrator
ProprietaryNBI

SDN Controller

Open NBI

Transport API

Open Ctrl

Vendor Controller
Proprietary
SBI

Open SBI
Open Device

Vendor
Proprietary
Device7Open Line System

ODTN Project
We have launched “ODTN (Open and Disaggregated Transport Networks)”
Project with ONF and other companies to build a open reference
implementation with open technologies
Component
NBI

Project membersAs of 2018.4.20

Reference Architecture
TAPIOpen
SourceController
CommonData
Model
Data
Model
LanguageOpen
ProtocolInnovative
Device
8YANG

NETCONF
OLS / Disaggregation

Project Members

9Project Purpose and Charter• Bring eco-system together to• Build reference implementation using open source and open standards• Do lab and field trials• Consisting of three phases• Plan/Retrospective meetings for each phase• Kick-off with 3 leading service providers, 8 vendors(as of Jan 2018)10Project Scope
Transport API(TAPI)YANGCompile

YANG(2) Service Application(3) SBI Driver(4) Integration Test

(1) NBI Handler

Mapping Implement
Logic

SDN Controller

Compile YANG based service
model

RESTCONF
Compile(1) NBI Handler
Provide TAPI based NBI(2) Service Application
Implement Java code to map TAPI
to OpenConfig(3) SBI DriverCompile YANG based devicemodel

NETCONF

Configure device with OpenConfig
model(4) Integration & Test

Point-to-Point11

Phase 1: Point-to-Point Open Line System with Open APIsGoal•

Integrate ONOS and OLS devices with a simple P-to-P topology by using open API (TAPI / OpenConfig)• Build and verify the reference implementation for P-to-P use case
• Identify problems to be solved for the phase 2Device Components•

Transponder• OLS: mux/demux, in-line amplifierTerm•

Jan 2018 - Aug 2018 (8 months)• Phase 1.0 (transponder only): Jan 2018 – April 2018
• Phase 1.5 (transponder + OLS): May 2018 – August 2018

APIAPITRNMUXWSSAMPAPIWSSOpen Line System12(OLS)MUXTRN12

Phase 2: Mesh Metro ROADM with Open APIsGoal• Integrate ONOS and ROADM devices with a partial mesh topology by using open APIs
• Build and verify the reference implementation metro ROADM use case
• Identify problems to be solved for the phase 3

Device Components• Transponder• ROADM

APIAPI

API
API

TRN

ROADM

ROADM

TRN

TRN

ROADM

ROADM

TRNTerm• Sep 2018 – April 201913

Phase 3: Full Disaggregated ROADM with Open APIsGoal• Integrate ONOS and disaggregated optical components by using open APIs
• Verify the reference implementation that works certainly for disaggregated ROADM use case
• Identify problems to be solved toward production

To/from network control

APITRN• May 2019 - Dec 2019

API

AOS

To/from remote ROADM

Line ports
Singlewavelength

TRN

Term

AMP

WSS

API

TRN

• Transponder, WSS, AMP, AOS, etc. (details TBD)

API

EMS

TRN

Device Components

Client ports
(add)

API

Client ports(drop)
To/from packet layer

14

TeamProject Teams

Active Members

Project Steering

Comcast, NTT Com (Project Chair), Telefonica,
1 vendor, ONF

Use Case

Ciena, Comcast, Coriant, NEC,NTT Com(lead), Nokia, Telefonica, TIM
etc

Software Development

CTTC, NEC (lead), Nokia, Oplink, ZTE
etc

Infrastructure (not formed yet)

TBD - formed for each service provider lab

Testing (not formed yet)

TBD - work closely with SW Development
Team15

Schedule
Phase2 Mesh ROADM

Phase1 Point-to-Point
Phase 1.0 – Transponder onlyJanFebMarApr

Phase 1.5 – Transponder + OLS
MayJuneJuly

Result & Plan
Workshop
ODTN Kickoff
Dev & integration
Initial devices + α

ONS talkOFC talk

AugSepOct

Dec

Result & PlanWorkshop

Result & PlanWorkshop
ECOC

Dev & interchangeability test
+ additional devices

Nov

Dev & integration
TBD

High Level Design
TAPI over RESTCONF
NB API
mediation
layer

Protocol handling
Understand semantics of request

AppNetwork Service Request

Solves constrained path
Manage resources
Generate device control and configuration

Control logic

Instruction to device
SB driverlayer

Transponder

OLS

Transponder

Driver X

Driver Y

Driver Z

Map imposed semantics to commands thatdevice understands

OpenConfig over NETCONF
17Model Discussion slide in Use Case TeamModel Definition work by Use Case TeamOrchestrator(0. Scope Clarification and TAPI Model Selection)
1
1. TAPI NBI Selection
2. TAPI Parameter Mapping(ConnectivityService/SEP -> Connection/CEP) common
2
3. TAPI Parameter Selection (Connection/CEP)
mapped to SB
3
4. Parameter Mappingfrom TAPI (Connection/CEP) to OpenConfig(different for each vendor)
4
different for
5. OpenConfig SB Model Selection
each vendor(different for each vendor)

NBI(RESTCONF)

ConnnectivityService/SEP↓
Connection/CEP
Connection/CEP
Connection/CEP
Connection/CEP↓↓↓OpenConfig/CEP
OpenConfig/CEP
OpenConfig
NETCONF

5Transponder
Transponder
Transponder18

Model Discussion slide in Use Case TeamODTN Scope for Phase 1.0

Must bedone inadvance

Configurable
w/ OrangeBox

Configured Parameters

TAPI

OpenConfig

How to configure

step 0Topology
Transponder, Fiber, Link ports, Client ports(for Phase1.0)

Link, Node,NEP, SIP

n/avia API (for Provider)or Auto-generated(e.g. using show cmd orLLDP)

step 1

Optical parameters
Frequency, Modulation, Power, FEC, etc?

OTSi layer (+OTN?)
Connection/CEP
not used for phase 1.0

Optical parameters
for line ports

via API (for Provider)step 2Connection between line port and client port

DSR layer
Connection/CEP
ConnectivityService/SEP

Port mapping between
line and client

via NBI (for Client)

DSR Connectivity Service (40G)x5x5

DSR Conn(40G)

TAPI Model for phase 1.0

x5

aggregate
DSR

DSR Link Conn(40G)

1..1x5

Link (40G)
Link (200G)
OTSi layer(ignored)

Transponder1

1..1x5aggregatex5
DSR
Not needed

for pre-configuration of
optical parameters
Transponder2

Current Status & Next Steps•••TAPI & OpenConfig model definitions for phase 1.0
Software development in progress
2 vendors’ transponders to be tested for the phase 1.0• Nokia• Infinera•

F-2-F Meeting planned in May• Agenda• Phase 1.0 summary• Phase 1.5 planning• Any other discussions (TBD)• Location• ONF Office in Menlo Park, California• To be announced soon...
20

Visit our Wiki and join us!
https://wiki.onosproject.org/display/ODTN/ODTN

21