Hi Tim, Don Sturek, chair for the ZigBee Alliance Core Stack Group which developed ZigBee IP in support of Smart Energy Profile 2.0.
Here is a synopsis of the requirements: 1) Support Resource Discovery over a topology that includes Wi-Fi, HomePlug AV and GP and ZigBee IP (ZigBee IP is a multi-hop solution using ROLL RPL) connected via border routers 2) No device vendor wanted responsibility for a centralized DNS or uPNP repository that would be guaranteed to exist in all deployment scenarios. Ideally then services (resources) are self describing and locate-able through client directed queries (DNS-SD was a great solution for this) 3) mDNS was a great choice then for discovery, however, due to the use of ROLL RPL (or really any multi-hop route over solution), the use of link locals would not guarantee discovery of all services (resources). Hence, the extension of mDNS with this now outdated draft (captured in the requirements Kerry created for mdnsext I believe): http://tools.ietf.org/html/draft-lynn-dnsext-site-mdns-01 The DNS-SD draft (RFC 6763) was used in our application without change. We would have welcomed the use of mDNS (RFC 6762) but that would not work with ULAs (which we had to use due to the multi-hop subnet) Again, in some settings there could be a box doing DNS (as long as that platform was good with other vendor solutions posting DNS records into it!). In some settings (where say the electricity meter is the only common platform), most utilities don't want responsibility (or the risk) in having untrusted devices posting anything to them. I like the ideas in Homenet around gathering service information into centralized DNS repositories where such a service exists. By the way, if ULA's continue to be the addressing mechanism, then there are a couple of additional issues: 1) In a border router, clear rules on the propagation of ULA prefixes (eg, which interfaces, ideally those that face inward in the site topology and not to the ISP!) 2) What to do if a border router discovers the existance of other ULA prefixes I think these topics were detailed in this old draft presented in V6OPS sometime ago: http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 Don On 7/25/13 1:11 PM, "Tim Chown" <t...@ecs.soton.ac.uk> wrote: >On 25 Jul 2013, at 19:03, Don Sturek <d.stu...@att.net> wrote: > >> Hi Ulrich, >> >> Let me say as an implementer of ROLL RPL (and Trickle Multicast) the >>topic >> of multi-link subnets and the general topic of multicast address scope >> continues to be a major concern. For example, we needed to extend mDNS >>to >> cover site specific addressing for this reason as well as need to define >> another draft describing ULA prefix delegation rules and forwarding >>rules >> for border routers (yet to be done). > >Hi, > >It would be great to get requirements for this - hopefully this can be >raised in the dnssdext BoF next week, and contributed into the >draft-lynn-mdnsext-requirements-02 work by Kerry and Stuart. Currently >the dnssdext charter includes this use case. > >Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
