Re: [smartpowerdir] SmartGrid Status Update Please

Ralph Droms <rdroms.ietf@gmail.com> Mon, 09 May 2011 22:24 UTC

Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: smartpowerdir@ietfa.amsl.com
Delivered-To: smartpowerdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AEAE0809; Mon, 9 May 2011 15:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.349
X-Spam-Level:
X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lng+JyFjN8Fo; Mon, 9 May 2011 15:24:17 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id F154BE0808; Mon, 9 May 2011 15:24:16 -0700 (PDT)
Received: by qwc23 with SMTP id 23so4303877qwc.31 for <multiple recipients>; Mon, 09 May 2011 15:24:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=RwgJRJeuWiCx7hX6sywq7IQ/03lpp5XG6deC+P4THLc=; b=x9KOtVhtU6AwnsoL/AVskqCAvVbQIxEAQ8qDM7kEZzCg0BepA6gA69lfPiSusJWI5p 6yEWhdOEaBcvZ7WRGkIli7zW1A8+CqCibl/uYwHdzAfmFzseomJ3svSualSilvHT838R 8CLQyUNNI2eKGujJIUBLZhbR1pXKN8lcVb/DQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ek5IBRTDzNDmvwESe3JYVwMR2s8aa5n327bApVymUUM6I/kDBNeQldti7LKwS2N7Fe suaICdSNbf6oyCMeygyvcPCeTQk720Rm8zs2t8iqM3XJg0Br691VmBmmQsJ1nClov77S JWKLsjFNkqd/ZHOmG0JRSjHcHegY+x3dWFRz0=
Received: by 10.52.165.136 with SMTP id yy8mr152866vdb.194.1304969895426; Mon, 09 May 2011 12:38:15 -0700 (PDT)
Received: from [161.44.65.177] ([161.44.65.177]) by mx.google.com with ESMTPS id y11sm817188vcq.40.2011.05.09.12.38.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 12:38:14 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <712A9779-5B09-4B95-B67E-E4DD4A47159A@cisco.com>
Date: Mon, 9 May 2011 15:38:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF44946E-2014-4264-B435-4F10A7C35A5C@gmail.com>
References: <AB464FFF-134F-4EA3-A59A-23E2FBC14705@vigilsec.com> <53A33168-135E-4114-9EEE-D4E17F847FB2@cisco.com> <4DC232ED.90106@piuha.net> <712A9779-5B09-4B95-B67E-E4DD4A47159A@cisco.com>
To: Jari Arkko <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.1082)
Cc: IESG IESG <iesg@ietf.org>, IETF SmartPower Directorate <smartpowerdir@ietf.org>
Subject: Re: [smartpowerdir] SmartGrid Status Update Please
X-BeenThere: smartpowerdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Members of the Smart Power Directorate <smartpowerdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smartpowerdir>
List-Post: <mailto:smartpowerdir@ietf.org>
List-Help: <mailto:smartpowerdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2011 22:24:18 -0000

On May 5, 2011, at 1:31 PM 5/5/11, Fred Baker wrote:

> 
> On May 4, 2011, at 10:17 PM, Jari Arkko wrote:
> 
>> This is helpful, but I would also be interested in the other direction. That is, what is SGIP doing (have they gone for IP? IPv6? What are they focusing on now? What are their primary unfulfilled requirements?)
> 
> The SGIP is in the process of describing the standards that are important in the grid. Part of that means "today" and part means "tomorrow".
> 
> They have generally gone for IP, and for IPv6. Sliding IPv6 in wherever IPv4 is in use now means updating a broad array of existing standards, mostly from the IEC. I personally don't plan to do that; help from any interested quarter would be appreciated.
> 
> The SGIP, however, also feels that the ANSI C12 series of standards has present commercial importance. There are a number of issues with that, not the least of which is that US NIST has not certified the security profile for use in communication with the US government; any nuclear facility has to talk with Department of Energy, and there are important ties to Department of Commerce and other areas. From my perspective, the biggest worry is that ANSI C12.19 (a MIB by any other name, but one in which three tables have to be read and understood before one can interpret the remainder; for example, the choice of big-endian, little-endian, or BCD representation is a per-meter option) is hopelessly complex and doesn't quite interoperate with IEC TC 57's CIM. I am also disturbed by it being an OSI ACES/ROSE application layer network that uses UDP/IPv[46] or TCP/IPv[46] as one of a number of underlying networking options.
> 
> Another huge issue is embedded in Zigbee. Various factions, including important vendors, the UK, and the Texas Public Utility Commission, have adopted and started to deploy Zigbee Secure Energy Profile (SEP) 1, which presumes a link layer network and an application layer gateway at the Energy Services Interface (ESI). SEP 1 is essentially proprietary; different implementations don't necessarily talk with each other, security has been handed to Certicom with attendant commercial issues, and there are other problems. SEP 2 is an IPv6 network using 6lowpan and RPL, with yet-another-CIM that kinda-sorta interoperates with ANSI C12 or IEC TC 57's CIM, but not quite, and which uses draft-mcgrew-tls-aes-ccm-ecc to bypass Certicom. SEP 2 is nominally link layer independent, which means that it could run over a variety of technologies: IEEE 802.15.1 Bluetooth, IEEE 802.15.4, 802.15.4g, IEEE 1901 Homeplug, ITU G.9955/G.9956 Powerline Communications, and hybrid networks that route between 802.3, 802.11, and the others.

Agreed - SEP 2 is link layer independent, using HTTP/TCP/IP over any link layer (more about this later).

> However, Zigbee remains wedded strongly to IEEE 802.15.4, so rumor has it (and yes, it's just rumor) that the WiFi Alliance and the Homeplug consortium are having internal discussions about possibly adapting and changing SEP 2 independently to use their link layers.

Can you say more about what changes would be necessary?

I can imagine the SEP 2 specification would need to be changed to allow other MAC layers; I don't think the application layer parts of the spec would need to be changed.  There is some separation between the SEP 2 and ZigBee IP working groups regarding the specifications for the specific protocols, which is leading to some internal discussion about HTTP/TCP/IP.  I need to review the specs to draw a conclusion about the amount of work to be done to incorporate, e.g., WiFi and IEEE 1901.2.

> I don't know what the implications would be if that happened, but if I were the AD over the relevant IETF work groups I would want to understand the implications for 6lowpan, RPL, and COAP.

Extension to WiFi would have little or no impact.  Early SEP 2 testing has been performed over wired Ethernet so, in theory, WiFi should "just work".  I'm trying to get up to speed on IEEE 1901.2.  I have heard claims that 1901.2 would use 6lowpan and RPL, but it's not clear where.  There is some mention of the IEEE 802.15.4 MAC layer in the 1901.2 spec but I don't have a full understanding of the spec, yet.

CoAP is not formally part of SEP 2 at present.  However, there was a recent move within ZigBee to move from HTTP to CoAP, to address issues related to : flash resources for code, RAM resources for IP stack, network bandwidth and throughput.  There is a lively discussion about the choice, motivated by individual vendor interests as well as technical considerations.

> Speaking strictly for myself, with the exception of Bluetooth (which probably becomes a local interface to an application) I would prefer to see those simply become IPv6 networks, as most of them can handle a 1500+ byte frame. That story - if it's anything more than a rumor, which at this point I don't know - remains to be told. 
> 

Treating all those MACs as simple IPv6 networks would be my preference, as well. I'm trying to provide guidance in that direction.

- Ralph

>