RFC 8272
TinyIPFIX for Smart Meters in Constrained Networks
TinyIPFIX for Smart Meters in Constrained Networks ✨
RFC 8272 💖 Here's the vibe: it's an Informational doc from the Independent Submission stream (ISSN 2070-1721), published November 2017. The authors are C. Schmitt, B. Stiller (both University of Zurich) and B. Trammell (ETH Zurich). The title block doesn't list anything it obsoletes or updates, so it doesn't replace or change any other RFC.
Abstract
okay so this doc specifies TinyIPFIX, a protocol for sending smart-metering data over constrained networks, like IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN, RFC 4944) 🦋. TinyIPFIX is derived from IP Flow Information Export (RFC 7011) and reshaped for constrained networks ✨. It explains how TinyIPFIX Data and Template Records get sent over networks like 6LoWPAN, and how a proxy device can turn TinyIPFIX data into data that isn't TinyIPFIX 🔥.
Status of This Memo
this doc is not an Internet Standards Track spec. It's published for information only 🌸
it's a contribution to the RFC Series, totally independent of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about whether it's useful for implementing or deploying anything 💅. Docs the RFC Editor approves for publication aren't candidates for any level of Internet Standard. Check Section 2 of RFC 7841 for the details 🙈.
if you want the current status, any errata, or a way to give feedback, go to https://www.rfc-editor.org/info/rfc8272 🧚
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 💜
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully, because they spell out your rights and restrictions for this document 📜
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Hardware Constraints . . . . . . . . . . . . . . . . . . 6
3.2. Energy Constraints . . . . . . . . . . . . . . . . . . . 7
3.3. Packet Size Constraints . . . . . . . . . . . . . . . . . 7
3.4. Transport Protocol Constraints . . . . . . . . . . . . . 8
4. Application Scenarios for TinyIPFIX . . . . . . . . . . . . . 9
5. Architecture for TinyIPFIX . . . . . . . . . . . . . . . . . 11
6. TinyIPFIX Message Format . . . . . . . . . . . . . . . . . . 14
6.1. TinyIPFIX Message Header . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 24
7.2. Translating the Set Headers . . . . . . . . . . . . . . . 25
7.3. Expanding the Template Record Header . . . . . . . . . . 25
8. Template Management . . . . . . . . . . . . . . . . . . . . . 25
8.1. TCP/SCTP . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 301. Introduction ✨
okay so smart meters that form a constrained wireless network need an application-layer protocol that sends metering data from the devices to a central analysis device efficiently 🧚. The meters are usually built with low-cost, low-power hardware, and that brings real limits on computing capacity, memory, and networking resources 😭.
the devices are often battery powered and are supposed to run for ages without being able to recharge 🔋. To save energy, smart meters often power off their wireless networking device. So they don't have a steady connection. They only join the wireless network when there's data to export 🦋. A push protocol like TinyIPFIX, where data gets transmitted automatically from the meters to one or more collectors, is a great fit for reporting metering data in networks like this 💜.
TinyIPFIX is derived from IPFIX [RFC7011], so it inherits most of IPFIX's properties 👑. One of the big ones is the separation of data from its description. The data goes in Data Sets and the description goes in Template Sets 💅.
converting TinyIPFIX to IPFIX as per [RFC7011] is super simple, and it can happen at the border between the constrained network and the more general network 🔥. Turning one form of IPFIX data into another is called "IPFIX Mediation" [RFC5982]. So smart-metering networks built on TinyIPFIX can easily plug into an existing IPFIX measurement infrastructure 🌈.
1.1. Document Structure
Section 2 introduces the terminology used in this document 🎀. Next, Section 3 covers the hardware and software constraints in constrained networks, which is what motivates the changes to the IPFIX protocol 🙈. Section 4 describes the application scenarios, and Section 5 describes the architecture for TinyIPFIX ✨. Section 6 defines the TinyIPFIX protocol itself and talks about how TinyIPFIX differs from IPFIX 💖. Section 7 describes the Mediation Process from TinyIPFIX to IPFIX. Section 8 defines how Template Management works on the Exporter and the Collector 🧚. Section 9 and Section 10 cover the security and IANA considerations for TinyIPFIX 🔐.
2. Terminology
most of the terms in this doc are defined in [RFC7011], and each one starts with a capital letter 💅. Most of the IPFIX terms can be used to describe TinyIPFIX too. This document uses "IPFIX" to mean IPFIX as defined in [RFC7011]. It uses TinyIPFIX for the protocol specified here, which is meant for constrained networks 🦋. The "Tiny" prefix is added to IPFIX so you can tell the two versions apart 🌸.
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 [RFC7011] 📜. The term IPFIX Mediator is defined in [RFC5982]. The terms Intermediate Process, IPFIX Proxy, and IPFIX Concentrator are defined in [RFC6183] 💜.
all the terms above were adapted from the IPFIX definitions. They keep a similar meaning but live in a different world, the world of constrained networks. That's why "TinyIPFIX" now goes in front of each defined term ✨.
the term "smart meter" refers to constrained devices like wireless sensor nodes, motes, or any other small constrained device that can be part of a network based on 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 has the functionality of a TinyIPFIX Device. It usually has one or more sensors that measure 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 so it can 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 tell IPFIX and TinyIPFIX apart throughout this document 🦋.
TinyIPFIX Template Record
A TinyIPFIX Template Record is similar to an IPFIX Template Record in [RFC7011]. Its Template Record Header is swapped out for a TinyIPFIX Template Record Header, and otherwise it's the same as a Template Record. See Section 6.3 🌸.
TinyIPFIX Set
A 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
A 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
A TinyIPFIX Message is a message that comes from a TinyIPFIX Exporter. It's made up 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 a 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 💜. (yes, this term shows up twice in the original, and yes, it's giving déjà vu 🙈)
a TinyIPFIX Transport Session is defined by the communication between a TinyIPFIX Exporter (identified by a 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💖.
Okay, the foundations are set bestie, the next part gets into the constraints 🌸💅
3.1. Hardware Constraints 🔧
okay so TinyIPFIX target devices are usually running on low-cost hardware 💸, which means they have real CPU and memory constraints [Schmitt09]. Like, the IRIS mote from Crossbow Technologies, Inc. measures 58 x 32 x 7 mm (without a battery pack) [IRIS] 🥺. That is tiny!! So there's barely any room for a micro-controller, memory (128 kb program flash, 512 kb measurement serial flash, 8 kb RAM, 4 kb configuration EEPROM), and a radio-frequency transceiver, all squished onto the board 🫠.
The TelosB motes made by Crossbow Technologies, Inc. [TelosB] and ADVANTIC SISTEMAS Y SERVICIOS S.L. [Advantic] are a similar size, but they give you more memory (48 kb flash, 1024 kb serial, flash, 10 kb RAM, 16 kb configuration EEPROM) ✨. Same vibe for OpenMote, just with 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 memory, and should produce little overhead when encoding the application payload 🧠.
3.2. Energy Constraints ⚡
Smart meters that are battery powered have hard energy constraints [Schmitt09] 😤. If two AA 2800-mAh batteries power the mote, they contain approximately 30,240 Joule of energy. If they run out of power, the battery has to be changed, which means physically messing with the device 🙃. Therefore, using as little energy as possible for network communication is desired 💜.
A smart-metering device can save a LOT of energy if it powers down its radio-frequency transceiver 🔋. These devices don't have permanent network connectivity; they're 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 📤. Since the communication is unidirectional, a meter can completely power down its radio-frequency transceivers as long as it doesn't have any data to send 💤. If the metering device is able to keep a few measurements in memory, and real-time metering isn't a requirement, the TinyIPFIX Data Records can be pushed less frequently, therefore saving some more energy on the radio-frequency transceivers 🦋.
3.3. Packet Size Constraints 📦
TinyIPFIX is mainly targeted for 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 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 📏. On the other 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 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 🚚
The IPFIX standard [RFC7011] defines several transport protocol bindings for the transmission of IPFIX Messages. 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 🎀.
Therefore, using UDP on the transport layer for transmitting TinyIPFIX Messages is 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. In the case in which TCP or SCTP MAY be 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 unconstrained network, using SCTP as a 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 necessary, making TinyIPFIX highly flexible and usable for different communication protocols (e.g., 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 and are under the control of a single administrative domain 🔐.
4. Application Scenarios for TinyIPFIX ✨
okay so TinyIPFIX is basically a little sibling of IPFIX [RFC7011] 🎀 and that means it's a unidirectional push protocol that assumes UDP usage 🦋. Translation: all the talking goes one way, from an Exporting Process to a Collecting Process 💅. So TinyIPFIX only really fits in situations where meters send their data to one or more Collectors 📦. Bestie, that's the whole vibe.
Now, what if you also want pull requests to work? 🤔 The spec says it is RECOMMENDED not to change the TinyIPFIX code much, because the device has very limited memory [Schmitt2017] 🧠. The idea is that you just add a one-bit field called type 🎀, where 0 means a push message and 1 means a pull-triggered message. The filtering SHOULD be done by the gateway and NOT by the constrained device 🫶. So when a pull comes in, the device just gets triggered to make a TinyIPFIX message right away like normal, sets the type field to one instead of zero, and sends it to the gateway. Then the gateway does the filtering based on the pull request ✨. Smart, right? 😭
Okay, but UDP can lose packets 💀. If an initial Template Message gets lost, the Collector doesn't know the Template, so every TinyIPFIX Data Set that references that Template can't be decoded 🙈. Those Messages are gone unless the Collector caches them 😬. An application developer should totally get this: TinyIPFIX can only be used over UDP if losing these Messages is not a problem 🌸.
To help with this, it is RECOMMENDED to repeat the Template Message periodically 🔁. Just keep in mind that a Template never changes for a constrained device after deployment 💜. Even if a Template Message gets lost, the data can still be manually translated later once the Template Message is re-sent 🧚. Adding an acknowledgement mechanism is NOT RECOMMENDED 🙅♀️, because the device would have to store everything it sent until it got acknowledged, and that's way too much overhead for a tiny device 😵. And in critical applications, it is RECOMMENDED to repeat the Template Message even more often ⭐.
TinyIPFIX over UDP is especially NOT a suitable protocol for applications where sensor data triggers policy decisions or configuration updates and packet loss is not tolerable 🚨. Don't do it, bestie 🙅♀️💀.
Now the fun part 🌈! Applications that use smart sensors for accounting purposes over long-term measurements can seriously benefit from TinyIPFIX 💖. One big example is 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 nodes measured air temperature, relative humidity, and photosynthetically active solar radiation over a long period of time ☀️🍃. Iconic 😭.
TinyIPFIX is a good fit for scenarios like this 🎀. Data can be measured by the sensors of the TinyIPFIX Smart Meter over several 5-minute time intervals, and those measurements can be accumulated into a single TinyIPFIX Message 📦. Once there are enough measurements stored in the TinyIPFIX Message, e.g., when the 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 animal habitats 🐦, like the "Great Duck Island Project" [GreatDuck] [SMPC04] 🦆. The goal there was to monitor 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 measure periodically, accumulate the sensor data, and export it to a TinyIPFIX Collector 🫶.
Other application scenarios could include sensor networks used for long-term structural health monitoring 🌉, to investigate long-term weather conditions on the structure of a building 🏢. For example, a smart-metering network was built to monitor the structural health of the Golden Gate Bridge [Kim07] 🌁👑. If a sensor network is deployed to do a long-term measurement of structural integrity, TinyIPFIX can be used to collect the sensor-measurement data 💜.
Okay, so if an application developer is deciding whether to use TinyIPFIX for transmitting data from smart meters, they MUST take the following considerations into account 🧐. Wait, let me restate that properly for the group chat: they need to think through these four things first 📝💅.
- The application SHOULD require a push protocol by default 💖. The timing intervals for when to push data SHOULD be predefined before deployment ⏰. This property lets a TinyIPFIX Smart Meter turn off its wireless device to save energy, since it never has to receive any data 🔋✨.
- If real-time reporting is not required, the application might benefit from combining several measurements into a single TinyIPFIX Message 🧩. Yes, there's a delay, but it lowers traffic in the network 🚦. TinyIPFIX easily allows several measurements to be combined into a single TinyIPFIX Message (or a single packet) 📦💫. This can happen on the TinyIPFIX Smart Meter that combines its own measurements 🙌. Or it can happen within a multi-hop wireless network, where one IPFIX Proxy combines several TinyIPFIX Messages into a single TinyIPFIX Message before forwarding them 🦋.
- The application MUST accept potential packet loss 🥺. TinyIPFIX only fits applications where metering data is stored for accounting purposes, NOT applications where sensor data triggers configuration changes or policy decisions, unless Message loss is acceptable for some reason 🙅♀️.
- The application MUST NOT require per-message export timestamps (e.g., for auditing) ⏱️. TinyIPFIX removes export timestamps from IPFIX 🗑️, since they are generally only useful for Template Management operations, which TinyIPFIX also does not support 🚫. That's a minor inconvenience, because per-record timestamp Information Elements are still available in IPFIX 💅🌸.
5. Architecture for TinyIPFIX ✨
okay so the TinyIPFIX architecture is basically the IPFIX architecture's cool little cousin 🦋, and you can read all about the original in [RFC5470]. The most common setup is shown in Figure 1 🌸. Every TinyIPFIX Smart Meter can have different sensors hooked up. For example, an IRIS can have Temperature, Humidity, and Sound, while a TelosB can have Temperature, Bridgeness, Humidity, and GPS. Those sensors are what build 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 between TinyIPFIX
Devices and ApplicationsSo here's the vibe 🎀. A TinyIPFIX Smart Meter (S.M.) grabs measurement data from its internal sensors to make its TinyIPFIX Messages. Then it encodes those results into a TinyIPFIX Message using a TinyIPFIX Exporting Process and exports that 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 unconstrained devices at the constrained network border, which is giving very "on the edge" energy 🌈
Now, the second way to deploy a TinyIPFIX Smart Meter is to do accumulation on TinyIPFIX Messages while they travel through the constrained network, as shown in Figure 2 ✨ This accumulation can be performed by TinyIPFIX Concentrators. These devices must have enough resources to do the accumulation, so no skimping on them, bestie 💜
+------------------------+ +------------------------+
| TinyIPFIX Device | ... | TinyIPFIX Device |
| [Exporting Process] | | [Exporting Process] |
+------------------------+ +------------------------+
| |
TinyIPFIX | | TinyIPFIX
| |
v v
+----------------------------------+
|
v
+------------------------+
| TinyIPFIX Concentrator |
| [Collecting Process] |
| [Exporting Process] |
+------------------------+
|
TinyIPFIX |
|
v
+--------------------------+
| Collector |
| [Collecting Process(es)] |
+--------------------------+
Figure 2: Accumulation of TinyIPFIXTinyIPFIX Smart Meters send their data to a TinyIPFIX Concentrator, which needs enough storage space to hold all that incoming data 📦 If the Concentrator lives inside a TinyIPFIX Smart Meter, it MAY also be able to collect data from its sensors, if they're activated 🍓 It can also accumulate the incoming data along with its own measurement data. The accumulated data can then be re-exported to one or more Collectors. In that case, the TinyIPFIX Concentrator is viewed as receiving data from multiple Smart Meters, one locally and some remotely. Main character energy for sure 👑
The last deployment, shown in Figure 3, brings in another TinyIPFIX Mediation process 🫶
+-------------------------+ +-------------------------+
| Remote Smart Meter | | Local Smart Meter |
+-------------------------+ +-------------------------+
| TinyIPFIX Device | | TinyIPFIX Device |
| [Exporting Process] | | [Exporting Process] |
+-------------------------+ +-------------------------+
| |
TinyIPFIX | | TinyIPFIX
| |
v v
+-------------------------+
| TinyIPFIX Concentrator |
| [Collecting Process] |
+-------------------------+
Figure 3: TinyIPFIX MediatorIn this setup, the TinyIPFIX Smart Meters send their TinyIPFIX Messages to one node, for example the base station 🛰️ That node translates the TinyIPFIX Messages into IPFIX Messages. Those IPFIX Messages can then be exported into an existing IPFIX infrastructure, which is so convenient ngl 🥹 The Mediation process from TinyIPFIX to IPFIX is described in Section 7.
6. TinyIPFIX Message Format 💖
okay, message format time, and this part is lowkey the backbone of everything 🦴 A TinyIPFIX IPFIX Message starts with a TinyIPFIX Message Header, followed by one or more TinyIPFIX Sets. Those Sets can be either a TinyIPFIX Template Set or a TinyIPFIX Data Set. A TinyIPFIX Message MUST only contain one type of TinyIPFIX Set. No mixing and matching, periodt 💅 The format of the TinyIPFIX Message is shown in Figure 4 ✨
+----------------------------------------------------+
| TinyIPFIX Message Header |
+----------------------------------------------------+
| TinyIPFIX Set |
+----------------------------------------------------+
| TinyIPFIX Set |
+----------------------------------------------------+
...
+----------------------------------------------------+
| TinyIPFIX Set |
+----------------------------------------------------+
Figure 4: TinyIPFIX Message Format6.1. TinyIPFIX Message Header ✨
Okay so the TinyIPFIX Message Header is basically a glow-up of the IPFIX Message Header, with some optimization using field compression 💅. Here's the IPFIX Message Header from [RFC7011] 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 IPFIX Message Header is 16 octets long, and every IPFIX Message has to be started with it 🙈. TinyIPFIX needs its header to be much smaller because of the packet size constraints in Section 3.3. So the TinyIPFIX Header is a fixed part of three octets, as shown in Figure 6, followed by a variable part, as shown in Figures 7 to 10. Iconic layering 🧚
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. Sequence |
|1|2|Lookup | | Number | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext. SetID |
+-+-+-+-+-+-+-+-+Figure 6: Format of the TinyIPFIX Message Header including Fixed and Optional Parts
The fixed part is 3 octets long and has 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 changes length based on the E1 and E2 fields in the fixed header. There are four variants, and they're shown in Figures 7 to 10 below. Main character energy, honestly 👑
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 if E1 = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| SetID | Length | Sequence | Ext. SetID |
| | |Lookup | | Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: TinyIPFIX Message Header 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 if E1 = 0 and E2 = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| SetID | Length | Sequence | Ext. Sequenz |
| | |Lookup | | Number | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext. SetID |
+-+-+-+-+-+-+-+-+Figure 10: TinyIPFIX Message Header Format if E1 = E2 = 1
The fixed header fields are defined as follows [Kothmayr10] [Schmitt2014]:
E1 and E2
The E1 and E2 bits control whether the Ext. SetID field and the Ext. Sequence Number field are there, respectively. 🦋
If E1 = E2 = 0, the TinyIPFIX Message Header uses the format in Figure 7. In that case, the Extended Sequence Number and Extended SetID fields MUST NOT be present. Not even a little bit 🙅♀️
When E1 = 1, the extended SetID field MUST be present. Custom SetIDs go in the extended SetID field, with all the SetID Lookup bits set to 1 (see Figure 8). When it's evaluated, the value in the extended SetID field gets shifted left by 8 bits, so it doesn't collide with the reserved SetIDs 0-255. Want to reference those reserved ones instead? You can turn shifting off by setting all the SetID lookup bits to 1 🌈
Sampling rates can be higher than in typical constrained networks (like Wireless Sensor Networks (WSNs) or Cyber-Physical-Systems (CPS)), so these setups might have a lot of records per packet 📈. To make TinyIPFIX work for those cases, E2 = 1 is set (see Figure 9). This means the Extended Sequence Number field MUST be present, which gives you 8 more bits of sequence numbers than usual. Depending on the constrained network settings, E1 = E2 = 1 is also possible. That gives you the maximum TinyIPFIX Message header in Figure 10, where the Extended Sequence Number field and the Extended SetID field MUST both be present. Maximum slay 💖
SetID Lookup
This field works as a lookup for SetIDs and gives shortcuts for SetIDs that get used a lot ✨. Four values are defined:
- Value =
0; look up the extended SetID field, shifting enabled. - Value =
1; SetID =2and the message contains a Template definition. - Value =
2; SetID =256and the message contains a Data Record for Template 256. This puts special importance on one template ID. Most sensor nodes only define a single template right after booting and keep streaming data with that template ID for the whole session, so this shorthand is really useful for them 🍓 - Value =
3-14; SetIDs are reserved for future extensions. - Value =
15; look up the extended SetID field, shifting enabled.
Length
The Length field is a fixed 10 bits long.
Sequence Number
Because typical WSNs have low sampling rates, the Sequence Number field is only one byte long 🫧. But some applications might have a lot of records per packet. In that case, the sequence field can be extended to 16 bits by setting the E2-bit to 1.
Since TinyIPFIX packets always travel over a network protocol that specifies the packet's source, the "Observation Domain" can be treated as the source of a TinyIPFIX packet. So this IPFIX field got removed from the TinyIPFIX Header. If an application needs explicit Observation Domain info, each Data Record in the TinyIPFIX data message may contain an Observation Domain ID Information Element. See Section 3.1 of [RFC7011] for that one 🔍. The version field is gone too, since the SetID lookup field leaves room for future extensions. A 32-bit timestamp in seconds would need time synchronization across a wireless-sensor network and creates way too much overhead, so the "Export Time" field got cut 🙃. If applications should require a concrete observation time (for example, a timestamp), it is RECOMMENDED to include it as a separate Information Element in the TinyIPFIX Records. Yes, a timestamp is a whole vibe, but add it as its own Information Element 💅
6.2. TinyIPFIX Set
A TinyIPFIX Set is a bunch of TinyIPFIX Template or TinyIPFIX Data Records 🎀. Depending on the TinyIPFIX Record type, the TinyIPFIX Set can 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 is made of a 2-octet "Set ID" field and a 2-octet "Length" field. For the TinyIPFIX Set Header, both of those get compressed down to 1 octet each. The TinyIPFIX Set Header looks like 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
Here's what the two fields mean 👇
TinyIPFIX Set ID
The "Tiny Set ID" tells you what kind of data is carried in the TinyIPFIX Set. A TinyIPFIX Template Set is identified by TinyIPFIX Set ID 2, which matches the Template Set IDs IPFIX uses in [RFC7011]. TinyIPFIX Set ID number 3 MUST NOT be used, because Options Templates aren't supported. A TinyIPFIX Collector MUST ignore any Set with Set ID 3, and it SHOULD log it too 📝. Values from 4 to 127 are reserved for future use. Anything above 127 is used for TinyIPFIX Data Sets.
Length
The "Length" field holds the total length of the TinyIPFIX Set, including the TinyIPFIX Set Header 📏.
6.3. TinyIPFIX Template Record Format
Here's the format of TinyIPFIX Template Records, shown in Figure 12. A TinyIPFIX Template Record starts with a TinyIPFIX Template Record Header, and then one or more Field Specifiers follow. The Field Specifier format is defined in Section 6.4, and it's identical to the Field Specifier definition in [RFC7011] 🦋.
+--------------------------------------------------+
| TinyIPFIX Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+Figure 12: TinyIPFIX Template Format
The TinyIPFIX Template Record Header looks like 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. Keep those IDs unique, bestie 🫶
Field Count
This is the number of fields placed in the TinyIPFIX Template Record 🔥
6.4. Field Specifier Format ✨
okay so bestie, this is where the template record's field specifiers get their vibe 💅 The type and length of the transmitted data gets encoded in Field Specifiers inside TinyIPFIX Template Records. And the super iconic part is that the Field Specifier is literally identical to the one IPFIX defined in [RFC7011]. Same look, same energy 🎀
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 SpecifierWhere:
- E 🦋 This is the Enterprise bit, and it's the very first bit of the Field Specifier. If this bit is zero, the Information Element Identifier points to 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 points to an enterprise-specific Information Element, and the Enterprise Number field MUST be present.
- Information Element Identifier 🌸 A numeric value that says what type of Information Element we're dealing with.
- Field Length 🍓 The length of the matching encoded Information Element, in octets. Refer to [RFC7012]. The value 65535 is illegal in TinyIPFIX, because variable-length Information Elements are not supported. no cap, that one is a hard no 💀
- Enterprise Number 👑 The IANA Private Enterprise Number of the authority that defines the Information Element identifier in this Template Record.
Vendors can easily define their own data model by registering an 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 get sent in TinyIPFIX Data Sets. The format of the Data Records is shown in Figure 15 and it matches the Data Record format from IPFIX. It's giving consistency 🫶
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
Figure 15: Data Record Format7. TinyIPFIX Mediation 🌈
okay so there are two types of TinyIPFIX Intermediate Processes. The first one can happen on the transition between a constrained network (e.g., 6LoWPAN) and the unconstrained network. This mediation changes the network and transport protocol from 6LoWPAN preferring UDP to IP/(SCTP|TCP|UDP), and it's shown in Figure 16. main character energy ✨
+-----------------------+
| TinyIPFIX Device |
| [Exporting Process] |
+-----------------------+
|
TinyIPFIX |
over 6LoWPAN/UDP |
v
+-------------------------+
| TinyIPFIX mediator |
| [Collecting Process] |
| [Exporting Process] |
+-------------------------+
|
TinyIPFIX |
IP/(UDP/SCTP|TCP) |
v
+--------------------------+
| Collector |
| [Collecting Process(es)] |
+--------------------------+
Figure 16: Translation from TinyIPFIX over 6LoWPAN/UDP
to TinyIPFIX over IP/(SCTP|TCP|UDP)The mediator strips the TinyIPFIX Messages out of the 6LoWPAN/UDP packets and wraps them up in 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 IPFIXThis mediation can also be done by an IPFIX Collector before it parses the IPFIX message, as shown in Figure 18. There's no need for a parser from TinyIPFIX to IPFIX if this mediation process can be put in front of an existing IPFIX collector. 🦋
+------------------------+ +----------------------+
| TinyIPFIX Device | TinyIPFIX | IPFIX Mediator |
| [Exporting Processes] |----------------->| [Collecting Process] |
+------------------------+ | [Exporting Process] |
| | |
| |IPFIX |
| | |
| v |
| Collector |
| [Collecting Process] |
+----------------------+
Figure 18: Transformation from TinyIPFIX to IPFIXThe 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. After that, the new IPFIX Message Length needs to be calculated and inserted into the IPFIX Message header. 🍓
7.1. Expanding the Message 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 is 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 1 octet and need to be expanded:
- Set ID 🔥 The field needs to be expanded from 1 octet to 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 2 octets. 💖
8. Template Management 👑
As with IPFIX, TinyIPFIX 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: template loss can occur. If a Template is lost on its way to the Collector, any 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 static template directly after booting. 🫶
⚠️ UDP is the one that can drop templates, so if you're on UDP, you can't count on your Collector getting them. Lowkey stressful 😭
8.1. 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, which are not supported in TinyIPFIX. Template Withdrawals MUST NOT be sent by TinyIPFIX Exporters. 🎀
8.2. UDP ✨
Okay bestie, for UDP the Template Management rules from [RFC7011] apply by default 💖 unless this document says otherwise. Easy, right? 🎀
TinyIPFIX Templates MUST be sent by a TinyIPFIX Exporter before any TinyIPFIX Data Set that refers to that Template goes out. Templates don't really change in TinyIPFIX, so they should be pre-shared 🧚. TinyIPFIX Devices come with a default setup when they're deployed. After booting, they announce their TinyIPFIX Template straight to the network, and they MAY repeat it if UDP is being used 📡.
So a TinyIPFIX Template that has been sent once MAY NOT be withdrawn and MUST NOT expire 🙅♀️. It's giving "once it's out, it's out" energy. If a TinyIPFIX Smart Meter wants to use a different TinyIPFIX Template, it MUST use a new TinyIPFIX Template ID for that Template 🆕. No recycling IDs, bestie 💅.
Now the tea 🫖: with UDP, reliable transport of TinyIPFIX Templates can't be guaranteed, so Templates can be lost 😭. A TinyIPFIX Exporter MUST expect TinyIPFIX Template loss. Therefore, it MUST re-send its TinyIPFIX Templates periodically 🔁. A TinyIPFIX Template MUST be re-sent after a fixed number N of TinyIPFIX Messages that contain TinyIPFIX Data Sets referring to that Template. The number N MUST be configured by the application developer 🛠️.
Retransmission and the whole specification of N can be avoided if the TinyIPFIX Exporter and TinyIPFIX Collector use pre-shared templates 🫶. No resending drama at all, periodt ✨.
That's the whole UDP vibe, bestie 🌈💜
9. Security Considerations 🔐
Okay, this one is serious, so listen up 👀. The same security considerations as for the IPFIX Protocol [RFC7011] apply. So go read that one too, because the security story is the same family drama 💀.
10. IANA Considerations 🦋
This document does not require any IANA actions. IANA can take a little nap on this one 😴🌸.
11. References 📚
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>. - [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 S.L.,
<https://www.advanticsys.com/>, 2017. - [GreatDuck] Mainwaring, A., Polastre, J., Szewczyk, R., Culler, D., and J. Anderson, "Wireless Sensor Networks for Habitat Monitoring", In Proceedings of the 1st ACM international workshop on 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 of civil infrastructures using wireless sensor networks", Proceedings of the 6th international conference on Information processing in sensor networks (IPSN 2007), Cambridge, MA, ACM Press, pp. 254-263, DOI 10.1145/1236360.1236395, April 2007.
- [Kothmayr10] Kothmayr, T., "Data Collection in Wireless Sensor Networks for Autonomic Home Networking", Bachelor Thesis, Technical University of Munich, Munich, Germany, January 2010.
- [openMote] openMote Technologies S.L., 2017,
<http://openmote.com>. - [Schmitt09] Schmitt, C. and G. Carle, "Applications for Wireless Sensor Networks", Handbook of Research on P2P and Grid Systems for Service-Oriented Computing: Models, Methodologies and Applications, Edited by Antonopoulos N., Exarchakos G., Li M., and A. Liotta, Information Science Publishing, Chapter 46, pp. 1076-1091, ISBN: 978-1615206865, 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, 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, Edited by Sheng, M., Qin, Y., Yao, L., and B. Benatallah, Morgen Kaufmann (imprint of Elsevier), Chapter 8, pp. 229-247, ISBN: 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", Proceedings of the 2nd international conference on Embedded networked sensor systems (SenSys 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., Burgess, S., Dawnson, T., Buonadonna, P., Gay, D., and W. Hong, "A macroscope in the redwoods", Proceedings of the 3rd international conference on Embedded networked sensor systems (SenSys 05), 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.chThanks for sticking with me through all seven parts, bestie 💜🦋
📦 where this page comes from
- ietf: rfc8272 2017-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms