Skip to main content

TinyIPFIX for smart meters in constrained networks
draft-schmitt-ipfix-tiny-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8272.
Authors Corinna Schmitt , Burkhard Stiller , Brian Trammell
Last updated 2016-06-02
RFC stream (None)
Formats
IETF conflict review conflict-review-schmitt-ipfix-tiny, conflict-review-schmitt-ipfix-tiny, conflict-review-schmitt-ipfix-tiny, conflict-review-schmitt-ipfix-tiny, conflict-review-schmitt-ipfix-tiny, conflict-review-schmitt-ipfix-tiny
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 8272 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-schmitt-ipfix-tiny-00
gt;| [Collecting Process] |
    +------------------------+                  |  [Exporting Process] |
                                                |         |            |
                                                |         |IPFIX       |
                                                |         |            |
                                                |         v            |
                                                |   Collector(1)       |
                                                | [Collecting Process] |
                                                +----------------------+

             Figure 18: Transformation from TinyIPFIX to IPFIX

   The TinyIPFIX Mediation Process has to translate the TinyIPFIX
   Message Header, the TinyIPFIX Set Headers and the TinyIPFIX Template
   Record Header into their counterparts in IPFIX Afterwards, the new
   IPFIX Message Length needs to be calculated and inserted into the
   IPFIX Message header.

7.1.  Expanding the Message header

   The fields of the IPFIX Message Header that are shown in Figure 5 can
   be determined as follows:

   Version

      This is always 0x000a.

   Length

      The IPFIX Message Length can only be calculated after the complete
      TinyIPFIX Message has been translated.  The new length can be
      calculated by adding the length of the IPFIX Message Header, which
      is 16 octets, and the length of all Sets that are contained in the
      IPFIX Message.

   Export Time

      If the "Export Time" in the TinyIPFIX Message Header has a length
      of 4 octets, the value from the TinyIPFIX Message Header MUST be
      used for the IPFIX Message Header.  If it was omitted, the "Export
      Time" MUST be generated by the Mediator.  If the IPFIX Message is

Schmitt, et al.                 TinyIPFIX                      [Page 21]
Internet-Draft                  TinyIPFIX                      June 2016

      exported again, the "Export Time" field MUST contain the time in
      seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message
      leaves the Exporter.  If the Message is passed to an IPFIX
      Collector for decoding directly, the "Export Time" field is the
      time in seconds since 0000 UTC Jan 1 1970 at which the TinyIPFIX
      Message has been received by the TinyIPFIX Exporter.

   Sequence Number

      If the TinyIPFIX Sequence Number has a length of 4 octets, the
      original value MUST be used for the IPFIX Message.  If the
      TinyIPFIX Sequence Number has a size of one or two octets, the
      TinyIPFIX Mediator MUST expand the TinyIPFIX Sequence Number into
      a four octet field.  If the TinyIPFIX Sequence Number was omitted,
      the Mediator needs to calculate the Sequence Number as per
      [RFC7101].

   Observation Domain ID

      Since the Observation Domain ID is used to scope templates in
      IPFIX, it MUST be set to a unique value per TinyIPFIX Exporting
      Process, using either a mapping algorithmically determined by the
      Intermediate Process or directly configured by an administrator.

7.2.  Translating the Set Headers

   Both fields in the TinyIPFIX Set Header have a size of one octet and
   need to be expanded:

   Set ID

      The field needs to be expanded from one octet to two octets.  If
      the Set ID is below 128, no recalculation needs to be performed.
      This is because all IDs below 128 are reserved for special
      messages and match the IDs used in IPFIX.  The TinyIPFIX Set IDs
      starting with 128 identify TinyIPFIX Data Sets.  Therefore, every
      TinyIPFIX Set ID above 127 needs to be incremented by 128 because
      IPFIX Data Set IDs are located above 255.

   Set Length

      The field needs to be expanded from one octet to two octets.  It
      needs to be recalculated by adding a value of 2 octet to match the
      additional size of the Set Header.  For each TinyIPFIX Template
      Record that is contained in the TinyIPFIX Set, 2 more octets need
      to be added to the length.

Schmitt, et al.                 TinyIPFIX                      [Page 22]
Internet-Draft                  TinyIPFIX                      June 2016

7.3.  Expanding the Template Record Header

   Both fields in the TinyIPFIX Template Record Header have a length of
   one octet and therefore need translation:

   Template ID

      The field needs to be expanded from one octet to two octets.  The
      Template ID needs to be increased by a value of 128.

   Field Count

      The field needs to be expanded from one octet to two octets.

8.  Template Management

   As with IPFIX, TinyIPFIX templates management depends on the
   transport protocol used.  If TCP or SCTP is used, it can be ensured
   that TinyIPFIX Templates are delivered reliably.  If UDP is used,
   reliability cannot be guaranteed, and template loss can occur.  If a
   Template is lost on its way to the Collector, all following TinyIPFIX
   Data Records that refer to this TinyIPFIX Template cannot be decoded.
   Template withdrawals are not supported in TinyIPFIX.  This is
   generally not a problem, because most sensor nodes only define a
   single template directly after booting.

8.1.  TCP / SCTP

   If TCP or SCTP is an option and can be used for the transmission of
   TinyIPFIX, Template Management MUST be performed as defined in
   [RFC7101] for IPFIX, with the exception of template withdrawals,
   which are not supported in TinyIPFIX.  Template withdrawals MUST NOT
   be sent by TinyIPFIX exporters.

8.2.  UDP

   All specifications for Template management from [RFC7101] apply
   unless specified otherwise in this document.

   TinyIPFIX Templates MUST be sent by an TinyIPFIX Exporter before any
   TinyIPFIX Data Set that refers to the TinyIPFIX Template is
   transmitted.  TinyIPFIX Templates are not expected to change over
   time in TinyIPFIX.  Hence, a TinyIPFIX Template that has been sent
   once MAY NOT be withdrawn and MUST NOT expire.  If an TinyIPFIX Smart
   Meter wants to use another TinyIPFIX Template it MUST use a new
   TinyIPFIX Template ID for the TinyIPFIX Template.

Schmitt, et al.                 TinyIPFIX                      [Page 23]
Internet-Draft                  TinyIPFIX                      June 2016

   As UDP is used, reliable transport of TinyIPFIX Templates cannot be
   guaranteed and TinyIPFIX Templates can be lost.  A TinyIPFIX Exporter
   MUST expect TinyIPFIX Template loss.  It MUST therefore re-send its
   TinyIPFIX Templates periodically.  A TinyIPFIX Template MUST be re-
   send after a fixed number of N TinyIPFIX Messages that contained
   TinyIPFIX Data Sets that referred to this TinyIPFIX Template.  The
   number N MUST be configured by the application developer.

9.  Security considerations

   The same security considerations as for the IPFIX Protocol [RFC7101]
   apply.

10.  IANA Considerations

   This document has no actions for IANA.

11.  Acknowledgments

   Many thanks to Lothar Braun, Georg Carle, and Benoit Claise, who
   contributed significant work to earlier versions especially to the
   document entitled "Compressed IPFIX for Smart Meters in Constrained
   Networks" (draft-braun-core-compressed-ipfix), of this work.

   Many thanks to Thomas Kothmayr and Michael Meister, who implemented
   TinyIPFIX for TinyOS 2.x and Contiki 2.7 except the mediator.

12.  References

12.1.  Norminative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <http://www.rfc-editor.org/info/rfc4944>.

   [RFC7101]  Ginoza, S., "List of Internet Official Protocol Standards:
              Replaced by a Web Page", RFC 7101, DOI 10.17487/RFC7101,
              December 2013, <http://www.rfc-editor.org/info/rfc7101>.

Schmitt, et al.                 TinyIPFIX                      [Page 24]
Internet-Draft                  TinyIPFIX                      June 2016

   [RFC7012]  Claise, B., Ed. and B. Trammell, Ed., "Information Model
              for IP Flow Information Export (IPFIX)", RFC 7012,
              DOI 10.17487/RFC7012, September 2013,
              <http://www.rfc-editor.org/info/rfc7012>.

   [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
              "Architecture for IP Flow Information Export", RFC 5470,
              DOI 10.17487/RFC5470, March 2009,
              <http://www.rfc-editor.org/info/rfc5470>.

   [RFC5982]  Kobayashi, A., Ed. and B. Claise, Ed., "IP Flow
              Information Export (IPFIX) Mediation: Problem Statement",
              RFC 5982, DOI 10.17487/RFC5982, August 2010,
              <http://www.rfc-editor.org/info/rfc5982>.

   [RFC6183]  Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi,
              "IP Flow Information Export (IPFIX) Mediation: Framework",
              RFC 6183, DOI 10.17487/RFC6183, April 2011,
              <http://www.rfc-editor.org/info/rfc6183>.

12.2.  Informative References

   [Schmitt09]
              Schmitt, C. and G. Carle, "Applications for Wireless
              Sensor Networks", In Handbook of Research on P2P and Grid
              Systems for Service-Oriented Computing: Models,
              Methodologies and Applications, Antonopoulos N.;
              Exarchakos G.; Li M.; Liotta A. (Eds.), Information
              Science Publishing. , 2010.

   [Tolle05]  Tolle, G., Polastre, J., Szewczyk, R., Turner, N., Tu, K.,
              Buonadonna, P., Burgess, S., Gay, D., Hong, W., Dawnson,
              T., and D. Culler, "A macroscope in the redwoods", In the
              Proceedings of the 3rd ACM Conference on Embedded
              Networked Sensor Systems (Sensys 05), San Diego, ACM
              Press , November 2005.

   [Kim07]    Kim, S., Pakzad, S., Culler, D., Demmel, J., Fenves, G.,
              Glaser, S., and M. Turon, "Health Monitoring of Civil
              Infrastructure Using Wireless Sensor Networks", In the
              Proceedings of the 6th International Conference on
              Information Processing in Sensor Networks (IPSN 2007),
              Cambridge, MA, ACM Press, pp. 254-263 , April 2007.

Schmitt, et al.                 TinyIPFIX                      [Page 25]
Internet-Draft                  TinyIPFIX                      June 2016

   [SMPC04]   Szewczyk, R., Mainwaring, A., Polastre, J., and D. Culler,
              "An analysis of a large scale habitat monitoring
              application", The Proceedings of the Second ACM Conference
              on Embedded Networked Sensor Systems (SenSys 04) ,
              November 2004.

   [GreatDuck]
              Habitat Monitoring on Great Duck Island, ,
              "http://www.greatduckisland.net", The Proceedings of the
              Second ACM Conference on Embedded Networked Sensor Systems
              (SenSys 04) , November 2004.

   [Harvan08]
              Harvan, M. and J. Schoenwaelder, "TinyOS Motes on the
              Internet: IPv6 over 802.15.4 (6lowpan)", 2008.

   [Crossbow]
              Crossbow Technologies Inc., , "http://www.xbow.com", 2010.

   [kothmayr10]
              Kothmayr, T., "Data Collection in Wireless Sensor Networks
              for Autonomic Home Networking", Bachelor Thesis, Technical
              University of Munich, Germany , 2010.

   [schmitt2014]
              Schmitt, C., Kothmayr, T., Ertl, B., Hu, W., Braun, L.,
              and G. Carle, "TinyIPFIX: An Efficient Application
              Protocol for Data Exchange in Cyber Physical Systems",
              Computer Communications, ELSEVIER, DOI: 10.1016/
              j.comcom.2014.05.012 , 2014.

Authors' Addresses

   Corinna Schmitt
   University of Zurich
   Department of Informatics
   Communication Systems Group
   Binzmuehlestrasse 14
   Zurich  8050
   Switzerland

   Email: schmitt@ifi.uzh.ch

Schmitt, et al.                 TinyIPFIX                      [Page 26]
Internet-Draft                  TinyIPFIX                      June 2016

   Burkhard Stiller
   University of Zurich
   Department of Informatics
   Communication Systems Group
   Binzmuehlestrasse 14
   Zurich  8050
   Switzerland

   Email: stiller@ifi.uzh.ch

   Brian Trammell
   Swiss Federal Institute of Technology
   Gloriastrasse 35
   Zurich  8092
   Switzerland

   Email: ietf@trammell.ch

Schmitt, et al.                 TinyIPFIX                      [Page 27]