idnits 2.17.1 draft-schmitt-ipfix-tiny-01.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 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. 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 (November 30, 2016) is 2703 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 1066, but not defined == Missing Reference: 'RFC7101' is mentioned on line 1071, but not defined == Missing Reference: 'RFC5982' is mentioned on line 1085, but not defined == Missing Reference: 'RFC6183' is mentioned on line 1090, but not defined == Missing Reference: 'RFC2119' is mentioned on line 1061, but not defined == Missing Reference: 'RFC5470' is mentioned on line 1080, but not defined == Missing Reference: 'RFC7012' is mentioned on line 1075, 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: June 3, 2017 B. Trammell 6 ETH Zurich 7 November 30, 2016 9 TinyIPFIX for smart meters in constrained networks 10 draft-schmitt-ipfix-tiny-01 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 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 June 3, 2017. 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. 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 . . . . . . . . . . . . . . . . . 9 66 6. TinyIPFIX Message Format . . . . . . . . . . . . . . . . . . 11 67 6.1. TinyIPFIX Message Header . . . . . . . . . . . . . . . . 12 68 6.2. TinyIPFIX Set . . . . . . . . . . . . . . . . . . . . . . 16 69 6.3. TinyIPFIX Template Record Format . . . . . . . . . . . . 17 70 6.4. Field Specifier Format . . . . . . . . . . . . . . . . . 18 71 6.5. TinyIPFIX Data Record Format . . . . . . . . . . . . . . 19 72 7. TinyIPFIX Mediation . . . . . . . . . . . . . . . . . . . . . 19 73 7.1. Expanding the Message header . . . . . . . . . . . . . . 21 74 7.2. Translating the Set Headers . . . . . . . . . . . . . . . 22 75 7.3. Expanding the Template Record Header . . . . . . . . . . 23 76 8. Template Management . . . . . . . . . . . . . . . . . . . . . 23 77 8.1. TCP / SCTP . . . . . . . . . . . . . . . . . . . . . . . 23 78 8.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 9. Security considerations . . . . . . . . . . . . . . . . . . . 24 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 81 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 12.1. Norminative References . . . . . . . . . . . . . . . . . 24 84 12.2. Informative References . . . . . . . . . . . . . . . . . 25 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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 some kind of central analysis 92 device. The meters used to build such networks are usually equipped 93 with low-cost and low-power hardware. This leads to constraints in 94 computational 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 to re-charge themselves. In 98 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 autonomically from the meters to 103 one or more collectors, is suitable for reporting metering data in 104 such networks. 106 TinyIPFIX is derived from IPFIX [RFC7101] 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 [RFC7101] 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 The term smart meter is used to refer to constrained devices like 135 wireless senor nodes, motes or any other kind of small constraint 136 device that can be part of a network that is based on IEEE802.15.4 137 and 6LoWPAN [RFC4944]. 139 Most of the terms used in this draft are defined in [RFC7101]. All 140 these terms are written with their first letter being capitalized. 141 Most of the terms that are defined for IPFIX can be used to describe 142 TinyIPFIX. The term "TinyIPFIX" is used in front of the IPFIX term 143 to distinguish between the IPFIX version and the TinyIPFIX version. 145 This draft uses the term IPFIX to refer to IPFIX as per RFC 7101 and 146 the term TinyIPFIX for the IPFIX version defined in this draft. 148 The terms IPFIX Message, IPFIX Device, Set, Data Set, Template Set, 149 Data Record, Template Record, Collecting Process, Collector, 150 Exporting Process and Exporter are defined as in [RFC7101]. The term 151 IPFIX Mediator is defined in [RFC5982]. The terms Intermediate 152 Process, IPFIX Proxy, IPFIX Concentrator are defined in [RFC6183]. 154 All these terms above have been adapted from the IPFIX definitions. 155 As they keep a similar notion but in a different context of 156 constrained networks, the term "TinyIPFIX" now complements the 157 defined terms. 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 a smart metering device that contains at 167 least one 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 Collector or one or more TinyIPFIX Exporter. 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 tempering 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 Concentrator. 194 TinyIPFIX Message 196 The TinyIPFIX Message is a message originated by a TinyIPFIX 197 Exporter. It is composed of a TinyIPFIX Message Header and one or 198 more TinyIPFIX Sets. The TinyIPFIX Message Format is defined in 199 Section 6. 201 TinyIPFIX Data Record 203 A TinyIPFIX Data Record equals a Data Record in [RFC7101]. The 204 term is used to distinguish between IPFIX and TinyIPFIX throughout 205 the document. 207 TinyIPFIX Template Record 209 A TinyIPFIX Template Record is similar to a Template Record. The 210 Template Record Header is substituted with a TinyIPFIX Template 211 Record Header and is otherwise equal to a Template Record. See 212 Section 6.3. 214 TinyIPFIX Set 216 The TinyIPFIX Set is a group of TinyIPFIX Data Records or 217 TinyIPFIX Template Records with a TinyIPFIX Set Header. Its 218 format is defined in Section 6.2. 220 TinyIPFIX Data Set 222 The TinyIPFIX Data Set is a TinyIPFIX Set that contains TinyIPFIX 223 Data Records. 225 TinyIPFIX Template Set 227 A TinyIPFIX Template Set is a TinyIPFIX Set that contains 228 TinyIPFIX Template Records. 230 TinyIPFIX Intermediate Process 232 A TinyIPFIX Intermediate Process is an Intermediate Process that 233 can handle TinyIPFIX Messages. 235 TinyIPFIX Proxy 237 A TinyIPFIX Proxy is an IPFIX Proxy that can handle TinyIPFIX 238 Messages. 240 TinyIPFIX Concentrator 241 A TinyIPFIX Concentrator is an IPFIX Concentrator that can handle 242 TinyIPFIX Messages. 244 A TinyIPFIX Transport Session is defined by the communication between 245 a TinyIPFIX Exporter (identified by an 6LowPAN-Address, the Transport 246 Protocol, and the Transport Port) and a TinyIPFIX Collector 247 (identified by the same properties). 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 251 document are to be interpreted as described in [RFC2119]. 253 3. Constraints 255 3.1. Hardware constraints 257 The target devices for TinyIPFIX are usually equipped with low-cost 258 hardware and therefore face several constraints concerning CPU and 259 memory [Schmitt09]. For example, the IRIS mote from Crossbow 260 Technologies Inc. has a size of 58 x 32 x 7 mm (without a battery 261 pack) [Crossbow]. Thus, there is little space for micro controller, 262 flash memory (128 kb) and radio frequency transceiver, which are 263 located on the board. 265 Network protocols used on such hardware need to respect these 266 constraints. They must be simple to implement using little code and 267 little run time memory and should produce little overhead when 268 encoding the application payload. 270 3.2. Energy constraints 272 Smart meters that are battery powered have hard energy constraints 273 [Schmitt09]. By power supply of two 2 AA 2,800-mAh batteries this 274 means approximately 30,240J. If they run out of power, their battery 275 has to be changed, which means physical manipulation to the device is 276 necessary. Using as little energy as possible for network 277 communication is therefore desired. 279 A smart metering device can save a lot of energy, if it powers down 280 its radio frequency transceiver. Such devices do not have permanent 281 network connectivity but are only part of the network as needed. A 282 push protocol, where only one side is sending data, is suitable for 283 transmitting application data under such circumstances. As the 284 communication is unidirectional, a meter can completely power down 285 its radio frequency transceivers as long as it does not have any data 286 to sent. If the metering device is able to keep a few measurements 287 in memory, and if real time metering is not a requirement, the 288 TinyIPFIX Data Records can be pushed less frequently. Therefore, 289 saving some more energy on the radio frequency transceivers. 291 3.3. Packet size constraints 293 TinyIPFIX is mainly targeted for the use in 6LoWPAN networks, which 294 are based on IEEE 802.15.4 [RFC4944]. However, the protocol can also 295 be used to transmit data in other networks. IEEE 802.15.4 defines a 296 maximum frame size of 127 octets, which usually leaves 102 octets for 297 user data. IPv6 on the other hand defines a minimum MTU of 1280 298 octets. Hence, fragmentation has to be implemented in order to 299 transmit such large packets. While fragmentation allows the 300 transmission of large messages, its use is problematic in networks 301 with high packet loss because the complete message has to be 302 discarded if only a single fragment gets lost. 304 TinyIPFIX enhances IPFIX by a header compression scheme, which allows 305 to reduce the overhead from header sizes significantly. 306 Additionally, the overall TinyIPFIX Message size is reduced, which 307 reduces the need for fragmentation. 309 3.4. Transport protocol constraints 311 The IPFIX standard [RFC7101] defines several transport protocol 312 bindings for the transmission of IPFIX Messages. SCTP support is 313 REQUIRED for any IPFIX Device to achieve standard conformance 314 [RFC7101], and its use is highly recommended. However, sending IPFIX 315 over UDP and TCP MAY also be implemented. 317 This transport protocol recommendation is not suitable for TinyIPFIX. 318 A header compression scheme that allows to compress an IPv6 header 319 from 40 octets down to 2 octets is defined in 6LoWPAN. There is a 320 similar compression scheme for UDP, but there is no such compression 321 for TCP or SCTP headers. If header compression can be employed, more 322 space for application payload is available. 324 Using UDP on the transport layer for transmitting IPFIX Messages is 325 therefore recommended. Furthermore, TCP or SCTP are currently not 326 supported on some platforms, like on TinyOS [Harvan08]. Hence, UDP 327 may be the only option. 329 Every TinyIPFIX Exporter and Collector MUST implement UDP transport 330 layer support for transmitting data in a constrained network 331 environment. It MAY also offer TCP or SCTP support. However, using 332 these protocols is NOT RECOMMENDED as their use will consume more 333 power and reduces the available size of application payload compared 334 to the use of UDP. If TinyIPFIX is transmitted over a non- 335 constrained network, using SCTP as a transport layer protocol is 336 RECOMMENDED. 338 4. Application scenarios for TinyIPFIX 340 TinyIPFIX is derived from IPFIX [RFC7101] and is therefore a 341 unidirectional push protocol. This means all communication that 342 employs TinyIPFIX is unidirectional from an Exporting Process to a 343 Collecting Process. Hence, TinyIPFIX only fits for application 344 scenarios where meters transmit data to one or more Collectors. 346 If TinyIPFIX is used over UDP, as recommended, packet loss can occur. 347 Furthermore, if an initial Template Message gets lost, and is 348 therefore unknown to the Collector, all TinyIPFIX Data Sets that 349 reference this Template cannot be decoded. Hence, all these Messages 350 are lost if they are not cached by the Collector. It should be clear 351 to an application developer, that TinyIPFIX can only be used over UDP 352 if these TinyIPFIX Message losses are not a problem. 354 TinyIPFIX over UDP is especially not a suitable protocol for 355 applications where sensor data trigger policy decisions or 356 configuration updates for which packet loss is not tolerable. 358 Applications that use smart sensors for accounting purposes for long 359 time measurements can benefit from the use of TinyIPFIX. One 360 application for IPFIX can be long term monitoring of large physical 361 volumes. In [Tolle05], Tolle et al. built a system for monitoring a 362 "70-meter tall redwood tree, at a density interval of 5 minutes in 363 time and 2 meters in space". The sensor node infrastructure was 364 deployed to measure the air temperature, relative humidity and 365 photosynthetically active solar radiation over a long time period. 367 Deploying TinyIPFIX in such scenarios seems to be a good fit. The 368 sensors of the TinyIPFIX Smart Meter can be queried over several 5 369 minute time intervals and the query results can be aggregated into a 370 single TinyIPFIX Message. As soon as enough query results are stored 371 in the TinyIPFIX Message, e.g. if the TinyIPFIX Message size fills 372 the available payload in a single IEEE 802.15.4 packet, the wireless 373 transceiver can be activated and the TinyIPFIX Message can be 374 exported to a TinyIPFIX Collector. 376 Similar sensor networks have been built to monitor the habitat of 377 animals, e.g. in the "Great Duck Island Project" [GreatDuck], 378 [SMPC04]. The purpose of the sensor network was to monitor the birds 379 by deploying sensors in and around their burrows. The measured 380 sensor data was collected and stored in a database for offline 381 analysis and visualization. Again, the sensors can perform their 382 measurements periodically, aggregate the sensor data and export them 383 to a TinyIPFIX Collector. 385 Other application scenarios for TinyIPFIX could be applications where 386 sensor networks are used for long term structural health monitoring 387 in order to investigate long term weather conditions on the structure 388 of a building. For example, a smart metering network has been built 389 to monitor the structural health of the Golden Gate Bridge [Kim07]. 390 If a sensor network is deployed to perform a long term measurement of 391 the structural integrity, TinyIPFIX can be used to collect the sensor 392 measurement data. 394 If an application developer wants to decide whether to use TinyIPFIX 395 for transmitting data from smart meters, he must take the following 396 considerations into account: 398 1. The application must require a push protocol. It is not possible 399 to request data from a smart meter. The TinyIPFIX Smart Meter 400 decides for itself when to send its metering data. 402 2. The property above allows a TinyIPFIX Smart Meter to turn off its 403 wireless device in order to save energy, as it does not have to 404 receive any data. 406 3. If real-time is not required, the application might benefit from 407 accumulated several measurements into a single TinyIPFIX Message. 408 TinyIPFIX easily allows the aggregation of several into a single 409 TinyIPFIX Message (or a single packet). This aggregation can 410 happen on the TinyIPFIX Smart Meter that aggregates several of 411 its own measurements. Or it can happen within a multi-hop 412 wireless network where one IPFIX Proxy aggregates several 413 TinyIPFIX Messages into a single TinyIPFIX Message before 414 forwarding them. 416 4. The application must accept potential packet loss. TinyIPFIX 417 only fits for applications where metering data is stored for 418 accounting purposes and not for applications where the sensor 419 data triggers configuration changes or policy decisions (except: 420 if Message loss is acceptable for some reason). 422 5. Architecture for TinyIPFIX 424 The TinyIPFIX architecture is similar to the IPFIX architecture which 425 is described in [RFC5470]. The most common deployment of TinyIPFIX 426 Smart Meters is shown in Figure 1. 428 +----------------+ +----------------+ 429 |[*Application 1]| ... |[*Application n]| 430 +--------+-------+ +-------+--------+ 431 ^ ^ 432 | | 433 +----------+----------+ 434 ^ 435 | 436 +------------------------+ +--------+-------------------+ 437 | TinyIPFIX S.M. | TinyIPFIX | TinyIPFIX Collector | 438 | [Exporting Process] |----------->| [Collecting Process(es)] | 439 +------------------------+ +----------------------------+ 441 Figure 1: Direct transmission between sensors and applications 443 A TinyIPFIX Smart Meter (S.M.) queries its internal sensors to 444 retrieve the sensor data. It then encodes the results into a 445 TinyIPFIX Message and exports this TinyIPFIX Message to one or more 446 TinyIPFIX Collectors. The TinyIPFIX Collector runs one or more 447 applications that process the collected sensor data. The TinyIPFIX 448 Collector can be deployed on non-constrained devices at the 449 constrained network border. 451 A second way to deploy TinyIPFIX Smart Meter can employ aggregation 452 on TinyIPFIX Messages during their journey through the constrained 453 network as shown in Figure 2. This aggregation can be performed by 454 special TinyIPFIX Smart Meter that act as TinyIPFIX Concentrators. 455 Such devices must have enough resources to perform the aggregation. 457 +-------------------------+ +------------------------+ 458 | TinyIPFIX S.M. | TinyIPFIX | TinyIPFIX Concentrator | 459 | [Exporting Process] |----------------->| [Collecting Process] | 460 +-------------------------+ +-------->| [Exporting Process] | 461 | +------------------------+ 462 +-------------------------+ | | 463 | TinyIPFIX S.M. | | TinyIPFIX| 464 | [Exporting Process] |--------+ | 465 +-------------------------+ v 466 +-------+------------------+ 467 | Collector(1) | 468 | [Collecting Process(es)] | 469 +--------------------------+ 471 Figure 2: Aggregation on TinyIPFIX 473 TinyIPFIX Smart Meters send their data to TinyIPFIX Concentrator 474 which needs to have enough storage space to store the incoming data. 475 It may also aggregate the incoming data with its own measurement 476 data. The aggregated data can then be re-exported again to one or 477 more Collectors. 479 The last deployment, shown in Figure 3, employs another TinyIPFIX 480 Mediation process. 482 +------------------------+ +------------------------+ 483 | TinyIPFIX S.M | TinyIPFIX | TinyIPFIX Proxy | 484 | [Exporting Process] |----------------->| [Collecting Process] | 485 +------------------------+ | [Exporting Process] | 486 +------------------------+ 487 | 488 IPFIX | 489 v 490 +--------------------------+ 491 | IPFIX Collector(1) | 492 | [Collecting Process(es)] | 493 +--------------------------+ 495 Figure 3: Aggregation on TinyIPFIX 497 The TinyIPFIX Smart Meters transmit their TinyIPFIX Messages to one 498 node, e.g. the base station, which translates the TinyIPFIX Messages 499 to IPFIX Messages. The IPFIX Messages can then be exported into an 500 existing IPFIX infrastructure. The Mediation process from TinyIPFIX 501 to IPFIX is described in Section 7. 503 6. TinyIPFIX Message Format 505 A TinyIPFIX IFPIX Message starts with a TinyIPFIX Message Header, 506 followed by one or more TinyIPFIX Sets. The TinyIPFIX Sets can be 507 any of the possible two types: TinyIPFIX Template Set and TinyIPFIX 508 Data Set. A TinyIPFIX Message MUST only contain one type of 509 TinyIPFIX Set. The format of the TinyIPFIX Message is shown in 510 Figure 4 511 +----------------------------------------------------+ 512 | TinyIPFIX Message Header | 513 +----------------------------------------------------+ 514 | TinyIPFIX Set | 515 +----------------------------------------------------+ 516 | TinyIPFIX Set | 517 +----------------------------------------------------+ 518 ... 519 +----------------------------------------------------+ 520 | TinyIPFIX Set | 521 +----------------------------------------------------+ 523 Figure 4: TinyIPFIX Message Format 525 6.1. TinyIPFIX Message Header 527 The TinyIPFIX Message Header is derived from the IPFIX Message 528 Header, with some optimization using field compression. The IPFIX 529 Message Header from [RFC7101] is shown in Figure 5. 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Version Number | Length | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Export Time | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Sequence Number | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Observation ID | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Figure 5: IPFIX Message Header 545 The length of the IPFIX Message Header is 16 octets and every IPFIX 546 Message has to be started with it. The TinyIPFIX Message Header 547 needs to be smaller due to the packet size constraints discussed in 548 Section 3.3. TinyIPFIX introduces a TinyIPFIX Message Header that 549 has a smaller size. The TinyIPFIX header consists of a fixed part of 550 three octets and a variable length "Remaining Header" as shown in 551 Figure 6. 553 0 1 554 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 555 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 556 |E1|E2| SetID | Length | 557 | | | Lookup | | 558 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 559 | Sequence | Ext. Sequence | 560 | Number | Number | 561 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 562 | Ext. SetID | 563 +--+--+--+--+--+--+--+--+ 565 Figure 6: Format of the TinyIPFIX Message header 567 The first part has a fixed length of thre octets and consists of the 568 "E1" field (1 bit), the "E2" field (1 bit), the "SetID Lookup" field 569 (4 bit), the "Length" field (10 bit), and the "Sequence Number" field 570 (8 bit). The second part (the "Remaining Header") has a variable 571 length. Its length is defined by the "E1" and "E2" field in the 572 fixed header part. The four variants are illustrated in the figures 573 below. 575 0 1 576 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 577 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 578 |0 |0 | SetID | Length | 579 | | | Lookup | | 580 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 581 | Sequence | 582 | Number | 583 +--+--+--+--+--+--+--+--+ 585 Figure 7: TinyIPFIX Message Header format if E1 = E2 = 0 587 0 1 588 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 589 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 590 |1 |0 | SetID | Length | 591 | | | Lookup | | 592 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 593 | Sequence | Ext. SetID | 594 | Number | | 595 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 597 Figure 8: TinyIPFIX Message Header format if E1 = 1 and E2 = 0 599 0 1 600 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 601 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 602 |0 | 1| SetID | Length | 603 | | | Lookup | | 604 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 605 | Sequence | Ext. Sequence | 606 | Number | Number | 607 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 609 Figure 9: TinyIPFIX Message Header format if E1 = 0 and E2 = 1 611 0 1 612 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 613 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 614 |1 |1 | SetID | Length | 615 | | | Lookup | | 616 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 617 | Sequence | Ext. Sequence | 618 | Number | Number | 619 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 620 | Ext. SetID | 621 +--+--+--+--+--+--+--+--+ 623 Figure 10: TinyIPFIX Message Header format if E1 = E2 = 1 625 The fixed header fields are defined as follows [kothmayr10] 626 [schmitt2014]: 628 E1 and E2 629 The bits marked "E1" and "E2" control the presence of the file 630 "Ext. SetID" and the length of the field "Ext. Sequence Number" 631 respectively. In case E1 = E2 = 0 the TinyIPFIX message header 632 has the format as shown in Figure 7. No Ext. Sequence Number and 633 Ext. SetID are required. In case E1 = 1, custom SetIDs can be 634 specified in the extended SetID field (cf. Figure 8.) When 635 evaluated, the value specified in the extended SetID field is 636 shifted left by 8 bits to prevent collisions with the reserved 637 SetIDs 0-255. To reference these, shifting can be disabled by 638 setting all SetID lookup bits to 1. Depending on the application 639 sampling rates might be larger than in typical WSNs and, thus, 640 they may have a large quantity of records per packet. In order to 641 make TinyIPFIX applicable for those cases E2 = 1 is set (cf. 642 Figure 9.) This means the Ext. Sequence Number field is available 643 offering 8-bit more sequence numbers as usual. Depending on the 644 WSN settings the also the combination E1 = E2 = 1 is possible 645 resulting in the maximum TinyIPFIX Message header shown in 646 Figure 10where Ext. Sequence Number field and Ext. SetID field are 647 required. 649 SetID Lookup 651 This field acts as a lookup field for the SetIDs and provides 652 shortcuts to often used SetIDs. So far only four values are 653 defined: Value = 0 means Lookup extended SetID field, Shifting 654 enabled. Value = 1 means SetID = 2 and message contains a 655 Template definition. Value = 2 means SetID = 256 and message 656 containts Data Record for Template 256. This places special 657 importance on a single template ID, but since most sensor nodes 658 only define a single template directly after booting and continue 659 to stream data with this template ID during the whole session 660 lifetime, this shorthand is useful for this case. Value = 3-14 661 means SetIDs are reserved for future extensions. Value = 15 means 662 Lookup extended SetID field, shiftig enabled. 664 Length 666 The length field has a fixed length of 10 bits. 668 Sequence Number 670 Due to the low sampling rate in typical WSNs, the "Sequence 671 Number" field is only one byte long. However, some applications 672 may have a large quantity of records per packet. In this case the 673 sequence field can be extended to 16 bit by setting the E2-bit to 674 1. 676 Since TinyIPFIX packets are always transported via a network 677 protocol, which specifies the source of the packet, the "Observation 678 Domain" can be equated with the source of a TinyIPFIX packet and the 679 field can be dropped from the header. Should applications require 680 several Observation Domains the information can be included in the 681 TinyIPFIX data message. The version field has been dropped since the 682 SetID lookup field provides room for future extensions. The 683 specification of a 32 bit time stamp in seconds would require the 684 time synchronization across a wireless sensor network and produces 685 too much overhead. Thus, the "Export Time" field is dropped. If 686 applications should require the specification of time it can be sent 687 as part of the TinyIPFIX data message. 689 6.2. TinyIPFIX Set 691 A TinyIPFIX Set is a set of TinyIPFIX Template or TinyIPFIX Data 692 Records. Depending on the TinyIPFIX Record type, the TinyIPFIX Set 693 can either be a TinyIPFIX Template Set or a TinyIPFIX Data Set. 694 Every TinyIPFIX Set is started with a TinyIPFIX Set Header and is 695 followed by one or more TinyIPFIX Records. 697 The IPFIX Set Header consists of an two octet "Set ID" field and a 698 two octet "Length" field. These two fields are compressed to one 699 octet each for the TinyIPFIX Set Header. The format of the TinyIPFIX 700 Set Header is shown in Figure 11. 702 0 1 703 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Comp. Set ID | Length | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Figure 11: TinyIPFIX Set Header 710 The two fields are defined as follows: 712 TinyIPFIX Set ID 714 The "TinyIPFIX Set ID" (Comp. Set ID) identifies the type of data 715 that is transported in the TinyIPFIX Set. A TinyIPFIX Template 716 Set is identified by TinyIPFIX Set ID 2. This corresponds to the 717 Set IDs that are used by Sets in IPFIX. TinyIPFIX Set ID number 3 718 MUST NOT be used. All values from 4 to 127 are reserved for 719 future use. Values above 127 are used for TinyIPFIX Data Sets. 721 Length 722 The "Length" Field contains the total length of the TinyIPFIX Set, 723 including the TinyIPFIX Set Header. 725 6.3. TinyIPFIX Template Record Format 727 The format of the TinyIPFIX Template Records is shown in Figure 12. 728 The TinyIPFIX Template Record starts with a TinyIPFIX Template Record 729 Header and is followed by one or more Field Specifiers. The Field 730 Specifier format is defined as in Section 6.4 and is identical to the 731 Field Specifier definition in [RFC7101]. 733 +--------------------------------------------------+ 734 | TinyIPFIX Template Record Header | 735 +--------------------------------------------------+ 736 | Field Specifier | 737 +--------------------------------------------------+ 738 | Field Specifier | 739 +--------------------------------------------------+ 740 ... 741 +--------------------------------------------------+ 742 | Field Specifier | 743 +--------------------------------------------------+ 745 Figure 12: TinyIPFIX Template Format 747 The format of the TinyIPFIX Template Record Header is shown in 748 Figure 13. 750 0 1 751 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Comp. Temp ID | Field Count | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 Figure 13: TinyIPFIX Template Record Header 758 TinyIPFIX Template ID 760 Each TinyIPFIX Template Record must have a unique TinyIPFIX 761 Template ID (Comp. Temp ID) between 128 and 255. The TinyIPFIX 762 Template ID must be unique for the given TinyIPFIX Transport 763 Session. 765 Field Count 766 The number of fields placed in the TinyIPFIX Template Record. 768 6.4. Field Specifier Format 770 The type and length of the transmitted data is encoded in Field 771 Specifiers within TinyIPFIX Template Records. The Field Specifier is 772 shown in Figure 14 and is identical with the Field Specifier that was 773 defined for IPFIX [RFC7101]. The following text has been copied from 774 [RFC7101] for completeness. 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 |E| Information Element ident. | Field Length | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Enterprise Number | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 Figure 14: TinyIPFIX Dta Field Specifier 786 Where: 788 E 790 Enterprise bit. This is the first bit of the Field Specifier. If 791 this bit is zero, the Information Element Identifier identifies an 792 IETF-specified Information Element, and the four-octet Enterprise 793 Number field MUST NOT be present. If this bit is one, the 794 Information Element Identifier identifies an enterprise-specific 795 Information Element, and the Enterprise Number field MUST be 796 present. 798 Information Element Identifier 800 A numeric value that represents the type of Information Element. 802 Field Length 804 The length of the corresponding encoded Information Element, in 805 octets. Refer to [RFC7012]. The value 65535 is illegal as there 806 are no variable size encoded elements as they are defined in 807 IPFIX. 809 Enterprise Number 810 IANA Private Enterprise Number of the authority defining the 811 Information Element identifier in this Template Record. 813 Vendors can easily define their own data model by registering a 814 Enterprise ID with IANA. Using their own Enterprise ID, they can use 815 any ID in the way they want them to use. 817 6.5. TinyIPFIX Data Record Format 819 The Data Records are sent in TinyIPFIX Data Sets. The format of the 820 Data Records is shown in Figure 15 and matches the Data Record format 821 from IPFIX. 823 +--------------------------------------------------+ 824 | Field Value | 825 +--------------------------------------------------+ 826 | Field Value | 827 +--------------------------------------------------+ 828 ... 829 +--------------------------------------------------+ 830 | Field Value | 831 +--------------------------------------------------+ 833 Figure 15: Data Record Format 835 7. TinyIPFIX Mediation 837 There are two types of TinyIPFIX Intermediate Processes. The first 838 one can occur on the transition between a constraint 6LoWPAN and the 839 non-constrained network. This mediation changes the network and 840 transport protocol from 6LowPAN/UDP to IP/(SCTP|TCP|UDP) and is shown 841 in Figure 16. 843 +-----------------------+ TinyIPFIX +-------------------------+ 844 | TinyIPFIX S.M. | 6LoWPAN/UDP | TinyIPFIX mediator | 845 | [Exporting Process] |--------------->| [Collecting Process] | 846 +-----------------------+ | [Exporting Process] | 847 +-------------------------+ 848 | 849 TinyIPFIX | 850 IP/(UDP/SCTP|TCP) | 851 v 852 +--------------------------+ 853 | Collector(1) | 854 | [Collecting Process(es)] | 855 +--------------------------+ 857 Figure 16: Translation from TinyIPFIX over 6LowPAN/UDP to TinyIPFIX 858 over IP/(SCTP|TCP|UDP) 860 The mediator removes the TinyIPFIX Messages from the 6LowPAN/UDP 861 packets and wraps them into the new network and transport protocols. 862 Templates MUST be managed the same way as in the constraint 863 environment after the translation to IP/(SCTP|UDP|TCP) (see 864 Section 8). 866 The second type of mediation transforms TinyIPFIX into IPFIX. This 867 process MUST be combined with the transport protocol mediation as 868 shown in Figure 17. 870 +------------------------+ TinyIPFIX +-----------------------+ 871 | TinyIPFIX S.M. | 6LoWPAN/UDP | IPFIX mediator | 872 |[Exporting Processes] |---------------->| [Collecting Process] | 873 +------------------------+ | [Exporting Process] | 874 +-----------------------+ 875 | 876 IPFIX | 877 IP/(UDP/SCTP|TCP) | 878 v 879 +--------------------------+ 880 | Collector(1) | 881 | [Collecting Process(es)] | 882 +--------------------------+ 884 Figure 17: Transformation from TinyIPFIX to IPFIX 886 This mediation can also be performed by an IPFIX Collector before 887 parsing the IPFIX message as shown in Figure 18. There is no need 888 for a TinyIPFIX IPFIX parser if such a mediation process can be 889 employed in front of an already existing IPFIX collector. 891 +------------------------+ TinyIPFIX +----------------------+ 892 | TinyIPFIX S.M. | 6LoWPAN/UDP | IPFIX Mediator | 893 | [Exporting Processes] |----------------->| [Collecting Process] | 894 +------------------------+ | [Exporting Process] | 895 | | | 896 | |IPFIX | 897 | | | 898 | v | 899 | Collector(1) | 900 | [Collecting Process] | 901 +----------------------+ 903 Figure 18: Transformation from TinyIPFIX to IPFIX 905 The TinyIPFIX Mediation Process has to translate the TinyIPFIX 906 Message Header, the TinyIPFIX Set Headers and the TinyIPFIX Template 907 Record Header into their counterparts in IPFIX Afterwards, the new 908 IPFIX Message Length needs to be calculated and inserted into the 909 IPFIX Message header. 911 7.1. Expanding the Message header 913 The fields of the IPFIX Message Header that are shown in Figure 5 can 914 be determined as follows: 916 Version 918 This is always 0x000a. 920 Length 922 The IPFIX Message Length can only be calculated after the complete 923 TinyIPFIX Message has been translated. The new length can be 924 calculated by adding the length of the IPFIX Message Header, which 925 is 16 octets, and the length of all Sets that are contained in the 926 IPFIX Message. 928 Export Time 930 If the "Export Time" in the TinyIPFIX Message Header has a length 931 of 4 octets, the value from the TinyIPFIX Message Header MUST be 932 used for the IPFIX Message Header. If it was omitted, the "Export 933 Time" MUST be generated by the Mediator. If the IPFIX Message is 934 exported again, the "Export Time" field MUST contain the time in 935 seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message 936 leaves the Exporter. If the Message is passed to an IPFIX 937 Collector for decoding directly, the "Export Time" field is the 938 time in seconds since 0000 UTC Jan 1 1970 at which the TinyIPFIX 939 Message has been received by the TinyIPFIX Exporter. 941 Sequence Number 943 If the TinyIPFIX Sequence Number has a length of 4 octets, the 944 original value MUST be used for the IPFIX Message. If the 945 TinyIPFIX Sequence Number has a size of one or two octets, the 946 TinyIPFIX Mediator MUST expand the TinyIPFIX Sequence Number into 947 a four octet field. If the TinyIPFIX Sequence Number was omitted, 948 the Mediator needs to calculate the Sequence Number as per 949 [RFC7101]. 951 Observation Domain ID 953 Since the Observation Domain ID is used to scope templates in 954 IPFIX, it MUST be set to a unique value per TinyIPFIX Exporting 955 Process, using either a mapping algorithmically determined by the 956 Intermediate Process or directly configured by an administrator. 958 7.2. Translating the Set Headers 960 Both fields in the TinyIPFIX Set Header have a size of one octet and 961 need to be expanded: 963 Set ID 965 The field needs to be expanded from one octet to two octets. If 966 the Set ID is below 128, no recalculation needs to be performed. 967 This is because all IDs below 128 are reserved for special 968 messages and match the IDs used in IPFIX. The TinyIPFIX Set IDs 969 starting with 128 identify TinyIPFIX Data Sets. Therefore, every 970 TinyIPFIX Set ID above 127 needs to be incremented by 128 because 971 IPFIX Data Set IDs are located above 255. 973 Set Length 975 The field needs to be expanded from one octet to two octets. It 976 needs to be recalculated by adding a value of 2 octet to match the 977 additional size of the Set Header. For each TinyIPFIX Template 978 Record that is contained in the TinyIPFIX Set, 2 more octets need 979 to be added to the length. 981 7.3. Expanding the Template Record Header 983 Both fields in the TinyIPFIX Template Record Header have a length of 984 one octet and therefore need translation: 986 Template ID 988 The field needs to be expanded from one octet to two octets. The 989 Template ID needs to be increased by a value of 128. 991 Field Count 993 The field needs to be expanded from one octet to two octets. 995 8. Template Management 997 As with IPFIX, TinyIPFIX templates management depends on the 998 transport protocol used. If TCP or SCTP is used, it can be ensured 999 that TinyIPFIX Templates are delivered reliably. If UDP is used, 1000 reliability cannot be guaranteed, and template loss can occur. If a 1001 Template is lost on its way to the Collector, all following TinyIPFIX 1002 Data Records that refer to this TinyIPFIX Template cannot be decoded. 1003 Template withdrawals are not supported in TinyIPFIX. This is 1004 generally not a problem, because most sensor nodes only define a 1005 single template directly after booting. 1007 8.1. TCP / SCTP 1009 If TCP or SCTP is an option and can be used for the transmission of 1010 TinyIPFIX, Template Management MUST be performed as defined in 1011 [RFC7101] for IPFIX, with the exception of template withdrawals, 1012 which are not supported in TinyIPFIX. Template withdrawals MUST NOT 1013 be sent by TinyIPFIX exporters. 1015 8.2. UDP 1017 All specifications for Template management from [RFC7101] apply 1018 unless specified otherwise in this document. 1020 TinyIPFIX Templates MUST be sent by a TinyIPFIX Exporter before any 1021 TinyIPFIX Data Set that refers to the TinyIPFIX Template is 1022 transmitted. TinyIPFIX Templates are not expected to change over 1023 time in TinyIPFIX. Hence, a TinyIPFIX Template that has been sent 1024 once MAY NOT be withdrawn and MUST NOT expire. If a TinyIPFIX Smart 1025 Meter wants to use another TinyIPFIX Template it MUST use a new 1026 TinyIPFIX Template ID for the TinyIPFIX Template. 1028 As UDP is used, reliable transport of TinyIPFIX Templates cannot be 1029 guaranteed and TinyIPFIX Templates can be lost. A TinyIPFIX Exporter 1030 MUST expect TinyIPFIX Template loss. It MUST therefore re-send its 1031 TinyIPFIX Templates periodically. A TinyIPFIX Template MUST be re- 1032 send after a fixed number of N TinyIPFIX Messages that contained 1033 TinyIPFIX Data Sets that referred to this TinyIPFIX Template. The 1034 number N MUST be configured by the application developer. 1036 9. Security considerations 1038 The same security considerations as for the IPFIX Protocol [RFC7101] 1039 apply. 1041 10. IANA Considerations 1043 This document has no actions for IANA. 1045 11. Acknowledgments 1047 Many thanks to Lothar Braun, Georg Carle, and Benoit Claise, who 1048 contributed significant work to earlier versions especially to the 1049 document entitled "Compressed IPFIX for Smart Meters in Constrained 1050 Networks" (draft-braun-core-compressed-ipfix), of this work. 1052 Many thanks to Thomas Kothmayr, Michael Meister, and Livio Sgier, who 1053 implemented TinyIPFIX for TinyOS 2.x, Contiki 2.7/3.0 (except the 1054 mediator) for different sensor platforms (IRIS, TelosB, and 1055 OpenMote). 1057 12. References 1059 12.1. Norminative References 1061 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1062 Requirement Levels", BCP 14, RFC 2119, 1063 DOI 10.17487/RFC2119, March 1997, 1064 . 1066 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1067 "Transmission of IPv6 Packets over IEEE 802.15.4 1068 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1069 . 1071 [RFC7101] Ginoza, S., "List of Internet Official Protocol Standards: 1072 Replaced by a Web Page", RFC 7101, DOI 10.17487/RFC7101, 1073 December 2013, . 1075 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 1076 for IP Flow Information Export (IPFIX)", RFC 7012, 1077 DOI 10.17487/RFC7012, September 2013, 1078 . 1080 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 1081 "Architecture for IP Flow Information Export", RFC 5470, 1082 DOI 10.17487/RFC5470, March 2009, 1083 . 1085 [RFC5982] Kobayashi, A., Ed. and B. Claise, Ed., "IP Flow 1086 Information Export (IPFIX) Mediation: Problem Statement", 1087 RFC 5982, DOI 10.17487/RFC5982, August 2010, 1088 . 1090 [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, 1091 "IP Flow Information Export (IPFIX) Mediation: Framework", 1092 RFC 6183, DOI 10.17487/RFC6183, April 2011, 1093 . 1095 12.2. Informative References 1097 [Schmitt09] 1098 Schmitt, C. and G. Carle, "Applications for Wireless 1099 Sensor Networks", In Handbook of Research on P2P and Grid 1100 Systems for Service-Oriented Computing: Models, 1101 Methodologies and Applications, Antonopoulos N.; 1102 Exarchakos G.; Li M.; Liotta A. (Eds.), Information 1103 Science Publishing. , 2010. 1105 [Tolle05] Tolle, G., Polastre, J., Szewczyk, R., Turner, N., Tu, K., 1106 Buonadonna, P., Burgess, S., Gay, D., Hong, W., Dawnson, 1107 T., and D. Culler, "A macroscope in the redwoods", In the 1108 Proceedings of the 3rd ACM Conference on Embedded 1109 Networked Sensor Systems (Sensys 05), San Diego, ACM 1110 Press , November 2005. 1112 [Kim07] Kim, S., Pakzad, S., Culler, D., Demmel, J., Fenves, G., 1113 Glaser, S., and M. Turon, "Health Monitoring of Civil 1114 Infrastructure Using Wireless Sensor Networks", In the 1115 Proceedings of the 6th International Conference on 1116 Information Processing in Sensor Networks (IPSN 2007), 1117 Cambridge, MA, ACM Press, pp. 254-263 , April 2007. 1119 [SMPC04] Szewczyk, R., Mainwaring, A., Polastre, J., and D. Culler, 1120 "An analysis of a large scale habitat monitoring 1121 application", The Proceedings of the Second ACM Conference 1122 on Embedded Networked Sensor Systems (SenSys 04) , 1123 November 2004. 1125 [GreatDuck] 1126 Habitat Monitoring on Great Duck Island, , 1127 "http://www.greatduckisland.net", The Proceedings of the 1128 Second ACM Conference on Embedded Networked Sensor Systems 1129 (SenSys 04) , November 2004. 1131 [Harvan08] 1132 Harvan, M. and J. Schoenwaelder, "TinyOS Motes on the 1133 Internet: IPv6 over 802.15.4 (6lowpan)", 2008. 1135 [Crossbow] 1136 Crossbow Technologies Inc., , "http://www.xbow.com", 2010. 1138 [kothmayr10] 1139 Kothmayr, T., "Data Collection in Wireless Sensor Networks 1140 for Autonomic Home Networking", Bachelor Thesis, Technical 1141 University of Munich, Germany , 2010. 1143 [schmitt2014] 1144 Schmitt, C., Kothmayr, T., Ertl, B., Hu, W., Braun, L., 1145 and G. Carle, "TinyIPFIX: An Efficient Application 1146 Protocol for Data Exchange in Cyber Physical Systems", 1147 Computer Communications, ELSEVIER, DOI: 10.1016/ 1148 j.comcom.2014.05.012 , 2014. 1150 Authors' Addresses 1152 Corinna Schmitt 1153 University of Zurich 1154 Department of Informatics 1155 Communication Systems Group 1156 Binzmuehlestrasse 14 1157 Zurich 8050 1158 Switzerland 1160 Email: schmitt@ifi.uzh.ch 1161 Burkhard Stiller 1162 University of Zurich 1163 Department of Informatics 1164 Communication Systems Group 1165 Binzmuehlestrasse 14 1166 Zurich 8050 1167 Switzerland 1169 Email: stiller@ifi.uzh.ch 1171 Brian Trammell 1172 Swiss Federal Institute of Technology 1173 Gloriastrasse 35 1174 Zurich 8092 1175 Switzerland 1177 Email: ietf@trammell.ch