[要約] RFC 5103は、IP Flow Information Export（IPFIX）を使用して双方向フローのエクスポートを行うための仕様です。このRFCの目的は、ネットワークトラフィックの双方向フロー情報を効果的に収集し、分析するための方法を提供することです。
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）プロトコルを使用して、双方向フロー（BIFLOW）情報をエクスポートするための効率的な方法について説明します。
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要求と未回答のTCP要求の分離、往復時間などの計算など、非対称ルーティングインフラストラクチャの一部ではない計量プロセス、特に展開されているプロセスの計算プロセスなど双方向の交通が流れる単一のポイントは、双方向の流れを観察するために十分に配置されています（二胞体）。このようなトポロジでは、コレクターではなく測定インターフェイスでビフローが組み立てられている場合、ビフローアセンブリの総リソース要件はしばしば低くなります。IPFIXプロトコルでは、BIFLOWデータをエクスポートするためのソリューションとして、情報モデル拡張機能のみが完了する必要があります。
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「Biflow Semantics」の双方向フローデータのセマンティクスを探ります。セクション5の「方向割り当て」で二胞体の方向を決定するためのさまざまな可能性を調べます。次に、セクション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.1から6.3で説明されているように、方向割り当て情報を表す単一の追加情報要素が必要です。この方法の選択は、IPFIXを使用した他の可能なBIFLOWエクスポートの方法の調査によって動機付けられました。ただし、セクション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プロトコルドキュメント）とその関連ドキュメントは、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]で定義されているフローキーの単一フィールドです。soulityIpv4AddressおよびdettinentTransportportは、方向性のあるキーフィールドの例です。
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.
非方向キーフィールド：非方向キーフィールドは、Flowのいずれのエンドポイントに特異的に関連付けられていないIPFIXプロトコルドキュメント[RFC5101]で定義されているフローキー内の単一フィールドです。Protocolidentifierは、非方向性キーフィールドの例です。
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.
Uniflow（単方向の流れ）：Uniflowは、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:
Biflow（双方向の流れ）：Biflowは、2つのエンドポイント間で両方向に送られたパケットで構成されるIPFixプロトコルドキュメント[RFC5101]で定義されているフローです。ビフロウは、次のような2つのユニフローで構成されています。
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.
前方方向（ビフローの）：ビフローソースから送られたパケットで構成されるビフローの方向。ビフローの前方方向に関連付けられた値は、通常の情報要素を使用して表されます。言い換えれば、Uniflowは、前方方向しか持たないBiflowとして定義される場合があります。
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.
逆情報要素：通常の（または順方向）情報要素に対応するものとして定義された情報要素ですが、ビフロウの逆方向に関連付けられています。
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.
このドキュメントで説明されている単一のレコードBiflowエクスポート方法を選択する際に、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つのユニフローとしてビフロウをエクスポートすることです。収集プロセスは、最小限の状態要件でそれらを再組み立てることができます。ただし、これには、収集プロセスが依存できない非公式の取り決めであり、帯域幅効率がなく、各ユニフローレコードのフローキーデータのエクスポートを複製するという欠点があります。
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つのユニフローを単一の構成に正式にリンクします。ただし、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つのエンドポイント間の両方向に流れるパケットを表すフローです。ipfix内の単一のエンティティとして（単なる普通の単一の組み合わせとは対照的に）単一のエンティティとして扱う説得力のある理由があります。第一に、ほとんどのアプリケーション層ネットワークプロトコルは本質的に双方向であるため、ビフローベースのデータモデルはネットワークの動作をより正確に表し、フローデータをより簡単に適用してネットワークの動作に関する興味深い質問に答えることができます。第二に、ビフロウデータをエクスポートすると、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.
二分は、ユニフロウよりも意味的に複雑です。Uniflowsを処理する場合、ソースおよび宛先情報要素のセマンティクスは、基礎となるパケットヘッダーデータのセマンティクスによって明確に定義されます。ソース情報要素はソースヘッダーフィールドを表し、宛先情報要素は宛先ヘッダーフィールドを表します。単一のIPFIXデータレコードを使用してBIFLOWを表す場合、ソースと宛先の定義をより慎重に選択する必要があります。
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]で定義されている情報要素の場合、biflowソースに関連付けられた方向性キーフィールドは、名前が「ソース」で始まる情報要素と、次の方向性キーフィールドで表されることに注意してください。ビフローの宛先は、「宛先」で名前が始まる情報要素で表されます。エンタープライズ固有の情報要素も、これらの規則に従うことをお勧めします。
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つの方向は、ビフローを構成するために一致した2つのユニフォローと大まかに考えられるかもしれません。次に、Biflowレコードには、各フローキーレコードが1回含まれています。Uniflowsからのビフロウの構成の図については、図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.
逆方向の値は、逆情報要素で表されます。テンプレート内のこれらの逆情報要素の表現については、セクション5で詳しく説明します。フローレコードは、少なくとも1つの逆情報要素と少なくとも1つの方向キーフィールドが含まれている場合、収集プロセスによるビフローレコードと見なされる場合があります。逆情報要素を含むフローレコードは、方向性のあるキーフィールドは違法ではなく、エクスポートプロセスによって送信されてはなりません。また、収集プロセスによって削除する必要があります。収集プロセスは、そのような違法なフロー記録の受領を記録する必要があります。
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の値を持つカウンターは逆方向のない方向に同等であるため、ユニフローをエクスポートすることに注意してください。ただし、このアプローチは、ゼロ値が明確な意味を持つ逆情報要素（たとえば、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やサンプル化物などの範囲と要素としての観測点を備えたオプションを使用して通信できます。
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.
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.
流量測定アプリケーションの多様性と計量プロセスの展開に関する制限により、すべての場合にビフローの方向を割り当てる1つの方法は適用されません。このセクションでは、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によって特定された特定のエクスポートプロセスがイニシエーターによって方向を割り当てていることを構成することができます。または、収集プロセスとエクスポートプロセスの両方を、特定の方向割り当て境界線と同時に構成することができます。ただし、複数の方向選択方法を使用するプロセスのエクスポート、またはさまざまな方法を使用してプロセスからデータを受け入れるプロセスを収集するために、方向割り当て情報のオプションの表現のために二倍方向情報要素が提供されます。
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.
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のように、図2のように、ローカルリンクレイヤーに配置された単一のメータープロセスによって最も簡単に実行されることに注意してください。
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に示すように、測定アプリケーションがネットワーク周辺に展開されている場合、その周辺の「内部」として定義できる安定したアドレスセットがあり、イニシエーターとレスポンダーを決定するための測定アプリケーションの要件がない場合特定の通信の場合、計量プロセスは、biflowソースを境界外のエンドポイントに割り当てる必要があります。
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.
境界線の内部を定義するアドレスセットをエクスポートする施設は提供されていません。このセットは、BiflowソースとBiflowの宛先アドレスのセットを観察する収集プロセス、または帯域外で構成された構成によって推測される場合があります。
+---------+ +---------+
====>+ 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.
測定アプリケーションがネットワークコアに展開されている場合、図5のように、境界線を定義する安定したアドレスセット（たとえば、BGPの更新による）があり、Aのイニシエーターまたはレスポンダーを決定する要件または能力はない場合通信が与えられた場合、計量プロセスはビフローソースとビフローの宛先エンドポイントを任意に割り当てることができます。
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.
上記のように、ビフロウは単一のフローレコードを使用してエクスポートされます。各フローレコードには、フローキーフィールドが1回含まれています。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をこのドキュメントに割り当て、「IPFIX逆情報要素」（リバースペン）を意味するペンを定義します。このリバースペンは、テンプレート内の「逆方向フラグ」として機能します。このペンスペース内の各情報要素番号は、対応するIANAが割り当てられた公開情報要素番号の逆の対応物に割り当てられます。言い換えれば、特定のフォワード情報要素に対応するテンプレート内の逆情報要素を生成するには、以下の図6のように、エンタープライズビットを設定して逆ペンスペース内の情報要素を定義するだけです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
forward | | reverse V
フォワード||逆v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| (rev) flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse PEN 29305 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example Mapping between Forward and Reverse IEs
図6：フォワードと逆のIESの間のマッピングの例
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]の特定の情報要素は可逆的ではないことに注意してください。つまり、それらは逆情報要素として意味的に意味がありません。エクスポートプロセスは、非可逆情報要素の逆の対応物を含むテンプレートをエクスポートしてはなりません。反転不可能な情報要素の逆の対応物を受信する収集プロセスは、その情報要素をフローレコードから破棄する場合があります。非反転情報要素は、Biflowレコード全体のプロパティを表しているか、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).
1. [RFC5102]のセクション5.1で定義されている識別子は、Uniflowコレクションの単一の方向に関連付けられない：FlowID（5.1.7）、TemplateID（5.1.8）、観測ドメニド（5.1.9）、およびCommonPropertiesID（5.1.11）。
2. Process configuration elements defined in Section 5.2 of [RFC5102].
2. [RFC5102]のセクション5.2で定義されているプロセス構成要素。
3. Process statistics elements defined in Section 5.3 of [RFC5102].
3. [RFC5102]のセクション5.3で定義されている統計要素をプロセスします。
4. paddingOctets defined in Section 5.12.1 of [RFC5102].
4. [RFC5102]のセクション5.12.1で定義されているパディングクテット。
5. biflowDirection (defined in Section 6.3 of this document).
5. Biflowdirection（このドキュメントのセクション6.3で定義）。
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.
フローキーとして一般的に使用される情報要素（たとえば、情報モデルのセクション5.4および5.5で定義されているヘッダーフィールド）は、特定のコンテキストで値フィールドとして使用される可能性があるため、ICMPエラーメッセージをフローに関連付ける場合のように、可逆的であることに注意してください。それらを引き起こした。
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.
上記の逆ペンは、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ビットの1つを予約して、逆を意味する可能性があります。方向。たとえば、最も重要なビットが選択された場合、これにより、情報要素IDS 0x0000から0x3fffの逆方向に、情報要素ID 0x4000〜0x7fffを予約します。
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 Information Element SHOULD appear in each Flow Record. This field may take the following values:
説明：ビフローソースと宛先を割り当てるために使用される方向割り当て方法の説明。この情報要素は、フローレコードに存在する場合、またはIPFIXオプションを使用してエクスポートプロセスまたは観測ドメインからエクスポートされるすべてのフローに適用される場合があります。この情報要素がフローレコードに存在しないか、スコープを介してビフロウに関連付けられていない場合、方向割り当て方法の構成は帯域外で行われると想定されます。IPFIXオプションを使用して、この情報要素を観測ドメイン内またはエクスポートプロセスからすべてのフローに適用する場合、オプションは確実に送信する必要があることに注意してください。信頼できる輸送が利用できない場合（つまり、UDPを使用する場合）、この情報要素は各フローレコードに表示されるはずです。このフィールドは次の値をとる場合があります。
+-------+------------------+----------------------------------------+
| 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）は、このドキュメントを「IPFIX Reverse Information Element Private Enterprise」としてこのドキュメントにプライベートエンタープライズ番号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 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.
このドキュメントは、セクション6.3で定義されているように、新しいIPFIX情報要素であるBiFlowDirectionの作成を指定します。IANAは、biflowdirection情報要素のIPFIX情報要素レジストリに情報要素番号239を割り当てました。この情報要素で定義された値は静的であるため、サブレジストリで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.
Lutz Mark、Juergen Quittek、Andrew Johnson、Paul Aitken、Benoit Claise、Carsten Schmollの貢献とコメントに感謝します。Michelle Cottonが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.、ed。、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「IPフロー情報エクスポートの情報モデル」、RFC 5102、2008年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、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. Zander、「IP Flow Information Export（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.、Brownlee、N.、Claise、B。、およびJ. Quittek、「IP Flow Information Exportのアーキテクチャ」、2006年9月に進行中の作業。
[IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", Work in Progress, July 2007.
[Ipfix-as] Zseby、T.、Boschi、E.、Brownlee、N。、およびB. Claise、「Ipfix Applicability」、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] Boschi、E.、Mark、L.、Quittek、J。、Stiemerling、M。、およびP. Aitken、「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.
[IPFIXを減らす] Boschi、E.、Mark、L。、およびB. Claise、「IPフロー情報エクスポート（IPFIX）およびパケットサンプリング（PSAMP）レポートの冗長性の削減」、2007年5月の作業。
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で指定されているビフローレコードについて説明します。逆ペンは、逆情報要素を前方に区別する目的で割り当てられます。
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.
o フローの開始時間：IPFIX情報モデル[RFC5102]のフロースタートセカンド、4オクテットの長さ。
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 Flowの逆開始時間：IPFIX情報モデル[RFC5102]のフロースタートセカンド、4オクテットの長さ、エンタープライズビットは1に設定されています。次のペンは逆ペンです。
o The IPv4 source IP address: sourceIPv4Address in the IPFIX Information Model [RFC5102], with a length of 4 octets.
o IPv4ソースIPアドレス：IPFIX情報モデル[RFC5102]のsoulityIpv4Address、長さ4オクテット。
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 ソースポート：IPFIX情報モデル[RFC5102]のSourcetransportport、2オクテットの長さ。
o The destination port: destinationTransportPort in the IPFIX Information Model [RFC5102], with a length of 2 octets.
o 宛先ポート：IPFIX情報モデル[RFC5102]のDestinationTransportport、2オクテットの長さ。
o The protocol identifier: protocolIdentifier in the IPFIX Information Model [RFC5102], with a length of 1 octet.
o プロトコル識別子：IPFIX情報モデル[RFC5102]のProtocolidentifier、1オクテットの長さ。
o The number of octets of the Flow: octetTotalCount in the IPFIX Information Model [RFC5102], with a length of 4 octets.
o フローのオクテットの数：IPFIX情報モデル[RFC5102]のオクテットタルクアウント、4オクテットの長さ。
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]のオクテットタルクアウント、4オクテットの長さ、エンタープライズビットは1に設定されています。次のペンは逆ペンです。
o The number of packets of the Flow: packetTotalCount in the IPFIX Information Model [RFC5102], with a length of 4 octets.
o フローのパケットの数：IPFIX情報モデル[RFC5102]のPackettotalCount、4オクテットの長さ。
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 フローのパケットの逆数：IPFIX情報モデル[RFC5102]のPackettotalCount、4オクテットの長さ、およびエンタープライズビットは1に設定されています。次のペンは逆ペンです。
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.
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.
次の例は、セクション6.2で指定されているように、IPFIXオプションメカニズムを使用して、特定の観測ドメインで境界方向選択が有効であることを指定する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 観察ドメイン：IPFIX情報モデル[RFC5102]の観察ドメインID、4オクテットの長さ。
o The direction assignment method: biflowDirection as defined in Section 6.2, above, with a length of 1 octet.
o 方向割り当て方法：上記のセクション6.2で定義されている2倍方向に、長さは1オクテットです。
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：Biflow Direction Optionsテンプレートセット
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：ビフロー方向オプションデータセット
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でコード化されたこのドキュメントで定義されている二元化情報要素の機械読み取り可能な説明が含まれています。この付録は情報性の性質であり、セクション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"?>
<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">
<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>
<field name = "biflowdirection" dataType = "unsigned8" datatypesemantics = "識別子" group = "misc" elementid = "239" applicability = "all" status = "current"> <paragraph>指示割り当ての説明Biflowソースと宛先を割り当てるために使用される方法。この情報要素は、フローデータレコードに存在するか、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
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland
Elisa Boschi Hitachi Europe c/o eth zurich gloriastrasse 35 8092チューリッヒスイス
Phone: +41 44 6327057
EMail: elisa.boschi@hitachi-eu.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。