6lowapp C.Schmitt Internet Draft L.Braun Intended status: Informational G.Carle Expires: March 2010 TU Muenchen October 15, 2009 IPFIX for Wireless Sensors draft-schmitt-6lowapp-ipfix-ws-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 13th, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Schmitt,Braun,Carle Expires March 13th, 2010 [Page 1] Internet-Draft IPFIX for Wireless Sensors October 2009 Abstract In this draft we want to introduce an idea to develop a protocol for efficient data transmission for Wireless Sensors using the ideas of IPFIX. We will call this protocol IPFIX-WS. Table of Contents 1. Introduction...................................................2 1.1. Document structure........................................3 2. Conventions used in this document..............................3 3. Hardware Requirements..........................................3 4. IPFIX Protocol for Wireless Sensors............................4 4.1. IPFIX Standard - RFC 5101.................................4 4.2. IPFIX-WS..................................................4 4.3. Technical details for IPFIX-WS............................5 5. Integration of Wireless Sensors in Home Networks...............6 5.1. Hardware setting for test scenario........................6 5.2. Testbed results...........................................6 5.3. Planned add-ons for IPFIX-WS..............................9 6. Formal Syntax.................................................12 7. Security Considerations.......................................13 8. IANA Considerations...........................................13 9. Conclusions...................................................13 10. References...................................................14 10.1. Normative References....................................14 10.2. Informative References..................................15 Authors' Addresses...............................................16 1. Introduction Today everyone calls for new approaches for data acquisition in real- time. Different challenging requirements must be solved, such as efficient collection of environmental data using Wireless Sensors and efficient data transmission due to hardware limitations. Constraints on size, energy consumption and price lead to very limited memory, computational and communications resources. The desire for sensor nodes to be operational for a long time without external intervention, such as exchange of the batteries, which are often the only source of energy, leads to additional restrictions in the usage of the resources. Some research is done to address the issue of the sole dependency on battery power, but for now it remains the Schmitt,Braun,Carle Expires March 13th,2010 [Page 2] Internet-Draft IPFIX for Wireless Sensors October 2009 prevalent source of energy for WSNs. The physical size of a sensor node is another limiting factor. The IRIS mote which is used in our setup has the dimensions of 58 x 32 x 7 mm, without the battery pack. Thus it does not leave much room for the micro controller, flash memory (128 kb) and RF transceiver, all of which are located on this board. To satisfy those needs, standard protocols for efficient data transmission from common networks, such as the IP Flow Information Export (IPFIX) protocol, should be adapted to the equipment of Wireless Sensors. Another possibility is to reduce the data amount by implementing in-network data aggregation functionality. The most important thing is to develop these approaches while still providing interoperability between devices of different vendors. 1.1. Document structure This draft will describe the idea to adapt the common IPFIX protocol to the requirements of Wireless Sensor technology. The resources are limited and the most important aspect is saving energy. Thus, the data should be transmitted efficiently to save energy costs. In the upcoming sections we want to introduce the IPFIX protocol for common networks followed by modifications for wireless sensors. A description of current implementation approaches and planned add-ons will follow. Finally, security and IANA considerations are mentioned as well as a conclusion. 2. Conventions used in this document The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC-2119 [RFC2119]. 3. Hardware Requirements As mentioned before, Wireless Sensors should be used for collecting environmental data. They have many hardware requirements themselves, but the requirements of the application scenario also have to be kept in mind. On the hardware side, energy and computing capacity, as well as the space on the platforms are limited [1]. According to the application scenarios the sensors will be equipped with a different Schmitt,Braun,Carle Expires March 13th,2010 [Page 3] Internet-Draft IPFIX for Wireless Sensors October 2009 amount and types of sensors (e.g. for temperature, humidity, seismic data). 4. IPFIX Protocol for Wireless Sensors 4.1. IPFIX Standard - RFC 5101 The IP Flow Information export (IPFIX) protocol was standardized under the RFC 5101 [RFC5101] and developed for common networks to transmit data efficiently. IPFIX itself is a PUSH-protocol. That means an exporter periodically transmits data to one or more collectors. The communication is template based. Before the data itself is transmitted a template is sent to declare how upcoming data has to be decoded. Thus, meta information is sent only once and for decoding there only need to be moved some pointers over the data. Finally, the processing needs are low. To make the transmission more efficient, data aggregation can be added. Today the IPFIX protocol is used for network monitoring in common networks. These networks have different observation points and the hardware has no limited resources. In such networks IP flows pass through the different elements of the observed network. Due to security reasons it is interesting and useful to observe these flows. In this case the IPFIX Collecting process allows the user to verify different observation points of interest in the network. At this point the user is able to observe irregularities in traffic [RFC5101]. 4.2. IPFIX-WS As mentioned before, Wireless Sensors have different requirements. The common network protocol IPFIX is not yet adapted to fulfil the requirements of Wireless Sensors. In the first step, type and enterprise IDs must be defined to transmit sensor data measurements using IPFIX. Also new templates must be developed. An example is shown in Figure 1. As a consequence the data amount during transmission will be minimized and energy will be saved. The most important solutions are the data aggregation itself and a data compression [3]. +------------------------------------------------+ | Set ID | Length | +------------------------------------------------+ Schmitt,Braun,Carle Expires March 13th,2010 [Page 4] Internet-Draft IPFIX for Wireless Sensors October 2009 | Template ID | Field Count | +------------------------------------------------+ | ID: Node ID | Data Length ID: Node ID | +------------------------------------------------+ | Enterprise ID | +------------------------------------------------+ | ID: Time stamp | Data Length ID: Time Stamp | +------------------------------------------------+ | Enterprise ID | +------------------------------------------------+ | ID: Temperature | Data Length ID: Temperature | +------------------------------------------------+ | Enterprise ID | +------------------------------------------------+ | ID: Humidity | Data Length ID: Humidity | +------------------------------------------------+ | Enterprise ID | +------------------------------------------------+ Figure 1: IPFIX-WS Template Set for sensor data 4.3. Technical details for IPFIX-WS To apply IPFIX to Wireless Sensors the following tasks should be fulfilled: - gather data from the sensors attached to the node - generate IPFIX packets and transmit them to the base station of the network - perform in-network aggregation to reduce the amount of network traffic and preserve energy - receive and parse IPFIX packets on a Gateway server - Transfer the acquired data to a home network infrastructure. To achieve these goals, different steps must be executed. The mote's sensors are queried periodically to generate new sensor data. These raw values are transmitted to a specially developed tinyIPFIX library. It writes the values to the location specified by an IPFIX template, which was generated automatically when the mote booted. The template specifies the needed raw values. If all of these values are collected and written to the correct position in the respective IPFIX Schmitt,Braun,Carle Expires March 13th,2010 [Page 5] Internet-Draft IPFIX for Wireless Sensors October 2009 data message, then the IPFIX packet is ready for transmission and sent to the base station via a multihop network. The base station is a special node in the network which is the connection point between a wireless and wired infrastructure. It listens for incoming packets from nodes in the network and transmits their payload to the gateway server over an USB connection. On the gateway a listening program waits for transmissions. The IPFIX messages sent via USB are parsed according to the matching IPFIX templates; their sensor values are extracted and transferred to the home network infrastructure. Here the raw values are converted from their platform specific representation to a platform independent value. For example a 14bit Integer raw value coming from a temperature sensor is converted to a Double whose value is in Celsius. 5. Integration of Wireless Sensors in Home Networks Today common Home Networks work with IP addressing. Thus, the Wireless Sensors must be organised in a mesh network using also IPs for communication. For this situation the 6LoWPAN protocol was developed [4]. Additional requirements for connecting both system parts and a seamless integration of the Wireless Sensors into an existing infrastructure must be provided as well as support for devices of different vendors. 5.1. Hardware setting for test scenario For our approach we are using IRIS motes from Crossbow Technology Inc. [10]. These motes have limited resources and can cooperate with different sensor boards. Crossbow Technology Inc. offers different sensor boards which include sensors for light, temperature, humidity, barometric pressure, seismic, GPS and others. The motes run TinyOS [11], an open-source and component-based operating system. Current versions of TinyOS are 1.x and 2.x which provided different applications and driver support. 5.2. Testbed results Currently the IPFIX-approach was implemented in a network with 3 sensor nodes and one base station, and successfully tested in simulations with more nodes. Practical tests are running with the sensor boards MTS300CB and MTS400CB at the moment. The transmitted Schmitt,Braun,Carle Expires March 13th,2010 [Page 6] Internet-Draft IPFIX for Wireless Sensors October 2009 data in such IPFIX packets consists of values shown in Figure 1. The packet sizes ranges from 34 bytes (data packet) to 72 bytes (template packet), including the IPFIX header. For simplicity, only one data set is sent per transmission. Figure 2 shows an example of an IPFIX- WS Template message and Figure 3 an IPFIX-WS Data message. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Export Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID | Length Template | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information Element ID | Length Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . +-+-+-+-+- Figure 2: IPFIX-WS Template Format 0 1 2 3 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 Schmitt,Braun,Carle Expires March 13th,2010 [Page 7] Internet-Draft IPFIX for Wireless Sensors October 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Export Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Length Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Payload | Data Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Export Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IPFIX-WS Data Format example (Node ID = Observation ID) Parallel, 6LoWPAN was implemented for the platform IRIS using TinyOS 2.x based on the work of Harvan and Schoenwaelder [2]. They implemented a 6lowpan/IPv6 stack. The standard 802.15.4 provides two types of addresses (16-bit or 64-bit). Depending on the hardware used, the transmitted payload with 6LoWPAN can be up to 127 bytes. Optimal transmission is gained with 102 bytes payload. With the help of a fragmentation mechanism below the IP layer at least 1280 bytes can be transmitted. In the worst case, the IPv6 header has a size of 40 bytes. But the goal is to have as much space as possible for the payload. Thus, a header compression was implemented to compress the header down to 2 bytes. This compression mechanism can also be used for the transmission header like UDP which follows the IPv6 header. It can be compressed from 8 bytes down to 4 bytes. The IPv6 compression mechanism is called HC1 and the UDP compression mechanism is called HC_UDP. Figure 4 shows the worst case of transmission with no compression. +---------------------------------------------------------+ | 802.15.4 Header | AM type | HC1 Dispatch | HC1 Header | | (9-25 bytes) | (1 byte)| (1 byte) | (1 byte) | +---------------------------------------------------------+ Schmitt,Braun,Carle Expires March 13th,2010 [Page 8] Internet-Draft IPFIX for Wireless Sensors October 2009 | Hop Limit | uncompressed IPv6 fields | HC_UDP | | (1 byte) | (~36 bytes) | (1 byte) | +---------------------------------------------------------+ | uncompressed UDP fields | data | | (8 bytes) | (50-66 bytes) | +---------------------------------------------------------+ | 802.15.4 CRC | | (2 bytes) | +---------------+ Figure 4: 6LoWPAN packet format uncompressed [RFC4944] In the worst case, as shown in Figure 4, only 50-66 bytes are left for the data payload depending on the chosen address types in the 802.15.4 Header. Thus, compression is very important and in optimal case allows a data payload of 94-110 bytes depending on address types [RFC4944]. The 6LoWPAN approach was also successfully tested in real scenarios using IRIS motes. Currently the payload is simple without using sensor measurements due to driver problems. 5.3. Planned add-ons for IPFIX-WS Currently we try to develop a header compression to reduce the header size of each IPFIX message which consists of the IPFIX Message Header and the Set Header as shown in Figure 5. 0 1 2 3 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 Schmitt,Braun,Carle Expires March 13th,2010 [Page 9] Internet-Draft IPFIX for Wireless Sensors October 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Export Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation Domain ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: IPFIX Header Format including Message and Set Header Since IPFIX was designed for conventional networks, some extensions and changes have to be introduced to increase it's efficiency in WSNs. One of the problems when deploying IPFIX in sensor networks is the overhead introduced by the relatively large header which is at least 32 bytes in size (24 bytes from the Message Header + 4 bytes from the Set header) as is shown in Figure 5. Remember, that the maximum size of a packet being transferred with an IEEE 802.15.4 network is 127 bytes. To address this issue, a header compression scheme was devised, which will be introduced in this section. The idea behind our approach to header compression is to define the length of the fields separately in a pre header which is shown in Figure 6. First the Version field from the original IPFIX header is shortened to 5 bit, this leaves room for the IPFIX version to increase from version 10 to version 31. The definition of the length of the fields Message Length, Export Time, Sequence Number and Observation Domain ID follows. A value of 0 in the designated bit(s) means that the field is allowed 1 byte in the subsequent header, a value of 1 means 2 bytes, etc.. The next two bits are designated for the template offset. Decoders of IPFIX Messages are expected to keep track of the sequence in which they received templates from the IPFIX exporters. A value of 0 in the template offset bits means that the decoder should use the template it has received last, a value of 1 means the template before that and a value of 2 means two templates before the last one. If this offset is given for a data message, two bytes for the Set ID can be saved. If template offset is set to 3 (both bits are one) it is ignored and a proper statement of the template ID is expected in the header. The next bit is called the Single Set Flag. It indicates whether the message contains only a single IPFIX set. If this is the case, the explicit statement of set Schmitt,Braun,Carle Expires March 13th,2010 [Page 10] Internet-Draft IPFIX for Wireless Sensors October 2009 length in the header can be omitted since this value can be computed from the total message length. The last bit in the pre header is the Template Set Flag. If it is set to one, the first set in the message is a template set which is defined to have Set ID = 2. Thus the two bytes for definition of the set ID can be omitted. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version |L| EX|SN | D |TO |S|T| | Number | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L = Size of Length Field, EX = Size of Export Time Field, SN = Size of Sequence Number Field, D = Size of Observation Domain ID Field, TO = Template Offset Field, S = Single set Flag, T = Template Set Flag Figure 6: IPFIX pre header defining the length of the subsequent header In the best case scenario all header fields can be fitted to one byte and the set header can be fully omitted. The possibility to shorten the message length and Observation Domain ID to one byte is fairly obvious. Most messages will be shorter than 255 bytes, in fact if they are to be transmitted in a single packet they have to be smaller than 127 byte with our hardware. Since the Observation Domain usually refers to the node ID a value of one byte can accommodate 256 nodes which represent a WSN of medium scale. The sequence number can also be shortened to one byte, since a rollover after 255 messages is non problematic due to the low data sampling rate of typical WSNs. For the time stamp, a value of one byte could refer to the time that has passed since the last full UTC time stamp has been sent. Since the field length can be different with every package sent, it is possible to only transmit a full 4 bytes time stamp periodically and suffice with a delta value in between. So, for the best case this method can achieve a reduction in header size from 32 bytes to 6 bytes, or a compression of 81.25%. Figure 7 gives an example of the best case, which is actually fairly common since it shows the transmission of a data record referencing the last sent template set. In the worst case Schmitt,Braun,Carle Expires March 13th,2010 [Page 11] Internet-Draft IPFIX for Wireless Sensors October 2009 however, header size may increase to 33 byte when all header fields are defined to be their original length. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xA |0|0 0|0 0|0 0|0 0|1|0| IPFIX Message Pre Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------- | Message | Time Offset | | Length | = 30 sec | IPFIX Message Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence | Node ID = 234 | | Number = 123 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------- | Last Template | From Message | Set Header (omitted) | ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Best case header for the IPFIX header compression A parallel approach is to integrate the IPFIX messages in the communication with 6LoWPAN. Here we are faced with some missing drivers for our hardware. We plan to port drivers from TinyOS 1.x to TinyOS 2.x which is needed for 6LoWPAN. Currently the only supported sensor board for IRIS motes under TinyOS 2.x is MTS300. If the integration with 6LoWPAN is done the IPFIX messages may get a more compressed format due to redundancy. For example the source address mentioned in the IP header is the same as the node ID in the IPFIX packets. Thus, the whole packet size might become smaller. 6. Formal Syntax IPFIX - - IP Flow Information Export protocol based on RFC 5101 IPFIX-WS - - IP Flow Information Export protocol for Wireless Sensors Schmitt,Braun,Carle Expires March 13th,2010 [Page 12] Internet-Draft IPFIX for Wireless Sensors October 2009 7. Security Considerations Measurement data security and data integrity can be integrated as well. IPFIX copes with these security issues by specifying that every IPFIX device needs to support TLS (on stream based transport protocols) or DTLS (on datagram based transport protocols). Fouladgar et al. [5] developed Tiny 3-TLS, a TLS handshake sub-protocol for sensor nodes, which can be used for securing IPFIX data transmission. TinySec [6] can be used instead to achieve data link security and message authentication. It offers an authentication encryption mode where data payload is encrypted and the packet itself is authenticated by a MAC. Another approach using the same idea as TinySec was developed by Luk et al. [7], called MiniSec. It is a secure sensor network communication architecture which modifies the common packet structure of TinyOS and combines features from TinySec and ZigBee [8] to perform low energy consumption and high security. 8. IANA Considerations Vendors may specify their own IDs that are located above ID 32767. All these IDs have the most significant bit set to 1. If a collector recognizes an ID with this bit set, he can determine that this ID is a non standard ID. The collector will then check the enterprise ID (EID). Each vendor has to register an enterprise ID with Internet Assigned Numbers Authority (IANA) [9] which will ensure that any vendor can be identified uniquely. 9. Conclusions In this draft we introduced a concept for integrating IPFIX in wireless sensor networks. We showed that IPFIX is suitable for deploying and integrating WSNs into home networks. With a connection to 6LoWPAN this approach can also be used for other applications using IP-addresses for communication. IPFIX defines an efficient data format for transmitting sensor measurement data using low bandwidth. Generating and parsing IPFIX data can be performed with little processing power, thus saving energy on the nodes. Arbitrary aggregation techniques can be deployed to further reduce the transmitted data. If standard template IDs are issued, interoperability between different devices from different Schmitt,Braun,Carle Expires March 13th,2010 [Page 13] Internet-Draft IPFIX for Wireless Sensors October 2009 manufacturers can be ensured. At the same time, vendors can register their own enterprise and type IDs to build custom devices. These devices can still interoperate with other devices. By using IP on the network layer below IPFIX, wireless sensor networks can easily be integrated in existing home networks. Therefore, new sensor nodes can be easily deployed and new functionality to the autonomic network can be added in an automatic fashion. 10. References 10.1. Normative References [1] C.Schmitt and G.Carle: 'Applications for Wireless Sensor Networks', Handbook of Research on P2P and Grid Systems for Service-Oriented Computing: Models, Methodologies and Applications, Edited by N.Antonopulus, G.Exarchakos, M.Li and A.Liotto, ISBN: 1-61520-686-8, Information Science Publishing, 2009 (in printing process) [2] M.Harvan and J.Schoenwaelder, 'TinyOS Motes on the Internet: IPv6 over 802.15.4 (6lowpan)', PIK - Praxis der Informations- verarbeitung und Kommunikation, 2008, vol.31, pp. 244-251. [4] J.W.Hui and D.E.Culler, 'IP is dead, ling live IP for wireless sensor networks', in SenSys 2008: Proceedings of the 6th ACM conference on Embedded network sensor systems, ACM New York, NY, USA, 2008, pp.15-28. [5] S. Fouladgar, B. Mainaud, K. Masmoudi, and H. Afifi, 'Tiny 3-tls: A trust delegation protocol for wireless sensor networks', Lecture Notes in Computer Science, 2006, vol. 4357, p. 32-42. [6] C. Karlof, N. Sastry, and D. Wagner, 'TinySec: a link layer security architecture for wireless sensor networks', in Proceedings of the 2nd international conference on Embedded networked sensor systems. ACM New York, NY, USA, 2004, pp. 162- - 175. [7] M. Luk, G. Mezzour, A. Perrig, and V. Gligor, 'MiniSec: a secure sensor network communication architecture', in IPSN 2007: Proceedings of the 6th international conference on Information processing in sensor networks. ACM New York, NY, USA, 2007, pp. 479-488. Schmitt,Braun,Carle Expires March 13th,2010 [Page 14] Internet-Draft IPFIX for Wireless Sensors October 2009 [8] ZigBee Alliance, 'ZigBee specification. Technical Report', ZigBee Alliance, Document 053474r06 Version 1.0, June 2005. [9] Internet Assigned Numbers Authority, http://www.iana.org/, 2009. [10] Crossbow Technologies Inc., http://www.xbow.com/, 2009. [11] TinyOS Homepage, http://www.tinyos.net, 2009. [RFC4919] N.Kushalnagar et al., 'IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals', 2007 [RFC4944] N.Kushalnagar et al., 'Transmission of IPv6 Packets over IEEE 802.15.4 Networks', 2007 [RFC5101] B.Claise et al., 'Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information', 2008 [RFC2119] S.Bradner et al., 'Key words for use in RFCs to Indicate Requirement Levels', BCP 14, RFC 2119, 1997. 10.2. Informative References [3] G.Muenz and L.Braun, 'Lossless Compression for IP Flow Information Export (IPFIX)', The Internet Engineering Task Force (IETF), Internet-Draft (work in progress), 2008 Schmitt,Braun,Carle Expires March 13th,2010 [Page 15] Internet-Draft IPFIX for Wireless Sensors October 2009 Authors' Addresses Corinna Schmitt TU Muenchen Chair for Network Architectures and Services Boltzmannstr. 3 85748 Garching, Germany Email: schmitt@net.in.tum.de Lothar Braun TU Muenchen Chair for Network Architectures and Services Boltzmannstr. 3 85748 Garching, Germany Email: braun@net.in.tum.de Georg Carle TU Muenchen Chair for Network Architectures and Services Boltzmannstr. 3 85748 Garching, Germany Email: carle@net.in.tum.de Schmitt,Braun,Carle Expires March 13th,2010 [Page 16]