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

[Cullen Jennings <[e-mail]>]

On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote:

> My comments:
>
> The charter seems to combine goals as well as architecture together  
> in one go. Probably can be simplified ? Specific comments below:
>
>
> On Thu, Oct 29, 2009 at 2:42 AM, Cullen Jennings <[e-mail]>  
> wrote:
>
>
> 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.
>
> ARC> We are implicitly stating that devices in a lowpan will have  
> simple management requirements (kind of like set/get mostly). I'd  
> like to see this group also consider (in terms of usecases) what are  
> the various control functions that are desirable, given an internet  
> connect ecosystem? I don't think we should assume that just because  
> most home control was mostly about simple on/off/read  till date,  
> that is what we should architect for. It is a minimal requirement,  
> but not complete by itself.

You bring up an important architecture consideration in design of a  
system like this. Roughly I think about the different levels of data/ 
transaction models we could have as going something like this

In order of complexity...

1) simple set of fixed variables that could be controlled

2) a single flat list of dynamically changeable set of variables that  
can can take on simple types (I might place IPFIX as being somewhat  
close to this model)

3) a hierarchical list of variables that can be related (I'd place  
basic usage SNMP roughly in this category but more advanced usage of  
SNMP probably can do category 4)

4) a REST based approach (I'd place HTTP REST in this case)

5) a full RPC model (I'd place CORBA in this class)

Every use case I have seen so far could be solved by 3, 4, or 5. I  
think most people have expressed an opinion that about 4 looks about  
the right level of flexibility for this. So the questions is, if there  
is pretty good agreement on that, then I think we should just roll  
with it as tentative decision and see what it starts looking like as a  
design evolves. As the design evolves, one may find this was a bogus  
choice and need to revisit it. If you think there is a strong argument  
for 3 or 5 or even 1 or 2, lets get that info out on the list.


>
>
>
> 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.
>
> ARC> I don't think HTTP to XX mapping should be assumed at this  
> stage. HTTP may be a popular protocol, but there could be others. So  
> a general goal of internet protocols to device control protocol  
> mapping is more suitable

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?

2) Given some people want HTTP, can you live with the answer to HTTP  
being yes and understanding that just because we said yes to HTTP does  
not mean we are saying no to everything else?


>
>
> 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.
>
> ARC> Is this needed as a part of the charter?

I don't know. I had someone I showed the charter to say, "but no I  
need a cache somewhere, these Device use low power" and I put this in  
to show that the PEP could be used this way.

>
>
> The initial work item of the WG are to define:
>
>
>
>
> 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.
>
> <etc>
>
> ARC> This seems to be a requirement specification of what a CoAP  
> should be. I think it should be left for a dedicated req doc, not as  
> part of a charter.

Fair enough. See my other thread on Architecture Sketch. I agree with  
you there are cons to doing something like this in the charter.

>
>
> -- 
> Arjun Roychowdhury
>