Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Open and Disaggregated Transport Networks Proje...

Open and Disaggregated Transport Networks Project (iPOP2018)

The presentation at the iPOP 2018 conference.
https://www.pilab.jp/ipop2018/info/onlineproceedings.html

Toru Furusawa

June 01, 2018
Tweet

More Decks by Toru Furusawa

Other Decks in Research

Transcript

  1. iPOP 2018, NICT, Koganei, Japan Page 1 ODTN - Open

    and Disaggregated Transport Network - Toru Furusawa, Xiaocheng Zhang, Hiroki Okui, Naoki Miyata, Shigenari Suzuki, Yuichiro Wada and Dai Kashiwa NTT Communications
  2. Page 2 iPOP 2018, NICT, Koganei, Japan Agenda • Our

    activity for Disaggregated Transport Networks • Technology Trends • Introduction of ODTN Project • Demo • Conclusion and Next Steps 2
  3. Page 3 iPOP 2018, NICT, Koganei, Japan Our Activity for

    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… 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. Page 4 iPOP 2018, NICT, Koganei, Japan 4 • 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 wavelength expansion Open Line Systems
  5. Page 5 iPOP 2018, NICT, Koganei, Japan 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. Page 6 iPOP 2018, NICT, Koganei, Japan 6 Topology Service

    Connectivity Service Path Computation Service Shared Network Information Context Virtual Network Service Notification Service NE Network Resource Groups NE NE SDN Controller NE NE SDN Controller NE NE Application Transport API Transport API Other SBIs ONF Driven API used for NBI and SBI of Transport Network Controllers ONF Transport API (TAPI)
  7. Page 7 iPOP 2018, NICT, Koganei, Japan Towards Full Open

    Architecture 7 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
  8. Page 8 iPOP 2018, NICT, Koganei, Japan ODTN Project •

    Started Open and Disaggregated Transport Network Project with ONF and other companies to build a open reference implementation • Bring eco-system together to – Build reference implementation using open source and open standards – Do lab and field trials • Consist of three phases – Plan/Retrospective meetings for each phase 8
  9. Page 9 iPOP 2018, NICT, Koganei, Japan ODTN Project •

    Started Open and Disaggregated Transport Networks Project with ONF and other companies to build a open reference implementation • Bring eco-system together to – Build reference implementation using open source and open standards – Do lab and field trials • Consist of three phases – Plan/Retrospective meetings for each phase 9
  10. Page 10 iPOP 2018, NICT, Koganei, Japan Project Members •

    5 Service Providers – China Unicom, Comcast, NTT Communications, TIM, Telefonica • 4 Tier 1 Vendors – NEC, Nokia, Oplink, ZTE • 6 Tier 2 Vendors – ADVA, Ciena, CoAdna, Coriant, Infinera, Lumentum
  11. Page 11 iPOP 2018, NICT, Koganei, Japan 11 Team Active

    Members Project Steering Comcast, NTT Com, Telefonica, 1 vendor, ONF Use Case Ciena, Comcast, Coriant, NEC, NTT Com, Nokia, Telefonica, TIM etc Software Development CTTC, NEC, 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 Teams
  12. Page 12 iPOP 2018, NICT, Koganei, Japan 12 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 Project Scope
  13. Page 13 iPOP 2018, NICT, Koganei, Japan 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 13 13 WSS TRN API Open Line System (OLS) API API MUX WSS AMP MUX TRN
  14. Page 14 iPOP 2018, NICT, Koganei, Japan 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 14 TRN ROADM ROADM ROADM ROADM TRN TRN TRN API API API API
  15. Page 15 iPOP 2018, NICT, Koganei, Japan 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 15 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
  16. Page 16 iPOP 2018, NICT, Koganei, Japan 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 Schedule
  17. Page 17 iPOP 2018, NICT, Koganei, Japan c.f. TAPI Model

    for the phase 1 17 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 1..1 1..1 OTSi layer(not used for the phase 1.0)
  18. Page 18 iPOP 2018, NICT, Koganei, Japan Demo Transponder (XT3300)

    Transponder (XT3300) 100G / NETCONF TAPI / REST API
  19. Page 19 iPOP 2018, NICT, Koganei, Japan Conclusion & Next

    Steps Conclusion • NTT Communications is developing Disaggregated Transport Networks • We have started ODTN project under ONF to create a reference implementation by using open source software and open common models – ONOS controller – TAPI – OpenConfig Next Steps • Start the phase 1.5 - using OLS in addition to transponders • Phase 2 planning 19
  20. Page 20 iPOP 2018, NICT, Koganei, Japan Visit our Wiki

    and join us! https://wiki.onosproject.org/display/ODTN/ODTN 20
  21. Page 21 iPOP 2018, NICT, Koganei, Japan 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 21 High Level Design