[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

Return-Path: <d.sturek@att.net>
X-Original-To: mdnsext@ietfa.amsl.com
Delivered-To: mdnsext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AB3A721F9433 for <mdnsext@ietfa.amsl.com>; Thu, 25 Jul 2013 13:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.261
X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lRzHMEp6EEn6 for <mdnsext@ietfa.amsl.com>; Thu, 25 Jul 2013 13:35:17 -0700 (PDT)
Received: from nm1-vm7.access.bullet.mail.gq1.yahoo.com (nm1-vm7.access.bullet.mail.gq1.yahoo.com []) by ietfa.amsl.com (Postfix) with ESMTP id 69D1721F943C for <mdnsext@ietf.org>; Thu, 25 Jul 2013 13:35:16 -0700 (PDT)
Received: from [] by nm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 20:35:15 -0000
Received: from [] by tm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 20:35:15 -0000
Received: from [] by smtp120.sbc.mail.ne1.yahoo.com with NNFMP; 25 Jul 2013 20:35:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374784515; bh=gFfL75VOOcFtFnI3SO4TK7carOhKF8DwLxdC3en5d0o=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=yBpXzKWXavTv63XX6T273AojozZa6B7DLjFngMNEFQZgb2/Zm5tYUgeKCZyNFspa64JGgC4ozv3WgMbfXjTNXfDp0h/vMP8cwMDtky4cEp2D2Y7W+W8cZ9wh4xQl9PBF7ClujjZJKE72J2WCS/t8rpFsIHg85kq9O7hxzseQSuI=
X-Yahoo-Newman-Id: 759979.79855.bm@smtp120.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: q97k1zcVM1kP9LsDFgSrjW3oE8XDnzWrNHIO5_QVkwvUoEA xr4kwfa6T35RUxumJZe3EYHN.AEKYD8F40FfTTO1Gqzq_tRYSpEWiOt3U5q9 v1_uwDryw7.CBQ3aiGG7CT5y0LhZE11SEQ0BmPnxBxMJKFGfpN.59VhFM5Ui J_2Yez.q6n1baQ8lje8CHQOevoJirLAPQtwl.Q8Qb2bkCU29D6QCtfx9sX3U tMuGQuY.FzyF_CTUdlcAJgLbtmegYyoVkYVaO2BJKNbcqJv5GMtVEtO1R.iY nHHEQXMgXvQoddxCT5H1qWbjY3RPROxtu3HbH5c05pbiWBPM8.Ngac4VAmRU ZGQARRmBv7dCXTQoPNcR2PLJrGFgPL_8qfZ5m23ptRe3jDSxctK6HGAjxW2j BBrgPWFpW5TfwnS2iWypvSSPdZmxYnC1Rjk41YOt_RiBLwtIbsOxbMf0M2eF vLoIW.ep1HAxRIhbJFJ8H0CkF0FAb1YPB8U2byKEPf1Cnq0GKk2FLKMXzc2z bDrfU1HGZOK5QEB3HBcPSi117hNP2q8tyYw_0arYvHixbPB7SPlXPlviuRpS jzc6J.qf3SCVGg779YeimXXNpye_8NjpRsIJ8BMxi.GVWec.5NHsq6wGiM3J Kig--
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-Rocket-Received: from [] (d.sturek@ with login) by smtp120.sbc.mail.ne1.yahoo.com with SMTP; 25 Jul 2013 20:35:15 +0000 UTC
User-Agent: Microsoft-MacOutlook/
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
X-Mailman-Approved-At: Sun, 28 Jul 2013 08:31:43 -0700
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)
X-BeenThere: mdnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mdnsext>
List-Post: <mailto:mdnsext@ietf.org>
List-Help: <mailto:mdnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 20:35:22 -0000

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):

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
I think these topics were detailed in this old draft presented in V6OPS
sometime ago:  


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
>> 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
>> cover site specific addressing for this reason as well as need to define
>> another draft describing ULA prefix delegation rules and forwarding
>> for border routers (yet to be done).
>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.