SRI International1

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)

<draft-ietf-manet-tbrpf-06.txt>

Richard Ogier

ogier@erg.sri.com

September 21, 2002

SRI International2

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).

SRI International3

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.

SRI International4

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 OLSR’s relay willingness (both teams independently decided to add this feature).

SRI International5

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.

SRI International6

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.

SRI International7

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.

SRI International8

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.