6lowapp                                                       C.Schmitt
Internet Draft                                                  L.Braun
Intended status: Informational                                  G.Carle
Expires: March 2010                                         TU Muenchen
                                                       October 15, 2009

                        IPFIX for Wireless Sensors

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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


   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

   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',
   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

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


   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

   - 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

   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

   Figure 6: IPFIX pre header defining the length of the subsequent

   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-                                                                          -

   [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.

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]