Paper summary
Explain control traffic by controller function
An SDN controller’s traffic can be estimated from the operations it performs and the network it manages.
The study derives control-traffic models for ONOS, Floodlight and POX using their default applications. It analyzes exchanged packets and separates functions such as connection setup, discovery, statistics and forwarding.
Build a model from the controller’s individual functions
Mathematical terms relate control-message counts and sizes to switches, ports, hosts, flows and hop distances. The model separates connection setup, discovery, statistics collection, forwarding and other controller functions, then combines their contributions. This also explains why controllers can produce different traffic volumes on the same topology: their default applications perform different amounts of monitoring and discovery work.
| Input group | Quantities |
|---|---|
| Infrastructure | Switches, ports and hosts |
| Traffic | Flows and path hop counts |
| Controller behavior | Setup, discovery, statistics and forwarding functions |
Compare predicted traffic with measured traffic
Mininet experiments cover three fat-tree sizes and three ISP-topology configurations, using ONOS, Floodlight and POX. The paper reports 94.8% average prediction accuracy across its evaluation. It also identifies discrepancies caused by temporary traffic such as neighbor discovery, bootstrap and DNS requests. The estimates describe the analyzed controllers and default applications; a controller with different applications or polling behavior needs corresponding model terms.
View full-size figureKey takeaways
- Control traffic reflects what the controller does. Separating discovery, monitoring and flow processing explains why topology alone cannot determine message volume.
- An interpretable model can connect network structure to traffic demand. Function-specific terms combine switch, host, flow and path quantities into the prediction.