How plain flooding works
Flooding is the simplest way to get a message across a mesh network. The sender broadcasts the message to every neighbour in range. Each node that receives it for the first time broadcasts it again, and so on, until the message has spread through every part of the network the sender is connected to.
RFC 6621, which defines Simplified Multicast Forwarding for wireless mesh and mobile ad hoc networks, calls this Classic Flooding. In that mode each router transmits a packet once. RFC 7731, the Multicast Protocol for Low-Power and Lossy Networks (MPL), offers the same option, describing it as having each device that receives a message rebroadcast it.
Flooding has real strengths. No node needs a map of the network or a route to the destination, so there is nothing to keep up to date when devices move. RFC 7731 describes MPL as avoiding the need to construct or maintain any multicast forwarding topology, disseminating messages to every forwarder in its domain instead. How a message crosses a mesh network compares flooding with routing at a higher level.
Why flooding needs limits
The cost of flooding is that every node transmits every message, and on a shared radio channel that adds up fast.
- Collisions. RFC 5148 explains that when nodes forward the messages they receive, nearby nodes commonly receive and forward the same message, and if they forward immediately their transmissions can interfere with each other. A collision can stop a receiver from getting some or all of the copies.
- Broadcast storms. The term comes from the research literature on ad hoc networks: RFC 6621 cites the 1999 paper “The Broadcast Storm Problem in a Mobile Ad Hoc Network”. RFC 6206 describes the effect in its own setting as many nodes responding at once and in a synchronised fashion.
- Repeat transmissions. A node with no record of what it has already sent cannot tell a new message from a copy of one it forwarded a moment ago, so it would forward the copy again.
Duplicate caches and hop limits
Two mechanisms make flooding usable at all.
Duplicate detection. Each node remembers the messages it has recently forwarded and drops a copy it has seen before. RFC 6621 calls this duplicate packet detection and describes two ways to recognise a duplicate: by an identifier carried in the packet, or by a hash of the packet kept in the node’s cache. Its forwarding rules say this detection is critical to stopping the same relay from retransmitting a packet more than once. Message deduplication covers the same idea at the application layer.
A hop limit. The sender sets a time to live (TTL) that each relay lowers, and a message is not forwarded once the limit is reached.
Bluetooth Mesh shows both in one standard. Its managed flooding has relays retransmit what they receive, but each relay checks a message cache first and discards a copy it has already handled, and the TTL field limits how many times a message can be relayed. In the SIG’s primer, a TTL of 3 allows at most two relays.
Sending fewer copies
Caches and TTLs stop the worst problems, but plain flooding still has every node transmit. Several techniques cut that down.
- Jitter. RFC 5148 says a node forwarding a message should delay it by a random duration up to a set maximum, so that neighbours forwarding the same message do not all transmit at the same moment.
- Selected relays. In OLSRv2 (RFC 7181), each router picks a subset of its neighbours, its flooding multipoint relays (MPRs), that between them reach all of its two-hop neighbours. A router forwards flooded control traffic only when it first receives it from a router that selected it as a flooding MPR. RFC 7181 calls this MPR flooding and describes it as reducing the number of transmissions required. RFC 6621 describes the broader idea as a reduced relay set, often a connected dominating set calculated by a distributed algorithm.
- Counter-based suppression. In the Trickle algorithm (RFC 6206), a node counts how many consistent transmissions it hears from neighbours during an interval and transmits only if that count is below a redundancy constant, k. MPL can run its data forwarding through Trickle, which lets it trade dissemination speed for fewer transmissions.
- Relaying only where needed. In Bluetooth Mesh, only nodes with the relay feature enabled retransmit, and directed forwarding goes further: a relay forwards only if it lies on a known path toward the destination.
When flooding is the right choice
RFC 6621 frames efficient flooding as an engineering trade-off, to be used where it is acceptable. It fits messages meant for every node, and networks whose links vary widely over space and time, which is the setting RFC 7731 designs MPL for. It costs most where traffic is heavy and nodes are close together, because that is where neighbours forwarding the same message collide.
Many systems mix flooding and routing. Mesh routing protocols often flood their control messages so that every router learns the topology, then send data along chosen routes. RFC 6621 describes Simplified Multicast Forwarding as extending that efficient flooding from routing control traffic to data, which is why the relay reduction techniques above come from routing protocols.