This is an archive of the ONOS 1.3 wiki. For the current ONOS wiki, look here.

Meetings related to this use case happen every two weeks; All of the slides from past meetings are available here.

Below are some notes and direct links.

Nov 4 2015

notes

  • Control plane topology - we'll stick to one logical controller sees all components (transponder, OCS/cross connect, ROADM, etc)
  • Connectivity matrix model (port-port connectivity constraints in DWDM's) for correct routing
    • Sample model based on YANG (a generic device connectivity model), but can be PCEP or anything else
    • For passing info to ONOS
      • i.e. "vendor X's transponder can't be reached from transponder of vendor Y"
      • Perhaps a tentative API on northbound, especially since we don't support YANG north
  • PoC storyboard.
    • Services that convey SLA + connectivity (like E-Line) and traditionally multicast, shifting to on-demand (like video)
    • CORD controllers (segmentrouting, vRouter)
      • our PoC doesn't focus on access technologies (G.Fast/GPON) connecting to CE
    • Metro cluster
      • uses aforementioned connectivity matrix between vRouter and ROADM
      • has no insight into CORD section of network
    • What is our inter-controller communication mechanism?
      • RPC-provider (bidirectional, using grpc as a starter) on metro controller side + Topology abstraction app on CORD controller
    • ROADMs w/ two transponders each from different vendors, connected to CORD-type deployment
      • All parts fit into a single rack (ROADMs/transponders, CORD HW + ctrls, Metro controllers)
    • Assume just one CORD rack as both a source and sink of service traffic (this is mostly for frugality).
      • We should be careful to show the traffic hair-pin route.
      • Also, hairpins might not be possible between two different vendor's transponders.
    • What are we showing?
      • Given that transponders behave, we'll be able to demo the interoperability at ROADM level.
      • We might be able to demo data-plane level interoperability at transponder level if we turn off FEC, modulation schemes match
        • but, it's a diff problem that we may or may not be able to solve, in which case, we need matching vendor endpoints.
  • Thoughts/comments?
    • GUI and observability? We need to think about it soon.
    • Supervisory channel/topology discovery amongst ROADMs - leave out for now and use network config system, though we will need it eventually.
    • Need to have vendors sanity check timeline/APIs

Oct 21 2015

notes

  • Metro architecture: What are the levels of interaction between CORD and metro controllers?
    • One idea to have metro controller see simplified topology for CORD domains (i.e., a big switch).
    • How to see resource outside of CO? How to look into avail resource for full path for i.e. QoS?
    • Response for fallback in case of failure? Who has what visibility into resource information?
  • It would be nice to have an interface (managerial/visualization/etc) to peer into everything.
    • The displayed data doesn't have to be literally available everywhere, and the visualization can be based on aggregated info
  • CORD sites (Huawei): E-Line across metro using CORD architecture
    • clarifications - VNFs instantiated by OpenStack (XOS), and ONOS learns about them via XOS's calculation results. XOS in turn knows about the services/chaining requirements since it creates the VMs/instantiates services.
  • E-Line storyboard: XOS and interaction between local/global ctrl's? open question (currernt capabilities of XOS, etc)
    • VNF - VM/Docker or a bundle in ONOS? the former. The latter just sets up flows to chain them together
    • There are two types of services, per-subscriber or multi-tenant.
    • ONOS just sees hosts, or maybe even just switches and acting on traffic
  • Dissagregated ROADM: Is the device controller per-device or rack/racks?
    • The mapping should be tunable depending on need of visibility to one versus all devices
    • Why not provide ONOS as a VNF? We probably don't want 20 ONOS for 20 racks, or per-domain configs, and that would fit into the model of global orchestration (which we need)

Sep 24 2015

Sep 9 2015

 

  • No labels