A dynamic distributed multicast routing protocol

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to a data network and, in particular, relates to a multicast protocol for finding, joining, and leaving a multicast group that receives specific information.

【0002】

[Conventional technology]

Nowadays, users associated with multimedia terminals such as ordinary workstations or PCs, such as lectures, audio / video conferencing, broadcast audio provided by nodes such as packet exchanges in digital networks. A request to participate in a specific event can be input by the terminal.

【0003】

Participate in the event because it is typically associated with some type of identifier, namely a group identifier (eg, an 800 number (recipient-paid telephone number) or conference bridging number in a regular telephone network). A user who wishes to do so can identify an event in the request he / she makes to his / her terminal. The user's terminal then sends this request to the relevant serviced node in the digital network.

【0004】

A group identifier can represent a set of users who are interested in specific information associated with an event. Group identifiers are different from the identifiers used to identify a particular user. Typically, the membership associated with a group identifier can be dynamic, allowing members to enter and leave the group at any time.

【0005】

Also, there are no restrictions on the physical location of multicast group members, which may or may not be in the same physical location. The network does this by maintaining information about the group and typically configuring a network directory used to track the connections of active members. That is, the serviced node gives the group identifier to the network directory.

【0006】

[Problems to be Solved by the Invention]

This directory returns the address of the nearest node that can join. The servicing node then sends a request to join the multicast group to the identified node. Nodes that join or leave the multicast group must advertise the directory so that they can update their membership information. Unfortunately, membership can change so often that managing such directories can be costly and inefficient.

【0007】

The network may also maintain such membership by configuring a multicast server in the network. The data transmitted by the user is then first sent to the server, which sends this information to all other members of the multicast group. Although this approach seems simple to implement, it can cause the server to fail at a single point during an event. Also, this approach does not make good use of network resources because user data must be sent to the server.

【0008】

[Means for solving problems]

The present invention is for a data network to maintain multicast group information in a distributed format in which any node in the network can automatically locate, join and leave a multicast group. Provides an efficient and standardizable mechanism for. This mechanism is distributed so that a single node must maintain complete information about other participants in the multicast group.

【0009】

In particular, according to an exemplary embodiment of the invention, a multicast group constitutes at least one routing tree formed from selected paths to each of a number of other nodes identified in the tree. Enter a request to join a multicast group by sending an identifying discovery message to a node selected according to the routing tree. In response to receiving a message identifying the closest node connected to the multicast group, the requesting node simply sends a join message to the identified node to join the multicast group.

【0010】

BEST MODE FOR CARRYING OUT THE INVENTION

Our new protocol is what we call a "Participant-Initiated Join", that is, a node issues a request to join a multicast group, and in doing so joins the multicast. Supports those that determine the network path that should be used to. The first stage is called the "Find" stage because it is the node that issues the request to determine the identity of the node that is already in the multicast tree.

【0011】

The second stage is called the "Join" stage because the requesting node attempts to join the nearest node already on the multicast tree. During the discovery phase, a node attempting to join a multicast group generates a request message and sends the request message to all of its neighbors on the shortest path tree that has roots in the requesting node.

【0012】

The next node that receives this message sends this message to the next node downstream along the link in the shortest path tree that has roots in the starting node. This process continues until the request message reaches either a node that is already on the multicast tree or a leaf node in the shortest path tree that has roots in the starting node (ie, the node that has the desired multicast information). ..

【0013】

Each node already on the multicast tree responds to the request with a cost parameter set to 0. Leaf nodes that are not on the multicast tree respond to requests with a cost parameter set to -1. In receiving all responses to a message, the node determines the closest node and sends the response message upstream from the closest node towards the request initiating node. Before doing this, the node updates the cost function to reflect the cost from this node to the nearest node.

【0014】

The starting node receives all the responses and determines the closest node. This ends the discovery stage. At the join stage, the requesting node determines the path to the nearest node and sends a join request message. This determined path is inserted in the message so that intermediate nodes do not have to make the same decision. The closest node with the requested information responds with an acknowledgment message, and all nodes in the path are branches of the multicast tree.

【0015】

The example described above is shown in FIG. 1, and it is assumed that the multicast information sought is multimedia event 150, eg, a broadcast lecture. The multimedia signals that characterize the multimedia event are fed to node 105, which requests to receive a copy of such signals via network 100 formed from data nodes 105,110,115,120,125,130 and 135. It can operate as a normal video server to supply the input user with a video signal in the form of a digital signal.

【0016】

In one embodiment of the invention, for example, each node is a conventional ATM switch. The user associated with workstation 170 enters the request in the usual way using a keyboard (not shown) to view the event on monitor 175, where the request contains an identifier associated with the multimedia event. However, this request does not include the identity (eg address) of the source of the multicast information.

【0017】

Upon receipt of the request, workstation 170 translates the request into the format expected by the associated network node 125, which is also shown as the E node. As one aspect of the invention, each network 100 does not include a directory that identifies the information provided by the nodes of the network 100. Therefore, in order to find the node having the multicast information, the node 125 pools each of the nodes of the other network 100.

【0018】

However, before doing so, node 125 constitutes a tree formed for each of the other nodes from the selected path, and the selection is a given parameter such as cost, number of hops, etc. It is made based on. In one embodiment of the invention, the cost is characterized by a weighted value. Such weighted values are shown in parentheses in FIG. 1 and are used to identify at least the cost path / route, as described above.

【0019】

For example, if node 120 (D) needs to send a message to node 105 (A), node 120 will probably send the message via node 110 (B). This is because the sum of the weights associated with the links in the path is less than the sum of the weights associated with the links in the path through node 115 (C), i.e. (5) + (1) < This is because it is (6) + (3).

【0020】

Therefore, according to known technology, at the discovery stage, node 125 constructs a path tree and controls the routing of messages in order to find the node having the required multicast information, that is, the event 150 to be broadcast. Use a tree. An example of such a tree is shown in Figure 2. Therefore, node 120 sends the discovery message to node 135 (G) and node 120 (D) according to the tree.

【0021】

This discovery message includes, among other things, the address of the message starting node, the identifier associated with the requested information, and the request for the identity of the node that has the requested information. This message may also contain information that characterizes the constructed path tree. Therefore, upon receiving the message, node 135 returns a response message with a cost parameter set to -1.

【0022】

Node 120 does not have the required information, but as shown in Figure 2, the path tree indicates that the message must be routed individually to nodes 110, 115 and 130, so node 120 sends the message. Do not give up. Similarly, when a message reaches node 110, the node does not abandon the message and sends it to node 105 (A), even if the message does not have the required information. Therefore, it is assumed that node 105 has the required information, and node 105 sets the cost parameter to 0 and returns a response message containing the identity (address) of node 105 to node 125. Respond to received messages.

【0023】

Upon receipt of the response message, node 125 enters the participation phase, as described above. At this stage, node 125 constitutes the shortest path to node 105 and sends a join message containing the address of node 125, along with a request to join the multicast of the identified event.

【0024】

It can be seen in FIG. 2 that such a path would go through nodes 110 and 120 instead of going through nodes 115 and 120. Node 105 replies with an acknowledgment of participation and begins supplying the broadcast event to node 125 via the determined path. When nodes 110 and 120 in the multicast path start receiving multicast information, nodes 110 and 120 record in their respective internal memory that they have such information.

【0025】

At this point, it is also assumed that the user associated with node 130 also wants to receive the multicast and enter a request for that information. Similarly, node 130 constitutes a minimum cost path tree and issues its own discovery message according to a tree (not shown). When this message reaches node 120, it responds to node 130 with a response message indicating that it has information.

【0026】

As mentioned above, node 130 collects response messages and, from these messages, determines which of the nodes with the required information is closest to node 130. In this example, the closest node for the desired purpose would be node 120. Therefore, node 130 can participate in the multicast by sending a join message to node 120 instead of to node 105. Then, when node 120 receives a packet of such information from node 110, node 120 sends a copy to node 125 and node 130.

【0027】

At this point, if the user enters a request to terminate the reception of the multicast on workstation 170, node 125 forms a segregated message, which is sent to node 120 according to a configured path tree rooted in node 125. Send to. When node 120 receives this message, node 120 stores this message in local memory and terminates the supply of multicast information to node 125, but continues to supply this information so that it can be received by node 130. Will be done.

【0028】

If node 130 issues a separate message prior to the end of the broadcast event, node 120 supplies the multicast to node 120 in response to this message and in response to the absence of other receiving nodes for multicast. Send a message to node 110 to exit. Similarly, node 110 sends a similar message to node 105 if there are no other receiving nodes for the multicast information.

【0029】

A situation can occur in which one node receives discovery messages from multiple nodes, eg, two nodes, at about the same time (simultaneously). To handle this situation and maintain the accuracy of the distributed protocol, one node, eg node 125, adds a time stamp to the discovery message.

【0030】

In this method, if one node, eg node D, receives discovery messages from nodes 125 and 130 at the same time, node D processes the discovery message with the early time stamp and the response message with the late time stamp. Reply to the node that issued the message, for example node 130. Then, when the minimum cost multicast path is established from node 105 to node 120, node 130 issues a discovery message after waiting for a random (or predetermined) time and proceeds as described above.

【0031】

In one embodiment of the invention, the principles of the invention are embodied in a state machine embodied at each network node for each multicast group. An example of such a state machine is shown in FIG. 3, which consists of five main states: idle state 301, standby state 302, tentative state 303, active state 304 and retry state 305.

【0032】

Before discussing FIG. 3, different messages that can be sent by a node attempting to join a multicast and messages sent by other nodes in the network in response to a request to join a multicast session will be described. A node attempting to join a multicast tree / session sends a request message as described above.

【0033】

The request message header contains, among other things, the identity of the multicast information, the identity of the sending node and the time stamp. It can also include a count of retries. Request messages can only be initiated by idle nodes. One node sends a response message in response to a request message.

【0034】

The response message contains the header information of the request message and an associated cost parameter that identifies the cost of the shortest path from the current node to the nearest node already on the tree. This cost is updated when the response moves from one node to another. This cost is set to -1 if there are no active nodes on a particular path.

【0035】

One node sends a retry message when it is determined that another request has already been processed, as described above. Requests with an early time stamp are allowed to continue as long as the retry message is sent to the start node of the request with the late time stamp, as described above. One node sends a join request message if it wants to join the multicast session / tree.

【0036】

The path to the nearest node is encoded in this message. The active node sends a join acknowledgment message in response to receiving the join request message. Receiving this message indicates that one node is on the multicast tree. When a node wishes to leave the multicast session / tree, it sends an isolation message to the active neighbor.

【0037】

In FIG. 3, in the idle state, the node has no information belonging to the multicast information (that is, the tree). After sending the request message, the node goes into a wait state and waits for a response. The node enters a tentative state after sending a join request message to the nearest node already on the multicast tree. In this state, the node waits for the join acknowledgment message.

【0038】

A node enters the active state when it participates in a multicast session, that is, when it is on the multicast tree. A node reaches this state when it receives a join acknowledgment message from a node that is already on the tree. Also, an active node can maintain tree information about all the links that accompany it and belong to the tree. However, the node does not maintain any state information about the new request in order to join the tree.

【0039】

To join the multicast tree, the node, if it is the initiating node of the request, reaches a retry state and receives a retry message via one of the links in the tree. In this state, the node does not need to maintain any state information about other requests. The node also waits a random amount of time before retransmitting the original request. This node can also keep track of the number of request messages it sends.

【0040】

An enhanced version of the idle state is shown in Figure 4. As mentioned above, the node issues a request message when idle.

【0041】

Only nodes in this state can issue request messages. Request messages are identified using tuples <sending node ID, time stamp, retry count>. Here, the sending node ID is the ID of the node that is the originator of the message, the time stamp is the counter value in the sending ID, and the retry count is the number of attempts that the node has joined the tree. The retry count is initially 0.

【0042】

The initial request message is sent over all links via the shortest path tree rooted at the starting node. Then, the node enters the standby state. When the node receives either the request message (action path 401) or the join request message (action path 402), the following actions are taken. For example, a request message is received from node B and therefore tuple <ID_B , CNTR_B , RC_B > Is included. Then, the receiving node performs the following operations.

【0043】

If the message is not on the shortest path, send a response message to the starting node at cost = -1. If not, update the time stamp (local counter). Save message status information. Send a request message. Change the state to the standby state. If no link is available, send a response message with cost = -1. Change the state to the idle state.

【0044】

When the participation request message is received from node B, the receiving node proceeds with the process as follows.

【0045】

Send a join request message to the next node. Change the state to a temporary state. If the current node is the final destination recorded in the message, return a response message to the starting node. This condition can occur if the node changes its state from the active state to the idle state during the time between sending the request message and sending the join request message to node B.

【0046】

Enhanced versions of the standby state are shown in Figures 5A, 5B and 6. For Figures 5A and 5B, the node has a tuple <ID_A , CNTR_A , RC_A Suppose a request message containing> is received from node A.

【0047】

Also, the node has a tuple <ID_B , CNTR_B , RC_B When a request message containing> is received from node B, the node takes the following actions (path 501):

【0048】

Update the local time stamp counter. If the message is not received via the shortest path, send a response message to node B and set the cost to -1. If the message is received via the shortest path and Node B takes precedence over Node A in time, it sends a retry message to Node A. Clear the state information belonging to node A. Saves information belonging to node B and sends a request message.

【0049】

If a node receives a response message via one of its links, it takes the following actions (path 502):

【0050】

If the response message does not contain state information, ignore it. If not the last response, store cost information and wait for another response message. If it is the last response message, determine the best message by minimizing (message cost field + link cost). Then, after updating the cost, it sends an optimal message to the request start node. Change the state to the idle state. If it is the start node of the request message, calculate the shortest path to the shortest node. Send a join request message to that node via the shortest path. Change the state to a temporary state.

【0051】

If the node receives a retry message via one of its links, it takes the following actions (path 601 in Figure 6):

【0052】

If the retry message does not contain state information, ignore it. Clears the state information and sends a retry message to the request start node. Change the state to the idle state. If it is the start node of the request, it changes the state to the retry state. Increment the retry count value. Wait for a random amount of time and resend the request message with the updated retry count value. Here, the same count value (CNTR) will be used to ensure fairness.

【0053】

When this node receives a participation request message from a node, for example, node B, that node proceeds as follows (path 602 in FIG. 6).

【0054】

Change the state to a temporary state. If the next node information is available, send a join request message to the next node and a retry message to node A. If the next node does not exist, a retry message is sent to the start node of the join request message.

【0055】

An enhanced version of the tentative state of FIG. 3 is shown in FIG. 7, where a node enters the tentative state after receiving a join request message initiated by another node, eg, node A. At that point, the node has a tuple <ID_B , CNTR_B, RC_B When a request message is received from node B containing>, the receiving node proceeds in the following way (path 701).

【0056】

If the request message is not received via the shortest path, a response message is returned to the starting node with cost = -1. If not, update the local counter value. Send a retry message to the starting node of the message.

【0057】

On the other hand, if the node receives a retry message, the node takes the following actions (path 702):

【0058】

If the retry message matches the join request message, send the retry message back to node A. Change the state to the idle state. If the retry message does not match the join request message, ignore it.

【0059】

If the node receives the join acknowledgment message in another way, the node takes the following actions (path 703):

【0060】

Change the state to the active state. Send a join acknowledgment message to node A. Clear all status information. Update the multicast tree information so that the join request message contains the received link.

【0061】

An enhanced version of the active state in Figure 3 is shown in Figure 8, and the node is already on the multicast tree. In this case, only that node responds to new and join requests. Other messages can be ignored.

【0062】

The active node has a tuple <ID_B, CNTR_B , RC_BWhen a request message is received from node B containing>, the receiving node takes the following actions (path 801):

【0063】

If the request message is not received via the shortest path, a response message is sent to the starting node with cost = -1. If not, update the local counter value. Send a response message with cost = 0.

【0064】

On the other hand, when the node receives the participation request message from the node B, the node returns the participation acknowledgment message to the node B (path 802). If the node otherwise receives the isolation message from node B, the node takes the following actions:

【0065】

Update multicast tree information. If there is only one active next-door node and that node is not a member of the multicast group, send an isolation message to the next-door node. Change the state to the idle state.

【0066】

An enhanced version of the retry state is shown in Figure 9. The node goes into a retry state after sending the request message. Node A is in retry state and the associated tuple information is <ID_A , CNTR_A , RC_A >, Node A sends the request message and its tuple information is <ID_B , CNTR_B , RC_B Suppose it is received from node B, which is>. In this case, node A takes the following actions (path 901).

【0067】

If the message is not on the shortest path, return a response message with a cost set to -1. Update the local counter. If node A takes precedence over node B in time, send a retry message to node B. When node B takes precedence over node A in time, it saves the state information of node B and sends a request message. Save node A information and stop node A's retry timer. Node A cannot join the multicast group until Node B joins. Change the state to the standby state. (Node A will wait for node B).

【0068】

On the other hand, when the participation request message is received from node B, that node takes the following actions (path 902).

【0069】

Change the state to a temporary state. Send a join request message to the next node on the path. Saves node A information and waits. (Node A cannot resend the request message until Node B joins the multicast group). When the retry timer expires, the retry count value is incremented and tuple <ID_A , CNTR_A , RC_A Send a request message containing>. CNTR_AThe old value of is used to guarantee fairness.

【0070】

The above can be easily embodied in a network formed by a plurality of so-called peer groups. Peer groups are groups of network nodes that form smaller networks. In particular, large networks formed by a large number of nodes can be logically reconfigured to improve the efficiency of numbers. Such a reconfiguration requires groups of nodes, each acting as a smaller network. Here, the connection management function is logically extended to each level of the network hierarchy.

【0071】

State information is maintained at each physical node. Each group is also represented by a peer group reader (PGL) as a logical node at a higher level in the network hierarchy. PGL maintains separate state information for logical nodes at that hierarchy level. Logical nodes perform the same state transitions as physical nodes at lower levels in the network hierarchy. In this sense, our new protocol is applicable to such networks with the following modifications (extensions):

【0072】

Discovery stage i) Participating nodes require their PGL to enter the "discovery" stage at the next highest level in the hierarchy. At the logical level, pre-established virtual connections between logical nodes are used to send request and response messages. At the discovery stage, a logical node, like a physical node, can make a transition from an idle state to a wait state and a retry state.

【0073】

ii) If the PGL is already active at a high level (which can mean that some other active node is in the peer group), this information is returned to the requesting node. Upon receiving this information, the requesting node executes a protocol to determine the closest active node in the peer group. The ID of the closest physical or logical active node is returned to the low-level request node. If the current level is the lowest, the requesting node enters the join phase.

【0074】

iii) Otherwise, the PGL iterates over the above steps at a higher level until it reaches the top level of the hierarchy. At that level, PGL enters the discovery stage. At the end of the discovery phase, the requesting node has the ID of the closest active node. This ID can be either the physical ID of a node in the same peer group (for a single peer group) or, for multiple peer groups, the logical ID of a higher level node in the logical peer group. possible.

【0075】

Participation stage Based on the available terrain information, the requesting node determines the path to the nearest node. This path will not be completed if the closest node is a logical node in a higher level logical peer group. The determined path is stored in the form of a designated transition list (DTL). This is described in Private Network Node Interface (PNNI) Specification Version 1.0, available from ATM Forums, 2570 West, El Camino Real, Suite 304, Mountain View, California 94040-1313. The DTL is embedded in the join request message before being sent to the nearest node. Upon receiving the join request message, the node executes the following protocol.

【0076】

i) If the node is already active, reply with a join acknowledgment message. The join acknowledgment message is replied to the start node in the opposite direction with the same path.

【0077】

ii) Otherwise, if the DTL stack is not empty, the join request message will be sent to the next node based on the information available in the DTL. The new path can be added to the DTL by the entry node as described in the references above. Also, join request messages and join acknowledgment messages can be transmitted over network signal channels. A join request message or join acknowledgment message is sent through a boundary link, and a logical node at the appropriate level must be notified so that the logical node can make a state transition to a tentative or active state, respectively. Must be. This is done by sending a copy of the join request or join acknowledgment message to the appropriate logical node.

【0078】

iii) If the DTL stack is empty, the node enters the discovery stage to determine the closest active node. Then, the information of the nearest node is encoded as DTL, and the message is transmitted to the nearest node.

【0079】

Similar actions are taken when the participating node leaves the multicast group. In this case, the isolation message is sent to the active neighbor node if the participating node has only one active neighbor node. Then, the participating node enters the idle state. If the next node has only one active next node instead of a participating node, it sends an isolation message to its nearest neighbor. If the isolated message is sent through a boundary link, a copy of the message is sent to the appropriate logical node so that the overall state of the node can be changed to the idle state.

【0080】

The extended protocol just described will be further understood by describing it in relation to the examples shown in FIGS. 10-13. A network formed from three peer groups 201, 202 and 203 of a network node (eg, an ATM switch) is shown. The nodes in peer group (a) 201 are labeled A.1 to A.5, respectively, and the nodes in peer group (b) 202 are labeled B.1 to B.5, respectively. The nodes in peer group (c) 203 are labeled C.1 to C.5, respectively.

【0081】

The black (filled) node acts as a PGL for each peer group in each of Figures 10-13. For Figure 10, node A.3 wants to join the multicast group and makes a request to put the PGL into the discovery stage at a higher level indicated by the ellipse containing the logical PGLA, B and C. Send to PGL (Node A). As PGLA enters the highest level, it sends a request message to other members of its peer group to determine which has the requested multicast information.

【0082】

Suppose PGLA determines that there are no members of the multicast in peer groups B and C. This information is sent to node A.3 and the state of node A.3 becomes active. The multicast tree is now composed of a single node A.3. Overall, the state machine at logical node A causes a transition to the active state. The active state at each level is indicated by the box in FIG. Participating nodes at each level are indicated by shaded boxes.

【0083】

It is assumed that node C.4 wants to join the multicast group and sends a request to its PGL (node C) to enter the discovery phase. In response, Node C sends a request message to Logical Node B and Logical Node A. Node C may enter a retry state if there are simultaneous join requests from logical node B. In the absence of any other request, only logical node A is active and this information is sent by logical node C to node C.4. This action completes the discovery stage for node C.4.

【0084】

At the join stage, node C.4 encodes the path to peer group A as a DTL and sends a join request message to peer group A. This message enters peer group B through the boundary link (C.2--B.4). Here, node B.4 is the entry node and the DTL stack is not empty (participation step (ii)). Node B.4 identifies the path to peer group A through that peer group and appends the DTL to that path. Then, the message is sent to peer group A.

【0085】

Node B.4 also sends a copy of the join request message to PGL node B.1. This PGL node B.1 maintains the overall state machine for logical node B. Node B.1 updates Node B's overall state machine to a tentative state. Suppose this message enters peer group A through the link (B.5--A.5). The DTL stack is now empty (participation step (iii)).

【0086】

Upon receiving the message, node A.5 enters the discovery stage to determine the closest node to receive the message, node A.3. Then, the path to node A.3 is added to the DTL, and the participation request message is sent to node A.3. Node A.3 in the active state responds to the reception of the message by returning the participation acknowledgment message (step (i) of the participation stage). The participation acknowledgment message retraces the path followed by the participation request message.

【0087】

When the join acknowledgment message passes through the boundary ring (A.5--B.5), the state machine of logical node B is updated to the active state. Logical node C becomes active when a join acknowledgment message is sent over the link (B.4--C.2). The resulting multicast tree is shown by the dotted line in Figure 2. Node B.2 can participate in the multicast tree by joining node B.4, as shown in FIG.

【0088】

When the participating node A.3 leaves the multicast group, it sends the isolation message to node A.5, which propagates the isolation message to node B.5. Node A.5 also sends a copy of the isolation message to node A.1 so that the overall state machine of logical peer group A can be changed to the idle state. In addition, node B.5 sends a separation message to node B.4. However, since node B.4 has two active adjacent nodes, namely nodes B.1 and C.2, the latter message propagation stops at node B.4. The resulting tree is shown in Figure 14.

【0089】

Now suppose node B.2 leaves the multicast group as well. At this point, the isolation message propagates to node C.4. If the isolation message is sent over link B.4--C.2, a copy is also sent to node B.1 so that the overall state machine for the peer group can be changed to idle. The final tree consisting only of node C.4 is shown in Figure 15.

【0090】

[Effect of the invention]

As described above, according to the present invention, it is possible to provide a multicast protocol for finding an inexpensive and highly efficient multicast group, joining the multicast group, and leaving the multicast group.

[Simple explanation of drawings]

[Figure 1]

The figure which shows the structure of the communication network in which the principle of this invention is executed.

[Figure 2]

The figure which shows the routing tree which has a root in a specific one of the nodes of FIG.

[Fig. 3]

The state diagram which shows the operation of the node by the principle of this invention.

[Fig. 4]

The figure which shows each extended version of the operation state shown in FIG.

[Fig. 5]

The figure which shows each extended version of the operation state shown in FIG.

[Fig. 6]

The figure which shows each extended version of the operation state shown in FIG.

[Fig. 7]

The figure which shows each extended version of the operation state shown in FIG.

[Fig. 8]

The figure which shows each extended version of the operation state shown in FIG.

[Fig. 9]

The figure which shows each extended version of the operation state shown in FIG.

[Fig. 10]

The figure which shows the operation of the principle of this invention in an exemplary hierarchical network.

[Fig. 11]

The figure which shows the operation of the principle of this invention in an exemplary hierarchical network.

[Fig. 12]

The figure which shows the operation of the principle of this invention in an exemplary hierarchical network.

[Fig. 13]

The figure which shows the operation of the principle of this invention in an exemplary hierarchical network.

[Fig. 14]

The figure which shows the operation of the principle of this invention in an exemplary hierarchical network.

[Fig. 15]

The figure which shows the operation of the principle of this invention in an exemplary hierarchical network.

[Explanation of symbols]

100 networks 105,110,115,120,125,130,135 nodes 150 multimedia events 170 workstation 175 monitor