Subject: [6lowapp] Newbie questions

From: Kerry Lynn <[email-masked]>
Date: Mon, 2 Nov 2009 08:32:22 -0500

Greetings,

My name is Kerry Lynn and I hope to contribute to this effort remotely.  I
am an independent contractor working in the area of building automation
and have worked previously in Cisco and Apple network engineering in
addition to supporting university research into constrained devices.  I
hope you will bear with what may be foolish questions as I come up to
speed:

I tried to access the audio stream and jabber feed from yesterday's
meeting but was unable to do so.  Is IETF registration necessary?

Is it the consensus of the group to support peer-to-peer as well as
server-based configurations?  The first is what I'd term the "one light,
one switch" scenario while the latter would include DHCP, DNS, etc.
and perhaps application proxy support.

Has anyone considered something like T/TCP as a candidate for
transaction support?  I know it has been traditionally implemented
as a superset of TCP but I suspect it could be much simpler than
full TCP if used in a controlled environment such as local
communication with a full TCP/HTTP/REST proxy.  The security
concerns could be addressed simultaneously.

Has anyone proposed mDNS/DNS-SD as an alternative to SLP?
Does anyone have a feeling for how one client implementation
compares to the other in terms if complexity?

Thanks, -K-

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 2 Nov 2009 06:16:44 -0800

Hi Kerry,

Here is the big problem we keep coming up against in service discovery:
1)   Most agent based solutions are deeply unpopular by HAN device
manufacturers.

Here is why:
1)  Many different vendors contribute to devices in the home area network
(HAN)
2)  No vendor of device "X" wants to have to increase their storage and
computing capacity to become the repository of service information for all
other devices in the network.
3)  HANs are not managed networks where some owning entity would place
infrastructure devices

Note what I wrote above is for the home area network (HAN).  Building
automation is another story as there is certainly a building control system
in place there.

The simplest solution for this for the HAN:  Allow individual devices to
hold their own service information and provide a unicast/multicast query
system to allow for self description of service information.  Allow for
individual devices on the HAN to form their own queries and get direct
responses back from devices matching those service requests.

For the I-D I turned in for service discovery, I did use the SLP DA
(Directory Agent, I believe) to hold the strings (URI plus service) and had
the DA responsible for substituting those for tokens upon request.  However,
I had in mind that would be all the DA would do and all service discovery
was UA (User Agent) based.

For a building controls solution (commercial or industrial), the DA could be
fully populated an used on the building control system......

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Kerry Lynn
Sent: Monday, November 02, 2009 5:32 AM
To: [email-masked]
Subject: [6lowapp] Newbie questions

Greetings,

Thanks, -K-
_______________________________________________
6lowapp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowapp

---

From: Lars Eggert <[email-masked]>
Date: Mon, 2 Nov 2009 16:13:39 -0800

> concerns could be addressed simultaneously.

T/TCP could be an option, if its security/DoS drawbacks are not  
considered to be an issue in these scenarios.

Lars

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 2 Nov 2009 23:06:19 -0700

Hi Kerry,

All the IETF meeting should be open and you can join them and we  
welcome your participation. There's really no such thing as "member"  
of the IETF, just individuals that participate. I could be confused,  
but I don't think there was a meeting yesterday. If there was any sort  
of official IETF meeting, you should have been able to join it.

Cullen

---

From: Zach Shelby <[email-masked]>
Date: Tue, 3 Nov 2009 08:18:54 +0200

Hi,

(New thread title)

With regards to service discovery and CoAP, the question is do we need  
full-blown service discovery at all for such constrained networks and  
devices in this WG?

Looking at the requirements and discussions so far, the conclusion we  
had is that the same CoAP protocol can easily be used for exchanging  
service information (profiles) in a distributed manner, but allowing  
for a DA-like entity to exist if needed. DPWS uses a similar approach.

The current proposed CoAP charter text takes this simple approach.  
Define a discovery interface and a simple profile format using the  
same protocol. For constrained nodes this makes sense, no requirement  
to implement a separate protocol. This is also extensible for vendors  
or other standards (e.g. DPWS, oBIX) to extend profiles.

I am not saying that general service discovery mechanisms are not  
useful some day (SLP, mDNS, UPnP etc.). There could be a future spin- 
off or re-charter for this work. But looking at the current  
applications and requirements on the table - what the charter is  
suggesting is good enough and will demand the least effort.

Thoughts?

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

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: "Don Sturek" <[email-masked]>
Date: Tue, 3 Nov 2009 06:16:18 -0800

Hi Zach,

I haven't yet seen a service discovery solution that is usable for small
footprint devices (SSDP, SLP, DPWS, etc.).  All use text strings (which will
translated to multiple packets) or directory agents in the network which are
not popular in unmanaged networks

Do you have any other references?  Is there something I missed with one of
these technologies?

I see service discovery as a hard requirement in unattended networks.

Don

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: Monday, November 02, 2009 10:19 PM
To: [email-masked]
Cc: 'Kerry Lynn'; [email-masked]
Subject: Re: [6lowapp] Discovery

Hi,

(New thread title)

Thoughts?

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: Tue, 3 Nov 2009 23:33:29 +0200

> not popular in unmanaged networks

Agreed.

What I am saying is that a much simpler discovery mechanism is enough  
to fulfill the requirements I have seen. We don't need a full-blown  
discovery of anything using any protocol for any device now. We just  
need a built-in discovery mechanism for what interfaces are available  
for this protocol, and optionally extra meta-info about those  
interfaces or the device.

> Do you have any other references?  Is there something I missed with  

A few examples:
- DPWS has a model of using the application protocol (HTTP or SOAP- 
over-UDP) to offer device profiles. Discovery could be supported in a  
similar way, but much simpler in CoAP.
- Web interfaces can be described in many standard ways already, e.g.  
WADL or WSDL. And of course the URL itself already describes a lot.
- It is normal practice to make these web interface descriptions  
available on a well-known interface, so that they can be used. For  
example REST designers often make the WADL description available on / 
wadl.
- The SENSEI project has implemented a mechanism like this (draft- 
gold-6lowapp-sensei).
- Tons of other protocols have simple built-in interface discovery.

We don't have to decide exactly how to do it now, but I don't see it  
being a hard problem.

> I see service discovery as a hard requirement in unattended networks.

I totally agree.

But by just defining a couple REST interfaces and a generic, compact  
format for e.g. URL and interface desc info, you can build that into  
the protocol (as a well-known interface) just as is normal practice on  
the web.

This is basically what the charter says right now, define a simple  
discovery mechanism using the CoAP protocol supporting profiles. We  
don' t have to decide exactly how to do it, but we should have the  
general goals in there (unattended, peer-to-peer, no DA required,  
profiles extensible).

General service discovery could be future work for re-chartering?

Zach

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

---

From: Vlad Trifa <[email-masked]>
Date: Wed, 4 Nov 2009 10:18:51 +0100

Hello,

just my thoughts about the discovery. Wouldn't it make sense to  
somewhat decouple the physical (network-level) discovery (eg.ws- 
discovery, bonjour) from the actual use of the device and the  
semantics describing the device API in possible high-level format  
(WADL, etc)? This allows to offer different more or less elaborate  
description of how to use devices, and having a transparent discovery  
mechanism (I doubt it's difficult to oblige manufacturers to implement  
a single discovery standard). In particular, this would allow to find/ 
understand/use devices that do not have a network discovery mechanism,  
for example by entering it's wadl url in an application manually.

Another comment, I think that attaching semantics to urls (ie. hard- 
wiring commands as tags in the URL, with /wadl as Zach proposed) is  
not the best way to go, because it's a little against the REST design  
principle (because this basically defines a protocol on top of REST  
that all devices shall adopt - nothing wrong with that inherently and  
it would work - but requires to push such a standard based on uri  
schemas for all devices, which might be a bitter pill to swallow :)

Vlad

On Nov 3, 2009, at 10:33 PM, Zach Shelby wrote:

> What I am saying is that a much simpler discovery mechanism is  
> enough to fulfill the requirements I have seen. We don't need a full- 
> blown discovery of anything using any protocol for any device now.  
> We just need a built-in discovery mechanism for what interfaces are  
> available for this protocol, and optionally extra meta-info about  
> those interfaces or the device.
>
>>
> over-UDP) to offer device profiles. Discovery could be supported in  
> a similar way, but much simpler in CoAP.
> - Web interfaces can be described in many standard ways already,  
> e.g. WADL or WSDL. And of course the URL itself already describes a  
> lot.
> the protocol (as a well-known interface) just as is normal practice  
> on the web.
>
> 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: Wed, 4 Nov 2009 11:33:27 +0200

Hi Vlad,

On Nov 4, 2009, at 11:18 , Vlad Trifa wrote:

> description of how to use devices, and having a transparent  
> discovery mechanism (I doubt it's difficult to oblige manufacturers  
> to implement a single discovery standard). In particular, this would  
> allow to find/understand/use devices that do not have a network  
> discovery mechanism, for example by entering it's wadl url in an  
> application manually.

Yep, that is the idea here.

> not the best way to go, because it's a little against the REST  
> design principle (because this basically defines a protocol on top  
> of REST that all devices shall adopt - nothing wrong with that  
> inherently and it would work - but requires to push such a standard  
> based on uri schemas for all devices, which might be a bitter pill  
> to swallow :)

Just an example of how some people do it. It doesn't matter when the  
exact solution is yet. Now we just need the charter to give he  
guidelines of what we are working on.

I think we agree that we do not need general service discovery here  
yet, just an interface discovery technique?

Zach

>> enough to fulfill the requirements I have seen. We don't need a  
>> full-blown discovery of anything using any protocol for any device  
>> now. We just need a built-in discovery mechanism for what  
>> interfaces are available for this protocol, and optionally extra  
>> meta-info about those interfaces or the device.
>>
>>>
>> example REST designers often make the WADL description available  
>> on /wadl.
>> We don't have to decide exactly how to do it now, but I don't see  
>> it being a hard problem.
>>
>>>
>> But by just defining a couple REST interfaces and a generic,  
>> compact format for e.g. URL and interface desc info, you can build  
>> that into the protocol (as a well-known interface) just as is  
>> normal practice on the web.
>>
>>>> automation is another story as there is certainly a building  
>>>> control
>>>> system
>>>> in place there.
>>>>
>>> contain
>> recipient, please contact the sender and delete the e-mail from  
>> your system without producing, distributing or retaining copies  
>> thereof.
>>
>>
>>

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