6lowapp                                                        D. Sturek
Internet-Draft                                    Pacific Gas & Electric
Intended status: Informational                                 Z. Shelby
Expires: April 22, 2010                                        Sensinode
                                                               D. Lohman
                                                      M. Garrison Stuber
                                                               S. Ashton
                                                        October 19, 2009

                  Smart Energy Requiements for 6LowApp

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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.


   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

   (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

   (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

              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

              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.

              Kamiya, T. and J. Schneider, "Efficient XML Interchange
              (EXI) Format 1.0", World Wide Web Consortium LastCall WD-
              exi-20080919, September 2008,

              Cokus, M. and D. Vogelheim, "Efficient XML Interchange
              (EXI) Best Practices", World Wide Web Consortium WD WD-
              exi-best-practices-20071219, December 2007,

7.2.  Informative References

              NIST, "NIST Smart Grid Priority Action Plan (PAP) - IP for
              Smart Grid",  , <http://www.nist.gov/public_affairs/

   [NIST-SG]  NIST, "NIST Smart Grid Roadmap",  ,

   [OpenHAN]  UCA, "UCA International Open Smart Grid - OpenHAN",  ,

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

   Phone: +1-619-504-3615
   Email: d.sturek@att.net

   Zach Shelby
   Kidekuja 2
   Vuokatti  88600

   Phone: +358407796297
   Email: zach@sensinode.com

   Dan Lohman
   2111 N Molter Road
   Liberty Lake, WA  99019

   Phone: +1-509-891-3840
   Email: Daniel.Lohman@itron.com

   Michael Garrison Stuber
   2111 N. Molter Road
   Liberty Lake, WA  99025

   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
   47 Farnsworth Street
   Boston, MA  02210

   Phone: +1.617.951.1201
   Email: skip.ashton@ember.com

Sturek, et al.           Expires April 22, 2010                [Page 12]