Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)

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

• ltdraft-ietf-manet-tbrpf-06.txtgt
• Richard Ogier
• ogier_at_erg.sri.com
• September 21, 2002

2
Major Changes for Version 06

• Section describing operation of TBRPF routing has
  been rewritten to improve readability.
• HELLO messages have been modified to include
  relay priority.
• New configurable parameter IMPLICIT_DELETION
  indicates whether link deletions are implied by
  link additions in topology updates.
• Name has been changed by replacing Broadcast
  with Dissemination. Acronym is still TBRPF.
• New IPR statement gives away all rights to all
  portions of TBRPF included in a jointly developed
  protocol (posted on the IETF page of IPR
  notices).

3
Improved Description of TBRPF Routing

• Organized with a separate subsection for each
  procedure (e.g., Processing Topology Updates).
• Pseudocode format changed Each procedure or
  algorithm is described using numbered steps in
  English, with less math notation.
• Clarified that TBRPF computes the equivalent of
  multipoint relays (MPRs).
• MPRs are used for topology dissemination and
  flooding of multiple interface and network prefix
  information.
• 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 the MPR selectors of OLSR.
• This equivalence makes it possible to merge TBRPF
  with OLSR. For example, MPRs can be selected as
  in OLSR while topology discovery is done as in
  TBRPF.

4
Relay Priority

• Each node advertises its relay priority in each
  HELLO.
• A node with higher relay priority is more likely
  to
• Include more neighbors in RN
• Report a larger part of its source tree
• Be selected as a next hop relay.
• A node with relay priority 0 is equivalent to a
  non-relay node, which was already supported in
  previous versions of the draft.
• Relay priority is similar to OLSRs relay
  willingness (both teams independently decided to
  add this feature).

5
Implicit Deletion Option

• If IMPLICIT_DELETION 1, then the addition of a
  link (u,v) in a Topology Update implies the
  deletion of any link (w,v) with the same head
  node. (Valid if the node reports only links in
  its source tree.)
• Indicated by the implicit deletion bit in
  Topology Updates.
• If a node uses the option of reporting redundant
  topology information (so that two links with the
  same head node can be reported), then
  IMPLICIT_DELETION must be 0, since in this case
  link deletion cannot be implied by link addition.

6
New IPR statement for TBRPF

• Grants a royalty-free license to everyone for any
  parts of TBRPF that either
• become part of an IETF standard, or
• are included in a jointly developed protocol,
  whether or not the protocol becomes a standard.
• In addition, grants a royalty-free license for
  non-commercial (research) use of TBRPF while it
  is being evaluated by the IETF or is described in
  an Experimental RFC.
• No need to apply for a license automatic.
• Posted on the IETF page of IPR notices.
• May be modified based on feedback from the WG.

7
Implementation Status

• 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.
• Implementation is compliant with the latest
  draft, but does not include optional features.

8
Rough plan for Experimental RFC

• Review packet format, and possibly make minor
  changes to simplify it (e.g., exclude simple
  mode and always use 8 bits for message type).
• Current version supports only 255 neighbors (8
  bits). Possibly include an option bit that
  provides a 16-bit field for the number of
  neighbors.
• HELLOs contain only neighbor RIDs (like OSPF).
  Possibly change this to neighbor interface IDs to
  handle special situations that can occur in
  wireless networks.
• Possibly support multiple instances of TBRPF.
• Possibly support authentication, either using a
  secret key and message digest as in OSPF, or
  using the IP Authentication Header RFC 2402
  proposed for IPSec. (This issue is common to all
  MANET protocols.)
• Additional details may be needed to completely
  specify IPv6 operation.
• Review draft for proper use of MUST, SHOULD, MAY,
  etc.
• Other recommended changes, including style
  changes.