Network Working Group B. Trammell
Request for Comments: 5103 CERT/NetSA
Category: Standards Track E. Boschi
Hitachi Europe
January 2008
Bidirectional Flow Export Using IP Flow Information Export (IPFIX)
IPフロー情報のエクスポートを使用した双方向フローのエクスポート（IPFIX）
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each Biflow using a single Flow Record.
この文書は、単一のフローレコードを使用して各バイフローを表し、IPフロー情報エクスポート（IPFIX）プロトコルを用いた双方向フロー（バイフロー）情報をエクスポートするための効率的な方法を記載しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Rationale and History . . . . . . . . . . . . . . . . . . . . 5
4. Biflow Semantics . . . . . . . . . . . . . . . . . . . . . . . 6
5. Direction Assignment . . . . . . . . . . . . . . . . . . . . . 8
5.1. Direction by Initiator . . . . . . . . . . . . . . . . . . 9
5.2. Direction by Perimeter . . . . . . . . . . . . . . . . . . 10
5.3. Arbitrary Direction . . . . . . . . . . . . . . . . . . . 10
6. Record Representation . . . . . . . . . . . . . . . . . . . . 11
6.1. Reverse Information Element Private Enterprise Number . . 11
6.2. Enterprise-Specific Reverse Information Elements . . . . . 13
6.3. biflowDirection Information Element . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17
Appendix B. XML Specification of biflowDirection Information
Element . . . . . . . . . . . . . . . . . . . . . . . 21
Many flow analysis tasks benefit from association of the upstream and downstream flows of a bidirectional communication, e.g., separating answered and unanswered TCP requests, calculating round trip times, etc. Metering processes that are not part of an asymmetric routing infrastructure, especially those deployed at a single point through which bidirectional traffic flows, are well positioned to observe bidirectional flows (Biflows). In such topologies, the total resource requirements for Biflow assembly are often lower if the Biflows are assembled at the measurement interface as opposed to the Collector. The IPFIX Protocol requires only information model extensions to be complete as a solution for exporting Biflow data.
多くのフロー分析作業等、往復時間を計算し、答えや未回答TCP要求を分離し、例えば、双方向通信の上流と下流の流れの関連付けから、非対称ルーティングインフラストラクチャの一部ではない計量プロセス、で展開特に利益をもたらします双方向トラフィックが流れるシングルポイントは、ウェル双方向フロー（Biflows）を観察するように配置されています。コレクタとは対照的にBiflows測定インターフェースに組み立てられる場合、そのようなトポロジで、バイフローアセンブリの総リソース要件はしばしば低いです。 IPFIXプロトコルはバイフローデータをエクスポートするためのソリューションとして完結したことが唯一の情報モデルの拡張が必要です。
To that end, we propose a Biflow export method using a single Flow Record per Biflow in this document. We explore the semantics of bidirectional flow data in Section 4, "Biflow Semantics"; examine the various possibilities for determining the direction of Biflows in Section 5, "Direction Assignment"; then define the Biflow export method in Section 6, "Record Representation".
そのために、私たちは、この文書でバイフローごとに単一のフローレコードを使用してバイフローのエクスポート方法を提案します。我々は第4節、「バイフローセマンティクス」で双方向のフローデータの意味を探ります。 5章、「方向割り当て」にBiflowsの方向を決定するための様々な可能性を調べます。その後、第6節、「レコードの表現」でバイフローエクスポート方法を定義します。
This export method requires additional Information Elements to represent data values for the reverse direction of each Biflow, and a single additional Information Element to represent direction assignment information, as described in Sections 6.1 through 6.3. The selection of this method was motivated by an exploration of other possible methods of Biflow export using IPFIX; however, these methods have important drawbacks, as discussed in Section 3, "Rationale and History".
このエクスポート方法6.3を介してセクション6.1に記載されているように、方向割り当て情報を表現するために各バイフローの逆方向のデータ値を表すために、追加の情報要素を必要とし、単一の追加情報要素。この方法の選択は、IPFIXを使用バイフローエクスポートの他の可能な方法の探求によって動機付けました。しかし、これらの方法は第3節、「理論的根拠と歴史」で説明したように、重要な欠点を有しています。
"Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information" [RFC5101] (informally, the IPFIX Protocol document) and its associated documents define the IPFIX Protocol, which provides network engineers and administrators with access to IP traffic flow information.
「IPトラフィックフロー情報交換のためのIPFIXプロトコルの仕様」[RFC5101]（非公式に、IPFIXプロトコル文書）とそれに関連する文書は、IPトラフィックのフロー情報へのアクセスとネットワークエンジニアや管理者に提供しIPFIXプロトコルを定義します。
"Architecture for IP Flow Information Export" [IPFIX-ARCH] (the IPFIX Architecture document) defines the architecture for the export of measured IP flow information out of an IPFIX Exporting Process to an IPFIX Collecting Process, and the basic terminology used to describe the elements of this architecture, per the requirements defined in "Requirements for IP Flow Information Export" [RFC3917]. The IPFIX Protocol document [RFC5101] then covers the details of the method for transporting IPFIX Data Records and Templates via a congestion-aware transport protocol from an IPFIX Exporting Process to an IPFIX Collecting Process.
「IPフロー情報エクスポートするためのアーキテクチャ」[IPFIX-ARCH]（IPFIXアーキテクチャ文書）はIPFIX収集プロセスにIPFIXエクスポートプロセスのうち、測定IPフロー情報のエクスポートのためのアーキテクチャを定義し、説明するために使用される基本的な用語「IPフロー情報をエクスポートするための要件」[RFC3917]で定義された要件ごとに、このアーキテクチャの要素、。 IPFIXプロトコルドキュメント[RFC5101]は次いで、IPFIX収集プロセスにIPFIXエクスポートプロセスから渋滞認識トランスポートプロトコルを介してIPFIXデータレコードとテンプレートを輸送するための方法の詳細を覆います。
"Information Model for IP Flow Information Export" [RFC5102] (informally, the IPFIX Information Model document) describes the Information Elements used by IPFIX, including details on Information Element naming, numbering, and data type encoding. Finally, "IPFIX Applicability" [IPFIX-AS] describes the various applications of the IPFIX protocol and their use of information exported via IPFIX, and relates the IPFIX architecture to other measurement architectures and frameworks.
「IPフロー情報のエクスポートのための情報モデル」[RFC5102]（非公式に、IPFIX情報モデル文書は）情報要素の命名、番号付け、およびデータ型のエンコーディングの詳細を含むIPFIXによって使用される情報要素について説明します。最後に、「IPFIX適用」[IPFIX-ASは、種々のIPFIXプロトコルのアプリケーションとIPFIXを介してエクスポートされた情報の使用を説明し、他の測定アーキテクチャおよびフレームワークにIPFIXアーキテクチャに関する。
This document references the Protocol and Architecture documents for terminology, uses the IPFIX Protocol to define a bidirectional flow export method, and proposes additions to the information model defined in the IPFIX Information Model document.
この文書は、専門用語のためのプロトコルとアーキテクチャのドキュメントを参照する双方向フローのエクスポート方法を定義するためにIPFIXプロトコルを使用し、IPFIX情報モデルドキュメントで定義された情報モデルへの追加を提案しています。
Capitalized terms used in this document that are defined in the Terminology section of the IPFIX Protocol document [RFC5101] are to be interpreted as defined there. The following additional terms are defined in terms of the IPFIX Protocol document terminology.
IPFIXプロトコルドキュメント[RFC5101]の用語のセクションで定義され、この文書で使用大文字の用語が定義されるように解釈されるべきです。以下の追加条件は、IPFIXプロトコルドキュメントの用語で定義されています。
Directional Key Field: A Directional Key Field is a single field in a Flow Key as defined in the IPFIX Protocol document [RFC5101] that is specifically associated with a single endpoint of the Flow. sourceIPv4Address and destinationTransportPort are example Directional Key Fields.
方向キーフィールド：方向キーフィールドは、具体的にはフローの単一のエンドポイントに関連付けられているIPFIXプロトコルドキュメント[RFC5101]で定義されるようにフローキーに単一のフィールドです。 sourceIPv4AddressとdestinationTransportPortは、例えば、方向キーフィールドです。
Non-directional Key Field: A Non-directional Key Field is a single field within a Flow Key as defined in the IPFIX Protocol document [RFC5101] that is not specifically associated with either endpoint of the Flow. protocolIdentifier is an example Non-directional Key Field.
無指向性キーフィールド：無指向性キー・フィールド具体フローの終点のいずれかに関連付けられていないIPFIXプロトコルドキュメント[RFC5101]で定義されるようにフローキー内の単一のフィールドです。プロトコル識別子は、例えば、無指向キー・フィールドです。
Uniflow (Unidirectional Flow): A Uniflow is a Flow as defined in the IPFIX Protocol document [RFC5101], restricted such that the Flow is composed only of packets sent from a single endpoint to another single endpoint.
ユニフロー（一方向の流れ）は：ユニフローは、IPFIXプロトコルドキュメント[RFC5101]で定義されたフローだけ別の単一のエンドポイントに単一のエンドポイントから送信されたパケットで構成されているような制限として流れです。
Biflow (Bidirectional Flow): A Biflow is a Flow as defined in the IPFIX Protocol document [RFC5101], composed of packets sent in both directions between two endpoints. A Biflow is composed from two Uniflows such that:
バイフロー（双方向フロー）：バイフローは、2つのエンドポイント間で双方向に送信されたパケットで構成されるIPFIXプロトコルドキュメント[RFC5101]で定義されるようなフローです。バイフローは、そのような二Uniflowsから構成されています。
1. the value of each Non-directional Key Field of each Uniflow is identical to its counterpart in the other, and
1.各ユニフローの各非方向キーフィールドの値が他のその対応物と同一であり、そして
2. the value of each Directional Key Field of each Uniflow is identical to its reverse direction counterpart in the other.
2.各ユニフローの各方向キーフィールドの値は、他に、その逆方向の対応と同一です。
A Biflow contains two non-key fields for each value it represents associated with a single direction or endpoint: one for the forward direction and one for the reverse direction, as defined below.
以下に定義されるように、順方向用と逆方向に1つ：バイフローは単一方向またはエンドポイントに関連付けられ、それが表す各値のための2つの非キーフィールドが含ま。
Biflow Source: The Biflow Source is the endpoint identified by the source Directional Key Fields in the Biflow.
バイフロー出典：バイフローソースは、ソースバイフローで方向キーのフィールドで識別されるエンドポイントです。
Biflow Destination: The Biflow Destination is the endpoint identified by the destination Directional Key Fields in the Biflow.
バイフロー先：バイフロー先は、先バイフローで方向キーのフィールドで識別されるエンドポイントです。
forward direction (of a Biflow): The direction of a Biflow composed of packets sent by the Biflow Source. Values associated with the forward direction of a Biflow are represented using normal Information Elements. In other words, a Uniflow may be defined as a Biflow having only a forward direction.
（バイフローの）順方向：バイフローソースによって送信されたパケットから構成されるバイフローの方向。バイフローの順方向に関連付けられた値は、通常の情報要素を用いて表現しています。換言すれば、ユニフローはバイフローのみ前進方向を有するものとして定義することができます。
reverse direction (of a Biflow): The direction of a Biflow composed of packets sent by the Biflow Destination. Values associated with the reverse direction of a Biflow are represented using Reverse Information Elements, as defined below.
（バイフローの）逆方向：バイフロー先によって送信されたパケットから構成されるバイフローの方向。以下に定義されるようバイフローの逆方向に関連付けられた値は、リバース情報要素を使用して表されます。
Reverse Information Element: An Information Element defined as corresponding to a normal (or forward) Information Element, but associated with the reverse direction of a Biflow.
リバース情報Element：情報要素は、通常の（又はフォワード）情報要素に対応するものとして定義されるが、バイフローの逆方向に関連付けられました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
In selecting the Single Record Biflow export method described in this document as the recommendation for bidirectional flow export using IPFIX, we considered several other possible methods.
IPFIXを用いた双方向フローの輸出のための勧告として、この文書で説明する単一レコードバイフローエクスポート方法を選択する際に、我々は他のいくつかの可能な方法を検討しました。
The first and most obvious would be simply to export Biflows as two Uniflows adjacent in the record stream; a Collecting Process could then reassemble them with minimal state requirements. However, this has the drawbacks that it is merely an informal arrangement the Collecting Process cannot rely upon, and that it is not bandwidth-efficient, duplicating the export of Flow Key data in each Uniflow record.
最初の、そして最も明白なは、単にレコードストリームに隣接する2つのUniflowsとしてBiflowsをエクスポートすることです。収集プロセスは、最小限の状態の要件とそれらを組み立て直すことができます。しかし、これは単に収集プロセスが依存することはできません非公式配置である欠点があり、それが各ユニフローレコード内の流れのキーデータのエクスポートを複製し、帯域幅効率的ではないということ。
We then considered the method outlined in Reducing Redundancy in IPFIX and Packet Sampling (PSAMP) Reports [IPFIX-REDUCING] for reducing this bandwidth inefficiency. This would also formally link the two Uniflows into a single construct, by exporting the Flow Key as Common Properties then exporting each direction's information as Specific Properties. However, it would do so at the expense of additional overhead to transmit the commonPropertiesId, and additional state management requirements at both the Collecting and Exporting Processes.
我々は、この帯域幅の非効率性を低減するためのIPFIXとパケットサンプリング（PSAMP）レポート[IPFIX低減]の冗長性を減少させるのに概説した方法を検討しました。また、これは正式に共通プロパティは、特定のプロパティとして各方向の情報をエクスポートするようなフローキーをエクスポートすることで、単一の構築物に2 Uniflowsをリンクします。しかし、それはcommonPropertiesIdを送信するために追加のオーバーヘッドを犠牲にしてそう、との両方の収集とエクスポートプロセスで追加の状態管理の要件です。
A proposal was made on the IPFIX mailing list to use the Multiple Information Element feature of the protocol to export forward and reverse counters using identical Information Elements in the same Flow Record. In this approach, the first instance of a counter would represent the forward direction, and the second instance of the same counter would represent the reverse. This had the disadvantage of conflicting with the presently defined semantics for these counters, and, as such, was abandoned.
提案は、前方エクスポートし、同じフローレコードに同じ情報要素を使用してカウンターを逆にするプロトコルの複数の情報要素の機能を使用するには、IPFIXのメーリングリストで行われました。このアプローチでは、カウンタの最初のインスタンスが順方向に相当するであろう、と同じカウンタの2つ目のインスタンスは、逆を表すことになります。これは、次のような、放棄された、これらのカウンタのために現在定義された意味論と矛盾するという欠点を持っていた、と。
As stated in the Terminology section above, a Biflow is simply a Flow representing packets flowing in both directions between two endpoints on a network. There are compelling reasons to treat Biflows as single entities (as opposed to merely ad-hoc combinations of Uniflows) within IPFIX. First, as most application-layer network protocols are inherently bidirectional, a Biflow-based data model more accurately represents the behavior of the network, and enables easier application of flow data to answering interesting questions about network behavior. Second, exporting Biflow data can result in improved export efficiency by eliminating the duplication of Flow Key data in an IPFIX message stream, and improve collection efficiency by removing the burden of Biflow matching from the Collecting Process where possible.
上記用語のセクションで述べたように、バイフローは、単にネットワーク上の2つのエンドポイントの間で両方向に流れるパケットを表すフローです。 （Uniflowsの単なるアドホックの組み合わせではなく）IPFIX内の単一のエンティティとしてBiflowsを治療するために、説得力のある理由があります。ほとんどのアプリケーション層のネットワークプロトコルは本質的に双方向であるように、まず、バイフローベースのデータ・モデルは、より正確にネットワークの動作を表しており、ネットワークの挙動についての興味深い質問に答えるにフローデータをより簡単にアプリケーションを可能にします。第二、バイフローデータをエクスポートするIPFIXメッセージストリームにフローキーデータの重複を排除することによって改善された輸出効率をもたらし、可能な収集プロセスから一致バイフローの負担を除去することにより集光効率を向上させることができます。
Biflows are somewhat more semantically complicated than Uniflows. When handling Uniflows, the semantics of source and destination Information Elements are clearly defined by the semantics of the underlying packet header data: the source Information Elements represent the source header fields, and the destination Information Elements represent the destination header fields. When representing Biflows with single IPFIX Data Records, the definitions of source and destination must be chosen more carefully.
Biflowsはより意味的にややUniflowsよりも複雑です。 Uniflowsを扱う場合、送信元と宛先の情報要素の意味は明確に、基礎となるパケットのヘッダデータのセマンティクスによって定義される：ソース情報要素は、ソース・ヘッダ・フィールドを表し、及び宛先の情報要素は、宛先ヘッダフィールドを表します。単一IPFIXデータレコードとBiflowsを表す場合は、送信元と送信先の定義は、より慎重に選択しなければなりません。
As in the Terminology section above, we define the Source of a Biflow to be that identified by the source Directional Key Field(s), and the Destination of the Biflow to be that identified by the destination Directional Key Field(s). Note that, for IANA-registered Information Elements, or those defined by the IPFIX Information Model [RFC5102], Directional Key Fields associated with the Biflow Source are represented by Information Elements whose names begin with "source", and Directional Key Fields associated with the Biflow Destination are represented by Information Elements whose names begin with "destination"; it is recommended that enterprise-specific Information Elements follow these conventions, as well.
上記用語のセクションにおけるように、我々はバイフローのソースは、そのソース方向キーフィールド（複数可）によって識別される定義、及びバイフローの宛先は、宛先方向キーフィールド（複数可）によって識別されます。 IANA登録情報要素、またはバイフローソースに関連したIPFIX情報モデル[RFC5102]、方向キーのフィールドで定義されたものは、名前が「ソース」で始まる情報要素で表現されている、と方向キーのフィールドに関連付けられた、ということに注意してくださいバイフロー先は、名前が「先」で始まる情報要素で表現されています。企業固有の情報要素は、同様に、これらの規則に従うことをお勧めします。
Methods for assignment of Source and Destination by the Metering and Exporting Processes are described in the following section.
計量とエクスポートプロセスによってソースおよびデスティネーションの割り当てのための方法は、次のセクションに記載されています。
As the Source and Destination of a Biflow are defined in terms of its Directional Keys, Biflow values are also split info forward and reverse directions. As in the Terminology section above, the forward direction of a Biflow is composed of packets sent by the Biflow Source, and the reverse direction of a Biflow is composed of packets sent by the Destination. In other words, the two directions of a Biflow may be roughly thought of as the two Uniflows that were matched to compose the Biflow. A Biflow record, then, contains each Flow Key record once, and both forward Information Elements and Reverse Information Elements for each non-key field. See Figure 1 for an illustration of the composition of Biflows from Uniflows.
バイフローの発信元と宛先は、その方向キーで定義されているとおり、バイフロー値は、分割情報、前方もあり、方向を逆転します。上記用語のセクションにおけるように、バイフローの順方向はバイフローソースによって送信されたパケットから構成され、そしてバイフローの逆方向は、宛先によって送信されたパケットから構成されています。換言すれば、バイフローの二つの方向は概ねバイフローを構成する整合された2つのUniflowsと考えることができます。バイフローレコードは、その後、各一回のフローキーレコード、フォワード情報要素と各非キーフィールドのためのリバース情報要素の両方が含まれています。 UniflowsからBiflowsの組成については、図1を参照してください。
Uniflow Uniflow
+-------+-------+-----------------+ +-------+-------+-----------------+
| src A | dst B | counters/values | | src B | dst A | counters/values |
+-------+-------+-----------------+ +-------+-------+-----------------+
| | | |
V V V V
+-------+-------+---------------------+---------------------+
| src A | dst B | fwd counters/values | rev counters/values |
+-------+-------+---------------------+---------------------+
Biflow
Figure 1: Bidirectional Flow Conceptual Diagram
図1：双方向のフロー概念図
The reverse direction values are represented by Reverse Information Elements. The representation of these Reverse Information Elements within Templates is detailed in Section 5. A Flow Record may be considered to be a Biflow record by the Collecting Process if it contains at least one Reverse Information Element AND at least one Directional Key Field. Flow Records containing Reverse Information Elements but no Directional Key Fields are illegal, MUST NOT be sent by the Exporting Process, and SHOULD be dropped by the Collecting Process. The Collecting Process SHOULD log the receipt of such illegal Flow Records.
逆方向の値は、逆情報要素によって表されます。テンプレート内のこれらのリバース情報要素の表現は、それが少なくとも一つのリバース情報要素と少なくとも一つの方向キー・フィールドが含まれている場合、Aフローレコードが収集プロセスによってバイフローレコードであるとみなすことができる5章で詳しく説明しています。リバース情報要素が、無方向キーフィールドを含むフローレコードは、エクスポートプロセスで送ってはいけません、違法であり、収集プロセスによって廃棄されるべきです。収集プロセスは、このような違法なフローレコードの領収書をログインする必要があります。
When exporting Uniflows, Exporting Processes SHOULD use a Template containing no Reverse Information Elements. Note that a Template whose only Reverse Information Elements are counters MAY be used to export Uniflows, as counters with values of 0 are semantically equivalent to no reverse direction. However, this approach is not possible for Reverse Information Elements whose zero values have a distinct meaning (e.g., tcpControlBits).
Uniflowsをエクスポートする場合、エクスポートプロセスは全く逆の情報要素を含まないテンプレートを使用する必要があります。なお、その唯一のリバース情報要素であるカウンタ0の値とカウンタとして、Uniflowsをエクスポートするために使用されるかもしれない意味的に逆方向に相当するテンプレート。しかし、このアプローチは、そのゼロ値の異なる意味（例えば、tcpControlBits）を有するリバース情報要素のために不可能です。
Note that a Biflow traversing a middlebox [RFC3234] may show different flow properties on each side of the middlebox due to changes to the packet header or payload performed by the middlebox itself. Therefore, it MUST be clear at a Collecting Process whether packets were observed and metered before or after modification. The Observation Process SHOULD be located on one side of a middlebox, and the Exporting Process SHOULD communicate to the Collecting Process both the incoming value of the flow property changed within the middlebox and the changed value on the "other side". The IPFIX Information Model [RFC5102] provides Information Elements with prefix "post" for this purpose. The location of the Observation Point(s) with respect to the middlebox can be communicated using Options with Observation Point as Scope and elements such as lineCardID or samplerID.
ミドルボックスを横断バイフロー[RFC3234]を伴うミドルボックス自体によって実行されるパケットのヘッダ又はペイロードの変更にミドルボックスのそれぞれの側に異なる流動特性を示すことができることに留意されたいです。したがって、パケットは変更の前または後に観察され、計量されたかどうかを収集プロセスに明確でなければなりません。観測過程は、ミドルボックスの一方の側に配置する必要があり、そしてエクスポートプロセスは、収集プロセスの両方ミドルと「他方の側」に変更された値内で変化流動特性の着信値に通信する必要があります。 IPFIX情報モデル[RFC5102]は、この目的のために、接頭辞「ポスト」との情報要素を提供します。ミドルに対して観測ポイント（複数可）の位置を範囲として観測ポイントとオプションとそのようなlineCardID又はsamplerIDなどの要素を使用して通信することができます。
For further information on the effect of middleboxes within the IPFIX architecture, refer to Section 7 of the IPFIX Implementation Guidelines [IPFIX-IMPLEMENTATION].
IPFIXアーキテクチャ内の中間装置の効果の詳細については、IPFIX実装ガイドライン[IPFIX-IMPLEMENTATION]のセクション7を参照してください。
By the definition of Observation Domain in Section 2 of the IPFIX Protocol document [RFC5101], Biflows may be composed only of packets observed within the same Observation Domain. This implies that Metering Processes that build Biflows out of Uniflows must ensure that the two Uniflows were observed within the same Observation Domain.
IPFIXプロトコルドキュメント[RFC5101]のセクション2における観測ドメインの定義により、Biflowsは、同じ観測ドメイン内で観察パケットから構成されてもよいです。これはUniflowsの外にBiflowsを構築計量プロセスは、2 Uniflowsが同じ観測ドメイン内で観察されたことを確認しなければならないことを意味します。
Due to the variety of flow measurement applications and restrictions on Metering Process deployment, one single method of assigning the directions of a Biflow will not apply in all cases. This section describes three methods of direction assignment, and recommends them based upon Metering Process position and measurement application requirements. In each of the figures in this section, the "MP" box represents the Metering Process.
計量プロセスの展開に流量測定アプリケーション及び制限の様々な、バイフローの方向を割り当てる一つの方法は、すべての場合に適用されません。このセクションでは、方向割り当ての3つの方法について説明し、測光処理位置と測定アプリケーション要件に基づいて、それらをお勧めします。このセクションの各図において、「MP」ボックスは、計量プロセスを表します。
As the method selection is dependent on Metering Process position, it is sufficient to configure the direction assignment method at the Collecting and/or the Exporting Process out-of-band. For example, a Collecting Process might be configured that a specific Exporting Process identified by exporterIPv4Address is assigning direction by initiator; or both a Collecting Process and an Exporting Process could be simultaneously configured with a specific direction assignment perimeter. However, for Exporting Processes that use multiple direction selection methods, or for Collecting Processes accepting data from Exporting Processes using a variety of methods, a biflowDirection Information Element is provided for optional representation of direction assignment information.
方法の選択は、計量プロセスの位置に依存するように、収集及び/又はアウトオブバンドエクスポートプロセスの方向割り当て方式を設定するのに十分です。例えば、収集プロセスはexporterIPv4Addressによって識別される特定のエクスポートプロセスを開始することにより方向を割り当てるされるように構成されるかもしれません。または収集プロセスとエクスポートプロセスの両方が同時に特定の方向割り当て周囲で構成することができます。しかし、複数の方向の選択方法を使用するプロセスをエクスポートする、または種々の方法を使用してエクスポートプロセスからデータを受け入れるプロセスを収集するため、biflowDirection情報要素は、方向割り当て情報の任意の表現のために提供されます。
If the measurement application requires the determination of the initiator and responder of a given communication, the Metering Process SHOULD define the Biflow Source to be the initiator of the Biflow, where possible. This can be roughly approximated by a Metering Process observing packets in both directions simply assuming that the first packet seen in a given Biflow is the packet initiating the Biflow. A Metering Process may improve upon this method by using knowledge of the transport or application protocols (e.g., TCP flags, DNS question/answer counts) to better approximate the flow-initiating packet.
測定アプリケーションは、所与の通信のイニシエータとレスポンダの決意を必要とする場合、計量プロセスは、可能なバイフローのイニシエータであることバイフローソースを定義する必要があります。これはおおよそ単に所与バイフローに見られる最初のパケットがバイフローを開始したパケットであると仮定し、両方向にパケットを観察計量プロセスによって近似することができます。計量プロセスは、トランスポートまたはアプリケーションプロトコルの知識を使用して、この方法を改善することができる（例えば、TCPフラグは、DNS質問/回答数）は、より良いフロー開始パケットを近似します。
Note that direction assignment by initiator is most easily done by a single Metering Process positioned on a local link layer, as in Figure 2, or a single Metering Process observing bidirectional packet flows at a symmetric perimeter routing point, as in Figure 3.
注イニシエータによってその方向割り当てが最も容易図2のように、ローカルリンク層上に配置された単一の計量プロセスによって行われ、または双方向パケットを観察する単一計量プロセスは、図3のように、対称的な境界ルーティングポイントに流れます。
Note also that many Metering Processes have an "active" timeout, such that any flow with a duration longer than the active timeout is expired and any further packets belonging to that flow are accounted for as part of a new flow. This mechanism may cause issues with the assumption that a first packet seen is from the flow initiator, if the "first" packet is a middle packet in a long-duration flow.
注意はまた、多くの計量プロセスは長くアクティブタイムアウトよりも期間を持つすべてのフローが期限切れになっていると、そのフローに属する任意の更なるパケットが新しいフローの一部として計上されているように、「アクティブ」タイムアウトを持っています。このメカニズムは、「最初の」パケットが長時間流れの中間パケットであるか見て最初のパケットは、フローイニシエータからであるという仮定の問題が発生することがあります。
+-------+ +-------+
| node | | node |
+---+---+ +---+---+
| | +---------+
<===+=====+=====+======>+ +<===> Internet
| | router |
+---+---+ +---------+
| MP |
+---+---+
Figure 2: Local Link Metering Process Position
図2：ローカルリンク計量プロセス位置
+-------+ +-------+
| node | | node |
+---+---+ +---+---+
| | +---------+
<===+===========+======>+ +<===> Internet
| router |
| +----+--+
+----+ MP |
+-------+
Figure 3: Symmetric Routing Point Metering Process Position
図3：対称ルーティングポイント測光処理位置
If the measurement application is deployed at a network perimeter, as illustrated in Figure 4, such that there is a stable set of addresses that can be defined as "inside" that perimeter, and there is no measurement application requirement to determine the initiator and responder of a given communication, then the Metering Process SHOULD assign the Biflow Source to be the endpoint outside the perimeter.
図4に示すように、測定アプリケーションは、ネットワークの境界に配備されている場合は、そのような「内部」という境界として定義することができるアドレスの安定したセットがあり、イニシエータとレスポンダーを決定するための測定アプリケーションの要件は存在しないこと所与の通信は、計量プロセスは、境界外のエンドポイントであることバイフローソースを割り当てる必要があります。
No facility is provided for exporting the address set defining the interior of a perimeter; this set may be deduced by the Collecting Process observing the set of Biflow Source and Biflow Destination addresses, or configured out-of-band.
いいえ施設は周囲の内部を画定するアドレスセットをエクスポートするために提供されていません。このセットはバイフローソースとバイフロー宛先アドレスのセットを観察する収集プロセスにより推定、またはアウトオブバンド構成することができます。
+---------+ +---------+
====>+ access +====> ====>+ access +====>
Internet | router | Local Net | router | Internet
(link A) <====+ A +<==== <====+ B +<==== (link B)
+----+----+ +---------+
|
+---+---+
| MP |
+-------+
Figure 4: Perimeter Metering Process Position
図4：測光処理位置ペリメター
If the measurement application is deployed in a network core, such that there is no stable set of addresses defining a perimeter (e.g., due to BGP updates), as in Figure 5, and no requirement or ability to determine the initiator or responder of a given communication, then the Metering Process MAY assign the Biflow Source and Biflow Destination endpoints arbitrarily.
測定アプリケーションは、Aの開始又は応答を決定するという要件や能力がある（これはBGPアップデートに、例えば、）境界を画定するアドレスのない安定したセットは、図5のように、ではない、そのようなことは、ネットワークコアにおいて展開されている場合通信与えられ、その後、計量プロセスは、任意にバイフローソースとバイフロー先のエンドポイントを割り当てることができます。
In this case, the Metering Process SHOULD be consistent in its choice of direction. Once assigned, direction SHOULD be maintained for the lifetime of the Biflow, even in the case of active timeout of a long-lived Biflow.
この場合、計量プロセスは、方向のその選択に一貫しているべきです。一度割り当てられ、方向も長命バイフローの活性タイムアウトの場合には、バイフローの寿命のために維持されるべきです。
|
V
+----+----+ +---------+
<===+ core | | core +===>
| router +<========>+ router |
===>+ | | +<===
+----+----+ +----+----+
| |
+---+---+ V
| MP |
+-------+
Figure 5: Transit/Core Metering Process Position
図5：トランジット/コア測光処理位置
As noted above, Biflows are exported using a single Flow Record, each of which contains the Flow Key fields once, and both forward Information Elements and Reverse Information Elements for each non-key field. The IPFIX Information Model is extended to provide a Reverse Information Element counterpart to each presently defined forward Information Element, as required by any Information Element that may be a non-key field in a Biflow.
上述したように、Biflowsは、各非キーフィールドに一度のフローキーのフィールドを含むそれぞれの単一フローレコード、フォワード情報要素とリバースの情報要素の両方を使用してエクスポートされます。バイフロー非キーフィールドとすることができる任意の情報要素によって要求されるIPFIX情報モデルは、それぞれ現在前方に定義された情報要素にリバース情報要素の対応を提供するように拡張されます。
Reverse Information Elements are specified as a separate "dimension" in the Information Element space, assigning Private Enterprise Number (PEN) 29305 to this document, and defining that PEN to signify "IPFIX Reverse Information Element" (the Reverse PEN). This Reverse PEN serves as a "reverse direction flag" in the Template; each Information Element number within this PEN space is assigned to the reverse counterpart of the corresponding IANA-assigned public Information Element number. In other words, to generate a Reverse Information Element in a Template corresponding to a given forward Information Element, simply set the enterprise bit and define the Information Element within the Reverse PEN space, as in Figure 6 below.
リバース情報要素このドキュメントに民間企業番号（PEN）29305を割り当て、情報要素の空間に別の「次元」として指定し、PEN「はIPFIXリバース情報要素」（リバースPEN）を意味することを定義しています。このリバースPENは、テンプレートに「逆方向フラグ」として機能します。このPEN空間内の各情報要素の数は、対応するIANAによって割り当てられたパブリック情報要素の数の逆相手に割り当てられています。換言すれば、前方に所定の情報要素に対応するテンプレートにリバース情報要素を生成するために、単に企業のビットを設定し、以下の図6に示すように、リバースPEN空間内の情報要素を定義します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
forward |
|
reverse V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| (rev) flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse PEN 29305 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example Mapping between Forward and Reverse IEs
図6：順方向および逆方向のIEの間のマッピングの例
As the Reverse Information Element dimension is treated explicitly as such, new Information Elements can be added freely to the IANA-managed space without concern for whether a Reverse Information Element should also be added. Aside from the initial allocation of a Private Enterprise Number for this purpose, there is no additional maintenance overhead for supporting Reverse Information Elements in the IPFIX Information Model.
リバース情報要素の寸法は、このようなとして明示的に扱われたように、新しい情報要素は、リバース情報要素も追加する必要があるかどうかを心配することなくIANAが管理する空間に自由に追加することができます。別にこの目的のために民間企業数の初期割り当てから、IPFIX情報モデルにリバース情報要素をサポートするための追加のメンテナンスのオーバーヘッドがありません。
Note that certain Information Elements in the IPFIX Information Model [RFC5102] are not reversible; that is, they are semantically meaningless as Reverse Information Elements. An Exporting Process MUST NOT export a Template containing the reverse counterpart of a non-reversible Information Element. A Collecting Process receiving the reverse counterpart of a non-reversible Information Element MAY discard that Information Element from the Flow Record. Non-reversible Information Elements represent properties of the Biflow record as a whole, or are intended for internal the use of the IPFIX Protocol itself. Therefore, by definition, they cannot be associated with a single direction or endpoint of the Flow.
IPFIX情報モデルにおける特定の情報エレメント[RFC5102]は可逆的ではないことに留意されたいです。つまり、彼らはリバース情報要素として意味的に無意味です。エクスポートプロセスは、非可逆情報要素の逆の対応を含むテンプレートをエクスポートしてはなりません。非可逆情報要素の逆の対応を受けた収集プロセスは、フローレコードからその情報要素を捨てるかもしれ。非可逆情報要素は、全体としてバイフローレコードのプロパティを表す、またはIPFIXプロトコル自体の内部使用のために意図されています。したがって、定義により、それらは、流れの単一方向またはエンドポイントに関連付けることができません。
The following specific Information Elements are not reversible:
次の特定の情報要素は可逆的ではありません。
1. Identifiers defined in Section 5.1 of [RFC5102] that cannot be associated with a single direction of Uniflow collection: flowId (5.1.7), templateId (5.1.8), observationDomainId (5.1.9), and commonPropertiesId (5.1.11).
ユニフローコレクションの単方向と関連付けることができない[RFC5102]のセクション5.1で定義された1識別子：フローID（5.1.7）、れるtemplateId（5.1.8）、observationDomainId（5.1.9）、及びcommonPropertiesId（5.1.11 ）。
2. Process configuration elements defined in Section 5.2 of [RFC5102].
[RFC5102]のセクション5.2で定義された2プロセス構成要素。
Any future addition to the Information Element Registry by IANA that meets the criteria defined above SHOULD also be considered to be non-reversible by the Collecting Process.
上記で定義された基準を満たすIANAによって情報要素レジストリに将来の添加はまた、収集プロセスによって、非可逆的であると考えられるべきです。
Note that Information Elements commonly used as Flow Keys (e.g., header fields defined in Sections 5.4 and 5.5 of the Information Model) are reversible, as they may be used as value fields in certain contexts, as when associating ICMP error messages with the flows that caused them.
彼らはそのフローにICMPエラーメッセージを関連付けるときのように、特定の状況における値フィールドとして使用することができるように、一般的にフローキーとして使用する情報要素（セクション5.4および情報モデルの5.5で定義され、例えば、ヘッダフィールド）が、可逆的であることに注意してくださいそれらを引き起こしました。
Note that the Reverse PEN defined above is only available for allocating reverse counterparts of IANA-registered IPFIX Information Elements. No facility is provided for allocating reverse counterparts of enterprise-specific Information Elements.
上記で定義されたリバースPENは、IANAに登録IPFIX情報エレメントの逆対応を割り当てるためにのみ使用可能であることに留意されたいです。何の機能は、企業固有の情報要素の逆の対応を割り当てるために提供されていません。
The allocation of enterprise-specific Information Elements for IPFIX is left to the discretion of the organization allocating them. Note that, as enterprise-specific Information Elements are designed for the internal use of private enterprises, the lack of any guidance or standard on Information Element allocation policies poses no interoperability issues. However, if a private enterprise's own Information Element registry anticipates the allocation of reversible Information Elements, and the use of this specification for the export of Biflow data, that registry MAY reserve one of the fifteen available bits in the Information Element ID to signify the reverse direction. For example, if the most significant bit were selected, this would reserve Information Element IDs 0x4000 to 0x7FFF for the reverse direction of Information Element IDs 0x0000 to 0x3FFF.
IPFIXのための企業別の情報要素の割り当ては、それらを割り当てる団体の裁量に任されています。エンタープライズ固有の情報要素として、民間企業の内部使用のために設計されている、ということに注意してください、情報要素の割り当てポリシー上の任意のガイダンスや基準の欠如は何の相互運用性の問題を提起していません。民間企業独自の情報要素レジストリは可逆情報要素の割り当て、およびバイフローデータの輸出については、この仕様書の利用を見込ん場合は、そのレジストリは逆を意味する情報要素IDに15利用可能なビットのいずれかを予約することができます方向。最上位ビットを選択した場合、例えば、これは0x3FFFのに情報要素のIDが0x0000の逆方向のためには0x7FFFに情報要素のID 0x4000のを予約します。
Description: A description of the direction assignment method used to assign the Biflow Source and Destination. This Information Element MAY be present in a Flow Record, or applied to all flows exported from an Exporting Process or Observation Domain using IPFIX Options. If this Information Element is not present in a Flow Record or associated with a Biflow via scope, it is assumed that the configuration of the direction assignment method is done out-of-band. Note that when using IPFIX Options to apply this Information Element to all flows within an Observation Domain or from an Exporting Process, the Option SHOULD be sent reliably. If reliable transport is not available (i.e., when using UDP), this
説明：バイフロー送信元と宛先を割り当てるために使用される方向割り当て方法の説明。この情報要素はフローレコードに存在する、またはIPFIXオプションを使用してエクスポートプロセスや観測ドメインからエクスポートされたすべてのフローに適用することができます。この情報要素は、フローレコード中に存在するか、またはスコープを介しバイフローに関連付けられていない場合は、方向割り当て方法の構成は、アウトオブバンドで行われるものとします。観測ドメイン内またはエクスポートプロセスからのすべてのフローにこの情報要素を適用するためにIPFIXオプションを使用する場合、オプションが確実に送信する必要があることに注意してください。信頼性の高い輸送は（すなわち、UDPを使用した場合）使用できない場合は、この
Information Element SHOULD appear in each Flow Record. This field may take the following values:
情報要素は、各フローレコードに表示されます。このフィールドには、次の値をとることがあります。
+-------+------------------+----------------------------------------+
| Value | Name | Description |
+-------+------------------+----------------------------------------+
| 0x00 | arbitrary | Direction was assigned arbitrarily. |
| 0x01 | initiator | The Biflow Source is the flow |
| | | initiator, as determined by the |
| | | Metering Process' best effort to |
| | | detect the initiator. |
| 0x02 | reverseInitiator | The Biflow Destination is the flow |
| | | initiator, as determined by the |
| | | Metering Process' best effort to |
| | | detect the initiator. This value is |
| | | provided for the convenience of |
| | | Exporting Processes to revise an |
| | | initiator estimate without re-encoding |
| | | the Biflow Record. |
| 0x03 | perimeter | The Biflow Source is the endpoint |
| | | outside of a defined perimeter. The |
| | | perimeter's definition is implicit in |
| | | the set of Biflow Source and Biflow |
| | | Destination addresses exported in the |
| | | Biflow Records. |
+-------+------------------+----------------------------------------+
Abstract Data Type: unsigned8
抽象データ型：UNSIGNED8
Data Type Semantics: identifier
データ型の意味：識別子
ElementId: 239
ELEMENTID：239
Status: current
ステータス：現在の
This document specifies the creation of a new dimension in the Information Element space defined by the IPFIX Information Model [RFC5102]. This new dimension is defined by the allocation of a new Private Enterprise Number (PEN). The Internet Assigned Numbers Authority (IANA) has assigned Private Enterprise Number 29305 to this document as the "IPFIX Reverse Information Element Private Enterprise", with this document's authors as point of contact.
このドキュメントは、IPFIX情報モデル[RFC5102]で定義された情報要素の空間に新たな次元の作成を指定します。この新しいディメンションは、新たな民間企業番号（PEN）の割り当てによって定義されます。 IANA（Internet Assigned Numbers Authority）は、接触のポイントとして、この文書の著者で、「IPFIXリバース情報要素民間企業」として、この文書に民間企業番号29305を割り当てました。
This document specifies the creation of a new IPFIX Information Element, biflowDirection, as defined in Section 6.3. IANA has assigned Information Element number 239 in the IPFIX Information
6.3節で定義されているこの文書は、新しいIPFIX情報エレメント、biflowDirectionの作成を指定します。 IANAはIPFIX情報に情報要素番号239が割り当てられています
Element registry for the biflowDirection Information Element. The values defined for this Information Element are static, and as such do not need to be maintained by IANA in a sub-registry.
biflowDirection情報要素の要素レジストリ。この情報要素に定義されている値は静的であり、そのようにサブレジストリにIANAによって維持されている必要はありません。
The same security considerations as for the IPFIX Protocol [RFC5101] apply.
IPFIXプロトコルの場合と同じセキュリティ上の考慮事項は、[RFC5101]適用されます。
We would like to thank Lutz Mark, Juergen Quittek, Andrew Johnson, Paul Aitken, Benoit Claise, and Carsten Schmoll for their contributions and comments. Special thanks to Michelle Cotton for her assistance in navigating the IANA process for Enterprise Number assignment, and for the IANA pre-review of the document.
私たちは、彼らの貢献とコメントのためルッツマーク、ユルゲンQuittek、アンドリュー・ジョンソン、ポール・エイトケン、ブノワClaise、およびカーステンSchmollに感謝したいと思います。エンタープライズ番号の割り当てのための、およびドキュメントのIANA事前審査のためにIANAプロセスをナビゲート中の彼女の援助のためのミシェル・コットンに感謝します。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B.、エド。、RFC 5101、2008年1月 "IPトラフィックフロー情報を交換するためのIPフロー情報のエクスポート（IPFIX）プロトコルの仕様"。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、ブライアント、S.、Claise、B.、エイトケン、P.、およびJ.マイヤー、 "IPフロー情報のエクスポートのための情報モデル"、RFC 5102、2008年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B.とS.つば、 "のMiddleboxes：分類と課題"、RFC 3234、2002年2月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B.、およびS.ザンダー、 "IPフロー情報エクスポート（IPFIX）のための要件"、RFC 3917、2004年10月。
[IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", Work in Progress, September 2006.
[IPFIX - ARCH] Sadasivan、G.、ブラウンリー、N.、Claise、B.、およびJ. Quittek、 "IPフロー情報のエクスポートのためのアーキテクチャ"、進歩、2006年9月での作業。
[IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", Work in Progress, July 2007.
[IPFIX-AS] Zseby、T.、ボスキ、E.、ブラウンリー、N.、およびB. Claise、 "IPFIX適用"、進歩、2007年7月ワーク。
[IPFIX-IMPLEMENTATION] Boschi, E., Mark, L., Quittek, j., Stiemerling, M., and P. Aitken, "IPFIX Implementation Guidelines", Work in Progress, September 2007.
[IPFIX-IMPLEMENTATION]ボスキ、E.、マーク、L.、Quittek、J。、Stiemerling、M.、およびP.エイトケン、 "IPFIXの実装のガイドライン"、進歩、2007年9月での作業。
[IPFIX-REDUCING] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", Work in Progress, May 2007.
、進捗状況、2007年5月の仕事 "IPフロー情報のエクスポート（IPFIX）とパケットサンプリング（PSAMP）レポートで冗長性の削減"、ボスキ、E.、マーク、L.、およびB. Claiseを[IPFIX低減]。
Appendix A. Examples
付録A.例
The following example describes a Biflow record as specified in Section 6, above. The Reverse PEN is assigned for the purpose of differentiating forward from Reverse Information Elements.
次の例では、上記第6節で指定されるようバイフローレコードを記述する。リバースPENは、リバースの情報要素から前方に分化させる目的のために割り当てられます。
The information exported in this case is:
この場合にエクスポートされた情報は以下のとおりです。
o The start time of the flow: flowStartSeconds in the IPFIX Information Model [RFC5102], with a length of 4 octets.
IPFIX情報モデル[RFC5102]でflowStartSeconds、4つのオクテットの長さ：フローの開始時刻O。
o The reverse start time of the flow: flowStartSeconds in the IPFIX Information Model [RFC5102], with a length of 4 octets, and the enterprise bit set to 1. The following PEN is the Reverse PEN.
流れの逆転開始時間O：IPFIX情報モデルにおけるflowStartSeconds [RFC5102]、4つのオクテットの長さ、及び以下PEN 1に設定エンタープライズビットが逆PENです。
o The IPv4 source IP address: sourceIPv4Address in the IPFIX Information Model [RFC5102], with a length of 4 octets.
sourceIPv4Address IPFIX情報モデル[RFC5102]で、4つのオクテットの長さ：IPv4の送信元IPアドレス、O。
o The IPv4 destination IP address: destinationIPv4Address in the IPFIX Information Model [RFC5102], with a length of 4 octets.
O IPv4の宛先IPアドレス：IPFIX情報モデル[RFC5102]でdestinationIPv4Address、4つのオクテットの長さを有します。
o The source port: sourceTransportPort in the IPFIX Information Model [RFC5102], with a length of 2 octets.
ソースポートO：2つのオクテットの長さIPFIX情報モデルにおけるsourceTransportPort [RFC5102]。
o The destination port: destinationTransportPort in the IPFIX Information Model [RFC5102], with a length of 2 octets.
宛先ポートO：2つのオクテットの長さIPFIX情報モデルにおけるdestinationTransportPort [RFC5102]。
o The protocol identifier: protocolIdentifier in the IPFIX Information Model [RFC5102], with a length of 1 octet.
1つのオクテットの長さを有するIPFIX情報モデルにおけるプロトコル識別子[RFC5102]：プロトコル識別子O。
o The number of octets of the Flow: octetTotalCount in the IPFIX Information Model [RFC5102], with a length of 4 octets.
4つのオクテットの長さを有するIPFIX情報モデルにおけるoctetTotalCount [RFC5102]：フローのオクテット数、O。
o The reverse number of octets of the Flow: octetTotalCount in the IPFIX Information Model [RFC5102], with a length of 4 octets, and the enterprise bit set to 1. The following PEN is the Reverse PEN.
Oフローのオクテットの逆数：IPFIX情報モデル[RFC5102]でoctetTotalCount、4つのオクテットの長さ、及び次のPENは、1に設定エンタープライズビットはリバースPENです。
o The number of packets of the Flow: packetTotalCount in the IPFIX Information Model [RFC5102], with a length of 4 octets.
4つのオクテットの長さを有するIPFIX情報モデルにおけるpacketTotalCount [RFC5102]：フローのパケット数、O。
o The reverse number of packets of the Flow: packetTotalCount in the IPFIX Information Model [RFC5102], with a length of 4 octets, and the enterprise bit set to 1. The following PEN is the Reverse PEN.
逆流のパケットの数（O）packetTotalCount IPFIX情報モデル[RFC5102]で、4つのオクテットの長さ、及び次のPENは、1に設定エンタープライズビットリバースPENです。
and the resulting Template Set would look like the diagram below:
そして得られたテンプレートセットは、次の図のようになります。
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 = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID >= 256 | Field Count = 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse PEN 29305 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceTransportPort 7 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationTransportPort 11 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier 4 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetTotalCount 85 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| octetTotalCount 85 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse PEN 29305 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetTotalCount 86 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| packetTotalCount 86 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse PEN 29305 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Single Record Biflow Template Set
図7：単一レコードバイフローテンプレートセット
The following example Data Set represents a typical HTTP transaction. Its format is defined by the example Template, above.
次の例では、データセットは、一般的なHTTPトランザクションを表します。そのフォーマットは、上記の実施例テンプレートによって定義されます。
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 = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2006-02-01 17:00:00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2006-02-01 17:00:01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32770 | 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | 18000 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . | 128000 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . | 65 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . | 110 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . |
+-+-+-+-+-+-+-+-+
Figure 8: Single Record Biflow Data Set
図8：単一レコードバイフローデータセット
The following example demonstrates the use of the biflowDirection Information Element, as specified in Section 6.2, using the IPFIX Options mechanism to specify that perimeter direction selection is in effect for a given Observation Domain.
周方向の選択は、所与の観測ドメインに対して有効であることを指定するIPFIXオプションメカニズムを使用して、セクション6.2で指定されるように以下の実施例は、biflowDirection情報要素の使用を示します。
The information exported in this case is:
この場合にエクスポートされた情報は以下のとおりです。
o The Observation Domain: observationDomainId in the IPFIX Information Model [RFC5102], with a length of 4 octets.
観測ドメインO：4つのオクテットの長さを有するIPFIX情報モデルにおけるobservationDomainId [RFC5102]。
o The direction assignment method: biflowDirection as defined in Section 6.2, above, with a length of 1 octet.
方向割り当て方法O：biflowDirection 1つのオクテットの長さと、上記セクション6.2で定義された通りです。
and the resulting Options Template Set would look like the diagram below:
そして得られたオプションのテンプレートセットは、次の図のようになります。
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 = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID >= 256 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Count = 1 |0| observationDomainId 149 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| biflowDirection 239 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Biflow Direction Options Template Set
図9：バイフロー方向オプションテンプレートセット
The following example Data Set would specify that perimeter direction selection is in effect for the Observation Domain with ID 33. Its format is defined by the example Options Template, above. Note that this example data set would be sent reliably, as specified in the description of the biflowDirection Information Element.
その周方向の選択を指定するであろう次の例では、データセットは、上記の実施例オプションテンプレートによって定義されたID 33をそのフォーマットの観測ドメインに有効です。 biflowDirection情報要素の説明で指定されるように、この例のデータセットは、確実に送信されることに留意されたいです。
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 = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 |
+-+-+-+-+-+-+-+-+
Figure 10: Biflow Direction Options Data Set
図10：バイフロー方向オプションデータセット
Appendix B. XML Specification of biflowDirection Information Element
biflowDirection情報要素の付録B.のXML仕様
This appendix contains a machine-readable description of the biflowDirection information element defined in this document, coded in XML. Note that this appendix is of informational nature, while the text in Section 6.3 is normative.
この付録では、XMLでコード化されたこの文書で定義されたbiflowDirection情報要素の機械可読記述が含まれています。 6.3節のテキストは規範的である一方で、この付録では、情報の性質のものであることに注意してください。
The format in which this specification is given is described by the XML Schema in Appendix B of the IPFIX Information Model [RFC5102].
この仕様が与えられたフォーマットは、IPFIX情報モデル[RFC5102]の付録BにXMLスキーマによって記述されています。
<?xml version="1.0" encoding="UTF-8"?>
<？xml version = "1.0" エンコード= "UTF-8"？>
<fieldDefinitions xmlns="urn:ietf:params:xml:ns:ipfix-info" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:ipfix-info ipfix-info.xsd">
<fieldDefinitionsのxmlns = "壷：IETF：のparams：XML：NS：IPFIX-情報" のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance" のxsi：schemaLocationの= "壷：IETF：のparams ：XML：NS：IPFIX-情報IPFIX-info.xsd ">
<field name="biflowDirection" dataType="unsigned8" dataTypeSemantics="identifier" group="misc" elementId="239" applicability="all" status="current"> <description> <paragraph> A description of the direction assignment method used to assign the Biflow Source and Destination. This Information Element MAY be present in a Flow Data Record, or applied to all flows exported from an Exporting Process or Observation Domain using IPFIX Options. If this Information Element is not present in a Flow Record or associated with a Biflow via scope, it is assumed that the configuration of the direction assignment method is done out-of-band. Note that when using IPFIX Options to apply this Information Element to all flows within an Observation Domain or from an Exporting Process, the Option SHOULD be sent reliably. If reliable transport is not available (i.e., when using UDP), this Information Element SHOULD appear in each Flow Record. This field may take the following values: </paragraph>
<フィールド名=「biflowDirection」データ型=「UNSIGNED8」dataTypeSemantics =「識別子」グループ=「その他」ELEMENTID =「239」の適用=「全ての」ステータス=「現在」> <記述> <パラグラフ>方向割り当ての説明この方法は、バイフローSourceとDestinationを割り当てるために使用されます。この情報要素はフローデータレコードに存在する、またはIPFIXオプションを使用してエクスポートプロセスや観測ドメインからエクスポートされたすべてのフローに適用することができます。この情報要素は、フローレコード中に存在するか、またはスコープを介しバイフローに関連付けられていない場合は、方向割り当て方法の構成は、アウトオブバンドで行われるものとします。観測ドメイン内またはエクスポートプロセスからのすべてのフローにこの情報要素を適用するためにIPFIXオプションを使用する場合、オプションが確実に送信する必要があることに注意してください。信頼性の高いトランスポートが利用できない場合（UDPを使用した場合、すなわち、）、この情報要素は、各フローレコードに表示されます。このフィールドは、次の値をとることがあります。</パラグラフ>
<artwork>
+-------+------------------+----------------------------------------+
| Value | Name | Description |
+-------+------------------+----------------------------------------+
| 0x00 | arbitrary | Direction was assigned arbitrarily. |
| 0x01 | initiator | The Biflow Source is the flow |
| | | initiator, as determined by the |
| | | Metering Process' best effort to |
| | | detect the initiator. |
| 0x02 | reverseInitiator | The Biflow Destination is the flow |
| | | initiator, as determined by the |
| | | Metering Process' best effort to |
| | | detect the initiator. This value is |
| | | provided for the convenience of |
| | | Exporting Processes to revise an |
| | | initiator estimate without re-encoding |
| | | the Biflow Record. |
| 0x03 | perimeter | The Biflow Source is the endpoint |
| | | outside of a defined perimeter. The |
| | | perimeter's definition is implicit in |
| | | the set of Biflow Source and Biflow |
| | | Destination addresses exported in the |
| | | Biflow Records. |
+-------+------------------+----------------------------------------+
</artwork>
</description>
</field>
</fieldDefinitions>
Authors' Addresses
著者のアドレス
Brian H. Trammell CERT Network Situational Awareness Software Engineering Institute 4500 Fifth Avenue Pittsburgh, PA 15213 United States
ブライアンH.トラメルCERTネットワーク状況認識ソフトウェア工学研究所4500フィフスアベニューピッツバーグ、ペンシルバニア15213米国
Phone: +1 412 268 9748 EMail: bht@cert.org
電話：+1 412 268 9748 Eメール：bht@cert.org
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland
エリサボスキ日立ヨーロッパのC / ETHチューリッヒGloriastrasse 35 8092チューリッヒスイスO
Phone: +41 44 6327057 EMail: elisa.boschi@hitachi-eu.com
電話：+41 44 6327057 Eメール：elisa.boschi@hitachi-eu.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。