Re: [smartpowerdir] SmartGrid Status Update Please

Fred Baker <fred@cisco.com> Mon, 09 May 2011 20:04 UTC

Return-Path: <fred@cisco.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 7016CE08D0; Mon, 9 May 2011 13:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.507
X-Spam-Level:
X-Spam-Status: No, score=-110.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 T6X1QI51l1Gf; Mon, 9 May 2011 13:04:28 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 05B2FE08C2; Mon, 9 May 2011 13:04:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3225; q=dns/txt; s=iport; t=1304971468; x=1306181068; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=DTdBEmlZvOPWmk0rDBuIfHKMw+bc64TOALln+b9PM68=; b=iy46CM1bZ9oHARODkivLLnhjYdJihnAt5l6CKDsP3UEC1mrDJkADviWK 8SNERgjwYjKSTvgXFPogryTk7qp64HTpYfoLb4pOeKmuztMjiVtpolo3y /nfTkF1TQaSMKXbvGvIeeX7fnkyaNYlQAPyodPmpSYK6lexAa9V1LuJRY A=;
X-IronPort-AV: E=Sophos;i="4.64,342,1301875200"; d="scan'208";a="311790827"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 09 May 2011 20:04:27 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p49K4LwE008182; Mon, 9 May 2011 20:04:26 GMT
Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Mon, 09 May 2011 13:04:27 -0700
X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Mon, 09 May 2011 13:04:27 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <CF44946E-2014-4264-B435-4F10A7C35A5C@gmail.com>
Date: Mon, 09 May 2011 13:04:10 -0700
Message-Id: <7F6103FD-AC7D-47DD-A835-CDBD8CB22BE0@cisco.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> <CF44946E-2014-4264-B435-4F10A7C35A5C@gmail.com>
To: Ralph Droms <rdroms.ietf@gmail.com>
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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 20:04:29 -0000

On May 9, 2011, at 12:38 PM, Ralph Droms wrote:
>> 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?

The only thing that has enough meat in it to quote is a comment from Bob Dolin at Echelon to the effect that 6lowpan would have to be modified to be used in an otherwise IEC 14908-3 PLC environment. There are also questions on the routing; IEEE 802.15.4 is a famously noisy channel; IEEE 1901 is less so, at least on relatively new wire. There does come a question for any PLC signal on what happens with old wire. I know the IEC 14908 includes a "route me alternately" flag for use on retransmissions where PLC routing may be suspect.

> 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.  

Ditto. It's a 2K frame and and a 1 MBPS MAC on a 3.8 MBPS service, which is to say "a lot of FEC" as I understand it. Seems like IP would be able to run native.

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