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

[Zach Shelby <[e-mail]>]

Hi Folks,

Murphy's law of mailing lists - you always miss the 100 post thread  
when off-line for a few days ;-) Great to see the list discussions!  
Here are my summarized thoughts after reading the recent threads:

* WG name

I agree this WG should *not* be called 6lowapp - that was just a name  
we made to get this interest group started... This is not IPv6  
specific, nor is it LoWPAN specific. I think we should call the WG the  
same as the protocol/framework. In this case CoAP. Although I  liked  
LoAP better. And just think... LOw-power Application Framework =  
LoAF ;-)

* Architecture:

Cullen and Lisa summarized this perfectly. We need a basic  
architectural principle built into this charter. I do agree the  
charter shouldn't go into too much detail. Cullen's proposal is really  
only (trying to) say this about architecture:

1) This is a resource framework
2) This framework integrates a profile discovery mechanism
2) Integration with the HTTP web is a must
3) A proxy solution is used for integration with HTTP, caching etc.  
along with other protocol translations. This is optional, and can be  
located anywhere on the Internet. Some others may be defined in this  
charter, or in future re-chartering.
4) Application layer security is an integral part of the framework

In my opinion these basic architectural assumptions are a great start  
for the requirements and applications are focusing on. I think we  
should be more explicit that CoAP is part of the Internet web  
architecture, and we are not inventing a completely new model. A proxy  
is by no means required, it is just a means to integrate with HTTP,  
perform caching, improve security etc.

The scope of CoAP is by no means just a LoWPAN. The framework may be  
used over an entire building network, parts of the smart grid, in  
manufacturing facilities, across cellular networks etc. Proxies may be  
located just about anywhere. So yes, we need to take the wider  
Internet into account although CoAP will mainly be used in the  
constrained network domain. We should also be specific that CoAP can  
be used between devices directly, and doesn't require an infrastructure.

Finally, I agree with Cullen that the REST paradigm is sufficient for  
providing both simple variable manipulation, full resource  
manipulation, and also RPC can of course be built on-top of REST just  
as it can be with e.g. WS or XMPP today. I would say we should  
explicitly target the REST model for the CoAP framework as well as it  
is a good middle-ground.

* Requirements vs. Objectives:

I am in-line with Carsten and Jonathan that we need to call these  
objectives and avoid the endless requirement trap. In addition to the  
requirement drafts submitted to 6lowapp, and use cases available  
elsewhere, I especially find the use cases produced in the ROLL WG  
something we can also pull application requirements out of.

* Proxy vs. Gateway:

In my opinion we should definitely call this a proxy. The entity is  
optional, basic features can be considered proxy features, even CoAP- 
HTTP integration. Jonathan pointed out that you may also implement  
Gateway type features. I agree, but those can be built on-top.  
Features which are application specific (like aggregation) should be  
out of scope I agree. CoAP would not require a gateway by any means -  
we don't want to give that impression.

Now on the question if you need a proxy? Yes, often you will need a  
proxy but it should not be required. Proxies are a normal piece of the  
web architecture. Just as with an HTTP proxy, a CoAP proxy could be  
located anywhere so it doesn't necessarily add cost to the Smart  
Energy HAN, but more likely is just a feature on some router/server.

* Security

It is important that we build application layer security into this  
framework. Although some wireless mesh L2 technology has built-in  
security such as AES in IEEE 802.15.4, that doesn't provide end-to-end  
security, nor security outside that link. Obviously security is  
optional, just as with HTTP today.

* HTTP

There has been talk about using "optimized HTTP", "constrained HTTP",  
"compressed HTTP" on the list as a solution for this. The problem is,  
after making those optimizations, it is no longer HTTP. Web-servers  
speak HTTP/1.0 or HTTP/1.1 and will not be compatible both ways. The  
same goes for the security features. You might as well call such a  
thing Chopan, CoAP or whatever. Optimized HTTP would also need to be  
proxied, just as in the proposed CoAP architecture. As pointed out by  
several, even this kind of HTTP optimization may work for some  
applications, but surely not all. HTTP is also bound to TCP with no  
multicast support. The interaction model doesn't cover the  
requirements seen. So we are back to what the charter says, we need a  
protocol to achieve the objectives for applications over constrained  
networks. The solution would surely will use parts of HTTP as a design  
reference as seen in frank-6lowapp-chopan, and input from many other  
protocols. Text vs. binary is just a design consideration...

* TCP

Don pointed out the low-power wireless mesh packet loss problems. In  
addition I have big problems with TCP breaking from mobility (in e.g.  
building asset management with LoWPANs, the IP address may change  
often) and no multicast support. In M2M, the packet exchanges are  
often very short (sometimes just one small payload), the TCP  
connection model just doesn't make sense there. That said, I think we  
should allow TCP to be used with CoAP, and I encourage future work on  
reliable transport improvements.

* Charter proposal

So down to the text below. Again a great start. I think it needs to be  
more specific on applications, use cases and the architecture. In  
other places it is way too specific for example talking about sensors  
and actuators - where in practice we are working with general embedded  
devices. With a couple good editing rounds and taking list comments  
into account, this is going to be good to go into the BOF with.

Zach

On Oct 29, 2009, at 8:42 , Cullen Jennings wrote:

>
> I've been talking to various folks about the how quickly they would  
> like to get initial standards on this topic complete. To move  
> quickly, I think we need an initial charter that is extremely  
> focused and makes it clear what we are going to go do. After we meat  
> the initial goals of the WG, we could expand the WG to explore into  
> more area and extend the protocols to do more. I bounced some ideas  
> around with Zack, Carsten, and Don and have put an initial draft of  
> what I think of as a focused charter might look like below.
>
> It's just a straw man and it has some problems in it. I've been  
> trying to merge all the various things different people have told me  
> and organize them. I'm not promoting that I think this is the best  
> plan - it just a plan that we can use as a baseline to talk about  
> what we really want to do as group and if this charter reflects that  
> or not.
>
> Please, read it. Think about, if the WG did this, could you live  
> with that. If No, why and what requirements do you have this does  
> not meet. If you could live with it but some changes would make it  
> better, what are they.
>
> Thanks, Cullen
>
> ----------------------------------------
>
>
>
> Applications are being developed for networks that have very limed  
> packets sizes, have high degree of packet loss, and where a  
> substantial number of devices that may be powered of at any point in  
> time but periodically "wake up" for beef periods of time. These  
> Networks are referred to as Constrained Networks (CNEets). Low-Power  
> Wireless Personal Area Networks (LoWPANs) are an example of this  
> type of network. These networks are becoming increasing important  
> for applications such as home automation, energy management, and the  
> Internet of Things. This working group will define a framework a  
> limited class of applications that deal with manipulation of simple  
> resources on devices on a CNet. This includes applications to  
> monitor simple sensors such as a temperature gauge, light switch, or  
> power meter and control an actuator such as a light switch, heating  
> system, or door lock. Typical uses include power management and  
> reporting, and home automation.
>
> The general architecture consists of nodes on the CNet, called  
> Devices, that have one or more Resources that represent sensors and  
> actuators. Devices send message to change and 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 and a notify approach to manipulating  
> resources. As part of the framework for building these applications,  
> the WG will define a CNet Application Protocol (CoAP) for  
> manipulation or 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 are possible.
>
> There are also nodes called PEPs (Performance Enhancing Proxy) that  
> gateway between the protocols typically used by the applications on  
> the Internet and the protocol used on the CNet. An application on  
> the general network can use HTTP REST to communicate with the PEP  
> which will use CoAP to manipulate the Resource on the Device. The WG  
> will define a mapping on the PEP from the CoAP to the a HTTP  REST  
> API. Each interface profile will define the Resources on the device  
> that application can manipulate and what manipulations are  
> possible.  This will determine the HTTP REST APIs on the PEPs and  
> the CoAP protocol encoding to manipulate the Resources on the Device  
> it will also specify an XML MINE type for each class of Device that  
> can be used to described the Resource state in the the body of HTTP  
> REST messages. The WG may also work on a mapping to SNMP on the PEP.  
> It is worth noting that the PEP does not have to be deployed at the  
> boundary of the CNet and the more general network but can be  
> deployed at various location in the network.
>
> The PEP boxes can provide various forms of "caching". For example,  
> if a temperature sensor is normally asleep but wakes up every five  
> minutes and sends the current temperature to the a PEP that  
> subscribed, when the PEP receives a request over HTTP for that  
> temperature resource, it can respond with the last seen value  
> instead of trying to query the Device which is currently asleep. The  
> PEPs may also provide support for discovering devices that may not  
> be currently responding as they are temporarily asleep.
>
> The initial work item of the WG are to define:
>
> 1) A requirements and architecture document that documents the high  
> level boxes and arrows view of the protocol along with high level  
> description of how the security, particular for commissioning of new  
> devices into the network will work. The WG may also produce a  
> document that describes various uses cases that help motivate the  
> requirements.
>
> 2) Specification of the framework for defining interface profiles  
> and the defining the CoAP. The CoAP will be able to set and query a  
> resource on a Device. It will allow a device to publish a value or  
> event to another Device. It will support a  non-reliable multicast  
> message to be sent to a group of devices to manipulate a resource on  
> all the devices simultaneously (roughly within 50 ms of each other).  
> The protocol will operate over UDP assuming a TBD byte payload and  
> assume an underlying network bandwidth of approximately TBD kbps.  
> The payload will be based on interface profile specific XML document  
> compressed with EXI.
>
> 3) Specification on how to use the CoAP to discover Devices on the  
> LoPAN and to interrogate them to find out which interface profiles  
> they support.
>
> 4) Specification for the HTTP REST based API on the PEP to  
> communicate with Devices.
>
> 4a) Possibly specify a separate specifications with mappings to  
> SNMP. [[NOte: In the BOF it would be nice to figure out if this is  
> in the charter or not.]]
>
> 5) A small set of basic interface profiles to illustrate how this is  
> done. Interface profiles will be done for a power meter, a light and  
> light switch, and temperature sensor.
>
> 6) A document with operation and management advice about running a  
> network using these applications.
>
> Security, particularly keying of new Devices, is very challenging  
> for these applications. On one hand this needs to support models  
> where an end user can introduce a new device onto their network that  
> may have no display or not input capability's. On the other end this  
> may transport information about alarm systems or controlling door  
> locks to a building over a wireless network.
>
> The CoAP protocol will support three commissioning methodologies.
>
> 1) Duckling mode. One device is put in a "mother duck" mode where it  
> listens for broadcasts of Devices trying to imprint. Other Devices  
> are put in a "duckling" mode where they broad cast to the "mother  
> duck" Device then "imprint" by forming a new shared secret between  
> the two Devices. Once this is complete the devices are taken out of  
> this mode and can be use in a secure fashion.
>
> 2) Out of Band Key mode. Each device in manufactured with an initial  
> symmetric key physically printed on the side in numeric and barcode  
> form. Alternatively the device could have a barcode that forms a URL  
> which when dereferenced with appropriate authorization provides a  
> secure access to the key. A human can enter or scan this into a  
> computer that can then be used form a secure connection with the  
> Device. Once a secure connection is formed, the symmetric key can be  
> changed.
>
> 3) Certificate mode. Each device is manufactured with a certificate  
> with an asymmetric key. The fingerprint of the certificate is  
> printed on a barcode. During commissioning, a computer can scan the  
> barcode, the connect to the device and replace the certificate with  
> a locally generated certificate that can be used for forming secure  
> connections.
>
> Modes 1 and 2 are mandatory to implement but mode 3 is option. 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.  
> This transitive trust introduction can be used during commissioning  
> even if A and B do not yet have network connectivity to each other.
>
> The CoAP will use CMS for object security. The WG will request the  
> security area define a subset of CMS along with an EXI encoding  
> instead of ASN.1 that is appropriate for a CNet network and for  
> theses types of devices. It will have one mandatory to implement  
> crytpo profile with no public key cryptograph to support modes 1 and  
> 2 and additional crypto profile with public key cryptograph for  
> support of mode 3. In mode 3, it will (or will not TBD) require  
> support for Elliptical Curve Cryptograph (ECC).
>
> The WG will coordinate on requirements from TBD (other SDO and  
> organizations). The WG will closing coordinate with other IETF WGs  
> including ROLL 6LowPAN and appropriate groups in OAM and Security.
>
> Milestone:
>
> Jan 2010 - Select WG document for basis of CoAP protocol
>
> Jun 2010 - Requirements and Architecture to IESG as Info
>
> Dec 2010 - Core protocol specification to IESG as PS
>
> Dec 2010 - HTTP Rest API mapping to IESG as PS
>
> Mar 2011 - Discovery specification to IESG as PS
>
> Mar 2011 - Specifications of basic interface profiles to IESG as PS
>
> Mar 2012 - Ops & Management advice to IESG as Info
>
>

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: [phone]

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.