Multifractal Analysis Of Selected Multicast Routing Protocols In IP Networks

The article presents results of studies using simulations on computer network devices, designed to examine the effectiveness of routing protocols with the video streaming and generated traffic for Jperf applications. In order to demonstrate the effectiveness of the selected protocols several simulation scenarios were made using different sized UDP packets. The traffic was analyzed in terms of statistical selfsimilarity. Multifractal analysis has also been made, using two kinds of spectrums. The study determined the relationship between them. These tasks were designed to determine the multifractal and long-term relationship for a given process.


Introduction
Live streaming content such as video, Internet radio broadcasts, VoIP are ones of the most promising services among the many possibilities offered by IP networks [1].Unfortunately, the network traffic of these services is problematic from the point of view of taking congestions [2] and traffic patterns recognition [3].The main reason is the large size of the required bandwidth, in particular for video streaming.This band may increase as with the popularity of the service [4].In addition, the traffic will be irregular because the data are received by the random recipients [5].It is expected that the live streaming will dominate traffic in IP networks [6,7].This means that the above traffic problems become critical at this moment.Given the nature of the service, the implementation of multicast techniques seems to be the best solution to solve these problems [8].A key element of live video traffic is simultaneous distribution of information to multiple recipients.Therefore, it can be assumed that during operation of such a service network resources are wasted.The multicast techniques can effectively reduce the size of such a traffic [9].In order to reduce implementation problems, we can implement standard multicast protocols or other multicast techniques.
Although these opportunities are widely available, it becomes important to determine how effectively multicasting can reduce the intractability of traffic caused by the live content.As it was written above a video network traffic is usually caused by congestions.Their existence lead to enlargement of response time and reduced network throughput.Usually they occur if the bandwidth is insufficient and the amount of data traffic exceeds available capacity.Starting from pioneer work of Leland and his cooperators [10] it is known that network traffic congestions can be omnipotent as an emergent phenomena [11,12] and we cannot avoid them, but we can reduce their number taking into account different techniques and methods, among them there are: monitoring network traffic, use network segmentation, use a content delivery network, reconfigure TCP/IP settings, use backpressure routing, prioritize network traffic, use network redundancy, use multicast techniques.The existence of congestions is also related to the bursty traffic and statistical self-similarity [10,13] thus it is important to determine all possible phenomena that allow better understanding the complex nature of video stream network traffic.
A paper consists of seven sections.Section 2 gives a discussion about goals and multicast routing mechanisms used in routing protocols.We describe used protocols: PIM-DM (Protocol Independent Multicast --Dense Mode) and PIM-SM (Protocol Independent Multicast --Sparse Mode).Section 3 is a presentation of analysed network specification with topology based on five Cisco routers and two or three computers, depending on the type of scenario.Section 4 presents the methodology for determining the Hurst coefficient and the tools used for the test of streaming video (Selfis application).Section 5 gives details about carried experiment and Section 6 shows multifractal spectrum for the studies using a multicast server and one recipient.We presented long-term relationships in the test process.Section 7 gives conclusions and research for the future.

Multicast Routing
Multicast routing refers to the creation of trees distribution that provide a path from the multicast source to a multicast group members.Multicast routing protocols can be divided into types with respect to the type of network.In a wired network routing protocols are identified based on two types of trees [14]:  Source trees;  Shared trees.In contrast, wireless networks multicast routing protocols can be divided into three types of trees created:  The source tree;  Shared Tree;  Based on the grid.PIM-DM (Protocol Independent Multicast -Dense Mode) is relatively simple implementation of the flood-and-prune protocol.It is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers and uses dense multicast routing.Prune messages are used to prevent future messages from propagating to routers without group membership information.To illustrate (in Fig. 1), host S1 is the source of a multicast group G and a host H2 is a member of the group.When the source S1 starts sending IP datagrams to a group G, the datagram floods all routers [15,17].
Each router that processes the packet, creates entry (S1, G) in multicast routing table, where the input interface is set as the RPF interface for the source S1,and set of output interfaces include all other interfaces (Table 1).E.g., multicast routing table of the router R2, is as follows [15]:

Table 1. Description of multicast routing table R2 router
According to the algorithm flood-and-prune, the router R4, that is not connected to the network and members of the group, sends a Prune message through his RPF interface to the router R2.The message contains the address of the group G and address severed source node S1 (Table 2).When the R2 receives a message Prune selects the appropriate output interface as cut off:

Input interface
The set of output interfaces PIM-SM (Protocol Independent Multicast -Sparse Mode) is more complex than PIM-DM.PIM-SM initially builds a tree core for multicast group, which is common to all sources and generally scales fairly well for wide-area usage.When traffic from a source exceeds the threshold, PIM builds source tree for the source.The following will be discussed how core tree is constructed, how a source transmits data and PIM-SM turns them into the source tree.
In PIM-SM, the core router is called the rendezvous point (RP), and the core tree is rendezvous point tree (RPT).It is one-way, i.e., packets are forwarded only down trees, and sources send packets to the RP.RP can either be statically configured or dynamically determined by a broadcast mechanism, which is part of the PIM-SM.Moreover, the network may have a different RP for each multicast group [16].A Rendezvous Point (RP) is a router in a multicast network domain that acts as a shared root for a multicast shared tree.Any number of routers can be configured to work as RPs and they can be configured to cover different group ranges.For correct operation, every multicast router within a Protocol Independent Multicast (PIM) domain must be able to map a particular multicast group address to the same RP [24].
In PIM, the router can have both entry (S, G) and (*, G) in the routing table for the same multicast group.In this case, when a packet arrives with a source address S for the group G, the router at the beginning is trying to find a match in the routing table for an entry (S, G).If such a match does not exist, then searches for the entry (*, G).If also it doesn't exists, the router attempts to forward the packet to the RP for that group.If it is not aware of any of RP, the datagram is discarded.When there is a match, the router performs checking of the RP, i.e. verifies if the datagram has been received by the input interface, which is recorded in the routing table entry, and then transmits the data to a set of output interfaces.In multicast, the router forwards the packet away from the source to make progress along the distribution tree and prevent routing loops.The router's multicast forwarding state runs more logically by organizing tables based on the reverse path, from the receiver back to the root of the distribution tree.This process is known as reverse-path forwarding (RPF).The router adds a branch to a distribution tree depending on whether the request for traffic from a multicast group passes the reverse-path-forwarding check (RPF check).Every multicast packet received must pass an RPF check before it is eligible to be replicated or forwarded on any interface.The RPF check is essential for every router's multicast implementation.When a multicast packet is received on an interface, the router interprets the source address in the multicast IP packet as the destination address for a unicast IP packet.The source multicast address is found in the unicast routing table, and the outgoing interface is determined.If the outgoing interface found in the unicast routing table is the ITM Web of Conferences 21, 00016 (2018) CST 2018 https://doi.org/10.1051/itmconf/20182100016same as the interface that the multicast packet was received on, the packet passes the RPF check.Multicast packets that fail the RPF check are dropped because the incoming interface is not on the shortest path back to the source [24].
When a host joins a multicast group, the Designated Router (DR) for that host sends a message: Join the reverse path to the RP.DR for the host H2 or router R3 (Figure 2a) sends a Join (*, G) to R2, its neighbour RPF for RP.Assuming that R2 does not have an entry (*, G) in the routing table when it receives Join message, it creates such an entry and sends a Join(*, G) to R5.When RP gets Join message, it adds the output interface, that connects with R2 to the entry (*, G) in the routing table.Just like with messages Prune Join messages are sent periodically, about once every minute.Entries in the routing table created by a message Join have a limited lifetime and router removes the entry if it does not receive any new message Join for some time [16].
When a host H3 joins the multicast group G, as shown in Fig. 2 (b), the router R4 sends a Join(*, G) to R2.Because R2 already has an entry (*, G) the routing table does not send a Join message to RP and simply adds the I2 interface to a set of output interfaces for the entry (*, G) in the routing table [16].https://doi.org/10.1051/itmconf/20182100016travels to RP shortest reverse path and creates entries (S, G) in the routing tables of all routers between the source and RP [18].
When the Join message reaches the source DR, DR sends packets from the source to the RP.When the RP receives packets from the reverse path, it sends a Register-stop message to the DR to stop the transmission containing datagrams.For a time between receiving messages Join and Register-stop source DR receives two copies of each packet from the source, one in the Communication Register and one in the parent package.Host S1 sends a multicast packet to its DR, that is R1.This includes the datagram in a Register message and send it as a unicast message to the RP [19].
RP receives the packet and forwards it to the RPT.In Fig. 2, we assume that host H1 only joined to the group G and the RPT consists of a path R5 -> R2 -> R3.Then, RP sends a message Join (S1, G) to DR source.When R1 receives a Join message, creates an entry (S1, G) in the routing table and starts to stem the transmission of packets, i.e. normal IP datagrams with destination address G, to the RP.As shown in Fig. 2 (b), R1 continues to send packages in the message Register to RP.As soon as the first parent packet arrives to R5, the router sends a Register-stop to R1.This stops the transmission of messages Register with packets [18].

Study
For the analysis of multicast traffic in this work an experiments on computer networks with multicast routing protocols: PIM-DM and PIM-SM were carried out.The study used five Cisco routers and two or three computers, depending on the type of scenario.

Fig. 3. Tested network topology
During the first simulation one of the computers was a multicast server, which transmits video using VLC media player program, while in the entire network was only one recipient.This experiment was conducted for a network with separately implemented two abovementioned multicast routing protocols.
The second study was to transmit streaming video from the multicast server to two recipients included in the test network.Like the previous study this one was also carried out for both multicast routing protocols.
The third study was to generate traffic using a Jperf generator, from the server to the one or two recipients.In this study the main objective was the highest load capacity of the network and the analysis of load resistance of two multicast routing protocols.The different sizes of UDP packets were transmitted.The test may have allowed to verify that network bandwidth can be obtained for a variety of UDP packets in two types of multicast routing

Self-similarity statistical analysis
Statistical self-similarity analysis was performed using a Selfis application [25].This software is based on the source code written in the Java programming language.The main parameter in the analysis of statistical self-similarity was the number of transmitted packets per second.To determine the statistical similarity, Selfis uses the Hurst coefficient.The Hurst coefficient allows to specify the nature of the process, long-term dependencies, direction of change and stationarity.To determine these properties the relation H > 0.5 was used.However, if the Hurst coefficient is smaller than 0.5, it is considered that in the according process occurs short term dependencies, the process is not persistent and do not occur stationarity dependencies [10,18,20].
The fractional Brownian motion (fBm) is the basis of long-range dependent statistical models.This model is a natural expansion of Brownian motion and was proposed by Mandelbrot and Van Ness [21] as an association with a Hurst parameter H. Mandelbrot and his followers proposed many natural phenomena which can be described by fBm.A process (term of 'process' doesn't mean a program that is executed or processed in a computer system) can be considered as self-similar if for some H>0.
Equation ( 1) means that the process is invariant under translations of time and scale.If variable t is considered as a time and X(t) as a process space then, according to Eq. ( 1), every change of time scale by factor a>0 corresponds to change of space scale by factor   .The H exponent shows the process memory effects and also gives information of time series persistence.In Gaussian processes H=0.5 denotes the probability that process will stay in its trend and it equals p=0.5; if H changes the p also.If H is under 0.5 value a sequence has a tendency to return to the mean and is called an anti-persistent [22].There is also another type of self-similar processes -Lévy α-stable processes where  = 1/.Then the existence of a memory effect is described by d in range <-1/2,1/2> parameter and finally  = 1/ +  (if d=0 than  = 1/).
In 1994, according to famous paper of Leland [10], the existence of long-range dependences in computer networks was noted.The existence of statistical self-similarity leads to many important features of computer network traffic including flow burstines and congestions.

Long-range dependencies in analyzed data
We assume that the analysed time series are stationary; our experiments were carried under stable and do not changing conditions.However, it should be remember that some methods used to estimate H in fact give d parameter.Then the overall information about the process self-similarity should be obtained with the analysis of probability distribution.Generally, is not easy to obtain the real value of time series statistical self-similarity factor thus a few methods can be used: The description of each method can be found for example in [23].Most of these methods were used, because calculations of H parameter is not easy, and strong confirmation of investigation result was required.

PIM-DM and PIM-SM protocols -video streaming
After the test of streaming video to a single recipient with the use of both protocols it can be stated that this process has long-term dependencies.All statistical methods for determining the Hurst coefficient for PIM-SM protocol (Table 3) designated this ratio above 0.5, while for the protocol PIM-DM only Absolute Moment method set the Hurst coefficient below 0.5.

Table 3. Description Analysis of Hurst coefficient for the PIM-DM and PIM-SM protocolsstreaming video -one recipient
After connecting to the multicast group a second recipient, we can see that the values of the Hurst coefficient determined by the majority of methods for both protocols: PIM Dense Mode and PIM Sparse Mode are below 0.5.Multicasting of video transmission to more than one recipient does not lead to deepening the long-range dependencies, but even decreases the intensity of this phenomena.Detailed results are included in the Table 4. Table 4. Analysis of Hurst coefficient for the PIM-DM and PIM-SM protocols -streaming videotwo recipients

PIM-DM and PIM-SM -Jperf
Table 5 shows a comparison of Hurst coefficient for studies using Jperf traffic generator for one server and one recipient.The Hurst values clearly show that processes with implemented routing protocols: Multicast PIM-DM and PIM-SM, are characterized by long-term dependencies.For the second case, in the Jperf traffic generator only one method does not calculate the Hurst coefficient above threshold value 0.5.For other methods the Hurst coefficient was greater than 0.5 and sometimes even greater in the case of one recipient (see Table 5), which indicates comparable long-term dependencies occurring in the process.Detailed results are included in the Table 6.As a summary it can be stated that program traffic generators not always lead to a real traffic nature and obtained results can be different from those gathered in real cases.

The performance analysis of multicast routing protocols
To complete this research the JPerf traffic generator was used.The study was designed to test bandwidth with implemented two multicast routing protocols.The packet that has been set in the program had value 1359 bytes and 1470 bytes.The data collected in the Wireshark were used to obtain graphs as shown in Fig. 4 and 5. Fig. 4 shows a comparison of the capacity for the two routing protocols using multicast streaming 1359 bytes.In the initial period of the audit it may be noted that the capacity of network protocol implemented with PIM Sparse Mode was higher than the PIM Dense Mode protocol.However, in later studies the performance of both protocols was similar.
In the case of streaming 1470 bytes it can be seen that for a half the time of the experiment time PIM Dense Mode protocol showed higher performance (details are in Fig. 5).

Fig. 5. Capacity comparison for 1470 bytes packets
The flow capacity in this period was in the range of 2.9 Mb/s to 3.15 Mb/s.While at the same time PIM Dense Mode protocol the capacity was in the range of from 2.92 to 2.96 Mb/s.In the second half of the experiment time the capacity for both multicast routing protocols was at the same level.It was in the range of 2.9 Mb/s to 3.12 Mb/s.

Multifractal of Analysis
For multifractal analysis the FracLab tool has been used which is written in Matlab [26].Before the multifractal spectrum analysis was done a polynomial synthesis of the collected data was performed.Multifractal spectrum was determined by two methods.The first method is using Legenrde'a transform, which is determined by the classical method.The second way to determine the spectrum is the kernel density estimation [22].When we compare the two spectrum at the same time, and the result will be similar, it means that the process is characterized by multifractal dependencies.
Data collected for statistical self-similarity analysis was used to analyse the multifractal analysis.As shown in Fig. 6 the two multifractal spectrum for testing video streaming with implemented PIM Dense Mode routing multicast protocol are given.The apparent similarity of multifractal spectrum shows that in the studies using a multicast server and one recipient, in the process occurred multifractal dependency, and former long-term relationships in the test process.Another study subject of multifractal analysis was the JPerf traffic generation.In the case of this experiment a multifractal spectrum can be noted; the spectrum using Legenrde'a transform with major deviation (Fig. 7) which also shows signs of similarities.It can be concluded that also in this process the multifractal dependencies exist, which means that process is also based on long-term dependencies.
The multifractal spectrum analysis was also used to determine the multifractal relationship for networks with implemented PIM Sparse Mode multicast routing protocol.In Fig. 8 two multifractal spectrum are presented; they were obtained from the data collected during the streaming video traffic.The results confirm that in a study using a multicast server and one recipient with implemented PIM SM routing multicast protocol, a process occurred with multifractal dependencies and this proves the occurrence of longterm dependencies.The last case of multifractal analysis was to study UDP traffic generated by JPerf traffic generator.In this case, it can be seen that the shape of the spectrum does not vary; generated process was characterized by multifractal properties.

Summary
The carried out tests to determine the multifractal and long-term dependencies as well as the analysis of the routing protocol performance has been implemented in network with two multicast routing protocols: PIM Dense Mode and PIM Sparse Mode.For each of these protocols various studies have been carried out in order to gather enough data for analysis.
Implementation of multicast technology over IP networks involves choosing the appropriate multicast routing protocol.A major significance in the design of this type of network is awareness of large data to be transmitted.The comparison of multicast routing protocols presented in this work was done for a small network in which there were 5 routers, 1 and 2 multicast customer servers and showed that not each size of the packet in routing protocol is fully efficient.
During the study of statistical self-similarity, in the case of video streaming server and one recipient, Hurst coefficient for both protocols had values above 0.5.With this relationship, it could be stated that the process has long-term dependences.
In the case of studies in which a multicast server and two customers were implemented not all methods of the Hurst coefficient calculation give $H$ value above 0.5.This relationship leads to the conclusion that in this type of experiment based on real stream the existence of long-term dependencies is not so obvious due to the use of multicast protocols.
It was also found that in the network with implemented multicast routing protocols and traffic generated by Jperf occurred multifractal dependencies which largely confirms that in the network either with streaming video content or with generated UDP traffic long-term dependences take place.

Fig. 2 .
Fig. 2. RPF and cut off in PIM-DM Cut off and join messages When a source wants to transmit data to the multicast group, the DR for the source sends a Register message to the RP of that group and includes multicast packet in this message.RP which receives the Register message, receives the packet and sends it down the RPT tree.If the RPT has no node down, RP discards the packet.When the Register message with datagram reaches the RP, it sends a Join (S, G) to the source.Join message

Table 2 .
Description of the multicast routing table -cut off of the output interface

Source IP multicast group
Residuals (VR) -it calculates the  value,  Aggregated Variance (AV) -it calculates the  value,  Mean Value Analysis (MVA) -it calculates the  value,  R/S -it calculates the  value, Detrended Fluctuation Analysis (DFA) -it calculates the  value,  Periodogram -it calculates the  value,  Whittle Estimator -it calculates the  value,  Waveled Method -it calculates the  value.

Table 5 .
Analysis of Hurst coefficient for the PIM-DM and PIM-SM protocols -Jperf -one recipient

Table 6 .
Analysis of Hurst coefficient for the PIM-DM and PIM-SM protocols -JPerf -one recipient