idnits 2.17.1 draft-schmitt-6lowapp-ipfix-ws-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 73 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2009) is 5306 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4919' is defined on line 583, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 6lowapp C.Schmitt 2 Internet Draft L.Braun 3 Intended status: Informational G.Carle 4 Expires: March 2010 TU Muenchen 5 October 15, 2009 7 IPFIX for Wireless Sensors 8 draft-schmitt-6lowapp-ipfix-ws-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 13th, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 In this draft we want to introduce an idea to develop a protocol for 47 efficient data transmission for Wireless Sensors using the ideas of 48 IPFIX. We will call this protocol IPFIX-WS. 50 Table of Contents 52 1. Introduction...................................................2 53 1.1. Document structure........................................3 54 2. Conventions used in this document..............................3 55 3. Hardware Requirements..........................................3 56 4. IPFIX Protocol for Wireless Sensors............................4 57 4.1. IPFIX Standard - RFC 5101.................................4 58 4.2. IPFIX-WS..................................................4 59 4.3. Technical details for IPFIX-WS............................5 60 5. Integration of Wireless Sensors in Home Networks...............6 61 5.1. Hardware setting for test scenario........................6 62 5.2. Testbed results...........................................6 63 5.3. Planned add-ons for IPFIX-WS..............................9 64 6. Formal Syntax.................................................12 65 7. Security Considerations.......................................13 66 8. IANA Considerations...........................................13 67 9. Conclusions...................................................13 68 10. References...................................................14 69 10.1. Normative References....................................14 70 10.2. Informative References..................................15 71 Authors' Addresses...............................................16 73 1. Introduction 75 Today everyone calls for new approaches for data acquisition in real- 76 time. Different challenging requirements must be solved, such as 77 efficient collection of environmental data using Wireless Sensors and 78 efficient data transmission due to hardware limitations. Constraints 79 on size, energy consumption and price lead to very limited memory, 80 computational and communications resources. The desire for sensor 81 nodes to be operational for a long time without external 82 intervention, such as exchange of the batteries, which are often the 83 only source of energy, leads to additional restrictions in the usage 84 of the resources. Some research is done to address the issue of the 85 sole dependency on battery power, but for now it remains the 86 prevalent source of energy for WSNs. The physical size of a sensor 87 node is another limiting factor. The IRIS mote which is used in our 88 setup has the dimensions of 58 x 32 x 7 mm, without the battery pack. 89 Thus it does not leave much room for the micro controller, flash 90 memory (128 kb) and RF transceiver, all of which are located on this 91 board. 93 To satisfy those needs, standard protocols for efficient data 94 transmission from common networks, such as the IP Flow Information 95 Export (IPFIX) protocol, should be adapted to the equipment of 96 Wireless Sensors. Another possibility is to reduce the data amount by 97 implementing in-network data aggregation functionality. The most 98 important thing is to develop these approaches while still providing 99 interoperability between devices of different vendors. 101 1.1. Document structure 103 This draft will describe the idea to adapt the common IPFIX protocol 104 to the requirements of Wireless Sensor technology. The resources are 105 limited and the most important aspect is saving energy. Thus, the 106 data should be transmitted efficiently to save energy costs. In the 107 upcoming sections we want to introduce the IPFIX protocol for common 108 networks followed by modifications for wireless sensors. A 109 description of current implementation approaches and planned add-ons 110 will follow. Finally, security and IANA considerations are mentioned 111 as well as a conclusion. 113 2. Conventions used in this document 115 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 116 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 117 document are to be interpreted as described in RFC-2119 [RFC2119]. 119 3. Hardware Requirements 121 As mentioned before, Wireless Sensors should be used for collecting 122 environmental data. They have many hardware requirements themselves, 123 but the requirements of the application scenario also have to be kept 124 in mind. On the hardware side, energy and computing capacity, as well 125 as the space on the platforms are limited [1]. According to the 126 application scenarios the sensors will be equipped with a different 127 amount and types of sensors (e.g. for temperature, humidity, seismic 128 data). 130 4. IPFIX Protocol for Wireless Sensors 132 4.1. IPFIX Standard - RFC 5101 134 The IP Flow Information export (IPFIX) protocol was standardized 135 under the RFC 5101 [RFC5101] and developed for common networks to 136 transmit data efficiently. IPFIX itself is a PUSH-protocol. That 137 means an exporter periodically transmits data to one or more 138 collectors. The communication is template based. Before the data 139 itself is transmitted a template is sent to declare how upcoming data 140 has to be decoded. Thus, meta information is sent only once and for 141 decoding there only need to be moved some pointers over the data. 142 Finally, the processing needs are low. To make the transmission more 143 efficient, data aggregation can be added. 145 Today the IPFIX protocol is used for network monitoring in common 146 networks. These networks have different observation points and the 147 hardware has no limited resources. In such networks IP flows pass 148 through the different elements of the observed network. Due to 149 security reasons it is interesting and useful to observe these flows. 150 In this case the IPFIX Collecting process allows the user to verify 151 different observation points of interest in the network. At this 152 point the user is able to observe irregularities in traffic 153 [RFC5101]. 155 4.2. IPFIX-WS 157 As mentioned before, Wireless Sensors have different requirements. 158 The common network protocol IPFIX is not yet adapted to fulfil the 159 requirements of Wireless Sensors. In the first step, type and 160 enterprise IDs must be defined to transmit sensor data measurements 161 using IPFIX. Also new templates must be developed. An example is 162 shown in Figure 1. As a consequence the data amount during 163 transmission will be minimized and energy will be saved. The most 164 important solutions are the data aggregation itself and a data 165 compression [3]. 167 +------------------------------------------------+ 168 | Set ID | Length | 169 +------------------------------------------------+ 170 | Template ID | Field Count | 171 +------------------------------------------------+ 172 | ID: Node ID | Data Length ID: Node ID | 173 +------------------------------------------------+ 174 | Enterprise ID | 175 +------------------------------------------------+ 176 | ID: Time stamp | Data Length ID: Time Stamp | 177 +------------------------------------------------+ 178 | Enterprise ID | 179 +------------------------------------------------+ 180 | ID: Temperature | Data Length ID: Temperature | 181 +------------------------------------------------+ 182 | Enterprise ID | 183 +------------------------------------------------+ 184 | ID: Humidity | Data Length ID: Humidity | 185 +------------------------------------------------+ 186 | Enterprise ID | 187 +------------------------------------------------+ 189 Figure 1: IPFIX-WS Template Set for sensor data 191 4.3. Technical details for IPFIX-WS 193 To apply IPFIX to Wireless Sensors the following tasks should be 194 fulfilled: 196 - gather data from the sensors attached to the node 198 - generate IPFIX packets and transmit them to the base station of 199 the network 201 - perform in-network aggregation to reduce the amount of network 202 traffic and preserve energy 204 - receive and parse IPFIX packets on a Gateway server 206 - Transfer the acquired data to a home network infrastructure. 208 To achieve these goals, different steps must be executed. The mote's 209 sensors are queried periodically to generate new sensor data. These 210 raw values are transmitted to a specially developed tinyIPFIX 211 library. It writes the values to the location specified by an IPFIX 212 template, which was generated automatically when the mote booted. The 213 template specifies the needed raw values. If all of these values are 214 collected and written to the correct position in the respective IPFIX 215 data message, then the IPFIX packet is ready for transmission and 216 sent to the base station via a multihop network. The base station is 217 a special node in the network which is the connection point between a 218 wireless and wired infrastructure. It listens for incoming packets 219 from nodes in the network and transmits their payload to the gateway 220 server over an USB connection. On the gateway a listening program 221 waits for transmissions. The IPFIX messages sent via USB are parsed 222 according to the matching IPFIX templates; their sensor values are 223 extracted and transferred to the home network infrastructure. Here 224 the raw values are converted from their platform specific 225 representation to a platform independent value. For example a 14bit 226 Integer raw value coming from a temperature sensor is converted to a 227 Double whose value is in Celsius. 229 5. Integration of Wireless Sensors in Home Networks 231 Today common Home Networks work with IP addressing. Thus, the 232 Wireless Sensors must be organised in a mesh network using also IPs 233 for communication. For this situation the 6LoWPAN protocol was 234 developed [4]. Additional requirements for connecting both system 235 parts and a seamless integration of the Wireless Sensors into an 236 existing infrastructure must be provided as well as support for 237 devices of different vendors. 239 5.1. Hardware setting for test scenario 241 For our approach we are using IRIS motes from Crossbow Technology 242 Inc. [10]. These motes have limited resources and can cooperate with 243 different sensor boards. Crossbow Technology Inc. offers different 244 sensor boards which include sensors for light, temperature, humidity, 245 barometric pressure, seismic, GPS and others. The motes run TinyOS 246 [11], an open-source and component-based operating system. Current 247 versions of TinyOS are 1.x and 2.x which provided different 248 applications and driver support. 250 5.2. Testbed results 252 Currently the IPFIX-approach was implemented in a network with 3 253 sensor nodes and one base station, and successfully tested in 254 simulations with more nodes. Practical tests are running with the 255 sensor boards MTS300CB and MTS400CB at the moment. The transmitted 256 data in such IPFIX packets consists of values shown in Figure 1. The 257 packet sizes ranges from 34 bytes (data packet) to 72 bytes (template 258 packet), including the IPFIX header. For simplicity, only one data 259 set is sent per transmission. Figure 2 shows an example of an IPFIX- 260 WS Template message and Figure 3 an IPFIX-WS Data message. 262 0 1 2 3 264 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Version Number | Length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Export Time | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Sequence Number | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Observation ID | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Set ID | Length Template | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Template ID | Field Counter | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Information Element ID | Length Data | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Enterprise ID | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | . . . 284 +-+-+-+-+- 286 Figure 2: IPFIX-WS Template Format 288 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Version Number | Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Export Time | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Sequence Number | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Observation ID | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Template ID | Length Data | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Data Payload | Data Payload | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Export Time | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Node ID | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 3: IPFIX-WS Data Format example (Node ID = Observation ID) 311 Parallel, 6LoWPAN was implemented for the platform IRIS using TinyOS 312 2.x based on the work of Harvan and Schoenwaelder [2]. They 313 implemented a 6lowpan/IPv6 stack. The standard 802.15.4 provides two 314 types of addresses (16-bit or 64-bit). Depending on the hardware 315 used, the transmitted payload with 6LoWPAN can be up to 127 bytes. 316 Optimal transmission is gained with 102 bytes payload. With the help 317 of a fragmentation mechanism below the IP layer at least 1280 bytes 318 can be transmitted. In the worst case, the IPv6 header has a size of 319 40 bytes. But the goal is to have as much space as possible for the 320 payload. Thus, a header compression was implemented to compress the 321 header down to 2 bytes. This compression mechanism can also be used 322 for the transmission header like UDP which follows the IPv6 header. 323 It can be compressed from 8 bytes down to 4 bytes. The IPv6 324 compression mechanism is called HC1 and the UDP compression mechanism 325 is called HC_UDP. Figure 4 shows the worst case of transmission with 326 no compression. 328 +---------------------------------------------------------+ 329 | 802.15.4 Header | AM type | HC1 Dispatch | HC1 Header | 330 | (9-25 bytes) | (1 byte)| (1 byte) | (1 byte) | 331 +---------------------------------------------------------+ 332 | Hop Limit | uncompressed IPv6 fields | HC_UDP | 333 | (1 byte) | (~36 bytes) | (1 byte) | 334 +---------------------------------------------------------+ 335 | uncompressed UDP fields | data | 336 | (8 bytes) | (50-66 bytes) | 337 +---------------------------------------------------------+ 338 | 802.15.4 CRC | 339 | (2 bytes) | 340 +---------------+ 342 Figure 4: 6LoWPAN packet format uncompressed [RFC4944] 344 In the worst case, as shown in Figure 4, only 50-66 bytes are left 345 for the data payload depending on the chosen address types in the 346 802.15.4 Header. Thus, compression is very important and in optimal 347 case allows a data payload of 94-110 bytes depending on address types 348 [RFC4944]. 350 The 6LoWPAN approach was also successfully tested in real scenarios 351 using IRIS motes. Currently the payload is simple without using 352 sensor measurements due to driver problems. 354 5.3. Planned add-ons for IPFIX-WS 356 Currently we try to develop a header compression to reduce the header 357 size of each IPFIX message which consists of the IPFIX Message Header 358 and the Set Header as shown in Figure 5. 360 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Version Number | Length | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Export Time | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Sequence Number | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Observation Domain ID | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Set ID | Length | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Figure 5: IPFIX Header Format including Message and Set Header 377 Since IPFIX was designed for conventional networks, some extensions 378 and changes have to be introduced to increase it's efficiency in 379 WSNs. One of the problems when deploying IPFIX in sensor networks is 380 the overhead introduced by the relatively large header which is at 381 least 32 bytes in size (24 bytes from the Message Header + 4 bytes 382 from the Set header) as is shown in Figure 5. Remember, that the 383 maximum size of a packet being transferred with an IEEE 802.15.4 384 network is 127 bytes. To address this issue, a header compression 385 scheme was devised, which will be introduced in this section. 387 The idea behind our approach to header compression is to define the 388 length of the fields separately in a pre header which is shown in 389 Figure 6. First the Version field from the original IPFIX header is 390 shortened to 5 bit, this leaves room for the IPFIX version to 391 increase from version 10 to version 31. The definition of the length 392 of the fields Message Length, Export Time, Sequence Number and 393 Observation Domain ID follows. A value of 0 in the designated bit(s) 394 means that the field is allowed 1 byte in the subsequent header, a 395 value of 1 means 2 bytes, etc.. The next two bits are designated for 396 the template offset. Decoders of IPFIX Messages are expected to keep 397 track of the sequence in which they received templates from the IPFIX 398 exporters. A value of 0 in the template offset bits means that the 399 decoder should use the template it has received last, a value of 1 400 means the template before that and a value of 2 means two templates 401 before the last one. If this offset is given for a data message, two 403 bytes for the Set ID can be saved. If template offset is set to 3 404 (both bits are one) it is ignored and a proper statement of the 405 template ID is expected in the header. The next bit is called the 406 Single Set Flag. It indicates whether the message contains only a 407 single IPFIX set. If this is the case, the explicit statement of set 408 length in the header can be omitted since this value can be computed 409 from the total message length. The last bit in the pre header is the 410 Template Set Flag. If it is set to one, the first set in the message 411 is a template set which is defined to have Set ID = 2. Thus the two 412 bytes for definition of the set ID can be omitted. 414 0 1 416 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Version |L| EX|SN | D |TO |S|T| 420 | Number | | | | | | | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 L = Size of Length Field, EX = Size of Export Time Field, SN = Size 424 of Sequence Number Field, D = Size of Observation Domain ID Field, 425 TO = Template Offset Field, S = Single set Flag, T = Template Set 426 Flag 428 Figure 6: IPFIX pre header defining the length of the subsequent 429 header 431 In the best case scenario all header fields can be fitted to one byte 432 and the set header can be fully omitted. The possibility to shorten 433 the message length and Observation Domain ID to one byte is fairly 434 obvious. Most messages will be shorter than 255 bytes, in fact if 435 they are to be transmitted in a single packet they have to be smaller 436 than 127 byte with our hardware. Since the Observation Domain usually 437 refers to the node ID a value of one byte can accommodate 256 nodes 438 which represent a WSN of medium scale. The sequence number can also 439 be shortened to one byte, since a rollover after 255 messages is non 440 problematic due to the low data sampling rate of typical WSNs. For 441 the time stamp, a value of one byte could refer to the time that has 442 passed since the last full UTC time stamp has been sent. Since the 443 field length can be different with every package sent, it is possible 444 to only transmit a full 4 bytes time stamp periodically and suffice 445 with a delta value in between. So, for the best case this method can 446 achieve a reduction in header size from 32 bytes to 6 bytes, or a 447 compression of 81.25%. Figure 7 gives an example of the best case, 448 which is actually fairly common since it shows the transmission of a 449 data record referencing the last sent template set. In the worst case 450 however, header size may increase to 33 byte when all header fields 451 are defined to be their original length. 453 0 1 455 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | 0xA |0|0 0|0 0|0 0|0 0|1|0| IPFIX Message Pre Header 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------- 460 | Message | Time Offset | 461 | Length | = 30 sec | IPFIX Message Header 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Sequence | Node ID = 234 | 464 | Number = 123 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------- 466 | Last Template | From Message | Set Header (omitted) 467 | ID | Length | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 7: Best case header for the IPFIX header compression 472 A parallel approach is to integrate the IPFIX messages in the 473 communication with 6LoWPAN. Here we are faced with some missing 474 drivers for our hardware. We plan to port drivers from TinyOS 1.x to 475 TinyOS 2.x which is needed for 6LoWPAN. Currently the only supported 476 sensor board for IRIS motes under TinyOS 2.x is MTS300. 478 If the integration with 6LoWPAN is done the IPFIX messages may get a 479 more compressed format due to redundancy. For example the source 480 address mentioned in the IP header is the same as the node ID in the 481 IPFIX packets. Thus, the whole packet size might become smaller. 483 6. Formal Syntax 485 IPFIX - - IP Flow Information Export protocol based on RFC 5101 487 IPFIX-WS - - IP Flow Information Export protocol for Wireless Sensors 489 7. Security Considerations 491 Measurement data security and data integrity can be integrated as 492 well. IPFIX copes with these security issues by specifying that every 493 IPFIX device needs to support TLS (on stream based transport 494 protocols) or DTLS (on datagram based transport protocols). Fouladgar 495 et al. [5] developed Tiny 3-TLS, a TLS handshake sub-protocol for 496 sensor nodes, which can be used for securing IPFIX data transmission. 497 TinySec [6] can be used instead to achieve data link security and 498 message authentication. It offers an authentication encryption mode 499 where data payload is encrypted and the packet itself is 500 authenticated by a MAC. Another approach using the same idea as 501 TinySec was developed by Luk et al. [7], called MiniSec. It is a 502 secure sensor network communication architecture which modifies the 503 common packet structure of TinyOS and combines features from TinySec 504 and ZigBee [8] to perform low energy consumption and high security. 506 8. IANA Considerations 508 Vendors may specify their own IDs that are located above ID 32767. 509 All these IDs have the most significant bit set to 1. If a collector 510 recognizes an ID with this bit set, he can determine that this ID is 511 a non standard ID. The collector will then check the enterprise ID 512 (EID). Each vendor has to register an enterprise ID with Internet 513 Assigned Numbers Authority (IANA) [9] which will ensure that any 514 vendor can be identified uniquely. 516 9. Conclusions 518 In this draft we introduced a concept for integrating IPFIX in 519 wireless sensor networks. We showed that IPFIX is suitable for 520 deploying and integrating WSNs into home networks. With a connection 521 to 6LoWPAN this approach can also be used for other applications 522 using IP-addresses for communication. 524 IPFIX defines an efficient data format for transmitting sensor 525 measurement data using low bandwidth. Generating and parsing IPFIX 526 data can be performed with little processing power, thus saving 527 energy on the nodes. Arbitrary aggregation techniques can be deployed 528 to further reduce the transmitted data. If standard template IDs are 529 issued, interoperability between different devices from different 530 manufacturers can be ensured. At the same time, vendors can register 531 their own enterprise and type IDs to build custom devices. These 532 devices can still interoperate with other devices. By using IP on the 533 network layer below IPFIX, wireless sensor networks can easily be 534 integrated in existing home networks. Therefore, new sensor nodes can 535 be easily deployed and new functionality to the autonomic network can 536 be added in an automatic fashion. 538 10. References 540 10.1. Normative References 542 [1] C.Schmitt and G.Carle: 'Applications for Wireless Sensor 543 Networks', Handbook of Research on P2P and Grid Systems for 544 Service-Oriented Computing: Models, Methodologies and 545 Applications, Edited by N.Antonopulus, G.Exarchakos, M.Li and 546 A.Liotto, ISBN: 1-61520-686-8, Information Science Publishing, 547 2009 (in printing process) 549 [2] M.Harvan and J.Schoenwaelder, 'TinyOS Motes on the Internet: IPv6 550 over 802.15.4 (6lowpan)', PIK - Praxis der Informations- 551 verarbeitung und Kommunikation, 2008, vol.31, pp. 244-251. 553 [4] J.W.Hui and D.E.Culler, 'IP is dead, ling live IP for wireless 554 sensor networks', in SenSys 2008: Proceedings of the 6th ACM 555 conference on Embedded network sensor systems, ACM New York, NY, 556 USA, 2008, pp.15-28. 558 [5] S. Fouladgar, B. Mainaud, K. Masmoudi, and H. Afifi, 'Tiny 3-tls: 559 A trust delegation protocol for wireless sensor networks', 560 Lecture Notes in Computer Science, 2006, vol. 4357, p. 32-42. 562 [6] C. Karlof, N. Sastry, and D. Wagner, 'TinySec: a link layer 563 security architecture for wireless sensor networks', in 564 Proceedings of the 2nd international conference on Embedded 565 networked sensor systems. ACM New York, NY, USA, 2004, pp. 162- - 566 175. 568 [7] M. Luk, G. Mezzour, A. Perrig, and V. Gligor, 'MiniSec: a secure 569 sensor network communication architecture', in IPSN 2007: 570 Proceedings of the 6th international conference on Information 571 processing in sensor networks. ACM New York, NY, USA, 2007, pp. 572 479-488. 574 [8] ZigBee Alliance, 'ZigBee specification. Technical Report', ZigBee 575 Alliance, Document 053474r06 Version 1.0, June 2005. 577 [9] Internet Assigned Numbers Authority, http://www.iana.org/, 2009. 579 [10] Crossbow Technologies Inc., http://www.xbow.com/, 2009. 581 [11] TinyOS Homepage, http://www.tinyos.net, 2009. 583 [RFC4919] N.Kushalnagar et al., 'IPv6 over Low-Power Wireless 584 Personal Area Networks (6LoWPANs): Overview, Assumptions, 585 Problem Statement, and Goals', 2007 587 [RFC4944] N.Kushalnagar et al., 'Transmission of IPv6 Packets over 588 IEEE 802.15.4 Networks', 2007 590 [RFC5101] B.Claise et al., 'Specification of the IP Flow Information 591 Export (IPFIX) Protocol for the Exchange of IP Traffic Flow 592 Information', 2008 594 [RFC2119] S.Bradner et al., 'Key words for use in RFCs to Indicate 595 Requirement Levels', BCP 14, RFC 2119, 1997. 597 10.2. Informative References 599 [3] G.Muenz and L.Braun, 'Lossless Compression for IP Flow 600 Information Export (IPFIX)', The Internet Engineering Task Force 601 (IETF), Internet-Draft (work in progress), 2008 603 Authors' Addresses 605 Corinna Schmitt 606 TU Muenchen 607 Chair for Network Architectures and Services 608 Boltzmannstr. 3 609 85748 Garching, Germany 610 Email: schmitt@net.in.tum.de 612 Lothar Braun 613 TU Muenchen 614 Chair for Network Architectures and Services 615 Boltzmannstr. 3 616 85748 Garching, Germany 617 Email: braun@net.in.tum.de 619 Georg Carle 620 TU Muenchen 621 Chair for Network Architectures and Services 622 Boltzmannstr. 3 623 85748 Garching, Germany 624 Email: carle@net.in.tum.de