# M-Emu: A Platform for Multicast Emulation
## 4 Validation
### Case Study
In this example, each node should register the MFT entry; therefore, when a node runs this interface, the return value is 1. The whole process of the emulation is shown in Figure 5.

After the above process, a multicast tree can be established in PIM-SM mode. According to Section 3.3, the _Statistical tools_ provided by M-Emu records data packet information in a certain format. Next, we give an example of how M-Emu records packet information. After A1 selects R1 as its RP, it sends data to R1 by unicast. When R1 receives multicast data from A1, it records the data as Figure 6. The meaning of the data in _Packet Type

Figure 5: The process of emulation of PIM-SM. can be found in Section 3.2. When C1 forwards the multicast data sent from R1 to A2, the multicast data is recorded as shown in Figure 7. When A2 receives multicast data from R1, it records the data as shown in Figure 8. It can be seen that _Statistical tools_ can accurately and comprehensively record the forwarding status of multicast packets on the network. According to the data packets recorded by all nodes, we can find the following key information:

* MFT load: R1, C1, A1 and A2 all need to maintain the multicast forwarding state for this multicast group, and thus their MFT load is +1. * Link Load: Links R1-C1, C1-A1 and C1-A2 all need to forward the multicast stream, and their load is 100 kb/s. * Multicast tree cost: The multicast tree forwards 100 bits of data through three links. Therefore, the Multicast tree cost is 300 bits. * End-to-end delay: According to the time stamp of each data packet, the time of sending data from A1 to A2 is 5 ms. In many cases, users want to emulate SBT rather than ST. At this point, the user simply adds each DR to the cRPs set and forces the DR to select itself as the root node. In addition, users can also adjust the RP-selection method and GP-selection method to build a more complex multicast tree. ### Emulation Performance

In this part, we test the performance of M-Emu and original NS4 in various aspects when deploying the experiments in Section 4.1. We require the data plane to execute multicast algorithms independently without interaction with the control plane. The reason for such a setting is that many researches require the data plane to have the ability to independently formulate and execute various algorithms [12; 13; 15]. For NS4, to enable the data plane to handle multicast protocols and algorithms independently, a natural thought would be to add a host, which we can call a service node, directly connected to each switch. The service nodes of NS4 operate as the service module of M-Emu, while the switch nodes of NS4 operate as the forwarding module of M-Emu. This approach is a degradation of M-Emu because it requires the deployment of additional nodes, resulting in increased system resource usage. Our experiments are conducted on a Dell R740 xd PowerEdge server with two Xeon(R) Gold 5218R CPUs and 300 GB RAM. The evaluation metrics include:

* Memory Consumption. This metric indicates the memory size required by the emulation platform to process a certain number of multicast flows. * CPU utilization. This metric indicates the CPU utilization by the emulation platform to process a certain number of multicast flows. Figure 8: Packet-Information 3. Figure 6: Packet-Information 1. * Traffic of Management Message. This metric indicates the traffic of various management messages when the same number of multicast flows (1000) are completed. * Packet Process time of Emu-Node. This metric indicates the time required for the emulation platform to interact with the real network. * Execution Time. This metric indicates the time required by the emulation platform to process a certain number of multicast flows. #### 4.2.1 Memory Consumption

We compare the memory consumption of each architecture in fat tree topologies when processing 1000 multicast flows.