Page History

...

We enable Null Providers to be the consumer of the flow rules, bypassing Openflow Adaptors and the potential performance limitation of using real or emulated switches. 

Specific to this For the experiment we run ran for this release, we use used the following parameters:

• The total number of Null Devices used is a constant, 35 - their masterships are "mastership is equally " assigned to all nodes in the cluster, ex. when running a 5-node cluster, each node has masterships of seven devices;
• The total number of flow rules to install for the cluster is 122,500 - this number is chosen so that it is large enough a size, and also easily split to the cluster sizes under test. From there we calculate the number of flows to be install on each switch as a argument for the "flow-tester.py" tool.
• We test two most relevant scenarios: 1) when number of Neighbors is zero, which is  the case where all flow rules are to be install locating on the generating node; 2) when number of Neighbors is (cluster size -1), i.e. each node generator generate flow rule for itself and all other nodes in the cluster.
• We run the experiment with cluster size of 1, 3, 5 , and 7.
• The response time is gathered with a statistical integration of 20 (after 4 5 warm-up runs).

 Note: At the time of release, ONOS core still utilizes Hazelcast as the store protocol for backing up flow rules. Experiments showed that using this back up can cause high variation of the flow rule burst install rate. In this experiment, we run this set of experiments with flow rule backup turned off from the released code (under "$ONOS_ROOT/core/store/dist/src/main/java/org/onosproject/store/flow/impl/DistributedFlowRuleStore.java)