Internet Engineering Task Force (IETF) B. Claise
Request for Comments: 6313 G. Dhandapani
Updates: 5102 P. Aitken
Category: Standards Track S. Yates
ISSN: 2070-1721 Cisco Systems, Inc.
July 2011
Export of Structured Data in IP Flow Information Export (IPFIX)
Abstract
抽象
This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record.
この文書は、RFC 5101でIPフロー情報のエクスポート（IPFIX）プロトコル仕様とデータレコード内の情報要素の階層構造化データやリスト（配列）をサポートするために、RFC 5102で指定されたIPFIX情報モデルへの拡張を指定します。この拡張は、可変長リストとテンプレートとの間の階層的な包含関係の仕様として複雑なデータ構造の定義を可能にします。最後に、意味論は、構造化データレコード内の複数のリスト要素間の関係を表現するために設けられています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6313.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6313で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。のセクション4.eで説明したように、コードのコンポーネントは、簡素化されたBSDライセンスのテキストを含める必要があり、この文書から抽出されました
the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
トラスト法規定および簡体BSDライセンスで説明したように、保証なしで提供されています。
Table of Contents
目次
1. Overview ........................................................5
1.1. IPFIX Documents Overview ...................................5
1.2. Relationship between IPFIX and PSAMP .......................6
2. Introduction ....................................................6
2.1. The IPFIX Track ............................................7
2.2. The IPFIX Limitations ......................................8
2.3. Structured Data Use Cases ..................................8
2.4. Specifications Summary ....................................11
3. Terminology ....................................................11
3.1. New Terminology ...........................................12
3.2. Conventions Used in This Document .........................12
4. Linkage with the IPFIX Information Model .......................12
4.1. New Abstract Data Types ...................................12
4.1.1. basicList ..........................................12
4.1.2. subTemplateList ....................................12
4.1.3. subTemplateMultiList ...............................12
4.2. New Data Type Semantic ....................................13
4.2.1. List ...............................................13
4.3. New Information Elements ..................................13
4.3.1. basicList ..........................................13
4.3.2. subTemplateList ....................................13
4.3.3. subTemplateMultiList ...............................13
4.4. New Structured Data Type Semantics ........................13
4.4.1. undefined ..........................................14
4.4.2. noneOf .............................................14
4.4.3. exactlyOneOf .......................................14
4.4.4. oneOrMoreOf ........................................15
4.4.5. allOf ..............................................16
4.4.6. ordered ............................................16
4.5. Encoding of IPFIX Data Types ..............................16
4.5.1. basicList ..........................................17
4.5.2. subTemplateList ....................................19
4.5.3. subTemplateMultiList ...............................21
5. Structured Data Format .........................................25
5.1. Length Encoding Considerations ............................25
5.2. Recursive Structured Data .................................26
5.3. Structured Data Information Elements Applicability
in Options Template Sets ..................................26
5.4. Usage Guidelines for Equivalent Data Representations ......27
5.5. Padding ...................................................29
5.6. Semantic ..................................................29
6. Template Management ............................................33
7. The Collecting Process's Side ..................................33
8. Defining New Information Elements Based on the New
Abstract Data Types ............................................34
9. Structured Data Encoding Examples ..............................34
9.1. Encoding a Multicast Data Record with basicList ...........35
9.2. Encoding a Load-Balanced Data Record with a basicList .....37
9.3. Encoding subTemplateList ..................................38
9.4. Encoding subTemplateMultiList .............................41
9.5. Encoding an Options Template Set Using Structured Data ....46
10. Relationship with the Other IPFIX Documents ...................51
10.1. Relationship with Reducing Redundancy ....................51
10.1.1. Encoding Structured Data Element Using
Common Properties .................................51
10.1.2. Encoding Common Properties Elements with
Structured Data Information Element ...............51
10.2. Relationship with Guidelines for IPFIX Testing ...........53
10.3. Relationship with IPFIX Mediation Function ...............54
11. IANA Considerations ...........................................54
11.1. New Abstract Data Types ..................................54
11.1.1. basicList .........................................54
11.1.2. subTemplateList ...................................54
11.1.3. subTemplateMultiList ..............................55
11.2. New Data Type Semantics ..................................55
11.2.1. list ..............................................55
11.3. New Information Elements .................................55
11.3.1. basicList .........................................55
11.3.2. subTemplateList ...................................56
11.3.3. subTemplateMultiList ..............................56
11.4. New Structured Data Semantics ............................56
11.4.1. undefined .........................................56
11.4.2. noneOf ............................................57
11.4.3. exactlyOneOf ......................................57
11.4.4. oneOrMoreOf .......................................57
11.4.5. allOf .............................................57
11.4.6. ordered ...........................................58
12. Security Considerations .......................................58
13. References ....................................................58
13.1. Normative References .....................................58
13.2. Informative References ...................................58
14. Acknowledgements ..............................................59
Appendix A. Additions to XML Specification of IPFIX
Information Elements and Abstract Data Types ..........60
Appendix B. Encoding IPS Alert Using Structured Data
Information Elements ..................................65
Table of Figures
図の表
Figure 1: basicList Encoding ......................................17
Figure 2: basicList Encoding with Enterprise Number ...............18
Figure 3: Variable-Length basicList Encoding (Length < 255 Octets) 18
Figure 4: Variable-Length basicList Encoding (Length 0 to 65535
Octets) .................................................19
Figure 5: subTemplateList Encoding ................................19
Figure 6: Variable-Length subTemplateList Encoding
(Length < 255 Octets) ...................................20
Figure 7: Variable-Length subTemplateList Encoding
(Length 0 to 65535 Octets) ..............................21
Figure 8: subTemplateMultiList Encoding ...........................21
Figure 9: Variable-Length subTemplateMultiList Encoding
(Length < 255 Octets) ...................................23
Figure 10: Variable-Length subTemplateMultiList Encoding
(Length 0 to 65535 Octets) ..............................24
Figure 11: Encoding basicList, Template Record .....................35
Figure 12: Encoding basicList, Data Record, Semantic allOf .........36
Figure 13: Encoding basicList, Data Record with Variable-Length
Elements, Semantic allOf ................................37
Figure 14: Encoding basicList, Data Record, Semantic exactlyOneOf ..38
Figure 15: Encoding subTemplateList, Template for One-Way Delay
Metrics .................................................39
Figure 16: Encoding subTemplateList, Template Record ...............40
Figure 17: Encoding subTemplateList, Data Set ......................40
Figure 18: Encoding subTemplateMultiList, Template for Filtering
Attributes ..............................................44
Figure 19: Encoding subTemplateMultiList, Template for Sampling
Attributes ..............................................44
Figure 20: Encoding subTemplateMultiList, Template for Flow Record .45
Figure 21: Encoding subTemplateMultiList, Data Set .................45
Figure 22: PSAMP SSRI to Be encoded ................................48
Figure 23: Options Template Record for PSAMP SSRI Using
subTemplateMultiList ....................................48
Figure 24: PSAMP SSRI, Template Record for interface ...............49
Figure 25: PSAMP SSRI, Template Record for linecard ................49
Figure 26: PSAMP SSRI, Template Record for linecard and interface ..49
Figure 27: Example of a PSAMP SSRI Data Record, Encoded Using a
subTemplateMultiList ...................................50
Figure 28: Common and Specific Properties Exported Together
[RFC5473] ..............................................51
Figure 29: Common and Specific Properties Exported Separately
According to [RFC5473] .................................52
Figure 30: Common and Specific Properties Exported with Structured
Data Information Element ...............................52
Figure 31: Encoding IPS Alert, Template for Target ................67
Figure 32: Encoding IPS Alert, Template for Attacker ..............68
Figure 33: Encoding IPS Alert, Template for Participant ...........68
Figure 34: Encoding IPS Alert, Template for IPS Alert .............69
Figure 35: Encoding IPS Alert, Data Set ...........................69
The IPFIX protocol [RFC5101] provides network administrators with access to IP Flow information.
IPFIXプロトコル[RFC5101]はIPフロー情報へのアクセスをネットワーク管理者に提供します。
The architecture for the export of measured IP Flow information out of an IPFIX Exporting Process to a Collecting Process is defined in the IPFIX architecture [RFC5470], per the requirements defined in RFC 3917 [RFC3917].
収集プロセスにIPFIXエクスポートプロセスのうち、測定IPフロー情報のエクスポートのためのアーキテクチャは、RFC 3917で定義された要件に従ってIPFIXアーキテクチャ[RFC5470]、[RFC3917]で定義されています。
The IPFIX architecture [RFC5470] specifies how IPFIX Data Records and Templates are carried via a congestion-aware transport protocol from IPFIX Exporting Processes to IPFIX Collecting Processes.
IPFIXアーキテクチャ[RFC5470]はどのようにIPFIXデータレコードとテンプレートがIPFIX収集プロセスにIPFIXのエクスポートプロセスから混雑対応のトランスポートプロトコルを介して運ばれる指定します。
IPFIX has a formal description of IPFIX Information Elements, their name, type, and additional semantic information, as specified in the IPFIX information model [RFC5102].
IPFIXはIPFIX情報モデル[RFC5102]で指定されるように、正式なIPFIX情報要素の説明、自分の名前、タイプ、および追加の意味情報を持っています。
In order to gain a level of confidence in the IPFIX implementation, probe the conformity and robustness, and allow interoperability, the guidelines for IPFIX testing [RFC5471] present a list of tests for implementers of compliant Exporting Processes and Collecting Processes.
IPFIX実装の信頼のレベルを得るために、IPFIX試験[RFC5471]のガイドラインに準拠エクスポートプロセスと収集プロセスの実装のための試験のリストを提示し、適合性および堅牢性をプローブとの相互運用性を可能にします。
The Bidirectional Flow Export [RFC5103] specifies a method for exporting bidirectional flow (biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each biflow using a single Flow Record.
双方向フローエクスポート[RFC5103]は、単一のフローレコードを使用して各バイフローを表すIPフロー情報エクスポート（IPFIX）プロトコルを使用して双方向の流れ（バイフロー）情報をエクスポートする方法を指定します。
"Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] specifies a bandwidth-saving method for exporting Flow or packet information, by separating information common to several Flow Records from information specific to an individual Flow Record: common Flow information is exported only once.
[RFC5473]「IPフロー情報のエクスポート（IPFIX）とパケットサンプリング（PSAMP）レポートでの冗長性を減らすことは、」個々のフローに固有の情報から、いくつかのフローレコードに共通の情報を分離することによって、フローまたはパケット情報をエクスポートするための帯域幅を節約する方法を指定しますレコード：一般的なフロー情報を一度だけエクスポートされます。
The specification in this document applies to the IPFIX protocol specifications [RFC5101]. All specifications from [RFC5101] apply unless specified otherwise in this document.
この文書に記載されている仕様は、IPFIXプロトコル仕様[RFC5101]に適用されます。この文書で特に指定しない限り、[RFC5101]からのすべての仕様が適用されます。
The Packet Sampling (PSAMP) protocol [RFC5476] specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collecting Process. Like IPFIX, PSAMP has a formal description of its information elements, their name, type, and additional semantic information. The PSAMP information model is defined in [RFC5477].
パケットサンプリング（PSAMP）プロトコル[RFC5476]は収集処理PSAMPにPSAMPエクスポートプロセスからパケット情報のエクスポートを指定します。 IPFIXのように、PSAMPは、その情報要素、自分の名前、タイプ、および追加の意味情報の形式的な記述があります。 PSAMP情報モデルは、[RFC5477]で定義されています。
As the PSAMP protocol specifications [RFC5476] are based on the IPFIX protocol specifications, the specifications in this document are also valid for the PSAMP protocol.
PSAMPプロトコル仕様[RFC5476]はIPFIXプロトコル仕様に基づいているとして、この文書に記載されている仕様はPSAMPプロトコルのためにも有効です。
Indeed, the major difference between IPFIX and PSAMP is that the IPFIX protocol exports Flow Records while the PSAMP protocol exports Packet Reports. From a pure export point of view, IPFIX will not distinguish a Flow Record composed of several packets aggregated together from a Flow Record composed of a single packet. So the PSAMP export can be seen as a special IPFIX Flow Record containing information about a single packet.
確かに、IPFIXとPSAMPの主な違いは、IPFIXプロトコルはPSAMPプロトコル輸出パケットレポートしながら、フローレコードをエクスポートすることです。ビューの純粋な輸出の観点から、IPFIXは、単一のパケットで構成されるフローレコードから一緒に集約複数のパケットから構成されるフローレコードを区別しません。だから、PSAMPの輸出は、単一のパケットについての情報を含む特別なIPFIXフローレコードとして見ることができます。
While collecting the interface counters every five minutes has proven to be useful in the past, more and more granular information is required from network elements for a series of applications: performance assurance, capacity planning, security, billing, or simply monitoring. However, the amount of information has become so large that, when dealing with highly granular information such as Flow information, a push mechanism (as opposed to a pull mechanism, such as Simple Network Management Protocol (SNMP)) is the only solution for routers whose primary function is to route packets. Indeed, polling short-lived Flows via SNMP is not an option: high-end routers can support hundreds of thousands of Flows simultaneously. Furthermore, in order to reduce the export bandwidth requirements, the network elements have to integrate mediation functions to aggregate the collected information, both in space (typically, from different linecards or different Exporters) and in time.
パフォーマンス保証、キャパシティプランニング、セキュリティ、課金、または単に監視：インターフェイスカウンタを収集しながら、5分ごとに過去に有用であることが証明されている、より多くの粒状の情報は、一連のアプリケーションのためのネットワーク要素から必要とされます。しかし、情報の量は、このようなフロー情報として、きめ細かな情報を扱う際に、プッシュ機構は、（そのような簡易ネットワーク管理プロトコル（SNMP）として、プル機構ではなく）ルータのための唯一の解決策である、ことを非常に大きくなってきましたその主な機能は、パケットをルーティングするためにあります。確かに、SNMP経由でポーリング短命フローは、オプションではありません：ハイエンドルータは、同時に数百フローの何千ものをサポートすることができます。さらに、輸出の帯域幅要件を削減するために、ネットワーク要素は、空間内で（一般的に、異なるラインカードまたは別の輸出から）と時間の両方で、収集した情報を集約するために調停機能を統合する必要があります。
Typically, it would be beneficial if access routers could export Flow Records, composed of the counters before and after an optimization mechanism on the egress interface, instead of exporting two Flow Records with identical tuple information.
アクセスルータではなく、同じタプル情報を持つ2つのフローレコードをエクスポートするの、出力インターフェイスに最適化メカニズムの前と後のカウンターで構成フローレコードをエクスポートすることができれば一般的に、それは有益であろう。
In terms of aggregation in time, let us imagine that, for performance assurance, the network management application must receive the performance metrics associated with a specific Flow, every millisecond. Since the performance metrics will be constantly changing, there is a new dimension to the Flow definition: we are not dealing anymore with a single Flow lasting a few seconds or a few minutes, but with a multitude of one millisecond sub-flows for which the performance metrics are reported.
時間の集計の面では、私たちは、性能保証のために、ネットワーク管理アプリケーションが特定のフロー、ミリ秒ごとに関連したパフォーマンスメトリックを受けなければならない、と想像してみましょう。パフォーマンスメトリックは常に変化しますので、フロー定義に新しい次元があります：私たちは、数秒または数分持続する単一のフローではもう扱ってますが、1ミリ秒サブフローの多数とされていないためパフォーマンスメトリックが報告されています。
Which current protocol is suitable for these requirements: push mechanism, highly granular information, and huge number of similar records? IPFIX, as specified in RFC 5101 would give part of the solution.
これらの要件に適したどの現在のプロトコルである：プッシュ機構、きめ細かい情報、および同様のレコードの膨大な数？ IPFIXは、RFC 5101で指定されたソリューションの一部を与えるだろう。
The IPFIX working group has specified a protocol to export Flow information [RFC5101]. This protocol is designed to export information about IP traffic Flows and related measurement data, where a Flow is defined by a set of key attributes (e.g., source and destination IP address, source and destination port).
IPFIXワーキンググループは、フロー情報[RFC5101]をエクスポートするプロトコルを指定しています。このプロトコルは、フローはキー属性（例えば、送信元および宛先IPアドレス、送信元および宛先ポート）のセットによって定義されたIPトラフィックフローと関連する測定データに関する情報をエクスポートするように設計されています。
The IPFIX protocol specification [RFC5101] specifies that traffic measurements for Flows are exported using a TLV (type, length, value) format. The information is exported using a Template Record that is sent once to export the {type, length} pairs that define the data format for the Information Elements in a Flow. The Data Records specify values for each Flow.
IPFIXプロトコル仕様[RFC5101]はフローのトラフィック測定は、TLV（タイプ、長さ、値）フォーマットを使用してエクスポートされることを指定します。情報は、フロー内の情報要素のデータフォーマットを定義する{タイプ、長さ}ペアをエクスポートするために一度送信されるテンプレートレコードを使用してエクスポートされています。データレコードは、各フローの値を指定します。
Based on the requirements for IP Flow Information Export (IPFIX) [RFC3917], the IPFIX protocol has been optimized to export Flow-related information. However, thanks to its Template mechanism, the IPFIX protocol can export any type of information, as long as the relevant Information Element is specified in the IPFIX information model [RFC5102], registered with IANA [IANA-IPFIX], or specified as an enterprise-specific Information Element. For each Information Element, the IPFIX information model [RFC5102] defines a numeric identifier, an abstract data type, an encoding mechanism for the data type, and any semantic constraints. Only basic, single-valued data types, e.g., numbers, strings, and network addresses, are currently supported.
IPフロー情報のエクスポート（IPFIX）[RFC3917]のための要件に基づいて、IPFIXプロトコルは、フローに関連する情報をエクスポートするために最適化されています。しかし、そのテンプレート機構のおかげで、IPFIXプロトコルであれば、関連情報要素は、IPFIX情報モデル[RFC5102]で指定されたIANA [IANA-IPFIX]に登録され、又は企業として指定されているように、任意のタイプの情報をエクスポートすることができ固有の情報要素。各情報要素について、IPFIX情報モデル[RFC5102]は、数値識別子、抽象データ型、データ型の符号化機構、及び任意の意味制約を定義します。唯一の基本的な、単一値のデータ型は、例えば、数値、文字列、およびネットワークアドレスは、現在サポートされています。
The IPFIX protocol specification [RFC5101] does not support the encoding of hierarchical structured data and arbitrary-length lists (sequences) of Information Elements as fields within a Template Record. As it is currently specified, a Data Record is a "flat" list of single-valued attributes. However, it is a common data modeling requirement to compose complex hierarchies of data types, with multiple occurrences, e.g., 0..* cardinality allowed for instances of each Information Element in the hierarchy.
IPFIXプロトコル仕様[RFC5101]はテンプレートレコード内のフィールドのように階層構造化されたデータ及び情報要素の任意の長さのリスト（配列）の符号化をサポートしていません。それが現在指定されている通り、データレコードは、単一値の属性の「フラット」のリストです。しかし、例えば、複数回出現して、データ型の複雑な階層を構成するための一般的なデータモデリングの要件である0 .. *階層内の各情報要素のインスタンスに許可さカーディナリティ。
A typical example is the MPLS label stack entries model. An early NetFlow implementation used two Information Elements to represent the MPLS label stack entry: a "label stack entry position" followed by a "label stack value". However, several drawbacks were discovered. Firstly, the Information Elements in the Template Record had to be imposed so that the position would always precede the value. However, some encoding optimizations are based on the permutation of Information Element order. Secondly, a new semantic intelligence, not described in the information model, had to be hard-coded in the Collecting Process: the label value at the position "X" in the stack is contained in the "label stack value" Information Element following by a "label stack entry position" Information Element containing the value "X". Therefore, this model was abandoned.
典型的な例は、MPLSラベルスタックエントリーモデルです。 「ラベルスタック値」に続いて「ラベルスタックエントリー位置」：早期のNetFlowの実装では、MPLSラベルスタックエントリーを表現するために2つの情報要素を使用していました。しかし、いくつかの欠点が発見されました。まず、テンプレートレコード内の情報要素は、位置は常に値の前になるように課さなければなりませんでした。しかし、いくつかのエンコーディングの最適化は、情報要素の順序の順列に基づいています。第二に、情報モデルに記述されていない新しいセマンティックインテリジェンスは、収集処理中にハードコーディングされなければならなかった：スタック内の位置「X」のラベル値は、「ラベルスタック値」に含まれる情報要素をして、次の値「X」を含む「ラベルスタックエントリー位置」情報要素。したがって、このモデルは放棄されました。
The selected solution in the IPFIX information model [RFC5102] is a long series of Information Elements: mplsTopLabelStackSection, mplsLabelStackSection2, mplsLabelStackSection3, mplsLabelStackSection4, mplsLabelStackSection5, mplsLabelStackSection6, mplsLabelStackSection7, mplsLabelStackSection8, mplsLabelStackSection9, mplsLabelStackSection10. While this model removes any ambiguity, it overloads the IPFIX information model with repetitive information. Furthermore, if mplsLabelStackSection11 is required, IANA [IANA-IPFIX] will not be able to assign the new Information Element next to the other ones in the registry, which might cause some confusion.
mplsTopLabelStackSection、mplsLabelStackSection2、mplsLabelStackSection3、mplsLabelStackSection4、mplsLabelStackSection5、mplsLabelStackSection6、mplsLabelStackSection7、mplsLabelStackSection8、mplsLabelStackSection9、mplsLabelStackSection10：IPFIX情報モデル[RFC5102]で選択された解決策は、情報要素の長いシリーズです。このモデルは、任意の曖昧さを取り除くが、それは繰り返しの情報をIPFIX情報モデルをオーバーロード。 mplsLabelStackSection11が必要な場合はさらに、IANA [IANA-IPFIX】いくつかの混乱を引き起こす可能性がある、レジストリ内の他のものの隣に新しい情報要素を割り当てることはできません。
Clearly, the MPLS label stack entries issue can best be solved by using a real structured data type composed of ("label stack entry position", "label stack value") pairs, potentially repeated multiple times in Flow Records, since this would be the most efficient from an information model point of view.
明らかに、MPLSラベルスタックエントリーの問題が最もよく、これは可能であろうから、（「ラベルスタックエントリー位置」、「ラベルスタック値」）のペア、フローレコードで潜在的に繰り返し複数回で構成される実際の構造化データ型を使用することによって解決することができますビューの情報モデルの観点から最も効率的。
Some more examples enter the same category: how to encode the list of output interfaces in a multicast Flow, how to encode the list of BGP Autonomous Systems (AS) in a BGP Flow, how to encode the BGP communities in a BGP Flow, etc.
など、BGPフローでBGPコミュニティをエンコードする方法、BGPフローにBGP自律システム（AS）のリストをエンコードする方法、マルチキャストフローに出力インターフェイスのリストをエンコードする方法：いくつかのより多くの例は、同じカテゴリに入ります。
The one-way delay passive measurement, which is described in the IPFIX applicability [RFC5472], is yet another example that would benefit from a structured data encoding. Assuming synchronized clocks, the Collector can deduce the one-way delay between two Observation Points from the following two Information Elements, collected from two different Observation Points:
IPFIXの適用[RFC5472]に記載されて一方向遅延パッシブ測定は、構造化データの符号化から利益を得るさらに別の例です。同期したクロックを想定すると、コレクタは、二つの異なる観測点から収集し、次の二つの情報要素からの2つの観測点間の片道遅延を、推測することができます。
- Packet arrival time: observationTimeMicroseconds [RFC5477]
- Packet ID: digestHashValue [RFC5477]
In practice, this implies that many pairs of (observationTimeMicroseconds, digestHashValue) must be exported for each Observation Point, even if Hash-Based Filtering [RFC5475] is used. On top of that information, if the requirement is to understand the one-way delay per application type, the 5-tuple (source IP address, destination IP address, protocol, source port, destination port) would need to be added to every Flow Record. Instead of exporting this repetitive 5-tuple, as part of every single Flow Record a Flow Record composed of a structured data type such as the following would save a lot of bandwidth:
実際には、これは（observationTimeMicroseconds、digestHashValue）の多くのペアがハッシュベースのフィルタリング[RFC5475]を使用しても、各観測点のためにエクスポートされなければならないことを意味します。要件は、アプリケーションタイプごとの一方向遅延を理解することである場合、その情報の上、5タプル（送信元IPアドレス、宛先IPアドレス、プロトコル、送信元ポート、宛先ポート）毎にフローに追加する必要があります記録。代わりに、このような多くの帯域幅を節約するだろう、次のように構造化データ・タイプで構成されるすべての単一のフローレコードフローレコードの一部として、この繰り返しの5タプルをエクスポートします：
5-tuple { observationTimeMicroseconds 1, digestHashValue 1 } { observationTimeMicroseconds 2, digestHashValue 2 } { observationTimeMicroseconds 3, digestHashValue 3 } { ... , ... }
5タプル{observationTimeMicroseconds 1、digestHashValue 1} {observationTimeMicroseconds 2、digestHashValue 2} {observationTimeMicroseconds 3、digestHashValue 3} {...、...}
As a last example, here is a more complex case of hierarchical structured data encoding. Consider the example scenario of an IPS (Intrusion Prevention System) alert data structure containing multiple participants, where each participant contains multiple attackers and multiple targets, with each target potentially composed of multiple applications, as depicted below:
最後の例として、ここでは、階層構造化されたデータ符号化のより複雑なケースです。以下に示すように、各参加者は、潜在的に複数のアプリケーションからなる各ターゲットと、複数の攻撃者と複数のターゲットが含まれている複数の参加者を含むIPS（侵入防止システム）警告データ構造の一例のシナリオを検討してください。
alert signatureId protocolIdentifier riskRating participant 1 attacker 1 sourceIPv4Address applicationId ... attacker N sourceIPv4Address applicationId target 1 destinationIPv4Address applicationId 1 ... applicationId n ... target N destinationIPv4Address applicationId 1 ... applicationId n participant 2 ...
警告signatureIdプロトコル識別子riskRating参加者1アタッカー1 sourceIPv4Address APPLICATIONID ...アタッカーN sourceIPv4Address APPLICATIONID目標1 destinationIPv4Address APPLICATIONID 1 ... APPLICATIONID N ...ターゲットN destinationIPv4Address APPLICATIONID 1 ... APPLICATIONID nは参加者2 ...
To export this information in IPFIX, the data would need to be flattened (thus, losing the hierarchical relationships) and a new IPFIX Template created for each alert, according to the number of applicationId elements in each target, the number of targets and attackers in each participant, and the number of participants in each alert. Clearly, each Template will be unique to each alert, and a large amount of CPU, memory, and export bandwidth will be wasted creating, exporting, maintaining, and withdrawing the Templates. See Appendix B for a specific example related to this case study.
IPFIXでこの情報をエクスポートするには、データは、各ターゲットでAPPLICATIONID要素の数、ターゲットと攻撃者の数のに応じて、各アラート用に作成された新しいIPFIXテンプレート（階層関係を失って、これ）平坦化される必要があるであろう各参加者、および各アラートの参加者数。明らかに、各テンプレートには、各アラート、およびCPU、メモリを大量に一意になり、そして輸出の帯域幅は維持、およびテンプレートを引き出す、作成、エクスポート無駄になります。このケーススタディに関連する具体的な例については、付録Bを参照してください。
This document specifies an IPFIX extension to support hierarchical structured data and variable-length lists by defining three new Information Elements and three corresponding new abstract data types called basicList, subTemplateList, and subTemplateMultiList. These are defined in Sections 4.1 and 4.3.
この文書では、3つの新しい情報要素とbasicList、subTemplateList、およびsubTemplateMultiListと呼ばれる3つの対応する新しい抽象データ型を定義することによって、階層構造化データと可変長のリストをサポートするために、IPFIXの拡張子を指定します。これらは、セクション4.1と4.3で定義されています。
The three Structured Data Information Elements carry some semantic information so that the Collecting Process can understand the relationship between the different list elements. The semantic in the Structured Data Information Elements is provided in order to express the relationship among the multiple top-level list elements. As an example, if a list is composed of the elements (A,B,C), the semantic expresses the relationship among A, B, and C, regardless of whether A, B, and C are individual elements or a list of elements.
収集プロセスが異なるリスト要素間の関係を理解することができるように3つの構造化データの情報要素はいくつかの意味情報を運びます。構造化データ情報要素内のセマンティックは、複数のトップレベルのリスト要素間の関係を表現するために設けられています。リストの要素（A、B、C）から構成されている場合、一例として、セマンティックは、B、およびCの関係を表す関係なく、かどうかA、B、およびCの個々の要素または要素のリストであります。
It is important to note that whereas the Information Elements and abstract data types defined in the IPFIX information model [RFC5102] represent single values, these new abstract data types are structural in nature and primarily contain references to other Information Elements and to Templates. By referencing other Information Elements and Templates from an Information Element's data content, it is possible to define complex data structures such as variable-length lists and to specify hierarchical containment relationships between Templates. Therefore, this document prefers the more generic "Data Record" term to the "Flow Record" term.
情報要素とIPFIX情報モデル[RFC5102]で定義された抽象データ型は、単一の値を表すのに対し、これらの新しい抽象データ型は、自然の中での構造であり、主に他の情報要素にし、テンプレートへの参照が含まれていることに注意することが重要です。情報要素のデータ内容から、他の情報要素およびテンプレートを参照することにより、このような可変長リストなどの複雑なデータ構造を定義するとテンプレート間の階層の包含関係を特定することが可能です。したがって、この文書は、「フローレコード」という用語には、より一般的な「データレコード」という用語を好みます。
This document specifies three new abstract data types, which are basic blocks to represent structured data. However, this document does not comment on all possible combinations of basicList, subTemplateList, and subTemplateMultiList. Neither does it limit the possible combinations.
このドキュメントでは、構造化データを表現するための基本的なブロックである3つの新しい抽象データ型を、指定します。しかし、この文書はbasicList、subTemplateList、およびsubTemplateMultiListのすべての可能な組み合わせについてはコメントしません。どちらもそれは可能な組み合わせを制限しないん。
IPFIX-specific terminology used in this document is defined in Section 2 of the IPFIX protocol specification [RFC5101] and Section 3 of the PSAMP protocol specification [RFC5476]. As in [RFC5101], these IPFIX-specific terms have the first letter of a word capitalized when used in this document.
この文書で使用IPFIX固有の用語は、IPFIXプロトコル仕様[RFC5101]のセクション2とPSAMPプロトコル仕様[RFC5476]のセクション3で定義されています。 [RFC5101]のように、これらIPFIX固有の用語は、本文書で使用される場合、単語の最初の文字が大文字有します。
Structured Data Information Element
構造化データ情報要素
One of the Information Elements supporting structured data, i.e., the basicList, subTemplateList, or subTemplateMultiList Information Elements specified in Section 4.3.
構造化データ、すなわち、basicList、subTemplateList、またはセクション4.3で指定されたsubTemplateMultiList情報要素をサポートする情報要素の一つ。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
As in the IPFIX protocol specification [RFC5101], the new Information Elements specified in Section 4.3 MUST be sent in canonical format in network-byte order (also known as the big-endian byte ordering).
IPFIXプロトコル仕様[RFC5101]のように、4.3節で指定された新しい情報要素は、（また、ビッグエンディアンバイト順序として知られている）ネットワークバイト順で正規の形式で送らなければなりません。
This document specifies three new abstract data types, as described below.
後述のようにこの文書は、3つの新しい抽象データ型を指定します。
The type "basicList" represents a list of zero or more instances of any Information Element, primarily used for single-valued data types. Examples include a list of port numbers, a list of interface indexes, a list of AS in a BGP AS-PATH, etc.
タイプ「basicList」は、主に単一値のデータ型のために使用される任意の情報要素のゼロ以上のインスタンスのリストを表します。例としては、などのポート番号のリスト、インタフェースインデックスのリスト、BGP AS-PATHでASのリストを含み、
The type "subTemplateList" represents a list of zero or more instances of a structured data type, where the data type of each list element is the same and corresponds with a single Template Record. Examples include a structured data type composed of multiple pairs of ("MPLS label stack entry position", "MPLS label stack value"), a structured data type composed of performance metrics, and a structured data type composed of multiple pairs of IP address, etc.
タイプ「subTemplateList」は、各リスト要素のデータ型が同じであり、単一のテンプレートレコードに対応する構造化データ型のゼロ以上のインスタンスのリストを表します。例としては、複数のペアからなる構造化データ・タイプは、（「MPLSラベルスタックエントリ位置」、「MPLSラベルスタック値」）、パフォーマンス・メトリックからなる構造化データ・タイプ、およびIPアドレスの複数の対からなる構造化データ・タイプ、等
The type "subTemplateMultiList" represents a list of zero or more instances of a structured data type, where the data type of each list element can be different and corresponds with different Template definitions. Examples include a structured data type composed of multiple access-list entries, where entries can be composed of different criteria types.
タイプ「subTemplateMultiList」は、各リスト要素のデータ型が異なっていてもよく、異なるテンプレート定義に対応することができる構造化データ型のゼロ以上のインスタンスのリストを表します。例には、エントリは、異なる条件タイプで構成することができる複数のアクセス・リスト・エントリからなる構造化データ・タイプを含みます。
This document specifies a new data type semantic, in addition to the ones specified in Section 3.2 of the IPFIX information model [RFC5102], as described below.
後述のようにこの文書では、IPFIX情報モデル[RFC5102]の3.2節で指定されたものに加えて、セマンティック新しいデータ型を指定します。
A list represents an arbitrary-length sequence of zero or more structured data Information Elements, either composed of regular Information Elements or composed of data conforming to a Template Record.
リストは、定期的な情報要素から成る又はテンプレートレコードに準拠したデータから構成されるいずれか、ゼロ以上の構造化データ情報要素の任意の長さの配列を表します。
This document specifies three new Information Elements, as described below.
後述のようにこの文書は、3つの新しい情報要素を指定します。
A basicList specifies a generic Information Element with a basicList abstract data type as defined in Section 4.1.1 and list semantics as defined in Section 4.2.1. Examples include a list of port numbers, a list of interface indexes, etc.
4.2.1項で定義されたセクション4.1.1およびリストセマンティクスで定義されているようbasicListはbasicList抽象データ型を持つ一般的な情報要素を指定します。例としては、などのポート番号のリスト、インタフェースインデックスのリストを含み、
A subTemplateList specifies a generic Information Element with a subTemplateList abstract data type as defined in Section 4.1.2 and list semantics as defined in Section 4.2.1.
4.2.1項で定義された4.1.2およびリストセマンティクスで定義されているようsubTemplateListはsubTemplateList抽象データ型を持つ一般的な情報要素を指定します。
A subTemplateMultiList specifies a generic Information Element with a subTemplateMultiList abstract data type as defined in Section 4.1.3 and list semantics as defined in Section 4.2.1.
4.2.1項で定義されたセクション4.1.3およびリストセマンティクスで定義されているようsubTemplateMultiListはsubTemplateMultiList抽象データ型を持つ一般的な情報要素を指定します。
Structured data type semantics are provided in order to express the relationship among multiple list elements in a Structured Data Information Element. These structured data type semantics require a new IPFIX subregistry, as specified in the "IANA Considerations" section. The semantics are specified in the following subsections.
構造化データ型のセマンティクスは、構造化データ情報要素内の複数のリスト要素間の関係を表現するために設けられています。 「IANAの考慮事項」のセクションで指定されているこれらの構造化データ・タイプのセマンティクスは、新しいIPFIXの副登録が必要です。セマンティクスは、以下のサブセクションで指定されています。
The "undefined" structured data type semantic specifies that the semantic of list elements is not specified and that, if a semantic exists, then it is up to the Collecting Process to draw its own conclusions. The "undefined" structured data type semantic, which is the default value, is used when no other structured data type semantic applies.
「未定義の」構造化データ・タイプセマンティック指定は、リスト要素の意味が指定されていないと意味が存在する場合には、それは、独自の結論を引き出すために収集プロセスの状態であること。他の構造化データ型のセマンティックが適用されない場合、デフォルト値であるセマンティック「未定義」構造化データ・タイプは、使用されています。
For example, a mediator that wants to translate IPFIX [RFC5101] into the export of structured data according to the specifications in this document doesn't know what the semantic is; it can only guess, as the IPFIX specifications [RFC5101] does not contain any semantic. Therefore, the mediator should use the "undefined" semantic.
たとえば、この文書の仕様に従って構造化データの輸出にIPFIX [RFC5101]を翻訳したいメディエータは、セマンティックが何であるかを知りません。 IPFIX仕様[RFC5101]は任意のセマンティックが含まれていないとして、それだけで、推測することができます。そのため、仲介者は「未定義」セマンティックを使用する必要があります。
The "noneOf" structured data type semantic specifies that none of the elements are actual properties of the Data Record.
「noneOf」構造化データ型のセマンティックは、要素のどれもがデータレコードの実際の性質ではないことを指定します。
For example, a mediator might want to report to a Collector that a specific Flow is suspicious, but that it checked already that this Flow does not belong to the attack type 1, attack type 2, or attack type 3. So this Flow might need some further inspection. In such a case, the mediator would report the Flow Record with a basicList composed of (attack type 1, attack type 2, attack type 3) and the respective structured data type semantic of "noneOf".
例えば、仲介者は、特定のフローが不審であることをコレクターに報告することがありますが、それはこのフローは攻撃タイプ1、攻撃タイプ2、または攻撃タイプ3に属していないことをすでに確認されるように、このフローは必要になる場合がありますさらにいくつかの検査。このような場合、メディエータは（攻撃タイプ1、攻撃タイプ2、攻撃タイプ3）と「noneOf」の意味各構造化データ型からなるbasicListでフローレコードを報告します。
Another example is a router that monitors some specific BGP AS-PATHs and reports if a Flow belongs to any of them. If the router wants to export that a Flow does not belong to any of the monitored BGP AS-PATHs, the router reports a Data Record with a basicList composed of (BGP AS-PATH 1, BGP AS-PATH 2, BGP AS-PATH 3) and the respective structured data type semantic of "noneOf".
別の例は、フローがそれらのいずれかに属している場合、いくつかの特定のBGP AS-パスとレポートを監視するルータです。ルータはフローを監視BGP AS-パスのいずれかに属していないことをエクスポートしたい場合、ルータは（BGP AS-PATH 1、BGP AS-PATH 2、BGPはAS-PATHで構成basicListでデータレコードをレポート3）及び「noneOf」の各構造化データ型セマンティック。
The "exactlyOneOf" structured data type semantic specifies that only a single element from the structured data is an actual property of the Data Record. This is equivalent to a logical XOR operation.
構造化データから単一要素のみがデータレコードの実際の財産である「exactlyOneOf」構造化データ型のセマンティックを指定します。これは、論理XOR演算と等価です。
For example, if a Flow record contains a basicList of outgoing interfaces with the "exactlyOneOf" semantic, then it implies that the reported Flow only egressed from a single interface, although the Flow Record lists all of the possible outgoing interfaces. This is a typical example of a per destination load-balancing.
フローレコードは、セマンティック「exactlyOneOf」と発信インターフェイスのbasicListが含まれている場合たとえば、それはフローレコードが可能な発信インターフェイスのすべてが一覧表示されますが、報告されたフローだけで、単一のインターフェースからegressedことを意味しています。これは、宛先ごとの負荷分散の典型的な例です。
Another example is a mediator that must aggregate Data Records from different Observation Points and report an aggregated Observation Point. However, the different Observation Points can be specified by different Information Element types depending on the Exporter. For example:
別の例は、異なる観測点からのデータレコードを集約し、集約された観測点を報告しなければならないメディエーターです。しかし、異なる観測点は輸出に依存して、異なる情報要素の種類によって指定することができます。例えば：
Exporter1 Observation Point is characterized by the exporterIPv4Address, so a specific Exporter can be represented.
Exporter1観測ポイントはexporterIPv4Addressことを特徴とするので、特定の輸出を表すことができます。
Exporter2 Observation Point is characterized by the exporterIPv4Address and a basicList of ingressInterface, so the Exporting Process can express that the observations were made on a series of input interfaces.
エクスポートプロセスは、観察が入力インターフェイスの一連で行われたことを表現できるようにExporter2観測ポイントは、exporterIPv4AddressとingressInterfaceのbasicListことを特徴とします。
Exporter3 Observation Point is characterized by the exporterIPv4Address and a specific lineCardId, so the Exporting Process can express that the observation was made on a specific linecard.
エクスポートプロセスが観察は、特定のラインカード上で行われたことを表現できるようにExporter3観測ポイントは、exporterIPv4Address及び特定lineCardIdによって特徴付けられます。
If the mediator models the three different types of Observation Points with the three Template Records below:
メディエーターモデル以下の3枚のテンプレートレコードとの観測点の3種類の場合：
Template Record 1: exporterIPv4Address Template Record 2: exporterIPv4Address, basicList of ingressInterface Template Record 3: exporterIPv4Address, lineCardId
テンプレートレコード1：exporterIPv4Addressテンプレートレコード2：exporterIPv4Address、basicList ingressInterfaceのテンプレートレコード3：exporterIPv4Address、lineCardId
then it can represent the aggregated Observation Point with a subTemplateMultiList and the semantic "exactlyOneOf". The aggregated Observation Point is modeled with the Data Records corresponding to either Template Record 1, Template Record 2, or Template Record 3 but not more than one of these. This implies that the Flow was observed at exactly one of the Observation Points reported.
それはsubTemplateMultiListと意味「exactlyOneOf」と集約された観測点を表すことができます。集約された観測点は、データレコードは、テンプレートレコード1、テンプレートレコード2、又はテンプレートレコード3のいずれかに対応するが、これらのではないつ以上を用いてモデル化されます。これは、流れが報告された観測点のちょうど1で観察されたことを意味します。
The "oneOrMoreOf" structured data type semantic specifies that one or more elements from the list in the structured data are actual properties of the Data Record. This is equivalent to a logical OR operation.
構造化データ内のリストから1つのまたは複数の要素がデータレコードの実際の性質であることを構造化データ・タイプセマンティック指定する「oneOrMoreOf」。これは、論理OR演算に相当します。
Consider an example where a mediator must report an aggregated Flow (e.g., by aggregating IP addresses from IP prefixes), with an aggregated Observation Point. However, the different Observation Points can be specified by different Information Element types as described in Section 4.4.2.
集約された観測点と、メディエータ（例えば、IPプレフィックスからIPアドレスを集約することによって）集約フローを報告しなければならない例を考えます。 4.4.2項で説明したようにしかし、異なる観測ポイントが異なる情報要素の種類によって指定することができます。
If the mediator models the three different types of Observation Points with the three Template Records below:
メディエーターモデル以下の3枚のテンプレートレコードとの観測点の3種類の場合：
Template Record 1: exporterIPv4Address
Template Record 2: exporterIPv4Address, basicList of
ingressInterface
Template Record 3: exporterIPv4Address, lineCardId
then it can represent the aggregated Observation Point with a subTemplateMultiList and the semantic "oneOrMoreOf". The aggregated Observation Point is modeled with the Data Records corresponding to either Template Record 1, Template Record 2, or Template Record 3. This implies that the Flow was observed on at least one of the Observation Points reported, and potentially on multiple Observation Points.
それはsubTemplateMultiListと意味を持つ集約観測点を表すことができ、「oneOrMoreOf」。集約された観測点は、これは、フローは、複数の観測点に潜在的に報告された観測点の少なくとも一方に観察したことを意味するデータレコードテンプレートレコード1、テンプレートレコード2、又はテンプレートレコード3のいずれかに対応してモデル化されます。
The "allOf" structured data type semantic specifies that all of the list elements from the structured data are actual properties of the Data Record.
構造化データからリストのすべての要素がデータレコードの実際のプロパティである「ALLOF」構造化データ型のセマンティックを指定します。
For example, if a Record contains a basicList of outgoing interfaces with the "allOf" semantic, then the observed Flow is typically a multicast Flow where each packet in the Flow has been replicated to each outgoing interface in the basicList.
例えば、レコードが「ALLOF」意味のある発信インターフェイスのbasicListを含む場合、次いで観察フローは、フロー内の各パケットはbasicList内の各発信インターフェイスに複製されたマルチキャストフローは、典型的です。
The "ordered" structured data type semantic specifies that elements from the list in the structured data are ordered.
構造化データのリストからの要素が順序付けられている構造化データ・タイプセマンティック指定「を命じました」。
For example, an Exporter might want to export the AS10 AS20 AS30 AS40 BGP AS-PATH. In such a case, the Exporter would report a basicList composed of (AS10, AS20, AS30, AS40) and the respective structured data type semantic of "ordered".
例えば、輸出業者は、AS10のAS20のAS30のAS40 BGP AS-PATHをエクスポートしたい場合があります。このような場合、輸出業者は（AS10、AS20、AS30、AS40）からなるbasicListと「順序付け」の意味各構造化データ型を報告します。
The following subsections define the encoding of the abstract data types defined in Section 4.1. These data types may be encoded using either fixed- or variable-length Information Elements, as discussed in Section 5.1. Like in the IPFIX specifications [RFC5101], all lengths are specified in octets.
以下のサブセクションは、セクション4.1で定義された抽象データ型のエンコーディングを定義します。セクション5.1で議論するように、これらのデータ・タイプは、固定または可変長情報要素のいずれかを使用して符号化することができます。 IPFIX仕様[RFC5101]のように、すべての長さをオクテットで指定されています。
The basicList Information Element defined in Section 4.3.1 represents a list of zero or more instances of an Information Element and is encoded as follows:
4.3.1項で定義されたbasicList情報要素は、情報要素のゼロ以上のインスタンスのリストを表し、次のように符号化されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Semantic |0| Field ID | Element... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Length | basicList Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: basicList Encoding
図1：basicListエンコーディング
Semantic
セマンティック
The Semantic field indicates the relationship among the different Information Element values within this Structured Data Information Element. Refer to IANA's "IPFIX Structured Data Types Semantics" registry.
セマンティックフィールドは、この構造化データ情報要素内の異なる情報要素の値の関係を示しています。 IANAの「IPFIX構造化データ・タイプのセマンティクス」のレジストリを参照してください。
Field ID
フィールドID
Field ID is the Information Element identifier of the Information Element(s) contained in the list.
フィールドIDは、リストに含まれている情報要素（複数可）の情報要素識別子です。
Element Length
要素長さ
Per Section 7 of [RFC5101], the Element Length field indicates the length, in octets, of each list element specified by Field ID, or contains the value 0xFFFF if the length is encoded as a variable-length Information Element at the start of the basicList Content.
[RFC5101]のセクション7当たり、素子長さフィールドは、フィールドIDで指定された各リスト要素のオクテットの長さを示し、または長さが開始時に可変長情報要素として符号化された場合に値が0xFFFFが含まbasicListコンテンツ。
Effectively, the Element Length field is part of the header, so even in the case of a zero-element list, it MUST NOT be omitted.
効果的に、素子長さフィールドは、ヘッダの一部であり、そうであってもゼロ要素のリストの場合には、省略してはいけません。
basicList Content
basicListコンテンツ
A Collecting Process decodes list elements from the basicList Content until no further data remains. A field count is not included but can be derived when the Information Element is decoded.
それ以上のデータが残っていないまで収集プロセスはbasicListコンテンツからリスト要素をデコードします。フィールドカウントが含まれていませんが、情報要素がデコードされたときに導出することができます。
Note that in the diagram above, Field ID is shown with the Enterprise bit (most significant bit) set to 0. Instead, if the Enterprise bit is set to 1, a four-byte Enterprise Number MUST be encoded immediately after the Element Length as shown below. See the "Field Specifier Format" section in the IPFIX protocol [RFC5101] for additional information.
上記の図では、フィールドIDがエンタープライズビットで示されることに注意してくださいエンタープライズビットが1に設定されている場合（最上位ビット）を0に設定する代わりに、4バイトの企業番号として直ちに要素長さの後に符号化されなければなりません下に示された。追加情報については、IPFIXプロトコル[RFC5101]で「フィールド指定子のフォーマット」を参照してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Semantic |1| Field ID | Element... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Length | Enterprise Number ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | basicList Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: basicList Encoding with Enterprise Number
図2：エンタープライズ番号とbasicListエンコーディング
Also, note that if a basicList has zero elements, the encoded data contains the Semantic field, Field ID, the Element Length field, and the four-byte Enterprise Number (if present), while the basicList Content is empty.
また、basicListはゼロ要素を持つ場合basicListコンテンツが空であるが、符号化されたデータは、セマンティックフィールド、フィールドID、素子長さフィールド、及び4バイトの企業番号（存在する場合）を含むことに注意してください。
If the basicList is encoded as a variable-length Information Element in less than 255 octets, it MAY be encoded with the Length field per Section 7 of [RFC5101] as shown in Figure 3. However, the three-byte length encoding, as shown in Figure 4, is RECOMMENDED (see Section 5.1).
basicList未満255個のオクテットで可変長情報要素として符号化される場合は、図3に示すように示すように、それは、[RFC5101]のセクション7あたりの長さフィールドと3バイトの長さの符号を符号化することができます図4に、（セクション5.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (< 255)| Semantic |0| Field ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element Length | basicList Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Variable-Length basicList Encoding
(Length < 255 Octets)
If the basicList is encoded as a variable-length Information Element in 255 or more octets, it MUST be encoded with the Length field per Section 7 of [RFC5101] as follows:
basicListが255オクテット以上で可変長情報要素として符号化される場合、次のように[RFC5101]のセクション7あたりLengthフィールドで符号化されなければなりません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | Length (0 to 65535) | Semantic |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Field ID | Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| basicList Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Variable-Length basicList Encoding (Length 0 to 65535 Octets)
図4：可変長basicList符号化（65535オクテットまでの長さ0）
The subTemplateList Information Element represents a list of zero or more Data Records corresponding to a specific Template. Because the Template Record referenced by a subTemplateList Information Element can itself contain other subTemplateList Information Elements, and because these Template Record references are part of the Information Elements content in the Data Record, it is possible to represent complex hierarchical data structures. The following diagram shows how a subTemplateList Information Element is encoded within a Data Record:
subTemplateList情報要素は、特定のテンプレートに対応するゼロまたはそれ以上のデータレコードのリストを表します。 subTemplateList情報要素が参照するテンプレートレコードは、それ自体が他のsubTemplateList情報要素を含むことができ、これらのテンプレートレコードの参照がデータレコード内の情報要素の内容の一部であるため、複雑な階層データ構造を表現することができるので。次の図は、subTemplateList情報要素は、データレコード内でエンコードされた方法を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Semantic | Template ID | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subTemplateList Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: subTemplateList Encoding
図5：subTemplateListエンコーディング
Semantic
セマンティック
The Semantic field indicates the relationship among the different Data Records within this Structured Data Information Element.
セマンティックフィールドは、この構造化データ情報要素内の異なるデータレコード間の関係を示しています。
Template ID
テンプレートのID
The Template ID field contains the ID of the Template used to encode and decode the subTemplateList Content.
テンプレートIDフィールドは、符号化及びsubTemplateListコンテンツを復号するために使用されるテンプレートのIDを含んでいます。
subTemplateList Content
subTemplateListコンテンツ
subTemplateList Content consists of zero or more instances of Data Records corresponding to the Template ID specified in the Template ID field. A Collecting Process decodes the subTemplateList Content until no further data remains. A record count is not included but can be derived when the subTemplateList is decoded. Encoding and decoding are performed recursively if the specified Template itself contains Structured Data Information Elements as described here.
subTemplateListコンテンツは、テンプレートIDフィールドに指定されたテンプレートIDに対応するデータレコードのゼロ以上のインスタンスで構成されています。それ以上のデータが残っていないまで収集プロセスはsubTemplateListコンテンツをデコードします。レコード数が含まれていませんが、subTemplateListがデコードされたときに導出することができます。ここで説明するように指定されたテンプレート自体が構造化データ情報要素が含まれている場合、エンコードとデコードが再帰的に実行されています。
Note that, if a subTemplateList has zero elements, the encoded data contains only the Semantic field and the Template ID field, while the subTemplateList Content is empty.
subTemplateListはゼロ要素を持つ場合subTemplateListコンテンツが空であるが、符号化されたデータは、唯一の意味領域とテンプレートIDフィールドを含むことに留意されたいです。
If the subTemplateList is encoded as a variable-length Information Element in less than 255 octets, it MAY be encoded with the Length field per Section 7 of [RFC5101] as shown in Figure 6. However, the three-byte length encoding, as shown in Figure 7, is RECOMMENDED (see Section 5.1).
subTemplateList未満255個のオクテットで可変長情報要素として符号化される場合は、図6に示すように示すように、それは、[RFC5101]のセクション7あたりの長さフィールドと3バイトの長さの符号を符号化することができます図7に、（セクション5.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (< 255)| Semantic | Template ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subTemplateList Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Variable-Length subTemplateList Encoding (Length < 255 Octets)
図6：可変長subTemplateList符号化（長さ<255オクテット）
If the subTemplateList is encoded as a variable-length Information Element in 255 or more octets, it MUST be encoded with the Length field per Section 7 of [RFC5101] as follows:
subTemplateListが255オクテット以上で可変長情報要素として符号化される場合、次のように[RFC5101]のセクション7あたりLengthフィールドで符号化されなければなりません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | Length (0 to 65535) | Semantic |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | subTemplateList Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Variable-Length subTemplateList Encoding (Length 0 to 65535 Octets)
図7：可変長subTemplateList符号化（65535オクテットまでの長さ0）
Whereas each element in a subTemplateList Information Element corresponds to a single Template, it is sometimes useful for a list to contain elements corresponding to different Templates. To support this case, each top-level element in a subTemplateMultiList Information Element carries a Template ID, Length, and zero or more Data Records corresponding to the Template ID. The following diagram shows how a subTemplateMultiList Information Element is encoded within a Data Record. Note that the encoding following the Semantic field is consistent with the Set Header specified in [RFC5101].
subTemplateList情報要素の各要素が単一のテンプレートに対応し、一方、リストが異なるテンプレートに対応する要素を含有することが時には有用です。このような場合をサポートするために、subTemplateMultiList情報要素内の各トップレベル要素は、テンプレートIDに対応するテンプレートID、長さを搬送し、ゼロまたはそれ以上のデータレコード。次の図は、subTemplateMultiList情報要素は、データレコード内でエンコードされる方法を示しています。意味領域次エンコーディングは[RFC5101]で指定されたセットヘッダと一致していることに留意されたいです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Semantic | Template ID X |Data Records...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Length X | Data Record X.1 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Record X.2 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Record X.L Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Template ID Y |Data Records...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Length Y | Data Record Y.1 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Record Y.2 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Record Y.M Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Template ID Z |Data Records...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Length Z | Data Record Z.1 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Record Z.2 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Record Z.N Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+
Figure 8: subTemplateMultiList Encoding
図8：subTemplateMultiListエンコーディング
Semantic
セマンティック
The Semantic field indicates the top-level relationship among the series of Data Records corresponding to the different Template Records within this Structured Data Information Element.
セマンティックフィールドは、この構造化データ情報要素内の異なるテンプレートレコードに対応するデータレコードのシリーズの中でトップレベルの関係を示しています。
Template ID
テンプレートのID
Unlike the subTemplateList Information Element, each element of the subTemplateMultiList contains a Template ID that specifies the encoding of the following Data Records.
subTemplateList情報要素とは異なり、subTemplateMultiListの各要素は、以下のデータレコードのエンコーディングを指定するテンプレートIDが含まれています。
Data Records Length
データレコード長
This is the total length of the Data Records encoding for the Template ID previously specified, including the two bytes for the Template ID and the two bytes for the Data Records Length field itself.
これは、以前のテンプレートIDの2バイトとデータレコード長フィールド自体のための2つのバイトを含む、指定されたテンプレートIDのデータレコード符号の合計の長さです。
Data Record X.M
データレコードX.M
The Data Record X.M consists of the Mth Data Record of the Template Record X. A Collecting Process decodes the Data Records according to Template Record X until no further data remains, according to the Data Records Length X. Further Template IDs and Data Records may then be decoded according to the overall subTemplateMultiList length. A record count is not included but can be derived when the Element Content is decoded. Encoding and decoding are performed recursively if the specified Template itself contains Structured Data Information Elements as described here.
データレコードXMは、テンプレートレコードX. A収集処理のM番目のデータレコードで構成されていまたテンプレートIDおよびデータレコードは、次に可能性のあるデータレコードの長さXに応じて、更なるデータがなくなるまでテンプレートレコードXに応じてデータレコードを復号化全体subTemplateMultiList長に応じて復号すること。レコード数が含まれていませんが、要素の内容が解読されたときに導出することができます。ここで説明するように指定されたテンプレート自体が構造化データ情報要素が含まれている場合、エンコードとデコードが再帰的に実行されています。
In the exceptional case of zero instances in the subTemplateMultiList, no data is encoded, only the Semantic field and Template ID field(s), and the Data Record Length field is set to zero.
subTemplateMultiListゼロインスタンスの例外的な場合では、データは、意味領域とテンプレートIDフィールド（複数可）、符号化されていない、およびデータレコード長フィールドはゼロに設定されます。
If the subTemplateMultiList is encoded as a variable-length Information Element in less than 255 octets, it MAY be encoded with the Length field per Section 7 of [RFC5101] as shown in Figure 9. However, the three-byte length encoding, as shown in Figure 10, is RECOMMENDED (see Section 5.1).
subTemplateMultiList未満255個のオクテットで可変長情報要素として符号化される場合は、図9に示すように示すように、それは、[RFC5101]のセクション7あたりの長さフィールドと3バイトの長さの符号を符号化することができます図10に、（セクション5.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (< 255)| Semantic | Template ID X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Records Length X | Data Record X.1 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Record X.2 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Record X.L Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Template ID Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Records Length Y | Data Record Y.1 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Record Y.2 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Record Y.M Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Template ID Z |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Records Length Z | Data Record Z.1 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Record Z.2 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Data Record Z.N Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Variable-Length subTemplateMultiList Encoding (Length < 255 Octets)
図9：可変長subTemplateMultiList符号化（長さ<255オクテット）
If the subTemplateMultiList is encoded as a variable-length Information Element in 255 or more octets, it MUST be encoded with the Length field per Section 7 of [RFC5101] as follows:
subTemplateMultiListが255オクテット以上で可変長情報要素として符号化される場合、次のように[RFC5101]のセクション7あたりLengthフィールドで符号化されなければなりません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | Length (0 to 65535) | Semantic |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID X | Data Records Length X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Record X.1 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Record X.2 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Record X.L Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID Y | Data Records Length Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Record Y.1 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Record Y.2 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Record Y.M Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID Z | Data Records Length Z |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Record Z.1 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Record Z.2 Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Record Z.N Content ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Variable-Length subTemplateMultiList Encoding (Length 0 to 65535 Octets)
図10：可変長subTemplateMultiList符号化（65535オクテットまでの長さ0）
The new Structured Data Information Elements represent a list that potentially carries complex hierarchical and repeated data.
新構造化データの情報要素は、潜在的に複雑な階層と繰り返しデータを運ぶリストを表します。
When the encoding of a Structured Data Information Element has a fixed length (because, for example, it contains the same number of fixed-length elements, or if the permutations of elements in the list always produces the same total length), the element length can be encoded in the corresponding Template Record.
構造化データ情報要素の符号化は、固定長（例えば、それは固定長の同じ数の要素を含んでいるため、またはリスト内の要素の順列が常に同じ全長を生成する場合）、素子の長さを有する場合対応するテンプレートレコードに符号化することができます。
However, when representing variable-length data, hierarchical data, and repeated data with variable element counts, where the number and length of elements can vary from record to record, we RECOMMEND that the Information Elements are encoded using the variable-length encoding described in Section 7 of [RFC5101], with the length carried before the Structured Data Information Element encoding.
要素の数及び長さが記録するレコードから変えることができる可変素子数と可変長データ、階層データ、重複データを表す場合しかし、我々は、情報要素は、に記載の可変長符号化を用いて符号化されることをお勧めします構造化データ情報要素を符号化する前に行う長さを有する、[RFC5101]のセクション7、。
Because of the complex and repeated nature of the data, it is potentially difficult for the Exporting Process to efficiently know in advance the exact encoding size. In this case, the Exporting Process may encode the available data starting at a fixed offset and fill in the final length afterwards. Therefore, the three-byte length encoding is RECOMMENDED for variable-length Information Elements in all Template Records containing a Structured Data Information Element, even if the encoded length can be less than 255 bytes, because the starting offset of the data is known in advance.
エクスポートプロセスが効率的に正確な符号化サイズを予め知っておくためにので、データの複雑かつ繰り返し性質のため、それは潜在的に困難です。この場合、エクスポートプロセスは、固定されたオフセットから始まる利用可能なデータを符号化することができ、その後、最終的な長さで埋めます。データの開始オフセットが予め分かっているので、したがって、3バイト長の符号化は、符号化された長さが255バイト未満であることができる場合であっても、構造化データ情報要素を含むすべてのテンプレートレコードに可変長情報要素のために推奨され。
When encoding such data, an Exporting Process MUST take care to not exceed the maximum allowed IPFIX message length of 65535 bytes as specified in [RFC5101].
そのようなデータを符号化する際に、エクスポートプロセスは、[RFC5101]で指定されるように65535バイトの最大許容IPFIXメッセージの長さを超えないように注意しなければなりません。
It is possible to define recursive relationships between IPFIX structured data instances, for example, when representing a tree structure. The simplest case of this might be a basicList, where each element is itself a basicList, or a subTemplateList where one of the fields of the referenced Template is itself a subTemplateList referencing the same Template. Also, the Exporting Process MUST take care when encoding recursively-defined structured data not to exceed the maximum allowed length of an IPFIX Message (as noted in Length Encoding Considerations).
ツリー構造を表す場合、例えば、IPFIX構造化データ・インスタンス間の再帰的関係を定義することが可能です。この最も単純な場合は、参照テンプレートのフィールドのいずれかが、同じテンプレートを参照subTemplateList自体である各要素はbasicList自体でbasicList、またはsubTemplateListかもしれません。 （レングス符号化の考慮事項に記載されているように）IPFIXメッセージの最大長を超えないように再帰的に定義された構造化データを符号化する場合にも、エクスポートプロセスは、注意しなければなりません。
5.3. Structured Data Information Elements Applicability in Options Template Sets
5.3. オプションテンプレートセットでの構造化データの情報要素の適用
Structured Data Information Elements MAY be used in Options Template Sets.
構造化データの情報要素はオプションテンプレートセットで使用されるかもしれません。
As an example, consider a mediation function that must aggregate Data Records from multiple Observation Point types:
一例として、複数の観測点タイプからデータレコードを集約しなければならない調停機能を考えてみます。
Router 1, (interface 1) Router 2, (linecard A) Router 3, (linecard B) Router 4, (linecard C, interface 2)
ルータ1、（インターフェース1）ルータ2、（ラインカードA）ルータ3、（ラインカードB）ルータ4、（ラインカードC、インタフェース2）
In order to encode the PSAMP Selection Sequence Report Interpretation [RFC5476], the mediation function must express this combination of Observation Points as a single new Observation Point. Recall from [RFC5476] that the PSAMP Selection Sequence Report Interpretation consists of the following fields:
PSAMP選択シーケンスレポートの解釈[RFC5476]をコード化するためには、調停機能は、単一の新しい観測点として観測点の組み合わせを表現しなければなりません。 [RFC5476]からリコールPSAMP選択シーケンスレポートの解釈は、次のフィールドで構成されていること：
Scope: selectionSequenceId Non-Scope: one Information Element mapping the Observation Point selectorId (one or more)
スコープ：selectionSequenceId非対象範囲：1情報要素の観測ポイントselectorId（1以上）をマッピング
Without structured data, there is clearly no way to express the complex aggregated Observation Point as "one Information Element mapping the Observation Point". However, the desired result may be easily achieved using the structured data types. Refer to Section 9.5. for an encoding example related to this case study.
構造化データがなければ、明確に「1情報要素の観測ポイントをマッピングする」として集計し、複雑な観察ポイントを表現する方法はありません。しかし、所望の結果を容易に構造化データ型を使用して達成することができます。 9.5節を参照してください。このケーススタディに関連するエンコーディング例えば。
Regarding the scope in the Options Template Record, the IPFIX specification [RFC5101] mentions that "the IPFIX protocol doesn't prevent the use of any Information Elements for scope". Therefore, a Structured Data Information Element MAY be used as scope in an Options Template Set.
オプションテンプレートレコード内の範囲について、IPFIX仕様[RFC5101]は「IPFIXプロトコルはスコープの任意の情報要素の使用を妨げない」と述べています。したがって、構造化データ情報要素はオプションテンプレートセット内のスコープとして使用することができます。
Extending the previous example, the mediation function could export a given name for this complex aggregated Observation Point:
前の例を拡張し、調停機能は、この複雑な集約された観測点に与えられた名前をエクスポートできます。
Scope: Aggregated Observation Point (structured data) Non-Scope: a new Information Element containing the name
スコープ：集約の観測ポイント（構造化データ）非対象範囲：新しい情報要素は、名前を含みます
Because basicList, subTemplateList, and subTemplateMultiList are all lists, in several cases, there is more than one way to represent what is effectively the same data structure. However, in some cases, one approach has an advantage over the other, e.g., more compact, uses fewer resources, and is therefore preferred over an alternate representation.
basicList、subTemplateList、およびsubTemplateMultiListがすべてリストされているので、いくつかのケースでは、効果的に同じデータ構造が何であるかを表すために複数の方法があります。しかし、いくつかのケースでは、1つのアプローチは、他の上の利点を有し、例えば、よりコンパクトに、より少ないリソースを使用し、したがって、代替表現よりも好ましいです。
A subTemplateList can represent the same simple list of single-valued Information Elements as a basicList, if the Template referenced by the subTemplateList contains only one single-valued Information Element. Although the encoding is more compact than a basicList by two bytes, using a subTemplateList, in this case, requires a new
subTemplateListが参照するテンプレートは、ただ1つの値の情報要素が含まれている場合subTemplateListは、basicListとして単一値情報要素の同じ単純なリストを表すことができます。符号化subTemplateListを使用して、2バイトでbasicListよりもコンパクトであるが、この場合には、新たに必要と
Template per Information Element. The basicList requires no additional Template and is therefore RECOMMENDED in this case.
情報要素ごとのテンプレート。 basicListは、追加のテンプレートを必要としないため、この場合にお勧めです。
Although a subTemplateMultiList with one Element can represent the contents of a subTemplateList, the subTemplateMultiList carries two additional bytes (Element Length). It is also potentially useful to a Collecting Process to know in advance that a subTemplateList directly indicates that list element types are consistent. The subTemplateList Information Element is therefore RECOMMENDED in this case.
一つの要素とsubTemplateMultiListはsubTemplateListの内容を表すことができるが、subTemplateMultiListは、2つの追加バイト（要素長さ）を運びます。 subTemplateListが直接リスト要素の型が一致していることを示していることを事前に知ることも収集プロセスに有用である可能性があります。 subTemplateList情報要素は、したがって、この場合にお勧めです。
The Semantic field in a subTemplateMultiList indicates the top-level relationship among the series of Data Records corresponding to the different Template Records, within this Structured Data Information Element. If a semantic is required to describe the relationship among the different Data Records corresponding to a single Template ID within the subTemplateMultiList, then an encoding based on a basicList of subTemplateLists should be used; refer to Section 5.6 for more information. Alternatively, if a semantic is required to describe the relationship among all Data Records within a subTemplateMultiList (regardless of the Template Record), an encoding based on a subTemplateMultiList with one Data Record corresponding to a single Template ID can be used.
subTemplateMultiListにおけるセマンティックフィールドは、この構造化データ情報要素内の異なるテンプレートレコードに対応するデータレコードのシリーズの中でトップレベルの関係を、示しています。セマンティックをsubTemplateMultiList内の単一のテンプレートIDに対応する異なるデータ・レコード間の関係を記述するために必要とされる場合、subTemplateListsのbasicListに基づいて符号化を使用すべきです。詳細については、セクション5.6を参照してください。セマンティックは、（関係なく、テンプレートレコードの）単一のテンプレートIDに対応するデータレコードとsubTemplateMultiListに基づいて符号化をsubTemplateMultiList内のすべてのデータレコード間の関係を記述するために必要とされる場合に代替的に使用することができます。
Note that the referenced Information Element(s) in the Structured Data Information Elements can be taken from the IPFIX information model [RFC5102], the PSAMP information model [RFC5477], any of the Information Elements defined in the IANA IPFIX registry [IANA-IPFIX], or enterprise-specific Information Elements.
構造化データ情報エレメントにおいて参照情報要素（単数または複数）はIPFIX情報モデルから取り出すことができることに留意されたい[RFC5102]、PSAMP情報モデル[RFC5477]、IANA IPFIXレジストリに定義されている情報要素の任意[IANA-IPFIX ]、または企業固有の情報要素。
If a Template Record contains a subTemplateList as the only field, a Set encoding as specified in the IPFIX protocol specifications [RFC5101] should be considered, unless:
テンプレートレコードが唯一のフィールドとしてsubTemplateListが含まれている場合は、IPFIXプロトコル仕様[RFC5101]で指定されたセットエンコーディングがない限り、考慮されるべきです。
- A relationship among multiple list elements must be exported, in which case, the semantic from the IPFIX Structured Data Information Element can convey this relationship.
- 複数のリストの要素間の関係は、その場合には、IPFIX構造化データ情報要素から意味は、この関係を伝えることができ、エクスポートする必要があります。
- The Exporting Process wants to convey the number of elements in the list, even in the special cases of zero or one element in the list. Indeed, the case of an empty list cannot be represented with the IPFIX protocol specifications [RFC5101]. In the case of a single element list, the Template Record specified in the IPFIX protocol specification [RFC5101] could be used. However, on the top of the Template Record with the subTemplateList to export multiple list elements, this supplementary Template would impose some extra management, both on the Exporting Process and on the Collecting Process, which might have to correlate the information from two Template Records.
- エクスポートプロセスも、リスト内のゼロまたは1つの要素の特殊なケースでは、リスト内の要素の数を伝えたいです。実際には、空のリストの場合は、IPFIXプロトコル仕様[RFC5101]で表すことができません。単一要素リストの場合には、テンプレートレコードを使用することができるIPFIXプロトコル仕様[RFC5101]で指定されました。しかし、複数のリスト要素をエクスポートするsubTemplateListとテンプレートレコードの上に、この補助的なテンプレートは、エクスポートプロセスにと2枚のテンプレートレコードからの情報を相関させる必要がある場合があります収集プロセス、上の両方の、いくつかの余分な管理を課します。
Similarly, if a Template Record contains a subTemplateMultiList as the only field, an IPFIX Message as described in the IPFIX protocol specification [RFC5101] should be considered, unless:
テンプレートレコードが唯一のフィールドとしてsubTemplateMultiListが含まれている場合、同様に、IPFIXメッセージない限り、考慮されるべきであるIPFIXプロトコル仕様[RFC5101]に記載されているように。
- A relationship among top-level list elements must be exported, in which case, the semantic from the IPFIX Structured Data Information Element can convey this relationship.
- トップレベルのリスト要素間の関係は、その場合には、IPFIX構造化データ情報要素から意味は、この関係を伝えることができ、エクスポートする必要があります。
- The Exporting Process wants to convey the number of Data Records corresponding to every Template in the subTemplateMultiList.
- エクスポートプロセスはsubTemplateMultiList内のすべてのテンプレートに対応するデータレコードの数を伝えたいです。
The Exporting Process MAY insert some padding octets in structured data field values in a Data Record by including the 'paddingOctets' Information Element as described in [RFC5101], Section 3.3.1. The paddingOctets Information Element can be included in a Template Record referenced by a structured data Information Element for this purpose.
エクスポートプロセスは、[RFC5101]に記載されているように、「paddingOctets」情報要素を含むことによって、データレコード内の構造化データのフィールド値の一部のパディングオクテットを挿入することができる3.3.1。 paddingOctets情報要素は、この目的のために構造化されたデータ情報要素が参照するテンプレートレコードに含めることができます。
Semantic interpretations of received Data Records at or beyond the Collecting Process remain explicitly undefined, unless that data is transmitted using this extension with explicit structured data type semantic information.
そのデータは、明示的な構造化データ・タイプ意味情報と、この拡張機能を使用して送信されていない限り、収集プロセスで、または超えて受け取ったデータレコードの意味解釈は、明示的に未定義のまま。
It is not the Exporter's role to check the validity of the semantic representation of Data Records.
データレコードの意味表現の妥当性をチェックするために輸出業者の役割ではありません。
More complex semantics can be expressed as a combination of the Semantic Data Information Elements specified in this document.
より複雑なセマンティクスは、この文書で指定されたセマンティック・データ情報要素の組み合わせとして表現することができます。
For example, the export of the AS10 AS20 AS30 AS40 {AS50,AS60} BGP AS-PATH would be reported as a basicList of two elements, each element being a basicList of BGP AS, with the top-level structured data type semantic of "ordered". The first element would contain a basicList composed of (AS10,AS20,AS30,AS40) and the respective structured data type semantic of "ordered", while the second element would contain a basicList composed of (AS50, AS60) and the respective structured data type semantic of "exactlyOneOf". A high-level Data Record diagram would be represented as:
例えばAS-PATH AS10とAS20とAS30とAS40 {AS50、AS60} BGP」との意味的なトップレベルの構造化データ・タイプと、各要素はBGP ASのbasicListされ、二つの要素のbasicListとして報告されるの、輸出順序付けられました"。第二要素が（AS50、AS60）からなるbasicListと各構造化データを含むであろうしつつ、第1の要素は、（AS10、AS20、AS30、AS40）および「順序付け」の意味各構造化データ型からなるbasicListを含むであろう「exactlyOneOf」の意味と入力します。ハイレベルのデータレコード図は次のように表現されます。
BGP AS-PATH = (basicList, ordered,
BGP AS-PATH =（basicListは、注文しました
(basicList, ordered, AS10,AS20,AS30,AS40),
（basicList、注文、AS10、AS20、AS30、AS40）、
(basicList, exactlyOneOf, AS50, AS60)
（基本一覧、ちょうど1、AS50、AS60）
)
）
If a semantic is required to describe the relationship among the different Data Records corresponding to a single Template ID within the subTemplateMultiList, then an encoding based on a basicList of subTemplateLists should be used, as shown in the next case study.
セマンティックをsubTemplateMultiList内の単一のテンプレートIDに対応する異なるデータ・レコード間の関係を記述するために必要とされる場合、次の事例に示されるように、次いでsubTemplateListsのbasicListに基づく符号化は、使用されるべきです。
Case study 1:
ケーススタディ1：
In this example, an Exporter monitoring security attacks must export a list of security events consisting of attackers and targets. For the sake of the example, assume that the Collector can differentiate the attacker (which is expressed using source fields) from the target (which is expressed using destination fields). Imagine that attackers A1 or A2 may attack targets T1 and T2.
この例では、セキュリティ攻撃を監視Exporterは、攻撃者とターゲットからなるセキュリティイベントのリストをエクスポートする必要があります。例のために、コレクタ（宛先フィールドを使用して表現される）ターゲットから（ソース・フィールドを使用して表現される）攻撃を区別することができると仮定する。攻撃者A1やA2がターゲットT1およびT2を攻撃することを想像してみてください。
The first case uses a subTemplateMultiList composed of two Template Records, one representing the attacker and one representing the target, each of them containing an IP address and a port.
最初のケースは二つのテンプレートレコードからなるsubTemplateMultiListを使用してターゲットを表す攻撃一つを表す1つ、それらの各々は、IPアドレスとポートを含みます。
Attacker Template Record = (src IP address, src port)
攻撃者はテンプレートレコード=（SRC IPアドレス、SRCポート）
Target Template Record = (dst IP address, dst port)
ターゲットテンプレートレコード=（DST IPアドレス、DSTポート）
A high-level Data Record diagram would be represented as:
ハイレベルのデータレコード図は次のように表現されます。
Alert = (subTemplateMultiList, allOf,
警告=（subTemplateMultiList、ALLOF、
(Attacker Template Record, A1, A2),
（攻撃テンプレートレコード、A1、A2）、
(Target Template Record, T1, T2)
（ターゲットテンプレートレコード、T1、T2）
)
）
The Collecting Process can only conclude that the list of attackers (A1, A2) and the list of targets (T1, T2) are present, without knowing the relationship amongst attackers and targets. The Exporting Process would have to explicitly call out the relationship amongst attackers and targets as the top-level semantic offered by the subTemplateMultiList isn't sufficient.
収集プロセスは、攻撃者とターゲット間の関係を知ることなく、攻撃者（A1、A2）とターゲット（T1、T2）のリストのリストは、存在していると結論付けることができます。エクスポートプロセスはsubTemplateMultiListが提供するトップレベルのセマンティックが十分でないとして明示的に攻撃者とターゲットの間で関係を呼び出す必要があります。
The only proper encoding for the previous semantic (i.e., attacker A1 or A2 may attack target T1 and T2) uses a basicList of subTemplateLists and is represented as follows:
以前のセマンティック（即ち、アタッカーA1又はA2がターゲットT1およびT2を攻撃することができる）のためにのみ適切な符号化はsubTemplateListsのbasicListを使用し、次のように表されます。
Attacker Template Record = (src IP address, src port)
攻撃者はテンプレートレコード=（SRC IPアドレス、SRCポート）
Target Template Record = (dst IP address, dst port)
ターゲットテンプレートレコード=（DST IPアドレス、DSTポート）
Alert = (basicList, allOf,
警告=（basicList、ALLOF、
(subTemplateList, exactlyOneOf, attacker A1, A2)
（subTemplateList、exactlyOneOf、攻撃者A1、A2）
(subTemplateList, allOf, target T1, T2)
（subTemplateList、ALLOF、ターゲットT1、T2）
)
）
Case study 2:
ケーススタディ2：
In this example, an Exporter monitoring security attacks must export a list of attackers and targets. For the sake of the example, assume that the Collector can differentiate the attacker (which is expressed using source fields) from the target (which is expressed using destination fields). Imagine that attacker A1 or A2 is attacking target T1, while attacker A3 is attacking targets T2 and T3. The first case uses a subTemplateMultiList that contains Data Records corresponding to two Template Records, one representing the attacker and one representing the target, each of them containing an IP address and a port.
この例では、セキュリティ攻撃を監視Exporterは、攻撃者とターゲットのリストをエクスポートする必要があります。例のために、コレクタ（宛先フィールドを使用して表現される）ターゲットから（ソース・フィールドを使用して表現される）攻撃を区別することができると仮定する。攻撃者A3がターゲットT2とT3を攻撃している間に、A1やA2がターゲットT1を攻撃している攻撃者を想像してみてください。最初のケースは二つのテンプレートレコードに対応するデータレコードを含むsubTemplateMultiListを使用してターゲットを表す攻撃一つを表す1つ、それらの各々は、IPアドレスとポートを含みます。
Attacker Template Record = (src IP address, src port)
Target Template Record = (dst IP address, dst port)
A high-level Data Record diagram would be represented as:
ハイレベルのデータレコード図は次のように表現されます。
Alert = (subTemplateMultiList, allOf,
警告=（subTemplateMultiList、ALLOF、
(Attacker Template Record, A1, A2, A3),
（攻撃テンプレートレコード、A1、A2、A3）、
(Target Template Record, T1, T2, T3)
（ターゲットテンプレートレコード、T1、T2、T3）
)
）
The Collecting Process can only conclude that the list of attackers (A1, A2, A3), and the list of targets (T1, T2, T3) are present, without knowing the relationship amongst attackers and targets.
収集プロセスは、攻撃者とターゲット間の関係を知ることなく、攻撃者（A1、A2、A3）、および標的（T1、T2、T3）のリストのリストは、存在していると結論付けることができます。
The second case could use a Data Record definition composed of the following:
後者の場合は、以下で構成されるデータレコード定義を使用することができます。
Alert = (subTemplateMultiList, allOf,
警告=（subTemplateMultiList、ALLOF、
(Attacker Template Record, A1, A2),
（攻撃テンプレートレコード、A1、A2）、
(Target Template Record, T1),
（ターゲットテンプレートレコード、T1）
(Attacker Template Record, A3),
（攻撃テンプレートレコード、A3）
(Target Template Record, T2, T3)
（ターゲットテンプレートレコード、T2、T3）
)
）
With the above representation, the Collecting Process can infer that the alert consists of the list of attackers (A1, A2), target (T1), attacker (A3), and list of targets (T2, T3). From the sequence in which attackers and targets are encoded, the Collector can possibly deduce that some relationship exists among (A1, A2, T1) and (A2, T1, T2) but cannot understand what it is exactly. So, there is a need for the Exporting Process to explicitly define the relationship between the attackers, and targets and the top-level semantic of the subTemplateMultiList is not sufficient.
上記の表現で、収集プロセスは、アラートが攻撃者（A1、A2）、ターゲット（T1）、アタッカー（A3）、及びターゲットのリスト（T2、T3）のリストで構成されていることを推測することができます。攻撃者とターゲットがコード化される順序から、コレクターは、おそらくいくつかの関係が（A1、A2、T1）及び（A2、T1、T2）の間に存在するが、それは正確に何であるか理解できないことを推測することができます。だから、明示的に攻撃し、目標とsubTemplateMultiListのセマンティックトップレベルが十分でないとの間の関係を定義するためにエクスポートプロセスの必要性があります。
The only proper encoding for the previous semantic (i.e., attacker A1 or A2 attacks target T1, attacker A3 attacks targets T2 and T3) uses a basicList of subTemplateLists and is represented as follows:
前セマンティックに対してのみ適切なエンコード（即ち、アタッカーA1またはA2の攻撃がT1を標的とする、攻撃者A3攻撃は、T2とT3を標的）subTemplateListsのbasicListを使用し、次のように表されます。
Participant P1 =
参加者P1 =
(basicList, allOf,
（basicList、ALLOF、
(subTemplateList, exactlyOneOf, attacker A1, A2)
（subTemplateList、exactlyOneOf、攻撃者A1、A2）
(subTemplateList, undefined, target T1)
（SubTemplateList、未定義は、T1をターゲット）
)
）
Participant P2 =
参加者P2 =
(basicList, allOf,
（basicList、ALLOF、
(subTemplateList, undefined, attacker A3,
（subTemplateList、未定義、攻撃者はA3、
(subTemplateList, allOf, targets T2, T3)
（subTemplateList、ALLOFは、T2、T3をターゲット）
)
）
The security alert is represented as a subTemplateList of participants.
セキュリティの警告が参加者のsubTemplateListとして表現されます。
Alert =
警告=
(subTemplateList, allOf, Participant P1, Participant P2)
（subTemplateList、ALLOF、参加者P1、参加者P2）
Note that, in the particular case of a single element in a Structured Data Information Element, the Semantic field is actually not very useful since it specifies the relationship among multiple elements. Any choice of allOf, exactlyOneOf, or OneOrMoreOf would provide the same result semantically. Therefore, in case of a single element in a Structured Data Information Element, the default "undefined" semantic SHOULD be used.
構造化データ情報要素内の単一の要素の特定の場合において、意味領域が実際には複数の要素間の関係を指定するために非常に有用ではないことに留意されたいです。 ALLOF、exactlyOneOf、またはOneOrMoreOfのいずれかの選択は、意味的に同じ結果を提供するであろう。したがって、構造化データ情報要素内の単一の要素の場合には、デフォルトではセマンティックを使用しなければならない「未定義しました」。
This section introduces some more specific Template management and Template Withdrawal Message-related specifications compared to the IPFIX protocol specification [RFC5101].
このセクションでは、IPFIXプロトコル仕様[RFC5101]と比較していくつかのより具体的なテンプレート管理及びテンプレート離脱メッセージ関連の仕様を導入します。
First of all, the Template ID uniqueness is unchanged compared to [RFC5101]; the uniqueness is local to the Transport Session and Observation Domain that generated the Template ID. In other words, the Set ID used to export the Template Record does not influence the Template ID uniqueness.
まず、テンプレートIDの一意性は、[RFC5101]に比べて不変です。ユニークさは、テンプレートIDを生成交通セッションと観測ドメインにローカルです。言い換えれば、セットIDは、テンプレートIDの一意性に影響を与えないテンプレートレコードをエクスポートするために使用しました。
While [RFC5101] mentions that "if an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process", this rule MAY be ignored within Structured Data Information Elements.
[RFC5101]は「情報要素は、テンプレート内で複数回必要な場合は、この情報要素の異なる発生が計量プロセスによるそれらの治療の論理的な順序に従うべきである」と述べている間、この規則は、構造化データの情報の中に無視されるかもしれません要素。
As specified in [RFC5101], Templates that are not used anymore SHOULD be deleted. Deleting a Template implies that it MUST NOT be used within subTemplateList and subTemplateMultiList anymore. Before reusing a Template ID, the Template MUST be deleted. In order to delete an allocated Template, the Template is withdrawn through the use of a Template Withdrawal Message.
[RFC5101]で指定されるように、もはや使用されていないテンプレートは削除されるべきです。テンプレートを削除すると、それはもうsubTemplateListとsubTemplateMultiList内で使用してはならないことを意味します。テンプレートIDを再利用する前に、テンプレートを削除する必要があります。割り当てられたテンプレートを削除するために、テンプレートは、テンプレート無効化メッセージの使用を介して引き出されます。
This section introduces some more specific specifications to the Collection Process compared to Section 9 in the IPFIX protocol [RFC5101].
このセクションでは、IPFIXプロトコル[RFC5101]セクション9と比較して収集プロセスにいくつかのより具体的な仕様を導入します。
As opposed to the IPFIX specification in [RFC5101], IPFIX Messages with IPFIX Structured Data Information Elements change the IPFIX concept from the Collector's point of view as the data types are present in the Data Records rather than in the Template Records. For example, a basicList Information Element in a Template Record doesn't specify the list element data type; this information is contained in the Data Record. For example, in case of a subTemplateMultiList, the Collecting Process must refer to the included Template Records in the middle of the Data Record decode.
[RFC5101]でIPFIX仕様とは対照的に、データ型がデータレコードではなく、テンプレートレコードに存在しているとして、IPFIX構造化データの情報要素とIPFIXメッセージは、ビューのコレクターズ・ポイントからIPFIXのコンセプトを変更します。例えば、テンプレートレコードでbasicList情報要素は、リストの要素のデータ型を指定しません。この情報は、データレコードに含まれています。例えば、subTemplateMultiListの場合には、収集プロセスは、データレコードデコードの中央に含まれるテンプレートレコードを参照しなければなりません。
As described in [RFC5101], a Collecting Process MUST note the Information Element identifier of any Information Element that it does not understand and MAY discard that Information Element from the Flow Record. Therefore, a Collection Process that does not support the extension specified in this document can ignore the Structured Data Information Elements in a Data Record, or it can ignore Data Records containing these new Structured Data Information Elements while continuing to process other Data Records.
[RFC5101]で説明したように、収集プロセスは、それが理解していないことをすべての情報要素の情報要素識別子を注意しなければならなくて、フローレコードからその情報要素を捨てるかもしれ。そのため、この文書で指定された拡張子をサポートしていないコレクションのプロセスは、データレコード内の構造化データの情報要素を無視することができ、またはそれは他のデータレコードを処理するために継続しながら、これらの新しい構造化データの情報要素を含むデータレコードを無視することができます。
If the structured data contains the "undefined" structured data type semantic, the Collecting Process MAY attempt to draw its own conclusion in terms of the semantic contained in the Data Record.
構造化データは、セマンティック「未定義」構造化データ・タイプが含まれている場合は、収集プロセスは、データレコードに含まれるセマンティックの観点から、独自の結論を引き出すしようとすることができます。
8. Defining New Information Elements Based on the New Abstract Data Types
新しい抽象データ型に基づいて8の定義新しい情報要素
This document specifies three new abstract data types: basicList, subTemplateList, and subTemplateMultiList. As specified in [RFC5102], the specification of new IPFIX Information Elements uses the Template specified in Section 2.1 of [RFC5102]. This Template mentioned existing and future the data types: "One of the types listed in Section 3.1 of this document or in a future extension of the information model". So new Information Elements can be specified based on the three new abstract data types.
basicList、subTemplateList、およびsubTemplateMultiList：この文書は、3つの新しい抽象データ型を指定します。 [RFC5102]で指定されているように、新しいIPFIX情報要素の仕様は、[RFC5102]のセクション2.1で指定されたテンプレートを使用しています。 「このドキュメントのセクション3.1か情報モデルの今後の拡大に記載されているタイプの一つ」：このテンプレートは、既存および将来のデータ型を述べました。だから、新しい情報要素は3つの新しい抽象データ型に基づいて指定することができます。
The authors anticipate the creation of both enterprise-specific and IANA Information Elements based on the IPFIX structured data types. For example, bgpPathList, bgpSequenceList, and bgpSetList, of abstract types and semantics basicList/ordered, basicList/ordered, and basicList/exactlyOneOf respectively, would define the complete semantic of the list. This specification doesn't specify any new Information Elements beyond the ones in Section 4.3.
著者は、IPFIX構造化データの種類に基づいて、企業固有およびIANA情報要素の両方の作成を期待しています。例えば、bgpPathList、bgpSequenceList、およびbgpSetList、抽象型およびセマンティクスのbasicList /はそれぞれbasicList /が発注し、発注、およびbasicList / exactlyOneOfは、リストの完全なセマンティックを定義します。この仕様は、4.3節でものを越えた新たな情報要素が指定されていません。
The following examples are created solely for the purpose of illustrating how the extensions proposed in this document are encoded.
以下の実施例は、この文書で提案されている拡張子のエンコード方法を説明する目的のためだけに作成されます。
Consider encoding a multicast Data Record containing the following data:
次のデータを含むマルチキャストデータレコードをコード考えてみましょう：
---------------------------------------------------------------
Ingress If | Source IP | Destination IP | Egress Interfaces
---------------------------------------------------------------
9 192.0.2.201 233.252.0.1 1, 4, 8
---------------------------------------------------------------
Template Record for the multicast Flows, with the Template ID 256:
テンプレートID 256とのマルチキャストフローのためのテンプレートレコード、：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 24 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ingressInterface = 10 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| DestinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| basicList = 291 | Field Length = 0xFFFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Encoding basicList, Template Record
図11：エンコーディングbasicList、テンプレートレコード
The list of outgoing interfaces is represented as a basicList with semantic allOf, and the Length of the list is chosen to be encoded in three bytes even though it may be less than 255 octets.
発信インターフェイスのリストは、セマンティックALLOFとbasicListとして表され、リストの長さ未満で255個のオクテットであっても3バイトで符号化されるように選択されます。
The Data Set is represented as follows:
次のようにデータセットが表現されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingressInterface = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv4Address = 192.0.2.201 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DestinationIPv4Address = 233.252.0.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | List Length = 17 | semantic=allOf|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface FieldId = 14 |egressInterface Field Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface value 1 = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface value 2 = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface value 3 = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Encoding basicList, Data Record, Semantic allOf
図12：エンコードbasicList、データレコード、セマンティックALLOF
In the example above, the basicList contains fixed-length elements. To illustrate how variable-length elements would be encoded, the same example is shown below with variable-length interface names in the basicList instead:
上記の例では、basicListは、固定長の要素を含みます。可変長要素を符号化する方法を説明するために、同じ例が代わりbasicListに可変長のインターフェース名で以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingressInterface = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv4Address = 192.0.2.201 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DestinationIPv4Address = 233.252.0.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | List Length = 25 | semantic=allOf|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| InterfaceName FieldId = 82 | InterfaceName Field Len=0xFFFF|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 5 | 'F' | 'E' | '0' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| '/' | '0' | Length = 7 | 'F' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'E' | '1' | '0' | '/' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| '1' | '0' | Length = 5 | 'F' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'E' | '2' | '/' | '2' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Encoding basicList, Data Record with Variable-Length Elements, Semantic allOf
図13：エンコードbasicList可変長要素を有するデータレコード、セマンティックALLOF
Consider encoding a load-balanced Data Record containing the following data:
次のデータを含む負荷分散されたデータレコードをコード考えてみましょう：
---------------------------------------------------------------
Ingress If | Source IP | Destination IP | Egress Interfaces
---------------------------------------------------------------
9 192.0.2.201 233.252.0.1 1, 4, 8
---------------------------------------------------------------
So the Data Record egressed from either interface 1, 4, or 8. The Data Set is represented as follows:
そうデータレコードは、次のようにデータ・セットが示されているインタフェース1、4、または8のいずれかからegressed。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingressInterface = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv4Address = 192.0.2.201 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DestinationIPv4Address = 233.252.0.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | List Length = 17 |sem=exactlyOne |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface FieldId = 14 |egressInterface Field Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface value 1 = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface value 2 = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egressInterface value 3 = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: sem=exactlyOne represents semantic=exactlyOneOf
注意：SEM = exactlyOneはセマンティック= exactlyOneOfを表し
Figure 14: Encoding basicList, Data Record, Semantic exactlyOneOf
図14：エンコードbasicList、データレコード、セマンティックexactlyOneOf
As explained in Section 2.2, multiple pairs of (observationTimeMicroseconds, digestHashValue) must be collected from two different Observation Points to passively compute the one-way delay across the network. This data can be exported with an optimized Data Record that consists of the following attributes:
2.2節で説明したように、（observationTimeMicroseconds、digestHashValue）の複数対が受動的にネットワークを介して一方向遅延を計算するために、2つの異なる観測ポイントから収集されなければなりません。このデータは、以下の属性で構成されて最適化されたデータレコードをエクスポートすることができます。
5-tuple
{ observationTimeMicroseconds 1, digestHashValue 1 }
{ observationTimeMicroseconds 2, digestHashValue 2 }
{ observationTimeMicroseconds 3, digestHashValue 3 }
{ ... , ... }
A subTemplateList is best suited for exporting the list of (observationTimeMicroseconds, digestHashValue). For illustration purposes, the number of elements in the list is 5; in practice, it could be more.
subTemplateListは（observationTimeMicroseconds、digestHashValue）のリストをエクスポートするのに最適です。例示の目的のために、リスト内の要素の数は5です。実際には、より多くの可能性があります。
------------------------------------------------------------------
srcIP | dstIP | src | dst |proto| one-way delay
| | Port | Port | | metrics
------------------------------------------------------------------
192.0.2.1 192.0.2.105 1025 80 6 Time1, 0x0x91230613
Time2, 0x0x91230650
Time3, 0x0x91230725
Time4, 0x0x91230844
Time5, 0x0x91230978
------------------------------------------------------------------
The following Template is defined for exporting the one-way delay metrics:
次のテンプレートは、一方向の遅延メトリックをエクスポートするために定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| observationTimeMicroSec=324 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| digestHashValue = 326 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Encoding subTemplateList, Template for One-Way Delay Metrics
図15：エンコードのsubTemplateList、テンプレートのワンウェイ遅延メトリック
The Template Record for the Optimized Data Record is as follows:
次のように最適化されたデータレコードのテンプレートレコードは、次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 32 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 258 | Field Count = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceTransportPort = 7 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationTransportPort= 11| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier = 4 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| subTemplateList = 292 | Field Length = 0xFFFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Encoding subTemplateList, Template Record
図16：エンコーディングsubTemplateList、テンプレートレコード
The list of (observationTimeMicroseconds, digestHashValue) is exported as a subTemplateList with semantic allOf. The Length of the subTemplateList is chosen to be encoded in three bytes even though it may be less than 255 octets.
（observationTimeMicroseconds、digestHashValue）のリストは、セマンティックALLOFとsubTemplateListとしてエクスポートされます。 subTemplateListの長さ未満で255個のオクテットであっても3バイトで符号化されるように選択されます。
The Data Record is represented as follows:
次のようにデータレコードが表されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 258 | Length = 83 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv4Address = 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIPv4Address = 192.0.2.105 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceTransportPort = 1025 | destinationTransportPort = 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol = 6 | 255 | one-way metrics list len = 63 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| semantic=allOf| TemplateID = 257 | TimeValue1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octets 2-5 of TimeValue1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octets 6-8 of TimeValue1 |digestHashVal1=|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 0x0x91230613 | TimeValue2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octets 2-5 of TimeValue2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octets 6-8 of TimeValue2 |digestHashVal2=|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 0x0x91230650 | TimeValue3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octets 2-5 of TimeValue3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octets 6-8 of TimeValue3 |digestHashVal3=|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 0x0x91230725 | TimeValue4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octets 2-5 of TimeValue4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octets 6-8 of TimeValue4 |digestHashVal4=|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 0x0x91230844 | TimeValue5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octets 2-5 of TimeValue5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octets 6-8 of TimeValue5 |digestHashVal5=|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 0x0x91230978 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Encoding subTemplateList, Data Set
図17：エンコードsubTemplateList、データセット
As explained in Section 4.5.3, a subTemplateMultiList is used to export a list of mixed-type content where each top-level element corresponds to a different Template Record.
セクション4.5.3で説明したように、subTemplateMultiListは、各トップレベル要素が別のテンプレートレコードに対応する混合型コンテンツのリストをエクスポートするために使用されます。
To illustrate this, consider the Data Record with the following attributes:
これを説明するために、次の属性を持つデータレコードを考慮してください。
5-tuple (Flow Keys), octetCount, packetCount
attributes for filtering
selectorId,
selectorAlgorithm
attributes for sampling
selectorId,
selectorAlgorithm,
samplingPacketInterval,
samplingPacketSpace
This example demonstrates that the Selector Report Interpretation [RFC5476] can be encoded with the subTemplateMultiList. More specifically, the example describes Property Match Filtering Selector Report Interpretation [RFC5476] used for filtering purposes, and the Systemic Count-Based Sampling as described in Section 6.5.2.1 of [RFC5476]. Some traffic will be filtered according to match properties configured, some will be sampled, some will be filtered and sampled, and some will not be filtered or sampled.
この例では、セレクターレポートの解釈[RFC5476]はsubTemplateMultiListでエンコードすることができることを実証します。 [RFC5476]のセクション6.5.2.1に記載されるように、より具体的には、例えば、フィルタリングのために使用されるプロパティマッチフィルタリングセレクタ報告解釈[RFC5476]、および全身カウントベースのサンプリングを記載します。一部のトラフィックは、特性がいくつか一部を濾過し、サンプリングされ、サンプリングされ、一部は、濾過又はサンプリングされなくなり、構成一致に従ってフィルタリングされます。
A subTemplateMultiList is best suited for exporting this variable data. A Template is defined for filtering attributes and another Template is defined for sampling attributes. A Data Record can contain data corresponding to either of the Templates, both of them, or neither of them.
subTemplateMultiListは、この変数のデータをエクスポートするのに最適です。テンプレートには、フィルタリングの属性のために定義され、別のテンプレートは、サンプリング属性のために定義されています。データレコードは、テンプレートのいずれかに該当するデータを、それらの両方、またはそれらのどちらを含めることができます。
Consider the example below where the following Data Record contains both filtering and sampling attributes.
以下のデータレコードは、フィルタリングとサンプリング属性の両方を含む場合、以下の例を考えてみましょう。
Key attributes of the Data Record:
データレコードのキー属性：
------------------------------------------------------------------
srcIP | dstIP | src | dst | proto | octetCount | packet
| | Port | Port | | | Count
------------------------------------------------------------------
2001:DB8::1 2001:DB8::2 1025 80 6 108000 120
------------------------------------------------------------------
Filtering attributes:
フィルタリング属性：
-------------------------------------------
selectorId | selectorAlgorithm
-------------------------------------------
100 5 (Property Match Filtering)
-------------------------------------------
Sampling attributes:
サンプリング属性：
For Systemic Count-Based Sampling as defined in Section 6.5.2.1 of [RFC5476] the required algorithm-specific Information Elements are:
全身カウントベースのサンプリングのために[RFC5476]に必要なアルゴリズム固有の情報要素のセクション6.5.2.1で定義されたとおりです。
samplingPacketInterval: number of packets selected in a row
samplingPacketSpace: number of packets between selections
Example of a simple 1-out-of-100 systematic count-based Selector definition, where the samplingPacketInterval is 1 and the samplingPacketSpace is 99.
samplingPacketIntervalが1であるとsamplingPacketSpaceが99である、単純な1アウト・オブ・100系統的な数ベースのセレクタの定義、例。
--------------------------------------------------------------
selectorId | selectorAlgorithm | sampling | sampling
| | Packet | Packet
| | Interval | Space
--------------------------------------------------------------
15 1 (Count-Based Sampling) 1 99
--------------------------------------------------------------
To represent the Data Record, the following Template Records are defined:
データレコードを表現するには、以下のテンプレートレコードが定義されています。
Template for filtering attributes: 259
Template for sampling attributes: 260
Template for Flow Record: 261
Flow record (261)
| (sourceIPv6Address)
| (destinationIPv6Address)
| (sourceTransportPort)
| (destinationTransportPort)
| (protocolIdentifier)
| (octetTotalCount)
| (packetTotalCount)
|
+------ filtering attributes (259)
| (selectorId)
| (selectorAlgorithm)
|
+------ sampling attributes (260)
| (selectorId)
| (selectorAlgorithm)
| (samplingPacketInterval)
| (samplingPacketSpace)
The following Template Record is defined for filtering attributes:
以下のテンプレートレコードは、属性をフィルタリングするために定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 259 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| selectorId = 302 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| selectorAlgorithm = 304 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Encoding subTemplateMultiList, Template for Filtering Attributes
図18：subTemplateMultiListエンコーディング、フィルタリングのためのテンプレート属性
The Template for sampling attributes is defined as follows:
次のようにサンプリング属性のテンプレートが定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 260 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| selectorId = 302 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| selectorAlgorithm = 304 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| samplingPacketInterval = 305| Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| samplingPacketSpace = 306 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Encoding subTemplateMultiList, Template for Sampling Attributes
図19：subTemplateMultiListエンコーディング、サンプリングのためのテンプレート属性
Note that while selectorAlgorithm is defined as unsigned16, and samplingPacketInterval and samplingPacketSpace are defined as unsigned32, they are compressed down to 1 octet here as allowed by Reduced Size Encoding in Section 6.2 of the IPFIX protocol specifications [RFC5101].
selectorAlgorithmはUNSIGNED16として定義され、そしてsamplingPacketIntervalとsamplingPacketSpaceがUnsigned32のように定義されている間IPFIXプロトコル仕様[RFC5101]のセクション6.2で縮小サイズの符号化によって許可されるように、それらはここでは1つのオクテットに圧縮されることに留意されたいです。
Template for the Flow Record is defined as shown below:
以下に示すようにフローレコードのテンプレートが定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 261 | Field Count = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv6Address = 27 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv6Address = 28 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceTransportPort = 7 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationTransportPort=11 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier = 4 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetTotalCount = 85 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetTotalCount = 86 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| subTemplateMultiList = 293 | Field Length = 0XFFFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Encoding subTemplateMultiList, Template for Flow Record
図20：フローレコードのエンコードsubTemplateMultiList、テンプレート
A subTemplateMultiList with semantic allOf is used to export the filtering and sampling attributes. The Length field of the subTemplateMultiList is chosen to be encoded in three bytes even though it may be less than 255 octets.
セマンティックALLOFとsubTemplateMultiListは、フィルタリングおよびサンプリングの属性をエクスポートするために使用されます。 subTemplateMultiListのLengthフィールドは、それ未満255個のオクテットであっても3バイトで符号化されるように選択されます。
The Data Record is encoded as follows:
次のようにデータレコードは、符号化されています：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 261 | Length = 73 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv6Address = ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2001:DB8::1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIPv6Address = ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2001:DB8::2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceTransportPort = 1025 | destinationTransportPort = 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol = 6 | octetTotalCount = 108000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | packetTotalCount = 120 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | 255 | Attributes List Length = 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|semantic=allOf | Filtering Template ID = 259 |Filtering Attr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Length = 9 | selectorId = ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 100 |selectorAlg = 5| Sampling Template ID = 260 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sampling Attributes Length=11 | selectorId = ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 15 |selectorAlg = 1| Interval = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Space = 99 |
+-+-+-+-+-+-+-+-+
Figure 21: Encoding subTemplateMultiList, Data Set
図21：エンコードsubTemplateMultiList、データセット
As described in Section 5.3, consider a mediation function that must aggregate Data Records from different Observation Points.
5.3節で述べたように、異なる観測点からのデータレコードを集約しなければならない調停機能を検討してください。
Say Observation Point 1 consists of one or more interfaces, Observation Points 2 and 3 consist of one or more linecards, and Observation Point 4 consists of one or more interfaces and one or more linecards. Without structured data, a Template would have to be defined for every possible combination to interpret the data corresponding to each of the Observation Points. However, with structured data, a basicList can be used to encode the list of interfaces and another basicList can be used to encode the list of linecards.
観測ポイント1は、1つ以上のインターフェースで構成され言う、観測点2及び3は、一つ以上のラインカードから成り、観測点4は、1つまたは複数のインターフェースと1つ以上のラインカードから成ります。構造化データがないと、テンプレートは、観測点のそれぞれに対応したデータを解釈するためにあらゆる可能な組み合わせのために定義しなければならないであろう。しかしながら、構造化データと、basicListは、インターフェイスのリストを符号化するために使用することができ、別のbasicListは、ラインカードのリストを符号化するために使用することができます。
For the sake of simplicity, each Observation Point shown below has the IP address corresponding to the Router and an <interface> or <linecard> or <linecard and interface>. This can very well be extended to include a list of interfaces and a list of linecards using basicLists as explained above.
簡略化のため、以下に示す各観測点は、ルータと<インターフェース>または<ラインカード>又は<ラインカードとインターフェイス>に対応するIPアドレスを有しています。これは非常によく上で説明したようにインターフェースのリストとbasicListsを使用してラインカードのリストを含むように拡張することができます。
Observation Point 1: Router 1, (interface 1) Observation Point 2: Router 2, (linecard A) Observation Point 3: Router 3, (linecard B) Observation Point 4: Router 4, (linecard C, interface 2)
観測点1：ルータ1、（インターフェース1）観測点2：ルータ2、（ラインカードA）観測点3：ルータ3、（ラインカードB）の観測点4：ルータ4、（ラインカードC、インタフェース2）
The mediation function wishes to express this as a single Observation Point, in order to encode the PSAMP Selection Sequence Report Interpretation (SSRI). Recall from [RFC5476] that the PSAMP Selection Sequence Report Interpretation consists of the following fields:
調停関数はPSAMP選択シーケンスレポート解釈（SSRI）を符号化するために、1つの観測ポイントとしてこれを表現することを望みます。 [RFC5476]からリコールPSAMP選択シーケンスレポートの解釈は、次のフィールドで構成されていること：
Scope: selectionSequenceId Non-Scope: one Information Element mapping the Observation Point selectorId (one or more)
スコープ：selectionSequenceId非対象範囲：1情報要素の観測ポイントselectorId（1以上）をマッピング
For example, the Observation Point detailed above may be encoded in a PSAMP Selection Sequence Report Interpretation as shown below:
以下に示すように、例えば、上記の詳細観察ポイントPSAMP選択シーケンス報告の解釈で符号化されてもよいです。
Selection Sequence 7 (Filter->Sampling): Observation Point: subTemplateMultiList. Router 1 (IP address = 192.0.2.11), (interface 1) Router 2 (IP address = 192.0.2.12), (linecard A) Router 3 (IP address = 192.0.2.13), (linecard B) Router 4 (IP address = 192.0.2.14), (linecard C, interface 2) selectorId: 5 (Filter, match IPv4SourceAddress 192.0.2.1) selectorId: 10 (Sampler, Random 1 out-of ten)
選択順序7（フィルタ - >サンプリング）：観察ポイント：subTemplateMultiList。ルータ1（IPアドレス= 192.0.2.11）、（インターフェース1）ルータ2（IPアドレス= 192.0.2.12）、（ラインカードA）ルータ3（IPアドレス= 192.0.2.13）、（ラインカードB）ルータ4（IPアドレス= 192.0.2.14）、（ラインカードC、インタフェース2）selectorId：5（フィルタ、一致IPv4SourceAddress 192.0.2.1）selectorId：10（サンプラー、ランダム1アウトオブ10）
The following Templates are defined to represent the PSAMP SSRI: Template for representing PSAMP SSRI: 262 Template for representing interface: 263 Template for representing linecard: 264 Template for representing linecard and interface: 265
以下のテンプレートはPSAMP SSRIを表すように定義される：PSAMP SSRIを表すテンプレート：インタフェースを表す262テンプレート：ラインカードを表す263テンプレート：ラインカードとのインターフェイスを表す264テンプレート：265
PSAMP SSRI (262)
| (SelectionSequenceId)
|
+--- Observation Point 1 (263)
| (exporterIPv4Address)
| (Interface Id)
|
+--- Observation Point 2 and 3 (264)
| (exporterIPv4Address)
| (linecard)
|
+--- Observation Point 4 (265)
| (exporterIPv4Address)
| (linecard)
| (Interface Id)
|
| (selectorId 1)
| (selectorId 2)
Note that the example could further be improved with a basicList of selectorId if many Selector IDs have to be reported.
多くのセレクタIDを報告する必要がある場合などは、さらにselectorIdのbasicListで改善することができることに注意してください。
Figure 22: PSAMP SSRI to Be Encoded
図22：エンコードされるPSAMP SSRI
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 262 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| selectionSequenceId = 301 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Length = 4 |0| subTemplateMultiList = 293 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 0xFFFF |0| selectorId = 302 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| selectorId = 302 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Options Template Record for PSAMP SSRI Using
subTemplateMultiList
A subTemplateMultiList with semantic allOf is used to encode the list of Observation Points.
セマンティックALLOFとsubTemplateMultiListは、観測ポイントのリストをエンコードするために使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 263 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| exporterIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ingressInterface = 10 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: PSAMP SSRI, Template Record for interface
図24：PSAMP SSRI、インタフェースのためのテンプレートレコード
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 264 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| exporterIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| lineCardId = 141 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: PSAMP SSRI, Template Record for linecard
図25：PSAMP SSRI、ラインカード用テンプレートレコード
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 265 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| exporterIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| lineCardId = 141 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ingressInterface = 10 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: PSAMP SSRI, Template Record for linecard and interface
図26：PSAMP SSRI、ラインカードとインターフェイスするためのテンプレートレコード
The PSAMP SSRI Data Set is represented as follows:
次のようにPSAMP SSRIデータセットが表現されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 262 | Length = 68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| selectionSequenceId = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | Observation Point List Len=49 |semantic=allOf |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP1 Template ID = 263 | OP1 Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router 1 exporterIPv4Address = 192.0.2.11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP1 ingressInterface = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP2&OP3 Template ID = 264 | OP2 & OP3 Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router 2 exporterIPv4Address = 192.0.2.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP2 lineCardId = A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router 3 exporterIPv4Address = 192.0.2.13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP3 lineCardId = B |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP4 Template ID = 265 | OP4 Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router 4 exporterIPv4Address = 192.0.2.14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP4 lineCardId = C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP4 ingressInterface = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| selectorId = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| selectorId = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Example of a PSAMP SSRI Data Record, Encoded Using a subTemplateMultiList
図27：PSAMP SSRIデータレコードの例、subTemplateMultiListを使用してエンコード
Note that the Data Record above contains multiple instances of Template 264 to represent Observation Point 2 (Router2, linecard A) and Observation Point 3 (Router3, linecard B). Instead, if a single Observation Point had both linecard A and linecard B, a basicList would be used to represent the list of linecards.
データレコードは、上記観測点2（ルータ2、ラインカードA）と観測点3（Router3、ラインカードB）を表現するためにテンプレート264の複数のインスタンスを含んでいることに留意されたいです。単一の観測点は、ラインカードAとラインカードBの両方を持っていた場合は代わりに、basicListは、ラインカードのリストを表すために使用されるだろう。
"Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information Export (IPFIX) protocol.
「IPフロー情報のエクスポート（IPFIX）とパケットサンプリングに冗長性を削減する（PSAMP）レポート」[RFC5473]はIPフロー情報のエクスポート（IPFIX）プロトコルを使用してフローまたはパケット情報をエクスポートするための帯域幅の節約方法を説明します。
It defines the commonPropertiesID Information Element for exporting Common Properties.
それは共通プロパティをエクスポートするためcommonPropertiesID情報要素を定義します。
When Structured Data Information Elements contain repeated elements, these elements may be replaced with a commonPropertiesID Information Element as specified in [RFC5473]. The replaced elements may include the basicList, subTemplateList, and subTemplateMultiList Information Elements.
構造化データ情報要素を繰り返し要素を含む場合、[RFC5473]で指定されるように、これらの要素はcommonPropertiesID情報要素で置き換えることができます。置換要素はbasicList、subTemplateList、およびsubTemplateMultiList情報要素を含むことができます。
This technique might help reducing the bandwidth requirements for the export. However, a detailed analysis of the gain has not been done; refer to Section 8.3 of [RFC5473] for further considerations.
この技術は、輸出のための帯域幅要件を削減に役立つかもしれません。しかし、ゲインの詳細な分析が行われていません。さらに考慮事項については、[RFC5473]のセクション8.3を参照してください。
10.1.2. Encoding Common Properties Elements with Structured Data Information Element
10.1.2. 構造化データ情報要素と共通プロパティの要素をコードします
Structured Data Information Element MAY be used to define a list of commonPropertiesID, as a replacement for the specifications in [RFC5473].
構造化データ情報要素は、[RFC5473]で仕様の代替として、commonPropertiesIDのリストを定義するために使用されるかもしれません。
Indeed, the example in Figures 1 and 2 of [RFC5473] can be encoded with the specifications in this document.
実際、図1及び[RFC5473]の2の例では、この文書に記載されている仕様に符号化することができます。
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow1 information> |
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow2 information> |
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow3 information> |
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow4 information> |
+----------------+-------------+---------------------------+
| ... | ... | ... |
+----------------+-------------+---------------------------+
Figure 28: Common and Specific Properties Exported Together [RFC5473]
図28：コモン、特定のプロパティをまとめてエクスポート[RFC5473]
+------------------------+-----------------+-------------+
| index for properties A | sourceAddressA | sourcePortA |
+------------------------+-----------------+-------------+
| ... | ... | ... |
+------------------------+-----------------+-------------+
+------------------------+---------------------------+
| index for properties A | <Flow1 information> |
+------------------------+---------------------------+
| index for properties A | <Flow2 information> |
+------------------------+---------------------------+
| index for properties A | <Flow3 information> |
+------------------------+---------------------------+
| index for properties A | <Flow4 information> |
+------------------------+---------------------------+
Figure 29: Common and Specific Properties Exported Separately According to [RFC5473]
図29：[RFC5473]によると、これとは別にエクスポートコモン、特定のプロパティ
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow1 information> |
+----------------+-------------+---------------------------+
| <Flow2 information> |
+---------------------------+
| <Flow3 information> |
+---------------------------+
| <Flow4 information> |
+---------------------------+
| ... |
+---------------------------+
Figure 30: Common and Specific Properties Exported with Structured Data Information Element
図30：構造化データ情報要素でエクスポートコモン、特定のプロパティ
The example in Figure 28 could be encoded with a basicList if the <Flow information> represents a single Information Element, with a subTemplateList if the <Flow information> represents a Template Record, or with a subTemplateMultiList if the <Flow information> is composed of different Template Records.
場合<情報の流れ>場合は、図28の例では、basicListで符号化することができるsubTemplateListと、単一の情報要素を表す<情報フロー>テンプレートレコード、または<情報の流れ>場合subTemplateMultiListとから構成さを表します別のテンプレートレコード。
Using Structured Data Information Elements as a replacement for the techniques specified in "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] offers the advantage that a single Template Record is defined. Hence, the Collector's job is simplified in terms of Template management and combining Template/Options Template Records.
「IPフロー情報のエクスポート（IPFIX）とパケットサンプリング（PSAMP）レポートでの冗長性を削減する」で指定された技術の代わりとして構造化データの情報要素を使用して、[RFC5473]は、単一のテンプレートレコードが定義されるという利点を提供しています。したがって、コレクターの仕事は、テンプレート管理およびテンプレート/オプションテンプレートレコードを結合するという点で簡略化されています。
However, it must be noted that using Structured Data Information Elements as a replacement for the techniques specified in "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" only applies to simplified cases. For example, the "Multiple Data Reduction" (Section 7.1 [RFC5473]) might be too complex to encode with Structured Data Information Elements.
しかし、それだけで単純化の場合に適用される「（PSAMP）レポートは、IPフロー情報のエクスポート（IPFIX）とパケットサンプリングに冗長性を削減する」で指定された技術の代替としてのデータ情報要素を構造化使用してことに注意しなければなりません。例えば、「複数のデータ削減」（セクション7.1 [RFC5473]）は、構造化データの情報要素をエンコードするには複雑すぎるかもしれません。
[RFC5471] presents a list of tests for implementers of IP Flow Information Export (IPFIX) compliant Exporting Processes and Collecting Processes.
[RFC5471]はIPフロー情報のエクスポート（IPFIX）準拠のエクスポートプロセスと収集プロセスの実装のためのテストのリストを提示します。
Although [RFC5471] doesn't define any structured data element specific tests, the Structured Data Information Elements can be used in many of the [RFC5471] tests.
[RFC5471]は、任意の構造化されたデータ要素の特定のテストを定義していないが、構造化データの情報要素は[RFC5471]の試験の多くで使用することができます。
The [RFC5471] series of test could be useful because the document specifies that every Information Element type should be tested. However, not all cases from this document are tested in [RFC5471].
文書は、すべての情報要素の種類をテストする必要があることを指定しているため、テストの[RFC5471]シリーズは役に立つかもしれません。しかし、このドキュメントのすべての場合は、[RFC5471]でテストされていません。
The following sections are especially noteworthy:
次のセクションでは、特に注目に値するのとおりです。
3.2.1. Transmission of Template with Fixed-Size Information Elements
3.2.1. 固定サイズの情報要素とテンプレートの送信
- each data type should be used in at least one test. The new data types specified in Section 4.1 should be included in this test.
- 各データ・タイプは、少なくとも1つの試験に使用されるべきです。 4.1節で指定された新しいデータ型は、この試験に含まれるべきです。
3.2.2. Transmission of Template with Variable-Length Information Elements
3.2.2. 可変長情報要素とテンプレートの送信
- this test should be expanded to include Data Records containing variable length basicList, subTemplateList, and subTemplateMultiList Information Elements.
- このテストは、可変長basicList、subTemplateList、およびsubTemplateMultiList情報要素を含むデータレコードを含むように拡張されなければなりません。
- this test should include the export of basicList, subTemplateList, and subTemplateMultiList Information Elements containing Enterprise-specific Information Elements, e.g., see the example in Figure 2.
- このテストは、エンタープライズ固有の情報要素を含むbasicList、subTemplateList、及びsubTemplateMultiList情報要素のエクスポートを含むべきで、例えば、図2の例を参照。
3.3.3. Multiple Instances of the Same Information Element in One Template
3.3.3. 一つのテンプレートで同じ情報要素の複数インスタンス
- this test should verify that multiple instances of the basicList, subTemplateList, and subTemplateMultiList Information Elements are accepted.
- このテストはbasicList、subTemplateList、およびsubTemplateMultiList情報要素の複数のインスタンスが受け入れられることを確認する必要があります。
- since the structured data types defined here allow modeling of complex data structures, they may be useful for stress testing both Exporting Processes and Collecting Processes.
- ここで定義された構造化データ型は複雑なデータ構造のモデリングを許可しているので、彼らは、エクスポートプロセスと収集プロセスの両方をストレステストのために有用である可能性があります。
The Structured Data Information Elements would be beneficial for the export of aggregated Data Records in mediation function, as was demonstrated with the example of the aggregated Observation Point in Section 5.3.
5.3節で集約された観測点の例で実証されたように構造化データの情報要素は、調停機能の集約されたデータレコードのエクスポートのために有益であろう。
This document specifies several new IPFIX abstract data types, a new IPFIX Data Type Semantic, and several new Information Elements.
この文書は、新しいIPFIXデータ型セマンティック、およびいくつかの新しい情報要素をいくつかの新しいIPFIXの抽象データ型を指定します。
Two new IPFIX registries have been created, and the existing IPFIX Information Element registry has been updated as detailed below.
二つの新しいIPFIXレジストリが作成されていること、および下記のとおり、既存のIPFIX情報エレメントレジストリが更新されました。
Section 4.1 of this document specifies several new IPFIX abstract data types. Per Section 6 of the IPFIX information model [RFC5102], new abstract data types can be added to the IPFIX information model in the IPFIX Information Element Data Types registry.
このドキュメントのセクション4.1には、いくつかの新しいIPFIXの抽象データ型を指定します。 IPFIX情報モデル[RFC5102]のセクション6ごとに、新しい抽象データ型はIPFIX情報エレメントのデータ型のレジストリ内のIPFIX情報モデルに追加することができます。
Abstract data types that have been added to the IPFIX Information Element Data Types registry are listed below.
IPFIX情報エレメントデータタイプレジストリに追加された抽象データ型は以下のとおりです。
The type "basicList" represents a list of any Information Element used for single-valued data types.
タイプ「basicListは、」単一値のデータ型のために使用されるすべての情報要素のリストを表します。
The type "subTemplateList" represents a list of a structured data type, where the data type of each list element is the same and corresponds with a single Template Record.
タイプ「subTemplateList」は、各リスト要素のデータ型が同じであり、単一のテンプレートレコードに対応する構造化データ型のリストを表します。
The type "subTemplateMultiList" represents a list of structured data types, where the data types of the list elements can be different and correspond with different Template definitions.
タイプ「subTemplateMultiList」はリスト要素のデータ型が異なっていてもよく、異なるテンプレート定義に対応することができる構造化データ・タイプのリストを表します。
Section 4.2 of this document specifies a new IPFIX Data Type Semantic. Per Section 3.2 of the IPFIX information model [RFC5102], new data type semantics can be added to the IPFIX information model. Therefore, the IANA IPFIX informationElementSemantics registry [IANA-IPFIX], which contains all the data type semantics from Section 3.2 of [RFC5102], has been augmented with the "list" value below.
このドキュメントのセクション4.2は新しいIPFIXデータ型のセマンティックを指定します。 IPFIX情報モデル[RFC5102]の3.2節ごとに、新しいデータ型のセマンティクスはIPFIX情報モデルに追加することができます。したがって、[RFC5102]のセクション3.2からのすべてのデータ型の意味が含まれているIANA IPFIX informationElementSemanticsレジストリ[IANA-IPFIX]は、以下の「リスト」値で増強されています。
A list is a structured data type, being composed of a sequence of elements, e.g., Information Element, Template Record.
リストには、例えば、要素の配列で構成されている構造化データ型、情報要素、テンプレートレコードです。
Section 4.3 of this document specifies several new Information Elements that have been created in the IPFIX Information Element registry [IANA-IPFIX].
このドキュメントのセクション4.3はIPFIX情報エレメントレジストリ[IANA-IPFIX]で作成されたいくつかの新しい情報要素を指定します。
New Information Elements that have been added to the IPFIX Information Element registry are listed below.
IPFIX情報エレメントレジストリに追加された新しい情報要素は以下のとおりです。
Name: basicList Description: Specifies a generic Information Element with a basicList abstract data type. Examples include a list of port numbers, and a list of interface indexes. Abstract Data Type: basicList Data Type Semantics: list ElementId: 291 Status: current
名前：basicList説明：basicList抽象データ型の一般的な情報要素を指定します。例としては、ポート番号のリスト、およびインターフェイスインデックスのリストが含まれています。抽象データ型：basicListデータ型の意味：リストELEMENTID：291状態：現在の
Name: subTemplateList Description: Specifies a generic Information Element with a subTemplateList abstract data type. Abstract Data Type: subTemplateList Data Type Semantics: list ElementId: 292 Status: current
名前：subTemplateList説明：subTemplateList抽象データ型の一般的な情報要素を指定します。抽象データ型：subTemplateListデータ型の意味：リストELEMENTID：292状態：現在の
Name: subTemplateMultiList Description: Specifies a generic Information Element with a subTemplateMultiList abstract data type. Abstract Data Type: subTemplateMultiList Data Type Semantics: list ElementId: 293 Status: current
名前：subTemplateMultiList説明：subTemplateMultiList抽象データ型の一般的な情報要素を指定します。抽象データ型：subTemplateMultiListデータ型の意味：リストELEMENTID：293状態：現在の
Section 4.4 of this document specifies a series of new IPFIX structured data type semantics, which is expressed as an 8-bit value. This requires the creation of a new "IPFIX Structured Data Types Semantics" IPFIX subregistry [IANA-IPFIX].
この文書のセクション4.4は8ビット値として表現される新たなIPFIX構造化データ型のセマンティクス、一連の指定します。これは、新しい「IPFIX構造化データ・タイプのセマンティクス」IPFIXの副登録[IANA-IPFIX]を作成する必要があります。
Entries may be added to this subregistry subject to a Standards Action [RFC5226]. Initially, this registry includes all the structured data type semantics listed below.
エントリは、標準アクション[RFC5226]この副登録対象に加えてもよいです。最初は、このレジストリは、下記の全ての構造化データ・タイプのセマンティクスが含まれています。
Name: undefined
名前：未定義
Description: The "undefined" structured data type semantic specifies that the semantic of list elements is not specified and that, if a semantic exists, then it is up to the Collecting Process to draw its own conclusions. The "undefined" structured data type semantic is the default structured data type semantic.
説明：セマンティックが存在する場合は、「未定義」構造化データ・タイプセマンティックリスト要素の意味が指定されていないことを指定すると、それは、それは、独自の結論を引き出すために収集プロセスまでです。 「未定義の」構造化データ型のセマンティックは、セマンティックデフォルトの構造化データ・タイプです。
Value: 0xFF
値：0xFFを
Reference: RFC 6313
参考：RFC 6313
Name: noneOf
名前：noneOf
Description: The "noneOf" structured data type semantic specifies that none of the elements are actual properties of the Data Record.
説明：要素のどれもがデータレコードの実際の性質ではない「noneOf」構造化データ型のセマンティックを指定します。
Value: 0x00
値：$ 00
Reference: RFC 6313
参考：RFC 6313
Name: exactlyOneOf
名前：exactlyOneOf
Description: The "exactlyOneOf" structured data type semantic specifies that only a single element from the structured data is an actual property of the Data Record. This is equivalent to a logical XOR operation.
説明：構造化データから、ただ一つの要素は、データレコードの実際の財産である「exactlyOneOf」構造化データ型のセマンティックを指定します。これは、論理XOR演算と等価です。
Value: 0x01
値：0x01の
Reference: RFC 6313
参考：RFC 6313
Name: oneOrMoreOf
名前：oneOrMoreOf
Description: The "oneOrMoreOf" structured data type semantic specifies that one or more elements from the list in the structured data are actual properties of the Data Record. This is equivalent to a logical OR operation.
説明：構造化データ内のリストから1つのまたは複数の要素がデータレコードの実際の性質であることを構造化データ・タイプ「oneOrMoreOf」セマンティックを指定します。これは、論理OR演算に相当します。
Value: 0x02
値：0x02の
Reference: RFC 6313
参考：RFC 6313
Name: allOf
名前：ALLOF
Description: The "allOf" structured data type semantic specifies that all of the list elements from the structured data are actual properties of the Data Record.
説明：構造化データからリストのすべての要素がデータレコードの実際のプロパティである「ALLOF」構造化データ型のセマンティックを指定します。
Value: 0x03
値：0x03の
Reference: RFC 6313
参考：RFC 6313
Name: ordered Description: The "ordered" structured data type semantic specifies that elements from the list in the structured data are ordered.
名前：発注内容：構造化データのリストからの要素が順序付けられている構造化データ・タイプセマンティック指定「を命じました」。
Value: 0x04
値：0x04を
Reference: RFC 6313
参考：RFC 6313
The addition of complex data types necessarily complicates the implementation of the Collector. This could easily result in new security vulnerabilities (e.g., buffer overflows); this creates additional risk in cases where either Datagram Transport Layer Security (DTLS) is not used or if the Observation Point and Collector belong to different trust domains. Otherwise, the same security considerations as for the IPFIX protocol [RFC5101] and the IPFIX information model [RFC5102] apply.
複雑なデータ型の追加は必ずしもコレクターの実装を複雑にしています。これは簡単に（例えば、バッファオーバーフロー）新たなセキュリティの脆弱性につながる可能性。これは、観測ポイントとコレクターが異なる信頼ドメインに属している場合はデータグラムトランスポート層セキュリティ（DTLS）を使用するかしないのいずれかの場合に追加的なリスクを作成します。そうでなければ、IPFIXプロトコル[RFC5101]とIPFIX情報モデル[RFC5102]と同じセキュリティ上の考慮事項が適用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B.、エド。、RFC 5101、2008年1月 "IPトラフィックフロー情報を交換するためのIPフロー情報のエクスポート（IPFIX）プロトコルの仕様"。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、ブライアント、S.、Claise、B.、エイトケン、P.、およびJ.マイヤー、 "IPフロー情報のエクスポートのための情報モデル"、RFC 5102、2008年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B.、およびS.ザンダー、 "IPフロー情報エクスポート（IPFIX）のための要件"、RFC 3917、2004年10月。
[RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008.
[RFC5103]トラメル、B.およびE.ボスキ、 "IPフロー情報のエクスポートを使用した双方向フローのエクスポート（IPFIX）"、RFC 5103、2008年1月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470] Sadasivan、G.、ブラウンリー、N.、Claise、B.、およびJ. Quittek、RFC 5470、2009年3月 "IPフロー情報のエクスポートのためのアーキテクチャ"。
[RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP Flow Information Export (IPFIX) Testing", RFC 5471, March 2009.
[RFC5471] Schmoll、C.、エイトケン、P.、およびB. Claise、RFC 5471、2009年3月 "IPフロー情報のエクスポート（IPFIX）テストのためのガイドライン"。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、ボスキ、E.、ブラウンリー、N.、およびB. Claise、 "IPフロー情報のエクスポート（IPFIX）の適用"、RFC 5472、2009年3月。
[RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009.
[RFC5473]ボスキ、E.、マーク、L.、およびB. Claise、RFC 5473、2009年3月 "IPフロー情報のエクスポート（IPFIX）とパケットサンプリング（PSAMP）レポートで冗長性を削減します"。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5475] Zseby、T.、モリーナ、M.、ダッフィールド、N.、ニッコリーニ、S.、およびF. Raspall、 "IPパケットの選択のためのサンプリングとフィルタリング技術"、RFC 5475、2009年3月。
[RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476] Claise、B.、編。、ジョンソン、A.、およびJ. Quittek、 "パケットサンプリング（PSAMP）プロトコル仕様"、RFC 5476、2009年3月。
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5477]ディーツ、T.、Claise、B.、エイトケン、P.、ドレスラー、F.、およびG.カール、RFC 5477 "情報モデルパケットサンプリングの輸出について"、2009年3月。
[IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <http://www.iana.org/>.
[IANA-IPFIX] IANA、 "IPフロー情報のエクスポート（IPFIX）エンティティ"、<http://www.iana.org/>。
The authors would like to thank Zhipu Jin, Nagaraj Varadharajan, Brian Trammel, Atsushi Kobayashi, and Rahul Patel for their feedback, and Gerhard Muenz, for proofreading the document.
著者は、文書を校正するために、Zhipuジン、Nagaraj Varadharajan、ブライアン・トランメル、敦小林、そして彼らのフィードバックのためラーフル・パテル、およびゲルハルトMuenzに感謝したいと思います。
Appendix A. Additions to XML Specification of IPFIX Information Elements and Abstract Data Types
IPFIX情報要素と抽象データ型のXML仕様の付録A.の追加
This appendix contains additions to the machine-readable description of the IPFIX information model coded in XML in Appendices A and B in [RFC5102]. Note that this appendix is of informational nature, while the text in Section 4 (generated from this appendix) is normative.
この付録では、[RFC5102]に付録AおよびBにXMLでコード化されたIPFIX情報モデルの機械可読記述に追加が含ま。 （この付録から生成された）第4節のテキストは規範的である一方で、この付録では、情報の性質のものであることに注意してください。
The following field definitions are appended to the IPFIX information model in Appendix A of [RFC5102].
次のフィールド定義は、[RFC5102]の付録AにIPFIX情報モデルに付加されています。
<field name="basicList" dataType="basicList" group="structured-data" dataTypeSemantics="List" elementId="291" applicability="all" status="current"> <description> <paragraph> Represents a list of zero or more instances of any Information Element, primarily used for single-valued data types. Examples include a list of port numbers, list of interface indexes, and a list of AS in a BGP AS-PATH. </paragraph> </description> </field>
<フィールド名= "basicList" データ型= "basicList" グループ= "構造化データ" dataTypeSemantics = "リスト" ELEMENTID = "291" の適用= "すべて" ステータス= "現在"> <description>は、<段落>のリストを表し主に単一値のデータ型のために使用される任意の情報要素のゼロ以上のインスタンス、。例としては、ポート番号のリスト、インタフェースインデックスのリスト、およびBGP AS-PATHでASのリストが含まれています。 </パラグラフ> </記述> </分野>
<field name="subTemplateList" dataType="subTemplateList" group="structured-data" dataTypeSemantics="List" elementId="292" applicability="all" status="current"> <description> <paragraph> Represents a list of zero or more instances of a structured data type, where the data type of each list element is the same and corresponds with a single Template Record. Examples include a structured data type composed of multiple pairs of ("MPLS label stack entry position", "MPLS label stack value"), a structured data type composed of performance metrics, and a structured data type composed of multiple pairs of IP address. </paragraph> </description> </field>
<フィールド名=「subTemplateList」データ型=「subTemplateList」グループ=「構造化データ」dataTypeSemantics =「リスト」ELEMENTID =「292」の適用=「すべて」ステータス=「現在」> <記述> <パラグラフ>は、のリストを表し各リスト要素のデータ型が同じであり、単一のテンプレートレコードに対応する構造化データ型のゼロ以上のインスタンス。例としては、（「MPLSラベルスタックエントリ位置」、「MPLSラベルスタック値」）、パフォーマンス・メトリックからなる構造化データ・タイプ、およびIPアドレスの複数の対からなる構造化データ型の複数の対からなる構造化データ・タイプを含みます。 </パラグラフ> </記述> </分野>
<field name="subTemplateMultiList" dataType="subTemplateMultiList" group="structured-data" dataTypeSemantics="List" elementId="293" applicability="all" status="current"> <description> <paragraph> Represents a list of zero or more instances of structured data types, where the data type of each list element can be different and corresponds with different Template definitions. Examples include, a structured data type composed of multiple access-list entries, where entries can be composed of different criteria types. </paragraph> </description> </field>
<フィールド名=「subTemplateMultiList」データ型=「subTemplateMultiList」グループ=「構造化データ」dataTypeSemantics =「リスト」ELEMENTID =「293」の適用=「すべて」ステータス=「現在」> <記述> <パラグラフ>は、のリストを表し各リスト要素のデータ型が異なると異なるテンプレート定義に対応することができる構造化データ型のゼロ以上のインスタンス。例には、エントリは異なる条件タイプで構成することができる複数のアクセス・リスト・エントリからなる構造化データ・タイプを含みます。 </パラグラフ> </記述> </分野>
The following structured data type semantic definitions are appended to the IPFIX information model in Appendix A of [RFC5102].
以下の構造化データ型の意味論的定義は[RFC5102]の付録AにIPFIX情報モデルに付加されています。
<structuredDataTypeSemantics> <structuredDataTypeSemantic name="undefined" value="255"> <description> <paragraph> The "undefined" structured data type semantic specifies that the semantic of list elements is not specified and that, if a semantic exists, then it is up to the Collecting Process to draw its own conclusions. The "undefined" structured data type semantic is the default structured data type semantic. </paragraph> </description> </structuredDataTypeSemantic>
<structuredDataTypeSemantics> <structuredDataTypeSemantic名=「未定義」値=「255」> <記述> <パラグラフ>「未定義の」構造化データ型のセマンティックは、セマンティックが存在する場合は、リストの要素の意味は、それが、その後、指定し、そのされていないことを指定します独自の結論を引き出すために収集プロセスまでです。 「未定義の」構造化データ型のセマンティックは、セマンティックデフォルトの構造化データ・タイプです。 </パラグラフ> </記述> </ structuredDataTypeSemantic>
<structuredDataTypeSemantic name="noneOf" value="0"> <description> <paragraph> The "noneOf" structured data type semantic specifies that none of the elements are actual properties of the Data Record. </paragraph> </description> </structuredDataTypeSemantic>
<structuredDataTypeSemantic名=「noneOf」値=「0」> <記述> <パラグラフ>要素のいずれもデータレコードの実際の特性ではない「noneOf」構造化データ型セマンティック指定。 </パラグラフ> </記述> </ structuredDataTypeSemantic>
<structuredDataTypeSemantic name="exactlyOneOf" value="1"> <description> <paragraph> The "exactlyOneOf" structured data type semantic specifies that only a single element from the structured data is an actual property of the Data Record. This is equivalent to a logical XOR operation. </paragraph> </description> </structuredDataTypeSemantic>
構造化されたデータから単一の要素がデータレコードの実際の特性である<structuredDataTypeSemantic名=「exactlyOneOf」値=「1」> <記述> <パラグラフ>「exactlyOneOf」構造化データ型セマンティック指定。これは、論理XOR演算と等価です。 </パラグラフ> </記述> </ structuredDataTypeSemantic>
<structuredDataTypeSemantic name="oneOrMoreOf" value="2"> <description> <paragraph> The "oneOrMoreOf" structured data type semantic specifies that one or more elements from the list in the structured data are actual properties of the Data Record. This is equivalent to a logical OR operation. </paragraph> </description> </structuredDataTypeSemantic>
<structuredDataTypeSemantic名=「oneOrMoreOf」値=「2」> <記述> <パラグラフ>構造化データ型「oneOrMoreOf」セマンティック指定構造化データのリストから一の以上の要素は、データレコードの実際の特性であること。これは、論理OR演算に相当します。 </パラグラフ> </記述> </ structuredDataTypeSemantic>
<structuredDataTypeSemantic name="allOf" value="3"> <description> <paragraph> The "allOf" structured data type semantic specifies that all of the list elements from the structured data are actual properties of the Data Record. </paragraph> </description> </structuredDataTypeSemantic>
構造化データからリストのすべての要素<structuredDataTypeSemantic名=「ALLOF」値=「3」> <記述> <パラグラフ>「ALLOF」構造化データ型のセマンティック指定は、データレコードの実際のプロパティです。 </パラグラフ> </記述> </ structuredDataTypeSemantic>
<structuredDataTypeSemantic name="ordered" value="4"> <description> <paragraph> The "ordered" structured data type semantic specifies that elements from the list in the structured data are ordered. </paragraph> </description> </structuredDataTypeSemantic> </structuredDataTypeSemantics>
<記述> <パラグラフ> <structuredDataTypeSemantic名前=値=「4」を「注文」>構造化データのリストからの要素が順序付けられている構造化データ・タイプセマンティック指定「を命じました」。 </パラグラフ> </記述> </ structuredDataTypeSemantic> </ structuredDataTypeSemantics>
The following schema definitions are appended to the abstract data types defined in Appendix B of [RFC5102]. This schema and its namespace are registered by IANA at http://www.iana.org/assignments/xml-registry/schema/ipfix.xsd.
以下のスキーマ定義は、[RFC5102]の付録Bで定義された抽象データ型に付加されています。このスキーマとその名前空間はhttp://www.iana.org/assignments/xml-registry/schema/ipfix.xsdでIANAによって登録されています。
<simpleType name="dataType"> <restriction base="string"> <enumeration value="basicList"> <annotation> <documentation> Represents a list of zero or more instances of any Information Element, primarily used for single-valued data types. Examples include a list of port numbers, a list of interface indexes, and a list of AS in a BGP AS-PATH. </documentation> </annotation> </enumeration> <enumeration value="subTemplateList"> <annotation> <documentation> Represents a list of zero or more instances of a structured data type, where the data type of each list element is the same and corresponds with a single Template Record. Examples include a structured data type composed of multiple pairs of ("MPLS label stack entry position", "MPLS label stack value"), a structured data type composed of performance metrics, and a structured data type composed of multiple pairs of IP address. </documentation> </annotation> </enumeration> <enumeration value="subTemplateMultiList"> <annotation> <documentation> Represents a list of zero or more instances of structured data types, where the data type of each list element can be different and corresponds with different Template definitions. An example is a structured data type composed of multiple access-list entries, where entries can be composed of different criteria types. </documentation> </annotation> </enumeration> </restriction> </simpleType>
<単純名=「データ型」> <制限基地=「文字列」> <列挙値=「basicList」> <注釈> <ドキュメンテーション>主に単一値データのために使用される任意の情報要素のゼロ以上のインスタンスのリストを表しタイプ。例としては、ポート番号のリスト、インタフェースインデックスのリスト、およびBGP AS-PATHでASのリストが含まれています。 </ドキュメンテーション> </注釈> </列挙> <列挙値=「subTemplateList」> <注釈> <ドキュメンテーション>各リスト要素のデータ型である構造化データ型のゼロ以上のインスタンスのリストを表し同じ単一のテンプレートレコードに対応します。例としては、（「MPLSラベルスタックエントリ位置」、「MPLSラベルスタック値」）、パフォーマンス・メトリックからなる構造化データ・タイプ、およびIPアドレスの複数の対からなる構造化データ型の複数の対からなる構造化データ・タイプを含みます。 </ドキュメンテーション> </注釈> </列挙> <列挙値=「subTemplateMultiList」> <注釈> <ドキュメンテーション>各リスト要素のデータ型が異なることができる構造化データ型のゼロ以上のインスタンスのリストを表しそして別のテンプレートの定義に対応します。例では、エントリは、異なる条件タイプで構成することができる複数のアクセス・リスト・エントリからなる構造化データ型です。 </ドキュメンテーション> </注釈> </列挙> </制限> </ simpleTypeの>
<simpleType name="dataTypeSemantics"> <restriction base="string"> <enumeration value="List"> <annotation> <documentation> Represents an arbitrary-length sequence of structured data elements, either composed of regular Information Elements or composed of data conforming to a Template Record. </documentation> </annotation> </enumeration> </restriction> </simpleType>
<単純名=「dataTypeSemantics」> <制限ベース=「文字列」> <列挙値=「リスト」> <注釈> <ドキュメント>は、通常の情報要素から成る又はから成るいずれかの、構造化されたデータ要素の任意の長さの配列を表しますテンプレートレコードに準拠したデータ。 </ドキュメンテーション> </注釈> </列挙> </制限> </ simpleTypeの>
<complexType name="structuredDataTypeSemantics"> <sequence> <element name="structuredDataTypeSemantic" minOccurs="1" maxOccurs="unbounded"> <complexType> <sequence> <element name="description" type="text"/> </sequence> <attribute name="name" type="string" use="required"/> <attribute name="value" type="unsignedByte" use="required"/> </complexType> </element> </sequence> </complexType>
<complexTypeの名前= "structuredDataTypeSemantics"> <シーケンス> <要素名= "structuredDataTypeSemantic" のminOccurs = "1" のmaxOccurs = "無制限"> <complexTypeの> <シーケンス> <要素名= "説明" タイプ= "テキスト" /> < /シーケンス> <属性名= "名前" タイプ= "文字列" 使用= "必要" /> <属性名= "値" タイプ= "なunsignedByte" 使用= "必要" /> </ complexTypeの> </要素> < /シーケンス> </ complexTypeの>
<element name="structuredDataTypeSemantics" type="structuredDataTypeSemantics"> <annotation> <documentation> Structured data type semantics express the relationship among multiple list elements in a structured data Information Element. </documentation> </annotation> </element>
<要素名=「structuredDataTypeSemantics」タイプ=「structuredDataTypeSemantics」> <注釈> <ドキュメンテーション>構造化データ型のセマンティクスは、構造化されたデータ情報要素内の複数のリスト要素間の関係を表現します。 </ドキュメンテーション> </注釈> </要素>
Appendix B. Encoding IPS Alert Using Structured Data Information Elements
構造化データの情報要素の使用付録B.エンコーディングIPSアラート
In this section, an IPS alert example is used to demonstrate how complex data and multiple levels of hierarchy can be encoded using Structured Data Information Elements. Also, this example demonstrates how a basicList of subTemplateLists can be used to represent semantics at multiple levels in the hierarchy.
このセクションでは、IPSアラートの例では、構造化データ情報要素を使用して符号化する方法を複雑なデータと階層の複数のレベルを実証するために使用されます。また、この例ではsubTemplateListsのbasicList階層に複数のレベルで意味を表すために使用することができる方法を示しています。
An IPS alert consists of the following mandatory attributes: signatureId, protocolIdentifier, and riskRating. It can also contain zero or more participants, and each participant can contain zero or more attackers and zero or more targets. An attacker contains the attributes sourceIPv4Address and applicationId, and a target contains the attributes destinationIPv4Address and applicationId.
signatureId、プロトコル識別子、およびriskRating：IPSアラートは、次の必須属性で構成されています。それはまた、ゼロ以上の参加者を含めることができ、各参加者は、ゼロ以上の攻撃やゼロ以上のターゲットを含めることができます。攻撃者は、属性sourceIPv4AddressとAPPLICATIONIDが含まれ、ターゲット属性destinationIPv4AddressとアプリケーションIDが含まれています。
Note that the signatureId and riskRating Information Element fields are created for these examples only; the Field IDs are shown as N/A. The signatureId helps to uniquely identify the IPS signature that triggered the alert. The riskRating identifies the potential risk, on a scale of 0-100 (100 being most serious), of the traffic that triggered the alert.
signatureIdとriskRating情報要素フィールドはこれらの実施例のみのために作成されていることに注意してください。フィールドIDは、N / Aとして示されています。 signatureIdは一意にアラートをトリガーしたIPSシグネチャを識別するのに役立ちます。 riskRatingは、アラートをトリガーしたトラフィックの、0〜100（100が最も深刻である）の規模で、潜在的なリスクを識別します。
Consider the example described in case study 2 of Section 5.6. The IPS alert contains participants encoded as a subTemplateList with semantic allOf. Each participant uses a basicList of subTemplateLists to represent attackers and targets. For the sake of simplicity, the alert has two participants P1 and P2. In participant P1, attacker A1 or A2 attacks target T1. In participant P2, attacker A3 attacks targets T2 and T3.
5.6節のケーススタディ2で説明した例を考えてみましょう。 IPSアラートは、セマンティックALLOFとsubTemplateListとしてエンコードされた参加者が含まれています。各参加者は、攻撃者とターゲットを表現するためにsubTemplateListsのbasicListを使用しています。簡略化のため、アラートが2人の参加者P1とP2を持っています。参加者P1では、攻撃者はA1やA2の攻撃はT1をターゲットにしています。参加者P2では、攻撃者A3攻撃はT2とT3を対象としています。
Participant P1:
参加者P1：
(basicList, allOf,
（basicList、ALLOF、
(subTemplateList, exactlyOneOf, attacker A1, A2)
（subTemplateList、exactlyOneOf、攻撃者A1、A2）
(subTemplateList, undefined, target T1)
（SubTemplateList、未定義は、T1をターゲット）
)
）
Participant P2:
参加者P2：
(basicList, allOf,
（basicList、ALLOF、
(subTemplateList, undefined, attacker A3,
(subTemplateList, allOf, targets T2, T3)
)
）
Alert :
警戒 ：
(subTemplateList, allOf, Participant P1, Participant P2)
（subTemplateList、ALLOF、参加者P1、参加者P2）
------------------------------------------------------------------
| | | participant
sigId |protocol| risk | attacker | target
| Id | Rating | IP | appId | IP | appId
------------------------------------------------------------------
1003 17 10 192.0.2.3 103 192.0.2.103 3001
192.0.2.4 104
192.0.2.5 105 192.0.2.104 4001
192.0.2.105 5001
------------------------------------------------------------------
Participant P1 contains: Attacker A1: (IP, appId)=(192.0.2.3, 103) Attacker A2: (IP, appId)=(192.0.2.4, 104) Target T1: (IP, appId)= (192.0.2.103, 3001)
参加者P1が含ま：攻撃A1：（IP、APPID）=（192.0.2.3、103）攻撃A2：（IP、APPID）=（192.0.2.4、104）、ターゲットT1：（IP、APPID）=（192.0.2.103を、 3001）
Participant P2 contains: Attacker A3: (IP, appId) = (192.0.2.5, 105) Target T2: (IP, appId)= (192.0.2.104, 4001) Target T3: (IP, appId)= (192.0.2.105, 5001)
参加者P2が含ま：攻撃A3：（IP、APPID）=（192.0.2.5、105）ターゲットT2：（IP、APPID）=（192.0.2.104、4001）ターゲットT3：（IP、APPID）=（192.0.2.105を、 5001）
To represent an alert, the following Templates are defined: Template for target (268) Template for attacker (269)
警告を表すために、次のテンプレートが定義されている攻撃者のための標的のテンプレート（268）テンプレート（269）
Template for participant (270) Template for alert (271)
アラートの参加者のためのテンプレート（270）テンプレート（271）
alert (271)
| (signatureId)
| (protocolIdentifier)
| (riskRating)
|
+------- participant (270)
|
+------- attacker (269)
| (sourceIPv4Address)
| (applicationId)
|
+------- target (268)
| (destinationIPv4Address)
| (applicationId)
Note that the attackers are always composed of a single applicationId, while the targets typically have multiple applicationIds; for the sake of simplicity, this example shows only one applicationId in the target.
ターゲットは、典型的には、複数のapplicationIdsを持っていながら、攻撃者は、常に単一APPLICATIONIDで構成されていることに注意してください。簡単のため、この例では、ターゲットで唯一のアプリケーションIDを示します。
Template Record for target, with the Template ID 268:
テンプレートID 268とターゲットのテンプレートレコード、：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 268 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| applicationId = 95 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: Encoding IPS Alert, Template for Target
図31：ターゲットのIPSアラート、テンプレートのエンコーディング
Template Record for attacker, with the Template ID 269:
テンプレートID 269を持つ攻撃者のためのテンプレートレコード、：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 269 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| applicationId = 95 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: Encoding IPS Alert, Template for Attacker
図32：攻撃者のためにIPSアラート、テンプレートのエンコーディング
Template Record for participant, with the Template ID 270:
テンプレートID 270と参加者のためのテンプレートレコード、：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 12 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 270 | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| basicList = 291 | Field Length = 0xFFFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33: Encoding IPS Alert, Template for Participant
図33：参加者のためにIPSアラート、テンプレートのエンコーディング
The Template Record for the participant has one basicList Information Element, which is a list of subTemplateLists of attackers and targets.
参加者のためのテンプレートレコードは、攻撃者とターゲットのsubTemplateListsのリストである1 basicList情報要素を持っています。
Template Record for IPS alert, with the Template ID 271:
テンプレートID 271とIPSのアラートのテンプレートレコード、：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 24 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 271 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| signatureId = N/A | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier = 4 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| riskRating = N/A | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| subTemplateList = 292 | Field Length = 0xFFFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: Encoding IPS Alert, Template for IPS Alert
図34：IPSアラートのIPSアラート、テンプレートのエンコーディング
The subTemplateList in the alert Template Record contains a list of participants.
警告テンプレートレコードでsubTemplateListは、参加者のリストが含まれています。
The Length of basicList and subTemplateList are encoded in three bytes even though they may be less than 255 octets.
basicListとsubTemplateListの長さは、彼らがより少ない255個のオクテットであっても3バイトでエンコードされています。
The Data Set is represented as follows:
次のようにデータセットが表現されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 271 | Length = 102 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signatureId = 1003 | protocolId=17 | riskRating=10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 |participant List Length = 91 |semantic=allOf |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| participant Template ID = 270 | 255 | P1 List Len = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 41 | semantic=allOf| P1 List Field ID = 292 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P1 List Field ID Len = 0xFFFF | 255 |P1 attacker ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List Len = 19 |sem=exactlyOne | P1 attacker Template ID = 269 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P1 attacker A1 sourceIPv4Address = 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P1 attacker A1 applicationId = 103 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P1 attacker A2 sourceIPv4Address = 192.0.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P1 attacker A2 applicationId = 104 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | P1 target List Len = 11 | sem=undefined |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P1 target Template ID = 268 | P1 target T1 destinationIPv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Address = 192.0.2.103 |P1 target T1 applicationId =...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 3001 | 255 | P2 List Len = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 41 | semantic=allOf| P2 List Field ID = 292 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2 List Field ID Len = 0xFFFF | 255 |P2 attacker ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List Len = 11 | sem=undefined | P2 attacker Template ID = 269 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2 attacker A3 sourceIPv4Address = 192.0.2.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2 attacker A3 applicationId = 105 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | P2 target List Len = 19 |semantic=allOf |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2 target Template ID = 268 | P2 target T2 destinationIPv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Address = 192.0.2.104 |P2 target T2 applicationId =...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 4001 | P2 target T3 destinationIPv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Address = 192.0.2.105 |P2 target T3 applicationId =...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 5001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: sem=exactlyOne represents semantic=exactlyOneOf
注意：SEM = exactlyOneはセマンティック= exactlyOneOfを表し
Figure 35: Encoding IPS Alert, Data Set
図35：IPSアラート、データセットのエンコーディング
Authors' Addresses
著者のアドレス
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 Belgium
ブノワClaiseシスコシステムズ、株式会社デKleetlaan 6aはB1のディーゲム1813ベルギー
Phone: +32 2 704 5622 EMail: bclaise@cisco.com
電話：+32 2 704 5622 Eメール：bclaise@cisco.com
Gowri Dhandapani Cisco Systems, Inc. 13615 Dulles Technology Drive Herndon, Virginia 20171 United States
ガウリDhandapaniシスコシステムズ、株式会社13615ダレステクノロジードライブハーンドン、バージニア州20171米国
Phone: +1 408 853 0480 EMail: gowri@cisco.com
電話：+1 408 853 0480 Eメール：gowri@cisco.com
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Commercial Street Edinburgh, EH6 6LX United Kingdom
ポール・エイトケンシスコシステムズ社96コマーシャル岸壁コマーシャルストリートエディンバラ、EH6 6LXイギリス
Phone: +44 131 561 3616 EMail: paitken@cisco.com
電話：+44 131 561 3616 Eメール：paitken@cisco.com
Stan Yates Cisco Systems, Inc. 7100-8 Kit Creek Road PO Box 14987 Research Triangle Park, North Carolina 27709-4987 United States
スタン・イエーツシスコ・システムズ・インク7100から8キットクリーク道路私書箱14987リサーチトライアングルパーク、ノースカロライナ州27709から4987米国
Phone: +1 919 392 8044 EMail: syates@cisco.com
電話：+1 919 392 8044 Eメール：syates@cisco.com