Network Working Group B. Claise, Ed.
Request for Comments: 5101 Cisco Systems, Inc.
Category: Standards Track January 2008
Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
IPトラフィックフロー情報を交換するためのIPフロー情報のエクスポート（IPFIX）プロトコルの仕様
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process.
この文書では、ネットワーク上でIPトラフィックフロー情報を送信するために役立つIPフロー情報のエクスポート（IPFIX）プロトコルを指定します。情報収集プロセスにエクスポートプロセスからIPトラフィックフロー情報を送信するために、フローデータ及びそれらを通信する標準的な手段の一般的な表現が必要とされます。このドキュメントは、IPFIXデータとテンプレートレコードは、IPFIXの収集プロセスへのIPFIXエクスポートプロセスからのトランスポートプロトコルの数の上に運ばれる方法を説明します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. IPFIX Documents Overview ...................................4
2. Terminology .....................................................4
2.1. Terminology Summary Table ..................................9
3. IPFIX Message Format ...........................................10
3.1. Message Header Format .....................................11
3.2. Field Specifier Format ....................................13
3.3. Set and Set Header Format .................................14
3.3.1. Set Format .........................................14
3.3.2. Set Header Format ..................................15
3.4. Record Format .............................................16
3.4.1. Template Record Format .............................16
3.4.2. Options Template Record Format .....................18
3.4.2.1. Scope .....................................19
3.4.2.2. Options Template Record Format ............20
3.4.3. Data Record Format .................................22
4. Specific Reporting Requirements ................................23
4.1. The Metering Process Statistics Option Template ...........23
4.2. The Metering Process Reliability Statistics Option
Template ..................................................24
4.3. The Exporting Process Reliability Statistics
Option Template ...........................................25
4.4. The Flow Keys Option Template .............................26
5. IPFIX Message Header "Export Time" and Flow Record Time ........27
6. Linkage with the Information Model .............................28
6.1. Encoding of IPFIX Data Types ..............................28
6.1.1. Integral Data Types ................................28
6.1.2. Address Types ......................................28
6.1.3. float32 ............................................28
6.1.4. float64 ............................................28
6.1.5. boolean ............................................28
6.1.6. string and octetarray ..............................28
6.1.7. dateTimeSeconds ....................................29
6.1.8. dateTimeMilliseconds ...............................29
6.1.9. dateTimeMicroseconds ...............................29
6.1.10.dateTimeNanoseconds.................................29
6.2. Reduced Size Encoding of Integer and Float Types ..........29
7. Variable-Length Information Element ............................30
8. Template Management ............................................31
9. The Collecting Process's Side ..................................34
10. Transport Protocol ............................................36
10.1. Transport Compliance and Transport Usage .................36
10.2. SCTP .....................................................37
10.2.1. Congestion Avoidance ..............................37
10.2.2. Reliability .......................................37
10.2.3. MTU ...............................................37
10.2.4. Exporting Process .................................38
10.2.4.1. Association Establishment ................38
10.2.4.2. Association Shutdown .....................38
10.2.4.3. Stream ...................................38
10.2.4.4. Template Management ......................39
10.2.5. Collecting Process ................................39
10.2.6. Failover ..........................................39
10.3. UDP ......................................................39
10.3.1. Congestion Avoidance ..............................39
10.3.2. Reliability .......................................40
10.3.3. MTU ...............................................40
10.3.4. Port Numbers ......................................40
10.3.5. Exporting Process .................................40
10.3.6. Template Management ...............................40
10.3.7. Collecting Process ................................41
10.3.8. Failover ..........................................42
10.4. TCP ......................................................42
10.4.1. Connection Management .............................42
10.4.1.1. Connection Establishment .................42
10.4.1.2. Graceful Connection Release ..............43
10.4.1.3. Restarting Interrupted Connections .......43
10.4.1.4. Failover .................................43
10.4.2. Data Transmission .................................43
10.4.2.1. IPFIX Message Encoding ...................43
10.4.2.2. Template Management ......................44
10.4.2.3. Congestion Handling and Reliability ......44
10.4.3. Collecting Process ................................45
11. Security Considerations .......................................46
11.1. Applicability of TLS and DTLS ............................47
11.2. Usage ....................................................48
11.3. Authentication ...........................................48
11.4. Protection against DoS Attacks ...........................48
11.5. When DTLS or TLS Is Not an Option ........................50
11.6. Logging an IPFIX Attack ..................................50
11.7. Securing the Collector ...................................51
12. IANA Considerations ...........................................51
Appendix A. IPFIX Encoding Examples ...............................52
A.1. Message Header Example.....................................52
A.2. Template Set Examples......................................53
A.2.1. Template Set Using IETF-Specified Information
Elements ...........................................53
A.2.2. Template Set Using Enterprise-Specific Information
Elements ...........................................53
A.3. Data Set Example ..........................................55
A.4. Options Template Set Examples .............................56
A.4.1. Options Template Set Using IETF-Specified
Information Elements ...............................56
A.4.2. Options Template Set Using Enterprise-Specific
Information Elements ...............................56
A.4.3. Options Template Set Using an Enterprise-Specific
Scope ..............................................57
A.4.4. Data Set Using an Enterprise-Specific Scope ........58
A.5. Variable-Length Information Element Examples ..............59
A.5.1. Example of Variable-Length Information Element
with Length Inferior to 255 Octets .................59
A.5.2. Example of Variable-Length Information Element
with Length 255 to 65535 Octets ....................59
References ........................................................59
Normative References ...........................................59
Informative References .........................................60
Acknowledgments ...................................................61
A data network with IP traffic primarily consists of IP flows passing through the network elements. It is often interesting, useful, or even required to have access to information about these flows that pass through the network elements for administrative or other purposes. The IPFIX Collecting Process should be able to receive the flow information passing through multiple network elements within the data network. This requires uniformity in the method of representing the flow information and the means of communicating the flows from the network elements to the collection point. This document specifies the protocol to achieve these aforementioned requirements. This document specifies in detail the representation of different flows, the additional data required for flow interpretation, packet format, transport mechanisms used, security concerns, etc.
IPトラフィックとデータ・ネットワークは、主にネットワーク要素を通過するIPフローから成ります。それは多くの場合、興味深く有益な、あるいは行政や他の目的のためのネットワーク要素を通過するこれらのフローに関する情報へのアクセスを有することが必要です。 IPFIX収集プロセスは、データネットワーク内の複数のネットワーク要素を通過するフロー情報を受信することができなければなりません。これは、フロー情報と収集ポイントへのネットワーク要素からの流れを伝える手段を表現する方法で均一性を必要とします。この文書では、これらの前述の要件を達成するためのプロトコルを指定します。この文書では詳細に異なる流れの表現、フロー解釈、パケットフォーマット、使用されるトランスポート機構、セキュリティ上の問題、等に必要な追加データを指定します
The IPFIX protocol provides network administrators with access to IP flow information. The architecture for the export of measured IP flow information out of an IPFIX Exporting Process to a Collecting Process is defined in [IPFIX-ARCH], per the requirements defined in [RFC3917]. This document specifies how IPFIX data records and templates are carried via a number of transport protocols from IPFIX Exporting Processes to IPFIX Collecting Processes. IPFIX has a formal description of IPFIX Information Elements, their name, type and additional semantic information, as specified in [RFC5102]. Finally, [IPFIX-AS] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks.
IPFIXプロトコルは、IPフロー情報へのアクセスをネットワーク管理者に提供します。収集プロセスにIPFIXエクスポートプロセスのうち、測定IPフロー情報のエクスポートのためのアーキテクチャは、[RFC3917]で定義された要件に従って、[IPFIX-ARCH]で定義されています。このドキュメントは、IPFIXデータレコードとテンプレートがIPFIX収集プロセスにIPFIXのエクスポートプロセスからのトランスポートプロトコルの数を経由して運ばれる方法を指定します。 IPFIXは、[RFC5102]で指定されるように、IPFIX情報要素、自分の名前、タイプ、および追加の意味情報の形式的な記述があります。最後に、[IPFIX-AS]はIPFIXプロトコルを使用できるアプリケーションの種類と、彼らが提供された情報を使用する方法について説明します。それはさらに、IPFIXフレームワークは、他のアーキテクチャおよびフレームワークの関係を示します。
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]に記載されているように解釈されます。
The definitions of the basic terms like IP Traffic Flow, Exporting Process, Collecting Process, Observation Points, etc. are semantically identical to those found in the IPFIX requirements document [RFC3917]. Some of the terms have been expanded for more clarity when defining the protocol. Additional terms required for the protocol have also been defined. Definitions in this document and in [IPFIX-ARCH] are equivalent, except that definitions that are only relevant to the IPFIX protocol only appear here.
などのプロセス、観測ポイント、収集プロセスをエクスポートするIPトラフィックフローのような基本的な用語の定義は、IPFIX要件ドキュメント[RFC3917]に見られるものと意味的に同じです。プロトコルを定義するときの用語のいくつかは、より明確にするために拡張されています。プロトコルのために必要な追加条件も定義されています。この文書に記載されていると[IPFIX-ARCH]で定義はIPFIXプロトコルにのみ関連する定義はここでしか表示されていることを除いて、等価です。
The terminology summary table in Section 2.1 gives a quick overview of the relationships between some of the different terms defined.
2.1節での用語の要約表は、定義されたさまざまな用語のいくつかの関係の概要を示します。
Observation Point
観測点
An Observation Point is a location in the network where IP packets can be observed. Examples include: a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router.
観測ポイントは、IPパケットを観察することができるネットワーク内の場所です。例えば、イーサネットベースのLAN、ルータの単一ポート、またはルータの（物理的または論理的な）インターフェイスのセットとプローブが結合している線、共有媒体を、。
Note that every Observation Point is associated with an Observation Domain (defined below), and that one Observation Point may be a superset of several other Observation Points. For example, one Observation Point can be an entire line card. That would be the superset of the individual Observation Points at the line card's interfaces.
すべての観測点が観測ドメイン（以下に定義）に関連付けられていると、1つの観測ポイントは、いくつかの他の観測点スーパーセットすることができることであることに留意されたいです。例えば、1つの観測点は、全体のラインカードとすることができます。これは、ラインカードのインターフェイスで、個々の観測点のスーパーセットになります。
Observation Domain
観測ドメイン
An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. For example, a router line card may be an Observation Domain if it is composed of several interfaces, each of which is an Observation Point. In the IPFIX Message it generates, the Observation Domain includes its Observation Domain ID, which is unique per Exporting Process. That way, the Collecting Process can identify the specific Observation Domain from the Exporter that sends the IPFIX Messages. Every Observation Point is associated with an Observation Domain. It is RECOMMENDED that Observation Domain IDs also be unique per IPFIX Device.
観測ドメインフロー情報は、計量プロセスによって集約することができるの観測ポイントの最大のセットです。それは観測ポイントでそれぞれがいくつかのインタフェースで構成されている場合、例えば、ルータラインカードは、観測ドメインであってもよいです。それが生成するIPFIXメッセージに、観測ドメインは、エクスポートプロセスごとに一意であり、その観測ドメインIDを含みます。その方法は、収集プロセスはIPFIXメッセージを送る輸出業者から特定の観測ドメインを識別することができます。すべての観測点は、観測ドメインに関連付けられています。観測ドメインIDはまた、IPFIX Device単位でユニークであることが推奨されます。
IP Traffic Flow or Flow
IPトラフィックフローまたはフロー
There are several definitions of the term 'flow' being used by the Internet community. Within the context of IPFIX we use the following definition:
インターネットコミュニティによって使用されている用語「流れ」のいくつかの定義があります。 IPFIXの文脈の中で、私たちは次の定義を使用します。
A Flow is defined as a set of IP packets passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties. Each property is defined as the result of applying a function to the values of:
フローは、特定の時間間隔の間、ネットワーク内の観測点を通過するIPパケットの集合として定義されます。特定のフローに属するすべてのパケットは、一般的なプロパティのセットを持っています。各プロパティは、の値に関数を適用した結果のように定義されます。
1. one or more packet header fields (e.g., destination IP address), transport header fields (e.g., destination port number), or application header fields (e.g., RTP header fields [RFC3550]).
1.一つ以上のパケットヘッダフィールド（例えば、宛先IPアドレス）、トランスポートヘッダフィールド（例えば、宛先ポート番号）、またはアプリケーションヘッダフィールド（例えば、RTPヘッダフィールド[RFC3550]）。
2. one or more characteristics of the packet itself (e.g., number of MPLS labels, etc...).
パケット自体の2.一つ以上の特性（例えば、MPLSラベル、等...の数）。
3. one or more of fields derived from packet treatment (e.g., next hop IP address, the output interface, etc...).
3.一つまたはパケット処理に由来するフィールドの複数（例えば、ネクストホップIPアドレス、出力インタフェース、等...）。
A packet is defined as belonging to a Flow if it completely satisfies all the defined properties of the Flow.
パケットは、それが完全にフローの定義されたすべてのプロパティを満たす場合、フローに属するものとして定義されます。
This definition covers the range from a Flow containing all packets observed at a network interface to a Flow consisting of just a single packet between two applications. It includes packets selected by a sampling mechanism.
この定義は、2つのアプリケーション間のちょうど単一のパケットからなるフローへのネットワークインタフェースで観察されるすべてのパケットを含むフローからの範囲をカバーします。これは、サンプリング機構によって選択されたパケットを含んでいます。
Flow Key
フローキー
Each of the fields that:
そのフィールドの各：
3. are derived from packet treatment (e.g., Autonomous System (AS) number),
3.は、パケットの処理（例えば、自律システム（AS）番号）から誘導されます
and that are used to define a Flow are termed Flow Keys.
およびフローを定義するために使用されるフローキーはと呼ばれています。
Flow Record
フローレコード
A Flow Record contains information about a specific Flow that was observed at an Observation Point. A Flow Record contains measured properties of the Flow (e.g., the total number of bytes for all the Flow's packets) and usually characteristic properties of the Flow (e.g., source IP address).
フローレコードは、観測点で観測された特定のフローに関する情報が含まれています。フローレコードは、フロー（例えば、すべてのフローのパケットの合計バイト数）の測定された特性と流れの通常の特性（例えば、送信元IPアドレス）を含みます。
Metering Process
計量プロセス
The Metering Process generates Flow Records. Inputs to the process are packet headers and characteristics observed at an Observation Point, and packet treatment at the Observation Point (for example, the selected output interface).
計量プロセスは、フローレコードを生成します。プロセスへの入力は、パケットヘッダと特性観測点で観測され、観測ポイント（例えば、選択された出力インタフェース）でのパケット処理です。
The Metering Process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining Flow Records.
計量プロセスは、パケットヘッダキャプチャを含む関数のセット、タイムスタンプ、サンプリング、分類、およびフローレコードを維持することから成ります。
The maintenance of Flow Records may include creating new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records.
フローレコードのメンテナンスは、新しいレコードを作成し、既存のものを更新し、フロー統計情報を計算し、さらに流動特性を導出する、フローの有効期限を検出し、エクスポートプロセスにフローレコードを渡して、フローレコードを削除することを含むことができます。
Exporting Process
エクスポートプロセス
The Exporting Process sends Flow Records to one or more Collecting Processes. The Flow Records are generated by one or more Metering Processes.
エクスポートプロセスは、一の以上の収集プロセスにフローレコードを送信します。フローレコードは、一つ以上の計量プロセスによって生成されます。
Exporter
輸出業者
A device that hosts one or more Exporting Processes is termed an Exporter.
一つ以上のエクスポート・プロセスをホスト装置が輸出と呼ばれます。
IPFIX Device
IPFIXデバイス
An IPFIX Device hosts at least one Exporting Process. It may host further Exporting Processes and arbitrary numbers of Observation Points and Metering Processes.
IPFIXデバイスのホストは、少なくとも一つのエクスポートプロセス。さらに、エクスポートプロセスと観測ポイントと計量プロセスの任意の数をホストすることができます。
Collecting Process
収集処理
A Collecting Process receives Flow Records from one or more Exporting Processes. The Collecting Process might process or store received Flow Records, but such actions are out of scope for this document.
収集プロセスは、一の以上のエクスポート・プロセスからのフローレコードを受け取ります。処理したり、店舗かもしれない収集プロセスは、フローレコードを受けたが、そのような行動は、このドキュメントの範囲外です。
Collector
コレクタ
A device that hosts one or more Collecting Processes is termed a Collector.
一つ以上の収集プロセスをホストデバイスは、コレクタと呼ばれます。
Template
テンプレート
A Template is an ordered sequence of <type, length> pairs used to completely specify the structure and semantics of a particular set of information that needs to be communicated from an IPFIX Device to a Collector. Each Template is uniquely identifiable by means of a Template ID.
テンプレートは、完全コレクタにIPFIXデバイスから通信される必要がある情報の特定のセットの構造およびセマンティクスを指定するために使用される<タイプ、長さ>対の順序付けられたシーケンスです。各テンプレートは、テンプレートIDによって一意に識別可能です。
IPFIX Message
IPFIXメッセージ
An IPFIX Message is a message originating at the Exporting Process that carries the IPFIX records of this Exporting Process and whose destination is a Collecting Process. An IPFIX Message is encapsulated at the transport layer.
IPFIXメッセージと宛先収集プロセスであり、このエクスポートプロセスのIPFIXレコードを運ぶエクスポートプロセスで発信メッセージです。 IPFIXメッセージは、トランスポート層でカプセル化されています。
Message Header
メッセージのヘッダー
The Message Header is the first part of an IPFIX Message, which provides basic information about the message, such as the IPFIX version, length of the message, message sequence number, etc.
メッセージヘッダーなどIPFIXバージョン、メッセージの長さ、メッセージシーケンス番号、として、メッセージに関する基本的な情報を提供するIPFIXメッセージの最初の部分であります
Template Record
テンプレートレコード
A Template Record defines the structure and interpretation of fields in a Data Record.
テンプレートレコードは、データレコード内のフィールドの構造と解釈を定義します。
Data Record
データレコード
A Data Record is a record that contains values of the parameters corresponding to a Template Record.
データレコードは、テンプレートレコードに対応するパラメータの値を含むレコードです。
Options Template Record
オプションテンプレートレコード
An Options Template Record is a Template Record that defines the structure and interpretation of fields in a Data Record, including defining how to scope the applicability of the Data Record.
オプションテンプレートレコードは、どのスコープにデータレコードの適用を規定するなど、データレコード構造とフィールドの解釈を定義するテンプレートレコードです。
Set
セットする
Set is a generic term for a collection of records that have a similar structure. In an IPFIX Message, one or more Sets follow the Message Header.
セットには、同様の構造を持つレコードのコレクションの総称です。 IPFIXのメッセージでは、一つ以上のセットはメッセージヘッダに従ってください。
There are three different types of Sets: Template Set, Options Template Set, and Data Set.
テンプレートセット、オプションテンプレートセット、およびデータセット：セットの3種類があります。
Template Set
テンプレートセット
A Template Set is a collection of one or more Template Records that have been grouped together in an IPFIX Message.
テンプレートセットは、IPFIXのメッセージにまとめてきた一つ以上のテンプレートレコードのコレクションです。
Options Template Set
オプションテンプレートセット
An Options Template Set is a collection of one or more Options Template Records that have been grouped together in an IPFIX Message.
オプションテンプレートセットは、IPFIXのメッセージにまとめられている1つまたは複数のオプションテンプレートレコードのコレクションです。
Data Set
データセット
A Data Set is one or more Data Records, of the same type, that are grouped together in an IPFIX Message. Each Data Record is previously defined by a Template Record or an Options Template Record.
データセットは、IPFIXのメッセージにまとめられているのと同じタイプの、一つ以上のデータレコードです。各データレコードは、以前テンプレートレコードまたはオプションテンプレートレコードで定義されています。
Information Element
情報要素
An Information Element is a protocol and encoding-independent description of an attribute that may appear in an IPFIX Record. The IPFIX information model [RFC5102] defines the base set of Information Elements for IPFIX. The type associated with an Information Element indicates constraints on what it may contain and also determines the valid encoding mechanisms for use in IPFIX.
情報要素は、IPFIX記録に現れ得る属性のプロトコル及びエンコーディングに依存しない記述です。 IPFIX情報モデル[RFC5102]はIPFIXの情報要素の基本セットを定義します。情報要素に関連付けられているタイプは、それが含まれているかもしれないものの制約を示し、また、IPFIXで使用するための有効なエンコードメカニズムを決定します。
Transport Session
交通セッション
In Stream Control Transmission Protocol (SCTP), the transport session is known as the SCTP association, which is uniquely identified by the SCTP endpoints [RFC4960]; in TCP, the transport session is known as the TCP connection, which is uniquely identified by the combination of IP addresses and TCP ports used. In UDP, the transport session is known as the UDP session, which is uniquely identified by the combination of IP addresses and UDP ports used.
ストリーム制御伝送プロトコル（SCTP）において、トランスポートセッションを一意SCTPエンドポイント[RFC4960]によって識別されるSCTPアソシエーション、として知られています。 TCPにおいて、トランスポートセッションを一意に使用されるIPアドレスとTCPポートの組み合わせによって識別されるTCP接続として知られています。 UDPでは、トランスポートセッションを一意に使用されるIPアドレスとUDPポートの組み合わせによって識別されたUDPセッションとして知られています。
+------------------+---------------------------------------------+
| | contents |
| +--------------------+------------------------+
| Set | Template | record |
+------------------+--------------------+------------------------+
| Data Set | / | Data Record(s) |
+------------------+--------------------+------------------------+
| Template Set | Template Record(s) | / |
+------------------+--------------------+------------------------+
| Options Template | Options Template | / |
| Set | Record(s) | |
+------------------+--------------------+------------------------+
Figure A: Terminology Summary Table
図A：用語概要表
A Data Set is composed of Data Record(s). No Template Record is included. A Template Record or an Options Template Record defines the Data Record.
データセットは、データレコード（複数可）で構成されています。何テンプレートレコードは含まれません。テンプレートレコードまたはオプションテンプレートレコードは、データレコードを定義します。
A Template Set contains only Template Record(s).
テンプレートセットはテンプレートレコード（複数可）が含まれています。
An Options Template Set contains only Options Template Record(s).
オプションテンプレートセットのみのオプションテンプレートレコード（複数可）が含まれています。
An IPFIX Message consists of a Message Header, followed by one or more Sets. The Sets can be any of the possible three types: Data Set, Template Set, or Options Template Set.
IPFIXメッセージは、一つ以上の設定に続いてメッセージヘッダ、から構成されています。データセット、テンプレートセット、またはオプションテンプレートセット：セットが可能な3種類のいずれかとすることができます。
The format of the IPFIX Message is shown in Figure B.
IPFIXメッセージのフォーマットを図Bに示されています
+----------------------------------------------------+
| Message Header |
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
...
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
Figure B: IPFIX Message Format
図B：IPFIXメッセージの形式
The Exporter MUST code all binary integers of the Message Header and the different Sets in network-byte order (also known as the big-endian byte ordering).
輸出業者は、（また、ビッグエンディアンバイト順序として知られている）ネットワークバイトオーダーにメッセージヘッダと異なるセットのすべてのバイナリ整数をコード化しなければなりません。
Following are some examples of IPFIX Messages:
IPFIXメッセージのいくつかの例を次に示します。
1. An IPFIX Message consisting of interleaved Template, Data, and Options Template Sets -- A newly created Template is exported as soon as possible. So, if there is already an IPFIX Message with a Data Set that is being prepared for export, the Template and Option Template Sets are interleaved with this information, subject to availability of space.
インターリーブされたテンプレートから成る1】IPFIXメッセージは、データ、およびオプションテンプレートセット - 新しく作成されたテンプレートは、できるだけ早くエクスポートされます。輸出のために準備されているデータセットとIPFIXメッセージがすでに存在しているのであれば、テンプレートおよびオプションのテンプレートセットは、スペースの空き状況に、この情報をインターリーブされています。
+--------+--------------------------------------------------------+
| | +----------+ +---------+ +-----------+ +---------+ |
|Message | | Template | | Data | | Options | | Data | |
| Header | | Set | | Set | ... | Template | | Set | |
| | | | | | | Set | | | |
| | +----------+ +---------+ +-----------+ +---------+ |
+--------+--------------------------------------------------------+
Figure C: IPFIX Message, Example 1
図C：IPFIXメッセージ、実施例1
2. An IPFIX Message consisting entirely of Data Sets -- After the appropriate Template Records have been defined and transmitted to the Collecting Process, the majority of IPFIX Messages consist solely of Data Sets.
データの完全なる2.アンIPFIXメッセージセット - 適切なテンプレートレコードが定義され、収集プロセスに送信された後、IPFIXメッセージの大部分は、データセットのみから成ります。
+--------+----------------------------------------------+
| | +---------+ +---------+ +---------+ |
|Message | | Data | | Data | | Data | |
| Header | | Set | ... | Set | ... | Set | |
| | +---------+ +---------+ +---------+ |
+--------+----------------------------------------------+
Figure D: IPFIX Message, Example 2
図D：IPFIXメッセージ、実施例2
3. An IPFIX Message consisting entirely of Template and Options Template Sets.
完全テンプレートとオプションテンプレートセットからなる3アンIPFIXメッセージ。
+--------+-------------------------------------------------+
| | +----------+ +----------+ +----------+ |
|Message | | Template | | Template | | Options | |
| Header | | Set | ... | Set | ... | Template | |
| | | | | | | Set | |
| | +----------+ +----------+ +----------+ |
+--------+-------------------------------------------------+
Figure E: IPFIX Message, Example 3
図E：IPFIXメッセージ、実施例3
The format of the IPFIX Message Header is shown in Figure F.
IPFIXメッセージヘッダーのフォーマットは、図Fに示されています
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure F: IPFIX Message Header Format
図F：IPFIXメッセージヘッダー形式
Message Header Field Descriptions:
メッセージヘッダフィールドの説明：
Version
版
Version of Flow Record format exported in this message. The value of this field is 0x000a for the current version, incrementing by one the version used in the NetFlow services export version 9 [RFC3954].
このメッセージでエクスポートフローレコード形式のバージョン。このフィールドの値は、一つのNetFlowサービスエクスポートバージョン9 [RFC3954]で使用されるバージョンによって増分、現在のバージョンの0x000aです。
Length
長さ
Total length of the IPFIX Message, measured in octets, including Message Header and Set(s).
IPFIXメッセージの全長は、メッセージヘッダとセット（S）を含む、オクテット単位で測定します。
Export Time
エクスポート時間
Time, in seconds, since 0000 UTC Jan 1, 1970, at which the IPFIX Message Header leaves the Exporter.
時間は、秒単位で、0000 UTC 1970年1月1日以降、これでIPFIXメッセージヘッダは、輸出を残します。
Sequence Number
シーケンス番号
Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent on this PR-SCTP stream from the current Observation Domain by the Exporting Process. Check the specific meaning of this field in the subsections of Section 10 when UDP or TCP is selected as the transport protocol. This value SHOULD be used by the Collecting Process to identify whether any IPFIX Data Records have been missed. Template and Options Template Records do not increase the Sequence Number.
インクリメンタルシーケンスカウンタモジュロエクスポートプロセスによって現在の観測ドメインからこのPR-SCTPストリームで送信されたすべてのIPFIXデータレコードの2 ^ 32。 UDPまたはTCPをトランスポートプロトコルとして選択されている場合、セクション10のサブセクションで、この分野の具体的な意味をチェックしてください。この値は、任意のIPFIXデータレコードが失われたかどうかを識別するために収集プロセスによって使用されるべきです。テンプレートとオプションテンプレートレコードは、シーケンス番号を増加させません。
Observation Domain ID
観測ドメインID
A 32-bit identifier of the Observation Domain that is locally unique to the Exporting Process. The Exporting Process uses the Observation Domain ID to uniquely identify to the Collecting Process the Observation Domain that metered the Flows. It is RECOMMENDED that this identifier also be unique per IPFIX Device. Collecting Processes SHOULD use the Transport Session and the Observation Domain ID field to separate different export streams originating from the same Exporting Process. The Observation Domain ID SHOULD be 0 when no specific Observation Domain ID is relevant for the entire IPFIX Message, for example, when exporting the Exporting Process Statistics, or in case of a hierarchy of Collectors when aggregated Data Records are exported.
エクスポートプロセスに局所的に一意である観測ドメインの32ビットの識別子。エクスポートプロセスは、一意に収集プロセスフローを計量観測ドメインを同定するために観測ドメインIDを使用します。また、この識別子もIPFIX Device単位でユニークであることが推奨されます。収集プロセスは、同じエクスポートプロセスに起因するさまざまな輸出の流れを分離するために交通セッションと観測ドメインIDフィールドを使用すべきです。特別観測ドメインIDは、例えば、全体IPFIXメッセージに関連しない場合に観測ドメインIDは0でなければならず、エクスポートプロセスの統計情報をエクスポートするとき、またはコレクターの階層の場合に集約されたデータレコードがエクスポートされます。
Vendors need the ability to define proprietary Information Elements, because, for example, they are delivering a pre-standards product, or the Information Element is, in some way, commercially sensitive. This section describes the Field Specifier format for both IETF-specified Information Elements [RFC5102] and enterprise-specific Information Elements.
例えば、彼らは前の規格の製品を提供している、ので、ベンダーは、独自の情報要素を定義する能力を必要とする、または情報要素は、何らかの方法で、商業的に敏感です。このセクションでは、IETF指定の情報エレメント[RFC5102]と企業固有の情報要素の両方のフィールド指定子のフォーマットを説明しています。
The Information Elements are identified by the Information Element identifier. When the Enterprise bit is set to 0, the corresponding Information Element identifier will report an IETF-specified Information Element, and the Enterprise Number MUST NOT be present. When the Enterprise bit is set to 1, the corresponding Information Element identifier will report an enterprise-specific Information Element; the Enterprise Number MUST be present. An example of this is shown in Section A.4.2.
情報要素は、情報要素識別子によって識別されます。エンタープライズビットが0に設定されている場合は、対応する情報要素識別子は、IETF指定の情報エレメントを報告し、エンタープライズ番号が存在してはなりません。エンタープライズ・ビットが1にセットされたとき、対応する情報要素識別子は、企業固有の情報エレメントを報告します。エンタープライズ番号が存在しなければなりません。この例は、セクションA.4.2に示されています。
The Field Specifier format is shown in Figure G.
フィールド指定子フォーマットは図Gに示されています
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Information Element ident. | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure G: Field Specifier Format
図G：フィールド指定子のフォーマット
Where:
どこ：
E
絵
Enterprise bit. This is the first bit of the Field Specifier. If this bit is zero, the Information Element Identifier identifies an IETF-specified Information Element, and the four-octet Enterprise Number field MUST NOT be present. If this bit is one, the Information Element identifier identifies an enterprise-specific Information Element, and the Enterprise Number filed MUST be present.
エンタープライズビット。これは、フィールド指定子の最初のビットです。このビットがゼロの場合は、情報要素識別子は、IETF指定の情報要素を識別し、4オクテットエンタープライズ番号フィールドが存在してはなりません。このビットが1である場合、情報要素識別子は、企業固有の情報要素を識別し、提出された会社の電話番号が存在しなければなりません。
Information Element identifier
情報要素識別子
A numeric value that represents the type of Information Element. Refer to [RFC5102].
情報要素の種類を表す数値。 [RFC5102]を参照してください。
Field Length
フィールド長
The length of the corresponding encoded Information Element, in octets. Refer to [RFC5102]. The field length may be smaller than the definition in [RFC5102] if the reduced size encoding is used (see Section 6.2). The value 65535 is reserved for variable-length Information Elements (see Section 7).
オクテットに対応する符号化された情報要素の長さ、。 [RFC5102]を参照してください。縮小サイズのエンコーディングが使用される場合、フィールド長は[RFC5102]で定義よりも小さくすることができる（セクション6.2を参照）。値65535は、可変長情報要素（第7節参照）のために予約されています。
Enterprise Number
エンタープライズ番号
IANA enterprise number [PEN] of the authority defining the Information Element identifier in this Template Record.
このテンプレートレコード内の情報要素識別子を定義する権限のIANAエンタープライズ番号[PEN]。
A Set is a generic term for a collection of records that have a similar structure. There are three different types of Sets: Template Sets, Options Template Sets, and Data Sets. Each of these Sets consists of a Set Header and one or more records. The Set Format and the Set Header Format are defined in the following sections.
設定は、同様の構造を持つレコードのコレクションの総称です。テンプレートセット、オプションテンプレートセット、およびデータセット：3つの異なるセットの種類があります。これらの組のそれぞれは、セットのヘッダーと1つ以上のレコードで構成されています。セット形式と設定ヘッダー形式は、以下のセクションで定義されています。
A Set has the format shown in Figure H. The record types can be either Template Records, Options Template Records, or Data Records. The record types MUST NOT be mixed within a Set.
設定は、図H.レコードタイプは、のいずれかであることができるテンプレートレコード、オプションテンプレートレコード、またはデータレコードのフォーマットを示しています。レコードタイプは、セット内で混在させることはできません。
+--------------------------------------------------+
| Set Header |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
...
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| Padding (opt.) |
+--------------------------------------------------+
Figure H: Set Format
図H：設定されているフォーマット
The Set Field Definitions are as follows:
次のように設定フィールドの定義は以下のとおりです。
Set Header
ヘッダーを設定
The Set Header Format is defined in Section 3.3.2.
セットのヘッダー形式は、3.3.2項で定義されています。
Record
記録
One of the record Formats: Template Record, Options Template Record, or Data Record Format.
テンプレートレコード、オプションテンプレートレコード、またはデータレコードフォーマット：レコードフォーマットの一つ。
Padding
パディング
The Exporting Process MAY insert some padding octets, so that the subsequent Set starts at an aligned boundary. For security reasons, the padding octet(s) MUST be composed of zero (0) valued octets. The padding length MUST be shorter than any allowable record in this Set. If padding of the IPFIX Message is desired in combination with very short records, then the padding Information Element 'paddingOctets' [RFC5102] can be used for padding records such that their length is increased to a multiple of 4 or 8 octets. Because Template Sets are always 4-octet aligned by definition, padding is only needed in case of other alignments e.g., on 8-octet boundaries.
その後の設定が整列境界で開始するようにエクスポートプロセスは、いくつかのパディングオクテットを挿入することができます。セキュリティ上の理由のために、パディングオクテット（S）は、ゼロ（0）値のオクテットで構成されなければなりません。パディング長はこのセットに任意の許容記録よりも短くする必要があります。 IPFIXメッセージのパディングが非常に短いレコードと組み合わせて、所望される場合、次いで、パディング情報要素「paddingOctets」[RFC5102]は、その長さが4つのまたは8オクテットの倍数に増加するようにパディング・レコードのために使用することができます。テンプレートセットは、常に定義によって整列4オクテットであるため、パディングは唯一の8オクテット境界に、例えば他のアライメントの場合に必要とされます。
Every Set contains a common header. This header is defined in Figure I.
すべての設定は共通ヘッダが含まれています。このヘッダは、図Iに定義されています
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure I: Set Header Format
図I：セットのヘッダー形式
The Set Header Field Definitions are as follows:
次のように設定ヘッダーフィールドの定義は以下のとおりです。
Set ID
セットID
Set ID value identifies the Set. A value of 2 is reserved for the Template Set. A value of 3 is reserved for the Option Template Set. All other values from 4 to 255 are reserved for future use. Values above 255 are used for Data Sets. The Set ID values of 0 and 1 are not used for historical reasons [RFC3954].
セットIDの値がセットを識別します。 2の値は、テンプレートセット用に予約されています。 3の値は、オプションテンプレートセット用に予約されています。 4〜255の他のすべての値は、将来の使用のために予約されています。 255以上の値はデータセットのために使用されています。 0と1のセットのID値は、歴史的な理由[RFC3954]のために使用されていません。
Length
長さ
Total length of the Set, in octets, including the Set Header, all records, and the optional padding. Because an individual Set MAY contain multiple records, the Length value MUST be used to determine the position of the next Set.
ヘッダーを設定し、すべてのレコード、およびオプションのパディングを含むオクテットのSetの合計の長さ、、。個々の設定は、複数のレコードが含まれている可能性があるため、長さ値は、次のセットの位置を決定するために使用しなければなりません。
IPFIX defines three record formats, defined in the next sections: the Template Record Format, the Options Template Record Format, and the Data Record Format.
テンプレートレコードの形式、オプションテンプレートレコード形式、およびデータレコード形式：IPFIXは次のセクションで定義された3つのレコード形式を定義します。
One of the essential elements in the IPFIX record format is the Template Record. Templates greatly enhance the flexibility of the record format because they allow the Collecting Process to process IPFIX Messages without necessarily knowing the interpretation of all Data Records. A Template Record contains any combination of IANA-assigned and/or enterprise-specific Information Elements identifiers.
IPFIXレコード形式に不可欠な要素の一つは、テンプレートレコードです。彼らは収集プロセスは、必ずしもすべてのデータレコードの解釈を知らなくても、IPFIXのメッセージを処理できるようにするためのテンプレートが大幅にレコード形式の柔軟性を向上させます。テンプレートレコードは、IANAによって割り当てられたおよび/または企業固有の情報要素識別子の任意の組み合わせを含んでいます。
The format of the Template Record is shown in Figure J. It consists of a Template Record Header and one or more Field Specifiers. The definition of the Field Specifiers is given in Figure G above.
テンプレートレコードのフォーマットは、テンプレートレコードヘッダと1つ以上のフィールド指定子から構成図J.に示されています。フィールド指定子の定義は、上記の図Gに示されています。
+--------------------------------------------------+
| Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
Figure J: Template Record Format
図J：テンプレートレコード・フォーマット
The format of the Template Record Header is shown in Figure K.
テンプレートレコードヘッダのフォーマットを図K.に示されています
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (> 255) | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure K: Template Record Header Format
図K：テンプレートレコードヘッダー形式
The Template Record Header Field Definitions are as follows:
次のようにテンプレートレコードヘッダーフィールドの定義は以下のとおりです。
Template ID
テンプレートのID
Each of the newly generated Template Records is given a unique Template ID. This uniqueness is local to the Transport Session and Observation Domain that generated the Template ID. Template IDs 0-255 are reserved for Template Sets, Options Template Sets, and other reserved Sets yet to be created. Template IDs of Data Sets are numbered from 256 to 65535. There are no constraints regarding the order of the Template ID allocation.
新しく生成されたテンプレートレコードのそれぞれは、固有のテンプレートIDを与えています。このユニークさは、テンプレートIDを生成交通セッションと観測ドメインにローカルです。テンプレートIDは0から255までは、まだ作成するテンプレートセット、オプションテンプレートセット、およびその他の予約を設定するために予約されています。データセットのテンプレートIDは、テンプレートIDの割り当ての順序に関する一切の制約はありません256から65535に番号が付けられています。
Field Count
フィールドカウント
Number of fields in this Template Record.
このテンプレートレコード内のフィールドの数。
The example in Figure L shows a Template Set with mixed standard and enterprise-specific Information Elements. It consists of a Set Header, a Template Header, and several Field Specifiers.
図Lの例では、混合標準および企業固有の情報要素とテンプレートセットを示しています。それはセットのヘッダー、テンプレートのヘッダー、およびいくつかのフィールド指定子で構成されています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.1 | Field Length 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 1.2 | Field Length 1.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.N | Field Length 1.N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 2.1 | Field Length 2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.2 | Field Length 2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.M | Field Length 2.M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure L: Template Set Example
図L：テンプレートセットの例
Information Element Identifiers 1.2 and 2.1 are defined by the IETF (Enterprise bit = 0) and, therefore, do not need an Enterprise Number to identify them.
情報要素識別子1.2と2.1ので、それらを識別するためにエンタープライズ番号を必要としない、IETFによって定義された（エンタープライズビット= 0）とされています。
Thanks to the notion of scope, The Options Template Record gives the Exporter the ability to provide additional information to the Collector that would not be possible with Flow Records alone.
スコープの概念のおかげで、オプションテンプレートレコードは、輸出業者にのみフローレコードでは可能ではないでしょうCollectorに追加情報を提供することができます。
One Options Template Record example is the "Flow Keys", which reports the Flow Keys for a Template, which is defined as the scope. Another example is the "Template configuration", which reports the configuration sampling parameter(s) for the Template, which is defined as the scope.
一つのオプションテンプレートレコードの例は、スコープとして定義されているテンプレートのためのフローキーを報告し、「フローキー」、です。別の例では、範囲として定義されているテンプレート、の構成サンプリングパラメータ（複数可）を報告する「テンプレートの設定」、です。
The scope, which is only available in the Options Template Set, gives the context of the reported Information Elements in the Data Records. Note that the IPFIX Message Header already contains the Observation Domain ID (the identifier of the Observation Domain). If not zero, this Observation Domain ID can be considered as an implicit scope for the Data Records in the IPFIX Message. The Observation Domain ID MUST be zero when the IPFIX Message contains Data Records with different Observation Domain ID values defined as scopes.
オプションテンプレートセットでのみ使用可能範囲は、データレコードで報告された情報要素のコンテキストを提供します。 IPFIXメッセージヘッダーが既に観測ドメインID（観測ドメインの識別子）が含まれていることに注意してください。ゼロでない場合は、この観測ドメインIDはIPFIXメッセージ内のデータレコードのための暗黙の範囲とみなすことができます。 IPFIXメッセージは、スコープとして定義された異なる観測ドメインID値とデータレコードが含まれている場合に観測ドメインIDはゼロでなければなりません。
Multiple Scope Fields MAY be present in the Options Template Record, in which case, the composite scope is the combination of the scopes. For example, if the two scopes are defined as "metering process" and "template", the combined scope is this Template for this Metering Process. The order of the Scope Fields, as defined in the Options Template Record, is irrelevant in this case. However, if the order of the Scope Fields in the Options Template Record is relevant, the order of the Scope Fields MUST be used. For example, if the first scope defines the filtering function, while the second scope defines the sampling function, the order of the scope is important. Applying the sampling function first, followed by the filtering function, would lead to potentially different Data Records than applying the filtering function first, followed by the sampling function. In this case, the Collector deduces the function order by looking at the order of the scope in the Options Template Record.
複数のスコープフィールドはオプションテンプレートレコード中に存在してもよく、その場合には、複合範囲は、スコープの組み合わせです。 2つのスコープは「計量法」と「テンプレート」として定義されている場合、例えば、合成範囲は、この計量プロセスは、このテンプレートです。スコープフィールドの順序は、オプションテンプレートレコードで定義されるように、この場合には無関係です。オプションテンプレートレコード内のスコープフィールドの順序が関連している場合は、スコープフィールドの順序を使用しなければなりません。第二範囲は、サンプリング関数を定義しつつ、第1範囲は、フィルタリング機能を定義する場合、例えば、スコープの順序が重要です。第1のサンプリング機能を適用すると、フィルタリング機能に続いて、サンプリング機能が続き、最初のフィルタリング機能を適用するよりも、潜在的に異なるデータレコードにつながるであろう。この場合、コレクタはオプションテンプレートレコード内のスコープの順序を見て、機能の順序を推定します。
The scope is an Information Element specified in the IPFIX Information Model [RFC5102]. An IPFIX-compliant implementation of the Collecting Process SHOULD support this minimum set of Information Elements as scope: LineCardId, TemplateId, exporterIPv4Address, exporterIPv6Address, and ingressInterface. Note that other Information Elements, such as meteringProcessId, exportingProcessId, observationDomainId, etc. are also valid scopes. The IPFIX protocol doesn't prevent the use of any Information Elements for scope. However, some Information Element types don't make sense if specified as scope; for example, the counter Information Elements.
スコープはIPFIX情報モデル[RFC5102]で指定された情報要素です。 LineCardId、れるtemplateId、exporterIPv4Address、exporterIPv6Address、およびingressInterface：収集プロセスのIPFIXに準拠した実装は、情報スコープとしてこの元素の最小セットをサポートする必要があります。などmeteringProcessId、exportingProcessId、observationDomainId、などの他の情報要素は、また、有効なスコープであることに注意してください。 IPFIXプロトコルは、スコープの任意の情報要素の使用を妨げるものではありません。スコープとして指定されている場合しかし、いくつかの情報要素タイプは意味がありません。例えば、カウンタ情報要素。
Finally, note that the Scope Field Count MUST NOT be zero.
最後に、スコープフィールドカウントがゼロにされてはならないことに注意してください。
An Options Template Record contains any combination of IANA-assigned and/or enterprise-specific Information Elements identifiers.
オプションテンプレートレコードは、IANAによって割り当てられたおよび/またはエンタープライズ固有の情報要素識別子の任意の組み合わせが含まれています。
The format of the Options Template Record is shown in Figure M. It consists of an Options Template Record Header and one or more Field Specifiers. The definition of the Field Specifiers is given in Figure G above.
オプションテンプレートレコードのフォーマットは、それがオプションテンプレートレコードヘッダと1つ以上のフィールド指定子から構成図M.に示されています。フィールド指定子の定義は、上記の図Gに示されています。
+--------------------------------------------------+
| Options Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
Figure M: Options Template Record Format
図M：オプションテンプレートレコード形式
The format of the Options Template Record Header is shown in Figure N.
オプションテンプレートレコードヘッダのフォーマットを図Nに示されています
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (> 255) | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure N: Options Template Record Header Format
図N：オプションテンプレートレコードのヘッダー形式
The Options Template Record Header Field Definitions are as follows:
次のようにオプションテンプレートレコードのヘッダーフィールドの定義は以下のとおりです。
Template ID
テンプレートのID
Template ID of this Options Template Record. This value is greater than 255.
このオプションテンプレートレコードのテンプレートID。この値が255以上です。
Field Count
フィールドカウント
Number of all fields in this Options Template Record, including the Scope Fields.
スコープフィールドを含め、このオプションテンプレートレコード内のすべてのフィールドの数。
Scope Field Count
スコープフィールドカウント
Number of scope fields in this Options Template Record. The Scope Fields are normal Fields except that they are interpreted as scope at the Collector. The Scope Field Count MUST NOT be zero.
スコープの数は、このオプションテンプレートレコードのフィールド。スコープフィールドは、それらがコレクタの範囲として解釈されることを除いて、通常のフィールドです。スコープフィールドカウントがゼロであってはなりません。
The example in Figure O shows an Option Template Set with mixed IETF and enterprise-specific Information Elements. It consists of a Set Header, an Option Template Header, and several Field Specifiers.
図Oの例では、混合IETFおよび企業固有の情報要素とテンプレートセットオプションを示しています。それはセットのヘッダー、オプションテンプレートのヘッダー、およびいくつかのフィールド指定子で構成されています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 258 | Field Count = N + M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = N |0| Scope 1 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length |0| Scope 2 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 2 Field Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |1| Scope N Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope N Field Length | Scope N Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Scope N Enterprise Number |1| Option 1 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option 1 Field Length | Option 1 Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Option 1 Enterprise Number | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |0| Option M Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option M Field Length | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure O: Option Template Set Example
図O：オプションテンプレートセットの例
The Data Records are sent in Data Sets. The format of the Data Record is shown in Figure P. It consists only of one or more Field Values. The Template ID to which the Field Values belong is encoded in the Set Header field "Set ID", i.e., "Set ID" = "Template ID".
データレコードは、データセットに送信されます。データレコードのフォーマットは、それが1つのまたは複数のフィールド値で構成図Pに示されています。フィールド値が属するテンプレートIDが設定ヘッダフィールド「セットID」、すなわち、「セットID」=「テンプレートID」に符号化されます。
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
Figure P: Data Record Format
図P：データレコードのフォーマット
Note that Field Values do not necessarily have a length of 16 bits. Field Values are encoded according to their data type specified in [RFC5102].
フィールド値は、必ずしも16ビットの長さを持っていないことに注意してください。フィールド値は[RFC5102]で指定されたそれらのデータ・タイプに従って符号化されます。
Interpretation of the Data Record format can be done only if the Template Record corresponding to the Template ID is available at the Collecting Process.
データレコードフォーマットの解釈は、テンプレートIDに対応するテンプレートレコードが収集プロセスで利用可能である場合にのみ行うことができます。
The example in Figure Q shows a Data Set. It consists of a Set Header and several Field Values.
図Qの例では、データセットを示します。これは、設定ヘッダーといくつかのフィールド値で構成されています。
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 = Template ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 1 | Record 1 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 1 | Record 2 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 1 | Record 3 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure Q: Data Set, Containing Data Records
図Q：データセット、データレコードを含みます
Some specific Options Templates and Options Template Records are necessary to provide extra information about the Flow Records and about the Metering Process.
いくつかの特定のオプションテンプレートとオプションテンプレートレコードは、フローレコードについておよびメーター・プロセスに関する追加情報を提供するために必要です。
The Option Template and Options Template Records defined in these subsections, which impose some constraints on the Metering Process and Exporting Process implementations, MAY be implemented. If implemented, the specific Option Templates SHOULD be implemented as specified in these subsections.
計量プロセスとエクスポートプロセスの実装にいくつかの制約を課すこれらのサブセクションで定義されたオプションのテンプレートとオプションテンプレートレコードは、実装されてもよいです。実装されている場合、これらのサブセクションに指定されているように、特定のオプションテンプレートを実装する必要があります。
The minimum set of Information Elements is always specified in these Specific IPFIX Options Templates. Nevertheless, extra Information Elements may be used in these specific Options Templates.
情報要素の最小セットは、常にこれらの具体的なIPFIXオプションテンプレートで指定されています。それにも関わらず、余分な情報要素は、これらの特定のオプションテンプレートで使用することができます。
The Metering Process Statistics Option Template specifies the structure of a Data Record for reporting Metering Process statistics. It SHOULD contain the following Information Elements that are defined in [RFC5102]:
計量プロセス統計オプションテンプレートは、計量プロセスの統計情報を報告するためのデータレコードの構造を指定します。これは、[RFC5102]で定義されている以下の情報要素が含まれている必要があります。
observationDomainId An identifier of an Observation Domain that is locally unique to the Exporting Process. This Information Element MUST be defined as a Scope Field.
エクスポートプロセスにローカルで一意である観測ドメインIDと観測ドメインの識別子。この情報要素はスコープフィールドとして定義されなければなりません。
exportedMessageTotalCount The total number of IPFIX Messages that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization.
エクスポートプロセスが正常にエクスポートプロセスの再初期化以来収集プロセスに送信されたIPFIXメッセージの総数をexportedMessageTotalCount。
exportedFlowTotalCount The total number of Flow Records that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization.
エクスポートプロセスが正常にエクスポートプロセスの再初期化以来収集プロセスに送信されたフローレコードの合計数をexportedFlowTotalCount。
exportedOctetTotalCount The total number of octets that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization.
エクスポートプロセスが正常にエクスポートプロセスの再初期化以来収集プロセスに送信されたオクテットの総数exportedOctetTotalCount。
The Exporting Process SHOULD export the Data Record specified by the Metering Process Statistics Option Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable.
エクスポートプロセスは、定期的に計量プロセス統計オプションテンプレートで指定されたり、一部の輸出ポリシーに基づいてデータレコードをエクスポートする必要があります。この周期性またはエクスポートポリシーは設定であるべきです。
Note that if several Metering Processes are available on the Exporter Observation Domain, the Information Element meteringProcessId MUST be specified as an additional Scope Field.
いくつかの計量プロセスは、輸出業者観測ドメインで利用可能である場合には、情報要素meteringProcessIdが追加スコープフィールドとして指定しなければならないことに注意してください。
The Metering Process Reliability Option Template specifies the structure of a Data Record for reporting lack of reliability in the Metering Process. It SHOULD contain the following Information Elements that are defined in [RFC5102]:
計量プロセスの信頼性オプションテンプレートは、計量プロセスの信頼性の欠如を報告するためのデータレコードの構造を指定します。これは、[RFC5102]で定義されている以下の情報要素が含まれている必要があります。
observationDomainId An identifier of an Observation Domain that is locally unique to the Exporting Process. This Information Element MUST be defined as a Scope Field.
エクスポートプロセスにローカルで一意である観測ドメインIDと観測ドメインの識別子。この情報要素はスコープフィールドとして定義されなければなりません。
ignoredPacketTotalCount The total number of IP packets that the Metering Process did not process.
計量プロセスは、プロセスではありませんでしたIPパケットの合計数をignoredPacketTotalCount。
ignoredOctetTotalCount The total number of octets in observed IP packets that the Metering Process did not process.
計量プロセスは、プロセスではありませんでした観測されたIPパケットのオクテットの総数をignoredOctetTotalCount。
time first ignored The timestamp of the first IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowStart" timestamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used.
時間は最初の計量プロセスによって無視された最初のIPパケットのタイムスタンプを無視しました。このタイムスタンプは、「flowStart」タイムスタンプ情報要素flowStartMilliseconds、flowStartMicroseconds、flowStartNanoseconds、およびflowStartDeltaMicrosecondsのいずれかを使用することができます。
time last ignored The timestamp of the last IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowEnd" timestamp Information Elements flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds can be used.
時間は、最後の計量プロセスによって無視された最後のIPパケットのタイムスタンプを無視しました。このタイムスタンプは、「flowEnd」タイムスタンプ情報要素flowEndMilliseconds、flowEndMicroseconds、flowEndNanoseconds、およびflowEndDeltaMicrosecondsのいずれかを使用することができます。
The Exporting Process SHOULD export the Data Record specified by the Metering Process Reliability Statistics Option Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable.
エクスポートプロセスは、定期的に計量プロセス信頼性の統計オプションテンプレートで指定されたり、一部の輸出ポリシーに基づいてデータレコードをエクスポートする必要があります。この周期性またはエクスポートポリシーは設定であるべきです。
Note that if several Metering Processes are available on the Exporter Observation Domain, the Information Element meteringProcessId MUST be specified as an additional Scope Field.
いくつかの計量プロセスは、輸出業者観測ドメインで利用可能である場合には、情報要素meteringProcessIdが追加スコープフィールドとして指定しなければならないことに注意してください。
The Exporting Process Reliability Option Template specifies the structure of a Data Record for reporting lack of reliability in the Exporting process. It SHOULD contain the following Information Elements that are defined in [RFC5102]:
エクスポートプロセスの信頼性オプションテンプレートは、エクスポート・プロセスの信頼性の欠如を報告するためのデータレコードの構造を指定します。これは、[RFC5102]で定義されている以下の情報要素が含まれている必要があります。
Exporting Process ID The identifier of the Exporting Process for which lack of reliability is reported. There are three Information Elements specified in [RFC5102] that can be used for this purpose: exporterIPv4Address, exporterIPv6Address, or exportingProcessId. This Information Element MUST be defined as a Scope Field.
プロセスIDを信頼性の欠如が報告されているエクスポートプロセスの識別子をエクスポートします。 exporterIPv4Address、exporterIPv6Address、またはexportingProcessId：この目的のために使用することができる[RFC5102]で指定された3つの情報要素があります。この情報要素はスコープフィールドとして定義されなければなりません。
notSentFlowTotalCount The total number of Flows that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process.
計量プロセスによって生成され、計量プロセスによって、または代わりに収集プロセスに送信されるのエクスポートプロセスによって廃棄されたフローの総数notSentFlowTotalCount。
notSentPacketTotalCount The total number of packets in Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process.
計量プロセスによって生成され、計量プロセスによって、または代わりに収集プロセスに送信されるのエクスポートプロセスによって廃棄されたフローレコード内のパケットの総数notSentPacketTotalCount。
notSentOctetTotalCount The total number of octets in packets in Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process.
計量プロセスによって生成され、計量プロセスによって、または代わりに収集プロセスに送信されるのエクスポートプロセスによって廃棄されたフローレコード内のパケットのオクテットの総数notSentOctetTotalCount。
time first flow dropped The timestamp of the first Flow was dropped by the Metering Process. For this timestamp, any of the "flowStart" timestamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used.
最初のフローが第一流のタイムスタンプを滴下時間は、計量プロセスによって滴下しました。このタイムスタンプは、「flowStart」タイムスタンプ情報要素flowStartMilliseconds、flowStartMicroseconds、flowStartNanoseconds、およびflowStartDeltaMicrosecondsのいずれかを使用することができます。
time last flow dropped The timestamp of the last IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowEnd" timestamp Information Elements flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds can be used.
時間の最後の流れは、計量プロセスによって無視された最後のIPパケットのタイムスタンプを落としました。このタイムスタンプは、「flowEnd」タイムスタンプ情報要素flowEndMilliseconds、flowEndMicroseconds、flowEndNanoseconds、およびflowEndDeltaMicrosecondsのいずれかを使用することができます。
The Exporting Process SHOULD export the Data Record specified by the Exporting Process Reliability Statistics Option Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable.
エクスポートプロセスは、定期的にエクスポートプロセスの信頼性の統計オプションテンプレートで指定されたり、一部の輸出ポリシーに基づいてデータレコードをエクスポートする必要があります。この周期性またはエクスポートポリシーは設定であるべきです。
The Flow Keys Option Template specifies the structure of a Data Record for reporting the Flow Keys of reported Flows. A Flow Keys
フローキーオプションテンプレートは、報告されたフローのフローキーを報告するためのデータレコードの構造を指定します。フローキーズ
Data Record extends a particular Template Record that is referenced by its templateId identifier. The Template Record is extended by specifying which of the Information Elements contained in the corresponding Data Records describe Flow properties that serve as Flow Keys of the reported Flow.
データレコードは、そのれるtemplateId識別子によって参照される特定のテンプレートレコードを拡張します。テンプレートレコードは、対応するデータレコードに含まれる情報要素のどの指定することによって拡張され報告されたフローのフローキーとして機能流動特性を記述する。
The Flow Keys Option Template SHOULD contain the following Information Elements that are defined in [RFC5102]:
フローキーオプションテンプレートは、[RFC5102]で定義されている以下の情報要素が含まれている必要があります。
templateId An identifier of a Template. This Information Element MUST be defined as a Scope Field.
テンプレートの識別子をれるtemplateId。この情報要素はスコープフィールドとして定義されなければなりません。
flowKeyIndicator Bitmap with the positions of the Flow Keys in the Data Records.
データレコード内の流れのキーの位置にflowKeyIndicatorビットマップ。
The IPFIX Message Header "Export Time" field is the time in seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message Header leaves the Exporter. The time-related Information Elements specified in [RFC5102] MAY use this "Export Time" as base time and specify an offset relative to it, instead of using a common base time, such as 0000 UTC Jan 1, 1970. All Information Elements that do not have their base time defined by their data type MUST have the base time clearly specified in their description.
IPFIXメッセージヘッダー「エクスポート時間」フィールドには、IPFIXメッセージヘッダは、輸出を離れる時に0000 UTC 1970年1月1日、以来の秒単位の時間です。 [RFC5102]で指定した時間に関連する情報要素は、そのように0000 UTC 1月1日、1970年のすべての情報要素として、基本時間として、この「エクスポート時間」を使用し、それに対する相対オフセットを指定し、代わりに、共通の基準時間を使用するかもしれません彼らの基本時間は明らかにその説明で指定された基準時間を持たなければならない彼らのデータ型で定義されていません。
For example, Data Records requiring a microsecond precision can export the flow start and end times with the flowStartMicroseconds and flowEndMicroseconds Information Elements [RFC5102], containing the time since 0000 UTC Jan 1, 1970. An alternate solution is to export the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [RFC5102] in the Data Record, which respectively report the flow start and end time offsets compared to the IPFIX Message Header "Export Time". The latter solution lowers the export bandwidth requirement while it increases the load on the Exporter, as the Exporting Process must calculate the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds of every single Data Record before exporting the IPFIX Message.
例えば、マイクロ秒の精度を必要とするデータレコードは、0000 UTC 1月1日、1970年の代替ソリューションはflowStartDeltaMicrosecondsとflowEndDeltaMicroseconds情報をエクスポートするための時間を含む、flowStartMicrosecondsとflowEndMicroseconds情報エレメント[RFC5102]と流れの開始および終了時間をエクスポートすることができそれぞれIPFIXメッセージヘッダー「エクスポート時間」に比べ、フローの開始および終了時間オフセットをレポートデータレコード、中の要素[RFC5102]。それは、エクスポートプロセスはIPFIXメッセージをエクスポートする前にすべての単一のデータレコードのflowStartDeltaMicrosecondsとflowEndDeltaMicrosecondsを計算しなければならないので、輸出への負荷が増大しながら、後者の溶液は、エクスポート帯域幅要件を低下させます。
It must be noted that using time-related Information Elements with offset times, compared to the IPFIX Message Header "Export Time", imposes some time constraints on the Data Records contained in the IPFIX Message. In the example of flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [RFC5102], the Data Record must be exported within a maximum of 71 minutes after its creation. Otherwise, the 32-bit counter would not be sufficient to contain the flow start time offset.
IPFIXメッセージヘッダー「エクスポート時間」に比べて、時間をオフセットと時間関連情報要素を使用して、IPFIXメッセージに含まれるデータレコードにいくつかの時間の制約を課すことに留意しなければなりません。 flowStartDeltaMicrosecondsとflowEndDeltaMicroseconds情報エレメント[RFC5102]の例では、データレコードは、その作成後71分の最大以内にエクスポートしなければなりません。そうでない場合は、32ビットカウンタは、オフセット流出開始時間を含むのに十分ではないであろう。
The Information Elements [RFC5102] MUST be sent in canonical format in network-byte order (also known as the big-endian byte ordering).
情報要素[RFC5102]は（もビッグエンディアンバイト順序として知られている）ネットワークバイト順で正規の形式で送らなければなりません。
The following sections will define the encoding of the data types specified in [RFC5102].
以下のセクションでは、[RFC5102]で指定されたデータ・タイプの符号化を定義します。
Integral data types -- octet, signed8, unsigned16, signed16, unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded using the default canonical format in network-byte order. Signed Integral data types are represented in two's complement notation.
積分データ型 - オクテット、signed8、UNSIGNED16、signed16、Unsigned32の、signed32、signed64、およびunsigned64は - ネットワークバイト順にデフォルト標準フォーマットを用いて符号化されなければなりません。符号付き整数データ型は、2の補数で表されます。
Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be encoded the same way as the integral data types. The macAddress is treated as a 6-octet integer, the ipv4Address as a 4-octet integer, and the ipv6Address as a 16-octet integer.
アドレスタイプ - MACADDRESS、IPv4Addressを、そしてipv6Addressは - 整数データ型と同じように符号化されなければなりません。 MACADDRESSは、16オクテットの整数として、6オクテットの整数、4オクテットの整数としてIPv4Addressを、及びipv6Addressとして扱われます。
The float32 data type MUST be encoded as an IEEE single-precision 32-bit floating point-type, as specified in [IEEE.754.1985].
【IEEE.754.1985]で指定されるようにのfloat32データ型は、IEEE単精度32ビット浮動小数点型として符号化されなければなりません。
The float64 data type MUST be encoded as an IEEE double-precision 64-bit floating point-type, as specified in [IEEE.754.1985].
【IEEE.754.1985]で指定されるようにのfloat64データ型は、IEEE倍精度64ビット浮動小数点型として符号化されなければなりません。
The boolean data type is specified according to the TruthValue in [RFC2579]: it is an integer with the value 1 for true and a value 2 for false. Every other value is undefined. The boolean data type MUST be encoded in a single octet.
ブールデータ型は[RFC2579]でのTruthValueに従って指定されている：それは真の値1と偽の値2を有する整数です。他のすべての値は未定義です。ブールデータ型は単一オクテットで符号化されなければなりません。
The data type string represents a finite length string of valid characters of the Unicode character encoding set. The string data type MUST be encoded in UTF-8 format. The string is sent as an array of octets using an Information Element of fixed or variable length.
データ型の文字列は、Unicode文字エンコーディングセットの有効な文字の有限の長さの文字列を表します。文字列データ型は、UTF-8形式でエンコードされなければなりません。文字列は、固定長または可変長の情報要素を用いて、オクテットのアレイとして送信されます。
The length of the Information Element specifies the length of the octetarray.
情報エレメントの長さはoctetarrayの長さを指定します。
The data type dateTimeseconds represents a time value in units of seconds normalized to the GMT timezone. It MUST be encoded in a 32-bit integer containing the number of seconds since 0000 UTC Jan 1, 1970. The 32-bit integer allows the time encoding up to 136 years.
データ型dateTimeseconds GMTタイムゾーンに正規化された秒単位の時間値を表します。 32ビット整数時間が136年までをコードすることができUTC 1月1日、1970年0000からの秒数を含む32ビットの整数に符号化されなければなりません。
The data type dateTimeMilliseconds represents a time value in units of milliseconds normalized to the GMT timezone. It MUST be encoded in a 64-bit integer containing the number of milliseconds since 0000 UTC Jan 1, 1970.
データ型dateTimeMilliseconds GMTタイムゾーンに正規化されたミリ秒単位の時間値を表します。これは、0000 UTC 1970年1月1日からのミリ秒数を含む64ビットの整数に符号化されなければなりません。
The data type dateTimeMicroseconds represents a time value in units of microseconds normalized to the GMT timezone. It MUST be encoded in a 64-bit integer, according to the NTP format given in [RFC1305].
データ型dateTimeMicroseconds GMTタイムゾーンに正規化されたマイクロ秒単位の時間値を表します。これは[RFC1305]で与えられたNTPフォーマットに従って、64ビットの整数に符号化されなければなりません。
The data type of dateTimeNanoseconds represents a time value in units of nanoseconds normalized to the GMT time zone. It MUST be encoded in a 64-bit integer, according to the NTP format given in [RFC1305].
dateTimeNanosecondsのデータ型は、GMTタイムゾーンに正規化ナノ秒単位の時間値を表します。これは[RFC1305]で与えられたNTPフォーマットに従って、64ビットの整数に符号化されなければなりません。
Information Elements containing integer, string, float, and octetarray types in the information model MAY be encoded using fewer octets than those implied by their type in the information model definition [RFC5102], based on the assumption that the smaller size is sufficient to carry any value the Exporter may need to deliver. This reduces the network bandwidth requirement between the Exporter and the Collector. Note that the Information Element definitions [RFC5102] will always define the maximum encoding size.
情報モデルの整数、文字列、フロート、及びoctetarrayタイプを含む情報要素は、より小さなサイズは、任意のを運ぶのに十分であるという仮定に基づいて、情報モデルの定義[RFC5102]にそれらのタイプによって暗示されるものよりも少ないオクテットを使用して符号化することができます値Exporterは提供する必要があるかもしれません。これは、輸出業者とコレクタ間のネットワーク帯域幅の要件を低減します。情報要素の定義[RFC5102]は常に最大符号化サイズを定義することに注意してください。
For instance, the information model [RFC5102] defines byteCount as an unsigned64 type, which would require 64 bits. However, if the Exporter will never locally encounter the need to send a value larger than 4294967295, it may chose to send the value instead as an unsigned32. For example, a core router would require an unsigned64 byteCount, while an unsigned32 might be sufficient for an access router.
例えば、情報モデル[RFC5102]は64ビットを必要とするであろうunsigned64はタイプとして定義：バイト。輸出業者がローカル4294967295より大きい値を送信する必要が発生したことはありませんしかし、もし、それがUnsigned32のよう代わりに値を送信することを選択することができます。 Unsigned32のは、アクセスルータには十分かもしれませんしながら、例えば、コアルータは、unsigned64は：バイトを必要とします。
This behavior is indicated by the Exporter by specifying a type size with a smaller length than that associated with the assigned type of the Information Element. In the example above, the Exporter would place a length of 4 versus 8 in the Template.
この現象は、情報要素の割り当てタイプに関連付けられているよりも小さい長さと文字サイズを指定することによって、輸出業者によって示されています。上記の例では、輸出は、テンプレートに8対4の長さを置くことになります。
If reduced sizing is used, it MUST only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16. The signed versus unsigned property of the reported value MUST be preserved. The reduction in size can be to any number of octets smaller than the original type if the data value still fits, i.e., so that only leading zeroes are dropped. For example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).
unsigned64は、signed64、Unsigned32の、signed32、UNSIGNED16、およびsigned16：縮小サイズが使用されている場合、それだけで次の整数型に適用されなければなりません。報告された値の符号なしプロパティに対する署名が保存されなければなりません。唯一の先行ゼロがドロップされるように小型化、即ちオクテットデータ値が依然として収まる場合、元の型よりも小さく、任意の数にすることができます。例えば、unsigned64は、7、6、5、4、3、2、または1つのオクテット（単数または複数）に小型化することができます。
Reduced sizing can also be used to reduce float64 to float32. The float32 not only has a reduced number range, but due to the smaller mantissa, is also less precise.
減少サイジングはまたのfloat32へのfloat64を低減するために使用することができます。 float32は、低減された数の範囲を有するが、より小さい仮数に起因し、またあまり正確ではないだけ。
The reduced size encoding MUST NOT be applied to dateTimeMicroseconds or to dateTimeNanoseconds because these represent an inherent structure that would be destroyed by using less than the original number of bytes.
これらのバイトの元の数よりも少ないを使用して破壊される固有の構造を表すために縮小サイズの符号化はdateTimeMicrosecondsまたはdateTimeNanosecondsに適用してはいけません。
The IPFIX Template mechanism is optimized for fixed-length Information Elements [RFC5102]. Where an Information Element has a variable length, the following mechanism MUST be used to carry the length information for both the IETF and proprietary Information Elements.
IPFIXテンプレート機構は、固定長の情報エレメント[RFC5102]のために最適化されています。情報要素は、可変長を有する場合、以下のメカニズムは、IETFおよび専有情報要素の両方のための長さの情報を搬送するために使用されなければなりません。
In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that length of the Information Element will be carried in the Information Element content itself.
テンプレートセットにおいて、情報要素フィールド長はこの予約長さの値は、情報要素の長さは、情報要素コンテント自体に実施される収集プロセスに通知65535として記録されます。
In most cases, the length of the Information Element will be less than 255 octets. The following length-encoding mechanism optimizes the overhead of carrying the Information Element length in this majority case. The length is carried in the octet before the Information Element, as shown in Figure R.
ほとんどの場合、情報エレメントの長さが255個の未満のオクテットになります。以下の長さの符号化機構は、この大多数の場合には情報要素長を搬送するオーバーヘッドを最適化します。図R.に示すように長さが、情報要素のオクテット前に実施されます
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)| Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure R: Variable-Length Information Element (length < 255 octets)
図R：可変長情報エレメント（長さ<255オクテット）
If the length of the Information Element is greater than or equal to 255 octets, the length is encoded into 3 octets before the Information Element. The first octet is 255, and the length is carried in the second and third octets, as shown in Figure S.
情報要素の長さがより大きいか255個のオクテットに等しい場合、長さは、情報要素の前に3つのオクテットに符号化されます。最初のオクテットは255であり、図S.に示すように長さが、第二及び第三オクテットで搬送されます
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) | IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure S: Variable-Length Information Element (length 0 to 65535 octets)
図S：可変長情報エレメント（長さ0〜65535オクテット）
The octets carrying the length (either the first or the first three octets) MUST NOT be included in the length of the Information Element.
長さ（第一または第3オクテットのいずれか）を有するオクテットは情報要素の長さに含まれてはいけません。
This section describes Template Management when using SCTP and PR-SCTP as the transport protocol. Any necessary changes to Template Management specifically related to TCP or UDP transport protocols are specified in Section 10.
トランスポートプロトコルとしてSCTPとPR-SCTPを使用する場合は、このセクションでは、テンプレートの管理について説明します。特にTCPやUDPのトランスポートプロトコルに関連したテンプレート管理に必要な変更は、セクション10で指定されています。
The Exporting Process assigns and maintains the Template IDs per SCTP association for the Exporter's Observation Domains. A newly created Template Record is assigned an unused Template ID by the Exporting Process.
エクスポートプロセスは、割り当てや輸出の観測ドメインのSCTPアソシエーションごとにテンプレートIDを維持します。新しく作成されたテンプレートレコードは、エクスポートプロセスによって使用されていないテンプレートIDが割り当てられます。
If a specific Information Element is required by a Template, but is not available in observed packets, the Exporting Process MAY choose to export Flow Records without this Information Element in a Data Record defined by a new Template.
特定の情報要素がテンプレートによって要求されるが、観測されたパケットで利用できない場合、エクスポートプロセスは、新しいテンプレートで定義されたデータレコードにこの情報要素なしでフローレコードをエクスポートすることを選ぶかもしれ。
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. For example, if a selected packet goes through two hash functions, and if the two hash values are sent within a single Template, the first occurrence of the hash value should belong to the first hash function in the Metering Process. For example, when exporting the two source IP addresses of an IPv4 in IPv4 packets, the first sourceIPv4Address Information Element occurrence should be the IPv4 address of the outer header, while the second occurrence should be the inner header one.
情報要素は、テンプレートで複数回必要な場合は、この情報要素の異なる出現は、計量法によるそれらの治療の論理的な順序に従ってください。例えば、選択されたパケットは、2つのハッシュ関数を通過する場合、および2つのハッシュ値が単一のテンプレート内で送信された場合、ハッシュ値の最初の発生は、計量プロセスにおける第1のハッシュ関数に属するべきです。 IPv4パケットのIPv4での二つのソースIPアドレスをエクスポートするときに、第2の発生が内部ヘッダものでなければならないしながら、例えば、第一sourceIPv4Address情報要素の発生は、外部ヘッダのIPv4アドレスであるべきです。
Template Sets and Options Template Sets may be sent on any SCTP stream. Template Sets and Options Template Sets MUST be sent reliably, using SCTP-ordered delivery. As such, the Collecting Process MUST store the Template Record information for the duration of the SCTP association so that it can interpret the corresponding Data Records that are received in subsequent Data Sets.
テンプレートセットとオプションテンプレートセットは、任意のSCTPストリームで送信することができます。テンプレートセットとオプションテンプレートセットは、SCTP-注文の配信を使用して、確実に送らなければなりません。このように、収集プロセスは、後続のデータセットで受信され、対応するデータレコードを解釈できるように、SCTPアソシエーションの期間テンプレートレコード情報を格納しなければなりません。
The Exporting Process SHOULD transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID, to help ensure that the Collector has the Template Record before receiving the first Data Record. Data Records that correspond to a Template Record MAY appear in the same and/or subsequent IPFIX Message(s).
エクスポートプロセスは、コレクタが第一のデータレコードを受信する前にテンプレートレコードを持っていることを保証するために、その（オプション）テンプレートIDを使用して任意のデータセットの事前にテンプレートセットとオプションテンプレートセットを送信しなければなりません。テンプレートレコードに対応するデータレコードは、同一のおよび/または後続のIPFIXメッセージ（単数または複数）に表示されることがあります。
Different Observation Domains from the same SCTP association may use the same Template ID value to refer to different Templates.
同じSCTPアソシエーション異なる観測ドメインは、異なるテンプレートを参照するために同じテンプレートID値を使用してもよいです。
The Templates that are not used anymore SHOULD be deleted. 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.
もう使用されていないテンプレートを削除する必要があります。テンプレートIDを再利用する前に、テンプレートを削除する必要があります。割り当てられたテンプレートを削除するために、テンプレートは、テンプレート無効化メッセージの使用を介して引き出されます。
The Template Withdrawal Message MUST NOT be sent until sufficient time has elapsed to allow the Collecting Process to receive and process the last Data Record using this Template information. This time MUST be configurable. A suitable default value is 5 seconds after the last Data Record has been sent.
十分な時間が収集プロセスは、このテンプレートの情報を使用して、最後のデータレコードを受信して処理できるように経過するまで、テンプレート無効化メッセージを送ってはいけません。この時間は、構成可能でなければなりません。最後のデータレコードが送られた後、適切なデフォルト値は5秒です。
The Template ID from a withdrawn Template MUST NOT be reused until sufficient time has elapsed to allow for the Collecting Process to receive and process the Template Withdrawal Message.
十分な時間がテンプレート無効化メッセージを受信して処理するために収集プロセスを可能にするために、経過するまで引き抜かテンプレートからテンプレートIDを再利用してはいけません。
A Template Withdrawal Message is a Template Record for that Template ID with a Field Count of 0. The format of the Template Withdrawal Message is shown in Figure T.
テンプレート離脱メッセージは、図T.に示されている0テンプレート無効化メッセージのフォーマットのフィールドカウントとそのテンプレートIDのテンプレートレコードであります
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 or 3) | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID N | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID ... | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID M | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure T: Template Withdrawal Message Format
図T：テンプレート無効化メッセージのフォーマット
The Set ID field MUST contain the value 2 for Template Set Withdrawal and the value 3 for Options Template Set Withdrawal. Multiple Template IDs MAY be withdrawn with a single Template Withdrawal Message, in that case, padding MAY be used.
セットIDフィールドには、テンプレートセットの撤退のための値2とオプションテンプレートセットの撤退のために値3を含まなければなりません。複数のテンプレートIDは、その場合には、パディングを使用することができる、単一のテンプレート離脱メッセージで引き出すことができます。
The Template Withdrawal Message withdraws the Template IDs for the Observation Domain ID specified in the IPFIX Message Header.
テンプレート無効化メッセージはIPFIXメッセージヘッダに指定された観測ドメインIDのテンプレートIDを取り下げました。
The Template Withdrawal Message may be sent on any SCTP stream. The Template Withdrawal Message MUST be sent reliably, using SCTP-ordered delivery.
テンプレート無効化メッセージは、任意のSCTPストリームで送信することができます。テンプレート無効化メッセージは、SCTP-注文の配信を使用して、確実に送らなければなりません。
The Template Withdrawal Message MUST NOT contain new Template or Options Template Records.
テンプレート無効化メッセージは、新しいテンプレートやオプションテンプレートレコードを含めることはできません。
If the measurement parameters change such that a new Template is required, the Template MUST be withdrawn (using a Template Withdraw Message and a new Template definition) or an unused Template ID MUST be used. Examples of the measurement changes are: a new sampling rate, a new Flow expiration process, a new filtering definition, etc.
測定パラメータは、新しいテンプレートが必要とされるように変更した場合、テンプレートは（メッセージおよび新たなテンプレート定義を引き出しテンプレートを使用して）引き出さなければならない、または未使用のテンプレートIDを使用しなければなりません。測定の変化の例としては、など、新たなサンプリングレート、新しいフローの有効期限のプロセス、新しいフィルタの定義、
When the SCTP association shuts down or the Exporting Process restarts, all Template assignments are lost and Template IDs MUST be reassigned.
SCTPアソシエーションがシャットダウンまたはエクスポートプロセスが再起動すると、すべてのテンプレートの割り当てが失われ、テンプレートIDを再割り当てする必要があります。
If the Metering Process restarts, the Exporting Process MUST either reuse the previously assigned Template ID for each Template, or it MUST withdraw the previously issued Template IDs by sending Template Withdraw Message(s) before reusing them.
計量プロセスを再起動する場合は、エクスポートプロセスは、各テンプレートの以前に割り当てられたテンプレートIDを再利用しなければならないか、それはそれらを再利用する前に、メッセージ（複数可）を撤回テンプレートを送信することにより、以前に発行されたテンプレートのIDを撤回しなければなりません。
A Template Withdrawal Message to withdraw all Templates for the Observation Domain ID specified in the IPFIX Message Header MAY be used. Its format is shown in Figure U.
IPFIXメッセージヘッダに指定された観測ドメインIDのためのすべてのテンプレートを撤回するテンプレート無効化メッセージを使用することができます。そのフォーマットを図U.に示されています
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 = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 2 | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure U: All Data Templates Withdrawal Message Format
図U：すべてのデータのテンプレート無効化メッセージのフォーマット
A Template Withdrawal Message to withdraw all Options Templates for the Observation Domain ID specified in the IPFIX Message Header MAY be used. Its format is shown in Figure V.
IPFIXメッセージヘッダに指定された観測ドメインIDのすべてのオプションのテンプレートを撤回するテンプレート無効化メッセージを使用することができます。そのフォーマットは図Vに示されています
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 = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 3 | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure V: All Options Templates Withdrawal Message Format
図V：すべてのオプションのテンプレート無効化メッセージのフォーマット
When the SCTP association restarts, the Exporting Process MUST resend all the Template Records.
SCTPアソシエーションが再起動すると、エクスポートプロセスは、すべてのテンプレートレコードを再送信する必要があります。
This section describes the Collecting Process when using SCTP and PR-SCTP as the transport protocol. Any necessary changes to the Collecting Process specifically related to TCP or UDP transport protocols are specified in Section 10.
トランスポートプロトコルとしてSCTPとPR-SCTPを使用する場合、このセクションでは、収集プロセスを記載しています。具体的にはTCPまたはUDPトランスポートプロトコルに関連する収集プロセスに必要な変更はセクション10で指定されています。
The Collecting Process SHOULD listen for a new association request from the Exporting Process. The Exporting Process will request a number of streams to use for export. An Exporting Process MAY request and support more than one stream per SCTP association.
収集プロセスは、エクスポートプロセスから新しいアソシエーション要求をリッスンすべきです。エクスポートプロセスは、輸出のために使用するストリームの数を要求します。エクスポートプロセスMAY要求とSCTPアソシエーションごとに複数のストリームをサポートしています。
If the Collecting Process receives a malformed IPFIX Message, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error. Note that non-zero Set padding does not constitute a malformed IPFIX Message.
収集プロセスが不正IPFIXメッセージを受信した場合、それはIPFIXメッセージを破棄し、SCTPアソシエーションをリセットする必要があり、エラーをログに記録すべきです。非ゼロセットパディングが不正な形式のIPFIXメッセージを構成するものではないことに注意してください。
Template Sets and Option Template Sets are only sent once. The Collecting Process MUST store the Template Record information for the duration of the association so that it can interpret the corresponding Data Records that are received in subsequent Data Sets.
テンプレートセットとオプションテンプレートセットは一度だけ送信されます。それは後続のデータセットで受信され、対応するデータレコードを解釈できるように、収集プロセスは、関連付けの持続時間のためのテンプレートレコードの情報を格納しなければなりません。
Template IDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives a Template that has already been received but that has not previously been withdrawn (i.e., a Template Record from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shut down the association.
テンプレートIDは、SCTP協会あたりと観測ドメインごとに一意です。収集プロセスが既に受信されているテンプレートを受信するが、それは以前に引き出されていない場合（すなわち、IDはSCTPアソシエーション上で受信された同じテンプレートと同じ輸出観測ドメインからテンプレートレコード）、次いで、収集プロセスは停止する必要があります協会。
When an SCTP association is closed, the Collecting Process MUST discard all Templates received over that association and stop decoding IPFIX Messages that use those Templates.
SCTPアソシエーションが閉じられたときに、収集プロセスは、すべてのテンプレートを破棄しなければならないことアソシエーションを介して受信し、これらのテンプレートを使用IPFIXメッセージをデコード停止。
The Collecting Process normally receives Template Records from the Exporting Process before receiving Data Records. The Data Records are then decoded and stored by the Collector. If the Template Records have not been received at the time Data Records are received, the Collecting Process MAY store the Data Records for a short period of time and decode them after the Template Records are received. A Collecting Process MUST NOT assume that the Data Set and the associated Template Set (or Options Template Set) are exported in the same IPFIX Message.
収集プロセスは、通常、データレコードを受信する前にエクスポートプロセスからテンプレートレコードを受け取ります。データレコードは、復号化され、コレクタによって保存されます。テンプレートレコードは、データレコードが受信された時点で受信されていない場合は、収集プロセスは時間の短い期間のためのデータレコードを格納してもよいし、テンプレートレコードを受信した後にそれらをデコードします。収集プロセスは、データセットと関連するテンプレートセット（またはオプションテンプレートセット）が同じIPFIXメッセージにエクスポートされると仮定してはいけません。
The 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.
収集プロセスは、それが理解できないと捨てるかもしれ任意の情報要素の情報要素識別子を注意しなければならないフローレコードからの情報エレメントいます。
The Collector MUST accept padding in Data Records and Template Records. The padding size is the Set Length minus the size of the Set Header (4 octets for the Set ID and the Set Length), modulo the Record size deduced from the Template Record.
コレクターは、データレコードとテンプレートレコードでパディングを受け入れなければなりません。パディングサイズが設定された長さマイナスセットヘッダのサイズ（設定IDと設定された長さは4つのオクテット）である、テンプレートレコードから推定レコードサイズを法。
The IPFIX protocol has a Sequence Number field in the Export header that increases with the number of IPFIX Data Records in the IPFIX Message. A Collector may detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. A Collector SHOULD provide a logging mechanism for tracking out-of-sequence IPFIX Messages. Such out-of-sequence IPFIX Messages may be due to Exporter resource exhaustion where it cannot transmit messages at their creation rate, an Exporting Process reset, congestion on the network link between the Exporter and Collector, Collector resource exhaustion where it cannot process the IPFIX Messages at their arrival rate, out-of-order packet reception, duplicate packet reception, or an attacker injecting false messages.
IPFIXプロトコルはIPFIXメッセージにIPFIXデータレコードの数と共に増加エクスポートヘッダ内のシーケンス番号フィールドを有しています。コレクタは、ドロップアウトオブシーケンス検出、またはシーケンス番号を追跡することによってIPFIXメッセージを複製することができます。コレクターは、アウトオブシーケンスIPFIXメッセージを追跡するためのロギングメカニズムを提供する必要があります。そのようなアウトオブシーケンスIPFIXメッセージは、それが彼らの作成速度、エクスポートプロセスのリセット、エクスポータとコレクタとの間のネットワーク・リンク上の混雑、それはIPFIXを処理できないコレクターリソースの枯渇にメッセージを送信することができない資源の枯渇を輸出に起因し得ます彼らの到着率でメッセージ、アウトオブオーダーパケット受信、重複パケット受信、または偽のメッセージを注入する攻撃。
If a Collecting Process receives a Template Withdrawal Message, the Collecting Process MUST delete the corresponding Template Records associated with the specific SCTP association and specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates.
収集プロセスがテンプレート無効化メッセージを受信した場合、収集プロセスは、特定のSCTPアソシエーション及び特定観測ドメインに関連付けられた対応するテンプレートレコードを削除し、そして引き抜かテンプレートを使用IPFIXメッセージをデコード停止しなければなりません。
If the Collecting Process receives a Template Withdraw message for a Template Record it has not received before on this SCTP association, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages.
収集プロセスは、テンプレートは、それがこのSCTPアソシエーション上で前に受信していないテンプレートレコードのメッセージを撤回受信した場合、それは、SCTPアソシエーションをリセットIPFIXメッセージを破棄し、それが不正な形式のIPFIXメッセージの場合と同様にエラーをログに記録すべきであるしなければなりません。
A Collecting Process that receives IPFIX Messages from several Observation Domains on the same Transport Session MUST be aware that the uniqueness of the Template ID is not guaranteed across Observation Domains.
同じトランスポートセッションでいくつかの観測ドメインからIPFIXメッセージを受け取り、収集プロセスは、テンプレートIDの一意性は観察ドメイン間で保証されていないことを認識する必要があります。
The Collector MUST support the use of Templates containing multiple occurrences of the similar Information Elements.
コレクターは、同様の情報要素の複数の発生を含むテンプレートの使用をサポートしなければなりません。
The IPFIX Protocol Specification has been designed to be transport protocol independent. Note that the Exporter can export to multiple Collecting Processes using independent transport protocols.
IPFIXプロトコル仕様は、トランスポートプロトコルに依存しないように設計されています。輸出業者は、独立したトランスポートプロトコルを使用して複数の収集プロセスにエクスポートすることもできます。
The IPFIX Message Header 16-bit Length field limits the length of an IPFIX Message to 65535 octets, including the header. A Collecting Process MUST be able to handle IPFIX Message lengths of up to 65535 octets.
IPFIXメッセージヘッダー16ビット長のフィールドは、ヘッダを含め65535個のオクテットにIPFIXメッセージの長さを制限します。収集プロセスは、最大65535オクテットのIPFIXメッセージの長さを扱うことができなければなりません。
We need to differentiate between what must be implemented (so that operators can interoperably deploy compliant implementations from different vendors) and what should or could be used in various operational environments. We must also make sure that ALL implementations can operate in a congestion-aware and congestion-avoidance mode.
私たちは、実装する必要があります（演算子は、相互運用異なるベンダーから準拠した実装を配備することができるように）、何がまたは様々な運用環境で使用することができなければならないものを区別する必要があります。我々はまた、すべての実装が輻輳を意識し、輻輳回避モードで動作できることを確認する必要があります。
SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] MUST be implemented by all compliant implementations. UDP [UDP] MAY also be implemented by compliant implementations. TCP [TCP] MAY also be implemented by compliant implementations.
[RFC3758]で指定されたPR-SCTP拡張を使用して、SCTP [RFC4960]は、すべての対応する実装によって実装されなければなりません。 UDP [UDP]にも準拠した実装によって実現することができます。 TCP [TCP]も準拠した実装によって実現することができます。
PR-SCTP SHOULD be used in deployments where Exporters and Collectors are communicating over links that are susceptible to congestion. PR-SCTP is capable of providing any required degree of reliability.
PR-SCTPは、輸出やコレクターが混雑の影響を受けやすいリンクを介して通信している展開で使用されるべきです。 PR-SCTPは、信頼性の任意の必要な度合いを提供することが可能です。
TCP MAY be used in deployments where Exporters and Collectors communicate over links that are susceptible to congestion, but PR-SCTP is preferred due to its ability to limit back pressure on Exporters and its message versus stream orientation.
輸出への圧力と流れの向きに対して、そのメッセージをバックに制限する能力にTCPは、輸出やコレクターが混雑の影響を受けやすいリンクを介して通信する展開で使用されてもよいが、PR-SCTPが好ましいです。
UDP MAY be used, although it is not a congestion-aware protocol. However, the IPFIX traffic between Exporter and Collector MUST run in an environment where IPFIX traffic has been provisioned for, or is contained through some other means.
それは混雑を認識プロトコルではありませんが、UDPを使用することができます。しかし、輸出業者やコレクターの間でIPFIXトラフィックはIPFIXトラフィックをプロビジョニングされた、またはいくつかの他の手段を介して収容されている環境で実行する必要があります。
This section describes how IPFIX can be transported over SCTP [RFC4960] using the PR-SCTP [RFC3758] extension.
このセクションでは、IPFIXは、PR-SCTP [RFC3758]拡張を使用して、SCTP [RFC4960]を介して転送することができる方法について説明します。
The SCTP transport protocol provides the required level of congestion avoidance by design.
SCTPトランスポートプロトコルを設計することによって、輻輳回避の必要なレベルを提供します。
SCTP will detect congestion in the end-to-end path between the IPFIX Exporting Process and the IPFIX Collecting Process, and limit the transfer rate accordingly. When an IPFIX Exporting Process has records to export, but detects that transmission by SCTP is temporarily impossible, it can either wait until sending is possible again, or it can decide to drop the record. In the latter case, the dropped export data MUST be accounted for, so that the amount of dropped export data can be reported.
SCTPは、IPFIXエクスポートプロセスとIPFIX収集プロセスの間のエンドツーエンドのパスの輻輳を検出し、それに応じて転送速度を制限します。 IPFIXエクスポートプロセスがエクスポートするレコードを持っていますが、SCTPによる送信が一時的に不可能であることを検出すると、それが再び可能である、またはそれがレコードをドロップすることを決定することができ、送信されるまで待つことができます。ドロップされたエクスポート・データの量を報告することができるように、後者の場合には、ドロップされたエクスポートデータは、考慮しなければなりません。
The SCTP transport protocol is by default reliable, but has the capability to deliver messages with partial reliability [RFC3758].
SCTPトランスポートプロトコルは、デフォルトでは信頼性があるが、部分的に信頼性[RFC3758]でメッセージを配信する機能があります。
Using reliable SCTP messages for the IPFIX export is not in itself a guarantee that all Data Records will be delivered. If there is congestion on the link from the Exporting Process to the Collecting Process, or if a significant number of retransmissions are required, the send queues on the Exporting Process may fill up; the Exporting Process MAY either suspend, export, or discard the IPFIX Messages. If Data Records are discarded the IPFIX Sequence Numbers used for export MUST reflect the loss of data.
IPFIXのエクスポート用に信頼性の高いSCTPメッセージを使用すると、自分自身にすべてのデータレコードが配信されること保証するものではありません。収集プロセスへのエクスポートプロセスからのリンクで輻輳がある場合は、再送信のかなりの数が必要な場合、または、エクスポートプロセス上の送信キューがいっぱいあり;エクスポートプロセスは、輸出を一時停止、またはIPFIXメッセージを捨てるかもしれいずれか。データレコードが破棄された場合は、輸出のために使用さIPFIXのシーケンス番号は、データの損失を反映しなければなりません。
SCTP provides the required IPFIX Message fragmentation service based on path MTU discovery.
SCTPは、パスMTUの発見に基づいて、必要なIPFIXメッセージの断片化のサービスを提供しています。
The IPFIX Exporting Process SHOULD initiate an SCTP association with the IPFIX Collecting Process. By default, the Collecting Process listens for connections on SCTP port 4739. By default, the Collecting Process listens for secure connections on SCTP port 4740 (refer to the Security Considerations section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting and Collecting Processes to use a different SCTP port.
IPFIXエクスポートプロセスはIPFIX収集プロセスとのSCTPアソシエーションを開始すべきです。デフォルトでは、収集プロセスは、デフォルトでSCTPポート4739.上の接続を待機し、収集プロセスはSCTPポート4740上のセキュアな接続（セキュリティに関する考慮事項のセクションを参照）をリッスンします。デフォルトでは、エクスポートプロセスは、これらのポートの1つに接続しようとします。別のSCTPポートを使用するようにエクスポートと収集プロセスの両方を設定することは可能でなければなりません。
The Exporting Process MAY establish more than one association (connection "bundle" in SCTP terminology) to the Collecting Process.
エクスポートプロセスは、収集プロセスに複数のアソシエーション（SCTPの用語で接続「バンドル」）を確立することができます。
An Exporting Process MAY support more than one active association to different Collecting Processes (including the case of different Collecting Processes on the same host).
エクスポートプロセスは、（同じホスト上の異なる収集プロセスの場合を含む）は、異なる収集プロセスに複数のアクティブ・アソシエーションをサポートするかもしれません。
When an Exporting Process is shut down, it SHOULD shut down the SCTP association.
エクスポートプロセスがシャットダウンされたとき、それはSCTPアソシエーションを停止すべきです。
When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD shut down its end of the association. The Collecting Process SHOULD continue to receive and process IPFIX Messages until the Exporting Process has closed its end of the association.
収集プロセスは、もはやIPFIXメッセージを受信したい場合は、協会の終わりにシャットダウンするべきではありません。収集プロセスは、エクスポートプロセスは、アソシエーションのその端部を閉鎖するまでIPFIXメッセージを受信して処理を継続すべきです。
When a Collecting Process detects that the SCTP association has been abnormally terminated, it MUST continue to listen for a new association establishment.
収集プロセスはSCTPアソシエーションが異常終了したことを検出すると、それは新しいアソシエーションの確立をリッスンし続けなければなりません。
When an Exporting Process detects that the SCTP association to the Collecting Process is abnormally terminated, it SHOULD try to re-establish the association.
エクスポートプロセスは、収集プロセスへのSCTPアソシエーションが異常終了したことを検出すると、それが関連を再確立しようとする必要があります。
Association timeouts SHOULD be configurable.
協会のタイムアウトは設定可能であるべきです。
An Exporting Process MAY request more than one SCTP stream per association. Each of these streams may be used for the transmission of IPFIX Messages containing Data Sets, Template Sets, and/or Options Template Sets.
エクスポートプロセスは、関連ごとに複数のSCTPストリームを要求することができます。これらのストリームの各データセットを含むIPFIXメッセージ、テンプレートセット、および/またはオプションテンプレートセットの送信のために使用することができます。
Depending on the requirements of the application, the Exporting Process may send Data Sets with full or partial reliability, using ordered or out-of-order delivery, over any SCTP stream established during SCTP Association setup.
アプリケーションの要件に応じて、データを送信することがエクスポートプロセスはSCTP協会のセットアップ時に確立任意のSCTPストリーム上で、注文やアウトオブオーダー配信を使用して、完全または部分的な信頼性を持って設定します。
An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as per Section 4 of the PR-SCTP [RFC3758] specification when using partial reliability to transmit IPFIX Messages containing only Data Sets.
唯一のデータセットを含むIPFIXメッセージを送信するために部分的信頼性を使用する場合IPFIXエクスポートプロセスは、PR-SCTP [RFC3758]仕様のセクション4に従って任意PR-SCTPサービス定義を使用するかもしれません。
However, Exporting Processes SHOULD mark such IPFIX Messages for retransmission for as long as resource or other constraints allow.
しかし、エクスポートプロセスは限りリソースまたは他の制約が許す限りのために再送信のために、このようなIPFIXメッセージをマークすべきです。
When the transport protocol is SCTP, the default Template Management described in Section 8 is used.
トランスポートプロトコルがSCTPである場合には、テンプレート管理はセクション8で説明したデフォルトが使用されます。
When the transport protocol is SCTP, the default Collector processing described in Section 9 is used.
トランスポートプロトコルがSCTPである場合、第9章で説明されているデフォルトのコレクタ処理が使用されます。
If the Collecting Process does not acknowledge the attempt by the Exporting Process to establish an association, the Exporting Process should retry using the SCTP exponential backoff feature. The Exporter MAY log an alarm if the time to establish the association exceeds a specified threshold, configurable on the Exporter.
収集プロセスは、関連付けを確立するために、エクスポートプロセスによって試みを認めていない場合は、エクスポートプロセスはSCTP指数バックオフ機能を使用して再試行する必要があります。アソシエーションを確立するための時間がエクスポータで設定指定されたしきい値を超えると輸出業者は、アラームを記録することがあります。
If Collecting Process failover is supported by the Exporting Process, a second SCTP association MAY be opened in advance.
収集処理のフェイルオーバーがエクスポートプロセスによってサポートされている場合、第二SCTPアソシエーションが事前に開くことができます。
This section describes how IPFIX can be transported over UDP [UDP].
このセクションでは、IPFIXはUDP [UDP]を介して輸送することができる方法を説明します。
UDP has no integral congestion-avoidance mechanism. Its use over congestion-sensitive network paths is therefore not recommended. UDP MAY be used in deployments where Exporters and Collectors always communicate over dedicated links that are not susceptible to congestion, i.e., over provisioned links compared to the maximum export rate from the Exporters.
UDPには不可欠な輻輳回避メカニズムを持っていません。混雑に敏感なネットワークパス以上、その使用はそのため推奨されません。 UDPは、輸出業者とコレクタは常に、すなわち、輸出業者からの最大の輸出率に比べプロビジョニングリンク上で、輻輳を受けない専用リンクを介して通信する展開で使用されるかもしれません。
UDP is not a reliable transport protocol, and cannot guarantee delivery of messages. IPFIX Messages sent from the Exporting Process to the Collecting Process using UDP may therefore be lost. UDP MUST NOT be used unless the application can tolerate some loss of IPFIX Messages.
UDPは信頼性の高いトランスポートプロトコルではなく、メッセージの配信を保証することはできません。 UDPを使用して収集プロセスにエクスポートプロセスから送信されたIPFIXメッセージは、したがって失われる可能性があります。アプリケーションがIPFIXメッセージのいくつかの損失を許容することができない限り、UDPを使用してはいけません。
The Collecting Process SHOULD deduce the loss and reordering of IPFIX Data Records by looking at the discontinuities in the IPFIX Sequence Number. In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the UDP Transport Session prior to the receipt of this IPFIX Message, modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. Templates sent from the Exporting Process to the Collecting Process using UDP as a transport MUST be re-sent at regular intervals, in case previous copies were lost.
収集プロセスはIPFIXのシーケンス番号の不連続性を見ることで、IPFIXデータレコードの損失や並べ替えを推測すべきです。 UDPの場合は、IPFIXシーケンス番号が前にこのIPFIXメッセージ、剰余2 ^ 32の受信にUDPトランスポート・セッションのために送られたIPFIXデータレコードの合計数が含まれています。コレクタは、ドロップアウトオブシーケンス検出、またはシーケンス番号を追跡することによってIPFIXメッセージを複製すべきです。トランスポートとしてUDPを使用して収集プロセスにエクスポートプロセスから送信されたテンプレートは、以前のコピーが失われた場合には、一定の間隔で再送信されなければなりません。
The maximum size of exported messages MUST be configured such that the total packet size does not exceed the path MTU. If the path MTU is unknown, a maximum packet size of 512 octets SHOULD be used.
エクスポートされたメッセージの最大サイズは、全パケットサイズがパスMTUを超えないように構成されなければなりません。パスMTUが不明の場合は、512オクテットの最大パケット・サイズを使用すべきです。
By default, the Collecting Process listens on the UDP port 4739. By default, the Collecting Process listens for secure connections on UDP port 4740 (refer to the "Security Considerations" section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting and Collecting Processes to use a different UDP port.
デフォルトでは、収集プロセスは、デフォルトでは4739.は、収集プロセスは、UDPポート4740上のセキュアな接続（「セキュリティに関する考慮事項」を参照）をリッスンするUDPポートでリッスンします。デフォルトでは、エクスポートプロセスは、これらのポートの1つに接続しようとします。異なるUDPポートを使用してエクスポートおよび収集プロセスの両方を設定することは可能でなければなりません。
The Exporting Process MAY duplicate the IPFIX Message to the several Collecting Processes.
エクスポートプロセスは、いくつかの収集プロセスにIPFIXのメッセージを複製してもよい（MAY）。
When IPFIX uses UDP as the transport protocol, Template Sets and Option Template Sets MUST be re-sent at regular intervals. The frequency of the (Options) Template transmission MUST be configurable. The default value for the frequency of the (Options) Template transmission is 10 minutes. The Exporting Process SHOULD transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID to help ensure that the
IPFIXがトランスポートプロトコルとしてUDPを使用する場合、テンプレートセットとオプションテンプレートセットは、定期的に再送信しなければなりません。 （オプション）テンプレートの送信の周波数は設定可能でなければなりません。 （オプション）テンプレートの送信周波数のデフォルト値は10分です。エクスポートプロセスは、（オプション）テンプレートIDを確保するためにことを使用するすべてのデータセットの前にテンプレートセットとオプションテンプレートセットを送信する必要があること
Collector has the Template Record before receiving the first Data Record.
コレクターは、最初のデータレコードを受信する前にテンプレートレコードを持っています。
In the event of configuration changes, the Exporting Process SHOULD send multiple copies of the new Template definitions, in different IPFIX Messages, at an accelerated rate. In such a case, it SHOULD transmit the changed Template Record(s) and Options Template Record(s), without any data, in advance to help ensure that the Collector will have the correct Template information before receiving the first data.
設定変更の場合に、エクスポートプロセスは加速速度で、異なるIPFIXメッセージに、新しいテンプレート定義の複数のコピーを送信すべきです。このような場合には、コレクタは、最初のデータを受信する前に、正しいテンプレートの情報を持つことを保証するために、事前に、任意のデータなしに、変更テンプレートレコード（複数可）とオプションテンプレートレコード（複数可）を送信しなければなりません。
If the Option Template scope is defined in another Template, then both Templates SHOULD be sent in the same IPFIX Message. For example, if a Flow Key Option Template (see Section 4.4) is sent in an Option Template, then the associated Template SHOULD be sent in the same IPFIX Message.
オプションテンプレートスコープが別のテンプレートで定義されている場合、両方のテンプレートが同じIPFIXメッセージで送信されるべきです。オプションテンプレートに送られるフローキーオプションテンプレート（4.4節を参照）場合、例えば、その後、関連するテンプレートは同じIPFIXメッセージで送信されるべきです。
Following a configuration change that can modify the interpretation of the Data Records (for example, a sampling rate change) a new Template ID MUST be used, and the old Template ID MUST NOT be reused until its lifetime (see Section 10.3.7) has expired.
（10.3.7を参照）新しいテンプレートIDを使用しなければならないし、古いテンプレートIDは、その寿命まで再利用してはならないデータレコードの解釈を変更することができ、構成変更（例えば、サンプリングレートの変更）している以下の有効期限が切れています。
If UDP is selected as the transport protocol, the Template Withdraw Messages MUST NOT be used, as this method is inefficient due to the unreliable nature of UDP.
UDPは、トランスポートプロトコルとして選択されている場合は、この方法が原因UDPの信頼性のない自然に非効率的であるとして、テンプレート撤回メッセージは、使用してはいけません。
The Collecting Process MUST associate a lifetime with each Template (or another definition of an identifier considered unique within the Transport Session) received via UDP. Templates (and similar definitions) not refreshed by the Exporting Process within the lifetime are expired at the Collecting Process. If the Template (or other definition) is not refreshed before that lifetime has expired, the Collecting Process MUST discard that definition and any current and future associated Data Records. In which case, an alarm MUST be logged. The Collecting Process MUST NOT decode any further Data Records that are associated with the expired Template. If a Template is refreshed with a Template Record that differs from the previously received Template Record, the Collecting Process SHOULD log a warning and replace the previously received Template Record with the new one. The Template lifetime at the Collecting Process MUST be at least 3 times higher than the Template refresh timeout configured on the Exporting Process.
収集プロセスはUDPを介して受信された各テンプレート（またはトランスポートセッション内で一意と考え識別子の別の定義）と寿命を関連付ける必要があります。寿命内エクスポートプロセスによってリフレッシュされないテンプレート（及び同様の定義は）収集プロセスで有効期限が切れています。その寿命が満了する前に、テンプレート（またはその他の定義）がリフレッシュされない場合は、収集プロセスは、その定義と任意の現在および将来の関連するデータレコードを捨てなければなりません。その場合には、アラームがログインしている必要があります。収集プロセスは、期限切れのテンプレートに関連付けられている任意の更なるデータレコードを復号化してはなりません。テンプレートは、以前に受信したテンプレートレコードとは異なりテンプレートレコードでリフレッシュされている場合は、収集プロセスは警告をログに記録し、以前に新しいものとテンプレートレコードを受信置き換える必要があります。収集プロセスにおけるテンプレート寿命は、エクスポートプロセスに構成されたテンプレートのリフレッシュ・タイムアウトよりも少なくとも3倍高くなければなりません。
Template IDs are unique per UDP session and per Observation Domain. At any given time, the Collecting Process SHOULD maintain the following for all the current Template Records and Options Template
テンプレートIDは、UDPセッションごとと観測ドメインごとに一意です。どの時点でも、収集プロセスは、現在のすべてのテンプレートレコードとオプションテンプレートに対して次を維持する必要があります
Records: <IPFIX Device, Exporter source UDP port, Observation Domain ID, Template ID, Template Definition, Last Received>.
レコード：<最後に受信したIPFIXデバイス、輸出元UDPポート、観測ドメインID、テンプレートID、テンプレート定義、>。
The Collecting Process SHOULD accept Data Records without the associated Template Record (or other definitions) required to decode the Data Record. If the Template Records (or other definitions such as Common Properties) have not been received at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Template Records (or other definitions) are received. The short period of time MUST be lower than the lifetime of definitions associated with identifiers considered unique within the UDP session.
収集プロセスは、データレコードを復号するために必要な関連するテンプレートレコード（または他の定義）することなく、データレコードを受け入れるべきです。テンプレートレコード（または、そのような共通プロパティなど他の定義）は、データレコードが受信された時点で受信されていない場合は、短時間のデータレコードを保存し、テンプレートレコード（またはその他の定義の後にそれらをデコードするべきで収集プロセス）が受信されています。時間の短い期間は、UDPセッション内で一意の識別子と考えると関連付けられた定義の寿命よりも低くなければなりません。
If the Collecting Process receives a malformed IPFIX Message, it MUST discard the IPFIX Message and SHOULD log the error.
収集プロセスは、不正な形式のIPFIXメッセージを受信した場合、それはIPFIXメッセージを捨てなければなりませんし、エラーをログに記録すべきです。
Because UDP is not a connection-oriented protocol, the Exporting Process is unable to determine from the transport protocol that the Collecting Process is no longer able to receive the IPFIX Messages. Therefore, it cannot invoke a failover mechanism. However, the Exporting Process MAY duplicate the IPFIX Message to several Collecting Processes.
UDPはコネクション型のプロトコルではないため、エクスポートプロセスは、収集プロセスがもはやIPFIXメッセージを受信することができるトランスポートプロトコルから決定することができません。したがって、フェールオーバーメカニズムを呼び出すことはできません。しかし、エクスポートプロセスは、いくつかの収集プロセスにIPFIXのメッセージを複製してもよい（MAY）。
This section describes how IPFIX can be transported over TCP [TCP].
このセクションでは、IPFIXは、TCP [TCP]を介して輸送することができる方法を説明します。
The IPFIX Exporting Process initiates a TCP connection to the Collecting Process. By default, the Collecting Process listens for connections on TCP port 4739. By default, the Collecting Process listens for secure connections on TCP port 4740 (refer to the Security Considerations section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting Process and the Collecting Process to use a different TCP port.
IPFIXエクスポートプロセスは、収集プロセスへのTCP接続を開始します。デフォルトでは、収集プロセスは、デフォルトではTCPポート4739.上の接続を待機し、収集プロセスは、TCPポート4740上のセキュアな接続（セキュリティに関する考慮事項のセクションを参照）をリッスンします。デフォルトでは、エクスポートプロセスは、これらのポートの1つに接続しようとします。別のTCPポートを使用するようにエクスポートプロセスと収集プロセスの両方を設定することも可能でなければなりません。
An Exporting Process MAY support more than one active connection to different Collecting Processes (including the case of different Collecting Processes on the same host).
エクスポートプロセスは、（同じホスト上の異なる収集プロセスの場合を含む）は、異なる収集プロセスに複数のアクティブな接続をサポートするかもしれません。
The Exporter MAY log an alarm if the time to establish the connection exceeds a specified threshold, configurable on the Exporter.
接続を確立するための時間が輸出で設定可能、指定されたしきい値を超えた場合、輸出業者は、アラームを記録することがあります。
When an Exporting Process is shut down, it SHOULD shut down the TCP connection.
エクスポートプロセスがシャットダウンされる場合は、TCPコネクションをシャットダウンする必要があります。
When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD close its end of the connection. The Collecting Process SHOULD continue to read IPFIX Messages until the Exporting Process has closed its end.
収集プロセスは、もはやIPFIXメッセージを受信したい場合は、接続の終わりを閉じるべきではありません。エクスポートプロセスが終了を閉じたまでは収集プロセスはIPFIXメッセージを読むことを続けるべきです。
When a Collecting Process detects that the TCP connection to the Exporting Process has terminated abnormally, it MUST continue to listen for a new connection.
収集プロセスは、エクスポートプロセスへのTCP接続が異常終了したことを検出すると、それは新しい接続をリッスンし続けなければなりません。
When an Exporting Process detects that the TCP connection to the Collecting Process has terminated abnormally, it SHOULD try to re-establish the connection. Connection timeouts and retry schedules SHOULD be configurable. In the default configuration, an Exporting Process MUST NOT attempt to establish a connection more frequently than once per minute.
エクスポートプロセスは、収集プロセスへのTCP接続が異常終了したことを検出すると、接続を再確立しようとする必要があります。接続タイムアウトと再試行スケジュールが設定可能であるべきです。デフォルトの設定では、エクスポートプロセスは、毎分一回よりも頻繁に接続を確立することを試みてはいけません。
If the Collecting Process does not acknowledge the attempt by the Exporting Process to establish a connection, it will retry using the TCP exponential backoff feature.
収集プロセスは、接続を確立するために、エクスポートプロセスによって試みを認めない場合は、TCP指数バックオフ機能を使用して再試行します。
If Collecting Process failover is supported by the Exporting Process, a second TCP connection MAY be opened in advance.
収集プロセスのフェイルオーバーがエクスポートプロセスによってサポートされている場合は、2番目のTCP接続が事前に開くことができます。
Once a TCP connection is established, the Exporting Process starts sending IPFIX Messages to the Collecting Process.
TCP接続が確立されると、エクスポートプロセスは、収集プロセスにIPFIXメッセージの送信を開始します。
IPFIX Messages are sent over the TCP connection without any special encoding. The Length field in the IPFIX Message Header defines the end of each IPFIX Message and thus the start of the next IPFIX Message. This means that IPFIX Messages cannot be interleaved.
IPFIXのメッセージは、特別なエンコードせずにTCP接続を介して送信されます。 IPFIXメッセージヘッダの長さフィールドは、各IPFIXメッセージの終わり、従って次IPFIXメッセージの開始を定義します。これはIPFIXメッセージをインターリーブすることができないことを意味します。
In the case of TCP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent from this TCP connection, from the current Observation Domain by the Exporting Process, prior to the receipt of this IPFIX Message, modulo 2^32.
TCPの場合、IPFIXシーケンス番号は、このIPFIXメッセージの受信、モジュロ2 ^ 32の前にエクスポートプロセスによって現在の観測ドメインから、このTCP接続から送信されたIPFIXデータレコードの合計数が、含まれています。
If an Exporting Process exports data from multiple Observation Domains, it should be careful to choose IPFIX Message lengths appropriately to minimize head-of-line blocking between different Observation Domains. Multiple TCP connections MAY be used to avoid head-of-line between different Observation Domains.
複数観測ドメインからエクスポートプロセスエクスポートデータ場合、IPFIXメッセージは、ヘッド・オブ・ライン異なる観測ドメイン間のブロッキングを最小限にするために適宜長を選択するように注意しなければなりません。複数のTCPコネクションは、ヘッドオブライン異なる観測ドメイン間を避けるために使用することができます。
For each Template, the Exporting Process MUST send the Template Record before exporting Data Records that refer to that Template.
テンプレートごとに、エクスポートプロセスは、そのテンプレートを参照してくださいデータレコードをエクスポートする前にテンプレートレコードを送らなければなりません。
Template IDs are unique per TCP connection and per Observation Domain. A Collecting Process MUST record all Template and Options Template Records for the duration of the connection, as an Exporting Process is not required to re-export Template Records.
テンプレートIDは、TCP接続ごとと観測ドメインごとに一意です。エクスポートプロセスを再輸出するために必要とされていないとして収集プロセスは、接続の間テンプレートレコードをすべてのテンプレートとオプションテンプレートレコードを記録しなければなりません。
When the TCP connection restarts, the Exporting Process MUST resend all the Template Records.
ときにTCPコネクションを再起動すると、エクスポートプロセスは、すべてのテンプレートレコードを再送信する必要があります。
When a TCP connection is closed, the Collecting Process MUST discard all Templates received over that connection and stop decoding IPFIX Messages that use those Templates.
TCP接続が閉じられたときに、収集プロセスは、すべてのテンプレートを破棄しなければならないこと接続を介して受信し、これらのテンプレートを使用IPFIXメッセージをデコード停止。
The Templates that are not used anymore SHOULD be deleted. 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 over the TCP connection.
もう使用されていないテンプレートを削除する必要があります。テンプレートIDを再利用する前に、テンプレートを削除する必要があります。割り当てられたテンプレートを削除するために、テンプレートは、TCP接続を介してテンプレート無効化メッセージの使用を介して引き出されます。
If the Collecting Process receives a malformed IPFIX Message, it MUST reset the TCP connection, discard the IPFIX Message, and SHOULD log the error.
収集プロセスは、不正な形式のIPFIXメッセージを受信した場合、それはIPFIXメッセージを破棄し、TCP接続をリセットしなければならない、とエラーを記録すべきです。
TCP ensures reliable delivery of data from the Exporting Process to the Collecting Process. TCP also controls the rate at which data can be sent from the Exporting Process to the Collecting Process, using a mechanism that takes into account both congestion in the network and the capabilities of the receiver.
TCPは、収集プロセスへのエクスポートプロセスからのデータの信頼性の高い配信を保証します。 TCPは、データがアカウントにネットワークの輻輳と受信機の両方の機能を取り機構を使用して、収集プロセスにエクスポートプロセスから送信される速度を制御します。
Therefore, an IPFIX Exporting Process may not be able to send IPFIX Messages at the rate that the Metering Process generates it, either because of congestion in the network or because the Collecting Process cannot handle IPFIX Messages fast enough. As long as congestion is transient, the Exporting Process can buffer IPFIX Messages for transmission. But such buffering is necessarily limited, both because of resource limitations and because of timeliness requirements, so ongoing and/or severe congestion may lead to a situation where the Exporting Process is blocked.
したがって、IPFIXエクスポートプロセスは、計量プロセスが十分に速くIPFIXメッセージを処理できない収集プロセスネットワークまたはので、どちらかのため混雑の発生率でIPFIXメッセージを送信することができないかもしれません。限り輻輳が一過性であるように、エクスポートプロセスは、送信のためIPFIXメッセージをバッファリングすることができます。しかしそのようなバッファリングはそれほど進行中の及び/又は重度の輻輳がエクスポートプロセスがブロックされる状況につながる可能性があり、なぜなら、リソースの制限のため、および適時性要件の両方、必ずしも限定されるものです。
When an Exporting Process has Data Records to export but the transmission buffer is full, and it wants to avoid blocking, it can decide to drop some Data Records. The dropped Data Records MUST be accounted for, so that the amount can later be exported.
エクスポートプロセスがエクスポートするデータレコードを持っていますが、送信バッファがいっぱいになると、それはブロックを回避しようとするとき、それはいくつかのデータレコードをドロップすることを決定することができます。量は、後にエクスポートすることができるようにドロップされたデータレコードは、考慮しなければなりません。
When an Exporting Process finds that the rate at which records should be exported is consistently higher than the rate at which TCP sending permits, it should provide back pressure to the Metering Processes. The Metering Process could then adapt by temporarily reducing the amount of data it generates, for example, using sampling or aggregation.
エクスポートプロセスは、レコードをエクスポートしなければならない速度はTCPが許可を送信する速度よりも一貫して高いことを検出すると、計量プロセスに背圧を提供すべきです。計量プロセスは、その後、サンプリングまたは凝集を使用して、例えば、一時的にそれが生成するデータの量を減少させることによって適応させることができました。
The Collecting Process SHOULD listen for a new TCP connection from the Exporting Process.
収集プロセスは、エクスポートプロセスから新しいTCP接続をリッスン。
If the Collecting Process receives a malformed IPFIX Message, it MUST reset the TCP connection, discard the IPFIX Message, and SHOULD log the error. Note that non-zero Set padding does not constitute a malformed IPFIX Message.
収集プロセスは、不正な形式のIPFIXメッセージを受信した場合、それはIPFIXメッセージを破棄し、TCP接続をリセットしなければならない、とエラーを記録すべきです。非ゼロセットパディングが不正な形式のIPFIXメッセージを構成するものではないことに注意してください。
Template Sets and Option Template Sets are only sent once. The Collecting Process MUST store the Template Record information for the duration of the connection so that it can interpret the corresponding Data Records that are received in subsequent Data Sets.
テンプレートセットとオプションテンプレートセットは一度だけ送信されます。それは後続のデータセットで受信され、対応するデータレコードを解釈できるように、収集プロセスは、接続の持続時間のためのテンプレートレコードの情報を格納しなければなりません。
Template IDs are unique per TCP connection and per Observation Domain. If the Collecting Process receives a Template that has already been received but that has not previously been withdrawn (i.e., a Template Record from the same Exporter Observation Domain with the same Template ID received on the TCP connection), then the Collecting Process MUST shut down the connection.
テンプレートIDは、TCP接続ごとと観測ドメインごとに一意です。収集プロセスが既に受信されているテンプレートを受信するが、それは以前に引き出されていない場合（すなわち、IDがTCP接続で受信した同じテンプレートと同じ輸出観測ドメインからテンプレートレコード）、次いで、収集プロセスは停止する必要があります接続。
When a TCP connection is closed, the Collecting Process MUST discard all Templates received over that connection and stop decoding IPFIX Messages that use those Templates.
TCP接続が閉じられたときに、収集プロセスは、すべてのテンプレートを破棄しなければならないこと接続を介して受信し、これらのテンプレートを使用IPFIXメッセージをデコード停止。
If a Collecting Process receives a Template Withdrawal Message, the Collecting Process MUST delete the corresponding Template Records associated with the specific TCP connection and specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates.
収集プロセスがテンプレート無効化メッセージを受信した場合、収集プロセスは、特定のTCP接続と特定観測ドメインに関連付けられた対応するテンプレートレコードを削除し、そして引き抜かテンプレートを使用IPFIXメッセージをデコード停止しなければなりません。
If the Collecting Process receives a Template Withdrawal Message for a Template Record it has not received before on this TCP connection, it MUST reset the TCP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages.
収集プロセスは、それがこのTCPコネクション上で以前に受信していないテンプレートレコードのテンプレート無効化メッセージを受信した場合、それはIPFIXメッセージを破棄、TCPの関連付けをリセットする必要があり、それが不正な形式のIPFIXメッセージの場合と同様に、エラーをログに記録すべきです。
The security considerations for the IPFIX protocol have been derived from an analysis of potential security threats, as discussed in the "Security Considerations" section of IPFIX requirements [RFC3917]. The requirements for IPFIX security are as follows:
IPFIX要件[RFC3917]の「セキュリティの考慮事項」の項で説明したようにIPFIXプロトコルのためのセキュリティの考慮事項は、潜在的なセキュリティの脅威の分析に由来しています。次のようにIPFIXのセキュリティのための要件は次のとおりです。
1. IPFIX must provide a mechanism to ensure the confidentiality of IPFIX data transferred from an Exporting Process to a Collecting Process, in order to prevent disclosure of Flow Records transported via IPFIX.
1. IPFIXはIPFIXを介して輸送フローレコードの開示を防止するために、収集プロセスにエクスポートプロセスから転送されたIPFIXデータの機密性を確保するためのメカニズムを提供しなければなりません。
2. IPFIX must provide a mechanism to ensure the integrity of IPFIX data transferred from an Exporting Process to a Collecting Process, in order to prevent the injection of incorrect data or control information (e.g., Templates) into an IPFIX Message stream.
2. IPFIXは、誤ったデータの注入を防止またはIPFIXメッセージストリームに情報（例えば、テンプレート）を制御するために、収集プロセスにエクスポートプロセスから転送されたIPFIXデータの整合性を確保するためのメカニズムを提供しなければなりません。
3. IPFIX must provide a mechanism to authenticate IPFIX Collecting and Exporting Processes, to prevent the collection of data from an unauthorized Exporting Process or the export of data to an unauthorized Collecting Process.
3. IPFIXは、不正エクスポートプロセスや不正収集プロセスへのデータのエクスポートからのデータの収集を防止するために、IPFIX収集およびエクスポートプロセスを認証するためのメカニズムを提供しなければなりません。
Because IPFIX can be used to collect information for network forensics and billing purposes, attacks designed to confuse, disable, or take information from an IPFIX collection system may be seen as a prime objective during a sophisticated network attack.
IPFIXは、ネットワークフォレンジックと課金のための情報を収集するために使用することができますので、混乱無効、またはIPFIX収集システムから情報を取るように設計された攻撃は、高度なネットワーク攻撃時のプライム目的として見ることができます。
An attacker in a position to inject false messages into an IPFIX Message stream can either affect the application using IPFIX (by falsifying data), or the IPFIX Collecting Process itself (by modifying or revoking Templates, or changing options); for this reason, IPFIX Message integrity is important.
IPFIXメッセージストリームに偽のメッセージを注入する位置に、攻撃者は、（修正または取り消しテンプレート、またはオプションを変更することによって）IPFIX（データを改ざんすることによって）を使用して、アプリケーション、またはIPFIX収集プロセス自体に影響しますか。この理由のために、IPFIXのメッセージの整合性が重要です。
The IPFIX Messages themselves may also contain information of value to an attacker, including information about the configuration of the network as well as end-user traffic and payload data, so care must be taken to confine their visibility to authorized users. When an Information Element containing end-user payload information is exported, it SHOULD be transmitted to the Collecting Process using a means that secures its contents against eavesdropping. Suitable mechanisms include the use of either a direct point-to-point connection or the use of an encryption mechanism. It is the responsibility of the Collecting Process to provide a satisfactory degree of security for this collected data, including, if necessary, anonymization of any reported data.
ケアは、許可されたユーザへの可視性を制限するために注意しなければならないので、IPFIXメッセージ自体はまた、ネットワークの構成に関する情報だけでなく、エンドユーザトラフィック及びペイロードデータを含む、攻撃者に価値の情報を含むことができます。情報要素を含むエンドユーザのペイロード情報がエクスポートされるとき、それが盗聴に対してその内容を固定する手段を用いて、収集プロセスに送信されるべきです。適切なメカニズムは、直接ポイントツーポイント接続または暗号化メカニズムを使用するいずれかの使用を含みます。任意の必要な、匿名のデータを報告している場合、を含む、データを収集し、このためのセキュリティの満足度を提供するために、収集プロセスの責任です。
Transport Layer Security (TLS) [RFC4346] and Datagram Transport Layer Security (DTLS) [RFC4347] were designed to provide the confidentiality, integrity, and authentication assurances required by the IPFIX protocol, without the need for pre-shared keys.
トランスポート層セキュリティ（TLS）[RFC4346]とデータグラムトランスポート層セキュリティ（DTLS）[RFC4347]は事前共有キーを必要とせずに、IPFIXプロトコルによって必要とされる機密性、完全性、および認証保証を提供するように設計されました。
With the mandatory SCTP and PR-SCTP transport protocols for IPFIX, DTLS [RFC4347] MUST be implemented. If UDP is selected as the IPFIX transport protocol, DTLS [RFC4347] MUST be implemented. If TCP is selected as the IPFIX transport protocol, TLS [RFC4346] MUST be implemented.
IPFIXのための必須のSCTPとPR-SCTPトランスポートプロトコルと、DTLS [RFC4347]は実装しなければなりません。 UDPは、IPFIXトランスポートプロトコルとして選択された場合、DTLS [RFC4347]は実装しなければなりません。 TCPは、IPFIXのトランスポートプロトコルとして選択された場合、TLS [RFC4346]は実装しなければなりません。
Note that DTLS is selected as the security mechanism for SCTP and PR-SCTP. Though TLS bindings to SCTP are defined in [RFC3436], they require all communication to be over reliable, bidirectional streams, and require one TLS connection per stream. This arrangement is not compatible with the rationale behind the choice of SCTP as an IPFIX transport protocol.
DTLSは、SCTPとPR-SCTPのためのセキュリティ・メカニズムとして選択されていることに注意してください。 SCTPへのTLSバインディングは、[RFC3436]で定義されているが、彼らは信頼性の高い、双方向の流れの上にあることを、すべての通信を必要とし、ストリームごとにTLS接続が必要です。この構成は、IPFIXトランスポートプロトコルとしてSCTPの選択の背後にある理論的根拠と互換性がありません。
Note that using DTLS [RFC4347] has a vulnerability, i.e., a true man in the middle may attempt to take data out of an association and fool the sender into thinking that the data was actually received by the peer. In generic TLS for SCTP (and/or TCP), this is not possible. This means that the removal of a message may become hidden from the sender or receiver. Another vulnerability of using PR-SCTP with DTLS is that someone could inject SCTP control information to shut down the SCTP association, effectively generating a loss of IPFIX Messages if those are buffered outside of the SCTP association. In the future, techniques such as [dtls-for-sctp] could be used to overcome these vulnerabilities.
DTLS [RFC4347]を使用すると、脆弱性を有することに留意されたい、すなわち、中央に真人は関連からデータを取得し、データが実際にピアによって受信されたことを考えに送信者をだますことを試みることができます。一般的なSCTPのためのTLS（および/またはTCP）で、これは不可能です。これは、メッセージの除去は、送信者または受信者から隠さなることを意味します。 DTLSとPR-SCTPを使用することの別の脆弱性は、誰かが、それらはSCTPアソシエーションの外側にバッファリングされる場合に効果的IPFIXメッセージの損失を発生させる、SCTPアソシエーションをシャットダウンするSCTP制御情報を注入することができることです。将来的には、このような[DTLS-FOR-SCTP]のような技術は、これらの脆弱性を克服するために使用することができます。
When using DTLS over SCTP, the Exporting Process MUST ensure that each IPFIX Message is sent over the same SCTP stream that would be used when sending the same IPFIX Message directly over SCTP. Note that DTLS may send its own control messages on stream 0 with full reliability; however, this will not interfere with the processing of stream 0 IPFIX Messages at the Collecting Process, because DTLS consumes its own control messages before passing IPFIX Messages up to the application layer.
SCTP上DTLSを使用する場合、エクスポートプロセスは、各IPFIXメッセージはSCTP上に直接同じIPFIXメッセージを送信する際に使用される同一のSCTPストリームを介して送信されることを保証しなければなりません。 DTLSは、完全な信頼性を備えたストリーム0上で、独自の制御メッセージを送信することがあります。 DTLSは、アプリケーション層までIPFIXメッセージを渡す前に、それ自身の制御メッセージを消費するためしかし、これは、収集プロセスにおけるストリーム0 IPFIXメッセージの処理を妨げません。
The IPFIX Exporting Process initiates the communication to the IPFIX Collecting Process, and acts as a TLS or DTLS client according to [RFC4346] and [RFC4347], while the IPFIX Collecting Process acts as a TLS or DTLS server. The DTLS client opens a secure connection on the SCTP port 4740 of the DTLS server if SCTP or PR-SCTP is selected as the transport protocol. The TLS client opens a secure connection on the TCP port 4740 of the TLS server if TCP is selected as the transport protocol. The DTLS client opens a secure connection on the UDP port 4740 of the DTLS server if UDP is selected as the transport protocol.
IPFIXエクスポートプロセスはIPFIX収集プロセスへの通信を開始し、IPFIX収集プロセスは、TLSまたはDTLSサーバとして機能しながら、[RFC4346]及び[RFC4347]に従ってTLSまたはDTLSクライアントとして機能します。 SCTPまたはPR-SCTPをトランスポートプロトコルとして選択されている場合DTLSクライアントは、DTLSサーバのSCTPポート4740上のセキュアな接続を開きます。 TCPはトランスポートプロトコルとして選択されている場合はTLSクライアントはTLSサーバのTCPポート4740上のセキュアな接続を開きます。 UDPは、トランスポートプロトコルとして選択されている場合DTLSクライアントは、DTLSサーバのUDPポート4740上での安全な接続を開きます。
IPFIX Exporting Processes and IPFIX Collecting Processes are identified by the fully qualified domain name of the interface on which IPFIX Messages are sent or received, for purposes of X.509 client and server certificates as in [RFC3280].
IPFIXのエクスポートプロセスとIPFIX収集プロセスはIPFIXメッセージは[RFC3280]のようにX.509クライアントとサーバー証明書の目的のために、送信または受信されているインタフェースの完全修飾ドメイン名で識別されます。
To prevent man-in-the-middle attacks from impostor Exporting or Collecting Processes, the acceptance of data from an unauthorized Exporting Process, or the export of data to an unauthorized Collecting Process, strong mutual authentication via asymmetric keys MUST be used for both TLS and DTLS. Each of the IPFIX Exporting and Collecting Processes MUST verify the identity of its peer against its authorized certificates, and MUST verify that the peer's certificate matches its fully qualified domain name, or, in the case of SCTP, the fully qualified domain name of one of its endpoints.
詐欺師のプロセスをエクスポートするか、収集、不正エクスポートプロセスからのデータの受け入れ、または不正な収集プロセスへのデータのエクスポートからのman-in-the-middle攻撃を防ぐために、非対称鍵を経由して、強力な相互認証は、両方のTLSを使用しなければなりませんそしてDTLS。 IPFIXのエクスポートの各とプロセスの収集は、その許可された証明書に対してピアの身元を確認しなければならない、とピアの証明書は、SCTPの1の完全修飾ドメイン名の場合には、完全修飾ドメイン名と一致、またはことを確かめなければなりませんそのエンドポイント。
The fully qualified domain name used to identify an IPFIX Collecting Process or Exporting Process may be stored either in a subjectAltName extension of type dNSName, or in the most specific Common Name field of the Subject field of the X.509 certificate. If both are present, the subjectAltName extension is given preference.
IPFIX収集プロセスまたはエクスポートプロセスを識別するために使用される完全修飾ドメイン名は、型のdNSNameのsubjectAltName拡張中、またはX.509証明書の件名フィールドの最も具体的なCommon Nameフィールドのいずれかに格納されてもよいです。両方が存在する場合、subjectAltName拡張が優先されます。
Internationalized domain names (IDN) in either the subjectAltName extension of type dNSName or the most specific Common Name field of the Subject field of the X.509 certificate MUST be encoded using Punycode [RFC3492] as described in Section 4 of [RFC3490], "Conversion Operations".
[RFC3490]のセクション4で説明したように型のdNSNameのsubjectAltName拡張またはX.509証明書の件名フィールドの最も具体的なCommon Nameフィールドのいずれかにおける国際化ドメイン名（IDN）」は、ピュニコード[RFC3492]を使用して符号化されなければなりません変換の操作」。
An attacker may mount a denial-of-service (DoS) attack against an IPFIX collection system either directly, by sending large amounts of traffic to a Collecting Process, or indirectly, by generating large amounts of traffic to be measured by a Metering Process.
攻撃者は、計量プロセスによって測定される大量のトラフィックを生成することによって、間接的に収集プロセスに大量のトラフィックを送信する、またはによって、直接的IPFIX収集システムに対するサービス拒否（DoS）攻撃を仕掛けることができます。
Direct denial-of-service attacks can also involve state exhaustion, whether at the transport layer (e.g., by creating a large number of pending connections), or within the IPFIX Collecting Process itself (e.g., by sending Flow Records pending Template or scope information, a large amount of Options Template Records, etc.).
直接サービス拒否攻撃は、トランスポート層であるかどうかにかかわらず（例えば、係属中の多数の接続を作成することによって）、状態の枯渇を伴う、またはIPFIX収集プロセス自体（内部例えば、テンプレートまたはスコープ情報を保留中のフローレコードを送信することによってすることができます、オプションテンプレートレコードなど）の大量。
SCTP mandates a cookie-exchange mechanism designed to defend against SCTP state exhaustion denial-of-service attacks. Similarly, TCP provides the "SYN cookie" mechanism to mitigate state exhaustion; SYN cookies SHOULD be used by any Collecting Process accepting TCP connections. DTLS also provides cookie exchange to protect against DTLS server state exhaustion.
SCTPは、SCTP状態枯渇サービス拒否（DoS）攻撃を防御するために設計されたクッキー交換メカニズムを義務付け。同様に、TCP状態の消耗を軽減する「SYNクッキー」機構を提供します。 SYNクッキーは、TCP接続を受け入れる任意の収集プロセスによって使用されるべきです。 DTLSはまた、DTLSサーバ状態の枯渇から保護するためにクッキー交換を提供します。
The reader should note that there is no way to prevent fake IPFIX Message processing (and state creation) for UDP & SCTP communication. The use of TLS and DTLS can obviously prevent the creation of fake states, but they are themselves prone to state exhaustion attacks. Therefore, Collector rate limiting SHOULD be used to protect TLS & DTLS (like limiting the number of new TLS or DTLS session per second to a sensible number).
読者は、UDP＆SCTPの通信のために偽のIPFIXメッセージ処理（および状態の作成）を防止する方法がないことに注意してください。 TLSとDTLSの使用が明らかに偽の状態の生成を防止することができますが、彼らは国家の枯渇攻撃を受けやすいそのものです。したがって、制限コレクタ速度はTLS＆DTLS（賢明な数に毎秒新たなTLSまたはDTLSセッションの数を制限するなど）を保護するために使用されるべきです。
IPFIX state exhaustion attacks can be mitigated by limiting the rate at which new connections or associations will be opened by the Collecting Process, the rate at which IPFIX Messages will be accepted by the Collecting Process, and adaptively limiting the amount of state kept, particularly records waiting on Templates. These rate and state limits MAY be provided by a Collecting Process; if provided, the limits SHOULD be user configurable.
IPFIX状態枯渇攻撃は新しい接続や団体が収集プロセスによって開かされる速度を制限することによって軽減することができ、IPFIXのメッセージが収集プロセスによって受け入れられ、かつ適応的に状態の量を制限される速度は、特に記録を保管しましたテンプレートを待っています。これらの速度と状態制限は収集プロセスによって提供されてもよいです。提供される場合、制限はユーザ設定可能であるべきです。
Additionally, an IPFIX Collecting Process can eliminate the risk of state exhaustion attacks from untrusted nodes by requiring TLS or DTLS mutual authentication, causing the Collecting Process to accept IPFIX Messages only from trusted sources.
また、IPFIX収集プロセスは、信頼できるソースからIPFIXメッセージを受け入れるように収集プロセスを引き起こし、TLSまたはDTLS相互認証を要求することにより、信頼されていないノードから状態枯渇攻撃のリスクを排除することができます。
With respect to indirect denial of service, the behavior of IPFIX under overload conditions depends on the transport protocol in use. For IPFIX over TCP, TCP congestion control would cause the flow of IPFIX Messages to back off and eventually stall, blinding the IPFIX system. PR-SCTP improves upon this situation somewhat, as some IPFIX Messages would continue to be received by the Collecting Process due to the avoidance of head-of-line blocking by SCTP's multiple streams and partial reliability features, possibly affording some visibility of the attack. The situation is similar with UDP, as some datagrams may continue to be received at the Collecting Process, effectively applying sampling to the IPFIX Message stream, implying that some forensics may be left.
サービスの間接的な拒否に関しては、過負荷状態の下でIPFIXの挙動は、使用中のトランスポートプロトコルに依存します。 TCP上のIPFIXの場合は、TCPの輻輳制御は、IPFIXシステムを盲検化、IPFIXメッセージの流れが後退し、最終的に失速してしまいます。 PR-SCTPは、いくつかのIPFIXメッセージはおそらく攻撃のいくつかの可視性を与える、原因SCTPの複数のストリームと部分の信頼性機能により、ヘッドオブラインブロッキングの回避に収集プロセスによって受信され続けるだろうと、ややこの状況を改善します。いくつかのデータグラムは、いくつかのフォレンジックを残すことができることを意味し、有効IPFIXメッセージストリームにサンプリングを適用し、収集プロセスで受信し続けることができるような状況は、UDPと同様です。
To minimize IPFIX Message loss under overload conditions, some mechanism for service differentiation could be used to prioritize IPFIX traffic over other traffic on the same link. Alternatively, IPFIX Messages can be transported over a dedicated network. In this case, care must be taken to ensure that the dedicated network can handle the expected peak IPFIX Message traffic.
過負荷状態でIPFIXメッセージの損失を最小限にするために、サービスの差別化のためのいくつかのメカニズムが同じリンク上の他のトラフィックよりIPFIXトラフィックの優先順位付けに使用することができます。また、IPFIXのメッセージは、専用のネットワーク上で転送することができます。この場合は、注意が専用ネットワークが期待されるピークIPFIXメッセージトラフィックを処理できるように注意する必要があります。
The use of DTLS or TLS might not be possible in some cases due to performance issues or other operational concerns.
DTLSまたはTLSの使用は、パフォーマンスの問題やその他の運用の問題にいくつかのケースでは可能ではないかもしれません。
Without TLS or DTLS mutual authentication, IPFIX Exporting Processes and Collecting Processes can fall back on using IP source addresses to authenticate their peers. A policy of allocating Exporting Process and Collecting Process IP addresses from specified address ranges, and using ingress filtering to prevent spoofing, can improve the usefulness of this approach. Again, completely segregating IPFIX traffic on a dedicated network, where possible, can improve security even further. In any case, the use of open Collecting Processes (those that will accept IPFIX Messages from any Exporting Process regardless of IP address or identity) is discouraged.
TLSまたはDTLS相互認証がなければ、IPFIXのエクスポートプロセスと収集プロセスは仲間を認証するために、IP送信元アドレスを使用してフォールバックすることができます。エクスポートプロセスを割り当て、指定されたアドレス範囲からのプロセスのIPアドレスを収集し、なりすましを防ぐために、イングレスフィルタリングを使用するポリシーが、このアプローチの有用性を向上させることができます。ここでも、完全に専用ネットワーク上のIPFIXトラフィックを分離、可能な場合は、さらにセキュリティを向上させることができます。いずれの場合においても、オープン収集プロセス（関係なく、IPアドレスまたは同一のいずれかエクスポートプロセスからIPFIXメッセージを受け入れるもの）の使用が推奨されます。
Modern TCP and SCTP implementations are resistant to blind insertion attacks (see [RFC1948], [RFC4960]); however, UDP offers no such protection. For this reason, IPFIX Message traffic transported via UDP and not secured via DTLS SHOULD be protected via segregation to a dedicated network.
近代的なTCPおよびSCTP実装はブラインド挿入攻撃に対して耐性である（[RFC1948]、[RFC4960]を参照）。しかし、UDPはそのような保護を提供しています。このため、IPFIXのメッセージトラフィックはUDPを介して伝送し、専用のネットワークへの偏析を経由して保護されなければならないDTLSを経由して固定されていません。
IPFIX Collecting Processes MUST detect potential IPFIX Message insertion or loss conditions by tracking the IPFIX Sequence Number, and SHOULD provide a logging mechanism for reporting out-of-sequence messages. Note that an attacker may be able to exploit the handling of out-of-sequence messages at the Collecting Process, so care should be taken in handling these conditions. For example, a Collecting Process that simply resets the expected Sequence Number upon receipt of a later Sequence Number could be temporarily blinded by deliberate injection of later Sequence Numbers.
IPFIX収集プロセスはIPFIXシーケンス番号を追跡することによって潜在的なIPFIXメッセージの挿入や損失状態を検出しなければならない、とシーケンス外のメッセージを報告するためのログメカニズムを提供する必要があります。注意がこれらの条件の処理に注意しなければならないので、攻撃者が収集プロセスにおけるアウトオブシーケンスメッセージの処理を利用することができるかもしれないことに留意されたいです。例えば、単に後シーケンス番号を受信すると期待シーケンス番号をリセット収集プロセスが一時的に後シーケンス番号の意図的な注射によって盲目にすることができます。
IPFIX Exporting and Collecting Processes SHOULD log any connection attempt that fails due to authentication failure, whether due to being presented an unauthorized or mismatched certificate during TLS or DTLS mutual authentication, or due to a connection attempt from an unauthorized IP address when TLS or DTLS is not in use.
TLSまたはDTLSがあるときIPFIXのエクスポートおよび収集プロセスは、または起因する不正なIPアドレスからの接続試行へTLSまたはDTLS相互認証時に不正または不一致証明書を提示されている起因するかどうか、による認証失敗に失敗したすべての接続の試みをログに記録します使用されていません。
IPFIX Exporting and Collecting Processes SHOULD detect and log any SCTP association reset or TCP connection reset.
IPFIXのエクスポートおよび収集プロセスは、任意のSCTPアソシエーションリセットまたはTCP接続のリセットを検出し、ログインする必要があります。
The security of the Collector and its implementation is important to achieve overall security. However, it is outside the scope of this document.
コレクターとその実装のセキュリティは全体的なセキュリティを実現することが重要です。しかし、それはこのドキュメントの範囲外です。
IPFIX Messages use two fields with assigned values. These are the IPFIX Version Number, indicating which version of the IPFIX Protocol was used to export an IPFIX Message, and the IPFIX Set ID, indicating the type for each set of information within an IPFIX Message.
IPFIXのメッセージは、割り当てられた値を持つ2つのフィールドを使用します。これらは、IPFIXメッセージ内の情報の各セットの型を示す、IPFIXメッセージ、およびIPFIXセットIDをエクスポートするために使用されたIPFIXプロトコルのバージョンを示し、IPFIXバージョン番号です。
The IPFIX Version Number value of 10 is reserved for the IPFIX protocol specified in this document. Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. The Set ID value of 2 is reserved for the Template Set. The Set ID value of 3 is reserved for the Option Template Set. All other Set ID values from 4 to 255 are reserved for future use. Set ID values above 255 are used for Data Sets.
10のIPFIXバージョン番号の値は、この文書で指定されたIPFIXプロトコルのために予約されています。 0と1のセットID値は、歴史的な理由[RFC3954]のために使用されていません。 2のセットIDの値がテンプレートセット用に予約されています。 3のセットID値は、オプションテンプレートセット用に予約されています。 4から255までのすべての他のセットIDの値は、将来の使用のために予約されています。データセットのための255以上のセットIDの値が使用されています。
New assignments in either IPFIX Version Number or IPFIX Set ID assignments require a Standards Action [RFC2434], i.e., they are to be made via Standards Track RFCs approved by the IESG.
IPFIXバージョン番号またはIPFIXセットIDの割り当てのいずれかの新しい割り当ては、すなわち標準化アクション[RFC2434]を、必要、彼らはIESGによって承認された標準化過程のRFCを介して行うことになっています。
Appendix A. IPFIX Encoding Examples
付録A. IPFIXエンコーディング例
This appendix, which is a not a normative reference, contains IPFIX encoding examples.
引用規格はないこの付録は、IPFIXエンコード例を含んでいます。
Let's consider the example of an IPFIX Message composed of a Template Set, a Data Set (which contains three Data Records), an Options Template Set and a Data Set (which contains 2 Data Records related to the previous Options Template Record).
のは、テンプレートセット、（3つのデータレコードが含まれている）データセット、オプションテンプレートセットと（以前のオプションテンプレートレコードに関連した2つのデータレコードが含まれている）データセットで構成されるIPFIXメッセージの例を考えてみましょう。
IPFIX Message:
IPFIXメッセージ：
+--------+------------------------------------------. . .
| | +--------------+ +------------------+
|Message | | Template | | Data |
| Header | | Set | | Set | . . .
| | | (1 Template) | | (3 Data Records) |
| | +--------------+ +------------------+
+--------+------------------------------------------. . .
. . .-------------------------------------------+
+------------------+ +------------------+ |
| Options | | Data | |
. . . | Template Set | | Set | |
| (1 Template) | | (2 Data Records) | |
+------------------+ +------------------+ |
. . .-------------------------------------------+
A.1. Message Header Example
A.1。メッセージヘッダの例
The Message Header is composed of:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0x000a | Length = 152 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.2. Template Set Examples
A.2。テンプレートセットの例
A.2.1. Template Set Using IETF-Specified Information Elements
A.2.1。 IETF-指定された情報要素を使用してテンプレートセット
We want to report the following Information Elements:
私たちは、以下の情報要素を報告したいです。
- The IPv4 source IP address: sourceIPv4Address in [RFC5102], with a length of 4 octets
- IPv4ソースIPアドレス：sourceIPv4Address [RFC5102]で、4つのオクテットの長さ
- The IPv4 destination IP address: destinationIPv4Address in [RFC5102], with a length of 4 octets
- IPv4宛先IPアドレス：destinationIPv4Address [RFC5102]で、4つのオクテットの長さ
- The next-hop IP address (IPv4): ipNextHopIPv4Address in [RFC5102], with a length of 4 octets
- ネクストホップIPアドレス（IPv4）：ipNextHopIPv4Address [RFC5102]、4つのオクテットの長さ
- The number of packets of the Flow: inPacketDeltaCount in [RFC5102], with a length of 4 octets
- フローのパケットの数：4つのオクテットの長さを有する、[RFC5102]でinPacketDeltaCount、
- The number of octets of the Flow: inOctetDeltaCount in [RFC5102], with a length of 4 octets
- フローのオクテットの数：4つのオクテットの長さを有する、[RFC5102]でinOctetDeltaCount、
Therefore, the Template Set will be composed of the following:
そのため、テンプレートセットは、以下で構成されます。
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 = 28 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipNextHopIPv4Address = 15 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inPacketDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.2.2. Template Set Using Enterprise-Specific Information Elements
A.2.2。エンタープライズ固有の情報要素を使用してテンプレートセット
We want to report the following Information Elements:
私たちは、以下の情報要素を報告したいです。
- The IPv4 source IP address: sourceIPv4Address in [RFC5102], with a length of 4 octets
- IPv4ソースIPアドレス：sourceIPv4Address [RFC5102]で、4つのオクテットの長さ
- The IPv4 destination IP address: destinationIPv4Address in [RFC5102], with a length of 4 octets
- IPv4宛先IPアドレス：destinationIPv4Address [RFC5102]で、4つのオクテットの長さ
- An enterprise-specific Information Element representing proprietary information, with a type of 15 and a length of 4
- 企業固有の情報エレメント15の種類及び4の長さと、独自の情報を表します
- The number of packets of the Flow: inPacketDeltaCount in [RFC5102], with a length of 4 octets
- フローのパケットの数：4つのオクテットの長さを有する、[RFC5102]でinPacketDeltaCount、
- The number of octets of the Flow: inOctetDeltaCount in [RFC5102], with a length of 4 octets
- フローのオクテットの数：4つのオクテットの長さを有する、[RFC5102]でinOctetDeltaCount、
Therefore, the Template Set will be composed of the following:
そのため、テンプレートセットは、以下で構成されます。
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 257 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element Id. = 15| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inPacketDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.3. Data Set Example
A.3。データセットの例
In this example, we report the following three Flow Records:
この例では、我々は、次の3つのフローレコードをレポート：
Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets
| | | Number | Number
------------------------------------------------------------------
192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385
192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934
192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534
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 = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.254 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5009 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5344385 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 748 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 388934 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.65 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6534 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that padding is not necessary in this example.
パディングは、この例では必要ではないことに注意してください。
A.4. Options Template Set Examples
A.4。オプションテンプレートセットの例
A.4.1. Options Template Set Using IETF-Specified Information Elements
A.4.1。 IETF-指定された情報要素を使用してオプションテンプレートセット
Per line card (the router being composed of two line cards), we want to report the following Information Elements:
ラインカードごとに（ルータが2枚のラインカードで構成されている）、私たちは、以下の情報要素を報告したいです。
- Total number of IPFIX Messages: exportedPacketCount [RFC5102], with a length of 2 octets
- IPFIXメッセージの合計数：2つのオクテットの長さexportedPacketCount [RFC5102]、
- Total number of exported Flows: exportedFlowCount [RFC5102], with a length of 2 octets
- エクスポートされたフローの総数：2つのオクテットの長さexportedFlowCount [RFC5102]、
The line card, which is represented by the lineCardId Information Element [RFC5102], is used as the Scope Field.
lineCardId情報要素[RFC5102]で表されるラインカードは、スコープフィールドとして使用されます。
Therefore, the Options Template Set will be:
そのため、オプションテンプレートセットは次のようになります。
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 = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 258 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| lineCardId = 141 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| exportedFlowCount = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.4.2. Options Template Set Using Enterprise-Specific Information Elements
A.4.2。エンタープライズ固有の情報要素を使用してオプションテンプレートセット
Per line card (the router being composed of two line cards), we want to report the following Information Elements:
ラインカードごとに（ルータが2枚のラインカードで構成されている）、私たちは、以下の情報要素を報告したいです。
- Total number of IPFIX Messages: exportedPacketCount [RFC5102], with a length of 2 octets
- IPFIXメッセージの合計数：2つのオクテットの長さexportedPacketCount [RFC5102]、
- An enterprise-specific number of exported Flows, with a type of 42 and a length of 4 octets
- 42の種類及び4つのオクテットの長さを持つエクスポートフローの企業固有番号、
The line card, which is represented by the lineCardId Information Element [RFC5102], is used as the Scope Field.
lineCardId情報要素[RFC5102]で表されるラインカードは、スコープフィールドとして使用されます。
The format of the Options Template Set 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 = 3 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 259 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| lineCardId = 141 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |1|Information Element Id. = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | Enterprise number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Enterprise number | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.4.3. Options Template Set Using an Enterprise-Specific Scope
A.4.3。エンタープライズ固有のスコープを使用してオプションテンプレートセット
In this example, we want to export the same information as in the example in Section A.4.1:
この例では、セクションA.4.1に例のように同じ情報をエクスポートします：
- Total number of IPFIX Messages: exportedPacketCount [RFC5102], with a length of 2 octets
- IPFIXメッセージの合計数：2つのオクテットの長さexportedPacketCount [RFC5102]、
- Total number of exported Flows: exportedFlowCount [RFC5102], with a length of 2 octets
- エクスポートされたフローの総数：2つのオクテットの長さexportedFlowCount [RFC5102]、
But this time, the information pertains to a proprietary scope, identified by enterprise-specific Information Element number 123.
しかし、この時点では、情報は、エンタープライズ固有の情報エレメント数123によって識別される独自のスコープに関係します。
The format of the Options Template Set is now 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 = 3 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 260 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 | Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Enterprise Number |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| exportedFlowCount = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.4.4. Data Set Using an Enterprise-Specific Scope
A.4.4。企業固有のスコープを使用したデータセット
In this example, we report the following two Data Records:
この例では、我々は、以下の2つのデータレコードをレポート：
Line Card ID | IPFIX Message | Exported Flow Records
-------------------------------------------------------------------
Line Card 1 (lineCardId=1) | 345 | 10201
Line Card 2 (lineCardId=2) | 690 | 20402
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 = 260 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 345 | 10201 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 690 | 20402 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.5. Variable-Length Information Element Examples
A.5。可変長情報要素の例
A.5.1. Example of Variable-Length Information Element with Length Inferior to 255 Octets
A.5.1。 255個のオクテットに劣る長と可変長情報エレメントの例
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 5 octet Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.5.2. Example of Variable-Length Information Element with Length 255 to 65535 Octets
A.5.2。 65535オクテットまでの長さ255と可変長情報エレメントの例
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 | 1000 | IE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1000 octet Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
References
リファレンス
Normative References
引用規格
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装と分析"、RFC 1305、1992年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[RFC3436] Jungmaier、A.、レスコラ、E.、およびM. Tuexen、 "ストリーム制御伝送プロトコルを介してトランスポート層セキュリティ"、RFC 3436、2002年12月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル（SCTP）部分的な信頼性拡張"、RFC 3758、2004年5月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、 "ピュニコード：アプリケーションにおける国際化ドメイン名のUnicodeのブートストリングのエンコード（IDNA）"、RFC 3492、2003年3月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5102] Quittek, J., Bryant S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、ブライアントS.、Claise、B.、エイトケン、P.、およびJ.マイヤー、 "IPフロー情報のエクスポートのための情報モデル"、RFC 5102、2008年1月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[UDP]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
Informative References
参考文献
[IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture Model for IP Flow Information Export", Work in Progress, September 2006.
[IPFIX - ARCH] Sadasivan、G.、ブラウンリー、N.、Claise、B.、およびJ. Quittek、 "IPフロー情報のエクスポートのためのアーキテクチャモデル"、進歩、2006年9月での作業。
[IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", Work in Progress, June 2007.
[IPFIX-AS] Zseby、T.、ボスキ、E.、ブラウンリー、N.、およびB. Claise、 "IPFIX適用"、進歩、2007年6月に働いています。
[PEN] IANA Private Enterprise Numbers registry http://www.iana.org/assignments/enterprise-numbers.
[PEN] IANAプライベートエンタープライズ番号レジストリhttp://www.iana.org/assignments/enterprise-numbers。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948] Bellovin氏、S.、 "シーケンス番号攻撃からの保護"、RFC 1948、1996年5月。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B.、およびS.ザンダー、 "IPフロー情報エクスポート（IPFIX）のための要件"、RFC 3917、2004年10月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B.、エド。、 "シスコシステムズのNetFlowサービスエクスポートバージョン9"、RFC 3954、2004年10月。
[IEEE.754.1985] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 1985.
[IEEE.754.1985]電気電子技術者協会、「バイナリ浮動小数点演算のための基準」、IEEE規格754、1985年8月。
[dtls-for-sctp] Tuexen, M. and E. Rescola, "Datagram Transport Layer Security for Stream Control Transmission Protocol", Work in Progress, November 2007.
[DTLS-用-SCTP] Tuexen、M.とE. Rescola、 "ストリーム制御伝送プロトコルのためのデータグラムトランスポート層セキュリティ"、進歩、2007年11月に作業。
Acknowledgments
謝辞
We would like to thank the following persons: Ganesh Sadasivan for his significant contribution during the initial phases of the protocol specification; Juergen Quittek for the coordination job within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, and Andrew Johnson for the thorough reviews; Randall Stewart and Peter Lei for their SCTP expertise and contributions; Martin Djernaes for the first essay on the SCTP section; Michael Behringer and Eric Vyncke for their advice and knowledge in security; Michael Tuexen for his help regarding the DTLS section; Elisa Boschi for her contribution regarding the improvement of SCTP sections; Mark Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul Calato, and many more, for the technical reviews and feedback.
我々は、次の人に感謝したいと思います：ガネーシュSadasivanをプロトコル仕様の初期段階での彼の重要な貢献のために。 IPFIXとPSAMP内の連携ジョブのユルゲンQuittek。徹底的なレビューのためのNevilブラウンリー、デイブPlonka、ポール・エイトケン、そしてアンドリュー・ジョンソン。そのSCTPの専門知識と貢献のためのランドール・スチュワート、ピーター・レイ。 SCTPセクションの最初のエッセイのためのマーティンDjernaes。彼らのアドバイスやセキュリティに関する知識のためのマイケル・ベリンガーとエリックVyncke。 DTLSセクションに関する彼の助けのためにマイケルTuexen。 SCTP部分の改良に関する彼女の貢献のためのELISAボスキ。マーク・フルマー、セバスチャンザンダー、ジェフ・マイヤー、マウリツィオ・モリーナ、カーターブラード、タルGivoly、ルッツマーク、デビッド・ムーア、ロバート・ロウ、ポール・Calato、および技術的なレビューとフィードバックのために、より多くの。
Authors' Addresses
著者のアドレス
Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 EMail: bclaise@cisco.com
ブノワClaiseシスコシステムズデKleetlaan図6a B1 1831ディーゲムベルギー電話：+32 2 704 5622 Eメール：bclaise@cisco.com
Stewart Bryant Cisco Systems, Inc. 250, Longwater, Green Park, Reading, RG2 6GB, United Kingdom Phone: +44 (0)20 8824-8828 EMail: stbryant@cisco.com
スチュワートブライアントシスコシステムズ社250、Longwater、グリーンパーク、読書、RG2 6ギガバイト、イギリス電話：+44（0）20 8824から8828 Eメール：stbryant@cisco.com
Simon Leinen SWITCH Werdstrasse 2 P.O. Box CH-8021 Zurich Switzerland Phone: +41 44 268 1536 EMail: simon.leinen@switch.ch
サイモン・リネンスイッチWerdstrasse 2私書箱ボックスCH-8021チューリッヒスイス電話：+41 44 268 1536 Eメール：simon.leinen@switch.ch
Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-128 EMail: Thomas.Dietz@nw.neclab.eu
トーマス・ディーツNECヨーロッパ社NEC欧州研究所ネットワーク研究部門Kurfuersten-Anlageの36 69115ハイデルベルクドイツ電話：+49 6221 4342-128電子メール：Thomas.Dietz@nw.neclab.eu
Brian H. Trammell CERT Network Situational Awareness Software Engineering Institute 4500 Fifth Avenue Pittsburgh, PA 15213 United States Phone: +1 412 268 9748 EMail: bht@cert.org
ブライアンH.トラメルCERTネットワーク状況認識ソフトウェア工学研究所4500フィフスアベニューピッツバーグ、PA 15213人の米国電話：+1 412 268 9748 Eメール：bht@cert.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。