Re: [6lowapp] Discovery

[Zach Shelby <[e-mail]>]

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.