Subject: [dns-dir] Question about DNS-SD architecture in multi-link mesh networks

From: Ralph Droms <[email-masked]>
Date: Wed, 1 Feb 2012 10:47:57 -0500

The ZigBee Alliance is developing Smart Energy Profile 2.0 (SEP2.0) based on a collection of IETF protocols.  One of the key pieces is the use of DNS-SD.  The initial design calls for the use of multicast DNS, extended to use site-scoped multicast.

SEP2.0 may be deployed in a mixed network composed of wired Ethernet, WiFi and 6lowpan/IEEE802.15.4 ("ZigBee IP" or "ZIP") links.  While there is not a definitive conclusion, it seems multicast over ZIP is problematic.  There is no approved spec for multicast over ZIP and the designs under consideration have problems.  Furthermore, multicast DNS used for other purposes on the wired/wireless links will, without further specification, spill over and likely overwhelm the very low bandwidth in the ZIP network.

The most recent proposed design for DNS to support DNS-SD in SEP2.0 uses a mix of "greater-than-link" scoped multicast over the ZIP mesh (note that the IETF 6lowpan/IEEE802.15.4 architecture uses a multi-link subnet architecture for which mDNS must be extended beyond link-scoped multicast), mDNS on wired/wireless links and proxies on the routers.

Here's an early rev of an extension to mDNS for site-scoped multicast: http://tools.ietf.org/id/draft-lynn-dnsext-site-mdns-01.txt

Note that this design begs the question "How is the SEP2.0 namespace integrated into the DNS namespace?"  The mDNS-based solution defines ".site" as an analog to ".local"

I would like to hear your thoughts about how to provide DNS-SD in an unmanaged, multi-subnet network.  Don't feel constrained to mDNS-ish solutions; everything is on the table...

- Ralph

---

From: Thomas Narten <[email-masked]>
Date: Fri, 10 Feb 2012 18:07:09 -0500

> The ZigBee Alliance is developing Smart Energy Profile 2.0 (SEP2.0)
>  based on a collection of IETF protocols.  One of the key pieces is
>  the use of DNS-SD.  The initial design calls for the use of
>  multicast DNS, extended to use site-scoped multicast.

Bad idea. multicast deployment is spotty.

Link-local multicast is pretty ubiquitous (well, at least for
ethernet, which is pretty ubiquitous).

But it would be nuts to assume you have any multicast that spans
routers, even site scoped.

What SOHO environment with more than one router has site-wide
multicast enabled?

Thomas

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 11 Feb 2012 07:56:02 +0100

> What SOHO environment with more than one router has site-wide

Hm...I would not say "nuts". I see a number of ISPs having multicast turned on within their network for TV distribution (for example). So I would not be as much against this idea as Thomas. Across AS boundaries, agree, only unicast there, but otherwise I do see multicast. Specifically I see it working within a broadcast domain at the edge. And that is the environment I think zigbee is working.

  Patrik

---

From: Ralph Droms <[email-masked]>
Date: Sat, 11 Feb 2012 14:12:55 -0500

This problem space likely applies to homenet WG architecture and deployment scenarios, too.

Here's a short list of potential features:

* Disconnected operation ("fate sharing"): name resolution for reachable devices continues if the local network is disconnected from the global Internet
* Relative name resolution: some naming convention that allows name resolution while mitigating the need to know an absolute location in the global DNS namespace
* Unmanaged operation
* Efficient message utilization: for example, keep unwanted traffic off of an IEEE802.15.4 network.

So, in the home network environment, what's needed is a name resolution service that can continue to operate even if the connection to the service provider has failed.  It would be nice to be able to resolve a name like "that-printer-in-my office" without having to know the FQDN printerXXX.rdroms.big-service-provider.net.  DNS-SD should work, so a request for "thermostat service" lists all the thermostats in the home.

Extending mDNS to, say, ".site" has some of the desired features: unmanaged operation, relative name resolution, disconnected operation.  However, it's not clear it scales well to multiple links because of various timers, (as Thomas points out) mDNS depends on multi-router multicast, the mDNS traffic in a typical home network would swamp an IEEE802.15.4 network, and mDNS doesn't accommodate nodes that sometimes sleep (I'm aware that there are proxies to mitigate this problem).

On the other hand, can an unmanaged DNS server combined with DDNS and appropriate security be used as the basis for a DNS solution?  Any ideas about some form of relative naming that can off-load the requirement to identify the right DNS suffix for DNS-SD?

- Ralph

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 12 Feb 2012 08:34:09 +0100

> On the other hand, can an unmanaged DNS server combined with DDNS and appropriate security be used as the basis for a DNS solution?  Any ideas about some form of relative naming that can off-load t…

I think that already exists. Where you have "trust" in the local multicast cloud for the name resolution for the .local (or .site) names. You there have security on the application layer. Including using dns proxies that cache mdns responses and queries.

Then you have globally unique names as well, and you can use ddns for that. You can as Apple has done ignore the need to configure the actual domain path "droms.dynamic-service.provider.com", but you configure with the name of the service, username and password. That uses authenticated HTTP/HTML or something to register/update the names you want, but lookup is normal DNS.

   Patrik

---

From: Thomas Narten <[email-masked]>
Date: Mon, 13 Feb 2012 09:17:44 -0500

> Hm...I would not say "nuts". I see a number of ISPs having multicast 
> turned on within their network for TV distribution (for example).

yes. multicast is deployed in some environments. It is used for
audio/video in some places, and it is used in financial/trading
markets as well.

But it is not ubiquitously deployed by any stretch of the
imagination. You won't find it available in home networks (with more
than one link). You generally don't find it in data centers.

While I don't know much about ZigBeeSmartEnergy, it appears from their
web site that one of their targetrs is nconsumers and home networks.

It would seem nuts to me to base something on multicast unless it is
targetted for specific deployments where enablement of multicast can
be assumed or enabled.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Wed, 15 Feb 2012 06:18:20 -0500

On Feb 13, 2012, at 9:17 AM 2/13/12, Thomas Narten wrote:

>> [....]

Thomas - suppose we don't use multicast.  How would these design goals be met with unicast DNS:

- Ralph

> 
> Thomas
> 
> _______________________________________________
> dns-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-dir