■ Case 1
In this case, a BNR node (for example X) stopped receiving BNR_UP message for a
period of time exceeding a predefined threshold from its downstream node. Hence, X will
perform the following steps:-
- Updates its MFT table by removing entry for the downstream BNR that stop
sending BNR_UP messages.
- X checks its state after updating its MFT, if it is no longer a BNR it performs a
leave message regarding the state change. This message is similar to what
discussed in the third case Section 4.4.3.
- If X stays a BNR after updating its MFT, then it, as a result, will stop sending
data packets and other periodical messages towards the disconnected BNR.
■ Case 2
This case happens if a BNR (for example X) does not receive a BNR_Down message
from its previous (upstream) BNR. This means that node X and all nodes connected to it
are now disconnected from the tree and a sub-tree is created, which is rooted by X. The
following steps are followed:-
• Node X stops sending the periodical BNR_Down to its downstream nodes.
• Node X sends immediately a Link_failure message to its downstream nodes
informing them of this link failure and to prevent these nodes from starting a
repair procedure because they will not receive a BNR_Down message.
• Node X starts searching for new route to the multicast tree. It broadcasts a route
request message to find an upstream node to re-establish the connection to the
tree. This message is propagated and controlled by the underlying unicast
protocol (e.g., AODV), by controlling the direction of this message to be
upstream and to find a node with a route to the source or any upstream group
member. After a period of time node X will receive one or more reply messages
from its neighbours carrying a route to upstream member nodes, it selects one
according to some parameters like the number of hops and any other parameters
required for certain applications. Node X will wait for a period of time,
112