On-Demand Multicast Routing Protocol (ODMRP) is:

* A mesh-based, rather than a conventional tree-based, multicast scheme.
* Uses a forwarding group concept (only a subset of nodes forwards the multicast packets via scoped flooding): a set of nodes responsible for forwarding multicast data on shortest paths between any member pairs, to build a forwarding mesh for each multicast group.
* Flooding redundancy among forwarding group helps overcome node displacements and channel fading. Hence, unlike trees, frequent reconfigurations are not required.
* Applies on-demand procedures to dynamically build routes and maintain multicast group membership.
* Well suited for ad hoc wireless networks with mobile hosts where bandwidth is limited, topology changes frequently and power is constrained.

Tree-based Scheme is BAD
Multicast tree structures are fragile and must be readjusted continuously as connectivity changes. Furthermore, typical multicast trees usually require a global routing substructure such as link state or distance vector. The frequent exchange of routing vectors or link state tables, triggered by continuous topology changes, yields excessive channel and processing overhead.

Multicast Route and Membership Maintenance

* Group membership and multicast routes are established and updated by the source on demand.

* While a multicast source has packets to send:
o Multicast source periodically broadcasts a JOIN REQUEST (a member advertising packet) to the entire network. This periodic transmission refreshes the membership information and updates the route.

* When a node receives a non-duplicate JOIN REQUEST, it
o Stores the upstream node ID (i.e., backward learning), and
o Rebroadcasts the packet.

* When the JOIN REQUEST packet reaches a multicast receiver, the receiver
o Creates the source entry in its Member Table, or
o Updates the source entry in its Member Table.

While valid entries exist in the Member Table, JOIN TABLES are broadcasted periodically to the neighbors.

When a node receives a JOIN TABLE:

* It checks if the next node ID of one of the entries matches its own ID.
* If it does, the node realizes that it is on the path to the source and thus is part of the forwarding group.
* It then sets the FG Flag and broadcasts its own JOIN TABLE built upon matched entries.
* The JOIN TABLE is thus propagated by each forwarding group member until it reaches the multicast source via the shortest path. This process constructs (or updates) the routes from sources to receivers and builds a mesh of nodes, the forwarding group.

A multicast receiver can also be a forwarding group node if it is on the path between a multicast source and another receiver.

Example
Nodes S1 and S2 are multicast sources.
Nodes R1, R2, and R3 are multicast receivers.

Nodes R2 and R3 send their JOIN TABLES to both S1 and S2 via I2.
Node R1 sends its JOIN TABLE to S1 via I1 and to S2 via I2.

1. When receivers send their JOIN TABLES to next hop nodes, an intermediate node
2. I1 sets the FG Flag and builds its own JOIN TABLE since there is a next node ID entry in the JOIN TABLE received from R1 that matches its ID.
Note that the JOIN TABLE built by I1 has an entry for sender S1 but not for S2 because the next node ID for S2 in the received JOIN TABLE is not I1.
3. In the meantime, node I2 sets the FG Flag, constructs its own JOIN TABLE and sends it to its neighbors.
4. Note that even though I2 receives three JOIN TABLES from the receivers, it broadcasts the JOIN TABLE only once because the second and third table arrivals carry no new source information.
*Channel overhead is thus reduced dramatically in cases where numerous multicast receivers share the same links to the source.

Data Forwarding
After the group establishment and route construction process, a multicast source can transmit packets to receivers via selected routes and forwarding groups.

Periodic control packets are sent only when outgoing data packets are still present. When receiving a multicast data packet, a node forwards it only if

* It is not a duplicate and,
* The setting of the FG Flag for the multicast group has not expired. This procedure minimizes traffic overhead and prevents sending packets through stale routes.

Soft State
In ODMRP, no explicit control packets need to be sent to join or leave the group.

If a multicast source wants to leave the group, it simply stops sending JOIN REQUEST packets since it does not have any multicast data to send to the group.

If a receiver no longer wants to receive from a particular multicast group,

* It removes the corresponding entries from its Member Table and,
* It does not transmit the JOIN TABLE for that group.

Nodes in the forwarding group are demoted to non-forwarding nodes if not refreshed (no JOIN TABLES received) before they timeout.

Data Structures
Network hosts running ODMRP are required to maintain the following data structures.

* Member Table:
o Each multicast receiver stores the source information in the Member Table.
o For each multicast group the node is participating in, the source ID and the time when the last JOIN REQUEST is received from the source is recorded.
o If no JOIN REQUEST is received from a source within the refresh period, that entry is removed from the Member Table.

* Routing Table:
o A Routing Table is created on demand and is maintained by each node.
o An entry is inserted or updated when a non-duplicate JOIN REQUEST is received.
o The node stores the destination (i.e., the source of the JOIN REQUEST) and the next hop to the destination (i.e., the last node that propagated the JOIN REQUEST).
o The Routing Table provides the next hop information when transmitting Join Tables.

* Forwarding Group Table:
o When a node is a forwarding group node of the multicast group, it maintains the group information in the Forwarding Group Table.
o The multicast group ID and the time when the node was last refreshed is recorded.

* Message Cache:
o The Message Cache is maintained by each node to detect duplicates.
o When a node receives a new JOIN REQUEST or data, it stores the source ID and the sequence number of the packet.
o *Note that entries in the Message Cache need not be maintained permanently.
o *Schemes such as LRU (Least Recently Used) or FIFO (First In First Out) can be employed to expire and remove old entries and prevent the size of the Message Cache to be extensive.

Unicast Capability
One of the major strengths of ODMRP is its unicast routing capability. Not only ODMRP can work with any unicast routing protocol, it can function as both multicast and unicast. Thus, ODMRP can run without any underlying unicast protocol.

Advantages:

* Low channel and storage overhead
* Usage of up-to-date and shortest routes
* Robustness to host mobility
* Maintenance and exploitation of multiple redundant paths
* Scalability to a large number of nodes