Subject: [smartpower-interest] Smart things in stupid networks

From: Fred Baker <[email-masked]>
Date: Thu, 28 Jul 2011 06:58:02 -0400

FYI...

I sat down last night to categorize what work we have around that directly relates (as in, *says* it relates) to sensors, the smart grid, and the nebulous "internet of things". What I came up with is attached: 46 documents in 8 working groups or research groups, touching on everything from "here's how to build a home" to routing architectures to energy management MIBs.

I personally would be interested to have the various people involved comment for the group on what their contributions are about. It looks interesting, and enquiring minds want to know :-)

Core:
draft-arkko-core-security-arch-00.txt
draft-arkko-core-sleepy-sensors-01.txt
draft-braun-core-compressed-ipfix-02.txt
draft-garcia-core-security-02.txt
draft-sarikaya-core-sbootstrapping-02.txt

Homenet:
draft-arkko-townsley-homenet-arch-00.txt
draft-baker-fun-multi-router-00.txt

lwig:
draft-bormann-lwig-guidance-00.txt
draft-williams-lwig-api-considerations-00.txt

Crypto:
draft-campagna-suitee-01.txt

6man:
draft-chakrabarti-nordmark-energy-aware-nd-00.txt
draft-oreirdan-rosenwald-ipv6mail-transition-00.txt

eman:
draft-claise-energy-monitoring-mib-09.txt
draft-ietf-eman-energy-aware-mib-02.txt
draft-ietf-eman-framework-02.txt
draft-jennings-energy-pricing-01.txt
draft-nordman-eman-energy-perspective-01.txt
draft-tychon-eman-applicability-statement-02.txt
draft-verges-eman-separate-modules-mib-00.txt

6lowpan:
draft-daniel-6lowpan-security-analysis-05.txt
draft-ietf-6lowpan-btle-01.txt
draft-ietf-6lowpan-hc-15.txt
draft-ietf-6lowpan-routing-requirements-09.txt
draft-ietf-6lowpan-usecases-10.txt
draft-wang-6lowpan-scheduling-requirements-00.txt

roll:
draft-goyal-roll-metrics-direction-00.txt
draft-ietf-roll-applicability-ami-01.txt
draft-ietf-roll-security-framework-06.txt
draft-ietf-roll-terminology-05.txt
draft-popa-roll-applicability-ami-00.txt
draft-qiu-roll-kemp-00.txt

opsawg:
draft-ietf-opsawg-management-stds-01.txt

tictoc:
draft-ietf-tictoc-requirements-01.txt

dtnrg:
draft-irtf-dtnrg-prophet-09.txt

tsvwg:
draft-wood-tsvwg-saratoga-09.txt

netconf:
draft-schoenw-netconf-light-00.txt

hip/hiprg:
draft-irtf-hip-experiment-13.txt
draft-irtf-hiprg-rfid-03.txt
draft-moskowitz-hip-rg-dex-05.txt

iot:
draft-iab-smart-object-workshop-01.txt
draft-lee-iot-problem-statement-02.txt
draft-routing-architecture-iot-00.txt
draft-song-iot-emergency-network-00.txt
draft-walewski-iot-use-case-00.txt

Mentions Sensor Networks, Internet of Things, or Smart Grid, but not "about" it:
draft-cui-softwire-host-4over6-06.txt
draft-oreirdan-mody-bot-remediation-13.txt

---

From: <[email-masked]>
Date: Thu, 28 Jul 2011 12:34:48 +0100

Fred,

Your Internet of Things/sensors list below called out our UDP-based Saratoga data transfer protocol:
http://tools.ietf.org/html/draft-wood-tsvwg-saratoga
which will be presented in Friday's tsvwg meeting by Will Ivancic. Our slides are already uploaded at:
http://www.ietf.org/proceedings/81/slides/tsvwg-1.pdf

Saratoga is intended for high-end sensor equipment that needs to move files and stream data in private networks; engineered for speed and efficiency, not concerned with congestion in these private networks with dedicated links, as the network design engineers congestion out.

Saratoga has been used from space since 2004 on remote-sensing satellites, where link speeds and filesizes are getting faster rapidly. It's now being implemented and evaluated for continent-wide radio astronomy networks based on high-speed fibre: the Australian Square Kilometer Array bid you're aware of (and you know Chas Smith, who is doing that. We say 'petabytes' and 'exabytes' a lot.) Meanwhile, NASA Glenn is interested in using Saratoga for cameras on unmanned aerial vehicles (UAVs).

After a few years of working quietly on this, we have multiple implementations, interoperability...

Further information is at:
http://personal.ee.surrey.ac.uk/Personal/L.Wood/dtn/saratoga

I'm currently seeking funding for this work.

If you're interested in Saratoga, please attend Will Ivancic's presentation to tsvwg on Friday, or talk to Will or to Wes Eddy, who are at IETF Quebec.

regards,

Lloyd Wood
http://sat-net.com/L.Wood/CCSR

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]] 
> Sent: 28 July 2011 11:58
> To: [email-masked]
> Cc: [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Smart things in stupid networks
> 
> FYI...
> 
> I sat down last night to categorize what work we have around 
> that directly relates (as in, *says* it relates) to sensors, 
> the smart grid, and the nebulous "internet of things". What I 
> came up with is attached: 46 documents in 8 working groups or 
> research groups, touching on everything from "here's how to 
> build a home" to routing architectures to energy management MIBs.
> 
> I personally would be interested to have the various people 
> involved comment for the group on what their contributions 
> are about. It looks interesting, and enquiring minds want to know :-)
> 
> Core:

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 28 Jul 2011 09:38:50 -0400

Fred, glad to see this list. I hope you aggregate all this information into a ID. I provided a bit of information inline and one more draft of mine that I would to mention is

Apps Area:
draft-jennings-senml-06.txt

This draft defines a data format for reporting sensor values.

> draft-sarikaya-core-sbootstrapping-02.txt

The key core drafts are 

draft-ietf-core-block-04.txt
draft-ietf-core-coap-07.txt
draft-ietf-core-link-format-06.txt
draft-ietf-core-observe-02.txt

The goal of core is to provide a light weight protocol that sits in the stack in a similar place to HTTP. It can be used to set and retrieve resources on a very light weight constrained device such as a sensor. It also support a pub/sub model to be notified any time the a resource changes. Currently the specification do not do a huge amount to support for sleeping devices but it is a clear goal of many of the participants to get the core protocols to work well with devices that spend most of their time in low power sleep mode. 

> draft-jennings-energy-pricing-01.txt

This draft provides a way for a client device such as an electric car to find the future prices of electrical energy so that it adjust the times it wishes to consume energy to charge the car.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 28 Jul 2011 21:02:50 +0300

Hi Fred,

Thank you for collecting this list. It's very useful.

Let me also add another I-D: 

http://tools.ietf.org/html/draft-ohba-pana-relay-03

PANA (RFC 5191) is adopted by Zigbee Alliance Smart Energy Profile 2.0 for
authenticating devices for network access. PANA Relay introduces a DHCP-like
relay operation to PANA. This I-D is in RFC Editor's queue.

Regards,

Alper

> From: [email-masked] [mailto:smartpower-interest-
> [email-masked]] On Behalf Of Fred Baker
> Sent: Thursday, July 28, 2011 1:58 PM
> Cc: [email-masked]; [email-masked]; core-
> [email-masked]; [email-masked]; eman-
> [email-masked]; [email-masked]; homenet-
> [email-masked]; [email-masked]; roll-
> [email-masked]; [email-masked]
> Subject: [smartpower-interest] Smart things in stupid networks
> 
> FYI...
> 
> I sat down last night to categorize what work we have around that
> directly relates (as in, *says* it relates) to sensors, the smart grid,
> and the nebulous "internet of things". What I came up with is attached:
> 46 documents in 8 working groups or research groups, touching on
> everything from "here's how to build a home" to routing architectures
> to energy management MIBs.
> 
> I personally would be interested to have the various people involved
> comment for the group on what their contributions are about. It looks
> interesting, and enquiring minds want to know :-)
> 
> Core:
> _______________________________________________
> smartpower-interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smartpower-interest

---

From: [email-masked]
Date: Thu, 28 Jul 2011 18:08:31 +0000

Hi fred,

The draft draft-irtf-hiprg-rfid-03.txt is based on two ideas

- A "smart" thing has an identity, but not neccesary an IP layer
- A "smart" thing needs strong privacy, eg no fix identifier such as an IP  
address ou a hash value of some value

more details at
http://perso.telecom-paristech.fr/~urien/hiprfid/index.html

Best Regards

Pascal

> everything from "here's how to build a home" to routing architectures to  
> energy management MIBs.

---

From: <[email-masked]>
Date: Thu, 28 Jul 2011 20:20:00 +0000

Hi,

Our draft (6LoWpan: draft-ietf-6lowpan-btle-01.txt) is about transmitting IPv6 packets over Bluetooth Low Energy Radio. In practice we are reusing/adapting 6LoWpan stack, describing what parts of it will or will not be used and how BT-LE enables eliding source and/or destination addresses in certain cases. The work is connected to Bluetooth-SIG standardization organization: our draft assumes that SIG allocates a new fixed channel ID for IP traffic in BT-LE L2CAP layer.

Dr. Johanna Nieminen
Principal Researcher
Security and Networking Protocols team, NRC Radio Systems Laboratory, 
Chief Technology Office, Nokia
Mobile: +358 (0)50 486 3667

>From: ext Fred Baker [mailto:[email-masked]]
>Sent: 28 July, 2011 13:58
>Cc: [email-masked]; [email-masked]; lwig-
>[email-masked]; [email-masked]; eman-
>[email-masked]; [email-masked]; tictoc-
>I sat down last night to categorize what work we have around that directly
>relates (as in, *says* it relates) to sensors, the smart grid, and the nebulous
>"internet of things". What I came up with is attached: 46 documents in 8
>working groups or research groups, touching on everything from "here's how
>to build a home" to routing architectures to energy management MIBs.
>

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 28 Jul 2011 22:40:50 +0200

Hi Fred,

'draft-ietf-opsawg-management-stds' has been mainly triggered by NIST
SGIP and IEC guys and aims to complement RFC 6272 on "Internet Protocols
for the Smart Grid". The draft is being discussed in the SGIP IP Suite
WG and will be reviewed there before publication.

'draft-schoenw-netconf-light' defines a subset of the NETCONF protocol
(NETCONF Light) that can be implemented on resource constrained devices.
An implementation of NETCONF Light on Contiki operating system has been
created and is running on AVR Raven motes. The implementation is going
to be published as open-source soon.

Cheers, 
Mehmet 

> From: ext Cullen Jennings [mailto:[email-masked]]
> Sent: Thursday, July 28, 2011 3:39 PM
> To: Fred Baker (fred)
> Cc: [email-masked]; [email-masked]; homenet-
> [email-masked]; [email-masked]; 6man-
> [email-masked]; [email-masked]; 6lowpan-
> [email-masked]; [email-masked]; opsawg-
> [email-masked]; [email-masked]; netconf-
> [email-masked]
> Subject: Re: Smart things in stupid networks
> 
> 
> Fred, glad to see this list. I hope you aggregate all this information
into a
> ID. I provided a bit of information inline and one more draft of mine
that I
> would to mention is
> The goal of core is to provide a light weight protocol that sits in
the stack
> in a similar place to HTTP. It can be used to set and retrieve
resources on a
> very light weight constrained device such as a sensor. It also support
a
> pub/sub model to be notified any time the a resource changes.
Currently the
> specification do not do a huge amount to support for sleeping devices
but it
> is a clear goal of many of the participants to get the core protocols
to work
> well with devices that spend most of their time in low power sleep
mode.
> This draft provides a way for a client device such as an electric car
to find
> the future prices of electrical energy so that it adjust the times it
wishes
> to consume energy to charge the car.
>

---

From: "Simpson, Robby (GE Energy Services)" <[email-masked]>
Date: Thu, 28 Jul 2011 19:26:27 -0400

> authenticating devices for network access. PANA Relay introduces a
DHCP-
> like relay operation to PANA. This I-D is in RFC Editor's queue.

Hi Alper -- one clarification.

PANA is used by the ZigBee Alliance's ZigBee IP stack (a collection of
largely, if not exclusively IETF standards to allow IPv6 to work on
802.15.4).  This is different than the Smart Energy Profile 2.0, which
is link-layer agnostic and operates at the application layer.

- Robby

---

From: Don Sturek <[email-masked]>
Date: Thu, 28 Jul 2011 16:34:37 -0700

Hi Pascal,

I would expect that the presence of an IP layer is the minimum bar for
inclusion into the IETF internet of things.

Question for you:  How would devices without an IP layer participate in an
IP network?

Don

From:  <[email-masked]>
Date:  Thu, 28 Jul 2011 18:08:31 +0000
To:  Fred Baker <[email-masked]>
Cc:  <[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>,
<[email-masked]>
Subject:  Re: [smartpower-interest] Smart things in stupid networks

Hi fred, 

 - A  "smart" thing has an identity, but not neccesary an IP layer
-  A  "smart" thing  needs strong privacy, e.g. no fix identifier such as an
IP address ou a hash value of some value

more details at 

Best Regards 

Pascal 

relates (as in, *says* it relates) to sensors, the smart grid, and the nebulous
"internet of things". What I came up with is attached: 46 documents in 8 working
groups or research groups, touching on everything from "here's how to build a
home" to routing architectures to energy management MIBs.
> 
> 
> 
> 
> 
> I personally would be interested to have the various people involved comment
for the group on what their contributions are about. It looks interesting, and
enquiring minds want to know :-)
>_______________________________________________ smartpower-interest mailing
list [email-masked]
https://www.ietf.org/mailman/listinfo/smartpower-interest

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 29 Jul 2011 04:39:24 +0200

Hi Fred:

Thanks for starting this.

I note that your query found a number of ROLL drafts but missed RPL and
the main Objective Functions (OF0 and MRHof).
draft-ietf-roll-rpl
draft-ietf-roll-of0
draft-ietf-roll-minrank-hysteresis-of

RPL is a generic DV routing protocol that addresses routing in WSN and
considers:
1) building a multilink subnet. Eventually passing on subnet related
information (PIO) to allow slaac along the forming DAG.
2) routing via multiple gateways within one or multiple isolated network
instances

OFs adapt the protocol to the various constraints and metrics used in a
given instance; see also:
draft-ietf-roll-routing-metrics

Forwarding over instances can be done with additional 6MAN drafts:
draft-ietf-6man-rpl-option and 
draft-ietf-6man-rpl-routing-header

The RPL (HbH) option indicates amongst other things the instance ID
which can be seen as a L3 VLANID, though the address space specified
here is too small to be generalized. 

About draft-ietf-6lowpan-hc:
This work updates RFC 4944 to compress over 802.15.4 based networks. A
number of variations are being proposed for various other links from BT
to DECT via BACNET. 6LoPWAN HC was done in liaison with ISA100.11a, the
first industrial standard for WSN to adopt IP (v6 for that matter) which
adopted it, now becoming an IEC standard.
See also:
draft-lynn-6man-6lobac

Cheers,

Pascal

> From: Fred Baker (fred)
> Sent: Thursday, July 28, 2011 12:58 PM
directly

---

From: [email-masked]
Date: Fri, 29 Jul 2011 09:57:25 +0000

Hi Don,

In http://tools.ietf.org/html/draft-urien-hip-iot-00 there is a discussion  
about the RFID and the Internert Of Thing, and one issue is IP or not IP  
layer in the RFID.

If there is enough computing power then an IP stack may be supported

But

- An RFID has no battery
- An RFID is powered by a reader , the reader always includes an IP stack
- The primary goal of an RFID is to deliver a serial number, we want to  
protect this information.
- Some additionnal read/write operations may be available

In draft-irtf-hiprg-rfid-03.txt (  
http://www.ietf.org/proceedings/81/slides/HIPRG-1.pdf ) we use a modified  
HIP layer in the RFID and an IP stack in the reader. For read/write  
operations an ESP protocol could be used by the RFID, whose PDUs are  
transported by the reader IP packets.

The open issues are
- what protocol is running in the RFID for identity protection,
- what services are provided by the reader.

Best Regards

Pascal

> From: [email-masked]>
> To: Fred Baker [email-masked]>
> Cc: [email-masked]>, [email-masked]>,  
> [email-masked]>, [email-masked]>,  
> [email-masked]>, [email-masked]>,  
> [email-masked]>, [email-masked]>,  
> [email-masked]>, [email-masked]>,  
> [email-masked]>

> - A "smart" thing needs strong privacy, eg no fix identifier such as an  

> Le , Fred Baker [email-masked]> a écrit :

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 30 Jul 2011 16:30:54 -0400

+1 this effort would nicely complement RFC 6272

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cullen Jennings
Sent: Thursday, July 28, 2011 9:39 AM
To: Fred Baker (fred)
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: Re: [smartpower-interest] Smart things in stupid networks

Fred, glad to see this list. I hope you aggregate all this information into
a ID. I provided a bit of information inline and one more draft of mine that
I would to mention is

Apps Area:

The key core drafts are 

The goal of core is to provide a light weight protocol that sits in the
stack in a similar place to HTTP. It can be used to set and retrieve
resources on a very light weight constrained device such as a sensor. It
also support a pub/sub model to be notified any time the a resource changes.
Currently the specification do not do a huge amount to support for sleeping
devices but it is a clear goal of many of the participants to get the core
protocols to work well with devices that spend most of their time in low
power sleep mode. 

> draft-jennings-energy-pricing-01.txt

This draft provides a way for a client device such as an electric car to
find the future prices of electrical energy so that it adjust the times it
wishes to consume energy to charge the car.