wdiff rfc8272.original rfc8272.txt

Network Working Group
Independent Submission C. Schmitt
Internet-Draft
Request for Comments: 8272 B. Stiller
Intended status:
Category: Informational University of Zurich
Expires: March 24, 2018
ISSN: 2070-1721 B. Trammell
ETH Zurich
September 20,
November 2017

TinyIPFIX for smart meters Smart Meters in constrained networks
draft-schmitt-ipfix-tiny-04 Constrained Networks

Abstract

This document specifies the TinyIPFIX protocol that serves is used for
transmitting smart metering smart-metering data in constrained networks such as
6LoWPAN [RFC4944]. IPv6
over Low-Power Wireless Personal Area Networks (6LoWPAN, RFC 4944).
TinyIPFIX is derived from IPFIX [RFC7011] IP Flow Information Export (RFC 7011) and
adopted to the needs of constrained networks. This document
specifies how the TinyIPFIX Data and Template Records are transmitted
in constrained networks such as 6LoWPAN and how TinyIPFIX data can be
converted into unTinyIPFIX data that is not TinyIPFIX in a proxy device.

Status of This Memo

This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.

This is a contribution to the
provisions RFC Series, independently of BCP 78 any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and BCP 79.

Internet-Drafts makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are working documents not a candidate for any level of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list
Standard; see Section 2 of RFC 7841.

Information about the current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 March 24, 2018.
https://www.rfc-editor.org/info/rfc8272.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3
1.1. Document structure Structure . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4
3. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Hardware constraints Constraints . . . . . . . . . . . . . . . . . . 6
3.2. Energy constraints Constraints . . . . . . . . . . . . . . . . . . . 6 7
3.3. Packet size constraints Size Constraints . . . . . . . . . . . . . . . . . 7
3.4. Transport protocol constraints Protocol Constraints . . . . . . . . . . . . . 7 8
4. Application scenarios Scenarios for TinyIPFIX . . . . . . . . . . . . . 8 9
5. Architecture for TinyIPFIX . . . . . . . . . . . . . . . . . 11
6. TinyIPFIX Message Format . . . . . . . . . . . . . . . . . . 13 14
6.1. TinyIPFIX Message Header . . . . . . . . . . . . . . . . 14 15
6.2. TinyIPFIX Set . . . . . . . . . . . . . . . . . . . . . . 18
6.3. TinyIPFIX Template Record Format . . . . . . . . . . . . 19
6.4. Field Specifier Format . . . . . . . . . . . . . . . . . 20
6.5. TinyIPFIX Data Record Format . . . . . . . . . . . . . . 21
7. TinyIPFIX Mediation . . . . . . . . . . . . . . . . . . . . . 21
7.1. Expanding the Message header Header . . . . . . . . . . . . . . 24
7.2. Translating the Set Headers . . . . . . . . . . . . . . . 25
7.3. Expanding the Template Record Header . . . . . . . . . . 25
8. Template Management . . . . . . . . . . . . . . . . . . . . . 25
8.1. TCP / SCTP TCP/SCTP . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Security considerations Considerations . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments References . . . . . . . . . . . . . . . . . . . . . . . 26
12. . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . 27
12.1. Normative References . . . . . . . . . . 28
Acknowledgments . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 28 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 30

1. Introduction

Smart meters that form a constrained wireless network need an
application layer
application-layer protocol that allows the efficient transmission of
metering data from the devices to a central analysis device. The
meters used to build such networks are usually equipped with low-cost
and low-power hardware. This leads to constraints in computational
capacities, available memory memory, and networking resources.

The devices are often battery powered and are expected to run for a
long time without having the possibility of recharging themselves.
In order to save energy, smart meters often power off their wireless
networking device. Hence, they don't have a steady network
connection, but
connection; they are only part of the wireless network as needed when
there is data that needs to be exported. A push protocol like TinyIPFIX, where
data is transmitted autonomic autonomically from the meters to one or more
collectors, is suitable for reporting metering data in such networks.

TinyIPFIX is derived from IPFIX [RFC7011] and therefore [RFC7011]; therefore, it inherits
most of its IPFIX's properties. One of these properties is the
separation of data and its data description by encoding the former in
Data Sets and the latter in Template Sets.

Transforming TinyIPFIX to IPFIX as per [RFC7011] is very simple and
can be done on the border between the constrained network and the
more general network. The transformation between one form of IPFIX
data into another is known as IPFIX Mediation "IPFIX Mediation" [RFC5982]. Hence,
smart metering
smart-metering networks that are based on TinyIPFIX can be easily
integrated into an existing IPFIX measurement infrastructure.

1.1. Document structure Structure

Section 2 introduces the terminology used in this draft. document.
Afterwards, hardware and software constraints in constrained
networks, which will motivate our modifications to the IPFIX
protocol, are discussed in Section 3. Section 4 describes the
application scenarios and Section 5 describes the architecture for
TinyIPFIX. Section 6 defines the TinyIPFIX protocol itself and
discusses the differences between TinyIPFIX and IPFIX. The Mediation
Process from TinyIPFIX to IPFIX is described in Section 7. Section 8
defines the process of Template Management on the Exporter and the
Collector. Section 9 and Section 10 discuss the security and IANA
considerations for TinyIPFIX.

2. Terminology

Most of the terms used in this draft document are defined in [RFC7011]. All
Each of these terms are written begins with their first letter being capitalized. a capital letter. Most of the terms
that are defined for IPFIX can be used to describe TinyIPFIX. This draft
document uses the term IPFIX "IPFIX" to refer to IPFIX as defined in
[RFC7011] and the term TinyIPFIX for the protocol specified in this
draft document assuming constrained networks. The
term prefix "Tiny" is used in front of the
added to IPFIX term to distinguish between the IPFIX version and the
TinyIPFIX version.

The terms IPFIX Message, IPFIX Device, Set, Data Set, Template Set,
Data Record, Template Record, Collecting Process, Collector,
Exporting Process Process, and Exporter are defined as in [RFC7011]. The
term IPFIX Mediator is defined in [RFC5982]. The terms Intermediate
Process, IPFIX Proxy, IPFIX Concentrator are defined in [RFC6183].

All these the terms above have been adapted from the IPFIX definitions. As
they keep a similar notion but in a different context of constrained
networks, the term "TinyIPFIX" now complements precedes the defined terms.

The term smart meter "smart meter" is used to refer to constrained devices like
wireless sensor nodes, motes motes, or any other kind of small constrained
device that can be part of a network that is based on IEEE802.15.4 IEEE 802.15.4
and 6LoWPAN [RFC4944].

TinyIPFIX Exporting Process

The TinyIPFIX Exporting Process is a process that exports
TinyIPFIX Records.

TinyIPFIX Exporter

A TinyIPFIX Exporter is device that contains at least one
TinyIPFIX Exporting Process.

TinyIPFIX Collecting Process

The TinyIPFIX Collecting Process is a process inside a device that
is able to receive and process TinyIPFIX Records.

TinyIPFIX Collector

A TinyIPFIX Collector is a device that contains at least one
TinyIPFIX Collecting Process.

TinyIPFIX Device

A TinyIPFIX Device is a device that contains one or more TinyIPFIX
Collectors or one or more TinyIPFIX Exporters.

TinyIPFIX Smart Meter

A TinyIPFIX Smart Meter is a device that contains the
functionality of a TinyIPFIX Device. It is usually equipped with
one or more sensors that meter a physical quantity, like power
consumption, temperature, or physical tampering with the device.
Every TinyIPFIX Smart Meter MUST at least contain a TinyIPFIX
Exporting Process. It MAY contain a TinyIPFIX Collecting Process
in order to work as a TinyIPFIX Proxy or TinyIPFIX Concentrator.

TinyIPFIX Data Record

A TinyIPFIX Data Record equals an IPFIX Data Record in [RFC7011].
The term is used to distinguish between IPFIX and TinyIPFIX
throughout this document.

TinyIPFIX Template Record

A TinyIPFIX Template Record is similar to an IPFIX Template Record
in [RFC7011]. The Template Record Header is substituted with a
TinyIPFIX Template Record Header and is otherwise equal to a
Template Record. See Section 6.3.

TinyIPFIX Set

The TinyIPFIX Set is a group of TinyIPFIX Data Records or
TinyIPFIX Template Records with a TinyIPFIX Set Header. Its
format is defined in Section 6.2.

TinyIPFIX Data Set

The TinyIPFIX Data Set is a TinyIPFIX Set that contains TinyIPFIX
Data Records.

TinyIPFIX Template Set

A TinyIPFIX Template Set is a TinyIPFIX Set that contains
TinyIPFIX Template Records.

TinyIPFIX Message

The TinyIPFIX Message is a message originated by a TinyIPFIX
Exporter. It is composed of a TinyIPFIX Message Header and one or
more TinyIPFIX Sets. The TinyIPFIX Message Format is defined in
Section 6.

TinyIPFIX Intermediate Process

A TinyIPFIX Intermediate Process is an IPFIX Intermediate Process
that can handle TinyIPFIX Messages.

TinyIPFIX Proxy

A TinyIPFIX Proxy is an IPFIX Proxy that can handle TinyIPFIX
Messages.

TinyIPFIX Concentrator

A TinyIPFIX Concentrator is device that can handle TinyIPFIX
Messages (e.g., pre-process them) and is not constrained.

TinyIPFIX Proxy

A TinyIPFIX Proxy is an IPFIX Proxy that can handle TinyIPFIX
Messages and is not constrained.

A TinyIPFIX Transport Session is defined by the communication between
a TinyIPFIX Exporter (identified by an 6LoWPAN-Address, the Transport
Protocol, and the Transport Port) and a TinyIPFIX Collector
(identified by the same properties).

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

3.
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

3. Constraints

3.1. Hardware constraints Constraints

The target devices for TinyIPFIX are usually equipped with low-cost
hardware and therefore
hardware; therefore, they face several constraints concerning CPU and
memory [Schmitt09]. For example, the IRIS mote from Crossbow
Technologies
Technologies, Inc. has a size of 58 x 32 x 7 mm (without a battery
pack) [Crossbow]. [IRIS]. Thus, there is little space for micro controller, a micro-controller,
memory (128 kb program flash, 512 kb measurement serial flash, 8 kb
RAM, 4 kb configuration EEPROM), and radio frequency radio-frequency transceiver,
which are located on the board. Similar issues occure by The TelosB motes produced by
Crossbow Technologies Technologies, Inc. [Crossbow] [TelosB] and Advantic Sys.
Inc. ADVANTIC SISTEMAS Y
SERVICIOS S.L. [Advantic] are similar sized, but offering more
memory (48 kb flash, 1024 kb serial serial, flash, 10 kb RAM, 16 kb
configuration EEPROM). The same holds for OpenMote, but the offering
is 512 kb flash and 32 kb RAM [openMote].

Network protocols used on such hardware need to respect these
constraints. They must be simple to implement using little code and
little run time run-time memory and should produce little overhead when
encoding the application payload.

3.2. Energy constraints Constraints

Smart meters that are battery powered have hard energy constraints
[Schmitt09]. By power supply of If two 2 AA 2,800-mAh 2800-mAh batteries this
means power the mote, they
contain approximately 30,240J. 30,240 Joule of energy. If they run out of
power, their battery has to be changed, which means physical
manipulation to the device is necessary. Using Therefore, using as little
energy as possible for network communication is therefore desired.

A smart metering smart-metering device can save a lot of energy, if it powers down
its radio frequency radio-frequency transceiver. Such devices do not have permanent
network connectivity but connectivity; they are only part of the network as needed. A
push protocol, where only one side is sending data, is suitable for
transmitting application data under such circumstances. As the
communication is unidirectional, a meter can completely power down
its radio frequency radio-frequency transceivers as long as it does not have any data
to send. If the metering device is able to keep a few measurements
in memory, and if real time real-time metering is not a requirement, the
TinyIPFIX Data Records can be pushed less frequently, therefore
saving some more energy on the radio frequency radio-frequency transceivers.

3.3. Packet size constraints Size Constraints

TinyIPFIX is mainly targeted for the use in 6LoWPAN networks, which
are based on IEEE 802.15.4 [RFC4944]. However, the protocol can also
be used to transmit data in other networks when a mediator is used
for translating the TinyIPFIX data into the data format used in the
other network (e.g., IPFIX) and IPFIX). And the protocol is able to map the
6LoWPAN addresses to the addresses used in the other network. This
operation typically consists of per-message re-encapsulation and/or
re-encoding. As defined [RFC4944], IEEE 802.15.4 starts from a
maximum physical layer packet size of 127 octets (aMaxPHYPacketSize)
and a maximum frame overhead of 25 octets (aMaxFrameOverhead),
leaving a maximum frame size of 102 octets at the media access
control (MAC) layer. IPv6 on On the other hand hand, IPv6 defines a minimum MTU
of 1280 octets. Hence, fragmentation has to be implemented in order
to transmit such large packets. While fragmentation allows the
transmission of large messages, its use is problematic in networks
with high packet loss because the complete message has to be
discarded if only a single fragment gets lost.

TinyIPFIX enhances IPFIX by a header compression header-compression scheme, which allows
the header size overhead to be significantly reduced. Additionally,
the overall TinyIPFIX Message size is reduced, which reduces the need
for fragmentation.

3.4. Transport protocol constraints Protocol Constraints

The IPFIX standard [RFC7011] defines several transport protocol
bindings for the transmission of IPFIX Messages. SCTP Stream Control
Transmission Protocol (SCTP) support is REQUIRED for any IPFIX Device
to achieve standard conformance [RFC7011], and its use is highly
recommended. However, sending IPFIX over UDP and TCP MAY also be
implemented.

This transport protocol recommendation is not suitable for TinyIPFIX.
A header compression scheme that allows a compression of an IPv6
header from 40 octets down to 2 octets is defined in 6LoWPAN. There
is a similar compression scheme for UDP, but there is no such
compression for TCP or SCTP headers. If header compression can be
employed, more space for application payload is available.

Using

Therefore, using UDP on the transport layer for transmitting
TinyIPFIX Messages is therefore RECOMMENDED. Furthermore, TCP or SCTP are
currently not supported on some platforms, like on TinyOS [Harvan08].
Hence, UDP may be the only option.

Every TinyIPFIX Exporter and Collector MUST implement UDP transport transport-
layer support for transmitting data in a constrained network
environment. It MAY also offer TCP or SCTP support. In the case in
which TCP or SCTP MAY be used used, power consumption will grow and the
available size of application payload compared to the use of UDP May
be reduced. If TinyIPFIX is transmitted over a non-constrained unconstrained
network, using SCTP as a transport layer transport-layer protocol is RECOMMENDED.
TinyIPFIX works independent of the target environment, because it
MUST only be ensured that all intermediate devices can understand
TinyIPFIX and be able to extract needed packet information (e.g., IP
destination address). TinyIPFIX messages can be included in other
transport protocols in the payload whenever is needed necessary, making
TinyIPFIX highly flexible and usable for different communication
protocols (e.g.,
COAP, Constrained Application Protocol (CoAP), UDP, TCP).
TinyIPFIX itself just specifies a messages format for the collected
data to be transmitted.

The constraints on UDP usage given in Section 6.2 of [RFC5153] apply
to TinyIPFIX as well. TinyIPFIX is not intended for use over the
open Internet. In general, the networks on which it runs are
considered dedicated for sensor operations, operations and are under the control
of a single administrative domain.

4. Application scenarios Scenarios for TinyIPFIX

TinyIPFIX is derived from IPFIX [RFC7011] and [RFC7011]; therefore, it is therefore a
unidirectional push protocol assuming UDP usage. This means all
communication that employs TinyIPFIX is unidirectional from an
Exporting Process to a Collecting Process. Hence, TinyIPFIX only
fits for application scenarios where meters transmit data to one or
more Collectors. In case pull request requests should also be supported by
TinyIPFIX
TinyIPFIX, it is RECOMMENDED not to change the code of TinyIPFIX much
to get along with the restricted memory available [schmitt2017]. [Schmitt2017].
Meaning including just a one bit field, called type, to distinguish
between push and pull messages would be feasable, feasible, but the filtering
SHOULD be done by the gateway and not by the constrained device, device;
meaning if a pull is performed performed, the constained constrained device is triggered
to create a TinyIPFIX message immediately as usual, set the type
field to one instead of zero (for a push message), and sends send message
to the gateway. Where at At the gateway gateway, the filtering is performed based on
the pull request.

If TinyIPFIX is used over UDP, as recommended, packet loss can occur.
Furthermore, if an initial Template Message gets lost, and is
therefore unknown to the Collector, all TinyIPFIX Data Sets that
reference this Template cannot be decoded. Hence, all these Messages
are lost if they are not cached by the Collector. It should be clear
to an application developer, developer that TinyIPFIX can only be used over UDP
if these TinyIPFIX Message losses are not a problem. Avoiding To avoid this
loss
loss, it is RECOMMEND RECOMMENDED to repeat the Template Message periodically
having periodically,
keeping in mind that a Template never changes for a constrained
device after deployment. Even when Template Messages becomes become lost in
the
network network, the data can be manually translated later when the
Template Messages is resend. re-sent. Including an acknowledgement mechanism
is NOT RECOMMENDED due to overhead, because this would require
storage of any send sent data on the constrained devices until it is was
acknowledged. In critial applications critical applications, it is RECOMMENDED to repeat
the Template Message more often.

TinyIPFIX over UDP is especially not a suitable protocol for
applications where sensor data trigger policy decisions or
configuration updates for which packet loss is not tolerable.

Applications that use smart sensors for accounting purposes for long
time long-
term measurements can benefit from the use of TinyIPFIX. One
application for IPFIX is long term long-term monitoring of large physical
volumes. In [Tolle05], Tolle et al. built a system for monitoring a
"70-meter tall redwood tree, at a density interval of 5 minutes in
time and 2 meters in space". The sensor node infrastructure was
deployed to measure the air temperature, relative humidity humidity, and
photosynthetically active solar radiation over a long time long-term period.

TinyIPFIX is a good fit for such scenarios. Data can be measured by
the sensors of the TinyIPFIX Smart Meter over several 5 minute 5-minute time
intervals and
intervals; the measurements can be accumulated into a single
TinyIPFIX Message. As soon as enough measurements are stored in the
TinyIPFIX Message, e.g. e.g., if the TinyIPFIX Message size fills the
available payload in a single IEEE 802.15.4 packet, the wireless
transceiver can be activated and the TinyIPFIX Message can be
exported to a TinyIPFIX Collector.

Similar sensor networks have been built to monitor the habitat of
animals, e.g. e.g., in the "Great Duck Island Project" [GreatDuck], [GreatDuck]
[SMPC04]. The purpose of the sensor network was to monitor the birds
by deploying sensors in and around their burrows. The measured
sensor data was collected and stored in a database for offline
analysis and visualization. Again, the sensors can perform their
measurements periodically, accumulate the sensor data data, and export
them to a TinyIPFIX Collector.

Other application scenarios for TinyIPFIX could be applications where
sensor networks are used for long term long-term structural health monitoring
in order to investigate long term long-term weather conditions on the structure
of a building. For example, a smart metering smart-metering network has been built
to monitor the structural health of the Golden Gate Bridge [Kim07].
If a sensor network is deployed to perform a long term long-term measurement of
the structural integrity, TinyIPFIX can be used to collect the sensor
measurement
sensor-measurement data.

If an application developer wants to decide whether to use TinyIPFIX
for transmitting data from smart meters, he must take the following
considerations into account:

1. The application should require a push protocol per by default. The
timing intervals of when to push data should be pre-defind predefined before
deployment. The property above allows a TinyIPFIX Smart Meter to
turn off its wireless device in order to save energy, as it does
not have to receive any data.

2. If real-time reporting is not required, the application might
benefit from accumulate combining several measurements into a single
TinyIPFIX Message, causing delay but lowering traffic in the
network. TinyIPFIX easily allows allow the accumulation combination of several
measurements into a single TinyIPFIX Message (or a single
packet). This accumulation combination can happen on the TinyIPFIX Smart
Meter that accumulates combines several of its own measurements. Or Or, it can
happen within a multi-hop wireless network where one IPFIX Proxy accumulates
combines several TinyIPFIX Messages into a single TinyIPFIX
Message before forwarding them.

3. The application must accept potential packet loss. TinyIPFIX
only fits for applications where metering data is stored for
accounting purposes and not for applications where the sensor
data triggers configuration changes or policy decisions, except
when Message loss is acceptable for some reason.

4. The application must not require per-message export timestamps
(e.g.
(e.g., for auditing). TinyIPFIX removes export timestamps,
generally only useful for template management operations Template Management operations, which
it also does not support, from IPFIX. This is a minor
inconvenience, since per-record timestamp Information Elements
are also available in IPFIX.

5. Architecture for TinyIPFIX

The TinyIPFIX architecture is similar to the IPFIX architecture,
which is described in [RFC5470]. The most common deployment of
TinyIPFIX Smart Meters is shown in Figure 1 1, where each TinyIPFIX
Smart Meter can have different sensors available (e.g., IRIS:
Temperature, Humidity, Sound; TelosB: Temperature, Bridgeness,
Humidity, GPS) building the sensor data.

+------------------------+ +------------------------+
| TinyIPFIX Device | ... | TinyIPFIX Device |
| [Exporting Process] | | [Exporting Process] |
+------------------------+ +------------------------+
| |
TinyIPFIX | | TinyIPFIX
| |
v v
+----------------------------------+
|
v
+----------------------------+
| TinyIPFIX Collector |
| [Collecting Process(es)] |
+----------------------------+
|
v
+-----------------------+
| |
v v
+----------------+ +----------------+
|[*Application 1]| ... |[*Application n]|
+----------------+ +----------------+

Figure 1: Direct transmission Transmission between TinyIPFIX
Devices and
applications Applications

A TinyIPFIX Smart Meter (S.M.) receives measurement data from its
internal sensors to to create its TinyIPFIX messages. It then Messages. Then, it encodes
the results into a TinyIPFIX Message usinf using a TinyIPFIX Exporting
Process and exports this TinyIPFIX Message to one or more TinyIPFIX
Collectors. The TinyIPFIX Collector runs one or more applications
that process the collected sensor data. The TinyIPFIX Collector can
be deployed on non-constrained unconstrained devices at the constrained network
border.

A second way to deploy TinyIPFIX Smart Meter can employ accumulation
on TinyIPFIX Messages during their journey through the constrained
network as shown in Figure 2. This accumulation can be performed by
TinyIPFIX Concentrators. Such devices must have enough resources to
perform the accumulation.

Figure 2: Accumulation of TinyIPFIX

TinyIPFIX Smart Meters send their data to a TinyIPFIX Concentrator,
which needs to have enough storage space to store the incoming data.
If the TinyIPFIX Concentrator is hosted in a TinyIPFIX Smart Meter Meter,
it MAY be also be able to collect data from it sensors, if activated, it activated.
It may also accumulate the incoming data with its own measurement
data. The accumulated data can then be re-exported again to one or more
Collectors. In that case case, the TinyIPFIX Concentrator can be viewed
as receiving data from multiple Smart Meters - Meters: one locally and some
remotely.

The last deployment, shown in Figure 3, employs another TinyIPFIX
Mediation process.

Figure 3: TinyIPFIX Mediator

In this deployment, the TinyIPFIX Smart Meters transmit their
TinyIPFIX Messages to one node, e.g. e.g., the base station, which
translates the TinyIPFIX Messages to IPFIX Messages. The IPFIX
Messages can then be exported into an existing IPFIX infrastructure.
The Mediation process from TinyIPFIX to IPFIX is described in
Section 7.

6. TinyIPFIX Message Format

A TinyIPFIX IFPIX Message starts with a TinyIPFIX Message Header,
followed by one or more TinyIPFIX Sets. The TinyIPFIX Sets can be
either of type TinyIPFIX Template Set or of type TinyIPFIX Data Set.
A TinyIPFIX Message MUST only contain one type of TinyIPFIX Set. The
format of the TinyIPFIX Message is shown in Figure 4.

+----------------------------------------------------+
| TinyIPFIX Message Header |
+----------------------------------------------------+
| TinyIPFIX Set |
+----------------------------------------------------+
| TinyIPFIX Set |
+----------------------------------------------------+
...
+----------------------------------------------------+
| TinyIPFIX Set |
+----------------------------------------------------+

Figure 4: TinyIPFIX Message Format

6.1. TinyIPFIX Message Header

The TinyIPFIX Message Header is derived from the IPFIX Message
Header, with some optimization using field compression. The IPFIX
Message Header from [RFC7011] is shown in Figure 5.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: IPFIX Message Header

The length of the IPFIX Message Header is 16 octets octets, and every IPFIX
Message has to be started with it. The TinyIPFIX Message Header
needs to be smaller due to the packet size constraints discussed in
Section 3.3. The TinyIPFIX Header consists of a fixed part of three
octets as shown in Figure 6, followed by a variable part as shown in
Figure
Figures 7 to Figure 10.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|E| SetID | Length | Sequence | Ext. Sequenz Sequence |
|1|2|Lookup | | Number | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext. SetID |
+-+-+-+-+-+-+-+-+

Figure 6: Format of the TinyIPFIX Message Header
including fixed Fixed and
optional parts Optional Parts

The fixed part has a length of three 3 octets and consists of the "E1"
field (1 bit), the "E2" field (1 bit), the "SetID Lookup" field (4
bits), the "Length" field (10 bits), and the "Sequence Number" field
(8 bits). The variable part has a variable length defined by the
"E1" and "E2" fields in the fixed header. The four variants are
illustrated in Figure 7 to Figure 10 below.

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| SetID | Length | Sequence |
| | |Lookup | | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: TinyIPFIX Message Header format Format if E1 = E2 = 0

Figure 8: TinyIPFIX Message Header format Format if E1 = 1 and E2 = 0

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|E| SetID | Length | Sequence | Ext. Sequenz |
|1|2|Lookup | | Number | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: TinyIPFIX Message Header format Format if E1 = 0 and E2 = 1

Figure 10: TinyIPFIX Message Header format Format if E1 = E2 = 1

The fixed header fields are defined as follows [kothmayr10]
[schmitt2014]: [Kothmayr10]
[Schmitt2014]:

E1 and E2

The bits marked "E1" and "E2" control the presence of the field
"Ext. SetID" and the presence of the field "Ext. Sequence
Number"
Number", respectively.

In case E1 = E2 = 0 0, the TinyIPFIX message header Message Header has the format
shown in Figure 7. The fields Extended Sequence Number and
Extended SetID MUST NOT be present.

When E1 = 1, the extended SetID field MUST be present. Custom
SetIDs can be specified in the extended SetID field field, setting all
SetID Lookup bits to 1 (cf. Figure 8.) When evaluated, the value
specified in the extended SetID field is shifted left by 8 bits to
prevent collisions with the reserved SetIDs 0-255. To reference
these, shifting can be disabled by setting all SetID lookup bits
to 1.

Depending on the application application, sampling rates might be larger than
in typical constraind constrained networks (e.g., Wireless Sensor Networks
(WSN), Cyper-Physical-Systems (CPS)) and,
(WSNs), Cyber-Physical-Systems (CPS)); thus, they may have a large
quantity of records per packet. In order to make TinyIPFIX
applicable for those cases cases, E2 = 1 is set (cf. Figure 9). This
means the Extended Sequence Number field MUST be present present, offering
8-bit more sequence numbers as usual. Depending on the
constrained network settings also settings, the combination E1 = E2 = 1 is
possible also
possible, resulting in the maximum TinyIPFIX Message header shown
in Figure 10 where the Extended Sequence Number field and Extended
SetID field MUST both be present.

SetID Lookup

This field acts as a lookup field for the SetIDs and provides
shortcuts to often used SetIDs. Four values are defined:

Value = 0 means Lookup 0; Look up extended SetID field, Shifting enabled.

Value = 1 means 1; SetID = 2 and message contains a Template definition.

Value = 2 means 2; SetID = 256 and message containts contains Data Record for
Template 256. This places special importance on a single template
ID, but but, since most sensor nodes only define a single template
directly after booting and continue to stream data with this
template ID during the whole session lifetime, this shorthand is
useful for this case.

Value = 3-14 means 3-14; SetIDs are reserved for future extensions.

Value = 15 means lookup 15; look up extended SetID field, shifting enabled.

Length

The length field has a fixed length of 10 bits.

Sequence Number

Due to the low sampling rate in typical WSNs, the "Sequence
Number" field is only one byte long. However, some applications
may have a large quantity of records per packet. In this case case,
the sequence field can be extended to 16 bit by setting the E2-bit
to 1.

Since TinyIPFIX packets are always transported via a network
protocol, which specifies the source of the packet, the "Observation
Domain" can be equated with the source of a TinyIPFIX packet.
Therefore
Therefore, this IPFIX field has been removed from the TinyIPFIX
Header. Should an application require explicit Observation Domain
information, each Data Record in the TinyIPFIX data message may
contain an Observation Domain ID Information Element; see Section 3.1
of [RFC7011]. The version field has been removed since the SetID
lookup field provides room for future extensions. The specification
of a 32 bit time stamp 32-bit timestamp in seconds would require the time
synchronization across a wireless sensor wireless-sensor network and produces too
much overhead. Thus, the "Export Time" field has been removed. If
applications should require a concrete observation time (e.g.,
timestamp)
timestamp), it is RECOMMENDED to include it as a separate Information
Element in the TinyIPFIX Records.

6.2. TinyIPFIX Set

A TinyIPFIX Set is a set of TinyIPFIX Template or TinyIPFIX Data
Records. Depending on the TinyIPFIX Record type, the TinyIPFIX Set
can either be either a TinyIPFIX Template Set or a TinyIPFIX Data Set. Every
TinyIPFIX Set starts with a TinyIPFIX Set Header and is followed by
one or more TinyIPFIX Records.

The IPFIX Set Header consists of a two octet 2-octet "Set ID" field and a two
octet
2-octet "Length" field. These two fields are compressed to one 1 octet
each for the TinyIPFIX Set Header. The format of the TinyIPFIX Set
Header is shown in Figure 11.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tiny Set ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 11: TinyIPFIX Set Header
The two fields are defined as follows:

TinyIPFIX Set ID

The "Tiny Set ID" identifies the type of data that is transported
in the TinyIPFIX Set. A TinyIPFIX Template Set is identified by
TinyIPFIX Set ID 2. This corresponds to the Template Set IDs that
is
are used by IPFIX [[RFC7011]]. [RFC7011]. TinyIPFIX Set ID number 3 MUST NOT
be used, as Options Templates are not supported; a TinyIPFIX
Collector MUST ignore and SHOULD log any Set with Set ID 3. All
values from 4 to 127 are reserved for future use. Values above
127 are used for TinyIPFIX Data Sets.

Length

The "Length" Field contains the total length of the TinyIPFIX Set,
including the TinyIPFIX Set Header.

6.3. TinyIPFIX Template Record Format

The format of the TinyIPFIX Template Records is shown in Figure 12.
The TinyIPFIX Template Record starts with a TinyIPFIX Template Record
Header and this is followed by one or more Field Specifiers. The
Field Specifier format is defined as in Section 6.4 and is identical
to the Field Specifier definition in [RFC7011].

+--------------------------------------------------+
| TinyIPFIX Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+

Figure 12: TinyIPFIX Template Format

The format of the TinyIPFIX Template Record Header is shown in
Figure 13.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 13: TinyIPFIX Template Record Header

TinyIPFIX Template ID

Each TinyIPFIX Template Record must have a unique TinyIPFIX
Template ID (Comp. Temp ID) between 128 and 255. The TinyIPFIX
Template ID must be unique for the given TinyIPFIX Transport
Session.

Field Count

The number of fields placed in the TinyIPFIX Template Record.

6.4. Field Specifier Format

The type and length of the transmitted data is encoded in Field
Specifiers within TinyIPFIX Template Records. The Field Specifier is
shown in Figure 14 and is identical with the Field Specifier that was
defined for IPFIX [RFC7011].

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Information Element ident. | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14: TinyIPFIX Data Field Specifier

Where:

Enterprise bit. This is the first bit of the Field Specifier. If
this bit is zero, the Information Element Identifier identifies an
IETF-specified Information Element, and the four-octet Enterprise
Number field MUST NOT be present. If this bit is one, the
Information Element Identifier identifies an enterprise-specific
Information Element, and the Enterprise Number field MUST be
present.

Information Element Identifier

A numeric value that represents the type of Information Element.

Field Length

The length of the corresponding encoded Information Element, in
octets. Refer to [RFC7012]. The value 65535 is illegal in
TinyIPFIX, as variable-length Information Elements are not
supported.

Enterprise Number

IANA Private Enterprise Number of the authority defining the
Information Element identifier in this Template Record.

Vendors can easily define their own data model by registering a
Enterprise ID with IANA. Using their own Enterprise ID, they can use
any ID in the way they want them to use.

6.5. TinyIPFIX Data Record Format

The Data Records are sent in TinyIPFIX Data Sets. The format of the
Data Records is shown in Figure 15 and matches the Data Record format
from IPFIX.

+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+

Figure 15: Data Record Format

7. TinyIPFIX Mediation

There are two types of TinyIPFIX Intermediate Processes. The first
one can occur on the transition between a constrained network (e.g.,
6LoWPAN) and the non-constrained unconstrained network. This mediation changes the
network and transport protocol from 6LoWPAN preferring UDP to
IP/(SCTP|TCP|UDP) and is shown in Figure 16.

Figure 16: Translation from TinyIPFIX over 6LoWPAN/UDP
to TinyIPFIX over IP/(SCTP|TCP|UDP)

The mediator removes the TinyIPFIX Messages from the 6LoWPAN/UDP
packets and wraps them into the new network and transport protocols.
Templates MUST be managed the same way as in the constrained
environment after the translation to IP/(SCTP|UDP|TCP) (see
Section 8).

The second type of mediation transforms TinyIPFIX into IPFIX. This
process MUST be combined with the transport protocol mediation as
shown in Figure 17.

+-----------------------+
| TinyIPFIX Device |
| [Exporting Process] |
+-----------------------+
|
TinyIPFIX |
|
v
+-------------------------+
| TinyIPFIX mediator |
| [Collecting Process] |
| [Exporting Process] |
+-------------------------+
|
IPFIX |
IP/(UDP/SCTP|TCP) |
v
+--------------------------+
| Collector |
| [Collecting Process(es)] |
+--------------------------+

Figure 17: Transformation from TinyIPFIX to IPFIX

This mediation can also be performed by an IPFIX Collector before
parsing the IPFIX message as shown in Figure 18. There is no need
for a parser from TinyIPFIX to IPFIX if such a mediation process can
be employed in front of an existing IPFIX collector.

Figure 18: Transformation from TinyIPFIX to IPFIX
The TinyIPFIX Mediation Process has to translate the TinyIPFIX
Message Header, the TinyIPFIX Set Headers Headers, and the TinyIPFIX Template
Record Header into their counterparts in IPFIX. Afterwards, the new
IPFIX Message Length needs to be calculated and inserted into the
IPFIX Message header.

7.1. Expanding the Message header Header

The fields of the IPFIX Message Header that are shown in Figure 5 can
be determined from a TinyIPFIX Message Header as follows:

Version

This is always 0x000a.

Length

The IPFIX Message Length can only be calculated after the complete
TinyIPFIX Message has been translated. The new length can be
calculated by adding the length of the IPFIX Message Header, which
is 16 octets, and the length of all Sets that are contained in the
IPFIX Message.

Export Time

The "Export Time" MUST be generated by the Mediator, and contains
the time in seconds since 00:00 UTC Jan 1, 1970, at which the
IPFIX Message leaves the Mediator.

Sequence Number

If the TinyIPFIX Sequence Number has a length of 4 octets, the
original value MUST be used for the IPFIX Message. If the
TinyIPFIX Sequence Number has a size of one or two octets, the
TinyIPFIX Mediator MUST expand the TinyIPFIX Sequence Number into
a four octet field. If the TinyIPFIX Sequence Number was omitted,
the Mediator needs to calculate the Sequence Number as per
[RFC7011].

Observation Domain ID

Since the Observation Domain ID is used to scope templates in
IPFIX, it MUST be set to a unique value per TinyIPFIX Exporting
Process, using either a mapping algorithmically determined by the
Intermediate Process or directly configured by an administrator.

7.2. Translating the Set Headers

Both fields in the TinyIPFIX Set Header have a size of one 1 octet and
need to be expanded:

Set ID

The field needs to be expanded from one 1 octet to two 2 octets. If the
Set ID is below 128, no recalculation needs to be performed. This
is because all IDs below 128 are reserved for special messages and
match the IDs used in IPFIX. The TinyIPFIX Set IDs starting with
128 identify TinyIPFIX Data Sets. Therefore, every TinyIPFIX Set
ID above number 127 needs to be incremented by number 128 because
IPFIX Data Set IDs are numbered above 255.

Set Length

The field needs to be expanded from one octet to two octets. It
needs to be recalculated by adding a value of 2 octets to match
the additional size of the Set Header. For each TinyIPFIX
Template Record that is contained in the TinyIPFIX Set, 2 more
octets need to be added to the length.

7.3. Expanding the Template Record Header

Both fields in the TinyIPFIX Template Record Header have a length of
one octet and therefore need translation:

Template ID

The field needs to be expanded from one octet to two octets. The
Template ID needs to be increased by a value of 128.

Field Count

The field needs to be expanded from one octet to two 2 octets.

8. Template Management

As with IPFIX, TinyIPFIX templates management Template Management depends on the transport
protocol used. If TCP or SCTP is used, it can be ensured that
TinyIPFIX Templates are delivered reliably. If UDP is used,
reliability cannot be guaranteed, and guaranteed: template loss can occur. If a
Template is lost on its way to the Collector, all the any following TinyIPFIX
Data Records that refer to this TinyIPFIX Template cannot be decoded.
Template withdrawals Withdrawals are not supported in TinyIPFIX. This is
generally not a problem, because most sensor nodes only define a
single static template directly after booting.

8.1. TCP / SCTP TCP/SCTP

If TCP or SCTP is used for the transmission of TinyIPFIX, Template
Management MUST be performed as defined in [RFC7011] for IPFIX, with
the exception of template withdrawals, Template Withdrawals, which are not supported in
TinyIPFIX. Template withdrawals Withdrawals MUST NOT be sent by TinyIPFIX
Exporters.

8.2. UDP

All specifications for Template management Management from [RFC7011] apply
unless specified otherwise in this document.

TinyIPFIX Templates MUST be sent by a TinyIPFIX Exporter before any
TinyIPFIX Data Set that refers to the TinyIPFIX Template is
transmitted. TinyIPFIX Templates are not expected to change over
time in TinyIPFIX and, thus, they should be pre-shared. TinyIPFIX
Device
Devices have a default setup when deployed and deployed; after booting booting, they
announce their TinyIPFIX Template directly to the networkand network and MAY
repeat it if UDP is used. Hence, a TinyIPFIX Template that has been
sent once MAY NOT be withdrawn and MUST NOT expire. If a TinyIPFIX
Smart Meter wants to use another TinyIPFIX Template Template, it MUST use a
new TinyIPFIX Template ID for the TinyIPFIX Template.

While UDP is used, reliable transport of TinyIPFIX Templates cannot be
be, guaranteed and TinyIPFIX Templates can be lost. A TinyIPFIX
Exporter MUST expect TinyIPFIX Template loss. It Therefore, it MUST therefore re-send re-
send its TinyIPFIX Templates periodically. A TinyIPFIX Template MUST
be re-
send re-sent after a fixed number N of TinyIPFIX Messages that contain
TinyIPFIX Data Sets referring to the TinyIPFIX Template. The number
N MUST be configured by the application developer. Retransmission
and the specification of N can be avoided if TinyIPFIX Exporter and
TinyIPFIX Collector use pre-shared templates.

9. Security considerations Considerations

The same security considerations as for the IPFIX Protocol [RFC7011]
apply.

10. IANA Considerations

This document has no actions for IANA. does not require any IANA actions.

11. Acknowledgments

Many thanks to Lothar Braun, Georg Carle, and Benoit Claise, who
contributed significant work to earlier versions especially to the
document entitled "Compressed IPFIX for Smart Meters in Constrained
Networks" (draft-braun-core-compressed-ipfix), of this work.

Many thanks to Thomas Kothmayr, Michael Meister, and Livio Sgier, who
implemented TinyIPFIX for TinyOS 2.x, Contiki 2.7/3.0 (except the
mediator) for different sensor platforms (IRIS, TelosB, and
OpenMote).

12. References

12.1.

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>.

[RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P.
Aitken, "IP Flow Information Export (IPFIX) Implementation
Guidelines", RFC 5153, DOI 10.17487/RFC5153, April 2008,
<https://www.rfc-editor.org/info/rfc5153>.

[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
"Architecture for IP Flow Information Export", RFC 5470,
DOI 10.17487/RFC5470, March 2009,
<https://www.rfc-editor.org/info/rfc5470>.

[RFC5982] Kobayashi, A., Ed. and B. Claise, Ed., "IP Flow
Information Export (IPFIX) Mediation: Problem Statement",
RFC 5982, DOI 10.17487/RFC5982, August 2010,
<https://www.rfc-editor.org/info/rfc5982>.

[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi,
"IP Flow Information Export (IPFIX) Mediation: Framework",
RFC 6183, DOI 10.17487/RFC6183, April 2011,
<https://www.rfc-editor.org/info/rfc6183>.

[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.

[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC7012, September 2013,
<https://www.rfc-editor.org/info/rfc7012>.

12.2.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

11.2. Informative References

[Advantic]
Advantic Sistemas y Servicios,
"https://www.advanticsys.com/",
ADVANTIC SISTEMAS Y SERVICIOS S.L.,
<https://www.advanticsys.com/>, 2017.

[Crossbow]
Crossbow Technologies Inc., "http://www.xbow.com", 2010.

[GreatDuck]
Mainwaring, A., Polastre, J., Szewczyk, R., Culler, D.,
and J. Anderson, "Wireless Sensor Networks for Habitat Monitoring on Great Duck Island,
"http://www.greatduckisland.net", The
Monitoring", In Proceedings of the
Second 1st ACM Conference international
workshop on Embedded Networked Sensor Systems
(SenSys 04) , November 2004. Wireless sensor networks and applications ACM,
pp. 88-97, DOI 10.1145/570738.570751, 2002.

[Harvan08]
Harvan, M. and J. Schoenwaelder, "TinyOS Motes on the
Internet: IPv6 over 802.15.4 (6LoWPAN)",
DOI 10.1515/piko.2008.0042, December 2008.

[IRIS] Memsic, "Data Sheet IRIS", 2017,
<http://www.memsic.com/userfiles/files/Datasheets/WSN/
IRIS_Datasheet.pdf>.

[Kim07] Kim, S., Pakzad, S., Culler, D., Demmel, J., Fenves, G.,
Glaser, S., and M. Turon, "Health Monitoring monitoring of Civil
Infrastructure Using Wireless Sensor Networks", In the civil
infrastructures using wireless sensor networks",
Proceedings of the 6th International Conference international conference on
Information Processing processing in Sensor Networks sensor networks (IPSN
2007), Cambridge, MA, ACM Press, pp. 254-263 , 254-263,
DOI 10.1145/1236360.1236395, April 2007.

[kothmayr10]

[Kothmayr10]
Kothmayr, T., "Data Collection in Wireless Sensor Networks
for Autonomic Home Networking", Bachelor Thesis, Technical
University of Munich, Germany , Munich, Germany, January 2010.

[openMote]
openMote Technologies S.L., 2017, <http://openmote.com>.

[Schmitt09]
Schmitt, C. and G. Carle, "Applications for Wireless
Sensor Networks", In Handbook of Research on P2P and Grid
Systems for Service-Oriented Computing: Models,
Methodologies and Applications, Edited by Antonopoulos N.; N.,
Exarchakos G.; G., Li M.; Liotta M., and A. (Eds.), Liotta, Information Science Publishing. ,
Publishing, Chapter 46, pp. 1076-1091,
ISBN: 978-1615206865, 2010.

[schmitt2014]

[Schmitt2014]
Schmitt, C., Kothmayr, T., Ertl, B., Hu, W., Braun, L.,
and G. Carle, "TinyIPFIX: An Efficient Application
Protocol efficient application
protocol for Data Exchange data exchange in Cyber Physical Systems", cyber physical systems",
Computer Communications, ELSEVIER, DOI: 10.1016/
j.comcom.2014.05.012 , 2014.

[schmitt2017] Vol. 74, pp. 63-76,
DOI 10.1016/j.comcom.2014.05.012, 2016.

[Schmitt2017]
Schmitt, C., Anliker, C., and B. Stiller, "Efficient and
Secure Pull Requests for Emergency Cases Using a Mobile
Access Framework", Managing the Web of Things: Linking the
Real World to the Web, M.Sheng, Y. Edited by Sheng, M., Qin, L. Y., Yao,
L., and B.
Benatallah (Eds.), Benatallah, Morgen Kaufmann (imprint of
Elsevier), Chapter 8, pp. 229-247,
ISBN: 978-0-12-809764-9 , 978-0-12-809764-9, 2017.

[SMPC04] Szewczyk, R., Mainwaring, A., Polastre, J., and D. Culler,
"An analysis of a large scale habitat monitoring
application", The Proceedings of the Second ACM Conference 2nd international
conference on Embedded Networked Sensor Systems networked sensor systems (SenSys 04) ,
04), DOI 10.1145/1031495.1031521, November 2004.

[TelosB] Memsic, "Data Sheet TelosB", 2017,
<http://www.memsic.com/userfiles/files/DataSheets/WSN/
telosb_datasheet.pdf>.

[Tolle05] Tolle, G., Polastre, J., Szewczyk, R., Culler, D., Turner,
N., Tu, K.,
Buonadonna, P., Burgess, S., Gay, D., Hong, W., Dawnson, T., Buonadonna, P., Gay,
D., and D. Culler, W. Hong, "A macroscope in the redwoods", In the
Proceedings of the 3rd ACM Conference international conference on
Embedded
Networked Sensor Systems (Sensys networked sensor systems (SenSys 05), San Diego, ACM
Press ,
DOI 10.1145/1098918.1098925, November 2005.

Acknowledgments

Many thanks to Lothar Braun, Georg Carle, and Benoit Claise, who
contributed significant work to earlier draft versions of this work,
especially to the document titled "Compressed IPFIX for Smart Meters
in Constrained Networks".

Many thanks to Thomas Kothmayr, Michael Meister, and Livio Sgier, who
implemented TinyIPFIX (except the mediator) for TinyOS 2.x and
Contiki 2.7/3.0 for 3 different sensor platforms (IRIS, TelosB, and
OpenMote).

Authors' Addresses

Corinna Schmitt
University of Zurich
Department of Informatics
Communication Systems Group
Binzmuehlestrasse 14
Zurich 8050
Switzerland

Email: schmitt@ifi.uzh.ch

Burkhard Stiller
University of Zurich
Department of Informatics
Communication Systems Group
Binzmuehlestrasse 14
Zurich 8050
Switzerland

Email: stiller@ifi.uzh.ch

Brian Trammell
Swiss Federal Institute of Technology
Gloriastrasse 35
Zurich 8092
Switzerland

Email: ietf@trammell.ch