Subject: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode)

From: "Daniel Park" <[email-masked]>
Date: Thu, 6 Dec 2007 16:57:18 +0900

This is a tip for understanding and referring how we can fat down NDP for
6lowpan networks. In 16ng working group, we tried to live up with IEEE
802.16 Idle/Sleep mode in conjunction with IPv6 NDP. Here is a RA
optimization results...

Hope those efforts help...

Daniel Park
Co-chair, 16ng working group.

*8.2**.  Router Advertisement*

   The AR SHOULD send a number (configurable value) of router
   advertisements as soon as the IPv6 link is established, to the MS.
   The AR sends unsolicited router advertisements periodically as per
   [RFC4861 <http://tools.ietf.org/html/rfc4861>].  The interval between
periodic router advertisements is
   however greater than the specification in Neighbor discovery for
   IPv6, and is discussed in the following section.

*8.3**.  Router lifetime and periodic router advertisements*

   The router lifetime SHOULD be set to a large value, preferably in
   hours.  This document over-rides the specification for the value of
   the router lifetime in Neighbor Discovery for IP Version 6 (IPv6)
   [RFC4861 <http://tools.ietf.org/html/rfc4861>].  The AdvDefaultLifetime
in the router advertisement MUST
   be either zero or between MaxRtrAdvInterval and 43200 seconds.  The
   default value is 2 * MaxRtrAdvInterval.

   802.16 hosts have the capability to transition to an idle mode in
   which case the radio link between the BS and MS is torn down.  Paging
   is required in case the network needs to deliver packets to the MS.
   In order to avoid waking a mobile which is in idle mode and consuming
   resources on the air interface, the interval between periodic router
   advertisements SHOULD be set quite high.  The MaxRtrAdvInterval value
   specified in this document over-rides the recommendation in Neighbor
   Discovery for IP Version 6 (IPv6)
[RFC4861<http://tools.ietf.org/html/rfc4861>].
The MaxRtrAdvInterval
   MUST be no less than 4 seconds and no greater than 21600 seconds.
   The default value for MaxRtrAdvInterval is 10800 seconds.
_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 6 Dec 2007 00:17:40 -0800

Hi Daniel,

Thanks for the 16ng ND optimization excerpts. The 16ng IPv6-ND and 6lowpan ND
draft share the same idea in this respect. In addition to increasing the router
advertisement interval, it also proposes a choice to avoid periodic RA
alltogether
by using periodic soliciation technique. That way, periodic RA will not wake up
 all the nodes in the 6lowpan.

I see the default value for 802.16 network is about 18min for periodic RAs.

-Samita

On 12/5/07, Daniel Park <[email-masked]> wrote:
> 8.2.  Router Advertisement
>
>    [RFC4861].  The interval between periodic router advertisements is
> 8.3.  Router lifetime and periodic router advertisements
>
>    [RFC4861].  The AdvDefaultLifetime in the router advertisement MUST
>    Discovery for IP Version 6 (IPv6) [ RFC4861].  The MaxRtrAdvInterval

---

From: "Timothy J. Salo" <[email-masked]>
Date: Thu, 06 Dec 2007 16:10:48 -0600

Samita Chakrabarti wrote:
> ... That way, periodic RA will not wake up
>  all the nodes in the 6lowpan. ...

To the best of my knowledge, 802.15.4 implementations power-down
the radio when the system sleeps.  As such, a broadcast packet
does not wake a sleeping 802.15.4 node.  Rather, the packet
is simply never received by the sleeping node.

If my understanding about this behavior is incorrect, someone
please correct me.  I have been meaning to check and see what
the spec says about this, but haven't yet...

Given that the response to broadcast packets differs in 802.16
networks (where an idle node wakes to process the packet) and
802.15.4 networks (where a sleeping node is never even aware
of the packet), different solutions are probably required.

To reiterate what I have said before, I believe that we must
explicitly specify the behavior we expect of multicast in
6lowpan networks that contain sleeping nodes.  In particular,
does multicast mean "received by the potentially very small
percentage of the nodes that aren't currently sleeping" or might
it mean "received by every node after they wake up [whenever
day that might be]"?  After we specify the behavior of multicast,
then we can then try to figure out whether we can actually
implement that behavior in a useful way.

In the interim, I suggest a moratorium on simply assuming that
multicast is a potential solution to any of the challenges
we face (e.g., duplicate address detection, router announcements,
neighbor discovery, ...)

-tjs

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 06 Dec 2007 14:40:21 -0800

Hi Tim, comments in line.

> is simply never received by the sleeping node.

Depends on the link-layer energy management protocol. It is possible to
heavily duty-cycle radio while supporting a broadcast communication.

> the spec says about this, but haven't yet...

This gets back to the question raised in the WG meeting, regarding how
much of the MAC we should assume. The 802.15.4 specification only
defines a limited set of power management mechanisms. As a result, many
commercial implementations and industrial standards built on 802.15.4
forego the defined power management mechanisms. We've been careful so
far to rely only on the frame format and nothing else.

> we face (e.g., duplicate address detection, router announcements,

Why not simply let the particular protocol specification state its 
assumptions about the underlying link? The challenge is that 6lowpan 
links may be configured very differently and solutions may differ 
greatly depending on the operational framework. I'd rather not limit the 
WG to a specific one.

--
Jonathan Hui

---

From: "Timothy J. Salo" <[email-masked]>
Date: Thu, 06 Dec 2007 18:39:58 -0600

> heavily duty-cycle radio while supporting a broadcast communication.

Should I interpret your first sentence to mean: "It depends on
whether the node sleeps?"  If it means more than that, please explain.

I assume that "heavily duty-cycle [the] radio" is an obscure
way of saying "power down the radio". [I like simple,
direct language, evidence to the contrary notwithstanding.]

Do any of the 802.15.4 chips support a "wake on receive"
capability?  Does this capability (assuming it exists)
require that the radio be powered on continuously? That is,
does this capability power-down _only_ the processor, but
not the radio?  Does this capability really save enough
power to meet the needs of many battery-powered, hopefully
long-lived wireless sensor networks?

If this capability actually exists, then we can talk
about whether it is actually useful.

Please provide an outline of how you think broadcast might
work in networks where most of the nodes sleep (really sleep,
as in powering down the radio and most of the microprocessor)
most of the time.  This is an important discussion to start
soon.

> far to rely only on the frame format and nothing else.

Well, I also don't believe that we have yet specified a complete
solution, much less one that works and is useful in common
environments.

Personally, I doubt that we can develop a complete, working,
useful solution without giving more thought to what 802.15.4
capabilities we require or use if they are available.  (Wasn't
that the general conclusion of the working group meeting?
Or, is that still an open question?)

>>   [...]

Well, perhaps for a couple of reasons.

First, we have split the functionality necessary to run IPv6 over
802.15.4 networks across a large number of documents.  If each of
these documents use or require different sets of 802.15.4
capabilities, it will be difficult to figure out whether we
have actually specified a complete solution for a particular
environment (or perhaps even for any environment).

Second, it depends on what our interoperability objective is.
There are a range of opinions about what "interoperability"
actually means.  For some, interoperability means "if you
implement a particular feature, here is how it should be
implemented".  The other view of interoperability focuses
on system-level interoperability.  Under this view, the
objective is "If a system implements the relevant [broad]
standards, this it is assured to interoperate with all
other systems that implement these standards".  A major
problem with the first approach is that it doesn't assure
system-level interoperability.  This is particularly true
when lots of fine-grained standards exist (which is the
direction that the 6lowpan working group seems to be headed
at the moment).  That is, when a vendor can pick one standard
from column 1, one from column 2, etc. for more than a trivially
small number of columns, the chance of systems from different
vendors will interoperate become very small.

Personally, I prefer system-level (rather than a feature-level)
interoperability.  It is possible that we will find that there
are several very different environments that we want to support
(e.g., networks in which nodes sleep versus networks in which
nodes can always receive packets).  And, we may find that these
different environments require different solutions.  If this
the case, I think that we should specify a small number of
solutions that target specific environments, rather than specify
a large number of component technologies that vendors can
combine in various ways to create solutions (which are likely
to be functionally proprietary, in the sense that they don't
interoperate with other vendors' products).

-tjs

---

From: Philip Levis <[email-masked]>
Date: Thu, 6 Dec 2007 18:49:38 -0800

> whether the node sleeps?"  If it means more than that, please explain.

The general point is that the notion of "I send a packet when the  
node is off" assumes a particular energy approach. For example, it  
could be that the sender transmits a long PHY-layer preamble *before*  
the packet, and receivers periodically wake up for a few ms to listen  
for such a preamble. From the transmitter's perspective, this is just  
"sending a packet" but the receiver's radio is asleep, nevertheless  
the packet can arrive successfully.

The assumption is that the link layer provides a broadcast primitive  
that reaches nearby nodes, taking into consideration the power  
management policy. More specifically, the number of nodes reached by  
a broadcast should be independent of the radio duty cycle.

> long-lived wireless sensor networks?

This doesn't work like you think it does. To hear a signal, your  
radio has to be on. The energy cost of demodulation is not the  
principal issue.

> most of the time.  This is an important discussion to start

Node transmits long preamble. Node transmits packet many times.  
Here's a paper in submission that quantifies two approaches on a  
particular 802.15.4 chip. Note that it actually references two other  
approaches (BMAC and XMAC) which are themselves extensions of earlier  
schemes. The author of this paper develops wireless sensor networks  
for various branches of the U.S. government.

http://csl.stanford.edu/~pal/share/spots08.pdf

> solution, much less one that works and is useful in common

You could argue that layer 2 interoperability is outside the scope of  
6lowpan. For example, not all 15.4 devices work on 2.4GHz; I assume  
we aren't trying to get 868MHz and 2.4GHz nodes to interoperate?

Phil

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 06 Dec 2007 18:52:04 -0800

Hi Tim, see comments below:

> whether the node sleeps?"  If it means more than that, please explain.

No, you should interpret it as: "with what schedule does the radio 
enable or disable its receiver".

> direct language, evidence to the contrary notwithstanding.]

Duty-cycle is a generally accepted term to refer to the proportion of
time a device is on or off: http://en.wikipedia.org/wiki/Duty_cycle

> long-lived wireless sensor networks?

Low power listening and time-synchronization are two generally accepted
mechanisms for duty-cycling a radio. Both mechanisms have been shown to
significantly reduce average power consumption (fractions of a percent) 
in a variety of applications.

> about whether it is actually useful.

The capability does exist and is being deployed today.

> most of the time.  This is an important discussion to start

Use low power listening, schedule broadcast slots in a synchronized
protocol, buffer packets at a router. There's a bunch of literature on
this already.

[...]

> interoperate with other vendors' products).

And we do this by first outlining the small number of configurations. 
This is what the architecture ID is trying to do. It outlines a number 
of scenarios and states that different mechanisms may be required 
depending on the operational scenario you're assuming. Sure, the 
architecture ID still needs work, but its a starting point. I believe we 
are in agreement here?

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Dec 2007 11:17:41 +0100

Hi

I tend to agree with Tim here; multicast is a complex issue in the low
power / sleepy space. It's even unclear which WG should be responsible
to define it.
 
Back to basics, there are basically 2 extreme models to locate somebody;
cry out loud or white board. ND on Ethernet uses the first model based
on multicast. Mobile IP uses the second. When you look up a mobile node
on the Home Link, the Home Agent is the reference that responds the ND
requests on behalf of the mobile nodes.

So my question is: Should we take as granted that ND on the LoWPAN
requires multicast? Maybe the white board model based on unicast is
enough, in which case we get rid of a very difficult dependency.
Considering that there is a need for a router that understands 6LowPAN
to connect the LoWPAN to the Internet, that router is the natural
location for a white board.

So the concept of backbone router is this: cry out loud on the high
speed backbone that federates LoWPANs, and white board on the LoWPAN,
and ND proxying to federate the whole thing. The backbone router
implements ND proxying in a fashion that is compatible with mobile IP so
one day, sensors with a global address can move away and stay virtually
there. 

In the meantime, a link local address is enough to connect to any node
in the network federated by backbone routers, and a mote can move from a
backbone router to another within the federated network without
renumbering.

The story begins in
http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router
-00.txt :)

Pascal

>-----Original Message-----
>From: Timothy J. Salo [mailto:[email-masked]] 
>Sent: Thursday, December 06, 2007 11:11 PM
>To: 6lowpan
>Subject: Re: [6lowpan] ND optimization for sensor nodes (power 
>saving/ Idle/Sleep mode)
>
>> ... That way, periodic RA will not wake up  all the nodes in the 
>> 6lowpan. ...
>
>To the best of my knowledge, 802.15.4 implementations 
>power-down the radio when the system sleeps.  As such, a 
>broadcast packet does not wake a sleeping 802.15.4 node.  
>Rather, the packet is simply never received by the sleeping node.
>
>percentage of the nodes that aren't currently sleeping" or 
>might it mean "received by every node after they wake up 
>[whenever day that might be]"?  After we specify the behavior 
>of multicast, then we can then try to figure out whether we 
>can actually implement that behavior in a useful way.
>
>multicast is a potential solution to any of the challenges we 
>face (e.g., duplicate address detection, router announcements, 
>neighbor discovery, ...)
>
>-tjs
>
>
>

---

From: Philip Levis <[email-masked]>
Date: Fri, 7 Dec 2007 10:06:36 -0800

> location for a white board.

The issue here is whether sleep schedules are visible to the network  
layer, or whether it observes longer latency. MACs which do not  
support a "cry out" approach, e.g.,  TDMA with no broadcast slot,  
typically emulate broadcast through unicast to each neighbor for  
which a slot exists. The network layer is not made aware of this, as  
the TDMA schedule will by necessity constrain the set of neighbors  
that you have a "link" to. Or are you assuming mesh under?

> one day, sensors with a global address can move away and stay  

I guess I don't quite understand why you think the whiteboard  
approach is necessary. Can you describe a use case where "cry out"  
doesn't work? The "nodes are off" case seems very suspect to me: if  
nodes are *really* off, e.g., for long, application-level periods,  
you would not expect multicast to reach them. Instead, you would  
depend on higher-layer protocols (e.g., SRM) for improving  
reliability. If nodes are off for very short, link-layer periods, the  
MAC should take care of this. Networks in deployment today tend to  
solely use the latter approach, as it's quite sufficient.

  It might be the best approach for performance reasons, but it may  
not be. The fact that such a tradeoff might depend on the actual  
media access approach used suggests to me that this is something e

> in the network federated by backbone routers,

So this assumes mesh under?

> and a mote can move from a

This is definitely a desirable property.

Phil

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 07 Dec 2007 14:19:44 -0800

Hi Pascal,

The backbone solution proposed in your draft targets a particular 
configuration and we should definitely consider it. Though I strongly 
believe that we are going to see different 6LoWPAN/802.15.4 network 
configurations. There may be some that do not connect to the Internet 
and do not require or cannot afford a router. There may be others that 
choose a route-over approach vs. mesh-under. I just want to reiterate my 
wish that we don't force the WG into a solution space that only covers a 
particular 6LoWPAN/802.15.4 configuration. Instead, we should consider a 
few representative configurations as Tim suggested. While it'd be great 
to see a single solution satisfy all of them, we should be open to 
having different ones if needed.

--
Jonathan Hui

---

From: "Muneeb Ali" <[email-masked]>
Date: Fri, 7 Dec 2007 23:54:14 +0100

> radio has to be on. The energy cost of demodulation is not the

Yes, to hear a signal the radio needs to be on. So "wake on receive" is hard
unless you consider dual radios. The concept of "dual radios" has existed in
theory. A second, always-on, radio can wake up the "main" radio to give you
wake on receive functionality. However, the power consumption of the
always-on second radio will cost you a lot more (in terms of energy)
compared to duty-cycling the "main" radio. Thats why dual radios with
wake-on-receive have largely remained a theoretical concept. See this work
http://www.st.ewi.tudelft.nl/~koen/papers/wakeup-radio.pdf

for a working prototype of a dual radio (EUR 5 per radio) that has
acceptable energy costs in always-on mode. The current problem, however, is
that the range of the wake-up radio is fairly small. Second problem is that
to keep the energy costs low, you will end up with a "bare-bones" radio that
is not even sophisticated enough to do addressing. You end up waking up a
lot of neighbors if you don't know how to address a particular one (don't
know if they have already solved this). Increasing the range while keeping
energy costs acceptable is an on-going work at the startup from where one of
the authors is from.

-- 
Cheers,

Muneeb Ali | http://muneeb.org
_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: "yanzexuan" <[email-masked]>
Date: Sat, 8 Dec 2007 16:17:21 +0800 (CST)

Hi all,
I learned much from u all in the passed one year, it's my hounor to be a member of 6lowpan group, It's a promissing team.
I am leaving school soon, and will no longer work on 6lowpan, so, do any body know how to quit from 6Lowpan group? or, would the admin be kindly to remove me from the member list?
thanks,
yan

From: "Muneeb Ali" <[email-masked]>
To: "Philip Levis" <[email-masked]>
Date: Sat, 8 Dec 2007 06:54:14 +0800 (CST)
Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode)

Phil

Yes, to hear a signal the radio needs to be on. So "wake on receive" is hard unless you consider dual radios. The concept of "dual radios" has existed in theory. A second, always-on, radio can wake up the "main" radio to give you wake on receive functionality. However, the power consumption of the always-on second radio will cost you a lot more (in terms of energy) compared to duty-cycling the "main" radio. Thats why dual radios with wake-on-receive have largely remained a theoretical concept. See this work 
http://www.st.ewi.tudelft.nl/~koen/papers/wakeup-radio.pdf

for a working prototype of a dual radio (EUR 5 per radio) that has acceptable energy costs in always-on mode. The current problem, however, is that the range of the wake-up radio is fairly small. Second problem is that to keep the energy costs low, you will end up with a "bare-bones" radio that is not even sophisticated enough to do addressing. You end up waking up a lot of neighbors if you don't know how to address a particular one (don't know if they have already solved this). Increasing the range while keeping energy costs acceptable is an on-going work at the startup from where one of the authors is from. 

-- 
Cheers,

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 07 Dec 2007 14:49:03 -0700

Since I'm working with Pascal on the Backbone Router (BbR)
draft/concept, I agree and like the idea that if the lowpan is connected
to the internet there will be something like a BbR and it would be a
natural place to  have the "white board".

I don't necessarily agree that multicast for sleepy nodes is really any
more complex than it is for non-sleepy nodes when the underlying network
doesn't support multicast.

My other concern about relying on the BbR for ND type service is if the
network is installed without an Internet connection (or BbR).

	geoff

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 07 Dec 2007 15:07:14 -0700

Tim,
  I think that you have some misunderstandings.

> is simply never received by the sleeping node.
This is not true.  A node that sleeps can receive broadcast packets.  

  - If the broadcast packet is transmitted on some schedule then the
sleeping node can wake up on that schedule and receive the packet.
  - If the broadcast packet is transmitted with some sort of long
preamble then the sleeping node can wake up on it's own schedule, over
hear the preamble and stay awake to receive the packet.
  - If the broadcast packet is transmitted multiple times the sleeping
node can wake up during one of these transmissions and receive the
packet.

This is much like receiving any packet, not just broadcast packets.

> the spec says about this, but haven't yet...

There is nothing in the spec on this.  As far as I know, there are no
15.4 radios that wake on some sort of reception.

> 6lowpan networks that contain sleeping nodes.

No we don't.

>   In particular,
> day that might be]"?  
> After we specify the behavior of multicast,

NO.

---

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 10 Dec 2007 23:04:26 +0530

I tend to agree with Tim that sleeping can potentially be a big issue
for both 6lowpan and more general routing in sensor networks. I do not
think it should be dismissed.

I also think that if 6lowpan does not choose one architectures (e.g.
host-host, router-host, or router-router), it will be difficult to
specify some of the optimizations. For example, ND optimization.

Ian

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 10 Dec 2007 23:02:11 -0700

Ian,
  I'm not sure what you mean by choosing one architecture?

	geoff

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Dec 2007 13:47:29 +0100

Hi Jonathan and Geoff:

This makes sense to me. Now;

The BrB draft is 2 fold; part of it is routing from to the backbone and the Internet; and part of it is white board concept applied to 6LoWPAN. We could separate the features in 2 drafts, but it seems simpler to specify that the implementation of the proxy part towards the backbone be required only when there is a backbone in the first place. 

It also seems that the white board is a good approach regardless of whether we have a backbone or not, considering the very nature of the LoWPAN. We can do a very refined multicast support and try to approach the energy cost and latency that we get with the white board model; but it seems to me that the nearest to that grail we could get, the more states we'd add in nodes all around, and still we'd never get as good as white board. I've no handy proof of this assertion, but I'd be surprised and quite interested to be proven wrong.

Also, it makes sense that the behavior of the motes be the same whether there's a backbone or not; if we recognize the need for the backbone router for a number of supported situations, and if we agree that the white board approach enables the registration for the proxy function transparently, then isn't it the fair approach overall?

In all of the architectures and deployments I've seen, there is always a special box, called a sink, a router, a manager or a gateway, that plays a central role for the LoWPAN. The case when that special box does not exist seems really remote, so we can quite safely assume that the special box exists and is a good candidate for the white board.

Does that make sense?

Pascal

>From: Jonathan Hui [mailto:[email-masked]] 
>Sent: vendredi 7 décembre 2007 23:20
>To: Pascal Thubert (pthubert)
>Cc: Timothy J. Salo; 6lowpan
>The backbone solution proposed in your draft targets a 
>particular configuration and we should definitely consider it. 
>Though I strongly believe that we are going to see different 
>6LoWPAN/802.15.4 network configurations. There may be some 
>that do not connect to the Internet and do not require or 
>cannot afford a router. There may be others that choose a 
>route-over approach vs. mesh-under. I just want to reiterate 
>my wish that we don't force the WG into a solution space that 
>only covers a particular 6LoWPAN/802.15.4 configuration. 
>Instead, we should consider a few representative 
>configurations as Tim suggested. While it'd be great to see a 
>single solution satisfy all of them, we should be open to 
>> Back to basics, there are basically 2 extreme models to locate 
>> somebody; cry out loud or white board. ND on Ethernet uses the first 
>> model based on multicast. Mobile IP uses the second. When 
>you look up 
>> a mobile node on the Home Link, the Home Agent is the reference that 
>> responds the ND requests on behalf of the mobile nodes.
>> 
>> implements ND proxying in a fashion that is compatible with 
>mobile IP 
>> so one day, sensors with a global address can move away and stay 
>> virtually there.
>> 
>> in the network federated by backbone routers, and a mote can 
>move from 
>> a backbone router to another within the federated network without 
>> renumbering.
>> 
>> The story begins in
>> 
>power-down the 
>>> radio when the system sleeps.  As such, a broadcast packet does not 
>>> wake a sleeping 802.15.4 node.
>>> If my understanding about this behavior is incorrect, 
>someone please 
>>> correct me.  I have been meaning to check and see what the 
>spec says 
>>> about this, but haven't yet...
>>>
>>> 802.15.4 networks (where a sleeping node is never even aware of the 
>>> packet), different solutions are probably required.
>>>
>>> explicitly specify the behavior we expect of multicast in 6lowpan 
>>> networks that contain sleeping nodes.  In particular, does 
>multicast 
>>> mean "received by the potentially very small percentage of 
>the nodes 
>>> that aren't currently sleeping" or might it mean "received by every 
>>> node after they wake up [whenever day that might be]"?  After we 
>>> specify the behavior of multicast, then we can then try to 
>figure out 
>>> whether we can actually implement that behavior in a useful way.
>>>
>>> multicast is a potential solution to any of the challenges we face 
>>> (e.g., duplicate address detection, router announcements, neighbor 
>>> discovery, ...)
>>>
>>> -tjs
>>>
>>>
>>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 12 Dec 2007 09:03:50 +0100

Hi Philip

Thanks a bunch for your answers, and sorry for being delayed; please see
inline.

>The issue here is whether sleep schedules are visible to the 
>network layer, or whether it observes longer latency. MACs 
>which do not support a "cry out" approach, e.g.,  TDMA with no 
>broadcast slot, typically emulate broadcast through unicast to 
>each neighbor for which a slot exists. The network layer is 
>not made aware of this, as the TDMA schedule will by necessity 
>constrain the set of neighbors that you have a "link" to. Or 
>are you assuming mesh under?

Yes; I have in mind the following requirements:

- One link throughout (same subnet)
- potentially multiple radio hops (mesh-under)
- potentially a high speed federating backbone (proxy ND)
- one fits-it-all ND solution for motes (no "profile" for ND)

And the multiple radio hops are mesh under in this case. If we used ROLL
all the time then we could assume a model close to the 802.11
infrastructure mode and simplify the problem quite a bit. But there are
already mesh-under approaches that are well-advanced and using 6LoWPAN
so we have to support them as well.

The white board is a clean way to decouple ND from the multicast
problem. Note: I'm not 100% sure that we need to solve the multicast
problem at network level in the mesh-under LoWPAN anyway. For the
specific needs such as upload trigger or software image upgrade,
application level support could be good enough, for instance using RFC
2090 to optimize a download.

Remember that we have this minimum LoWPAN node IPv6 support to define.
If we can avoid multicast stuff like MLD snooping we simplify that
support quite a bit. 

>doesn't work? The "nodes are off" case seems very suspect to 
>me: if nodes are *really* off, e.g., for long, 
>application-level periods, you would not expect multicast to 
>reach them. Instead, you would depend on higher-layer 
>protocols (e.g., SRM) for improving reliability. If nodes are 
>off for very short, link-layer periods, the MAC should take 
>care of this. Networks in deployment today tend to solely use 
>the latter approach, as it's quite sufficient.
>

I'm arguing that we do not need multicast for the specific mission of ND
over LoWPAN and that the white board model saves energy and time even if
we had mesh level multicast support. You need to go through Samita's
draft to see how ND uses multicast and the issues and costs that are
associated to that.

I'm not arguing that multicast can not be done. I'm not convinced it
should be done because I've not seen the requirement docs that prove
that a generic network service is required in the mesh-under space at
least for the applications that are currently envisioned. 

Finally I'm making a difference between multicast and broadcast. If
multicast is actually implemented over a mac level broadcast, that makes
it completely inefficient for the mission at hand (NS, DAD, etc...).
OTOH, if we have mesh-under multicast routing, we save a lot of
bandwidth and latency, and the flows start to compare with white board,
but we add states everywhere for mcast routing we're still not as good
anyway. 

Neither way achieves ND flows faster than white board. White board
enables instant response to DAD within a LoWPAN. Backbone router enables
instant response over the transit even if the node is sleeping. The only
trouble with white board is that it's not fully distributed P2P. Maybe
that's acceptable WRT the benefits in the LoWPAN case.

>  It might be the best approach for performance reasons, but 
>it may not be. The fact that such a tradeoff might depend on 
>the actual media access approach used suggests to me that this 
>is something e
>
>>

Does. That's the model for WiHART and ISA 100.11a. That model is here to
stay, even if the brighter future is ROLL.
I'd concentrate the multicast routing effort in ROLL, reusing well known
techniques, and keep mesh-under simple enough for the missions that it
is currently designed for.

>This is definitely a desirable property.

Yes, the requirement comes from ISA. They want 10K nodes in a single
network. They want a link local address to be valid throughout, and
transparent mobility: the network is thus a single link, and the BbR is
designed with a mobility support that inherits from RFC 3775 - with
slight differences.

Pascal

---

From: "Timothy J. Salo" <[email-masked]>
Date: Wed, 12 Dec 2007 11:07:17 -0600

>   I think that you have some misunderstandings.

Undoubtedly.  However, this broad claim about my lack of
omniscience doesn't appear to be applicable to the issue
that my e-mail raises.

> node can wake up during one of these transmissions and receive the

All you have said is that a sleeping node can receive if
it isn't sleeping.  I don't think that this sort of "Black is
white, (as long as it changes color)" answer does much to advance
the discussion at hand.

By the way, you missed the most interesting solution to this
problem, namely the "indirect transmission" mechanism
specified in the 802.15.4 specification.  See, for example,
section 7.5.6.3 of the 802.15.4-2006 specification.  Note
that 802.15.4 also defines "macTransactionPersistenceTime",
a parameter which specifies the maximum time that a coordinator
must hold onto a packet waiting for an RFD to wake.  (Also,
I think 802.15.4 specifies a minimum queue length of one!)

These schemes have several problems, some of them serious:

o They don't interoperate.  Again, is system-level
   interoperability one of our objectives?  If it isn't, I
   suggest we simply say so.

o They all require a fair amount of energy.  In particular,
   the second approach burns a lot of energy on the transmit
   side (as well as burns channel bandwidth) waiting for all
   of the receive nodes to wake.  Plus, the unlucky receive
   nodes that wake early have to stay awake to receive the
   whole preamble.  And, this scheme pretty much requires
   that all nodes wake pretty regularly.  For most processors,
   simply waking is a time- and energy-consuming task.  Yes,
   some newer microprocessors require less time and energy to
   wake.  But, do we want to hardwire that assumption into
   6lowpan?

o All of these schemes cause multicast to exhibit a latency
   that is nontrivial and not necessarily bounded.  Again, it
   seems to me that we need to say _something_ about the
   expected behavior of multicast in 6lowpan environments.
   Is there a bound on latency (which of course puts an upper
   bound on how long nodes can sleep, and therefore how long
   they can live)?

> 15.4 radios that wake on some sort of reception.

Precisely.  My point is that multicast is different in
802.16 networks (which I understand have a wake-from-idle
capability) and 802.15.4 networks (which don't).  I don't
think that we should simply assume that the 16ng approach
to using multicast is necessarily directly applicable to
6lowpan.  I am suggesting that we actually think about the
issue.

>> 6lowpan networks that contain sleeping nodes.

I continue to disagree.  For example, is there no bound on
how long multicast may take?  Is there an expectation of some
level of reliably reaching every node in the network?
The behavior of multicast in 6lowpan networks _will_ be
different than with traditional media (e.g., latency,
reliability, cost).  It would seem prudent to at least
warn application and protocol developers about this.

>> we face (e.g., duplicate address detection, router announcements,

Battery-powered nodes have a fixed amount of energy.  They
can spend that energy on infrastructure or overhead activities
(like waking up to listen for repetitive RA multicasts) or they
can spend that energy transmitting useful application information.
I think 6lowpan should minimize the energy cost of simply belonging
to a 6lowpan network.  I think that this means eliminating
multicasts that provide no more information than simply "I'm not
dead yet".  For that matter, I suggest that we try to eliminate
the need for the basic 6lowpan infrastructure protocols to use
any multicast.

Having said all that, I understand that "perfect" is often the
enemy of "good enough".  However, I think it would be beneficial
to at least think about what "perfect" might look before declaring
"good enough".

-tjs

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 12 Dec 2007 10:01:43 -0800

Hi Pascal,

Yes, I do see a bunch of cases where BrB and "white-board" may make a 
lot of sense. But, we're drifting a bit from the genesis of this 
discussion. The proposed statement from Tim was to place a moratorium on 
the use of multicast in proposed solutions. My suggestion is that this 
statement is over constraining. One such example where multicast may be 
useful is in route-over networks. Link-local multicast only has a scope 
of a single radio transmission hop and is often done by either 
implementing or emulating broadcast at L2, which most energy-management 
protocols for 802.15.4 support.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 12 Dec 2007 19:15:58 +0100

Hi Jonathan,

I think we're on sync. All I claim is that for the specific purpose of ND over LoWPAN, the white board model is more efficient then multicast; and that the different is most apparent when we're doing multihop (mesh under). I do not want to ban work on multicast. But if we have a preferred solution that do not depend on specific mesh under / mac variation for broadcast/multicast support, it's all the better. If that solution enables scaling with a BbR for no additional control, well, fine.

Pascal

>Sent: mercredi 12 décembre 2007 19:02
>Cc: Geoff Mulligan; Timothy J. Salo; 6lowpan
>Yes, I do see a bunch of cases where BrB and "white-board" may 
>make a lot of sense. But, we're drifting a bit from the 
>genesis of this discussion. The proposed statement from Tim 
>was to place a moratorium on the use of multicast in proposed 
>solutions. My suggestion is that this statement is over 
>constraining. One such example where multicast may be useful 
>is in route-over networks. Link-local multicast only has a 
>scope of a single radio transmission hop and is often done by 
>either implementing or emulating broadcast at L2, which most 
>energy-management protocols for 802.15.4 support.
>
>--
>Jonathan Hui
>
>
>> The BrB draft is 2 fold; part of it is routing from to the 
>backbone and the Internet; and part of it is white board 
>concept applied to 6LoWPAN. We could separate the features in 
>2 drafts, but it seems simpler to specify that the 
>implementation of the proxy part towards the backbone be 
>required only when there is a backbone in the first place. 
>> 
>> It also seems that the white board is a good approach 
>regardless of whether we have a backbone or not, considering 
>the very nature of the LoWPAN. We can do a very refined 
>multicast support and try to approach the energy cost and 
>latency that we get with the white board model; but it seems 
>to me that the nearest to that grail we could get, the more 
>states we'd add in nodes all around, and still we'd never get 
>as good as white board. I've no handy proof of this assertion, 
>but I'd be surprised and quite interested to be proven wrong.
>> 
>> Also, it makes sense that the behavior of the motes be the 
>same whether there's a backbone or not; if we recognize the 
>need for the backbone router for a number of supported 
>situations, and if we agree that the white board approach 
>enables the registration for the proxy function transparently, 
>then isn't it the fair approach overall?
>> 
>> In all of the architectures and deployments I've seen, there 
>is always a special box, called a sink, a router, a manager or 
>a gateway, that plays a central role for the LoWPAN. The case 
>when that special box does not exist seems really remote, so 
>we can quite safely assume that the special box exists and is 
>a good candidate for the white board.
>> 
>> Does that make sense?
>> 
>> Pascal
>>  
>> 
>>> configuration and we should definitely consider it.
>>> 6LoWPAN/802.15.4 network configurations. There may be some that do 
>>> not connect to the Internet and do not require or cannot afford a 
>>> router. There may be others that choose a route-over approach vs. 
>>> mesh-under. I just want to reiterate my wish that we don't 
>force the 
>>> WG into a solution space that only covers a particular 
>>> 6LoWPAN/802.15.4 configuration.
>>> Instead, we should consider a few representative configurations as 
>>> Tim suggested. While it'd be great to see a single solution satisfy 
>>> all of them, we should be open to having different ones if needed.
>>>
>>> --
>>> Jonathan Hui
>>>
>>>
>http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-rou
>>> t
>>>> er
>>>> -00.txt :)
>>>>
>>>> Pascal
>>>>  
>>>>

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 12 Dec 2007 10:35:48 -0800

>   suggest we simply say so.

Hasn't the IETF traditionally concerned itself with interoperability at 
L3 and above? 802.15.4 links with different configurations are logically 
different links as stated in the architecture ID. I don't think this WG 
should be worried about interoperability between arbitrary link layers 
simply because they utilize a radio with 'IEEE 802.15.4' in its 
datasheet. Note that just because a radio may be IEEE 802.15.4 
compliant, doesn't mean it can communicate with any arbitrary IEEE 
802.15.4 radio. There may be differences in frequency (2.4 GHz, 916 MHz, 
868 MHz), modulation (BPSK, ASK, O-QPSK), baudrate (20, 100, 250 kbps). 
Then there's IEEE 802.15.4-2006 vs. 802.15.4a vs. the 
currently-in-progress 802.15.4e. I'd be surprised if the 
energy-management mechanisms in 802.15.4-2006 are at all compatible with 
802.15.4e. Note that there are commonalities in all of this (addressing, 
frame format, etc). I don't think it is in the best interest of this WG 
to pick a single slice and say we will develop solutions that address 
only that one slice.

--
Jonathan Hui

---

From: "Timothy J. Salo" <[email-masked]>
Date: Wed, 12 Dec 2007 13:35:51 -0600

Jonathan Hui wrote:
> Hasn't the IETF traditionally concerned itself with 
> interoperability at L3 and above?

I think there is no question that 6lowpan is breaking new
ground within the IETF.  As far as I know, this is the first
IETF Working Group that intends to specify a layer-two
routing solution.  (Yes, yes, I know.  We could claim that
it is actually "mesh under routing" or layer 2.5 routing, or
layer 2.3457 routing.  But nonetheless, 6lowpan intends to
specify a routing solution that operates on link-layer
addresses.  And, I think this is unique within the IETF.)

Given that 6lowpan is already working on a layer-two routing
solution (no matter what you call it) it seems to me that
we have created a strong argument that, at least in some
environments, it is important to think about how things
should be done below layer three.  This should permit us
to think about layer-two issues that we think may be important.

> I don't think this WG 

Well, dramatic as you try to make it sound, these parameters can't
be selected independently.  Customers in ITU Region 2 have about
two choices:

o 2.450 GHz / 250 kbps / O-QPSK
o 915 MHz / 40 kbps / DSSS with BKSK

I think 868 MHz operation is only permitted in Europe (but I think
915 MHz ISM operation is restricted to ITU Region 2, which doesn't
include Europe).  Interestingly, I believe that devices operating in
the 868 MHz ISM band [in Europe] are permitted to operate at only a
1% duty cycle.

So yes, customers may, depending where they are, have as many as
_two_ (not the 36 you seemed to be trying to lead us to believe)
incompatible physical layer choices.  (Although which two choices
customers have varies by geographic, or more precisely ITU, region).

Correct me if I am wrong, but you appear to be arguing that because
the 802.15.4 spec offers customers two choices, then the IETF should
make no effort to ensure system-level interoperability.  I am not
convinced that this is the right answer (or the right reasoning).

By the way, I am glad to see your support for the notion that
6lowpan is targeting 802.14.4 _networks_, rather than 802.15.4
_radios_.  This permits us to at least consider making use
of 802.15.4 functionality that might not be implemented in
802.15.4-compatible chips.

-tjs

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 12 Dec 2007 12:50:12 -0800

> addresses.  And, I think this is unique within the IETF.)

Really? There is nothing in the proposed charter that suggests we will 
develop a mesh under routing solution. If you remember at the 69th IETF, 
we did come to an agreement that we would not develop a mesh-under 
solution at this time. The only related proposal is to develop 
*requirements* for such a mesh under solution which could be defined 
outside the IETF.

[...]

> customers have varies by geographic, or more precisely ITU, region).

You haven't addressed my concerns about the variants of IEEE 802.15.4 
(a, e, 2006). I also forgot to include ISA, which is developing their 
own 802.15.4 configuration, utilizing frequency agility and time 
synchronization. Should we ignore them too? The issue is that 
802.15.4-2006 specifies only a limited set of energy-management 
mechanisms, which are often not satisfactory in a large number of 
applications. For example, there is no provision for energy-constrained 
FFDs. This is precisely the reason why there are new energy-management 
protocols being defined for 802.15.4. Furthermore, what about support 
for route-over which would be useful for ROLL (if it forms)? Are you 
ready to say that link-local multicast should never be used? How do you 
plan on discovering your neighbors at L3? The WG currently does not 
assume a particular configuration and I believe there is support to keep 
it that way.

> convinced that this is the right answer (or the right reasoning).

It all depends on what's included in your 'system'. If you expect 
802.15.4-2006, ISA100.11a, 802.15.4e to all interoperate using the exact 
same network-layer mechanisms, then good luck. You might get 2 of the 3, 
but I highly doubt you'd get all three.

> 802.15.4-compatible chips.

Yes, I am promoting networks. The issue is that just saying 802.15.4 
does not define the network.

--
Jonathan Hui

---

From: Philip Levis <[email-masked]>
Date: Thu, 13 Dec 2007 12:23:56 -0800

On Dec 12, 2007, at 9:07 AM, Timothy J. Salo wrote:
>>>
>> This is not true.  A node that sleeps can receive broadcast  
>> packets.    - If the broadcast packet is transmitted on some  
>> schedule then the

Geoff's point is that while the nodes sleep, you schedule and  
structure communication such that this does not prevent receiving  
packets. Numerous products, protocols, and systems have shown you can  
achieve very low duty cycles while still maintaining connectivity.

Phil