| Network Working Group | C. Schmitt |
| Internet-Draft | B. Stiller |
| Intended status: Standards Track | University of Zurich |
| Expires: December 4, 2016 | B. Trammell |
| ETH Zurich | |
| June 2, 2016 |
TinyIPFIX for smart meters in constrained networks
draft-schmitt-ipfix-tiny-00
This document specifies the TinyIPFIX protocol that serves for transmitting smart metering data in 6LoWPAN networks [RFC4944]. TinyIPFIX is derived from IPFIX [RFC7101] and adopted to the needs of constrained networks. This documents specifies how the TinyIPFIX Data and Template Records are transmitted in 6LoWPAN networks and how TinyIPFIX data can be converted into unTinyIPFIX data in a proxy device.
This Internet-Draft is submitted to IETF 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 December 4, 2016.
Copyright (c) 2016 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.
Smart meters that form a constrained wireless network need an application layer protocol that allows the efficient transmission of metering data from the devices to some kind of 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 and networking resources.
The devices are often battery powered and are expected to run for a long time without having the possibility to re-charge 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 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 autonomically from the meters to one or more collectors, is suitable for reporting metering data in such networks.
TinyIPFIX is derived from IPFIX [RFC7101] and therefore inherits most of its 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 [RFC7101] 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 [RFC5982]. Hence, smart metering networks that are based on TinyIPFIX can be easily integrated into an existing IPFIX measurement infrastructure.
Section 2 introduces the terminology used in this draft. 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.
The term smart meter is used to refer to constrained devices like wireless senor nodes, motes or any other kind of small constraint device that can be part of a network that is based on IEEE802.15.4 and 6LoWPAN [RFC4944].
Most of the terms used in this draft are defined in [RFC7101]. All these terms are written with their first letter being capitalized. Most of the terms that are defined for IPFIX can be used to describe TinyIPFIX. The term "TinyIPFIX" is used in front of the IPFIX term to distinguish between the IPFIX version and the TinyIPFIX version. This draft uses the term IPFIX to refer to IPFIX as per RFC 7101 and the term TinyIPFIX for the IPFIX version defined in this draft.
The terms IPFIX Message, IPFIX Device, Set, Data Set, Template Set, Data Record, Template Record, Collecting Process, Collector, Exporting Process and Exporter are defined as in [RFC7101]. The term IPFIX Mediator is defined in [RFC5982]. The terms Intermediate Process, IPFIX Proxy, IPFIX Concentrator are defined in [RFC6183].
All these 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 the defined terms.
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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The target devices for TinyIPFIX are usually equipped with low-cost hardware and therefore face several constraints concerning CPU and memory [Schmitt09]. For example, the IRIS mote from Crossbow Technologies Inc. has a size of 58 x 32 x 7 mm (without a battery pack) [Crossbow]. Thus, there is little space for micro controller, flash memory (128 kb) and radio frequency transceiver, which are located on the board.
Network protocols used on such hardware need to respect these constraints. They must be simple to implement using little code and little run time memory and should produce little overhead when encoding the application payload.
Smart meters that are battery powered have hard energy constraints [Schmitt09]. By power supply of two 2 AA 2,800-mAh batteries this means approximately 30,240J. If they run out of power, their battery has to be changed, which means physical manipulation to the device is necessary. Using as little energy as possible for network communication is therefore desired.
A smart metering device can save a lot of energy, if it powers down its radio frequency transceiver. Such devices do not have permanent network connectivity but 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 transceivers as long as it does not have any data to sent. If the metering device is able to keep a few measurements in memory, and if 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 transceivers.
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. IEEE 802.15.4 defines a maximum frame size of 127 octets, which usually leaves 102 octets for user data. IPv6 on the other hand 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 scheme, which allows to reduce the overhead from header sizes significantly. Additionally, the overall TinyIPFIX Message size is reduced, which reduces the need for fragmentation.
The IPFIX standard [RFC7101] defines several transport protocol bindings for the transmission of IPFIX Messages. SCTP support is REQUIRED for any IPFIX Device to achieve standard conformance [RFC7101], 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 to compress 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 UDP on the transport layer for transmitting IPFIX 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 layer support for transmitting data in a constrained network environment. It MAY also offer TCP or SCTP support. However, using these protocols is NOT RECOMMENDED as their use will consume more power and reduces the available size of application payload compared to the use of UDP. If TinyIPFIX is transmitted over a non-constrained network, using SCTP as a transport layer protocol is RECOMMENDED.
TinyIPFIX is derived from IPFIX [RFC7101] and is therefore a unidirectional push protocol. 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.
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, that TinyIPFIX can only be used over UDP if these TinyIPFIX Message losses are not a problem.
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 measurements can benefit from the use of TinyIPFIX. One application for IPFIX can be 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 and photosynthetically active solar radiation over a long time period.
Deploying TinyIPFIX in such scenarios seems to be a good fit. The sensors of the TinyIPFIX Smart Meter can be queried over several 5 minute time intervals and the query results can be aggregated into a single TinyIPFIX Message. As soon as enough query results are stored in the TinyIPFIX Message, 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. in the "Great Duck Island Project" [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, aggregate the sensor data and export them to a TinyIPFIX Collector.
Other application scenarios for TinyIPFIX could be applications where sensor networks are used for long term structural health monitoring in order to investigate long term weather conditions on the structure of a building. For example, a 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 measurement of the structural integrity, TinyIPFIX can be used to collect the 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:
+----------------+ +----------------+
|[*Application 1]| ... |[*Application n]|
+--------+-------+ +-------+--------+
^ ^
| |
+----------+----------+
^
|
+------------------------+ +--------+-------------------+
| TinyIPFIX S.M. | TinyIPFIX | TinyIPFIX Collector |
| [Exporting Process] |----------->| [Collecting Process(es)] |
+------------------------+ +----------------------------+
Figure 1: Direct transmission between sensors and applications
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.
+-------------------------+ +------------------------+
| TinyIPFIX S.M. | TinyIPFIX | TinyIPFIX Concentrator |
| [Exporting Process] |----------------->| [Collecting Process] |
+-------------------------+ +-------->| [Exporting Process] |
| +------------------------+
+-------------------------+ | |
| TinyIPFIX S.M. | | TinyIPFIX|
| [Exporting Process] |--------+ |
+-------------------------+ v
+-------+------------------+
| Collector(1) |
| [Collecting Process(es)] |
+--------------------------+
Figure 2: Aggregation on TinyIPFIX
A second way to deploy TinyIPFIX Smart Meter can employ aggregation on TinyIPFIX Messages during their journey through the constrained network as shown in Figure 2. This aggregation can be performed by special TinyIPFIX Smart Meter that act as TinyIPFIX Concentrators. Such devices must have enough resources to perform the aggregation.
+------------------------+ +------------------------+
| TinyIPFIX S.M | TinyIPFIX | TinyIPFIX Proxy |
| [Exporting Process] |----------------->| [Collecting Process] |
+------------------------+ | [Exporting Process] |
+------------------------+
|
IPFIX |
v
+--------------------------+
| IPFIX Collector(1) |
| [Collecting Process(es)] |
+--------------------------+
Figure 3: Aggregation on TinyIPFIX
The last deployment, shown in Figure 3, employs another TinyIPFIX Mediation process.
The TinyIPFIX Smart Meters transmit their TinyIPFIX Messages to one node, 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.
+----------------------------------------------------+
| TinyIPFIX Message Header |
+----------------------------------------------------+
| TinyIPFIX Set |
+----------------------------------------------------+
| TinyIPFIX Set |
+----------------------------------------------------+
...
+----------------------------------------------------+
| TinyIPFIX Set |
+----------------------------------------------------+
Figure 4: 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 any of the possible two types: TinyIPFIX Template Set and TinyIPFIX Data Set. An TinyIPFIX Message MUST only contain one type of TinyIPFIX Set. The format of the TinyIPFIX Message is shown in Figure 4
The TinyIPFIX Message Header is derived from the IPFIX Message Header, with some optimization using field compression. The IPFIX Message Header from [RFC7101] 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
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|E1|E2| SetID | Length |
| | | Lookup | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Sequence | Ext. Sequence |
| Number | Number |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Ext. SetID |
+--+--+--+--+--+--+--+--+
Figure 6: Format of the TinyIPFIX Message header
The length of the IPFIX Message Header is 16 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. TinyIPFIX introduces a TinyIPFIX Message Header that has a smaller size. The TinyIPFIX header consists of a fixed part of three octets and a variable length "Remaining Header" as shown in Figure 6.
The first part has a fixed length of thre octets and consists of the "E1" field (1 bit), the "E2" field (1 bit), the "SetID Lookup" field (4 bit), the "Length" field (10 bit), and the "Sequence Number" field (8 bit). The second part (the "Remaining Header") has a variable length. Its length is defined by the "E1" and "E2" field in the fixed header part. The four variants are illustrated in the figures below.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|0 |0 | SetID | Length |
| | | Lookup | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Sequence |
| Number |
+--+--+--+--+--+--+--+--+
Figure 7: TinyIPFIX Message Header format if E1 = E2 = 0
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|1 |0 | SetID | Length |
| | | Lookup | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Sequence | Ext. SetID |
| Number | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 8: TinyIPFIX Message Header format if E1 = 1 and E2 = 0
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|0 | 1| SetID | Length |
| | | Lookup | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Sequence | Ext. Sequence |
| Number | Number |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 9: TinyIPFIX Message Header format if E1 = 0 and E2 = 1
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|1 |1 | SetID | Length |
| | | Lookup | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Sequence | Ext. Sequence |
| Number | Number |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Ext. SetID |
+--+--+--+--+--+--+--+--+
Figure 10: TinyIPFIX Message Header format if E1 = E2 = 1
The fixed header fields are defined as follows [kothmayr10] [schmitt2014]:
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 and the field can be dropped from the header. Should applications require several Observation Domains the information can be included in the TinyIPFIX data message. The version field has been dropped since the SetID lookup field provides room for future extensions. The specification of a 32 bit time stamp in seconds would require the time synchronization across a wireless sensor network and produces too much overhead. Thus, the "Export Time" field is dropped. If applications should require the specification of time it can be sent as part of the TinyIPFIX data message.
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 a TinyIPFIX Template Set or a TinyIPFIX Data Set. Every TinyIPFIX Set is started with an TinyIPFIX Set Header and is followed by one or more TinyIPFIX Records.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Comp. Set ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TinyIPFIX Set Header
The IPFIX Set Header consists of an two octet "Set ID" field and a two octet "Length" field. These two fields are compressed to one octet each for the TinyIPFIX Set Header. The format of the TinyIPFIX Set Header is shown in Figure 11.
The two fields are defined as follows:
+--------------------------------------------------+
| TinyIPFIX Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
Figure 12: TinyIPFIX Template Format
The format of the TinyIPFIX Template Records is shown in Figure 12. The TinyIPFIX Template Record starts with an TinyIPFIX Template Record Header and 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 [RFC7101].
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Comp. Temp ID | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: TinyIPFIX Template Header
The format of the TinyIPFIX Template Record Header is shown in Figure 13.
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 Template Header
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 [RFC7101]. The following text has been copied from [RFC7101] for completeness.
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.
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
Figure 15: 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.
+-----------------------+ TinyIPFIX +-------------------------+
| TinyIPFIX S.M. | 6LoWPAN/UDP | TinyIPFIX mediator |
| [Exporting Process] |--------------->| [Collecting Process] |
+-----------------------+ | [Exporting Process] |
+-------------------------+
|
TinyIPFIX |
IP/(UDP/SCTP|TCP) |
v
+--------------------------+
| Collector(1) |
| [Collecting Process(es)] |
+--------------------------+
Figure 16: Translation from TinyIPFIX over 6LowPAN/UDP to TinyIPFIX over IP/(SCTP|TCP|UDP)
There are two types of TinyIPFIX Intermediate Processes. The first one can occur on the transition between a constraint 6LoWPAN and the non-constrained network. This mediation changes the network and transport protocol from 6LowPAN/UDP to IP/(SCTP|TCP|UDP) and is shown in Figure 16.
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 constraint environment after the translation to IP/(SCTP|UDP|TCP) (see Section 8).
+------------------------+ TinyIPFIX +-----------------------+
| TinyIPFIX S.M. | 6LoWPAN/UDP | IPFIX mediator |
|[Exporting Processes] |---------------->| [Collecting Process] |
+------------------------+ | [Exporting Process] |
+-----------------------+
|
IPFIX |
IP/(UDP/SCTP|TCP) |
v
+--------------------------+
| Collector(1) |
| [Collecting Process(es)] |
+--------------------------+
Figure 17: Transformation from TinyIPFIX to IPFIX
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 +----------------------+
| TinyIPFIX S.M. | 6LoWPAN/UDP | IPFIX Mediator |
| [Exporting Processes] |----------------->| [Collecting Process] |
+------------------------+ | [Exporting Process] |
| | |
| |IPFIX |
| | |
| v |
| Collector(1) |
| [Collecting Process] |
+----------------------+
Figure 18: 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 TinyIPFIX IPFIX parser if such a mediation process can be employed in front of an already existing IPFIX collector.
The TinyIPFIX Mediation Process has to translate the TinyIPFIX Message Header, the TinyIPFIX Set 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.
The fields of the IPFIX Message Header that are shown in Figure 5 can be determined as follows:
Both fields in the TinyIPFIX Set Header have a size of one octet and need to be expanded:
Both fields in the TinyIPFIX Template Record Header have a length of one octet and therefore need translation:
As with IPFIX, TinyIPFIX templates 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 template loss can occur. If a Template is lost on its way to the Collector, all following TinyIPFIX Data Records that refer to this TinyIPFIX Template cannot be decoded. Template withdrawals are not supported in TinyIPFIX. This is generally not a problem, because most sensor nodes only define a single template directly after booting.
If TCP or SCTP is an option and can be used for the transmission of TinyIPFIX, Template Management MUST be performed as defined in [RFC7101] for IPFIX, with the exception of template withdrawals, which are not supported in TinyIPFIX. Template withdrawals MUST NOT be sent by TinyIPFIX exporters.
All specifications for Template management from [RFC7101] apply unless specified otherwise in this document.
TinyIPFIX Templates MUST be sent by an 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. Hence, a TinyIPFIX Template that has been sent once MAY NOT be withdrawn and MUST NOT expire. If an TinyIPFIX Smart Meter wants to use another TinyIPFIX Template it MUST use a new TinyIPFIX Template ID for the TinyIPFIX Template.
As UDP is used, reliable transport of TinyIPFIX Templates cannot be guaranteed and TinyIPFIX Templates can be lost. A TinyIPFIX Exporter MUST expect TinyIPFIX Template loss. It MUST therefore re-send its TinyIPFIX Templates periodically. A TinyIPFIX Template MUST be re-send after a fixed number of N TinyIPFIX Messages that contained TinyIPFIX Data Sets that referred to this TinyIPFIX Template. The number N MUST be configured by the application developer.
The same security considerations as for the IPFIX Protocol [RFC7101] apply.
This document has no actions for IANA.
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 and Michael Meister, who implemented TinyIPFIX for TinyOS 2.x and Contiki 2.7 except the mediator.
| [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, Antonopoulos N.; Exarchakos G.; Li M.; Liotta A. (Eds.), Information Science Publishing. , 2010. |
| [Tolle05] | Tolle, G., Polastre, J., Szewczyk, R., Turner, N., Tu, K., Buonadonna, P., Burgess, S., Gay, D., Hong, W., Dawnson, T. and D. Culler, "A macroscope in the redwoods", In the Proceedings of the 3rd ACM Conference on Embedded Networked Sensor Systems (Sensys 05), San Diego, ACM Press , November 2005. |
| [Kim07] | Kim, S., Pakzad, S., Culler, D., Demmel, J., Fenves, G., Glaser, S. and M. Turon, "Health Monitoring of Civil Infrastructure Using Wireless Sensor Networks", In the Proceedings of the 6th International Conference on Information Processing in Sensor Networks (IPSN 2007), Cambridge, MA, ACM Press, pp. 254-263 , April 2007. |
| [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 on Embedded Networked Sensor Systems (SenSys 04) , November 2004. |
| [GreatDuck] | Habitat Monitoring on Great Duck Island, , "http://www.greatduckisland.net", The Proceedings of the Second ACM Conference on Embedded Networked Sensor Systems (SenSys 04) , November 2004. |
| [Harvan08] | Harvan, M. and J. Schoenwaelder, "TinyOS Motes on the Internet: IPv6 over 802.15.4 (6lowpan)", 2008. |
| [Crossbow] | Crossbow Technologies Inc., , "http://www.xbow.com", 2010. |
| [kothmayr10] | Kothmayr, T., "Data Collection in Wireless Sensor Networks for Autonomic Home Networking", Bachelor Thesis, Technical University of Munich, Germany , 2010. |
| [schmitt2014] | Schmitt, C., Kothmayr, T., Ertl, B., Hu, W., Braun, L. and G. Carle, "TinyIPFIX: An Efficient Application Protocol for Data Exchange in Cyber Physical Systems", Computer Communications, ELSEVIER, DOI: 10.1016/j.comcom.2014.05.012 , 2014. |