[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 [127.0.0.1]) 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-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [216.39.63.179]) by ietfa.amsl.com (Postfix) with ESMTP id 69D1721F943C for <mdnsext@ietf.org>; Thu, 25 Jul 2013 13:35:16 -0700 (PDT)
Received: from [216.39.60.173] by nm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 20:35:15 -0000
Received: from [98.138.104.100] by tm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 20:35:15 -0000
Received: from [127.0.0.1] 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 [10.0.0.4] (d.sturek@67.124.200.231 with login) by smtp120.sbc.mail.ne1.yahoo.com with SMTP; 25 Jul 2013 20:35:15 +0000 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
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): 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