This document discusses different approaches for broadcasting in hypercube networks. It describes the flooding approach which provides reliable delivery but uses excessive bandwidth. It also describes single-spanning tree broadcasting and reverse path forwarding. Single-spanning tree broadcasting restricts traffic to a single tree to avoid loops but can cause congestion. Reverse path forwarding only forwards packets along the shortest path to the source to avoid duplicates. Both approaches are suitable for hypercubes as they have inherent symmetry allowing for edge-disjoint trees and shortest paths calculated using XOR operations.

1. Broadcasting In
Hypercube Networks
Sujith Nair
12316EN005

2. The Flooding Approach

3. The Flooding Approach
Pros:
-reliable message delivery
Cons:
-multiple duplicate packets are received at nodes.
-high network bandwidth consumption

4. Single-Spanning-Tree Broadcast
LAN Bridges typically restrict all packet traffic to
a single spanning tree.
This is done either by forbidding loops in the
physical topology or by running a distributed
algorithm among the bridges to compute a
spanning tree.

5. Single-Spanning-Tree Broadcast
When a bridge receives a broadcast packet, it
simply forwards it onto every incident branch of
the tree except the one on which it arrived.
Because the tree spans all segments and has no
loops, the packet is delivered exactly once (in the
absence of errors) to every segment.

6. Single-Spanning-Tree Broadcast
Cons:
- Broadcast traffic is concentrated on certain links,
which form a part of the spanning tree.
-This results in network congestion.

7. Single-Spanning-Tree Broadcast in a
Hypercube
Computing a spanning-tree in a hypercube is
computationally simple.
Moreover, edge-disjoint spanning trees exist in a
hypercube, because of its inherent symmetry.
Hence, network congestion can be avoided by using
different edge-disjoint spanning trees at different
times.

8. Reverse Path Forwarding
A node forwards a broadcast packet originating at
source S if and only if it arrives via the shortest
path from the node back to S (i.e., the “reverse
path”).
The node forwards the packet out on all incident
links except the one on which the packet arrived.

9. Reverse Path Forwarding
To implement the basic reverse path forwarding
algorithm, a router must be able to identify the
shortest path from the router back to any host.
In internetworks that use distance-vector routing
for unicast traffic, that information is precisely
what is stored in the routing tables in every
router.

10. Reverse Path Forwarding Algorithm
1. run single-source shortest path.
i) for each node, the shortest path to every other
node is computed.
ii)using the shortest path, an outgoing link is
associated with each node.
iii)a routing table is made; for each node, an
outgoing link is assigned.

11. Reverse Path Forwarding Algorithm
1. Consider a broadcast packet received at a node n,
through link l. Let its source be s.
i) If in the routing table, the entry corresponding
to s is l, then broadcast to all neighbors
ii) else discard.

12. Reverse Path Forwarding in Hypercube
In hypercube networks, the shortest unicast path to
any host node can be found using the XOR
operation.
Hence, distance-vector tables are not needed for
performing RPF in hypercube networks.

14. 0011 xor 0100 = 0111
assume the unicast routing algorithm routes to a
node which differs from the current node in the LSB
bit.
Hence, when unicasting from 0011 to 0100, 0011
sends the packet to 0010.
Thus, when a broadcast packet from 0100 is
received at 0011, it is only further broadcasted if it is
received via 0010.

15. The above operation can also be performed by
maintaining routing tables.
The trade-off between maintaining a routing table
at each node and performing an xor operation for
every broadcast , depends on the table look-up
latency and memory requirement at each node.

16. References
Deering, Stephen E. "Multicast routing in internetworks
and extended LANs." ACM SIGCOMM Computer
Communication Review 25.1 (1995): 88-101.

17. Thank You