From fred@cisco.com Thu May 5 10:31:44 2011 Return-Path: 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 C8B07E08F4; Thu, 5 May 2011 10:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.569 X-Spam-Level: X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 HMORwAKhqfka; Thu, 5 May 2011 10:31:44 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id CAC93E08F1; Thu, 5 May 2011 10:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3559; q=dns/txt; s=iport; t=1304616704; x=1305826304; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=e/9IZfL7D37AJaJRTvywXVnZjY6vx2bJZVLiUehLvJc=; b=gNJEzgBZH3/TabNKGkYMtOKkt1JTzl+pBXTD9P6YwQMPHUQtVLthBFOe 3o6z+IRucGAfBAGmqZC4iQGTBqKrR/zQcV26hyrSqfiBNo7C+MOLmWA8V 6PUsmlxCR2rHjYmr8Ri/AjVVuraaawVz/D+DHuxfiAsnTj2Jhcz8mPM99 4=; X-IronPort-AV: E=Sophos;i="4.64,321,1301875200"; d="scan'208";a="351169263" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 05 May 2011 17:31:43 +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 p45HVb1V012895; Thu, 5 May 2011 17:31:42 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Thu, 05 May 2011 10:31:43 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Thu, 05 May 2011 10:31:43 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DC232ED.90106@piuha.net> Date: Thu, 5 May 2011 10:31:25 -0700 Message-Id: <712A9779-5B09-4B95-B67E-E4DD4A47159A@cisco.com> References: <53A33168-135E-4114-9EEE-D4E17F847FB2@cisco.com> <4DC232ED.90106@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IETF SmartPower Directorate , IESG IESG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 17:31:44 -0000 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. =46rom 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. 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. 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. 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.=20 From jari.arkko@piuha.net Fri May 6 02:26:10 2011 Return-Path: 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 E7884E06C8; Fri, 6 May 2011 02:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, 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 7W4Lnat1VvIb; Fri, 6 May 2011 02:26:10 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id D0F0EE0651; Fri, 6 May 2011 02:26:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 26AA82CC4B; Fri, 6 May 2011 12:26:07 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tw7C8HxxM2F; Fri, 6 May 2011 12:26:06 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2079D2CC2F; Fri, 6 May 2011 12:26:06 +0300 (EEST) Message-ID: <4DC39CBB.3070907@piuha.net> Date: Fri, 06 May 2011 09:01:15 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Fred Baker References: <53A33168-135E-4114-9EEE-D4E17F847FB2@cisco.com> <4DC232ED.90106@piuha.net> <712A9779-5B09-4B95-B67E-E4DD4A47159A@cisco.com> In-Reply-To: <712A9779-5B09-4B95-B67E-E4DD4A47159A@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: IESG IESG , IETF SmartPower Directorate 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 09:26:11 -0000 Thank you. This was very useful. Jari Fred Baker kirjoitti: > On May 4, 2011, at 10:17 PM, Jari Arkko wrote: > > =20 >> This is helpful, but I would also be interested in the other direction= =2E That is, what is SGIP doing (have they gone for IP? IPv6? What are th= ey focusing on now? What are their primary unfulfilled requirements?) >> =20 > > The SGIP is in the process of describing the standards that are importa= nt 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, m= ostly from the IEC. I personally don't plan to do that; help from any int= erested 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, n= ot the least of which is that US NIST has not certified the security prof= ile for use in communication with the US government; any nuclear facility= has to talk with Department of Energy, and there are important ties to D= epartment of Commerce and other areas. From my perspective, the biggest w= orry 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 remai= nder; for example, the choice of big-endian, little-endian, or BCD repres= entation is a per-meter option) is hopelessly complex and doesn't quite i= nteroperate 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 i= mportant vendors, the UK, and the Texas Public Utility Commission, have a= dopted and started to deploy Zigbee Secure Energy Profile (SEP) 1, which = presumes a link layer network and an application layer gateway at the Ene= rgy Services Interface (ESI). SEP 1 is essentially proprietary; different= implementations don't necessarily talk with each other, security has bee= n handed to Certicom with attendant commercial issues, and there are othe= r problems. SEP 2 is an IPv6 network using 6lowpan and RPL, with yet-anot= her-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 Cert= icom. SEP 2 is nominally link layer independent, which means that it coul= d run over a variety of technologies: IEEE 802.15.1 Bluetooth, IEEE 802.1= 5.4, 802.15.4g, IEEE 1901 Homeplug, ITU G.9955/G.9956 Powerline Communica= tions, and hybrid networks that route between 802.3, 802.11, and the othe= rs. However, Zigbee remains wedded strongly to IEEE 802.15.4, so rumor ha= s it (and yes, it's just rumor) that the WiFi Alliance and the Homeplug c= onsortium are having internal discussions about possibly adapting and cha= nging SEP 2 independently to use their link layers. I don't know what the= implications would be if that happened, but if I were the AD over the re= levant IETF work groups I would want to understand the implications for 6= lowpan, RPL, and COAP. Speaking strictly for myself, with the exception o= f 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.=20 > > > > =20 From fred@cisco.com Mon May 9 13:04:29 2011 Return-Path: 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 In-Reply-To: Date: Mon, 9 May 2011 13:04:10 -0700 Message-Id: <7F6103FD-AC7D-47DD-A835-CDBD8CB22BE0@cisco.com> References: <53A33168-135E-4114-9EEE-D4E17F847FB2@cisco.com> <4DC232ED.90106@piuha.net> <712A9779-5B09-4B95-B67E-E4DD4A47159A@cisco.com> To: Ralph Droms X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IESG IESG , IETF SmartPower Directorate 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. >=20 > 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. >=20 >> 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. >=20 > 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. =20= 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. >=20 > 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. >=20 >> 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.=20 >>=20 >=20 > Treating all those MACs as simple IPv6 networks would be my = preference, as well. I'm trying to provide guidance in that direction. >=20 > - Ralph >=20 >>=20 >=20 From rdroms.ietf@gmail.com Mon May 9 15:24:18 2011 Return-Path: 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 ; 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 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: References: <53A33168-135E-4114-9EEE-D4E17F847FB2@cisco.com> <4DC232ED.90106@piuha.net> <712A9779-5B09-4B95-B67E-E4DD4A47159A@cisco.com> To: Jari Arkko X-Mailer: Apple Mail (2.1082) Cc: IESG IESG , IETF SmartPower Directorate 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: >=20 > On May 4, 2011, at 10:17 PM, Jari Arkko wrote: >=20 >> 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?) >=20 > 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". >=20 > 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. >=20 > 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. =46rom 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. >=20 > 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.=20 >=20 Treating all those MACs as simple IPv6 networks would be my preference, = as well. I'm trying to provide guidance in that direction. - Ralph >=20 From jari.arkko@piuha.net Wed May 11 22:23:52 2011 Return-Path: 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 26A0CE06A7 for ; Wed, 11 May 2011 22:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 cKloOoOeq2yx for ; Wed, 11 May 2011 22:23:50 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id E886EE06A6 for ; Wed, 11 May 2011 22:23:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 10EAF2CC49 for ; Thu, 12 May 2011 08:23:49 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUPOv3xNoflH for ; Thu, 12 May 2011 08:23:48 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A6FC02CC2F for ; Thu, 12 May 2011 08:23:48 +0300 (EEST) Message-ID: <4DCB6EE3.5030905@piuha.net> Date: Thu, 12 May 2011 07:23:47 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF SmartPower Directorate Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [smartpowerdir] good examples of current IP-based sensor deployments? X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 05:23:52 -0000 For a presentation, I need examples of existing, significant deployments of IP-based smart grid/sensor/IOT networks. Good pointers, anyone? Jari