[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[manet] Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt

Yes that's a good point but having a common packet format is not in contradiction with having a dedicated mcast addr per routing protocol. I understand that having a unique mcast addr makes it easy to aggregate routing information but while I understand this is useful for a given protocol, I cannot see why it's useful among different protocols. I mean, carrying routing messages all over the MANET is one thing, but this makes little sense if intermediate nodes are not ready to partipate in packet forwarding. For example in the following scenario

  A(DYMO) --- B(OLSRv2) --- C(DYMO)

if node C receives DYMO messages from A (messages sent by A are aggregated with the messages sent by B) and vice versa, still node B does not process DYMO messages and hence would not create forwarding states. Communication between A and C is not possible. With dedicated mcast addresses, C and A don't see eachother at the DYMO level but anyway they cannot communicate so it makes perfect sense to me.

As I said in an autoconf-only email, having different mcast addresses is an optimization because it introduces some low-level filtering at the MAC layer. For example NHDP introduces the ALL-MANET-NEIGHBORS address: in your view would this be different than the ALL-MANET-ROUTERS address?

Personaly I don't see any negative reasons for not having an mcast address per protocol (DYMO, OLSRv2, NHDP). Note that I'm not against your scheme, I just think it's better to have dedicated mcast addresses.

regards,
Christophe

Ian Chakeres wrote: 
Since March 2005, we've come a long way building common building
blocks into MANET protocols. We now have a common packet/message
format (PacketBB) and a common neighborhood discovery protocol (NHDP).
In order to aggregate MANET messages we'd need to send these to the
same Multicast group. This is the reasoning behind using a single
multicast group; instead of one per protocol.

Ian

On 7/25/06, Christophe Jelger <Christophe.Jelger at unibas.ch> wrote:

Ian/all,

I didn't attend the last ietf meeting so I don't know how this topic was
discussed but I remember we had a similar discussion in March 2005 and
the consensus (March 17th 2005) was that there should be a multicast
address for each MANET routing protocol as done with existing routing
protocols (e.g. ff02::5 and ff02::6 for OSPF, ff02::9 for RIP, ff02::d
for PIM).

One argument was to be consistent with current practices, and another
argument was that we already have ff02::1 (all nodes) and ff02::2 (all
routers) so it was not clear why we should have an extra
"all_manet_routers" address (especially if we have a multicast address
for each manet routing protocol). Also having a different multicast
address for each manet routing protocol prevents a node that does not
run a given routing protocol to process packets associated to it: it
will not even receive them at the MAC layer.

So I'm rather in favor of having for example ff02::DYMO and
ff02::OLSRv2, and if a larger scope is required we can instead have
ff0x::DYMO and ff0x::OLSRv2. This implies that there would not be an
all_manet_routers address. Now for address autoconfiguration, there
could also be a dedicated multicast address ff0x::MANET-AUTOCONF.

regards,
Christophe

PS: note that the same reasoning applies to IPv4

Ian Chakeres wrote:
> Here is the draft I promised during MANET IETF 66 discussing MANET
> IANA considerations. It is meant to aid in discussing IANA assignments
> for MANET. I've broken down the different components into different
> sections.
>
> I think we are all in agreement in the immediate need for LL
> (link-local) MANET Routers multicast group.
>
> Less agreement, but definitely useful is a MANET UDP port.
>
> More discussion is needed for Scoped MANET Routers and any other
> scoped "host/node" multicast groups. Please comment on these. I would
> especially like some feedback from AUTOCONF people.
>
> Please email your comments to the lists or to me directly.
>
> Thanks.
> Ian Chakeres
>
> BTW: A document discussing MANET architecture should be coming out
> this week. Once it is posted I'll send an email also. The arch
> document may help in discussing the different IANA assignments.
>



_______________________________________________
manet mailing list
manet at ietf.org
https://www1.ietf.org/mailman/listinfo/manet