[要約] RFC 6313は、IP Flow Information Export（IPFIX）での構造化データのエクスポートに関する仕様です。目的は、IPFIXフローコレクタが構造化データを受け取り、処理および解析するための方法を提供することです。
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)
IPフロー情報エクスポート（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化された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].
RFC 3917 [RFC3917]で定義されている要件に従って、IPFIXエクスポートプロセスから収集プロセスへの測定されたIPフロー情報のエクスポートのアーキテクチャは、IPFIXアーキテクチャ[RFC5470]で定義されています。
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）プロトコルを使用して、双方向フロー（BIFLOW）情報をエクスポートする方法を指定し、単一のフローレコードを使用して各ビフローを表します。
"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.
「IPフロー情報エクスポート（IPFIX）およびパケットサンプリング（PSAMP）レポートの冗長性の削減」[RFC5473]は、個々のフローに特有の情報から共通の情報に共通する情報を分離することにより、フローまたはパケット情報をエクスポートするための帯域幅節約方法を指定します。記録：一般的なフロー情報は一度だけエクスポートされます。
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.
インターフェイスカウンターを収集することは過去に有用であることが証明されていますが、パフォーマンス保証、容量計画、セキュリティ、請求、または単に監視など、一連のアプリケーションのために、より多くの詳細な情報がネットワーク要素から必要です。ただし、情報の量は非常に大きくなっているため、フロー情報などの高度な粒状情報を扱う場合、プッシュメカニズム（単純なネットワーク管理プロトコル（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つのフローレコードをエクスポートするのではなく、Egressインターフェイスの最適化メカニズムの前後のカウンターで構成されるアクセスルーターがフローレコードをエクスポートできる場合は有益です。
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ミリ秒ごとに特定のフローに関連するパフォーマンスメトリックを受信する必要があると想像してみましょう。パフォーマンスメトリックは絶えず変化しているため、フロー定義には新しい次元があります。数秒または数分間続く単一のフローをもう処理していませんが、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.
これらの要件に適している現在のプロトコルは、プッシュメカニズム、高度にきめ細かい情報、膨大な数の同様のレコードに適していますか？RFC 5101で指定されているIPFIXは、ソリューションの一部を示します。
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（タイプ、長さ、値）形式を使用してエクスポートされることを指定しています。情報は、フロー内の情報要素のデータ形式を定義する{type、length}ペアをエクスポートするために1回送信されるテンプレートレコードを使用してエクスポートされます。データレコードは、各フローの値を指定します。
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]で関連する情報要素が指定されている限り、あらゆる種類の情報をエクスポートできます。 - 特定の情報要素。各情報要素について、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の実装では、2つの情報要素を使用して、MPLSラベルスタックエントリを表します。「ラベルスタックエントリポジション」と「ラベルスタック値」が続きます。ただし、いくつかの欠点が発見されました。まず、テンプレートレコード内の情報要素を課す必要があり、位置が常に値に先行するようにする必要がありました。ただし、一部のエンコーディング最適化は、情報要素の順序の順列に基づいています。第二に、情報モデルに記載されていない新しいセマンティックインテリジェンスは、収集プロセスでハードコーディングする必要がありました。スタックの位置「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.
IPFIX情報モデル[RFC5102]の選択されたソリューションは、一連の情報要素です：mplStoplabelStackSection、MpLSlabelStackSection2、MpLSLabelStackSection3、MpLSLabelStackSection4、MpLSLabelStackSection4、MplSlabelStackSection5、MplScackSectionCection6、MplScection6、Mplscection6、Mplscection6、Mplscection6、Mplscection6、このモデルはあいまいさを削除しますが、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自律システム（AS）のリストをエンコードする方法、BGPフローでBGPコミュニティをエンコードする方法など。
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つの異なる観測ポイントから収集された次の2つの情報要素からの2つの観測点の間に一方向遅延を推定できます。
- Packet arrival time: observationTimeMicroseconds [RFC5477] - Packet ID: digestHashValue [RFC5477]
- パケットの到着時間：observationTimemicRoseconds [RFC5477] - パケット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:
実際には、これは、ハッシュベースのフィルタリング[RFC5475]が使用されていても、観測点ごとに多くのペア（観測チメミックルーセカンド、消化器）をエクスポートする必要があることを意味します。その情報に加えて、要件がアプリケーションタイプごとの一元配置遅延を理解する場合、5タプル（ソースIPアドレス、宛先IPアドレス、プロトコル、ソースポート、宛先ポート）をすべてのフローに追加する必要があります記録。この繰り返しの5タプルをエクスポートする代わりに、すべてのフローレコードの一部として、以下のような構造化されたデータ型で構成されるフローレコードは、多くの帯域幅を節約できます。
5-tuple
{ 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 ...
Alert SignatureID Protocolidentidifier Riskrating参加者1攻撃者1 SOURCESIPV4ADDRESS APPLICATIONID ...攻撃者n SOUCESIPV4ADDRESS ApplicationIDターゲット1 DestinationIPV4Address ApplicationID 1 ... ApplicationID N ... Target N DestindainIPV4Address 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）で構成されている場合、セマンティックは、a、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.
構造化されたデータをサポートする情報要素の1つ、すなわち、セクション4.3で指定されている基本リスト、サブテンプラテリスト、またはサブテンプラットマルチリスト情報要素をサポートしています。
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.
BasicListは、セクション4.1.1で定義されているBasicList抽象データ型を持つ一般的な情報要素を指定し、セクション4.2.1で定義されているセマンティクスをリストします。例には、ポート番号のリスト、インターフェイスインデックスのリストなどが含まれます。
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.1.2で定義されているサブテンプラテリストの抽象データ型を持つ一般的な情報要素を指定し、セクション4.2.1で定義されているセマンティクスをリストします。
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.1.3で定義されているサブテンプラテマルチリストの抽象データ型を持つ一般的な情報要素を指定し、セクション4.2.1で定義されているセマンティクスをリストします。
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）とそれぞれの構造化されたデータ型セマンティックで構成される基本リストで報告します。
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としていくつかのBGPを監視し、報告するルーターです。フローが監視されているBGP As-Pathのいずれにも属さないことをルーターがエクスポートしたい場合、ルーターは（BGP As-Path 1、BGP As-Path 2、BGP As-Pathで構成される基本リストを含むデータレコードを報告します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.
「正確に」構造化されたデータ型セマンティックは、構造化されたデータの単一要素のみがデータレコードの実際のプロパティであることを指定します。これは、論理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.
たとえば、フローレコードに「正確な」セマンティックとの発信インターフェイスの基本リストが含まれている場合、フローレコードにはすべての発信インターフェイスがリストされていますが、報告されたフローが単一のインターフェイスからのみegsedされていることを意味します。これは、宛先ごとの負荷分散の典型的な例です。
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.
Export1の観測点は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の基本リストによって特徴付けられるため、エクスポートプロセスは、一連の入力インターフェイスで観測が行われたことを表現できます。
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、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.
次に、サブテンプレーテマルチリストとセマンティック「正確な」との集約された観測点を表すことができます。集約された観測点は、テンプレートレコード1、テンプレートレコード2、またはテンプレートレコード3に対応するデータレコードでモデル化されていますが、これらの1つ以下です。これは、報告された観測点の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.
「Oneormoreof」構造化データ型セマンティックは、構造化されたデータのリストから1つ以上の要素がデータレコードの実際のプロパティであることを指定しています。これは、論理または操作に相当します。
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
テンプレートレコード1：ExporterIPv4Addressテンプレートレコード2：ExporterIPv4Address、ingressInterfaceテンプレートレコード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.
次に、サブテンプラテマルチリストとセマンティックな「Oneormoreof」を使用した集約された観測点を表すことができます。集約された観測点は、テンプレートレコード1、テンプレートレコード2、またはテンプレートレコード3のいずれかに対応するデータレコードでモデル化されています。これは、報告された観測点の少なくとも1つ、および潜在的に複数の観測ポイントで流れが観察されたことを意味します。
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の各発信インターフェイスに複製されるマルチキャストフローです。
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".
たとえば、輸出業者は、AS20 AS20 AS30 AS40 BGP AS-PATHをエクスポートしたい場合があります。そのような場合、輸出者は（AS10、AS20、AS30、AS40）とそれぞれの構造化されたデータ型セマンティックで構成される基本リストを「順序付け」と報告します。
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で指定された各リスト要素の長さを示しています。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はエンタープライズビット（最も重要なビット）が0に設定されていることで表示されていることに注意してください。代わりに、エンタープライズビットが1に設定されている場合、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に要素がゼロの場合、エンコードされたデータにはセマンティックフィールド、フィールドID、要素長フィールド、および4バイトエンタープライズ番号（存在する場合）が含まれ、BasicListコンテンツが空になっていることに注意してください。
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).
基本リストが255オクテット未満の可変長情報要素としてエンコードされている場合、図3に示すように、[RFC5101]のセクション7ごとに長さのフィールドでエンコードされる場合があります。図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)
図3：可変長さの基本リストエンコード（長さ<255オクテット）
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ごとに長さフィールドでエンコードする必要があります。
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：可変長さの基本リストエンコード（長さ0〜65535オクテット）
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情報要素は、特定のテンプレートに対応するゼロ以上のデータレコードのリストを表します。サブテンプラテリスト情報要素によって参照されるテンプレートレコード自体が他のサブテリスト情報要素を含めることができるため、これらのテンプレートレコード参照はデータレコードの情報要素コンテンツの一部であるため、複雑な階層データ構造を表すことができます。次の図は、サブテンプラテリスト情報要素がデータレコード内でどのようにエンコードされるかを示しています。
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：サブテンプラテリストエンコーディング
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フィールドには、サブテンプラテリストコンテンツのエンコードとデコードに使用されるテンプレートのIDが含まれています。
subTemplateList Content
サブテンプラテリストコンテンツ
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.
サブテンプラテリストコンテンツは、テンプレートIDフィールドで指定されたテンプレートIDに対応するデータレコードのゼロ以上のインスタンスで構成されています。収集プロセスは、それ以上のデータが残るまでサブテンプラテリストコンテンツを解読します。記録的なカウントは含まれていませんが、サブテンプラテリストがデコードされたときに導出できます。指定されたテンプレート自体に、ここで説明されているように構造化されたデータ情報要素が含まれている場合、エンコードとデコードは再帰的に実行されます。
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.
サブテンプラテリストの要素がゼロの場合、エンコードされたデータにはセマンティックフィールドとテンプレート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).
サブテンプルテリストが255オクテット未満の可変長情報要素としてエンコードされている場合、図6に示すように、[RFC5101]のセクション7ごとに長さのフィールドでエンコードされる場合があります。図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：可変長サブテンプラテリストエンコーディング（長さ<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:
サブテンプラテリストが255以上のオクテットの可変長情報要素としてエンコードされている場合、次のように[RFC5101]のセクション7ごとに長さフィールドでエンコードする必要があります。
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：可変長サブテンプラテリストエンコード（長さ0〜65535オクテット）
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].
サブテンプラテリスト情報要素の各要素は単一のテンプレートに対応していますが、リストが異なるテンプレートに対応する要素を含めることが役立つ場合があります。このケースをサポートするために、サブテンプレーテリスト情報要素の各トップレベル要素には、テンプレートIDに対応するテンプレートID、長さ、およびゼロ以上のデータレコードが含まれます。次の図は、サブテンプレームルトリスト情報要素がデータレコード内でどのようにエンコードされるかを示しています。セマンティックフィールドに続くエンコーディングは、[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：サブテンプレームルトリストエンコーディング
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のエンコードをエンコードするデータレコードの合計長さです。これには、テンプレートIDの2バイトと、データレコードの長さフィールド自体の2バイトが含まれます。
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.
データレコードX.Mは、テンプレートレコードXのMTHデータレコードで構成されています。データレコードの長さXに従って、それ以上のデータが残るまでテンプレートレコードXに従ってデータレコードを収集することは、テンプレートレコードXに従ってデコードします。全体的なサブテンプレームルトリストの長さに従ってデコードされます。レコードカウントは含まれていませんが、要素コンテンツがデコードされると導出できます。指定されたテンプレート自体に、ここで説明されているように構造化されたデータ情報要素が含まれている場合、エンコードとデコードは再帰的に実行されます。
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.
サブテンプラテマルチリストのゼロインスタンスの例外的なケースでは、データはエンコードされておらず、セマンティックフィールドとテンプレート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ごとに長さのフィールドでエンコードされる場合があります。図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：可変長さのサブテンプラテマルチリストエンコーディング（長さ<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ごとに長さフィールドでエンコードする必要があります。
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：可変長さのサブテンプラテマルチリストエンコーディング（長さ0〜65535オクテット）
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.
データの複雑で繰り返される性質のため、エクスポートプロセスが正確なエンコードサイズを事前に効率的に知ることは潜在的に困難です。この場合、エクスポートプロセスは、固定オフセットから始まる利用可能なデータをエンコードし、その後最終長さに記入する場合があります。したがって、エンコードされた長さが255バイト未満であっても、構造化されたデータ情報要素を含むすべてのテンプレートレコードの可変長さの情報要素には、3バイトの長さエンコードが推奨されます。。
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]で指定されているように、最大許容されるIPFIXメッセージ長65535バイトを超えないように注意する必要があります。
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構造データインスタンス間の再帰的な関係を定義することができます。これの最も単純なケースは、各要素自体が基本リストであるか、参照されたテンプレートのフィールドの1つ自体が同じテンプレートを参照するサブテンプレーテリストであるサブテンプラテリストであるBasicListである可能性があります。また、再帰的に定義された構造化されたデータをエンコードする場合は、IPFIXメッセージの最大許可された長さを超えない場合（考慮事項をエンコードする長さ）、エクスポートプロセスが注意する必要があります。
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 Non-Scope：観測点をマッピングする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 Template per Information Element. The basicList requires no additional Template and is therefore RECOMMENDED in this case.
サブテンプラテリストは、SubtemplateListによって参照されるテンプレートに1つの単一値情報要素のみが含まれている場合、BasicListと同じ単一値情報要素の同じ単純なリストを表すことができます。この場合、サブテンプラテリストを使用して、エンコードは2バイトだけの基本リストよりもコンパクトですが、情報要素ごとに新しいテンプレートが必要です。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.
1つの要素を持つサブテンプレートマルチリストは、サブテンプラテリストの内容を表すことができますが、サブテンプレーテマルチリストは2つの追加バイト（要素長）を運びます。また、サブテンプラテリストがリスト要素タイプが一貫していることを直接示すことを事前に知ることは、収集プロセスにとっても潜在的に役立ちます。したがって、この場合、サブテンプラテリスト情報要素が推奨されます。
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内の単一のテンプレートIDに対応する異なるデータレコード間の関係を記述するためのセマンティックが必要な場合、サブテンプラテリストの基本リストに基づくエンコードを使用する必要があります。詳細については、セクション5.6を参照してください。あるいは、サブテンプラットマルチリスト内のすべてのデータレコード間の関係（テンプレートレコードに関係なく）の関係を記述するためにセマンティックが必要な場合、単一のテンプレートIDに対応する1つのデータレコードを持つサブテンプラートマルチリストに基づくエンコードを使用できます。
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]から取得できることに注意してください。]、またはエンタープライズ固有の情報要素。
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:
テンプレートレコードに唯一のフィールドとしてサブテンプルテリストが含まれている場合、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.
- エクスポートプロセスは、リスト内の特別な場合でも、リスト内の要素の数を伝えたいと考えています。実際、空のリストの場合は、IPFIXプロトコル仕様[RFC5101]で表すことはできません。単一の要素リストの場合、IPFIXプロトコル仕様[RFC5101]で指定されたテンプレートレコードを使用できます。ただし、複数のリスト要素をエクスポートするためにサブテンプラテリストを使用したテンプレートレコードの上部では、この補足テンプレートは、エクスポートプロセスと収集プロセスの両方に追加の管理を課し、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:
同様に、テンプレートレコードに唯一のフィールドとしてサブテンプレーテマルチリストが含まれている場合、IPFIXプロトコル仕様[RFC5101]で説明されているIPFIXメッセージを考慮する必要があります。
- 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.
- エクスポートプロセスは、サブテンプラテマルチリストのすべてのテンプレートに対応するデータレコードの数を伝えたいと考えています。
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]、セクション3.3.1に記載されている「パディングコンテット」情報要素を含めることにより、データレコードに構造化されたデータフィールド値にいくつかのパディングオクテットを挿入する場合があります。Padningoctets情報要素は、この目的のために構造化されたデータ情報要素によって参照されるテンプレートレコードに含めることができます。
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:
たとえば、AS10 AS20 AS20 AS40 {AS50、AS60} BGP AS-PATHのエクスポートは、2つの要素の基本リストとして報告されます。各要素は、BGPの基本リストであり、トップレベルの構造化データ型セマンティックです。順序付けられました"。最初の要素には、（AS10、AS20、AS30、AS40）とそれぞれの構造化データ型セマンティックで構成される基本リストが含まれ、2番目の要素には（AS50、AS60）とそれぞれの構造化データで構成される基本リストが含まれます。「正確に」のセマンティックを入力します。高レベルのデータレコード図は、次のように表されます。
BGP AS-PATH = (basicList, ordered,
(basicList, ordered, AS10,AS20,AS30,AS40),
（BasicList、Ordered、AS10、AS20、AS30、AS40）、
(basicList, exactlyOneOf, AS50, AS60)
（BasicList、正確なもの、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.
次のケーススタディに示されているように、サブテンプレーテリスト内の単一のテンプレートIDに対応する異なるデータレコード間の関係を説明するためにセマンティックが必要な場合、サブテンプラテリストの基本リストに基づくエンコードを使用する必要があります。
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.
この例では、輸出者の監視セキュリティ攻撃は、攻撃者とターゲットからなるセキュリティイベントのリストをエクスポートする必要があります。例のために、コレクターがターゲット（宛先フィールドを使用して表現される）から攻撃者（ソースフィールドを使用して表される）を区別できると仮定します。攻撃者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.
最初のケースでは、2つのテンプレートレコードで構成されるサブテンペラテンマルチリストを使用します。1つは攻撃者とターゲットを表すもう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,
(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）のリストが存在することのみを結論付けることができます。サブテンプレーテマルチリストが提供するトップレベルのセマンティックでは十分ではないため、エクスポートプロセスは攻撃者とターゲット間の関係を明示的に呼び出す必要があります。
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を攻撃する場合があります）は、サブテンプレートリストの基本リストを使用し、次のように表されます。
Attacker Template Record = (src IP address, src port)
Target Template Record = (dst IP address, dst port)
Alert = (basicList, allOf,
(subTemplateList, exactlyOneOf, attacker A1, A2)
（SubtemplateList、正確に、攻撃者A1、A2）
(subTemplateList, allOf, target T1, T2)
（サブテンプルテリスト、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.
この例では、輸出者の監視セキュリティ攻撃は、攻撃者とターゲットのリストをエクスポートする必要があります。例のために、コレクターがターゲット（宛先フィールドを使用して表現される）から攻撃者（ソースフィールドを使用して表される）を区別できると仮定します。攻撃者A1またはA2がターゲットT1を攻撃し、攻撃者A3がターゲットT2とT3を攻撃していると想像してください。最初のケースでは、2つのテンプレートレコードに対応するデータレコードを含むサブテンプラートマルチリストを使用します。1つは攻撃者とターゲットを表す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,
(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:
2番目のケースでは、以下で構成されるデータレコード定義を使用できます。
Alert = (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）の間に何らかの関係が存在することを推測することができますが、それが何であるかを理解することはできません。したがって、攻撃者とターゲットとサブテンプラテマルチリストのトップレベルのセマンティックとの関係を明示的に定義するためのエクスポートプロセスが十分ではありません。
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を攻撃する）は、サブテンプレートリストの基本リストを使用し、次のように表現します。
Participant P1 =
参加者P1 =
(basicList, allOf,
（BasicList、Allof、
(subTemplateList, exactlyOneOf, attacker A1, A2)
（SubtemplateList、正確に、攻撃者A1、A2）
(subTemplateList, undefined, target T1)
（サブテンプルテリスト、未定義、ターゲットT1）
)
））
Participant P2 =
参加者P2 =
(basicList, allOf,
（BasicList、Allof、
(subTemplateList, undefined, attacker A3,
（サブテンプルテリスト、未定義、攻撃者A3、
(subTemplateList, allOf, targets T2, T3)
（サブテンプラテリスト、Allof、ターゲットT2、T3）
)
））
The security alert is represented as a subTemplateList of participants.
セキュリティアラートは、参加者のサブテンプラテリストとして表されます。
Alert =
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、regitoneof、またはonemormoreofの選択は、同じ結果を意味的に提供します。したがって、構造化されたデータ情報要素に単一の要素がある場合、デフォルトの「未定義」セマンティックを使用する必要があります。
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.
まず、[RFC5101]と比較して、テンプレートIDの一意性は変更されていません。一意性は、テンプレート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]で指定されているように、使用されていないテンプレートは削除する必要があります。テンプレートを削除することは、サブテンプラテリストおよびサブテンプレーテマルチリスト内で使用してはならないことを意味します。テンプレート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情報要素は、リスト要素データ型を指定しません。この情報はデータレコードに含まれています。たとえば、サブテンプレームルチリストの場合、収集プロセスは、データレコードデコードの途中に含まれるテンプレートレコードを参照する必要があります。
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.
構造化されたデータに「未定義の」構造化データ型セマンティックが含まれている場合、収集プロセスは、データレコードに含まれるセマンティックに関して独自の結論を引き出すことを試みることがあります。
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または情報モデルの将来の拡張にリストされているタイプの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、BGPSECKENCELIST、およびBGPSETLISTの抽象型およびセマンティクスのBasicList/Ordered、BasicList/Ordered、およびそれぞれBasicList/recostoneofは、リストの完全なセマンティックを定義します。この仕様では、セクション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：エンコードベーシックリスト、テンプレートレコード
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.
発信インターフェイスのリストは、セマンティックアロフを持つ基本リストとして表され、リストの長さは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：ベーシックリスト、データレコード、セマンティックアロフのエンコード
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：基本リストのエンコーディング、可変長要素を備えたデータレコード、セマンティックアロフ
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:
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
Figure 14: Encoding basicList, Data Record, Semantic exactlyOneOf
図14：ベーシックリスト、データレコード、セマンティックの正確なエンコード
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で説明したように、複数のペアの（観測チメミックルーセカンド、消化器）を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.
サブテンプラテリストは、（観察されるtimememicRoseconds、消化器）のリストをエクスポートするのに最適です。イラストのために、リスト内の要素の数は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：サブテンプラテリストのエンコード、一元配置遅延メトリックのテンプレート
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：サブテンプラテリストのエンコード、テンプレートレコード
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.
（観察チメミックロージョン、消化器）のリストは、セマンティックAllofを備えたサブテンプラテリストとしてエクスポートされます。サブテンプラテリストの長さは、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：サブテンプラテリストのエンコード、データセット
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で説明したように、サブテンプラットマルチリストを使用して、各トップレベル要素が異なるテンプレートレコードに対応する混合タイプコンテンツのリストをエクスポートします。
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
5-Tuple（Flow Keys）、OctetCount、PacketCount SelectorIDのフィルタリングの属性、SelectorID、SelectorAlgorithm、SamplingPacketInterval、SamplingPacketSpaceのSelectorAlgorithm属性属性
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.
この例は、Selector Reportの解釈[RFC5476]がサブテンプレームルトリストとエンコードできることを示しています。より具体的には、この例では、フィルタリング目的で使用されるプロパティマッチフィルタリングセレクターレポートの解釈[RFC5476]、および[RFC5476]のセクション6.5.2.1で説明されている全身カウントベースのサンプリングについて説明しています。一部のトラフィックは、構成された一致プロパティに従ってフィルタリングされ、一部はサンプリングされ、一部はフィルター処理されてサンプリングされ、一部はフィルタリングまたはサンプリングされません。
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
SamplingPacketInterval：行で選択されたパケットの数samplingpacketspace：選択間のパケット数
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であるSamplingPacketIntervalの単純な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
フィルタリング属性のテンプレート：サンプリング属性の259テンプレート：フローレコード用の260テンプレート：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：サブテンプレームルトリストのエンコード、属性をフィルタリングするためのテンプレート
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：サブテンプラットマルチリストのエンコード、サンプリング属性のテンプレート
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プロトコル仕様のセクション6.2で許可されているサイズの縮小により、ここで1オクテットまで圧縮されることに注意してください[RFC5101]。
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：エンコードサブテンプラットマルチリスト、フローレコード用のテンプレート
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を備えたサブテンプレーテマルトリストは、フィルタリング属性とサンプリング属性をエクスポートするために使用されます。サブテンプラテマルチリストの長さフィールドは、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：エンコードサブテンプラテマルチリスト、データセット
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は1つ以上のリネカードで構成され、観測ポイント4は1つ以上のインターフェイスと1つ以上のリネカードで構成されます。構造化されたデータがなければ、各観測点に対応するデータを解釈するために、可能なすべての組み合わせに対してテンプレートを定義する必要があります。ただし、構造化されたデータを使用すると、基本リストを使用してインターフェイスのリストをエンコードでき、別の基本リストを使用してリネカードのリストをエンコードできます。
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.
簡単にするために、以下に示す各観測点には、ルーターと<インターフェイス>または<linecard>または<linecardとinterface>に対応するIPアドレスがあります。これは、上記のように基本リストを使用してインターフェイスのリストとリネカードのリストを含めるように非常に拡張できます。
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）をエンコードするために、これを単一の観測点として表現したいと考えています。[RFC5476]から、PSAMP選択シーケンスレポートの解釈が次のフィールドで構成されていることを思い出してください。
Scope: selectionSequenceId Non-Scope: one Information Element mapping the Observation Point selectorId (one or more)
範囲：SelectionSequenceID Non-Scope：観測点をマッピングする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アドレス4（IPアドレス）= 192.0.2.14）、（Linecard C、Interface 2）selectorid：5（フィルター、一致IPv4Sourceaddress 192.0.2.1）selectionId：10（サンプラー、ランダム1アウト10 oftion）
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の基本リストを使用して、この例をさらに改善できることに注意してください。
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
図23：Subtemplatemultilistを使用したPsampSSRIのオプションテンプレートレコード
A subTemplateMultiList with semantic allOf is used to encode the list of Observation Points.
セマンティックALLOFを持つサブテンプレートマルチリストは、観測ポイントのリストをエンコードするために使用されます。
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 The PSAMP SSRI Data Set is represented as follows:
図26：PSAMP SSRI、LineCardおよびインターフェイスのテンプレートレコード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：Subtemplatemultilistを使用してエンコードされたPSAMP SSRIデータレコードの例
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（Router2、LineCard A）および観測点3（Router3、LineCard B）を表すテンプレート264の複数のインスタンスが含まれていることに注意してください。代わりに、単一の観測点にリネカードAとリネカードBの両方がある場合、ベーシックリストを使用してリネカードのリストを表します。
"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.
一般的なプロパティをエクスポートするための一般的なプロパリエイド情報要素を定義します。
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]で指定されているように、共通のプロパリエイド情報要素に置き換えることができます。交換された要素には、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を参照してください。
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.
実際、[RFC5473]の図1および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の例は、<flow情報>が単一の情報要素を表す場合、<flow情報>がテンプレートレコードを表す場合はサブテンプラテリスト、または<フロー情報>が構成されている場合はサブテンペラトゥマルチリストを使用する場合、基本リストでエンコードできます。異なるテンプレートレコード。
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.
ただし、「IPフロー情報エクスポート（IPFIX）およびパケットサンプリング（PSAMP）レポートの冗長性の低減（PSAMP）レポートで指定された手法の代替として構造化されたデータ情報要素を使用すると、単純化されたケースにのみ適用されることに注意する必要があります。たとえば、「複数のデータ削減」（セクション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.
- このテストは、可変長さの基本リスト、サブテンプラテリスト、およびサブテンプラートマルチリスト情報要素を含むデータレコードを含めるように拡張する必要があります。
3.3.1. Enterprise-Specific Information Elements
3.3.1. エンタープライズ固有の情報要素
- 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. 1つのテンプレート内の同じ情報要素の複数のインスタンス
- this test should verify that multiple instances of the basicList, subTemplateList, and subTemplateMultiList Information Elements are accepted.
- このテストでは、BasicList、SubtemplateList、およびSubtemplatemultilistの情報要素の複数のインスタンスが受け入れられていることを確認する必要があります。
3.5. Stress/Load Tests
3.5. ストレス/負荷テスト
- 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.
2つの新しい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データ型セマンティクス：List 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説明：サブテンプラテリストの抽象データ型を持つ一般的な情報要素を指定します。抽象データ型：サブテンプラテリストデータ型セマンティクス：リスト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
名前：neenof
Description: The "noneOf" structured data type semantic specifies that none of the elements are actual properties of the Data Record.
説明：「noneof」構造化データ型セマンティックは、いずれの要素がデータレコードの実際のプロパティではないことを指定しています。
Value: 0x00
値：0x00
Reference: RFC 6313
参照：RFC 6313
Name: exactlyOneOf
名前：正確にof
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.
説明：「正確に」構造化されたデータ型セマンティックは、構造化されたデータの単一要素のみがデータレコードの実際のプロパティであることを指定します。これは、論理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.
説明：「Oneormoreof」構造化データ型セマンティックは、構造化されたデータのリストから1つ以上の要素がデータレコードの実際のプロパティであることを指定しています。これは、論理または操作に相当します。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、ed。、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[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.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「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. Zander、「IP Flow Information Export（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] Trammell、B。およびE. Boschi、「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.、Brownlee、N.、Claise、B。、およびJ. Quittek、「IPフロー情報エクスポートのアーキテクチャ」、RFC 5470、2009年3月。
[RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP Flow Information Export (IPFIX) Testing", RFC 5471, March 2009.
[RFC5471] Schmoll、C.、Aitken、P。、およびB. Claise、「IP Flow Information Export（IPFIX）テストのガイドライン」、RFC 5471、2009年3月。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、Boschi、E.、Brownlee、N。、およびB. Claise、「IP Flow Information Export（IPFIX）Applicability」、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] Boschi、E.、Mark、L。、およびB. Claise、「IPフロー情報エクスポート（IPFIX）およびパケットサンプリング（PSAMP）レポートの冗長性の削減」、RFC 5473、2009年3月。
[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.、Molina、M.、Duffield、N.、Niccolini、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.、ed。、Johnson、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] Dietz、T.、Claise、B.、Aitken、P.、Dressler、F.、およびG. Carle、「パケットサンプリングエクスポートの情報モデル」、RFC 5477、2009年3月。
[IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <http://www.iana.org/>.
[IANA-IPFIX] IANA、「IP Flow Information Export（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 Jin、Nagaraj Varadharajan、Brian Trammel、Atushi kobayashi、およびRahul Patelのフィードバック、およびGerhard Muenzにドキュメントを校正してくれたことに感謝したいと思います。
Appendix A. Additions to XML Specification of IPFIX Information Elements and Abstract Data Types
付録A. IPFIX情報要素と抽象データ型のXML仕様への追加
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>
<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>
<field name = "subtemplateList" datAtype = "subtemplateList" group = "structured-data" dataTypesemantics = "list" elementId = "292" applicability = "all" status = "> <説明> <paragraph>各リスト要素のデータ型が同じであり、単一のテンプレートレコードに対応する構造化データ型のゼロ以上のインスタンス。例には、複数のペア（「MPLSラベルスタックエントリポジション」、「MPLSラベルスタック値」）の複数のペアで構成される構造化データ型、パフォーマンスメトリックで構成される構造化データ型、および複数のペアのIPアドレスで構成される構造化データ型が含まれます。</paragraph> </description> </field>
<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>
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>
<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 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 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 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 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>
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>
<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>
<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>
<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>
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アラートの例を使用して、構造化されたデータ情報要素を使用して複雑なデータと複数のレベルの階層をエンコードする方法を実証します。また、この例は、サブテンプレーテリストの基本リストを使用して、階層の複数のレベルでセマンティクスを表す方法を示しています。
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.
IPSアラートは、次の必須属性で構成されています：SignatureID、Protocolidentifier、およびRiskrating。また、ゼロ以上の参加者を含めることができ、各参加者はゼロ以上の攻撃者とゼロ以上のターゲットを含めることができます。攻撃者には、sourceipv4AddressとapplicationIDの属性が含まれており、ターゲットにはdestinatipv4AddressおよびapplicationIDが含まれます。
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およびリスクのある情報要素フィールドは、これらの例のみで作成されていることに注意してください。フィールドIDはn/aとして表示されます。SignatureIDは、アラートをトリガーしたIPS署名を一意に識別するのに役立ちます。リスクは、アラートを引き起こしたトラフィックの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を備えたサブテンプラテリストとしてエンコードされた参加者が含まれています。各参加者は、サブテンプラテリストの基本リストを使用して、攻撃者とターゲットを表します。簡単にするために、アラートには2人の参加者P1とP2がいます。参加者P1では、攻撃者A1またはA2がターゲットT1を攻撃します。参加者P2では、攻撃者A3がT2とT3をターゲットに攻撃します。
Participant P1:
参加者P1：
(basicList, allOf,
（BasicList、Allof、
(subTemplateList, exactlyOneOf, attacker A1, A2)
（SubtemplateList、正確に、攻撃者A1、A2）
(subTemplateList, undefined, target T1)
（サブテンプルテリスト、未定義、ターゲットT1）
)
））
Participant P2:
参加者P2：
(basicList, allOf,
（BasicList、Allof、
(subTemplateList, undefined, attacker A3, (subTemplateList, allOf, targets T2, T3)
（サブテンプラテリスト、未定義、攻撃者A3、（サブテンプラテリスト、ALLOF、ターゲット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)
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)
To represent an alert, the following Templates are defined: Template for target (268) Template for attacker (269) Template for participant (270) Template for alert (271)
アラートを表すために、次のテンプレートが定義されています。ターゲット用のテンプレート（268）攻撃者のテンプレート（269）参加者のテンプレート（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.
攻撃者は常に単一のApplicationIDで構成されているが、ターゲットには通常複数のApplicationIDがあることに注意してください。簡単にするために、この例は、ターゲットに1つのアプリケーション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.
参加者のテンプレートレコードには、攻撃者とターゲットのサブテンプラテリストのリストであるBasicList情報要素が1つあります。
Template Record for IPS alert, with the Template ID 271:
IPSアラートのテンプレートレコード、テンプレートID 271：
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.
アラートテンプレートレコードのサブテンプラテリストには、参加者のリストが含まれています。
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
Figure 35: Encoding IPS Alert, Data Set
図35：IPSアラートのエンコード、データセット
Authors' Addresses
著者のアドレス
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 Belgium
Benoit Claise Cisco Systems、Inc。de Kleetlaan 6a B1 Diegem 1813ベルギー
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Gowri Dhandapani Cisco Systems, Inc. 13615 Dulles Technology Drive Herndon, Virginia 20171 United States
Gowri Dhandapani Cisco Systems、Inc。13615 Dulles Technology Drive Herndon、バージニア20171米国
Phone: +1 408 853 0480
EMail: gowri@cisco.com
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Commercial Street Edinburgh, EH6 6LX United Kingdom
Paul Aitken Cisco Systems、Inc。96コマーシャルキーコマーシャルストリートエディンバラ、EH6 6LXイギリス
Phone: +44 131 561 3616
EMail: 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
Stan Yates Cisco Systems、Inc。7100-8 Kit Creek Road PO Box 14987 Research Triangle Park、North Carolina 27709-4987米国
Phone: +1 919 392 8044
EMail: syates@cisco.com