Subject: Re: A Note on Broadcast Control Packets

From: [email-masked] (Joseph P. Macker)
Date: Mon, 1 Dec 1997 13:20:34 -0500

At 10:39 AM 12/1/97 -0400, Zygmunt Haas wrote:
>Hi John,
>
>Yes, broadcasting may be unreliable. But there are many situations in which
>reliable broadcasting in not required. Especially in route-discovery protocols
>that rely on flooding. A node can receive a flood from multiple sources.
>If some of them are lost, this does not represent a major problem. 
 
I was hoping that the group can migrate towards a slightly flexible control messaging framework that would allow particular protocol or interfaces to do what makes sense (e.g., broadcast, point-to-point, reliable when needed).  This is partly what the recent IMEP draft that Scott put together was about (this is a support protocol that could be used for different mobile routing protocols and much remains to be fleshed out).  I realize different routing approaches and link layer mechanisms can lead to different individual requirements/preferences here and we should discuss it in that context.  This is a good time for us to figure out how much commonality exists here.

-joe

---

From: Bora Akyol <[email-masked]>
Date: Tue, 02 Dec 1997 10:15:34 -0500

> I was hoping that the group can migrate towards a slightly flexible control messaging framework that would allow particular protocol or interfaces to do what makes sense (e.g., broadcast, point-to-…

I believe that as long as you have a single transmitter in the radio
units and don't have global synchronization (which would rule out
designated control broadcast slots) and the radios are more than a few
feet apart from each other, you will need to have something other than
broadcast for "reliable" control messaging and signaling. Moreover,
if power is an issue, you possibly would like to turn off your receiver
off some of the time. 

One other thing to note is that "reliable" is almost certainly required
for route updates so that route information is accurate and
network resources are not wasted by misrouted packets. 

Of course this is open to discussion.

-- 
Bora Akyol
BBN Technologies
GTE Internetworking

---

From: "M. Scott Corson" <[email-masked]>
Date: Tue, 2 Dec 1997 17:13:52 -0500 (EST)

> Of course this is open to discussion.

Bora,

Some of this is discussed in the IMEP draft.

-Scott

*******************************************************************************

M. Scott Corson                                 Institute for Systems Research
[email-masked]                              A.V. Williams Bldg. (115)
Phone: 301-405-6630 (Rm. 2205 AVW)              University of Maryland     
Fax:   301-314-8586                             College Park, MD  20742

*******************************************************************************