Re: [6lowapp] Discovery

["Don Sturek" <[e-mail]>]

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