Subject: [manet] I-D ACTION:draft-ietf-manet-tbrpf-10.txt

From: [email-masked]
Date: Tue, 29 Jul 2003 12:14:48 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title		: Topology Dissemination Based on Reverse-Path 
                          Forwarding (TBRPF)
	Author(s)	: R. Ogier, M. Lewis, F. Templin
	Filename	: draft-ietf-manet-tbrpf-10.txt
	Pages		: 47
	Date		: 2003-7-29
	
TBRPF is a proactive, link-state routing protocol designed for mobile
ad-hoc networks, which provides hop-by-hop routing along shortest
paths to each destination. Each node running TBRPF computes a source
tree (providing paths to all reachable nodes) based on partial
topology information stored in its topology table, using a
modification of Dijkstra's algorithm. To minimize overhead, each node
reports only *part* of its source tree to neighbors. TBRPF uses a
combination of periodic and differential updates to keep all
neighbors informed of the reported part of its source tree. Each node
also has the option to report additional topology information (up to
the full topology), to provide improved robustness in highly mobile
networks. TBRPF performs neighbor discovery using 'differential'
HELLO messages which report only *changes* in the status of
neighbors. This results in HELLO messages that are much smaller than
those of other link-state routing protocols such as OSPF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-tbrpf-10.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-manet-tbrpf-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-manet-tbrpf-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Shubhranshu <[email-masked]>
Date: Thu, 31 Jul 2003 10:10:51 -0800

Hi,

In section 5.2 , second paragraph -- " The part 
of T that a node reports to neighbors is called the
   "reported subtree" and is denoted RT... "

Which part of T  ?

Thanks 
Shubhranshu

----- Original Message ----- 
From: <[email-masked]>
To: <IETF-Announce:>
Cc: <[email-masked]>
Sent: Tuesday, July 29, 2003 8:14 AM
Subject: [manet] I-D ACTION:draft-ietf-manet-tbrpf-10.txt

> http://www.ietf.org/internet-drafts/draft-ietf-manet-tbrpf-10.txt

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: [email-masked]
Date: Wed, 30 Jul 2003 20:16:44 -0700

>    "reported subtree" and is denoted RT... "

Hi Shubhranshu,

The answer can be found two paragraphs later (in Section 5.2 - Overview
of the Routing Module) where RT and RN are described, and in more detail 
in Section 8.4.4 - Updating the Reported Node Set.

Regards,
Richard

---

From: Shubhranshu <[email-masked]>
Date: Thu, 31 Jul 2003 14:12:38 -0800

Hi Richard,
 Thanks
One more quick question :
In section 8.4.4, third paragraph --- " .... shortest 
paths, up to 2 hops, from each neighbor to each other 
neighbor, using only neighbors (or node i itself) as an intermediate node,...."

I feel that it should be     ".....to  each other neighbor, using only
*node i itself* as an intermediate node ..." 
If not  then I am afraid i could not  exactly understand how  
node i determines that one of its neighbors 
may select i to be its next hop  on its shortest path to j. 

Regards
Shubhranshu

---

From: [email-masked]
Date: Thu, 31 Jul 2003 13:03:13 -0700

Hi Shubhranshu,

> In section 8.4.4, third paragraph --- " .... node i computes shortest 

For reference, here is the paragraph in the draft:

   "A node first determines which of its neighbors belong to RN. Node i
   includes a neighbor j in RN if and only if node i determines that one
   of its neighbors may select i to be its next hop on its shortest path
   to j. To make this determination, node i computes the shortest paths,
   up to 2 hops, from each neighbor to each other neighbor, using only
   neighbors (or node i itself) as an intermediate node, and using relay
   priority and router ID to break ties."

Maybe this rewrite will make it clearer: To determine which neighbors 
are in RN, node i computes shortest paths, up to 2 hops, from each 
neighbor k to each other neighbor j, allowing only neighbors of node i
(or node i itself) to be the intermediate node, and using relay priority
and router ID to break ties. (If the intermediate node happens to be
node i, then node j is included in RN.)

The procedure Update_RN() defined in the same section makes this precise.

Note also that node i knows the local links reported by each neighbor,
i.e., it knows the full topology for its 2-hop neighborhood, which
allows it to compute the 2-hop shortest paths mentioned above.

The following paragraph from the draft helps to understand
the analogy between neighbors in RN and MPR selectors:

   "We note that neighbors in RN are analogous to multipoint relay (MPR)
   selectors [9]. Thus, if node i selects neighbor j to be in RN, then
   node i effectively selects itself to be an MPR of node j. This is
   quite different from [9], in which a node does not select itself to
   be an MPR, but selects a subset of its neighbors to be MPRs."

Regards,
Richard