[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

Given that these protocols are going to run over wireless interfaces
(like IEEE 802.11), the main contributor to congestion is channel
access (not bits). Therefore; if each protocol uses a separate packet
it can result in a significant increase in channel access.

Let me give a simple example. OLSR will use NHDP, it will also add
certain TLVs to NHDP for determining MPRs. OLSR will also send other
messages. It does not really make sense to separate the two onto
different multicast addresses or ports.

Continuing to add to this example, imagine that a portion of the
network is also running DYMO and NHDP. If separate multicast groups
were used these messages would consume even more channel access
opportunities.

One more continuation, it is likely that either reactive or proactive
may use SMF with NHDP. Again, if a separate link-local address is used
then these messages cannot be aggregated.

Realistically, if a certian deployment (provider) requires each part
of the solution to use a different multicast group this could be
implemented, but I think the default (interoperable behavior) should
be to use a single multicast address to reduce channel access.

Christophe, do you think we should define one default multicast
address and one for each component?

Ian Chakeres

On 7/25/06, Christophe Jelger <Christophe.Jelger at unibas.ch> wrote: 
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