The Proposed Multicast Routing Protocols
4.2 Overhead-Reduced On Demand Multicast Routing (ORODMR) ProtocolProtocol
The proposed Overhead-Reduced On Demand Multicast Routing (ORODMR) protocol reduces the control overhead needed to maintain robust connectivity among Mobile Nodes (MNs).
4.2.1 Routing Tables
Each MN operating the ORODMR protocol maintains two routing tables. The first of them is the Join Reply Table (JRTable). The fields of the JRTable are as follows:
• Multicast Group IP Address
• Forwarding Group Flag Refresh Time
• Replying Member
• Replying Time
New entries are added or updated in the JRTable following the receipt of route replies (i.e.
Join Tables) when the MN does not have a route entry for the indicated information in the
message.
The second routing table that each MN keeps is the Join Request Table (JQTable). Similar to the maintenance of JRTable, new entries are added or updated in the JQTable after a MN receives unrecorded route requests. The contents of the JQTable are as follows:
• Multicast Group IP Address
• Source IP Address
• Sequence Number
• Previous Hop
The source ip address means the source of the Join Request and the previous hop indicates the last MN that propagated Join Request. The JQTable provides the next hop (route) information during Join Table transmissions. The source ip address and the sequence number of the packet are utilized to detect duplicates.
Besides two routing tables, all multicast group receivers maintain a Member Table that stores the multicast group information. For each multicast group that the MN joins, the responding multicast group address and the time when the last Join Request is arrived from that multicast group source (or sources) are recorded. If no Join Request is received from the recorded multicast group before the refresh time expires, the related entry is deleted from the Member Table. The operation described here achieves the partial soft state property in both the ORODMR and the ODMRP algorithms. The Member Table contains the following fields:
• Multicast Group IP Address
• Membership Refresh Time
4.2.2 Multicast Route Discovery and Forwarding Group Membership Es-tablishment
The Multicast route discovery mechanism starts from the Join Request transmission by a source MN. The fields of the Join Request consist of the multicast group address and the
sequence number. As a MN receives a Join Request, it checks that whether the packet is duplicate or not by the source IP address and the sequence number field. If the Join Request is fresh, the fields in the JQTable are added or updated according to the carried information in the request packet. The previous hop field in the JQTable points out the reverse route information to the multicast source. The Join Requests are broadcasted out the whole network until they arrive in a multicast receiver.
The multicast receiver responds the Join Request with a join reply message (i.e. the Join Table). Join Tables are propagated by broadcasting like request packets. A node that receives the Join Table sent out by the multicast receiver exactly knows the IP address information of the receiver, because it can extract the multicast receiver IP address from the IP protocol header. It is found that most of the existing multicast routing protocols do not use this receiver material to do anything. The multicast receiver IP address is obvious in the receiver-sent Join Table message but as the packet is relayed by the non-receiver node the receiver IP address is lost. To record the IP address of the receiver that responds a Join Request and generates a Join Table, two extra fields (replying member and replying time) are devised. The fields of a Join Table are as follows:
• Multicast Group IP Address
• Source IP Address
• Next Hop
• Replying Member
• Replying Time
The reverse route recorded in the JQTable is utilized here. The next hop field indicates the next hop along the route to the multicast source and the value comes from the previous hop field in JQTable. The replying member means the multicast receiver which generates the current Join Table. The replying time records the sending time in second of the Join Table.
When a MN receives a first Join Table, it checks that if the next hop field matches its own IP address. If it is on the reverse route, it has to set itself as a forwarding group member.
The forwarding group flag is set by altering the forwarding group flag refresh time to the current time and adding corresponding multicast group IP address, replying member and replying time in the JRTable. After the forwarding group’s recognition, the node broadcasts its own Join Table. More explicitly, the next hop in the Join Table are changed according to previous hop in its JQTable. The replying member and the replying time are propagated out the one-hop range from the multicast receiver. For those MNs not on the reverse route, they just relay Join Table messages without making any packet content changes.
In the conventional ODMRP protocol, no matter how many Join Tables are received, the responding operation is the same. The second or the following Join Table receipt causes a node to check the forwarding group membership and to broadcast its or the ordinary Join Table. If the multicast group address already exists in the JRTable, only the forwarding group flag refresh time is updated. In the proposed ORODMR protocol, the two extra fields in Join Tables records the multicast receiver that have generated the Join Table and the knowledge of the receiver can be used for reducing unnecessary control packets.
Fig. 4.3 shows a Join Request and Join Table procedure for multicast route discovery. It is noted that node F2 will receive three Join Table packets and two of these packets are sent by node R2. Node F1 will receive six Join Table packets (two of them are from node R1 and two are from node R2). The two successive Join Table packets generated by node R2 (or node R1) carry the exactly same message. It is not necessary for node F2 and node F1 to respond the same reply packets.
In the ORODMR protocol, a MN that receives a Join Table checks the replying member and replying time in the JRTable in addition. If the replying member related to the multicast group already exists in the JRTable, the node takes the difference of the current time and the replying time into account. When the difference is larger than a predefined threshold value, it means that the receiving Join Table is fresh enough and the node will rebroadcast the original reply packet or broadcast its own reply packet depending on the next hop field in Join Table. On the other hand, if the difference is equal or smaller than the threshold value, the Join Table is simply used to update forwarding group flag refresh time in JRTable and
S
F1
F2
R1
R2
R
R
Join Request Join Table
Figure 4.3: Join Request and Join Table Procedure for Multicast Route Discovery any kind of relays are not preformed. For example, node F2 will only broadcast its own Join Table once for the Join Tables that get node R2 in the replying member field and so does node F1. But the design in the conventional ODMRP algorithm guides node F1 and node F2 to respond every received Join Table. The ORODMR protocol reduces certain control packet flooding effectively and it is significant for any control overhead decrement in the design of the multicast routing protocols.
The proposed ORODMR protocol keeps fine mesh structures and reduces control overhead in the same time. The revoked reply packet propagation does not influence the basic data packet delivery session because the membership update of forwarding group is the same with the conventional design.