Skip to main content

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
RFC 3684

Revision differences

Document history

Date Rev. By Action
2004-02-20
11 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2004-02-20
11 (System) RFC published
2003-11-04
11 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2003-11-03
11 Amy Vezza IESG state changed to Approved-announcement sent
2003-11-03
11 Amy Vezza IESG has approved the document
2003-11-03
11 (System) Last call text was added
2003-11-03
11 (System) Ballot approval text was added
2003-10-31
11 Amy Vezza Removed from agenda for telechat - 2003-10-30 by Amy Vezza
2003-10-30
11 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza
2003-10-24
11 Alex Zinin State Changes to IESG Evaluation from IESG Evaluation::Revised ID Needed by Alex Zinin
2003-10-24
11 Alex Zinin Placed on agenda for telechat - 2003-10-30 by Alex Zinin
2003-10-15
11 (System) New version available: draft-ietf-manet-tbrpf-11.txt
2003-10-10
11 Alex Zinin State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Alex Zinin
2003-10-10
11 Alex Zinin
Asked the authors to address some more IESG comments:

1. Some statement on what's known about the correctness of
  the protocol, its proof, etc. …
Asked the authors to address some more IESG comments:

1. Some statement on what's known about the correctness of
  the protocol, its proof, etc. Pointers would be good.
  No need to include the proof in the doc, just a brief
  statement.

2. Question:

>    The number of nodes that can be supported depends on several factors,
>    including the data rate, the rate of topology changes, and the
>    network density (average number of neighbors). Simulations have shown
>    that TBRPF can support 250 nodes in mobile networks using IEEE 802.11
>    with a data rate of 2 Mbps.

is 2Mbps the user data rate? do we know how much the protocol
itself consumed?

3. Router ID

>      Each node is identified by a unique 32-bit router ID (RID),
>      which for IPv4 is equal to the IP address of one of its
>      interfaces. The term "node u" denotes the node whose RID is
>      equal to u.

> so, in v4 is is mandatory that it is an ip address of an
> interface, but in v6 it is arbitrary?  why perpetuate the bgp
> routerid confusion?

> and, given that the definition of 'interface' precludes virtual
> interfaces, commonly known today as 'loopbacks', in v4 one can not
> use common ops practice, and in v6 things become muddy.

4. Link notation:

>    In the following overview of the operation of TND, we assume that
>    interface I belongs to node i, and interface J belongs to node j.
>    When a node i changes the status of a link (I,J), it includes the
>    neighbor interface address J in the appropriate list (NEIGHBOR
>    REQUEST/REPLY/LOST) in at most NBR_HOLD_COUNT (typically 3)
>    consecutive HELLOs sent on interface I. This ensures that node j will
>    either receive one of these HELLOs on interface J, or will miss
>    NBR_HOLD_COUNT HELLOs and thus declare the link (J,I) to be LOST.
 
> yes, the notiation defined for bi-dir links seems to be unordered,
> but would it not be clearer if that last (J,I) was (I,J)?
2003-09-04
11 Amy Vezza Removed from agenda for telechat - 2003-09-04 by Amy Vezza
2003-09-04
11 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2003-08-25
11 Alex Zinin Placed on agenda for telechat - 2003-09-04 by Alex Zinin
2003-08-21
11 Amy Vezza Removed from agenda for telechat - 2003-07-10 by Amy Vezza
2003-08-14
11 Alex Zinin Placed on agenda for telechat - 2003-07-10 by Alex Zinin
2003-08-14
11 Alex Zinin State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Alex Zinin
2003-08-14
11 Alex Zinin
-10 addresses the IESG comments (below). putting on the agenda for the next telechat.

  - the document appears to just grab the address from …
-10 addresses the IESG comments (below). putting on the agenda for the next telechat.

  - the document appears to just grab the address from the
    unallocated space, rather than request it.

  - the document does not mention such address allocation
    in the IANA section.
2003-07-29
10 (System) New version available: draft-ietf-manet-tbrpf-10.txt
2003-07-10
11 Amy Vezza State Changes to IESG Evaluation  :: AD Followup from IESG Evaluation by Vezza, Amy
2003-07-03
11 Alex Zinin -09 ready to go. putting on the agenda.
2003-07-03
11 Alex Zinin State Changes to IESG Evaluation from AD Evaluation  :: Revised ID Needed by Zinin, Alex
2003-06-26
09 (System) New version available: draft-ietf-manet-tbrpf-09.txt
2003-06-06
11 Alex Zinin
Comments from the rtg-dir provided to the authors on May 7, 2003. Waiting for the new rev.

>I am conducting a routing directorate  (rtg-dir) review …
Comments from the rtg-dir provided to the authors on May 7, 2003. Waiting for the new rev.

>I am conducting a routing directorate  (rtg-dir) review of this draft, and
>I have a few (relatively trivial) comments/questions. I would be grateful
>for your responses.
>
>        Mike Shand
>
>
>
>
>1. Introduction
>
>        The term "proactive routing protocol" has a specific meaning
> within the MANET context. It might be useful for readers unfamiliar with
> the concept to give a brief definition in the "terminology" section.
>
>4. Applicability Section
>
>Is there some evidence to support the claim "it can support networks with
>up to a few hundred nodes".?
>e.g. that is the design scope, or simulations and or implementations
>support this.
>
>5.1 Overview of neighbor discovery
>
>There seems to be an inconsistency in the use of MUST/MAY in this section
>(and possibly in other sections as well).
>
>In para 7 "must" appears uncapitalized. This seems reasonable, given that
>this is just an overview.
>
>However, in the last para we have "MAY".
>
>6.1 TBRFP Packet header
>F- flag extension. Should it say that when using F to insert single octet
>of padding, the flag extension bits MUST be zero?
>
>C- Checksum included.
>The phrase "a 16 bit checksum beginning in the first octet of the header
>extension" is ambiguous, since it is not (yet) clear whether the
>"beginning" refers to the data over which the checksum is calculated, or
>the location of the computed checksum. Subsequent text reveals that it is
>the latter, but this could be made clear by saying something like
>
>"a 16 bit checksum in the first two octets of the header extension".
>
>Also, this mechanism means that a single bit error (clearing the C bit)
>can result in undetected corruption. Note that in this case the 16 bits of
>checksum will be interpreted as something else. Is that a concern?
>
>6.2 TBRPF Packet Body
>
>This use of TLVs is somewhat strange. Normally the L field is always
>present immediately after the T field and hence a new (and not recognized)
>type can be introduced, such that it is simply parsed over and ignored.
>This cannot be done with the proposed structure. IPv6 option TLVs DO have
>the normal property. It is probably confusing to call the TBRPF messages TLVs
>
>The draft doesn't say what to do with non-recognized type values. Drop the
>packet?
>
>6.2.1 Padding Options
>
>Senders MAY
>
>
>Is the use of the F bit to insert a one octet pad redundant  because of
>the existence of the Pad1 option? Or are the two intended to serve
>different purposes. (the former inserts padding prior to the length and
>router ID header extensions). It seems odd to have TWO mechanisms to
>achieve the same ends.
>
>7.8 Configurable parameters.
>
>MAX_JITTER Jitter is usually expressed as a percentage, not an absolute
>value, and value of 25% is typical. Is there a particular reason for
>specifying it this way?
>
>10.6 Support for nonMANET Hosts
>
>Should there be a section about how a TBRPF domain interfaces with the
>internet at large? Are there any special considerations?  Or is everything
>which needs to be covered dealt with in section 10.5?
>
>
>
>That's all I have. I haven't reviewed the protocol specification for
>correctness. I assume the authors and WG have already done that:-)
2003-06-06
11 Alex Zinin State Changes to AD Evaluation  :: Revised ID Needed from Publication Requested by Zinin, Alex
2003-04-25
11 Alex Zinin Draft Added by Zinin, Alex
2003-04-22
08 (System) New version available: draft-ietf-manet-tbrpf-08.txt
2003-03-07
07 (System) New version available: draft-ietf-manet-tbrpf-07.txt
2002-11-06
06 (System) New version available: draft-ietf-manet-tbrpf-06.txt
2002-03-07
05 (System) New version available: draft-ietf-manet-tbrpf-05.txt
2002-01-14
04 (System) New version available: draft-ietf-manet-tbrpf-04.txt
2001-11-29
03 (System) New version available: draft-ietf-manet-tbrpf-03.txt
2001-09-06
02 (System) New version available: draft-ietf-manet-tbrpf-02.txt
2001-03-06
01 (System) New version available: draft-ietf-manet-tbrpf-01.txt
2000-08-31
00 (System) New version available: draft-ietf-manet-tbrpf-00.txt