Broadcast in Hypercube
Download as PPTX, PDF1 like1,863 views
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.
Broadcast in Hypercube
- 1. Broadcasting In Hypercube Networks Sujith Nair 12316EN005
- 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