Topology Dissemination Based on ReversePath Forwarding TBRPF

1
Topology Dissemination Based on Reverse-Path
Forwarding (TBRPF)

• Richard Ogier
• ogier_at_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.