Internet Engineering Task Force (IETF) A. Kobayashi, Ed.
Request for Comments: 5982 NTT PF Lab.
Category: Informational B. Claise, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
August 2010
IP Flow Information Export (IPFIX) Mediation: Problem Statement
Abstract
抽象
Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IP Flow Information Export (IPFIX) Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then it describes IPFIX Mediation applicability examples along with the problems.
フローベースの測定は、さまざまなネットワーク監視の用途のための一般的な方法です。異なる要件を持つアプリケーションを監視するためのフローベースの情報の共有が決意を助けるかもしれないIPフロー情報のエクスポート（IPFIX）調停測定システムのスケーラビリティ、フローベースの計測の柔軟性、および輸出の信頼性の面でいくつかの未解決の問題を提起します。この文書では、ネットワーク管理者が直面している、そしてそれが問題と一緒にIPFIX仲介の適用例を説明することを測定ベースを流れるように関連するいくつかの問題について説明します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5982.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5982で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology and Definitions .....................................3
3. IPFIX/PSAMP Documents Overview ..................................5
3.1. IPFIX Documents Overview ...................................5
3.2. PSAMP Documents Overview ...................................5
4. Problem Statement ...............................................5
4.1. Coping with IP Traffic Growth ..............................6
4.2. Coping with Multipurpose Traffic Measurement ...............7
4.3. Coping with Heterogeneous Environments .....................7
4.4. Summary ....................................................7
5. Mediation Applicability Examples ................................8
5.1. Adjusting Flow Granularity .................................8
5.2. Collecting Infrastructure ..................................8
5.3. Correlation for Data Records ...............................9
5.4. Time Composition ...........................................9
5.5. Spatial Composition .......................................10
5.6. Data Record Anonymization .................................11
5.7. Data Retention ............................................11
5.8. IPFIX Export from a Branch Office .........................12
5.9. Distributing Data Record Types ............................13
5.10. Flow-Based Sampling and Selection ........................14
5.11. Interoperability between Legacy Protocols and IPFIX ......15
6. IPFIX Mediators' Implementation-Specific Problems ..............15
6.1. Loss of Original Exporter Information .....................15
6.2. Loss of Base Time Information .............................16
6.3. Transport Sessions Management .............................16
6.4. Loss of Options Template Information ......................16
6.5. Template ID Management ....................................17
6.6. Consideration for Network Topology ........................18
6.7. IPFIX Mediation Interpretation ............................18
6.8. Consideration for Aggregation .............................19
7. Summary and Conclusion .........................................20
8. Security Considerations ........................................20
9. Acknowledgements ...............................................21
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................22
Contributors ......................................................24
An advantage of flow-based measurement is that it allows monitoring large amounts of traffic observed at distributed Observation Points. While flow-based measurement can be applied to one of various purposes and applications, it is difficult for flow-based measurement to apply to multiple applications with very different requirements in parallel. Network administrators need to adjust the parameters of the metering devices to fulfill the requirements of every single measurement application. Such configurations are often not supported by the metering devices, either because of functional restrictions or because of limited computational and memory resources, which inhibit the metering of large amounts of traffic with the desired setup. IP Flow Information Export (IPFIX) Mediation fills the gap between restricted metering capabilities and the requirements of measurement applications by introducing an intermediate device called the IPFIX Mediator.
フローベースの計測の利点は、分散型の観測点で観測された大量のトラフィックを監視できることです。フローベースの測定は、様々な目的及び用途のいずれにも適用することができるが、それは並列に非常に異なる要件を持つ複数のアプリケーションに適用するフローベースの測定は困難です。ネットワーク管理者は、すべての単一の測定アプリケーションの要件を満たすために計量装置のパラメータを調整する必要があります。このような構成は、多くの場合、必要なセットアップに大量のトラフィックの計量を阻害し、どちらかのために機能的な制限のため、または限られた計算リソースとメモリリソースの計量装置によってサポートされていません。 IPフロー情報エクスポート（IPFIX）メディエーションはIPFIXメディエータと呼ばれる中間装置を導入することにより制限計量能力と測定アプリケーションの要件との間のギャップを埋めます。
The IPFIX requirements defined in [RFC3917] mention examples of intermediate devices located between Exporters and Collectors, such as IPFIX proxies or concentrators. But, there are no documents defining a generalized concept for such intermediate devices. This document addresses that issue by defining IPFIX Mediation -- a generalized intermediate device concept for IPFIX -- and examining in detail the motivations behind its application.
[RFC3917]で定義されたIPFIX要件は、IPFIXプロキシまたは濃縮などの輸出とコレクターとの間に位置する中間デバイスの例を言及しています。しかし、このような中間デバイス用の一般的な概念を定義する一切の文書はありません。 IPFIXのための一般的な中間デバイスのコンセプト - - そして詳細にそのアプリケーションの背後にある動機を調べる。このドキュメントは、IPFIXの仲介を定義することによって、その問題を解決します。
This document is structured as follows: Section 2 describes the terminology used in this document, Section 3 gives an IPFIX/Packet Sampling (PSAMP) document overview, Section 4 introduces general problems related to flow-based measurement, Section 5 describes some applicability examples where IPFIX Mediation would be beneficial, and, finally, Section 6 describes some problems an IPFIX Mediation implementation might face.
次のようにこのドキュメントが構成されている：第2節は、この文書で使用される用語を説明し、第3 IPFIX /パケットサンプリング（PSAMP）文書の概要を示し、第4の測定ベースのフローに関連する一般的な問題を導入し、第5節では、いくつかの適用例ここに記載しIPFIX調停は有益であろう、そして、最後に、第6節ではIPFIX仲介実装が直面するかもしれないいくつかの問題について説明します。
The IPFIX-specific and PSAMP-specific terminology used in this document is defined in [RFC5101] and [RFC5476], respectively. In this document, as in [RFC5101] and [RFC5476], the first letter of each IPFIX-specific and PSAMP-specific term is capitalized along with the IPFIX Mediation-specific terms defined here.
この文書で使用IPFIX特異的およびPSAMP固有の用語は、それぞれ、[RFC5101]及び[RFC5476]で定義されています。この文書では、[RFC5101]及び[RFC5476]、各IPFIX特異的およびPSAMP固有の用語の最初の文字とは、ここで定義されたIPFIX仲介固有の用語と一緒に大文字にされます。
In this document, we call "record stream" a stream of records carrying flow- or packet-based information. The records may be encoded as IPFIX Data Records or in any other format.
この文書では、「レコードストリーム」flow-またはパケットベースの情報を運ぶレコードのストリームを呼びます。レコードは、IPFIXデータレコードとして、または任意の他の形式でエンコードされてもよいです。
Original Exporter
オリジナル輸出業者
An Original Exporter is an IPFIX Device that hosts the Observation Points where the metered IP packets are observed.
オリジナル輸出業者は、計量されたIPパケットが観測される観測ポイントをホストするIPFIXデバイスです。
IPFIX Mediation
IPFIX調停
IPFIX Mediation is the manipulation and conversion of a record stream for subsequent export using the IPFIX protocol.
IPFIXメディエーションは、IPFIXプロトコルを使用して、後続のエクスポートのレコードストリームの操作および変換です。
The following terms are used in this document to describe the architectural entities used by IPFIX Mediation.
以下の用語は、IPFIXの仲介によって使用される建築エンティティを記述するために、このドキュメントで使用されています。
Intermediate Process
中級プロセス
An Intermediate Process takes a record stream as its input from Collecting Processes, Metering Processes, IPFIX File Readers, other Intermediate Processes, or other record sources; performs some transformations on this stream, based upon the content of each record, states maintained across multiple records, or other data sources; and passes the transformed record stream as its output to Exporting Processes, IPFIX File Writers, or other Intermediate Processes, in order to perform IPFIX Mediation. Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter.
中間処理は、収集プロセス、計量プロセス、IPFIXファイルリーダー、他の中間プロセス、または他のレコードソースからの入力として記録ストリームを取ります。このストリーム上のいくつかの変換を実行し、各レコードの内容に基づいて、複数のレコード、またはその他のデータソースにわたって維持述べて。そしてIPFIX調停を行うために、エクスポートプロセス、IPFIXファイル作家、又は他の中間プロセスにその出力として形質レコードストリームを渡します。典型的には、中間処理は、IPFIXメディエータによってホストされています。代替的に、中間処理は、元の輸出業者によってホストされてもよいです。
IPFIX Mediator
IPFIXのメディエータ
An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation by receiving a record stream from some data sources, hosting one or more Intermediate Processes to transform that stream, and exporting the transformed record stream into IPFIX Messages via an Exporting Process. In the common case, an IPFIX Mediator receives a record stream from a Collecting Process, but it could also receive a record stream from data sources not encoded using IPFIX, e.g., in the case of conversion from the NetFlow V9 protocol [RFC3954] to the IPFIX protocol.
IPFIXメディエータは、いくつかのデータソースからレコード・ストリームを受信し、そのストリームを変換するために、1つの以上の中間プロセスをホストし、エクスポートプロセスを介して、IPFIXメッセージに変換レコード・ストリームをエクスポートすることによってIPFIXメディエーションを提供IPFIXデバイスです。一般的なケースでは、IPFIXメディエータは、収集プロセスからレコード・ストリームを受信し、それはまたへのNetFlow V9プロトコル[RFC3954]からの変換の場合には、符号化された例えばIPFIXを使用していないデータソースからレコード・ストリームを受信することができますIPFIXプロトコル。
Note that the IPFIX Mediator is a generalization of the concentrator and proxy elements envisioned in the IPFIX requirements [RFC3917]. IPFIX Mediators running appropriate Intermediate Processes provide the functionality specified therein.
IPFIXメディエータはIPFIX要件[RFC3917]に想定コンセントレータとプロキシ要素の一般化であることに留意されたいです。適切な中間プロセスを実行IPFIXメディエーターは、その中に指定された機能を提供します。
IPFIX Mediation can be applied to Flow- or packet-based information. The Flow-based information is encoded as IPFIX Flow Records by the IPFIX protocol, and the packet-based information is extracted by some packet selection techniques and then encoded as PSAMP Packet Reports by the PSAMP protocol. Thus, this section describes relevant documents for both protocols.
IPFIX調停はFlow-またはパケットベースの情報に適用することができます。フローベースの情報は、IPFIXプロトコルによってIPFIXフローレコードとしてエンコードされ、そしてパケットベースの情報は、いくつかのパケットの選択技術によって抽出し、PSAMPパケットはPSAMPプロトコルによってレポートとして符号化されます。したがって、このセクションでは、両方のプロトコルに関連する文書を記述しています。
The IPFIX protocol [RFC5101] provides network administrators with access to IP flow information. The architecture for the export of measured IP flow information from an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], per the requirements defined in [RFC3917]. The IPFIX protocol [RFC5101] specifies how IPFIX Data Records and Templates are carried via a number of transport protocols from IPFIX Exporting Processes to IPFIX Collecting Processes. IPFIX has a formal description of IPFIX Information Elements, their names, types, and additional semantic information, as specified in [RFC5102]. [RFC5815] specifies the IPFIX Management Information Base. Finally, [RFC5472] describes what types of applications can use the IPFIX protocol and how they can use the information provided. Furthermore, it shows how the IPFIX framework relates to other architectures and frameworks. The storage of IPFIX Messages in a file is specified in [RFC5655].
IPFIXプロトコル[RFC5101]はIPフロー情報へのアクセスをネットワーク管理者に提供します。収集プロセスにIPFIXエクスポートプロセスからの測定されたIPフロー情報のエクスポートのためのアーキテクチャは、[RFC3917]で定義された要件に従って、[RFC5470]で定義されています。 IPFIXプロトコル[RFC5101]はどのIPFIXデータレコードとテンプレートがIPFIX収集プロセスにIPFIXエクスポートプロセスからのトランスポート・プロトコルの数を介して運ばれる指定します。 IPFIXはIPFIX情報要素、それらの名前、種類、および[RFC5102]で指定したように、追加の意味情報の形式的な記述があります。 [RFC5815]はIPFIX管理情報ベースを指定します。最後に、[RFC5472]はアプリケーションの種類は、IPFIXプロトコルを使用することができるものと、彼らが提供された情報を使用する方法について説明します。また、IPFIXフレームワークが他のアーキテクチャおよびフレームワークの関係を示します。ファイル内のIPFIXメッセージの記憶は、[RFC5655]で指定されています。
The framework for packet selection and reporting [RFC5474] enables network elements to select subsets of packets by statistical and other methods and to export a stream of reports on the selected packets to a Collector. The set of packet selection techniques (Sampling and Filtering) standardized by PSAMP is described in [RFC5475]. The PSAMP protocol [RFC5476] specifies the export of packet information from a PSAMP Exporting Process to a Collector. Like IPFIX, PSAMP has a formal description of its Information Elements, their names, types, and additional semantic information. The PSAMP information model is defined in [RFC5477]. [PSAMP-MIB] describes the PSAMP Management Information Base.
パケット選択及び報告[RFC5474]のためのフレームワークは、統計および他の方法でパケットのサブセットを選択し、コレクタに選択されたパケットのレポートのストリームをエクスポートするネットワーク要素を可能にします。 PSAMPによって標準化パケット選択技術（サンプリング及びフィルタリング）のセットは、[RFC5475]に記載されています。 PSAMPプロトコル[RFC5476]はコレクタにPSAMPエクスポートプロセスからパケット情報のエクスポートを指定します。 IPFIXのように、PSAMPは、その情報要素、それらの名前、種類、および追加の意味情報の形式的な記述があります。 PSAMP情報モデルは、[RFC5477]で定義されています。 [PSAMP-MIB]はPSAMP管理情報ベースについて説明します。
Network administrators generally face the problems of measurement system scalability, Flow-based measurement flexibility, and export reliability, even if some techniques, such as Packet Sampling, Filtering, Data Records aggregation, and export replication, have already been developed. The problems consist of adjusting some parameters of metering devices to resources of the measurement system while fulfilling appropriate conditions: data accuracy, Flow granularity, and export reliability. These conditions depend on two factors.
ネットワーク管理者は、一般的なパケットサンプリング、フィルタリング、データレコードの集約、およびエクスポートの複製など、いくつかの技術は、すでに開発されている場合でも、測定システムのスケーラビリティ、フローベースの計測の柔軟性、および輸出の信頼性の問題に直面しています。粒度、およびエクスポートの信頼性を流れ、データの精度：問題は、適切な条件を満たしつつ、測定システムのリソースへの計量装置のいくつかのパラメータを調整することから成ります。これらの条件は2つの要因に依存します。
o Measurement system capacity: This consists of the bandwidth of the management network, the storage capacity, and the performances of the collecting devices and exporting devices.
O計測システム容量：これは、管理ネットワークの帯域幅、記憶容量、及び収集装置とエクスポートデバイスの性能から成ります。
o Application requirements: Different applications, such as traffic engineering, detecting traffic anomalies, and accounting, impose different Flow Record granularities, and data accuracies.
Oアプリケーションの要件：さまざまなトラフィック・エンジニアリングなどのアプリケーション、トラフィックの異常を検出し、会計、異なるフローレコードの粒度を課し、データ精度。
The sustained growth of IP traffic has been overwhelming the capacities of measurement systems. Furthermore, a large variety of applications (e.g., Quality-of-Service (QoS) measurement, traffic engineering, security monitoring) and the deployment of measurement systems in heterogeneous environments have been increasing the demand and complexity of IP traffic measurements.
IPトラフィックの持続的な成長は、測定システムの能力を圧倒されました。さらに、多様な用途（例えば、サービス品質（QoS）の測定、トラフィックエンジニアリング、セキュリティ監視）と異機種混在環境での測定システムの展開は、IPトラフィック測定の需要と複雑さが増加しています。
Enterprise or service provider networks already have multiple 10 Gb/s links, their total traffic exceeding 100 Gb/s. In the near future, broadband users' traffic will increase by approximately 40% every year according to [TRAFGRW]. When administrators monitor IP traffic sustaining its growth at multiple Exporters, the amount of exported Flow Records from Exporters could exceed the ability of a single Collector.
企業やサービスプロバイダのネットワークは、すでに複数の10 Gb / sのリンク、100 Gb /秒を超える彼らのトラフィックの合計を持っています。近い将来には、ブロードバンドユーザーのトラフィックは、[TRAFGRW]によると、毎年約40％増加します。管理者が複数の輸出でその成長を維持するIPトラフィックを監視する場合、輸出業者からエクスポートされたフローレコードの量は、単一コレクタの能力を超える可能性があります。
To deal with this problem, current data reduction techniques (Packet Sampling and Filtering in [RFC5475], and aggregation of measurement data) have been generally implemented on Exporters. Note that Packet Sampling leads to potential loss of small Flows. With both Packet Sampling and aggregation techniques, administrators might no longer be able to detect and investigate subtle traffic changes and anomalies, as this requires detailed Flow information. With Filtering, only a subset of the Data Records are exported.
この問題に対処するために、現在のデータ低減技術（[RFC5475]におけるパケットのサンプリングとフィルタリング、および計測データの集合）は、一般的に輸出に実装されています。パケットサンプリングが小さいフローの潜在的な損失につながることに注意してください。これは、詳細なフロー情報を必要とするパケットサンプリングおよびアグリゲーション技術の両方を使用すると、管理者は、もはや、微妙なトラフィックの変化や異常を検出し、調査することはできないかもしれません。フィルタリングを使用すると、データレコードのサブセットのみがエクスポートされます。
Considering the potential drawbacks of Packet Sampling, Filtering, and Data Records aggregation, there is a need for a large-scale collecting infrastructure that does not rely on data reduction techniques.
パケットサンプリング、フィルタリング、およびデータレコード凝集の潜在的な欠点を考慮すると、データ削減技術に依存しない大規模な収集インフラストラクチャの必要性があります。
Different monitoring applications impose different requirements on the monitoring infrastructure. Some of them require traffic monitoring at a Flow level while others need information about individual packets or just Flow aggregates.
別の監視アプリケーションは、監視インフラストラクチャ上のさまざまな要件を課します。他の人が個々のパケットに関する情報を必要とするか、単に凝集体を流れながら、それらのいくつかは、フローレベルでのトラフィックの監視を必要とします。
To fulfill these diverse requirements, an Exporter would need to perform various complex metering tasks in parallel, which is a problem due to limited resources. Hence, it can be advantageous to run the Exporter with a much simpler setup and to perform appropriate post-processing of the exported Data Records at a later stage.
これらの多様な要件を満たすために、輸出が原因限られたリソースに問題がある、並行して様々な複雑な計量作業を実行する必要があります。したがって、はるかに簡単なセットアップと輸出を実行すると、後の段階でエクスポートしたデータレコードの適切な事後処理を実行することが有利であり得ます。
Network administrators use IPFIX Devices and PSAMP Devices from various vendors, various software versions, and various device types (router, switch, or probe) in a single network domain. Even legacy flow export protocols are still deployed in current networks. This heterogeneous environment leads to differences in Metering Process capabilities, Exporting Process capacity (export rate, cache memory, etc.), and data format. For example, probes and switches cannot retrieve some derived packet properties from a routing table.
ネットワーク管理者は、単一のネットワークドメイン内のさまざまなベンダー、様々なソフトウェアのバージョン、および様々なデバイスタイプ（ルータ、スイッチ、またはプローブ）からIPFIXデバイスとPSAMPデバイスを使用しています。でも、レガシーフローのエクスポートプロトコルは、まだ現在のネットワークに配置されています。この異機種環境ではプロセス能力（輸出率、キャッシュメモリ、など）、およびデータ・フォーマットのエクスポート、計量プロセスの能力の違いにつながります。例えば、プローブおよびスイッチは、ルーティングテーブルから一部誘導されたパケットのプロパティを取得することができません。
To deal with this problem, the measurement system needs to mediate the differences. However, equipping all collecting devices with this absorption function is difficult.
この問題に対処するために、測定システムは、違いを仲介する必要があります。しかし、この吸収機能をすべて収集デバイスを装備することは困難です。
Due to resource limitations of the measurement system, it is important to use traffic data reduction techniques as early as possible, e.g., at the Exporter. However, this implementation is made difficult by the heterogeneous environment of exporting devices. On the other hand, keeping data accuracy and Flow granularity to meet the requirements of different monitoring applications requires a scalable and flexible collecting infrastructure.
測定システムのリソース制限のために、輸出で、例えば、可能な限り早期に交通データ削減技術を使用することが重要です。しかし、この実装は、エクスポートデバイスの異機種環境によって困難になります。一方、データの正確性を維持し、異なるモニタリング・アプリケーションの要件を満たすために粒度をフローはスケーラブルで柔軟な収集インフラストラクチャを必要とします。
This implies that a new Mediation function is required in typical Exporter-Collector architectures. Based on some applicability examples, the next section shows the limitation of the typical Exporter-Collector architecture model and the IPFIX Mediation benefits.
これは、新しい仲介機能は、典型的な輸出業者、コレクターのアーキテクチャで必要とされることを意味しています。いくつかの適用例に基づいて、次のセクションでは、典型的な輸出コレクタアーキテクチャモデルとIPFIX仲介利点の制限を示します。
The simplest set of Flow Keys is a fixed 5-tuple of protocol, source and destination IP addresses, and source and destination port numbers. A shorter set of Flow Keys, such as a triple, a double, or a single property, (for example, network prefix, peering autonomous system number, or BGP Next-Hop fields), creates more aggregated Flow Records. This is especially useful for measuring router-level traffic matrices in a core network domain and for easily adjusting the performance of Exporters and Collectors.
フローキーの最も単純なセットは、プロトコル、送信元および宛先IPアドレス、送信元および宛先ポート番号の固定5タプルです。そのような（例えば、ネットワークプレフィックス、自律システム番号、またはBGPネクストホップフィールドピアリング）、二重または単一性、三重などのフローキーの短いセット、より集約フローレコードを作成します。これは、コアネットワークドメイン内のルータレベルのトラフィックマトリクスを測定するため、容易に輸出やコレクターのパフォーマンスを調整するために特に有用です。
Implementation analysis:
実装の分析：
Implementations for this case depend on where Flow granularity is adjusted. More suitable implementations use configurable Metering Processes in Original Exporters. The cache in the Metering Process can specify its own set of Flow Keys and extra fields. The Original Exporter thus generates Flow Records of the desired Flow granularity.
この場合の実装はフローの粒度を調整する場所によって異なります。より適切な実装では、オリジナルの輸出で設定可能な計量プロセスを使用します。計量プロセスにおけるキャッシュ・フローは、キーと追加フィールドの独自のセットを指定することができます。オリジナル輸出業者は、このように所望の流れ粒度のフローレコードを生成します。
In the case where a Metering Process hosting no ability to change the Flow Keys in Original Exporters creates Flow Records, or PSAMP Packet Reports, an IPFIX Mediator can aggregate Data Records based on a new set of Flow Keys. Even in the case of a Metering Process hosting this ability, an IPFIX Mediator can further aggregate the Flow Records.
オリジナル輸出にフローキーを変更する機能をホスティングしない計量プロセスは、フローレコード、またはPSAMPパケットレポートを作成する場合には、フローキーの新しいセットに基づいてデータレコードを集約することができますIPFIXのメディエータ。でも、この能力をホスティングしている計量プロセスの場合には、IPFIXのメディエータはさらにフローレコードを集約することができます。
Increasing numbers of IPFIX Exporters, IP traffic growth, and the variety of treatments expected to be performed on the Data Records make it more and more difficult to implement all measurement applications within a single Collector.
IPFIX輸出、IPトラフィックの増加、およびデータレコードに対して実行されることが予想トリートメントの様々な数の増加は、それがますます困難単一コレクター内のすべての測定アプリケーションを実装するために作ります。
Implementation analysis:
実装の分析：
To increase the collecting (e.g., the bandwidth capacity) and processing capacity, distributed Collectors close to Exporters need to be deployed. In such a case, those Collectors would become IPFIX Mediators, re-exporting Data Records on demand to centralized applications. To cope with the variety of measurement applications, one possible implementation uses an Intermediate Process deciding to which Collector(s) each record is exported. More specific cases are described in Section 5.9.
収集（例えば、帯域幅容量）と処理能力を増加させるために、輸出に近い分散コレクターは、展開される必要があります。そのような場合には、これらのコレクターは、集中アプリケーションにオンデマンドでIPFIXメディエーター、再エクスポートデータレコードになるだろう。測定様々なアプリケーションに対応するために、一つの可能な実装は、コレクタ（複数可）は、各レコードがエクスポートされることを決定する中間処理を使用します。より具体的な例は、セクション5.9で説明されています。
The correlation amongst Data Records or between Data Records and metadata provides new metrics or information, including the following.
データレコードの中またはデータレコードとメタデータとの相関関係は、次のような新しいメトリックや情報を提供します。
o One-to-one correlation between Data Records
データレコード間のOは1対1の相関関係
* One-way delay from the correlation of PSAMP Packet Reports from different Exporters along a specific path. For example, one-way delay is calculated from the correlation of two PSAMP Packet Reports, including the packet digest and the arrival time at the Observation Point. This scenario is described in Section 6.2.1.2 of [RFC5475].
* PSAMPパケットの相関関係から、一方向遅延は、特定のパスに沿って異なる輸出業者からの報告します。例えば、一方向遅延はパケットダイジェストと観測点の到着時刻を含む二PSAMPパケットレポートの相関から計算されます。このシナリオは、[RFC5475]のセクション6.2.1.2に記載されています。
* Packet inter-arrival time from the correlation of sequential PSAMP Packet Reports from an Exporter.
*輸出業者からの順次PSAMPパケットレポートの相関からのパケット到着間隔時間。
* Treatment from the correlation of Data Records with common properties, observed at incoming/outgoing interfaces. Examples are the rate-limiting ratio, the compression ratio, the optimization ratio, etc.
*発信/着信インターフェイスで観察共通の特性を有するデータレコードの相関から治療。例には、律速比、圧縮比、最適化率であります
o Correlation amongst Data Records
データレコードの中のOの相関
Average/maximum/minimum values from correlating multiple Data Records. Examples are the average/maximum/minimum number of packets of the measured Flows, the average/maximum/minimum one-way delay, the average/maximum/minimum number of lost packets, etc.
複数のデータレコードを相関から平均/最大/最小値。例は、測定されたフローのパケットの平均値/最大値/最小数、平均値/最大値/最小の一方向遅延、失われたパケットの平均値/最大値/最小数、等です
o Correlation between Data Records and other metadata
データレコードと他のメタデータ間の相関O
Examples are some BGP attributes associated with Data Records, as determined via routing table lookup.
例としては、ルーティングテーブルルックアップを介して決定されるように、いくつかのBGPは、データレコードに関連付けられた属性です。
Implementation analysis:
実装の分析：
One possible implementation for this case uses an Intermediate Process located between the Metering Processes and Exporting Processes on the Original Exporter, or alternatively, a separate IPFIX Mediator located between the Original Exporters and IPFIX Collectors.
この場合の一つの可能な実装は、代わりにオリジナル輸出、または、元の輸出及びIPFIXコレクターとの間に位置する別IPFIXメディエータに計量プロセスおよびエクスポートプロセスの間に位置する中間プロセスを使用します。
Time composition is defined as the aggregation of consecutive Data Records with identical Flow Keys. It leads to the same output as setting a longer active timeout on Original Exporters, with one advantage: the creation of new metrics such as average, maximum, and minimum values from Flow Records with a shorter time interval enables administrators to keep track of changes that might have happened during the time interval.
時間組成物は、同一のフローキーズとの連続したデータレコードの集合として定義されます。それは一つの利点で、オリジナル輸出業者の長いアクティブタイムアウトを設定するのと同じ出力につながる：短い時間間隔でフローレコードから、このような平均値、最大値などの新しい評価指標の作成、および最小値が変化を追跡するために、管理者を可能にします時間間隔の間に起きている可能性があります。
Implementation analysis:
実装の分析：
One possible implementation for this case uses an Intermediate Process located between the Metering Processes and Exporting Processes on the Original Exporter, or alternatively a separate IPFIX Mediator located between the Original Exporters and IPFIX Collectors.
この場合の一つの可能な実装は、計量プロセスおよびエクスポートプロセスオリジナル輸出業者に、あるいはオリジナル輸出及びIPFIXコレクターとの間に位置する別IPFIXメディエータとの間に位置する中間プロセスを使用します。
Spatial composition is defined as the aggregation of Data Records in a set of Observation Points within an Observation Domain, across multiple Observation Domains from a single Exporter, or even across multiple Exporters. The spatial composition is divided into four types.
空間的な組成物は、観測ドメイン内で、単一の輸出業者からの複数の観測ドメイン間で、あるいは複数の輸出を横切る観測ポイントのセットのデータレコードの集合として定義されます。空間構成は、4つのタイプに分けられます。
o Case 1: Spatial composition within one Observation Domain
Oケース1：1観測ドメイン内の空間構成
For example, to measure the traffic for a single logical interface in the case in which link aggregation [IEEE802.3ad] exists, Data Records metered at physical interfaces belonging to the same trunk can be merged.
例えば、リンクアグリゲーションは、[IEEE802.3ad準拠】存在する場合には、単一の論理インタフェースのトラフィックを測定するために、同じトランクに属する物理インターフェイスで計量データレコードをマージすることができます。
o Case 2: Spatial composition across Observation Domains, but within a single Original Exporter
Oケース2：観測ドメイン間での空間構成が、単一オリジナル輸出業者の中
For example, in the case in which link aggregation exists, Data Records metered at physical interfaces belonging to the same trunk grouping beyond the line card can be merged.
例えば、リンクアグリゲーションが存在する場合には、ラインカードを越えて同じトランクグループに属する物理インターフェイスで計量データレコードをマージすることができます。
o Case 3: Spatial composition across Exporters
Oケース3：輸出全体の空間構成
Data Records metered within an administrative domain, such as the west area and east area of an ISP network, can be merged.
データレコードは、ISPネットワークの西地区と東エリアとして、管理ドメイン内に計量マージすることができます。
o Case 4: Spatial composition across administrative domains
Oケース4：管理ドメイン間での空間構成
Data Records metered across administrative domains, such as across different customer networks or different ISP networks, can be merged. For example, a unique Collector knows in which customer network an Exporter exists, and then works out the traffic data per customer based on the Exporter IP address.
データレコードは、別の顧客のネットワークや異なるISPネットワーク全体としての管理ドメイン、全体で計量マージすることができます。例えば、ユニークなコレクターは、顧客のネットワーク輸出業者が存在する知って、その後、輸出業者IPアドレスに基づいて、顧客ごとのトラフィックデータをうまくいきます。
Implementation analysis:
実装の分析：
One possible implementation for cases 1 and 2 uses an Intermediate Process located between the Metering Processes and Exporting Processes on the Original Exporter. A separate IPFIX Mediator located between the Original Exporters and IPFIX Collectors is a valid solution for cases 1, 2, 3, and 4.
ケース1及び2のための一つの可能な実装は、計量プロセスおよび元輸出にエクスポートプロセス間に位置する中間プロセスを使用します。オリジナル輸出業者とIPFIXコレクターとの間に位置する別IPFIXメディエータは、ケース1、2、3、および4のための有効な解決策です。
IPFIX exports across administrative domains can be used to measure traffic for wide-area traffic engineering or to analyze Internet traffic trends, as described in the spatial composition across administrative domains in the previous subsection. In such a case, administrators need to adhere to privacy protection policies and prevent access to confidential traffic measurements by other people. Typically, anonymization techniques enable the provision of traffic data to other people without violating these policies.
管理ドメイン間IPFIX輸出は、前のサブセクションでの管理ドメイン間空間構成で説明したように、広域トラフィックエンジニアリングのためのトラフィックを測定するために、またはインターネットトラフィックの傾向を分析するために使用することができます。そのような場合には、管理者がプライバシー保護ポリシーを遵守し、他の人々によって機密トラフィック測定結果へのアクセスを防止する必要があります。一般的に、匿名化技術は、これらのポリシーに違反することなく、他の人へのトラフィックデータの提供を可能にします。
Generally, anonymization modifies a data set to protect the identity of the people or entities described by the data set from being disclosed. It also attempts to preserve sets of network traffic properties useful for a given analysis while ensuring the data cannot be traced back to the specific networks, hosts, or users generating the traffic. For example, IP address anonymization is particularly important for avoiding the identification of users, hosts, and routers. As another example, when an ISP provides traffic monitoring service to end customers, network administrators take care of anonymizing interface index fields that could disclose any information about the vendor or software version of the Exporters.
一般的に、匿名化が開示されているから、データセットによって記述人またはエンティティのアイデンティティを保護するために設定されたデータを変更します。それはまた、データを確保しつつ、所定の分析に有用なネットワーク・トラフィックの特性のセットを保存しようとするバックトラフィックを生成する特定のネットワーク、ホスト、又はユーザーに追跡することができません。例えば、IPアドレス匿名化は、ユーザ、ホスト、ルータの識別を回避するために特に重要です。 ISPが顧客を終了するトラフィック監視サービスを提供する別の例として、ネットワーク管理者は、輸出のベンダーやソフトウェアのバージョンに関する情報を開示する可能性が匿名インタフェースインデックスフィールドの世話をします。
Implementation analysis:
実装の分析：
One possible implementation for this case uses an anonymization function at the Original Exporter. However, this increases the load on the Original Exporter. A more flexible implementation uses a separate IPFIX Mediator between the Original Exporter and Collector.
この場合の1つの可能な実装は、オリジナル輸出業者で匿名化機能を使用しています。しかし、これはオリジナル輸出業者への負荷が増加します。より柔軟な実装は、オリジナルエクスポータとコレクタとの間に別IPFIXメディエータを使用します。
Data retention refers to the storage of traffic data by service providers and commercial organizations. Legislative regulations often require that network operators retain both IP traffic data and call detail records, in wired and wireless networks, generated by end users while using a service provider's services. The traffic data is required for the purpose of the investigation, detection, and prosecution of serious crime, if necessary. Data retention examples relevant to IP networks are the following:
データ保持は、サービスプロバイダや商業組織によるトラフィックデータのストレージを指します。立法規制は、多くの場合、サービスプロバイダのサービスを利用しながら、有線および無線ネットワークでは、エンドユーザーによって生成され、ネットワークオペレータは、両方のIPトラフィックデータを保持し、詳細レコードを呼び出すことが必要です。必要に応じて、トラフィックデータは、重大な犯罪の捜査、検出、および起訴の目的のために必要とされます。 IPネットワークに関連するデータ保持の例は次のとおりです。
o Internet telephony (includes every multimedia session associated with IP multimedia services)
Oインターネット電話（IPマルチメディア・サービスに関連するすべてのマルチメディアセッションを含みます）
o Internet email
Oインターネット電子メール
o Internet access
お いんてｒねｔ あっせっｓ
Data retention, for these services in particular, requires a measurement system with reliable export and huge storage, as the data must be available for a long period of time, typically at least six months.
データは、典型的には少なくとも6ヶ月、時間の長い期間のために利用可能でなければならないとして、データ保持は、特にこれらのサービスのために、信頼性の高い輸出と巨大なストレージと測定システムを必要とします。
Implementation analysis:
実装の分析：
Regarding export reliability requirement, the most suitable implementation uses the Stream Control Transmission Protocol (SCTP) between the Original Exporter and Collector. If an unreliable transport protocol such as UDP is used, a legacy exporting device exports Data Records to a nearby IPFIX Mediator through UDP, and then an IPFIX Mediator could reliably export them to the IPFIX Collector through SCTP. If an unreliable transport protocol such as UDP is used and if there is no IPFIX Mediator, the legacy exporting device should duplicate the exports to several Collectors to lower the probability of losing Flow Records. However, it might result in network congestion, unless dedicated export links are used.
輸出の信頼性の要件については、最も適切な実装は、オリジナルエクスポータとコレクタ間のストリーム制御伝送プロトコル（SCTP）を使用しています。 UDPのような信頼性のないトランスポートプロトコルを使用する場合は、レガシーエクスポートデバイスは、UDPを通じて近くのIPFIXのメディエータにデータレコードをエクスポートして、IPFIXのメディエータは確実にSCTPを通じてIPFIXコレクタにエクスポートできます。 UDPのような信頼性のないトランスポートプロトコルが使用され、何のIPFIXのメディエータが存在しない場合は、レガシーエクスポートデバイスは、フローレコードを失う確率を下げるために、いくつかのコレクターへの輸出を複製する必要がある場合。専用の輸出リンクが使用されていない限り、しかし、それは、ネットワークの輻輳が発生する場合があります。
Regarding huge storage requirements, the collecting infrastructure is described in Section 5.2.
巨大なストレージ要件については、収集インフラストラクチャーは、セクション5.2に記載されています。
Generally, in large enterprise networks, Data Records from branch offices are gathered in a central office. However, in the long-distance branch office case, the bandwidth for transporting IPFIX is limited. Therefore, even if multiple Data Record types should be of interest to the Collector (e.g., IPFIX Flow Records in both directions, IPFIX Flow Records before and after WAN optimization techniques, performance metrics associated with the IPFIX Flow Records exported at regular intervals, etc.), the export bandwidth limitation is an important factor to pay attention to.
一般的に、大規模な企業ネットワークでは、支社からのデータレコードは、中央オフィスに集まっています。しかし、長距離ブランチオフィスの場合には、IPFIXを輸送するための帯域幅が制限されています。そのため、複数のデータレコードの種類は、などのWAN最適化技術、定期的にエクスポートIPFIXフローレコードに関連したパフォーマンスメトリック、前と後の両方の方向にコレクタ（例えば、IPFIXフローレコード、IPFIXフローレコードを対象としていなければならない場合でも、 ）、輸出帯域幅の制限は、に注意を払うことが重要な要因です。
Implementation analysis:
実装の分析：
One possible implementation for this case uses an IPFIX Mediator located in a branch office. The IPFIX Mediator would aggregate and correlate Data Records to cope with the export bandwidth limitation.
この場合の一つの可能な実装は、ブランチオフィスにあるIPFIXのメディエータを使用しています。 IPFIXのメディエータは、輸出の帯域幅の制限に対処するためにデータレコードを集約し、相関するであろう。
Recently, several networks have shifted towards integrated networks, such as the pure IP and MPLS networks, which include IPv4, IPv6, and VPN traffic. Data Record types (IPv4, IPv6, MPLS, and VPN) need to be analyzed separately and from different perspectives for different organizations. A single Collector handling all Data Record types might become a bottleneck in the collecting infrastructure. Data Records distributed based on their respective types can be exported to the appropriate Collector, resulting in load distribution amongst multiple Collectors.
最近、いくつかのネットワークは、IPv4の、IPv6、およびVPNトラフィックを含め、純粋なIPおよびMPLSネットワークとして統合ネットワークにシフトしています。データレコードの種類（IPv4の、IPv6の、MPLS、およびVPN）別に、異なる組織のための異なる視点から分析する必要があります。すべてのデータレコードの種類を扱う、単一のコレクターは、収集インフラのボトルネックになる可能性があります。それぞれのタイプに基づいて配信されたデータレコードは、複数のコレクターの間で負荷分散をもたらす、適切なコレクタにエクスポートすることができます。
Implementation analysis:
実装の分析：
One possible implementation for this case uses replication of the IPFIX Message in an Original Exporter for multiple IPFIX Collectors. Each Collector then extracts the Data Record required by its own applications. However, this replication increases the load of the Exporting Process and the waste of bandwidth between the Exporter and Collector.
この場合の1つの可能な実装は、複数のIPFIXコレクターのためのオリジナル輸出にIPFIXのメッセージの複製を使用しています。各コレクタは、その後、独自のアプリケーションで必要なデータレコードを抽出します。しかし、この複製は、エクスポート処理の負荷や輸出とコレクタとの間の帯域幅の浪費を増加させます。
A more sophisticated implementation uses an Intermediate Process located between the Metering Processes and Exporting Processes in an Original Exporter. The Intermediate Process determines to which Collector a Data Record is exported, depending on certain field values. If an Original Exporter does not have this capability, it exports Data Records to a nearby separate IPFIX Mediator, and then the IPFIX Mediator could distribute them to the appropriate IPFIX Collectors.
より洗練された実装では、オリジナル輸出業者に計量プロセスとエクスポートプロセスの間に位置する中間プロセスを使用しています。中間プロセスは、コレクタデータレコードが特定のフィールドの値に応じて、エクスポートされていることを決定します。オリジナル輸出業者は、この能力を持っていない場合は、近くの別のIPFIXのメディエータにデータレコードをエクスポートして、IPFIXのメディエータは、適切なIPFIXコレクターに配布できます。
For example, in the case of distributing a specific customer's Data Records, an IPFIX Mediator needs to identify the customer networks. The Route Distinguisher (RD), ingress interface, peering Autonomous System (AS) number, or BGP Next-Hop, or simply the network prefix may be evaluated to distinguish different customer networks. In the following figure, the IPFIX Mediator reroutes Data Records on the basis of the RD value. This system enables each customer's traffic to be inspected independently.
例えば、特定の顧客のデータレコードを配布する場合には、IPFIXのメディエータは、顧客のネットワークを識別するために必要です。ルート識別子（RD）、入力インターフェイスは、ピアリング自律システム（AS）番号、またはBGPネクストホップ、または単にネットワークプレフィックスは、異なる顧客ネットワークを区別するために評価することができます。次の図では、IPFIXのメディエータは、RD値に基づいてデータレコードを再ルーティングします。このシステムは、独立して、検査対象の各顧客のトラフィックを可能にします。
.---------.
|Traffic |
.---->|Collector|<==>Customer#A
| |#1 |
| '---------'
RD=100:1
.----------. .-----------. |
|IPFIX | |IPFIX |----' .---------.
|Exporter#1| |Mediator | RD=100:2 |Traffic |
| |------->| |--------->|Collector|<==>Customer#B
| | | | |#2 |
| | | |----. '---------'
'----------' '-----------' |
RD=100:3
| .---------.
| |Traffic |
'---->|Collector|<==>Customer#C
|#3 |
'---------'
Figure A. Distributing Data Records to Collectors
Using IPFIX Mediator
Generally, the distribution of the number of packets per Flow seems to be heavy tailed. Most types of Flow Records are likely to be small Flows consisting of a small number of packets. The measurement system is overwhelmed with a huge amount of these small Flows. If statistics information of small Flows is exported as merged data by applying a policy or threshold, the load on the Exporter is reduced. Furthermore, if the Flow distribution is known, exporting only a subset of the Data Records might be sufficient.
一般的に、フローごとのパケット数の分布は、重い尾のようです。フローレコードのほとんどのタイプは、少数のパケットからなる小さな流れである可能性が高いです。測定システムは、これらの小さな流れの膨大な量に圧倒されています。小さなフローの統計情報がポリシーまたはしきい値を適用することにより、マージされたデータとしてエクスポートされている場合は、輸出業者への負荷が軽減されます。フロー分布が知られている場合はさらに、データレコードのサブセットのみをエクスポートすることは十分かもしれません。
Implementation analysis:
実装の分析：
One possible implementation for this case uses an Intermediate Process located between the Metering Processes and Exporting Processes on the Original Exporter, or alternatively a separate IPFIX Mediator located between the Original Exporters and IPFIX Collectors. A set of IPFIX Mediation functions, such as Filtering, selecting, and aggregation, is used in the IPFIX Mediator.
この場合の一つの可能な実装は、計量プロセスおよびエクスポートプロセスオリジナル輸出業者に、あるいはオリジナル輸出及びIPFIXコレクターとの間に位置する別IPFIXメディエータとの間に位置する中間プロセスを使用します。このようなフィルタリング、選択、及び凝集などのIPFIX仲介機能のセットは、IPFIXメディエータで使用されています。
During the migration process from a legacy protocol such as NetFlow [RFC3954] to IPFIX, both NetFlow exporting devices and IPFIX Exporters are likely to coexist in the same network. Operators need to continue measuring the traffic data from legacy exporting devices, even after introducing IPFIX Collectors.
そのようなNetFlowのようなレガシープロトコル[RFC3954]からIPFIXへの移行プロセス中、両方のNetFlowエクスポートデバイスとIPFIX輸出業者は、同じネットワークに共存する可能性があります。オペレータはさえIPFIXコレクターを導入した後、レガシーエクスポートデバイスからのトラフィックデータを測定し続ける必要があります。
Implementation analysis:
実装の分析：
One possible implementation for this case uses an IPFIX Mediator that converts a legacy protocol to IPFIX.
この場合の一つの可能な実装は、IPFIXにレガシープロトコルを変換IPFIXメディエータを使用します。
Both the Exporter IP address indicated by the source IP address of the IPFIX Transport Session and the Observation Domain ID included in the IPFIX Message header are likely to be lost during IPFIX Mediation. In some cases, an IPFIX Mediator might drop the information deliberately. In general, however, the Collector must recognize the origin of the measurement information, such as the IP address of the Original Exporter, the Observation Domain ID, or even the Observation Point ID. Note that, if an IPFIX Mediator cannot communicate the Original Exporter IP address, then the IPFIX Collector will wrongly deduce that the IP address of the IPFIX Mediator is that of the Original Exporter.
IPFIXトランスポートセッションと観測ドメインIDの送信元IPアドレスが示す輸出IPアドレスの両方は、IPFIXメッセージヘッダに含まIPFIX仲介中に失われる可能性があります。いくつかのケースでは、IPFIXのメディエータは、故意に情報をドロップする可能性があります。しかし、一般に、コレクターは、オリジナル輸出業者のIPアドレスとして、観測ドメインID、あるいは観察ポイントのIDを測定情報の出所を認識しなければなりません。 IPFIXのメディエータは、オリジナル輸出業者のIPアドレスを伝えることができない場合は、IPFIXコレクターが誤ってIPFIXのメディエータのIPアドレスがオリジナル輸出業者のものであることを推測します、ということに注意してください。
In the following figure, a Collector can identify two IP addresses: 192.0.2.3 (IPFIX Mediator) and 192.0.2.2 (Exporter#2), respectively. The Collector, however, needs to somehow recognize both Exporter#1 and Exporter#2, which are the Original Exporters. The IPFIX Mediator must be able to notify the Collector about the IP address of the Original Exporter.
192.0.2.3（IPFIXメディエータ）と192.0.2.2（輸出＃2）、それぞれ次の図では、コレクタは2つのIPアドレスを識別することができます。コレクターは、しかし、何とかオリジナル輸出されている両方の輸出業者＃1と輸出＃2を、認識する必要があります。 IPFIXのメディエータは、オリジナル輸出業者のIPアドレスについてのコレクターに通知することができなければなりません。
.----------. .--------.
|IPFIX | |IPFIX |
|Exporter#1|--------->|Mediator|---+
| | | | |
'----------' '--------' | .---------.
IP:192.0.2.1 IP:192.0.2.3 '----->|IPFIX |
ODID:10 ODID:0 |Collector|
+------>| |
.----------. | '---------'
|IPFIX | |
|Exporter#2|-----------------------'
| |
'----------'
IP:192.0.2.2
ODID:20
Figure B. Loss of Original Exporter Information
オリジナル輸出情報の図B.損失
The Export Time field included in the IPFIX Message header represents a reference timestamp for Data Records. Some IPFIX Information Elements, described in [RFC5102], carry delta timestamps that indicate the time difference from the value of the Export Time field. If the Data Records include any delta time fields and the IPFIX Mediator overwrites the Export Time field when sending IPFIX Messages, the delta time fields become meaningless and, because Collectors cannot recognize this situation, wrong time values are propagated.
IPFIXメッセージのヘッダに含まれるエクスポートTimeフィールドは、データレコードのための基準タイムスタンプを表します。 [RFC5102]で説明されている一部のIPFIX情報要素は、輸出Timeフィールドの値から時間差を示すデルタタイムスタンプを運びます。データレコードは、任意のデルタ時間フィールドを含むとIPFIXメッセージを送信するときに、IPFIXのメディエータは、エクスポートTimeフィールドを上書きする場合は、デルタ時間フィールドが無意味になると、コレクターはこの状況を認識できないので、間違った時間値が伝播されます。
Maintaining relationships between the incoming Transport Sessions and the outgoing ones depends on the Mediator's implementation. If an IPFIX Mediator relays multiple incoming Transport Sessions to a single outgoing Transport Session, and if the IPFIX Mediator shuts down its outgoing Transport Session, Data Records of the incoming Transport Sessions would not be relayed anymore. In the case of resetting an incoming Transport Session, the behavior of the IPFIX Mediator needs to be specified.
入ってくるトランスポートセッションと発信のものの間の関係を維持することがメディエータの実装に依存します。 IPFIXのメディエータは、単一の発信交通のセッションに複数の着信転送セッションを中継し、IPFIXのメディエータは、その送信交通セッション、入ってくるトランスポートセッションのデータレコードをシャットダウンした場合、もはや中継されない場合。入ってくる交通セッションをリセットする場合は、IPFIXのメディエータの動作を指定する必要があります。
In some cases, depending on the implementation of the IPFIX Mediators, the information reported in the Data Records defined by Options Templates could also be lost. If, for example, the Sampling rate is not communicated from the Mediator to the Collector, the Collector would miscalculate the traffic volume. This might lead to crucial problems. Even if an IPFIX Mediator were to simply relay received Data Records defined by Options Templates, the values of its scope fields could become meaningless in the content of a different Transport Session. The minimal information to be communicated by an IPFIX Mediator must be specified.
いくつかのケースでは、IPFIXメディエーターの実装に応じて、オプションのテンプレートで定義されたデータレコードに報告された情報は失われる可能性があります。例えば、サンプリングレートがコレクタにメディエータから伝達されていない場合、コレクタは、トラフィック量を誤って計算します。これは重要な問題につながる可能性があります。 IPFIXのメディエータは、単にオプションのテンプレートで定義された受信データレコードを中継していたとしても、その範囲フィールドの値は、異なる交通セッションの内容で無意味になる可能性があります。 IPFIXメディエータによって通信される最小限の情報を指定しなければなりません。
The Template ID is unique on the basis of the Transport Session and Observation Domain ID. If an IPFIX Mediator is not able to manage the relationships amongst the Template IDs and the incoming Transport Session information, and if the Template ID is used in the Options Template scope, IPFIX Mediators would, for example, relay wrong values in the scope field and in the Template Withdrawal Message. The Collector would thus not be able to interpret the Template ID in the Template Withdrawal Message and in the Options Template scope. As a consequence, there is a risk that the Collector would then shut down the IPFIX Transport Session.
テンプレートIDは、交通セッションと観測ドメインIDに基づいてユニークです。 IPFIXのメディエータは、テンプレートIDと、着信転送セッション情報の中で関係を管理することができず、そしてテンプレートIDはオプションテンプレートのスコープで使用されている場合、IPFIXメディエーターは、例えば、スコープフィールドに間違った値を中継したい場合やテンプレート無効化メッセージインチコレクターは、このようにテンプレート無効化メッセージにし、オプションテンプレートスコープにテンプレートIDを解釈することはできません。その結果、コレクタはその後、IPFIX交通セッションをシャットダウンしてしまうおそれがあります。
For example, an IPFIX Mediator must maintain the state of the incoming Transport Sessions in order to manage the Template ID on its outgoing Transport Session correctly. Even if the Exporter Transport Session re-initializes, the IPFIX Mediator must manage the association of Template IDs in a specific Transport Session. In the following figure, the IPFIX Mediator exports three Templates (256, 257, and 258), received from Exporter#3, Exporter#2, and Exporter#1, respectively. If Exporter#1 re-initializes, and the Template ID value 258 is now replaced with 256, the IPFIX Mediator must correctly manage the new mapping of (incoming Transport Session, Template ID) and (outgoing Transport Session, Template ID) without shutting down its outgoing Transport Session.
例えば、IPFIXのメディエータは、正しくその発信交通セッションにテンプレートIDを管理するために入ってくるトランスポートセッションの状態を維持しなければなりません。輸出業者交通セッションが初期化を再度場合でも、IPFIXのメディエータは、特定のトランスポートセッションでのテンプレートIDの関連付けを管理しなければなりません。以下の図では、IPFIXメディエータは、3つのテンプレートエクスポート（256、257、および258）はそれぞれ、輸出＃3、輸出＃2、及び輸出＃1から受信しました。輸出業者の＃1の再初期化、およびテンプレートのID値258は現在256に置き換えている場合は、IPFIXのメディエータは、正しくシャットダウンせずに（入ってくる交通セッション、テンプレートID）及び（発信交通セッション、テンプレートID）の新しいマッピングを管理しなければなりませんその出て行く交通セッション。
.----------. OLD: Template ID 258
|IPFIX | NEW: Template ID 256
|Exporter#1|----+
| | |
'----------' X
.----------. | .-----------. .----------.
|IPFIX | '---------->| | | |
|Exporter#2|--------------->|IPFIX |-------------->|IPFIX |
| |Template ID 257 |Mediator |Template ID 258| Collector|
'----------' +---------->| |Template ID 257| |
.----------. | '-----------'Template ID 256'----------'
|IPFIX | |
|Exporter#3|----'
| | Template ID 256
'----------'
Figure C. Relaying from Multiple Transport Sessions
to a Single Transport Session
While IPFIX Mediation can be applied anywhere, caution should be taken as to how to aggregate the counters, as there is a potential risk of double counting. For example, if three Exporters export PSAMP Packet Reports related to the same flow, the one-way delay can be calculated, while summing up the number of packets and bytes does not make sense. Alternatively, if three Exporters export Flow Records entering an administrative domain, then the sum of the packets and bytes is a valid operation. Therefore, the possible function to be applied to Flow Records must take into consideration the measurement topology. The information such as the network topology, or at least the Observation Point and measurement direction, is required for IPFIX Mediation.
IPFIX調停はどこにでも適用できますが、注意がダブルカウントの潜在的なリスクがあるため、カウンターを集約する方法として取られるべきです。 3つの輸出がPSAMPパケットは同じフローに関連するレポートエクスポートする場合のパケットとバイトの数を合計すると、意味がありませんが、例えば、一方向の遅延は、計算することができます。また、もし3つの輸出業者は、フローレコードは、管理ドメインを入力エクスポートし、その後、パケットとバイトの合計は有効な操作です。そのため、レコードをフローに適用される可能性の機能を考慮に測定トポロジを取る必要があります。このようなネットワークトポロジーなどの情報、又は少なくとも観測ポイントと測定方向は、IPFIX調停のために必要とされます。
In some cases, the IPFIX Collector needs to recognize which specific function(s) IPFIX Mediation has executed on the Data Records. The IPFIX Collector cannot distinguish between time composition and spatial composition, if the IPFIX Mediator does not export the applied function. Some parameters related to the function also would need to be exported. For example, in the case of time composition, the active timeout of original Flow Records is required to interpret the minimum/maximum counter correctly. In the case of spatial composition, spatial area information on which Data Records is aggregated is required.
いくつかのケースでは、IPFIXコレクターはIPFIX調停はデータレコード上で実行している特定のどの機能（複数可）を認識する必要があります。 IPFIXのメディエータが適用される関数をエクスポートしない場合はIPFIXコレクターは、時間組成と空間構成を区別することはできません。機能に関連するいくつかのパラメータもエクスポートする必要があります。例えば、時間組成物の場合には、元のフローレコードのアクティブタイムアウトが正しく最小/最大カウンタを解釈する必要があります。空間構成の場合には、データレコードが集約された空間領域情報が必要です。
Whether the aggregation is based on time or spatial composition, caution should be taken regarding how to aggregate non-key fields in IPFIX Mediation. The IPFIX information model [RFC5102] specifies that the value of non-key fields, which are derived from fields of packets or from packet treatment and for which the value may change from packet to packet within a single Flow, is determined by the first packet observed for the corresponding Flow, unless the description of the Information Element explicitly specifies a different semantics.
凝集は、時間や空間構成に基づいているかどうか、注意がIPFIX調停での非キーフィールドを集約する方法については注意が必要です。 IPFIX情報モデル[RFC5102]はパケットのフィールドから、またはパケット処理から派生した値が単一のフロー内のパケットからパケットへ変化し得るためのものである非キーフィールドの値は、最初のパケットによって決定されることを指定します情報要素の記述が明示的に異なる意味を指定しない限り、対応するフローを観察しました。
However, this simple rule might not be appropriate when aggregating Flow Records that have different values in a non-key field. For example, if Differentiated Services Code Point (DSCP) information is to be exported, the following problem can be observed: if two Flows with identical Flow Key values are measured at different Observation Points, they may contain identical packets observed at different locations in the network and at different points in time. On their way from the first to the second Observation Point, the DSCP and potentially some other packet fields may have changed. Hence, if the Information Element ipDiffServCodePoint is included as a non-key field, it can be useful to include the DSCP value observed at either the first or the second Observation Point in the resulting Flow Record, depending on the application.
非キーフィールドに異なる値を持つフローレコードを集約するときしかし、この単純なルールは適切ではないかもしれません。差別化サービスコードポイント（DSCP）情報をエクスポートする場合は、例えば、次のような問題を観察することができる。同じフローキー値を持つ2つのフローが異なる観測点で測定された場合、彼らは異なる場所で観測された、同一のパケットが含まれていてもよいですネットワークと異なる時点で。最初から第2の観察ポイントに向かう途中で、DSCPおよび潜在的にいくつかの他のパケットフィールドが変更されている可能性があります。情報要素ipDiffServCodePointを非キーフィールドとして含まれていれば、従って、用途に応じて、第一又は得られたフローレコード内の第二観測点のいずれかで観察されたDSCP値を含むことが有用であり得ます。
Other potential solutions include removing the Information Element ipDiffServCodePoint from the Data Record when re-exporting the aggregate Flow Record, changing the Information Element ipDiffServCodePoint from a non-key field to a Flow Key when re-exporting the aggregated Flow Record, or assigning a non-valid value for the Information Element to express to the Collector that this Information Element is meaningless.
他の潜在的な解決策は場合、集約フローレコードを再輸出集約フローレコードを再エクスポートする際にフローキーに非キーフィールドから情報要素ipDiffServCodePointを変更する、または非割り当てデータレコードから情報要素ipDiffServCodePointを除去することを含みますこの情報要素は無意味であることをコレクターに表現する情報要素について-valid値。
If Packet Sampling or Filtering is applied, the IPFIX Mediator must report an adjusted PSAMP Configured Selection Fraction when aggregating IPFIX Flow Records with different Sampling rates.
パケットサンプリングやフィルタリングが適用されている場合は異なるサンプリングレートでIPFIXフローレコードを集約するとき、IPFIXのメディエータは調整PSAMP構成された選択画分を報告しなければなりません。
Finally, special care must be taken when aggregating Flow Records resulting from different Sampling techniques such as Systematic Count-Based Sampling and Random n-out-of-N Sampling, for example.
最後に、特別な注意は、例えば系統的カウントベースのサンプリングとランダムN-アウトNサンプリングなどの異なるサンプリング技術から生じるフローレコードを集計する際に注意しなければなりません。
This document describes the problems that network administrators have been facing, the applicability of IPFIX Mediation to these problems, and the problems related to the implementation of IPFIX Mediators. To assist the operations of the Exporters and Collectors, this document demonstrates that there exist various IPFIX Mediation functions from which the administrators may select.
この文書では、ネットワーク管理者が直面している問題は、これらの問題へのIPFIX調停の適用、およびIPFIXメディエーターの実装に関連する問題について説明します。輸出業者やコレクターの動作を支援するために、このドキュメントは、管理者が選択することができ、そこから様々なIPFIX仲介機能が存在することを示しています。
However, there are still some open issues with the use of IPFIX Mediators. These issues stem from the fact that no standards regarding IPFIX Mediation have been set. In particular, the minimum information that should be communicated between Original Exporters and Collectors, the mapping between different IPFIX Transport Sessions, and the internal components of IPFIX Mediators should be standardized.
しかし、IPFIXメディエーターを用いたいくつかの未解決の問題が残っています。これらの問題は、IPFIX調停に関していかなる基準が設定されていないという事実から生じます。具体的には、元の輸出及びコレクター、異なるIPFIXトランスポートセッションの間のマッピング、およびIPFIXメディエーターの内部構成要素間で通信されなければならない最低限の情報が標準化されるべきです。
A flow-based measurement system must prevent potential security threats: the disclosure of confidential traffic data, injection of incorrect data, and unauthorized access to traffic data. These security threats of the IPFIX protocol are covered by the Security Considerations section in [RFC5101] and are still valid for IPFIX Mediators.
フローベースの計測システムは、潜在的なセキュリティの脅威を防ぐ必要があります：機密トラフィックデータの開示、不正なデータの注入、およびトラフィックデータへの不正アクセスを。 IPFIXプロトコルのこれらのセキュリティの脅威は[RFC5101]でのSecurity Considerations部で覆われており、まだIPFIXメディエーターに対して有効です。
A measurement system must also prevent the following security threats related to IPFIX Mediation:
測定システムはまた、IPFIX調停に関連する次のようなセキュリティ上の脅威を防ぐ必要があります。
o Attacks against an IPFIX Mediator
IPFIXのメディエータに対するO攻撃
IPFIX Mediators can be considered as a prime target for attacks, as an alternative to IPFIX Exporters and Collectors. IPFIX Proxies or Masquerading Proxies need to prevent unauthorized access or denial-of-service (DoS) attacks from untrusted public networks.
IPFIXメディエーターはIPFIX輸出やコレクターの代替として、攻撃の主なターゲットとして考えることができます。 IPFIXプロキシまたはマスカレードプロキシは信頼されない公衆ネットワークからの不正アクセスやサービス拒否（DoS）攻撃を防ぐために必要です。
o Man-in-the-middle attack by untrusted IPFIX Mediator
信頼されていないIPFIXのメディエータによってO man-in-the-middle攻撃
The Exporter-Mediator-Collector structure model could be misused for a man-in-the-middle attack.
輸出-メディエータ・コレクターの構造モデルは、man-in-the-middle攻撃のために悪用される可能性があります。
o Configuration on IPFIX Mediation
IPFIX調停のO構成
An accidental misconfiguration and unauthorized access to configuration data could lead to the crucial problem of disclosure of confidential traffic data.
コンフィギュレーション・データへの偶発的な設定ミスや不正アクセスは、機密トラフィックデータの開示の重要な問題につながる可能性があります。
o Unintentional exposure of end-user information
エンドユーザ情報のO意図しない露光
The probability of collecting fine-grained information on one arbitrary end user increases with the number of Observation Points. An IPFIX Mediator facing such a situation may have to apply appropriate functions (e.g., anonymization or aggregation) to the Data Records it produces.
観測点の数を有する任意の一つのエンドユーザー増加にきめ細かい情報を収集する確率。このような状況に直面IPFIXメディエータは、それが生成するデータレコードに適切な機能（例えば、匿名化または凝集）を適用していてもよいです。
o Multiple-tenancy policy on an IPFIX Mediator
IPFIXのメディエータのOマルチテナントポリシー
An IPFIX Mediator handling traffic data from multiple tenants or customers needs to protect those tenants or customers from one another's traffic data. For example, an IPFIX Mediator needs to identify the customer's identifier, e.g., ingress interface index, network address range, VLAN ID, Media Access Control (MAC) address, etc., when feeding the customer's traffic data to a customer's own dedicated IPFIX Collector. If the IPFIX Mediator cannot identify each customer's traffic data, it may need to drop the Data Records. In addition, another technique to keep track of a customer's identifier may be required when customer sites are movable, e.g., in the case of a virtual machine moving to another physical machine.
複数のテナントや顧客からのトラフィックデータを扱うIPFIXのメディエータは、互いのトラフィックデータからそれらのテナントや顧客を保護する必要があります。例えば、IPFIXのメディエータはなど、顧客の識別子、例えば、入力インターフェイスインデックス、ネットワークアドレスの範囲、VLAN ID、メディアアクセス制御（MAC）アドレスを特定する必要があり、お客様専用のIPFIXコレクターに顧客のトラフィックデータを供給する場合。 IPFIXのメディエータは、各顧客のトラフィックデータを識別することができない場合は、データレコードをドロップする必要があるかもしれません。顧客サイトに移動可能である場合に加えて、顧客の識別子を追跡する別の技術は、別の物理マシンに移動する仮想マシンの場合には、例えば、必要とされ得ます。
o Confidentiality protection via an IPFIX Mediator
IPFIXメディエーターを介したO機密保護
To ensure security of Data Records in transit, transport of Data Records should be confidential and integrity-protected, e.g., by using Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC4347]. However, an IPFIX Collector cannot know whether received Data Records are transported as encrypted data between an Original Exporter and an IPFIX Mediator. If this information is required on the IPFIX Collector, it must be encoded in the IPFIX Mediator.
輸送中のデータレコードのセキュリティを確保するために、データレコードの輸送は、トランスポート層セキュリティ（TLS）[RFC5246]またはデータグラムトランスポート層セキュリティ（DTLS）[RFC4347]を使用することにより、例えば、機密性と完全性保護されなければなりません。しかし、IPFIXコレクターは受け取ったデータレコードはオリジナル輸出およびIPFIXのメディエータ間の暗号化データとして転送されているかどうかを知ることはできません。この情報はIPFIXコレクタ上必要な場合は、IPFIXのメディエータでエンコードする必要があります。
o Certification for an Original Exporter
オリジナル輸出業者のためのO認定
An IPFIX Collector communicating via an IPFIX Mediator cannot verify the identity of an Original Exporter directly. If an Original Exporter and an IPFIX Collector are located in different administrative domains, an IPFIX Collector cannot trust its Data Records. If this information is required on the IPFIX Collector, it must be encoded in the IPFIX Mediator.
IPFIXのメディエータを介して通信するIPFIXコレクターは直接オリジナル輸出業者の身元を確認することはできません。オリジナル輸出およびIPFIXコレクタが異なる管理ドメインに配置されている場合は、IPFIXコレクターはそのデータレコードを信頼することはできません。この情報はIPFIXコレクタ上必要な場合は、IPFIXのメディエータでエンコードする必要があります。
We would like to thank the following persons: Gerhard Muenz for thorough, detailed review and significant contributions regarding the improvement of whole sections; Keisuke Ishibashi for contributions during the initial phases of the document; Brian Trammell for contributions regarding the improvement of the Terminology and Definitions section; and Nevil Brownlee, Juergen Schoenwaelder, and Motonori Shindo for their technical reviews and feedback.
我々は、次の人に感謝したいと思います：ゲルハルトMuenzを徹底し、詳細なレビューとセクション全体の改善に関する重要な貢献のために。文書の初期段階での貢献のため圭介石橋。用語と定義セクションの改善に関する貢献のためのブライアン・トラメル。そして彼らの技術的なレビューとフィードバックのためのNevilブラウンリー、ユルゲンSchoenwaelder、および元紀進藤。
[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）プロトコルの仕様"。
[RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476] Claise、B.、編。、ジョンソン、A.、およびJ. Quittek、 "パケットサンプリング（PSAMP）プロトコル仕様"、RFC 5476、2009年3月。
[IEEE802.3ad] IEEE Computer Society, "Link Aggregation", IEEE Std 802.3ad-2000, March 2000.
[IEEE802.3ad準拠] IEEEコンピュータ学会、 "リンクアグリゲーション"、IEEE STDの802.3adの-2000、2000年3月。
[PSAMP-MIB] Dietz, T., Ed., Claise, B., and J. Quittek, "Definitions of Managed Objects for Packet Sampling", Work in Progress, July 2010.
[PSAMP-MIB]ディーツ、T.、エド。、Claise、B.、およびJ. Quittek、 "パケットサンプリングのための管理オブジェクトの定義"、進行、2010年7月ワーク。
[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月。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B.、エド。、 "シスコシステムズのNetFlowサービスエクスポートバージョン9"、RFC 3954、2004年10月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[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月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470] Sadasivan、G.、ブラウンリー、N.、Claise、B.、およびJ. Quittek、RFC 5470、2009年3月 "IPフロー情報のエクスポートのためのアーキテクチャ"。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、ボスキ、E.、ブラウンリー、N.、およびB. Claise、 "IPフロー情報のエクスポート（IPFIX）の適用"、RFC 5472、2009年3月。
[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009.
[RFC5474]ダフィールド、N.編、Chiou、D.、Claise、B.、グリーンバーグ、A.、Grossglauser、M.、およびJ. Rexfordの、 "パケット選択及び報告のための枠組み"、RFC 5474年3月2009。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5475] Zseby、T.、モリーナ、M.、ダッフィールド、N.、ニッコリーニ、S.、およびF. Raspall、 "IPパケットの選択のためのサンプリングとフィルタリング技術"、RFC 5475、2009年3月。
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5477]ディーツ、T.、Claise、B.、エイトケン、P.、ドレスラー、F.、およびG.カール、RFC 5477 "情報モデルパケットサンプリングの輸出について"、2009年3月。
[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, October 2009.
[RFC5655]トラメル、B.、ボスキ、E.、マーク、L.、Zseby、T.、およびA.ワグナー、 "IPフロー情報のエクスポート（IPFIX）ファイルフォーマットの仕様"、RFC 5655、2009年10月。
[RFC5815] Dietz, T., Ed., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 5815, April 2010.
[RFC5815]ディーツ、T.、エド。、小林、A.、Claise、B.、およびG. Muenz、RFC 5815 "IPフロー情報のエクスポートのための管理オブジェクトの定義"、2010年4月。
[TRAFGRW] Cho, K., Fukuda, K., Esaki, H., and A. Kato, "The Impact and Implications of the Growth in Residential User-to-User Traffic", SIGCOMM2006, pp. 207-218, Pisa, Italy, September 2006.
【TRAFGRW】チョ、K.、福田、K.、江崎、H.、およびA.加藤、「衝撃と住宅ユーザ対ユーザのトラフィックの成長の含意」、SIGCOMM2006、PP。207-218、ピサ、イタリア、2006年9月。
Contributors
協力者
Haruhiko Nishida NTT Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan
はるひこ にしだ んっｔ いんふぉｒまちおん しゃりんｇ Ｐぁｔふぉｒｍ ぁぼらとりえｓ ３ー９ー１１ みどりーちょ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
Phone: +81-422-59-3978 EMail: nishida.haruhiko@lab.ntt.co.jp
電話：+ 81-422-59-3978 Eメール：nishida.haruhiko@lab.ntt.co.jp
Christoph Sommer University of Erlangen-Nuremberg Department of Computer Science 7 Martensstr. 3 Erlangen 91058 Germany
コンピュータサイエンス7 Martensstrのエアランゲン・ニュルンベルク課のクリストフ・ソマー大学。 3 91058エアランゲンドイツ
Phone: +49 9131 85-27993 EMail: christoph.sommer@informatik.uni-erlangen.de URI: http://www7.informatik.uni-erlangen.de/~sommer/
電話：+49 9131 85から27993 Eメール：christoph.sommer@informatik.uni-erlangen.de URI：http://www7.informatik.uni-erlangen.de/~sommer/
Falko Dressler University of Erlangen-Nuremberg Department of Computer Science 7 Martensstr. 3 Erlangen 91058 Germany
コンピュータサイエンス7 Martensstrのエアランゲン・ニュルンベルク部門のファルコ・ドレスラー大学。 3エアランゲン91058ドイツ
Phone: +49 9131 85-27914 EMail: dressler@informatik.uni-erlangen.de URI: http://www7.informatik.uni-erlangen.de/~dressler/
電話：+49 9131 85から27914 Eメール：URIをdressler@informatik.uni-erlangen.de：http://www7.informatik.uni-erlangen.de/~dressler/
Stephan Emile France Telecom 2 Avenue Pierre Marzin Lannion, F-22307 France
ステファン・エミール・フランステレコム2アベニューピエールMarzinラニオン、F-22307フランス
Fax: +33 2 96 05 18 52 EMail: emile.stephan@orange-ftgroup.com
ファックス：+33 2 96 05 18 52 Eメール：emile.stephan@orange-ftgroup.com
Authors' Addresses
著者のアドレス
Atsushi Kobayashi (editor) NTT Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan
あつし こばやし （えぢとｒ） んっｔ いんふぉｒまちおん しゃりんｇ Ｐぁｔふぉｒｍ ぁぼらとりえｓ ３ー９ー１１ みどりーちょ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
Phone: +81-422-59-3978 EMail: akoba@nttv6.net
電話：+ 81-422-59-3978 Eメール：akoba@nttv6.net
Benoit Claise (editor) Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1831 Belgium
ブノワClaise（エディタ）は、シスコシステムズ、株式会社デKleetlaan 6aはB1のディーゲム1831ベルギー
Phone: +32 2 704 5622 EMail: bclaise@cisco.com
電話：+32 2 704 5622 Eメール：bclaise@cisco.com