One document matched: draft-sturek-6lowapp-smartenergy-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4944 SYSTEM "reference.RFC.4944.xml">
<!ENTITY RFC2045 SYSTEM "reference.RFC.2045.xml">
<!ENTITY RFC2046 SYSTEM "reference.RFC.2046.xml">
<!ENTITY RFC3023 SYSTEM "reference.RFC.3023.xml">
<!ENTITY RFC3870 SYSTEM "reference.RFC.3870.xml">
<!ENTITY RFC3902 SYSTEM "reference.RFC.3902.xml">
<!ENTITY RFC5023 SYSTEM "reference.RFC.5023.xml">
<!ENTITY W3C.WD-exi-20080919 SYSTEM "reference.W3C.WD-exi-20080919.xml">
<!ENTITY W3C.WD-exi-best-practices-20071219 SYSTEM "reference.W3C.WD-exi-best-practices-20071219.xml">
<!ENTITY I-D.shelby-6lowapp-encoding SYSTEM "reference.I-D.shelby-6lowapp-encoding.xml">
<!ENTITY I-D.bormann-6lowpan-6lowapp-problem SYSTEM "reference.I-D.bormann-6lowpan-6lowapp-problem.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" ipr="pre5378Trust200902" docName="draft-sturek-6lowapp-smartenergy-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title>Smart Energy Requiements for 6LowApp</title>
<author initials="D" surname="Sturek" fullname="Don Sturek">
<organization>
Pacific Gas & Electric
</organization>
<address>
<postal>
<street>77 Beale Street</street>
<city>San Francisco, CA</city>
<code></code>
<country>USA</country>
</postal>
<phone>+1-619-504-3615</phone>
<email>d.sturek@att.net</email>
</address>
</author>
<author initials="Z" surname="Shelby" fullname="Zach Shelby">
<organization>
Sensinode
</organization>
<address>
<postal>
<street>Kidekuja 2</street>
<city>Vuokatti</city>
<code>88600</code>
<country>FINLAND</country>
</postal>
<phone>+358407796297</phone>
<email>zach@sensinode.com</email>
</address>
</author>
<author initials="D" surname="Lohman" fullname="Dan Lohman">
<organization>
Itron
</organization>
<address>
<postal>
<street>2111 N Molter Road</street>
<city>Liberty Lake, WA</city>
<code>99019</code>
<country>USA</country>
</postal>
<phone>+1-509-891-3840</phone>
<email>Daniel.Lohman@itron.com</email>
</address>
</author>
<author initials="M" surname="Garrison Stuber" fullname="Michael Garrison Stuber">
<organization>
Itron
</organization>
<address>
<postal>
<street>2111 N. Molter Road</street>
<city>Liberty Lake, WA</city>
<code>99025</code>
<country>U.S.A.</country>
</postal>
<phone>+1.509.891.3441</phone>
<email>Michael.Stuber@itron.com</email>
</address>
</author>
<author initials="S" surname="Ashton" fullname="Skip Ashton">
<organization>
Ember
</organization>
<address>
<postal>
<street>47 Farnsworth Street</street>
<city>Boston, MA</city>
<code>02210</code>
<country>U.S.A.</country>
</postal>
<phone>+1.617.951.1201</phone>
<email>skip.ashton@ember.com</email>
</address>
</author>
<date year="2009"/>
<area>Internet</area>
<workgroup>6lowapp</workgroup>
<keyword>Requirements</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='introduction' title="Introduction">
<t>
An initial major deployment of IEEE 802.15.4 and 6LoWPAN <xref target="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 <xref target="NIST-SG"/>.
</t>
<t>
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 <xref target="NIST-PAP"/>. The 6LowApp activity <xref target="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 <xref target="OpenHAN"/>.
</t>
<t>
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.
</t>
<t>
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 <xref target="requirements"/>. 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 <xref target="future"/>.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='requirements' title="Requirements">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<section anchor='general' title="General Requirements">
<t>
The following general requirements have been identified from SE 2:
<list style="format (%d)">
<t>End-to-end IPv6 is required across both back-end systems and embedded networks in Smart Energy.</t>
<t>Integration into the overall Smart Grid architecture is an important requirement for SE 2.</t>
<t>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).</t>
<t>Security methods using large key lengths and multiple large packet exchanges are not desirable. The US NIST effort incorporates a cyber security recommendation <xref target="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.</t>
<t>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.</t>
</list>
</t>
</section>
<section anchor='protocol' title="Application Protocol">
<t>
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.
</t>
<t>
The following requirements have been identified related to the application protocol:
<list style="format (%d)">
<t>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.</t>
<t>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.</t>
<t>Standard application protocol response and error codes compatible with HTTP.</t>
<t>Reliability must be provided for application layer messages.</t>
<t>Support must be provided for the use of UDP as a transport, and optionally for the use of TCP or future reliable transports.</t>
<t>A publish-subscribe mechanism for the delivery of smart energy events to client devices in the HAN is required.</t>
<t>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.</t>
<t>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 <xref target="W3C.WD-exi-20080919"/> is planned. Thus a payload indication for application/xml, text/xml and other xml content types <xref target="RFC3023"/> and the transfer encoding <xref target="RFC2045"/> x-exi is required <xref target="W3C.WD-exi-best-practices-20071219"/>. See <xref target="I-D.shelby-6lowapp-encoding"/> for a further analysis for XML encoding technique requirements.</t>
<t>Roaming support is required (the IPv6 address of nodes may change).</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</section>
<section anchor='commissioning' title="Application Commissioning">
<t>
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.
</t>
<t>
The following requirements related to application commissioning have been identified:
<list style="format (%d)">
<t>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.</t>
<t>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.</t>
<t>The use of multicast for discovery and advertisement must be supported, along with the support of unicast responses.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='future' title="Future Work">
<t>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.</t>
<t>
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.
</t>
<t>
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 to 6LowApp.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Conclusions">
<t>
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.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Security Considerations">
<t>
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 <xref target="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.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="IANA Considerations">
<t>
This draft requires no IANA consideration.
</t>
</section>
<!------------------------------------------------------>
<!-- SECTION: ACKNOWLEDGMENTS -->
<!------------------------------------------------------>
<!--
<section title="Acknowledgments">
<t>
(Don)
</t>
</section>
-->
</middle>
<back>
<references title='Normative References'>
&RFC4944;
&RFC2045;
&RFC3023;
&I-D.bormann-6lowpan-6lowapp-problem;
&W3C.WD-exi-20080919;
&W3C.WD-exi-best-practices-20071219;
&I-D.shelby-6lowapp-encoding;
</references>
<references title='Informative References'>
<reference anchor="NIST-SG" target="http://www.nist.gov/smartgrid/standards.html">
<front>
<title>NIST Smart Grid Roadmap</title>
<author initials="" surname="" fullname="">
<organization>NIST</organization>
</author>
<date month="" year="" />
</front>
<seriesInfo name="" value="" />
</reference>
<reference anchor="NIST-PAP" target="http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf">
<front>
<title>NIST Smart Grid Priority Action Plan (PAP) - IP for Smart Grid</title>
<author initials="" surname="" fullname="">
<organization>NIST</organization>
</author>
<date month="" year="" />
</front>
<seriesInfo name="" value="" />
</reference>
<reference anchor="OpenHAN" target="http://osgug.ucaiug.org/sgsystems/openhan/default.aspx">
<front>
<title>UCA International Open Smart Grid - OpenHAN</title>
<author initials="" surname="" fullname="">
<organization>UCA</organization>
</author>
<date month="" year="" />
</front>
<seriesInfo name="" value="" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:45:09 |