Subject: [Roll] need clarification: DIS processing

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 2 Nov 2009 18:00:40 +0100

Hi all,
 
one question:
when a router receives a DIS, should it answer right away? I guess this
is a good source of collision, so a random timer would help. Could we
set T to a random value between I_min /2 and I_Min, without resetting I
(receiving a DIS does not mean inconsistency)?
 
Best,
Julien

---

From: JP Vasseur <[email-masked]>
Date: Mon, 2 Nov 2009 22:03:37 +0100

Hi,

On Nov 2, 2009, at 6:00 PM, Julien Abeille (jabeille) wrote:

> Hi all,
>
> one question:
> when a router receives a DIS, should it answer right away? I guess  
> this is a good source of collision, so a random timer would help.  
> Could we set T to a random value between I_min /2 and I_Min, without  
> resetting I (receiving a DIS does not mean inconsistency)?

I do not see either why we should reset the trickle timer.

JP.

>
> Best,
> Julien
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Tue, 3 Nov 2009 11:25:46 -0800

On Nov 2, 2009, at 1:03 PM, JP Vasseur wrote:

>> Could we set T to a random value between I_min /2 and I_Min,  
>> without resetting I (receiving a DIS does not mean inconsistency)?
>

The CTP analogy to DIS is the "pull" bit, which allows a node to  
solicit beacons (the equivalent of DIOs) from neighbors. Hearing a  
message with the pull bit set resets a node's trickle timer. This  
causes nearby nodes to send beacons very soon, speeding discovery. I  
think it makes sense to just reset the trickle timer, rather than  
trying to introduce special edge cases.

Phil

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 3 Nov 2009 11:50:03 -0800

> trying to introduce special edge cases.

Agreed.  Though is the spec clear on whether the DIO is sent unicast  
or multicast in response to a unicast DIS?  Is there a good use case  
to unicast the DIO response back to the requester?  If unicasting a  
response, setting the Trickle timer is probably not the right  
approach.  But I personally don't think unicast responses are  
particularly helpful.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Nov 2009 13:52:35 +0100

At the moment, I cannot figure when an immediate response would be
needed. 

I think Phil mentions that somewhere else as well. The idea would be to
arm trickle and let it time out.

Also let us keep in mind that in networking at large, most timers are
jittered to avoid network synchronizations. In wireless, it is even
worse since as you point out, synchronization also means collisions.

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Julien Abeille (jabeille)
Sent: lundi 2 novembre 2009 18:01
To: ROLL WG
Subject: [Roll] need clarification: DIS processing

Hi all,

one question:

Best,

Julien

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 9 Nov 2009 18:21:27 +0100

of course it needs jitter. Now trickle is armed anyway at all times
right (T timer). If we do not do anything specific, the DIO will not
come earlier with DIS than without...
So if no immediate response is needed, then DIS is not needed. I still
think it is, for instance anytime you lose you r last parent, and do not
want to wait possibly hours to get a DIO. This is the same as with RS/RA
(jittered !)
 
Resetting trickle (I to Imin, and T to random ) does not make sense I
guess, as sending a DIS does not always mean global instability.
Thoughts on how to arm a small jittered timer?
 
Best,
Julien

________________________________

	From: Pascal Thubert (pthubert) 
	Sent: lundi 9 novembre 2009 13:53
	To: Julien Abeille (jabeille); Philip Levis
	Cc: ROLL WG
	Subject: RE: [Roll] need clarification: DIS processing

	At the moment, I cannot figure when an immediate response would
be needed. 

	I think Phil mentions that somewhere else as well. The idea
would be to arm trickle and let it time out.

	Also let us keep in mind that in networking at large, most
timers are jittered to avoid network synchronizations. In wireless, it
is even worse since as you point out, synchronization also means
collisions.

	Pascal

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Abeille (jabeille)
	Sent: lundi 2 novembre 2009 18:01
	To: ROLL WG
	Subject: [Roll] need clarification: DIS processing

	Hi all,

	one question:

	when a router receives a DIS, should it answer right away? I
guess this is a good source of collision, so a random timer would help.
Could we set T to a random value between I_min /2 and I_Min, without
resetting I (receiving a DIS does not mean inconsistency)?

	Best,

	Julien

---

From: Tim Winter <[email-masked]>
Date: Wed, 11 Nov 2009 19:04:12 -0500

Hi Julien,

> want to wait possibly hours to get a DIO. This is the same as with RS/RA

Yes, I agree DIS is needed also- and this is exactly how we got to DIS.  It
started by first allowing nodes to actively probe the neighborhood by using
`RS' to solicit `RA-DIO'. from their neighborhood in previous RPL versions.
 This was thought to be useful, e.g., for battery powered nodes that do not
want to wait.  Now that RPL does not use RS/RA/NA we have introduced DIS for
this exact purpose.

> Thoughts on how to arm a small jittered timer?

It doesn't mean global instability- but it does mean that something has
changed in the local neighborhood at least.  So fair enough I think to reset
trickle, to let trickle do it's job.  I agree with prior comments- lets not
make a special case here for DIS handling.

The DIS should then also be multicast, and it should trigger multicast DIO
responses.

Regards,

-Tim

>  
> Best,
> Julien
> 
>     ------------------------------------------------------------------------
>     *From:* Pascal Thubert (pthubert)
>     *Sent:* lundi 9 novembre 2009 13:53
>     *To:* Julien Abeille (jabeille); Philip Levis
>     *Cc:* ROLL WG
>     *Subject:* RE: [Roll] need clarification: DIS processing
> 
>     I think Phil mentions that somewhere else as well. The idea would be
>     to arm trickle and let it time out.
> 
>      
> 
>     Also let us keep in mind that in networking at large, most timers
>     are jittered to avoid network synchronizations. In wireless, it is
>     even worse since as you point out, synchronization also means
>     collisions.
> 
>      
> 
>     Pascal
> 
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Julien Abeille (jabeille)
>     *Sent:* lundi 2 novembre 2009 18:01
>     *To:* ROLL WG
>     *Subject:* [Roll] need clarification: DIS processing
> 
>      
> 
>     Hi all,
> 
>      
> 
>     one question:
> 
> ------------------------------------------------------------------------
>

---

From: Philip Levis <[email-masked]>
Date: Thu, 12 Nov 2009 07:31:29 -0800

> make a special case here for DIS handling.

I think that the Trickle text in the draft presents it in a narrower  
light than which it's been used for routing protocols. A CTP node, for  
example, resets the Trickle timer on three conditions:

1. It receives a packet to forward whose transmitter's routing cost <=  
the receiver's routing cost.
2. It receives a packet with the "P" bit set (the equivalent of a DIS).
3. Its cost decreases significantly.

We've all been discussing 1. But let's no forget conditions 2 and 3.  
For 2, a node does not have entries in its neighbor table, then one  
could say its logical topology is inconsistent with its physical  
topology. 3 is very much a performance optimization. It handles the  
case when a node might suddenly offer a much less expensive route than  
before, and its neighbors view of its cost is out-of-date enough that  
it might lead to sub-optimal behavior.

My experience is that conditions 1 and 2 are both important, 3 is just  
a small optimization. Using an exponentially increasing timer (rather  
than just a jittered one) is critical. The reason is that, under  
sufficient density, a given jittered interval can be too small and  
lead to many collisions (don't forget we're LLNs, and so can be using  
low-power link layers that don't work that well under broadcast  
storms). If you go back to the Trickle paper, you'll note there were  
several experimental cases where propagation took more than one timer  
interval per hop due to collisions. Having an exponentially increasing  
timer solves this problem: if the optimal interval length is L, then  
nodes will find it in 2L, with a logarithmic message cost. This is  
part of what allows Trickle to adapt to thousand-fold changes in  
network density.

> The DIS should then also be multicast, and it should trigger  

Agreed.

---

From: Tim Winter <[email-masked]>
Date: Fri, 13 Nov 2009 20:47:26 -0500

WG,

Upon further discussion we propose for -05 :

	- A multicast DIS will trigger multicast DIO (by resetting the trickle
timer) as in support of case `2' below, where a node wants to poll the
neighborhood

	- A unicast DIS will trigger a unicast DIO response.  This is in
consideration of the fact that DIO Configuration Options may not be included
in every DIO- in the case where a node has, e.g., added a new parent and is
uncertain about the DAG configuration, it may use a unicast DIS.  In every
unicast DIO response then the DAG Configuration MUST be included.

Sounds good?

- RPL Authors

Philip Levis wrote:
> We've all been discussing 1. But let's no forget conditions 2 and 3. For
> 2, a node does not have entries in its neighbor table, then one could
> say its logical topology is inconsistent with its physical topology. 3
> is very much a performance optimization. It handles the case when a node
> might suddenly offer a much less expensive route than before, and its
> neighbors view of its cost is out-of-date enough that it might lead to
> sub-optimal behavior.
> 
> My experience is that conditions 1 and 2 are both important, 3 is just a
> small optimization. Using an exponentially increasing timer (rather than
> just a jittered one) is critical. The reason is that, under sufficient
> density, a given jittered interval can be too small and lead to many
> collisions (don't forget we're LLNs, and so can be using low-power link
> layers that don't work that well under broadcast storms). If you go back
> to the Trickle paper, you'll note there were several experimental cases
> where propagation took more than one timer interval per hop due to
> collisions. Having an exponentially increasing timer solves this
> problem: if the optimal interval length is L, then nodes will find it in
> 2L, with a logarithmic message cost. This is part of what allows Trickle
> to adapt to thousand-fold changes in network density.
>

---

From: [email-masked]
Date: Mon, 16 Nov 2009 13:32:28 -0600

Hi TIm,

Can you clarify the use cases for DIS again?  I am trying to piece 
together your response to Julien's email, but am not sure I'm getting it.

I agree with Julien that we need a DIO solicitation message (i.e. DIS) 
since as he says a packet can't wait around for hours waiting for a new 
DAG parent.  I buy that and agree with it.  However, I am a bit confused 
why a multicast DIS should trigger a multicast DIO.  This seems to simply 
add unnecessary packets onto the network.  Why wouldn't a multicast DIS be 
responded to by a unicast DIO from each of the node's neighbors rather 
than a series of multicast DIOs from each of its neighbors.

Jerry

Tim Winter <[email-masked]> 
Sent by: [email-masked]
11/13/2009 07:47 PM

To
ROLL WG <[email-masked]>
cc

Subject
Re: [Roll] need clarification: DIS processing

WG,

                 - A multicast DIS will trigger multicast DIO (by 
resetting the trickle
timer) as in support of case `2' below, where a node wants to poll the
neighborhood

                 - A unicast DIS will trigger a unicast DIO response. This 
is in
consideration of the fact that DIO Configuration Options may not be 
included
in every DIO- in the case where a node has, e.g., added a new parent and 
is
uncertain about the DAG configuration, it may use a unicast DIS.  In every
unicast DIO response then the DAG Configuration MUST be included.

Sounds good?

- RPL Authors

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Nov 2009 14:50:02 -0500

>>>>> "Jerald" == Jerald P Martocci <[email-masked]> writes:
    Jerald> I agree with Julien that we need a DIO solicitation message
    Jerald> (i.e. DIS) since as he says a packet can't wait around for
    Jerald> hours waiting for a new DAG parent.  I buy that and agree
    Jerald> with it.  However, I am a bit confused why a multicast DIS
    Jerald> should trigger a multicast DIO.  This seems to simply add
    Jerald> unnecessary packets onto the network.  

  I am reacting to the last sentence.
  I'd have thought that multicast avoids unncesary packets!!!!
  So perhaps we are not talking about the same thing?

  Maybe we need better terminology.
  I think that there are three kinds of transmission:
    a) unicast 
    b) link-level multicast
    c) subnet-level multicast 
  On ethernet, (b) and (c) are the same thing.

  On 6lowpan-type networks, I think (b) is what happens when you
transmit to the nodes that can hear you, and (c) is what you do via a
whiteboard or multicast relay.

  (Maybe there are accepted terms for this, of which I am ignorant)

  Only transmissions of type (c) cause more packets on the wire.

  Transmissions of type (b) would save packets, because one message
arrives at many receivers at the same time.  Maybe (b) causes receivers
that would otherwise have been happy to sleep (doze?) to wake up.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: [email-masked]
Date: Tue, 17 Nov 2009 08:31:40 -0600

Hi Michael,

Yes you're right, whether the responses to a DIS are multicast or unicast, 
the packet count is the same.  However, if the responses are multicasts 
(rather than unicasts) then other nodes are necessarily interpreting 
packets that are really not destined to them.  I would prefer the 
responses to a multicast DIS be a series of unicast DIOs.

Michael Richardson <[email-masked]> 
Sent by: [email-masked]
11/16/2009 01:50 PM

To
ROLL WG <[email-masked]>
cc

Subject

- -- 
]       He who is tired of Weird Al is tired of life!           | 
firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net 
architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device 
driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE
                                then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Nov 2009 10:12:23 -0500

>>>>> "Jerald" == Jerald P Martocci <[email-masked]> writes:
    Jerald> Yes you're right, whether the responses to a DIS are
    Jerald> multicast or unicast, the packet count is the same.
    Jerald> However, if the responses are multicasts (rather than
    Jerald> unicasts) then other nodes are necessarily interpreting
    Jerald> packets that are really not destined to them.  I would
    Jerald> prefer the responses to a multicast DIS be a series of
    Jerald> unicast DIOs.

So, what concerns you is the wake-up cost of the extra DIOs.

---

From: Joakim Eriksson <[email-masked]>
Date: Tue, 17 Nov 2009 16:20:39 +0100

On the other hand it might be possible to do redundancy-count of
the multi-cast DIOs for all nodes in range and thereby get lower 
likelihood of sending a DIO when the trickle timer triggers next
time!?

Best regards,
-- Joakim Eriksson, SICS

---

From: [email-masked]
Date: Tue, 17 Nov 2009 09:41:48 -0600

Michael,

No. Just the extra processing requirement to handle messages not destined 
for the device.  As I have stated many times, these devices are small 
controllers that provide environmental control as their first priority, 
and route packets as a side job.  The less they need to deal with 
communication messages, the more they can control the environment.

Jerry

Michael Richardson <[email-masked]> 
Sent by: [email-masked]
11/17/2009 09:12 AM

To
[email-masked]
cc
ROLL WG <[email-masked]>, [email-masked]
Subject
Re: [Roll] need clarification: DIS processing

                                then sign the petition.

---

From: Philip Levis <[email-masked]>
Date: Tue, 17 Nov 2009 08:08:02 -0800

On Nov 17, 2009, at 6:31 AM, [email-masked] wrote:

>
>
> Hi Michael,
>
> Yes you're right, whether the responses to a DIS are multicast or  
> unicast, the packet count is the same.  However, if the responses  
> are multicasts (rather than unicasts) then other nodes are  
> necessarily interpreting packets that are really not destined to  
> them.  I would prefer the responses to a multicast DIS be a series  
> of unicast DIOs.

How would this work? To what destination(s) would the node send a  
series of unicast DIOs? This should be a lower-layer decision: it's up  
to lower layers to know/decide how best to implement a multicast.

Phil

---

From: [email-masked]
Date: Tue, 17 Nov 2009 10:28:32 -0600

I thought nodes always had to send DIOs on trickle timer expiration in 
case a new node is awaiting a DIO to join the DAG?

Has there been any thought of dropping the periodic DIOs now that we have 
event based DIS/DIOs?  It seems to me that as a new node wanting to join 
the DAG (or move around the DAG) I would be more inclined to simply issue 
a multicast DIS and immediately get the state of my neighbors than to wait 
around for an undetermined amount of time collecting periodic DIOs.

Jerry

Joakim Eriksson <[email-masked]> 
11/17/2009 09:20 AM

To
Michael Richardson <[email-masked]>
cc
[email-masked], ROLL WG <[email-masked]>
Subject
Re: [Roll] need clarification: DIS processing

Best regards,
-- Joakim Eriksson, SICS

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 17 Nov 2009 08:40:55 -0800

On Nov 17, 2009, at 8:28 AM, [email-masked] wrote:

> I thought nodes always had to send DIOs on trickle timer expiration  
> in case a new node is awaiting a DIO to join the DAG?
>
> Has there been any thought of dropping the periodic DIOs now that we  
> have event based DIS/DIOs?  It seems to me that as a new node  
> wanting to join the DAG (or move around the DAG) I would be more  
> inclined to simply issue a multicast DIS and immediately get the  
> state of my neighbors than to wait around for an undetermined amount  
> of time collecting periodic DIOs.

Since link qualities vary over time, periodic DIOs are important if  
you want nodes already in the DAG to learn better routes and adapt to  
these temporal changes.

--
Jonathan Hui

---

From: Joakim Eriksson <[email-masked]>
Date: Tue, 17 Nov 2009 17:53:00 +0100

> case a new node is awaiting a DIO to join the DAG?

As I understand it node only send if there was too few DIOs sent during
the last period (last interval). This will keep the number of DIO
transmission caused by the Trickle timers fairly low independent of
the node density.

Best regards,
-- Joakim Eriksson, SICS

> have event based DIS/DIOs?  It seems to me that as a new node wanting to 
> join the DAG (or move around the DAG) I would be more inclined to simply 
> issue a multicast DIS and immediately get the state of my neighbors than 
> to wait around for an undetermined amount of time collecting periodic DIOs.
> 
> Jerry
> 
> 
> 
> 
> *Joakim Eriksson <[email-masked]>*
> 
> 11/17/2009 09:20 AM
> 
> 	
> To

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Nov 2009 11:59:09 -0500

>>>>> "Jerald" == Jerald P Martocci <[email-masked]> writes:
    Jerald> I thought nodes always had to send DIOs on trickle timer
    Jerald> expiration in case a new node is awaiting a DIO to join the
    Jerald> DAG?

    Jerald> Has there been any thought of dropping the periodic DIOs now
    Jerald> that we have event based DIS/DIOs?  It seems to me that as a
    Jerald> new node wanting to join the DAG (or move around the DAG) I
    Jerald> would be more inclined to simply issue a multicast DIS and
    Jerald> immediately get the state of my neighbors than to wait
    Jerald> around for an undetermined amount of time collecting
    Jerald> periodic DIOs.

But, doesn't that multicast DIS disturb all the nodes as much as the
multicast DIO reply?  
If the node is snoozing, ideally it has woken up, and will reply.

Maybe one answer is that we should not using the all-routers/all-hosts
multicast groups, but rather we should have new multicast groups for
DIOs and DIS. That would permit nodes not interested in DIS (because
they can only operate as leaves) to filter out the DIS in their hardware
multicast filters... (he says, knowing that likely the simplest hardware
doesn't even have that...)

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 17 Nov 2009 09:03:35 -0800

> transmission caused by the Trickle timers fairly low independent of

Right.  But to address Jerry's follow-on question below, it is  
important to have some lower bound on network-wide DIO transmissions  
to allow the network to adapt to varying link conditions.

>> Has there been any thought of dropping the periodic DIOs now that  
>> we have event based DIS/DIOs?  It seems to me that as a new node  
>> state of my neighbors than to wait around for an undetermined  
>> amount of time collecting periodic DIOs.

--
Jonathan Hui

---

From: [email-masked]
Date: Tue, 17 Nov 2009 11:05:39 -0600

Not sure I buy that.  If I'm not satisfied with my routes, why wouldn't I 
take the lead and issue a DIS as needed?

 It seems to me we should have either a time based algorithm or an event 
based algorithm, but not both.  I could see having both if the time based 
algorithm was used mainly as a heartbeat to assure that the links are 
still in place.  However, if this was the reason, the periodicity of the 
periodic DIOs would be in minutes no milliseconds.

Jerry

Jonathan Hui <[email-masked]> 
11/17/2009 10:41 AM

To
[email-masked]
cc
Joakim Eriksson <[email-masked]>, ROLL WG <[email-masked]>
Subject
Re: [Roll] need clarification: DIS processing

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 17 Nov 2009 09:14:20 -0800

On Nov 17, 2009, at 9:05 AM, [email-masked] wrote:

> Not sure I buy that.  If I'm not satisfied with my routes, why  
> wouldn't I take the lead and issue a DIS as needed?

In most cases, picking routes is based on relative terms (e.g. I chose  
route A because it is better than B, not because B is  
unsatisfactory).  While I may have a working route, how would I  
discover a much better route if one exists?

>  It seems to me we should have either a time based algorithm or an  
> event based algorithm, but not both.  I could see having both if the  
> time based algorithm was used mainly as a heartbeat to assure that  
> the links are still in place.  However, if this was the reason, the  
> periodicity of the periodic DIOs would be in minutes no milliseconds.

Well, "minutes" in some cases is not good enough.  If routes are  
inconsistent or you need to discover a new one, waiting "minutes" to  
discover a new route may not be acceptable.  But sending DIOs on the  
order of "seconds" is also not acceptable in those situations.  Hence  
the need for an adaptive timer.  Note that, for the most part, the  
timer is periodic - but that you can speed it up in certain situations.

This tradeoff between fast and slow periods is nothing new.  Many IP- 
based protocols operate by having a short period when reacting to some  
event and a long period to maintain the network.

--
Jonathan Hui

---

From: [email-masked]
Date: Tue, 17 Nov 2009 11:44:23 -0600

Michael,

Comments interlaced below:

11/17/2009 10:59 AM

To
ROLL WG <[email-masked]>
cc

Subject

No. the multicast DIS is targeted only to the node's neighbors all of 
which need to get this data.  Multicast DIOs on the other hand will go to 
1) the DIS originator who really needs the info, but also 2) to all other 
nodes in its radio range which often times includes nodes that didn't 
receive the original DIS.

NOTE: I am assuming that the DIS/DIO multicasts are all "link local" 
multicasts and hence are only going to devices within direct radio range 
of the transmitting device.  Is this a valid assumption?

That probably won't happen.  Sleeping nodes will be on a periodic timer 
and will likely be completely out of phase with the DIS message 
transmission.  If an application has sleeping routers, there will need to 
be some other means to synchronize the network.  In my application 
(Building Control) all our routers will be powered and hence I won't have 
that headache.

As I see it, all our sensors (temperature, occupancy, light, solar, etc) 
will be hosts positioned as leaves and not even in the DAG.  They will 
sleep.  Some will awake periodically (temp sensors), others on event 
(light switches).  They will forward their data to the nearest DAG router 
destined for their requisite controller await their application ACK and go 
back snoozing.

And yes, none of the devices in the DAG will have any special filtering 
hardware support.  Furthermore, the devices must have zero-configuration 
hence defining special multicast groups is not feasible.

Thanks,

Jerry

                                then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Nov 2009 21:37:38 -0500

>>>>> "Jerald" == Jerald P Martocci <[email-masked]> writes:
    Jerald> As I see it, all our sensors (temperature, occupancy, light,
    Jerald> solar, etc) will be hosts positioned as leaves and not even
    Jerald> in the DAG.  They will sleep.  Some will awake periodically
    Jerald> (temp sensors), others on event (light switches).  They will
    Jerald> forward their data to the nearest DAG router destined for
    Jerald> their requisite controller await their application ACK and
    Jerald> go back snoozing.

By this, I think you mean that they will be on-link with an RPL router,
as a normal IPv6 node.

    Jerald> And yes, none of the devices in the DAG will have any
    Jerald> special filtering hardware support.  Furthermore, the
    Jerald> devices must have zero-configuration hence defining special
    Jerald> multicast groups is not feasible.

The filters I'm talking about have been built into commodity ethernet
MACs since 10Mb/s. (Classic Lance Ethernet chip in a sun2 of 25 years
ago.. has this).  
  So, the filters are not special, it's the normal multicast filters...

  However, there are now many devices that really are just a PHY and a
high speed serial port (which can be USB, ethernet, sometimes even
DVI...), with the rest of the MAC really being implemented in software
and/or firmware (FPGA).  I think the Atmel devices might fall into this
category.  
  I do not what the situation is in Zigbee or 802.11 low cost radios is
though... They must able to some minor bits of filtering though.
  Are we talking about the same issue here?

---

From: JP Vasseur <[email-masked]>
Date: Thu, 19 Nov 2009 09:38:29 +0100

On Nov 16, 2009, at 8:50 PM, Michael Richardson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>

Just bear in mind that we always refer to IP multicast, since we are  
not link layer specific.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBSwGs6YCLcPvd0N1lAQKt/QgAoaq8+YxFPjcDwbZMyl5lfHHpvr+khEdH
> LgGd+8AmdNNfeiINH/369a02FgMuAZQjb1SHGdGsZZcR0JcB5BajalaAJy3VD0yL
> IwfUxGwlaHZrcmJaBkQ5ShHOH4tUizo/9hLar4vEtFu4EGLUaRR5C86VMTdtLs1s
> eUXiDLXhaftjyVhDC8TsYOY92FGdw/cmy8LFXNgCSBVqPgUwOV5t4oo5lngvzhQp
> U5Znba6IvrHmMb4w8m8UIkuKZ1ugaBBQG9/S2a5EAAw+6vBK1x6aHVnxpdQXS5qG
> VnCoxQlYIS5aBY/zPl+/siB8srLkEpKUHlTquVH8Ee0QgncNgdftqg==
> =MCIA
> -----END PGP SIGNATURE-----

---

From: JP Vasseur <[email-masked]>
Date: Thu, 19 Nov 2009 09:43:42 +0100

> likelihood of sending a DIO when the trickle timer triggers next

It is a possible approach (implemented actually on several non IP  
systems), but as pointed out by Jerry the node needs to
process the multicast DIO, keep track of who also sent one, reset  
timers, etc ... which cost in term of energy.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 19 Nov 2009 09:48:04 +0100

On Nov 17, 2009, at 6:14 PM, Jonathan Hui wrote:

> In most cases, picking routes is based on relative terms (e.g. I  
> chose route A because it is better than B, not because B is  
>> event based algorithm, but not both.  I could see having both if  
>> the time based algorithm was used mainly as a heartbeat to assure  
>> that the links are still in place.  However, if this was the  
>> reason, the periodicity of the periodic DIOs would be in minutes no  
>> milliseconds.
>
> order of "seconds" is also not acceptable in those situations.   
> Hence the need for an adaptive timer.  Note that, for the most part,  
> the timer is periodic - but that you can speed it up in certain  
> situations.
>
> based protocols operate by having a short period when reacting to  
> some event and a long period to maintain the network.

Indeed, note that this is why (on a different subject) global repair  
is also a reoptimization mechanism. In many IP protocols you do use  
indeed fast mechanism for immediate actions combined with longer term  
strategies for reoptimization. Repair is one of the notorious examples.

---

From: [email-masked]
Date: Thu, 19 Nov 2009 08:37:19 -0600

Hi JP,

I don't think RPL can simply state 'IP Multicast' as you note below.  As 
Michael mentions there are a) unicasts, b) link-level multicast and c) 
subnet-level multicasts.  He further mentions that on Ethernet link-level 
and subnet level multicasts are the same.  I totally agree with this. 
However, the converse of this is not true; on wireless mesh networks 
link-level multicast and subnet-level multicasts are very different. 

On a 6LowPAN based mesh network for example the link-level multcast domain 
will be simply the nodes within direct radio range of the source; while a 
subnet level multicast domain will cover the entire LLN.  I believe RPL 
has to clearly state the extent of the multicast domain in every case; 
else different implementations may define different multicast domains 
yielding no interoperability.  Furthermore the network traffic patterns 
will be hugely impacted if multicasts cross the entire LLN, when the 
algorithm was meant to be limited to the source's neighbors.

Jerry

JP Vasseur <[email-masked]> 
Sent by: [email-masked]
11/19/2009 02:38 AM

To

>   Kyoto Plus: watch the video <
http://www.youtube.com/watch?v=kzx1ycLXQSE

---

From: JP Vasseur <[email-masked]>
Date: Thu, 19 Nov 2009 15:41:28 +0100

Sorry Jerry I was not clear ... I just wanted to clarify that the term  
multicast is used in an IP context (not referring to the link layer).

On Nov 19, 2009, at 3:37 PM, [email-masked] wrote:

>
> Hi JP,
>
>
> I don't think RPL can simply state 'IP Multicast' as you note  
> below.  As Michael mentions there are a) unicasts, b) link-level  
> multicast and c) subnet-level multicasts.  He further mentions that  
> on Ethernet link-level and subnet level multicasts are the same.  I  
> totally agree with this.  However, the converse of this is not true;  
> on wireless mesh networks link-level multicast and subnet-level  
> multicasts are very different.
>
> On a 6LowPAN based mesh network for example the link-level multcast  
> domain will be simply the nodes within direct radio range of the  
> source; while a subnet level multicast domain will cover the entire  
> LLN.  I believe RPL has to clearly state the extent of the multicast  
> domain in every case; else different implementations may define  
> different multicast domains yielding no interoperability.   
> Furthermore the network traffic patterns will be hugely impacted if  
> multicasts cross the entire LLN, when the algorithm was meant to be  
> limited to the source's neighbors.
>
> Jerry
>
>
>
>
>