[要約] 要約：RFC 5982は、IPFIXメディエーションの問題を説明しています。IPFIXメディエーションは、ネットワークデバイス間でIPフロー情報を転送するためのプロトコルです。目的：このRFCの目的は、IPFIXメディエーションの問題を明確にし、その解決策を提案することです。
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
IPフロー情報エクスポート（IPFIX）調停：問題声明
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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では、フローベースの測定に関連する一般的な問題を紹介します。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.
このドキュメントでは、フローまたはパケットベースの情報を運ぶレコードのストリームを「レコードストリーム」と呼びます。レコードは、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メディエーターは収集プロセスからレコードストリームを受け取りますが、NetflowV9プロトコル[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メディエーションは、フローまたはパケットベースの情報に適用できます。フローベースの情報は、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フロー情報へのアクセスを提供します。[RFC3917]で定義されている要件に従って、IPFIXエクスポートプロセスから収集プロセスへの測定されたIPフロー情報のエクスポートのアーキテクチャが[RFC5470]で定義されています。IPFIXプロトコル[RFC5101]は、IPFIXデータレコードとテンプレートが、IPFIXのエクスポートプロセスからIPFIXの収集プロセスへの多数のトランスポートプロトコルを介してどのように運ばれるかを指定します。IPFIXには、[RFC5102]で指定されているように、IPFIX情報要素、名前、種類、および追加のセマンティック情報の正式な説明があります。[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/sを超えています。近い将来、[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メディエーターになり、一元化されたアプリケーションにデマンドでデータレコードを再輸出します。さまざまな測定アプリケーションに対処するために、可能な実装の1つは、各レコードがエクスポートされるコレクターを決定する中間プロセスを使用します。より具体的なケースについては、セクション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パケットレポートの相関からの一元配置遅延。たとえば、一元配置遅延は、パケットダイジェストと観測点での到着時間を含む2つの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.
このケースの可能な実装の1つは、メータープロセスと元の輸出業者のエクスポートプロセスの間にある中間プロセス、または元の輸出業者と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.
時間構成は、同一のフローキーを持つ連続したデータレコードの集約として定義されます。これは、元の輸出業者により長いアクティブなタイムアウトを設定するのと同じ出力につながります。1つの利点は、時間間隔を持つフローレコードからの平均、最大値、最小値などの新しいメトリックの作成により、管理者が変更を追跡できるようにすることができます。時間間隔中に起こった可能性があります。
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.
このケースの可能な実装の1つは、メータープロセスと元の輸出業者のエクスポートプロセスの間にある中間プロセス、または元の輸出業者と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の可能な実装の1つは、メータープロセスと元の輸出業者のエクスポートプロセスの間にある中間プロセスを使用します。元の輸出業者と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.
一般に、匿名化はデータセットを変更して、データセットによって記載されている人々またはエンティティのIDを保護して開示されています。また、特定の分析に役立つネットワークトラフィックプロパティのセットを保存しようとし、トラフィックを生成する特定のネットワーク、ホスト、またはユーザーにデータを追跡できないようにします。たとえば、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
o インターネット・アクセス
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を輸送するための帯域幅は限られています。したがって、複数のデータレコードタイプがコレクターにとって興味深いものであっても（たとえば、両方向のIPFIXフローレコード、WAN最適化手法の前後の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.
このケースの可能な実装の1つは、支店にある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メディエーターは顧客ネットワークを特定する必要があります。Route Distinguiseer（RD）、Ingress Interface、Peering Autonomous System（AS）番号、またはBGP Next-Hop、または単にネットワークプレフィックスを評価して、さまざまな顧客ネットワークを区別することができます。次の図では、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
図A. IPFIXメディエーターを使用してコレクターにデータレコードを配布する
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.
このケースの可能な実装の1つは、メータープロセスと元の輸出業者のエクスポートプロセスの間にある中間プロセス、または元の輸出業者と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.
このケースの可能な実装の1つは、レガシープロトコルを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トランスポートセッションのソースIPアドレスとIPFIXメッセージヘッダーに含まれる観測ドメインIDで示される輸出者IPアドレスの両方が、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.
次の図では、コレクターは2つのIPアドレスを識別できます：それぞれ192.0.2.3（IPFIXメディエーター）と192.0.2.2（輸出者＃2）。ただし、コレクターは、元の輸出業者であるExporter＃1とExporter＃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メッセージヘッダーに含まれるエクスポート時間フィールドは、データレコードのリファレンスタイムスタンプを表します。[RFC5102]に記載されている一部のIPFIX情報要素は、エクスポート時間フィールドの値からの時差を示すデルタタイムスタンプを運びます。データレコードにDelta Timeフィールドが含まれており、IPFIXメディエーターがIPFIXメッセージを送信するときにエクスポート時間フィールドを上書きする場合、デルタタイムフィールドは無意味になり、コレクターはこの状況を認識できないため、間違った時間値が伝播されます。
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、輸出者＃2、および輸出者＃1から受信した3つのテンプレート（256、257、および258）をエクスポートします。Export＃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
図C.複数の輸送セッションから単一の輸送セッションへの中継
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コレクターは時間構成と空間組成を区別できません。関数に関連するいくつかのパラメーターもエクスポートする必要があります。たとえば、時間構成の場合、最小/最大カウンターを正しく解釈するには、元のフローレコードのアクティブなタイムアウトが必要です。空間構成の場合、データレコードが集約される空間領域情報が必要です。
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が非キーフィールドとして含まれている場合、アプリケーションに応じて、結果のフローレコードの最初または2番目の観測点で観察された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-out-of-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]のセキュリティに関する考慮事項セクションでカバーされており、IPFIXメディエーターにはまだ有効です。
A measurement system must also prevent the following security threats related to IPFIX Mediation:
測定システムは、IPFIX調停に関連する次のセキュリティの脅威も防ぐ必要があります。
o Attacks against an IPFIX Mediator
o IPFIXメディエーターに対する攻撃
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
o 信頼されていないIPFIXメディエーターによる中間の攻撃
The Exporter-Mediator-Collector structure model could be misused for a man-in-the-middle attack.
Exporter-Mediator-Collector構造モデルは、中間の攻撃で誤用される可能性があります。
o Configuration on IPFIX Mediation
o IPFIXメディエーションの構成
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.
1つの任意のエンドユーザーに関する細かい情報を収集する確率は、観測ポイントの数とともに増加します。このような状況に直面しているIPFIXメディエーターは、生成するデータレコードに適切な機能（匿名化や集約など）を適用する必要がある場合があります。
o Multiple-tenancy policy on an IPFIX Mediator
o IPFIXメディエーターに関する複数のテナンシーポリシー
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メディエーターは、顧客のトラフィックデータを顧客自身の専用IPFIXコレクターにフィードする際に、顧客の識別子、たとえば、イングレスインターフェイスインデックス、ネットワークアドレス範囲、VLAN ID、メディアアクセス制御（MAC）アドレスなどを識別する必要があります。。IPFIXメディエーターが各顧客のトラフィックデータを識別できない場合、データレコードをドロップする必要がある場合があります。さらに、顧客サイトが移動可能である場合、例えば別の物理マシンに移動する仮想マシンの場合、顧客の識別子を追跡する別の手法が必要になる場合があります。
o Confidentiality protection via an IPFIX Mediator
o IPFIXメディエーターを介した機密保護
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コレクターは、元の輸出業者のIDを直接検証することはできません。元の輸出業者と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.
次の人に感謝します。GerhardMuenzは、セクション全体の改善に関する徹底的な詳細なレビューと重要な貢献について。文書の初期段階での貢献については、イスバシケ介。用語と定義セクションの改善に関する貢献については、ブライアン・トラメル。ネビル・ブラウンリー、ジュエルゲン・シェーンワエルダー、モトノリ・シンドは、技術的なレビューとフィードバックをしてくれました。
[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月。
[RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476] Claise、B.、ed。、Johnson、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 Computer Society、「Link Aggregation」、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] Dietz、T.、Ed。、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. Zander、「IP Flow Information Export（IPFIX）の要件」、RFC 3917、2004年10月。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B.、ed。、「Cisco Systems Netflow Services Exportバージョン9」、RFC 3954、2004年10月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、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.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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.、Brownlee、N.、Claise、B。、およびJ. Quittek、「IPフロー情報エクスポートのアーキテクチャ」、RFC 5470、2009年3月。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、Boschi、E.、Brownlee、N。、およびB. Claise、「IP Flow Information Export（IPFIX）Applicability」、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] Duffield、N.、Ed。、Chiou、D.、Claise、B.、Greenberg、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.、Molina、M.、Duffield、N.、Niccolini、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] Dietz、T.、Claise、B.、Aitken、P.、Dressler、F.、およびG. Carle、「パケットサンプリングエクスポートの情報モデル」、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] Trammell、B.、Boschi、E.、Mark、L.、Zseby、T。、およびA. Wagner、「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] Dietz、T.、Ed。、ed。、Kobayashi、A.、Claise、B。、およびG. Muenz、「IPフロー情報エクスポートの管理オブジェクトの定義」、RFC 5815、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] Cho、K.、Fukuda、K.、Esaki、H。、およびA. Kato、「住宅ユーザーからユーザーへのトラフィックの成長の影響と意味」、Sigcomm2006、pp。207-218、Pisa、イタリア、2006年9月。
Contributors
貢献者
Haruhiko Nishida NTT Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan
Haruhiko nisho ntt情報共有プラットフォーム研究所3-9-11 Midori-Cho Musashino-Shi、東京180-8585日本
Phone: +81-422-59-3978
EMail: 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 Erlangen 91058ドイツ
Phone: +49 9131 85-27993
EMail: 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 Erlangen 91058ドイツ
Phone: +49 9131 85-27914
EMail: dressler@informatik.uni-erlangen.de
URI: http://www7.informatik.uni-erlangen.de/~dressler/
Stephan Emile France Telecom 2 Avenue Pierre Marzin Lannion, F-22307 France
ステファンエミールフランステレコム2アベニューピエールマルジンラニオン、F-22307フランス
Fax: +33 2 96 05 18 52
EMail: 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
小林アトシ（編集者）NTT情報共有プラットフォーム研究所3-9-11 Midori-Cho Musashino-Shi、Tokyo 180-8585 Japan
Phone: +81-422-59-3978
EMail: akoba@nttv6.net
Benoit Claise (editor) Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1831 Belgium
Benoit Claise（編集者）Cisco Systems、Inc。de Kleetlaan 6a B1 Diegem 1831ベルギー
Phone: +32 2 704 5622
EMail: bclaise@cisco.com