Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)

1. Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) Richard Ogier ogier@erg.sri.com March 20, 2003

2. Changes for Version 07 • Added several clarifications to TBRPF routing operation, based on comments from Julie Wong at SRI, who developed a new implementation of TBRPF. • Simplified the TBRPF packet header by eliminating the “simple mode” option (which allowed the packet header to coincide with the first message header if no header extensions are required). • Modified the format for HELLO messages and added a new optional format for TOPOLOGY UPDATE messages, to allow each message to include a larger number of router IDs. • Added text to the Security Considerations section to reference two new works from the IETF Secure Neighbor Discovery (SEND) working group. (This section recommends using IP Authentication Header.) • Divided References into Normative and Informative sections. • Corrected some typos. • Removed hyphenation. • TBRPF is ready to be submitted for Experimental publication.

3. Clarifications to TBRPF routing operation • Added precise definition of a “leaf node” (of the source tree). • Added explanation for three lists of nodes in Topology Updates (e.g., the first NRL nodes are leaf nodes, thus avoiding the need to generate separate topology updates for leaf nodes). • Clarified that a relay priority of 0 indicates a non-relay node. • Made a few minor changes to the pseudocode (mostly typos) so that it agrees with our implementation. • Clarified that each node MUST send (on each interface) at least one HELLO message per HELLO_INTERVAL, but MAY send HELLO messages more frequently than this. • Clarified that TBRPF computes the equivalent of multipoint relays (MPRs): • Nodes select themselves as MPRs with respect to a subset of neighbors (in OLSR, an MPR is selected by neighbors of the MPR). • Neighbors in the reportable node set RN are equivalent to MPR selectors.

4. Changes to Hello and Topology Update messages • Change to HELLO message format: The field giving the number of 32-bit neighbor RIDs in message has been increased from 8 bits to 12 bits, to allow more neighbors to be reported in the same message. (Note, however, that HELLO messages are differential, so they usually include only a small subset of neighbors.) • New optional long format for TOPOLOGY UPDATE message: The three fields (n, NRL, NRNL) giving the number of RIDs in the three lists are each 16 bits in the long format, versus 8 bits in the normal format. • These changes remove the previous limitation that each node could have at most 255 neighbors.

5. TBRPF Experience • TBRPF has been implemented in Linux, ns-2, OPNET, and Qualnet. • Has been tested in networks of PDAs using Cisco and Lucent 802.11 cards. Experiments have been conducted in which nodes are carried by helicopters. • Simulations by SRI and other researchers show that TBRPF compares favorably with OLSR and AODV for a range of MANET scenarios. • Recent simulation results presented at WCNC 2003 this week (Tao Lin et al.) comparing OLSR and TBRPF are consistent with our results. (In most cases TBRPF generates less control traffic.)

6. Suggestions for designing a standards track proactive routing • Performance, efficiency, scalability should be considered. If two alternative techniques exist that are equally good except for performance, then the one with better performance should be used. • Periodic topology updates should not be generated (or should be much less frequent) if topology changes do not occur. • We were planning to do this in TBRPF, but were under pressure to keep it “simple”. • Some metric information should be included in topology updates, at least a metric for each interface at each node (and maybe a metric for each link). • Neighbor discovery should be modular. It should perform only neighbor discovery, e.g., should be separate from MPR selection.