idnits 2.17.1 draft-schmitt-ipfix-tiny-02.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 (May 31, 2017) is 2516 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: December 2, 2017 B. Trammell 6 ETH Zurich 7 May 31, 2017 9 TinyIPFIX for smart meters in constrained networks 10 draft-schmitt-ipfix-tiny-02 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 December 2, 2017. 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 . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 27 81 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 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. As defined [RFC4944], IEEE 309 802.15.4 starts from a maximum physical layer packet size of 127 310 octets (aMaxPHYPacketSize) and a maximum frame overhead of 25 octets 311 (aMaxFrameOverhead), leaving a maximum frame size of 102 octets at 312 the media access control (MAC) layer. IPv6 on the other hand defines 313 a minimum MTU of 1280 octets. Hence, fragmentation has to be 314 implemented in order to transmit such large packets. While 315 fragmentation allows the transmission of large messages, its use is 316 problematic in networks with high packet loss because the complete 317 message has to be discarded if only a single fragment gets lost. 319 TinyIPFIX enhances IPFIX by a header compression scheme, which allows 320 the header size overhead to be significantly reduced. Additionally, 321 the overall TinyIPFIX Message size is reduced, which reduces the need 322 for fragmentation. 324 3.4. Transport protocol constraints 326 The IPFIX standard [RFC7011] defines several transport protocol 327 bindings for the transmission of IPFIX Messages. SCTP support is 328 REQUIRED for any IPFIX Device to achieve standard conformance 329 [RFC7011], and its use is highly recommended. However, sending IPFIX 330 over UDP and TCP MAY also be implemented. 332 This transport protocol recommendation is not suitable for TinyIPFIX. 333 A header compression scheme that allows a compression of an IPv6 334 header from 40 octets down to 2 octets is defined in 6LoWPAN. There 335 is a similar compression scheme for UDP, but there is no such 336 compression for TCP or SCTP headers. If header compression can be 337 employed, more space for application payload is available. 339 Using UDP on the transport layer for transmitting IPFIX Messages is 340 therefore recommended. Furthermore, TCP or SCTP are currently not 341 supported on some platforms, like on TinyOS [Harvan08]. Hence, UDP 342 may be the only option. 344 Every TinyIPFIX Exporter and Collector MUST implement UDP transport 345 layer support for transmitting data in a constrained network 346 environment. It MAY also offer TCP or SCTP support. In case TCP or 347 SCTP MAY be used power consumption will grow and the available size 348 of application payload compared to the use of UDP May be reduced. If 349 TinyIPFIX is transmitted over a non-constrained network, using SCTP 350 as a transport layer protocol is RECOMMENDED. TinyIPFIX works 351 independent of the target environment, because it MUST only be 352 ensured that all intermediate devices can understand TinyIPFIX and be 353 able to extract needed packet information (e.g., IP destination 354 address). TinyIPFIX messages can be included n other transport 355 protocols in the payload whenever is needed making TinyIPFIX highly 356 flexible and usable for different communication protocols (e.g., 357 COAP, UDP, TCP). TinyIPFIX itself just specifies a messages format 358 for the collected data to be transmitted. 360 4. Application scenarios for TinyIPFIX 362 TinyIPFIX is derived from IPFIX [RFC7011] and is therefore a 363 unidirectional push protocol assuming UDP usage. This means all 364 communication that employs TinyIPFIX is unidirectional from an 365 Exporting Process to a Collecting Process. Hence, TinyIPFIX only 366 fits for application scenarios where meters transmit data to one or 367 more Collectors. In case pull request SHOULD also be supported by 368 TinyIPFIX it is RECOMMENDED not to change the code of TinyIPFIX much 369 to get along with the restricted memory available [schmitt2017]. 370 Meaning including just a one bit field, called type, to distinguish 371 between push and pull messages would be feasable, but the filtering 372 SHOULD be done by the gateway and not by the constrained device, 373 meaning if a pull is performed the constained device is triggered to 374 create a TinyIPFIX message immediately as usual, set the type field 375 to one instead of zero (for a push message), and sends message to the 376 gateway. Where at the gateway the filtering is performed based on 377 the pull request. 379 If TinyIPFIX is used over UDP, as recommended, packet loss can occur. 380 Furthermore, if an initial Template Message gets lost, and is 381 therefore unknown to the Collector, all TinyIPFIX Data Sets that 382 reference this Template cannot be decoded. Hence, all these Messages 383 are lost if they are not cached by the Collector. It should be clear 384 to an application developer, that TinyIPFIX can only be used over UDP 385 if these TinyIPFIX Message losses are not a problem. Avoiding this 386 loss it is RECOMMEND to repeat the Template Message periodically 387 having in mind that a Template never changes for a constrained device 388 after deployment. Even when Template Messages becomes lost in the 389 network the data can be manually translated later when the Template 390 Messages is resend. Including an acknowledgement mechanism is NOT 391 RECOMMENDED due to overhead, because this would require storage of 392 any send data on the constrained devices until it is acknowledged. 393 In critial applications it is RECOMMENDED to repeat the Template 394 Message more often. 396 TinyIPFIX over UDP is especially not a suitable protocol for 397 applications where sensor data trigger policy decisions or 398 configuration updates for which packet loss is not tolerable. 400 Applications that use smart sensors for accounting purposes for long 401 time measurements can benefit from the use of TinyIPFIX. One 402 application for IPFIX is long term monitoring of large physical 403 volumes. In [Tolle05], Tolle et al. built a system for monitoring a 404 "70-meter tall redwood tree, at a density interval of 5 minutes in 405 time and 2 meters in space". The sensor node infrastructure was 406 deployed to measure the air temperature, relative humidity and 407 photosynthetically active solar radiation over a long time period. 409 TinyIPFIX is a good fit for such scenarios. The sensors of the 410 TinyIPFIX Smart Meter can be queried over several 5 minute time 411 intervals and the query results can be accumulated into a single 412 TinyIPFIX Message. As soon as enough query results are stored in the 413 TinyIPFIX Message, e.g. if the TinyIPFIX Message size fills the 414 available payload in a single IEEE 802.15.4 packet, the wireless 415 transceiver can be activated and the TinyIPFIX Message can be 416 exported to a TinyIPFIX Collector. 418 Similar sensor networks have been built to monitor the habitat of 419 animals, e.g. in the "Great Duck Island Project" [GreatDuck], 420 [SMPC04]. The purpose of the sensor network was to monitor the birds 421 by deploying sensors in and around their burrows. The measured 422 sensor data was collected and stored in a database for offline 423 analysis and visualization. Again, the sensors can perform their 424 measurements periodically, accumulate the sensor data and export them 425 to a TinyIPFIX Collector. 427 Other application scenarios for TinyIPFIX could be applications where 428 sensor networks are used for long term structural health monitoring 429 in order to investigate long term weather conditions on the structure 430 of a building. For example, a smart metering network has been built 431 to monitor the structural health of the Golden Gate Bridge [Kim07]. 433 If a sensor network is deployed to perform a long term measurement of 434 the structural integrity, TinyIPFIX can be used to collect the sensor 435 measurement data. 437 If an application developer wants to decide whether to use TinyIPFIX 438 for transmitting data from smart meters, he must take the following 439 considerations into account: 441 1. The application should require a push protocol per default. The 442 timing intervals when to push data should be pre-defind before 443 deployment. 445 2. The property above allows a TinyIPFIX Smart Meter to turn off its 446 wireless device in order to save energy, as it does not have to 447 receive any data. 449 3. If real-time reporting is not required, the application might 450 benefit from accumulate several measurements into a single 451 TinyIPFIX Message, causing delay but lowering traffic in the 452 network. TinyIPFIX easily allows the accumulation of several 453 measurements into a single TinyIPFIX Message (or a single 454 packet). This accumulation can happen on the TinyIPFIX Smart 455 Meter that accumulates several of its own measurements. Or it 456 can happen within a multi-hop wireless network where one IPFIX 457 Proxy accumulates several TinyIPFIX Messages into a single 458 TinyIPFIX Message before forwarding them. 460 4. The application must accept potential packet loss. TinyIPFIX 461 only fits for applications where metering data is stored for 462 accounting purposes and not for applications where the sensor 463 data triggers configuration changes or policy decisions (except: 464 if Message loss is acceptable for some reason). 466 5. Architecture for TinyIPFIX 468 The TinyIPFIX architecture is similar to the IPFIX architecture, 469 which is described in [RFC5470]. The most common deployment of 470 TinyIPFIX Smart Meters is shown in Figure 1 where each TinyIPFIX 471 Smart Meter can have different sensors available (e.g., IRIS: 472 Temperature, Humidity, Sound; TelosB: Temperature, Bridgeness, 473 Humidity, GPS) building the sensor data. 475 +------------------------+ +------------------------+ 476 | TinyIPFIX Device | ... | TinyIPFIX Device | 477 | [Exporting Process] | | [Exporting Process] | 478 +------------------------+ +------------------------+ 479 | | 480 TinyIPFIX | | TinyIPFIX 481 | | 482 v v 483 +----------------------------------+ 484 | 485 v 486 +----------------------------+ 487 | TinyIPFIX Collector | 488 | [Collecting Process(es)] | 489 +----------------------------+ 490 | 491 v 492 +-----------------------+ 493 | | 494 v v 495 +----------------+ +----------------+ 496 |[*Application 1]| ... |[*Application n]| 497 +----------------+ +----------------+ 499 Figure 1: Direct transmission between TinyIPFIX Devices and 500 applications 502 A TinyIPFIX Smart Meter (S.M.) queries its internal sensors to 503 retrieve the sensor data to create its TinyIPFIX messages. It then 504 encodes the results into a TinyIPFIX Message usinf a TinyIPFIX 505 Exporting Process and exports this TinyIPFIX Message to one or more 506 TinyIPFIX Collectors. The TinyIPFIX Collector runs one or more 507 applications that process the collected sensor data. The TinyIPFIX 508 Collector can be deployed on non-constrained devices at the 509 constrained network border. 511 A second way to deploy TinyIPFIX Smart Meter can employ accumulation 512 on TinyIPFIX Messages during their journey through the constrained 513 network as shown in Figure 2. This accumulation can be performed by 514 TinyIPFIX Concentrators. Such devices must have enough resources to 515 perform the accumulation. 517 +------------------------+ +------------------------+ 518 | TinyIPFIX Device | ... | TinyIPFIX Device | 519 | [Exporting Process] | | [Exporting Process] | 520 +------------------------+ +------------------------+ 521 | | 522 TinyIPFIX | | TinyIPFIX 523 | | 524 v v 525 +----------------------------------+ 526 | 527 v 528 +------------------------+ 529 | TinyIPFIX Concentrator | 530 | [Collecting Process] | 531 | [Exporting Process] | 532 +------------------------+ 533 | 534 TinyIPFIX | 535 | 536 v 537 +--------------------------+ 538 | Collector | 539 | [Collecting Process(es)] | 540 +--------------------------+ 542 Figure 2: Accumulation of TinyIPFIX 544 TinyIPFIX Smart Meters send their data to TinyIPFIX Concentrator, 545 which needs to have enough storage space to store the incoming data. 546 If the TinyIPFIX Concentrator is hosted in a TinyIPFIX Smart Meter it 547 MAY be also able to collect data from it sensors, if activated, it 548 may also accumulate the incoming data with its own measurement data. 549 The accumulated data can then be re-exported again to one or more 550 Collectors. In that case the TinyIPFIX Concentrator can be viewed as 551 receiving data from multiple Smart Meters - one locally and some 552 remotely. 554 The last deployment, shown in Figure 3, employs another TinyIPFIX 555 Mediation process. 557 +-------------------------+ +-------------------------+ 558 | Remote Smart Meter | | Local Smart Meter | 559 +-------------------------+ +-------------------------+ 560 | TinyIPFIX Device | | TinyIPFIX Device | 561 | [Exporting Process] | | [Exporting Process] | 562 +-------------------------+ +-------------------------+ 563 | | 564 TinyIPFIX | | TinyIPFIX 565 | | 566 v v 567 +-------------------------+ 568 | TinyIPFIX Concentrator | 569 | [Collecting Process] | 570 +-------------------------+ 572 Figure 3: TinyIPFIX Mediator 574 In this deployment, the TinyIPFIX Smart Meters transmit their 575 TinyIPFIX Messages to one node, e.g. the base station, which 576 translates the TinyIPFIX Messages to IPFIX Messages. The IPFIX 577 Messages can then be exported into an existing IPFIX infrastructure. 578 The Mediation process from TinyIPFIX to IPFIX is described in 579 Section 7. 581 6. TinyIPFIX Message Format 583 A TinyIPFIX IFPIX Message starts with a TinyIPFIX Message Header, 584 followed by one or more TinyIPFIX Sets. The TinyIPFIX Sets can be 585 either of type TinyIPFIX Template Set or of type TinyIPFIX Data Set. 586 A TinyIPFIX Message MUST only contain one type of TinyIPFIX Set. The 587 format of the TinyIPFIX Message is shown in Figure 4. 589 +----------------------------------------------------+ 590 | TinyIPFIX Message Header | 591 +----------------------------------------------------+ 592 | TinyIPFIX Set | 593 +----------------------------------------------------+ 594 | TinyIPFIX Set | 595 +----------------------------------------------------+ 596 ... 597 +----------------------------------------------------+ 598 | TinyIPFIX Set | 599 +----------------------------------------------------+ 601 Figure 4: TinyIPFIX Message Format 603 6.1. TinyIPFIX Message Header 605 The TinyIPFIX Message Header is derived from the IPFIX Message 606 Header, with some optimization using field compression. The IPFIX 607 Message Header from [RFC7011] is shown in Figure 5. 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Version Number | Length | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Export Time | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Sequence Number | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Observation ID | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 Figure 5: IPFIX Message Header 623 The length of the IPFIX Message Header is 16 octets and every IPFIX 624 Message has to be started with it. The TinyIPFIX Message Header 625 needs to be smaller due to the packet size constraints discussed in 626 Section 3.3. The TinyIPFIX Header consists of a fixed part of three 627 octets as shown in Figure 6, followed by a variable part as shown in 628 Figure 7 to Figure 10. 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 |E|E| SetID | Length | Sequence | Ext. Sequenz | 634 |1|2|Lookup | | Number | Number | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Ext. SetID | 637 +-+-+-+-+-+-+-+-+ 639 Figure 6: Format of the TinyIPFIX Message Header including fixed and 640 optional parts 642 The fixed part has a length of three octets and consists of the "E1" 643 field (1 bit), the "E2" field (1 bit), the "SetID Lookup" field (4 644 bits), the "Length" field (10 bits), and the "Sequence Number" field 645 (8 bits). The variable part has a variable length defined by the 646 "E1" and "E2" fields in the fixed header. The four variants are 647 illustrated in Figure 7 to Figure 10 below. 649 0 1 2 650 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 |0|0| SetID | Length | Sequence | 653 | | |Lookup | | Number | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Figure 7: TinyIPFIX Message Header format if E1 = E2 = 0 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 |1|0| SetID | Length | Sequence | Ext. SetID | 662 | | |Lookup | | Number | | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 Figure 8: TinyIPFIX Message Header format if E1 = 1 and E2 = 0 667 0 1 2 3 668 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 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 |E|E| SetID | Length | Sequence | Ext. Sequenz | 671 |1|2|Lookup | | Number | Number | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Figure 9: TinyIPFIX Message Header format if E1 = 0 and E2 = 1 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 |1|1| SetID | Length | Sequence | Ext. Sequenz | 680 | | |Lookup | | Number | Number | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Ext. SetID | 683 +-+-+-+-+-+-+-+-+ 685 Figure 10: TinyIPFIX Message Header format if E1 = E2 = 1 687 The fixed header fields are defined as follows [kothmayr10] 688 [schmitt2014]: 690 E1 and E2 692 The bits marked "E1" and "E2" control the presence of the field 693 "Ext. SetID" and the presence of the field "Ext. Sequence 694 Number" respectively. 696 In case E1 = E2 = 0 the TinyIPFIX message header has the format 697 shown in Figure 7. The fields Extended Sequence Number and 698 Extended SetID MUST NOT be present. 700 When E1 = 1, the extended SetID field MUST be present. Custom 701 SetIDs can be specified in the extended SetID field setting all 702 SetID Lookup bits to 1 (cf. Figure 8.) When evaluated, the value 703 specified in the extended SetID field is shifted left by 8 bits to 704 prevent collisions with the reserved SetIDs 0-255. To reference 705 these, shifting can be disabled by setting all SetID lookup bits 706 to 1. 708 Depending on the application sampling rates might be larger than 709 in typical constraind networks (e.g., Wireless Sensor Networks 710 (WSN), Cyper-Physical-Systems (CPS)) and, thus, they may have a 711 large quantity of records per packet. In order to make TinyIPFIX 712 applicable for those cases E2 = 1 is set (cf. Figure 9). This 713 means the Extended Sequence Number field MUST be present offering 714 8-bit more sequence numbers as usual. Depending on the 715 constrained network settings also the combination E1 = E2 = 1 is 716 possible resulting in the maximum TinyIPFIX Message header shown 717 in Figure 10 where Extended Sequence Number field and Extended 718 SetID field MUST both be present. 720 SetID Lookup 722 This field acts as a lookup field for the SetIDs and provides 723 shortcuts to often used SetIDs. Four values are defined: 725 Value = 0 means Lookup extended SetID field, Shifting enabled. 727 Value = 1 means SetID = 2 and message contains a Template 728 definition. 730 Value = 2 means SetID = 256 and message containts Data Record for 731 Template 256. This places special importance on a single template 732 ID, but since most sensor nodes only define a single template 733 directly after booting and continue to stream data with this 734 template ID during the whole session lifetime, this shorthand is 735 useful for this case. 737 Value = 3-14 means SetIDs are reserved for future extensions. 739 Value = 15 means lookup extended SetID field, shifting enabled. 741 Length 743 The length field has a fixed length of 10 bits. 745 Sequence Number 747 Due to the low sampling rate in typical WSNs, the "Sequence 748 Number" field is only one byte long. However, some applications 749 may have a large quantity of records per packet. In this case the 750 sequence field can be extended to 16 bit by setting the E2-bit to 751 1. 753 Since TinyIPFIX packets are always transported via a network 754 protocol, which specifies the source of the packet, the "Observation 755 Domain" can be equated with the source of a TinyIPFIX packet. 756 Therefore this IPFIX field has been removed from the TinyIPFIX 757 Header. Should applications require several Observation Domains the 758 information can be included in the TinyIPFIX data message. The 759 version field has been removed since the SetID lookup field provides 760 room for future extensions. The specification of a 32 bit time stamp 761 in seconds would require the time synchronization across a wireless 762 sensor network and produces too much overhead. Thus, the "Export 763 Time" field has been removed. If applications should require a 764 concret observation time (e.g., timestamp) it is RECOMMENDED to 765 include it as a separat field in the TinyIPFIX Records. 767 6.2. TinyIPFIX Set 769 A TinyIPFIX Set is a set of TinyIPFIX Template or TinyIPFIX Data 770 Records. Depending on the TinyIPFIX Record type, the TinyIPFIX Set 771 can either be a TinyIPFIX Template Set or a TinyIPFIX Data Set. 772 Every TinyIPFIX Set starts with a TinyIPFIX Set Header and is 773 followed by one or more TinyIPFIX Records. 775 The IPFIX Set Header consists of an two octet "Set ID" field and a 776 two octet "Length" field. These two fields are compressed to one 777 octet each for the TinyIPFIX Set Header. The format of the TinyIPFIX 778 Set Header is shown in Figure 11. 780 0 1 781 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Tiny Set ID | Length | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Figure 11: TinyIPFIX Set Header 788 The two fields are defined as follows: 790 TinyIPFIX Set ID 792 The "Tiny Set ID" identifies the type of data that is transported 793 in the TinyIPFIX Set. A TinyIPFIX Template Set is identified by 794 TinyIPFIX Set ID 2. This corresponds to the Template Set IDs that 795 is used by IPFIX [[RFC7011]]. TinyIPFIX Set ID number 3 MUST NOT 796 be used. All values from 4 to 127 are reserved for future use. 797 Values above 127 are used for TinyIPFIX Data Sets. 799 Length 800 The "Length" Field contains the total length of the TinyIPFIX Set, 801 including the TinyIPFIX Set Header. 803 6.3. TinyIPFIX Template Record Format 805 The format of the TinyIPFIX Template Records is shown in Figure 12. 806 The TinyIPFIX Template Record starts with a TinyIPFIX Template Record 807 Header and is followed by one or more Field Specifiers. The Field 808 Specifier format is defined as in Section 6.4 and is identical to the 809 Field Specifier definition in [RFC7011]. 811 +--------------------------------------------------+ 812 | TinyIPFIX Template Record Header | 813 +--------------------------------------------------+ 814 | Field Specifier | 815 +--------------------------------------------------+ 816 | Field Specifier | 817 +--------------------------------------------------+ 818 ... 819 +--------------------------------------------------+ 820 | Field Specifier | 821 +--------------------------------------------------+ 823 Figure 12: TinyIPFIX Template Format 825 The format of the TinyIPFIX Template Record Header is shown in 826 Figure 13. 828 0 1 829 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Template ID | Field Count | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 Figure 13: TinyIPFIX Template Record Header 836 TinyIPFIX Template ID 838 Each TinyIPFIX Template Record must have a unique TinyIPFIX 839 Template ID (Comp. Temp ID) between 128 and 255. The TinyIPFIX 840 Template ID must be unique for the given TinyIPFIX Transport 841 Session. 843 Field Count 844 The number of fields placed in the TinyIPFIX Template Record. 846 6.4. Field Specifier Format 848 The type and length of the transmitted data is encoded in Field 849 Specifiers within TinyIPFIX Template Records. The Field Specifier is 850 shown in Figure 14 and is identical with the Field Specifier that was 851 defined for IPFIX [RFC7011]. 853 0 1 2 3 854 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 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 |E| Information Element ident. | Field Length | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Enterprise Number | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 Figure 14: TinyIPFIX Data Field Specifier 863 Where: 865 E 867 Enterprise bit. This is the first bit of the Field Specifier. If 868 this bit is zero, the Information Element Identifier identifies an 869 IETF-specified Information Element, and the four-octet Enterprise 870 Number field MUST NOT be present. If this bit is one, the 871 Information Element Identifier identifies an enterprise-specific 872 Information Element, and the Enterprise Number field MUST be 873 present. 875 Information Element Identifier 877 A numeric value that represents the type of Information Element. 879 Field Length 881 The length of the corresponding encoded Information Element, in 882 octets. Refer to [RFC7012]. The value 65535 is illegal in 883 TinyIPFIX. 885 Enterprise Number 887 IANA Private Enterprise Number of the authority defining the 888 Information Element identifier in this Template Record. 890 Vendors can easily define their own data model by registering a 891 Enterprise ID with IANA. Using their own Enterprise ID, they can use 892 any ID in the way they want them to use. 894 6.5. TinyIPFIX Data Record Format 896 The Data Records are sent in TinyIPFIX Data Sets. The format of the 897 Data Records is shown in Figure 15 and matches the Data Record format 898 from IPFIX. 900 +--------------------------------------------------+ 901 | Field Value | 902 +--------------------------------------------------+ 903 | Field Value | 904 +--------------------------------------------------+ 905 ... 906 +--------------------------------------------------+ 907 | Field Value | 908 +--------------------------------------------------+ 910 Figure 15: Data Record Format 912 7. TinyIPFIX Mediation 914 There are two types of TinyIPFIX Intermediate Processes. The first 915 one can occur on the transition between a constrained network (e.g., 916 6LoWPAN) and the non-constrained network. This mediation changes the 917 network and transport protocol from 6LoWPAN preferring UDP to 918 IP/(SCTP|TCP|UDP) and is shown in Figure 16. 920 +-----------------------+ 921 | TinyIPFIX Device | 922 | [Exporting Process] | 923 +-----------------------+ 924 | 925 TinyIPFIX | 926 over 6LoWPAN/UDP | 927 v 928 +-------------------------+ 929 | TinyIPFIX mediator | 930 | [Collecting Process] | 931 | [Exporting Process] | 932 +-------------------------+ 933 | 934 TinyIPFIX | 935 IP/(UDP/SCTP|TCP) | 936 v 937 +--------------------------+ 938 | Collector | 939 | [Collecting Process(es)] | 940 +--------------------------+ 942 Figure 16: Translation from TinyIPFIX over 6LoWPAN/UDP to TinyIPFIX 943 over IP/(SCTP|TCP|UDP) 945 The mediator removes the TinyIPFIX Messages from the 6LoWPAN/UDP 946 packets and wraps them into the new network and transport protocols. 947 Templates MUST be managed the same way as in the constrained 948 environment after the translation to IP/(SCTP|UDP|TCP) (see 949 Section 8). 951 The second type of mediation transforms TinyIPFIX into IPFIX. This 952 process MUST be combined with the transport protocol mediation as 953 shown in Figure 17. 955 +-----------------------+ 956 | TinyIPFIX Device | 957 | [Exporting Process] | 958 +-----------------------+ 959 | 960 TinyIPFIX | 961 | 962 v 963 +-------------------------+ 964 | TinyIPFIX mediator | 965 | [Collecting Process] | 966 | [Exporting Process] | 967 +-------------------------+ 968 | 969 IPFIX | 970 IP/(UDP/SCTP|TCP) | 971 v 972 +--------------------------+ 973 | Collector | 974 | [Collecting Process(es)] | 975 +--------------------------+ 977 Figure 17: Transformation from TinyIPFIX to IPFIX 979 This mediation can also be performed by an IPFIX Collector before 980 parsing the IPFIX message as shown in Figure 18. There is no need 981 for a parser from TinyIPFIX to IPFIX if such a mediation process can 982 be employed in front of an existing IPFIX collector. 984 +------------------------+ +----------------------+ 985 | TinyIPFIX Device | TinyIPFIX | IPFIX Mediator | 986 | [Exporting Processes] |----------------->| [Collecting Process] | 987 +------------------------+ | [Exporting Process] | 988 | | | 989 | |IPFIX | 990 | | | 991 | v | 992 | Collector | 993 | [Collecting Process] | 994 +----------------------+ 996 Figure 18: Transformation from TinyIPFIX to IPFIX 998 The TinyIPFIX Mediation Process has to translate the TinyIPFIX 999 Message Header, the TinyIPFIX Set Headers and the TinyIPFIX Template 1000 Record Header into their counterparts in IPFIX. Afterwards, the new 1001 IPFIX Message Length needs to be calculated and inserted into the 1002 IPFIX Message header. 1004 7.1. Expanding the Message header 1006 The fields of the IPFIX Message Header that are shown in Figure 5 can 1007 be determined from a TinyIPFIX Message Header as follows: 1009 Version 1011 This is always 0x000a. 1013 Length 1015 The IPFIX Message Length can only be calculated after the complete 1016 TinyIPFIX Message has been translated. The new length can be 1017 calculated by adding the length of the IPFIX Message Header, which 1018 is 16 octets, and the length of all Sets that are contained in the 1019 IPFIX Message. 1021 Export Time 1023 If the "Export Time" in the TinyIPFIX Message Header has a length 1024 of 4 octets, the value from the TinyIPFIX Message Header MUST be 1025 used for the IPFIX Message Header. The "Export Time" MUST be 1026 generated by the Mediator, because the "export Time" field was 1027 dropped as defined in Section 6.1. If the IPFIX Message is 1028 exported again, the "Export Time" field MUST contain the time in 1029 seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message 1030 leaves the Exporter. If the Message is passed to an IPFIX 1031 Collector for decoding directly, the "Export Time" field is the 1032 time in seconds since 0000 UTC Jan 1 1970 at which the TinyIPFIX 1033 Message has been received by the TinyIPFIX Exporter. 1035 Sequence Number 1037 If the TinyIPFIX Sequence Number has a length of 4 octets, the 1038 original value MUST be used for the IPFIX Message. If the 1039 TinyIPFIX Sequence Number has a size of one or two octets, the 1040 TinyIPFIX Mediator MUST expand the TinyIPFIX Sequence Number into 1041 a four octet field. If the TinyIPFIX Sequence Number was omitted, 1042 the Mediator needs to calculate the Sequence Number as per 1043 [RFC7011]. 1045 Observation Domain ID 1046 Since the Observation Domain ID is used to scope templates in 1047 IPFIX, it MUST be set to a unique value per TinyIPFIX Exporting 1048 Process, using either a mapping algorithmically determined by the 1049 Intermediate Process or directly configured by an administrator. 1051 7.2. Translating the Set Headers 1053 Both fields in the TinyIPFIX Set Header have a size of one octet and 1054 need to be expanded: 1056 Set ID 1058 The field needs to be expanded from one octet to two octets. If 1059 the Set ID is below 128, no recalculation needs to be performed. 1060 This is because all IDs below 128 are reserved for special 1061 messages and match the IDs used in IPFIX. The TinyIPFIX Set IDs 1062 starting with 128 identify TinyIPFIX Data Sets. Therefore, every 1063 TinyIPFIX Set ID above number 127 needs to be incremented by 1064 number 128 because IPFIX Data Set IDs are numbered above 255. 1066 Set Length 1068 The field needs to be expanded from one octet to two octets. It 1069 needs to be recalculated by adding a value of 2 octets to match 1070 the additional size of the Set Header. For each TinyIPFIX 1071 Template Record that is contained in the TinyIPFIX Set, 2 more 1072 octets need to be added to the length. 1074 7.3. Expanding the Template Record Header 1076 Both fields in the TinyIPFIX Template Record Header have a length of 1077 one octet and therefore need translation: 1079 Template ID 1081 The field needs to be expanded from one octet to two octets. The 1082 Template ID needs to be increased by a value of 128. 1084 Field Count 1086 The field needs to be expanded from one octet to two octets. 1088 8. Template Management 1090 As with IPFIX, TinyIPFIX templates management depends on the 1091 transport protocol used. If TCP or SCTP is used, it can be ensured 1092 that TinyIPFIX Templates are delivered reliably. If UDP is used, 1093 reliability cannot be guaranteed, and template loss can occur. If a 1094 Template is lost on its way to the Collector, all the following 1095 TinyIPFIX Data Records that refer to this TinyIPFIX Template cannot 1096 be decoded. Template withdrawals are not supported in TinyIPFIX. 1097 This is generally not a problem, because most sensor nodes only 1098 define a single template directly after booting. 1100 8.1. TCP / SCTP 1102 If TCP or SCTP is used for the transmission of TinyIPFIX, Template 1103 Management MUST be performed as defined in [RFC7011] for IPFIX, with 1104 the exception of template withdrawals, which are not supported in 1105 TinyIPFIX. Template withdrawals MUST NOT be sent by TinyIPFIX 1106 Exporters. 1108 8.2. UDP 1110 All specifications for Template management from [RFC7011] apply 1111 unless specified otherwise in this document. 1113 TinyIPFIX Templates MUST be sent by a TinyIPFIX Exporter before any 1114 TinyIPFIX Data Set that refers to the TinyIPFIX Template is 1115 transmitted. TinyIPFIX Templates are not expected to change over 1116 time in TinyIPFIX and, thus, they should be pre-shared. TinyIPFIX 1117 Device have a default setup when deployed and after booting they 1118 announce their TinyIPFIX Template directly to the networkand MAY 1119 repeat it if UDP is used. Hence, a TinyIPFIX Template that has been 1120 sent once MAY NOT be withdrawn and MUST NOT expire. If a TinyIPFIX 1121 Smart Meter wants to use another TinyIPFIX Template it MUST use a new 1122 TinyIPFIX Template ID for the TinyIPFIX Template. 1124 As UDP is used, reliable transport of TinyIPFIX Templates cannot be 1125 guaranteed and TinyIPFIX Templates can be lost. A TinyIPFIX Exporter 1126 MUST expect TinyIPFIX Template loss. It MUST therefore re-send its 1127 TinyIPFIX Templates periodically. A TinyIPFIX Template MUST be re- 1128 send after a fixed number of N TinyIPFIX Messages that contained 1129 TinyIPFIX Data Sets that referred to this TinyIPFIX Template. The 1130 number N MUST be configured by the application developer. This re- 1131 sending, especially specification of N, can be avoided if TinyIPFIX 1132 Exporter and TinyIPFIX Collector use pre-shared templates. 1134 9. Security considerations 1136 The same security considerations as for the IPFIX Protocol [RFC7011] 1137 apply. 1139 10. IANA Considerations 1141 This document has no actions for IANA. 1143 11. Acknowledgments 1145 Many thanks to Lothar Braun, Georg Carle, and Benoit Claise, who 1146 contributed significant work to earlier versions especially to the 1147 document entitled "Compressed IPFIX for Smart Meters in Constrained 1148 Networks" (draft-braun-core-compressed-ipfix), of this work. 1150 Many thanks to Thomas Kothmayr, Michael Meister, and Livio Sgier, who 1151 implemented TinyIPFIX for TinyOS 2.x, Contiki 2.7/3.0 (except the 1152 mediator) for different sensor platforms (IRIS, TelosB, and 1153 OpenMote). 1155 12. References 1157 12.1. Normative References 1159 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1160 Requirement Levels", BCP 14, RFC 2119, 1161 DOI 10.17487/RFC2119, March 1997, 1162 . 1164 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1165 "Transmission of IPv6 Packets over IEEE 802.15.4 1166 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1167 . 1169 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 1170 "Specification of the IP Flow Information Export (IPFIX) 1171 Protocol for the Exchange of Flow Information", STD 77, 1172 RFC 7011, DOI 10.17487/RFC7011, September 2013, 1173 . 1175 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 1176 for IP Flow Information Export (IPFIX)", RFC 7012, 1177 DOI 10.17487/RFC7012, September 2013, 1178 . 1180 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 1181 "Architecture for IP Flow Information Export", RFC 5470, 1182 DOI 10.17487/RFC5470, March 2009, 1183 . 1185 [RFC5982] Kobayashi, A., Ed. and B. Claise, Ed., "IP Flow 1186 Information Export (IPFIX) Mediation: Problem Statement", 1187 RFC 5982, DOI 10.17487/RFC5982, August 2010, 1188 . 1190 [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, 1191 "IP Flow Information Export (IPFIX) Mediation: Framework", 1192 RFC 6183, DOI 10.17487/RFC6183, April 2011, 1193 . 1195 12.2. Informative References 1197 [Schmitt09] 1198 Schmitt, C. and G. Carle, "Applications for Wireless 1199 Sensor Networks", In Handbook of Research on P2P and Grid 1200 Systems for Service-Oriented Computing: Models, 1201 Methodologies and Applications, Antonopoulos N.; 1202 Exarchakos G.; Li M.; Liotta A. (Eds.), Information 1203 Science Publishing. , 2010. 1205 [Tolle05] Tolle, G., Polastre, J., Szewczyk, R., Turner, N., Tu, K., 1206 Buonadonna, P., Burgess, S., Gay, D., Hong, W., Dawnson, 1207 T., and D. Culler, "A macroscope in the redwoods", In the 1208 Proceedings of the 3rd ACM Conference on Embedded 1209 Networked Sensor Systems (Sensys 05), San Diego, ACM 1210 Press , November 2005. 1212 [Kim07] Kim, S., Pakzad, S., Culler, D., Demmel, J., Fenves, G., 1213 Glaser, S., and M. Turon, "Health Monitoring of Civil 1214 Infrastructure Using Wireless Sensor Networks", In the 1215 Proceedings of the 6th International Conference on 1216 Information Processing in Sensor Networks (IPSN 2007), 1217 Cambridge, MA, ACM Press, pp. 254-263 , April 2007. 1219 [SMPC04] Szewczyk, R., Mainwaring, A., Polastre, J., and D. Culler, 1220 "An analysis of a large scale habitat monitoring 1221 application", The Proceedings of the Second ACM Conference 1222 on Embedded Networked Sensor Systems (SenSys 04) , 1223 November 2004. 1225 [GreatDuck] 1226 Habitat Monitoring on Great Duck Island, , 1227 "http://www.greatduckisland.net", The Proceedings of the 1228 Second ACM Conference on Embedded Networked Sensor Systems 1229 (SenSys 04) , November 2004. 1231 [Harvan08] 1232 Harvan, M. and J. Schoenwaelder, "TinyOS Motes on the 1233 Internet: IPv6 over 802.15.4 (6LoWPAN)", 2008. 1235 [Crossbow] 1236 Crossbow Technologies Inc., , "http://www.xbow.com", 2010. 1238 [Advantic] 1239 Advantic Sistemas y Servicios, , 1240 "https://www.advanticsys.com/", 2017. 1242 [kothmayr10] 1243 Kothmayr, T., "Data Collection in Wireless Sensor Networks 1244 for Autonomic Home Networking", Bachelor Thesis, Technical 1245 University of Munich, Germany , 2010. 1247 [schmitt2014] 1248 Schmitt, C., Kothmayr, T., Ertl, B., Hu, W., Braun, L., 1249 and G. Carle, "TinyIPFIX: An Efficient Application 1250 Protocol for Data Exchange in Cyber Physical Systems", 1251 Computer Communications, ELSEVIER, DOI: 10.1016/ 1252 j.comcom.2014.05.012 , 2014. 1254 [schmitt2017] 1255 Schmitt, C., Anliker, C., and B. Stiller, "Efficient and 1256 Secure Pull Requests for Emergency Cases Using a Mobile 1257 Access Framework", Managing the Web of Things: Linking the 1258 Real World to the Web, M.Sheng, Y. Qin, L. Yao, and B. 1259 Benatallah (Eds.), Morgen Kaufmann (imprint of Elsevier), 1260 Chapter 8, pp. 229-247, ISBN: 978-0-12-809764-9 , 2017. 1262 Authors' Addresses 1264 Corinna Schmitt 1265 University of Zurich 1266 Department of Informatics 1267 Communication Systems Group 1268 Binzmuehlestrasse 14 1269 Zurich 8050 1270 Switzerland 1272 Email: schmitt@ifi.uzh.ch 1273 Burkhard Stiller 1274 University of Zurich 1275 Department of Informatics 1276 Communication Systems Group 1277 Binzmuehlestrasse 14 1278 Zurich 8050 1279 Switzerland 1281 Email: stiller@ifi.uzh.ch 1283 Brian Trammell 1284 Swiss Federal Institute of Technology 1285 Gloriastrasse 35 1286 Zurich 8092 1287 Switzerland 1289 Email: ietf@trammell.ch