One document matched: draft-sturek-6lowapp-smartenergy-00.txt
6lowapp D. Sturek
Internet-Draft Pacific Gas & Electric
Intended status: Informational Z. Shelby
Expires: April 22, 2010 Sensinode
D. Lohman
M. Garrison Stuber
Itron
S. Ashton
Ember
October 19, 2009
Smart Energy Requiements for 6LowApp
draft-sturek-6lowapp-smartenergy-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010.
Sturek, et al. Expires April 22, 2010 [Page 1]
Internet-Draft Smart Energy Requiements for 6LowApp October 2009
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
The new Smart Energy (SE) Version 2 (SE 2) is aimed at providing end-
to-end connectivity between energy providers, energy consumers, and
their respective equipment. This effort has been recognized as part
of the Smart Grid roadmap by the US National Institute of Standards
and Technology (NIST). Whereas SE 1 was based on a proprietary
ZigBee stack, SE 2 will is based on IPv6 with support for IEEE
802.15.4, HomePlug and use across the Internet. The work in 6LowApp
on application protocols and commissioning is an important component
of SE 2. This document introduces SE 2 along with requirements
identified for 6LowApp and considerations for future work.
Sturek, et al. Expires April 22, 2010 [Page 2]
Internet-Draft Smart Energy Requiements for 6LowApp October 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. General Requirements . . . . . . . . . . . . . . . . . . . 5
2.2. Application Protocol . . . . . . . . . . . . . . . . . . . 6
2.3. Application Commissioning . . . . . . . . . . . . . . . . 7
3. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Sturek, et al. Expires April 22, 2010 [Page 3]
Internet-Draft Smart Energy Requiements for 6LowApp October 2009
1. Introduction
An initial major deployment of IEEE 802.15.4 and 6LoWPAN [RFC4944] is
Smart Energy (SE) Version 2 (SE 2). This effort, started by the
ZigBee/HomePlug liaison, has been recognized as part of the Smart
Grid roadmap by the US National Institute of Standards and Technology
(NIST). The full NIST Smart Grid roadmap can be found at [NIST-SG].
IETF plays a key role in deployment of Smart Grid standards into the
Home Area Network (HAN). The NIST Smart Grid Priority Action Plan
(PAP) number one is titled "IP for Smart Grid [NIST-PAP]. The
6LowApp activity [I-D.bormann-6lowpan-6lowapp-problem] is recognized
within the SE 2 community as key to deployment and in addressing the
initial round of proposed work (outlined above) as well as a forum
for additional work going forward. Unlike ZigBee protocol stacks of
the past, Smart Energy 2.0 will be built fully upon IEEE, IETF, IEC
and W3C standards, and is IPv6 based. The 6LowApp Application area
WG activity is expected to provide the application protocols used by
SE 2. Application payload formats are specified in the IEC using W3C
standards. The UCA International OpenSG has recently published
OpenHAN requirements and a Market Requirements Document for Smart
Energy v2 [OpenHAN].
Smart Energy communications provides a vital link between energy
providers, energy consumers, and their respective equipment. Smart
Energy messages may be used for a variety of purposes from
facilitating reduction in energy consumption during peak times,
saving consumers money, to facilitating energy consumption patterns
that are more environmentally friendly. Smart Energy networks may be
entirely self-contained, relying exclusively on 6LoWPAN, end-to-end
in which enterprise networks are tied to 6LoWPAN networks, or
federated in which networks are bridged at the application level
because of commercial or security concerns. Smart Energy
transactions are generally focused on interactions with energy
consumers and their equipment, rather than grid automation and
management communications; however, it is consumer equipment may in
some cases serve as sensors for larger grid operations. In these
cases Smart Energy transactions may be part of a larger,
comprehensive Smart Grid strategy.
This document examines the requirements for Smart Energy 2 related to
the work items identified for the planned 6LowApp working group,
which are presented in Section Section 2. As Smart Energy and the
Smart Grid are long-term standardization processes, issues that may
require work in the IETF in the future are also identified in Section
Section 3.
Sturek, et al. Expires April 22, 2010 [Page 4]
Internet-Draft Smart Energy Requiements for 6LowApp October 2009
2. Requirements
For Smart Energy to be truly successful, it must be ubiquitous. It
is useful for an energy producer to be able to indicate an increase
in price to a consumer, and have their equipment respond according to
some consumer specified behavior; it becomes more useful when the
consumer has a rich variety of choices regarding how to respond. The
consumer gets greater value when a greater number of their devices
are smart energy enabled -- Metcalfe's Law applied to appliances and
heating systems. Appliance and electronics manufacturers are very
sensitive to added cost though. Any solution must be very
inexpensive to implement, simple to deploy, and it must not increase
support costs or return rates. Already many energy providers
throughout the world are deploying new Smart Meters with 802.15.4-
based RF communications to link into the home. The 6LowApp effort
must facilitate bullet-proof application messaging, while remaining
very simple to implement.
Smart Energy devices must have a simple way to determine what
services exist on the network. Obtaining service information must
not require substantial fixed resources for either the client or the
service. It also must not require a single central directory, or a
time-consuming node-by-node interrogation process. The ideal
solution will allow a new node on the network to easily determine
what services are offered, as well as allowing existing nodes to
discover new services as they become available.
To realize the goal of IP networking deployment over IEEE 802.15.4
networks, additional work is desired within IETF. Work within the
ZigBee Alliance on the ZigBee/HomePlug Smart Energy Profile has
identified the following needs introduced in the following sections.
2.1. General Requirements
The following general requirements have been identified from SE 2:
(1) End-to-end IPv6 is required across both back-end systems and
embedded networks in Smart Energy.
(2) Integration into the overall Smart Grid architecture is an
important requirement for SE 2.
(3) IEEE 802.15.4 based devices support very small code and RAM
sizes. To envision deployment in everyday devices such as white
goods (refrigerators, washers, dryers, pool pumps, etc.),
microcontrollers with very small code footprint sizes are used
(typically on the order of 128K flash and 4K of RAM).
Sturek, et al. Expires April 22, 2010 [Page 5]
Internet-Draft Smart Energy Requiements for 6LowApp October 2009
(4) Security methods using large key lengths and multiple large
packet exchanges are not desirable. The US NIST effort
incorporates a cyber security recommendation [NIST-PAP]. While
maintaining efficient key sizes and packet exchanges, the
security suite needs also to meet security review and
acceptance. Light-weight, simplified implementations of
standard IETF security solutions are desired.
(5) Support for communicating with devices that have no formal
relationship with other Smart Energy network nodes, and may not
have completed any explicit authorization. Therefore SE 2
requires support of public messaging to devices which may reside
on non-SE networks.
2.2. Application Protocol
SE 2 requires an application protocol which can carry all envisioned
messaging between SE devices, and between SE devices and servers.
For more powerful devices and networks, a standard XML/HTTP/TCP
solution is assumed for messaging. Many SE 2 devices in the HAN will
be extremely simple IEEE 802.15.4 nodes running a 6LoWPAN protocol
stack. Other similarly limited devices and networks are foreseen for
other parts of Smart Energy and the Smart Grid as well.
The following requirements have been identified related to the
application protocol:
(1) To fully realize integration of the data with the web, an
efficient message transfer protocol is desired.
Interperability with HTTP can be provided through a proxy that
can be located on the edge of the embedded network or elsewhere
in the Smart Energy network. Such a proxy must be as
transparent as possible.
(2) The goal is to enable efficient packet exchange between SE 2
devices (within 1 packet message exchanges where-ever possible)
while enabling compatability of the data on the wider Internet
without cost to the small devices.
(3) Standard application protocol response and error codes
compatible with HTTP.
(4) Reliability must be provided for application layer messages.
(5) Support must be provided for the use of UDP as a transport, and
optionally for the use of TCP or future reliable transports.
Sturek, et al. Expires April 22, 2010 [Page 6]
Internet-Draft Smart Energy Requiements for 6LowApp October 2009
(6) A publish-subscribe mechanism for the delivery of smart energy
events to client devices in the HAN is required.
(7) A push data mechanism to support battery powered device data
delivery where the delivery duty cycle is unknown is required.
Cachability for sleeping nodes is a desired feature.
(8) SE 2 seeks to exchange messages between devices through an XML
syntax. Due to packet size limitations in the IEEE 802.15.4
devices, a World Wide Web Consortium (W3C) EXI encoding
[W3C.WD-exi-20080919] is planned. Thus a payload indication
for application/xml, text/xml and other xml content types
[RFC3023] and the transfer encoding [RFC2045] x-exi is required
[W3C.WD-exi-best-practices-20071219]. See
[I-D.shelby-6lowapp-encoding] for a further analysis for XML
encoding technique requirements.
(9) Roaming support is required (the IPv6 address of nodes may
change).
(10) Minimal overhead for use over 6LoWPAN networks and other low-
bandwidth links. The goal is that the majority of messages can
fit into a single IEEE 802.15.4 payload.
(11) Latency times should be mimimized of the HAN, and ideally a
typical exchange should consist of just a single request and a
single response message.
(12) SE 2 requires support of efficient network management in the
HAN. The SE 2 application protocol must support get and set
operations required for application and device management. It
is not expected that limited nodes support SNMP, but instead
may use the same application protocol also for management.
2.3. Application Commissioning
In Smart Energy 2 the term Service Discovery is used for the process
of finding other SE services and registering locally offered
services. The discovery required for SE 2 is limited to devices and
services related to SE, rather than generic devices and services of
any kind (such as in UPnP). Thus the 6LowApp work item term
"Application Commissioning" is compatible with the needs of SE 2.
The following requirements related to application commissioning have
been identified:
Sturek, et al. Expires April 22, 2010 [Page 7]
Internet-Draft Smart Energy Requiements for 6LowApp October 2009
(1) SE 2 plans to deploy fully unattended devices (no required user
interaction). These devices need to locate the correct
homeowner network, join and discover services. Discovery of
services envisions advertised XML message exchange by devices in
the network to identify devices supplying complementary
services.
(2) A large central directory is not desirable - but the solutions
does need to deal with sleeping devices and interoperability
with general service discovery which may be handled by a
directory agent. be discovered.
(3) The use of multicast for discovery and advertisement must be
supported, along with the support of unicast responses.
(4) The exchange of full XML strings, either as part of device
message exchange or service discovery, in a mesh network using
6LowPAN requires fragmentation and multiple packet transfer for
a single transaction is not possible due to bandwidth and
routing constraints.
(5) Due to requirements to support devices supplying full XML (for
example, HomePlug AV/SE capable of supporting full Ethernet
packets) and 6LoWPAN (with a limitation of 127 byte packets), a
method of interchanging full XML and encoded/compressed XML in
Service Discovery is desired.
3. Future Work
The standardization of Smart Energy and the Smart Grid is a long-term
process with far reaching goals. In this section we look at the
needs of this effort from the IETF outside of the scope of 6LowApp
application protocols.
Improvements in transport layer support for low-power wireless mesh
networks and the kinds of interactions typical to Smart Energy is an
area that needs work. TCP has historically struggled in deployments
using lossy links where Ethernet assumptions on packet loss are not
realized. Thus many lossy link deployments have resorted to UDP with
application supplied guaranteed delivery features. Enhancements to
TCP to enable deployment on lossy, mesh routed links would allow for
seamless deployment of services on a variety of medium that does not
always behave like Ethernet links.
Smart Energy 2 (Home Area Networking) is only one small part of the
Smart Grid. Future area such as Neighborhood Area Networking or the
monitoring of the Smart Grid itself will also need solutions related
Sturek, et al. Expires April 22, 2010 [Page 8]
Internet-Draft Smart Energy Requiements for 6LowApp October 2009
to 6LowApp.
4. Conclusions
Smart Energy 2 will be an important Smart Grid application of IPv6
with resource constratined embedded devices and limited wireless mesh
networks. The requirements of Smart Energy 2 should be taken into
account for 6LowApp charter work to ensure that the end result is
useful for this and other related applications. In addition to an
application protocol and commissioning, future work needed will
include transport optimizations, security and extension to more Smart
Grid applications.
5. Security Considerations
Security is an important requirement for Smart Energy and the Home
Area Network domain. The US NIST effort incorporates a cyber
security recommendation currently in progrss, and summarized in
[NIST-PAP]. Today mechanisms can already be provided at the link
layer (IEEE 802.15.4 AES-128 encryption), at the IP layer with IPSEC
and at the application layer with TLS. It is however unclear which
of these mechanisms can be successfully applied to resource
constrained devices and networks. Although configurations of IPSEC
and light-weight TLS could in theory be applied, they may not be
compatible with the very short-lived message sequences of SE 2. The
ideal solution may fit in with a HTTP proxy to provide transparent
security for requests from external networks, while not crushing the
802.15.4 network and the tiny devices that live on it. In the future
it may be necessary to develop more generic security mechanisms
suitable to this domain.
6. IANA Considerations
This draft requires no IANA consideration.
7. References
7.1. Normative References
[I-D.bormann-6lowpan-6lowapp-problem]
Bormann, C., Sturek, D., and Z. Shelby, "6LowApp: Problem
Statement for 6LoWPAN and LLN Application Protocols",
draft-bormann-6lowpan-6lowapp-problem-01 (work in
progress), July 2009.
Sturek, et al. Expires April 22, 2010 [Page 9]
Internet-Draft Smart Energy Requiements for 6LowApp October 2009
[I-D.shelby-6lowapp-encoding]
Shelby, Z., Luimula, M., and D. Peintner, "Efficient XML
Encoding and 6LowApp", draft-shelby-6lowapp-encoding-00
(work in progress), October 2009.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[W3C.WD-exi-20080919]
Kamiya, T. and J. Schneider, "Efficient XML Interchange
(EXI) Format 1.0", World Wide Web Consortium LastCall WD-
exi-20080919, September 2008,
<http://www.w3.org/TR/2008/WD-exi-20080919>.
[W3C.WD-exi-best-practices-20071219]
Cokus, M. and D. Vogelheim, "Efficient XML Interchange
(EXI) Best Practices", World Wide Web Consortium WD WD-
exi-best-practices-20071219, December 2007,
<http://www.w3.org/TR/2007/
WD-exi-best-practices-20071219>.
7.2. Informative References
[NIST-PAP]
NIST, "NIST Smart Grid Priority Action Plan (PAP) - IP for
Smart Grid", , <http://www.nist.gov/public_affairs/
releases/smartgrid_interoperability.pdf>.
[NIST-SG] NIST, "NIST Smart Grid Roadmap", ,
<http://www.nist.gov/smartgrid/standards.html>.
[OpenHAN] UCA, "UCA International Open Smart Grid - OpenHAN", ,
<http://osgug.ucaiug.org/sgsystems/openhan/default.aspx>.
Sturek, et al. Expires April 22, 2010 [Page 10]
Internet-Draft Smart Energy Requiements for 6LowApp October 2009
Authors' Addresses
Don Sturek
Pacific Gas & Electric
77 Beale Street
San Francisco, CA
USA
Phone: +1-619-504-3615
Email: d.sturek@att.net
Zach Shelby
Sensinode
Kidekuja 2
Vuokatti 88600
FINLAND
Phone: +358407796297
Email: zach@sensinode.com
Dan Lohman
Itron
2111 N Molter Road
Liberty Lake, WA 99019
USA
Phone: +1-509-891-3840
Email: Daniel.Lohman@itron.com
Michael Garrison Stuber
Itron
2111 N. Molter Road
Liberty Lake, WA 99025
U.S.A.
Phone: +1.509.891.3441
Email: Michael.Stuber@itron.com
Sturek, et al. Expires April 22, 2010 [Page 11]
Internet-Draft Smart Energy Requiements for 6LowApp October 2009
Skip Ashton
Ember
47 Farnsworth Street
Boston, MA 02210
U.S.A.
Phone: +1.617.951.1201
Email: skip.ashton@ember.com
Sturek, et al. Expires April 22, 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 15:20:15 |