[要約] RFC 8272は、制約のあるネットワークでのスマートメーター向けのTinyIPFIXプロトコルに関するものです。このRFCの目的は、制約のあるネットワーク環境でのスマートメーターデータの効率的な収集と転送を可能にすることです。
Independent Submission C. Schmitt
Request for Comments: 8272 B. Stiller
Category: Informational University of Zurich
ISSN: 2070-1721 B. Trammell
ETH Zurich
November 2017
TinyIPFIX for Smart Meters in Constrained Networks
制約付きネットワークのスマートメーター用TinyIPFIX
Abstract
概要
This document specifies the TinyIPFIX protocol that is used for transmitting smart-metering data in constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN, RFC 4944). TinyIPFIX is derived from IP Flow Information Export (RFC 7011) and adopted to the needs of constrained networks. This document specifies how the TinyIPFIX Data and Template Records are transmitted in constrained networks such as 6LoWPAN and how TinyIPFIX data can be converted into data that is not TinyIPFIX in a proxy device.
このドキュメントは、低電力ワイヤレスパーソナルエリアネットワーク（6LoWPAN、RFC 4944）を介したIPv6などの制約されたネットワークでスマートメータリングデータを送信するために使用されるTinyIPFIXプロトコルを指定します。 TinyIPFIXは、IPフロー情報エクスポート（RFC 7011）から派生し、制約のあるネットワークのニーズに採用されています。このドキュメントでは、6LoWPANなどの制約されたネットワークでTinyIPFIXデータとテンプレートレコードを送信する方法と、プロキシデバイスでTinyIPFIXデータをTinyIPFIX以外のデータに変換する方法について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8272.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8272で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Hardware Constraints . . . . . . . . . . . . . . . . . . 6
3.2. Energy Constraints . . . . . . . . . . . . . . . . . . . 7
3.3. Packet Size Constraints . . . . . . . . . . . . . . . . . 7
3.4. Transport Protocol Constraints . . . . . . . . . . . . . 8
4. Application Scenarios for TinyIPFIX . . . . . . . . . . . . . 9
5. Architecture for TinyIPFIX . . . . . . . . . . . . . . . . . 11
6. TinyIPFIX Message Format . . . . . . . . . . . . . . . . . . 14
6.1. TinyIPFIX Message Header . . . . . . . . . . . . . . . . 15
6.2. TinyIPFIX Set . . . . . . . . . . . . . . . . . . . . . . 18
6.3. TinyIPFIX Template Record Format . . . . . . . . . . . . 19
6.4. Field Specifier Format . . . . . . . . . . . . . . . . . 20
6.5. TinyIPFIX Data Record Format . . . . . . . . . . . . . . 21
7. TinyIPFIX Mediation . . . . . . . . . . . . . . . . . . . . . 21
7.1. Expanding the Message Header . . . . . . . . . . . . . . 24
7.2. Translating the Set Headers . . . . . . . . . . . . . . . 25
7.3. Expanding the Template Record Header . . . . . . . . . . 25
8. Template Management . . . . . . . . . . . . . . . . . . . . . 25
8.1. TCP/SCTP . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
Smart meters that form a constrained wireless network need an application-layer protocol that allows the efficient transmission of metering data from the devices to a central analysis device. The meters used to build such networks are usually equipped with low-cost and low-power hardware. This leads to constraints in computational capacities, available memory, and networking resources.
制約のあるワイヤレスネットワークを形成するスマートメーターには、デバイスから中央分析デバイスへの計測データの効率的な送信を可能にするアプリケーション層プロトコルが必要です。このようなネットワークの構築に使用されるメーターには、通常、低コストで低電力のハードウェアが装備されています。これにより、計算能力、使用可能なメモリ、およびネットワークリソースが制限されます。
The devices are often battery powered and are expected to run for a long time without having the possibility of recharging themselves. In order to save energy, smart meters often power off their wireless networking device. Hence, they don't have a steady network connection; they are only part of the wireless network as needed when there is data to be exported. A push protocol like TinyIPFIX, where data is transmitted autonomically from the meters to one or more collectors, is suitable for reporting metering data in such networks.
これらのデバイスはバッテリ駆動であることが多く、再充電の可能性がなくても長時間動作することが期待されています。エネルギーを節約するために、スマートメーターはワイヤレスネットワークデバイスの電源をオフにすることがよくあります。したがって、安定したネットワーク接続がありません。エクスポートするデータがある場合、それらは必要に応じてワイヤレスネットワークの一部にすぎません。 TinyIPFIXのようなプッシュプロトコルは、データがメーターから1つ以上のコレクターに自律的に送信されるため、このようなネットワークでのメーターデータのレポートに適しています。
TinyIPFIX is derived from IPFIX [RFC7011]; therefore, it inherits most of IPFIX's properties. One of these properties is the separation of data and its data description by encoding the former in Data Sets and the latter in Template Sets.
TinyIPFIXはIPFIX [RFC7011]から派生しています。したがって、IPFIXのほとんどのプロパティを継承します。これらのプロパティの1つは、データセットの前者とテンプレートセットの後者をエンコードすることによるデータとそのデータ記述の分離です。
Transforming TinyIPFIX to IPFIX as per [RFC7011] is very simple and can be done on the border between the constrained network and the more general network. The transformation between one form of IPFIX data into another is known as "IPFIX Mediation" [RFC5982]. Hence, smart-metering networks that are based on TinyIPFIX can be easily integrated into an existing IPFIX measurement infrastructure.
[RFC7011]に従ってTinyIPFIXをIPFIXに変換することは非常に簡単で、制約されたネットワークとより一般的なネットワークの間の境界で実行できます。ある形式のIPFIXデータから別の形式への変換は、 "IPFIX Mediation" [RFC5982]として知られています。したがって、TinyIPFIXに基づくスマートメータリングネットワークは、既存のIPFIX測定インフラストラクチャに簡単に統合できます。
Section 2 introduces the terminology used in this document. Afterwards, hardware and software constraints in constrained networks, which will motivate our modifications to the IPFIX protocol, are discussed in Section 3. Section 4 describes the application scenarios and Section 5 describes the architecture for TinyIPFIX. Section 6 defines the TinyIPFIX protocol itself and discusses the differences between TinyIPFIX and IPFIX. The Mediation Process from TinyIPFIX to IPFIX is described in Section 7. Section 8 defines the process of Template Management on the Exporter and the Collector. Section 9 and Section 10 discuss the security and IANA considerations for TinyIPFIX.
セクション2では、このドキュメントで使用されている用語を紹介します。その後、IPFIXプロトコルへの変更の動機となる制約付きネットワークでのハードウェアおよびソフトウェアの制約について、セクション3で説明します。セクション4はアプリケーションシナリオを説明し、セクション5はTinyIPFIXのアーキテクチャを説明します。セクション6では、TinyIPFIXプロトコル自体を定義し、TinyIPFIXとIPFIXの違いについて説明します。 TinyIPFIXからIPFIXへの仲介プロセスについては、セクション7で説明します。セクション8では、エクスポーターとコレクターでのテンプレート管理のプロセスを定義します。セクション9とセクション10では、TinyIPFIXのセキュリティとIANAの考慮事項について説明します。
Most of the terms used in this document are defined in [RFC7011]. Each of these terms begins with a capital letter. Most of the terms that are defined for IPFIX can be used to describe TinyIPFIX. This document uses the term "IPFIX" to refer to IPFIX as defined in [RFC7011] and the term TinyIPFIX for the protocol specified in this draft document assuming constrained networks. The prefix "Tiny" is added to IPFIX to distinguish between the IPFIX version and the TinyIPFIX version.
このドキュメントで使用されている用語のほとんどは、[RFC7011]で定義されています。これらの各用語は、大文字で始まります。 IPFIXに定義されているほとんどの用語は、TinyIPFIXを説明するために使用できます。このドキュメントでは、[RFC7011]で定義されているIPFIXを指すために「IPFIX」という用語を使用し、ネットワークが制約されていると仮定して、このドラフトドキュメントで指定されているプロトコルに対してTinyIPFIXを使用します。接頭辞「Tiny」がIPFIXに追加され、IPFIXバージョンとTinyIPFIXバージョンを区別します。
The terms IPFIX Message, IPFIX Device, Set, Data Set, Template Set, Data Record, Template Record, Collecting Process, Collector, Exporting Process, and Exporter are defined as in [RFC7011]. The term IPFIX Mediator is defined in [RFC5982]. The terms Intermediate Process, IPFIX Proxy, IPFIX Concentrator are defined in [RFC6183].
IPFIXメッセージ、IPFIXデバイス、セット、データセット、テンプレートセット、データレコード、テンプレートレコード、収集プロセス、コレクター、エクスポートプロセス、およびエクスポーターという用語は、[RFC7011]で定義されています。 IPFIX Mediatorという用語は[RFC5982]で定義されています。中間プロセス、IPFIXプロキシ、IPFIXコンセントレータという用語は、[RFC6183]で定義されています。
All the terms above have been adapted from the IPFIX definitions. As they keep a similar notion but in a different context of constrained networks, the term "TinyIPFIX" now precedes the defined terms.
上記のすべての用語は、IPFIXの定義に基づいています。それらは同様の概念を保持していますが、制約されたネットワークの異なるコンテキストにあるため、「TinyIPFIX」という用語は定義された用語の前に置かれています。
The term "smart meter" is used to refer to constrained devices like wireless sensor nodes, motes, or any other kind of small constrained device that can be part of a network that is based on IEEE 802.15.4 and 6LoWPAN [RFC4944].
「スマートメーター」という用語は、ワイヤレスセンサーノード、モート、またはIEEE 802.15.4および6LoWPAN [RFC4944]に基づくネットワークの一部である可能性のある他の種類の小さな制約付きデバイスなどの制約付きデバイスを指すために使用されます。
TinyIPFIX Exporting Process
TinyIPFIXエクスポートプロセス
The TinyIPFIX Exporting Process is a process that exports TinyIPFIX Records.
TinyIPFIXエクスポートプロセスは、TinyIPFIXレコードをエクスポートするプロセスです。
TinyIPFIX Exporter
TinyIPFIXエクスポーター
A TinyIPFIX Exporter is device that contains at least one TinyIPFIX Exporting Process.
TinyIPFIXエクスポーターは、少なくとも1つのTinyIPFIXエクスポートプロセスを含むデバイスです。
TinyIPFIX Collecting Process
TinyIPFIX収集プロセス
The TinyIPFIX Collecting Process is a process inside a device that is able to receive and process TinyIPFIX Records.
TinyIPFIX収集プロセスは、TinyIPFIXレコードを受信して処理できるデバイス内のプロセスです。
TinyIPFIX Collector
TinyIPFIXコレクター
A TinyIPFIX Collector is a device that contains at least one TinyIPFIX Collecting Process.
TinyIPFIXコレクターは、少なくとも1つのTinyIPFIX収集プロセスを含むデバイスです。
TinyIPFIX Device
TinyIPFIXデバイス
A TinyIPFIX Device is a device that contains one or more TinyIPFIX Collectors or one or more TinyIPFIX Exporters.
TinyIPFIXデバイスは、1つ以上のTinyIPFIXコレクターまたは1つ以上のTinyIPFIXエクスポーターを含むデバイスです。
TinyIPFIX Smart Meter
TinyIPFIXスマートメーター
A TinyIPFIX Smart Meter is a device that contains the functionality of a TinyIPFIX Device. It is usually equipped with one or more sensors that meter a physical quantity, like power consumption, temperature, or physical tampering with the device. Every TinyIPFIX Smart Meter MUST at least contain a TinyIPFIX Exporting Process. It MAY contain a TinyIPFIX Collecting Process in order to work as a TinyIPFIX Proxy or TinyIPFIX Concentrator.
TinyIPFIXスマートメーターは、TinyIPFIXデバイスの機能を含むデバイスです。通常、消費電力、温度、デバイスの物理的な改ざんなどの物理量を測定する1つ以上のセンサーが装備されています。すべてのTinyIPFIXスマートメーターには、少なくともTinyIPFIXエクスポートプロセスが含まれている必要があります。 TinyIPFIXプロキシまたはTinyIPFIXコンセントレータとして機能するために、TinyIPFIX収集プロセスが含まれている場合があります。
TinyIPFIX Data Record
TinyIPFIXデータレコード
A TinyIPFIX Data Record equals an IPFIX Data Record in [RFC7011]. The term is used to distinguish between IPFIX and TinyIPFIX throughout this document.
TinyIPFIXデータレコードは、[RFC7011]のIPFIXデータレコードと同じです。この用語は、このドキュメント全体でIPFIXとTinyIPFIXを区別するために使用されます。
TinyIPFIX Template Record
TinyIPFIXテンプレートレコード
A TinyIPFIX Template Record is similar to an IPFIX Template Record in [RFC7011]. The Template Record Header is substituted with a TinyIPFIX Template Record Header and is otherwise equal to a Template Record. See Section 6.3.
TinyIPFIXテンプレートレコードは、[RFC7011]のIPFIXテンプレートレコードに似ています。テンプレートレコードヘッダーはTinyIPFIXテンプレートレコードヘッダーに置き換えられ、それ以外はテンプレートレコードと同じです。セクション6.3を参照してください。
TinyIPFIX Set
TinyIPFIXセット
The TinyIPFIX Set is a group of TinyIPFIX Data Records or TinyIPFIX Template Records with a TinyIPFIX Set Header. Its format is defined in Section 6.2.
TinyIPFIXセットは、TinyIPFIXセットヘッダーを持つTinyIPFIXデータレコードまたはTinyIPFIXテンプレートレコードのグループです。その形式はセクション6.2で定義されています。
TinyIPFIX Data Set
TinyIPFIXデータセット
The TinyIPFIX Data Set is a TinyIPFIX Set that contains TinyIPFIX Data Records.
TinyIPFIXデータセットは、TinyIPFIXデータレコードを含むTinyIPFIXセットです。
TinyIPFIX Template Set
TinyIPFIXテンプレートセット
A TinyIPFIX Template Set is a TinyIPFIX Set that contains TinyIPFIX Template Records.
TinyIPFIXテンプレートセットは、TinyIPFIXテンプレートレコードを含むTinyIPFIXセットです。
TinyIPFIX Message
TinyIPFIXメッセージ
The TinyIPFIX Message is a message originated by a TinyIPFIX Exporter. It is composed of a TinyIPFIX Message Header and one or more TinyIPFIX Sets. The TinyIPFIX Message Format is defined in Section 6.
TinyIPFIXメッセージは、TinyIPFIXエクスポーターが発信したメッセージです。これは、TinyIPFIXメッセージヘッダーと1つ以上のTinyIPFIXセットで構成されています。 TinyIPFIXメッセージフォーマットはセクション6で定義されています。
TinyIPFIX Intermediate Process
TinyIPFIX中間プロセス
A TinyIPFIX Intermediate Process is an IPFIX Intermediate Process that can handle TinyIPFIX Messages.
TinyIPFIX中間プロセスは、TinyIPFIXメッセージを処理できるIPFIX中間プロセスです。
TinyIPFIX Proxy
TinyIPFIXプロキシ
A TinyIPFIX Proxy is an IPFIX Proxy that can handle TinyIPFIX Messages.
TinyIPFIXプロキシは、TinyIPFIXメッセージを処理できるIPFIXプロキシです。
TinyIPFIX Concentrator
TinyIPFIXコンセントレータ
A TinyIPFIX Concentrator is device that can handle TinyIPFIX Messages (e.g., pre-process them) and is not constrained.
TinyIPFIXコンセントレータは、TinyIPFIXメッセージを処理できる（たとえば、それらを前処理する）デバイスであり、制約されていません。
TinyIPFIX Proxy
TinyIPFIXプロキシ
A TinyIPFIX Proxy is an IPFIX Proxy that can handle TinyIPFIX Messages and is not constrained.
TinyIPFIXプロキシは、TinyIPFIXメッセージを処理できるIPFIXプロキシであり、制約はありません。
A TinyIPFIX Transport Session is defined by the communication between a TinyIPFIX Exporter (identified by an 6LoWPAN-Address, the Transport Protocol, and the Transport Port) and a TinyIPFIX Collector (identified by the same properties).
TinyIPFIXトランスポートセッションは、TinyIPFIXエクスポーター（6LoWPAN-Address、トランスポートプロトコル、およびトランスポートポートで識別）とTinyIPFIXコレクター（同じプロパティで識別）の間の通信によって定義されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The target devices for TinyIPFIX are usually equipped with low-cost hardware; therefore, they face several constraints concerning CPU and memory [Schmitt09]. For example, the IRIS mote from Crossbow Technologies, Inc. has a size of 58 x 32 x 7 mm (without a battery pack) [IRIS]. Thus, there is little space for a micro-controller, memory (128 kb program flash, 512 kb measurement serial flash, 8 kb RAM, 4 kb configuration EEPROM), and radio-frequency transceiver, which are located on the board. The TelosB motes produced by Crossbow Technologies, Inc. [TelosB] and ADVANTIC SISTEMAS Y SERVICIOS S.L. [Advantic] are similar sized, but offering more memory (48 kb flash, 1024 kb serial, flash, 10 kb RAM, 16 kb configuration EEPROM). The same holds for OpenMote, but the offering is 512 kb flash and 32 kb RAM [openMote].
TinyIPFIXのターゲットデバイスは通常、低コストのハードウェアを備えています。したがって、CPUとメモリに関するいくつかの制約に直面します[Schmitt09]。たとえば、Crossbow Technologies、Inc.のIRISモートのサイズは58 x 32 x 7 mm（バッテリーパックなし）[IRIS]です。したがって、ボード上にあるマイクロコントローラー、メモリ（128 kbのプログラムフラッシュ、512 kbの測定シリアルフラッシュ、8 kbのRAM、4 kbの構成EEPROM）、および無線周波数トランシーバー用のスペースはほとんどありません。 Crossbow Technologies、Inc. [TelosB]およびADVANTIC SISTEMAS Y SERVICIOS S.L.が生産するTelosBモート[Advantic]は同様のサイズですが、より多くのメモリを提供します（48 kbフラッシュ、1024 kbシリアル、フラッシュ、10 kb RAM、16 kb構成EEPROM）。 OpenMoteについても同様ですが、512 kbのフラッシュと32 kbのRAMが提供されています[openMote]。
Network protocols used on such hardware need to respect these constraints. They must be simple to implement using little code and little run-time memory and should produce little overhead when encoding the application payload.
このようなハードウェアで使用されるネットワークプロトコルは、これらの制約を尊重する必要があります。コードとランタイムメモリをほとんど使用せずに実装するのが簡単で、アプリケーションのペイロードをエンコードするときにオーバーヘッドがほとんど発生しないはずです。
Smart meters that are battery powered have hard energy constraints [Schmitt09]. If two AA 2800-mAh batteries power the mote, they contain approximately 30,240 Joule of energy. If they run out of power, their battery has to be changed, which means physical manipulation to the device is necessary. Therefore, using as little energy as possible for network communication is desired.
電池式のスマートメーターには厳しいエネルギー制約があります[Schmitt09]。 2つのAA 2800-mAhバッテリーがモートに電力を供給する場合、それらには約30,240ジュールのエネルギーが含まれます。電源が切れた場合、バッテリーを交換する必要があります。つまり、デバイスを物理的に操作する必要があります。したがって、ネットワーク通信にできるだけ少ないエネルギーを使用することが望まれます。
A smart-metering device can save a lot of energy, if it powers down its radio-frequency transceiver. Such devices do not have permanent network connectivity; they are only part of the network as needed. A push protocol, where only one side is sending data, is suitable for transmitting application data under such circumstances. As the communication is unidirectional, a meter can completely power down its radio-frequency transceivers as long as it does not have any data to send. If the metering device is able to keep a few measurements in memory, and if real-time metering is not a requirement, the TinyIPFIX Data Records can be pushed less frequently, therefore saving some more energy on the radio-frequency transceivers.
スマートメータリングデバイスは、無線周波数トランシーバーの電源を切ると、多くのエネルギーを節約できます。このようなデバイスには、永続的なネットワーク接続はありません。それらは必要に応じてネットワークの一部にすぎません。このような状況でアプリケーションデータを送信するには、片側だけがデータを送信するプッシュプロトコルが適しています。通信は単方向であるため、送信するデータがない限り、メーターは無線周波数トランシーバーを完全にパワーダウンできます。計測デバイスがいくつかの計測値をメモリに保持でき、リアルタイムの計測が必要ない場合は、TinyIPFIXデータレコードのプッシュ頻度を減らすことができるため、無線周波数トランシーバーのエネルギーを節約できます。
TinyIPFIX is mainly targeted for the use in 6LoWPAN networks, which are based on IEEE 802.15.4 [RFC4944]. However, the protocol can also be used to transmit data in other networks when a mediator is used for translating the TinyIPFIX data into the data format used in the other network (e.g., IPFIX). And the protocol is able to map the 6LoWPAN addresses to the addresses used in the other network. This operation typically consists of per-message re-encapsulation and/or re-encoding. As defined [RFC4944], IEEE 802.15.4 starts from a maximum physical layer packet size of 127 octets (aMaxPHYPacketSize) and a maximum frame overhead of 25 octets (aMaxFrameOverhead), leaving a maximum frame size of 102 octets at the media access control (MAC) layer. On the other hand, IPv6 defines a minimum MTU of 1280 octets. Hence, fragmentation has to be implemented in order to transmit such large packets. While fragmentation allows the transmission of large messages, its use is problematic in networks with high packet loss because the complete message has to be discarded if only a single fragment gets lost.
TinyIPFIXは主に、IEEE 802.15.4 [RFC4944]に基づく6LoWPANネットワークでの使用を対象としています。ただし、メディエータを使用してTinyIPFIXデータを他のネットワークで使用されているデータ形式（IPFIXなど）に変換する場合、このプロトコルを使用して他のネットワークでデータを送信することもできます。また、このプロトコルは、6LoWPANアドレスを他のネットワークで使用されているアドレスにマップできます。この操作は通常、メッセージごとの再カプセル化および/または再エンコードで構成されます。 [RFC4944]で定義されているように、IEEE 802.15.4は127オクテットの最大物理層パケットサイズ（aMaxPHYPacketSize）と25オクテットの最大フレームオーバーヘッド（aMaxFrameOverhead）から始まり、メディアアクセスコントロールで最大フレームサイズ102オクテットを残します（ MAC）レイヤー。一方、IPv6は1280オクテットの最小MTUを定義します。したがって、そのような大きなパケットを送信するためには、フラグメンテーションを実装する必要があります。断片化は大きなメッセージの送信を可能にしますが、パケットの損失が多いネットワークでは、単一のフラグメントのみが失われた場合にメッセージ全体を破棄する必要があるため、その使用には問題があります。
TinyIPFIX enhances IPFIX by a header-compression scheme, which allows the header size overhead to be significantly reduced. Additionally, the overall TinyIPFIX Message size is reduced, which reduces the need for fragmentation.
TinyIPFIXは、ヘッダー圧縮スキームによってIPFIXを拡張します。これにより、ヘッダーサイズのオーバーヘッドを大幅に削減できます。さらに、全体的なTinyIPFIXメッセージサイズが小さくなり、断片化の必要性が少なくなります。
The IPFIX standard [RFC7011] defines several transport protocol bindings for the transmission of IPFIX Messages. Stream Control Transmission Protocol (SCTP) support is REQUIRED for any IPFIX Device to achieve standard conformance [RFC7011], and its use is highly recommended. However, sending IPFIX over UDP and TCP MAY also be implemented.
IPFIX標準[RFC7011]は、IPFIXメッセージの送信用にいくつかのトランスポートプロトコルバインディングを定義しています。ストリームコントロールトランスミッションプロトコル（SCTP）のサポートは、標準の準拠[RFC7011]を達成するためにすべてのIPFIXデバイスで必須であり、その使用を強くお勧めします。ただし、UDPおよびTCPを介したIPFIXの送信も実装される場合があります。
This transport protocol recommendation is not suitable for TinyIPFIX. A header compression scheme that allows a compression of an IPv6 header from 40 octets down to 2 octets is defined in 6LoWPAN. There is a similar compression scheme for UDP, but there is no such compression for TCP or SCTP headers. If header compression can be employed, more space for application payload is available.
このトランスポートプロトコルの推奨事項は、TinyIPFIXには適していません。 6LoWPANでは、IPv6ヘッダーを40オクテットから2オクテットに圧縮できるヘッダー圧縮スキームが定義されています。 UDPにも同様の圧縮方式がありますが、TCPまたはSCTPヘッダーにはそのような圧縮はありません。ヘッダー圧縮を使用できる場合、アプリケーションペイロード用により多くのスペースを使用できます。
Therefore, using UDP on the transport layer for transmitting TinyIPFIX Messages is RECOMMENDED. Furthermore, TCP or SCTP are currently not supported on some platforms, like on TinyOS [Harvan08]. Hence, UDP may be the only option.
したがって、TinyIPFIXメッセージを送信するためにトランスポート層でUDPを使用することをお勧めします。さらに、TCPまたはSCTPは、TinyOS [Harvan08]などの一部のプラットフォームでは現在サポートされていません。したがって、UDPが唯一のオプションである場合があります。
Every TinyIPFIX Exporter and Collector MUST implement UDP transport-layer support for transmitting data in a constrained network environment. It MAY also offer TCP or SCTP support. In the case in which TCP or SCTP MAY be used, power consumption will grow and the available size of application payload compared to the use of UDP May be reduced. If TinyIPFIX is transmitted over a unconstrained network, using SCTP as a transport-layer protocol is RECOMMENDED. TinyIPFIX works independent of the target environment, because it MUST only be ensured that all intermediate devices can understand TinyIPFIX and be able to extract needed packet information (e.g., IP destination address). TinyIPFIX messages can be included in other transport protocols in the payload whenever is necessary, making TinyIPFIX highly flexible and usable for different communication protocols (e.g., Constrained Application Protocol (CoAP), UDP, TCP). TinyIPFIX itself just specifies a messages format for the collected data to be transmitted.
すべてのTinyIPFIXエクスポーターとコレクターは、制約されたネットワーク環境でデータを送信するためのUDPトランスポート層サポートを実装する必要があります。また、TCPまたはSCTPサポートを提供する場合があります。 TCPまたはSCTPを使用する場合は、消費電力が増加し、UDPを使用する場合と比較して、アプリケーションペイロードの使用可能なサイズが減少する場合があります。 TinyIPFIXが制約のないネットワークを介して送信される場合、トランスポート層プロトコルとしてSCTPを使用することをお勧めします。 TinyIPFIXは、すべての中間デバイスがTinyIPFIXを理解し、必要なパケット情報（IP宛先アドレスなど）を抽出できることのみを保証する必要があるため、ターゲット環境とは無関係に機能します。 TinyIPFIXメッセージは、必要に応じてペイロード内の他のトランスポートプロトコルに含めることができるため、TinyIPFIXは非常に柔軟性が高く、さまざまな通信プロトコル（たとえば、制約付きアプリケーションプロトコル（CoAP）、UDP、TCP）で使用できます。 TinyIPFIX自体は、送信される収集データのメッセージ形式を指定するだけです。
The constraints on UDP usage given in Section 6.2 of [RFC5153] apply to TinyIPFIX as well. TinyIPFIX is not intended for use over the open Internet. In general, the networks on which it runs are considered dedicated for sensor operations and are under the control of a single administrative domain.
[RFC5153]のセクション6.2に記載されているUDPの使用に関する制約は、TinyIPFIXにも適用されます。 TinyIPFIXは、オープンインターネット上での使用を意図していません。一般に、それが実行されるネットワークはセンサー操作専用であると見なされ、単一の管理ドメインの制御下にあります。
TinyIPFIX is derived from IPFIX [RFC7011]; therefore, it is a unidirectional push protocol assuming UDP usage. This means all communication that employs TinyIPFIX is unidirectional from an Exporting Process to a Collecting Process. Hence, TinyIPFIX only fits for application scenarios where meters transmit data to one or more Collectors. In case pull requests should also be supported by TinyIPFIX, it is RECOMMENDED not to change the code of TinyIPFIX much to get along with the restricted memory available [Schmitt2017]. Meaning including just a one bit field, called type, to distinguish between push and pull messages would be feasible, but the filtering SHOULD be done by the gateway and not by the constrained device; meaning if a pull is performed, the constrained device is triggered to create a TinyIPFIX message immediately as usual, set the type field to one instead of zero (for a push message), and send message to the gateway. At the gateway, the filtering is performed based on the pull request.
TinyIPFIXはIPFIX [RFC7011]から派生しています。したがって、UDPの使用を想定した単方向のプッシュプロトコルです。つまり、TinyIPFIXを使用するすべての通信は、エクスポートプロセスから収集プロセスへの単一方向です。したがって、TinyIPFIXは、メーターが1つ以上のコレクターにデータを送信するアプリケーションシナリオにのみ適合します。プルリクエストもTinyIPFIXでサポートする必要がある場合は、TinyIPFIXのコードをあまり変更せずに、利用可能な制限されたメモリを利用することをお勧めします[Schmitt2017]。プッシュメッセージとプルメッセージを区別するために、タイプと呼ばれる1ビットのフィールドのみを含めることは可能ですが、フィルタリングは制約されたデバイスではなくゲートウェイで行う必要があります。つまり、プルが実行されると、制約されたデバイスがトリガーされ、通常どおりすぐにTinyIPFIXメッセージが作成され、タイプフィールドがゼロではなく1に設定され（プッシュメッセージの場合）、メッセージがゲートウェイに送信されます。ゲートウェイでは、プル要求に基づいてフィルタリングが実行されます。
If TinyIPFIX is used over UDP, as recommended, packet loss can occur. Furthermore, if an initial Template Message gets lost, and is therefore unknown to the Collector, all TinyIPFIX Data Sets that reference this Template cannot be decoded. Hence, all these Messages are lost if they are not cached by the Collector. It should be clear to an application developer that TinyIPFIX can only be used over UDP if these TinyIPFIX Message losses are not a problem. To avoid this loss, it is RECOMMENDED to repeat the Template Message periodically, keeping in mind that a Template never changes for a constrained device after deployment. Even when Template Messages become lost in the network, the data can be manually translated later when the Template Messages is re-sent. Including an acknowledgement mechanism is NOT RECOMMENDED due to overhead, because this would require storage of any sent data on the constrained devices until it was acknowledged. In critical applications, it is RECOMMENDED to repeat the Template Message more often.
TinyIPFIXをUDP経由で使用すると、推奨されるように、パケット損失が発生する可能性があります。さらに、最初のテンプレートメッセージが失われ、そのためコレクタに認識されない場合、このテンプレートを参照するすべてのTinyIPFIXデータセットをデコードできません。したがって、コレクタによってキャッシュされない場合、これらのメッセージはすべて失われます。 TinyIPFIXは、これらのTinyIPFIXメッセージの損失が問題ではない場合にのみ、UDPでのみ使用できることをアプリケーション開発者に明らかにする必要があります。この損失を回避するには、テンプレートメッセージを定期的に繰り返すことをお勧めします。展開後、制約されたデバイスのテンプレートは決して変更されないことに注意してください。テンプレートメッセージがネットワークで失われた場合でも、後でテンプレートメッセージを再送信すると、データを手動で変換できます。確認応答メカニズムを含めることは、オーバーヘッドが原因で推奨されません。これは、確認応答されるまで、制約されたデバイスに送信データを保存する必要があるためです。重要なアプリケーションでは、テンプレートメッセージをより頻繁に繰り返すことをお勧めします。
TinyIPFIX over UDP is especially not a suitable protocol for applications where sensor data trigger policy decisions or configuration updates for which packet loss is not tolerable.
TinyIPFIX over UDPは、センサーデータがポリシーの決定をトリガーするアプリケーションや、パケット損失が許容されない構成の更新に適したプロトコルではありません。
Applications that use smart sensors for accounting purposes for long-term measurements can benefit from the use of TinyIPFIX. One application for IPFIX is long-term monitoring of large physical volumes. In [Tolle05], Tolle et al. built a system for monitoring a "70-meter tall redwood tree, at a density interval of 5 minutes in time and 2 meters in space". The sensor node infrastructure was deployed to measure the air temperature, relative humidity, and photosynthetically active solar radiation over a long-term period.
長期測定の会計目的でスマートセンサーを使用するアプリケーションでは、TinyIPFIXを使用するとメリットがあります。 IPFIXの1つのアプリケーションは、大規模な物理ボリュームの長期監視です。 [Tolle05]では、Tolle et al。 「高さ70メートルのレッドウッドツリー、時間間隔5分、空間2メートルの密度間隔で」を監視するシステムを構築しました。センサーノードインフラストラクチャは、長期間にわたって気温、相対湿度、および光合成でアクティブな日射量を測定するために導入されました。
TinyIPFIX is a good fit for such scenarios. Data can be measured by the sensors of the TinyIPFIX Smart Meter over several 5-minute time intervals; the measurements can be accumulated into a single TinyIPFIX Message. As soon as enough measurements are stored in the TinyIPFIX Message, e.g., if the TinyIPFIX Message size fills the available payload in a single IEEE 802.15.4 packet, the wireless transceiver can be activated and the TinyIPFIX Message can be exported to a TinyIPFIX Collector.
TinyIPFIXは、このようなシナリオに適しています。 TinyIPFIXスマートメーターのセンサーで、5分の時間間隔でデータを測定できます。測定値は単一のTinyIPFIXメッセージに蓄積できます。十分な測定値がTinyIPFIXメッセージに保存されるとすぐに、たとえば、TinyIPFIXメッセージのサイズが単一のIEEE 802.15.4パケットで利用可能なペイロードを満たす場合、ワイヤレストランシーバーをアクティブにして、TinyIPFIXメッセージをTinyIPFIXコレクターにエクスポートできます。
Similar sensor networks have been built to monitor the habitat of animals, e.g., in the "Great Duck Island Project" [GreatDuck] [SMPC04]. The purpose of the sensor network was to monitor the birds by deploying sensors in and around their burrows. The measured sensor data was collected and stored in a database for offline analysis and visualization. Again, the sensors can perform their measurements periodically, accumulate the sensor data, and export them to a TinyIPFIX Collector.
同様のセンサーネットワークは、たとえば「グレートダックアイランドプロジェクト」[GreatDuck] [SMPC04]で、動物の生息地を監視するために構築されています。センサーネットワークの目的は、巣穴の中や周囲にセンサーを配置して鳥を監視することでした。測定されたセンサーデータが収集され、オフラインで分析および視覚化するためにデータベースに保存されました。この場合も、センサーは定期的に測定を実行し、センサーデータを蓄積して、TinyIPFIXコレクターにエクスポートできます。
Other application scenarios for TinyIPFIX could be applications where sensor networks are used for long-term structural health monitoring in order to investigate long-term weather conditions on the structure of a building. For example, a smart-metering network has been built to monitor the structural health of the Golden Gate Bridge [Kim07]. If a sensor network is deployed to perform a long-term measurement of the structural integrity, TinyIPFIX can be used to collect the sensor-measurement data.
TinyIPFIXの他のアプリケーションシナリオは、建物の構造の長期的な気象条件を調査するために、長期的な構造ヘルスモニタリングにセンサーネットワークが使用されるアプリケーションです。たとえば、スマートメーターネットワークは、ゴールデンゲートブリッジの構造的な状態を監視するために構築されています[Kim07]。構造的完全性の長期測定を実行するためにセンサーネットワークが導入されている場合、TinyIPFIXを使用してセンサー測定データを収集できます。
If an application developer wants to decide whether to use TinyIPFIX for transmitting data from smart meters, he must take the following considerations into account:
アプリケーション開発者がスマートメーターからのデータの送信にTinyIPFIXを使用するかどうかを決定する場合、次の考慮事項を考慮する必要があります。
1. The application should require a push protocol by default. The timing intervals of when to push data should be predefined before deployment. The property above allows a TinyIPFIX Smart Meter to turn off its wireless device in order to save energy, as it does not have to receive any data.
1. アプリケーションでは、デフォルトでプッシュプロトコルが必要です。データをプッシュするタイミング間隔は、展開前に事前定義する必要があります。上記のプロパティを使用すると、データを受信する必要がないため、エネルギーを節約するためにTinyIPFIXスマートメーターがワイヤレスデバイスをオフにすることができます。
2. If real-time reporting is not required, the application might benefit from combining several measurements into a single TinyIPFIX Message, causing delay but lowering traffic in the network. TinyIPFIX easily allow the combination of several measurements into a single TinyIPFIX Message (or a single packet). This combination can happen on the TinyIPFIX Smart Meter that combines several of its own measurements. Or, it can happen within a multi-hop wireless network where one IPFIX Proxy combines several TinyIPFIX Messages into a single TinyIPFIX Message before forwarding them.
2. リアルタイムのレポートが不要な場合、アプリケーションは複数の測定値を単一のTinyIPFIXメッセージに結合することで利益を得る可能性があり、遅延を引き起こしますがネットワークのトラフィックを低下させます。 TinyIPFIXを使用すると、複数の測定値を1つのTinyIPFIXメッセージ（または1つのパケット）に簡単に組み合わせることができます。この組み合わせは、独自の測定値のいくつかを組み合わせたTinyIPFIXスマートメーターで発生する可能性があります。または、1つのIPFIXプロキシが転送する前に複数のTinyIPFIXメッセージを1つのTinyIPFIXメッセージに結合するマルチホップワイヤレスネットワーク内で発生する可能性があります。
3. The application must accept potential packet loss. TinyIPFIX only fits for applications where metering data is stored for accounting purposes and not for applications where the sensor data triggers configuration changes or policy decisions, except when Message loss is acceptable for some reason.
3. アプリケーションは、潜在的なパケット損失を受け入れる必要があります。 TinyIPFIXは、メータリングデータが会計目的で保存されるアプリケーションにのみ適合し、何らかの理由でメッセージの損失が許容される場合を除いて、センサーデータが構成の変更やポリシーの決定をトリガーするアプリケーションには適合しません。
4. The application must not require per-message export timestamps (e.g., for auditing). TinyIPFIX removes export timestamps, generally only useful for Template Management operations, which it also does not support, from IPFIX. This is a minor inconvenience, since per-record timestamp Information Elements are also available in IPFIX.
4. アプリケーションは、メッセージごとのエクスポートタイムスタンプ（監査など）を要求してはなりません。 TinyIPFIXは、エクスポートタイムスタンプを削除します。これは、通常、テンプレート管理操作にのみ役立ちますが、これもサポートしていないため、IPFIXからは削除されません。レコードごとのタイムスタンプ情報要素もIPFIXで利用できるため、これはマイナーな不便です。
The TinyIPFIX architecture is similar to the IPFIX architecture, which is described in [RFC5470]. The most common deployment of TinyIPFIX Smart Meters is shown in Figure 1, where each TinyIPFIX Smart Meter can have different sensors available (e.g., IRIS: Temperature, Humidity, Sound; TelosB: Temperature, Bridgeness, Humidity, GPS) building the sensor data.
TinyIPFIXアーキテクチャは、[RFC5470]で説明されているIPFIXアーキテクチャに似ています。 TinyIPFIXスマートメーターの最も一般的な展開を図1に示します。ここで、各TinyIPFIXスマートメーターは、センサーデータを構築するさまざまなセンサー（IRIS：温度、湿度、サウンド、TelosB：温度、ブリッジネス、湿度、GPSなど）を利用できます。
+------------------------+ +------------------------+
| TinyIPFIX Device | ... | TinyIPFIX Device |
| [Exporting Process] | | [Exporting Process] |
+------------------------+ +------------------------+
| |
TinyIPFIX | | TinyIPFIX
| |
v v
+----------------------------------+
|
v
+----------------------------+
| TinyIPFIX Collector |
| [Collecting Process(es)] |
+----------------------------+
|
v
+-----------------------+
| |
v v
+----------------+ +----------------+
|[*Application 1]| ... |[*Application n]|
+----------------+ +----------------+
Figure 1: Direct Transmission between TinyIPFIX Devices and Applications
図1：TinyIPFIXデバイスとアプリケーション間の直接伝送
A TinyIPFIX Smart Meter (S.M.) receives measurement data from its internal sensors to create its TinyIPFIX Messages. Then, it encodes the results into a TinyIPFIX Message using a TinyIPFIX Exporting Process and exports this TinyIPFIX Message to one or more TinyIPFIX Collectors. The TinyIPFIX Collector runs one or more applications that process the collected sensor data. The TinyIPFIX Collector can be deployed on unconstrained devices at the constrained network border.
TinyIPFIXスマートメーター（S.M.）は、内部センサーから測定データを受信して、TinyIPFIXメッセージを作成します。次に、TinyIPFIXエクスポートプロセスを使用して結果をTinyIPFIXメッセージにエンコードし、このTinyIPFIXメッセージを1つ以上のTinyIPFIXコレクターにエクスポートします。 TinyIPFIX Collectorは、収集されたセンサーデータを処理する1つ以上のアプリケーションを実行します。 TinyIPFIX Collectorは、制約のあるネットワーク境界にある制約のないデバイスに展開できます。
A second way to deploy TinyIPFIX Smart Meter can employ accumulation on TinyIPFIX Messages during their journey through the constrained network as shown in Figure 2. This accumulation can be performed by TinyIPFIX Concentrators. Such devices must have enough resources to perform the accumulation.
TinyIPFIXスマートメーターを展開する2番目の方法は、図2に示すように、制約されたネットワークを通過する間にTinyIPFIXメッセージの累積を使用できます。この累積はTinyIPFIXコンセントレーターによって実行できます。そのようなデバイスには、累積を実行するのに十分なリソースが必要です。
+------------------------+ +------------------------+
| TinyIPFIX Device | ... | TinyIPFIX Device |
| [Exporting Process] | | [Exporting Process] |
+------------------------+ +------------------------+
| |
TinyIPFIX | | TinyIPFIX
| |
v v
+----------------------------------+
|
v
+------------------------+
| TinyIPFIX Concentrator |
| [Collecting Process] |
| [Exporting Process] |
+------------------------+
|
TinyIPFIX |
|
v
+--------------------------+
| Collector |
| [Collecting Process(es)] |
+--------------------------+
Figure 2: Accumulation of TinyIPFIX
図2：TinyIPFIXの蓄積
TinyIPFIX Smart Meters send their data to a TinyIPFIX Concentrator, which needs to have enough storage space to store the incoming data. If the TinyIPFIX Concentrator is hosted in a TinyIPFIX Smart Meter, it MAY also be able to collect data from it sensors, if activated. It may also accumulate the incoming data with its own measurement data. The accumulated data can then be re-exported to one or more Collectors. In that case, the TinyIPFIX Concentrator can be viewed as receiving data from multiple Smart Meters: one locally and some remotely.
TinyIPFIXスマートメーターは、データをTinyIPFIXコンセントレータに送信します。これには、着信データを格納するための十分なストレージスペースが必要です。 TinyIPFIXコンセントレータがTinyIPFIXスマートメーターでホストされている場合、アクティブ化されていれば、センサーからデータを収集することもできます（MAY）。また、受信データを独自の測定データとともに蓄積する場合もあります。蓄積されたデータは、1つ以上のコレクターに再エクスポートできます。その場合、TinyIPFIXコンセントレータは、ローカルとリモートの複数のスマートメーターからデータを受信していると見なすことができます。
The last deployment, shown in Figure 3, employs another TinyIPFIX Mediation process.
図3に示す最後の展開では、別のTinyIPFIXメディエーションプロセスを採用しています。
+-------------------------+ +-------------------------+
| Remote Smart Meter | | Local Smart Meter |
+-------------------------+ +-------------------------+
| TinyIPFIX Device | | TinyIPFIX Device |
| [Exporting Process] | | [Exporting Process] |
+-------------------------+ +-------------------------+
| |
TinyIPFIX | | TinyIPFIX
| |
v v
+-------------------------+
| TinyIPFIX Concentrator |
| [Collecting Process] |
+-------------------------+
Figure 3: TinyIPFIX Mediator
図3：TinyIPFIXメディエーター
In this deployment, the TinyIPFIX Smart Meters transmit their TinyIPFIX Messages to one node, e.g., the base station, which translates the TinyIPFIX Messages to IPFIX Messages. The IPFIX Messages can then be exported into an existing IPFIX infrastructure. The Mediation process from TinyIPFIX to IPFIX is described in Section 7.
この配置では、TinyIPFIXスマートメーターは、TinyIPFIXメッセージを1つのノード（基地局など）に送信します。これにより、TinyIPFIXメッセージがIPFIXメッセージに変換されます。その後、IPFIXメッセージを既存のIPFIXインフラストラクチャにエクスポートできます。 TinyIPFIXからIPFIXへの仲介プロセスについては、セクション7で説明します。
A TinyIPFIX IPFIX Message starts with a TinyIPFIX Message Header, followed by one or more TinyIPFIX Sets. The TinyIPFIX Sets can be either of type TinyIPFIX Template Set or of type TinyIPFIX Data Set. A TinyIPFIX Message MUST only contain one type of TinyIPFIX Set. The format of the TinyIPFIX Message is shown in Figure 4.
TinyIPFIX IPFIXメッセージは、TinyIPFIXメッセージヘッダーで始まり、その後に1つ以上のTinyIPFIXセットが続きます。 TinyIPFIXセットは、タイプTinyIPFIXテンプレートセットまたはタイプTinyIPFIXデータセットのいずれかになります。 TinyIPFIXメッセージには、1種類のTinyIPFIXセットのみを含める必要があります。 TinyIPFIXメッセージのフォーマットを図4に示します。
+----------------------------------------------------+
| TinyIPFIX Message Header |
+----------------------------------------------------+
| TinyIPFIX Set |
+----------------------------------------------------+
| TinyIPFIX Set |
+----------------------------------------------------+
...
+----------------------------------------------------+
| TinyIPFIX Set |
+----------------------------------------------------+
Figure 4: TinyIPFIX Message Format
図4：TinyIPFIXメッセージ形式
The TinyIPFIX Message Header is derived from the IPFIX Message Header, with some optimization using field compression. The IPFIX Message Header from [RFC7011] is shown in Figure 5.
TinyIPFIXメッセージヘッダーはIPFIXメッセージヘッダーから派生し、フィールド圧縮を使用して最適化されています。 [RFC7011]からのIPFIXメッセージヘッダーを図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPFIX Message Header
図5：IPFIXメッセージヘッダー
The length of the IPFIX Message Header is 16 octets, and every IPFIX Message has to be started with it. The TinyIPFIX Message Header needs to be smaller due to the packet size constraints discussed in Section 3.3. The TinyIPFIX Header consists of a fixed part of three octets as shown in Figure 6, followed by a variable part as shown in Figures 7 to 10.
IPFIXメッセージヘッダーの長さは16オクテットであり、すべてのIPFIXメッセージはそれで開始する必要があります。セクション3.3で説明したパケットサイズの制約のため、TinyIPFIXメッセージヘッダーを小さくする必要があります。 TinyIPFIXヘッダーは、図6に示すように3オクテットの固定部分で構成され、その後に図7〜10に示すように可変部分が続きます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|E| SetID | Length | Sequence | Ext. Sequence |
|1|2|Lookup | | Number | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext. SetID |
+-+-+-+-+-+-+-+-+
Figure 6: Format of the TinyIPFIX Message Header including Fixed and Optional Parts
図6：固定パーツとオプションパーツを含むTinyIPFIXメッセージヘッダーのフォーマット
The fixed part has a length of 3 octets and consists of the "E1" field (1 bit), the "E2" field (1 bit), the "SetID Lookup" field (4 bits), the "Length" field (10 bits), and the "Sequence Number" field (8 bits). The variable part has a variable length defined by the "E1" and "E2" fields in the fixed header. The four variants are illustrated in Figure 7 to Figure 10 below.
固定部分の長さは3オクテットで、「E1」フィールド（1ビット）、「E2」フィールド（1ビット）、「SetID Lookup」フィールド（4ビット）、「Length」フィールド（10ビット）、および「シーケンス番号」フィールド（8ビット）。可変部分には、固定ヘッダーの「E1」および「E2」フィールドで定義される可変長があります。 4つのバリアントを以下の図7から図10に示します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| SetID | Length | Sequence |
| | |Lookup | | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: TinyIPFIX Message Header Format if E1 = E2 = 0
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| SetID | Length | Sequence | Ext. SetID |
| | |Lookup | | Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: TinyIPFIX Message Header Format if E1 = 1 and E2 = 0
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|E| SetID | Length | Sequence | Ext. Sequenz |
|1|2|Lookup | | Number | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: TinyIPFIX Message Header Format if E1 = 0 and E2 = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| SetID | Length | Sequence | Ext. Sequenz |
| | |Lookup | | Number | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext. SetID |
+-+-+-+-+-+-+-+-+
Figure 10: TinyIPFIX Message Header Format if E1 = E2 = 1
The fixed header fields are defined as follows [Kothmayr10] [Schmitt2014]:
固定ヘッダーフィールドは次のように定義されています[Kothmayr10] [Schmitt2014]：
E1 and E2
E1およびE2
The bits marked "E1" and "E2" control the presence of the field "Ext. SetID" and the presence of the field "Ext. Sequence Number", respectively.
「E1」および「E2」とマークされたビットは、フィールド「Ext。SetID」の存在とフィールド「Ext。Sequence Number」の存在をそれぞれ制御します。
In case E1 = E2 = 0, the TinyIPFIX Message Header has the format shown in Figure 7. The fields Extended Sequence Number and Extended SetID MUST NOT be present.
E1 = E2 = 0の場合、TinyIPFIXメッセージヘッダーの形式は図7に示されています。フィールドExtended Sequence NumberおよびExtended SetIDは存在してはいけません。
When E1 = 1, the extended SetID field MUST be present. Custom SetIDs can be specified in the extended SetID field, setting all SetID Lookup bits to 1 (cf. Figure 8.) When evaluated, the value specified in the extended SetID field is shifted left by 8 bits to prevent collisions with the reserved SetIDs 0-255. To reference these, shifting can be disabled by setting all SetID lookup bits to 1.
E1 = 1の場合、拡張SetIDフィールドが存在する必要があります。カスタムSetIDは拡張SetIDフィールドで指定でき、すべてのSetID Lookupビットを1に設定します（図8を参照）。評価されると、拡張SetIDフィールドで指定された値は左に8ビットシフトされ、予約済みSetIDs 0との衝突を防ぎます。 -255。これらを参照するには、すべてのSetIDルックアップビットを1に設定することで、シフトを無効にできます。
Depending on the application, sampling rates might be larger than in typical constrained networks (e.g., Wireless Sensor Networks (WSNs), Cyber-Physical-Systems (CPS)); thus, they may have a large quantity of records per packet. In order to make TinyIPFIX applicable for those cases, E2 = 1 is set (cf. Figure 9). This means the Extended Sequence Number field MUST be present, offering 8-bit more sequence numbers as usual. Depending on the constrained network settings, the combination E1 = E2 = 1 is also possible, resulting in the maximum TinyIPFIX Message header shown in Figure 10 where the Extended Sequence Number field and Extended SetID field MUST both be present.
アプリケーションによっては、サンプリングレートが通常の制約付きネットワーク（ワイヤレスセンサーネットワーク（WSN）、サイバーフィジカルシステム（CPS）など）よりも大きくなる場合があります。したがって、パケットごとに大量のレコードが存在する可能性があります。これらの場合にTinyIPFIXを適用できるようにするには、E2 = 1を設定します（図9を参照）。これは、拡張シーケンス番号フィールドが存在する必要があり、通常どおり8ビット以上のシーケンス番号を提供することを意味します。制約のあるネットワーク設定によっては、E1 = E2 = 1の組み合わせも可能であり、拡張シーケンス番号フィールドと拡張SetIDフィールドの両方が存在する必要がある図10に示す最大のTinyIPFIXメッセージヘッダーになります。
SetID Lookup
SetIDルックアップ
This field acts as a lookup field for the SetIDs and provides shortcuts to often used SetIDs. Four values are defined:
このフィールドは、SetIDのルックアップフィールドとして機能し、頻繁に使用されるSetIDへのショートカットを提供します。 4つの値が定義されています。
Value = 0; Look up extended SetID field, Shifting enabled.
値= 0;シフトが有効になっている拡張SetIDフィールドを検索します。
Value = 1; SetID = 2 and message contains a Template definition.
値= 1; SetID = 2で、メッセージにはテンプレート定義が含まれています。
Value = 2; SetID = 256 and message contains Data Record for Template 256. This places special importance on a single template ID, but, since most sensor nodes only define a single template directly after booting and continue to stream data with this template ID during the whole session lifetime, this shorthand is useful for this case.
値= 2; SetID = 256で、メッセージにはテンプレート256のデータレコードが含まれます。これにより、単一のテンプレートIDが特に重要になります。ただし、ほとんどのセンサーノードは、ブート直後に単一のテンプレートのみを定義し、セッションの存続期間全体を通してこのテンプレートIDでデータをストリーミングし続けるためです。 、この省略形はこの場合に役立ちます。
Value = 3-14; SetIDs are reserved for future extensions.
値= 3-14; SetIDは将来の拡張のために予約されています。
Value = 15; look up extended SetID field, shifting enabled.
値= 15;シフトが有効になっている拡張SetIDフィールドを検索します。
Length
長さ
The length field has a fixed length of 10 bits.
長さフィールドは10ビットの固定長です。
Sequence Number
シーケンス番号
Due to the low sampling rate in typical WSNs, the "Sequence Number" field is only one byte long. However, some applications may have a large quantity of records per packet. In this case, the sequence field can be extended to 16 bit by setting the E2-bit to 1.
一般的なWSNではサンプリングレートが低いため、「シーケンス番号」フィールドの長さは1バイトのみです。ただし、アプリケーションによっては、パケットごとに大量のレコードがある場合があります。この場合、E2ビットを1に設定することにより、シーケンスフィールドを16ビットに拡張できます。
Since TinyIPFIX packets are always transported via a network protocol, which specifies the source of the packet, the "Observation Domain" can be equated with the source of a TinyIPFIX packet. Therefore, this IPFIX field has been removed from the TinyIPFIX Header. Should an application require explicit Observation Domain information, each Data Record in the TinyIPFIX data message may contain an Observation Domain ID Information Element; see Section 3.1 of [RFC7011]. The version field has been removed since the SetID lookup field provides room for future extensions. The specification of a 32-bit timestamp in seconds would require the time synchronization across a wireless-sensor network and produces too much overhead. Thus, the "Export Time" field has been removed. If applications should require a concrete observation time (e.g., timestamp), it is RECOMMENDED to include it as a separate Information Element in the TinyIPFIX Records.
TinyIPFIXパケットは常に、パケットのソースを指定するネットワークプロトコルを介して転送されるため、「観測ドメイン」はTinyIPFIXパケットのソースと同等と見なすことができます。したがって、このIPFIXフィールドはTinyIPFIXヘッダーから削除されました。アプリケーションが明示的な観測ドメイン情報を必要とする場合、TinyIPFIXデータメッセージの各データレコードに観測ドメインID情報要素を含めることができます。 [RFC7011]のセクション3.1をご覧ください。 SetIDルックアップフィールドは将来の拡張の余地を提供するため、バージョンフィールドは削除されました。 32ビットのタイムスタンプを秒単位で指定するには、ワイヤレスセンサーネットワーク全体で時刻を同期する必要があり、オーバーヘッドが多すぎます。したがって、「エクスポート時間」フィールドは削除されました。アプリケーションで具体的な観測時間（タイムスタンプなど）が必要な場合は、TinyIPFIXレコードに個別の情報要素として含めることをお勧めします。
A TinyIPFIX Set is a set of TinyIPFIX Template or TinyIPFIX Data Records. Depending on the TinyIPFIX Record type, the TinyIPFIX Set can be either a TinyIPFIX Template Set or a TinyIPFIX Data Set. Every TinyIPFIX Set starts with a TinyIPFIX Set Header and is followed by one or more TinyIPFIX Records.
TinyIPFIXセットは、TinyIPFIXテンプレートまたはTinyIPFIXデータレコードのセットです。 TinyIPFIXレコードタイプに応じて、TinyIPFIXセットはTinyIPFIXテンプレートセットまたはTinyIPFIXデータセットのいずれかになります。すべてのTinyIPFIXセットはTinyIPFIXセットヘッダーで始まり、1つ以上のTinyIPFIXレコードが続きます。
The IPFIX Set Header consists of a 2-octet "Set ID" field and a 2-octet "Length" field. These two fields are compressed to 1 octet each for the TinyIPFIX Set Header. The format of the TinyIPFIX Set Header is shown in Figure 11.
IPFIXセットヘッダーは、2オクテットの「セットID」フィールドと2オクテットの「長さ」フィールドで構成されます。これらの2つのフィールドは、TinyIPFIXセットヘッダーのそれぞれ1オクテットに圧縮されます。 TinyIPFIXセットヘッダーのフォーマットを図11に示します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tiny Set ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TinyIPFIX Set Header
図11：TinyIPFIXセットヘッダー
The two fields are defined as follows:
2つのフィールドは次のように定義されます。
TinyIPFIX Set ID
TinyIPFIXセットID
The "Tiny Set ID" identifies the type of data that is transported in the TinyIPFIX Set. A TinyIPFIX Template Set is identified by TinyIPFIX Set ID 2. This corresponds to the Template Set IDs that are used by IPFIX [RFC7011]. TinyIPFIX Set ID number 3 MUST NOT be used, as Options Templates are not supported; a TinyIPFIX Collector MUST ignore and SHOULD log any Set with Set ID 3. All values from 4 to 127 are reserved for future use. Values above 127 are used for TinyIPFIX Data Sets.
「Tiny Set ID」は、TinyIPFIXセットで転送されるデータのタイプを識別します。 TinyIPFIXテンプレートセットは、TinyIPFIXセットID 2で識別されます。これは、IPFIX [RFC7011]で使用されるテンプレートセットIDに対応しています。オプションテンプレートはサポートされていないため、TinyIPFIXセットID番号3は使用しないでください。 TinyIPFIXコレクターは、セットID 3のセットを無視して記録する必要があります（SHOULD）。4から127までのすべての値は、将来の使用のために予約されています。 TinyIPFIXデータセットには、127を超える値が使用されます。
Length
長さ
The "Length" Field contains the total length of the TinyIPFIX Set, including the TinyIPFIX Set Header.
「長さ」フィールドには、TinyIPFIXセットヘッダーを含むTinyIPFIXセットの全長が含まれています。
The format of the TinyIPFIX Template Records is shown in Figure 12. The TinyIPFIX Template Record starts with a TinyIPFIX Template Record Header and this is followed by one or more Field Specifiers. The Field Specifier format is defined as in Section 6.4 and is identical to the Field Specifier definition in [RFC7011].
TinyIPFIXテンプレートレコードのフォーマットを図12に示します。TinyIPFIXテンプレートレコードはTinyIPFIXテンプレートレコードヘッダーで始まり、その後に1つ以上のフィールド指定子が続きます。フィールド指定子の形式はセクション6.4のように定義され、[RFC7011]のフィールド指定子の定義と同じです。
+--------------------------------------------------+
| TinyIPFIX Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
Figure 12: TinyIPFIX Template Format
図12：TinyIPFIXテンプレートの形式
The format of the TinyIPFIX Template Record Header is shown in Figure 13.
TinyIPFIXテンプレートレコードヘッダーのフォーマットを図13に示します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: TinyIPFIX Template Record Header
図13：TinyIPFIXテンプレートレコードヘッダー
TinyIPFIX Template ID
TinyIPFIXテンプレートID
Each TinyIPFIX Template Record must have a unique TinyIPFIX Template ID (Comp. Temp ID) between 128 and 255. The TinyIPFIX Template ID must be unique for the given TinyIPFIX Transport Session.
各TinyIPFIXテンプレートレコードには、128〜255の一意のTinyIPFIXテンプレートID（Comp。Temp ID）が必要です。TinyIPFIXテンプレートIDは、特定のTinyIPFIXトランスポートセッションに対して一意である必要があります。
Field Count
フィールド数
The number of fields placed in the TinyIPFIX Template Record.
TinyIPFIXテンプレートレコードに配置されたフィールドの数。
The type and length of the transmitted data is encoded in Field Specifiers within TinyIPFIX Template Records. The Field Specifier is shown in Figure 14 and is identical with the Field Specifier that was defined for IPFIX [RFC7011].
送信されるデータのタイプと長さは、TinyIPFIXテンプレートレコード内のフィールド指定子でエンコードされます。フィールド指定子を図14に示します。これは、IPFIX [RFC7011]で定義されたフィールド指定子と同じです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Information Element ident. | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: TinyIPFIX Data Field Specifier
図14：TinyIPFIXデータフィールド指定子
Where:
ただし：
E
絵
Enterprise bit. This is the first bit of the Field Specifier. If this bit is zero, the Information Element Identifier identifies an IETF-specified Information Element, and the four-octet Enterprise Number field MUST NOT be present. If this bit is one, the Information Element Identifier identifies an enterprise-specific Information Element, and the Enterprise Number field MUST be present.
エンタープライズビット。これはフィールド指定子の最初のビットです。このビットが0の場合、情報要素識別子はIETF指定の情報要素を識別し、4オクテットのエンタープライズ番号フィールドは存在してはならない（MUST NOT）。このビットが1の場合、情報要素識別子は企業固有の情報要素を識別し、企業番号フィールドが存在しなければなりません（MUST）。
Information Element Identifier
情報要素識別子
A numeric value that represents the type of Information Element.
情報要素のタイプを表す数値。
Field Length
フィールド長
The length of the corresponding encoded Information Element, in octets. Refer to [RFC7012]. The value 65535 is illegal in TinyIPFIX, as variable-length Information Elements are not supported.
オクテットで表した、対応するエンコードされた情報要素の長さ。 [RFC7012]を参照してください。可変長の情報要素はサポートされていないため、値65535はTinyIPFIXでは不正です。
Enterprise Number
企業番号
IANA Private Enterprise Number of the authority defining the Information Element identifier in this Template Record.
IANA Private Enterpriseこのテンプレートレコードで情報要素識別子を定義する機関の番号。
Vendors can easily define their own data model by registering a Enterprise ID with IANA. Using their own Enterprise ID, they can use any ID in the way they want them to use.
ベンダーは、エンタープライズIDをIANAに登録することにより、独自のデータモデルを簡単に定義できます。独自のエンタープライズIDを使用することで、任意のIDを使用したい方法で使用できます。
The Data Records are sent in TinyIPFIX Data Sets. The format of the Data Records is shown in Figure 15 and matches the Data Record format from IPFIX.
データレコードはTinyIPFIXデータセットで送信されます。データレコードの形式を図15に示します。これは、IPFIXのデータレコード形式と一致しています。
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
Figure 15: Data Record Format
図15：データレコードの形式
There are two types of TinyIPFIX Intermediate Processes. The first one can occur on the transition between a constrained network (e.g., 6LoWPAN) and the unconstrained network. This mediation changes the network and transport protocol from 6LoWPAN preferring UDP to IP/(SCTP|TCP|UDP) and is shown in Figure 16.
TinyIPFIX中間プロセスには2つのタイプがあります。最初の問題は、制約付きネットワーク（6LoWPANなど）と制約なしネットワークの間の移行時に発生する可能性があります。このメディエーションは、ネットワークとトランスポートプロトコルを、UDPを優先する6LoWPANからIP /（SCTP | TCP | UDP）に変更します。これを図16に示します。
+-----------------------+
| TinyIPFIX Device |
| [Exporting Process] |
+-----------------------+
|
TinyIPFIX |
over 6LoWPAN/UDP |
v
+-------------------------+
| TinyIPFIX mediator |
| [Collecting Process] |
| [Exporting Process] |
+-------------------------+
|
TinyIPFIX |
IP/(UDP/SCTP|TCP) |
v
+--------------------------+
| Collector |
| [Collecting Process(es)] |
+--------------------------+
Figure 16: Translation from TinyIPFIX over 6LoWPAN/UDP to TinyIPFIX over IP/(SCTP|TCP|UDP)
図16：TinyIPFIX over 6LoWPAN / UDPからTinyIPFIX over IP /（SCTP | TCP | UDP）への変換
The mediator removes the TinyIPFIX Messages from the 6LoWPAN/UDP packets and wraps them into the new network and transport protocols. Templates MUST be managed the same way as in the constrained environment after the translation to IP/(SCTP|UDP|TCP) (see Section 8).
メディエーターは、6LoWPAN / UDPパケットからTinyIPFIXメッセージを削除し、それらを新しいネットワークおよびトランスポートプロトコルにラップします。テンプレートは、IP /（SCTP | UDP | TCP）への変換後、制約された環境と同じ方法で管理する必要があります（セクション8を参照）。
The second type of mediation transforms TinyIPFIX into IPFIX. This process MUST be combined with the transport protocol mediation as shown in Figure 17.
2つ目のタイプのメディエーションは、TinyIPFIXをIPFIXに変換します。このプロセスは、図17に示すように、トランスポートプロトコルメディエーションと組み合わせる必要があります。
+-----------------------+
| TinyIPFIX Device |
| [Exporting Process] |
+-----------------------+
|
TinyIPFIX |
|
v
+-------------------------+
| TinyIPFIX mediator |
| [Collecting Process] |
| [Exporting Process] |
+-------------------------+
|
IPFIX |
IP/(UDP/SCTP|TCP) |
v
+--------------------------+
| Collector |
| [Collecting Process(es)] |
+--------------------------+
Figure 17: Transformation from TinyIPFIX to IPFIX
図17：TinyIPFIXからIPFIXへの変換
This mediation can also be performed by an IPFIX Collector before parsing the IPFIX message as shown in Figure 18. There is no need for a parser from TinyIPFIX to IPFIX if such a mediation process can be employed in front of an existing IPFIX collector.
このメディエーションは、図18に示すように、IPFIXメッセージを解析する前にIPFIXコレクターでも実行できます。既存のIPFIXコレクターの前でそのようなメディエーションプロセスを使用できる場合、TinyIPFIXからIPFIXへのパーサーは必要ありません。
+------------------------+ +----------------------+
| TinyIPFIX Device | TinyIPFIX | IPFIX Mediator |
| [Exporting Processes] |----------------->| [Collecting Process] |
+------------------------+ | [Exporting Process] |
| | |
| |IPFIX |
| | |
| v |
| Collector |
| [Collecting Process] |
+----------------------+
Figure 18: Transformation from TinyIPFIX to IPFIX
図18：TinyIPFIXから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.
TinyIPFIXメディエーションプロセスでは、TinyIPFIXメッセージヘッダー、TinyIPFIXセットヘッダー、およびTinyIPFIXテンプレートレコードヘッダーを、対応するIPFIXに変換する必要があります。その後、新しいIPFIXメッセージ長を計算し、IPFIXメッセージヘッダーに挿入する必要があります。
The fields of the IPFIX Message Header that are shown in Figure 5 can be determined from a TinyIPFIX Message Header as follows:
図5に示すIPFIXメッセージヘッダーのフィールドは、TinyIPFIXメッセージヘッダーから次のように決定できます。
Version
バージョン
This is always 0x000a.
これは常に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.
IPFIXメッセージの長さは、完全なTinyIPFIXメッセージが翻訳された後でのみ計算できます。新しい長さは、16オクテットであるIPFIXメッセージヘッダーの長さと、IPFIXメッセージに含まれるすべてのセットの長さを加算することで計算できます。
Export Time
エクスポート時間
The "Export Time" MUST be generated by the Mediator, and contains the time in seconds since 00:00 UTC Jan 1, 1970, at which the IPFIX Message leaves the Mediator.
「エクスポート時刻」はメディエーターによって生成される必要があり、IPFIXメッセージがメディエーターを離れるUTC 1970年1月1日00:00以降の秒単位の時間を含みます。
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 [RFC7011].
TinyIPFIXシーケンス番号の長さが4オクテットの場合、元の値をIPFIXメッセージに使用する必要があります。 TinyIPFIXシーケンス番号のサイズが1または2オクテットの場合、TinyIPFIXメディエーターはTinyIPFIXシーケンス番号を4オクテットフィールドに拡張する必要があります。 TinyIPFIXシーケンス番号が省略された場合、メディエーターは[RFC7011]に従ってシーケンス番号を計算する必要があります。
Observation Domain ID
観測ドメイン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.
観測ドメインIDはIPFIXのテンプレートのスコープに使用されるため、中間プロセスによってアルゴリズムで決定されたマッピングを使用するか、管理者が直接構成したマッピングを使用して、TinyIPFIXエクスポートプロセスごとに一意の値に設定する必要があります。
Both fields in the TinyIPFIX Set Header have a size of 1 octet and need to be expanded:
TinyIPFIXセットヘッダーの両方のフィールドのサイズは1オクテットであり、拡張する必要があります。
Set ID
セットID
The field needs to be expanded from 1 octet to 2 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 number 127 needs to be incremented by number 128 because IPFIX Data Set IDs are numbered above 255.
フィールドは1オクテットから2オクテットに拡張する必要があります。セットIDが128未満の場合、再計算を実行する必要はありません。これは、128未満のすべてのIDが特別なメッセージ用に予約されており、IPFIXで使用されるIDと一致するためです。 128で始まるTinyIPFIXセットIDは、TinyIPFIXデータセットを識別します。したがって、IPFIXデータセットIDには255を超える番号が付けられているため、127を超えるすべてのTinyIPFIXセットIDを128ずつ増やす必要があります。
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 octets 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.
フィールドを1オクテットから2オクテットに拡張する必要があります。セットヘッダーの追加サイズと一致するように2オクテットの値を追加して再計算する必要があります。 TinyIPFIXセットに含まれるTinyIPFIXテンプレートレコードごとに、さらに2オクテットを長さに追加する必要があります。
Both fields in the TinyIPFIX Template Record Header have a length of one octet and therefore need translation:
TinyIPFIXテンプレートレコードヘッダーの両方のフィールドの長さが1オクテットであるため、変換が必要です。
Template ID
テンプレート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.
フィールドを1オクテットから2オクテットに拡張する必要があります。テンプレートIDは、128の値だけ増やす必要があります。
Field Count
フィールド数
The field needs to be expanded from one octet to 2 octets.
フィールドは1オクテットから2オクテットに拡張する必要があります。
As with IPFIX, TinyIPFIX Template 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: template loss can occur. If a Template is lost on its way to the Collector, any 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 static template directly after booting.
IPFIXと同様に、TinyIPFIXテンプレート管理は、使用されるトランスポートプロトコルに依存します。 TCPまたはSCTPを使用すると、TinyIPFIXテンプレートが確実に配信されるようになります。 UDPを使用する場合、信頼性は保証できません。テンプレートが失われる可能性があります。テンプレートがコレクターに向かう途中で失われた場合、このTinyIPFIXテンプレートを参照する後続のTinyIPFIXデータレコードはデコードできません。テンプレートの引き出しはTinyIPFIXではサポートされていません。ほとんどのセンサーノードは、ブート直後に単一の静的テンプレートのみを定義するため、これは通常問題ではありません。
If TCP or SCTP is used for the transmission of TinyIPFIX, Template Management MUST be performed as defined in [RFC7011] for IPFIX, with the exception of Template Withdrawals, which are not supported in TinyIPFIX. Template Withdrawals MUST NOT be sent by TinyIPFIX Exporters.
TinyIPFIXの送信にTCPまたはSCTPを使用する場合、TinyIPFIXでサポートされていないテンプレートの引き出しを除いて、IPFIXの[RFC7011]で定義されているとおりにテンプレート管理を実行する必要があります。テンプレートの引き出しはTinyIPFIXエクスポーターから送信してはなりません。
All specifications for Template Management from [RFC7011] apply unless specified otherwise in this document.
このドキュメントで特に指定されていない限り、[RFC7011]のテンプレート管理のすべての仕様が適用されます。
TinyIPFIX Templates MUST be sent by a 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 and, thus, they should be pre-shared. TinyIPFIX Devices have a default setup when deployed; after booting, they announce their TinyIPFIX Template directly to the network and MAY repeat it if UDP is used. Hence, a TinyIPFIX Template that has been sent once MAY NOT be withdrawn and MUST NOT expire. If a TinyIPFIX Smart Meter wants to use another TinyIPFIX Template, it MUST use a new TinyIPFIX Template ID for the TinyIPFIX Template.
TinyIPFIXテンプレートを参照するTinyIPFIXデータセットが送信される前に、TinyIPFIXテンプレートをTinyIPFIXエクスポータから送信する必要があります。 TinyIPFIXテンプレートは、TinyIPFIXで時間の経過とともに変化することは想定されていないため、事前共有する必要があります。 TinyIPFIXデバイスは、展開時にデフォルトの設定になります。起動後、彼らは直接TinyIPFIXテンプレートをネットワークに通知し、UDPが使用されている場合はそれを繰り返すことができます。したがって、一度送信されたTinyIPFIXテンプレートは、撤回することはできず、期限切れにすることはできません。 TinyIPFIXスマートメーターが別のTinyIPFIXテンプレートを使用する場合は、TinyIPFIXテンプレートに新しいTinyIPFIXテンプレートIDを使用する必要があります。
While 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. Therefore, it MUST re-send its TinyIPFIX Templates periodically. A TinyIPFIX Template MUST be re-sent after a fixed number N of TinyIPFIX Messages that contain TinyIPFIX Data Sets referring to the TinyIPFIX Template. The number N MUST be configured by the application developer. Retransmission and the specification of N can be avoided if TinyIPFIX Exporter and TinyIPFIX Collector use pre-shared templates.
UDPが使用されている間は、TinyIPFIXテンプレートの信頼できる転送は保証されず、TinyIPFIXテンプレートが失われる可能性があります。 TinyIPFIXエクスポーターは、TinyIPFIXテンプレートの損失を予期する必要があります。したがって、TinyIPFIXテンプレートを定期的に再送信する必要があります。 TinyIPFIXテンプレートは、TinyIPFIXテンプレートを参照するTinyIPFIXデータセットを含む一定数NのTinyIPFIXメッセージの後に再送信する必要があります。番号Nは、アプリケーション開発者が設定する必要があります。 TinyIPFIXエクスポーターとTinyIPFIXコレクターが事前共有テンプレートを使用する場合、再送信とNの指定を回避できます。
The same security considerations as for the IPFIX Protocol [RFC7011] apply.
IPFIXプロトコル[RFC7011]と同じセキュリティ上の考慮事項が適用されます。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://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, <https://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<https： //www.rfc-editor.org/info/rfc4944>。
[RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. Aitken, "IP Flow Information Export (IPFIX) Implementation Guidelines", RFC 5153, DOI 10.17487/RFC5153, April 2008, <https://www.rfc-editor.org/info/rfc5153>.
[RFC5153] Boschi、E.、Mark、L.、Quittek、J.、Stiemerling、M。、およびP. Aitken、「IPフロー情報エクスポート（IPFIX）実装ガイドライン」、RFC 5153、DOI 10.17487 / RFC5153、2008年4月、<https://www.rfc-editor.org/info/rfc5153>。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, DOI 10.17487/RFC5470, March 2009, <https://www.rfc-editor.org/info/rfc5470>.
[RFC5470] Sadasivan、G.、Brownlee、N.、Claise、B。、およびJ. Quittek、「Architecture for IP Flow Information Export」、RFC 5470、DOI 10.17487 / RFC5470、2009年3月、<https：// 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, <https://www.rfc-editor.org/info/rfc5982>.
[RFC5982]小林、A、エド。およびB. Claise、編、「IP Flow Information Export（IPFIX）Mediation：Problem Statement」、RFC 5982、DOI 10.17487 / RFC5982、2010年8月、<https://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, <https://www.rfc-editor.org/info/rfc6183>.
[RFC6183]小林、A。、クレイズ、B。、ムエンツ、G。、および石橋K。、「IPフロー情報エクスポート（IPFIX）メディエーション：フレームワーク」、RFC 6183、DOI 10.17487 / RFC6183、2011年4月、<https： //www.rfc-editor.org/info/rfc6183>。
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B。、編、Trammell、B。、編、およびP. Aitken、「フロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、 DOI 10.17487 / RFC7011、2013年9月、<https://www.rfc-editor.org/info/rfc7011>。
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, <https://www.rfc-editor.org/info/rfc7012>.
[RFC7012]クレイズ、B。、エド。およびB. Trammell、編、「IPフロー情報エクスポート（IPFIX）の情報モデル」、RFC 7012、DOI 10.17487 / RFC7012、2013年9月、<https://www.rfc-editor.org/info/rfc7012>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[Advantic] ADVANTIC SISTEMAS Y SERVICIOS S.L., <https://www.advanticsys.com/>, 2017.
[アドバンティック] ADVANTIC SISTEMAS Y SERVICIOS S.L.、<https://www.advanticsys.com/>、2017年。
[GreatDuck] Mainwaring, A., Polastre, J., Szewczyk, R., Culler, D., and J. Anderson, "Wireless Sensor Networks for Habitat Monitoring", In Proceedings of the 1st ACM international workshop on Wireless sensor networks and applications ACM, pp. 88-97, DOI 10.1145/570738.570751, 2002.
[GreatDuck] Mainwaring、A.、Polastre、J.、Szewczyk、R.、Culler、D。、およびJ. Anderson、「生息地監視のためのワイヤレスセンサーネットワーク」、ワイヤレスセンサーネットワークに関する第1回ACM国際ワークショップのプロシーディングスおよびアプリケーションACM、pp.88-97、DOI 10.1145 / 570738.570751、2002。
[Harvan08] Harvan, M. and J. Schoenwaelder, "TinyOS Motes on the Internet: IPv6 over 802.15.4 (6LoWPAN)", DOI 10.1515/piko.2008.0042, December 2008.
[Harvan08] Harvan、M.およびJ. Schoenwaelder、「インターネット上のTinyOSモート：IPv6 over 802.15.4（6LoWPAN）」、DOI 10.1515 / piko.2008.0042、2008年12月。
[IRIS] Memsic, "Data Sheet IRIS", 2017, <http://www.memsic.com/userfiles/files/Datasheets/WSN/ IRIS_Datasheet.pdf>.
[IRIS] Memsic、「Data Sheet IRIS」、2017、<http://www.memsic.com/userfiles/files/Datasheets/WSN/ IRIS_Datasheet.pdf>。
[Kim07] Kim, S., Pakzad, S., Culler, D., Demmel, J., Fenves, G., Glaser, S., and M. Turon, "Health monitoring of civil infrastructures using wireless sensor networks", Proceedings of the 6th international conference on Information processing in sensor networks (IPSN 2007), Cambridge, MA, ACM Press, pp. 254-263, DOI 10.1145/1236360.1236395, April 2007.
[Kim07] Kim、S.、Pakzad、S.、Culler、D.、Demmel、J.、Fenves、G.、Glaser、S。、およびM. Turon、「ワイヤレスセンサーネットワークを使用した市民インフラストラクチャのヘルスモニタリング」、第6回センサーネットワークにおける情報処理に関する国際会議（IPSN 2007）、マサチューセッツ州ケンブリッジ、ACM Press、pp。254-263、DOI 10.1145 / 1236360.1236395、2007年4月の議事録。
[Kothmayr10] Kothmayr, T., "Data Collection in Wireless Sensor Networks for Autonomic Home Networking", Bachelor Thesis, Technical University of Munich, Munich, Germany, January 2010.
[Kothmayr10] Kothmayr、T.、「自律ホームネットワーク用のワイヤレスセンサーネットワークでのデータ収集」、学士論文、ミュンヘン工科大学、ミュンヘン、ドイツ、2010年1月。
[openMote] openMote Technologies S.L., 2017, <http://openmote.com>.
[openMote] openMote Technologies S.L.、2017、<http://openmote.com>。
[Schmitt09] Schmitt, C. 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 Antonopoulos N., Exarchakos G., Li M., and A. Liotta, Information Science Publishing, Chapter 46, pp. 1076-1091, ISBN: 978-1615206865, 2010.
[Schmitt09] Schmitt、C.およびG. Carle、「Applications for Wireless Sensor Networks」、Handbook of Research on P2P and Grid Systems for Service-Oriented Computing：Models、Methodsology and Applications、Edited by Antonopoulos N.、Exarchakos G.、 Li M.、A。Liotta、情報科学出版、第46章、1076〜1091ページ、ISBN：978-1615206865、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, Vol. 74, pp. 63-76, DOI 10.1016/j.comcom.2014.05.012, 2016.
[Schmitt2014] Schmitt、C.、Kothmayr、T.、Ertl、B.、Hu、W.、Braun、L。、およびG. Carle、「TinyIPFIX：サイバー物理システムでのデータ交換のための効率的なアプリケーションプロトコル」、コンピューターコミュニケーション、ELSEVIER、Vol。 74、63-76ページ、DOI 10.1016 / j.comcom.2014.05.012、2016。
[Schmitt2017] Schmitt, C., Anliker, C., and B. Stiller, "Efficient and Secure Pull Requests for Emergency Cases Using a Mobile Access Framework", Managing the Web of Things: Linking the Real World to the Web, Edited by Sheng, M., Qin, Y., Yao, L., and B. Benatallah, Morgen Kaufmann (imprint of Elsevier), Chapter 8, pp. 229-247, ISBN: 978-0-12-809764-9, 2017.
[Schmitt2017] Schmitt、C.、Anliker、C。、およびB. Stiller、「モバイルアクセスフレームワークを使用した緊急の場合の効率的で安全なプルリクエスト」、Webの管理：実世界とWebのリンク、編集Sheng、M.、Qin、Y.、Yao、L.、and B. Benatallah、Morgen Kaufmann（imprint of Elsevier）、Chapter 8、pp.229-247、ISBN：978-0-12-809764-9、2017 。
[SMPC04] Szewczyk, R., Mainwaring, A., Polastre, J., and D. Culler, "An analysis of a large scale habitat monitoring application", Proceedings of the 2nd international conference on Embedded networked sensor systems (SenSys 04), DOI 10.1145/1031495.1031521, November 2004.
[SMPC04] Szewczyk、R.、Mainwaring、A.、Polastre、J。、およびD. Culler、「大規模生息地監視アプリケーションの分析」、組み込みネットワークセンサーシステムに関する第2回国際会議の議事録（SenSys 04） 、DOI 10.1145 / 1031495.1031521、2004年11月。
[TelosB] Memsic, "Data Sheet TelosB", 2017, <http://www.memsic.com/userfiles/files/DataSheets/WSN/ telosb_datasheet.pdf>.
[TelosB] Memsic、「Data Sheet TelosB」、2017、<http://www.memsic.com/userfiles/files/DataSheets/WSN/ telosb_datasheet.pdf>。
[Tolle05] Tolle, G., Polastre, J., Szewczyk, R., Culler, D., Turner, N., Tu, K., Burgess, S., Dawnson, T., Buonadonna, P., Gay, D., and W. Hong, "A macroscope in the redwoods", Proceedings of the 3rd international conference on Embedded networked sensor systems (SenSys 05), DOI 10.1145/1098918.1098925, November 2005.
[Tolle05] Tolle、G.、Polastre、J.、Szewczyk、R.、Culler、D.、Turner、N.、Tu、K.、Burgess、S.、Dawnson、T.、Buonadonna、P.、Gay、 D.、およびW.ホン、「レッドウッドのマクロスコープ」、第3回国際会議の組み込みネットワークセンサーシステムに関する会議議事録（SenSys 05）、DOI 10.1145 / 1098918.1098925、2005年11月。
Acknowledgments
謝辞
Many thanks to Lothar Braun, Georg Carle, and Benoit Claise, who contributed significant work to earlier draft versions of this work, especially to the document titled "Compressed IPFIX for Smart Meters in Constrained Networks".
Lothar Braun、Georg Carle、Benoit Claiseに感謝します。この作品の初期のドラフトバージョンに多大な貢献をしてくれました。特に、「制約付きネットワークのスマートメーター用の圧縮IPFIX」というタイトルのドキュメントに感謝します。
Many thanks to Thomas Kothmayr, Michael Meister, and Livio Sgier, who implemented TinyIPFIX (except the mediator) for TinyOS 2.x and Contiki 2.7/3.0 for 3 different sensor platforms (IRIS, TelosB, and OpenMote).
3つの異なるセンサープラットフォーム（IRIS、TelosB、OpenMote）にTinyOS 2.xとContiki 2.7 / 3.0にTinyIPFIX（メディエーターを除く）を実装したThomas Kothmayr、Michael Meister、Livio Sgierに感謝します。
Authors' Addresses
著者のアドレス
Corinna Schmitt University of Zurich Department of Informatics Communication Systems Group Binzmuehlestrasse 14 Zurich 8050 Switzerland
コリーナシュミットチューリッヒ大学情報学科コミュニケーションシステムグループBinzmuehlestrasse 14チューリッヒ8050スイス
Email: schmitt@ifi.uzh.ch
Burkhard Stiller University of Zurich Department of Informatics Communication Systems Group Binzmuehlestrasse 14 Zurich 8050 Switzerland
Burkhard Stillerチューリッヒ大学情報学部通信システムグループBinzmuehlestrasse 14チューリッヒ8050スイス
Email: stiller@ifi.uzh.ch
Brian Trammell Swiss Federal Institute of Technology Gloriastrasse 35 Zurich 8092 Switzerland
ブライアントラメルスイス連邦工科大学Gloriastrasse 35チューリッヒ8092スイス
Email: ietf@trammell.ch