This series of tests are designed to characterize ONOS core's intrinsic response time in a single Openflow event. The events characterized are switch connection and port up/down. We expect single-node ONOS to have a fast event response time. As the cluster size grows, we expect the overhead of communicating the events throughout the cluster should add additional latency to the response time. We determine that a link event is not a good vehicle to run the latency test. This is because that latency will be largely dominated by the LLDP packet timing. The resulted latency will show no intrinsic behavior of ONOS core.
In order to have accurate accounts of event timing among all nodes of the cluster, we first have to establish a synchronous clock using PTP protocol among the tester and ONOS nodes.
We use OVS switch(OF v 1.3) to emulate a switch first establish connection with ONOS. For more about the connection protocols, you may refer to the Openflow specification for the details. As the switch establishes the connection with ONOS, it triggers a set of OF message exchanges, and subsequently generate ONOS device event and graph event. Those events are also communicated throughout the cluster.
In order to only characterize the ONOS core's intrinsic response time, we eliminate the external effect's such as tcp handshake time by starting a timer (t0) when tcp "SYN/ACK" is detected at the ONOS node with TSHARK. Subsequently, we obtain the latest event-type timestamps (t2_a and t2_c) from "topology-events-metrics", from all nodes of the cluster. The latest timestamps reported by all nodes of the cluster is used as the response time of ONOS as a system. The latency is calculated as the difference of these timestamps and t0.
Results from multiple runs are used to collect statistical mean and deviation.
Diagram illustrating timing of a OVS switch add triggering a chain of ONOS events, eventually registering a Graph event in ONOS.
Method used for this measurement is similar to switch event latency measurement. There are a number of differences in the method. Instead of switch connection event,we use a port up/down activity as the event. In this case, a two-switch/single-link topology is used - simply started with Mininet. Similarly, in order to characterize the intrinsic core capability and eliminate external effects, the starting timestamp of "t0" is when we TSHARK to detect Openflow message of port status after we trigger the event on the OVS switch.
Diagram illustrating timing of a chain of ONOS events when an OVS switch port is brought up or down.