idnits 2.17.1 draft-schmitt-ipfix-tiny-00.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 ([RFC7101], [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 an TinyIPFIX Exporter before any TinyIPFIX Data Set that refers to the TinyIPFIX Template is transmitted. TinyIPFIX Templates are not expected to change over time in TinyIPFIX. Hence, a TinyIPFIX Template that has been sent once MAY NOT be withdrawn and MUST NOT expire. If an TinyIPFIX Smart Meter wants to use another TinyIPFIX Template it MUST use a new TinyIPFIX Template ID for the TinyIPFIX Template. -- The document date (June 2, 2016) is 2885 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4944' is mentioned on line 1060, but not defined == Missing Reference: 'RFC7101' is mentioned on line 1065, but not defined == Missing Reference: 'RFC5982' is mentioned on line 1079, but not defined == Missing Reference: 'RFC6183' is mentioned on line 1084, but not defined == Missing Reference: 'RFC2119' is mentioned on line 1055, but not defined == Missing Reference: 'RFC5470' is mentioned on line 1074, but not defined == Missing Reference: 'RFC7012' is mentioned on line 1069, but not defined Summary: 1 error (**), 0 flaws (~~), 10 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: Standards Track University of Zurich 5 Expires: December 4, 2016 B. Trammell 6 ETH Zurich 7 June 2, 2016 9 TinyIPFIX for smart meters in constrained networks 10 draft-schmitt-ipfix-tiny-00 12 Abstract 14 This document specifies the TinyIPFIX protocol that serves for 15 transmitting smart metering data in 6LoWPAN networks [RFC4944]. 16 TinyIPFIX is derived from IPFIX [RFC7101] and adopted to the needs of 17 constrained networks. This documents specifies how the TinyIPFIX 18 Data and Template Records are transmitted in 6LoWPAN networks and how 19 TinyIPFIX data can be converted into unTinyIPFIX data in a proxy 20 device. 22 Status of This Memo 24 This Internet-Draft is submitted to IETF 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 4, 2016. 39 Copyright Notice 41 Copyright (c) 2016 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. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Document structure . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1. Hardware constraints . . . . . . . . . . . . . . . . . . 6 58 3.2. Energy constraints . . . . . . . . . . . . . . . . . . . 6 59 3.3. Packet size constraints . . . . . . . . . . . . . . . . . 7 60 3.4. Transport protocol constraints . . . . . . . . . . . . . 7 61 4. Application scenarios for TinyIPFIX . . . . . . . . . . . . . 8 62 5. Architecture for TinyIPFIX . . . . . . . . . . . . . . . . . 9 63 6. TinyIPFIX Message Format . . . . . . . . . . . . . . . . . . 11 64 6.1. TinyIPFIX Message Header . . . . . . . . . . . . . . . . 12 65 6.2. TinyIPFIX Set . . . . . . . . . . . . . . . . . . . . . . 16 66 6.3. TinyIPFIX Template Record Format . . . . . . . . . . . . 17 67 6.4. Field Specifier Format . . . . . . . . . . . . . . . . . 18 68 6.5. TinyIPFIX Data Record Format . . . . . . . . . . . . . . 19 69 7. TinyIPFIX Mediation . . . . . . . . . . . . . . . . . . . . . 19 70 7.1. Expanding the Message header . . . . . . . . . . . . . . 21 71 7.2. Translating the Set Headers . . . . . . . . . . . . . . . 22 72 7.3. Expanding the Template Record Header . . . . . . . . . . 23 73 8. Template Management . . . . . . . . . . . . . . . . . . . . . 23 74 8.1. TCP / SCTP . . . . . . . . . . . . . . . . . . . . . . . 23 75 8.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 76 9. Security considerations . . . . . . . . . . . . . . . . . . . 24 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 78 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 80 12.1. Norminative References . . . . . . . . . . . . . . . . . 24 81 12.2. Informative References . . . . . . . . . . . . . . . . . 25 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 84 1. Introduction 86 Smart meters that form a constrained wireless network need an 87 application layer protocol that allows the efficient transmission of 88 metering data from the devices to some kind of central analysis 89 device. The meters used to build such networks are usually equipped 90 with low-cost and low-power hardware. This leads to constraints in 91 computational capacities, available memory and networking resources. 93 The devices are often battery powered and are expected to run for a 94 long time without having the possibility to re-charge themselves. In 95 order to save energy, smart meters often power off their wireless 96 networking device. Hence, they don't have a steady network 97 connection, but are only part of the wireless network as needed when 98 there is data that needs to be exported. A push protocol like 99 TinyIPFIX, where data is transmitted autonomically from the meters to 100 one or more collectors, is suitable for reporting metering data in 101 such networks. 103 TinyIPFIX is derived from IPFIX [RFC7101] and therefore inherits most 104 of its properties. One of these properties is the separation of data 105 and its data description by encoding the former in Data Sets and the 106 latter in Template Sets. 108 Transforming TinyIPFIX to IPFIX as per [RFC7101] is very simple and 109 can be done on the border between the constrained network and the 110 more general network. The transformation between one form of IPFIX 111 data into another is known as IPFIX Mediation [RFC5982]. Hence, 112 smart metering networks that are based on TinyIPFIX can be easily 113 integrated into an existing IPFIX measurement infrastructure. 115 1.1. Document structure 117 Section 2 introduces the terminology used in this draft. Afterwards, 118 hardware and software constraints in constrained networks, which will 119 motivate our modifications to the IPFIX protocol, are discussed in 120 Section 3. Section 4 describes the application scenarios and 121 Section 5 describes the architecture for TinyIPFIX. Section 6 122 defines the TinyIPFIX protocol itself and discusses the differences 123 between TinyIPFIX and IPFIX. The Mediation Process from TinyIPFIX to 124 IPFIX is described in Section 7. Section 8 defines the process of 125 Template Management on the Exporter and the Collector. Section 9 and 126 Section 10 discuss the security and IANA considerations for 127 TinyIPFIX. 129 2. Terminology 131 The term smart meter is used to refer to constrained devices like 132 wireless senor nodes, motes or any other kind of small constraint 133 device that can be part of a network that is based on IEEE802.15.4 134 and 6LoWPAN [RFC4944]. 136 Most of the terms used in this draft are defined in [RFC7101]. All 137 these terms are written with their first letter being capitalized. 138 Most of the terms that are defined for IPFIX can be used to describe 139 TinyIPFIX. The term "TinyIPFIX" is used in front of the IPFIX term 140 to distinguish between the IPFIX version and the TinyIPFIX version. 141 This draft uses the term IPFIX to refer to IPFIX as per RFC 7101 and 142 the term TinyIPFIX for the IPFIX version defined in this draft. 144 The terms IPFIX Message, IPFIX Device, Set, Data Set, Template Set, 145 Data Record, Template Record, Collecting Process, Collector, 146 Exporting Process and Exporter are defined as in [RFC7101]. The term 147 IPFIX Mediator is defined in [RFC5982]. The terms Intermediate 148 Process, IPFIX Proxy, IPFIX Concentrator are defined in [RFC6183]. 150 All these terms above have been adapted from the IPFIX definitions. 151 As they keep a similar notion but in a different context of 152 constrained networks, the term "TinyIPFIX" now complements the 153 defined terms. 155 TinyIPFIX Exporting Process 157 The TinyIPFIX Exporting Process is a process that exports 158 TinyIPFIX Records. 160 TinyIPFIX Exporter 162 A TinyIPFIX Exporter is a smart metering device that contains at 163 least one TinyIPFIX Exporting Process. 165 TinyIPFIX Collecting Process 167 The TinyIPFIX Collecting Process is a process inside a device that 168 is able to receive and process TinyIPFIX Records. 170 TinyIPFIX Collector 172 A TinyIPFIX Collector is a device that contains at least one 173 TinyIPFIX Collecting Process. 175 TinyIPFIX Device 177 A TinyIPFIX Device is a device that contains one or more TinyIPFIX 178 Collector or one or more TinyIPFIX Exporter. 180 TinyIPFIX Smart Meter 182 A TinyIPFIX Smart Meter is a device that contains the 183 functionality of an TinyIPFIX device. It is usually equipped with 184 one or more sensors that meter a physical quantity, like power 185 consumption, temperature, or physical tempering with the device. 186 Every TinyIPFIX Smart Meter MUST at least contain an TinyIPFIX 187 Exporting Process. It MAY contain a TinyIPFIX Collecting Process 188 in order to work as a TinyIPFIX Proxy or Concentrator. 190 TinyIPFIX Message 191 The TinyIPFIX Message is a message originated by an TinyIPFIX 192 Exporter. It is composed of a TinyIPFIX Message Header and one or 193 more TinyIPFIX Sets. The TinyIPFIX Message Format is defined in 194 Section 6. 196 TinyIPFIX Data Record 198 A TinyIPFIX Data Record equals a Data Record in [RFC7101]. The 199 term is used to distinguish between IPFIX and TinyIPFIX throughout 200 the document. 202 TinyIPFIX Template Record 204 A TinyIPFIX Template Record is similar to a Template Record. The 205 Template Record Header is substituted with a TinyIPFIX Template 206 Record Header and is otherwise equal to a Template Record. See 207 Section 6.3. 209 TinyIPFIX Set 211 The TinyIPFIX Set is a group of TinyIPFIX Data Records or 212 TinyIPFIX Template Records with a TinyIPFIX Set Header. Its 213 format is defined in Section 6.2. 215 TinyIPFIX Data Set 217 The TinyIPFIX Data Set is a TinyIPFIX Set that contains TinyIPFIX 218 Data Records. 220 TinyIPFIX Template Set 222 A TinyIPFIX Template Set is a TinyIPFIX Set that contains 223 TinyIPFIX Template Records. 225 TinyIPFIX Intermediate Process 227 A TinyIPFIX Intermediate Process is an Intermediate Process that 228 can handle TinyIPFIX Messages. 230 TinyIPFIX Proxy 232 A TinyIPFIX Proxy is an IPFIX Proxy that can handle TinyIPFIX 233 Messages. 235 TinyIPFIX Concentrator 237 A TinyIPFIX Concentrator is an IPFIX Concentrator that can handle 238 TinyIPFIX Messages. 240 A TinyIPFIX Transport Session is defined by the communication between 241 a TinyIPFIX Exporter (identified by an 6LowPAN-Address, the Transport 242 Protocol, and the Transport Port) and a TinyIPFIX Collector 243 (identified by the same properties). 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in [RFC2119]. 249 3. Constraints 251 3.1. Hardware constraints 253 The target devices for TinyIPFIX are usually equipped with low-cost 254 hardware and therefore face several constraints concerning CPU and 255 memory [Schmitt09]. For example, the IRIS mote from Crossbow 256 Technologies Inc. has a size of 58 x 32 x 7 mm (without a battery 257 pack) [Crossbow]. Thus, there is little space for micro controller, 258 flash memory (128 kb) and radio frequency transceiver, which are 259 located on the board. 261 Network protocols used on such hardware need to respect these 262 constraints. They must be simple to implement using little code and 263 little run time memory and should produce little overhead when 264 encoding the application payload. 266 3.2. Energy constraints 268 Smart meters that are battery powered have hard energy constraints 269 [Schmitt09]. By power supply of two 2 AA 2,800-mAh batteries this 270 means approximately 30,240J. If they run out of power, their battery 271 has to be changed, which means physical manipulation to the device is 272 necessary. Using as little energy as possible for network 273 communication is therefore desired. 275 A smart metering device can save a lot of energy, if it powers down 276 its radio frequency transceiver. Such devices do not have permanent 277 network connectivity but are only part of the network as needed. A 278 push protocol, where only one side is sending data, is suitable for 279 transmitting application data under such circumstances. As the 280 communication is unidirectional, a meter can completely power down 281 its radio frequency transceivers as long as it does not have any data 282 to sent. If the metering device is able to keep a few measurements 283 in memory, and if real time metering is not a requirement, the 284 TinyIPFIX Data Records can be pushed less frequently. Therefore, 285 saving some more energy on the radio frequency transceivers. 287 3.3. Packet size constraints 289 TinyIPFIX is mainly targeted for the use in 6LoWPAN networks, which 290 are based on IEEE 802.15.4 [RFC4944]. However, the protocol can also 291 be used to transmit data in other networks. IEEE 802.15.4 defines a 292 maximum frame size of 127 octets, which usually leaves 102 octets for 293 user data. IPv6 on the other hand defines a minimum MTU of 1280 294 octets. Hence, fragmentation has to be implemented in order to 295 transmit such large packets. While fragmentation allows the 296 transmission of large messages, its use is problematic in networks 297 with high packet loss because the complete message has to be 298 discarded if only a single fragment gets lost. 300 TinyIPFIX enhances IPFIX by a header compression scheme, which allows 301 to reduce the overhead from header sizes significantly. 302 Additionally, the overall TinyIPFIX Message size is reduced, which 303 reduces the need for fragmentation. 305 3.4. Transport protocol constraints 307 The IPFIX standard [RFC7101] defines several transport protocol 308 bindings for the transmission of IPFIX Messages. SCTP support is 309 REQUIRED for any IPFIX Device to achieve standard conformance 310 [RFC7101], and its use is highly recommended. However, sending IPFIX 311 over UDP and TCP MAY also be implemented. 313 This transport protocol recommendation is not suitable for TinyIPFIX. 314 A header compression scheme that allows to compress an IPv6 header 315 from 40 octets down to 2 octets is defined in 6LoWPAN. There is a 316 similar compression scheme for UDP, but there is no such compression 317 for TCP or SCTP headers. If header compression can be employed, more 318 space for application payload is available. 320 Using UDP on the transport layer for transmitting IPFIX Messages is 321 therefore recommended. Furthermore, TCP or SCTP are currently not 322 supported on some platforms, like on TinyOS [Harvan08]. Hence, UDP 323 may be the only option. 325 Every TinyIPFIX Exporter and Collector MUST implement UDP transport 326 layer support for transmitting data in a constrained network 327 environment. It MAY also offer TCP or SCTP support. However, using 328 these protocols is NOT RECOMMENDED as their use will consume more 329 power and reduces the available size of application payload compared 330 to the use of UDP. If TinyIPFIX is transmitted over a non- 331 constrained network, using SCTP as a transport layer protocol is 332 RECOMMENDED. 334 4. Application scenarios for TinyIPFIX 336 TinyIPFIX is derived from IPFIX [RFC7101] and is therefore a 337 unidirectional push protocol. This means all communication that 338 employs TinyIPFIX is unidirectional from an Exporting Process to a 339 Collecting Process. Hence, TinyIPFIX only fits for application 340 scenarios where meters transmit data to one or more Collectors. 342 If TinyIPFIX is used over UDP, as recommended, packet loss can occur. 343 Furthermore, if an initial Template Message gets lost, and is 344 therefore unknown to the Collector, all TinyIPFIX Data Sets that 345 reference this Template cannot be decoded. Hence, all these Messages 346 are lost if they are not cached by the Collector. It should be clear 347 to an application developer, that TinyIPFIX can only be used over UDP 348 if these TinyIPFIX Message losses are not a problem. 350 TinyIPFIX over UDP is especially not a suitable protocol for 351 applications where sensor data trigger policy decisions or 352 configuration updates for which packet loss is not tolerable. 354 Applications that use smart sensors for accounting purposes for long 355 time measurements can benefit from the use of TinyIPFIX. One 356 application for IPFIX can be long term monitoring of large physical 357 volumes. In [Tolle05], Tolle et al. built a system for monitoring a 358 "70-meter tall redwood tree, at a density interval of 5 minutes in 359 time and 2 meters in space". The sensor node infrastructure was 360 deployed to measure the air temperature, relative humidity and 361 photosynthetically active solar radiation over a long time period. 363 Deploying TinyIPFIX in such scenarios seems to be a good fit. The 364 sensors of the TinyIPFIX Smart Meter can be queried over several 5 365 minute time intervals and the query results can be aggregated into a 366 single TinyIPFIX Message. As soon as enough query results are stored 367 in the TinyIPFIX Message, e.g. if the TinyIPFIX Message size fills 368 the available payload in a single IEEE 802.15.4 packet, the wireless 369 transceiver can be activated and the TinyIPFIX Message can be 370 exported to a TinyIPFIX Collector. 372 Similar sensor networks have been built to monitor the habitat of 373 animals, e.g. in the "Great Duck Island Project" [GreatDuck], 374 [SMPC04]. The purpose of the sensor network was to monitor the birds 375 by deploying sensors in and around their burrows. The measured 376 sensor data was collected and stored in a database for offline 377 analysis and visualization. Again, the sensors can perform their 378 measurements periodically, aggregate the sensor data and export them 379 to a TinyIPFIX Collector. 381 Other application scenarios for TinyIPFIX could be applications where 382 sensor networks are used for long term structural health monitoring 383 in order to investigate long term weather conditions on the structure 384 of a building. For example, a smart metering network has been built 385 to monitor the structural health of the Golden Gate Bridge [Kim07]. 386 If a sensor network is deployed to perform a long term measurement of 387 the structural integrity, TinyIPFIX can be used to collect the sensor 388 measurement data. 390 If an application developer wants to decide whether to use TinyIPFIX 391 for transmitting data from smart meters, he must take the following 392 considerations into account: 394 1. The application must require a push protocol. It is not possible 395 to request data from a smart meter. The TinyIPFIX Smart Meter 396 decides for itself when to send its metering data. 398 2. The property above allows a TinyIPFIX Smart Meter to turn off its 399 wireless device in order to save energy, as it does not have to 400 receive any data. 402 3. If real-time is not required, the application might benefit from 403 accumulated several measurements into a single TinyIPFIX Message. 404 TinyIPFIX easily allows the aggregation of several into a single 405 TinyIPFIX Message (or a single packet). This aggregation can 406 happen on the TinyIPFIX Smart Meter that aggregates several of 407 its own measurements. Or it can happen within a multi-hop 408 wireless network where one IPFIX Proxy aggregates several 409 TinyIPFIX Messages into a single TinyIPFIX Message before 410 forwarding them. 412 4. The application must accept potential packet loss. TinyIPFIX 413 only fits for applications where metering data is stored for 414 accounting purposes and not for applications where the sensor 415 data triggers configuration changes or policy decisions (except: 416 if Message loss is acceptable for some reason). 418 5. Architecture for TinyIPFIX 420 The TinyIPFIX architecture is similar to the IPFIX architecture which 421 is described in [RFC5470]. The most common deployment of TinyIPFIX 422 Smart Meters is shown in Figure 1. 424 +----------------+ +----------------+ 425 |[*Application 1]| ... |[*Application n]| 426 +--------+-------+ +-------+--------+ 427 ^ ^ 428 | | 429 +----------+----------+ 430 ^ 431 | 432 +------------------------+ +--------+-------------------+ 433 | TinyIPFIX S.M. | TinyIPFIX | TinyIPFIX Collector | 434 | [Exporting Process] |----------->| [Collecting Process(es)] | 435 +------------------------+ +----------------------------+ 437 Figure 1: Direct transmission between sensors and applications 439 An TinyIPFIX Smart Meter (S.M.) queries its internal sensors to 440 retrieve the sensor data. It then encodes the results into a 441 TinyIPFIX Message and exports this TinyIPFIX Message to one or more 442 TinyIPFIX Collectors. The TinyIPFIX Collector runs one or more 443 applications that process the collected sensor data. The TinyIPFIX 444 Collector can be deployed on non-constrained devices at the 445 constrained network border. 447 A second way to deploy TinyIPFIX Smart Meter can employ aggregation 448 on TinyIPFIX Messages during their journey through the constrained 449 network as shown in Figure 2. This aggregation can be performed by 450 special TinyIPFIX Smart Meter that act as TinyIPFIX Concentrators. 451 Such devices must have enough resources to perform the aggregation. 453 +-------------------------+ +------------------------+ 454 | TinyIPFIX S.M. | TinyIPFIX | TinyIPFIX Concentrator | 455 | [Exporting Process] |----------------->| [Collecting Process] | 456 +-------------------------+ +-------->| [Exporting Process] | 457 | +------------------------+ 458 +-------------------------+ | | 459 | TinyIPFIX S.M. | | TinyIPFIX| 460 | [Exporting Process] |--------+ | 461 +-------------------------+ v 462 +-------+------------------+ 463 | Collector(1) | 464 | [Collecting Process(es)] | 465 +--------------------------+ 467 Figure 2: Aggregation on TinyIPFIX 469 TinyIPFIX Smart Meters send their data to TinyIPFIX Concentrator 470 which needs to have enough storage space to store the incoming data. 471 It may also aggregate the incoming data with its own measurement 472 data. The aggregated data can then be re-exported again to one or 473 more Collectors. 475 The last deployment, shown in Figure 3, employs another TinyIPFIX 476 Mediation process. 478 +------------------------+ +------------------------+ 479 | TinyIPFIX S.M | TinyIPFIX | TinyIPFIX Proxy | 480 | [Exporting Process] |----------------->| [Collecting Process] | 481 +------------------------+ | [Exporting Process] | 482 +------------------------+ 483 | 484 IPFIX | 485 v 486 +--------------------------+ 487 | IPFIX Collector(1) | 488 | [Collecting Process(es)] | 489 +--------------------------+ 491 Figure 3: Aggregation on TinyIPFIX 493 The TinyIPFIX Smart Meters transmit their TinyIPFIX Messages to one 494 node, e.g. the base station, which translates the TinyIPFIX Messages 495 to IPFIX Messages. The IPFIX Messages can then be exported into an 496 existing IPFIX infrastructure. The Mediation process from TinyIPFIX 497 to IPFIX is described in Section 7. 499 6. TinyIPFIX Message Format 501 A TinyIPFIX IFPIX Message starts with a TinyIPFIX Message Header, 502 followed by one or more TinyIPFIX Sets. The TinyIPFIX Sets can be 503 any of the possible two types: TinyIPFIX Template Set and TinyIPFIX 504 Data Set. An TinyIPFIX Message MUST only contain one type of 505 TinyIPFIX Set. The format of the TinyIPFIX Message is shown in 506 Figure 4 507 +----------------------------------------------------+ 508 | TinyIPFIX Message Header | 509 +----------------------------------------------------+ 510 | TinyIPFIX Set | 511 +----------------------------------------------------+ 512 | TinyIPFIX Set | 513 +----------------------------------------------------+ 514 ... 515 +----------------------------------------------------+ 516 | TinyIPFIX Set | 517 +----------------------------------------------------+ 519 Figure 4: TinyIPFIX Message Format 521 6.1. TinyIPFIX Message Header 523 The TinyIPFIX Message Header is derived from the IPFIX Message 524 Header, with some optimization using field compression. The IPFIX 525 Message Header from [RFC7101] is shown in Figure 5. 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Version Number | Length | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Export Time | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Sequence Number | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Observation ID | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Figure 5: IPFIX Message Header 541 The length of the IPFIX Message Header is 16 octets and every IPFIX 542 Message has to be started with it. The TinyIPFIX Message Header 543 needs to be smaller due to the packet size constraints discussed in 544 Section 3.3. TinyIPFIX introduces a TinyIPFIX Message Header that 545 has a smaller size. The TinyIPFIX header consists of a fixed part of 546 three octets and a variable length "Remaining Header" as shown in 547 Figure 6. 549 0 1 550 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 551 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 552 |E1|E2| SetID | Length | 553 | | | Lookup | | 554 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 555 | Sequence | Ext. Sequence | 556 | Number | Number | 557 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 558 | Ext. SetID | 559 +--+--+--+--+--+--+--+--+ 561 Figure 6: Format of the TinyIPFIX Message header 563 The first part has a fixed length of thre octets and consists of the 564 "E1" field (1 bit), the "E2" field (1 bit), the "SetID Lookup" field 565 (4 bit), the "Length" field (10 bit), and the "Sequence Number" field 566 (8 bit). The second part (the "Remaining Header") has a variable 567 length. Its length is defined by the "E1" and "E2" field in the 568 fixed header part. The four variants are illustrated in the figures 569 below. 571 0 1 572 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 573 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 574 |0 |0 | SetID | Length | 575 | | | Lookup | | 576 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 577 | Sequence | 578 | Number | 579 +--+--+--+--+--+--+--+--+ 581 Figure 7: TinyIPFIX Message Header format if E1 = E2 = 0 583 0 1 584 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 585 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 586 |1 |0 | SetID | Length | 587 | | | Lookup | | 588 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 589 | Sequence | Ext. SetID | 590 | Number | | 591 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 593 Figure 8: TinyIPFIX Message Header format if E1 = 1 and E2 = 0 595 0 1 596 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 597 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 598 |0 | 1| SetID | Length | 599 | | | Lookup | | 600 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 601 | Sequence | Ext. Sequence | 602 | Number | Number | 603 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 605 Figure 9: TinyIPFIX Message Header format if E1 = 0 and E2 = 1 607 0 1 608 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 609 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 610 |1 |1 | SetID | Length | 611 | | | Lookup | | 612 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 613 | Sequence | Ext. Sequence | 614 | Number | Number | 615 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 616 | Ext. SetID | 617 +--+--+--+--+--+--+--+--+ 619 Figure 10: TinyIPFIX Message Header format if E1 = E2 = 1 621 The fixed header fields are defined as follows [kothmayr10] 622 [schmitt2014]: 624 E1 and E2 625 The bits marked "E1" and "E2" control the presence of the file 626 "Ext. SetID" and the length of the field "Ext. Sequence Number" 627 respectively. In case E1 = E2 = 0 the TinyIPFIX message header 628 has the format as shown in Figure 7. No Ext. Sequence Number and 629 Ext. SetID are required. In case E1 = 1, custom SetIDs can be 630 specified in the extended SetID field (cf. Figure 8.) When 631 evaluated, the value specified in the extended SetID field is 632 shifted left by 8 bits to prevent collisions with the reserved 633 SetIDs 0-255. To reference these, shifting can be disabled by 634 setting all SetID lookup bits to 1. Depending on the application 635 sampling rates might be larger than in typical WSNs and, thus, 636 they may have a large quantity of records per packet. In order to 637 make TinyIPFIX applicable for those cases E2 = 1 is set (cf. 638 Figure 9.) This means the Ext. Sequence Number field is available 639 offering 8-bit more sequence numbers as usual. Depending on the 640 WSN settings the also the combination E1 = E2 = 1 is possible 641 resulting in the maximum TinyIPFIX Message header shown in 642 Figure 10where Ext. Sequence Number field and Ext. SetID field are 643 required. 645 SetID Lookup 647 This field acts as a lookup field for the SetIDs and provides 648 shortcuts to often used SetIDs. So far only four values are 649 defined: Value = 0 means Lookup extended SetID field, Shifting 650 enabled. Value = 1 means SetID = 2 and message contains a 651 Template definition. Value = 2 means SetID = 256 and message 652 containts Data Record for Template 256. This places special 653 importance on a single template ID, but since most sensor nodes 654 only define a single template directly after booting and continue 655 to stream data with this template ID during the whole session 656 lifetime, this shorthand is useful for this case. Value = 3-14 657 means SetIDs are reserved for future extensions. Value = 15 means 658 Lookup extended SetID field, shiftig enabled. 660 Length 662 The length field has a fixed length of 10 bits. 664 Sequence Number 666 Due to the low sampling rate in typical WSNs, the "Sequence 667 Number" field is only one byte long. However, some applications 668 may have a large quantity of records per packet. In this case the 669 sequence field can be extended to 16 bit by setting the E2-bit to 670 1. 672 Since TinyIPFIX packets are always transported via a network 673 protocol, which specifies the source of the packet, the "Observation 674 Domain" can be equated with the source of a TinyIPFIX packet and the 675 field can be dropped from the header. Should applications require 676 several Observation Domains the information can be included in the 677 TinyIPFIX data message. The version field has been dropped since the 678 SetID lookup field provides room for future extensions. The 679 specification of a 32 bit time stamp in seconds would require the 680 time synchronization across a wireless sensor network and produces 681 too much overhead. Thus, the "Export Time" field is dropped. If 682 applications should require the specification of time it can be sent 683 as part of the TinyIPFIX data message. 685 6.2. TinyIPFIX Set 687 A TinyIPFIX Set is a set of TinyIPFIX Template or TinyIPFIX Data 688 Records. Depending on the TinyIPFIX Record type, the TinyIPFIX Set 689 can either be a TinyIPFIX Template Set or a TinyIPFIX Data Set. 690 Every TinyIPFIX Set is started with an TinyIPFIX Set Header and is 691 followed by one or more TinyIPFIX Records. 693 The IPFIX Set Header consists of an two octet "Set ID" field and a 694 two octet "Length" field. These two fields are compressed to one 695 octet each for the TinyIPFIX Set Header. The format of the TinyIPFIX 696 Set Header is shown in Figure 11. 698 0 1 699 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Comp. Set ID | Length | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 Figure 11: TinyIPFIX Set Header 706 The two fields are defined as follows: 708 TinyIPFIX Set ID 710 The "TinyIPFIX Set ID" (Comp. Set ID) identifies the type of data 711 that is transported in the TinyIPFIX Set. A TinyIPFIX Template 712 Set is identified by TinyIPFIX Set ID 2. This corresponds to the 713 Set IDs that are used by Sets in IPFIX. TinyIPFIX Set ID number 3 714 MUST NOT be used. All values from 4 to 127 are reserved for 715 future use. Values above 127 are used for TinyIPFIX Data Sets. 717 Length 718 The "Length" Field contains the total length of the TinyIPFIX Set, 719 including the TinyIPFIX Set Header. 721 6.3. TinyIPFIX Template Record Format 723 The format of the TinyIPFIX Template Records is shown in Figure 12. 724 The TinyIPFIX Template Record starts with an TinyIPFIX Template 725 Record Header and is followed by one or more Field Specifiers. The 726 Field Specifier format is defined as in Section 6.4 and is identical 727 to the Field Specifier definition in [RFC7101]. 729 +--------------------------------------------------+ 730 | TinyIPFIX Template Record Header | 731 +--------------------------------------------------+ 732 | Field Specifier | 733 +--------------------------------------------------+ 734 | Field Specifier | 735 +--------------------------------------------------+ 736 ... 737 +--------------------------------------------------+ 738 | Field Specifier | 739 +--------------------------------------------------+ 741 Figure 12: TinyIPFIX Template Format 743 The format of the TinyIPFIX Template Record Header is shown in 744 Figure 13. 746 0 1 747 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Comp. Temp ID | Field Count | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Figure 13: TinyIPFIX Template Header 754 TinyIPFIX Template ID 756 Each TinyIPFIX Template Record must have a unique TinyIPFIX 757 Template ID (Comp. Temp ID) between 128 and 255. The TinyIPFIX 758 Template ID must be unique for the given TinyIPFIX Transport 759 Session. 761 Field Count 762 The number of fields placed in the TinyIPFIX Template Record. 764 6.4. Field Specifier Format 766 The type and length of the transmitted data is encoded in Field 767 Specifiers within TinyIPFIX Template Records. The Field Specifier is 768 shown in Figure 14 and is identical with the Field Specifier that was 769 defined for IPFIX [RFC7101]. The following text has been copied from 770 [RFC7101] for completeness. 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 |E| Information Element ident. | Field Length | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Enterprise Number | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 Figure 14: TinyIPFIX Template Header 782 Where: 784 E 786 Enterprise bit. This is the first bit of the Field Specifier. If 787 this bit is zero, the Information Element Identifier identifies an 788 IETF-specified Information Element, and the four-octet Enterprise 789 Number field MUST NOT be present. If this bit is one, the 790 Information Element Identifier identifies an enterprise-specific 791 Information Element, and the Enterprise Number field MUST be 792 present. 794 Information Element Identifier 796 A numeric value that represents the type of Information Element. 798 Field Length 800 The length of the corresponding encoded Information Element, in 801 octets. Refer to [RFC7012]. The value 65535 is illegal as there 802 are no variable size encoded elements as they are defined in 803 IPFIX. 805 Enterprise Number 806 IANA Private Enterprise Number of the authority defining the 807 Information Element identifier in this Template Record. 809 Vendors can easily define their own data model by registering a 810 Enterprise ID with IANA. Using their own Enterprise ID, they can use 811 any ID in the way they want them to use. 813 6.5. TinyIPFIX Data Record Format 815 The Data Records are sent in TinyIPFIX Data Sets. The format of the 816 Data Records is shown in Figure 15 and matches the Data Record format 817 from IPFIX. 819 +--------------------------------------------------+ 820 | Field Value | 821 +--------------------------------------------------+ 822 | Field Value | 823 +--------------------------------------------------+ 824 ... 825 +--------------------------------------------------+ 826 | Field Value | 827 +--------------------------------------------------+ 829 Figure 15: Data Record Format 831 7. TinyIPFIX Mediation 833 There are two types of TinyIPFIX Intermediate Processes. The first 834 one can occur on the transition between a constraint 6LoWPAN and the 835 non-constrained network. This mediation changes the network and 836 transport protocol from 6LowPAN/UDP to IP/(SCTP|TCP|UDP) and is shown 837 in Figure 16. 839 +-----------------------+ TinyIPFIX +-------------------------+ 840 | TinyIPFIX S.M. | 6LoWPAN/UDP | TinyIPFIX mediator | 841 | [Exporting Process] |--------------->| [Collecting Process] | 842 +-----------------------+ | [Exporting Process] | 843 +-------------------------+ 844 | 845 TinyIPFIX | 846 IP/(UDP/SCTP|TCP) | 847 v 848 +--------------------------+ 849 | Collector(1) | 850 | [Collecting Process(es)] | 851 +--------------------------+ 853 Figure 16: Translation from TinyIPFIX over 6LowPAN/UDP to TinyIPFIX 854 over IP/(SCTP|TCP|UDP) 856 The mediator removes the TinyIPFIX Messages from the 6LowPAN/UDP 857 packets and wraps them into the new network and transport protocols. 858 Templates MUST be managed the same way as in the constraint 859 environment after the translation to IP/(SCTP|UDP|TCP) (see 860 Section 8). 862 The second type of mediation transforms TinyIPFIX into IPFIX. This 863 process MUST be combined with the transport protocol mediation as 864 shown in Figure 17. 866 +------------------------+ TinyIPFIX +-----------------------+ 867 | TinyIPFIX S.M. | 6LoWPAN/UDP | IPFIX mediator | 868 |[Exporting Processes] |---------------->| [Collecting Process] | 869 +------------------------+ | [Exporting Process] | 870 +-----------------------+ 871 | 872 IPFIX | 873 IP/(UDP/SCTP|TCP) | 874 v 875 +--------------------------+ 876 | Collector(1) | 877 | [Collecting Process(es)] | 878 +--------------------------+ 880 Figure 17: Transformation from TinyIPFIX to IPFIX 882 This mediation can also be performed by an IPFIX Collector before 883 parsing the IPFIX message as shown in Figure 18. There is no need 884 for a TinyIPFIX IPFIX parser if such a mediation process can be 885 employed in front of an already existing IPFIX collector. 887 +------------------------+ TinyIPFIX +----------------------+ 888 | TinyIPFIX S.M. | 6LoWPAN/UDP | IPFIX Mediator | 889 | [Exporting Processes] |----------------->| [Collecting Process] | 890 +------------------------+ | [Exporting Process] | 891 | | | 892 | |IPFIX | 893 | | | 894 | v | 895 | Collector(1) | 896 | [Collecting Process] | 897 +----------------------+ 899 Figure 18: Transformation from TinyIPFIX to IPFIX 901 The TinyIPFIX Mediation Process has to translate the TinyIPFIX 902 Message Header, the TinyIPFIX Set Headers and the TinyIPFIX Template 903 Record Header into their counterparts in IPFIX Afterwards, the new 904 IPFIX Message Length needs to be calculated and inserted into the 905 IPFIX Message header. 907 7.1. Expanding the Message header 909 The fields of the IPFIX Message Header that are shown in Figure 5 can 910 be determined as follows: 912 Version 914 This is always 0x000a. 916 Length 918 The IPFIX Message Length can only be calculated after the complete 919 TinyIPFIX Message has been translated. The new length can be 920 calculated by adding the length of the IPFIX Message Header, which 921 is 16 octets, and the length of all Sets that are contained in the 922 IPFIX Message. 924 Export Time 926 If the "Export Time" in the TinyIPFIX Message Header has a length 927 of 4 octets, the value from the TinyIPFIX Message Header MUST be 928 used for the IPFIX Message Header. If it was omitted, the "Export 929 Time" MUST be generated by the Mediator. If the IPFIX Message is 930 exported again, the "Export Time" field MUST contain the time in 931 seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message 932 leaves the Exporter. If the Message is passed to an IPFIX 933 Collector for decoding directly, the "Export Time" field is the 934 time in seconds since 0000 UTC Jan 1 1970 at which the TinyIPFIX 935 Message has been received by the TinyIPFIX Exporter. 937 Sequence Number 939 If the TinyIPFIX Sequence Number has a length of 4 octets, the 940 original value MUST be used for the IPFIX Message. If the 941 TinyIPFIX Sequence Number has a size of one or two octets, the 942 TinyIPFIX Mediator MUST expand the TinyIPFIX Sequence Number into 943 a four octet field. If the TinyIPFIX Sequence Number was omitted, 944 the Mediator needs to calculate the Sequence Number as per 945 [RFC7101]. 947 Observation Domain ID 949 Since the Observation Domain ID is used to scope templates in 950 IPFIX, it MUST be set to a unique value per TinyIPFIX Exporting 951 Process, using either a mapping algorithmically determined by the 952 Intermediate Process or directly configured by an administrator. 954 7.2. Translating the Set Headers 956 Both fields in the TinyIPFIX Set Header have a size of one octet and 957 need to be expanded: 959 Set ID 961 The field needs to be expanded from one octet to two octets. If 962 the Set ID is below 128, no recalculation needs to be performed. 963 This is because all IDs below 128 are reserved for special 964 messages and match the IDs used in IPFIX. The TinyIPFIX Set IDs 965 starting with 128 identify TinyIPFIX Data Sets. Therefore, every 966 TinyIPFIX Set ID above 127 needs to be incremented by 128 because 967 IPFIX Data Set IDs are located above 255. 969 Set Length 971 The field needs to be expanded from one octet to two octets. It 972 needs to be recalculated by adding a value of 2 octet to match the 973 additional size of the Set Header. For each TinyIPFIX Template 974 Record that is contained in the TinyIPFIX Set, 2 more octets need 975 to be added to the length. 977 7.3. Expanding the Template Record Header 979 Both fields in the TinyIPFIX Template Record Header have a length of 980 one octet and therefore need translation: 982 Template ID 984 The field needs to be expanded from one octet to two octets. The 985 Template ID needs to be increased by a value of 128. 987 Field Count 989 The field needs to be expanded from one octet to two octets. 991 8. Template Management 993 As with IPFIX, TinyIPFIX templates management depends on the 994 transport protocol used. If TCP or SCTP is used, it can be ensured 995 that TinyIPFIX Templates are delivered reliably. If UDP is used, 996 reliability cannot be guaranteed, and template loss can occur. If a 997 Template is lost on its way to the Collector, all following TinyIPFIX 998 Data Records that refer to this TinyIPFIX Template cannot be decoded. 999 Template withdrawals are not supported in TinyIPFIX. This is 1000 generally not a problem, because most sensor nodes only define a 1001 single template directly after booting. 1003 8.1. TCP / SCTP 1005 If TCP or SCTP is an option and can be used for the transmission of 1006 TinyIPFIX, Template Management MUST be performed as defined in 1007 [RFC7101] for IPFIX, with the exception of template withdrawals, 1008 which are not supported in TinyIPFIX. Template withdrawals MUST NOT 1009 be sent by TinyIPFIX exporters. 1011 8.2. UDP 1013 All specifications for Template management from [RFC7101] apply 1014 unless specified otherwise in this document. 1016 TinyIPFIX Templates MUST be sent by an TinyIPFIX Exporter before any 1017 TinyIPFIX Data Set that refers to the TinyIPFIX Template is 1018 transmitted. TinyIPFIX Templates are not expected to change over 1019 time in TinyIPFIX. Hence, a TinyIPFIX Template that has been sent 1020 once MAY NOT be withdrawn and MUST NOT expire. If an TinyIPFIX Smart 1021 Meter wants to use another TinyIPFIX Template it MUST use a new 1022 TinyIPFIX Template ID for the TinyIPFIX Template. 1024 As UDP is used, reliable transport of TinyIPFIX Templates cannot be 1025 guaranteed and TinyIPFIX Templates can be lost. A TinyIPFIX Exporter 1026 MUST expect TinyIPFIX Template loss. It MUST therefore re-send its 1027 TinyIPFIX Templates periodically. A TinyIPFIX Template MUST be re- 1028 send after a fixed number of N TinyIPFIX Messages that contained 1029 TinyIPFIX Data Sets that referred to this TinyIPFIX Template. The 1030 number N MUST be configured by the application developer. 1032 9. Security considerations 1034 The same security considerations as for the IPFIX Protocol [RFC7101] 1035 apply. 1037 10. IANA Considerations 1039 This document has no actions for IANA. 1041 11. Acknowledgments 1043 Many thanks to Lothar Braun, Georg Carle, and Benoit Claise, who 1044 contributed significant work to earlier versions especially to the 1045 document entitled "Compressed IPFIX for Smart Meters in Constrained 1046 Networks" (draft-braun-core-compressed-ipfix), of this work. 1048 Many thanks to Thomas Kothmayr and Michael Meister, who implemented 1049 TinyIPFIX for TinyOS 2.x and Contiki 2.7 except the mediator. 1051 12. References 1053 12.1. Norminative References 1055 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1056 Requirement Levels", BCP 14, RFC 2119, 1057 DOI 10.17487/RFC2119, March 1997, 1058 . 1060 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1061 "Transmission of IPv6 Packets over IEEE 802.15.4 1062 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1063 . 1065 [RFC7101] Ginoza, S., "List of Internet Official Protocol Standards: 1066 Replaced by a Web Page", RFC 7101, DOI 10.17487/RFC7101, 1067 December 2013, . 1069 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 1070 for IP Flow Information Export (IPFIX)", RFC 7012, 1071 DOI 10.17487/RFC7012, September 2013, 1072 . 1074 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 1075 "Architecture for IP Flow Information Export", RFC 5470, 1076 DOI 10.17487/RFC5470, March 2009, 1077 . 1079 [RFC5982] Kobayashi, A., Ed. and B. Claise, Ed., "IP Flow 1080 Information Export (IPFIX) Mediation: Problem Statement", 1081 RFC 5982, DOI 10.17487/RFC5982, August 2010, 1082 . 1084 [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, 1085 "IP Flow Information Export (IPFIX) Mediation: Framework", 1086 RFC 6183, DOI 10.17487/RFC6183, April 2011, 1087 . 1089 12.2. Informative References 1091 [Schmitt09] 1092 Schmitt, C. and G. Carle, "Applications for Wireless 1093 Sensor Networks", In Handbook of Research on P2P and Grid 1094 Systems for Service-Oriented Computing: Models, 1095 Methodologies and Applications, Antonopoulos N.; 1096 Exarchakos G.; Li M.; Liotta A. (Eds.), Information 1097 Science Publishing. , 2010. 1099 [Tolle05] Tolle, G., Polastre, J., Szewczyk, R., Turner, N., Tu, K., 1100 Buonadonna, P., Burgess, S., Gay, D., Hong, W., Dawnson, 1101 T., and D. Culler, "A macroscope in the redwoods", In the 1102 Proceedings of the 3rd ACM Conference on Embedded 1103 Networked Sensor Systems (Sensys 05), San Diego, ACM 1104 Press , November 2005. 1106 [Kim07] Kim, S., Pakzad, S., Culler, D., Demmel, J., Fenves, G., 1107 Glaser, S., and M. Turon, "Health Monitoring of Civil 1108 Infrastructure Using Wireless Sensor Networks", In the 1109 Proceedings of the 6th International Conference on 1110 Information Processing in Sensor Networks (IPSN 2007), 1111 Cambridge, MA, ACM Press, pp. 254-263 , April 2007. 1113 [SMPC04] Szewczyk, R., Mainwaring, A., Polastre, J., and D. Culler, 1114 "An analysis of a large scale habitat monitoring 1115 application", The Proceedings of the Second ACM Conference 1116 on Embedded Networked Sensor Systems (SenSys 04) , 1117 November 2004. 1119 [GreatDuck] 1120 Habitat Monitoring on Great Duck Island, , 1121 "http://www.greatduckisland.net", The Proceedings of the 1122 Second ACM Conference on Embedded Networked Sensor Systems 1123 (SenSys 04) , November 2004. 1125 [Harvan08] 1126 Harvan, M. and J. Schoenwaelder, "TinyOS Motes on the 1127 Internet: IPv6 over 802.15.4 (6lowpan)", 2008. 1129 [Crossbow] 1130 Crossbow Technologies Inc., , "http://www.xbow.com", 2010. 1132 [kothmayr10] 1133 Kothmayr, T., "Data Collection in Wireless Sensor Networks 1134 for Autonomic Home Networking", Bachelor Thesis, Technical 1135 University of Munich, Germany , 2010. 1137 [schmitt2014] 1138 Schmitt, C., Kothmayr, T., Ertl, B., Hu, W., Braun, L., 1139 and G. Carle, "TinyIPFIX: An Efficient Application 1140 Protocol for Data Exchange in Cyber Physical Systems", 1141 Computer Communications, ELSEVIER, DOI: 10.1016/ 1142 j.comcom.2014.05.012 , 2014. 1144 Authors' Addresses 1146 Corinna Schmitt 1147 University of Zurich 1148 Department of Informatics 1149 Communication Systems Group 1150 Binzmuehlestrasse 14 1151 Zurich 8050 1152 Switzerland 1154 Email: schmitt@ifi.uzh.ch 1155 Burkhard Stiller 1156 University of Zurich 1157 Department of Informatics 1158 Communication Systems Group 1159 Binzmuehlestrasse 14 1160 Zurich 8050 1161 Switzerland 1163 Email: stiller@ifi.uzh.ch 1165 Brian Trammell 1166 Swiss Federal Institute of Technology 1167 Gloriastrasse 35 1168 Zurich 8092 1169 Switzerland 1171 Email: ietf@trammell.ch