[mdnsext] Discovery requirements for Smart Energy Profile 2.0 (SEP 2.0)

Don Sturek <d.sturek@att.net> Thu, 25 July 2013 20:35 UTC

User-Agent: Microsoft-MacOutlook/14.3.6.130613
Date: Thu, 25 Jul 2013 13:35:12 -0700
From: Don Sturek <d.sturek@att.net>
To: Tim Chown <tjc@ecs.soton.ac.uk>
Message-ID: <CE16D4F7.225F7%d.sturek@att.net>
Thread-Topic: Discovery requirements for Smart Energy Profile 2.0 (SEP 2.0)
In-Reply-To: <EMEW3|c037c5b28ff64fed2dc2f655ee9cafeep6OLC703tjc|ecs.soton.ac.uk|1896F191-4448-41AF-BC56-E643371BCC4E@ecs.soton.ac.uk>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: mdnsext@ietf.org, Routing Over Low power and Lossy networks <roll@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Subject: [mdnsext] Discovery requirements for Smart Energy Profile 2.0 (SEP 2.0)
Precedence: list

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" <tjc@ecs.soton.ac.uk> wrote:

>On 25 Jul 2013, at 19:03, Don Sturek <d.sturek@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

[mdnsext] Discovery requirements for Smart Energy… Don Sturek