An Adaptive Hierarchical Hybrid Multicast Based on Information-Centric Networking

Abstract

Many information-centric services have emerged, such as IPTV and video conferencing. These services put a lot of demands on scalable multicast communication. However, traditional IP multicast has low adoption because of its poor scalability. Therefore, some stateless multicast methods were proposed, which encapsulate the destination’s information into the packet header without requiring routers to maintain the multicast forwarding state. However, stateless multicast also faces some problems, such as ingress router overload, high forwarding overhead, packet redundancy, etc. In addition, most multicast methods cannot optimize the multicast tree because the multicast flow is simply forwarded along the shortest path tree from the source to receivers. This paper proposes an Adaptive Hierarchical Hybrid Multicast (AHHM) based on Information-Centric Networking. To balance the forwarding states and forwarding overhead, AHHM is designed as a two-layer structure, in which the upper layer establishes a stateful main tree and the lower layer establishes several stateless sub trees. The router on the main tree is defined as the multicast join node (MJN), and AHHM uses the Name Resolution System to maintain the mapping between each multicast group name and corresponding MJNs. To optimize the multicast transmission path, we designed the minimum cost selection strategy for users to select the appropriate MJN to join. Simulation results show that compared with Source-Specific Multicast (SSM) and Bit Index Explicit Replication (BIER), AHHM can not only reduce the multicast forwarding states but also reduce the control overhead and link load.

1. Introduction

With the development of the internet, people are more concerned about information itself rather than where to obtain it. A large number of information-centric services have emerged, such as software updates, video conferencing, multiplayer online games, distance education, and live broadcast. These services put forward scalable communication needs from an information producer to many interested information consumers. Due to the advantages of saving network and server resources, multicast is more suitable for these services than unicast. However, traditional IP multicast methods (such as PIM-SM [1], DVMRP [2], SSM [3], etc.) need to establish a stateful delivery tree for each group, and on-tree routers need to maintain the multicast forwarding state. The number of multicast forwarding states increases with the number of groups, which limits the scalability and adoption of traditional IP multicast methods [4].

In order to improve the scalability, some stateless multicast methods (such as Xcast [5], DOM [6], BIER [7], etc.) are proposed. For each group, the stateless multicast establishes a stateless delivery tree, in which the root node encapsulates destinations into the multicast packet header, and intermediate nodes directly forward the multicast packet according to destinations in the header without the need to maintain the forwarding state. However, there are still some problems in stateless multicast. First, the root node needs to track destinations information and attach destinations information into the header for the multicast packet, which brings a huge load to the root node. Second, the intermediate router needs to process the destinations information in the header when forwarding the multicast packet, which increases the forwarding cost. Third, the header size increases with the group size, which increases bandwidth consumption. As the most representative stateless multicast method, BIER [7] encodes the destinations into a bit string to reduce the header length. However, when the network size is larger than the length of the bit string, BIER needs to divide destinations into different Set Identifiers (SIs) and copy a packet for each SI, which leads to packet redundancy [8]. In addition, both stateful multicast and stateless multicast forward multicast flow from the root node to a set of receivers along the shortest path tree, which leads to overload of some nodes and links.

Information-Centric Networking (ICN) [9,10,11] was proposed to meet the new requirements of the internet and transmit information more efficiently. Some clean-slate ICN methods use the name-based routing mechanism [12], such as Named Data Networking (NDN) [13]. Due to the need for routers to store a large amount of routing states of information objects, the scalability of these methods is low. Besides, these ICN methods cannot be deployed on a large scale due to the high deployment costs [14]. Some other ICN methods (such as MobilityFirst [15]) that use the name resolution mechanism can coexist with existing IP networks to achieve incremental deployment [16]. These methods use a name resolution system (NRS) to map names to locators and then route requests to the source based on the locator.

In this paper, we propose an adaptive hierarchical hybrid multicast (AHHM) approach based on ICN to improve the scalability of multicast. AHHM is designed as a two-layer structure, in which the upper layer establishes a stateful main tree and the lower layer establishes several stateless sub trees. To balance the forwarding overhead and forwarding states, AHHM uses the stateless mode on routers with more states and uses the stateful mode on routers with fewer states. By adaptively adding stateless sub trees rooted at different MJNs, the destinations information that needs to be tracked is balanced to different roots of sub trees. The router on the main tree is defined as the multicast join node (MJN). AHHM uses the NRS to maintain the mapping between each multicast group name and MJNs. To optimize the multicast transmission path, we designed a minimum cost selection strategy for users to select the appropriate MJN to join the multicast group. We evaluated the performance of AHHM through a series of experiments. The experiment results show that: (1) the control overhead of AHHM is much smaller than that of BIER; (2) the multicast forwarding state of AHHM is much smaller than that of SSM but slightly higher than that of BIER; (3) the link load of AHHM is less than that of SSM and BIER.

The rest of the paper is organized as follows. We introduce related researches in Section 2. Then, we describe the system design of the proposed AHHM in Section 3 and introduce the multicast mechanism in detail in Section 4. In Section 5, we present the experimental setups and the evaluation results. Finally, we conclude our paper in Section 6.

2. Related Work

In the stateless multicast, the root node (such as source, source-side edge router, etc.) needs to track the destinations (such as receiver, receiver-side edge router, etc.) of the group. Some stateless multicast methods directly attach the destination’s information (such as the IP addresses of receivers) into the multicast packet header. Therefore, intermediate routers can forward the multicast packet according to the destination’s information in the header without the need to maintain the forwarding state. In order to reduce the packet header length, other stateless multicast methods first compress the destinations information and then attach the compressed destinations information to the packet header.

In Small Group Multicast (SGM) [17], Connectionless Multicast (CLM) [18], Xcast [5], and Multicast for Small Conferences (MSC) [19], the router divides the destinations into different sets according to the next hop of the destination. Then, it copies a packet for each set and forwards the packet with the appropriate header, which contains all the destinations in the set. Due to the limited size of the header, these protocols are only suitable for scenarios with a small number of receivers.

Xcast+ [20] combines Xcast with the Internet Group Management Protocol (IGMP) [21] to improve scalability. By encoding the Designated Routers (DRs) at receivers’ sides into the header instead of receivers, the size of the header can be reduced. Generalized Xcast (GXcast) [22] was proposed to solve the problem that these protocols do not support IP fragmentation.

As another method similar to Xcast, Sender Initiated Multicast (SIM) [23] can reduce the forwarding cost in Xcast. SIM proposes to use Bitmap technology to compress the receiver address list carried in the packet header. SIM has two forwarding modes: list mode and preset mode. The source always appends the receiver list to the multicast packet in the list mode and periodically appends the receiver list to the packet in the preset mode. In the preset mode, the router that supports SIM protocol maintains a table similar to NFT to forward SIM packets, which severely limits the scalability of SIM.

In order to reduce the header size, DOM [6] encodes the destinations into a bloom filter. Each router uses unicast IP routing information to determine the necessary copies and forwarding interfaces. However, the bloom filter has the problem of error rate, which leads to loops, packet storms, and other problems.

BIER [7] is proposed by IETF to improve the scalability of multicast. The ingress router encapsulates a bit string to each multicast packet. Each bit of the bit string is mapped to an egress router. The intermediate router just forwards the BIER packet according to the Bit Index Forwarding Table (BIFT). However, when the number of egress routers is larger than the length of the bit string, BIER needs to divide these egress routers into different Set Identifiers (SIs) and duplicate a packet for each SI, which brings the problem of packet redundancy. Hierarchical Forwarding Bit Index Explicit Replication (HF-BIER) [8] was proposed to solve the packet redundancy problem of BIER in large-scale networks.

Multicast Design for the MobilityFirst (MMF) [24] manages multicast groups by using the global name resolution service (GNRS) to map the multicast name to the addresses of receivers. MMF appends the names of receivers as additional destinations to the packet header and employs bitmap to compress the destinations. However, in MMF, the source needs to deal with the joining and leaving requests of each receiver, which brings great pressure on the source.

3. System Overview

AHHM completely separates the identifier from the location by using Entity-ID (EID) as the identifier and Network Address (NA) as the locator. All elements in the network are treated as entities, including devices, contents, services, etc. Each entity is assigned a fixed-length flat and globally unique EID. NA can be represented by IP address to be compatible with existing IP networks. NRS is used to map the EID to one or multiple NAs. In AHHM, each multicast group is assigned a Multicast Group EID (MGEID). Receivers can easily join or leave a multicast group based on the MGEID. Compared with multicast IP addresses, MGEID has a larger namespace so that more multicast groups can be enabled. Meanwhile, MGEID also eliminates the need for complicated multicast IP address management and allocation mechanisms, such as MASC [25].

AHHM is designed as a two-layer structure, in which the upper layer uses the stateful mode and the lower layer uses the stateless mode. Single-layer stateful (or stateless) multicast can be regarded as the special form of AHHM. Figure 1 is an example of the proposed AHHM system, which consists of a multicast source, receivers, AHHM routers, and NRS.

The AHHM router contains some modules, such as Topology-based Routing Table (TBRT), Name Forwarding Table (NFT), Group Map Table (GMT), and BIFT. TBRT maintains topology-based routing information to forward packets based on the NA. NFT maintains name forwarding information to forward packets based on the EID. Each router is set with an NFT load threshold, which means that the network performance will be greatly affected when the NFT load is greater than it. In order to support the stateless mode, each edge router is assigned a globally unique router ID (RID). The RID indicates which bit in the bit string represents the router. GMT maintains the RIDs of the egress routers corresponding to each MGEID. The router can forward the multicast packet according to the bit string through the BIFT, which is generated according to the topology-based routing information.

For each multicast group, AHHM establishes a stateful main tree similar to traditional IP Multicast in the upper layer and several stateless sub trees using the BIER mechanism in the lower layer.

In the stateful main tree, the root node is the source-side edge router (SER), and the leaf node is the receiver-side edge router (RER) or the root node of the lower-level sub tree. The router on the main tree needs to maintain the multicast forwarding state for the group in its NFT. After the router receives the multicast packet, it searches for the matching entry in its NFT and then quickly replicates and forwards the packet according to the matching NFT entry. The NFT entry has the following format:

<MGEID, Parent NA, Out-Interface List>

where MGEID identifies the group; Parent NA is the NA of the parent node on the main tree; Out-Interface List maintains outgoing interfaces used to forward multicast packets identified by the MGEID.

In the stateless sub tree, the root node is a node on the main tree, and the leaf node is the RER. The root node keeps track of the destinations it wants to send packets to by maintaining the leaf node’s information of the sub tree in its GMT. The GMT entry has the following format:

<MGEID, RER list>

where MGEID identifies the group; RER List maintains the RIDs of leaf nodes of this sub tree. The root node encodes the list of RERs into a bit string and attaches the bit string into the header. Intermediate nodes on the sub tree directly forward the multicast packet according to the bit string without maintaining the forwarding state. The leaf node clears the bit string in the multicast packet and delivers the packet to receivers.

The router on the main tree is defined as the multicast joining node (MJN) of the group. NRS maintains the mapping between each MGEID and the NAs of MJNs corresponding to the group. Unlike most multicast methods, simply forward the multicast flow along the shortest path tree from the source to receivers; users can obtain the MJNs of the group they are interested in through NRS and then select the appropriate MJN to join according to the given MJN selection strategy in AHHM. We can design a suitable MJN selection strategy according to the usage scenarios and optimization goals to optimize the multicast transmission path.

In the process of establishing the multicast communication from the MJN to the receiver, AHHM preferentially uses the stateful mode and then converts to the stateless mode when encountering the router whose NFT load reaches the threshold. By adaptively using the stateful mode on routers with fewer forwarding states and using the stateless mode on routers with more forwarding states, AHHM can effectively balance the forwarding overhead and forwarding states.

In the stateless multicast methods, the root node needs to track destinations and attaches destinations information to each multicast packet, which puts great load pressure on the root. In AHHM, only part of the destinations information needs to be maintained, and the destinations information that needs to be maintained is balanced on root nodes of multiple stateless sub trees. Therefore, AHHM can avoid the problem of root overload faced in other stateless multicast methods. Besides, AHHM can alleviate the problem of multicast packet redundancy faced in BIER because the number of egress routers in each stateless sub tree is much smaller.

4. Multicast Mechanism

The multicast source can send multicast packets without knowing the group members. After receiving the multicast packet identified by the MGEID for the first time, the SER needs to initialize the NFT entry of the MGEID and register the mapping between the MGEID and its NA with NRS. The establishment and destruction of multicast communication are completed through control signalings. The receiver can send the corresponding control signaling to join or leave the specified multicast group. In this section, we introduce the multicast mechanism of AHHM in detail from four aspects: joining a group, MJN selection, leaving a group, and data forwarding.

4.1. Joining a Group

The process of the receiver joining the multicast group is shown in Figure 2. If a receiver is interested in the multicast group identified by the MGEID, it informs the RER it connected to join the group (arrow 1). Then, the RER checks whether it contains the NFT entry of the MGEID (arrow 2). If so, the RER just inserts the interface connected to the receiver into the out-interface list of the NFT entry. Otherwise, the RER needs to initialize the NFT entry in which the Parent NA is empty, query the NRS for corresponding MJNs (arrows 3-4), select an appropriate MJN according to the given selection strategy, and then send a JOIN REQUEST message to the selected MJN (arrow 5).

After receiving the JOIN REQUEST message, the selected MJN checks whether the NFT load of the next router from it to the RER reaches the threshold (arrow 6). If the NFT load of the next router reaches the threshold, the MJN first inserts the mapping between the MGEID and the RID of the RER into its GMT and then replies to RER with a JOIN RESPONSE message in which the State Flag is set to stateless and the Parent NA is set to its NA (arrow 7). If the NFT load of the next router is less than the threshold, the MJN first inserts the forwarding interface from it to the RER into the out-interface list of the NFT entry corresponding to the MGEID and then replies to the RER with a JOIN RESPONSE message in which the State Flag is set to stateful and Parent NA is set to its NA (arrow 7).

When the intermediate router receives the JOIN RESPONSE message, it checks the State Flag of the message (arrow 8). For the JOIN RESPONSE message in which the State Flag is stateless, the intermediate router sends the message directly to the RER (arrow 11). For the JOIN RESPONSE message in which the State Flag is stateful, the intermediate router first registers the mapping between MGEID and its NA with NRS (arrow 9). Then, the router determines whether the NFT load of the next router from it to the RER reaches the threshold (arrow 10). If so, it performs the following steps: (1) initializes the NFT entry in which the Parent NA is set to the Parent NA carried in the message and the out-interface list is empty; (2) inserts the mapping between the MGEID and the RID of the RER into its GMT; (3) modifies the State Flag of the message to stateless and the Parent NA of the message to its NA; (4) forwards the message to the RER (arrow 11). If the NFT load of the next router is less than the threshold, the router also needs to perform some steps: (1) initialize the NFT entry in which the Parent NA is set to the Parent NA carried in the message and the out-interface list contains the forwarding interface from it to the RER; (2) modify the Parent NA of the message to its NA; (3) forward the message to the RER (arrow 11).

When the RER receives the JOIN RESPONSE message sent to it, it sets the Parent NA in the NFT entry of the MGEID to the Parent NA carried in the message. Then, it checks the State Flag of the received JOIN RESPONSE message (arrow 12). If the State Flag is set to stateful, the RER needs to register the mapping between MGEID and its NA with NRS (arrow 13).

Taking the nearest MJN selection strategy as an example, we illustrate the joining process of the proposed AHHM approach in detail in Figure 3. In the multicast group identified by MGEID₁, N1 is the MJN, and receivers R1, R2, and R3 want to join the multicast group. N1 has already initialized the NFT entry of MGEID₁ and registered the mapping between MGEID₁ and NA_N1 with NRS.

As shown in Figure 3a, R1 informs N6 that it wants to join the multicast group identified by MGEID₁. N6 initializes the NFT entry <-, MGEID₁, 2> and obtains that the MJN of the group is NA_N1 by querying NRS. Then, N6 sends a JOIN REQUEST message to N1. After receiving the JOIN REQUEST message sent from N6, N1 finds that the NFT load of the next router (N2) from it to N6 is less than the threshold. Thus, N1 inserts the forwarding interface (2) into the out-interface list of the NFT entry and then replies to N6 with a JOIN RESPONSE message, in which the State Flag is set to stateful and Parent NA is set to NA_N1. After receiving the JOIN RESPONSE message, N2 first registers the mapping between MGEID₁ and NA_N2 with NRS. Then, N2 finds that the NFT load of the next router (N4) from it to N6 reaches the threshold, so it adds the NFT entry <NA_N1, MGEID₁, -> and adds the GMT entry <MGEID₁, RID_N6>. Finally, N2 sets the State Flag in the message to stateless, modifies the Parent NA of the message to NA_N2, and forwards the message to N6. N4 just forwards the JOIN RESPONSE message with the stateless flag to N6. When N6 receives the JOIN RESPONSE message, it sets the Parent NA of the NFT entry to NA_N2.

As shown in Figure 3b, when N7 is notified that R2 wants to join the multicast group identified by MGEID₁, it first initializes the NFT entry <-, MGEID₁, 2>. Then, N7 obtains that MJNs of the group are NA_N1 and NA_N2 by querying NRS. N7 selects the nearest NA (NA_N1) as target MJN and sends a JOIN REQUEST message to the N1. After receiving the JOIN REQUEST message, N1 finds that the NFT load of the next router (N3) from it to N7 reaches the threshold. Thus, N1 adds the GMT entry <MGEID₁, RID_N7> and replies to N7 with a JOIN RESPONSE message in which the State Flag is set to stateless and Parent NA is set to NA_N1. N3 and N5 directly forward the JOIN RESPONSE message with the stateless flag to N7. After receiving the JOIN RESPONSE message, N7 sets the Parent NA of the NFT entry to NA_N1. As shown in Figure 3c, when R3 informs N7 that it wants to join the multicast group identified by MGEID₁, N7 directly inserts the interface (3) connected to R3 into the out-interface list of the NFT entry corresponding to MGEID₁.

4.2. MJN Selection

In AHHM, NRS maintains the mapping between each MGEID and NAs of the corresponding MJNs. When the RER is notified that the receiver connected to it wants to join a multicast group, it can obtain MJNs through NRS and then select a suitable MJN to join according to different strategies. For example, the RER can simply select the nearest MJN from the resolved MJNs to join.

To balance distance, forwarding state, and link load, we also designed a minimum cost MJN selection strategy. The comprehensive cost is expressed as Equation (1).

$$\mathrm{cost}=\mathsf{\alpha }·\frac{D}{D_{max}}+\beta ·\frac{PS}{S_{max}}+\gamma ·\frac{PT}{T_{max}}, \left(\mathsf{\alpha }+\mathsf{\beta }+\mathsf{\gamma }=1\right)$$

(1)

D is the distance from the user to the MJN. $D_{max}$ is the network diameter that is defined as the distance between the two farthest nodes in the network. $S_{max}$ is the maximum number of entries that the NFT of the router can support. $T_{max}$ is the bandwidth of the link. We traverse the routers on the path from the MJN to the RER until the NFT load of a router reaches the threshold. The maximum NFT entry number of the traversed routers is defined as the value of the path states (PS). We use the maximum link load on the path from the MJN to the RER as the value of the path traffic (PT).

The RER can select the MJN with the minimum comprehensive cost according to Algorithm 1. For each MJN, the RER first calculates the path from MJN to it (line 4). Second, the RER checks whether intermediate nodes of the path contain the MJN corresponding to the multicast group. If so, the RER discards the MJN (lines 5–10). Third, the RER calculates the PS (lines 12–18) and PT (lines 19–23) corresponding to the MJN. Fourth, the RER calculates the cost corresponding to the MJN according to the given parameters (line 24). Finally, the RER chooses the MJN with the minimum cost as the target MJN to join.

Algorithm 1. Minimum Cost MJN Selection Algorithm
	Input: $\left\{MJN\right\}$
	Output: $MJ{N}_{sel}$
1:	Initialization: $MJ{N}_{sel}= \varnothing ,C_{min}=\infty , D_{max}, S_{max}, T_{max}, \alpha , \beta , \gamma ,$
2:	for each $MTN$ in $\left\{MJN\right\}$ do
3:	Initialize $C=0, PS=0, PT=0, Flag=\mathrm{True}$
4:	Obtain the path from the $MJN$ to the user
5:	for each router on the path do
6:	if the router in the $\left\{MJN\right\}$ then
7:	$Flag=\mathrm{False}$
8:	break
9:	end if
10:	end for
11:	if $Flag=\mathrm{True}$ then
12:	for each router on the path do
13:	if the NFT entry number of the router reaches the threshold then
14:	Break
15:	else if the NFT entry number of the router is larger than $PS$ then
16:	Set the $PS$ to the NFT entry number of the router
17:	end if
18:	end for
19:	for each link on the path do
20:	if the load of the link is larger than $PT$ then
21:	Set the $PT$ to the load of the link
22:	end if
23:	end for
24:	$C=\alpha ·\frac{D}{D_{max}}+\beta ·\frac{PS}{S_{max}}+\gamma ·\frac{PT}{T_{max}}$
25:	if $C<C_{min}$ then
26:	$C_{min}=C, MJ{N}_{sel}=MJN$
27:	end if
28:	end if
29:	end for
30:	return $MJ{N}_{sel}$

However, RER needs to detect the status of routers and links when using the maximum cost MJN selection strategy, which will increase signaling overhead. Therefore, this strategy is more suitable for use in the Software-Defined Network (SDN) environment, where the controller has global network status information. We took the scenario shown in Figure 4 as an example to describe the minimum cost MJN selection strategy in detail. The receiver R informs N4 that it wants to join the multicast group identified by MGEID₁. Since N4 does not maintain the NFT entry corresponding to MGEID₁, N4 queries the NRS for the MJN list of the group. NRS returns NA_MJN1 and NA_MJN2 to N4. Then, N4 selects a suitable MJN to join according to the given MJN selection strategy. When using the nearest MJN selection strategy, N4 selects MJN1 as the target MJN to join because the distance between MJN1 and N4 is less than the distance between MJN2 and N4.

When using the minimum cost MJN selection strategy, N4 calculates the comprehensive cost of MJN1 and MJN2, respectively. We assume that the network diameter is 4, the link bandwidth is 1Gbps, the NFT load threshold is 100, and the α, β, and γ used in the comprehensive cost function are all 1/3. On the path from MJN1 to N4 (MJN1→N1→N4), we used the NFT load of N1 as PS and the link load of L2 as PT. Then, we calculated that the comprehensive cost of MJN1 is 0.7. The path from MJN2 to N4 is MJN2→N2→N3→N4. Since the NFT load of N3 reaches the threshold, we used the NFT load of N2 as the PS and the link load of L5 as the PT. Then we calculated that the comprehensive cost of MJN1 is 0.45. Since $\cos \mathrm{t}\left(\mathrm{MJN}1\right)<\cos \mathrm{t}\left(\mathrm{MJN}2\right)$, N4 chooses MJN2 as the target MJN to join.

4.3. Leaving a Group

The process of the receiver joining the multicast group is shown in Figure 5. When a receiver is no longer interested in the multicast group identified by MGEID, it informs the RER it connected to leave the group (arrow 1). The RER removes the interface connected to the receiver from the out-interface list of the NFT entry corresponding to the MGEID. If the RER finds that its GMT does not contain the MGEID and the out-interface list of the NFT entry is empty (arrow 2), it deregisters the mapping between the MGEID and its NA with NRS (arrow 3), sends a LEAVE message containing its RID to the Parent NA of the NFT entry (arrow 4), and removes the NFT entry.

When a router receives the LEAVE message sent to it, it first checks whether its GMT contains the mapping between the MGEID and the RID carried in the message. If so, it removes the mapping between the MGEID and the RID from its GMT. Otherwise, it removes the incoming interface of the message from the out-interface list of the NFT entry corresponding to the MGEID. Then, if its GMT does not contain the MGEID and the out-interface list of the NFT entry becomes empty (arrow 5), the router deregisters the mapping between the MGEID and its NA with NRS (arrow 6), sends a LEAVE message containing its RID to the Parent NA of the NFT entry (arrow 7), and removes the NFT entry.

Figure 6 details the leaving process of the proposed AHMM approach. As shown in Figure 6a, when R1 is no longer interested in the multicast group specified by MGEID₁, it just informs N6 that it wants to leave the group. Then, N6 sends a LEAVE message to N2 and removes the NFT entry of MGEID₁. After receiving the LEAVE message, N2 removes the mapping between MGEID₁ and RID_N6 from its GMT, sends a LEAVE message to N1, deregisters the mapping between MGEID₁ and NA_N2 with NRS, and removes the NFT entry. When N1 receives the LEAVE message sent from N2, it removes the incoming interface (2) of the message from the out-interface list of the NFT entry.

Then, R2 informs N7 that it wants to leave the multicast group, as shown in Figure 6b. N7 removes the incoming interface (2) of the message from the out-interface list of the NFT entry corresponding to MGEID₁. Then, R3 also informs N7 that it wants to leave the multicast group specified by MGEID₁, as shown in Figure 6c. N7 sends a LEAVE message to N1 and removes the NFT entry of MGEID₁. After receiving the LEAVE message sent from N7, N1 removes the mapping between MGEID₁ and RID_N7 from its GMT.

4.4. Data Forwarding

In AHHM, routers can not only forward multicast packets based on the MGEID but also forward multicast packets based on the bit string. If the State Flag of the received multicast packet is set to stateful, the router checks whether its GMT contains the MGEID. If so, it copies a packet, adds the bit string to the header of the copy, and modifies the State Flag to stateless. Then, it forwards the copy through BIFT and forwards the raw packet through NFT. Otherwise, it only needs to forward the packet through NFT. If the State Flag of the received multicast packet is set to stateless, the router checks whether the bit representing itself in the bit string is set. If so, the router clears the bit string in the message, modifies the Stateless Flag to stateful, and forwards the packet through NFT. Otherwise, the router directly forwards the raw packet through BIFT.

We took the scenario shown in Figure 7 as the example to describe the process of data forwarding in AHHM. After receiving the multicast packet in which the State Flag is set to stateful, N1 copies the packet firstly. For the copy, N1 modifies the State Flag to stateless, sets the bit string to 10, and forwards the copy through BIFT. For the raw packet, N1 forwards it through NFT. Since the GMT contains MGEID₁, N2 copies the multicast packet with the stateful flag. For the copy, N2 modifies the State Flag to stateless, sets the bit string to 01, and then forwards the packet through BIFT. Then, N2 discards the raw packet because the out-interface list of the NFT entry is empty. N4 directly forwards the multicast packet with the stateless flag through BIFT. After receiving the stateless multicast packet in which the bit representing it in the bit string is set, N6 clears the bit string, modifies the State Flag to stateful, and then forwards the packet to R1 through NFT. N3 and N5 directly forward the multicast packet with the stateless flag through BIFT. After receiving the stateless multicast packet in which the bit representing it in the bit string is set, N7 clears the bit string, sets the State Flag to stateful, and then forwards the packet to R2 and R3 through NFT.

5. Evaluation

In this section, we carried out a series of experiments to evaluate the performance of our proposed AHHM approach. Our evaluation offered a comparison with SSM and BIER. We first used BRITE [26] topology generator to randomly generate a topology. Then, we randomly deployed groups, each of which contains one source and some receivers. Each source and receiver were randomly connected to a router. NRS was deployed as an application to provide name resolution service for AHHM. For each experiment, we tested different multicast approaches under the same conditions and counted the relevant experimental results.

Table 1. Evaluation settings.

Parameter	Value	Parameter	Value
Topology Model	Router Waxman	α	1/3
Node Number	200	β	1/3
Edge Number	800	γ	1/3
Node Placement	Random	$D_{max}$ (hops)	5
Bandwidth Distribution	Constant	$S_{max}$ (states)	200
m (Number of links per new node)	4	$T_{max}$ (flows)	200
Bit String Length (bits)	2

shows the experimental settings used in our evaluation.

We conducted four sets of experiments to evaluate the performance of AHHM in terms of control overhead, forwarding state, and link load. In the first set of experiments, we tested these metrics of each multicast approach under different thresholds. In the second set of experiments, we tested these metrics of each multicast approach under different numbers of receivers. In the third set of experiments, we tested these metrics of each multicast approach under different numbers of groups. In the fourth set of experiments, we tested the cumulative distribution function (CDF) of these metrics in each multicast approach. The experimental parameters used in each set of experiments are shown in

Table 2. Parameters of each set of experiments.

Set Number of Experiments	Threshold	Group Number	Receiver Number
1	20, 40, 60, 80, 100	200	20
2	20	200	10, 20, 30, 40, 50
3	20	50, 100, 150, 200, 250, 300	20
4	20	200	20

. In order to make the experimental results more reliable, each set of experiments was repeated 100 times, and the average value was taken as the result.

5.1. Control Overhead

Firstly, we evaluated the control overhead of AHHM and BIER. Control overhead refers to the number of destinations that the router needs to track and maintain in the stateless mode. We counted the maximum number of destinations tracked among all routers, and the experimental results are shown in Figure 8.

Figure 8a shows that the control overhead in AHHM gradually decreases as the threshold increases. This is because AHHM prefers to use the stateful mode. When the threshold is increased, more groups use the stateful mode to establish multicast communication, thereby greatly reducing the control overhead of the router. Figure 8b,c shows that the control overhead in both AHHM and BIER increases with the number of receivers and groups. Figure 8d shows the CDF of the control overhead in each multicast approach. Compared with BIER multicast, AHHM can significantly reduce the number of destinations tracked and maintained by each router.

By analyzing the experimental data, we can find that the AHHM using the nearest selection strategy reduces the control overhead by 67.2% on average compared to the BIER. In BIER, the ingress router needs to track the information of all egress routers at the receiver-side for each group. In AHHM, only the information of RERs on stateless sub trees needs to be tracked, and the information of RERs that need to be maintained is balanced on root nodes of multiple stateless sub trees, not only on the SER.

In addition, we can also find that the minimum cost selection strategy reduces the control overhead by 40.6% on average compared with the nearest selection strategy in AHHM. When establishing multicast communication from the MJN to the receiver, AHHM preferentially uses stateful mode and switches to the stateless mode when encountering the router whose NFT load reaches the threshold. Unlike the nearest selection strategy, which only considers the factor of distance, the minimum cost selection strategy comprehensively considers the factors of distance, node status, and link status. Therefore, the minimum cost selection strategy can use the low-load nodes and links to establish the multicast communication from the MJN to the receiver in the stateful mode, thereby reducing the RER information that needs to be maintained.

5.2. Flow State

Secondly, we evaluated the number of multicast forwarding states that the router needs to maintain in each multicast approach. We compared the maximum number of multicast forwarding states among all routers in different multicast methods. The experimental results are shown in Figure 9.

Figure 9a shows that the number of forwarding states of the router in AHHM gradually increases as the threshold increases. When the threshold is increased, more groups use the stateful mode to establish multicast communication, which increases the number of forwarding states that routers need to maintain. Figure 9b,c shows that the number of multicast forwarding states in AHHM, SSM, and BIER all increases with the number of receivers and groups. The CDF of the number of forwarding states for each router in each approach is shown in Figure 9d. These experimental results indicate that the multicast forwarding state in AHHM is more than that in BIER but less than that in SSM.

By analyzing the experimental data, we can find that the number of multicast forwarding states in AHHM using the nearest selection strategy increased by 57.2% on average compared with BIER but decreased by 51.4% on average compared to SSM. This is because SSM needs to establish a stateful delivery tree for each group, and each on-tree router needs to maintain a forwarding state. BIER only needs edge routers instead of intermediate routers to maintain the multicast forwarding state. AHHM can adaptively use the stateful mode on routers with fewer forwarding states and the stateless mode on routers with more forwarding states. Therefore, compared with SSM, the forwarding states maintained in each router in AHHM are greatly reduced.

In addition, we can also find that the number of multicast forwarding states in AHHM using the minimum cost selection strategy is reduced by 12.1% on average compared with AHHM using the nearest selection strategy. This is because the minimum cost selection strategy can select the MJN with a smaller PS to join by considering the NFT load of each node on the path from the MJN to the RER.

5.3. Link Load

Thirdly, we evaluated the link load in each multicast approach. We counted the number of flows passing through each link and compared the maximum load among all links in different multicast methods. The experimental results are shown in Figure 10.

Figure 10a shows that the link load in the AHHM is basically unchanged as the threshold increases. This is because the threshold can affect the mode used when establishing multicast communication but cannot reduce traffic. Figure 10b,c shows that the maximum link load in AHHM, SSM, and BIER all increase with the number of receivers and groups. Figure 10d shows the CDF of a load of each link in each multicast approach. These experimental results indicate that AHHM can significantly reduce the link load compared to SSM multicast and BIER multicast.

By analyzing the experimental data, we can find that the maximum link load in AHHM using the nearest selection strategy is reduced by 18.4% on average compared to SSM and 58.9% on average compared to BIER. In BIER and SSM, multicast flows are uniformly transmitted along the shortest path tree from the source to all receivers, which leads to reuse and overload of some links. Especially when the number of egress routers is greater than the length of the bit string, BIER needs to divide egress routers into different SIs and copy a packet for each SI. Packet redundancy leads to greater link load in BIER. In contrast, AHHM selects a suitable MJN for each receiver to join the group according to the given strategy, so it can make full use of the low-load links to avoid link overload and traffic aggregation. Moreover, AHHM can alleviate the problem of multicast packet redundancy because the number of egress routers in each stateless sub tree is small.

We can also find that the maximum link load in the minimum cost selection strategy is 31.8% smaller on average than that in the nearest selection strategy. Since the factor of link load is considered when selecting MJN, the minimum cost selection strategy can make full use of low-load links and reduce the link load.

6. Conclusions

In this paper, we propose AHHM to improve the scalability of multicast. AHHM assigns a unique global MGEID to each multicast group. By adaptively using the stateless mode on routers with more forwarding states, the proposed AHHM can effectively balance the forwarding overhead and multicast forwarding states. By balancing the destinations information to different MJNs, AHHM alleviates the problems of ingress router overload and packet redundancy faced by BIER. In order to optimize the multicast transmission path, we used the NRS to maintain the mapping between each MGEID and MJNs and designed a minimum cost MJN selection strategy to select a suitable MJN for each receiver to join. We conducted a series of experiments to evaluate the performance of AHHM. The experiments show that AHHM can well balance the control overhead, multicast forwarding state, and link load. Compared with SSM, AHHM can greatly reduce multicast forwarding states and link load. Compared with BIER, AHHM increases some multicast forwarding states but greatly reduces the control overhead and link load.