Subject: [6lowapp] Next version of charter proposal up on 6lowapp.net

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Nov 2009 11:06:51 +0100

I have put a new version of the WG charter proposal on the wiki page at
http://6lowapp.net
=
http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp
(charter text is at the end of the page).

Obviously, I could not pick up every comment that was on the list  
(they were partially going in conflicting directions), but please do  
comment on the new version.

Gruesse, Carsten

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 5 Nov 2009 11:03:34 -0500

I plan to finish reading through all the email archives before the
6lowapp meeting, so this is the last time I'll apologize for not having
complete context.

There seems to be a wide divergence of opinion on the meaning of
"constrained", from full-on WS* to unable to contain any strings.  I would
offer a working definition, borrowed from Einstein, that CoNodes should
be "as simple as possible, but no simpler."

I believe that by moving as much functionality as possible from the
CoNodes into the CoGII nodes, we end up with a lower total system cost
and, ultimately, greater ubiquity. The definition of CoNode should admit
wired (e.g. power line connected) as well as wireless Devices.

As a general approach to foster consensus, I'd suggest the WG might
add to its "objectives and architecture" document a specification of
which services must be present in a CoNode and which must be
present in the CoGII node (and how the CoGII node differs from a
ROLL node; e.g. where does header de/compression reside?)

I support the viewpoint that a collection of CoNodes should be able to
implement some non-trivial applications without requiring a CoGII
node (e.g. the "one light, one switch" scenario).  Others may disagree
with this (perhaps even strongly) but I believe statements of this sort
will help focus the debate and lead to the the ultimate meaning of
"constrained".

I personally find it easier in the early stages to think in terms of abstract
services rather than specific protocols.  For example, "BACnet relies on
the ability to enumerate all the devices on the network and to query the
value of objects within a device."  The first is accomplished using the
"Who-is" or "Who-has" services (indeed, one might argue that having
two such mechanisms runs counter to interoperability) while the second
is accomplished using the "ReadProperty" service.  If we can reach
consensus on which services we need then mapping to specific
implementations might be easier.

Lastly, might I suggest using in the charter "CoNet" in place of "CNN"?

Respectfully submitted, Kerry Lynn

On Thu, Nov 5, 2009 at 5:06 AM, Carsten Bormann <[email-masked]> wrote:
> Obviously, I could not pick up every comment that was on the list (they were
> partially going in conflicting directions), but please do comment on the new
> version.
>
> Gruesse, Carsten
>
> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp
>

---

From: Arjun Roychowdhury <[email-masked]>
Date: Thu, 5 Nov 2009 11:30:36 -0500

> be "as simple as possible, but no simpler."

ARC> agree.

> wired (e.g. power line connected) as well as wireless Devices.

ARC> This is usually the same argument for a network full of
'interoperability gateways' though (and the core principle of dumb nodes,
intelligent networks). The problem with heavy reliance on CoGII is that
while it results in short term low system cost, over a longer term, these
CoGII elements become single point of failures, complicate network
management and make the end-end architecture brittle. Pushing functionality
by default to CoGII also results in quicker architecture and deployment -
but in the longer run, we have a system that is full of technology islands
patched together with frail bridges.

So the CoGII approach, to me, really should be "as few as possible and no
more"

> will help focus the debate and lead to the the ultimate meaning of

ARC> +1

> implementations might be easier.

ARC> +1

> --
Arjun Roychowdhury

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Nov 2009 17:35:52 +0100

> (charter text is at the end of the page).

Some feedback from a quick read of the charter text.

--

I have not clue what this means:

   [...] For these benchmark cases, the
   payload will be based on interface profile specific XML documents
   compressed with EXI.

Which benchmark cases is this text referring to? And why suddenly fix
a certain encoding?

--

I also do not understand the relationship of 4a) to 4). Since 4) talks
specifically about HTTP REST, how can 4a talk about non HTTP REST
protocols? I think 4) should say:

4) Specification how other protocols interface via a CoGII to CoAP.
   Separate specifications are envisioned zero or more of: SNMP, SMTP,
   SIP, and XMPP. [[Note: In the BOF it would be nice to figure out
   which of these are in the charter.]]

--

I find the text on various commissioning methods rather strange for
the charter of a working group. A working group charter item can be
the production of a BCP on commissioning methods. The current text
more looks like the initial draft of such a BCP, which does not belong
into a charter.

--

   CoAP will use CMS for object security. [...lost of more detail...]

This again looks like prescribing the solution - are we sure we do
understand that CMS is the right choice? Are we sure we understand how
CMS object security maps to other protocols mentioned under 4) and
that CoAP is supposed to interface to? Do we understand the overhead
of CMS security for say a simple meter reading? It might be better to
have a charter item to work on the security aspects and it might be
good to have security area advisors involved in this from the very
beginning.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Zach Shelby <[email-masked]>
Date: Thu, 5 Nov 2009 23:05:24 +0200

I agree, it should be removed. The EXI was mentioned there as a  
benchmark for payload sizes (not to fix anything), but that doesn't  
make sense either. I think the overhead goal should be more explicit  
there instead of talking about benchmarks. Now it says "enabling a  
50-70 byte payload".... considering what? I assume a 50-70 payload  
after IEEE 802.15.4 + 6LoWPAN  + UDP + CoAP without LoWPAN  
fragmentation.... without security. Or should we just say CoAP should  
aim at a header overhead of less than 10 bytes for simple cases  
without security?

Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain  
legally privileged information. If you are not the intended recipient,  
please contact the sender and delete the e-mail from your system  
without producing, distributing or retaining copies thereof.

---

From: Zach Shelby <[email-masked]>
Date: Thu, 5 Nov 2009 23:23:50 +0200

> be "as simple as possible, but no simpler."

+1.

We are trying to enable the minimal features required by the targeted  
application domains, while integrating that with the web architecture  
the best we can. So I like your saying. Let me add another - "keep it  
simple, stupid".

> wired (e.g. power line connected) as well as wireless Devices.

Coogies (CoGII) are not required at all in the charter (nor should  
they be), in fact they are only necessary for interconnecting the CoAP  
framework with HTTP or other possible paradigms. CoAP is meant to work  
totally stand-alone between embedded devices, between devices and  
servers etc. So the goal is to keep it really simple, as we can't  
assume there is anywhere to move functionality to.

Now that said, there are useful things CoNodes (I kindof like that)  
may use a Coogie for, but those are performance improvements. For  
example you may cache profiles there.

> ROLL node; e.g. where does header de/compression reside?)

Node speaking CoAP need to be totally autonomous, this is a must for  
these application areas. Coogies provide proxying to HTTP, possible  
caching for requests from the rest of the Internet etc.

Coogies operate at L5, and can be located just about anywhere. Sure,  
it may sometimes be running on the same device which operated as a  
LoWPAN Edge Router and/or LLN Border Router. More likely it is placed  
at the edge of the constrained domain, e.g. on the gateway router of  
the building automation IP network, or the AMI infrastructure etc.

Does that make sense from the charter? Ideas and making it more  
specific?

> implementations might be easier.

Abstract services are what the charter is going after, we are not  
specifying how the protocol itself is to be realized yet.

> Lastly, might I suggest using in the charter "CoNet" in place of  

I get a TV feeling from CNN myself.... So you are thinking CoNode and  
CoNet?

Zach

>> (they were

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Robert Cragie <[email-masked]>
Date: Fri, 06 Nov 2009 14:25:39 +0000

Some comments on the charter.

    * Generally, I like bullet points for clarity
    * Para 1 could do with a more bullet points. Suggested change:

        "Applications are being developed for networks where a
        substantial number of nodes:

        * Use very limited packet sizes
        * Have limited range
        * Exhibit a high degree of packet loss
        * Have restrictions on available power budget
        * May be powered off at any point in time but periodically "wake
        up" for brief periods of time
        * Have restrictions on the complexity that can be supported due
        to limited code size and limited RAM

        More generally, we speak of constrained-node/network (CNN)
        applications whenever at least some of the nodes and networks
        involved exhibit these characteristics.  This WG is
        concentrating on requirements from energy (e.g. Smart Energy
        2.0) and building management applications."

    * +1 for CoNet
    * +1 for CoNode. The idea of a "CoNode" makes more sense than a
      CoNet. It is possible to imagine a CoNet with nodes which don't
      have all the properties of a CoNode and thus could communicate
      using a different application protocol, i.e. one more familiar to
      the wider Internet (e.g. WS-*, HTTP REST). Do we only want to
      consider a CoNet containining CoNodes? If so, these non-CoNodes
      are probably out of scope of the discussion.
    * Para 2: "are becoming increasing important" -> "are becoming
      increasingly important"
    * Para 2: "a framework a limited class of applications" -> "a
      framework for a limited class of applications"
    * Para 3 could do with more bullet points. Suggested change:

        "The general architecture consists of nodes on the CNN, called
        Devices, that have one or more Resources that may represent
        sensors and actuators or other parameters.

        * Devices send messages to change Resources on other Devices
        * Devices send messages to query Resources on other Devices
        * Devices can send notifications about changed Resource values
        to subscribed Devices.

        In other words, the architecture requires push, pull and a
        notify approach to manipulating Resources.

        As part of the framework for building these applications, the WG
        will define a Constrained-node/network Application Protocol
        (CoAP) for manipulation of Resources on Devices. The framework
        will also specify a way to define new interface profiles that
        can be defined by vendors and other standards bodies to define
        the particular Resources on a Device and what manipulation is
        possible."

    * Should Device be CoDevice (i.e. CoNode + application functionality)?
    * "CoAP will be designed to be used between Devices (intra- or
      inter-CNN) as well as between Devices and general nodes on the
      Internet.". This suggests that we are defining an application
      protocol which would be suited to the wider Internet. However,
      then there is the introduction of the CoGII. This brings me back
      to my earlier post regarding intersection - are we trying to
      achieve this? Or is the CoAP really aimed at CoNodes only? In this
      case, the description as is of the CoGII is about right, i.e. an
      application layer gateway.
    * If we are considering a CoNet with CoNodes and non-CoNodes, there
      could also be a more general router between the non-CoNodes and
      the wider Internet using a different application protocol (e.g.
      WS-*, HTTP REST)
    * I agree with other comments re. specifiying EXI - not necessary
      for the purposes of the charter. State the requirement and in
      development state that EXI would meet the requirement
    * I think if you have the notion of the CoGII you can really come up
      with any binding you want so whilst I think HTTP REST may be the
      most important, others should become second-class citizens at this
      stage.
    * Commissioning methodologies. Whilst important, the suggestions
      seem to me too specific
    * Duckling mode general procedure is quite specific but the details
      are vague. Imprinting a shared secret seems like some sort of
      magic the way it is described
    * Out-of-band key mode. Too specific with regard to barcodes/URLs.
      There are many ways to set up a shared secret out-of-band
    * Certificate mode. Again, too specific with regard to barcodes and
      certificate replacement. Other issues need to be considered with
      certificates too (authentication, revocation etc.)
    * "In all modes, once Device A and Device B have formed a secure
      connection with Device C, Device C can be used to transitively
      introduce A and B so now A and B have a secure connection with C."
      I don't quite get this statement - should it say "so now A and B
      have a secure connection with each other"?
    * The use of a heavyweight syntax such as CMS (rfc5652) seems at
      odds with the aims of CoAP. In conjunction with a CoGII, there may
      be no need for such protection - symmetric key frame protection
      such as AES-CCM may well suffice.

In summary, my main question is: Do we want to limit the CoNet to just 
CoNodes and a (optional) CoGII? Is it enough to acknowledge that there 
will be another non-CoNode application protocol, which is suitable for 
some nodes in, say, 6LoWPAN, i.e. those with enough horsepower, power 
budget, link reliability to be able to natively handle RESTful HTTP/TCP?

Robert

---

From: Benoit Claise <[email-masked]>
Date: Mon, 09 Nov 2009 03:20:21 +0100

Carsten,

Thanks for the new charter proposal. 

- "This WG is concentrating on requirements from energy (e.g. Smart Energy 2.0) and building management applications."
Is the goal to describe these requirements in the "objectives and architecture" document?
If not, where can we understand those requirements from? 
The following were mentioned on the list:

    There are a lot of use cases to start with.  Here is a starter set:
    1)  OpenHAN:
    http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20-%20v1.04%20-%200808
    19-1.pdf
    2)  SmartGridipedia:
    http://www.smartgridipedia.org/index.php/Category:Use_Cases, both the
    Intelligrid and Southern California Edison use cases are good
    3)  ZigBee/HomePlug Market Requirements and Use Cases (which we are using
    for our Smart Energy V2 work):
    http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf 

Any other ones?

"The framework will also specify specify a way to support interface profiles, ..."
Can you expand on "interface profile".

"A document with operation and management advice about running a network using these applications."
Is advice the right word? It seems like one or two advices are sufficient to manage the network ;-)

Regards, Benoit.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 8 Nov 2009 21:32:51 -0500

I find this conflation of Smart Energy/HAN and LowApp confusing. Most  
of the in-home networks are not exactly "challenged". Even ZigBee has  
250 kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent  
to early DSL or 1990's modems.

Henning

On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote:

> - "This WG is concentrating on requirements from energy (e.g. Smart  
> Energy 2.0) and building management applications."
>> (they were partially going in conflicting directions), but please  
>> do comment on the new version.
>>
>> Gruesse, Carsten
>>

---

From: "Stuber, Michael" <[email-masked]>
Date: Sun, 8 Nov 2009 19:18:26 -0800

Keep in mind though, that much of that bandwidth is shared on these
networks  In an 802.15.4 environment, devices will share a single
channel.  If this work is successful there will be many constrained
nodes within the network, rather than a single pair of nodes.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Henning Schulzrinne
Sent: Sunday, November 08, 2009 6:33 PM
To: Benoit Claise
Cc: [email-masked]
Subject: Re: [6lowapp] Next version of charter proposal up on
6lowapp.net

I find this conflation of Smart Energy/HAN and LowApp confusing. Most of
the in-home networks are not exactly "challenged". Even ZigBee has 250
kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to
early DSL or 1990's modems.

Henning

On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote:

> 3)  ZigBee/HomePlug Market Requirements and Use Cases (which we are 
> using for our Smart Energy V2 work):
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 8 Nov 2009 22:25:07 -0500

Right, but the bandwidth per device is really, really low. How many  
bits do you send each day to a thermostat or light switch? Are there  
any measurements of the realistic signaling load in such networks?

I'm worried about artificially constraining the solution space to  
solve a practical non-problem.

Henning

On Nov 8, 2009, at 10:18 PM, Stuber, Michael wrote:

>> http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20- 
>> %20v1.04%20-%
>> 200808
>>
>> 19-1.pdf
>> 2)  SmartGridipedia:
>>

---

From: "Stuber, Michael" <[email-masked]>
Date: Sun, 8 Nov 2009 19:48:44 -0800

The amount of bandwidth required per applications varies a great deal.
Some devices, like light switches, or battery powered sensors may only
send a message or two per day.  Other devices such as energy usage
monitors or electric vehicles may send a large number of updates.
Electric meters may send current usage information to in-home displays
every 10 seconds.  Electric cars may start with an extended exchange to
negotiate a charging regime, followed by periodic updates to in-home
displays regarding the device's state of charge.

Most of the networks that I worry about are indeed likely to be small
(>30 nodes); however, there are places where folks have been running
larger smart energy networks for meter data collection that are upwards
of thousands of nodes.  The 802.15.4 T4G SUN work is likely to expand
this trend.  Starting with efficient protocols provides headroom for
growth in the application later.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Sunday, November 08, 2009 7:25 PM
To: Stuber, Michael
Cc: Benoit Claise; [email-masked]
Subject: Re: [6lowapp] Next version of charter proposal up on
6lowapp.net

Right, but the bandwidth per device is really, really low. How many bits
do you send each day to a thermostat or light switch? Are there any
measurements of the realistic signaling load in such networks?

I'm worried about artificially constraining the solution space to solve
a practical non-problem.

Henning

>>> I have put a new version of the WG charter proposal on the wiki page

>>> at http://6lowapp.net =

---

From: "Van Der Stok, Peter" <[email-masked]>
Date: Mon, 9 Nov 2009 07:21:42 +0100

Although I agree with the not challenged statement, a few updates:
I expect a presence detector to send out a message once per second or per 10 seconds
There may be 1 till 100 in one wireless mesh, dependent on office lay-out.
The crux comes when an alarm hits. Then we will have an avalanche of messages and some can be just thrown away and a few need to be sent on through the routers to some central post(s)regardless. There is the challenge of overload handling.

Peter

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Sunday, November 08, 2009 7:25 PM
To: Stuber, Michael
Cc: Benoit Claise; [email-masked]
Subject: Re: [6lowapp] Next version of charter proposal up on
6lowapp.net

Henning

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Benoit Claise <[email-masked]>
Date: Mon, 09 Nov 2009 08:15:27 +0100

From the requirement/use case remark in my initial email, I wanted to 
understand: how many constrained nodes in a single constrained network 
must share the 250kbit/s? For example, in case of discovery, concurrent 
events, concurrent queries, etc.
IMHO, this is an important input for the protocol design, which I didn't 
get from the BOF.

Regards, Benoit.

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 9 Nov 2009 03:30:49 -0800

250 Kbps is the theoretical maximum on the data link.   Considering back
offs and other required channel operations (CSMA) the maximum you will see
in practice is about 140 Kbps.

Next, the 140 Kbps is from point to point (a device to its neighbor).
Depending on the network topology and the data transfer characteristics (for
example, if you had an application where predominant traffic is MP2P where
all devices in a multihop network were to send data to a single access
point) you might see less than 10K bps at the concentrator (again, depends
on the data traffic model, the frequency of data transfer, the number of
hops from leaf nodes in the network to the concentrator, etc.).

Don

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Benoit Claise
Sent: Sunday, November 08, 2009 11:15 PM
To: Van Der Stok, Peter
Cc: Stuber, Michael; [email-masked]
Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

>From the requirement/use case remark in my initial email, I wanted to
understand: how many constrained nodes in a single constrained network must
share the 250kbit/s? For example, in case of discovery, concurrent events,
concurrent queries, etc.
IMHO, this is an important input for the protocol design, which I didn't get
from the BOF.

Regards, Benoit.

Although I agree with the not challenged statement, a few updates:
I expect a presence detector to send out a message once per second or per 10
seconds
There may be 1 till 100 in one wireless mesh, dependent on office lay-out.
The crux comes when an alarm hits. Then we will have an avalanche of
messages and some can be just thrown away and a few need to be sent on
through the routers to some central post(s)regardless. There is the
challenge of overload handling.
 
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stuber, Michael
Sent: Monday 9 November 2009 4:49
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

 
-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Sunday, November 08, 2009 7:25 PM
To: Stuber, Michael
Cc: Benoit Claise; [email-masked]
Subject: Re: [6lowapp] Next version of charter proposal up on
6lowapp.net

 
Henning

 
-----Original Message-----
 
I find this conflation of Smart Energy/HAN and LowApp confusing.
Most of
the in-home networks are not exactly "challenged". Even ZigBee has 250

 
Henning

Carsten,

Is the goal to describe these requirements in the "objectives and
architecture" document?

 
19-1.pdf
2)  SmartGridipedia:
 
http://www.smartgridipedia.org/index.php/Category:Use_Cases
, both the
Intelligrid and Southern California Edison use cases are good
3)  ZigBee/HomePlug Market Requirements and Use Cases (which we are
using for our Smart Energy V2 work):

"The framework will also specify specify a way to support interface
profiles, ..."
Can you expand on "interface profile".

"A document with operation and management advice about running a
network using these applications."
Is advice the right word? It seems like one or two advices are
sufficient to manage the network ;-)

Regards, Benoit.

 

at http://6lowapp.net =

 

Gruesse, Carsten

 
 
The information contained in this message may be confidential and legally
protected under applicable law. The message is intended solely for the
addressee(s). If you are not the intended recipient, you are hereby notified
that any use, forwarding, dissemination, or reproduction of this message is
strictly prohibited and may be unlawful. If you are not the intended
recipient, please contact the sender by return e-mail and destroy all copies
of the original message.
_______________________________________________
6lowapp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowapp

---

From: Arjun Roychowdhury <[email-masked]>
Date: Mon, 9 Nov 2009 09:35:28 -0500

Okay, I am sorry, I am very confused now. Can someone please point me to a
resource where I can read up what are the constraints for HAN devices this
group is talking about, specifically:

a) CPU constraints (and what sort of devices this applies/does not apply to)
b) Network constraints
c) What is the network topology for which modelling needs to be done to
figure out whether a protocol is appropriate or not?

I see numbers being talked about in this list and while discussing the
charter, but I am unable to see a clear modeling that arrives at those
numbers.

regds
arjun

On Mon, Nov 9, 2009 at 6:30 AM, Don Sturek <[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Benoit Claise
> *Sent:* Sunday, November 08, 2009 11:15 PM
> *To:* Van Der Stok, Peter
> *Cc:* Stuber, Michael; [email-masked]
>
> *Subject:* Re: [6lowapp] Next version of charter proposal up on
> 6lowapp.net
>
>
>
> From: [email-masked] [mailto:[email-masked] <[email-masked]>] On Behalf Of Stuber, Michael
>
> From: Henning Schulzrinne [mailto:[email-masked] <[email-masked]>]
>
> From: [email-masked] [mailto:[email-masked] <[email-masked]>] On
>
> *********************************************DISCLAIMER*********************************************
> The email is subject to Disclaimer as per -
> http://www.hsc.com/tabid/91/Default.aspx#emaildisclaimer
>
>
>

-- 
Arjun Roychowdhury

---

From: Shidan <[email-masked]>
Date: Mon, 9 Nov 2009 11:03:53 -0500

Just curious, if this is the an edge case and far from typical? If it is,
would it be reasonable to assume more than one concentrator?

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 9 Nov 2009 12:29:33 -0800

In terms of an edge case, this was a use where someone wanted to have a
single concentrator supporting as many sensor devices as possible each
reporting 1 second data.  It turns out the number you could support was in
the hundreds not thousands.

Whether this is an edge case or not is debatable.  It wasn't in this case
since the concentrators were expensive and they wanted to support 1000+
sensors to make their business case.

Don

From: Shidan [mailto:[email-masked]] 
Sent: Monday, November 09, 2009 8:04 AM
To: [email-masked]
Cc: Benoit Claise; Van Der Stok, Peter; Stuber, Michael; [email-masked]
Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

 

Don

Regards, Benoit.

Peter

 
 
-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Sunday, November 08, 2009 7:25 PM
To: Stuber, Michael
Cc: Benoit Claise; [email-masked]
Subject: Re: [6lowapp] Next version of charter proposal up on
6lowapp.net

Henning

 
-----Original Message-----

 

Henning

Carsten,

 

19-1.pdf
2)  SmartGridipedia:

 

Regards, Benoit.

 

at http://6lowapp.net =

 

Gruesse, Carsten

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 9 Nov 2009 12:42:56 -0800

Have a look at the 6LowAPP presentation at the BOF.   There is a slide
outlining a typical CPU used on such a system.

There is not a single set of network constraints or topologies.   There are
many networks deployed today using IEEE 802.15.4.  Many of these networks
run proprietary or vendor consortium standards (non-IP).  The 6LowAPP
problem statement (and 6LowPAN) capture what is needed to displace these
solutions with IP.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of Arjun
Roychowdhury
Sent: Monday, November 09, 2009 6:35 AM
To: [email-masked]
Cc: Benoit Claise; Van Der Stok, Peter; Stuber, Michael; [email-masked]
Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

b) Network constraints

regds

arjun

Don

Regards, Benoit.

Peter

 
 
-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Sunday, November 08, 2009 7:25 PM
To: Stuber, Michael
Cc: Benoit Claise; [email-masked]
Subject: Re: [6lowapp] Next version of charter proposal up on
6lowapp.net

 
Henning

 
-----Original Message-----

 

Henning

Carsten,

 

19-1.pdf
2)  SmartGridipedia:

 

Regards, Benoit.

 

at http://6lowapp.net =

        

 
Gruesse, Carsten

 

 

*********************************************DISCLAIMER*********************
************************
The email is subject to Disclaimer as per -
http://www.hsc.com/tabid/91/Default.aspx#emaildisclaimer

-- 
Arjun Roychowdhury