Download Distributed Computation of Reduced Multicast Trees

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Airborne Networking wikipedia , lookup

Distributed operating system wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

CAN bus wikipedia , lookup

IEEE 802.1aq wikipedia , lookup

Kademlia wikipedia , lookup

Routing in delay-tolerant networking wikipedia , lookup

Transcript
Distributed Computation of
Reduced Multicast Trees
Dominique Grad ✝ ✸
grad@iutsud.u-strasbg.fr
Jean-Jacques Pansiot ✸
pansiot@crc.u-strasbg.fr
Stella Marc-Zwecker ✸
stella@dpt-info.u-strasbg.fr
✝
Département Informatique
IUT de Strasbourg Sud - Université Robert Schuman
72, route du Rhin F67400 Illkirch-Graffenstaden
(33) 88 67 63 80
✸
Laboratoire des Sciences de l’Image,
de l’Informatique et de la Télédétection
Université Louis Pasteur LSIIT URA-CNRS 1871
7, rue Descartes F67000 Strasbourg FRANCE
ABSTRACT : Routing in large scale groups sets a specific problem related, on the one hand, to the wide area, and
on the other hand to the dynamic aspect of groups. Group communication goes through the construction of a
multicast tree, along which messages are duplicated and propagated towards group members. We present a
distributed algorithm for dynamic construction of shortest path tree on a non oriented weighted graph. The distinctive
feature of our algorithm, is that nodes without duplication function are not implied in the multicast tree. We thus
propose a scalable communication structure which is effective for widely sparsed groups, therefore minimizing
intermediate state resources.
KEY WORDS : shortest path tree, multicast protocol, routing, distributed computing
1
Introduction
The cooperative multimedia applications - such as videoconferencing, distance learning, video on demand
and CSCW which involve widely sparsed user groups, require a multipoint delivery service. The problems related to
multipoint addressing and routing, have proved to be very different in nature than those encountered in point to point
communications. The interconnection architectures - which had initially been planned and deployed to support point
to point communications - turned out to be particularly ill-fitted for multipoint communications. A lot of multipoint
extensions have therefore become necessary in the Network level protocols [Dee89] [Mar94], and in the routing
protocols [Moy94] [WPD88].
1.
Taking into account very different problems at a same level, has widely led to increase the protocol’s
complexity and the load of hosts and routers [Her95]. To limit this overhead, we have suggested a 2-level
architecture in which the sublayer handling multicast will rely on the classical Network sublayer. In this architecture,
we have defined an intermediate Logical Addressing and Routing (LAR) sublayer between Network and Transport
layers [PGM95]. This LAR sublayer allows a best effort forwarding of datagrams towards a variable set of destinations
identified by a logical address (see Section 2).
A multipoint communication requires the building of a communication support between senders and receivers
which are group members. A tree, along which the messages are duplicated and forwarded to members, is the main
structure in use. This tree can be built in a global way if the group membership is known initially and if it remains
stable throughout the whole communication. But in most cases, multipoint communications deal with dynamic groups
that are widely spread in an interconnection of networks. As the communication progresses and the group evolves due to the joining and leaving of members - the forwarding tree has to be modified quickly and easily.
Trees used in our LAR sublayer, are incrementally built, and are reduced : nodes located at branching points
of the tree are the only nodes to be implied, and the nodes located along the branches of the tree ignore everything
about the multipoint communication. Depending on the service required, a reduced tree can either be a shortest path
tree or a center based tree. Within the study of our multipoint architecture, we will consider dynamic and distributed
algorithms, which require only local knowledge to build multicast trees [SRV94].
In this paper, we are going to present such an algorithm for the computing of a reduced shortest path tree. In
the next section, we are going to set out the LAR sublayer and in section 3, we explain the principle of our algorithm
and the control messages exchanged. In section 4, we describe the algorithm itself. In section 5, we evaluate somme
characteristics of a reduced tree. In section 6, we offer some perspectives to extend and improve our algorithm, and
then we conclude in section 7.
2
The LAR sublayer
The Logical Addressing and Routing sublayer is located above the Network layer and below the Transport
layer. It corresponds to the highest possible level in an intermediate system (except for Application gateways), while
remaining the lowest level to handle information whose semantics depends on applications - in fact a group
corresponds to a set of processes running an application at a given time. The function of this sublayer is to identify
groups and individual hosts independently of their geographical location, and to achieve routing based on this logical
addressing via a multicast tree.
The LAR approach is a part of more general group management mechanisms, on which we are working. We
consider that a group is controlled by a manager, in charge of creating/deleting the group and supervising the joining
of new members through a group access control. This step may be followed by an updating step extending the LAR
tree towards the new member.
2.
2.1
LAR addressing
LAR addresses provide logical identification of hosts and dynamic objects such as groups. They are totally
independent of any geographical location by opposition to Network layer addresses, such as IP addresses [Pos81].
There is no relation between LAR addresses and Network addresses structure, since their semantics are independent.
However, Transport addresses can be built from LAR addresses, by adding a selector for example, just as TCP
addresses are built from IP addresses by adding a port number. One of the advantages of LAR addresses is that they
thus enable independence between Transport connections and « Network connections ». This problem is of utmost
importance, especially in the case of mobile hosts, which have to be able to change their Network address without
interrupting a Transport connection.
2.2
LAR routing
The LAR multicast tree for a given group G contains only the nodes identified explicitly by the LAR address
of this group G. These nodes are member nodes of G and nodes which have a duplication function in G. Messages
addressed to the group G are therefore processed at the LAR level only by tree nodes : these messages are processed
only at the Network level on intermediate nodes which are located on the path between two tree nodes. The advantage
of our approach is that intermediate routers do not have to maintain entries for group, if they do not play an active part
in it (neither member nor duplicating node). This allows an important saving of resources in the intermediate routers.
Figure 1 depicts an example of our layered architecture : a LAR PDU is sent from LAR node S and received by LAR
node A, that makes a duplication, and sends two copies
INTERMEDIATE
NODE
B
DUPLICATING
LAR NODE
A
MEMBER
LAR NODE
D1
delivery
upper layers
of the received packet : one is sent to LAR node D1 and
another to LAR node D2.
Point-to-point LAR tree edges such as (A,D1)
duplication
LAR
sublayer
Network
sublayer
and (A,D2) are supported by the Network layer as routes
routing
between LAR nodes. Intermediate network nodes such as
B do not belong to the LAR tree, since their LAR
lower layers
sublayer is not involved in this group, and they will be
later called relay nodes. Only LAR nodes which are
From S
towards LAR node D2
Figure 1 : LAR architecture
group's members, such as D1, will deliver LAR PDUs to
upper layers.
The LAR tree initially contains the first member of the group, which is its manager. Then, the tree is built
incrementally by adding nodes each time the manager asks a member insertion. Our approach does not add an extra
level of insecurity as related to the Network level point to point communications, since duplication points are checked
in the tree. Besides, a node cannot be easily added to the LAR tree of a group on its own initiative, since it would have
to update the routing tables of its potential neighbour in the tree. Beyond the advantages we have already presented,
the LAR approach is interesting because it supplies a sublayer which is appropriate to multipoint communications and
independent of the underlying Network protocols.
3.
3
Principle of the algorithm
We are going to present a simple algorithm computing incrementally a reduced shortest path tree. This
algorithm builds the tree by adding and withdrawing nodes successively. A new member requires an extra duplication
to be inserted into the tree. The duplication point is located where the route from the tree root towards the new
member departs from the tree (see 3.6). A new branch is created between the duplication point and the new member.
The tree remains unchanged between the root and the branching or duplication point. The leaving of a member is
accomplished in a symmetrical way, by deleting a duplication, and by pruning useless branches, as far as possible
towards the root.
3.1
Hypothesis of this algorithm
The communication network is modelled by a graph G = {N, L, d}, in which N is a set of nodes,
interconnected by the set of communication channels or links L, and d : L → N * , is a weight function giving the cost
of the link between two nodes. We suppose that the channels are bidirectional, so the graph G is undirected. In this
first version of our algorithm, we suppose that there is neither loss of message nor node failure. Although this version
is still quite far away from the protocol, because of its restrictive hypothesis, it makes up a key basis to prove the
feasibility of the LAR routing. The root of the tree, which is set initially, is the only one to play a specific part. It is the
node which receives the joining requests and triggers the insertion process for new members. All other nodes of the
graph execute the same algorithm. We suppose that an underlying distributed routing algorithm is running. It
determines on each node a path towards each other node of the graph which is summed up as a next-hop table. Our
algorithm refers only to the next-hop table, being fully independent of the routing algorithm. Among the many unicast
routing algorithms, we could for instance use a static routing algorithm computing the shortest paths [Ray91].
3.2
The reduced tree
A reduced tree is made up of nodes which are either
1
members or duplicating nodes or both. The degree of a node is the
number of adjacent edges in the reduced tree. In Figure 2, the tree
9
has a root node which is member and duplicating (see node 7). The
2
reduced tree is composed of leaf members with degree 1 (see nodes
3
1,2,3,5,6), of duplicating members (see node 4 with degree 2), and
8
duplicating nodes (non members) with a degree superior to 2 (see
nodes 8 and 9).
7
The edges of the graph are the links between the nodes of
4
the graph. The edges of the reduced tree are made up of a succession
of one or several graph edges (see 6-7 edge made up of 3 edges of
the graph). The graph nodes located on a reduced tree edge, called
5
relay nodes, do not belong to the reduced tree : they do not store any
6
duplicating node
graph edge
member
reduced tree edge
Figure 2 : A reduced tree
root
information relative to the tree.
graph or
relay node
4.
3.3
The tree node context
We suppose that the nodes of the graph are identified by integers from 1 to card(N). A node i maintains a global
routing table, computed and updated by the routing algorithm, and a list of groups in which it is involved.
nexti[j]
grouplisti
routing table computed initially
list of groups
:
:
// next-hop towards node j
// groups in which node i is a tree node
The context of a node i , which belongs to the tree of group G (G ∈ grouplisti), is summed up by the following variables :
neighbi
fatheri
list of integers
integer
:
:
neighb9={ 1, 2, 8 }
father 9 = 8
1
neighb2={ 2, 9 }
father 2 = 9
neighb8={ 3, 7, 9 }
father8 = 7
2
3
8
neighb7={ 4, 6, 7, 8 }
father7 = 7
7
neighb4={ 4, 7, 5 }
father4 = 7
4
neighbi
is composed of the neigbour nodes of i in the
reduced tree. The list
neighbi
of a member node contains its own
expressed from the previous variables :
nodei
⇔
G
memberi
⇔
nodei ∧ ( i ∈ neighbi )
// true if node is member
rooti
⇔
nodei ∧ ( fatheri = i )
// true if node is the root
duplici
⇔
nodei ∧ (card(neighbi )> 2)
// true if node is duplicating
∈ grouplisti
// true if node is a tree node
//number of adjacent tree edges
In Figure 3, we present the context of the reduced tree nodes. We
can verify the following properties for this group G :
member2 = member1 = member3 = member5 =member6 = true
5
6
member
root
Figure 3 : Nodes context
3.4
The list
degreei = (nodei ? card( neighbi - {i} ) : 0 )
neighb5={ 5, 4 }
father 5 = 4
neighb6={ 6, 7 }
father6 = 7
duplicating node
// neighbour node towards root
identity i. For a given group G, the following definitions are
9
neighb3={ 3, 8 }
father3 = 8
// list of the neigbours tree nodes
// members
root7 = true
// tree root
duplic7 = duplic8 = duplic9 = true
// duplicating nodes
member4 = duplic4 = true
// member duplicating node
degree9 = 3 ; degree3 = 1 ; degree4 = 2
// node degrees
The initial tree
We suppose that the initial tree is composed of an unique root node identified by id (G ∈ grouplistid). It is the
first member and will stay the last member in the tree for the group G. Its context is the following :
nodeid = true , neighbid = { id } and fatherid = id
⇒
memberid = true, duplicid = false, degreeid = 0, rootid = true
The initial context of all other nodes is simply nodei = false (G
exist ; they will be created et initialized when node i becomes tree node.
3.5
∉ grouplisti).
The other context variables do not
The control messages
The following messages are processed by tree nodes, except the insertion message, which is processed by
intermediate nodes. These control messages allow incremental updates of the tree.
5.
INSERT NewMember, EdgeOrigin, EdgeEnd. The insertion message is forwarded from the root along tree
edges towards the NewMember, to find the location of the duplication point. Since intermediate nodes do not store
information about the tree, it is necessary to specify in the message, both endpoints of the current edge.
MEMBER Neighbour. The membership message is sent by the duplicating node, once located, towards the
new member. It creates a new tree branch from the duplication point to the new member. It notifies the new member
that it is being inserted as a tree leaf, and of the identity (Neighbour) of its father in the tree.
PRUNE Neighbour. The pruning message is symmetrical to the previous message. A leaf node, leaving the
group, sends such a message to its unique neighbour, which suppress Neighbour in its list and triggers in that way the
pruning of the useless branch.
REPLACE Oldneighbour, NewNeighbour. The replacement message is useful for spliting a tree edge in two
parts or for merging two edges in one. The middle node sends such a message to both endpoints, which substitute
Oldneighbour for NewNeighbour in their neighbours lists.
The group management requests, triggering the processes of members joining and leaving, are sent by the
upper layers in the form of service requests. The message JOIN_REQ NewMember is processed by the tree root, and
the LEAVE_REQ message is processed by nodes leaving the group.
3.6
Joining of a member
Duplication Point
A
Route towards
new member A that is
on tree
B
Route towards
new member B that is
out of tree
Figure 4 : INSERT message forwarding
We say that node is on tree, if it is a tree node or a relay node, otherwise a node is out of tree. Insertion of a
new member is achieved from the tree towards the member. Following reception of JOIN_REQ, an INSERT message
is processed by the root, then by each node on the route towards the member. As long as the next hop is an on tree
node, the INSERT message is forwarded along tree edges. If the new member is on tree (see A in Figure 4), the
message reaches its destination.
(A1)
New member is a duplicating node. It appends its own identity to the list of neighbours.
(A2)
New member is a relay node. This case requires to split the edge in two parts, by sending a
REPLACE message to each of the endpoints.
6.
If the new member is out of tree (see B in Figure 4), the route towards it branches of tree, the INSERT message is at
the duplication point. A branch is created between the duplication point and the new member by sending a MEMBER
message to the member (A3). One of the tree situations occurs :
(A3a)
The duplication point is a duplicating node (possibly member). It appends the new member on its list
of neighbours.
(A3b)
The duplication point is a relay node, not yet a tree node. It becomes tree node with degree 3, and
sends a REPLACE message to both endpoints of the current edge. which is splitted in two parts.
(A3c)
The duplication point is a leaf member. It becomes duplicating member, and appends the new
member to its list of neighbours
A3
D5
D5
D3
D3
A2
D4
tree after
insertion
D4
A5
initial tree
A1
A4
Figure 5 : Joining of members
In Figure 5, we present an initial tree and the five joining cases updating a tree. A1, A2, A3, A4 and A5 are
the new members. D3, D4 and D5 are respectively the duplication points of A3, A4 and A5, coresponding to situations
(A3a), (A3b) and (A3c).
3.7
Leaving of a member
Deletion of a member is achieved in a symmetrical way, from the leaving member towards the tree root, by
pruning the possibly useless branch as far as possible.
(R1)
A leaf member leaves the group. It sends a PRUNE message to its father, which deletes the member from
its list of neigbours and which stays :
(R1a) member or with degree > 2, then no change in tree
(R1b) with degree = 2 (and non member), merge of two edges by sending a REPLACE to each edge endpoint.
(R1c) with degree = 1 (and non member), next branch pruning by sending of a PRUNE message. This case
occurs exceptionally, if a relay node was staying temporarily on tree.
A duplicating member leaves the group. It suppress its own identity in its list of neighbours. If it stays :
(R2) with degree >2, then no changes in tree
(R3) with degree = 2, merge of two edges by sending a message REPLACE to each edges endpoint.
7.
R5
initial tree
F3
F3
F5
F5
R3
F4
R1
R2
F4
tree after
deletions
R4
Figure 6 : Leaving of members
Nodes R1, R2, R3, R4 and R5 (see Figure 6) are leaving nodes. F1, F4 and F5 are respectively the father nodes of
R1, R4 and R5, coresponding to situations (R1a), (R1b) and (R1c).
3.8
Node state diagram
A node (except the root) will be in one of the four following states for a given group :
• Member
is a member node, tree leaf with degree 1
• Duplicating Node
is a non member node with a duplication function, with degree > 2
• Duplicating Member
is a member node with degree > 1
• Graph Node
otherwise (relay node or out of tree)
The diagram transitions A1, A2 and A3 are concerning a node becoming member, but A3a, A3b and A3c are
side effects on existing tree nodes. The diagram transitions R1, R2 and R3 are concerning a member leaving the
group, while R1a, R1b and R1c are the effects induced by this removal on a remaining tree node (see Figure 7).
Graph
Node
(A3)
(A2)
(R1)
(A3b)
(R1b)
(R3)
(R1c)
Member
(R1a)
(R1a)
(R1a)
(A3c)
Duplicating
Member
(A3a)
Duplicating
Node
(R2)
(A3a)
(A1)
Figure 7 : Node state diagram
8.
4
The algorithm
We are now presenting firstly the particular algorithm of the tree root processing of JOIN_REQ.
// Behaviour of root node id
Upon receipt of JOIN_REQ, NewMember
do
if ∃ v ∈ neighbid / next(v) = next(NewMember)
then
// next hop is on tree edge
send INSERT, NewMember, id, v to next(v)
else
// new branch towards NewMember
neighbid := neighbid ∪ {NewMember}
send MEMBER, id to NewMember
fi
od
Remember that in the next parts of the algorithm, the control messages contain the group identifier, which is
implicitly used by node i to identify its corresponding context.
// Behaviour of node i
Upon receipt of INSERT, NewMember, Orig, End
do
if memberi ∨ duplici
then
// node i is already a tree node
if NewMember = i
then
// (A1) duplicating node becomes member
neighbi := neighbi ∪ {i}
else
if ∃ v ∈ neighbi / next(v) = next(NewMember)
then
// forwarding on tree edge
send INSERT, NewMember, i, v to next(v)
else
// (A3) (A5) new branch
neighbi := neighbi ∪ {NewMember}
send MEMBER, i to NewMember
fi
fi
else
// i is a relay node
if NewMember = i
then
// (A2) relay node becomes member
grouplisti := grouplisti ∪ { G }
send REPLACE, Orig, i
to End
send REPLACE, End, i
to Orig
neighbi := { i, Orig, End }
else
if next(End) = next(NewMember)
then
// forwarding on tree
send INSERT, NewMember, Orig, End to next(End)
else
// (A4) relay node i becomes duplicating
grouplisti := grouplisti ∪ { G }
neighbi := { NewMember, Orig, End }
fatheri := Orig
send REPLACE, Orig, i
to End
send REPLACE, End, i
to Orig
send MEMBER, i
to NewMember
fi
fi
fi
od
Upon receipt of REPLACE , Old, New
do
// edge split or edge merge
neighbi = neighbi \ {Old} ∪ {New}
9.
if fatheri = Old
then
fatheri := New
fi
od
Upon receipt of MEMBER, UniqueNeighbour
do
// (A3) new member tree leaf
grouplisti := grouplisti ∪ { G }
neighbi = { i, UniqueNeighbour }
fatheri := UniqueNeighbour
od
Upon receipt of PRUNE, OldMember
do
neighbi = neighbi \ {OldMember}
if memberi ∨ degreei > 2
then
// (R1a) no changes
fi
if degreei = 2
then
// (R1b) v1-i and i-v2 concatenation
send REPLACE, i, v1
to v2
send REPLACE, i, v2
to v1
grouplisti := grouplisti \{ G }
fi
if degreei = 1
then
// (R1c) edge i-v pruning
send PRUNE, i
to v
grouplisti := grouplisti \{ G }
fi
od
Upon receipt of LEAVE_REQ
do
neighbi = neighbi \ {i}
if degreei > 2
then
// (R2) no changes
fi
if degreei = 2
then
// (R3) v1-i and i-v2 concatenation
send REPLACE, i, v1
to v2
send REPLACE, i, v2
to v1
grouplisti := grouplisti \{ G }
fi
if degreei = 1
then
// (R1) edge i-v pruning
send PRUNE, i
to v
grouplisti := grouplisti \{ G }
fi
od
5
Algorithm analysis
5.1
Number of messages
We are going to evaluate the complexity in number of messages of our algorithm. We suppose that a message,
exchanged between two tree nodes and forwarded by m intermediate nodes, will be considered as m messages. The
algorithm generates an INSERT message for each new member. This message is transmitted from the root towards a
duplication point. Then a MEMBER message is sent towards the new member if necessary. In any cases, the INSERT
message and the MEMBER message are forwarded d times, d being the hop count or distance between the root and the
new member. Let D be the average distance from the root tomembers, D = avg (di) / i ∈ [1 , n - 1]. Therefore,
consequently to n joining members, the complexity in number of messages is O(n ∗ D).
10.
5.2
Number of tree nodes
We are now going to estimate the number of nodes implied in a reduced tree. An n member group needs at
most n - 2 duplication points. In the worst case, all these points are distinct with degree 3, and members are tree
leaves with degree 1. The number of tree nodes is n + n - 2 = 2 * ( n - 1 ). In the best case, the root node is the unique
duplication point with degree n - 1, and the number of tree nodes is n. The number of nodes in a reduced tree is in
O(n).
In a non reduced tree, the intermediate nodes with degree 2 are added. In the case where paths from the root
to members are all distinct, the number of intermediate nodes is Σdi , i ∈ [1 , n - 1], with di being the hop count
between the root and leaf member i. Let D be the average distance (hops) from root to members, D = avg (di) / i ∈ [1 ,
n - 1]. The number of nodes in a non reduced tree is in O(n ∗ D)
We developed a graphical tool, simulating the principle of our shortest path tree building algorithm. On
random generated graphs [Wax88], and with random group membership, this tool calculates different tree
characteristics : number of nodes, number of relay nodes, average degree, diameter, average distance ...
We compared the number of nodes in a reduced tree to the total number of nodes in the same non reduced
tree. We calculated the ratio of relay nodes among all nodes, including members, in various trees. This ratio was
calculated on random generated graphs of 100, 200 and 500 nodes for groups made up from 2 to respectively 50, 100
and 250 members. Secondly, we displayed the same ratio for groups from 10 to 250 members, which are sparsely
located on the Internet (see Figure 8). In fact, from an Internet routes database, we have randomly selected hosts in the
Internet, computed shortest path trees and deduced shortest path trees [Pan95].
100%
80%
Internet
60%
40%
20%
100 nodes
200 nodes
500 nodes
0%
# of members
Figure 8 : Ratio of relay nodes
We can clearly verify that the ratio of relay nodes, which are useless in a reduced tree, is very significant. On
large graphs and moreover on the Internet, the saving of intermediate resources is maximal with small sparsed groups.
In case of a private group meeting with about 20 members located on the Internet (for instance an IETF working group
meeting), more than 80% of tree nodes are relay nodes in the multicast tree. They could stay out of the tree and they
would have no knowledge of this communication with a multicast routing protocol such as LAR.
11.
6
Fault tolerance
We are going to consider fault-tolerance extensions of our algorithm and give some hints on how we could
make it more robust and closer to a real implementation. In a fault-tolerant version the algorithm supplying the
routing information has to be adaptative, in order to take into account networks topology changes [MS79]. The relay
node and intermediate link failures are handled by this algorithm and therefore they are not detected by tree nodes.
The losses of multicast data messages are not processed by our algorithm which provides a best effort
datagram delivery service. On the other hand, the control traffic, especially insertion messages, could be made reliable
through a mechanism of acknowldgements and hop by hop retransmissions. When it sends an insertion message, a
tree node sets a timer. On receiving such a message, a tree node sends back an acknowledgement to the sender node,
thus meaning it assumes the insertion. When the timer expires, without the reception of an acknowledgment, the node
sends the insertion message again and resets the timer. This mechanism allows to delegate the responsibility of an
insertion hop by hop downstream on the tree nodes, and prevents many retransmissions from the tree root in case of
loss of an insertion or an acknowledgement message. On the other hand, this mechanism will not have a end to end
semantics.
The detection of a tree node failure, that is not handled by the routing algorithm, could be handled by a
mechanism at the initiative of downstream nodes. Each tree node periodically sends a message to its father node.
When receiving such a message, the father node acknowledges it and stores the timestamp of arrival. In absence of
such a message, the father node simply cuts this branch.
Local reconfiguration following a tree node failure could be handled with a mechanism that would consist in
storing the grand-father identity two hops upstream away. On detecting the failure of its father node, a node sends a
reconfiguration message towards its grand-father which - if it agrees - acknowledges the reconfiguration. The grandfather replaces its son which has broken down by the message sender. We could therefore tolerate the failure of one
generation of tree nodes, but not the failure of two consecutive generations. Without a response from its father or its
grand-father, a node multicasts downstream a sub-tree destruction message. Each member node on this sub-tree will
have to perform its own reconnection request.
The root failure is an important issue, and it requires the complete rebuilding of the tree. It would be easier to
build a new tree from a spare root, instead of trying to reconnect the subtrees by processing an expensive recovery
mechanism.
7
Conclusion
Our algorithm for the building of reduced multicast trees, intended for our LAR architecture, will offer a
scalable multicast routing structure. We have seen that the number of relay nodes in a multicast tree is dependent of
the average distance between the root and members. This amount of nodes is particularly important in graphs with a
12.
large diameter such as Internet. These relay nodes are not implied in a reduced tree, since they simply implement a
unicast routing mechanism, and their lighter function can be considered as a global saving of multicast routing
resources.
A better specification and future simulation of the fault-tolerant algorithm will allow us to make a
performance evaluation, as well as an exact comparison with real implemented protocols [DEF95] [BFC93]. The
global simulation will allow us to compare the reduced tree characteristics with those of other dynamic and distributed
algorithms [KJ83] [BB93]. We are also working on the building of reduced center based trees with dynamical center
migration.
Bibliographie
[BB93]
M. Bui, F. Butelle. Construction répartie d’arbre couvrant de diamètre minimum. Rapport de
Recherche INRIA N° 2017, Sept. 93
[BFC93]
T. Ballardie, P. Francis, J. Crowcroft. Core Based Trees (CBT): An Architecture for scalable InterDomain Multicast Routing, SIGCOMM’93, Ithaca, N.Y., USA, Sept. 93
[Dee89]
S. Deering. Host Extensions for IP Multicasting. Network Information Center, Request for
Comments RFC1112, Aug. 89
[DEF95]
S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L. Wei, P. Sharma and A. Helmy. Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification. Internet Draft, Aug. 95
[Her95]
O. Hermanns. Performance Evaluation of Connectionless Multicast Protocols for Cooperative
Multimedia Applications. Proc. of Performance Tools’95, Heidelberg, Sep. 95
[KJ83]
B. Kabada, J.M. Jaffe. Routing to Multiple Destinations in Computers Networks. IEEE Transactions
on Communications, Vol. COM-31, N° 3, pp. 343-351, Mar. 83
[Mar94]
D. Marlow. Host Group Extensions for CLNP Multicasting. Network Information Center, Internet
Draft, May 94
[Moy94]
J. Moy, Multicast Extension to OSPF, Network Information Center, Request for Comments,
RFC 1584, Mar.94
[MS79]
P. Merlin, A. Segall. A Failsafe Distributed Routing Protocol. IEEE Transactions on Computer, Vol.
COM-27, N° 9, pp. 1280-1287, Sep. 79
[Pan95]
J-J. Pansiot. On Routes, Trees and Multicast in the Internet. LSIIT, Université Louis Pasteur,
Rapport interne à paraître
[PGM95]
J-J. Pansiot, D.Grad, S. Marc-Zwecker. Towards a Logical and Addressing and Routing Sublayer for
Internet Multicasting, Proceeding of PROMS’95, Salzburg (Austria), Sept. 95
[Pos81]
J. Postel. Internet Protocol. Network Information Center, Request for Comments, RFC 791, Sep. 81
[Ray91]
M. Raynal. La communication et le temps dans les réseaux et les systèmes répartis. Ed. Eyrolles
13.
[SRV94]
H.F. Salama, D.S. Reeves, I. Viniotis, T. Sheu. Comparison of Multicast Routing Algorithms for
High-Spedd Networks, IBM Technical Report IBM-TR29.1930, Sept. 94
[Wax88]
B.M. Waxman. Routing on Multipoint Connections. IEEE Journal of Selected Areas in
Communications. Vol. 6, N° 9, Dec. 88
[WPD88]
D. Waitzman, C.Partidge, S. Deering. Distance vector Multicast Routing protocol. Network
Information Center, Request for Comments, RFC 1075, Nov. 88
14.