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.

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.

Table of Contents

1.  Introduction
2.  Requirements
    2.1.  General Requirements
    2.2.  Application Protocol
    2.3.  Application Commissioning
3.  Future Work
4.  Conclusions
5.  Security Considerations
6.  IANA Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses

1.  Introduction

An initial major deployment of IEEE 802.15.4 and 6LoWPAN [RFC4944] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.) 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] (NIST, “NIST Smart Grid Roadmap,” .).

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] (NIST, “NIST Smart Grid Priority Action Plan (PAP) - IP for Smart Grid,” .). The 6LowApp activity [I‑D.bormann‑6lowpan‑6lowapp‑problem] (Bormann, C., Sturek, D., and Z. Shelby, “6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols,” July 2009.) 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] (UCA, “UCA International Open Smart Grid - 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 (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 Section 3 (Future Work).

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

(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] (NIST, “NIST Smart Grid Priority Action Plan (PAP) - IP for Smart Grid,” .). 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.

(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] (Schneider, J. and T. Kamiya, “Efficient XML Interchange (EXI) Format 1.0,” September 2008.) is planned. Thus a payload indication for application/xml, text/xml and other xml content types [RFC3023] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.) and the transfer encoding [RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) x-exi is required [W3C.WD‑exi‑best‑practices‑20071219] (Vogelheim, D. and M. Cokus, “Efficient XML Interchange (EXI) Best Practices,” December 2007.). See [I‑D.shelby‑6lowapp‑encoding] (Shelby, Z., Luimula, M., and D. Peintner, “Efficient XML Encoding and 6LowApp,” October 2009.) 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:

(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 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] (NIST, “NIST Smart Grid Priority Action Plan (PAP) - IP for Smart Grid,” .). 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

7.2. Informative References

Authors' Addresses