This set of tests aims to characterize ONOS' latencies (i.e. response time) when an application installs, withdraws various batch-size intents. Also we characterize ONOS' response time in an event when the installed intents need to be re-routed due to a path change, e.g. the shortest path is no longer available. This is a test to exercise ONOS from top of stack at NB API, through intent and flow subsystems, to the bottom of the stack in SB API, with some effects of substituting Openflow Adaptor with Null Providers. The results of this set of test should provide network operators and application developers with a "first look" of the response time applications can expect when operating intents, in terms of how large the batch intents is, and how the cluster size affect the response time.
Referring to the following diagram, we use ONOS built-in app "push-test-intent" to push a batch of point-to-point intents from ONOS1 through its intent API. The utility constructs a set of intents based on the end points , batch size, and application id. It then pushes those intents through the intent API. When all intents are successfully installed, it returns the latency (response time). It subsequently withdraws those intents and returns a withdraw response time. When intents are pushed, ONOS internally compiles the intents to flow rules and write to the necessary distributed stores to distribute the intents and flows.
Referring to the diagram below. Particularly to our experiment, the intents constructed are end-to-end on a seven linear switch configuration, i.e. ingress of all intents are from one port of S1 and their egress is a port on S7. (We use an additional switch S8 in the topology for intent re-route tests, which is described next.) We use Null Providers to construct the switches (Null Devices) and topology (Null Links) and consume the flows (Null Flows) through them. As we scale the cluster size out, we reassign the masterships of the switches to "equally" distributed among the cluster nodes.
In this experiment, we will use the following parameters to characterize ONOS performance:
Also referring to the same diagram above, the intent re-route latency is a test to characterize ONOS performance in a event that the shortest path is no longer available, how quickly ONOS reacts to this event by reinstalling all intents to the new path. The sequence of the test are highlighted below: