Algorithm for an Oriented Multicast Routing Protocol

Transcription

1 Algorithm for an Oriented Multicast Routing Protocol Damien Magoni, Jean-Jacques Pansiot LSllT - Universiti: Louis Pasteur Boulevard Sebastien Brant, ILLKIRCH { magoni, pansiot Abstract - An increasing number of Internet applications and services will require the use of multicast in the near future. However, only a few techniques are currently used in networklayer multicast routing protocols, such as flooding, pruning or reverse path construction methods. We propose an algorithm to define a new way of multicasting. The base principle is to perform a limited multicast channeled around the unicast path joining the sender to a specific destination, hence the name oriented. This algorithm is close to reverse path multicast algorithms but the flooding is much more controlled. A protocol based on our algorithm could have many applications such as performing network node searches in a specific area. The algorithm is tailored as to be scalable to enable its use in an inter-domain environment. I. INTRODUCTION Although they have some difficulties to be deployed, multicast applications will surely be the next generation main applications running over the Internet. The slow start of the use of such applications may be due to the lack of efficient underlying multicast techniques and protocols. In this paper we propose a new algorithm destined to fill the gap between the two current main multicast techniques: flooding and pruning, and reverse path forwarding. In section I11 we give a specification of our algorithm. In short, it performs a limited multicast channeled around a unicast path. It has to be deployed at the network layer but need not constitute a self-contained protocol. In section IV we explain how the algorithm could be used by other protocols. Section V shows results for a typical use of our algorithm in a specific network node searching technique. 11. RELATED WORK Current multicast protocols usually implement one of the following multicast algorithms. A first rather simple algorithm, called flooding, is rather a broadcast operation than a multicast one. When a packet is received, the router checks if it has not been already received. If yes, it forwards the packet to all links except the reception link. This technique produces a lot of redundant packets and needs to maintain a lot of information states in routers. An improved version is called reverse path forwarding (RPF) [3]. When a packet arrives in a router, the latter checks if the packet comes from a shortest path to the source. If it is the packet is duplicated and sent to all the other interfaces, if it is the packet is discarded. RPF is an improvement over flooding and it is used in many network protocols. A variant of the RPF algorithm is called reverse path multicasting (RPM) [4]. It uses RPF as the base forwarding algorithm but upon data reception, a leaf router without member can send a prilning message to its father to mark off the link and so on. Periodically, packets are sent again to check if the router is still without members. However many pruning states must be kept in routers which make RPM not scalable ORIENTED MULTICAST ROUTING Our aim is to build an oriented multicast algorithm that uses the position of the other devices implied in the multicast communication as it is done in the RPM algorithm. But unlike the RPM algorithm, our algorithm does not need to maintain state information in routers. RPF is used in parts of our algorithm but in a very controlled way. A. Algorithm parameters Our multicast routing algorithm is parameterized. We define a variant as being a specific set of settings of all the algorithm parameters. By changing the values of the parameters we can currently obtain 5 variants. The next subsection will give the full specification of the algorithm and the parameters that have to be set to obtain a specific variant. The generic principle of the algorithm is to reach only the nodes located on or near the (or a) shortest path between the sender (S) and the destination (D). Every packet contains a special field, besides the TTL, called range. As long as the packet travels along a shortest path between S and D, it is multicasted on every link of the node except the arrival link and the range is never decreased. When it goes out of the shortest path SD, the policy depends on the parameter settings of the algorithm. It can be propagated by reverse path forwarding (RPF), by lateral multicasting (i.e. to nodes not 2593

2 leading by a shortest path to the source or the destination) or even by unicast towards its destination. In most cases the packet range is decreased for each hop and thus the maximum travelling distance for the packet is limited to at most the initial range value. Although we talk about shortest paths, and SD shortest path in particular, through this paper, it is indeed the path given by the underlying unicast routing system. The fact that it is not a true shortest path does not matter and our algorithm still works. Besides we rarely get a true shortest path in reality, particularly in inter-domain routing. From the packet current router position, we define E as being a neighbor router leading to D by a shortest path but not belonging to a SD shortest path. The parameters of the algorithm are fully detailed in table 1, including an explanation of their meaning. Name multicast ED-multicast ED-range-dec initial-range TABLE I ALGORITHM PARAMETERS Possible Values rpf, lateral rpf, destination - not ne N" Description Defines the multicast mode when the packets have left the shortest path from S to D and are not on a shortest path to D Defines the multicast when the packets have left the shortest path from S to D and are on a shortest ath to D Boolean indicating if the packet range has to be decremented when a packet is on a shortest path to D but on a shortest oath from S to D Defines the initial I range value of a packet Currently we assume the use of a specific network packet format for our algorithm modelling, but in reality the packet structure could be a subset of another network protocol packet format. In fact a packet used by our algorithm contains a number of fields typical of the IP protocol as well as others fields needed for our algorithm. Table I1 below gives the meaning of each algorithm specific field of a packet. Name SD ED range Possible Values ne N' B. Algorithm specijkation TABLE I1 PACKET FIELDS Description Boolean indicating if the packet comes from a link on a (S, D) shortest path Boolean indicating if the packet comes from a link on a shortest path to D (different from a (S, D) shortest path) Integer defining the nb of hops a packet can do when out of a (S, D) s.p. The algorithm is given below in pseudo-code. The following functions will mainly be running in routers as a core part of the protocol. The algorithm parameters are accessible through the algo-params structure. When a multicast emission is triggered at the application layer, the first packet is created and fields that are specific to the algorithm are initialized by the Initializationfunction. In it I a I i zat io apacket) packet.sd t true packet.ed t After packet initialization, Processing is called. This function is responsible for the forwarding or destruction of the packet. It can also contain any processing needed by other protocols. The Processing function will sometimes destroy the packet or call Switching which means the future multicasting of the packet. Note that in the following pseudo-code the symbol -I means: to be continued on the next line. Processing(packet) // do something to fulfill a specific service IF packet.ltl > 0 AND packet.range > 0 Switchindpacket) Destructior(packet) The aim of the Switching member function is to determine the position of the packet in order to select a suitable multicasting technique. 2594

3 Switch i ngpacket) IF packet.sd = true THEN Mu It icast i n gpacket, rpf) -IF packet. ED = true THEN Mu It icast i napacket, alg o-pa ra m s. ED-m u I ti cast) Mu It icast i napacket, a lg o-pa rams. mu It icast) The Multicasting function will spread the packet by various methods depending on the settings of the parameters of the algorithm and the fields of the packet. The router s interfaces are noted out-if for output interfaces and in-if for input interfaces. Multicasti ndpacket, mu/ticascmethod) IF mu/ticasc method = rpf TH EN IF out-if = packet.in-if THEN CONTINUE IF packet.sd = true THEN IF out-if leads to D by a shortest path THEN Emissior@acket, out-if,, ) Emissior@acket, out-if,,, true) IF out-if leads to D by a shortest path THEN Emissioeacket, out-if,, ) Emissior@acket, out-if,,, ) EN D-FOR-EACH -IF mu/ticascmethod = lateral THEN IF out-if!= packetin-if AND J out-if leads not to S OR D by a shortest path THEN Emissio@acket, out-if,,, ) -FOR-EACH -IF mu/ticascmethod = destination THEN IF out-if!= packet.in-if AND J out-if leads to D by a shortest path THEN Emissio!(packet, out-if,, ) -FOR-EACH The Emission function sets the initial range value, the current SD and ED booleans and calls the Reception function of the router at the other end of the sending interface. This call models the packet s travel between two routers. Emissiorr(packet, intedace, SO, ED, posifion) IF position = true THEN packet. ra nge t a lg o-pa ra ms. in itia I-ra nge packet.sd t SD packet.ed t ED interface. receivi ng-rou ter. Rece pt ion(packet) The last method of the whole process is the Reception function. It decreases the values of the TTL and the range, if needed, and transfers the packet to the Processingfunction. Rece pt io Npacket) IF RPF-check = OK THEN packet.ttl - - IF packet.sd = AND J (algo-params.ed-range-dec packet.ed = ) THEN packet.range - - Process i n dpacket) Destructior(packet) multicast ED-multicast ED-range-dec = true OR J Table 111 shows the parameter settings for creating the algorithm variants that have been tested. Results are shown further in section V. These values have to be set in the algo-params structure in order to model the variants. TABLE Ill ALGORITHM SETTINGS FOR VARIANTS lateral rpf rpf rpf rpf N/A rpf rpf dest. dest. N/A true true IV. APPLICATIONS A first very important use of our algorithm and corresponding protocol, would be its embedding in a network agent search protocol. In many protocols one or several network nodes with a specific functionality need to be selected to fulfill a given task. The classical multicast technique currently used by many protocols to carry out a network agent search is the expanding rings search (ERS) [2]. In an ERS, packets are sent by the source with an arbitrary fixed TTL value that defines a range for the packet. Initially an ERS packet is sent with a small TTL (say 1 or 2). If no agent is found, a new packet is sent with an increased TTL and so on until an agent is found or a threshold value for the TTL is reached. In an ERS, packets are forwarded by following the reverse path 2595

4 forwarding mechanism. Notice that an ERS does not take into account the position of the other actors of the communication and floods surrounding nodes in all directions. Examples of the use of a search protocol are: - find and select the nearest multicast retransmission node for a reliable multicast communication, - find and select a multicast tree node to graft a new member. Note that in theses examples, the search can be directed toward a specific node called the target. For the reliable communication, the target could be the data emitter. In reliable multicast protocols such as LGMP [5] and RMTP [7], receivers search for these retransmitting agents by multicasting requests according to the ERS scheme. For the multicast tree, the target could be the root of the multicast tree. In multicast tree creation and maintenance protocols such as YAM [2] and QoSMIC [I], when a receiver has succeeded in contacting the root of the multicast tree of the group, it usually uses an ERS to be able to graft itself to a node already belonging to the desired multicast tree (although ERS is sometimes coupled with other methods). In the above cases, our idea is to replace the ERS by a search protocol using our oriented multicast routing algorithm. It would be oriented towards the target (defined in each of the above examples) and it would be much more efficient than the ERS method. Moreover our algorithm is designed to find agents as close as possible to a shortest path from the initiator to the target which is of a great interest to the above protocols. Our algorithm could also be used in a network discovery protocol. Current discovery tools usually use hop-limited probes, but as they are not oriented, the probes cannot be sent with a high TTL value. Our algorithm would enable the discovery of the neighborhood of a unicast path towards an interesting specific destination. V. PERFORMANCES We have implemented our new algorithm in an agent search protocol skeleton to be able to compare it to an ERS. We do this to compare our oriented multicast routing algorithm to the RPF algorithm in a realistic use environment. This implementation was done in the simulation module of our network manipulator (nm) software tool. With this module, we can run static simulations to evaluate informations about algorithms such as the number of packets multicasted or the number of agent routers hit. We point out that a preliminary version of this work has been done within the scope of agent search in [6]. The nm simulation module is very efficient and fits perfectly for a first evaluation of our new algorithm before jumping to fine-tuned analysis stages. That would require the definition of additional parameters such as timers that do not exist at this point. It is also for this reason that we did not use LBNL s simulator ns. The latter will however be used in a second stage that will include every temporal parameter needed by the algorithm. A. Settings To feed the simulator we created graphs with the Georgia Tech - Internet Topology Model package developped by Zegura & al. [8]. We generated 100 graphs by the transit-stub method. Each graph has 1400 nodes, contains 2 % of agents and uses multiple routes routing. Each variant has been tested on 100 different source-destination pairs in each graph. So for a given SD distance, each variant has been tested times. The results of these simulations have been merged to give average results. We made these tests for SD distances of 5, 10, 15 and 20 hops. For the ERS, the TTL is incremented by 2 while no optimal agent is found, starting at 1 up to 9 (i.e. 1, 3, 5, etc.). For the variants, the range increment is 1 starting at 1 up to 5. B. Metria We have defined an important ratio called efficiency to be able to assess the variants. The efficiency is equal to the product of the number of optimal agents found and the number of routers hit divided by the product of the number of attempts needed to find an optimal agent and the number of packets emitted in the network. For an easier way to compare our variants to the expanding rings search, we have defined another ratio called the relative efficiency. It is equal to the efficiency of a specific variant divided by the efficiency of the ERS. C, Results On fig. 1 we show the average relative number of attempts needed to find at least one optimal agent (e.g. variant 1 needs 54% of the number of attempts an ERS needs to find an optimal agent). It is averaged on all the four tested distances. Notice that an ERS needs on average 3.8 attempts to find at least one optimal agent whatever the SD distance, which corresponds to a maximum TTL set to 7. The variant 3 has an average around 43% of an ERS which is equal to a average maximum range of 1.6, whatever the distance. 2596

5 Fig. 1. Average Relative Number of Attempts. Fig. 2 shows the cumulative relative efficiency of the variants. Their performances are good and increase when the SD distance increases. It is positive as they are designed for long distance searches. 3 clearly outperforms the other variants. Efficiency differences among variants are noticeable when the SD distance is 10 hops or higher. Fig. 3. Average Relative Efficiency. VI. CONCLUSION In the multicast routing research area, we have developped an original oriented multicast routing algorithm, that avoids the packet exploding phenomenon correlated to multicast methods such as flooding or reverse path forwarding. Its oriented feature is particularly suited for a dynamic search protocol of special-purpose network nodes lying on the way between two communicating partners. Several points will be studied later. In particular the steps to transform the algorithm into a protocol have not yet been undertaken. This would require to further define the algorithm messages and to introduce timers and finite state machine diagrams. We are also considering the use of a network simulator such as ns to demonstrate the feasibility of the temporal aspects of this algorithm. Finally a complete protocol implementation is also left for future work. Such a protocol could serve many other network or transport layer protocols and particularly multicast protocols. I Fig. 2. Cumulative Relative Efficiency. Finally, fig. 3 shows the relative efficiency of each variant averaged on all four tested distances. It is clear that variant 3 has the best result with an average efficiency 3.5 times better than the ERS average efficiency. These results clearly show that our oriented multicast algorithm could usefully replace the ERS algorithm in all the cases that we described in section IV. REFERENCES [I] A. Banerjea, M. Faloutsos, R. Pankaj, "QoSMIC : Quality of Service sensitive Multicast lntemet protocol", in Proc. ACM SIGCOMM'98, Vancouver, BC, September [2] K. Carlberg, J. Crowcroft, "Building Shared Trees Using a Oneto-Many Joining Mechanism", ACM Computer Cominunication Review, pp , January [3] Y. Dalal, R. Metcalfe, "Reverse path forwarding of broadcast packets", ACM Communications, vol. 21, no. 12, [4] S. Deering, "Multicast Routing in Datagram Intemetwork", Stanford University, California, U.S.A., December [5] M. Hofmann, M. Rohrmuller, "Enabling group communication in global networks", in Proc. Global Networking'97, June [6] D. Magoni, J.-J. Pansiot, "Agent Search by Oriented Multicast", in Proc. ACIS SNPD '00, Reims, France, May [7] S. Paul, K. K. Sabnani, J. C. Lin, S. Bhattacharyva, "Reliable Multicast Transport Protocol", IEEE Journal on Selected Areas in Communications, vol. 15, no. 3, April [8] E. W. Zegura, K. L. Calvert, M. J. Donahoo, "A quantitative comparison of graph-based models for intemetworks", IEEE/ACM Transactions on Networking, 5(6): , December