Dossier (long) sur la gestion des réseaux électriques (IETF)

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

Fred Baker <fred@cisco.com> 5 octobre 2009 23:47
À : Richard Shockey <richard@shockey.us>
Cc : ietf@ietf.org
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

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

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

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.

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.

Thank you for your response.

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

Brian E Carpenter <brian.e.carpenter@gmail.com> 6 octobre 2009 03:55
À : Richard Shockey <richard@shockey.us>
Cc : ietf@ietf.org

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

Répondre à : dcrocker@bbiw.net
À : ietf@ietf.org