# Delay Bounded Multi-Source Multicast in Software-Defined Networking
## 3 Architecture  
The design of the DBMS SDN system is illustrated in Figure 2. Four modules are designed for the DBMS scheme in the control plane.  
**Traffic Delay Cost Measurement Module:** This module is tasked with implementing traffic delay cost on network links using tracking, and reports each link delay cost as defined in Section 4 every time a routing calculation is performed. Traffic delay cost is implemented through periodic polling of all switches in the network with OpenFlow queries (as defined in the OpenFlow v1.0 specification [27]), similar to the approaches presented in [28; 29]. The controller reads the counters from all flows on all switches at a fixed measurement interval, analyzes the counters, and generates statistics to report to the network operators. The controller also dynamically adapts the rules based on the counter values from previous measurement intervals. In practice, this interval is limited by how quickly the controller can read the counters from the flows and generate the rules for the next interval. In our experiments, the interval ranges from seconds to minutes. Query times for each switch are randomly staggered, based on the time at which the switch first connected to the controller. This approach has known drawbacks, as continually polling the network introduces potentially unnecessary overhead in the control plane. This implementation could be improved by adopting a passive utilization tracking approach, such as the approach presented in [30]. This module maintains a map of least delay cost links keyed by switch DPID and port number, which the module queries when calculating total delay cost. When calculating link delay cost, it is assumed that all tracked links in the network have a uniform maximum bandwidth since there is no mechanism for querying the maximum bandwidth supported by a particular port in OpenFlow 1.0. This mechanism is provided in later versions of the OpenFlow specification.  
**Topology Discovery Module:** This module implements topology discovery through Link Layer Discovery Protocol (LLDP) polling. By using the information obtained from the topology discovery module we can construct the network topology graph \(G(V,E)\), where the node set \(V\) corresponds to  
Figure 2: DBMS proposed Architecture.  
the switches and the link set \(E\) corresponds to the links. Then, the data that is relative to the topology graph \(G\) would be sent to the tree construction module to build up the tree.  
**Source Node Selection Module:** This module work closely with the Tree Construction module since for a tree to be constructed the information about its root is very vital. This module is responsible for selecting a potential source node from the potential source nodes set \(\left\lvert S\right\rvert\). After the topology has been discovered, this module will get the information about the destination nodes set \(\left\lvert D\right\rvert\) and the potential source nodes set \(\left\lvert S\right\rvert\). This information is then used to select the potential source node for each multicast nodes based on the MILP presented in Section 4 using Algorithm 3.  
**Multicast Routing Model Module:** This module implements detection of multicast potential sources, multicast tree calculation, and installation/removal of OpenFlow rules to direct multicast traffic. Least delay path tree calculation is performed for each combination of multicast potential source IP address and destination IP address using DBMS-DelayPath Algorithm 1. Whenever a multicast receiver joins or leaves a multicast group for which a potential source has been identified, the multicast tree calculation and flow installation is performed. Routing is considered separately for each multicast group, and no flow aggregation between separate multicast groups is implemented.