# A Reverse Shortest Path Tree-Based Multicast Joining Node Selection Method
## 2 Related Work
Data request packets sent by the receiver will be forwarded in the network according to specific rules, and the first node that has the requested data will become the MJN. This method is advantageous in shortening data forwarding paths, but it cannot perceive the network's load state, which can lead to congestion. As a famous ICN solution, PURSUIT [30] also proposes a multicast mechanism. The multicast mechanism in PURSUIT relies on the topology manager (TM). TM in PURSUIT encodes the forwarding path in the Bloom filter of the data packet. When the data packet reaches a forwarding node, the forwarding node only needs to perform an \"AND\" operation between the label of the outgoing link and the Bloom filter in the data packet. If there is any match, the data packet is forwarded through the corresponding link. Multicast transmission can be achieved by simply encoding the entire multicast tree into a single Bloom filter. This multicast method relies on the central management node TM. However, this method does not take into account the issue of routing asymmetry when calculating multicast trees. Moreover, the centralized calculation method is not conducive to improving multicast scalability. NOMA [31] is a multicast communication mechanism designed based on MobilityFirst. NOMA uses Global Name Resolution Service (GNMRS) as a mapping between identifiers and address locators. NOMA first assigns a unique name to each network node; all entities interested in receiving data from a multicast stream can register their unique name in GNMRS. Then, the multicast service manager near the gateway uses this information to construct a multicast tree based on available resources and the desired size of the tree. Then, recursively, the names of each branch router in the multicast tree are mapped to the multicast group identifier in GNMRS. Similar to ILDM, PURSUIT, etc., the construction and maintenance of the multicast tree in NOMA depends on the multicast management node. However, this method does not take into account the issue of routing asymmetry when calculating multicast trees. Moreover, the centralized calculation method is not conducive to improving multicast scalability. At the same time, when the multicast membership changes, this method requires recalculation of the multicast tree, which can have a significant impact on the quality of multicast services. In addition, there are many methods attempting to construct Steiner trees to the balance network load and improve multicast capacity. These methods include algorithms based on genetic algorithms [14; 15; 32], taboo search [33], greedy randomized adaptive search process [16; 34], simulated annealing [17; 35], and other ideas. Many of these algorithms also use greedy strategies proposed in WAVE [14; 15; 16; 17]. However, a common problem with these algorithms is that they rely on centralized computing paradigms and involve a large number of iterative calculations. This can lead to significant service delays and central node performance bottlenecks, which hinder the scalability of multicast. In addition, they have not been able to address the issue of routing asymmetry. In summary, some of the existing MJN selection methods are unable to consider the asymmetry of routing, such as most TCP/IP multicast protocols; some methods have high multicast processing delays and heavy network loads, such as WAVE; and some methods use a centralized computing paradigm, that is not conducive to improving multicast scalability, such as ILDM, PURSUIT, and NOMA. Therefore, there is a need for an MJN selection method that fully considers the asymmetry of routing, has low latency, and distributed characteristics.