SRMP Maintenance Procedures

Due to host mobility and/or interference, an established route may be broken. Route maintenance should report routing problems and recover them. To achieve this, SRMP introduces several mechanisms including node-neighbors information, mesh refreshment, multicast mesh reconfiguration and member node pruning. We address several mechanisms in which the multicast mesh is refreshed, link breaks are detected and repaired, continuous node-neighbor information is provided, and pruning is supported allowing any node to leave the group. Our goal is to keep the lifetime of a route as long as possible. We make use of the MAC layer beacons and introduce two new messages: the Multicast-RERR Message, and the Leave_Group Message.

5.4.1 Neighbor Existence Mechanism

SRMP uses the MAC layer beacons to provide each node with information about its neighbors’ existence. When a node receives a neighbor’s beacon, it updates or creates the corresponding entry of this neighbor in its Neighbor_Stability_Table. Entry update takes place through incrementing the associativity ticks field, and setting the signal strength field according to the level of strength the beacon is received. In addition, the node performs continuous prediction for link’s availability towards the neighbor and updates its link availability field. If no beacons are received by a node from a certain neighbor up to a certain period of time, the node indicates neighbor's movement and updates its stability table fields towards this neighbor through setting the associativity ticks field to zero and signal strength and link availability fields to null until it receives new information from this neighbor.

5.4.2 Mesh Refreshment Mechanism

SRMP follows a simple mechanism in refreshing its mesh, making use of data packets propagation and requiring no extra control overhead. During data packets’ propagation, route refreshment for different paths on the mesh takes place. Each time the source transmits a data packet it updates in its Multicast_Routing_Cache the timer of each route used. Typically, an FG node forwarding this packet scans the packet header, and refreshes in its Multicast_Routing_Cache the corresponding route entry timer. A multicast receiver also scans the header of each received data packet, refreshing its corresponding Receiver_Multicast_Routing_Table entry timer to the source. Furthermore, multicast receivers re-initiate the reply phase at each predefined period of time as previously mentioned in Section 5.3.2, where each intermediate node as well as the source update their cache entries during this phase. Through this mechanism, we allow the existence of the most recent and correct routes in the mesh. We guarantee that no stale routes are

SRMP Maintenance Procedures 119 stored. Periodically, each node checks its timers and purges out expired multicast group entries.

5.4.3 Link Repair Mechanism

Mesh reconfigurations are required to adapt the multicast mesh to the movement of any mesh member node. SRMP reacts to nodes’ mobility on-demand, such that it detects link failure, through the use of MAC layer support, during data transmission on the mesh. We address two mechanisms: (i) how to maintain routes when a link fails between two FG nodes, and (ii) how to maintain routes when a link fails between a multicast receiver and an FG node. We assume that the mesh reconfigurations are not needed if the stability characteristics together with high battery life paths are valid throughout the lifetime of the multicast communications.

When link failure occurs between two FG nodes, SRMP follows the same concept proposed in the DSR unicast protocol. In this case, the node detecting the failure reports it to the original source of the data packets. First, it generates a Multicast-RERR packet indicating the broken link. Then, it deletes from its cache any route containing the broken link. Nodes on the way to the source, receiving this packet, clean in their turn their Multicast_Routing_Caches from all routes containing the broken link. The format of the Multicast-RERR packet is shown in Figure 5.9, where the Type field indicates whether he node is an FG node or a multicast receiver.

Figure 5.9 Format of the Multicast-RERR packet

Otherwise, if a link failure takes place between an FG node and a multicast receiver, the FG node detecting the failure simply deletes the receiver membership from its Neighbor_Stability_Table. Then, a Multicast-RERR packet is sent to all member neighbors reporting the failure, where the Route to sender field in this packet is set to the member neighbor address. Each member neighbor, receiving this packet, cleans in its turn its Multicast_Routing_Cache from routes containing this broken link. The process is repeated until all member nodes in the mesh are visited. During the protocol’s operation, each FG node continuously checks its Neighbor_Stability_Table and deletes from its Multicast_Routing_Cache any routes to multicast groups possessing no more members.

Figure 5.10 shows two examples for link failures, which address respectively the two above mechanisms. Figure 5.10 (a), demonstrates an example of the link failure between two FG nodes. During data transmission on the path [S-L-M-X-01], the link M-X is broken between the two FG nodes M and X. Firstly, M detects the failure and sends a Multicast-RERR packet to the original source of the data packet, storing the link M-X in the broken link field, while it stores the reversed route accumulated in the data packet

Type Group ID Broken Link Route to sender

header [L – S] in the route to sender field. Secondly, M deletes from its Multicast_Routing_Cache all the routes containing the broken link. When node L receives the Multicast-RERR packet, it performs the same operation for deleting its Multicast_Routing_Cache entries containing the broken link then it forwards the packet to the next node in the Route to sender field, which is the source S. Then, S deletes in its turn all routes containing the broken link from its Multicast_Routing_Cache.

Figure 5.10 Link Failure Examples: (a) Link breakage between two FG Nodes, (b) Breakage Between an FG Node and a Multicast Receive

Breakage Multicast-RERR xxx Deleted Entry

SRMP Maintenance Procedures 121 Figure 5.10 (b), demonstrates an example of the link failure between an FG node and a multicast receiver. During data transmission on the path [S-L-M-X-01], the link X-R2 is broken between the FG node X and the multicast receiver R2. Firstly, node X deletes the receiver R2 from its Neighbor_Stability_Table. If no entries exist for the multicast group 01 in node’s X Neighbor_Stability_Table, X deletes from its Multicast_Routing_Cache all routes to this multicast group and sends a Multicast-RERR packet to M and N. The broken link field in this packet contains X-01 and the route to sender field contains the address of N and M respectively. When N and M receives this packet, they delete from their Multicast_Routing_Caches all entries containing [X-01] then they repeat the same process via sending Multicast-RERR packets to their neighbors until reaching the source.

5.4.4 Pruning Scheme

SRMP employs a pruning mechanism allowing a member node to leave the multicast session. We distinguish two cases: (i) when an FG node wants to prune itself, and (ii) when a multicast receiver wants to prune itself.

We assume that a multicast source wishing to leave a multicast group simply stops transmitting data to the group, and deletes from its Multicast_Routing_Cache all entries for this group. This results in an expiration of all routes connecting the source to the multicast receivers, due to non-refreshment of these routes. Similarly, the Receiver_Multicast_Routing_Table entries towards this source are expired and deleted.

On the other hand, a multicast receiver wishing to leave a multicast group sends a Leave_Group message to all its member neighbors, and deletes from its Receiver_Multicast_Routing_Table all entries for this group. A member neighbor, receiving this message, cancels in its turn the receiver membership from its Neighbor_Stability_Table. If the Neighbor_Stability_Table of the member neighbor contains no more members for the multicast group, all routes towards this group are deleted from the member neighbor Multicast_Routing_Cache. Then, a Multicast-RERR message is in turn sent to all its member neighbors following the previous link failure procedure.

Furthermore, an FG node wishing to leave a multicast group sends a Leave_Group message to its neighbors, deleting from its Multicast_Routing_Cache all entries for the multicast group. Figure 5.11 gives the format of this message. The multicast group ID is stored in the Multicast group ID field, the Neighbor ID field stores the ID of the member neighbor to which the message is sent. Each neighbor receiving this message cancels the FG node membership from its Neighbor_Stability_Table, deletes routes containing this node from its Multicast_Routing_Cache, and then sends a Multicast-RERR message to its member neighbors with the Broken link field storing the FG node, and the previous procedure of link failure are followed.

Figure 5.11 Format of the Leave Group

Figure 5.12 demonstrates an example of nodes’ pruning in SRMP, showing respectively a multicast receiver pruning and an FG node pruning.

Figure 5.12A Pruning Example: (a) Multicast Receiver Pruning, (b) An FG Node Pruning In Figure 5.12 (a), the multicast receiver R1 wants to leave the multicast group. It deletes from its Receiver_Multicast_Routing_Table all entries for this group. Then, it

Multicast group ID Neighbor ID

Signal Strength Link Availability

R1 Mem --- --- --- Neighbor Type Associativity Ticks Signal Strength Link Availability

R1 Mem --- --- ---

Neighbor Type Associativity Ticks Signal Strength Link Availability

S Mem --- --- ---

Features 123 sends a Leave-Group message to its member neighbor X, where X sets R1 as non-member node in its Neighbor_Stability_Table.

In Figure 5.12 (b), the FG node M wants to leave the group. First, M deletes its Multicast_Routing_Cache entries for this group. And it sends a Leave-Group message to its member neighbors L and X, where they set node M as non-member in their Neighbor_Stability_Tables. Then, node L deletes from its Multicast_Routing_Cache all entries containing node M. Indeed, node X will do nothing, as it does not have route entries in its Multicast_Routing_Cache containing node M. Then, both nodes send Multicast-RERR packet to their member neighbors (S and N respectively) following the previous procedure of link failure.