Communication of Energy Pricing Information
draft-jennings-energy-pricing-00

Abstract

This specification defines media types for representing the future price of energy in JSON. It also defines a way for a client device, such as an electric car, to discover a web server that can provide the future pricing for local electrical energy. This will allow the client device to make intelligent decisions about when to use energy.

This draft is a very early skeleton of a draft to start discussion around this idea.

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on September 09, 2011.

Copyright Notice

Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Overview

Many uses of energy can be shifted in time. Consider charging an electric car. When the users plugs in a car at 9pm, they may not care when it actually charges, as long as it is ready at 8AM when they need to go to work. This is a classic real time problem and can be optimized as long as the charger for the car has relevant information about how long it will take to charge and the cost of electricity between the current time and the time when the task needs to be complete.

This specification defines a simple JSON[RFC4627]media type to provide the cost of energy at future points of time. It is an array of objects in which each object contains the time a new price will come into effect and the price at that time. JSON also defines a well known URL on a web server so that an HTTP client can retrieve this data. Finally as a way to automatically discover the web server, this specification defines a DHCP option to provide the host name of the web server.

Consider a typical residence with broadband internet and a residential gateway that gets its IP address via DHCP from the service provider. The service provider would provide the domain of the local power provider via DHCP. The residential gateway would get this and provide it in DHCP requests sent to the residential gateway. The residential gateway would also be able to override this, so if the consumer had arranged power from an alternative power provider, the name of that provider could be configured in the device.

A device on the residential network, such as a dishwasher, could find the energy provider name via DHCP. The dishwasher would then make an HTTP GET request to the well known URI defined in this specification. In other words, it would do an HTTP GET to the /.well_known/energy-price.json and would receive back an energyprice+json media type. For example

{
"currency" : "USD",
"prices":[
    { "time": "2011-04-12T23:20:00.00Z", "price": "0.028" },
    { "time": "2011-04-12T23:21:00.00Z", "price": "0.025" },
    { "time": "2011-04-12T23:22:00.00Z", "price": "0.021" }
]}

The above example shows a case where at 21:00 UTC, the price falls from 2.8 cents per KWh to 2.5 cents per KWh.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

3. Semantics

Each media type carries a single JSON object that represents a set of prices and times. This object contains optional attributes described below and a mandatory array of one or more measurements.

validTill:

Time at which this data will become invalid. UTC time in RFC 3339 format.

currency:

Optional. Specify currency in ISO 4217 [REF] currency code.

prices:

Array of price change objects. Mandatory and there must be at least one object in the array. Objects MUST be ordered in this array by time.

Each price time object contains several attributes, some of which are optional and some of which are mandatory.

time:

Time this price becomes effective. UTC time in RFC 3339 format.

price:

Price per KWh starting. The cost of energy changes to this price at the time in this object and remains at this price until the time of the next object in the prices array.

Open Issue: What is the best representation for time?

Open Issue: Is it OK that currency is optional?

Open Issue: How many entries can the array have? It would be nice to have some maximum size.

4. Well Known URL

A client that implements this specification uses the path "//.well-known/energy-price.json" for the resource name unless the client has been configured with an alternative path.

5. DHCP

Open Issues: Is DHCP the best approach to discovery or would something else be better?

6. IANA Considerations

Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with the RFC number of this specification.

6.1. Well-Known URI Registration

IANA will make the following "Well Known URI" registration as described in RFC 5785:

6.2. DHCP Options

TBD

6.3. Media Type Registration

The following registrations are done following the procedure specified in [RFC4288] and [RFC3023].

Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with the RFC number of this specification.

6.3.1. energyprice+json Media Type Registration

TBD

7. Security Considerations

TBD

Further discussion of security proprieties for media types can be found in Section 6.3.

8. Privacy Considerations

TBD

9. Acknowledgement

I would like to thank someone for their review comments.

10. References

Author's Address

Table of Contents

• 1. Overview
• 2. Terminology
• 3. Semantics
• 4. Well Known URL
• 5. DHCP
• 6. IANA Considerations
• 6.1. Well-Known URI Registration
• 6.2. DHCP Options
• 6.3. Media Type Registration
• 6.3.1. energyprice+json Media Type Registration
• 7. Security Considerations
• 8. Privacy Considerations
• 9. Acknowledgement
• 10. References
• Author's Address