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

[Toerless Eckert <[e-mail]>]

Thanks, Esko

Actually a client would discover a new service instance with quering the PTR RR,
so rfc6763 12.1. is relevant, but yes, it does  ask to include all dependent RRs.
Here is what i think is the minimum generic case for a single service instance with one locator address.

_service-name._udp.local                        PTR   service-instance-name._service-name._udp.local
 service-instance-name._service-name._udp.local SRV   prio weight port service-instance-locator.local
 service-instance-name._service-name._udp.local TXT   'key=value;...'
 service-instance-locator.local                 AAAA  IPv6-addr

I have not tried to figure out how many bits that would be, especially in comparison
to coap/core-link encoding.

Actually, when one uses only unicast DNS and SRP, i guess you wouldn't
use .local, but .default.service.arpa, which would make all the messages somewhat bigger
(thinking about how the ANIMA REST URLs where explicitly shortened, but then DNS
 adds the overhead back ...). I wonder how much of those details are better defined
in the ANIMA drafts so that we do ensure interoperability...

Cheers
    Toerless

On Tue, May 17, 2022 at 04:08:48PM +0000, Esko Dijk wrote:
> 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

-- 
---
[e-mail]