1 / 8

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF). <draft-ietf-manet-tbrpf-06.txt> Richard Ogier ogier@erg.sri.com September 21, 2002. Major Changes for Version 06. Section describing operation of TBRPF routing has been rewritten to improve readability.

oriana
Télécharger la présentation

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) <draft-ietf-manet-tbrpf-06.txt> Richard Ogier ogier@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 OLSR’s 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.

More Related