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

["Don Sturek" <[e-mail]>]

Sorry for the resend...   First one was with the wrong e-mail account.

Don


-----Original Message-----
From: Don Sturek 
Sent: Thursday, October 29, 2009 7:37 AM
To: 'Cullen Jennings'; [e-mail]
Cc: Zach Shelby; Carsten Bormann; Lisa Dusseault
Subject: RE: Proposed charter for 6LoWAPP BOF

Hi Cullen,

Overall, the proposed charter looks interesting.

On the Commissioning methods, I think making the "Duckling" mode mandatory
as indicated in the text below should not be decided in the charter.
Unless this commissioning method has undergone some form of security review,
it could well be something we (at least in Smart Energy) cannot use.  It
would be a shame to waste code space for something like this.

While we (again Smart Energy) are looking at a RESTfull HTTP architecture,
it would be good to point out that this is only one option.  It would be
nice to see if other popular communication solutions can work as well.

One more thng:   The discussion below indicates two level of communication:
PEPs and CoAps.   I would hope we could avoid this.  It would be nice to
address and communicate with CoAp devices as you would with any other device
on the internet whether a PEP was present or not.  I would not want to have
the group focused on this type of gateway approach.

Overall though this was a good start for the charter.

Don


-----Original Message-----
From: Cullen Jennings [mailto:[e-mail]] 
Sent: Wednesday, October 28, 2009 11:43 PM
To: [e-mail]
Cc: Zach Shelby; Carsten Bormann; Don Sturek; Lisa Dusseault
Subject: Proposed charter for 6LoWAPP BOF


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