ODTN - Open and Disaggregated Transport Networks -

The presentation at ONOS/CORD meetup in Tokyo, 2018.
Agenda:
http://www.e-side.co.jp/onoscordmeetup/#day2

PDF:
http://www.e-side.co.jp/onoscordmeetup/img/onos_2_furusawa.pdf

Transcript

1. ODTN - Open and Disaggregated Transport Networks - Toru Furusawa NTT Communications
2. Agenda • Technology Trends of Disaggregated Transport Networks • Introduction of ODTN Project • Project Scope • Members & Teams • Schedule • Software Design • Current Project Status & Next Steps 2
3. Technology Trends of Disaggregated Transport Networks ▪From All-in-One to Disaggregation ▪ Innovations and upgrades from “per all-in-one nodes” to “per each component” ▪ Integration from “in hardware” to “in software” ▪Active Open communities for disaggregated transport networks ▪ Open Line Systems ▪ OpenConfig ▪ TAPI etc… 3 Packet & Optical Transport Domain Access Domain MPLS VLAN/OTN OTN / WDM VNF From All-in-One to Disaggregation Transport NW Controller Orchestrator REST API NETCONF
4. 4 • Traditional optical line systems are integrated systems with a single vendor’s transponder, mux/demux, amp, ROADM Open Line Systems 4 • Open Line Systems are disaggregated systems composed of multi-vendor transponders • Possible to use preferred vendor’s transponder every time of wavelenth expansion
5. OpenConfig 5 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 & southbound protocol SDN Ctrl Model: OpenConfig Protocol: NETCONF/gNMI (out of scope) YANG
6. Transport API
   TAPI ONF Driven API used for NBI of Transport Network Controllers ONF TAPI 6
7. Towards Full Open Architecture with existing activities 7 Open NBI SDN Controller 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 SBI Open Ctrl Open Device Orchestrator Open Line System Transport API Vendor Controller <As-Is> <To-Be> Proprietary NBI Proprietary SBI Vendor Proprietary Device
8. ODTN Project 8 YANG NETCONF OLS / Disaggregation Data Model Language Open Protocol Common Data Model Open Source Controller Innovative Device Reference Architecture Component Project members
   As of 2018.4.20 We have launched “ODTN (Open and Disaggregated Transport Networks)” Project with ONF and other companies to build a open reference implementation with open technologies NBI TAPI
9. Project Members 9
10. 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
11. Project Scope 11 Point-to-Point SDN Controller Transport API (TAPI) YAN G YAN G (1) NBI Handler (3) SBI Driver (2) Service Application NETCONF RESTCONF Compile Compile Mapping Logic Implement (4) Integration Test (1) NBI Handler Compile YANG based service model Provide TAPI based NBI (2) Service Application Implement Java code to map TAPI to OpenConfig (3) SBI Driver Compile YANG based device model Configure device with OpenConfig model (4) Integration & Test
12. Phase 1: Point-to-Point Open Line System with Open APIs Goal • 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 2 Device Components • Transponder • OLS: mux/demux, in-line amplifier Term • Jan 2018 - Aug 2018 (8 months) • Phase 1.0 (transponder only): Jan 2018 – April 2018 • Phase 1.5 (transponder + OLS): May 2018 – August 2018 12 12 WSS TRN API Open Line System (OLS) API API MUX WSS AMP MUX TRN
13. Phase 2: Mesh Metro ROADM with Open APIs Goal • 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 Term • Sep 2018 – April 2019 13 TRN ROADM ROADM ROADM ROADM TRN TRN TRN API API API API
14. Phase 3: Full Disaggregated ROADM with Open APIs Goal • 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 Device Components • Transponder, WSS, AMP, AOS, etc. (details TBD) Term • May 2019 - Dec 2019 14 TRN TRN TRN TRN Client ports (add) To/from packet layer WSS AMP AOS Client ports (drop) Line ports Single wavelength To/from network control EMS To/from remote ROADM API API API API API
15. Project Teams 15 Team 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 Team
16. Schedule Phase2 Mesh ROADM Phase1 Point-to-Point Jan Feb Mar Apr May June July Aug Sep Result & Plan Workshop Oct Dev & integration Initial devices + α Dev & interchangeability test + additional devices ODTN Kickoff Result & Plan Workshop Dev & integration TBD ONS talk OFC talk Nov Dec Result & Plan Workshop ECOC Phase 1.0 – Transponder only Phase 1.5 – Transponder + OLS
17. App Network Service Request Instruction to device TAPI over RESTCONF OpenConfig over NETCONF Transponder Transponder OLS Driver X Driver Y Driver Z Solves constrained path Manage resources Generate device control and configuration Map imposed semantics to commands that device understands Protocol handling Understand semantics of request SB driver layer Control logic NB API mediation layer High Level Design 17
18. Model Definition work by Use Case Team (0. Scope Clarification and TAPI Model Selection) 1. TAPI NBI Selection 2. TAPI Parameter Mapping (ConnectivityService/SEP -> Connection/CEP) 3. TAPI Parameter Selection (Connection/CEP) mapped to SB 4. Parameter Mapping from TAPI (Connection/CEP) to OpenConfig (different for each vendor) 5. OpenConfig SB Model Selection (different for each vendor) 18 Orchestrator ConnnectivityService/SEP ↓ Connection/CEP Connection/CEP ↓ OpenConfig/CEP Connection/CEP ↓ OpenConfig/CEP Transponder Transponder Transponder Connection/CEP ↓ OpenConfig 1 2 3 5 4 common NBI(RESTCONF) NETCONF different for each vendor Model Discussion slide in Use Case Team
19. Transponder1 Transponder2 aggregate aggregate Link (200G) Link (40G) DSR DSR DSR Link Conn(40G) DSR Conn(40G) DSR Connectivity Service (40G) x5 x5 x5 x5 x5 x5 TAPI Model for phase 1.0 1..1 1..1 OTSi layer(ignored) Must be done in advance ODTN Scope for Phase 1.0 Configured Parameters TAPI OpenConfig How to configure step 0 Topology Transponder, Fiber, Link ports, Client ports (for Phase1.0) Link, Node, NEP, SIP n/a via API (for Provider) or Auto-generated (e.g. using show cmd or LLDP) 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 2 Connection between line port and client port DSR layer Connection/CEP ConnectivityService/SEP Port mapping between line and client via NBI (for Client) Configurable w/ OrangeBox Not needed for pre-configuration of optical parameters Model Discussion slide in Use Case Team
20. 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
21. Visit our Wiki and join us! https://wiki.onosproject.org/display/ODTN/ODTN 21