Subject: [Roll] definition of sleepy node

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jan 2013 09:44:02 -0500

The security-threats documents makes reference to "sleepy node", and
we do not have a definition of it in terminology-09.txt.  Does someone
have a good definition for such a thing?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: "Gillmore, Matthew" <[email-masked]>
Date: Tue, 22 Jan 2013 08:16:08 -0800

Michael,

How about this: "An energy constrained device that operates in a limited capacity to conserve energy."

I hesitate to explicitly state battery operated because the device may not have a battery at all.

Thanks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, January 22, 2013 9:44 AM
To: [email-masked]
Subject: [Roll] definition of sleepy node

The security-threats documents makes reference to "sleepy node", and we do not have a definition of it in terminology-09.txt.  Does someone have a good definition for such a thing?

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 22 Jan 2013 17:47:00 +0100

Hi Michael,

Sleepy node: is a node that stops transmitting and receiving messages.
This node still may partialy process or maintain needed information
within the sleep mode.

I still think that it is just a start definition may another thought
to be better written, please advise,

AB

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jan 2013 12:21:43 -0500

okay, how about:

sleepy node:

"An energy constrained device that has a sleep / wake cycle such that
it is asleep more often than it is awake.  It does this to conserve
energy.   A node can not transmit or receive messages while sleepy, but
can maintain state.  A sleepy node usually sleeps and wakes according to
a set schedule.  The sleep/wake cycle of an entire LLN usually needs to
be coordinated so that transmitters are sending while receivers are
awake the receive."

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 22 Jan 2013 19:18:52 +0100

Hi Michael,

Yes, I like the definition, thanks,

AB

On 1/22/13, Michael Richardson <[email-masked]> wrote:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Gillmore, Matthew" <[email-masked]>
Date: Tue, 22 Jan 2013 10:26:13 -0800

Please consider a friendly amendment to the last sentence

"A sleepy node usually sleeps and wakes according to a set schedule.  The sleep/wake cycle of an entire LLN usually needs to be coordinated so that transmitters are sending while receivers are awake to receive.

"To" instead of "the"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, January 22, 2013 12:22 PM
To: [email-masked]
Subject: Re: [Roll] definition of sleepy node

okay, how about:

sleepy node:

"An energy constrained device that has a sleep / wake cycle such that it is asleep more often than it is awake.  It does this to conserve
energy.   A node can not transmit or receive messages while sleepy, but
can maintain state.  A sleepy node usually sleeps and wakes according to a set schedule.  The sleep/wake cycle of an entire LLN usually needs to be coordinated so that transmitters are sending while receivers are awake the receive."

---

From: [email-masked]
Date: Tue, 22 Jan 2013 12:33:22 -0600

Michael,

Some sleepy nodes are periodic, some
aperiodic.

For periodic nodes (e.g. a temperature
sensor), although it awakens on a set schedule, it may not transmit and
receive on a set schedule.  A temp sensor may awaken each minute to
sense the ambient temperature.  If it hasn't changed since its last
transmission, it may go back to sleep without transmitting or receiving.

Aperiodic devices (e.g. a light switch)
may only access the network when the light switch is depressed.

Your definition implies to me that sleepy
nodes will have a set accessibility time on the network.  This is
not true.

Jerry

From:

Abdussalam Baryun <[email-masked]>

To:

Michael Richardson <[email-masked]>

Cc:

[email-masked]

Date:

01/22/2013 12:19 PM

Subject:

Re: [Roll] definition of sleepy node

Hi Michael,

AB

On 1/22/13, Michael Richardson <[email-masked]> wrote:

Roll mailing list

[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jan 2013 13:48:00 -0500

sleepy node:

"An energy constrained device that has a sleep / wake cycle such that it
is asleep more often than it is awake.  It does this to conserve 
energy.   A node can not transmit or receive messages while sleepy, but
can maintain state.  

A sleepy node may sleep and wakes according to a set schedule, or it may
wake as a result of external stimulous.  The sleep/wake cycle of an
entire LLN usually needs to be coordinated so that transmitters are
sending while receivers are awake to receive."

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 22 Jan 2013 19:49:38 +0100

Hi  Jerry,

It says *usually* not always. However, could you suggest a modify
text, or your opinion definition,

AB

On 1/22/13, [email-masked] <[email-masked]> wrote:
>
> Michael,
>
> Some sleepy nodes are periodic, some aperiodic.
>
> For periodic nodes (e.g. a temperature sensor), although it awakens on a set
> schedule, it may not transmit and receive on a set schedule.  A temp sensor
> may awaken each minute to sense the ambient temperature.  If it hasn't
> changed since its last transmission, it may go back to sleep without
> transmitting or receiving.
>
> Aperiodic devices (e.g. a light switch) may only access the network when the
> light switch is depressed.
>
> Your definition implies to me that sleepy nodes will have a set
> accessibility time on the network.  This is not true.
>
> Jerry
>
>
>
>
> From:
> ________________________________
>
>
>
> Hi Michael,
>

---

From: [email-masked]
Date: Tue, 22 Jan 2013 12:59:14 -0600

You wrote:

The sleep/wake cycle of an

sending while receivers are awake to receive.

This may be proper for an entire sleepy LLN, that
sleeps and wakes together, but

their is also the case where individual nodes sleep
and the LLN stays active.  In this case,

aperiodic sensors ( temperature
and others)  may transmit and receive at different times / relative
to each other, would it

not be better in this case to state
that each 'parent' synchronize transmitters to their respective sleeping
children, for this type of network?

We are discussing two different
type of sleepy architectures that behave differently with respect to their
waking characteristics.

Consider for sleepy nodes (not applicable
for sleepy LLNs)

The sleep/wake cycle of

each parent usually needs to be coordinated their children, so that the
parents

transmitters are sending while receivers are awake
to receive.

Ted

From:

Michael Richardson <[email-masked]>

To:

[email-masked]

Date:

01/22/2013 12:48 PM

Subject:

sleepy node:

it

energy.   A node can not transmit or receive messages while sleepy,
but

can maintain state.

--

[attachment "att3aq77.dat" deleted by Ted Humpal/CORP/Johnson_Controls]
_______________________________________________

Roll mailing list

[email-masked]

---

From: "Timothy J. Salo" <[email-masked]>
Date: Tue, 22 Jan 2013 13:06:27 -0600

I suggest that the definition of a sleepy node not include prescriptions
about how networks ought to be designed to accommodate nodes that
sleep.  I also suggest that the definition encompass the broadest range
of nodes that sleep.

Here is my attempt.  It's still not right, but perhaps some of the
language might be of use.

   A "sleepy node" is a device that episodically [from time-to-time]
   puts itself in a low-power, quiescent state, or "sleeps".  While
   sleeping, these devices cannot perform major functions, such as
   transmitting packets, receiving packets or performing computations.
   Often, these devices wake on the expiration of a timer, although
   some devices are capable of waking in response to an external event.
   A sleep state differs from a power-down state in that most device
   state is preserved; therefore, the transition from a sleep state to
   an operating state requires much less time than does booting from a
   powered-down state.  Generally, these devices sleep to conserve
   energy.  For example, battery-powered devices may sleep in order to
   extend their lifetimes.

- - - -

> it is asleep more often than it is awake.

A node that sleeps only 49% of the time ought to be considered a sleep
node, (in my view).  It presents the same problems to the design of
network protocols.

> A node can not transmit or receive messages while sleepy, but
> can maintain state.

The issue of preserving state gets complicated: the amount of state
that is preserved varies between devices, and some devices have
several sleep states that preserve different amounts of state.  And,
it is possible to preserve state across reboots.  I tried to cast
state preservation in terms supporting "waking", which is much
less dramatic than booting.  But, a protocol ought not care
whether a device wakes or boots.

(Actually, there are a whole range of energy-saving strategies.  Even
what I wrote probably conflicts with some strategies, such as shutting
down major subsystems, but keeping a processor awake; keeping only a
small processor alive, put putting the main processor to sleep; or
reducing the processor clock rate, but keeping the processor alive.)

(I believe that some devices can wake on the receipt of a packet.  But,
this probably isn't of much use with the typical LAN/PAN chips, where
receiving is expensive, and often requires almost as much power as
transmitting!)

> A sleepy node usually sleeps and wakes according to
> a set schedule.

Devices may also wake in response to external events.  I hope that
ROLL can accommodate these devices...

> The sleep/wake cycle of an entire LLN usually needs to

This sounds overly prescriptive to me.  In some systems, some nodes may
not be energy constrained, and so are capable of listening continuously.
These non-sleeping nodes may respond to sleeping nodes that wake
asynchronously.  Actually, I think these sorts of systems are pretty
common.  It is not clear to me that this less-synchronous behavior is
included in: "The sleep/wake cycle of an entire LLN usually needs to be
coordinated".

I don't think that a protocol should require that all devices in a
network have the same sleep cycle.  For example, some nodes ought to
be permitted to sleep for a long time, while other nodes may wake more
often.  Plus, the clocks in many of these devices are so crummy that a
node that sleeps for a long time is no longer synchronized with the
rest of the network.

Sleeping, and how sleep cycles are or aren't coordinated have
implications about whether broadcast or multicast have any meaning...

But mostly, I suggest that a prescription about how a network protocol
ought to handle sleeping nodes not be included in the definition of
a sleepy node.

Again, I hope this helps,

-tjs

---

From: "Bogliolo, Alessandro" <[email-masked]>
Date: Tue, 22 Jan 2013 20:26:17 +0100

2013/1/22 Timothy J. Salo <[email-masked]>

> sleep.  I also suggest that the definition encompass the broadest range

I fully agree.

Also, based on a background on wireless sensor networks and dynamic power
management,
I would suggest to see as a distinguishing feature of a sleepy node the
availability of a low-power
inactive state that can be entered to save energy while maintaining state
information and
some reactivity to timeouts (self wake ups) and external events.

A.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jan 2013 15:53:19 -0500

Please be aware that the definition of sleepy node need not be 
pendantically precise.  The purpose of the glossary of terms is
mostly so that when discussing LLNs with non-LLN network specialists
that we give them an idea what this could mean, not that we find do
LLN taxonomy.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 23 Jan 2013 01:31:04 +0100

> sleep.  I also suggest that the definition encompass the broadest range

I agree that we make it simple not confusing, define sleeping node NOT
sleeping network. Or we can separate definitions Sleepy Node, and
Sleepy LLN, and if Sleepy LLN is long then make another separation,

I need to sleep, good night :)

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 23 Jan 2013 01:36:29 +0100

+1

AB

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Thu, 31 Jan 2013 10:42:00 +0000

Seems like we have a consensus for:

Sleepy Node
A sleepy node is a node that may sometimes go into a sleep mode (i.e. go into a low power state to conserve power) and temporarily suspend protocol communication.  A sleepy node may also sometimes remain in a fully powered on state where it has the capability to perform RPL protocol communication.

Non-Sleepy Node
A non-sleepy node is a node that always remains in a fully powered on state (i.e. always awake) where it has the capability to perform RPL protocol communication.

Added to draft-ietf-roll-terminology-10.

Thanks.

JP.

On Jan 22, 2013, at 4:36 PM, Abdussalam Baryun wrote:

+1

AB

On 1/22/13, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 31 Jan 2013 11:58:41 +0100

+1

AB

On 1/31/13, JP Vasseur (jvasseur) <[email-masked]> wrote:
> A sleepy node is a node that may sometimes go into a sleep mode (i.e. go
> into a low power state to conserve power) and temporarily suspend protocol
> communication.  A sleepy node may also sometimes remain in a fully powered
> on state where it has the capability to perform RPL protocol communication.
>
>
> Non-Sleepy Node
> A non-sleepy node is a node that always remains in a fully powered on state
> (i.e. always awake) where it has the capability to perform RPL protocol
> communication.
>
>
> On 1/22/13, Michael Richardson
> <[email-masked]<mailto:[email-masked]>> wrote:
>