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

["Francisco J. Ros" <fjrm at dif.um.es>]

Hi everyone,

On Tuesday 25 July 2006 19:05, Ian Chakeres wrote:
> 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.
>
However, if the messages are aggregated the packet size increases and, 
accordingly, the likelihood of having an error in the transmission. I'm just 
pointing out that there is a tradeoff there.

> 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.
>
Agree.

> 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.
>
If the NHDP had its own multicast address, it wouldn't make a difference 
whether the other portion is running DYMO or OLSR.

> 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.
>
Yes.

Right now I can't see which approach is better. I think the point raised by 
Cristophe is important, since processing messages of a protocol which is not 
implemented by the node seems a waste of resources. On the other hand, 
sending OLSRv2 and NHDP messages to different addresses sounds quite strange.

Regards,
Francisco J. Ros

> 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

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