Re: [6lowapp] Discovery

[Vlad Trifa <[e-mail]>]

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:

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