Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

From: [email-masked]
Date: Wed, 4 Nov 2009 00:18:46 +0100

Hi Cullen,

    >----- Message de Cullen Jennings <[email-masked]> sur Sat, 31 Oct 
2009 11:29:41 -0600 -----
    >Pour:      [email-masked]
    >cc:        Don Sturek <[email-masked]>, [email-masked]
    >Objet:     Re: [6lowapp] Proposed charter for 6LoWAPP BOF
    >
    >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote:
    >
    > ...
    >OK - The way I want to try and derive us towards a decision here is 
    >get a list of candidate protocols then for each one ask the yes/no is 
 
    >the their agreement that we should do a mapping to that protocol. The 
 
    >protocols I have heard so far are HTTP, SNMP,  SMTP. So two questions
    >
    >1) what other protocols mapping should we do?

The charter has significantly changed these days and I would like to 
re-state the need for 
seamless interfacing between 6lowapp and the DPWS world. DPWS is a low 
cost SOA solution at 
device level and will play a major role in future Building and Industrial 
Automation systems 
(embedded in zone controllers, Automation servers, industrial PLCs...). 
Besides, in some 
cases, native support of DPWS in VISTA and Windows 7 network explorer 
might help in simplifying
discovery and commissioning of devices.
The HTTP REST model proposed in the new charter is sufficient for simple 
get/set operations but
I join Vlad Trifa when saying that there are requirements for more than 
just request/response 
messaging patterns like e.g. publish/subscribe (multicast). IMO seamless 
interfacing with WS_* 
(at least straightforward proxying) must be provided to ensure efficient 
integration of 6lowpan networks
in upcoming architectures.

Regards.
Nicolas

---

From: Zach Shelby <[email-masked]>
Date: Wed, 4 Nov 2009 11:04:01 +0200

Nicolas,

On Nov 4, 2009, at 1:18 , [email-masked] wrote:

>
> Hi Cullen,
>
>     >----- Message de Cullen Jennings <[email-masked]> sur Sat, 31  
> Oct 2009 11:29:41 -0600 -----
> seamless interfacing between 6lowapp and the DPWS world. DPWS is a  
> low cost SOA solution at
> device level and will play a major role in future Building and  
> Industrial Automation systems
> (embedded in zone controllers, Automation servers, industrial  
> PLCs...). Besides, in some
> cases, native support of DPWS in VISTA and Windows 7 network  
> explorer might help in simplifying

I totally agree that we should interface seamlessly with DPWS. Cullen  
is in the process of re-writing the charter, this is the reason it got  
left out temporarily (we had it in earlier). In fact the discovery  
mechanism is meant to be compatible with DPWS thinking, or at least  
useable with a subset of DPWS profiles if someone wants.

> The HTTP REST model proposed in the new charter is sufficient for  
> simple get/set operations but
> I join Vlad Trifa when saying that there are requirements for more  
> than just request/response
> messaging patterns like e.g. publish/subscribe (multicast). IMO  
> seamless interfacing with WS_*
> (at least straightforward proxying) must be provided to ensure  
> efficient integration of 6lowpan networks

The charter is actually saying that REST alone is not sufficient.  
Multicast is listed (or should be better listed). It will also be  
possible to realize RPC over CoAP, and thus someone could even use  
this for WS_* messaging if they wanted to. Just as it works with HTTP.  
Do you have some specific text changes in mind to make that more  
clear? Now it lists multicast, push, pull and notification.

Thanks,
Zach

>
> Regards.
> Nicolas
> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp

-- 
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: Paul Duffy <[email-masked]>
Date: Wed, 04 Nov 2009 07:50:26 -0500

I agree there is a need for more than request/response messaging, but 
WS_*  gives me pause for constrained devices and links. It is probably 
the most compute intensive, bandwidth hungry way to interface HAN-like 
endpoints.

> ------------------------------------------------------------------------
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Nov 2009 15:36:00 +0100

> clear? Now it lists multicast, push, pull and notification.

I have been following this discussion silently and it seems there are
pretty diverging opinions of the applications targeted by CoAP. Some
people apparently just want to read simple meters from lots of truely
resource constrained (thus cheap) devices and do very limited control
actions.  Others seem to see a need for a rather complex^Hcomplete
middleware instrastructure to be developed, including new transports
to support it (and not much discussion of the necessary security
infrastructure needed to support it has yet been seen here). Some
poeple might believe there is a magic silver bullet to support all
application scenarios equally well - I personally have some doubts
about the existance of it or that it can be found quickly. This goes
to the expectation that all the new protocols will be worked out and
standardized fast enough to meet aggressive industry consortia
deadlines of "tomorrow".

In my experience, the IETF is working best by breaking things down in
manageable pieces and assigning priorities to them. I believe this
needs to be done sooner rather than later here as well. Building a
long wishlist of things CoAP is expected to nicely interface with
seems like moving into the wrong direction (except you take a rather
liberal interpretation of "interfacing nicely" - the hard stuff is
often in the detailed semantics and their mismatches).

/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: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Wed, 4 Nov 2009 16:12:30 +0100

Hello,
I don't get one point here. Help me to understand.
Are we searching for a well known protocol to use as CoAP for 6lowPAN and WSN networks or are we searching for a "model" to use for?

I'm seeing here a lot of proposal like HTTP, SNMP, SIP, XMPP on the plate. Each of these protocols have been developed for a specific purpose keeping in mind specific constraints and requirements and each of them is a valid choice for the respective domain. On the other side, each of them have some drawbacks for 6lowPAN and WSN networks and I see a lot of diverged opinions here.

Why we fear for define a new application protocol especially designed for 6lowPAN and WSN networks?

I'm a newbie for 6lowPAN but my feeling is that a simple lightweight protocol (I also prefer LoAP instead of CoAP) with a minimal set of primitives (e.g. SET/SET-Reply, GET/GET-Reply and Event/Ack) is sufficient to cover the most part of the use cases and interaction models for 6lowPAN and WSN networks. Other items can be further added on the plate like security, service discovery, nodes and network management, and so on .. but all they can be solved with the same minimal approach keeping in mind the real nature and the scope of 6lowPAN networks. At the end of day, we are talking about CSMA/CA radio networks with high lossy and few kilobytes of useful throughput. Also the nodes spend most part of their time sleeping down to save power or can be inactive for days (or months). I've some doubts that complex protocols/frameworks (developed for other scopes than 6lowPAN) can run efficiently on our small poor devices. But that's only the feeling of a newbie ....

Adriano

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 4 Nov 2009 07:54:27 -0800

> often in the detailed semantics and their mismatches).

Exactly!  I have been advocating this and I'm glad others are bumping  
into the same problem.  If we want to make quick forward progress, we  
need to explicitly call out target applications (and probably use  
cases) in the charter.

SE 2 and Building Management applications seems like a good starting  
list and I would be satisfied if we only focused on those two for the  
time being.

--
Jonathan Hui

---

From: Zach Shelby <[email-masked]>
Date: Wed, 4 Nov 2009 18:01:19 +0200

> Exactly!  I have been advocating this and I'm glad others are  
> bumping into the same problem.  If we want to make quick forward  
> progress, we need to explicitly call out target applications (and  
> probably use cases) in the charter.
>
> list and I would be satisfied if we only focused on those two for  
> the time being.
>

+1!

We do need to specify which protocol we need to assume we can proxy  
with. I am satisfied with HTTP REST as the charter states now as a  
starting place as it covers those applications well. Others can come  
in the future as needed. We should though specifically list which  
standards organizations we will work with, and OASIS (e.g. oBIX, DPWS)  
is important there in addition to SE2 related organizations.

Zach

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

---

From: Paul Duffy <[email-masked]>
Date: Wed, 04 Nov 2009 11:03:57 -0500

+1 on scoping for SE 2.x and Building Management

---

From: Robert Cragie <[email-masked]>
Date: Wed, 04 Nov 2009 16:35:24 +0000

Not considering specific use cases, I see two general requirements 
coming out here:

   1. The requirement for a universal application protocol  which can
      work across the wider internet all the way from head-end to edge
      devices
   2. The requirement for an application protocol specific to low-power,
      resource constrained nodes (CoAP)

(1) pushes from the wider Internet to the edge devices.
(2) pushes from the edge devices to the wider Internet.

The utopian aim would be to find the intersection of these requirements, 
if it exists. Then the Internet of Things truly becomes feasible. 

Considering (1) further: The most feasible solution to run over the 
wider Internet and into the home is likely to be RESTful HTTP over TCP 
as it is so universally used now and is likely to persist well into the 
future. One important reason for this argument is that so much existing 
infrastructure supports this. For example, many small office and home 
systems use IPv4 and NAT gateways/routers. This is itself puts some 
imposition on the ability for true end-to-end IP routing as it stands 
due to the use of TCP/UDP ports. Indeed, the protocol stack 'waist' can 
almost be considered to be HTTP (80/tcp) these days, not IP at layer 3.

Considering (2) further: If we ignored the wider Internet as a whole, 
there is no doubt that a simple, efficient, low bandwidth application 
protocol would be developed which is oriented towards CNets. Indeed, one 
could argue that ZigBee satisfies that requirement very well. This sort 
of network is also already capable of being connected to the wider 
Internet through an application level gateway providing translation and 
also proxying and buffering for low bandwidth and sleepy devices. The 
fundamental problem with this approach is that the bridging is not 
occurring at the 'waist' but at the 'chest'. The maintenance of all the 
translations for the numerous networks could become a burden. This is 
also counter to routing IP at layer 3.

Therefore I see three ways of proceeding:

   1. Define an application protocol which uses RESTful HTTP over TCP
      extending to the edge devices and try to find a solution to the
      problems of TCP over lossy links
   2. Define an application protocol based on a universal transaction
      and transport which is flexible enough for all media and takes
      into consideration the underlying properties of the medium through
      cross-layer controls. However the scope of this work is probably
      beyond CoAP and assumes that IPv6 would become pervasive enough
      not to cause problems with existing infrastructure
   3. Define new application, transaction and transport protocols
      oriented towards CNets and define a proxy model for extension into
      the wider Internet

Note these are not mutually exclusive. If (1) were done, (3) could still 
be a solution for devices which do not meet the criteria to satisfy the 
use of TCP. If (2) were done there would probably be no point in doing 
(1) or (3). (3) could be done now but does not solve the requirement for 
"end-to-end", although there are a number of possibilities there if you 
split the application layer into the three layers defined in OSI, but 
that's another debate.

Regards,

Robert

---

From: Shidan <[email-masked]>
Date: Wed, 4 Nov 2009 11:44:11 -0500

+1 on scoping for Building Management and utilityAMI's requirements and use
cases.

On Wed, Nov 4, 2009 at 11:03 AM, Paul Duffy <[email-masked]> wrote:

>> Exactly!  I have been advocating this and I'm glad others are bumping into
>> the same problem.  If we want to make quick forward progress, we need to
>> explicitly call out target applications (and probably use cases) in the
>> charter.
>>
>> SE 2 and Building Management applications seems like a good starting list
>> and I would be satisfied if we only focused on those two for the time being.
>>
>> --
>> Jonathan Hui
>>

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Wed, 4 Nov 2009 17:59:28 +0100

Thanks Robert,

It sounds interesting. What you means exactly by saying "split the application layer into the three layers defined in OSI" ?

Regards,

Adriano

From: Robert Cragie [mailto:[email-masked]] 
Sent: mercoledì 4 novembre 2009 17.35
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); [email-masked]; [email-masked]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

Not considering specific use cases, I see two general requirements coming out here:

1.	The requirement for a universal application protocol  which can work across the wider internet all the way from head-end to edge devices
2.	The requirement for an application protocol specific to low-power, resource constrained nodes (CoAP)

The utopian aim would be to find the intersection of these requirements, if it exists. Then the Internet of Things truly becomes feasible.  

Considering (1) further: The most feasible solution to run over the wider Internet and into the home is likely to be RESTful HTTP over TCP as it is so universally used now and is likely to persist well into the future. One important reason for this argument is that so much existing infrastructure supports this. For example, many small office and home systems use IPv4 and NAT gateways/routers. This is itself puts some imposition on the ability for true end-to-end IP routing as it stands due to the use of TCP/UDP ports. Indeed, the protocol stack 'waist' can almost be considered to be HTTP (80/tcp) these days, not IP at layer 3.

Considering (2) further: If we ignored the wider Internet as a whole, there is no doubt that a simple, efficient, low bandwidth application protocol would be developed which is oriented towards CNets. Indeed, one could argue that ZigBee satisfies that requirement very well. This sort of network is also already capable of being connected to the wider Internet through an application level gateway providing translation and also proxying and buffering for low bandwidth and sleepy devices. The fundamental problem with this approach is that the bridging is not occurring at the 'waist' but at the 'chest'. The maintenance of all the translations for the numerous networks could become a burden. This is also counter to routing IP at layer 3.

1.	Define an application protocol which uses RESTful HTTP over TCP extending to the edge devices and try to find a solution to the problems of TCP over lossy links
2.	Define an application protocol based on a universal transaction and transport which is flexible enough for all media and takes into consideration the underlying properties of the medium through cross-layer controls. However the scope of this work is probably beyond CoAP and assumes that IPv6 would become pervasive enough not to cause problems with existing infrastructure
3.	Define new application, transaction and transport protocols oriented towards CNets and define a proxy model for extension into the wider Internet

Note these are not mutually exclusive. If (1) were done, (3) could still be a solution for devices which do not meet the criteria to satisfy the use of TCP. If (2) were done there would probably be no point in doing (1) or (3). (3) could be done now but does not solve the requirement for "end-to-end", although there are a number of possibilities there if you split the application layer into the three layers defined in OSI, but that's another debate.

Regards,

Robert

Hello,

 
 
Adriano
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Duffy (paduffy)
Sent: mercoledì 4 novembre 2009 13.50
To: [email-masked]
Cc: [email-masked]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

  

	Hi Cullen,
	 
	    >----- Message de Cullen Jennings <[email-masked]> <mailto:[email-masked]>  sur Sat, 31 
	    >cc:        Don Sturek <[email-masked]> <mailto:[email-masked]> , [email-masked]

	Regards.
	Nicolas

---

From: Shidan <[email-masked]>
Date: Wed, 4 Nov 2009 12:21:09 -0500

I couldn't agree more with your points which I highlighted below. We can't
look at this in a vacuum of just HANs but rather, it has to be a holistic
view.

In this case since time is of the essence, looking specifically at energy
management use cases is fine. I think Don went down this path in the thread
for message filtering and collectors and I think it would be good if we saw
more of how CoAp would relate to the rest of the networks and the
ideal qualities we want in it considering this holistic view, and then see
how much of that is possible.

---
Shidan

On Wed, Nov 4, 2009 at 11:35 AM, Robert Cragie
<[email-masked]>wrote:

>    1. The requirement for a universal application protocol  which can work
>    across the wider internet all the way from head-end to edge devices
> The utopian aim would be to find the intersection of these requirements, if
> it exists. Then the Internet of Things truly becomes feasible.
>
>

---

From: Robert Cragie <[email-masked]>
Date: Wed, 04 Nov 2009 18:07:59 +0000

In a nutshell: It is possible to consider presentation layer and session 
layer translation as opposed to just 'application layer' translation. 
Presentation layer translation could mean a common application protocol 
(e.g. IEC 61968 CIM) with various presentation layers (e.g. MIME types - 
text/xml, binary/exi etc.) and translations (or transformations) between 
them. Similarly, session layer translation could have common application 
and presentation layers but different session connections between 
endpoints and transformation between session transactions. This could 
facilitate proxying/buffering for low bandwidth/availability devices.

Robert

Adriano Pezzuto (apezzuto) wrote:
>
> Thanks Robert,
>
> It sounds interesting. What you means exactly by saying "split the 
> application layer into the three layers defined in OSI" ?
>
>  
>
> Regards,
>
> Adriano
>
>  
>
> *From:* Robert Cragie [mailto:[email-masked]]
> *Sent:* mercoledì 4 novembre 2009 17.35
> *To:* Adriano Pezzuto (apezzuto)
> *Cc:* Paul Duffy (paduffy); [email-masked]; [email-masked]
> *Subject:* Re: [6lowapp] Proposed charter for 6LoWAPP BOF
>
>  
>
>    2. The requirement for an application protocol specific to
>       low-power, resource constrained nodes (CoAP)
>
> The utopian aim would be to find the intersection of these 
> requirements, if it exists. Then the Internet of Things truly becomes 
> feasible. 
>
> as it is so universally used now and is likely to persist well into 
> the future. One important reason for this argument is that so much 
> existing infrastructure supports this. For example, many small office 
> and home systems use IPv4 and NAT gateways/routers. This is itself 
> puts some imposition on the ability for true end-to-end IP routing as 
> it stands due to the use of TCP/UDP ports. Indeed, the protocol stack 
> 'waist' can almost be considered to be HTTP (80/tcp) these days, not 
> IP at layer 3.
>
> protocol would be developed which is oriented towards CNets. Indeed, 
> one could argue that ZigBee satisfies that requirement very well. This 
> sort of network is also already capable of being connected to the 
> wider Internet through an application level gateway providing 
> translation and also proxying and buffering for low bandwidth and 
> sleepy devices. The fundamental problem with this approach is that the 
> bridging is not occurring at the 'waist' but at the 'chest'. The 
> maintenance of all the translations for the numerous networks could 
> become a burden. This is also counter to routing IP at layer 3.
>
>       into consideration the underlying properties of the medium
>       through cross-layer controls. However the scope of this work is
>       probably beyond CoAP and assumes that IPv6 would become
>       pervasive enough not to cause problems with existing infrastructure
>       oriented towards CNets and define a proxy model for extension
>       into the wider Internet
>
> Note these are not mutually exclusive. If (1) were done, (3) could 
> still be a solution for devices which do not meet the criteria to 
> satisfy the use of TCP. If (2) were done there would probably be no 
> point in doing (1) or (3). (3) could be done now but does not solve 
> the requirement for "end-to-end", although there are a number of 
> possibilities there if you split the application layer into the three 
> layers defined in OSI, but that's another debate.
>
> Regards,
>
> Robert
>
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Paul Duffy (paduffy)
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
>         >Pour:        [email-masked] <mailto:[email-masked]>
>
>         >cc:        Don Sturek <[email-masked]> <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
>
>         >OK - The way I want to try and derive us towards a decision here 
>
>     is  
>
>         >get a list of candidate protocols then for each one ask the 
>
>     yes/no is  
>
>         >the their agreement that we should do a mapping to that protocol. 
>
>      The  
>
>         >protocols I have heard so far are HTTP, SNMP,  SMTP. So two 
>
>     questions
>
>         >
>
>     [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Zach Shelby <[email-masked]>
Date: Wed, 4 Nov 2009 23:52:23 +0200

Robert,

Very good points below, thanks for the mail!

> (2) pushes from the edge devices to the wider Internet.

Yep, this is the tussle at play here. We are not considering all edge  
devices here, only the most constrained devices and networks.

> 	• Define an application protocol which uses RESTful HTTP over TCP  

So HTTP already is that protocol, and it is the current SOTA for  
embedded devices and networks where it gets the job done. We already  
determined that new transport work is a longer-term issue for the TSV  
area. The whole point of this interest group (and WG effort) is that  
there is a large set of devices, networks and applications where this  
is not sufficient. So I would say that 1 is definitely done.

> 	• Define an application protocol based on a universal transaction  
> and transport which is flexible enough for all media and takes into  
> consideration the underlying properties of the medium through cross- 
> layer controls. However the scope of this work is probably beyond  
> CoAP and assumes that IPv6 would become pervasive enough not to  
> cause problems with existing infrastructure

This is out of scope of the APP area, and probably breaks lots of IETF  
architectural concepts as well. So 2 is out.

> 	• Define new application, transaction and transport protocols  

This WG is not going to define new transport protocols (nor can it).  
There is good consensus to use UDP by default and allow for the use of  
TCP (or other suitable transports).

> satisfy the use of TCP.

TCP is only one issue, it is useful in some cases. HTTP and current  
security models assumed by the web infrastructure are not suitable for  
all constrained IP devices and networks.

>  If (2) were done there would probably be no point in doing (1) or  
> (3). (3) could be done now but does not solve the requirement for  
> "end-to-end", although there are a number of possibilities there if  
> you split the application layer into the three layers defined in  
> OSI, but that's another debate.

I think you hit on the whole point here. 1 is done, 2 is not possible,  
and what this WG needs to do is 3, making that as integrated into the  
web architecture as we can. If we do our job well, I don't see  
proxying between two protocols that share the same semantics (URLs,  
REST etc.) and leave the payload alone to be a problem.

Now. Considering that, do you have comments on the charter text? We  
are working on a new version right now.

Zach

>> Are we searching for a well known protocol to use as CoAP for  
>> 6lowPAN and WSN networks or are we searching for a "model" to use  
>> for?
>>
>> I'm seeing here a lot of proposal like HTTP, SNMP, SIP, XMPP on the  
>> plate. Each of these protocols have been developed for a specific  
>> purpose keeping in mind specific constraints and requirements and  
>> each of them is a valid choice for the respective domain. On the  
>> other side, each of them have some drawbacks for 6lowPAN and WSN  
>> networks and I see a lot of diverged opinions here.
>>
>> I'm a newbie for 6lowPAN but my feeling is that a simple  
>> lightweight protocol (I also prefer LoAP instead of CoAP) with a  
>> minimal set of primitives (e.g. SET/SET-Reply, GET/GET-Reply and  
>> Event/Ack) is sufficient to cover the most part of the use cases  
>> and interaction models for 6lowPAN and WSN networks. Other items  
>> can be further added on the plate like security, service discovery,  
>> nodes and network management, and so on .. but all they can be  
>> solved with the same minimal approach keeping in mind the real  
>> nature and the scope of 6lowPAN networks. At the end of day, we are  
>> talking about CSMA/CA radio networks with high lossy and few  
>> kilobytes of useful throughput. Also the nodes spend most part of  
>> their time sleeping down to save power or can be inactive for days  
>> (or months). I've some doubts that complex protocols/frameworks  
>> (developed for other scopes than 6lowPAN) can run efficiently on  
>> our small poor devices. But that's only the feeling of a newbie ....
>>
>> Adriano
>>
>> From:
>> [email-masked] [mailto:[email-masked]
>> ] On Behalf Of Paul Duffy (paduffy)
>> Cc:
>>>     >----- Message de Cullen Jennings
>>> <[email-masked]>
>>>  sur Sat, 31
>>>     >Pour:
>>> [email-masked]
>>>     >cc:        Don Sturek
>>> <[email-masked]>, [email-masked]
>>>
>>> low

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Nov 2009 17:00:14 -0500

I'm joining this discussion late, so I may be rehashing earlier  
discussions, but I admit to some confusion. We seem to be conflating a  
number of different constraints:
- low bandwidth
- low computational capabilities (CPU, memory)
- lossy links

Some systems suffer from all three, but others don't. For example,  
while an IP-enabled lightswitch may have a puny CPU, it has plenty of  
power and ZigBee is not exactly a low-bandwidth network and can easily  
handle an occasional HTTP or SIP message exchanged among appliances.

On the other hand, there's now a lot of interest in sensors that do  
more than gather a few 8-bit measurements every day, e.g., video and  
audio analysis. For those applications, HTTP isn't exactly the best fit.

Many home networks will incorporate devices from lightswitches and  
temperature sensors to appliances, home entertainment systems and  
electric vehicles. For a light-switch, carrying one bit in a 100-byte  
message isn't really necessary (X10 is far more efficient), but a GET/ 
SET protocol with one value isn't sufficient to control more  
complicated appliances.

Also, with distributed control, an event bus model seems most natural,  
as there will be many listeners for sensors and possibly distributed  
actuators for the same logical function. Again, not exactly a great  
fit for HTTP if operating in a peer-to-peer mode.

Henning

On Nov 4, 2009, at 11:35 AM, Robert Cragie wrote:

> The requirement for a universal application protocol  which can work  
> The requirement for an application protocol specific to low-power,  
> requirements, if it exists. Then the Internet of Things truly  
> becomes feasible.
>
> wider Internet and into the home is likely to be RESTful HTTP over  
> TCP as it is so universally used now and is likely to persist well  
> into the future. One important reason for this argument is that so  
> much existing infrastructure supports this. For example, many small  
> office and home systems use IPv4 and NAT gateways/routers. This is  
> itself puts some imposition on the ability for true end-to-end IP  
> routing as it stands due to the use of TCP/UDP ports. Indeed, the  
> protocol stack ‘waist’ can almost be considered to be HTTP (80/tcp)  
> these days, not IP at layer 3.
>
> Considering (2) further: If we ignored the wider Internet as a  
> whole, there is no doubt that a simple, efficient, low bandwidth  
> application protocol would be developed which is oriented towards  
> CNets. Indeed, one could argue that ZigBee satisfies that  
> requirement very well. This sort of network is also already capable  
> of being connected to the wider Internet through an application  
> level gateway providing translation and also proxying and buffering  
> for low bandwidth and sleepy devices. The fundamental problem with  
> this approach is that the bridging is not occurring at the ‘waist’  
> but at the ‘chest’. The maintenance of all the translations for the  
> numerous networks could become a burden. This is also counter to  
> routing IP at layer 3.
>
> Define an application protocol which uses RESTful HTTP over TCP  
> Define an application protocol based on a universal transaction and  
> transport which is flexible enough for all media and takes into  
> Define new application, transaction and transport protocols oriented  
> towards CNets and define a proxy model for extension into the wider  
> Internet
> possibilities there if you split the application layer into the  
> three layers defined in OSI, but that's another debate.
>
> Regards,
>
> Robert
>

---

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

On Nov 4, 2009, at 23:00, Henning Schulzrinne wrote:

> We seem to be conflating a number of different constraints:
> - low bandwidth

Let's add (again, for some, not all nodes in the mix):

-- constraints on power (sleeping nodes)
    -- preference for node-initiated communication
-- constraints on networking
    -- payloads beyond 50-70 bytes cause expensive/lossy fragmentation
    -- no IP multicast (except for a narrow radio range)

CoAP is not aimed at high-power, high-bitrate nodes such as WiFi  
cameras.
(CoAP might indeed help those WiFi cameras with talking to, say,  
additional PIR motion sensors or door/window sensors.)
HANs/BANs will certainly use a mixture of protocols, and e.g. RTP plus  
some control protocol (SIP, XMPP) may be fine for a camera.

Gruesse, Carsten

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Thu, 5 Nov 2009 10:33:33 +0100

Hi Zach and Robert,
I get the point. It sounds good.

Thanks,
Adriano

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: mercoledì 4 novembre 2009 22.52
To: [email-masked]
Cc: Adriano Pezzuto (apezzuto); Paul Duffy (paduffy); [email-masked]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

Robert,

> 	* Define an application protocol which uses RESTful HTTP over TCP  

> 	* Define an application protocol based on a universal transaction  

> 	* Define new application, transaction and transport protocols  

Zach