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]