Topology Broadcast Based on Reverse-Path Forwarding TBRPF

1. Topology Broadcast Based on Reverse-Path Forwarding (TBRPF) Richard Ogier Fred Templin Bhargav Bellur Mark Lewis SRI International ogier@erg.sri.com March 18, 2002

2. Overview of TBRPF TBRPF has two modules: Routing (including topology discovery): Each node reports only a portion of its source tree, called its reportable subtree RT, to all neighbors: using periodic updates (e.g., every 5 or 6 s) uses differential updates (e.g., every 1 or 2 s), which allow important updates to propagate quickly in small messages to all nodes affected by the update (unlike OLSR). without using sequence numbers for updates (unlike OLSR). Neighbor discovery: Uses differential HELLOs, which include only the IDs of new neighbors and recently lost neighbors. Is completely modular, and performs only the discovery of new neighbors and the loss of old neighbors (unlike OLSR).

3. Changes from version 03 to version 05 Status of This Memo was changed to be fully compliant with RFC2026. Introduction of support for multiple interfaces, associated hosts, and network prefixes. Introduction of support for link metrics. Flooding mechanism. Clarification of IPv6 operation. Option to report full source tree to provide increased robustness if sufficient bandwidth is available.

4. Patent rights Our patent rights statement (included in the draft) protects SRI only if TBRPF does not become an IETF standard. (Why should SRI give up its rights in this case?) If TBRPF (or any part of it) becomes a standard, anyone can use it for any purpose for free.

5. TBRPF Neighbor Discovery Uses differential HELLOs, which report only neighbors whose state has recently changed (unlike OSPF). This reduces overhead and allows HELLOs to be sent more frequently. All neighbors are reported periodically in topology updates (not part of neighbor discovery) less frequently (PER_UPDATE_INTERVAL). OLSR v06 has introduced a new parameter (REFRESH_INTERVAL), which allows all neighbors to be reported less frequently than HELLO_INTERVAL. As a result, OLSR can now use differential HELLOs just like TBRPF. However, in TBRPF, (1-hop) neighbor discovery is modular, i.e., it performs only neighbor sensing, unlike OLSR.

6. Advantages of modular neighbor sensing If a network performs neighbor sensing in the link/mac layer, then TBRPF can be used without HELLOs, thus eliminating redundancy. TBRPF neighbor sensing can be used with other routing protocols, and conversely, other neighbor sensing protocols can be used with TBRPF. In OLSR, since HELLOs (which report neighbor interface addresses) are used to discover 2-hop neighbors, MPRs cover all 2-hop interfaces, which is redundant. In TBRPF, 2-hop neighbors are discovered using Topology Updates (not HELLOs), so parent selection is based only on Router IDs thus avoiding this redundancy.

7. Overview of TBRPF Routing Each node computes its source tree T using a variation of Dijkstra, which also updates the topology graph TG: A link (u,v) is in TG only if it is reported by the next hop p(u) on the shortest path to node u. (For fast rerouting, this condition can be relaxed for a few seconds when p(u) changes.) Each node i reports, in periodic and differential updates, its reportable subtree RT, which includes its links to neighbors, and includes the branch of T rooted at neighbor j iff node i determines that node i is the next hop of some neighbor to reach j. To accomplish this, each node computes the min-hop paths from each neighbor to each other neighbor. When there are multiple min-hop paths, tie is broken using node ID. As a result, each node reports only a relatively small part of its source tree.

8. Example of reportable subtrees

9. Drawbacks of using MPRs MPRs can result in delayed recovery from link failures, as the following example shows. In OLSR v05, node i was not allowed to reroute through node j’ until it knows j’ is an MPR of node k. This requires messages to travel around the loop from i to j to k to j’ and back to i. This will either cause a delay or add overhead (if additional messages are sent). OLSR v06 introduces a fix called “advanced fast re-routing mechanism”, which allows node i to use 2-hop neighbor information to immediately reroute through node j’. However, this fix does not help node v, who does not know about link (j’, k).

10. Drawbacks of using MPRs (cont.) In TBRPF, node i would report link (j’, k) at the same time that it reports the failure of link (j,k), allowing immediate rerouting for nodes i and v. MPRs also have disadvantages if link costs are used. For example, node k would have to know the link costs of link (i, j) and (i, j’) to select its MPR. This requires each node to report both outgoing and incoming link costs. In TBRPF, node j only needs to know the outgoing link costs of each neighbor, to select itself as parent.

11. Advantages of using differential topology updates OLSR allows differential HELLO messages, but does not allow differential topology update (TC) messages. In TBRPF, differential topology updates allow link failures to be reported immediately in small messages, thus allowing fast recovery with minimum overhead. If OLSR is used with link-layer failure notification and triggered (full) TC messages, in a large network with frequent link failures, a lot of TC messages will be generated. Simulations are needed to determine how this affects overhead and performance. Note that INRIA has not yet released simulation code that supports link-layer notification.

12. Advantages of sending additional topology information Each node must report its reportable subtree RT, but may report additional topology information. For example, each node may report (the reportable part of) a biconnected subgraph, thus providing 2 disjoint paths to each destination. Reporting only the minimum information improves scalability and allows operation in low-bandwidth networks. If sufficient bandwidth is available in a highly dynamic network, it makes sense to report additional topology information to improve robustness.

13. Using link metrics Nodes may optionally include link metrics in Topology Update messages, and compute shortest paths w.r.t these metrics. (The proposed size of a metric is 8 bits.) Possible metrics can be based on signal strength, stability, reliability, bandwidth, power, delay, HELLO counts, etc. The example below shows that the use of a link metric that represents reliability can improve the end-to-end reliability. The upper path has reliability .59 and would be selected by OLSR if hysteresis threshold is 0.9, while the lower path has reliability .89 and would be selected if -log R is used as link metric.

14. Multiple interfaces Each MANET node can have multiple interfaces, including both wireless and wired (e.g., Ethernet or point-to-point). Each node is identified by a 32-bit Router ID (RID), which can be the IP address of one of its interfaces (for IPv4). Each node advertises the IP addresses of its interfaces (which are associated with the RID) in INTERFACE ASSOCIATION messages. These are generated and propagated in periodic and differential updates, similar to TOPOLOGY UPDATE messages. The HELLO messages sent on a given interface describe only that interface (like OSPF). Each Topology Update message is sent on all interfaces.

15. Associated hosts and network prefixes Each node advertises the IP addresses of its associated hosts in HOST ASSOCIATION messages, which are also generated and propagated in periodic and differential updates. Each node advertises the network prefixes of associated networks (whether internal or external to the MANET) in NETWORK PREFIX ASSOCIATION messages. To minimize message overhead, a network prefix is represented by a 1-byte PrefixLength (instead of a 4-byte mask), followed by the minimum number of bytes required to specify the prefix. A default prefix (with zero length) can be advertised in order to support a stub network.

16. IPv6 operation IPv6 operation can be supported by using 16-byte addresses instead of 4-byte addresses in INTERFACE, HOST, and NETWORK-PREFIX ASSOCATION messages. HELLOs and TOPOLOGY UPDATE messages will continue to use 4-byte RIDs (similar to OSPF for IPv6). Since HELLOs may need to identify neighbor interfaces, an Interface ID (which can be 1 byte) may need to be included for each neighbor in HELLOs.

17. TBRPF Flooding Mechanism Used for best-effort flooding (or network-wide broadcast) of packets to all nodes of a connected ad-hoc network. Uses information computed by TBRPF to achieve greater efficiency than full (classical) flooding. A duplicate cache is maintained so that a node does not forward the same packet more than once. A non-duplicate packet is forwarded only if the source IP address of the packet belongs to the set RN of reportable nodes computed by TBRPF. If a packet is to be forwarded, it is transmitted on all interfaces, with the following exception: if the packet was received on an interface that is NOT an ad-hoc interface, then the packet need not be transmitted on that interface.

18. Simulation comparison AODV - for ns-2.1b8 Available from http://www.cs.ucsb.edu/~eroyer/aodv.html TBRPF - for ns-2.1b8 (compliant with version 04 draft) Available from http://www.erg.sri.com/projects/tbrpf/sourcecode.html Uses same ‘C’ module as our Linux implementation. OLSR - for ns-2.1b7 (compliant with version 03 draft) Available from http://hipercom.inria.fr/olsr/ Bug affecting packet size was fixed. In all protocols, link-layer failure notification was NOT used, and packets could not be retrieved from the link layer (interface queue). ARP was bypassed for both TBRPF and OLSR, since MAC addresses can be obtained from received routing packets.

19. Simulation Model ns-2 version 2.1b8 WaveLAN IEEE 802.11 MAC with rate 2Mb/s and range 250m 50 and 100 nodes Two area sizes: 670m x 670m and 1500m x 300m Mobility model: No mobility and random waypoint model with 0 pause time and maximum speed 20 m/s. 20 simultaneous CBR traffic streams: Source and destination of each stream are selected randomly Duration of each stream is 30 seconds Size of each data packet is 512 bytes Packet generation rate per stream is increased from 2 to 8 packets/s Each simulation was run for 500 simulated seconds.

20. Performance Measures The following measures were plotted for increasing packet generation rates: percent of data packets delivered average end-to-end delay total routing control traffic in kbytes, including IP/MAC headers (divide by 500 to get kbytes/sec). normalized path length (average ratio of actual hops to minimum hops)

21. Summary of simulation results In every scenario, TBRPF achieved a higher delivery percentage (up to 15% higher) than OLSR. TBRPF also achieved a higher delivery percentage (up to 15% higher) than AODV in all scenarios with no mobility, and in all scenarios using the square (670x670) area with the lower packet rates (2 and 4 packets/s). For the long rectangular (1500x300) area, AODV achieved a higher delivery percentage (up to 5% higher) than TBRPF. In every scenario, TBRPF generated less routing control traffic than the other protocols: up to 60% less than OLSR and up to 48% less than AODV. This is despite the fact that TBRPF sends HELLOs twice as frequently as OLSR. In every scenario, TBRPF used the shortest paths (except nearly shortest in some cases with the higher packet rates). In every scenario, AODV used paths that were 12-20% longer on average than TBRPF. TBRPF usually had the best or nearly best delay.

22. TBRPF Source Code Source code for Linux implementation and ns-2 simulations can be requested from the TBRPF web site: http://www.erg.sri.com/projects/tbrpf Uses same C code for both simulations and implementation. (INRIA has also promised to release OLSR code with this feature.) We encourage MANET researchers to request the code and conduct their own experiments. About 20 people have already obtained the code.

23. Conclusions TBRPF has several advantages over OLSR: Less overhead, better performance in simulations. Avoids disadvantages of MPRs as discussed Modular (1-hop) neighbor discovery Differential topology updates Parent computation based only on RIDs, avoiding the redundancy of selecting MPRs to cover all 2-hop interfaces. Each HELLO sent on only one interface (like OSPF), reducing overhead. Additional topology information may be reported for increased robustness. Link metrics may be used to select better routes. Note that TBRPF can employ hysteresis similar to OLSR.

24. Future work Conduct further simulations, when ns-2 code for OLSR is available that includes link-layer notification and other new features. Improve readability of TBRPF draft. Provide additional details for the option of providing additional topology information. Modify HELLO message to indicate neighbor interfaces.