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

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 24 Jul 2006 14:58:20 -0700

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.

---------- Forwarded message ----------
From: [email-masked] <[email-masked]>
Date: Jul 24, 2006 12:50 PM
Subject: I-D ACTION:draft-chakeres-manet-iana-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Discussing MANET IANA Needs
        Author(s)       : I. Chakeres
        Filename        : draft-chakeres-manet-iana-00.txt
        Pages           : 9
        Date            : 2006-7-24

   This document enumerates several possible IANA assignments for MANET
   protocols.  It is meant to aid and stimulate discussion on this
   topic.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chakeres-manet-iana-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-chakeres-manet-iana-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-chakeres-manet-iana-00.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Christophe Jelger <[email-masked]>
Date: Tue, 25 Jul 2006 10:43:31 +0200

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

---

From: "Ian Chakeres" <[email-masked]>
Date: Tue, 25 Jul 2006 07:53:27 -0700

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

---

From: Christophe Jelger <[email-masked]>
Date: Tue, 25 Jul 2006 17:37:08 +0200

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

---

From: "Ian Chakeres" <[email-masked]>
Date: Tue, 25 Jul 2006 10:05:46 -0700

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

---

From: "Francisco J. Ros" <[email-masked]>
Date: Tue, 25 Jul 2006 19:34:53 +0200

Hi everyone,

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

> different multicast addresses or ports.
Agree.

> were used these messages would consume even more channel access
If the NHDP had its own multicast address, it wouldn't make a difference 
whether the other portion is running DYMO or OLSR.

> 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

> > >> 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).
> > >>
> > >> > IANA considerations. It is meant to aid in discussing IANA
> > >> > assignments for MANET. I've broken down the different components
> > >> > into different sections.
> > >> >
> > >> > scoped "host/node" multicast groups. Please comment on these. I
> > >> > would especially like some feedback from AUTOCONF people.
> > >> >

---

From: [email-masked]
Date: Tue, 25 Jul 2006 21:15:15 +0200

Ian,

See my comments inline.

> it can result in a significant increase in channel access.

ok that's something I didn't think of. However if this is the only point in
favor of aggregation I'm afraid I'm still not really convinced. One drawback of
aggregation is increased delay. That is, each node will have to wait some small
amount of time (1ms?, 10ms?) to be able to aggregate packets.

> be to use a single multicast address to reduce channel access.

ok I understand your points but I'm just not much convinced about the
aggregation feature. Of course it's somehow elegant but I'm not sure the extra
complexity is worth the effort.

> address and one for each component?

Well IMHO I'm still in favor of having separate multicast addresses for e.g.
respectively DYMO, OLSRv2 and NHDP. But hey after all this is not the most
important issue to be resolved so I won't fight very hard. ;-)

regards,
Christophe

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 26 Jul 2006 08:12:29 +0200

Christophe,

> amount of time (1ms?, 10ms?) to be able to aggregate packets.

That depends how it is done. If you run a protocol with periodic  
message emissions on one node, and then that node needs to forward an  
"occasional" external message, you have two options" either hold the  
external message while you wait for your next scheduled periodic  
message to be up for transmission (which incurs a delay). Or you may  
chose to immediately generate the next periodic message and transmit  
this immediately with the "external" message, and then reset your  
periodic schedule.

The devil is in the details. I believe that one detail would be that  
the MANET routing protocols which use periodic messages are perfectly  
capable of dealing with triggered "out of schedule" messages, and to  
reset the schedule as appropriate. Of course, one must not forget  
that it being *possible* to do something does not mean that it is  
*mandatory* to do so: if in the example given above the next periodic  
message was scheduled to be sent in 4 hours, it might possibly be  
that one would not want to reschedule, but just send the external  
message.

But yes, making a good message scheduler that's general enough to  
understand these things is part of the exercise of an implementation

>> different multicast addresses or ports.

And even more: even looking at the messages from a single nodes  
perspective, OLSRv2-nodes use NHDP for their local topology  
maintenance and will thus generate TC messages and NHDP-HELLO  
messages. Since HELLO messages are sent more frequently than TC  
messages, even a simple scheduler would say "if I am to send a TC  
message at the latest at deadline XXX, send it with the last HELLO  
message with a deadline <XXX" - in terms of "number of channel access  
cycles" it would thereby be "free" to run OLSRv2 on top of NHDP,  
since OLSRv2 TC messages and NHDP HELLO messages would thereby be  
sent aggregated.

> complexity is worth the effort.

Christophe, which complexity is it that you are worried about? The  
parsing of multi-message packets is something we've done in OLSR  
since before RFC3626. The scheduling issues, you can make a scheduler  
as complex as you like: taking into account aggregation in a clever  
way -- or as simple as you like by simply not doing aggregation.  
We've done that in OLSR since before RFC3626 too.

> important issue to be resolved so I won't fight very hard. ;-)

I think it is important, so I will fight very hard ;)

I do not see what different multicast addresses with identical scope  
for each component would buy us. Again, speaking with the OLSRv2-hat,  
I definitely would want my TC and HELLO messages to be aggregateable,  
and would therefore either say "thou shall send both to generic-manet- 
mcast-address-XXX", or say "thou shall send both to olsrv2-mcast- 
address-XXX", but I would *never* want to send them to different  
addresses.

Anything that would prevent me from aggregating such TCs and HELLOs  
would, in my opinion, be broken.

--thomas

---

From: Christophe Jelger <[email-masked]>
Date: Wed, 26 Jul 2006 10:21:06 +0200

Hello Thomas,

Thomas Clausen wrote:
> (...)
> parsing of multi-message packets is something we've done in OLSR  since 
> before RFC3626. The scheduling issues, you can make a scheduler  as 
> complex as you like: taking into account aggregation in a clever  way -- 
> or as simple as you like by simply not doing aggregation.  We've done 
> that in OLSR since before RFC3626 too.
> 

I refered to what you mention when you say "the devil is in the details" 
(i.e. the aggregation scheduler). Of course parsing is not an issue.

> for each component would buy us. 

Networking is about exchanging messages between interested parties. I 
just don't buy the idea that each MANET node will have to read and parse 
messages for which it might have "no interest": this sounds like spam to 
me. Moreover having a dedicated mcast addr per protocol is the best 
current practise in the ietf wgs.

> Again, speaking with the OLSRv2-hat,  I 
> definitely would want my TC and HELLO messages to be aggregateable,  and 
> would therefore either say "thou shall send both to generic-manet- 

At the end the draft authors (DYMO, OLSRv2, NHDP) will choose anyway 
what they prefer so that's why I cynically say "I won't fight very hard".

> would, in my opinion, be broken.

I realized that.

---

From: Abhishek Misra <[email-masked]>
Date: Wed, 26 Jul 2006 13:54:11 +0530 (IST)

Hello,

We are trying to develope Wireless Mesh Router[with multiple interfaces]
software I wish to know if some auto ip address assignment schemes for
mesh networks have been proposed.
We plan to use cards in master mode to support clients on each interface
and use wds links for routing and forwarding data. 

Thank You
Abhishek Misra