Re: [dnssd] CoAP resource discovery and DNS-SD

[Esko Dijk <[e-mail]>]

Toerless, there was also the below point in your mail:

> In coap, like in GRASP, we can map all necessary service elements into
> a single message, so we know it is a single request/reply exchange

As I understand, it can be the same for DNS-SD. A good implementation would return the SRV record for found services and also the associated AAAA records to have a single request/response. RFC 6763 12.2 defines this.
I would add to such behaviour that if the number of answers is high then the implementation can shorten the response by leaving out the AAAA records. Something that a DNS-SD server / SRP server suitable for mesh networks use could do.

(Of course it has the downside that in any case a client still MUST be prepared for the case that it doesn't receive the AAAA records in the first response. So in that sense client complexity is a bit higher than for e.g. CoAP / GRASP(?) )

Regards
Esko 

-----Original Message-----
From: Esko Dijk 
Sent: Monday, May 16, 2022 09:59
To: Toerless Eckert <[e-mail]>; Ted Lemon <[e-mail]>
Cc: [e-mail]
Subject: RE: [dnssd] CoAP resource discovery and DNS-SD

Hello Toerless,

Ted was referring to the Service Registration Protocol (SRP) for DNS-SD as defined by https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-13 .
This enables registration and discovery over generic services over unicast, similar to what a CoRE Resource Directory can do for CoAP resources.  A single request/reply exchange can be used to register a device's services.
Querying is the same as in unicast DNS-SD.

For SRP you need of course a way to get an IP address of the / a SRP server before you can use SRP registration/querying. In OpenThread, this is done by e.g. including such address in mesh-network-wide  configuration data. So then all devices that may need this, have it.
See GetNextDnsSrpUnicastInfo() https://github.com/openthread/openthread/blob/main/src/core/thread/network_data_service.cpp#L262 for details.

There's also the possibility to include a more compact set of configuration data that enables a device (client) to reach an SRP server over an anycast address ; see e.g. FindPreferredDnsSrpAnycastInfo() https://github.com/openthread/openthread/blob/main/src/core/thread/network_data_service.cpp#L196.
Anycast reachability is useful for redundancy if multiple SRP servers are available and are kept synchronized (using e.g. https://datatracker.ietf.org/doc/html/draft-lemon-srp-replication-01).

Some of the functions you mention may already be supported by the above approach. E.g. Thread defines mesh-local IPv6 addresses (described in the 'Thread Network Fundamentals' white paper) which would enable a device to advertise a particular service only in mesh scope, while other services could be advertised with greater scope by using a global or ULA IPv6 address. And the proxy function you mention may not be needed if multiple synchronized SRP servers are used, or a single SRP server that serves all mesh networks plus all regular non-constrained networks in an installation site.
Note that proxying between mDNS devices and SRP-using devices is provided for (by https://datatracker.ietf.org/doc/html/draft-sctl-advertising-proxy and rfc8766). Such that on-mesh constrained devices don't have to use multicast / mDNS.

Regards
Esko


-----Original Message-----
From: dnssd <[e-mail]> On Behalf Of Toerless Eckert
Sent: Saturday, May 14, 2022 16:02
To: Ted Lemon <[e-mail]>
Cc: [e-mail]
Subject: Re: [dnssd] CoAP resource discovery and DNS-SD


To discover a service via mDNS is not not necessarily quite LLN friendly.

You need to query/reply for all the RR involved in a service, which is
if i remember AAAA, SRV, PTR, TXT and maybe CNAME. Admittedly
i have not tried to work out how many bits this is, but there is
also the question of how many packets this will end up being in the
widey deployed implementations and who takes care of minimizing/optimizing
that. So there is a cost to this more comples layering. RRs, messages, packets.

In coap, like in GRASP, we can map all necessary service elements into
a single message, so we know it is a single request/reply exchange.

Yes, i would definitely prefer to minimize the amount of multicast,
especially given how those LLN can really only flood them across
the whole network, but both DNS and COAP could be on par in that
department. 

Due to the proprietary nature of Thread i have not been able to figure
out how it proposes to instantiate and discover the server instances
of DNS or COAP that should be used. But thatss also where another
complexity can come in:

                                    coap/dns
                                    server                             coap/dns
      client .... 802.15.4-net .... border-rtr .... ent-networks ..... server
                                                       ...
                                                     service-server

The server we may want to discover on the client may not necessarily be
connected to the 802.15.4 network, but the enterprise network behind it,
(most simple designs would hope/expect for the service we want to use to
 be running on the border-rtr).

So, it seems to me i need some form of scoping of service/resource
request/replies from clients between those that should be only
resolved within the 802.15.4 network, and those that should resolve
(also) across the ent-network behind it. I am not quite sure how
to most easily do this, but off the top of my head it looks as
if i wanted some simple proxy function on the border router which
on a per-service/resource basis decides whether to forward the request
upstream to the coap/dns server in the enterprise network or not.
And with coap i can see how that proxy function is easily implemented,
and the concept of such a proxy is discussed in coap.

Replicating that functionality in DNS would be quite more complex i fear.

Cheers
    Toerless

On Fri, May 13, 2022 at 08:01:37PM -0400, Ted Lemon wrote:
> The registry/mapping problem is where we fell down. Why are you trying to
> use Core for this anyway? DNS-SD works fine—that’s what we’re using for
> Thread, for example. You can just do a DNS UDP query or use DNS Push rather
> than using multicast if you use SRP to update the DNS server.
> 
> On Fri, May 13, 2022 at 19:57 Toerless Eckert <[e-mail]> wrote:
> 
> > Thanks, Ted
> >
> > Any pointer to Kerry's work in this regard ? I was looking through her
> > expired
> > draft, but i didn't see anything getting to that exact point
> > (draft-doi-core-parameter-option looks like related, but i can't really
> >  make heads or tails out of it).
> >
> > So lets say:
> >
> > REQ: GET /.well-known/core?rt=<resource>
> >
> >      RES: 2.05 Content
> >      Content-Format: 40
> >      Payload:
> >      </b>;rt=<resource>;p=<prio>;w=<weight>;proto=<string>,
> >      ...
> >
> > I am just defining in the spec for my resource that it has additional
> > option
> > link-target attributes. p= for a numeric priority value, w= for a numeric
> > weight attribute and proto= for a string enumerating protocol details.
> > And these are the same parameters as what i'd use for the same resource
> > (oops: service) when using DNS-SD.
> >
> > It seems as if rfc6690 didn't actually create a registry for those
> > link-targets
> > but simply created rt= and if= link-targets and just created a registry for
> > the values of rt= and if=. Which raises the question if i could simply
> > specify p/w/proto to be normative in the context of the specific resource,
> > and if not whether those addtiional link-targets would have to be
> > specified as
> > updated to rfc6690...
> >
> > Cheers
> >     Toerless
> >
> > On Fri, May 13, 2022 at 07:22:41PM -0400, Ted Lemon wrote:
> > > We were never able to figure that out either. The mapping from Core RD in
> > > particular to DNS-SD is something that the DNS-SD working group actually
> > > pursued for a while (Kerry Lynn worked on this pretty heavily for about a
> > > year).
> > >
> > > On Fri, May 13, 2022 at 7:20 PM Toerless Eckert <[e-mail]> wrote:
> > >
> > > > Dear CoAP WG
> > > >
> > > > I am trying to figure out how to use CoAP discovery as specified in
> > RFC7252
> > > > (and expanded in rfc6690 and rfc7390),  but i can not figure out how
> > > > one would encode basic parameters of a resource, such as those
> > supported
> > > > in DNS-SD, rfc6763:
> > > >
> > > > When discovering more than one instance of a resource, such as
> > possible,
> > > > when using multicast discovery as on rfc7252, clients will have to
> > figure
> > > > out,
> > > > which instance of a resource to select. DNS-SSD has priority and weight
> > > > parameters associated with each instance. How would one describe/encode
> > > > such instance and weight ?
> > > >
> > > > When discovering one or more instance via DNS-SD, the discoering client
> > > > may further select the best instance in terms of interoperability,
> > > > functionality
> > > > and performance based on one or more key=value property pairs
> > describing
> > > > the instance. How is this done in CoAP ?
> > > >
> > > > Thanks a lot!
> > > >
> > > > Toerless
> > > >
> > > > _______________________________________________
> > > > dnssd mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dnssd
> > > >
> >
> > --
> > ---
> > [e-mail]
> >

-- 
---
[e-mail]

_______________________________________________
dnssd mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnssd