Re: [6lowapp] Discovery

[Zach Shelby <[e-mail]>]

Hi Vlad,

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

> 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.

Yep, that is the idea here.

>
> 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 :)

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

>
> Vlad
>
>
> On Nov 3, 2009, at 10:33 PM, Zach Shelby wrote:
>
>>
>> On Nov 3, 2009, at 16:16 , Don Sturek wrote:
>>
>>> 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
>>
>> 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 one of
>>> these technologies?
>>
>> 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
>>
>>>
>>> Don
>>>
>>>
>>> -----Original Message-----
>>> From: Zach Shelby [mailto:[e-mail]]
>>> Sent: Monday, November 02, 2009 10:19 PM
>>> To: [e-mail]
>>> Cc: 'Kerry Lynn'; [e-mail]
>>> Subject: Re: [6lowapp] Discovery
>>>
>>> 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
>>>
>>> On Nov 2, 2009, at 16:16 , Don Sturek wrote:
>>>
>>>> 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: [e-mail] [mailto:[e-mail]] On
>>>> Behalf
>>>> Of Kerry Lynn
>>>> Sent: Monday, November 02, 2009 5:32 AM
>>>> To: [e-mail]
>>>> Subject: [6lowapp] Newbie questions
>>>>
>>>> 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-
>>>> _______________________________________________
>>>> 6lowapp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/6lowapp
>>>>
>>>> _______________________________________________
>>>> 6lowapp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/6lowapp
>>>
>>> -- 
>>> 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.
>>>
>>>
>>>
>>
>> -- 
>> 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.
>>
>>
>>
>> _______________________________________________
>> 6lowapp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lowapp
>

-- 
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.