With the continuous advancement of multimedia technology, the volume of traffic generated by multimedia applications, such as online meetings and live video broadcasts, has been increasing steadily [1,2,3]. Multicast is a data transmission method that transmits packets along a distribution tree from data sources to a set of receivers by simply replicating the packets at branches of the multicast distribution tree [4,5,6]. Thus, multicast can effectively save network resources and improve bandwidth utilization. Multicast technology can be divided into network layer multicast, application layer multicast, and link layer multicast. Compared with the other two technologies, network layer multicast has greater scalability, as it has the ability to effectively avoid redundant data transmission and cover a wider network range. As a result, network-layer multicast has always been an important research topic.

According to Cisco’s annual internet report [7], the number of devices connected to the internet worldwide is expected to increase by 50% from 2018 to 2023. With the growth in the number of network devices, the number of multicast groups on the network is also expected to increase. In multicast technology, the multicast capacity, which refers to the number of multicast groups that the network can accommodate, is a very important indicator. The multicast capacity signifies the throughput and efficiency of the network, and is an important measure of the scalability of multicast technology. The selection method of multicast joining nodes (MJNs) has a significant influence on multicast capacity. When joining a multicast group, a group member first sends a request to a designated router (DR). Then, the DR selects a node in the existing multicast tree (known as a multicast joining node, or MJN) to establish a multicast distribution path from the MJN to itself. The MJN selection method running on the DR has a significant impact on the distribution of the multicast tree, which directly affects the load distribution in the network, and thus has a considerable impact on multicast capacity [8,9,10].

The main challenge faced by MJN selection methods is how to effectively detect the path load status between MJN and DR, especially in the case of asymmetric routing [4,8,9]. Due to the fact that asymmetric routing has become a common feature of networks, more and more multicast technologies are adopting a downlink multicast path to ensure the quality of multicast data transmission [1,11,12,13]. The establishment of downlink paths means that the multicast path is the shortest path from MJN to DR, which ensures that data can be transmitted from the multicast tree to the receiver with the shortest delay. In contrast to the downlink path, the uplink path means that the multicast path is the shortest path from DR to MJN, and multicast data will not be transmitted from the multicast tree to the receiver with the shortest delay, leading to a deterioration in the quality of multicast service. In order to establish low-load downlink multicast paths, DR must consider asymmetric routing when detecting multicast path load status, otherwise the load status of the upstream path will be detected, resulting in incorrect detection results. However, few existing MJN selection methods consider this. This defect makes it difficult for existing MJN selection methods to achieve good results in real environments. In addition, MJN selection methods should have low latency and distributed characteristics for practical engineering deployment.

In traditional TCP/IP multicast, WAVE [13] is an important MJN selection method that influences many multicast mechanisms [14,15,16,17].

This method requires the DR to first send a request to the root of the multicast tree. When the multicast tree root receives the request, it will forward the request along the multicast tree. Each multicast tree node that receives the request will reply to the DR with a probe message, that will collect the load status information along the way. Upon receiving the probe messages, the DR can understand the load status of the downlink multicast paths, and then select the path with the lowest load to join the multicast tree. This method is essentially a greedy method that selects the path with the lowest load to join the multicast tree each time. It can effectively deal with situations where the routing is asymmetric. However, because it requires probing all of the nodes on the multicast tree, this method can lead to long multicast service delays, heavy network loads, and difficulty in deploying in engineering environments.

In order to meet the deployment requirements in engineering environments, many mature TCP/IP multicast techniques directly select the root node of the multicast tree as the MJN. Among them, some multicast technologies construct source trees, in which the root node of the multicast tree is located at the data source. Therefore, the MJNs of these multicast technologies are data sources, such as PIM-SSM [18], PIM-DM [19], MOSPF [20], etc. There are also some multicast technologies that construct shared trees, in which the root node of the multicast tree is located at the core or Rendezvous Point(RP). Therefore, the MJNs of these multicast technologies are all cores or RPs. These MJN selection methods cannot consider the network load status, which may easily lead to network load congestion and limit the scalability of multicast.

In ICN, routing is based on the content name rather than the IP address. This name-based routing allows receivers to request data from any position on the multicast tree, which is beneficial for optimizing the path of multicast data transmission [21,22,23,24]. The following is an introduction to some of the MJN selection methods used in ICN multicast technologies.

ILDM [25] is a multicast technology based on ICN. This technology proposes a path-state-aware MJN selection method. The method requires the control plane to calculate the path from MJN to DR and to detect various load statuses. Upon obtaining the load status of the downlink multicast path, the control plane returns the MJN with the lowest path load to DR. The MJN selection method of ILDM is essentially the same as WAVE, both of which adopt a greedy strategy to select the path with the lowest load to join the multicast tree. The difference is that the path detection of WAVE is distributed, while ILDM utilizes the control plane. ILDM can effectively deal with asymmetric routing issues. However, ILDM is a centralized MJN selection mechanism, that requires the control plane to perform a large amount of calculation, resulting in long multicast service delays and high pressure on the central node.

Classic ICN solutions, such as DONA [26], CCN [27], and NDN [28,29] inherently support multicast. The multicast mechanism of these solutions aggregates identical data requests by preserving existing data forwarding paths, thus supporting multicast services. When selecting MJN in these multicast solutions, they essentially choose the node closest to the receiver. 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.