RFC5101 日本語訳
5101 Specification of the IP Flow Information Export (IPFIX) Protocolfor the Exchange of IP Traffic Flow Information. B. Claise, Ed.. January 2008. (Format: TXT=147196 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Claise, Ed. Request for Comments: 5101 Cisco Systems, Inc. Category: Standards Track January 2008
ワーキンググループB.Claise、エドをネットワークでつないでください。コメントのために以下を要求してください。 5101年のシスコシステムズInc.カテゴリ: 標準化過程2008年1月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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 Traffic Flow情報をネットワークの上に伝えるために役立つIP Flow情報Export(IPFIX)プロトコルを指定します。 伝わるように、Exporting ProcessからCollecting Process、フロー・データの共通表現、およびそれらを伝える標準の手段があるという情報までのIP Traffic Flow情報が必要です。 このドキュメントはIPFIX DataとTemplate RecordsがIPFIX Exporting ProcessからIPFIX Collecting Processまでどう運ばれるかを多くのトランスポート・プロトコルに説明します。
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
1. 序論…3 1.1. IPFIXは概要を記録します…4 2. 用語…4 2.1. 用語概要テーブル…9 3. IPFIXメッセージ・フォーマット…10 3.1. メッセージヘッダー形式…11 3.2. 特許説明書の作成書形式をさばいてください…13 3.3. ヘッダー形式を設定して、設定してください…14 3.3.1. 形式を設定してください…14 3.3.2. ヘッダー形式を設定してください…15 3.4. レコード形式…16 3.4.1. テンプレートレコード形式…16 3.4.2. オプションテンプレートレコード形式…18 3.4.2.1. 範囲…19 3.4.2.2. オプションテンプレートレコード形式…20 3.4.3. データレコード形式…22 4. 特定の報告要件…23 4.1. 計量プロセス統計オプションテンプレート…23
Claise, et al. Standards Track [Page 1] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[1ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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
4.2. 計量プロセス信頼性の統計オプションテンプレート…24 4.3. 輸出プロセス信頼性の統計オプションテンプレート…25 4.4. 流れキーオプションテンプレート…26 5. IPFIXメッセージヘッダー「輸出時間」と流れの記録的な時間…27 6. 情報モデルがあるリンケージ…28 6.1. IPFIXデータ型のコード化…28 6.1.1. 不可欠のデータ型…28 6.1.2. タイプに演説してください…28 6.1.3float32…28 6.1.4float64…28 6.1.5論理演算子…28の6.1.6ストリングとoctetarray…28 6.1.7dateTimeSeconds…29 6.1.8dateTimeMilliseconds…29 6.1.9dateTimeMicroseconds…29 6.1.10.dateTimeNanoseconds…29 6.2. 整数と浮遊物のタイプのサイズコード化を減少させます…29 7. 可変長の情報要素…30 8. テンプレート管理…31 9. 収集の過程のs側…34 10. プロトコルを輸送してください…36 10.1. コンプライアンスと輸送用法を輸送してください…36 10.2. SCTP…37 10.2.1. 混雑回避…37 10.2.2. 信頼性…37 10.2.3. MTU…37 10.2.4. 輸出プロセス…38 10.2.4.1. 協会設立…38 10.2.4.2. 協会閉鎖…38 10.2.4.3. 流れてください…38 10.2.4.4. テンプレート管理…39 10.2.5. プロセスを集めます…39 10.2.6. フェイルオーバー…39 10.3. UDP…39 10.3.1. 混雑回避…39 10.3.2. 信頼性…40 10.3.3. MTU…40 10.3.4. 数を移植してください…40 10.3.5. 輸出プロセス…40 10.3.6. テンプレート管理…40 10.3.7. プロセスを集めます…41 10.3.8. フェイルオーバー…42 10.4. TCP…42 10.4.1. 接続管理…42 10.4.1.1. 接続設立…42 10.4.1.2. 優雅なコネクション解放…43
Claise, et al. Standards Track [Page 2] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[2ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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
10.4.1.3. 再開はコネクションズを中断しました…43 10.4.1.4. フェイルオーバー…43 10.4.2. データ伝送…43 10.4.2.1. IPFIXメッセージコード化…43 10.4.2.2. テンプレート管理…44 10.4.2.3. 混雑取り扱いと信頼性…44 10.4.3. プロセスを集めます…45 11. セキュリティ問題…46 11.1. TLSとDTLSの適用性…47 11.2. 用法…48 11.3. 認証…48 11.4. DoSに対する保護は攻撃されます…48 11.5. DTLSかTLSがオプションでないときに…50 11.6. IPFIXを登録して、攻撃してください…50 11.7. コレクタを機密保護します…51 12. IANA問題…51 例をコード化する付録A.IPFIX…52 A.1。 メッセージヘッダーの例…52 A.2。 テンプレートは例を設定しました…53 A.2.1。 テンプレートはIETFによって指定されたInformation Elementsを使用することでセットしました…53 A.2.2。 テンプレートはエンタープライズ-特殊情報Elementsを使用することでセットしました…53 A.3。 データセットの例…55 A.4。 オプションテンプレートは例を設定します…56 A.4.1。 オプションテンプレートはIETFによって指定されたInformation Elementsを使用することでセットしました…56 A.4.2。 オプションテンプレートはエンタープライズ-特殊情報Elementsを使用することでセットしました…56 A.4.3。 オプションテンプレートはエンタープライズ特有の範囲を使用することでセットしました…57 A.4.4。 エンタープライズ特有の範囲を使用するデータセット…58 A.5。 可変長の情報要素の例…59 A.5.1。 255の八重奏に劣った長さがある可変長の情報要素に関する例…59 A.5.2。 長さの255〜65535の八重奏がある可変長の情報要素に関する例…59の参照箇所…59 標準の参照…59 有益な参照…60の承認…61
1. Introduction
1. 序論
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
IPトラフィックがあるデータ網はネットワーク要素を通り抜けるIP流れから主として成ります。 それが、しばしばおもしろくて、役に立って、管理である、または他でそれがネットワーク要素を通るこれらの流れの情報に近づく手段を持つのに必要でさえあります。
Claise, et al. Standards Track [Page 3] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[3ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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.
目的。 IPFIX Collecting Processは、データ網の中の複数のネットワーク要素を通り抜けながら、流れ情報を受け取るはずであることができます。 これは流れ情報を表すメソッドとネットワーク要素から収集ポイントまでの流れを伝える手段で一様性を必要とします。 このドキュメントは、これらの前述の要件を達成するためにプロトコルを指定します。 このドキュメントは詳細に異なった流れの表現を指定します、と追加データが流れ解釈、パケット・フォーマット、メカニズムが使用した輸送、安全上の配慮などのために必要としました。
1.1. IPFIX Documents Overview
1.1. 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流れ情報へのアクセスをネットワーク管理者に提供します。 Collecting ProcessへのIPFIX Exporting Processからの測定IP流れ情報の輸出のためのアーキテクチャは[IPFIX-ARCH]で定義されます、[RFC3917]で定義された要件単位で。 このドキュメントはIPFIXデータレコードとテンプレートが多くのIPFIX Exporting ProcessesからIPFIX Collecting Processesまでのトランスポート・プロトコルでどう運ばれるかを指定します。 IPFIXには、[RFC5102]の指定されるとしてのIPFIX Information Elementsの形式的記述、それらの名前、タイプ、および追加意味情報があります。 最終的に、[IPFIX-AS]は、どんなタイプのアプリケーションがIPFIXプロトコルを使用できるかを説明します、そして、それらがどう情報を使用できるかは前提とされました。 その上、それはIPFIXフレームワークがどう他のアーキテクチャとフレームワークに関連するかを示しています。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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 Traffic Flow、Exporting Process、Collecting Process、Observation Pointsなどのような基本用語の定義は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における用語概要テーブルは定義された異なった用語のいくつかの間の関係の迅速な概要を与えます。
Claise, et al. Standards Track [Page 4] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[4ページ]RFC5101IPFIXは仕様2008年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.
Observation PointはIPパケットを観察できるネットワークで位置です。 例は: 徹底的調査がどれであるかに付けられた系列、イーサネットベースのLAN、ルータの単一のポート、またはルータにおける(物理的であるか論理的)のインタフェースの1セットなどの共有された媒体。
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.
あらゆるObservation PointがObservation Domain(以下では、定義される)に関連していて、1Observation Pointが他の数個のObservation Pointsのスーパーセットであるかもしれないことに注意してください。 例えば、1Observation Pointが全体の系列カードであるかもしれません。 それは系列カードのインタフェースの個々のObservation Pointsのスーパーセットでしょう。
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.
Observation DomainはMetering ProcessがFlow情報を集めることができるObservation Pointsの最も大きいセットです。 例えば、それがいくつかのインタフェース(それのそれぞれがObservation Pointである)で構成されるなら、ルータ系列カードはObservation Domainであるかもしれません。 それが生成するIPFIX Messageでは、Observation DomainはObservation Domain IDを含んでいます。(それは、Exporting Process単位でユニークです)。 そのように、Collecting ProcessはIPFIX Messagesを送るExporterから特定のObservation Domainを特定できます。 あらゆるObservation PointがObservation Domainに関連しています。 また、Observation Domain IDもIPFIX Device単位でユニークであることは、RECOMMENDEDです。
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:
Flowはある一定の時間間隔の間ネットワークでObservation Pointを渡す1セットのIPパケットと定義されます。 特定のFlowに属すすべてのパケットが1セットの通有性を持っています。 各特性は以下の値に機能を適用するという結果と定義されます。
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. 1人以上のパケットのヘッダーが(例えば、送付先IPアドレス)、輸送ヘッダーフィールド(例えば、目的地ポートナンバー)、またはアプリケーションヘッダーフィールド(例えば、RTPヘッダーフィールド[RFC3550])をさばきます。
2. one or more characteristics of the packet itself (e.g.,
number of MPLS labels, etc...).
2. パケット(例えば、MPLSラベルなどの数)自体の1つ以上の特性。
Claise, et al. Standards Track [Page 5] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[5ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
3. one or more of fields derived from packet treatment (e.g.,
next hop IP address, the output interface, etc...).
3.分野の1つ以上がパケット処理に由来していました(例えば、次に、IPアドレス、出力インタフェースなどは跳びます。)。
A packet is defined as belonging to a Flow if it completely
satisfies all the defined properties of the Flow.
パケットはFlowのすべての定義された特性を完全に満たすなら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.
この定義はネットワーク・インターフェースで観察されたすべてのパケットを含むFlowからまさしく2つのアプリケーションの間の単一のパケットから成るFlowまでの範囲をカバーしています。 それは標本抽出メカニズムによって選択されたパケットを含んでいます。
Flow Key
流れキー
Each of the fields that:
それぞれの分野、それ:
1. belong to the packet header (e.g., destination IP address),
1. パケットのヘッダー(例えば、送付先IPアドレス)に属してください。
2. are a property of the packet itself (e.g., packet length),
2. パケット(例えば、パケット長)自体が特性があります。
3. are derived from packet treatment (e.g., Autonomous System
(AS) number),
3. パケット処理(例えば、Autonomous System(AS)番号)から、派生しています。
and that are used to define a Flow are termed Flow Keys.
そして、それによるFlowを定義するのに使用されているのが、呼ばれたFlowキーズであるということです。
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).
Flow RecordはObservation Pointで観測された特定のFlowの情報を含んでいます。 Flow RecordはFlowの測定特性(例えば、Flowのパケットのためのバイトの総数)とFlowの通常独特の特性(例えば、ソース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).
Metering ProcessはFlow Recordsを生成します。 プロセスへの入力は、Observation Point(例えば、選択された出力インタフェース)でObservation Point、およびパケット処理で観察されたパケットのヘッダーと特性です。
The Metering Process consists of a set of functions that includes
packet header capturing, timestamping, sampling, classifying, and
maintaining Flow Records.
Metering ProcessはFlow Recordsをキャプチャして、timestampingして、抽出して、分類して、維持しているパケットのヘッダーを含んでいる関数群から成ります。
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.
Flow Recordsのメインテナンスは、新しい記録を作成するのを含むかもしれません、既存のものをアップデートして、Flow統計を計算して、さらなるFlowの特性を引き出して、Flow満了を検出して、Flow RecordsをExporting Processに渡して、Flow Recordsを削除して。
Claise, et al. Standards Track [Page 6] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[6ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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.
Exporting Processは1Collecting ProcessesにFlow Recordsを送ります。 Flow Recordsは1Metering Processesによって生成されます。
Exporter
輸出業者
A device that hosts one or more Exporting Processes is termed an
Exporter.
1Exporting Processesを接待するデバイスは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 Deviceは少なくとも1Exporting Processを接待します。 それはObservation PointsとMetering Processesの一層のExporting Processesと特殊活字の数字をホスティングするかもしれません。
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.
Collecting Processは1Exporting ProcessesからFlow Recordsを受けます。 Collecting Processは容認されたFlow Recordsを処理するか、または保存するかもしれませんが、このドキュメントのための範囲の外にそのような動作があります。
Collector
コレクタ
A device that hosts one or more Collecting Processes is termed a
Collector.
1Collecting Processesを接待するデバイスは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.
Templateは<タイプ(>組がIPFIX DeviceからCollectorまでコミュニケートする必要がある特定の情報の構造と意味論を完全に指定するのに使用した長さ)の規則正しい系列です。 それぞれのTemplateはTemplate 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 MessageはこのExporting Processに関するIPFIX記録を運んで、目的地がCollecting ProcessであるExporting Processで起因するメッセージです。 IPFIX Messageはトランスポート層でカプセル化されます。
Claise, et al. Standards Track [Page 7] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[7ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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.
Message HeaderはIPFIX Messageの最初の部分です、IPFIXバージョン、メッセージの長さ、メッセージ通番などのように。(IPFIX Messageはメッセージに関する基本情報を提供します)。
Template Record
テンプレート記録
A Template Record defines the structure and interpretation of
fields in a Data Record.
Template RecordはData Recordの分野の構造と解釈を定義します。
Data Record
データレコード
A Data Record is a record that contains values of the parameters
corresponding to a Template Record.
Data Recordは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.
Options Template Recordは構造を定義するTemplate Recordであり、Data Recordの分野の解釈、その方法を定義するのを含むのは、範囲への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 Messageでは、1SetsがMessage Headerに続きます。
There are three different types of Sets: Template Set, Options
Template Set, and Data Set.
Setsの3つの異なったタイプがあります: テンプレートセット、オプションテンプレートセット、およびデータセット。
Template Set
テンプレートセット
A Template Set is a collection of one or more Template Records
that have been grouped together in an IPFIX Message.
Template SetはIPFIX Messageで一緒に分類された1Template Recordsの収集です。
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.
Options Template SetはIPFIX Messageで一緒に分類された1Options Template Recordsの収集です。
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.
Data SetはIPFIX Messageで一緒に分類される同じタイプの1Data Recordsです。 各Data Recordは以前に、Template RecordかOptions Template Recordによって定義されます。
Claise, et al. Standards Track [Page 8] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[8ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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.
情報ElementはIPFIX Recordに現れるかもしれない属性のプロトコルとコード化して独立している記述です。 IPFIX情報モデル[RFC5102]はIPFIXのためにInformation Elementsの基底集合を定義します。 情報Elementに関連しているタイプは、それが何を含むかもしれないかに関して規制を示して、また、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.
Stream Control Transmissionプロトコル(SCTP)で、輸送セッションはSCTP協会として知られています。(SCTP終点[RFC4960]によってそれは、唯一特定されます)。 TCPでは、輸送セッションはTCP接続として知られています。(それは、ポートが使用したIPアドレスとTCPの組み合わせで唯一特定されます)。 UDPでは、輸送セッションはUDPセッションとして知られています。(それは、ポートが使用したIPアドレスとUDPの組み合わせで唯一特定されます)。
2.1. Terminology Summary Table
2.1. 用語概要テーブル
+------------------+---------------------------------------------+ | | 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.
Data SetはData Record(s)で構成されます。 どんなTemplate Recordも含まれていません。 Template RecordかOptions Template RecordがData Recordを定義します。
A Template Set contains only Template Record(s).
Template SetはTemplate Record(s)だけを含んでいます。
An Options Template Set contains only Options Template Record(s).
Options Template SetはOptions Template Record(s)だけを含んでいます。
Claise, et al. Standards Track [Page 9] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[9ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
3. IPFIX Message Format
3. IPFIXメッセージ・フォーマット
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 Messageは1Setsによって続かれたMessage Headerから成ります。 Setsは可能な3つのタイプのいずれであることができますも: データセット、テンプレートセット、またはオプションテンプレートがセットしました。
The format of the IPFIX Message is shown in Figure B.
IPFIX Messageの書式は図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).
Exporterはネットワークバイトオーダー(また、ビッグエンディアンバイト順として、知られている)でMessage Headerと異なったSetsのすべての2進整数をコード化しなければなりません。
Following are some examples of IPFIX Messages:
以下に、IPFIX Messagesに関するいくつかの例があります:
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. はさみ込まれたTemplate、Data、およびOptions Template Setsから成るIPFIX Message--新たに作成されたTemplateはできるだけ早く、エクスポートされます。 それで、輸出のために準備されているData SetとIPFIX Messageが既にあれば、TemplateとOption Template Setsはスペースの有用性を条件としたこの情報ではさみ込まれます。
+--------+--------------------------------------------------------+ | | +----------+ +---------+ +-----------+ +---------+ | |Message | | Template | | Data | | Options | | Data | | | Header | | Set | | Set | ... | Template | | Set | | | | | | | | | Set | | | | | | +----------+ +---------+ +-----------+ +---------+ | +--------+--------------------------------------------------------+
+--------+--------------------------------------------------------+ | | +----------+ +---------+ +-----------+ +---------+ | |メッセージ| | テンプレート| | データ| | オプション| | データ| | | ヘッダー| | セットします。| | セットします。| ... | テンプレート| | セットします。| | | | | | | | | セットします。| | | | | | +----------+ +---------+ +-----------+ +---------+ | +--------+--------------------------------------------------------+
Figure C: IPFIX Message, Example 1
図C: IPFIXメッセージ、例1
Claise, et al. Standards Track [Page 10] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[10ページ]RFC5101IPFIXは仕様2008年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. Data Setsから完全に成るIPFIX Message--適切なTemplate RecordsがCollecting Processに定義されて、伝えられた後に、IPFIX Messagesの大部分が唯一Data Setsから成ります。
+--------+----------------------------------------------+ | | +---------+ +---------+ +---------+ | |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. TemplateとOptions Template Setsから完全に成るIPFIX Message。
+--------+-------------------------------------------------+ | | +----------+ +----------+ +----------+ | |Message | | Template | | Template | | Options | | | Header | | Set | ... | Set | ... | Template | | | | | | | | | Set | | | | +----------+ +----------+ +----------+ | +--------+-------------------------------------------------+
+--------+-------------------------------------------------+ | | +----------+ +----------+ +----------+ | |メッセージ| | テンプレート| | テンプレート| | オプション| | | ヘッダー| | セットします。| ... | セットします。| ... | テンプレート| | | | | | | | | セットします。| | | | +----------+ +----------+ +----------+ | +--------+-------------------------------------------------+
Figure E: IPFIX Message, Example 3
図E: IPFIXメッセージ、例3
3.1. Message Header Format
3.1. メッセージヘッダー形式
The format of the IPFIX Message Header is shown in Figure F.
IPFIX Message Headerの書式は図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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン番号| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 輸出時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 観測ドメインID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure F: IPFIX Message Header Format
図F: IPFIXメッセージヘッダー形式
Claise, et al. Standards Track [Page 11] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[11ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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].
Flow Record形式のバージョンはこのメッセージでエクスポートしました。 この分野の値が最新版のための0x000aである、バージョンを1つ増加すると、NetFlowサービスでは、輸出バージョン9[RFC3954]は使用されました。
Length
長さ
Total length of the IPFIX Message, measured in octets, including
Message Header and Set(s).
Message HeaderとSet(s)を含む八重奏で測定されたIPFIX Messageの全長。
Export Time
輸出時間
Time, in seconds, since 0000 UTC Jan 1, 1970, at which the IPFIX
Message Header leaves the Exporter.
1970年1月1日協定世界時0000以来の秒の時間。(その時、IPFIX Message HeaderはExporterを残します)。
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.
すべてのIPFIX Data Recordsの増加の系列カウンタ法2^32はExporting Processで現在のObservation DomainからこのPR-SCTPストリームを転送しました。 UDPかTCPがトランスポート・プロトコルとして選定されたらセクション10の小区分におけるこの分野の特定の意味をチェックしてください。 これはSHOULDを評価します。何かIPFIX Data Recordsがいなくて寂しかったかどうか特定するのがCollecting Processによって使用されてください。 テンプレートとOptions Template RecordsはSequence Numberを増強しません。
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.
局所的にExporting ProcessにユニークなObservation Domainの32ビットの識別子。 Exporting Processは、唯一Flowsを計量したObservation DomainをCollecting Processに特定するのにObservation Domain IDを使用します。 また、この識別子もIPFIX Device単位でユニークであることは、RECOMMENDEDです。 Transport SessionとObservation Domain IDが異なった輸出を切り離すためにさばくProcesses SHOULD使用を集めるのは、同じExporting Processから発しながら、流れます。 Observation Domain ID SHOULD、Exporting Process Statisticsをエクスポートするとき、例えば、全体のIPFIX Messageにおいて、どんな特定のObservation Domain IDも関連していないか、または集められるとData RecordsがCollectorsの階層構造の場合にエクスポートされたら0になってください。
Claise, et al. Standards Track [Page 12] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[12ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
3.2. Field Specifier Format
3.2. 分野特許説明書の作成書形式
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.
ベンダーは独占Information Elementsを定義する能力を必要とします、例えば、プレ規格製品を提供しているか、または情報Elementが何らかの方法で商業的に敏感であるので。 このセクションはIETFによって指定されたInformation Elements[RFC5102]と企業特有のInformation Elementsの両方のためにField Specifier形式について説明します。
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.
Information Elementsは情報Element識別子によって特定されます。 エンタープライズビットが0に設定されるとき、対応する情報Element識別子はIETFによって指定された情報Elementを報告するでしょう、そして、エンタープライズNumberは存在しているはずがありません。 エンタープライズビットが1に設定されるとき、対応する情報Element識別子は企業特有の情報Elementを報告するでしょう。 エンタープライズNumberは存在していなければなりません。 この例はセクションA.4.2に示されます。
The Field Specifier format is shown in Figure G.
Field Specifier書式は図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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 情報Element ident。 | フィールド長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エンタープライズ番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure G: Field Specifier Format
図G: 分野特許説明書の作成書形式
Where:
どこ:
E
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.
エンタープライズに噛み付きました。 これはField Specifierの最初のビットです。 このビットがゼロであるなら、情報Element IdentifierはIETFによって指定された情報Elementを特定します、そして、4八重奏のエンタープライズNumber分野は存在しているはずがありません。 このビットが1であるなら、情報Element識別子は企業特有の情報Elementを特定します、そして、Numberがファイルしたエンタープライズは存在していなければなりません。
Information Element identifier
情報Element識別子
A numeric value that represents the type of Information Element.
Refer to [RFC5102].
情報Elementのタイプの代理をする数値。 [RFC5102]を参照してください。
Claise, et al. Standards Track [Page 13] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[13ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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).
対応の長さは八重奏で情報Elementをコード化しました。 [RFC5102]を参照してください。 減少しているサイズコード化が使用されているなら(セクション6.2を見てください)、フィールド長は[RFC5102]との定義よりわずかであるかもしれません。 値65535は変数の長さのInformation Elementsのために予約されます(セクション7を見てください)。
Enterprise Number
エンタープライズ番号
IANA enterprise number [PEN] of the authority defining the
Information Element identifier in this Template Record.
このTemplate Recordの情報Element識別子を定義する権威のIANA企業番号[PEN]。
3.3. Set and Set Header Format
3.3. ヘッダー形式を設定して、設定してください。
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.
Setは類似構造物を持っている記録の収集のための総称です。 Setsの3つの異なったタイプがあります: テンプレートセット、オプションテンプレートセット、およびデータセット。 それぞれのこれらのSetsはSet Headerと1つ以上の記録から成ります。 Set FormatとSet Header Formatは以下のセクションで定義されます。
3.3.1. Set Format
3.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.
Setには、図H.にレコード種類がTemplate Records、Options Template RecordsかData Recordsのどちらかであるかもしれないことが示された書式があります。 レコード種類はSetの中で複雑であってはいけません。
+--------------------------------------------------+
| Set Header |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
...
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| Padding (opt.) |
+--------------------------------------------------+
+--------------------------------------------------+ | ヘッダーを設定してください。| +--------------------------------------------------+ | 記録| +--------------------------------------------------+ | 記録| +--------------------------------------------------+ ... +--------------------------------------------------+ | 記録| +--------------------------------------------------+ | 詰め物(選んでください。) | +--------------------------------------------------+
Figure H: Set Format
図H: 形式を設定してください。
The Set Field Definitions are as follows:
Set Field Definitionsは以下の通りです:
Set Header
ヘッダーを設定してください。
The Set Header Format is defined in Section 3.3.2.
Set Header Formatはセクション3.3.2で定義されます。
Claise, et al. Standards Track [Page 14] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[14ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
Record
記録
One of the record Formats: Template Record, Options Template
Record, or Data Record Format.
記録的なFormatsの1つ: テンプレート記録、オプションテンプレート記録、またはデータレコード形式。
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.
Exporting Processは、その後のSetが並べられた境界で始まるように、いくつかの詰め物八重奏を挿入するかもしれません。 安全保障上の理由で、どんな(0)の評価された八重奏でも詰め物八重奏を構成してはいけません。 詰め物の長さはこのSetでのどんな許容できる記録よりも短いに違いありません。 IPFIX Messageの詰め物が非常に短い記録と組み合わせて望まれているなら記録を水増しするのに、詰め物情報Element'paddingOctets'[RFC5102]を使用できるので、それらの長さは4か8つの八重奏の倍数まで増強されます。 いつもTemplate Setsが定義上並べられた、4八重奏であるので、詰め物が例えば、8八重奏の境界における他の整列の場合に必要であるだけです。
3.3.2. Set Header Format
3.3.2. ヘッダー形式を設定してください。
Every Set contains a common header. This header is defined in Figure I.
あらゆるSetが一般的なヘッダーを含んでいます。 このヘッダーは図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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDを設定してください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure I: Set Header Format
図I: ヘッダー形式を設定してください。
The Set Header Field Definitions are as follows:
Set Header Field Definitionsは以下の通りです:
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価値はSetを特定します。 2の値はTemplate Setのために予約されます。 3の値はOption Template Setのために予約されます。 他のすべての4〜255までの値が今後の使用のために予約されます。 255を超えた値はData Setsに使用されます。 0と1のSet 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 Header、すべての記録、および任意の詰め物を含む八重奏における、Setの全長。 個々のSetが複数の記録を含むかもしれないので、次のSetの位置を決定するのにLength値を使用しなければなりません。
Claise, et al. Standards Track [Page 15] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[15ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
3.4. Record Format
3.4. レコード形式
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つのレコード形式を定義します: テンプレートレコード形式、オプションテンプレートレコード形式、およびデータレコード形式。
3.4.1. Template Record Format
3.4.1. テンプレートレコード形式
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レコード形式の必須元素の1つはTemplate Recordです。 それらがCollecting Processに必ずすべてのData Recordsの解釈を知っているというわけではなくてIPFIX Messagesを処理させるので、テンプレートはレコード形式の柔軟性を大いに高めます。 Template RecordはIANAによって割り当てられたそして/または、企業特有の情報Elements識別子のどんな組み合わせも含んでいます。
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.
Template Recordの書式は図J.にItがTemplate Record Headerと1Field Specifiersから成るのが示されます。 図GでField Specifiersの定義を上に与えます。
+--------------------------------------------------+
| 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.
Template Record Headerの書式は図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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID(>255)| 分野カウント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure K: Template Record Header Format
図K: テンプレート記録ヘッダー形式
Claise, et al. Standards Track [Page 16] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[16ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
The Template Record Header Field Definitions are as follows:
Template Record Header Field Definitionsは以下の通りです:
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.
それぞれの新たに生成しているTemplate RecordsにユニークなTemplate IDを与えます。 このユニークさはTemplate IDを生成したTransport SessionとObservation Domainに地方です。 テンプレートID0-255は、Template Sets、Options Template Sets、および他の予約されたSetsにもかかわらず、作成されるために予約されます。 Data SetsのテンプレートIDは256〜65535まで付番されます。 Template ID配分の注文に関して規制が全くありません。
Field Count
分野カウント
Number of fields in this Template Record.
この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の例は混ぜられた標準の、そして、企業特有のInformation Elementsと共にTemplate Setを示しています。 それはSet Header、Template Header、および数個のField Specifiersから成ります。
Claise, et al. Standards Track [Page 17] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[17ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=2を設定してください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID=256| 分野カウント=N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 情報Elementイド。 1.1 | フィールド長1.1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エンタープライズNo.1.1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| 情報Elementイド。 1.2 | フィールド長1.2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 情報Elementイド。 1. N| フィールド長1.N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エンタープライズ数の1.N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID=257| 分野カウント=M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| 情報Elementイド。 2.1 | フィールド長2.1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 情報Elementイド。 2.2 | フィールド長2.2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エンタープライズNo.2.2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 情報Elementイド。 2. M| フィールド長2.M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エンタープライズ数の2.M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 詰め物(選びます)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
情報Element Identifiers1.2と2.1はIETF(エンタープライズは=0に噛み付いた)によって定義されて、したがって、エンタープライズNumberは彼らを特定する必要はありません。
3.4.2. Options Template Record Format
3.4.2. オプションテンプレートレコード形式
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.
範囲の概念のおかげで、Options Template RecordはFlow Recordsが単独の状態で可能でないCollectorに追加情報を供給する能力をExporterに与えます。
Claise, et al. Standards Track [Page 18] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[18ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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.
1つのOptions Template Recordの例が範囲と定義されるTemplateのためにFlowキーズを報告する「流れキー」です。 別の例は範囲と定義されるTemplateのための構成標本抽出パラメタを報告する「テンプレート構成」です。
3.4.2.1. Scope
3.4.2.1. 範囲
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.
範囲(Options Template Setだけで利用可能である)はData Recordsで報告されたInformation Elementsの文脈を与えます。 IPFIX Message Headerが既に、Observation Domain ID(Observation Domainに関する識別子)を含むことに注意してください。 まして、ゼロ、IPFIX MessageのData Recordsにおいて、内在している範囲であるとこのObservation Domain IDをみなすことができます。 IPFIX Messageが異なったObservation Domain ID値が範囲と定義されているData Recordsを含むとき、Observation Domain 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.
複数のScopeフィールズがOptions Template Recordに出席しているかもしれない、その場合、合成範囲は範囲の組み合わせです。 例えば、範囲は2であるなら「プロセスを計量します」と「テンプレート」と定義されて、結合した範囲はこのMetering ProcessのためのこのTemplateです。 Options Template Recordで定義するScopeフィールズの注文はこの場合無関係です。 しかしながら、Options Template RecordでのScopeフィールズの注文が関連しているなら、Scopeフィールズの注文を使用しなければなりません。 最初の範囲がフィルタ機能を定義しますが、例えば、範囲の注文は重要であって、2番目の範囲は標本抽出機能を定義します。 標本抽出機能を適用して、フィルタ機能があとに続いた1番目は潜在的に最初にフィルタ機能を適用するのと異なったData Recordsに通じるでしょう、標本抽出機能があとに続いていて。 この場合、Collectorは、Options Template Recordでの範囲の注文を見ることによって、機能オーダーを推論します。
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情報Model[RFC5102]で指定された情報Elementです。 この最小限が設定した範囲としてのInformation ElementsのCollecting Process SHOULDサポートのIPFIX対応することの実装: LineCardId、TemplateId、exporterIPv4Address、exporterIPv6Address、およびingressInterface。 また、meteringProcessIdなどの他のInformation Elements、exportingProcessId、observationDomainIdなどが有効な範囲であることに注意してください。 IPFIXプロトコルはどんなInformation Elementsの範囲の使用も防ぎません。 しかしながら、範囲として指定されるなら、何人かの情報Elementタイプは理解できません。 例えば、カウンタInformation Elements。
Finally, note that the Scope Field Count MUST NOT be zero.
最終的に、Scope Field Countがゼロであるはずがないことに注意してください。
Claise, et al. Standards Track [Page 19] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[19ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
3.4.2.2. Options Template Record Format
3.4.2.2. オプションテンプレートレコード形式
An Options Template Record contains any combination of IANA-assigned and/or enterprise-specific Information Elements identifiers.
Options Template RecordはIANAによって割り当てられたそして/または、企業特有の情報Elements識別子のどんな組み合わせも含んでいます。
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.
Options Template Recordの書式は図M.にItがOptions Template Record Headerと1Field Specifiersから成るのが示されます。 図GでField Specifiersの定義を上に与えます。
+--------------------------------------------------+
| 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.
Options Template Record Headerの書式は図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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID(>255)| 分野カウント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 範囲分野カウント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure N: Options Template Record Header Format
Nは計算します: オプションテンプレート記録ヘッダー形式
The Options Template Record Header Field Definitions are as follows:
Options Template Record Header Field Definitionsは以下の通りです:
Template ID
テンプレートID
Template ID of this Options Template Record. This value is greater than 255.
このOptions Template RecordのテンプレートID。 この値は255以上です。
Claise, et al. Standards Track [Page 20] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[20ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
Field Count
分野カウント
Number of all fields in this Options Template Record, including the Scope Fields.
Scopeフィールズを含むこのOptions Template Recordのすべての分野の数。
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.
このOptions Template Recordの範囲分野の数。 それらが範囲としてCollectorで解釈されるのを除いて、Scopeフィールズは普通のフィールズです。 Scope Field Countはゼロであるはずがありません。
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と企業特有のInformation Elementsと共にOption Template Setを示しています。 それはSet Header、Option Template Header、および数個のField Specifiersから成ります。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=3を設定してください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID=258| 分野カウント=N+M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 範囲分野カウント=N|0| 範囲1Infor。 Elementアイダホ州 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 範囲1フィールド長|0| 範囲2Infor。 Elementアイダホ州 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 範囲2フィールド長| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |1| 範囲N Infor。 Elementアイダホ州 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 範囲Nフィールド長| 範囲Nエンタープライズ番号… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 範囲Nエンタープライズ番号|1| オプション1Infor。 Elementアイダホ州 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション1フィールド長| オプション1エンタープライズ番号… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... オプション1エンタープライズ番号| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |0| オプションM Infor。 Elementアイダホ州 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションMは長さをさばきます。| 詰め物(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure O: Option Template Set Example
図O: オプションテンプレートセットの例
Claise, et al. Standards Track [Page 21] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[21ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
3.4.3. Data Record Format
3.4.3. データレコード形式
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".
Data SetsでData Recordsを送ります。 Data Recordの書式は図P.にItが1Field Valuesだけから成るのが示されます。 Field Valuesが属するTemplate IDはSet Header分野「セットID」でコード化されます、すなわち、「セットID」は「Template 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].
Field Valuesには16ビットの長さが必ずあるというわけではないことに注意してください。 [RFC5102]で指定された彼らのデータ型によると、分野Valuesはコード化されます。
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.
Template IDに対応するTemplate RecordがCollecting Processで利用可能である場合にだけ、Data Record形式の解釈ができます。
The example in Figure Q shows a Data Set. It consists of a Set Header and several Field Values.
図Qの例はData Setを示しています。 それはSet Headerと数個のField Valuesから成ります。
Claise, et al. Standards Track [Page 22] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[22ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=IDを設定してください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 記録1--分野値1| 記録1--分野値2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 記録1--分野値3| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 記録2--分野値1| 記録2--分野値2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 記録2--分野値3| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 記録3--分野値1| 記録3--分野値2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 記録3--分野値3| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 詰め物(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure Q: Data Set, Containing Data Records
図Q: データレコードを含むデータセット
4. Specific Reporting Requirements
4. 特定の報告要件
Some specific Options Templates and Options Template Records are necessary to provide extra information about the Flow Records and about the Metering Process.
いくつかの特定のOptions TemplatesとOptions Template Recordsが、Flow Recordsと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.
これらの小区分で定義されたOption TemplateとOptions Template Recordsは実装されるかもしれません。小区分はMetering ProcessとExporting Process実装にいくつかの規制を課します。 実装される、特定のOption Templates SHOULD、これらの小区分で指定されるように、実装されてください。
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.
Information Elementsの最小のセットはこれらのSpecific IPFIX Options Templatesでいつも指定されます。 それにもかかわらず、付加的なInformation Elementsはこれらの特定のOptions Templatesで使用されるかもしれません。
4.1. The Metering Process Statistics Option Template
4.1. 計量プロセス統計オプションテンプレート
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]:
Metering Process Statistics Option TemplateはMetering Process統計を報告するのにData Recordの構造を指定します。 それ、SHOULDは中で定義される以下のInformation Elements[RFC5102]を含みます:
Claise, et al. Standards Track [Page 23] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[23ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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.
局所的にExporting ProcessにユニークなObservation Domainに関するobservationDomainId An識別子。 この情報ElementをScope Fieldと定義しなければなりません。
exportedMessageTotalCount
The total number of IPFIX Messages that the
Exporting Process successfully sent to the
Collecting Process since the Exporting
Process re-initialization.
exportedMessageTotalCount、Exporting Process再初期化以来Exporting Processが首尾よくCollecting Processに送ったIPFIX Messagesの総数。
exportedFlowTotalCount
The total number of Flow Records that the
Exporting Process successfully sent to the
Collecting Process since the Exporting
Process re-initialization.
exportedFlowTotalCount、Exporting Process再初期化以来Exporting Processが首尾よくCollecting Processに送ったFlow Recordsの総数。
exportedOctetTotalCount
The total number of octets that the Exporting
Process successfully sent to the Collecting
Process since the Exporting Process re-
initialization.
exportedOctetTotalCount、Exporting Process再初期化以来Exporting Processが首尾よくCollecting Processに送った八重奏の総数。
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.
Exporting Process SHOULDは定期的にMetering Process Statistics Option Templateによって指定されるか、または何らかの輸出方針に基づくData Recordをエクスポートします。 方針がSHOULDであるとエクスポートしてください。または、この周期性、構成可能であってください。
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.
数個のMetering ProcessesがExporter Observation Domainで利用可能であるなら、追加Scope Fieldとして情報Element meteringProcessIdを指定しなければならないことに注意してください。
4.2. The Metering Process Reliability Statistics Option Template
4.2. 計量プロセス信頼性の統計オプションテンプレート
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]:
Metering Process Reliability Option TemplateはMetering Processの信頼性の不足を報告するのにData Recordの構造を指定します。 それ、SHOULDは中で定義される以下のInformation Elements[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.
局所的にExporting ProcessにユニークなObservation Domainに関するobservationDomainId An識別子。 この情報ElementをScope Fieldと定義しなければなりません。
Claise, et al. Standards Track [Page 24] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[24ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
ignoredPacketTotalCount
The total number of IP packets that the
Metering Process did not process.
ignoredPacketTotalCount、Metering ProcessがしたIPパケットの総数は処理されません。
ignoredOctetTotalCount
The total number of octets in observed IP
packets that the Metering Process did not
process.
ignoredOctetTotalCount、Metering Processがした観測されたIPパケットの八重奏の総数は処理されません。
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.
1番目がMetering Processによって無視された最初のIPパケットに関するタイムスタンプを無視した時。 このタイムスタンプのために、"flowStart"タイムスタンプ情報のElements 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.
時間は最後にMetering Processによって無視された最後のIPパケットに関するタイムスタンプを無視しました。 このタイムスタンプのために、"flowEnd"タイムスタンプ情報のElements 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.
Exporting Process SHOULDは定期的にMetering Process Reliability Statistics Option Templateによって指定されるか、または何らかの輸出方針に基づくData Recordをエクスポートします。 方針がSHOULDであるとエクスポートしてください。または、この周期性、構成可能であってください。
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.
数個のMetering ProcessesがExporter Observation Domainで利用可能であるなら、追加Scope Fieldとして情報Element meteringProcessIdを指定しなければならないことに注意してください。
4.3. The Exporting Process Reliability Statistics Option Template
4.3. 輸出プロセス信頼性の統計オプションテンプレート
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]:
Exporting Process Reliability Option TemplateはExportingプロセスの信頼性の不足を報告するのにData Recordの構造を指定します。 それ、SHOULDは中で定義される以下のInformation Elements[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
信頼性のどの不足によってProcess IDがExporting Processに関する識別子であるとエクスポートするかが報告されます。 Information Elementsがこのために使用できる[RFC5102]で指定した3があります: またはexporterIPv4Address、exporterIPv6Address。
Claise, et al. Standards Track [Page 25] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[25ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
exportingProcessId. This Information Element
MUST be defined as a Scope Field.
exportingProcessId。 この情報ElementをScope Fieldと定義しなければなりません。
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、Collecting Processに送ることの代わりに、Metering Processによって生成されて、Metering ProcessかExporting Processによって下げられたFlowsの総数。
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、Metering Processによって生成されて、Metering Processに立ち寄ったFlow RecordsかCollecting Processに送ることの代わりにExporting Processによるパケットの総数。
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、Metering Processによって生成されて、Metering Processに立ち寄ったFlow RecordsかCollecting Processに送ることの代わりにExporting Processによるパケットの八重奏の総数。
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.
最初に、流れるのが最初のFlowに関するタイムスタンプを下げた時はMetering Processによって下げられました。 このタイムスタンプのために、"flowStart"タイムスタンプ情報のElements 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.
最後の流れがMetering Processによって無視された最後のIPパケットに関するタイムスタンプを下げた時。 このタイムスタンプのために、"flowEnd"タイムスタンプ情報のElements 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.
Exporting Process SHOULDは定期的にExporting Process Reliability Statistics Option Templateによって指定されるか、または何らかの輸出方針に基づくData Recordをエクスポートします。 方針がSHOULDであるとエクスポートしてください。または、この周期性、構成可能であってください。
4.4. The Flow Keys Option Template
4.4. 流れキーオプションテンプレート
The Flow Keys Option Template specifies the structure of a Data Record for reporting the Flow Keys of reported Flows. A Flow Keys
FlowキーズOption Templateは報告されたFlowsのFlowキーズを報告するのにData Recordの構造を指定します。 Flowキーズ
Claise, et al. Standards Track [Page 26] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[26ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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.
データRecordはtemplateId識別子によって参照をつけられる特定のTemplate Recordを広げています。 Template Recordは、指定することによって、広げられます(Elementsが対応するData Recordsに含んだ情報について報告されたFlowのFlowキーズとして役立つFlowの特性を記述します)。
The Flow Keys Option Template SHOULD contain the following Information Elements that are defined in [RFC5102]:
FlowキーズOption Template SHOULDは[RFC5102]で定義される以下のInformation Elementsを含みます:
templateId An identifier of a Template. This
Information Element MUST be defined as a
Scope Field.
Templateに関するtemplateId An識別子。 この情報ElementをScope Fieldと定義しなければなりません。
flowKeyIndicator Bitmap with the positions of the Flow Keys in
the Data Records.
Data RecordsのFlowキーズの位置があるflowKeyIndicator Bitmap。
5. IPFIX Message Header "Export Time" and Flow Record Time
5. IPFIXメッセージヘッダー「輸出時間」と流れの記録的な時間
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 Message Header「輸出時間」分野は1970年1月1日協定世界時0000以来の秒の時間です。(その時、IPFIX Message HeaderはExporterを残します)。 Elementsが[RFC5102]で指定した時間関連の情報は、ベース時間としてこの「輸出時間」を使用して、それに比例してオフセットを指定するかもしれません、一般的なベース時間を費やすことの代わりに、1970年1月1日協定世界時0000などのように。 そうしないInformation Elementsは持っていました。それらのデータ型によって定義された彼らのベース時間で、彼らの記述で明確にベース時間を指定しなければなりません。
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.
例えば、マイクロセカンド精度を必要とするData Recordsは、flowStartMicrosecondsとflowEndMicroseconds Information Elements[RFC5102]と共に流れが始めと終わりの回であるとエクスポートすることができます、1970年1月1日協定世界時0000以来の時間を含んでいて。 それぞれ流れを報告するData RecordのflowEndDeltaMicroseconds情報Elements[RFC5102]は始まります、そして、代替策がflowStartDeltaMicrosecondsをエクスポートすることであり、IPFIX Message Header「輸出時間」と比べて、終わりの時間は相殺されます。 Exporterで負荷を増強している間、後者のソリューションは輸出帯域幅要件を下ろします、IPFIX Messageをエクスポートする前にExporting ProcessがあらゆるData Recordの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 Message Header「輸出時間」と比べて、オフセット回と共に時間関連のInformation Elementsを使用するといくつかの時間規制がIPFIX Messageに含まれたData Recordsにつけ込むことに注意しなければなりません。 flowStartDeltaMicrosecondsとflowEndDeltaMicroseconds Information Elements[RFC5102]の例では、作成の後最大71分以内にData Recordをエクスポートしなければなりません。 さもなければ、32ビットのカウンタは、流れ開始時刻オフセットを含むように十分でないでしょう。
Claise, et al. Standards Track [Page 27] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[27ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
6. Linkage with the Information Model
6. 情報モデルがあるリンケージ
The Information Elements [RFC5102] MUST be sent in canonical format in network-byte order (also known as the big-endian byte ordering).
ネットワークバイトオーダーにおける正準な形式でInformation Elements[RFC5102]を送らなければなりません(また、ビッグエンディアンバイト順として、知られています)。
6.1. Encoding of IPFIX Data Types
6.1. IPFIXデータ型のコード化
The following sections will define the encoding of the data types specified in [RFC5102].
以下のセクションは[RFC5102]で指定されたデータ型のコード化を定義するでしょう。
6.1.1. Integral Data Types
6.1.1. 不可欠のデータ型
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)をコード化しなければなりません。 署名しているIntegralデータ型は2の補数記法で表されます。
6.1.2. Address Types
6.1.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は6八重奏の整数、4八重奏の整数としてのipv4Address、および16八重奏の整数としてのipv6Addressとして扱われます。
6.1.3. float32
6.1.3. float32
The float32 data type MUST be encoded as an IEEE single-precision 32-bit floating point-type, as specified in [IEEE.754.1985].
IEEEの単精度の32ビットの浮動小数点タイプ、中で指定にされるとしてfloat32データ型をコード化しなければならない、[IEEE、.754、.1985、]
6.1.4. float64
6.1.4. float64
The float64 data type MUST be encoded as an IEEE double-precision 64-bit floating point-type, as specified in [IEEE.754.1985].
IEEEの倍精度の64ビットの浮動小数点タイプ、中で指定にされるとしてfloat64データ型をコード化しなければならない、[IEEE、.754、.1985、]
6.1.5. boolean
6.1.5. 論理演算子
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によると、論理演算子データ型は指定されます: 偽のための本当、そして、a値2のための値1に従って、それは整数です。 他のあらゆる値が未定義です。 ただ一つの八重奏で論理演算子データ型をコード化しなければなりません。
6.1.6. string and octetarray
6.1.6. ストリングとoctetarray
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.
データ型ストリングはユニコード文字符号化セットの有効なキャラクタの有限長さのストリングを表します。 UTF-8形式で列データタイプをコード化しなければなりません。 八重奏の勢ぞろいとして修理されたか可変な長さの情報Elementを使用することでストリングを送ります。
Claise, et al. Standards Track [Page 28] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[28ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
The length of the Information Element specifies the length of the octetarray.
情報Elementの長さはoctetarrayの長さを指定します。
6.1.7. dateTimeSeconds
6.1.7. dateTimeSeconds
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はユニットの秒に時間的価値を表します。グリニッジ標準時までタイムゾーンを正常にしました。 1970年1月1日協定世界時0000以来秒数を含む32ビットの整数でそれをコード化しなければなりません。 32ビットの整数は、最大136年をコード化しながら、時間を許容します。
6.1.8. dateTimeMilliseconds
6.1.8. dateTimeMilliseconds
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はユニットのミリセカンドで時間的価値を表します。グリニッジ標準時までタイムゾーンを正常にしました。 1970年1月1日協定世界時0000以来ミリセカンドの数を含む64ビットの整数でそれをコード化しなければなりません。
6.1.9. dateTimeMicroseconds
6.1.9. dateTimeMicroseconds
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はユニットのマイクロセカンドのときに時間的価値を表します。グリニッジ標準時までタイムゾーンを正常にしました。 [RFC1305]で与えられたNTP書式によると、64ビットの整数でそれをコード化しなければなりません。
6.1.10. dateTimeNanoseconds
6.1.10. dateTimeNanoseconds
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に関するデータ型はユニットの数ナノ秒に時間的価値を表します。グリニッジ標準時まで時間帯を正常にしました。 [RFC1305]で与えられたNTP書式によると、64ビットの整数でそれをコード化しなければなりません。
6.2. Reduced Size Encoding of Integer and Float Types
6.2. 整数と浮遊物のタイプの減少しているサイズコード化
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.
情報の整数を含むElements、ストリング、浮遊物、およびoctetarrayは情報モデル定義[RFC5102]で彼らのタイプによって暗示されたものより少ない八重奏を使用することでモデルがコード化されるかもしれないという情報をタイプします、さらに小さいサイズがExporterが提供する必要があるかもしれないどんな値も運ぶことができるくらいの仮定に基づいて。これはExporterとCollectorの間のネットワーク帯域幅要件を減らします。 情報Element定義[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]はunsigned64タイプとbyteCountを定義します。(タイプは64ビットを必要とするでしょう)。 しかしながら、Exporterが局所的に4294967295より大きい値を送る必要性に決して直面しないなら、それは直面しています。unsigned32として代わりに値を送るのを選びました。 例えば、コアルータはunsigned64 byteCountを必要とするでしょうが、unsigned32はアクセスルータに十分であるかもしれません。
Claise, et al. Standards Track [Page 29] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[29ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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.
この振舞いは、情報Elementの割り当てられたタイプに従ったそれよりわずかな長さが関連しているタイプサイズを指定することによって、Exporterによって示されます。 例では、上では、Exporterが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。 報告された価値の未署名の特性に対する署名することを保存しなければなりません。 データ値がまだ合っているなら、原型より小さいいろいろな八重奏には寸法縮小があることができます、すなわち、主なゼロだけが下げられるように。 例えば、7、6、5、4、3、2、または1つの八重奏にunsigned64のサイズを縮小されることができます。
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.
また、float64をfloat32に変えるのに減少しているサイズ処理を使用できます。 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に減少しているサイズコード化を適用してはいけません。
7. Variable-Length Information Element
7. 可変長の情報要素
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 Templateメカニズムは固定長Information Elements[RFC5102]のために最適化されます。 情報Elementには可変長があるところでは、IETFと独占Information Elementsの両方のための長さの情報を運ぶのに以下のメカニズムを使用しなければなりません。
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.
Template Setに、情報Element Field Lengthは65535として記録されます。 この予約された長さの値は、情報Elementの長さが情報Element内容自体で運ばれるようにCollecting Processに通知します。
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.
多くの場合、情報Elementの長さは255未満の八重奏になるでしょう。 以下の長さをコード化するメカニズムはこの大多数事件における情報Elementの長さを運ぶオーバーヘッドを最適化します。 長さは図Rに示されるように八重奏で情報Elementの前まで運ばれます。
Claise, et al. Standards Track [Page 30] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[30ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (< 255)| Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)| 情報要素| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 必要に応じて、続きます…。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
情報Elementの長さが255以上の八重奏であるなら、長さは情報Elementの前の3つの八重奏にコード化されます。 最初の八重奏は255です、そして、長さは2番目と3番目の八重奏で運ばれます、図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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | 長さ(0〜65535)| IE| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 必要に応じて、続きます…。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
情報Elementの長さに長さ(1番目か最初の3つの八重奏のどちらか)を運ぶ八重奏を含んではいけません。
8. Template Management
8. テンプレート管理
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を使用するとき、このセクションはTemplate Managementについて説明します。 明確にTCPに関連するTemplate Managementへのどんな必要な改革か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.
Exporting ProcessはExporterのObservation DomainsのためにSCTP協会あたりのTemplate IDを割り当てて、維持します。 未使用のTemplate IDはExporting Processによって新たに作成されたTemplate Recordに割り当てられます。
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.
特定の情報ElementがTemplateが必要ですが、観測されたパケットで利用可能でないなら、Exporting Processは、新しいTemplateによって定義されたData Recordでこの情報ElementなしでFlow Recordsをエクスポートするのを選ぶかもしれません。
Claise, et al. Standards Track [Page 31] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[31ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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.
情報ElementがTemplateの一度より必要であるなら、この情報Element SHOULDの異なった発生はMetering Processによる彼らの処理に関する論理的順序に従います。 例えば、選択されたパケットが2つのハッシュ関数に直面して、独身のTemplateの中で2つのハッシュ値を送るなら、ハッシュ値の最初の発生はMetering Processにおける最初のハッシュ関数に属すべきです。 IPv4パケットでIPv4の2つのソースIPアドレスをエクスポートするとき、例えば、最初のsourceIPv4Address情報Element発生は外側のヘッダーのIPv4アドレスであるべきです、2番目の発生が内側のヘッダー1であるべきであるが。
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ストリームでもテンプレートSetsとOptions Template Setsを送るかもしれません。 SCTPによって命令された配送を使用して、テンプレートSetsとOptions Template Setsを確かに送らなければなりません。 そういうものとして、Collecting Processは、その後のData Setsに受け取られる対応するData Recordsを解釈できるように、SCTP協会の持続時間のためのTemplate Record情報を保存しなければなりません。
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).
Exporting Process SHOULDは最初のData Recordを受ける前に、CollectorにはTemplate Recordがあるのを確実にするのを助けるのにその(オプション)Template IDを使用するどんなData Setsの前にもTemplate SetとOptions Template Setを伝えます。 Template Recordに対応するデータRecordsは同じ、そして/または、その後のIPFIX Message(s)に現れるかもしれません。
Different Observation Domains from the same SCTP association may use the same Template ID value to refer to different Templates.
同じSCTP協会からの異なったObservation Domainsは、異なったTemplatesについて言及するのに同じTemplate 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.
そうするTemplatesはそれ以上SHOULDを使用しませんでした。削除されます。 Template IDを再利用する前に、Templateを削除しなければなりません。 割り当てられたTemplateを削除するために、TemplateはTemplate Withdrawal Messageの使用で引っ込められます。
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.
十分な時間がCollecting Processが最後のData Recordを受けて、処理するのを許容するためにこのTemplate情報を使用することで経過するまで、Template Withdrawal Messageを送ってはいけません。 今回は構成可能であるに違いありません。 最後のData Recordを送った後に適当なデフォルト値は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.
十分な時間がCollecting ProcessがTemplate Withdrawal Messageを受けて、処理するのを許容するために経過するまで、よそよそしいTemplateからのTemplate 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.
Template Withdrawal Messageは0のField CountがあるそのTemplate IDへのTemplate Recordです。 Template Withdrawal Messageの書式は図Tに示されます。
Claise, et al. Standards Track [Page 32] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[32ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = (2 or 3) | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID N | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID ... | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID M | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=(2か3)を設定してください。| 長さ=16| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID N| 分野カウント=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID… | 分野カウント=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID M| 分野カウント=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.
Set ID分野はTemplate Set Withdrawalのための値2とOptions Template Set Withdrawalのための値3を含まなければなりません。 複数のTemplate IDが独身のTemplate Withdrawal Messageと共に引き下がるかもしれなくて、その場合、詰め物は使用されるかもしれません。
The Template Withdrawal Message withdraws the Template IDs for the Observation Domain ID specified in the IPFIX Message Header.
Template Withdrawal MessageはIPFIX Message Headerで指定されたObservation Domain IDにTemplate 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ストリームでもTemplate Withdrawal Messageを送るかもしれません。 SCTPによって命令された配送を使用して、Template Withdrawal Messageを確かに送らなければなりません。
The Template Withdrawal Message MUST NOT contain new Template or Options Template Records.
Template Withdrawal Messageは新しいTemplateか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.
測定パラメタが新しいTemplateが必要であるようなものを変えるなら、Templateを引っ込めなければなりませんか(Template Withdraw Messageと新しいTemplate定義を使用して)、または未使用のTemplate IDを使用しなければなりません。 測定変化に関する例は以下の通りです。 新しい標本抽出率、新しいFlow満了プロセス、新しいフィルタリング定義など
When the SCTP association shuts down or the Exporting Process restarts, all Template assignments are lost and Template IDs MUST be reassigned.
SCTP協会が閉鎖するか、またはExporting Processが再開するとき、すべてのTemplate課題が無くなります、そして、Template 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.
Metering Processが再開するなら、Exporting Processが各Templateのために以前に割り当てられたTemplate IDを再利用しなければなりませんか、またはそれは、それらを再利用する前にTemplate Withdraw Message(s)を送ることによって、以前に発行されたTemplate 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 Message Headerで指定されたObservation Domain IDにすべてのTemplatesを引っ込めるTemplate Withdrawal Messageは使用されるかもしれません。 書式は図Uに示されます。
Claise, et al. Standards Track [Page 33] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[33ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 2 | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=2を設定してください。| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID=2| 分野カウント=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 Message Headerで指定されたObservation Domain IDにすべてのOptions Templatesを引っ込めるTemplate Withdrawal Messageは使用されるかもしれません。 書式は図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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=3を設定してください。| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID=3| 分野カウント=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協会が再開すると、Exporting ProcessはすべてのTemplate Recordsを再送しなければなりません。
9. The Collecting Process's Side
9. 収集の過程のs側
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を使用するとき、このセクションはCollecting Processについて説明します。 明確にTCPかUDPトランスポート・プロトコルに関連するCollecting Processへのどんな必要な改革もセクション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.
Collecting Process SHOULDはExporting Processからの新連合要求の聞こうとします。 Exporting Processは輸出に使用するストリームの数を要求するでしょう。 Exporting ProcessはSCTP協会あたり1つ以上のストリームを要求して、サポートするかもしれません。
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.
Collecting Processが奇形のIPFIX Messageを受けるなら、SCTP協会をリセットしなければならなくて、破棄はIPFIX Messageです、そして、SHOULDが誤りを登録します。 非ゼロSet詰め物が奇形のIPFIX Messageを構成しないことに注意してください。
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.
一度テンプレートSetsとOption Template Setsを送るだけです。 Collecting Processは、その後のData Setsに受け取られる対応するData Recordsを解釈できるように、協会の持続時間のためのTemplate Record情報を保存しなければなりません。
Claise, et al. Standards Track [Page 34] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[34ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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協会とObservation Domain単位でユニークです。 Collecting Processが既に受け取られましたが、以前に引っ込められていないTemplate(すなわち、SCTP協会に同じTemplate IDを受け取っている同じExporter Observation DomainからのTemplate Record)を受けるなら、Collecting Processは協会を閉鎖しなければなりません。
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協会が閉じられるとき、Collecting Processは、その協会の上に受け取られたすべてのTemplatesを捨てて、それらのTemplatesを使用するIPFIX Messagesを解読するのを止めなければなりません。
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.
Data Recordsを受ける前に、通常、Collecting ProcessはExporting ProcessからTemplate Recordsを受けます。 Data RecordsはCollectorによって次に、解読されて、保存されます。 Data Recordsが受け取られているときTemplate Recordsが受け取られていないなら、Template Recordsが受け取られていた後に、Collecting Processは短期間の間、Data Recordsを保存して、彼らを解読するかもしれません。 Collecting Processは、Data Setと関連Template Set(または、Options Template Set)が同じIPFIX Messageでエクスポートされると仮定してはいけません。
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.
Collecting Processは、それがするどんな情報Elementに関する情報Element識別子も分かって、Flow Recordからその情報Elementを捨てないかもしれないことに注意しなければなりません。
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.
CollectorはData RecordsとTemplate Recordsで詰め物を受け入れなければなりません。 詰め物サイズはSet Header(Set IDとSet Lengthのための4つの八重奏)(RecordサイズがTemplate Recordから推論した法)のサイズを引いたSet Lengthです。
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 Data Recordsの数がIPFIX Messageにある状態で増加するExportヘッダーにSequence Number分野を持っています。 Collectorは、Sequence Numberを追跡することによって、IPFIX Messagesを順序が狂って検出するか、下げるか、またはコピーするかもしれません。 Collector SHOULDは順序が狂ってIPFIX Messagesを追跡するのに伐採メカニズムを提供します。 順序が狂ってそのようなIPFIX MessagesがExporterリソース疲労困憊のためにそれが誤ったメッセージを注入しているそれらの作成レート、Exporting Processリセット、ExporterとCollector、Collectorリソース疲労困憊とのそれが彼らの到着率でIPFIX Messagesを処理できないネットワークリンクにおける混雑、故障しているパケットレセプション、写しパケットレセプション、または攻撃者でメッセージを送ることができないところにあるかもしれません。
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.
Collecting ProcessがTemplate Withdrawal Messageを受けるなら、Collecting Processは、特定のSCTP協会と特定のObservation Domainに関連している対応するTemplate Recordsを削除して、よそよそしいTemplatesを使用するIPFIX Messagesを解読するのを止めなければなりません。
Claise, et al. Standards Track [Page 35] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[35ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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.
Collecting ProcessがTemplate RecordへのTemplate Withdrawメッセージを受け取るなら、このSCTP協会にSCTP協会をリセットしなければならない前に受信していなくて、破棄はIPFIX Messageです、そして、SHOULDが奇形のIPFIX Messagesのためにするように誤りを登録します。
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.
同じTransport Sessionの上の数個のObservation DomainsからIPFIX Messagesを受けるCollecting ProcessはTemplate IDのユニークさがObservation Domainsの向こう側に保証されないのを意識しているに違いありません。
The Collector MUST support the use of Templates containing multiple occurrences of the similar Information Elements.
Collectorは同様のInformation Elementsの複数の発生を含むTemplatesの使用をサポートしなければなりません。
10. Transport Protocol
10. トランスポート・プロトコル
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プロトコルSpecificationは、トランスポート・プロトコル独立者になるように設計されています。 Exporterが独立しているトランスポート・プロトコルを使用することで複数のCollecting Processesにエクスポートすることができることに注意してください。
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.
16ビットのLengthがさばくIPFIX Message HeaderはIPFIX Messageの長さをヘッダーを含む65535の八重奏に制限します。 Collecting Processは最大65535の八重奏のIPFIX Messageの長さを扱うことができなければなりません。
10.1. Transport Compliance and Transport Usage
10.1. 輸送コンプライアンスと輸送用法
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.
私たちは、実装しなければならない(オペレータが異なったベンダーから対応する実装をinteroperablyに配布することができるように)ことと使用するべきであるか、または様々な運用環境に使用できたことの間で差別化する必要があります。 また、私たちは、すべての実装が混雑意識しているのと輻輳回避モードで作動できるのを確実にしなければなりません。
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 SHOULDは混雑に影響されやすいリンクの上に中古のコネが展開のどこのExportersとCollectorsであったかで交信する予定です。 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.
ExportersとCollectorsが混雑に影響されやすいリンクの上に交信するところでTCP MAYが展開に使用されて、PR-SCTPだけがExportersへの逆圧を制限する性能とそのメッセージのためストリームオリエンテーションに対して好まれます。
Claise, et al. Standards Track [Page 36] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[36ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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 MAY、それは混雑意識しているプロトコルではありませんが、使用されてください。 IPFIXトラフィックが食糧を供給された環境に立候補しなければならない、しかしながら、さもなければ、ExporterとCollectorの間のIPFIXトラフィックは、ある他の手段で含まれています。
10.2. SCTP
10.2. SCTP
This section describes how IPFIX can be transported over SCTP [RFC4960] using the PR-SCTP [RFC3758] extension.
このセクションはSCTP[RFC4960]の上でPR-SCTP[RFC3758]拡張子を使用することでどうIPFIXを輸送できるかを説明します。
10.2.1. Congestion Avoidance
10.2.1. 輻輳回避
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 Exporting ProcessとIPFIX Collecting Processの間の終わらせる終わりの混雑経路を検出して、それに従って、転送レートを制限するでしょう。 いつ、IPFIX Exporting Processにはしかし、エクスポートする記録があるかがそれを検出します。SCTPによるトランスミッションが一時不可能である、発信が再び可能になるまで、待つことができますか、またはそれは記録を下げると決めることができます。 後者の場合では、下げられた輸出データを説明しなければなりません、下げられた輸出データの量を報告できるように。
10.2.2. Reliability
10.2.2. 信頼性
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メッセージを使用するのがすべてのData Recordsが提供されるという保証自体でありません。 Exporting ProcessからCollecting Processへのリンクの上に混雑があるか、または多くの「再-トランスミッション」が必要であるなら、Exporting Processにおける送信キューは満たされるかもしれません。 Exporting ProcessはIPFIX Messagesを吊すか、エクスポートするか、または捨てるかもしれません。 Data Recordsが捨てられるなら、輸出に使用されるIPFIX Sequence民数記はデータの喪失を反映しなければなりません。
10.2.3. MTU
10.2.3. MTU
SCTP provides the required IPFIX Message fragmentation service based on path MTU discovery.
SCTPは経路MTU探索に基づく必要なIPFIX Message断片化サービスを提供します。
Claise, et al. Standards Track [Page 37] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[37ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
10.2.4. Exporting Process
10.2.4. 輸出プロセス
10.2.4.1. Association Establishment
10.2.4.1. 協会設立
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 Exporting Process SHOULDはIPFIX Collecting ProcessとのSCTP協会を開始します。 デフォルトで、Collecting ProcessはSCTPポート4739の上で接続の聞こうとします。 デフォルトで、Collecting Processは4740(Security Considerations部について言及する)のSCTPポートの上で安全な接続の聞こうとします。 デフォルトで、Exporting Processはこれらのポートの1つに接続しようとします。 異なったSCTPポートを使用するためにExportingとCollecting Processesの両方を構成するのは可能であるに違いありません。
The Exporting Process MAY establish more than one association (connection "bundle" in SCTP terminology) to the Collecting Process.
Exporting Processは1つ以上の協会(SCTP用語の接続「バンドル」)をCollecting Processに設立するかもしれません。
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).
Exporting Processは1つ以上の活動的な協会を異なったCollecting Processesにサポートするかもしれません(同じホストの上の異なったCollecting Processesに関するケースを含んでいて)。
10.2.4.2. Association Shutdown
10.2.4.2. 協会閉鎖
When an Exporting Process is shut down, it SHOULD shut down the SCTP association.
いつ、Exporting Processがあるかは停止して、それはSCTP協会の下側に閉じられたSHOULDです。
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.
Collecting Processがもういつまで欲しくないかがIPFIX Messagesを受けて、それは協会の終わりの下側に閉じられたSHOULDです。 Collecting Process SHOULDはExporting Processが協会の終わりを閉じるまで、IPFIX Messagesを受けて、処理し続けています。
When a Collecting Process detects that the SCTP association has been abnormally terminated, it MUST continue to listen for a new association establishment.
Collecting Processがそれを検出すると、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.
Exporting Processがそれを検出すると、Collecting ProcessへのSCTP協会は異常に終えられて、それは協会を復職させるSHOULDトライです。
Association timeouts SHOULD be configurable.
協会タイムアウトSHOULD、構成可能であってください。
10.2.4.3. Stream
10.2.4.3. ストリーム
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.
Exporting Processは1協会あたり1つ以上のSCTPストリームを要求するかもしれません。 それぞれのこれらのストリームはData Sets、Template Sets、そして/または、Options Template Setsを含むIPFIX Messagesのトランスミッションに使用されるかもしれません。
Claise, et al. Standards Track [Page 38] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[38ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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.
アプリケーションの要件によって、Exporting Processは完全であるか部分的な信頼性があるData Setsを送るかもしれません、命令されたか不適切な配送を使用して、SCTP Associationセットアップの間に確立されたどんな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.
Data Setsだけを含むIPFIX Messagesを伝えるのに部分的な信頼性を使用するとき、IPFIX Exporting ProcessはPR-SCTP[RFC3758]仕様のセクション4に従ってどんなPR-SCTP Service Definitionも使用するかもしれません。
However, Exporting Processes SHOULD mark such IPFIX Messages for retransmission for as long as resource or other constraints allow.
しかしながら、Exporting Processes SHOULDは同じくらい長い間の「再-トランスミッション」のためのリソースか他の規制が許容するようなIPFIX Messagesをマークします。
10.2.4.4. Template Management
10.2.4.4. テンプレート管理
When the transport protocol is SCTP, the default Template Management described in Section 8 is used.
トランスポート・プロトコルがSCTPであるときに、セクション8で説明されたデフォルトTemplate Managementは使用されています。
10.2.5. Collecting Process
10.2.5. 収集プロセス
When the transport protocol is SCTP, the default Collector processing described in Section 9 is used.
トランスポート・プロトコルがSCTPであるときに、セクション9で説明されたデフォルトCollector処理は使用されています。
10.2.6. Failover
10.2.6. フェイルオーバー
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.
Collecting Processが協会を設立するExporting Processによる試みを承諾しないなら、Exporting Processは、SCTPの指数のbackoffの特徴を使用することで再試行するはずです。 協会を設立する時間が指定された敷居を超えているなら、Exporterはアラームを登録するかもしれません、Exporterでは、構成可能です。
If Collecting Process failover is supported by the Exporting Process, a second SCTP association MAY be opened in advance.
Collecting ProcessフェイルオーバーがExporting Processによってサポートされるなら、2番目のSCTP協会はあらかじめ、開かれるかもしれません。
10.3. UDP
10.3. UDP
This section describes how IPFIX can be transported over UDP [UDP].
このセクションはUDP[UDP]の上でどうIPFIXを輸送できるかを説明します。
10.3.1. Congestion Avoidance
10.3.1. 輻輳回避
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には、どんな不可欠の輻輳回避メカニズムもありません。 したがって、混雑敏感なネットワーク経路の上の使用は推薦されません。 ExportersとCollectorsが混雑に影響されやすくない専用リンクの上にいつも交信するところでUDP MAYが展開に使用されて、すなわち、最大の輸出と比較された食糧を供給されたリンクの上では、Exportersから評価してください。
Claise, et al. Standards Track [Page 39] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[39ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
10.3.2. Reliability
10.3.2. 信頼性
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を使用することでExporting ProcessからCollecting Processに送られたIPFIX Messagesはなくされるかもしれません。 UDP MUST NOT、アプリケーションがIPFIX Messagesのいくらかの損失を黙認できないなら、使用されてください。
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.
Collecting Process SHOULDは、IPFIX Sequence Numberの不連続を見ることによって、IPFIX Data Recordsに関する損失と再命令を推論します。 UDPの場合では、IPFIX Sequence NumberはUDP Transport SessionのためにこのIPFIX Messageの領収書の前に送られたIPFIX Data Recordsの総数を含んでいます、法2^32。 Collector SHOULDは、Sequence Numberを追跡することによって、IPFIX Messagesを順序が狂って検出するか、下げるか、またはコピーします。 テンプレートは一定の間隔を置いて輸送を再送しなければならないのでUDPを使用することでExporting ProcessからCollecting Processまで発信しました、前のコピーがなくされるといけなかったので。
10.3.3. MTU
10.3.3. MTU
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が未知の、そして、a最大のパケットサイズであるなら、512八重奏SHOULDでは、使用されてください。
10.3.4. Port Numbers
10.3.4. ポートナンバー
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.
デフォルトで、Collecting ProcessはUDPポート4739の上で聴きます。 デフォルトで、Collecting Processは4740(「セキュリティ問題」セクションを示す)のUDPポートの上で安全な接続の聞こうとします。 デフォルトで、Exporting Processはこれらのポートの1つに接続しようとします。 異なったUDPポートを使用するためにExportingとCollecting Processesの両方を構成するのは可能であるに違いありません。
10.3.5. Exporting Process
10.3.5. 輸出プロセス
The Exporting Process MAY duplicate the IPFIX Message to the several Collecting Processes.
Exporting Processは数個のCollecting ProcessesにIPFIX Messageをコピーするかもしれません。
10.3.6. Template Management
10.3.6. テンプレート管理
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を使用すると、一定の間隔を置いてTemplate SetsとOption Template Setsを再送しなければなりません。 (オプション)テンプレートトランスミッションの頻度は構成可能であるに違いありません。 (オプション)テンプレートトランスミッションの頻度のためのデフォルト値は10分です。 Exporting Process SHOULDはそれを確実にするのを助けるのにその(オプション)Template IDを使用するどんなData Setsの前にもTemplate SetとOptions Template Setを伝えます。
Claise, et al. Standards Track [Page 40] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[40ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
Collector has the Template Record before receiving the first Data Record.
最初のData Recordを受ける前に、コレクタはTemplate 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.
構成変更の場合、Exporting Process SHOULDは新しいTemplate定義の複本を送ります、異なったIPFIX Messagesで、加速しているレートで。 このような場合にはそれ、SHOULDは、あらかじめ、最初のデータを受け取る前に、Collectorには正しいTemplate情報があるのを確実にするのを助けるために少しもデータなしで変えられたTemplate Record(s)とOptions Template Record(s)を伝えます。
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.
範囲はOption Templateであるなら別のTemplateで定義されて、次に、両方がTemplates SHOULDです。同じIPFIX Messageでは、送ります。 例えば、Flow Key Option Template(セクション4.4を見る)であるなら、送られたコネが同じIPFIX Messageであったなら、当時、送られたコネはOption Template、関連Template SHOULDですか?
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.
Data Records(例えば、標本抽出率変化)の解釈を変更できる構成変更に続いて、新しいTemplate IDを使用しなければなりません、そして、寿命(セクション10.3.7を見る)が期限が切れるまで、古いTemplate 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がトランスポート・プロトコルとして選定されるなら、Template Withdraw Messagesを使用してはいけません、このメソッドがUDPの頼り無い本質のために効率が悪いので。
10.3.7. Collecting Process
10.3.7. 収集プロセス
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.
Collecting ProcessはUDPを通して受け取る各Template(または、Transport Sessionの中でユニークであると考えられた識別子の別の定義)に生涯を関連づけなければなりません。 生涯中のExporting Processによってリフレッシュされなかったテンプレート(そして、同様の定義)はCollecting Processに吐き出されます。 その寿命が期限が切れる前にTemplate(または、他の定義)が壮快でないなら、Collecting Processはその定義とどんな現在の、そして、将来の関連Data Recordsも捨てなければなりません。 その場合、アラームを登録しなければなりません。 Collecting Processは満期のTemplateに関連している少しの一層のData Recordsも解読してはいけません。 Templateが以前に容認されたTemplate Recordと異なっているTemplate Recordと共にリフレッシュされるなら、Collecting Process SHOULDは警告を登録して、以前に容認されたTemplate Recordを新しい方に取り替えます。 Collecting ProcessのTemplate寿命はTemplateがExporting Processで構成されたタイムアウトをリフレッシュするより少なくとも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セッションとObservation Domain単位でユニークです。 その時々で、Collecting Process SHOULDはすべての現在のTemplate RecordsとOptions Templateのために以下を維持します。
Claise, et al. Standards Track [Page 41] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[41ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
Records: <IPFIX Device, Exporter source UDP port, Observation Domain ID, Template ID, Template Definition, Last Received>.
記録: <IPFIX Device、ExporterソースUDP港、Observation Domain Template ID(ID)Template Definition、Last Received>。
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.
Collecting Process SHOULDはData Recordを解読しなければならなかった関連Template Record(または、他の定義)なしでData Recordsを受け入れます。 Data Recordsが受け取られているときTemplate Records(または、Common Propertiesなどの他の定義)が受け取られていないなら、Collecting Process SHOULDは短期間の間、Data Recordsを保存して、Template Records(または、他の定義)が受け取られていた後に彼らを解読します。 短期間はUDPセッション中にユニークであると考えられる識別子に関連している定義の生涯より低いに違いありません。
If the Collecting Process receives a malformed IPFIX Message, it MUST discard the IPFIX Message and SHOULD log the error.
Collecting Processが奇形のIPFIX Messageを受けるなら、IPFIX Messageを捨てなければなりません、そして、SHOULDは誤りを登録します。
10.3.8. Failover
10.3.8. フェイルオーバー
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が接続指向のプロトコルでないので、Exporting Processは、トランスポート・プロトコルからCollecting ProcessがもうIPFIX Messagesを受け取ることができないことを決定できません。 したがって、それはフェイルオーバーメカニズムを呼び出すことができません。 しかしながら、Exporting Processは数個のCollecting ProcessesにIPFIX Messageをコピーするかもしれません。
10.4. TCP
10.4. TCP
This section describes how IPFIX can be transported over TCP [TCP].
このセクションはTCP[TCP]の上でどうIPFIXを輸送できるかを説明します。
10.4.1. Connection Management
10.4.1. 接続管理
10.4.1.1. Connection Establishment
10.4.1.1. コネクション確立
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 Exporting ProcessはTCP接続をCollecting Processに開始します。 デフォルトで、Collecting ProcessはTCPポート4739の上で接続の聞こうとします。 デフォルトで、Collecting Processは4740(Security Considerations部について言及する)のTCPポートの上で安全な接続の聞こうとします。 デフォルトで、Exporting Processはこれらのポートの1つに接続しようとします。 異なったTCPポートを使用するためにExporting ProcessとCollecting Processの両方を構成するのは可能であるに違いありません。
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).
Exporting Processは1つ以上の活発な接続を異なったCollecting Processesにサポートするかもしれません(同じホストの上の異なったCollecting Processesに関するケースを含んでいて)。
The Exporter MAY log an alarm if the time to establish the connection exceeds a specified threshold, configurable on the Exporter.
接続を確立する時間が指定された敷居を超えているなら、Exporterはアラームを登録するかもしれません、Exporterでは、構成可能です。
Claise, et al. Standards Track [Page 42] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[42ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
10.4.1.2. Graceful Connection Release
10.4.1.2. 優雅なコネクション解放
When an Exporting Process is shut down, it SHOULD shut down the TCP connection.
いつ、Exporting Processがあるかは停止して、それはTCP接続の下側に閉じられたSHOULDです。
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.
Collecting Processがもういつまで欲しくないかがIPFIX Messagesを受けて、それはSHOULDです。接続の終わりを閉じてください。 Collecting Process SHOULDは、Exporting Processが終わりを閉じるまでIPFIX Messagesを読み続けています。
10.4.1.3. Restarting Interrupted Connections
10.4.1.3. 再開はコネクションズを中断しました。
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.
Collecting Processがそれを検出するとき、Exporting Processとの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.
Exporting Processがそれを検出するとき、Collecting ProcessとのTCP接続は異常に終わって、それは接続を復職させるSHOULDトライです。 接続タイムアウトと再試行はSHOULDの計画をします。構成可能であってください。 デフォルト設定では、Exporting Processは、1分あたりの一度より頻繁に取引関係を築くのを試みてはいけません。
10.4.1.4. Failover
10.4.1.4. フェイルオーバー
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.
Collecting Processが、Exporting Processによる試みが取引関係を築くと認めないと、それは、TCPの指数のbackoffの特徴を使用することで再試行されるでしょう。
If Collecting Process failover is supported by the Exporting Process, a second TCP connection MAY be opened in advance.
Collecting ProcessフェイルオーバーがExporting Processによってサポートされるなら、2番目のTCP接続はあらかじめ、開かれるかもしれません。
10.4.2. Data Transmission
10.4.2. データ伝送
Once a TCP connection is established, the Exporting Process starts sending IPFIX Messages to the Collecting Process.
TCP接続がいったん確立されると、Exporting ProcessはIPFIX MessagesをCollecting Processに送り始めます。
10.4.2.1. IPFIX Message Encoding
10.4.2.1. 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.
少しも特別なコード化なしでTCP接続の上にIPFIX Messagesを送ります。 IPFIX Message HeaderのLength分野はそれぞれのIPFIX Messageの端とその結果次のIPFIX Messageの始まるのを定義します。 これは、IPFIX Messagesをはさみ込むことができないことを意味します。
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 Sequence NumberはこのTCP接続から送られたIPFIX Data Recordsの総数を含んでいます、Exporting Processによる現在のObservation Domainから、このIPFIX Messageの領収書の前で、法2^32。
Claise, et al. Standards Track [Page 43] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[43ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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.
Exporting Processが複数のObservation Domainsからのデータをエクスポートするなら、異なったObservation Domainsの間の系列のヘッドブロッキングを最小にするために適切にIPFIX Messageの長さを選ぶのに慎重であるはずです。 複数のTCP接続が、異なったObservation Domainsの間の系列のヘッドを避けるのに使用されるかもしれません。
10.4.2.2. Template Management
10.4.2.2. テンプレート管理
For each Template, the Exporting Process MUST send the Template Record before exporting Data Records that refer to that Template.
各Templateに関しては、そのTemplateについて言及するData Recordsをエクスポートする前に、Exporting ProcessはTemplate Recordを送らなければなりません。
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接続とObservation Domain単位でユニークです。 Collecting Processは接続の持続時間のためにすべてのTemplateとOptions Template Recordsを記録しなければなりません、Exporting ProcessはTemplate Recordsを再輸出するのに必要でないときに。
When the TCP connection restarts, the Exporting Process MUST resend all the Template Records.
TCP接続が再開すると、Exporting ProcessはすべてのTemplate Recordsを再送しなければなりません。
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接続が閉じられるとき、Collecting Processは、その接続の上に受け取られたすべてのTemplatesを捨てて、それらのTemplatesを使用するIPFIX Messagesを解読するのを止めなければなりません。
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.
そうするTemplatesはそれ以上SHOULDを使用しませんでした。削除されます。 Template IDを再利用する前に、Templateを削除しなければなりません。 割り当てられたTemplateを削除するために、TemplateはTCP接続の上でTemplate Withdrawal Messageの使用で引っ込められます。
If the Collecting Process receives a malformed IPFIX Message, it MUST reset the TCP connection, discard the IPFIX Message, and SHOULD log the error.
Collecting Processが奇形のIPFIX Messageを受けるなら、TCP接続をリセットしなければならなくて、破棄はIPFIX Messageです、そして、SHOULDが誤りを登録します。
10.4.2.3. Congestion Handling and Reliability
10.4.2.3. 混雑取り扱いと信頼性
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はデータのExporting ProcessからCollecting Processまでの信頼できる配信を確実にします。 また、TCPはExporting ProcessからCollecting Processにデータを送ることができるレートを制御します、ネットワークにおける混雑と受信機の能力の両方を考慮に入れるメカニズムを使用して。
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
したがって、IPFIX Exporting ProcessはMetering Processがそれを生成するレートでIPFIX Messagesを送ることができないかもしれません、ネットワークにおける混雑のためのどちらか、またはCollecting Processが十分速くIPFIX Messagesを扱うことができないので。 混雑が一時的である限り、Exporting ProcessはトランスミッションのためのIPFIX Messagesをバッファリングできます。 そしてしかし、そのようなバッファリングがともにリソース制限のために必ず制限される。
Claise, et al. Standards Track [Page 44] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[44ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
timeliness requirements, so ongoing and/or severe congestion may lead to a situation where the Exporting Process is blocked.
タイムリー要件であり、とても進行中の、そして/または、厳しい混雑はExporting Processが妨げられる状況につながるかもしれません。
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.
Exporting ProcessにはエクスポートするData Recordsがありますが、トランスミッションバッファが完全であり、妨げるのを避けたがっているとき、それは、いくつかのData Recordsを下げると決めることができます。 後で量をエクスポートすることができるように下げられたData Recordsの原因にならなければなりません。
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.
Exporting Processが、記録がエクスポートされるべきであるレートがTCP発信が可能にするレートより一貫して高いのがわかるとき、それは逆圧をMetering Processesに供給するべきです。 そして、Metering Processは、例えば、標本抽出か集合を使用することでそれが生成するデータ量を一時減少させることによって、適合するかもしれません。
10.4.3. Collecting Process
10.4.3. 収集プロセス
The Collecting Process SHOULD listen for a new TCP connection from the Exporting Process.
Collecting Process SHOULDは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.
Collecting Processが奇形のIPFIX Messageを受けるなら、TCP接続をリセットしなければならなくて、破棄はIPFIX Messageです、そして、SHOULDが誤りを登録します。 非ゼロSet詰め物が奇形のIPFIX Messageを構成しないことに注意してください。
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.
一度テンプレートSetsとOption Template Setsを送るだけです。 Collecting Processは、その後のData Setsに受け取られる対応するData Recordsを解釈できるように、接続の持続時間のためのTemplate Record情報を保存しなければなりません。
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接続とObservation Domain単位でユニークです。 Collecting Processが既に受け取られましたが、以前に引っ込められていないTemplate(すなわち、TCP接続のときに同じTemplate IDを受け取っている同じExporter Observation DomainからのTemplate Record)を受けるなら、Collecting Processは接続を止めなければなりません。
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接続が閉じられるとき、Collecting Processは、その接続の上に受け取られたすべてのTemplatesを捨てて、それらのTemplatesを使用するIPFIX Messagesを解読するのを止めなければなりません。
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.
Collecting ProcessがTemplate Withdrawal Messageを受けるなら、Collecting Processは、特定のTCP接続と特定のObservation Domainに関連している対応するTemplate Recordsを削除して、よそよそしいTemplatesを使用するIPFIX Messagesを解読するのを止めなければなりません。
Claise, et al. Standards Track [Page 45] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[45ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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.
Collecting ProcessがTemplate RecordのためにTemplate Withdrawal Messageを受けるなら、このTCP接続のときにTCP協会をリセットしなければならない前に受信していなくて、破棄はIPFIX Messageです、そして、SHOULDが奇形のIPFIX Messagesのためにするように誤りを登録します。
11. Security Considerations
11. セキュリティ問題
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プロトコルのためのセキュリティ問題を得ました、IPFIX要件[RFC3917]の「セキュリティ問題」セクションで議論するように。 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はExporting ProcessからCollecting Processまで移されたIPFIXデータの秘密性を確実にするためにメカニズムを提供しなければなりません、IPFIXを通して輸送されたFlow Recordsの公開を防ぐために。
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はExporting ProcessからCollecting Processまで移されたIPFIXデータの保全を確実にするためにメカニズムを提供しなければなりません、間違ったデータか制御情報(例えば、Templates)の注射をIPFIX Messageストリームに防ぐために。
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は、データの権限のないExporting Processかデータの輸出から権限のないCollecting Processまでの収集を防ぐためにIPFIX CollectingとExporting Processesを認証するメカニズムを提供しなければなりません。
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 Collecting Process(Templatesを変更するか、取り消す、またはオプションを変更するのによる)自身を使用することでIPFIX Messageストリームに誤ったメッセージを注ぐ立場の攻撃者はアプリケーションに影響できます。 この理由で、IPFIX Message保全は重要です。
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
また、IPFIX Messages自身は価値の情報を攻撃者に含むかもしれません、エンドユーザトラフィックとペイロードデータと同様にネットワークの構成の情報を含んでいてそれらの目に見えることを認定ユーザに制限するために注意しなければならなくて。 情報Elementであるときに、含んでいるエンドユーザペイロード情報はエクスポートされて、それはSHOULDです。盗聴に対してコンテンツを保証する手段を使用することでCollecting Processに伝えられてください。 適当なメカニズムは暗号化メカニズムのダイレクト二地点間接続か使用のどちらかの使用を含んでいます。 それはそうです。
Claise, et al. Standards Track [Page 46] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[46ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
responsibility of the Collecting Process to provide a satisfactory degree of security for this collected data, including, if necessary, anonymization of any reported data.
Collecting Processが必要なら、どんな報告されたデータのanonymizationも含むこの集まっているデータに満足できる度合いのセキュリティを提供する責任。
11.1. Applicability of TLS and DTLS
11.1. TLSとDTLSの適用性
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.
輸送Layer Security(TLS)[RFC4346]とデータグラムTransport Layer Security(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]で定義されますが、彼らは、信頼できて、双方向のストリームの上にすべてのコミュニケーションがあるのが必要であり、1ストリームあたり1つの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(そして/または、TCP)のためのジェネリックTLSでは、これは可能ではありません。 これは、メッセージの取り外しが送付者か受信機から隠されるようになるかもしれないことを意味します。DTLSとPR-SCTPを使用する別の脆弱性はだれかがSCTP協会を閉鎖するためにSCTP制御情報を注入できたということです、ものがSCTP協会の外でバッファリングされるなら事実上、IPFIX Messagesの損失を生成して。 将来、これらの脆弱性に打ち勝つのに[sctpのためのdtls]などのテクニックを使用できました。
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を使用するとき、Exporting Processは、各IPFIX MessageがSCTPの直接上に同じIPFIX Messageを送るとき使用されるのと同じSCTPストリームの上に送られるのを確実にしなければなりません。 DTLSが完全な信頼性があるストリーム0にそれ自身のコントロールメッセージを送るかもしれないことに注意してください。 しかしながら、これはストリーム0IPFIX Messagesの処理をCollecting Processに妨げないでしょう、IPFIX Messagesを応用層まで渡す前にDTLSがそれ自身のコントロールメッセージを消費するので。
Claise, et al. Standards Track [Page 47] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[47ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
11.2. Usage
11.2. 用法
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 Exporting ProcessはIPFIX Collecting Processへのコミュニケーションと、TLSとしての行為か[RFC4346]と[RFC4347]に従ったDTLSクライアントを開始します、SCTPかPR-SCTPがトランスポート・プロトコルとして選定されるなら、TLSかサーバDTLSクライアントのDTLSがSCTPで安全な接続を開くとき、IPFIX Collecting Process条例は4740のDTLSサーバを移植しますが。 TCPがトランスポート・プロトコルとして選定されるなら、TLSクライアントはTLSサーバのTCPポート4740の上で安全な接続を開きます。 UDPがトランスポート・プロトコルとして選定されるなら、DTLSクライアントはDTLSサーバのUDPポート4740の上で安全な接続を開きます。
11.3. Authentication
11.3. 認証
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 Exporting ProcessesとIPFIX Collecting Processesは[RFC3280]のようにX.509クライアントとサーバ証明書の目的のためにIPFIX Messagesを送るか、または受け取るインタフェースに関する完全修飾ドメイン名によって特定されます。
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.
詐欺師ExportingかCollecting Processes、データの承認から介入者攻撃を権限のないExporting Process、またはデータの輸出から権限のないCollecting Processまで防ぐために、TLSとDTLSの両方に非対称のキーを通した強い互いの認証を使用しなければなりません。 それぞれのIPFIX ExportingとCollecting Processesは、認可された証明書に対して同輩のアイデンティティについて確かめなければならなくて、または、同輩の証明書が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 Collecting Processを特定していたか、またはExporting ProcessはタイプdNSNameのsubjectAltName拡張子、またはX.509証明書のSubject分野の最も特定の俗称分野に保存されるかもしれません。 両方が存在しているなら、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".
タイプdNSNameのsubjectAltName拡張子かX.509証明書のSubject分野の最も特定の俗称分野のどちらかの国際化ドメイン名(IDN)は[RFC3490]のセクション4、「変換操作」で説明されるようにコード化された使用Punycode[RFC3492]であるに違いありません。
11.4. Protection against DoS Attacks
11.4. DoS攻撃に対する保護
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.
攻撃者は直接多量のトラフィックをCollecting Processに送るか、間接的のどちらかにIPFIX収集システムに対してサービスの否定(DoS)攻撃を仕掛けるかもしれません、Metering Processによって測定されるように多量のトラフィックを生成することによって。
Claise, et al. Standards Track [Page 48] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[48ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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 Collecting Process(未定のTemplateをFlow Recordsに送るか、または例えば、情報、多量のOptions Template Recordsなどを範囲に送るのによる)自身にかかわらず。
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州の疲労困憊サービス不能攻撃に対して防御するように設計されたクッキー交換メカニズムを強制します。 同様に、TCPは州の疲労困憊を緩和するために「SYNクッキー」メカニズムを提供します。 SYNクッキーSHOULD、TCP接続を受け入れるあらゆるCollecting Processによって使用されてください。 また、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 Message処理を防ぐ(作成を述べてください)方法が全くないことに注意するべきです。 TLSとDTLSの使用は明らかににせの州の創設を防ぐことができますが、それらは自分たちで疲労困憊攻撃を述べる傾向があります。 したがって、Collectorは、制限がSHOULDであると評定します。使用されて、TLS&DTLS(分別がある数への1秒あたりの新しい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州の疲労困憊攻撃を緩和できますか、または協会はCollecting Process(IPFIX MessagesがCollecting Process、および特に記録がTemplatesで待っていて、維持された状態の量を制限する適応型によって受け入れられるレート)によって開かれるでしょう。 これらのレートと州の限界はCollecting Processによって提供されるかもしれません。 提供するなら制限する、ユーザが構成可能であったなら、SHOULDを制限します。
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 Collecting Processは信頼されていないノードからTLSかDTLSの互いの認証を必要とすることによって、州の疲労困憊攻撃の危険を排除できます、Collecting Processが単に信頼できるソースからIPFIX Messagesを受け入れることを引き起こして。
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 Messagesの流れが引き返して、結局失速することを引き起こすでしょう、IPFIXシステムの目をくらまして。 PR-SCTPはこの状況をいくらか改良します、いくつかのIPFIX Messagesが、SCTPの複数のストリームと部分的な信頼性の機能による系列のヘッドブロッキングの回避のためCollecting Processによって受け取られ続けているだろうというとき、ことによると攻撃のいくらかの目に見えることを都合して。 状況はUDPについて同様です、いくつかのデータグラムが、Collecting Processに受け取られ続けているとき、事実上、IPFIX Messageストリームへの標本抽出を適用して、何らかのフォレンジックが残されるかもしれないのを含意して。
Claise, et al. Standards Track [Page 49] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[49ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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 Messageの損失を最小にするなら、サービス分化のための何らかのメカニズムが、同じリンクの上に他のトラフィックの上でIPFIXトラフィックを最優先させるのに使用されるかもしれません。 あるいはまた、専用ネットワークの上でIPFIX Messagesを輸送できます。 この場合、専用ネットワークが予想されたピークIPFIX Messageトラフィックを扱うことができるのを保証するために注意しなければなりません。
11.5. When DTLS or TLS Is Not an Option
11.5. DTLSかTLSがオプションでないときに
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 Exporting ProcessesとCollecting Processesは、彼らの同輩を認証するのにIPソースアドレスを使用することで退くことができます。 IPアドレスを指定されたアドレスの範囲からExporting ProcessとCollecting Processに割り当てて、だますのを防ぐのにイングレスフィルタリングを使用する方針はこのアプローチの有用性を改良できます。 一方、専用ネットワークでIPFIXトラフィックを完全に隔離するのは可能であるところでセキュリティをさらにさえ向上させることができます。 どのような場合でも、開いているCollecting Processes(IPアドレスかアイデンティティにかかわらずどんなExporting ProcessからもIPFIX Messagesを受け入れるもの)の使用はお勧めできないです。
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実装は盲目の挿入攻撃に抵抗力があります([RFC4960]、[RFC1948]を見てください)。 しかしながら、UDPはどんなそのような保護も提供しません。 この理由、UDPを通して輸送されて、保証されなかったIPFIX Messageトラフィックには、DTLS SHOULDを通して専用ネットワークへの隔離で保護されてください。
11.6. Logging an IPFIX Attack
11.6. IPFIX攻撃を登録します。
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 Collecting ProcessesはIPFIX Sequence Numberを追跡することによって、潜在的IPFIX Message挿入か損失状態を検出しなければなりません、そして、SHOULDは順序が狂ってメッセージを報告するのに伐採メカニズムを提供します。 これらの状態を扱いながら注意を中に入れるべきであるために攻撃者がCollecting Processで順序が狂ってメッセージの取り扱いを利用できるかもしれないことに注意してください。 例えば、後のSequence民数記の慎重な注射で一時後のSequence Numberを受け取り次第単に予想されたSequence NumberをリセットするCollecting Processは目をくらますことができるでしょう。
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.
IPFIX ExportingとCollecting Processes SHOULDは認証失敗のため失敗するどんな接続試みも登録します、権限のないかミスマッチしている証明書がTLSかDTLSの互いの認証の間、提示されるか、TLSかDTLSが使用中でないときに権限のないIPアドレスからの接続試みにかかわらず。
Claise, et al. Standards Track [Page 50] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[50ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
IPFIX Exporting and Collecting Processes SHOULD detect and log any SCTP association reset or TCP connection reset.
IPFIX ExportingとCollecting Processes SHOULDはどんなSCTP協会リセットやTCP接続リセットも検出して、登録します。
11.7. Securing the Collector
11.7. コレクタを機密保護します。
The security of the Collector and its implementation is important to achieve overall security. However, it is outside the scope of this document.
Collectorとその実装のセキュリティは、総合的なセキュリティを達成するために重要です。 しかしながら、このドキュメントの範囲の外にそれはあります。
12. IANA Considerations
12. IANA問題
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 Messagesは割り当てられた値がある2つの分野を使用します。 これらはIPFIXバージョンNumberです、IPFIXプロトコルのどのバージョンがIPFIX Message、およびIPFIX Set IDをエクスポートするのに使用されたかを示して、IPFIX Messageの中のそれぞれのセットの情報のためにタイプを示して。
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バージョンNumber価値は本書では指定されたIPFIXプロトコルのために予約されます。 0と1のセットID値は歴史的な理由[RFC3954]に使用されません。 2のSet ID価値はTemplate Setのために予約されます。 3のSet ID価値はOption Template Setのために予約されます。 他のすべての4〜255までのSet ID値が今後の使用のために予約されます。 255を超えたセットID値はData Setsに使用されます。
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バージョンNumberかIPFIX Set ID課題のどちらかにおける新しい課題はStandards Action[RFC2434]を必要とします、すなわち、それらがIESGによって承認されたStandards Track RFCsを通して作られていることになっています。
Claise, et al. Standards Track [Page 51] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[51ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
Appendix A. IPFIX Encoding Examples
例をコード化する付録A.IPFIX
This appendix, which is a not a normative reference, contains IPFIX encoding examples.
この付録(引用規格ではなく、aである)は例をコード化する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).
Template Setで構成されたIPFIX Message、Data Set(3Data Recordsを含む)、Options Template Set、およびData Setに関する例を考えましょう(どれが2Data Recordsを含んでいるかが前のOptions Template Recordに関連しました)。
IPFIX Message:
IPFIXメッセージ:
+--------+------------------------------------------. . . | | +--------------+ +------------------+ |Message | | Template | | Data | | Header | | Set | | Set | . . . | | | (1 Template) | | (3 Data Records) | | | +--------------+ +------------------+ +--------+------------------------------------------. . .
+--------+------------------------------------------. . . | | +--------------+ +------------------+ |メッセージ| | テンプレート| | データ| | ヘッダー| | セットします。| | セットします。| . . . | | | (1個のテンプレート) | | (3つのデータレコード) | | | +--------------+ +------------------+ +--------+------------------------------------------. . .
. . .-------------------------------------------+
+------------------+ +------------------+ |
| Options | | Data | |
. . . | Template Set | | Set | |
| (1 Template) | | (2 Data Records) | |
+------------------+ +------------------+ |
. . .-------------------------------------------+
. . .-------------------------------------------+ +------------------+ +------------------+ | | オプション| | データ| | . . . | テンプレートセット| | セットします。| | | (1個のテンプレート) | | (2つのデータレコード) | | +------------------+ +------------------+ | . . .-------------------------------------------+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Headerは以下で構成されます。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョンは0x000aと等しいです。| 長さ=152| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 輸出時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 観測ドメインID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Claise, et al. Standards Track [Page 52] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[52ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
A.2. Template Set Examples
A.2。 テンプレートセットの例
A.2.1. Template Set Using IETF-Specified Information Elements
A.2.1。 テンプレートは、IETFによって指定されたInformation Elementsを使用することでセットしました。
We want to report the following Information Elements:
以下のInformation Elementsを報告したいと思います:
- The IPv4 source IP address: sourceIPv4Address in [RFC5102],
with a length of 4 octets
- IPv4ソースIPアドレス: [RFC5102]の4つの八重奏の長さがあるsourceIPv4Address
- The IPv4 destination IP address: destinationIPv4Address in
[RFC5102], with a length of 4 octets
- IPv4送付先IPアドレス: [RFC5102]の4つの八重奏の長さがあるdestinationIPv4Address
- The next-hop IP address (IPv4): ipNextHopIPv4Address in
[RFC5102], with a length of 4 octets
- 次のホップIPアドレス(IPv4): [RFC5102]の4つの八重奏の長さがあるipNextHopIPv4Address
- The number of packets of the Flow: inPacketDeltaCount in
[RFC5102], with a length of 4 octets
- Flowのパケットの数: [RFC5102]の4つの八重奏の長さがあるinPacketDeltaCount
- The number of octets of the Flow: inOctetDeltaCount in
[RFC5102], with a length of 4 octets
- Flowの八重奏の数: [RFC5102]の4つの八重奏の長さがあるinOctetDeltaCount
Therefore, the Template Set will be composed of the following:
したがって、Template Setは以下で構成されるでしょう:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=2を設定してください。| 長さは28の八重奏と等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID256| 分野カウント=5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address=8| フィールド長=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address=12| フィールド長=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ipNextHopIPv4Address=15| フィールド長=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| inPacketDeltaCount=2| フィールド長=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| inOctetDeltaCount=1| フィールド長=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.2.2. Template Set Using Enterprise-Specific Information Elements
A.2.2。 テンプレートは、エンタープライズ-特殊情報Elementsを使用することでセットしました。
We want to report the following Information Elements:
以下のInformation Elementsを報告したいと思います:
- The IPv4 source IP address: sourceIPv4Address in [RFC5102], with a
length of 4 octets
- IPv4ソースIPアドレス: [RFC5102]の4つの八重奏の長さがあるsourceIPv4Address
Claise, et al. Standards Track [Page 53] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[53ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
- The IPv4 destination IP address: destinationIPv4Address in
[RFC5102], with a length of 4 octets
- IPv4送付先IPアドレス: [RFC5102]の4つの八重奏の長さがあるdestinationIPv4Address
- An enterprise-specific Information Element representing proprietary
information, with a type of 15 and a length of 4
- 一種の154の長さで知的財産情報を表す企業特有の情報Element
- The number of packets of the Flow: inPacketDeltaCount in [RFC5102],
with a length of 4 octets
- Flowのパケットの数: [RFC5102]の4つの八重奏の長さがあるinPacketDeltaCount
- The number of octets of the Flow: inOctetDeltaCount in [RFC5102],
with a length of 4 octets
- Flowの八重奏の数: [RFC5102]の4つの八重奏の長さがあるinOctetDeltaCount
Therefore, the Template Set will be composed of the following:
したがって、Template Setは以下で構成されるでしょう:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=2を設定してください。| 長さは32の八重奏と等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID257| 分野カウント=5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address=8| フィールド長=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address=12| フィールド長=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| 情報Elementアイダホ州 = 15| フィールド長=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エンタープライズ番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| inPacketDeltaCount=2| フィールド長=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| inOctetDeltaCount=1| フィールド長=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Claise, et al. Standards Track [Page 54] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[54ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
A.3. Data Set Example
A.3。 データセットの例
In this example, we report the following three Flow Records:
この例では、私たちは以下の3Flow Recordsを報告します:
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
Src IP addr。 | Dst IP addr。 | 次のHop addr。 | パケット| 八重奏| | | 数| 数------------------------------------------------------------------ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=256を設定してください。| 長さ=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.
詰め物はこの例で必要でないことに注意してください。
Claise, et al. Standards Track [Page 55] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[55ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
A.4. Options Template Set Examples
A.4。 オプションテンプレートセットの例
A.4.1. Options Template Set Using IETF-Specified Information Elements
A.4.1。 オプションテンプレートは、IETFによって指定されたInformation Elementsを使用することでセットしました。
Per line card (the router being composed of two line cards), we want to report the following Information Elements:
系列カード(2枚の系列カードで構成されるルータ)に従って、以下のInformation Elementsを報告したいと思います:
- Total number of IPFIX Messages: exportedPacketCount [RFC5102], with
a length of 2 octets
- IPFIX Messagesの数を合計してください: 2つの八重奏の長さがあるexportedPacketCount[RFC5102]
- Total number of exported Flows: exportedFlowCount [RFC5102], with a
length of 2 octets
- エクスポートしているFlowsの数を合計してください: 2つの八重奏の長さがあるexportedFlowCount[RFC5102]
The line card, which is represented by the lineCardId Information Element [RFC5102], is used as the Scope Field.
系列カード(lineCardId情報Element[RFC5102]によって表される)はScope Fieldとして使用されます。
Therefore, the Options Template Set will be:
したがって、Options Template Setは以下の通りになるでしょう。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=3を設定してください。| 長さ=24| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID258| 分野カウント=3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 範囲分野カウント=1|0| lineCardId=141| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 範囲1つのフィールド長=4|0| exportedPacketCount=41| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フィールド長=2|0| exportedFlowCount=42| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フィールド長=2| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.4.2. Options Template Set Using Enterprise-Specific Information
Elements
A.4.2。 オプションテンプレートは、エンタープライズ-特殊情報Elementsを使用することでセットしました。
Per line card (the router being composed of two line cards), we want to report the following Information Elements:
系列カード(2枚の系列カードで構成されるルータ)に従って、以下のInformation Elementsを報告したいと思います:
- Total number of IPFIX Messages: exportedPacketCount [RFC5102],
with a length of 2 octets
- IPFIX Messagesの数を合計してください: 2つの八重奏の長さがあるexportedPacketCount[RFC5102]
- An enterprise-specific number of exported Flows, with a type of
42 and a length of 4 octets
- 一種の42があるエクスポートしているFlowsの企業特有の数と4つの八重奏の長さ
The line card, which is represented by the lineCardId Information Element [RFC5102], is used as the Scope Field.
系列カード(lineCardId情報Element[RFC5102]によって表される)はScope Fieldとして使用されます。
Claise, et al. Standards Track [Page 56] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[56ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
The format of the Options Template Set is as follows:
Options Template Setの形式は以下の通りです:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=3を設定してください。| 長さ=28| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID259| 分野カウント=3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 範囲分野カウント=1|0| lineCardId=141| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 範囲1つのフィールド長=4|0| exportedPacketCount=41| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フィールド長=2|1|情報Elementアイダホ州 = 42 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フィールド長=4| エンタープライズ番号… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... エンタープライズ番号| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Messagesの数を合計してください: 2つの八重奏の長さがあるexportedPacketCount[RFC5102]
- Total number of exported Flows: exportedFlowCount [RFC5102],
with a length of 2 octets
- エクスポートしているFlowsの数を合計してください: 2つの八重奏の長さがあるexportedFlowCount[RFC5102]
But this time, the information pertains to a proprietary scope, identified by enterprise-specific Information Element number 123.
しかし、今回、情報は企業特有の情報Element No.123によって特定された独占範囲に関係します。
Claise, et al. Standards Track [Page 57] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[57ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
The format of the Options Template Set is now as follows:
Options Template Setの形式は現在、以下の通りです:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=3を設定してください。| 長さ=28| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートID260| 分野カウント=3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 範囲分野カウント=1|1|範囲1Infor。 高架鉄道。 アイダホ州 = 123 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 範囲1つのフィールド長=4| エンタープライズ番号… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... エンタープライズ番号|0| exportedPacketCount=41| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フィールド長=2|0| exportedFlowCount=42| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フィールド長=2| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.4.4. Data Set Using an Enterprise-Specific Scope
A.4.4。 エンタープライズ特有の範囲を使用するデータセット
In this example, we report the following two Data Records:
この例では、私たちは以下の2Data Recordsを報告します:
Line Card ID | IPFIX Message | Exported Flow Records ------------------------------------------------------------------- Line Card 1 (lineCardId=1) | 345 | 10201 Line Card 2 (lineCardId=2) | 690 | 20402
線カードID| IPFIXメッセージ| 流れ記録であるとエクスポートされます。------------------------------------------------------------------- 線カード1(lineCardId=1)| 345 | 10201 線カード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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=260を設定してください。| 長さ=20| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 345 | 10201 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 690 | 20402 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Claise, et al. Standards Track [Page 58] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[58ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 八重奏情報Element| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.5.2. Example of Variable-Length Information Element with Length 255
to 65535 Octets
A.5.2。 長さの255〜65535の八重奏がある可変長の情報要素に関する例
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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年の八重奏情報Element| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IE| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
References
参照
Normative References
引用規格
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC
1305, March 1992.
[RFC1305] 工場、D.、「ネットワーク時間は仕様、実装、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(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.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
Claise, et al. Standards Track [Page 59] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[59ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
[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、「ストリーム制御伝動プロトコルの上のトランスポート層セキュリティ」、RFC3436、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)部分的な信頼性の拡大を流します」、RFC3758、2004年5月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport
Layer Security", RFC 4347, April 2006.
[RFC4347] レスコラとE.とN.Modadugu、「データグラムトランスポート層セキュリティ」、RFC4347、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)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of
Unicode for Internationalized Domain Names in
Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、「Punycode:」 「Applications(IDNA)のInternationalized Domain Namesのためにユニコードをコード化するBootstring」、RFC3492、2003年3月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission
Protocol", RFC 4960, September 2007.
[RFC4960] スチュワート、R.、エド、「ストリーム制御伝動プロトコル」、RFC4960、9月2007日
[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流れ情報輸出のための情報モデル」、RFC5102(2008年1月)。
[TCP] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[TCP] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[UDP] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、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.
G.、ブラウンリー、N.、Claise、B.、およびJ.Quittek、「IP流れ情報輸出のためのアーキテクチャモデル」という[IPFIX-アーチ]Sadasivanは進行中(2006年9月)で働いています。
[IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
"IPFIX Applicability", Work in Progress, June 2007.
[IPFIX、-、]、Zseby、T.、Boschi、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 。
Claise, et al. Standards Track [Page 60] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[60ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
[RFC1948] Bellovin, S., "Defending Against Sequence Number
Attacks", RFC 1948, May 1996.
[RFC1948]Bellovin S. (「一連番号攻撃に対して防御すること」でのRFC1948)は1996がそうするかもしれません。
[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"、STD58、RFC2579、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)をエクスポートします」、RFC3917、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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services
Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B.、エド、「シスコシステムズのNetFlowサービスはバージョン9インチ、RFC3954に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、]、米国電気電子技術者学会、「2進の浮動小数点の演算の規格」、IEEE規格754、8月1985
[dtls-for-sctp] Tuexen, M. and E. Rescola, "Datagram Transport Layer
Security for Stream Control Transmission Protocol",
Work in Progress, November 2007.
[sctpのためのdtls] 「ストリーム制御伝動プロトコルのためのデータグラムトランスポート層セキュリティ」という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。 徹底的なレビューのためのネヴィル・ブラウンリー、デーヴPlonka、ポール・エイトケン、およびアンドリュー・ジョンソン。 彼らのSCTP専門的技術と貢献のためのランドル・スチュワートとピーターLei。 SCTP部に関する最初の随筆のためのマーチンDjernaes。 セキュリティにおけるそれらのアドバイスと知識のためのマイケルBehringerとエリックVyncke。 DTLS部の彼のご協力のためのマイケルTuexen。 SCTP部の改良に関する彼女の貢献のためのエリーサBoschi。 技術審査とフィードバックのためにフルマー、セバスチャン・ザンダー、ジェフ・マイヤー、マウリジオ・モリーナ、カーター・ブラード、タルGivoly、ルッツ・マーク、デヴィッド・ムーア、Robert Lowe、ポールCalato、およびずっと多くをマークしてください。
Claise, et al. Standards Track [Page 61] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[61ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
Authors' Addresses
作者のアドレス
Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 EMail: bclaise@cisco.com
ブノワClaiseシスコシステムズDe Kleetlaan 6a b1 1831Diegemベルギー電話: +32 2 704 5622はメールされます: 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
スチュワートブライアントシスコシステムズInc.250、RG2 6GB、イギリスが電話をするLongwater、グリーンパーク読書: +44 (0) 20 8824-8828 メールしてください: 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
サイモンLeinenはWerdstrasse2私書箱CH-8021チューリッヒスイス電話を切り換えます: +41 44 268 1536はメールされます: 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-原基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.トラメル本命のネットワークの状況により異なる認識ソフトウェア工学研究所4500五番街ピッツバーグ(PA)15213: +1 9748年の412 268メール: bht@cert.org
Claise, et al. Standards Track [Page 62] RFC 5101 IPFIX Protocol Specification January 2008
Claiseする、他 標準化過程[62ページ]RFC5101IPFIXは仕様2008年1月に議定書を作ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Claise, et al. Standards Track [Page 63]
Claiseする、他 標準化過程[63ページ]
一覧
スポンサーリンク
