idnits 2.17.1 draft-schmitt-ipfix-tiny-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7011], [RFC4944]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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 have a default setup when deployed and after booting they announce their TinyIPFIX Template directly to the networkand 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 it MUST use a new TinyIPFIX Template ID for the TinyIPFIX Template. -- The document date (July 25, 2017) is 2465 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Schmitt 3 Internet-Draft B. Stiller 4 Intended status: Informational University of Zurich 5 Expires: January 26, 2018 B. Trammell 6 ETH Zurich 7 July 25, 2017 9 TinyIPFIX for smart meters in constrained networks 10 draft-schmitt-ipfix-tiny-03 12 Abstract 14 This document specifies the TinyIPFIX protocol that serves for 15 transmitting smart metering data in constrained networks such as 16 6LoWPAN [RFC4944]. TinyIPFIX is derived from IPFIX [RFC7011] and 17 adopted to the needs of constrained networks. This document 18 specifies how the TinyIPFIX Data and Template Records are transmitted 19 in constrained networks such as 6LoWPAN and how TinyIPFIX data can be 20 converted into unTinyIPFIX data in a proxy device. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 26, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Document structure . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Hardware constraints . . . . . . . . . . . . . . . . . . 6 61 3.2. Energy constraints . . . . . . . . . . . . . . . . . . . 6 62 3.3. Packet size constraints . . . . . . . . . . . . . . . . . 7 63 3.4. Transport protocol constraints . . . . . . . . . . . . . 7 64 4. Application scenarios for TinyIPFIX . . . . . . . . . . . . . 8 65 5. Architecture for TinyIPFIX . . . . . . . . . . . . . . . . . 11 66 6. TinyIPFIX Message Format . . . . . . . . . . . . . . . . . . 13 67 6.1. TinyIPFIX Message Header . . . . . . . . . . . . . . . . 14 68 6.2. TinyIPFIX Set . . . . . . . . . . . . . . . . . . . . . . 18 69 6.3. TinyIPFIX Template Record Format . . . . . . . . . . . . 19 70 6.4. Field Specifier Format . . . . . . . . . . . . . . . . . 20 71 6.5. TinyIPFIX Data Record Format . . . . . . . . . . . . . . 21 72 7. TinyIPFIX Mediation . . . . . . . . . . . . . . . . . . . . . 21 73 7.1. Expanding the Message header . . . . . . . . . . . . . . 24 74 7.2. Translating the Set Headers . . . . . . . . . . . . . . . 25 75 7.3. Expanding the Template Record Header . . . . . . . . . . 25 76 8. Template Management . . . . . . . . . . . . . . . . . . . . . 25 77 8.1. TCP / SCTP . . . . . . . . . . . . . . . . . . . . . . . 26 78 8.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 79 9. Security considerations . . . . . . . . . . . . . . . . . . . 26 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 81 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 83 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 84 12.2. Informative References . . . . . . . . . . . . . . . . . 28 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 87 1. Introduction 89 Smart meters that form a constrained wireless network need an 90 application layer protocol that allows the efficient transmission of 91 metering data from the devices to a central analysis device. The 92 meters used to build such networks are usually equipped with low-cost 93 and low-power hardware. This leads to constraints in computational 94 capacities, available memory and networking resources. 96 The devices are often battery powered and are expected to run for a 97 long time without having the possibility of recharging themselves. 98 In order to save energy, smart meters often power off their wireless 99 networking device. Hence, they don't have a steady network 100 connection, but are only part of the wireless network as needed when 101 there is data that needs to be exported. A push protocol like 102 TinyIPFIX, where data is transmitted autonomic from the meters to one 103 or more collectors, is suitable for reporting metering data in such 104 networks. 106 TinyIPFIX is derived from IPFIX [RFC7011] and therefore inherits most 107 of its properties. One of these properties is the separation of data 108 and its data description by encoding the former in Data Sets and the 109 latter in Template Sets. 111 Transforming TinyIPFIX to IPFIX as per [RFC7011] is very simple and 112 can be done on the border between the constrained network and the 113 more general network. The transformation between one form of IPFIX 114 data into another is known as IPFIX Mediation [RFC5982]. Hence, 115 smart metering networks that are based on TinyIPFIX can be easily 116 integrated into an existing IPFIX measurement infrastructure. 118 1.1. Document structure 120 Section 2 introduces the terminology used in this draft. Afterwards, 121 hardware and software constraints in constrained networks, which will 122 motivate our modifications to the IPFIX protocol, are discussed in 123 Section 3. Section 4 describes the application scenarios and 124 Section 5 describes the architecture for TinyIPFIX. Section 6 125 defines the TinyIPFIX protocol itself and discusses the differences 126 between TinyIPFIX and IPFIX. The Mediation Process from TinyIPFIX to 127 IPFIX is described in Section 7. Section 8 defines the process of 128 Template Management on the Exporter and the Collector. Section 9 and 129 Section 10 discuss the security and IANA considerations for 130 TinyIPFIX. 132 2. Terminology 134 Most of the terms used in this draft are defined in [RFC7011]. All 135 these terms are written with their first letter being capitalized. 136 Most of the terms that are defined for IPFIX can be used to describe 137 TinyIPFIX. This draft uses the term IPFIX to refer to IPFIX as 138 defined in [RFC7011] and the term TinyIPFIX for the protocol 139 specified in this draft document assuming constrained networks. The 140 term "Tiny" is used in front of the IPFIX term to distinguish between 141 the IPFIX version and the TinyIPFIX version. 143 The terms IPFIX Message, IPFIX Device, Set, Data Set, Template Set, 144 Data Record, Template Record, Collecting Process, Collector, 145 Exporting Process and Exporter are defined as in [RFC7011]. The term 146 IPFIX Mediator is defined in [RFC5982]. The terms Intermediate 147 Process, IPFIX Proxy, IPFIX Concentrator are defined in [RFC6183]. 149 All these terms above have been adapted from the IPFIX definitions. 150 As they keep a similar notion but in a different context of 151 constrained networks, the term "TinyIPFIX" now complements the 152 defined terms. 154 The term smart meter is used to refer to constrained devices like 155 wireless sensor nodes, motes or any other kind of small constrained 156 device that can be part of a network that is based on IEEE802.15.4 157 and 6LoWPAN [RFC4944]. 159 TinyIPFIX Exporting Process 161 The TinyIPFIX Exporting Process is a process that exports 162 TinyIPFIX Records. 164 TinyIPFIX Exporter 166 A TinyIPFIX Exporter is device that contains at least one 167 TinyIPFIX Exporting Process. 169 TinyIPFIX Collecting Process 171 The TinyIPFIX Collecting Process is a process inside a device that 172 is able to receive and process TinyIPFIX Records. 174 TinyIPFIX Collector 176 A TinyIPFIX Collector is a device that contains at least one 177 TinyIPFIX Collecting Process. 179 TinyIPFIX Device 181 A TinyIPFIX Device is a device that contains one or more TinyIPFIX 182 Collectors or one or more TinyIPFIX Exporters. 184 TinyIPFIX Smart Meter 186 A TinyIPFIX Smart Meter is a device that contains the 187 functionality of a TinyIPFIX Device. It is usually equipped with 188 one or more sensors that meter a physical quantity, like power 189 consumption, temperature, or physical tampering with the device. 190 Every TinyIPFIX Smart Meter MUST at least contain a TinyIPFIX 191 Exporting Process. It MAY contain a TinyIPFIX Collecting Process 192 in order to work as a TinyIPFIX Proxy or TinyIPFIX Concentrator. 194 TinyIPFIX Data Record 196 A TinyIPFIX Data Record equals an IPFIX Data Record in [RFC7011]. 197 The term is used to distinguish between IPFIX and TinyIPFIX 198 throughout this document. 200 TinyIPFIX Template Record 202 A TinyIPFIX Template Record is similar to an IPFIX Template Record 203 in [RFC7011]. The Template Record Header is substituted with a 204 TinyIPFIX Template Record Header and is otherwise equal to a 205 Template Record. See Section 6.3. 207 TinyIPFIX Set 209 The TinyIPFIX Set is a group of TinyIPFIX Data Records or 210 TinyIPFIX Template Records with a TinyIPFIX Set Header. Its 211 format is defined in Section 6.2. 213 TinyIPFIX Data Set 215 The TinyIPFIX Data Set is a TinyIPFIX Set that contains TinyIPFIX 216 Data Records. 218 TinyIPFIX Template Set 220 A TinyIPFIX Template Set is a TinyIPFIX Set that contains 221 TinyIPFIX Template Records. 223 TinyIPFIX Message 225 The TinyIPFIX Message is a message originated by a TinyIPFIX 226 Exporter. It is composed of a TinyIPFIX Message Header and one or 227 more TinyIPFIX Sets. The TinyIPFIX Message Format is defined in 228 Section 6. 230 TinyIPFIX Intermediate Process 232 A TinyIPFIX Intermediate Process is an IPFIX Intermediate Process 233 that can handle TinyIPFIX Messages. 235 TinyIPFIX Proxy 237 A TinyIPFIX Proxy is an IPFIX Proxy that can handle TinyIPFIX 238 Messages. 240 TinyIPFIX Concentrator 242 A TinyIPFIX Concentrator is device that can handle TinyIPFIX 243 Messages (e.g., pre-process them) and is not constrained. 245 TinyIPFIX Proxy 247 A TinyIPFIX Proxy is an IPFIX Proxy that can handle TinyIPFIX 248 Messages and is not constrained. 250 A TinyIPFIX Transport Session is defined by the communication between 251 a TinyIPFIX Exporter (identified by an 6LoWPAN-Address, the Transport 252 Protocol, and the Transport Port) and a TinyIPFIX Collector 253 (identified by the same properties). 255 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 256 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 257 document are to be interpreted as described in [RFC2119]. 259 3. Constraints 261 3.1. Hardware constraints 263 The target devices for TinyIPFIX are usually equipped with low-cost 264 hardware and therefore face several constraints concerning CPU and 265 memory [Schmitt09]. For example, the IRIS mote from Crossbow 266 Technologies Inc. has a size of 58 x 32 x 7 mm (without a battery 267 pack) [Crossbow]. Thus, there is little space for micro controller, 268 memory (128 kb program flash, 512 kb measurement serial flash, 8 kb 269 RAM, 4 kb configuration EEPROM), and radio frequency transceiver, 270 which are located on the board. Similar issues occure by TelosB 271 produced by Crossbow Technologies Inc. [Crossbow] and Advantic Sys. 272 Inc. [Advantic] but offering more memory (48 kb flash, 1024 kb serial 273 flash, 10 kb RAM, 16 kb configuration EEPROM). 275 Network protocols used on such hardware need to respect these 276 constraints. They must be simple to implement using little code and 277 little run time memory and should produce little overhead when 278 encoding the application payload. 280 3.2. Energy constraints 282 Smart meters that are battery powered have hard energy constraints 283 [Schmitt09]. By power supply of two 2 AA 2,800-mAh batteries this 284 means approximately 30,240J. If they run out of power, their battery 285 has to be changed, which means physical manipulation to the device is 286 necessary. Using as little energy as possible for network 287 communication is therefore desired. 289 A smart metering device can save a lot of energy, if it powers down 290 its radio frequency transceiver. Such devices do not have permanent 291 network connectivity but are only part of the network as needed. A 292 push protocol, where only one side is sending data, is suitable for 293 transmitting application data under such circumstances. As the 294 communication is unidirectional, a meter can completely power down 295 its radio frequency transceivers as long as it does not have any data 296 to send. If the metering device is able to keep a few measurements 297 in memory, and if real time metering is not a requirement, the 298 TinyIPFIX Data Records can be pushed less frequently, therefore 299 saving some more energy on the radio frequency transceivers. 301 3.3. Packet size constraints 303 TinyIPFIX is mainly targeted for the use in 6LoWPAN networks, which 304 are based on IEEE 802.15.4 [RFC4944]. However, the protocol can also 305 be used to transmit data in other networks when a mediator is used 306 translating the TinyIPFIX data into the data format used in the other 307 network (e.g., IPFIX) and is able to map the 6LoWPAN addresses to the 308 addresses used in the other network. This operation typically 309 consists of per-message re-encapsulation and/or re-encoding. As 310 defined [RFC4944], IEEE 802.15.4 starts from a maximum physical layer 311 packet size of 127 octets (aMaxPHYPacketSize) and a maximum frame 312 overhead of 25 octets (aMaxFrameOverhead), leaving a maximum frame 313 size of 102 octets at the media access control (MAC) layer. IPv6 on 314 the other hand defines a minimum MTU of 1280 octets. Hence, 315 fragmentation has to be implemented in order to transmit such large 316 packets. While fragmentation allows the transmission of large 317 messages, its use is problematic in networks with high packet loss 318 because the complete message has to be discarded if only a single 319 fragment gets lost. 321 TinyIPFIX enhances IPFIX by a header compression scheme, which allows 322 the header size overhead to be significantly reduced. Additionally, 323 the overall TinyIPFIX Message size is reduced, which reduces the need 324 for fragmentation. 326 3.4. Transport protocol constraints 328 The IPFIX standard [RFC7011] defines several transport protocol 329 bindings for the transmission of IPFIX Messages. SCTP support is 330 REQUIRED for any IPFIX Device to achieve standard conformance 331 [RFC7011], and its use is highly recommended. However, sending IPFIX 332 over UDP and TCP MAY also be implemented. 334 This transport protocol recommendation is not suitable for TinyIPFIX. 335 A header compression scheme that allows a compression of an IPv6 336 header from 40 octets down to 2 octets is defined in 6LoWPAN. There 337 is a similar compression scheme for UDP, but there is no such 338 compression for TCP or SCTP headers. If header compression can be 339 employed, more space for application payload is available. 341 Using UDP on the transport layer for transmitting IPFIX Messages is 342 therefore RECOMMENDED. Furthermore, TCP or SCTP are currently not 343 supported on some platforms, like on TinyOS [Harvan08]. Hence, UDP 344 may be the only option. 346 Every TinyIPFIX Exporter and Collector MUST implement UDP transport 347 layer support for transmitting data in a constrained network 348 environment. It MAY also offer TCP or SCTP support. In case TCP or 349 SCTP MAY be used power consumption will grow and the available size 350 of application payload compared to the use of UDP May be reduced. If 351 TinyIPFIX is transmitted over a non-constrained network, using SCTP 352 as a transport layer protocol is RECOMMENDED. TinyIPFIX works 353 independent of the target environment, because it MUST only be 354 ensured that all intermediate devices can understand TinyIPFIX and be 355 able to extract needed packet information (e.g., IP destination 356 address). TinyIPFIX messages can be included n other transport 357 protocols in the payload whenever is needed making TinyIPFIX highly 358 flexible and usable for different communication protocols (e.g., 359 COAP, UDP, TCP). TinyIPFIX itself just specifies a messages format 360 for the collected data to be transmitted. 362 The constraints on UDP usage given in Section 6.2 of [RFC5153] apply 363 to TinyIPFIX as well. TinyIPFIX is not intended for use over the 364 open Internet. In general, the networks on which it runs are 365 considered dedicated for sensor operations, and under the control of 366 a single administrative domain. 368 4. Application scenarios for TinyIPFIX 370 TinyIPFIX is derived from IPFIX [RFC7011] and is therefore a 371 unidirectional push protocol assuming UDP usage. This means all 372 communication that employs TinyIPFIX is unidirectional from an 373 Exporting Process to a Collecting Process. Hence, TinyIPFIX only 374 fits for application scenarios where meters transmit data to one or 375 more Collectors. In case pull request SHOULD also be supported by 376 TinyIPFIX it is RECOMMENDED not to change the code of TinyIPFIX much 377 to get along with the restricted memory available [schmitt2017]. 378 Meaning including just a one bit field, called type, to distinguish 379 between push and pull messages would be feasable, but the filtering 380 SHOULD be done by the gateway and not by the constrained device, 381 meaning if a pull is performed the constained device is triggered to 382 create a TinyIPFIX message immediately as usual, set the type field 383 to one instead of zero (for a push message), and sends message to the 384 gateway. Where at the gateway the filtering is performed based on 385 the pull request. 387 If TinyIPFIX is used over UDP, as recommended, packet loss can occur. 388 Furthermore, if an initial Template Message gets lost, and is 389 therefore unknown to the Collector, all TinyIPFIX Data Sets that 390 reference this Template cannot be decoded. Hence, all these Messages 391 are lost if they are not cached by the Collector. It should be clear 392 to an application developer, that TinyIPFIX can only be used over UDP 393 if these TinyIPFIX Message losses are not a problem. Avoiding this 394 loss it is RECOMMEND to repeat the Template Message periodically 395 having in mind that a Template never changes for a constrained device 396 after deployment. Even when Template Messages becomes lost in the 397 network the data can be manually translated later when the Template 398 Messages is resend. Including an acknowledgement mechanism is NOT 399 RECOMMENDED due to overhead, because this would require storage of 400 any send data on the constrained devices until it is acknowledged. 401 In critial applications it is RECOMMENDED to repeat the Template 402 Message more often. 404 TinyIPFIX over UDP is especially not a suitable protocol for 405 applications where sensor data trigger policy decisions or 406 configuration updates for which packet loss is not tolerable. 408 Applications that use smart sensors for accounting purposes for long 409 time measurements can benefit from the use of TinyIPFIX. One 410 application for IPFIX is long term monitoring of large physical 411 volumes. In [Tolle05], Tolle et al. built a system for monitoring a 412 "70-meter tall redwood tree, at a density interval of 5 minutes in 413 time and 2 meters in space". The sensor node infrastructure was 414 deployed to measure the air temperature, relative humidity and 415 photosynthetically active solar radiation over a long time period. 417 TinyIPFIX is a good fit for such scenarios. Data can be measured by 418 the sensors of the TinyIPFIX Smart Meter over several 5 minute time 419 intervals and the measurements can be accumulated into a single 420 TinyIPFIX Message. As soon as enough measurements are stored in the 421 TinyIPFIX Message, e.g. if the TinyIPFIX Message size fills the 422 available payload in a single IEEE 802.15.4 packet, the wireless 423 transceiver can be activated and the TinyIPFIX Message can be 424 exported to a TinyIPFIX Collector. 426 Similar sensor networks have been built to monitor the habitat of 427 animals, e.g. in the "Great Duck Island Project" [GreatDuck], 428 [SMPC04]. The purpose of the sensor network was to monitor the birds 429 by deploying sensors in and around their burrows. The measured 430 sensor data was collected and stored in a database for offline 431 analysis and visualization. Again, the sensors can perform their 432 measurements periodically, accumulate the sensor data and export them 433 to a TinyIPFIX Collector. 435 Other application scenarios for TinyIPFIX could be applications where 436 sensor networks are used for long term structural health monitoring 437 in order to investigate long term weather conditions on the structure 438 of a building. For example, a smart metering network has been built 439 to monitor the structural health of the Golden Gate Bridge [Kim07]. 440 If a sensor network is deployed to perform a long term measurement of 441 the structural integrity, TinyIPFIX can be used to collect the sensor 442 measurement data. 444 If an application developer wants to decide whether to use TinyIPFIX 445 for transmitting data from smart meters, he must take the following 446 considerations into account: 448 1. The application should require a push protocol per default. The 449 timing intervals when to push data should be pre-defind before 450 deployment. The property above allows a TinyIPFIX Smart Meter to 451 turn off its wireless device in order to save energy, as it does 452 not have to receive any data. 454 2. If real-time reporting is not required, the application might 455 benefit from accumulate several measurements into a single 456 TinyIPFIX Message, causing delay but lowering traffic in the 457 network. TinyIPFIX easily allows the accumulation of several 458 measurements into a single TinyIPFIX Message (or a single 459 packet). This accumulation can happen on the TinyIPFIX Smart 460 Meter that accumulates several of its own measurements. Or it 461 can happen within a multi-hop wireless network where one IPFIX 462 Proxy accumulates several TinyIPFIX Messages into a single 463 TinyIPFIX Message before forwarding them. 465 3. The application must accept potential packet loss. TinyIPFIX 466 only fits for applications where metering data is stored for 467 accounting purposes and not for applications where the sensor 468 data triggers configuration changes or policy decisions, except 469 when Message loss is acceptable for some reason. 471 4. The application must not require per-message export timestamps 472 (e.g. for auditing). TinyIPFIX removes export timestamps, 473 generally only useful for template management operations which it 474 also does not support, from IPFIX. This is a minor 475 inconvenience, since per-record timestamp Information Elements 476 are also available in IPFIX. 478 5. Architecture for TinyIPFIX 480 The TinyIPFIX architecture is similar to the IPFIX architecture, 481 which is described in [RFC5470]. The most common deployment of 482 TinyIPFIX Smart Meters is shown in Figure 1 where each TinyIPFIX 483 Smart Meter can have different sensors available (e.g., IRIS: 484 Temperature, Humidity, Sound; TelosB: Temperature, Bridgeness, 485 Humidity, GPS) building the sensor data. 487 +------------------------+ +------------------------+ 488 | TinyIPFIX Device | ... | TinyIPFIX Device | 489 | [Exporting Process] | | [Exporting Process] | 490 +------------------------+ +------------------------+ 491 | | 492 TinyIPFIX | | TinyIPFIX 493 | | 494 v v 495 +----------------------------------+ 496 | 497 v 498 +----------------------------+ 499 | TinyIPFIX Collector | 500 | [Collecting Process(es)] | 501 +----------------------------+ 502 | 503 v 504 +-----------------------+ 505 | | 506 v v 507 +----------------+ +----------------+ 508 |[*Application 1]| ... |[*Application n]| 509 +----------------+ +----------------+ 511 Figure 1: Direct transmission between TinyIPFIX Devices and 512 applications 514 A TinyIPFIX Smart Meter (S.M.) receives measurement data from its 515 internal sensors to to create its TinyIPFIX messages. It then 516 encodes the results into a TinyIPFIX Message usinf a TinyIPFIX 517 Exporting Process and exports this TinyIPFIX Message to one or more 518 TinyIPFIX Collectors. The TinyIPFIX Collector runs one or more 519 applications that process the collected sensor data. The TinyIPFIX 520 Collector can be deployed on non-constrained devices at the 521 constrained network border. 523 A second way to deploy TinyIPFIX Smart Meter can employ accumulation 524 on TinyIPFIX Messages during their journey through the constrained 525 network as shown in Figure 2. This accumulation can be performed by 526 TinyIPFIX Concentrators. Such devices must have enough resources to 527 perform the accumulation. 529 +------------------------+ +------------------------+ 530 | TinyIPFIX Device | ... | TinyIPFIX Device | 531 | [Exporting Process] | | [Exporting Process] | 532 +------------------------+ +------------------------+ 533 | | 534 TinyIPFIX | | TinyIPFIX 535 | | 536 v v 537 +----------------------------------+ 538 | 539 v 540 +------------------------+ 541 | TinyIPFIX Concentrator | 542 | [Collecting Process] | 543 | [Exporting Process] | 544 +------------------------+ 545 | 546 TinyIPFIX | 547 | 548 v 549 +--------------------------+ 550 | Collector | 551 | [Collecting Process(es)] | 552 +--------------------------+ 554 Figure 2: Accumulation of TinyIPFIX 556 TinyIPFIX Smart Meters send their data to TinyIPFIX Concentrator, 557 which needs to have enough storage space to store the incoming data. 558 If the TinyIPFIX Concentrator is hosted in a TinyIPFIX Smart Meter it 559 MAY be also able to collect data from it sensors, if activated, it 560 may also accumulate the incoming data with its own measurement data. 561 The accumulated data can then be re-exported again to one or more 562 Collectors. In that case the TinyIPFIX Concentrator can be viewed as 563 receiving data from multiple Smart Meters - one locally and some 564 remotely. 566 The last deployment, shown in Figure 3, employs another TinyIPFIX 567 Mediation process. 569 +-------------------------+ +-------------------------+ 570 | Remote Smart Meter | | Local Smart Meter | 571 +-------------------------+ +-------------------------+ 572 | TinyIPFIX Device | | TinyIPFIX Device | 573 | [Exporting Process] | | [Exporting Process] | 574 +-------------------------+ +-------------------------+ 575 | | 576 TinyIPFIX | | TinyIPFIX 577 | | 578 v v 579 +-------------------------+ 580 | TinyIPFIX Concentrator | 581 | [Collecting Process] | 582 +-------------------------+ 584 Figure 3: TinyIPFIX Mediator 586 In this deployment, the TinyIPFIX Smart Meters transmit their 587 TinyIPFIX Messages to one node, e.g. the base station, which 588 translates the TinyIPFIX Messages to IPFIX Messages. The IPFIX 589 Messages can then be exported into an existing IPFIX infrastructure. 590 The Mediation process from TinyIPFIX to IPFIX is described in 591 Section 7. 593 6. TinyIPFIX Message Format 595 A TinyIPFIX IFPIX Message starts with a TinyIPFIX Message Header, 596 followed by one or more TinyIPFIX Sets. The TinyIPFIX Sets can be 597 either of type TinyIPFIX Template Set or of type TinyIPFIX Data Set. 598 A TinyIPFIX Message MUST only contain one type of TinyIPFIX Set. The 599 format of the TinyIPFIX Message is shown in Figure 4. 601 +----------------------------------------------------+ 602 | TinyIPFIX Message Header | 603 +----------------------------------------------------+ 604 | TinyIPFIX Set | 605 +----------------------------------------------------+ 606 | TinyIPFIX Set | 607 +----------------------------------------------------+ 608 ... 609 +----------------------------------------------------+ 610 | TinyIPFIX Set | 611 +----------------------------------------------------+ 613 Figure 4: TinyIPFIX Message Format 615 6.1. TinyIPFIX Message Header 617 The TinyIPFIX Message Header is derived from the IPFIX Message 618 Header, with some optimization using field compression. The IPFIX 619 Message Header from [RFC7011] is shown in Figure 5. 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Version Number | Length | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Export Time | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Sequence Number | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Observation ID | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Figure 5: IPFIX Message Header 635 The length of the IPFIX Message Header is 16 octets and every IPFIX 636 Message has to be started with it. The TinyIPFIX Message Header 637 needs to be smaller due to the packet size constraints discussed in 638 Section 3.3. The TinyIPFIX Header consists of a fixed part of three 639 octets as shown in Figure 6, followed by a variable part as shown in 640 Figure 7 to Figure 10. 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 |E|E| SetID | Length | Sequence | Ext. Sequenz | 646 |1|2|Lookup | | Number | Number | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Ext. SetID | 649 +-+-+-+-+-+-+-+-+ 651 Figure 6: Format of the TinyIPFIX Message Header including fixed and 652 optional parts 654 The fixed part has a length of three octets and consists of the "E1" 655 field (1 bit), the "E2" field (1 bit), the "SetID Lookup" field (4 656 bits), the "Length" field (10 bits), and the "Sequence Number" field 657 (8 bits). The variable part has a variable length defined by the 658 "E1" and "E2" fields in the fixed header. The four variants are 659 illustrated in Figure 7 to Figure 10 below. 661 0 1 2 662 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 |0|0| SetID | Length | Sequence | 665 | | |Lookup | | Number | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Figure 7: TinyIPFIX Message Header format if E1 = E2 = 0 670 0 1 2 3 671 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 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 |1|0| SetID | Length | Sequence | Ext. SetID | 674 | | |Lookup | | Number | | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Figure 8: TinyIPFIX Message Header format if E1 = 1 and E2 = 0 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 |E|E| SetID | Length | Sequence | Ext. Sequenz | 683 |1|2|Lookup | | Number | Number | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Figure 9: TinyIPFIX Message Header format if E1 = 0 and E2 = 1 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 |1|1| SetID | Length | Sequence | Ext. Sequenz | 692 | | |Lookup | | Number | Number | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Ext. SetID | 695 +-+-+-+-+-+-+-+-+ 697 Figure 10: TinyIPFIX Message Header format if E1 = E2 = 1 699 The fixed header fields are defined as follows [kothmayr10] 700 [schmitt2014]: 702 E1 and E2 704 The bits marked "E1" and "E2" control the presence of the field 705 "Ext. SetID" and the presence of the field "Ext. Sequence 706 Number" respectively. 708 In case E1 = E2 = 0 the TinyIPFIX message header has the format 709 shown in Figure 7. The fields Extended Sequence Number and 710 Extended SetID MUST NOT be present. 712 When E1 = 1, the extended SetID field MUST be present. Custom 713 SetIDs can be specified in the extended SetID field setting all 714 SetID Lookup bits to 1 (cf. Figure 8.) When evaluated, the value 715 specified in the extended SetID field is shifted left by 8 bits to 716 prevent collisions with the reserved SetIDs 0-255. To reference 717 these, shifting can be disabled by setting all SetID lookup bits 718 to 1. 720 Depending on the application sampling rates might be larger than 721 in typical constraind networks (e.g., Wireless Sensor Networks 722 (WSN), Cyper-Physical-Systems (CPS)) and, thus, they may have a 723 large quantity of records per packet. In order to make TinyIPFIX 724 applicable for those cases E2 = 1 is set (cf. Figure 9). This 725 means the Extended Sequence Number field MUST be present offering 726 8-bit more sequence numbers as usual. Depending on the 727 constrained network settings also the combination E1 = E2 = 1 is 728 possible resulting in the maximum TinyIPFIX Message header shown 729 in Figure 10 where Extended Sequence Number field and Extended 730 SetID field MUST both be present. 732 SetID Lookup 734 This field acts as a lookup field for the SetIDs and provides 735 shortcuts to often used SetIDs. Four values are defined: 737 Value = 0 means Lookup extended SetID field, Shifting enabled. 739 Value = 1 means SetID = 2 and message contains a Template 740 definition. 742 Value = 2 means SetID = 256 and message containts Data Record for 743 Template 256. This places special importance on a single template 744 ID, but since most sensor nodes only define a single template 745 directly after booting and continue to stream data with this 746 template ID during the whole session lifetime, this shorthand is 747 useful for this case. 749 Value = 3-14 means SetIDs are reserved for future extensions. 751 Value = 15 means lookup extended SetID field, shifting enabled. 753 Length 755 The length field has a fixed length of 10 bits. 757 Sequence Number 759 Due to the low sampling rate in typical WSNs, the "Sequence 760 Number" field is only one byte long. However, some applications 761 may have a large quantity of records per packet. In this case the 762 sequence field can be extended to 16 bit by setting the E2-bit to 763 1. 765 Since TinyIPFIX packets are always transported via a network 766 protocol, which specifies the source of the packet, the "Observation 767 Domain" can be equated with the source of a TinyIPFIX packet. 768 Therefore this IPFIX field has been removed from the TinyIPFIX 769 Header. Should an application require explicit Observation Domain 770 information, each Data Record in the TinyIPFIX data message may 771 contain an Observation Domain ID Information Element; see Section 3.1 772 of [RFC7011]. The version field has been removed since the SetID 773 lookup field provides room for future extensions. The specification 774 of a 32 bit time stamp in seconds would require the time 775 synchronization across a wireless sensor network and produces too 776 much overhead. Thus, the "Export Time" field has been removed. If 777 applications should require a concrete observation time (e.g., 778 timestamp) it is RECOMMENDED to include it as a separate Information 779 Element in the TinyIPFIX Records. 781 6.2. TinyIPFIX Set 783 A TinyIPFIX Set is a set of TinyIPFIX Template or TinyIPFIX Data 784 Records. Depending on the TinyIPFIX Record type, the TinyIPFIX Set 785 can either be a TinyIPFIX Template Set or a TinyIPFIX Data Set. Every 786 TinyIPFIX Set starts with a TinyIPFIX Set Header and is followed by 787 one or more TinyIPFIX Records. 789 The IPFIX Set Header consists of a two octet "Set ID" field and a two 790 octet "Length" field. These two fields are compressed to one octet 791 each for the TinyIPFIX Set Header. The format of the TinyIPFIX Set 792 Header is shown in Figure 11. 794 0 1 795 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Tiny Set ID | Length | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 Figure 11: TinyIPFIX Set Header 802 The two fields are defined as follows: 804 TinyIPFIX Set ID 806 The "Tiny Set ID" identifies the type of data that is transported 807 in the TinyIPFIX Set. A TinyIPFIX Template Set is identified by 808 TinyIPFIX Set ID 2. This corresponds to the Template Set IDs that 809 is used by IPFIX [[RFC7011]]. TinyIPFIX Set ID number 3 MUST NOT 810 be used, as Options Templates are not supported; a TinyIPFIX 811 Collector MUST ignore and SHOULD log any Set with Set ID 3. All 812 values from 4 to 127 are reserved for future use. Values above 813 127 are used for TinyIPFIX Data Sets. 815 Length 817 The "Length" Field contains the total length of the TinyIPFIX Set, 818 including the TinyIPFIX Set Header. 820 6.3. TinyIPFIX Template Record Format 822 The format of the TinyIPFIX Template Records is shown in Figure 12. 823 The TinyIPFIX Template Record starts with a TinyIPFIX Template Record 824 Header and is followed by one or more Field Specifiers. The Field 825 Specifier format is defined as in Section 6.4 and is identical to the 826 Field Specifier definition in [RFC7011]. 828 +--------------------------------------------------+ 829 | TinyIPFIX Template Record Header | 830 +--------------------------------------------------+ 831 | Field Specifier | 832 +--------------------------------------------------+ 833 | Field Specifier | 834 +--------------------------------------------------+ 835 ... 836 +--------------------------------------------------+ 837 | Field Specifier | 838 +--------------------------------------------------+ 840 Figure 12: TinyIPFIX Template Format 842 The format of the TinyIPFIX Template Record Header is shown in 843 Figure 13. 845 0 1 846 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Template ID | Field Count | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 Figure 13: TinyIPFIX Template Record Header 853 TinyIPFIX Template ID 854 Each TinyIPFIX Template Record must have a unique TinyIPFIX 855 Template ID (Comp. Temp ID) between 128 and 255. The TinyIPFIX 856 Template ID must be unique for the given TinyIPFIX Transport 857 Session. 859 Field Count 861 The number of fields placed in the TinyIPFIX Template Record. 863 6.4. Field Specifier Format 865 The type and length of the transmitted data is encoded in Field 866 Specifiers within TinyIPFIX Template Records. The Field Specifier is 867 shown in Figure 14 and is identical with the Field Specifier that was 868 defined for IPFIX [RFC7011]. 870 0 1 2 3 871 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 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 |E| Information Element ident. | Field Length | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Enterprise Number | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 Figure 14: TinyIPFIX Data Field Specifier 880 Where: 882 E 884 Enterprise bit. This is the first bit of the Field Specifier. If 885 this bit is zero, the Information Element Identifier identifies an 886 IETF-specified Information Element, and the four-octet Enterprise 887 Number field MUST NOT be present. If this bit is one, the 888 Information Element Identifier identifies an enterprise-specific 889 Information Element, and the Enterprise Number field MUST be 890 present. 892 Information Element Identifier 894 A numeric value that represents the type of Information Element. 896 Field Length 898 The length of the corresponding encoded Information Element, in 899 octets. Refer to [RFC7012]. The value 65535 is illegal in 900 TinyIPFIX, as variable-length Information Elements are not 901 supported. 903 Enterprise Number 905 IANA Private Enterprise Number of the authority defining the 906 Information Element identifier in this Template Record. 908 Vendors can easily define their own data model by registering a 909 Enterprise ID with IANA. Using their own Enterprise ID, they can use 910 any ID in the way they want them to use. 912 6.5. TinyIPFIX Data Record Format 914 The Data Records are sent in TinyIPFIX Data Sets. The format of the 915 Data Records is shown in Figure 15 and matches the Data Record format 916 from IPFIX. 918 +--------------------------------------------------+ 919 | Field Value | 920 +--------------------------------------------------+ 921 | Field Value | 922 +--------------------------------------------------+ 923 ... 924 +--------------------------------------------------+ 925 | Field Value | 926 +--------------------------------------------------+ 928 Figure 15: Data Record Format 930 7. TinyIPFIX Mediation 932 There are two types of TinyIPFIX Intermediate Processes. The first 933 one can occur on the transition between a constrained network (e.g., 934 6LoWPAN) and the non-constrained network. This mediation changes the 935 network and transport protocol from 6LoWPAN preferring UDP to 936 IP/(SCTP|TCP|UDP) and is shown in Figure 16. 938 +-----------------------+ 939 | TinyIPFIX Device | 940 | [Exporting Process] | 941 +-----------------------+ 942 | 943 TinyIPFIX | 944 over 6LoWPAN/UDP | 945 v 946 +-------------------------+ 947 | TinyIPFIX mediator | 948 | [Collecting Process] | 949 | [Exporting Process] | 950 +-------------------------+ 951 | 952 TinyIPFIX | 953 IP/(UDP/SCTP|TCP) | 954 v 955 +--------------------------+ 956 | Collector | 957 | [Collecting Process(es)] | 958 +--------------------------+ 960 Figure 16: Translation from TinyIPFIX over 6LoWPAN/UDP to TinyIPFIX 961 over IP/(SCTP|TCP|UDP) 963 The mediator removes the TinyIPFIX Messages from the 6LoWPAN/UDP 964 packets and wraps them into the new network and transport protocols. 965 Templates MUST be managed the same way as in the constrained 966 environment after the translation to IP/(SCTP|UDP|TCP) (see 967 Section 8). 969 The second type of mediation transforms TinyIPFIX into IPFIX. This 970 process MUST be combined with the transport protocol mediation as 971 shown in Figure 17. 973 +-----------------------+ 974 | TinyIPFIX Device | 975 | [Exporting Process] | 976 +-----------------------+ 977 | 978 TinyIPFIX | 979 | 980 v 981 +-------------------------+ 982 | TinyIPFIX mediator | 983 | [Collecting Process] | 984 | [Exporting Process] | 985 +-------------------------+ 986 | 987 IPFIX | 988 IP/(UDP/SCTP|TCP) | 989 v 990 +--------------------------+ 991 | Collector | 992 | [Collecting Process(es)] | 993 +--------------------------+ 995 Figure 17: Transformation from TinyIPFIX to IPFIX 997 This mediation can also be performed by an IPFIX Collector before 998 parsing the IPFIX message as shown in Figure 18. There is no need 999 for a parser from TinyIPFIX to IPFIX if such a mediation process can 1000 be employed in front of an existing IPFIX collector. 1002 +------------------------+ +----------------------+ 1003 | TinyIPFIX Device | TinyIPFIX | IPFIX Mediator | 1004 | [Exporting Processes] |----------------->| [Collecting Process] | 1005 +------------------------+ | [Exporting Process] | 1006 | | | 1007 | |IPFIX | 1008 | | | 1009 | v | 1010 | Collector | 1011 | [Collecting Process] | 1012 +----------------------+ 1014 Figure 18: Transformation from TinyIPFIX to IPFIX 1016 The TinyIPFIX Mediation Process has to translate the TinyIPFIX 1017 Message Header, the TinyIPFIX Set Headers and the TinyIPFIX Template 1018 Record Header into their counterparts in IPFIX. Afterwards, the new 1019 IPFIX Message Length needs to be calculated and inserted into the 1020 IPFIX Message header. 1022 7.1. Expanding the Message header 1024 The fields of the IPFIX Message Header that are shown in Figure 5 can 1025 be determined from a TinyIPFIX Message Header as follows: 1027 Version 1029 This is always 0x000a. 1031 Length 1033 The IPFIX Message Length can only be calculated after the complete 1034 TinyIPFIX Message has been translated. The new length can be 1035 calculated by adding the length of the IPFIX Message Header, which 1036 is 16 octets, and the length of all Sets that are contained in the 1037 IPFIX Message. 1039 Export Time 1041 The "Export Time" MUST be generated by the Mediator, and contains 1042 the time in seconds since 00:00 UTC Jan 1, 1970, at which the 1043 IPFIX Message leaves the Mediator. 1045 Sequence Number 1047 If the TinyIPFIX Sequence Number has a length of 4 octets, the 1048 original value MUST be used for the IPFIX Message. If the 1049 TinyIPFIX Sequence Number has a size of one or two octets, the 1050 TinyIPFIX Mediator MUST expand the TinyIPFIX Sequence Number into 1051 a four octet field. If the TinyIPFIX Sequence Number was omitted, 1052 the Mediator needs to calculate the Sequence Number as per 1053 [RFC7011]. 1055 Observation Domain ID 1057 Since the Observation Domain ID is used to scope templates in 1058 IPFIX, it MUST be set to a unique value per TinyIPFIX Exporting 1059 Process, using either a mapping algorithmically determined by the 1060 Intermediate Process or directly configured by an administrator. 1062 7.2. Translating the Set Headers 1064 Both fields in the TinyIPFIX Set Header have a size of one octet and 1065 need to be expanded: 1067 Set ID 1069 The field needs to be expanded from one octet to two octets. If 1070 the Set ID is below 128, no recalculation needs to be performed. 1071 This is because all IDs below 128 are reserved for special 1072 messages and match the IDs used in IPFIX. The TinyIPFIX Set IDs 1073 starting with 128 identify TinyIPFIX Data Sets. Therefore, every 1074 TinyIPFIX Set ID above number 127 needs to be incremented by 1075 number 128 because IPFIX Data Set IDs are numbered above 255. 1077 Set Length 1079 The field needs to be expanded from one octet to two octets. It 1080 needs to be recalculated by adding a value of 2 octets to match 1081 the additional size of the Set Header. For each TinyIPFIX 1082 Template Record that is contained in the TinyIPFIX Set, 2 more 1083 octets need to be added to the length. 1085 7.3. Expanding the Template Record Header 1087 Both fields in the TinyIPFIX Template Record Header have a length of 1088 one octet and therefore need translation: 1090 Template ID 1092 The field needs to be expanded from one octet to two octets. The 1093 Template ID needs to be increased by a value of 128. 1095 Field Count 1097 The field needs to be expanded from one octet to two octets. 1099 8. Template Management 1101 As with IPFIX, TinyIPFIX templates management depends on the 1102 transport protocol used. If TCP or SCTP is used, it can be ensured 1103 that TinyIPFIX Templates are delivered reliably. If UDP is used, 1104 reliability cannot be guaranteed, and template loss can occur. If a 1105 Template is lost on its way to the Collector, all the following 1106 TinyIPFIX Data Records that refer to this TinyIPFIX Template cannot 1107 be decoded. Template withdrawals are not supported in TinyIPFIX. 1108 This is generally not a problem, because most sensor nodes only 1109 define a single static template directly after booting. 1111 8.1. TCP / SCTP 1113 If TCP or SCTP is used for the transmission of TinyIPFIX, Template 1114 Management MUST be performed as defined in [RFC7011] for IPFIX, with 1115 the exception of template withdrawals, which are not supported in 1116 TinyIPFIX. Template withdrawals MUST NOT be sent by TinyIPFIX 1117 Exporters. 1119 8.2. UDP 1121 All specifications for Template management from [RFC7011] apply 1122 unless specified otherwise in this document. 1124 TinyIPFIX Templates MUST be sent by a TinyIPFIX Exporter before any 1125 TinyIPFIX Data Set that refers to the TinyIPFIX Template is 1126 transmitted. TinyIPFIX Templates are not expected to change over 1127 time in TinyIPFIX and, thus, they should be pre-shared. TinyIPFIX 1128 Device have a default setup when deployed and after booting they 1129 announce their TinyIPFIX Template directly to the networkand MAY 1130 repeat it if UDP is used. Hence, a TinyIPFIX Template that has been 1131 sent once MAY NOT be withdrawn and MUST NOT expire. If a TinyIPFIX 1132 Smart Meter wants to use another TinyIPFIX Template it MUST use a new 1133 TinyIPFIX Template ID for the TinyIPFIX Template. 1135 As UDP is used, reliable transport of TinyIPFIX Templates cannot be 1136 guaranteed and TinyIPFIX Templates can be lost. A TinyIPFIX Exporter 1137 MUST expect TinyIPFIX Template loss. It MUST therefore re-send its 1138 TinyIPFIX Templates periodically. A TinyIPFIX Template MUST be re- 1139 send after a fixed number N of TinyIPFIX Messages that contain 1140 TinyIPFIX Data Sets referring to the TinyIPFIX Template. The number 1141 N MUST be configured by the application developer. Retransmission 1142 and the specification of N can be avoided if TinyIPFIX Exporter and 1143 TinyIPFIX Collector use pre-shared templates. 1145 9. Security considerations 1147 The same security considerations as for the IPFIX Protocol [RFC7011] 1148 apply. 1150 10. IANA Considerations 1152 This document has no actions for IANA. 1154 11. Acknowledgments 1156 Many thanks to Lothar Braun, Georg Carle, and Benoit Claise, who 1157 contributed significant work to earlier versions especially to the 1158 document entitled "Compressed IPFIX for Smart Meters in Constrained 1159 Networks" (draft-braun-core-compressed-ipfix), of this work. 1161 Many thanks to Thomas Kothmayr, Michael Meister, and Livio Sgier, who 1162 implemented TinyIPFIX for TinyOS 2.x, Contiki 2.7/3.0 (except the 1163 mediator) for different sensor platforms (IRIS, TelosB, and 1164 OpenMote). 1166 12. References 1168 12.1. Normative References 1170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1171 Requirement Levels", BCP 14, RFC 2119, 1172 DOI 10.17487/RFC2119, March 1997, 1173 . 1175 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1176 "Transmission of IPv6 Packets over IEEE 802.15.4 1177 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1178 . 1180 [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. 1181 Aitken, "IP Flow Information Export (IPFIX) Implementation 1182 Guidelines", RFC 5153, DOI 10.17487/RFC5153, April 2008, 1183 . 1185 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 1186 "Architecture for IP Flow Information Export", RFC 5470, 1187 DOI 10.17487/RFC5470, March 2009, 1188 . 1190 [RFC5982] Kobayashi, A., Ed. and B. Claise, Ed., "IP Flow 1191 Information Export (IPFIX) Mediation: Problem Statement", 1192 RFC 5982, DOI 10.17487/RFC5982, August 2010, 1193 . 1195 [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, 1196 "IP Flow Information Export (IPFIX) Mediation: Framework", 1197 RFC 6183, DOI 10.17487/RFC6183, April 2011, 1198 . 1200 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 1201 "Specification of the IP Flow Information Export (IPFIX) 1202 Protocol for the Exchange of Flow Information", STD 77, 1203 RFC 7011, DOI 10.17487/RFC7011, September 2013, 1204 . 1206 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 1207 for IP Flow Information Export (IPFIX)", RFC 7012, 1208 DOI 10.17487/RFC7012, September 2013, 1209 . 1211 12.2. Informative References 1213 [Advantic] 1214 Advantic Sistemas y Servicios, 1215 "https://www.advanticsys.com/", 2017. 1217 [Crossbow] 1218 Crossbow Technologies Inc., "http://www.xbow.com", 2010. 1220 [GreatDuck] 1221 Habitat Monitoring on Great Duck Island, 1222 "http://www.greatduckisland.net", The Proceedings of the 1223 Second ACM Conference on Embedded Networked Sensor Systems 1224 (SenSys 04) , November 2004. 1226 [Harvan08] 1227 Harvan, M. and J. Schoenwaelder, "TinyOS Motes on the 1228 Internet: IPv6 over 802.15.4 (6LoWPAN)", 2008. 1230 [Kim07] Kim, S., Pakzad, S., Culler, D., Demmel, J., Fenves, G., 1231 Glaser, S., and M. Turon, "Health Monitoring of Civil 1232 Infrastructure Using Wireless Sensor Networks", In the 1233 Proceedings of the 6th International Conference on 1234 Information Processing in Sensor Networks (IPSN 2007), 1235 Cambridge, MA, ACM Press, pp. 254-263 , April 2007. 1237 [kothmayr10] 1238 Kothmayr, T., "Data Collection in Wireless Sensor Networks 1239 for Autonomic Home Networking", Bachelor Thesis, Technical 1240 University of Munich, Germany , 2010. 1242 [Schmitt09] 1243 Schmitt, C. and G. Carle, "Applications for Wireless 1244 Sensor Networks", In Handbook of Research on P2P and Grid 1245 Systems for Service-Oriented Computing: Models, 1246 Methodologies and Applications, Antonopoulos N.; 1247 Exarchakos G.; Li M.; Liotta A. (Eds.), Information 1248 Science Publishing. , 2010. 1250 [schmitt2014] 1251 Schmitt, C., Kothmayr, T., Ertl, B., Hu, W., Braun, L., 1252 and G. Carle, "TinyIPFIX: An Efficient Application 1253 Protocol for Data Exchange in Cyber Physical Systems", 1254 Computer Communications, ELSEVIER, DOI: 10.1016/ 1255 j.comcom.2014.05.012 , 2014. 1257 [schmitt2017] 1258 Schmitt, C., Anliker, C., and B. Stiller, "Efficient and 1259 Secure Pull Requests for Emergency Cases Using a Mobile 1260 Access Framework", Managing the Web of Things: Linking the 1261 Real World to the Web, M.Sheng, Y. Qin, L. Yao, and B. 1262 Benatallah (Eds.), Morgen Kaufmann (imprint of Elsevier), 1263 Chapter 8, pp. 229-247, ISBN: 978-0-12-809764-9 , 2017. 1265 [SMPC04] Szewczyk, R., Mainwaring, A., Polastre, J., and D. Culler, 1266 "An analysis of a large scale habitat monitoring 1267 application", The Proceedings of the Second ACM Conference 1268 on Embedded Networked Sensor Systems (SenSys 04) , 1269 November 2004. 1271 [Tolle05] Tolle, G., Polastre, J., Szewczyk, R., Turner, N., Tu, K., 1272 Buonadonna, P., Burgess, S., Gay, D., Hong, W., Dawnson, 1273 T., and D. Culler, "A macroscope in the redwoods", In the 1274 Proceedings of the 3rd ACM Conference on Embedded 1275 Networked Sensor Systems (Sensys 05), San Diego, ACM 1276 Press , November 2005. 1278 Authors' Addresses 1280 Corinna Schmitt 1281 University of Zurich 1282 Department of Informatics 1283 Communication Systems Group 1284 Binzmuehlestrasse 14 1285 Zurich 8050 1286 Switzerland 1288 Email: schmitt@ifi.uzh.ch 1289 Burkhard Stiller 1290 University of Zurich 1291 Department of Informatics 1292 Communication Systems Group 1293 Binzmuehlestrasse 14 1294 Zurich 8050 1295 Switzerland 1297 Email: stiller@ifi.uzh.ch 1299 Brian Trammell 1300 Swiss Federal Institute of Technology 1301 Gloriastrasse 35 1302 Zurich 8092 1303 Switzerland 1305 Email: ietf@trammell.ch