Network Search Service Using Oriented Multicasting

1

Network Search Service Using Oriented Multicasting Damien Magoni, Jean-Jacques Pansiot Abstract—Many protocols and applications need a discovery mechanism to enable a given client node to locate one or several specific nodes involved in the same communication. However, there is no protocol ready to fulfill this service at the network layer. Every protocol usually implements its own solution. In particular, multicast protocols often use a search technique called expanding ring search. This method searches for those specific nodes in all directions and thus uses much bandwidth. However a typical search can usually restrict its scan in a specific direction. To answer this problem, we propose a network search service in replacement of the expanding ring search. This service is based on an oriented multicasting protocol in order to ensure an efficiency higher than the expanding ring search. The oriented multicasting principle is to channel the multicasting of search packets towards a special node, involved in the communication, in order to scan only a limited area. We describe both the network search service and the oriented multicasting and we provide comparative simulation results between our service and the expanding ring search. Keywords—Multicasting, agent node, network search, expanding ring search.

I. I NTRODUCTION Many network protocols need to discover specific nodes before setting up a communication. These specific nodes are involved in the protocol functioning such as graft nodes for multicast trees or retransmission nodes for reliable multicast hierarchies and they usually have to be found prior to the data transmission. We call such a specific node a network agent node. It can be an end-user computer, a dedicated server or a router. Some services provide shared resources and the location of the agents that host them does not evolve over time. In this case, a service discovery based on a directory system works well. But many other services provide resources that evolve fastly over time. In particular, services provided by multicast protocols such as multicast tree creation and maintenance, are very topology-driven.In this case the service discovery should be dynamic. This means that the search must be done at each request as the results are supposed to change rapidly. At the network level (i.e. the IP layer) carrying out an agent search means trying to locate an agent by broadcasting messages containing information about the service needed. The broadcast can be

done by using IP broadcasting [1], multicasting by Reverse Path Forwarding (RPF) [2] or Anycasting [3]. Multicast protocols usually implement the second solution in a mechanism called Expanding Ring Search (ERS) [4]. This is because IP broadcasting is not efficient considering its network resource consumption and Anycasting is not yet deployed. Although the ERS algorithm uses RPF and is incremental, it is not always efficient. This is because it scans in all directions and therefore sends packets in uninteresting areas. In many cases where only a specific area needs to be scanned for agents, a mechanism based on our new algorithm can give better results than the use of the ERS algorithm. In this paper we describe a network agent search service destined to replace the ERS mechanism and we provide a detailed description of its key mechanism: the oriented multicasting algorithm. Section III contains the description of the oriented multicasting algorithm in pseudo-code as well as the data structures needed for it. Section IV describes the architecture of our network-level agent search service. This section also provides the algorithm for a typical network agent search. Finally, section V gives simulation results of an agent search using the oriented multicasting algorithm compared to an agent search using the ERS algorithm. II. R ELATED

WORK

There are currently several existing or proposed protocols to find network services. One of them, the Service Location Protocol [5] is not intended to be a global resolution system for the entire Internet. It is adapted to make use of directory agents that offer a centralized repository for service locations. This is appropriate to find common services such as printing but the creation and use of the directory agents may not scale in the Internet. Furthermore the information may not be up-to-date because it is a directory-based search. Another proposal is Anycasting [3]. Although it is not available in the Internet, Katabi et al. have made a proposal called GIA [6]. To be scalable GIA distinguishes popular and unpopular anycast routes and it uses a scoped inter-domain search in order to find uncommon services. Our proposal is not competing with these two. It is designed to find agents that do not provide

2

common services and that can be everywhere in the Internet. Thus is it closer to the GIA approach. However our solution is based on the IP router-level. In our solution, a search is always targeted (we say “oriented”) at a specific node and our service does not store in nodes any information on distant nodes. We also use a scoped search system but it is quite different from the classical Expanding Ring Search [4] currently proposed by GIA and some other protocols to carry out an agent search. For instance, in a reliable communication, some specific nodes (that we defined as agents in section I) are responsible for retransmitting data that has not been correctly received by one or more receivers. In reliable multicast protocols such as LGMP [7], RMTP [8] and TMTP [9], receivers search for these retransmitting agents by multicasting requests according to the ERS scheme. Receivers look for the nearest agent, but the agent should also be as close to the source as possible. We could orient the multicast by taking the multicast source as the target node. In multicast tree creation and maintenance protocols such as YAM [4] and QoSMIC [10], when a receiver has succeeded in contacting the root of the multicast tree of the group, it must be inserted into the existing multicast tree. The receiver then uses an ERS to be able to graft itself to a node already belonging to the desired multicast tree. The receiver would like to be grafted to an on-tree node that minimizes the total distance receiver–in-tree node–root node, in order to minimize delays. Although these protocols include more efficient search methods, they are more expensive too. YAM has defined the directed spanning join which can be seen as a particular instance of our algorithm. QoSMIC has defined a dual method: the search is accomplished simultaneously by a limited ERS from the initiator, and a search from the multicast tree. In our approach, we could take the root of the multicast tree as our target node. In protocols needing the use of converters such as MeGa [11], agents are servents grouped in clusters, that provide video streams adapted to the link capacity. At this time, clients use out–of–band means to contact these agents (e.g. via DHCP or a configuration file). However, the needs are the same than in the previous examples (excepted that agents run on hosts and not routers). The client is looking for a servent which will adapt the video stream throughput sent by the source. We can see here that we need a third-party search mechanism. The aim here too is to minimize the total distance client-servent-source. Note that the video source would be the target of the search. As we saw above, the ERS is a multicast search technique often proposed in current protocols. It is based on the use of the Time To Live (TTL) field of the IP header . ERS packets are sent by the source (noted S) with a

fixed TTL value that defines a maximum number of hops for every packets. Packets are then forwarded by a multicast technique called Reverse Path Forwarding (RPF) [2]. When a packet is received by a router, the latter checks if the packet comes from a shortest path to the source (RPF Check). If it is true, the packet is duplicated and sent on every interface of the router except for the receiving one, if it is false the packet is discarded. When an agent (noted A) receives the search packet, it sends an answer packet to the source. Initially ERS packets are multicasted with a small TTL.If no agent is found, a new wave of packets is multicasted with an increased TTL and so on until an agent is found or a threshold value for the TTL is reached. The nodes reached by this multicasting can be viewed as a disk centered at the initiator and with a radius equal to the highest TTL value used, hence the name expanding ring. In real life, use of an ERS with an initial TTL greater than 7 or 8 is hardly conceivable. A request packet propagated by an ERS by a source S does not take into account the position of the other actors of the communication and floods surrounding nodes in all directions. However we saw in each of the preceding examples that we could find a special target node serving as a beacon for the search area. Our aim is to use this information to orient the search and produce a more efficient agent search algorithm. In this paper we describe the oriented multicasting protocol1 , the network-level agent search service and protocol, and we provide the results of simulations carried out with LBNL ns-2 [14] on Internet-like graphs generated with LSIIT nm-0.94 [15]. III. O RIENTED

MULTICASTING

We propose an algorithm to define a new kind of multicast (i.e. oriented multicasting). The idea is to perform a limited multicast channeled around the unicast path joining the sender to a specific destination, hence the use of the term oriented. This algorithm is close to RPF multicast algorithms but the flooding is much more controlled. The generic principle of the algorithm is to reach only the nodes located on or near the (or a) shortest path between the multicast initiator S (called source) and the target node D (called destination). Every packet contains a special field 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 not decreased. When it leaves the shortest path SD, the policy depends on the parameter settings of the algorithm. It can be propagated by Reverse Path Forwarding (RPF) or by orthogonal multicasting. Orthogonal multicasting means A preliminary version was published in [12], [13].

3

that the packet is only sent on links not leading by a shortest path to the source or the destination (thus being “orthogonal” to the SD shortest path). This rule gives to the packets an orthogonal propagation effect intended to avoid packets redundancy. In most cases the packet range is decreased for each hop and thus the maximum traveling distance (out of SD) for the packet is limited to at most the initial range value. In some cases the initial range value is not fixed but depends on the position where the packet leaves SD. The initial range is then dynamically calculated at the point where the packet leaves the shortest path from S to D. The idea is that the distance that can be covered shall increase when the packet leaves the path farther from S. In fact the initial range is set proportionally to the value of the distance covered. 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 always a true shortest path does not matter and our algorithm still works.

for the initial range or TTL. The notion of attempt is defined as a single multicasting wave of search packets. If the search fails in the currently covered area, a new attempt is made with an increased initial range or TTL to cover an extended area. In the expanding ring example of figure 1 we represented three attempts, each one having an increased initial TTL value. Concerning the variants, two examples are shown in figure 1. Each variant example is represented with two attempts. We can see that the area of a search attempt of a variant is always surrounding the SD shortest path. In the context of our agent search service described in section IV, it is clear that the agents that can be found by an ERS could be at the opposite of the SD direction and thus not optimizing the S-A-D distance. Although the variants will cover a greater area than the expanding ring when SD increases, they have a much greater chance to find an agent located near the SD shortest path and thus minimizing the S-A-D distance. B. Data structures and algorithm

A. Oriented multicast variants Our algorithm is parameterized. By changing the values of the parameters we can obtain several different versions of our algorithm that we call variants. We study 10 of them in this paper. One parameter called shape controls the shape of the area covered by a oriented multicasting as shown in figure 1(a) and 1(b).

Table I lists the fields contained in the Oriented Multicasting Protocol (OMP) header. The OMP header will be identified in the IP header of the packet by a given value of the protocol number IP field. Notice that the IP source and IP destination addresses of a packet are noted src and dst in the rest of this paper. From the packet current router position, we define E as being a neighbor router not belonging to a SD shortest path. TABLE I O RIENTED MULTICASTING

D

D

S

S

(a) Expanding Ring shapes

HEADER FIELDS

D

S

Name SD

Values true, false

ED

true, false

(b)

Oriented Multicasting shapes

Fig. 1. Multicasting areas

S represents the node initiating the multicast search while D represents the target node of the multicast search (used by our algorithm only). Each thin black line defines the area covered in one search attempt with a given value

hops range


 
  

Description Boolean indicating if the packet comes from a link on a shortest path from S to D Boolean indicating if the packet comes from a link on a shortest path to D (from E which is not on a SD shortest path) Number of hops already done Integer used to define the degree of multicasting (the bigger it is, the farther the multicasting will be from the S, D axis)

4

The vrt (short for variant) structure contains the parameters of the algorithm. Table II gives a detailed explanation for each field of this structure. The variants of the group (a) of figure 1 are obtained with the shape parameter set to fixed and the variants of the group (b) with the shape parameter set to variable. TABLE II O RIENTED MULTICASTING

Name omcast

E omcast

Values rpf, ortho rpf, ucast

range dec

true, false

shape

fixed, variable

init range


 

PARAMETERS

Description Defines how packets are multicasted when out of the SD shortest path Defines how the packets are multicasted when out of the SD shortest path but on a shortest path to D Boolean indicating if the range has to be decreased when a packet is on a shortest path to D but not on a SD shortest path Defines the way of calculating the range value when the packets leave the SD shortest path Defines the initial range value of a packet

In our algorithm description we consider all the nodes of the network to be routers (the extension of the algorithm to hosts will be done at a later time). It’s worth noticing that our oriented multicasting algorithm maintains no state information in the routers. The functions composing the algorithm are given below in pseudo-code. As already said, the parameters of the algorithm are accessible through the vrt structure. These parameters could be included in the packets. This would enable to select a given variant without modifying any code in the routers. The overhead of including these parameters in the packet would be 13 bits (it is negligible). Concerning the implementation of OMP, we propose the use of the Router Alert IP option combined with a specific OMP header (as in RSVP [16]). The OMP header would contains an additional protocol nb field that would point to the network agent search protocol header. When an agent search is triggered at the search layer, the first pkt (short for packet) is created and fields that are specific to the oriented multicasting algorithm are initial-

ized by the I NITIALIZE function of the source S. At startup the packet is in S but is not on a shortest path from E to S or D because, according to our previous definition, E represent a router which is not on a shortest path from S to D.

 

 

  

 

!#"

I NITIALIZE 1 true 2 false 3 The ROUTE function provides an access to the underlying unicast routing system and tables.

%$'&'&)()*+,.-0/1
2 3*4()56$'78*9 /:
2 3*4(;56$ 78* $ &.&.()*+,

ROUTE 1 if leads to 2 then return true 3 else return false

by a shortest path

An incoming packet having the Router Alert option set and having an OMP header is processed by the R ECEIVE function. It performs a RPF check on the packet and discards it if necessary. It also decreases the value of the range, if appropriate, and transfers the packet to the S WITCH function.

 



R ECEIVE 1 if RPF C HECK 2 then D ISCARD 3 if false 4 then if 5 or 6 then 7 8 S WITCH

 6

0=< false  

 6

 < >.(? @(;$.
6A * & *47B< true 

< false 

@(;$.
6A *CD

@(;$.
6A *BEGF 

!D

IHF  



The aim of the S WITCH function is to determine the position of the packet (e.g. is it on a shortest path from S to D ?), in order to select a multicast technique. Notice that two variant parameters affect this choice.

 

 6

 <  

-  

<  

-0>.(?  ,JK7$L+ 0  

-0>.(? ,JK7$L+ 0

S WITCH 1 if true 2 then M ULTICAST rpf 3 else if true 4 then M ULTICAST 5 else M ULTICAST

The M ULTICAST function will spread the packet by various methods thus obtaining the different variants. The support for RPF-like forwarding is given by the rpf option. The ortho option only spread packets on links which are orthogonal to the SD direction (i.e. links not leading to

5

S or D by a shortest path). The function also sends a copy of the packet to the above layer via the P ROCESS function (see section IV). The interfaces of the router are noted oif for output interfaces and iif for input interfaces.

 

-0JM*8 0?&L  

 

@(;$'
6A *N'$'(?/:$'
2 @/1
2/: (?$'
6A *!#$' Q 0*8Jh]
ji  6

0  

 

4(;7klm$ &.&.(;*99 

&'+ =nM$ &.&.(;*99 

$)AL*8
2 W#" 

@ Qo9*Cp()*4q,r*94 

5r]
V7 R/:,
Kl5r]
V7 Q/Q9
/:& %"Ls?";"?  6

- rpf 

ATTEMPT 1 2 N EW 3 I NITIALIZE 4 5 6 7 8 9 T IMER 10 M ULTICAST-4 TH - LINE

(c) D replies to S

Fig. 3. Search phases

tocol. Idem. Idem.

N ETWORK

The P ROCESS function is called each time an OMP packet arrives in a router that runs the NLAS protocol. It checks if it can reply positively to the search request. It also handles the replies from an agent or the destination. In this algorithm, the search stops after having found one agent. However we can modify this behavior easily in order to stop only when a satisfactory agent is found. This can be defined in terms of delay or hop-count constraints. We discuss this issue in detail in section V.

 

 

@ Qo9* ()*4q,r*94 tP 5r]
V7 Q/Q9
:/ &h