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

From: Zach Shelby <[email-masked]>
Date: Sun, 1 Nov 2009 15:47:31 +0200

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: +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: Sun, 1 Nov 2009 15:52:13 +0200

On Nov 1, 2009, at 2:15 , Don Sturek wrote:

> Hi Cullen,
>
> One important use case to consider:
> 1)  Devices to manage are running on 6LowPAN (using some 6LowAPP  
> defined
> protocol).   Controlling devices are running someplace on the wider
> internet.

This is common in building management and most M2M applications as well.

> 2)  Does this mean that the scope of protocol work in 6LowAPP needs to
> identify this type of control as a valid use case?

Definitely! However we don't need to require the controlling device to  
speak CoAP (although it could). More likely there is a proxy somewhere  
between.

> 3)  Does the use of 6LowAPP protocols on the wider internet need to  
> then be
> in the scope of 6LowAPP?

Yes. This is IP, so the CoAP protocol can be used over any IP  
networks. If you need a proxy, it can be located anywhere. We should  
assume that CoAP will mainly be used in the constrained or application- 
specific domain.

Zach

>
> Don
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf
> Of Cullen Jennings
> Sent: Saturday, October 31, 2009 10:29 AM
> To: Jukka Manner
> Cc: Don Sturek; [email-masked]
> Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF
>
>
> On Oct 29, 2009, at 8:20 , Jukka Manner wrote:
>
>> 1. This seems to indicate that 6lowapp will not be tied to any
>> existing work, it will work on its own goals, but in collaboration
>> with others (which is somewhat open as what it means). I would have
>> expected that 6lowapp would specifically look at existing work in
>> related WGs and see how build on top of that.
>
> My mistake - I did not mean to imply that it was not layered on top of
> closely related existing work. I think most people assumed that this
> would run on top of a LoPAN but it seemed they also wanted it to be
> able to run on top of a other things including a normal IP LAN and
> WAN. Clearly this is all about same use cases as 6LoPAN and ties
> closing with 6LoPAN and ROLL as well as work going on at many other
> SDOs. However, I'm not sure what needs to be said. Are WG drafts with
> use case / requirements from other WG that we should be referencing?
> Give me ideas on what things you were thinking here. Clearly the IESG
> would not be keen on chartering a new WG to do something another WG
> was already charted to do - repeating work in two places seldom ends
> well :-) Can you suggest some specific text for the charter that you
> think would have fairly wide consent and captures what you are looking
> for here?
>
>
> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp
>
> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp

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

---

From: "Don Sturek" <[email-masked]>
Date: Sun, 1 Nov 2009 05:55:10 -0800

Hi Zach,

I am still hoping we don't have a proxy (or gateway).  Ideally, we can
define at least an application transport protocol that can work natively in
CoAp and be mainstream enough to be supported in the wider internet.

As soon as we say there is a proxy or gateway required, we will get pushback
from device manufacturers who don't want the added cost on their devices.

Don

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: Sunday, November 01, 2009 5:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

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

---

From: Zach Shelby <[email-masked]>
Date: Sun, 1 Nov 2009 17:12:40 +0200

Hi,

> CoAp and be mainstream enough to be supported in the wider internet.

I think we agree. The CoAP protocol (whatever it will be) could  
definitely be used on the wider Internet. If your controlling device/ 
server speaks CoAP, then voi la. If we do our job well, and this  
becomes standard for M2M use, then you will easily find CoAP support.

> from device manufacturers who don't want the added cost on their  

This definitely should not require a proxy, but as pointed out in  
other mails, there are reasons you may use proxy technology. Even if  
you would implement this with plain HTTP/1.1 you would use a proxy in  
most cases. But this isn't an issue for device manufacturers by any  
means! As we are dealing with IP, a proxy may be located on the  
backend network somewhere e.g. as a component on  any application  
server.

On the flip-side, if we require embedded devices to speak directly  
with unmodified HTTP/1.1 web servers, then we really will be adding  
cost, if it even works at all. This is the situation today, and the  
reason for so many proprietary protocol and field-bus solutions.

It sounds like we basically agree here?

Zach

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

---

From: Paul Duffy <[email-masked]>
Date: Sun, 01 Nov 2009 12:23:09 -0500

Hi Donn,

> We welcome other suggestions like XMPP and SIP but we did look at those and
> ruled them out for reasons like:
> 1)  Verboseness (using text string exchanges for devices with very small
> transmit/receive packet sizes)
> 2)  Session management overhead
>   

SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered 
intent.

But XMPP gives me pause...

- would not an EXI encoding go a long way to alleviate the verbosity issues?

- RESTful HTTP is a fine choice, but there are requirements for more 
than just request/response messaging patterns in the Smart Grid HAN and 
NAN.  XMPP would offer request/response (sensor reading), pub/sub 
(broadcast announcements), one way async (scheduled reads), presence for 
endpoint status, etc.

- how is XMPP session management any more onerous that HTTP over TLS?  
This assuming of course that TCP is doable.

Cheers

---

From: Vlad Trifa <[email-masked]>
Date: Sun, 1 Nov 2009 18:29:22 +0100

Hello,

I think for Web messaging there are very nice Web push patterns  
emerging (comet, pubsubhubbub, restms) that are worth considering.  
Sure, work is needed for reliability and security, but the entry  
barrier is much lower than xmpp, and its actually more suited for  
devices with similar features but less verbose which makes that  
solution appealing. I'm sending a paper to WWW about Web based  
messaging, hopefully I'll be able to share it with you soon (if I kick  
my butt enough to get back to work and finish it by tomorrow's  
deadline :)

Vlad

On Nov 1, 2009, at 6:23 PM, Paul Duffy wrote:

> SIP in the Smart Grid HAN seems a fundamental misfit to SIPs  
> chartered intent.
>
> than just request/response messaging patterns in the Smart Grid HAN  
> and NAN.  XMPP would offer request/response (sensor reading), pub/ 
> sub (broadcast announcements), one way async (scheduled reads),  
> presence for endpoint status, etc.
>
> - how is XMPP session management any more onerous that HTTP over  
> TLS?  This assuming of course that TCP is doable.
>
> Cheers
>
>
>> Don
>>
>>
>>
>>
>

---

From: "Don Sturek" <[email-masked]>
Date: Sun, 1 Nov 2009 09:50:56 -0800

Hi Paul,

Yes, XMPP would be quite interesting if the text exchange could be avoided.

Can we add this possibility to our CoAp charter as a application transport
possibility?

Don

-----Original Message-----
From: Paul Duffy [mailto:[email-masked]] 
Sent: Sunday, November 01, 2009 9:23 AM
To: [email-masked]
Cc: 'Cullen Jennings'; [email-masked]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

Hi Donn,

Cheers

---

From: Vlad Trifa <[email-masked]>
Date: Sun, 1 Nov 2009 19:33:44 +0100

Hi,

> you would implement this with plain HTTP/1.1 you would use a proxy  
> in most cases. But this isn't an issue for device manufacturers by  
> any means! As we are dealing with IP, a proxy may be located on the  

I think we shouldn't oblige people to use gateways, and manufacturers  
that want their device to plug-and-play should not need to hope for  
gateway. In our work, we see gateways as good to have goodies that can  
help adding nice features that shouldn't be supported at the device- 
level (access control, caching, masking failures, request buffering  
and caching). HTTP wouldn't necessarily mean UI - just API access.  
Gateways could serve as simple intermediaries to enable more  
meaningful interaction with device for end-users (think of home wifi  
routers that could offer nice management and mobile control/access to  
home networks, what nokia control center kind of does).

On the other hand it's hard to think that "gateways" will hardly ever  
disappear, if not for protocol translation at least for routing across  
physical interfaces. If gateways can do some distributed processing  
besides just routing packets, one could build more scalable  
infrastructures.

The thing for the proprietary protocols imho is that each manufacturer  
wants a little part of the market pie but also due to constraints on  
devices optimized solutions were needed for different solutions/apps,  
just like IP on devices didn't make sense 7 years ago. As an  
illustration more and more devices have already tiny web servers  
nowadays, so not much would be needed to RESTify them.

Based on our tests, I hardly see the functional limitations of http  
for interacting with devices, other than extra verbosity/latency,  
which in many scenarios doesn't have a huge impact on user experience  
(especially, for many scenarios we're considering here, if we get data  
in 0.5 seconds instead of 0.1 second doesn't hurt much). Please let me  
know some counter examples you would have.

Vlad

> 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: Sun, 1 Nov 2009 23:04:04 +0200

> Yes, XMPP would be quite interesting if the text exchange could be  

I think it should be possible to use an encoded XMPP over CoAP (so in  
the payload of CoAP). The XMPP model doesn't seem like an option for  
CoAP itself, as it would a) require the same encoding for everything,  
b) requires you to parse the whole thing to know what the heck it is  
and c) assumes a stream and thus TCP.

> Can we add this possibility to our CoAp charter as a application  

I think the charter could mention XMPP as something that can be run  
over the framework or be integrated with. The charter doesn't need to  
say what the solution for CoAP is yet, but rather concentrate on what  
it should achieve. As of now it is agnostic about that, which is good.

There was an important point by Paul below that the interaction models  
offered by HTTP are not sufficient, and I totally agree. CoAP can't be  
limited to only request/response and unicast interactions. So is this  
like REST+?

Zach

>> We welcome other suggestions like XMPP and SIP but we did look at  
>> those
> and
> and

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

---

From: Arjun Roychowdhury <[email-masked]>
Date: Sun, 1 Nov 2009 16:07:03 -0500

On Sat, Oct 31, 2009 at 12:29 PM, Cullen Jennings <[email-masked]> wrote:

>
> On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote:
>
> 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.

ARC> Right. If every use case can be solved by 4, and if an HTTP UA stack is
not an overkill for these devices, then I'd venture out to say that if the
need exists, then we should have a protocol that serves that need. My
argument is for something inbetween 4) and 5) - that is some session
oriented protocol, if one believes there will be sessions and an offer
answer needed. I mention SIP only because that is the one I know well. I am
not religious about SIP, but I am particular about a need.

And now, here is why some of us are putting across the fact that at the
least SIP needs to be evaluated:
(And I know you are well aware of SIP yourself, but I am putting some of
these across for others who may not be)

a) Size/Performance: Simply put, if an HTTP UA is ok, then a minimalistic
SIP UA not being ok is highly suspect. I doubt folks making this statement
have actually evaluated how much a session oriented protocol can be reduced
when it comes to implementation. I've personally worked on SIP UAs that
compress to 30K or less. How much of features you want to put in depends on
the network. Given a network, you can feature compromise. This entire
argument of verbosity vs. optimization is doubtful until you lay down
specific #s that need to be met (and why those #s exist)

b) Can SIP do everything HTTP can?: First, SIP can offer everything HTTP
can. Payloads? check. URI addressing schemes and REST based services. Check.
(http://myhome.com?remote=channel12 can be
sip:[email-masked]<[email-masked]>;channel=12)
etc.

c) What can SIP do better than HTTP?
c.1) Offer-Answer, capability, discovering the minimal feature set that
works between two or more devices

c.2) SIP works on more transport protocols than HTTP (yes, I am aware of
HTTP over UDP, but if we look at live deployments, almost all HTTP systems
use TCP. So if there is a communication needed from a non TCP network to
your HAN, welcome gateways. Almost all SIP deployments I know of today do
both TCP and UDP.)

c.3) Routing & Reachability: SIP's architecture of loose routing, forking,
etc.

c.4) Concept of a 'session' & 'session control' - SIP establishes a session
between one or more devices. These sessions can be transferred to any other
entity if required, monitored, or modified.

Basically, SIP is  HTTP+Sessions and an architecture to manage sessions.

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?
>
>
ARC> 1) SIP.
2) Yes.

-- 
Arjun Roychowdhury

---

From: Arjun Roychowdhury <[email-masked]>
Date: Sun, 1 Nov 2009 16:12:44 -0500

responding from my subscribed email id incase the previous one does not make
it to this list:

>> But XMPP gives me pause...
ARC> Why is that so? SIP is a protocol to communicate between one or more
entities. The fact that it was originally designed to communicate between
users is much less important compared to the benefits its architecture
brings in. If people use SIP to create a recvonly session with an IP camera
in their house to monitor security from their IMS (SIP) enabled cell phone,
how is that different from controlling any other device?

-- 
Arjun Roychowdhury

---

From: Shidan <[email-masked]>
Date: Sun, 1 Nov 2009 17:44:02 -0400

Hi Vlad,  I think a good question to ask yourself is why all of these
patterns are being created on the web, whether comet, Ajax, PubHubSub, or
actually why there is a need by the web community and the IETF to create
whole new protocols like WebSockets and Adobe Flash's TCP sockets.

The reason is because this is how the web has evolved. If it wasn't for the
business competition and related politics, I really doubt the evolution of
the web browser to being a standardized OS would be the case, which is where
we are headed. Thankfully, right now we don't have this problem with the
"Internet of Things" and the truth is, this working group will be an
important influencer of the IoT's evolution.

If you choose to follow the architectures you specify, at some point it's
going to look more like XMPP or SIP,  the only difference being you will
actually be defining all these things in the body and with more complicated
call flows. This is why new trends of the real time web should not
necessarily be a model for everything else for everything else in IT.
So I think a good analogy is we can build a web browser in assembly
language, but that wouldn't be the best route to building a good product.

I think we have to realize, putting away the immense role it had for
circumventing bad politics,  the web's real technical contribution, and
probably one of the most important, was a practical implementation of linked
data and hyperlinks. I think this will remain a major enabler of any
pervasive and global M2M application and this higher layer will not be in
the scope of the IETF just as much a the DOM isn't.

On Sun, Nov 1, 2009 at 1:29 PM, Vlad Trifa <[email-masked]> wrote:

> Hello,
>
> I think for Web messaging there are very nice Web push patterns emerging
> (comet, pubsubhubbub, restms) that are worth considering. Sure, work is
> needed for reliability and security, but the entry barrier is much lower
> than xmpp, and its actually more suited for devices with similar features
> but less verbose which makes that solution appealing. I'm sending a paper to
> WWW about Web based messaging, hopefully I'll be able to share it with you
> soon (if I kick my butt enough to get back to work and finish it by
> tomorrow's deadline :)
>
> Vlad
>
>
>> - RESTful HTTP is a fine choice, but there are requirements for more than
>> just request/response messaging patterns in the Smart Grid HAN and NAN.
>>  XMPP would offer request/response (sensor reading), pub/sub (broadcast
>> announcements), one way async (scheduled reads), presence for endpoint
>> status, etc.
>>

---

From: Shidan <[email-masked]>
Date: Sun, 1 Nov 2009 17:59:56 -0400

Hi Paul. XMPP definitely would be a great fit for this space and I would
definitely be a backer of that. But can you expand on why you think SIP
would be any less relevant for all those points you mention. I think what
would be instructive is to have an actual concrete matrix of the proposed
RESTful protocol, SIP and XMPP for just a couple of simple use cases and
call flows see exactly where it is that XMPP and SIP, if they are binary
encoded, don't meet the requirements of LoWPANs  and actually see which ones
are in fact the better choice.

On Sun, Nov 1, 2009 at 1:23 PM, Paul Duffy <[email-masked]> wrote:

> - how is XMPP session management any more onerous that HTTP over TLS?  This
> assuming of course that TCP is doable.
>
> Cheers
>
>
>
>  Don
>>
>>
>>
>>
>>
>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Sun, 1 Nov 2009 22:56:09 -0600

Are there any use cases which require session to be established between
the devices?

I am new to this community, but from the discussions that I have seen so
far, looks like most of the use cases require a request-response
transaction and not a session between two devices or groups of devices.
I am also not sure about real time properties that the applications in
this space will have, for which SIP can be used.

I would think that SIP event notification mechanism can be used for
things like monitoring the temperature, usage etc. 

I am not saying SIP can not be used and I do not have a very good
knowledge of use cases, but I think a starting point would be to come up
with some scenarios where session characteristics can be used.

Sanjay

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Arjun Roychowdhury
Sent: Monday, November 02, 2009 2:37 AM
To: Cullen Jennings (fluffy)
Cc: Don Sturek; [email-masked]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

On Sat, Oct 31, 2009 at 12:29 PM, Cullen Jennings <[email-masked]>
wrote:

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)

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.

ARC> Right. If every use case can be solved by 4, and if an HTTP UA
stack is not an overkill for these devices, then I'd venture out to say
that if the need exists, then we should have a protocol that serves that
need. My argument is for something inbetween 4) and 5) - that is some
session oriented protocol, if one believes there will be sessions and an
offer answer needed. I mention SIP only because that is the one I know
well. I am not religious about SIP, but I am particular about a need. 

a) Size/Performance: Simply put, if an HTTP UA is ok, then a
minimalistic SIP UA not being ok is highly suspect. I doubt folks making
this statement have actually evaluated how much a session oriented
protocol can be reduced when it comes to implementation. I've personally
worked on SIP UAs that compress to 30K or less. How much of features you
want to put in depends on the network. Given a network, you can feature
compromise. This entire argument of verbosity vs. optimization is
doubtful until you lay down specific #s that need to be met (and why
those #s exist)

b) Can SIP do everything HTTP can?: First, SIP can offer everything HTTP
can. Payloads? check. URI addressing schemes and REST based services.
Check. (http://myhome.com?remote=channel12 can be sip:[email-masked]
<mailto:[email-masked]> ;channel=12) etc.

c.2) SIP works on more transport protocols than HTTP (yes, I am aware of
HTTP over UDP, but if we look at live deployments, almost all HTTP
systems use TCP. So if there is a communication needed from a non TCP
network to your HAN, welcome gateways. Almost all SIP deployments I know
of today do both TCP and UDP.)

c.3) Routing & Reachability: SIP's architecture of loose routing,
forking, etc. 

c.4) Concept of a 'session' & 'session control' - SIP establishes a
session between one or more devices. These sessions can be transferred
to any other entity if required, monitored, or modified.

	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?

ARC> 1) SIP. 

2) Yes. 

-- 
Arjun Roychowdhury

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Sun, 1 Nov 2009 22:59:51 -0600

I think Paul is talking about verbose nature of SIP and also the parsing
of headers and message body that is required and whether the processing
cost fits into the requirement for low power embedded devices.

Sanjay 

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Arjun Roychowdhury
Sent: Monday, November 02, 2009 2:43 AM
To: Paul Duffy (paduffy)
Cc: [email-masked]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

responding from my subscribed email id incase the previous one does not
make it to this list:

On Sun, Nov 1, 2009 at 4:09 PM, Arjun Roychowdhury <[email-masked]>
wrote:

 

ARC> Why is that so? SIP is a protocol to communicate between one or
more entities. The fact that it was originally designed to communicate
between users is much less important compared to the benefits its
architecture brings in. If people use SIP to create a recvonly session
with an IP camera in their house to monitor security from their IMS
(SIP) enabled cell phone, how is that different from controlling any
other device?

-- 
Arjun Roychowdhury

---

From: Shidan <[email-masked]>
Date: Mon, 2 Nov 2009 00:18:51 -0500

Yes, we actually have discussed in depth many use cases and something on
both my plate and Arjun's is to share use cases and and a white paper with
this group on benefits of using a binary SIP protocol. We will include a
matrix of summarizing some of the concerns that members of this group have
shown with real numbers, which is something I think is really needed.
Hopefully this will be of help to the group in Hiroshima.

"I think Paul is talking about verbose nature of SIP and also the parsing of
headers and message body that is required and whether the processing cost
fits into the requirement for low power embedded devices."

This is valid a valid concern and I think after understanding the system we
are proposing, you will be pleasantly surprised.

---
Shidan Gouran

On Sun, Nov 1, 2009 at 11:56 PM, Sanjay Sinha (sanjsinh) <[email-masked]

> far, looks like most of the use cases require a request-response transaction
> and not a session between two devices or groups of devices.  I am also not
> sure about real time properties that the applications in this space will
> have, for which SIP can be used.
>
>
>
> I would think that SIP event notification mechanism can be used for things
> like monitoring the temperature, usage etc.
>
>
>
> I am not saying SIP can not be used and I do not have a very good knowledge
> of use cases, but I think a starting point would be to come up with some
> scenarios where session characteristics can be used.
>
>
>
> Sanjay
>
>
>
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Arjun Roychowdhury
> *Sent:* Monday, November 02, 2009 2:37 AM
> *To:* Cullen Jennings (fluffy)
> *Cc:* Don Sturek; [email-masked]
>
> *Subject:* Re: [6lowapp] Proposed charter for 6LoWAPP BOF
>
>
>
>
>
> ARC> Right. If every use case can be solved by 4, and if an HTTP UA stack
> is not an overkill for these devices, then I'd venture out to say that if
> the need exists, then we should have a protocol that serves that need. My
> (http://myhome.com?remote=channel12 can be sip:[email-masked]<[email-masked]>;channel=12)
> etc.
>
>
>

---

From: Jukka Manner <[email-masked]>
Date: Mon, 02 Nov 2009 11:20:57 +0200

My main point was that if you read the charter text as it is written, it 
seems to imply that the work will be something new, and not necessarily 
targeted to sensor networks, but more generic.

I would have put into the charter something that directly ties the WG to 
existing work, e.g.

"It is not the intention of 6lowapp to work on new transport and routing 
solutions [for sensor networks or whatever constraint environments]. The 
work is specifically tied to and intended to be layered on top of 
existing work done in the 6lowpan and Roll working groups, to name a few."

cheers,
Jukka

Cullen Jennings wrote:
> would run on top of a LoPAN but it seemed they also wanted it to be able 
> to run on top of a other things including a normal IP LAN and WAN. 
> Clearly this is all about same use cases as 6LoPAN and ties closing with 
> 6LoPAN and ROLL as well as work going on at many other SDOs. However, 
> I'm not sure what needs to be said. Are WG drafts with use case / 
> requirements from other WG that we should be referencing? Give me ideas 
> on what things you were thinking here. Clearly the IESG would not be 
> keen on chartering a new WG to do something another WG was already 
> charted to do - repeating work in two places seldom ends well :-) Can 
> you suggest some specific text for the charter that you think would have 
> fairly wide consent and captures what you are looking for here?
> 
>

---

From: Arjun Roychowdhury <[email-masked]>
Date: Sun, 1 Nov 2009 16:09:49 -0500

---

From: Paul Duffy <[email-masked]>
Date: Mon, 02 Nov 2009 10:58:45 -0500

Sanjay Sinha (sanjsinh) wrote:
>
> I think Paul is talking about verbose nature of SIP and also the 
> parsing of headers and message body that is required and whether the 
> processing cost fits into the requirement for low power embedded devices.
>

That's only part of the issue.  HAN will need req/resp, pub/sub, async 
one way messaging patterns, etc..  Req/resp RPC starts to get pretty 
weird over SIP.  Whereas it is a fully supported pattern in XMPP world.

> *Sent:* Monday, November 02, 2009 2:43 AM
> *To:* Paul Duffy (paduffy)
> *Cc:* [email-masked]
> responding from my subscribed email id incase the previous one does 
> not make it to this list:
>
> On Sun, Nov 1, 2009 at 4:09 PM, Arjun Roychowdhury <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>      
>

---

From: Arjun Roychowdhury <[email-masked]>
Date: Mon, 2 Nov 2009 11:17:03 -0500

Some notes:

HAN will need req/resp,

ARC> SIP: MESSAGE/OK, OPTIONS/OK
In addition, SIP can exchange these as part of a session, or out of it.

pub/sub,

ARC> SIP: SUBSCRIBE/NOTIFY/PUBLISH

async one way messaging patterns, etc..

ARC> SIP: Implicit notifications (3GPP uses it, for example), but yes, specs
do require an OK in response. I am interested in this part. When you mean
one way, you mean no return acknowledgement from the peer at the application
level? What sort of scenarios is that required for?

 Req/resp RPC starts to get pretty weird over SIP.  Whereas it is a fully
supported pattern in XMPP world.

ARC> Only if you tag the word RPC after request response :) On the other
hand if one views it as a SIP message with an XML payload, then it fits
perfectly.

regds
arjun

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 2 Nov 2009 22:44:16 -0700

On Nov 2, 2009, at 2:20 AM, Jukka Manner wrote:

> "It is not the intention of 6lowapp to work on new transport and  
> routing solutions [for sensor networks or whatever constraint  
> environments]. The work is specifically tied to and intended to be  
> layered on top of existing work done in the 6lowpan and Roll working  
> groups, to name a few."

Great text. That's what I was sort of thinking but failed to say.  
Let's get that in the next version.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 2 Nov 2009 22:46:33 -0700

On Oct 31, 2009, at 12:33 PM, Shidan wrote:

> Hi Cullen, I would check the motivational draft Arjun and I  
> submitted for SIP.
>
> 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
>
> In general there are many practical applications which are using SIP  
> and XMPP for M2M communications. This should be a consideration.

there seem a fair amount of agreement on this - will add to the list.