Subject: The IETF and the SmartGrid

From: "Richard Shockey" <[email-masked]>
Date: Mon, 5 Oct 2009 17:20:27 -0400

The general internet community needs to be aware of activities in North
America that directly relate to the use of IETF protocols in the Electric
Utility industry. This activity is generally referred to as the SmartGrid.
Though the issues immediately deal with technical and policy decisions in
the US and Canada, the SmartGrid concept is gaining significant momentum in
Europe and Asia as well.

http://www.smartgrids.eu/

http://en.wikipedia.org/wiki/Smart_grid#Countries

The SmartGrid has many definitions but as a practical matter it is a
substantial re-architecture of the data communications networks that
utilities use to maintain the stability and reliability of their power
grids. Many of the requirements for the SmartGrid in North America came out
of the 2003 North East power outage which demonstrated a substantial lack of
investment in Utility IT systems.

http://www.ferc.gov/EventCalendar/Files/20040915141105-blackout.pdf

Of particular note, is the desire by utilities to extend the reach of their
communications networks directly to the utility meter and beyond ultimately
into the customer premise itself. This is generally referred to as the
Advanced Meter Interface (AMI).  One of the use cases driving this
requirement is the next generation of plug-in hybrid electric vehicles. The
utilities, correctly IMHO, want to precisely control the timing of how these
vehicles are recharged so not to create a unique form of DOS attack and take
out the grid when everyone goes home at night.  This is a principal use case
in 6lowpan ( ID below ). Increasingly energy flows are becoming
bi-directional creating needs for more computational intelligence and
capability at the edge.  

What is going on? Why should the IETF community care?

The United States Government, as part of the Energy Independence and
Security Act of 2007 gave the National Institute of Standards and Technology
( NIST ) principal responsibility "to coordinate development of a framework
that includes protocols and model standards" for the SmartGrid.

http://www.nist.gov/smartgrid/

After several meetings sponsored by NIST in recent months, NIST released a
preliminary report. Several folks from the IETF community attended those
meetings, myself included. There multiple troubling stories about how those
meetings were organized but I'll leave those tales to others. 

http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf

One of the requests from NIST and the SmartGrid community was a list of Core
Internet protocols that NIST could refer to.  Fred Baker has been working on
that task. ( below )  

Myself and others are deeply concerned by how this effort is developing.
There is no current consensus on what the communications architecture of the
SmartGrid is or how IP actually fits into it.

The Utility Industry does not understand the current IPv4 number exhaust
problem and the consequences of that if they want to put a IP address on
every Utility Meter in North America. 

What is equally troubling is that many of the underlying protocols that
utilities wish to deploy are not engineered for IPv6. We have an example of
that in a recent ID.

http://tools.ietf.org/html/draft-c1222-transport-over-ip-01.txt

Obviously, there are significant CyberSecurity issues in the SmartGrid
concept and NIST has produced a useful document outlining the requirements
and usecases.

http://csrc.nist.gov/publications/drafts/nistir-7628/draft-nistir-7628.pdf

How the SmartGrid interfaces with or bridges with Home Area or Enterprise
Local Area networks is unclear, to put it mildly. 

I want to use this message to encourage the community to read the attached
documents and get involved in this effort as appropriate.  Additional NIST
documents will be published shortly with a open public comment period. 

I strongly urge members of the IETF community to participate in this comment
period and lend its expertise as necessary. 

It's useful and important work. 

************************

Title  : Core Protocols in the Internet Protocol Suite
	Author(s)       : F. Baker
	Filename        : draft-baker-ietf-core-03.txt
	Pages           : 32
	Date            : 2009-10-03

This note attempts to identify the core of the Internet Protocol Suite.  The
target audience is NIST, in the Smart Grid discussion, as they have
requested guidance on how to profile the Internet Protocol Suite.  In
general, that would mean selecting what they need from the picture presented
here.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-baker-ietf-core-03.txt

Title  : Design and Application Spaces for 6LoWPANs
	Author(s)       : E. Kim, et al.
	Filename        : draft-ietf-6lowpan-usecases-04.txt
	Pages           : 30
	Date            : 2009-10-01

This document investigates potential application scenarios and use cases for
low-power wireless personal area networks (LoWPANs).  This document provides
dimensions of design space for LoWPAN applications.
A list of use cases and market domains that may benefit and motivate the
work currently done in the 6LoWPAN WG is provided with the characterisitcis
of each dimention.  A complete list of practical use cases is not the goal
of this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-usecases-04.txt

Richard Shockey
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype/AIM: rshockey101 
LinkedIn : http://www.linkedin.com/in/rshockey101

---

From: Fred Baker <[email-masked]>
Date: Mon, 5 Oct 2009 14:47:38 -0700

Thanks. You already know this, as does Russ Housley, but I'll say it  
out loud for others to hear.

At the third NIST workshop on the Smart Grid, which was the week  
following the IETF meeting, several IETFers were invited by David Su  
of NIST to a workshop on the role of the Internet Architecture in the  
Smart Grid. He specifically asked for a document that could be used to  
discuss and describe the Internet Architecture, specifically to  
support the "profiling" (eg, subseting) of its architecture for the  
purpose. To that end, I started

http://tools.ietf.org/html/draft-baker-ietf-core
   "Core Protocols in the Internet Protocol Suite", Fred Baker, 3- 
Oct-09,
   <draft-baker-ietf-core-03.txt>

The initial document essentially described the protocols appropriate  
to a host; at the request and behest of several commentators, I have  
since added a brief description of unicast and multicast routing, QoS,  
address allocation and assignment (DHCP and ND), NTP, DNSSEC, SIP, the  
ISO Transport Service Interfaces (necessary for ACSE, which is used in  
the Smart Grid) and something of the business architecture of the  
Internet and therefore firewalls, NATs, and VPNs. I have in the can a  
version that puts in references for MPLS, and given that NIST is  
asking about calendaring and SNMP will likely include a few sentences  
on those.

I'm trying to walk what is at best a grey line; The things that are at  
the Internet Architecture's absolute core, at least to my mind, are  
described in RFCs 1122, 1123, and 1812. However, NIST is asking about  
the place of more things (like calendaring and timekeeping) and other  
possible users of the document are also asking for things that are  
more core to the business than the architecture, like NATs and MPLS.  
So I am trying to describe things that are core, and also answer  
useful questions about less-core things, all without trying to provide  
a list of all 1574 proposed standards, 89 draft standards, and 82  
standards.

Individuals who have noticed the draft have commented; folks who care  
should also do so. I have asked the IESG for directorate reviews, but  
have not gotten anything from any directorates.

As you say, NIST is requesting commentary on http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf 
. Those of us that work for US corporations or educational  
institutions would likely be wise to be involved in corporate reviews  
and replies, as that is how most review of this type comes back. The  
exact structure to reply in has not yet been announced, but I would  
imagine that will be remedied soon.

On Oct 5, 2009, at 2:20 PM, Richard Shockey wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Michael Dillon <[email-masked]>
Date: Mon, 5 Oct 2009 22:53:41 +0100

> utilities wish to deploy are not engineered for IPv6. We have an example of

I've asked the ARIN Public Policy mailing list how people would feel about
banning the Electric Utility industry (and sub contractors) from receiving
any IPv4 addresses for use on the Smart Grid. This would include direct
ARIN allocations and assignment from ISPs.

I think that you are right to raise this issue in discussion since we badly
need to shine a light on the details of transitioning the Internet to IPv6.

--Michael Dillon

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 5 Oct 2009 18:05:55 -0400

It will certainly get their attention ... :-) 

>  -----Original Message-----
>  From: Michael Dillon [mailto:[email-masked]]
>  Sent: Monday, October 05, 2009 5:54 PM
>  To: Richard Shockey
>  Cc: [email-masked]
>  Subject: Re: The IETF and the SmartGrid
>

---

From: Hiroshi Esaki <[email-masked]>
Date: Tue, 06 Oct 2009 09:39:26 +0900

Hi Fred and Michael,

This is Hiroshi Esaki of WIDE project, Japan.
We have long time worked on the introduction of IP technology into the
faculity networks, especially focusing on the usage of IPv6.
We run the Green University of Tokyo Project.
We have some professional operation using IPv6 on bulding automation
and lightening control system.
The most of exisiting and current system in this particular field is 
based on
non-IP system, however they are going to realize the benefit of IP 
technology
and open technology  in this field.

Thanks,
Hiroshi Esaki, WIDE Project

-- 
=======================================

Hiroshi ESAKI, Ph.D
 Professor,
 Graduate School of Information Science and Technology,
 The University of Tokyo,
 102A2, 7-3-1 Hongo, Bunkyo-ku, Tokyo 113-8656, Japan
 Email   [email-masked]
 TEL : +81-3-5841-7465
 FAX : +81-3-5841-7465
 http://www.i.u-tokyo.ac.jp/
 http://hiroshi1.hongo.wide.ad.jp/hiroshi/index.html

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 5 Oct 2009 21:19:40 -0400

Thank you for your response.

Is there any documentation URL's etc ( hopefully in English ) that you could
share?

>  From: [email-masked] [mailto:[email-masked]] On Behalf
>  Of Hiroshi Esaki
>  Sent: Monday, October 05, 2009 8:39 PM
>  To: Michael Dillon; Richard Shockey; [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Oct 2009 14:55:53 +1300

On 2009-10-06 10:20, Richard Shockey wrote:
...
> every Utility Meter in North America. 

Ironic, really, since IP addresses for every streetlight was one of
the favourite examples in the IPng days.

Let me quote from RFC 1673 "Electric Power Research Institute Comments on IPng",
authored by
   Ron Skelton
   Member of Technical Staff
   Advanced IT Group
   Electric Power Research Institute
   Palo Alto CA 94303

 "2. Basic Requirements.

      - Scaleability
        The addressing scheme must have essentially an unlimited address
        space to encompass an arbitrarily large number of information
        objects.  Specifically it must solve the fundamental limitations
        of 32 bit formats, a format for 20 octets and above is considered
        suitable."

(The document was biased towards OSI addressing.)

  Brian

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 06 Oct 2009 11:45:22 -0700

Brian E Carpenter wrote:
>> problem ...

+1

EPRI was an active participant in the IETF IPng discussions, in the early 90s, 
back when other IETF folk were claiming that we had no immediate pressure for 
expanded IP Addresses, and didn't have to solve this until 2010 or 2020...

EPRI was /already/ being turned down for IPv4 address blocks, back then!

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Peter Dambier <[email-masked]>
Date: Sun, 11 Oct 2009 00:30:38 +0200

Sorry if I misunderstand something,
but I thought it was already working.

e.g. chinese hackers successfully proofed they can switch off all
power companies in Australia whenever they want.

I remember some places in the world have forbidden to connect
lethal devices like powerplants to the internet.

I thought germany and the us where among these places.

Well, with germany I have heard rumors that palaestinians could
switch off the Biblis nuclear power plant whenever they felt the itch.
I know that is not true. Biblis is offline most of the time because
it is raining in.

Kind regards
Peter

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48

---

From: Peny Yang <[email-masked]>
Date: Tue, 13 Oct 2009 08:18:59 +0800

Is there any planned ad-hoc meeting/session related to this topic in
Hiroshima meeting?

Peny

On Tue, Oct 6, 2009 at 5:47 AM, Fred Baker <[email-masked]> wrote:
> Thanks. You already know this, as does Russ Housley, but I'll say it out
> loud for others to hear.
>
> At the third NIST workshop on the Smart Grid, which was the week following
> the IETF meeting, several IETFers were invited by David Su of NIST to a
> workshop on the role of the Internet Architecture in the Smart Grid. He
> specifically asked for a document that could be used to discuss and describe
> the Internet Architecture, specifically to support the "profiling" (eg,
> subseting) of its architecture for the purpose. To that end, I started
>
>  "Core Protocols in the Internet Protocol Suite", Fred Baker, 3-Oct-09,
> The initial document essentially described the protocols appropriate to a
> host; at the request and behest of several commentators, I have since added
> a brief description of unicast and multicast routing, QoS, address
> allocation and assignment (DHCP and ND), NTP, DNSSEC, SIP, the ISO Transport
> Service Interfaces (necessary for ACSE, which is used in the Smart Grid) and
> something of the business architecture of the Internet and therefore
> firewalls, NATs, and VPNs. I have in the can a version that puts in
> references for MPLS, and given that NIST is asking about calendaring and
> SNMP will likely include a few sentences on those.
>
> I'm trying to walk what is at best a grey line; The things that are at the
> Internet Architecture's absolute core, at least to my mind, are described in
> RFCs 1122, 1123, and 1812. However, NIST is asking about the place of more
> things (like calendaring and timekeeping) and other possible users of the
> document are also asking for things that are more core to the business than
> the architecture, like NATs and MPLS. So I am trying to describe things that
> are core, and also answer useful questions about less-core things, all
> without trying to provide a list of all 1574 proposed standards, 89 draft
> standards, and 82 standards.
>
> Individuals who have noticed the draft have commented; folks who care should
> also do so. I have asked the IESG for directorate reviews, but have not
> gotten anything from any directorates.
>
> As you say, NIST is requesting commentary on
> http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf.
> Those of us that work for US corporations or educational institutions would
> likely be wise to be involved in corporate reviews and replies, as that is
> how most review of this type comes back. The exact structure to reply in has
> not yet been announced, but I would imagine that will be remedied soon.
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 12 Oct 2009 21:04:28 -0700

> Is there any planned ad-hoc meeting/session related to this topic in

Well, ROLL and 6lowpan are relevant.

http://trac.tools.ietf.org/bof/trac/wiki and specifically http://trac.tools.ietf.org/bof/trac/wiki/BifIETF76 
  has a BOF called 6lowapp that is likely equally relevant, which is  
to say not designed specifically for the smart grid but potentially  
usable there. At this point, I'm not sure that the IETF has decided  
that the Smart Grid needs anything we haven't already given it in the  
Internet Architecture. It might, but I for one don't know yet what it  
would be. Perhaps a "reliable multicast" transport, perhaps a "route  
me differently" flag in IPv6 (which multipath TCP could also use),  
perhaps permission to send from a multicast group address, perhaps  
something else. At this point I don't think we honestly know what  
would help them.

Looks like we may have a bar BOF.

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 13 Oct 2009 09:04:25 -0400

Hi,

--On October 12, 2009 9:04:28 PM -0700 Fred Baker <[email-masked]> wrote:

> http://trac.tools.ietf.org/bof/trac/wiki and specifically
> http://trac.tools.ietf.org/bof/trac/wiki/BifIETF76  has a BOF called
> 6lowapp that is likely equally relevant, which is to say not designed
> specifically for the smart grid but potentially usable there. At this
> point, I'm not sure that the IETF has decided that the Smart Grid needs
> anything we haven't already given it in the Internet Architecture. It
> might, but I for one don't know yet what it would be. Perhaps a "reliable
> multicast" transport, perhaps a "route me differently" flag in IPv6
> (which multipath TCP could also use), perhaps permission to send from a
> multicast group address, perhaps something else. At this point I don't
> think we honestly know what would help them.
>

As a side comment, please note that the Calendaring and Scheduling 
Consortium (CalConnect) is also working with the SmartGrid folks on a 
calendaring standard for their needs. In particular CalConnect is promoting 
the use of iCalendar (RFC5545) via an XML representation 
(<http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-00>).

I would encourage all IETF participants from all areas to look at the 
SmartGrid work and see if other IETF technologies may be a good fit for the 
work they are proposing. Let's not have them re-invent the wheel.

-- 
Cyrus Daboo