Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. The largest portion of time spent in the discovery is from initial tcp connection to Openflow features-reply message received on ONOS. A further dissecting of the packets (not shown in the result graph), we can see majority of this time spent is ONOS waiting for OVS switch responding to its features_request in the initial Openflow handshake between the controller and the switch. This is a timing largely independent of ONOS processing.
  2. The second largest portion of the time spent is between "OFP feature reply -> OFP role request". This timing also increases with the ONOS cluster scale. This is the time spent when ONOS processes mastership election for the newly attached switch. ONOS if in standalone processes this locally, while in a multi-node cluster, additional delay incurs with   communication among nodes.
  3. The next time consuming process is from the Openflow handshake completes (OFP role reply), to when ONOS registers a Device event. This ONOS processing time is also affected by multi-node ONOS configuration This event requires ONOS writing of the event to the Device Store.
  4. The last timing is related to ONOS' node locally processing the Device event from the Device Store to registering Topology event in the Graph.

On a link switch down event, there is a slight increase of ONOS triggering Device event as cluster size scales.