Subject: RE: Manet flooding / broadcasting....

From: Scott Corson <[email-masked]>
Date: Sun, 20 Jan 2002 14:40:58 -0500

> mechanisms might not require condition (2).  Maybe we can 
> discuss whether
> condition (2) should be a requirement for all proposed 
> flooding mechanisms.

I agree that (2) is unnecessarily restrictive, and could be viewed as a
*constraint* within the flooding policy used in (3).

-Scott

---

From: Scott Corson <[email-masked]>
Date: Mon, 21 Jan 2002 13:54:23 -0500

> I am not sure that (2) is entirely uncessary. The aim is basically to
> avoid redundant retransmissions in order to save bandwidth. 

I understand the motivation, but you are now partially defining a protocol
mechanism to achieve the desired aim of flooding.  HOW that is done should
be left to the protocol.  If this happens to be a characteristic of all
useful flooding algorithms, then that is fine.  But if there are useful
algorithms without this characteristic, why should they be prohibited?

-Scott

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 21 Jan 2002 14:46:43 -0500

[email-masked] wrote:

> We're basically digging up an old question here, however I hope it is
> possible for the the WG to reach a concensus. The question is 
> simply one
> of how RFC1812 applies to a MANET.
> 
> Strictly speaking, according to RFC1812, the expectation of a limited
> broadcast is for that to never be forwarded. I.e. in a MANET, 
> a limited
> broadcast should reach only the originating nodes neighbors.
> 
> However, speaking in terms of applications requirements, it 
> seems to me
> that the analogy of a manet on equal terms as an "Ethernet" 
> may be more
> appropriate, and hence a limited broadcast should reach all 
> nodes in the
> manet (but none beyond the manet). Think dhcp as a possible 
> application in
> this context: perhaps one node in the manet acts as 
> dhcp-server, yet this
> is not present in all nodes neighborhood.

I agree with the DHCP example, which is in fact a bit of a kludge (when the
DHCP server is not a member of the local IP subnet), but I don't agree with
the analogy that a MANET could be considered as one single Ethernet. In my
view, the whole point of MANET is that it goes beyond the single subnet or
LAN.

> Either way, I think this is basically a matter of which symbols to
> associate with which semantics and mechanisms: it should definitely be
> decided, but it should not influence the construction of a broadcast /
> flooding protocol.

Why no play it safe and use a well-known multicast address? Actually, there
is 224.0.0.11 for "mobile agents." Perhaps something called "ad-hoc agents"
could be added to the list?

Bert
[email-masked]

---

From: Scott Corson <[email-masked]>
Date: Tue, 29 Jan 2002 17:08:16 -0500

> appropriate, 

I think it really depends on the applications and the context.  For small
stub networks this may be a reasonable view.

But generally I think the analogy of viewing a manet as an Ethernet is
flawed.  I think that by default a limited broadcast should not extend
beyond reach of nodes receiving the broadcast, and routers should not
rebroadcast, generally in keeping with RFC1812.  An application wishing to
create an Ethernet-like behaviour out of a manet may utilize the manet
flooding service we've been discussing.  It could encapsulate data for
flooding, and at each step in the flooding process the receiving routers
could receive and optionally process/drop the decapsulated packets in
addition to continuing with the flooding behavior.

So...if the WG is content to observe 1812 in this fashion, and implement the
flooding behavior over top in a variety of fashions (up to protocol
designers), I think we are heading towards agreement on the basics of a
service definition.

-Scott

---

From: [email-masked]
Date: Thu, 31 Jan 2002 14:56:37 +0100 (CET)

Richard,

(Sorry, Richard, for sending this twice. I forgot to Cc. the manet list
 the first time. My mistake)

On Thu, 31 Jan 2002 [email-masked] wrote:

> 
> Thomas,
> 
> > > Philippe,
> > > 
> > > Yes, I know that HELLOs can be partial and that each neighbor must be 
> > > included in at least one HELLO every HELLO interval, but unless there 
> > > are too many neighbor IDs to fit into one packet, normally OLSR uses one 
> > > full HELLO per HELLO interval.  (Just check the source code.)
> > 
> > Richard,
> > 
> > Please keep seperate implementation choises from protocol specifications. 
> > 
> > In the current implementation, it may be chosen to use full HELLO's. It
> > is also chosen not to use link-layer notifications. However, as is
> > mentioned elsewhere on the list (by Laurent), another possible choise
> > would be to include link-layer notifications and trigger partial HELLO's
> > as a result hereof.
> > 
> > While not provided by the implementation you are using, it cirtainly is
> > permitted by the protocol specification.
> 
> I guess my statement above was not clear.
> I was NOT precluding the possibility of sending partial HELLOs
> indicating LOST neighbors, in *addition* to sending one
> full HELLO per HELLO interval.
> I was just saying that, if the number of neighbors is not
> too large, they would normally be reported in a single full HELLO
> (to minimize overhead) rather than in multiple partial HELLOs.
> 

Actually, you are not even required to send any "full" HELLO's
periodically. 

Just to refresh: the rule is, that within NEIGHB_HOLD_TIME information
about each node must be transmitted at least once.

Thus, as you propose, one (correct) implementation could periodically send
"full" HELLO's and - as needed - send additional HELLO's, e.g. to indicate
status change of a link. This would be a perfectly valid implementation.

However if a neighbor has been reported in such a "non-periodic"
additional HELLO-message, it is not required to include that neighbor in
the following "periodic" HELLO-message. I.e. the "periodic" HELLO-messages
would not necessarilly be "full". This would also be a perfectly valid
implementation.

Of course I agree that, in general, it makes sense to consider the
overhead of transmitting a message on a given medium: when accessing the
medium, it makes sense to accomodate the "overhead" of doing so by
transmitting a reasonable amount of information. So a "smart" OLSR-
implementation would take advantage of the transmission of an "additional"
HELLO-message (reporting a neighbor link status change) to include
refreshing of other, non-changed links. This would then further reduce the
size of any "periodic" HELLO-messages - if not elliminate them
completely. This too would make a valid implementation.

However all this mostly concirns implementation choises, and may be
dictated by different needs in a specific network. 

-- 

-------------------------------------------
  Thomas Heide Clausen
  Civilingeniør i Datateknik (cand.polyt)
  M.Sc in Computer Engineering

  E-Mail: [email-masked]
  WWW:    http://www.cs.auc.dk/~voop
-------------------------------------------