Re: [smartpowerdir] SmartGrid Status Update Please

[Ralph Droms <[e-mail]>]

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

>