Network Working Group S. Leinen
Request for Comments: 3955 SWITCH
Category: Informational October 2004
Evaluation of Candidate Protocols for
IP Flow Information Export (IPFIX)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification.
このドキュメントは、IPFIXワーキンググループによって作成要件文書に基づいてIPフロー情報のエクスポート（IPFIX）プロトコルのための5つの候補プロトコル、の評価が含まれています。プロトコルは特徴付け広いカテゴリーに分類し、特定の要件に照らして評価されます。最後に、推奨は、IPFIX仕様のための基礎としてのNetFlow V9プロトコルを選択するように構成されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol Summaries . . . . . . . . . . . . . . . . . . . . . . 2
2.1. CRANE. . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Diameter . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. LFAP . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. NetFlow v9 . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Streaming IPDR . . . . . . . . . . . . . . . . . . . . . 6
3. Broad Classification of Candidate Protocols . . . . . . . . . 7
3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Data Representation. . . . . . . . . . . . . . . . . . . 8
3.3. Protocol Flow. . . . . . . . . . . . . . . . . . . . . . 9
4. Item-Level Compliance Evaluation . . . . . . . . . . . . . . . 10
4.1. Meter Reliability (5.1). . . . . . . . . . . . . . . . . 10
4.2. Sampling (5.2) . . . . . . . . . . . . . . . . . . . . . 11
4.3. Overload Behavior (5.3). . . . . . . . . . . . . . . . . 12
4.4. Timestamps (5.4) . . . . . . . . . . . . . . . . . . . . 12
4.5. Time Synchronization (5.5) . . . . . . . . . . . . . . . 12
4.6. Flow Expiration (5.6). . . . . . . . . . . . . . . . . . 13
4.7. Ignore Port Copy (5.9) . . . . . . . . . . . . . . . . . 13
4.8. Information Model (6.1). . . . . . . . . . . . . . . . . 13
4.9. Data Model (6.2) . . . . . . . . . . . . . . . . . . . . 13
4.10. Data Transfer (6.3). . . . . . . . . . . . . . . . . . . 14
5. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Recommendation . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix. A Note on References to the Candidate Protocol
Documents. . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 23
The IP Flow Information Export (IPFIX) Working Group has been chartered to select a protocol for the export of flow information from traffic-observing devices (such as routers or dedicated probes). To this end, an evaluation team was formed to evaluate submitted protocols. Each protocol was represented by an advocate, who submitted a specific evaluation document for the respective protocol against the requirements document [1]. The specification of each protocol was itself available as one or several Internet-Drafts, sometimes referring normatively to documents from outside the IETF.
IPフロー情報のエクスポート（IPFIX）ワーキンググループは、（ルータや専用のプローブとして）トラフィック観測機器からのフロー情報の輸出のためのプロトコルを選択するためにチャーターされました。このため、評価チームは、提出されたプロトコルを評価するために設立されました。各プロトコルは、[1]要件文書に対する各プロトコルの特定の評価文書を提出し提唱によって表されました。各プロトコルの仕様は、時々、IETF外部からドキュメントを規範参照して、1つまたはいくつかのインターネットドラフトとして自身が利用可能でした。
This document contains an evaluation of the submitted protocols with respect to the requirements document, and on a more general level, to the working group charter.
この文書では、要件ドキュメントに、そしてより一般的なレベルで、ワーキンググループ憲章に関して提出されたプロトコルの評価が含まれています。
The following IPFIX candidate protocol submissions were evaluated:
次IPFIX候補プロトコルの提出を評価しました。
o CRANE [7], [8] o Diameter [9], [10] o LFAP [11], [12], [13] o NetFlow v9 [2], [15], [16] o Streaming IPDR [17], [18]
クレーン[7]、[8]直径[9]、[10] LFAP [11]、[12]、[13]のNetFlow V9 [2]、[15]、[16]ストリーミングIPDR [17 ]、[18]
This document uses terminology defined in [1] intermixed with that from submissions to explain the mapping between the two.
この文書は、二つの間のマッピングを説明するために提出から[1]それと混合で定義された用語を使用します。
In the following, each candidate protocol is described briefly, highlighting its specific distinguishing features.
以下に、各候補プロトコルは、その特定の際立った特徴を強調し、簡単に説明します。
XACCT's Common Reliable Accounting for Network Element Protocol Version 1.0 [7][8] is described as a protocol for the transmission of accounting information from "Network Elements" to "mediation" and "business support systems".
ネットワーク要素プロトコルバージョン1.0のためのXACCTの一般的な信頼性の高い会計は、[7] [8]「ネットワーク要素」、「調停」と「業務支援システム」から会計情報の伝送のためのプロトコルとして記述されています。
The exporting side is the CRANE client, the collecting side is the CRANE server. Note that it is the server that is responsible for initiating the connection to the client. A client can have multiple simultaneous connections to different servers for robustness. Each server has an associated priority. A client only exports to the server with the highest priority that is perceived operational.
エクスポート側は回収側がCRANEサーバで、CRANEクライアントです。それはクライアントへの接続を開始する責任があるサーバーであることに注意してください。クライアントは、堅牢性のために別のサーバーへの複数の同時接続を持つことができます。各サーバは、関連付けられた優先度を持っています。クライアントは、動作認識されている最も優先順位の高いサーバにエクスポートされます。
Clients and servers exchange messages over a reliable protocol such as TCP [3] or (preferably) the Stream Control Transmission Protocol (SCTP) [5]. The protocol uses application-layer acknowledgements as an indication of successful processing by the server. Strong authentication or data confidentiality aren't supported by the protocol, but can be supported by lower-layer mechanisms such as IPsec [20] or TLS [21].
TCPのような信頼性の高いプロトコルを介してクライアントとサーバの交換メッセージ[3]又は（好ましくは）ストリーム制御伝送プロトコル（SCTP）[5]。プロトコルは、サーバーが成功した処理の指標としてアプリケーション層の肯定応答を使用します。強力な認証やデータの機密性は、プロトコルによってサポートされていないが、このようなIPsecの[20]またはTLS [21]のように下層機構によって支持することができます。
The protocol is bidirectional over the entire duration of a session. There are 20 different message types. The protocol supports template negotiation, not only at startup but also later on in a session, as well as general status inquiries. There is a separate version negotiation protocol defined over UDP.
プロトコルは、セッションの全期間にわたって双方向です。 20異なるメッセージの種類があります。プロトコルは、テンプレート交渉、起動時にも、後にセッションだけでなく、だけでなく、一般的なステータス問合せをサポートしています。 UDP上で定義された別のバージョン交渉プロトコルがあります。
Data encoding is based on templates. Templates contain "keys" representing items in data records. Clients (exporters) publish templates to servers (collectors). Servers can then select the subset of fields in a template that they are interested in. The client will suppress keys that haven't been selected by the server.
データの符号化は、テンプレートに基づいています。テンプレートには、データレコード内の項目を表す「キー」が含まれています。クライアント（輸出）のサーバ（コレクター）にテンプレートを公開します。サーバはその後、彼らが興味を持っているテンプレート内のフィールドのサブセットを選択することができます。クライアントは、サーバによって選択されていないキーを抑制します。
Data records contain references to template and configuration instances. They also carry sequence numbers (DSNs for Data Sequence Numbers). These sequence numbers can be used to de-duplicate data records that have been delivered multiple times during failover/fail-back in redundant configurations. A "duplicate" bit is set in these situations as a hint for the de-duplication process.
データレコードは、テンプレートとコンフィギュレーションインスタンスへの参照が含まれています。彼らはまた、シーケンス番号（データシーケンス番号のためのDSN）を運びます。これらのシーケンス番号は非重複する冗長構成でのフェイルオーバー/フェイルバック中に複数回配信されたデータレコードを使用することができます。 「複製」ビットは、重複除外プロセスのためのヒントとしてこれらの状況に設定されています。
The encoding of (flow information) data records themselves is very compact. The client (exporter) can choose to send data in big-endian (network byte order) or little-endian format. There are eighteen fixed-size key types, as well as five variable-length string and binary data (BLOB) types.
データ自体を記録する（フロー情報）の符号化は非常にコンパクトです。クライアント（輸出）はビッグエンディアン（ネットワークバイト順）またはリトルエンディアンフォーマットでデータを送信するように選択することができます。 18固定サイズキータイプ、ならびに5可変長ストリングおよびバイナリデータ（BLOB）タイプがあります。
Diameter [9][10] is an evolution of the Remote Authentication Dial In User Service (RADIUS) protocol [22]. RADIUS is widely used to outsource authentication and authorization in dialup access environments. Diameter is a generalized and extensible protocol intended to support Authentication, Authorization and Accounting (AAA) requirements of different applications. Dialup and Mobile IPv4 are examples of such applications defined in the IETF.
直径は、[9] [10]ユーザサービスにおけるリモート認証ダイヤル（RADIUS）プロトコル[22]の進化です。 RADIUSは広く、ダイヤルアップアクセス環境での認証と認可を外部委託するために使用されます。直径は、認証、認可及びアカウンティング（AAA）は、異なるアプリケーションの要件をサポートすることを意図し、一般化及び拡張可能プロトコルです。ダイヤルアップとモバイルIPv4は、IETFで定義されたようなアプリケーションの例です。
Diameter is a peer-to-peer protocol. The base protocol defines fourteen command codes, organized as seven request/response command pairs. Presumably, only a subset of these would be used in a pure IPFIX application. Diameter includes capability negotiation and error notifications. Diameter operates over TCP or (preferred) SCTP. There is a framework for end-to-end security, the mechanisms for which are defined in a separate document. IPsec or TLS can be used to provide authentication or encryption at the underlying layers.
直径は、ピア・ツー・ピア・プロトコルです。基本プロトコルは、7つの要求/応答コマンドのペアとして組織14行のコマンドコードを定義します。おそらく、これらのサブセットのみが純粋IPFIXアプリケーションで使用されるだろう。直径が機能ネゴシエーションとエラー通知が含まれています。直径は、TCPまたは（好ましい）SCTP上で動作します。エンドツーエンドのセキュリティのためのフレームワーク、別の文書で定義されているメカニズムが存在します。 IPSecまたはTLSは、下の層での認証や暗号化を提供するために使用することができます。
Diameter conveys data in the form of attribute/value pairs (AVPs). An AVP consists of eight bytes of header plus the space to store the data, which depends on the data format. There are numerous predefined AVP data formats, including signed and unsigned integer types, each in 32 and 64 bit variants, IPv4 and IPv6 addresses, as well as others. The advocacy document [10] suggests that the predefined data formats IPFilterRule and/or QoSFilterRule could be extended to represent IP Flow Information. Such rules are represented as readable UTF-8 strings. Alternatively, new AVPs could be defined to represent flow information.
直径は、属性/値ペア（AVPの）の形でデータを搬送します。 AVPは、ヘッダとデータのフォーマットに依存データを格納するためのスペースの8バイトから成ります。符号付きおよび符号なし整数型、32ビットおよび64ビットの変異体、IPv4アドレスとIPv6アドレスの各ならびにその他を含む、多数の予め定義されたAVPデータフォーマットがあります。アドボカシー文書[10]は所定のデータフォーマットIPFilterRuleの及び/又はQoSFilterRuleは、IPフロー情報を表現するために拡張することができることを示唆しています。このようなルールが読めるUTF-8文字列として表現されています。また、新しいのAVPは、フロー情報を表すように定義することができます。
LFAP [11][12][13] started out as the "Lightweight Flow Admission Protocol" and was used to outsource shortcut creation decisions on flow-based routers, as well as to provide per-flow statistics. Later versions removed the admission function and changed the name to "Lightweight Flow Accounting Protocol".
LFAP [11] [12] [13]は、「軽量フローアドミッション・プロトコル」としてスタートし、フローベースのルータ上のショートカットの作成の決定を外部委託するだけでなく、フローごとの統計情報を提供するために使用されました。それ以降のバージョンは、入学機能を削除し、「軽量フローアカウンティングプロトコル」に名前を変えました。
The exporter in LFAP is called the Connection Control Entity (CCE), and the collector is the Flow Accounting Server (FAS). These entities communicate with each other over a TCP connection. LFAP knows thirteen message types, including operations for connection management, version negotiation, flow information messages and administrative requests. Authentication and encryption can be provided by IPsec or TLS at lower layers. Additionally, the LFAP protocol itself supports four levels of security using HMAC-MD5 authentication and DES-CBC encryption. Note that DES is now widely regarded as not adequately secure, because its small key size makes brute-force attacks viable.
LFAP中輸出は、接続制御エンティティ（CCE）と呼ばれ、コレクタは、フローアカウンティングサーバ（FAS）です。これらのエンティティは、TCP接続を介して相互に通信します。 LFAPは、情報メッセージと管理要求を流し、接続管理、バージョン交渉のための操作を含む13個のメッセージタイプを、知っています。認証および暗号化は、下位層でIPSecまたはTLSによって提供することができます。また、LFAPプロトコル自体は、HMAC-MD5認証およびDES-CBC暗号化を使用して、セキュリティの4つのレベルをサポートしています。その小さなキーサイズは、ブルートフォース攻撃が実行可能になるため、DESは今や広く、十分に安全ではないとみなされることに注意してください。
A distinguishing feature is that LFAP has two different message types for flow information: A Flow Accounting Request (FAR) message is sent when a new flow is identified at the CCE (meter/exporter). Accounting information is sent later in one or multiple Flow Update Notification (FUN) messages. A collector must match each FUN to a Flow ID previously sent in a FAR.
特徴はLFAPは、フロー情報のための2つの異なるメッセージタイプを有することである：新しいフローがCCE（メートル/輸出）で識別されたときにフローアカウンティング要求（FAR）メッセージが送信されます。会計情報は、一つまたは複数のフローアップデート通知（FUN）メッセージの後半に送信されます。コレクタは以前FARで送信されたフローIDに各FUNと一致する必要があります。
The LFAP document also defines a set of useful statistics about the accounting process. A separate MIB document [14] is provided for management of LFAP entities using SNMP.
LFAP文書はまた、課金処理に関する有用な統計のセットを定義します。別MIB文献[14]はSNMPを使用してLFAPエンティティの管理のために提供されます。
LFAP encodes data in a Type/Length/Value format with four bytes of overhead per data item (two bytes for the type and two bytes for the length field).
LFAPは、データ項目ごとのオーバーヘッドの4バイト（タイプ2バイトと長さフィールドの2バイト）を有するタイプ/長さ/値の形式でデータを符号化します。
NetFlow v9 [2][15] is a generalized version of Cisco's NetFlow protocol. Previous versions of NetFlow, in particular version 5, have been widely implemented and used for the exporting and collecting of IP flow information.
NetFlow V9は、[2] [15] CiscoのNetFlowのプロトコルの一般的なバージョンです。 NetFlowの以前のバージョンは、特定のバージョン5で、広く実装されており、IPフロー情報のエクスポートおよび収集するために用いられます。
NetFlow uses a very simple protocol, with the exporter sending template, options, and data "FlowSets" to the collector. FlowSets are sequences of data records of similar format. NetFlow is the only one of the candidate protocols that works over UDP [4]. Because of the simple unidirectional nature of the protocol, it should be relatively straightforward to add mappings to other transport protocols such as SCTP or TCP.
NetFlowは、輸出がコレクタにテンプレート、オプション、およびデータ「フローセット」を送信すると、非常に単純なプロトコルを使用しています。フローセットは、同様の形式のデータレコードの配列です。 NetFlowは、UDP上で動作候補プロトコルの一つだけ[4]です。そのため、プロトコルの簡単な一方向の性質上、そのようなSCTPまたはTCPなどの他のトランスポートプロトコルにマッピングを追加するのは比較的簡単です。
The use of SCTP to transport NetFlow v9 has been suggested in [16]. The suggested mapping describes how control and data can be mapped to different streams within a single SCTP connection, and suggests that the Partial Reliability extension [23] be used on data streams. In the proposed mapping, the exporter would initiate the connection.
NetFlowのV9を輸送するSCTPの使用は[16]で提案されてきました。提案マッピングは、制御およびデータは、単一のSCTPコネクション内の異なるストリームにマッピングすることができる方法を説明し、部分信頼性延長[23]は、データストリームに対して使用されることを示唆しています。提案されたマッピングでは、輸出は、接続を開始することになります。
NetFlow v9 uses a template facility to describe exported data. The data itself is represented in a compact way using network byte order.
NetFlow V9は、エクスポートされたデータを記述するためのテンプレート機能を使用しています。データ自体は、ネットワークバイト順を使用してコンパクトに表現されます。
Streaming IPDR [17][18] is an application of the Network Data Management-Usage (NDM-U) for IP Services specification version 3.1 [19]. It has been developed by the Internet Protocol Detail Record Organization (IPDR, Inc. or ipdr.org). The terminology used is similar to CRANE's, talking about Service Elements (SEs), mediation systems and Business Support Systems (BSS).
ストリーミングIPDR [17] [18] IPサービス仕様バージョン3.1のネットワークデータ管理・使用法（NDM-U）の適用[19]です。これは、インターネットプロトコルの詳細レコード編成（IPDR、Inc.またはipdr.org）によって開発されました。使用される用語は、CRANEのに似ているサービス要素（SES）、調停システムとビジネスサポートシステム（BSS）の話します。
Streaming IPDR operates over TCP. There is a "Trivial TCP Delivery" mode as well as an "Acknowledged TCP Delivery" or "Reliable Streaming" mode. The latter uses application-layer acknowledgements for increased reliability.
ストリーミングIPDRは、TCP上で動作します。 「簡易TCP配達」モードと同様に「ADIは、TCPの配達」や「信頼性の高いストリーミング」モードがあります。後者は、信頼性を高めるためのアプリケーション層の肯定応答を使用します。
The protocol is basically unidirectional. The exporter opens a connection towards the collector, then sends a header followed by a set of record descriptors. Then it can send "Usage Event" records corresponding to these descriptors until the connection is terminated. New record descriptors can be sent at any time. Messages carry sequence numbers that are used for de-duplication during failover. They are also referenced by application-level acknowledgements when Reliable Streaming is used.
プロトコルは、基本的に一方向です。エクスポータは、コレクタに向かって接続を開き、レコードディスクリプタのセットに続くヘッダを送信します。そして、それは、接続が終了するまで、これらの記述子に対応する「使用状況イベント」レコードを送信することができます。新しいレコード記述子は、いつでも送信することができます。メッセージは、フェールオーバー中に重複排除のために使用されているシーケンス番号を運びます。信頼性の高いストリーミングが使用されているとき、彼らはまた、アプリケーション・レベルの確認応答によって参照されています。
IPDR uses an information modeling technique based on the XML-Schema language [24]. Data can be represented in XML or in a streamlined encoding based on the External Data Representation [25]. XDR forms the basis of Sun's Remote Procedure Call and Network File System protocols, and has proven to be both space- and processing-efficient.
IPDRは、XMLスキーマ言語[24]に基づいて、情報モデリング技術を使用します。データは、外部データ表現に基づいてXMLまたは合理エンコーディングで表すことができる[25]。 XDRはSunのリモートプロシージャコールとネットワークファイルシステムプロトコルの基礎を形成し、省スペースと処理効率の両方であることが判明しました。
In order to evaluate the candidate protocols against the higher-level requirements laid out in the IPFIX Working Group charter, it is useful to group them into broader categories.
IPFIXワーキンググループ憲章にレイアウトされ、より高いレベルの要求事項に対する候補プロトコルを評価するためには、グループより広範なカテゴリにそれらに便利です。
One way to look at the candidate protocols is to study the goals that have directed their respective design. Note that the intention is not to exclude protocols that have been designed with a different class of applications in mind, but simply to better understand the different tradeoffs that distinguish the protocols.
候補プロトコルを見て一つの方法は、それぞれの設計を指示した目標を研究することです。意図は念頭に置いてアプリケーションの異なるクラスで設計されてきたが、単に優れたプロトコルを区別異なるトレードオフを理解するためのプロトコルを除外しないことに注意してください。
Of the candidate protocols, Cisco's NetFlow is the purest example of a highly specialized protocol that has been designed with the sole objective of conveying accounting data from flow-aware routers at high rates. Starting from a fixed set of accounting fields, it has been extended a few times over the years to support additional fields and various types of aggregation in the metering/exporting process.
候補プロトコルの、CiscoのNetFlowは高速で流れを意識したルータから会計データを伝える唯一の目的で設計された専門性の高いプロトコルの最も純粋な例です。会計分野の固定セットから始めて、計量/エクスポートプロセスでの追加フィールドと集計の様々なタイプをサポートするために、長年にわたって数回延長されました。
Riverstone's LFAP is similarly focused, except that it originated in a protocol to outsource the decision whether to create shortcuts in flow-based routers. This is still manifest in an increased emphasis on reliable operation, and in the split reporting of flow information using Flow Accounting Request (FAR) and Flow Update Notification (FUN) messages.
リバーストーンのLFAPも同様に、それはフローベースのルータにショートカットを作成するかどうかの決定を外部委託するためのプロトコルで始まったことを除いて、集中しています。これは、信頼性の高い動作に増加重点であり、フローアカウンティング要求（FAR）とフローアップデート通知（FUN）メッセージを使用してフロー情報の分割の報告では、まだ明らかです。
It has been pointed out that split reporting as done by LFAP can reduce memory requirements at the exporter. This concerns a subset of attributes that are neither "key" attributes which define flows, nor attributes such as packet or byte counters that must be updated for each packet anyway. On the other hand, when there are many short-lived flows, the number of flow export messages will be significantly higher than with "unitary" flow export models, and the collector will have to keep state about active flows until they are terminated.
これは、輸出国でのメモリ要件を減らすことができますLFAPによって行われるよう報告その分割を指摘されています。これは、フローを定義でもない「キー」属性である属性のサブセットに関する、また、そのようなとにかくパケットごとに更新されなければならないパケットまたはバイトカウンタとしての属性。一方、多くの短命のフローが存在する場合には、フローエクスポートメッセージの数は、「一体型」の流れ輸出モデルと比べて有意に高くなり、コレクタは、彼らが終了するまでアクティブなフローについての状態を維持する必要があります。
Streaming IPDR and CRANE describe themselves as protocols to facilitate the reliable transfer of accounting information between Network Elements (or more generally "Service Elements" in the case of IPDR) and Mediation Systems or Business Support Systems (BSS). They reflect a view of the accounting problem and of network system architectures that originates in traditional "vertically integrated" telecommunications.
プロトコルはネットワーク・エレメント（またはより一般的にIPDRの場合は、「サービス要素」）と仲介システムやビジネスサポートシステム（BSS）との間での会計情報の信頼性の高い転送を容易にするためにとしてストリーミングIPDRとCRANEは自分自身を記述します。彼らは、会計上の問題の、伝統的な「垂直統合型」の通信に起因するネットワーク・システム・アーキテクチャの見解を反映します。
Both protocols also emphasize extensibility with the goal of applicability to a wide range of accounting tasks.
どちらのプロトコルも、会計業務の広い範囲への適用を目的とした拡張性を強調する。
IPDR is based on NDM-U, which uses the XML-Schema language for machine-readable specification of accounting data structures, while using the efficient XDR encoding for the actual data transfer.
IPDRは、実際のデータ転送のための効率的なXDR符号化を使用しながら、会計データ構造の機械読み取り可能な仕様のXMLスキーマ言語を使用NDM-U、に基づいています。
CRANE uses templates to describe exported data. These templates are negotiated between collector and exporter and can change during a session.
CRANEは、エクスポートされたデータを記述するためのテンプレートを使用しています。これらのテンプレートは、コレクタと輸出国の間で交渉され、セッション中に変更することができます。
Diameter is another example of a broader-purpose protocol, in that it covers aspects of authentication and authorization as well as accounting. This explains its strong emphasis on security and reliability. The design also takes into account various types of intermediate agents.
それは認証および承認ならびに会計の側面を覆うことで直径が、より広範な目的のプロトコルの別の例です。これは、セキュリティと信頼性への重視を説明しています。デザインも考慮に中間物質の様々なタイプを取ります。
IPFIX is intended to be deployed, among others, in high-speed routers and to be used for exporting detailed flow data at high flow rates. Therefore it is useful to look at the tradeoffs between the efficiency of data representation and the extensibility of data models. The two main efficiency goals should be (1) to minimize the export data rate and (2) to minimize data encoding overhead in the exporter. The overhead of decoding flow data at the collector is deemed less critical, and is partly covered by efficiency target (2), since an encoding that is easy on the encoder is often also easy on the decoder.
IPFIXは、高速ルータに、とりわけ、配備されることが意図され、高流量での詳細なフローデータをエクスポートするために使用されます。したがって、データ表現の効率とデータモデルの拡張性の間のトレードオフを見ることが有用です。二つの主な効率目標は、（1）エクスポートデータレートを最小にするために、（2）輸出におけるデータ符号化オーバーヘッドを最小限に抑えるためであるべきです。コレクタの復号フローデータのオーバーヘッドはそれほど重要とみなされ、エンコーダに容易である符号化はまた、しばしば、デコーダに容易であるため、部分的に、効率のターゲット（2）で覆われています。
The protocols in this group use an external mechanism to fully describe the format in which flow data is encoded. The mechanisms are "templates" in the case of CRANE and NetFlow, and a subset of the XML-Schema language, or alternatively XDR IDL, for IPDR.
このグループのプロトコルとは、エンコードされたデータフローの完全フォーマットを記述するために外部メカニズムを使用します。メカニズムはIPDRクレーンとNetFlowの場合には「テンプレート」、およびXMLスキーマ言語のサブセット、あるいはXDR IDLです。
A fully external data format description allows for very compact encoding, with data components such as 32-bit integers taking up only four octets. The XDR representation used in IPDR additionally ensures that larger fields are always aligned on 32-bit boundaries, which can reduce processing requirements at both the exporter and the collector, at a slight cost of space (thus bandwidth) due to padding.
完全外部データフォーマット記述は、32ビット整数としてデータ成分のみ4つのオクテットを占有して、非常にコンパクトな符号化を可能にします。 IPDRに使用XDR表現はさらにによるパディングに空間のわずかなコスト（したがって帯域幅）で、輸出及びコレクタの両方で処理要件を低減することができる、より大きなフィールドが常に32ビット境界で整列されることを確実にします。
Most protocols specify "network byte order" or "big-endian" format in the export data format. CRANE is the only protocol where the exporter may choose the byte ordering. The principal benefit is that this lowers the processing demand on exporters based on little-endian architectures.
ほとんどのプロトコルは、エクスポートデータフォーマットの「ネットワークバイト順序」または「ビッグエンディアン」形式を指定します。 CRANEは、輸出がバイト順序を選択することが唯一のプロトコルです。主な利点は、これはリトルエンディアンアーキテクチャに基づいて輸出業者の処理需要を低下させることです。
Diameter and LFAP represent flow data using Type/Length/Value encodings. While this makes it possible to partly decode flow data without full context information - possibly useful for debugging - it does increase the encoding size and thus the bandwidth requirements both on the wire and in the exporter and collector.
直径とLFAPは、タイプ/長さ/値のエンコーディングを使用してフローデータを表します。デバッグのためにおそらく有用 - - これは、部分的に完全なコンテキスト情報なしフローデータを復号することを可能にしながら、それがワイヤ上および輸出業者とコレクタの両方の符号化サイズ、したがって帯域幅要件を増加し。
LFAP has a "multi-record" encoding which claims to provide similar wire efficiency as the externally described encodings while still supporting diagnostic tools.
LFAPはまだ診断ツールをサポートしながら外部記述符号化と同様のワイヤ効率を提供すると主張「マルチレコード」エンコーディングを有しています。
Another criterion for classification is the flow of protocol messages between exporter and collector.
分類のための別の基準は、エクスポータとコレクタとの間のプロトコルメッセージの流れです。
In IPDR and NetFlow, the data flow is essentially from exporter to collector, with the collector only sending acknowledgements. The protocols send data descriptions (templates) on session establishment, and then start sending flow export data based on these templates. "Meta-information" about the operational status of the metering and exporting processes (for example about the sampling parameters in force at a given moment) is conveyed using a special type of "Option" template in NetFlow v9. IPDR currently doesn't have definitions for such "meta-data" types, but they could easily be defined outside the protocol proper.
IPDRとNetFlowでは、データ・フローは、コレクタのみ肯定応答を送信することと、輸出からコレクタに本質的です。プロトコルは、セッション確立にデータ記述（テンプレート）を送信した後、これらのテンプレートに基づいて、フローのエクスポートデータの送信を開始します。 （所与の瞬間における力のサンプリングパラメータについて例えば）計量およびエクスポートプロセスの動作ステータスに関する「メタ情報」のNetFlow V9の「オプション」テンプレートの特殊なタイプを使用して搬送されます。 IPDRは現在、「メタデータ」タイプの定義はありませんが、彼らは簡単に適切なプロトコル外で定義することができます。
CRANE allows for negotiation of the templates used for data export at the start of a session, and also allows negotiated template updates later on. CRANE sessions include an exporter and potentially several collectors, so these negotiations can involve more than two parties.
CRANEは、セッションの開始時にデータのエクスポートに使用するテンプレートの交渉を可能にし、また交渉したテンプレートの更新後にできます。 CRANEセッションは、輸出国と潜在的にいくつかのコレクターが含まれるので、これらの交渉は、二つ以上の当事者が関与することができます。
LFAP has an initial phase of version negotiation, followed by a phase of "data negotiation". After these startup phases, the exporter sends FAR and FUN messages to the collector. However, either party may also send Administrative Request (AR) messages to the other, and will normally receive Administrative Request Answers (ARA) in response. Administrative Requests can be used for status inquiries, including information about a specific active flow, or for negotiation of the "Information Elements" that the collector wants the exporter to export.
LFAPは、「データのネゴシエーション」の段階が続くバージョン交渉の初期段階を、持っています。これらのスタートアップ段階の後、輸出はコレクタにFARとFUNメッセージを送信します。しかし、いずれかの当事者は、他に管理要求（AR）メッセージを送信することができ、通常は応答して管理要求の回答（ARA）を受け取ります。管理要求は、特定のアクティブフローに関する情報、またはコレクタが輸出をエクスポートしたいことを「情報要素」の交渉を含め、ステータス問合せのために使用することができます。
Diameter has a general capabilities negotiation mechanism. The use of Diameter for IPFIX hasn't been described in sufficient detail to determine how capabilities negotiation would be used. After negotiation, the protocol would operate in essentially unidirectional mode, with Accounting-Request (ACR) messages flowing from the exporter to the collector, and Accounting-Answer (ACA) messages flowing back.
直径は、一般的な能力交渉機構を有しています。 IPFIXのための直径を使用することは、能力ネゴシエーションが使用される方法を決定するために十分に詳細に記載されていませんでした。ネゴシエーション後、プロトコルは、アカウンティング要求（ACR）メッセージがコレクタに輸出から流れる、およびアカウンティング回答（ACA）メッセージが逆流して、本質的に単方向モードで動作します。
The template for protocol advocates noted that not all requirements in [1] apply directly to the flow export protocol. In particular, sections 4 (Distinguishing Flows) and 5 (Metering Process) mainly specify requirements on the metering mechanism that "feeds" the exporter. However, in some cases they require information about the metering process to be reported to collectors, so the flow export protocol must support conveying this information.
プロトコルの支持者のためのテンプレートは、[1]内のすべての要件は、フローエクスポートプロトコルに直接適用されないことに注意しました。特に、セクション4（区別フロー）及び5（計量プロセス）は、主に輸出を「フィード」計量機構上の要件を指定します。しかし、いくつかのケースでは、彼らはコレクターに報告されるように計量プロセスに関する情報を必要とするので、フローエクスポートプロトコルは、この情報を伝えるサポートしている必要があります。
CRANE, Diameter, IPDR consider requirement 5.1 (reliability of the metering process or indication of "missing reliability") out of scope for the IPFIX protocol, which presumably means that they assume the metering process to be reliable.
クレーンは、直径がIPDRは、おそらく、彼らが信頼できると計量プロセスを想定することを意味する要件5.1 IPFIXプロトコルの範囲外（計量工程または「欠落信頼性」の指標の信頼性）を考えます。
The NetFlow v9 advocacy document takes a similar stance when it claims "Total Compliance. The metering process is reliable." (although this has been documented not to be true for all current Cisco implementations of NetFlow v5).
それは主張したときのNetFlow V9擁護文書は、同様の立場をとる「トータルコンプライアンスを。計量プロセスが信頼性があります。」 （が、これは、NetFlow v5のすべての現在のシスコの実装のために真ではないことが立証されています）。
LFAP is the only protocol that explicitly addresses the possibility that data might be lost in the metering process, and provides useful statistics for the collectors to estimate, not just the amount of flow data that was lost, but also the amount of data that was not unaccounted for.
LFAPは、明示的にデータが計量過程で失われるかもしれないという可能性に対処する唯一のプロトコルであり、コレクターは、だけでなく、失われたフローデータの量だけでなく、できなかったデータの量を推定するための便利な統計情報を提供します行方不明で。
Note that in the general case, it can be considered unrealistic to assume total reliability of a flow-based metering process in all situations, unless sampling or coarse flow definitions are used. With the fine-grained flow classification mechanisms mandated by IPFIX, it is easy to imagine traffic where each - possibly very small - packet would create a new flow. This kind of traffic is in fact encountered in practice during aggressive port scans, and will eventually lead to table overflows or exceeding of memory bandwidth at the meter.
サンプリングまたは粗いフロー定義が使用されていない限り、一般的なケースでは、すべての状況でフローベースの計量工程の総信頼性を仮定することは非現実的と考えることができることに留意されたいです。おそらく非常に小さい - - パケット新しいフローを作成しますIPFIXで義務付けられてきめ細かいフロー分類メカニズムと、それぞれのトラフィックを想像するのは容易です。トラフィックのこの種の積極的なポートスキャン中に、実際に発生した事実であり、そして最終的には、テーブルのオーバーフローにつながるかメートルでメモリ帯域幅を超過します。
While some of these situations can be handled by dropping data later on in the exporter, data transfer, or collector, or by transitioning the meter to sampling mode (or increasing the sampling interval), it will sometimes be considered the lesser evil to simply report on the data that couldn't be accounted for. Currently LFAP is the only protocol that supports this.
これらの状況のいくつかは、輸出、データ転送、又はコレクタに、またはサンプリングモード（またはサンプリング間隔を増加させる）にメーターを移行することによって、後にデータをドロップすることによって扱うことができるが、それは単に報告するために、より少ない悪考えます計上することができなかったデータに。現在、LFAPはこれをサポートする唯一のプロトコルです。
CRANE and IPDR don't mention the possibility of sampling. This is natural because they are targeted towards telco-grade accounting, where sampling would be considered inadmissible. Since support for sampling is a "MAY" requirement, its lack could be tolerated, but severely restricts the applicability of these protocols in places of high aggregation, where absolute precision is not necessary. This includes applications such as traffic profiling, traffic engineering, and large-scale attack/intrusion detection, but also usage-based accounting applications where charging based on sampling is agreed upon.
CRANEとIPDRは、サンプリングの可能性を言及していません。彼らは、サンプリングが許容できないと見なされる電話会社グレードの会計、をターゲットにしているので、これは自然なことです。サンプリングのサポートは、「MAY」の要件であるので、その欠如は許容ますが、深刻な絶対的な精度を必要としない高集約の場所でこれらのプロトコルの適用性を制限することができます。これは、トラフィックプロファイリング、トラフィックエンジニアリング、および大規模な攻撃/侵入検知などのアプリケーションが、また、サンプリングに基づく充電が合意されている使用量ベースのアカウンティングアプリケーションを含んでいます。
The Diameter advocate acknowledges the existence of sampling and suggests to define new (grouped) AVPs to carry information about the sampling parameters in use.
直径提唱者は、サンプリングの存在を認識し、使用中のサンプリング・パラメータに関する情報を搬送するために新しい（グループ化）AVPを定義することを示唆しています。
LFAP does not currently support sampling, although its advocate contends that adding support for this would be relatively straightforward, without going into too much detail.
その提唱者は、あまり詳細に行くことなく、このためのサポートを追加することが比較的簡単だろうと主張しているが、LFAPは現在、サンプリングをサポートしていません。
NetFlow v9 does support sampling (and many implementations and deployments of sampled NetFlow exist for previous NetFlow versions). Option Data is supposed to convey sampling configuration, although no sampling-related field types have yet been defined in the document.
NetFlow V9サンプリングをサポートしない（そしてサンプルNetFlowの多くの実装と展開は、以前のNetFlowのバージョンのために存在します）。何のサンプリングに関連したフィールドタイプがまだ文書で定義されていないが、オプションデータは、サンプリング構成を伝えることになっています。
The requirements document suggests that meters adapt to overload situations, for example by changing to sampling (or reducing the sampling rate if sampling is already in effect), by changing the flow definition to coarser flow categories (thinning), by stopping to meter, or by reducing packet processing.
要件文書は、サンプリング（又はサンプリングが有効に既にある場合、サンプリングレートを低下させる）に変更することにより、粗いフローカテゴリ（間引き）にフロー定義を変更することにより、メータに停止させることにより、例えば、メートル状況を過負荷に適応させることを示唆している、またはパケット処理を減らすことによって。
In these situations, the requirements document mandates that flow information from before the modification of metering behavior can be cleanly distinguished from flow information from after the modification. For the suggested mitigation methods of sampling or thinning, this essentially means that all existing flows have to be expired, and an entirely new set of flows must be started. This is undesirable because it causes a peak of resource usage in an already overloaded situation.
このような状況では、計量動作の変更前からの情報を流し要件文書の義務は、変更後からのフロー情報からきれいに区別することができます。サンプリングや間伐の提案緩和方法については、これは基本的にすべての既存のフローが期限切れしなければならないことを意味し、流れの全く新しいセットを開始する必要があります。それはすでに過負荷の状況でリソース使用量のピークが発生するので、これは望ましくありません。
LFAP and NetFlow claim to handle this requirement, both by supporting only the simple overload mitigation methods that don't require the entire set of existing flows to be expired. The NetFlow advocate claims that the reporting requirement could be easily met by expiring existing flows with the old template, while sending a new template for new flows. While it is true that NetFlow handles this requirement in a very graceful manner, the general performance issue remains.
LFAPとのNetFlow請求が期限切れするために、既存のフローのセット全体を必要としない単純な過負荷を軽減する方法をサポートすることにより、両方の、この要求を処理します。新しいフローのための新しいテンプレートを送信中のNetFlow提唱者は、古いテンプレートを使用して流れて報告要件を簡単に既存の期限切れによって満たされることができると主張しています。それはNetFlowが非常に優雅な方法で、この要件を取り扱うことは事実ですが、一般的なパフォーマンスの問題が残っています。
CRANE, Diameter, and IPDR consider the requirement out of scope for the protocol, although Diameter summarily acknowledges the possible need for new AVP definitions related to mitigation methods.
直径が即決軽減する方法に関連する新しいAVPの定義のための可能な必要性を認めるもののCRANE、直径、およびIPDRは、プロトコルの範囲外の要件を検討してください。
All protocols support reporting of timestamps with the required (one centisecond) or better precision.
すべてのプロトコルのサポートに必要な（1センチ）とタイムスタンプの報告や、より良い精度。
While all other protocols have timestamp types that are relative to a well-known reference time, timestamps in NetFlow are reported relative to the sysUpTime of the exporting device. For applications that require the absolute start/end times of flows, this means that exporter sysUpTime has to be matched with absolute time. Although every NetFlow export packet header contains a "UNIX Secs" field, it cannot be used for UTC synchronization without loss of precision, because this field only has 1-second resolution.
他のすべてのプロトコルは、周知の基準時間に対して相対的タイムスタンプの種類を有するが、NetFlowの中のタイムスタンプは、エクスポートデバイスのsysUpTimeに対して報告されています。フローの絶対開始/終了時間を必要とするアプリケーションの場合、これは輸出のsysUpTimeは絶対時間と一致しなければならないことを意味します。すべてのNetFlowエクスポートパケットのヘッダが「UNIX秒数」フィールドを含んでいるが、このフィールドのみ1秒の分解能を有するので、それは、精度を損なうことなくUTC同期のために使用することができません。
As currently specified, this requirement concerns the metering process only and has no bearing on the export protocol.
現在指定されているように、この要件は計量工程に関するおよびエクスポートプロトコルとは関係ありません。
If it is desired to export the reason for flow expiration (e.g., inactivity timeout, active flow timeout, expiration to reclaim resources, or observation of a flow termination indication such as a TCP FIN segment), then none of the protocols currently supports this, although each could be extended to do so.
それは、フローの有効期限の理由（例えば、非活動タイムアウト、アクティブフロータイムアウト、リソースを再利用する期限、あるいはそのようなTCP FINセグメントとしてフロー終了指示の観察）をエクスポートすることが望まれる場合には、プロトコルのどれも現在これをサポートしていません、それぞれがそうするように拡張することができます。
This requirement only concerns the metering process and has no bearing on the export protocol.
この要件は計量工程に関するおよびエクスポートプロトコルとは関係ありません。
All candidate protocols have information models that can represent all required and all optional attributes. The Diameter contribution lacks some detail on how exactly the IPFIX-specific attributes should be mapped.
すべての候補プロトコルは、すべての必要な、すべてのオプションの属性を表すことができ、情報のモデルを持っています。直径の寄与はIPFIX固有の属性をマッピングする必要があります正確にどのようにいくつかの詳細を欠いています。
Each candidate protocol defines a data model that allows for some degree of extensibility.
各候補プロトコルは、拡張性のある程度のを可能にするデータモデルを定義します。
CRANE uses Keys to specify fields in templates. A key "specification MUST consist of the description and the data type of the accounting item." Apparently extensibility is intended, but it is not clear whether adding a new Key really only involves writing a textual description and deciding upon a base type. Every Key also has a 32- bit Key ID, but from the current specification they don't seem to carry global semantics.
CRANEは、テンプレート内のフィールドを指定するには、キーを使用しています。キー「仕様は、説明および会計項目のデータ型で構成する必要があります。」どうやら拡張性を意図したが、新しいキーを追加すると、実際にはテキスト記述を書き込み、基本タイプに決定する必要かどうかは明らかではありません。すべてのキーはまた、32ビットキーIDを持っていますが、現在の仕様から、彼らはグローバルな意味を運ぶようには見えません。
Diameter's Attribute/Value Pairs (AVP) have a 32-bit identifier (AVP Code) administered by IANA. In addition, there is an optional 32-bit Vendor-ID that can contain an SMI Enterprise Number for vendor-defined attributes. If the Vendor-ID (and a corresponding flag in the attribute) is set, the AVP Code becomes local to that vendor.
直径の属性/値ペア（AVP）はIANAによって投与32ビット識別子（AVPコード）を有します。加えて、ベンダー定義属性のSMI企業番号を含むことができる任意の32ビットのベンダIDがあります。ベンダーID（および属性に対応するフラグ）がセットされている場合、AVPコードは、そのベンダーにローカルになります。
IPDR uses a subset of the XML-Schema language for extensibility, thus allowing for vendor- and application-specific extensions of the data model.
IPDRは、このようにデータ・モデルのベンダ及びアプリケーション固有の拡張を可能にする、拡張性のためのXMLスキーマ言語のサブセットを使用します。
In LFAP, flow attributes are defined as Information Elements. There is a 16-bit IE type code (which is carried in the export protocol for every IE). One type code is reserved for vendor-specific extensions. Arbitrary sub-types of the vendor-specific IE can be defined using ASN.1 Object IDs (OIDs).
LFAPでは、フローの属性は情報要素として定義されています。 （すべてのIEのエクスポートプロトコルで運ばれる）16ビットIEタイプコードがあります。一つのタイプのコードは、ベンダー固有の拡張のために予約されています。ベンダー固有IEの任意のサブタイプはASN.1のオブジェクトID（OID）を使用して定義することができます。
In NetFlow v9 as reviewed, data items are identified by a sixteen-bit field type. 26 field types are defined in the document. The document suggests to look check a Web page at Cisco Systems' site for the current list of field types. It would be preferable if the administration of the field type space would be delegated to IANA.
見直しなどのNetFlow V9では、データ項目は、16ビットのフィールドタイプによって識別されます。 26のフィールドタイプは、ドキュメントに定義されています。文書には、フィールドタイプの現在のリストについては、シスコシステムズのサイトでのWebページをチェック探すことを示唆しています。フィールドタイプスペースの投与はIANAに委任するかどうそれは望ましいだろう。
All protocols allow for flexible flow record definitions. CRANE and LFAP make the selection/negotiation of the attributes to be included in flow records a part of the protocol, the other protocols leave this to outside configuration mechanisms.
すべてのプロトコルは、柔軟なフローレコードの定義を可能とします。クレーンLFAPフローに含まれる属性の選択/ネゴシエーションプロトコルの一部を記録する、他のプロトコルは、外部設定機構にこれを残します。
All protocols except for NetFlow v9 operate over a single TCP or SCTP transport connection, and inherit the congestion-friendliness of these protocols.
NetFlowは、単一のTCPまたはSCTPトランスポート接続上で動作し、これらのプロトコルの混雑の使い勝手を継承V9を除くすべてのプロトコル。
NetFlow v9 was initially defined to operate over UDP, but specified in a transport-independent manner. Recently, a document [16] has been issued that describes how NetFlow v9 can be run over SCTP with the proposed Partial Reliability extension. This transport mapping would fill the congestion awareness requirement.
NetFlow V9は、最初はUDP上で動作するように定義されていますが、輸送に依存しない方法で指定されました。最近では、文書[16]のNetFlow V9が提案されている部分的な信頼性の拡張子を持つSCTP上で実行できる方法を説明しているが発行されました。このトランスポートマッピングは混雑意識の要件を満たします。
The requirements in the area of reliability are specified as follows: If flow records can be lost during transfer, this must be indicated to the collector in a way that permits the number of lost records to be gauged; and the protocol must be open to reliability extensions including retransmission of lost flow records, detection of exporter/collector disconnection and fail-over, and acknowledgement of flow records by the collecting process (application-level acknowledgements).
次のように信頼性の領域における要件が指定されている：フローレコードが転送中に失われる可能性があれば、これは測られるべき失われたレコードの数を可能にするようにコレクタに指示されなければなりません。プロトコルは、収集プロセス（アプリケーションレベルの肯定応答）によって失われたフローレコードの再送、輸出/コレクタの断線やフェイルオーバーの検出、およびフローレコードの確認応答を含む信頼性の拡張に開いていなければなりません。
Here are a few observations regarding the candidate protocols' approaches to reliability. Note that the requirement for multiple collectors (8.3) also touches on the issue of reliability.
ここでは、信頼性への候補プロトコルアプローチに関するいくつかの観察があります。複数のコレクター（8.3）の要件も、信頼性の問題に触れることに留意されたいです。
CRANE, Diameter, and IPDR, as protocols that strive to be carrier-grade accounting protocols, understandably exhibit a strong emphasis on near-total reliability of the flow export process. All three protocols use application-level acknowledgements (in case of IPDR, optionally) to include the entire collection process in the feedback loop. Indications of "lack of reliability" (lost flow data) are somewhat unnatural to these protocols, because they take every effort to never lose anything. These protocols seem suitable in situations where one would rather drop a packet than forward it unaccounted for.
CRANE、直径、およびIPDRは、キャリアグレードの会計プロトコルとなるよう努めていますプロトコルとして、当然のことながら、フローエクスポートプロセスのほぼ完全な信頼性を重視を示します。すべての3つのプロトコルは、フィードバックループ内のコレクション全体のプロセスを含むように（必要に応じて、IPDRの場合）アプリケーションレベルの肯定応答を使用します。彼らは何かを失うことはありませんためにあらゆる努力を取るので、「信頼性の欠如」（失われたフローデータ）の適応症は、これらのプロトコルにやや不自然です。これらのプロトコルは1つが、むしろそれは行方不明のために転送するよりも、パケットをドロップします状況には適しているようです。
LFAP has application-level acknowledgements, and it also reports detailed statistics about lost flows and the amount of data that couldn't be accounted for. It represents a middle ground in that it acknowledges that accounting reliability will sometimes be sacrificed for the benefit of other tasks, such as switching packets, and provides the tools to gracefully deal with such situations.
LFAPは、アプリケーションレベルの確認応答を持っており、それはまた、失われたフローおよび計上することができなかったデータの量に関する詳細な統計情報をレポートします。それは、会計の信頼性は、時々、このようなパケットを交換などの他のタスクの利益のために犠牲にされることを認めることで妥協点を表し、そして優雅な状況に対処するためのツールを提供します。
NetFlow v9 is the only protocol for which the use of a "reliable" transport protocol is optional, and the only protocol that doesn't support application-level acknowledgements. In all fairness, it should be noted that it is a very simple and efficient protocol, so in an actual deployment it might exhibit a higher level of reliability than some of the other protocols given the same amount of resources.
NetFlow V9は、「信頼できる」トランスポートプロトコルの使用は任意であり、アプリケーション・レベルの確認応答をサポートしていない唯一のプロトコルれる唯一のプロトコルです。公正を期すため、実際の展開で、それは同じ量のリソースを与えられ、他のプロトコルのいくつかのより信頼性の高いレベルを示す可能性があるので、それは、非常にシンプルかつ効率的なプロトコルであることに留意すべきです。
All protocols can use, and their descriptions in fact recommend them to use, lower-layer security mechanisms such as IPsec and, with the exception of NetFlow v9 over UDP, TLS. It can be argued that in all envisioned usage scenarios for IPFIX, both IPsec and TLS provide sufficient protection against the main identified threats of flow data disclosure and forgery.
すべてのプロトコルが使用でき、実際にはその説明はUDP、TLS経由のNetFlow V9を除いて、IPsecなど、下位層のセキュリティメカニズムを使用するためにそれらをお勧めします。 IPFIXのためのすべての想定される利用シナリオでは、IPsecとTLSの両方がフローデータ開示や偽造の主な識別された脅威に対して十分な保護を提供することを主張することができます。
The Diameter document is the only protocol definition that goes into sufficient level of detail with respect to the application of these mechanisms, in particular the negotiation of certificates and ciphers in TLS, and the use of IKE [6] for IPsec. Diameter also mandates that either IPsec or TLS be used.
直径文書は、TLS内の証明書と暗号のネゴシエーション、およびIPsecのためのIKE [6]の使用、特に、これらのメカニズムのアプリケーションに関して詳細の十分なレベルになる唯一のプロトコルの定義です。直径はまた、IPSecまたはTLSのいずれかを使用することを義務付け。
Diameter suggests an additional end-to-end security framework for dealing with untrusted third-party agents. I am not entirely convinced that this additional level of security justifies the additional complexity in the context of IPFIX.
直径が信頼されていないサードパーティのエージェントに対処するための追加的なエンドツーエンドのセキュリティフレームワークを提案します。私はセキュリティのこの追加のレベルはIPFIXのコンテキスト内で、追加の複雑さを正当化することを完全に納得していませんよ。
LFAP [11] is the only other protocol that includes some higher-level security mechanisms, providing four levels of security including no security, authenticated peers, flow data authentication, and flow data encryption using HMAC-MD5-96 and DES-CBC.
LFAP [11]はセキュリティ、認証されたピア、フローデータ認証を含まないセキュリティの4つのレベルを提供する、いくつかのより高いレベルのセキュリティメカニズムを含む唯一の他のプロトコルであり、HMAC-MD5-96およびDES-CBCを使用してデータの暗号化を流れます。
As far as the author can judge (not being a security expert), LFAP's built-in support for authentication and encryption doesn't provide significant additional security compared with the use of TLS or IPsec. It is potentially useful in situations where TLS or IPsec are unavailable for some reason, although in the context of IPFIX scenarios, it should be possible to assume support for these lower-layer mechanisms if the participating devices are capable of the necessary cryptographic methods at all.
限り著者は（セキュリティの専門家でない）を判定することができるよう、認証と暗号化のためのLFAPのビルトインサポートは、TLSやIPsecの使用と比較して有意な追加のセキュリティを提供していません。参加デバイスがまったく必要な暗号方式が可能である場合IPFIXシナリオのコンテキストにおいて、これらの下層メカニズムのサポートを想定することが可能であるべきであるが、それは、TLSやIPsecが何らかの理由で利用できない状況において有用である可能性があります。
All protocols support the mandatory "push" mode.
すべてのプロトコルは、必須の「プッシュ」モードをサポートしています。
The optional "pull" mode could be supported relatively easily in Diameter, and is foreseen in NDM-U, the basis of the Streaming IPDR proposal. CRANE, LFAP and NetFlow don't have a "pull" mode. For CRANE and LFAP, adding one would not violate the spirit of the protocols because they are already two-way, and in fact LFAP already foresees inquiries about specific active flows using Administrative Request (AR) messages with a RETURN_INDICATED_FLOWS Command Code IE.
オプションの「プル」モードでは、直径が比較的容易にサポートすることができ、NDM-U、ストリーミングIPDR提案の根拠に予見されます。 CRANE、LFAPとNetFlowは、「プル」モードを持っていません。彼らはすでに双方向であり、実際にはLFAPが既にRETURN_INDICATED_FLOWSコマンドコードIEで管理要求（AR）メッセージを使用して、特定のアクティブフローに関するお問い合わせを予見しているためCRANEとLFAPの場合は、1を追加するプロトコルの精神に違反しないでしょう。
As stated, this requirement concerns the metering process only and has no bearing on the export protocol.
述べたように、この要件は計量工程に関するおよびエクスポートプロトコルとは関係ありません。
The specific events listed in the requirements documents as examples for "specific events" are "the arrival of the first packet of a new flow and the termination of a flow after flow timeout". For the former, only LFAP explicitly generates messages upon creation of a new flow. NetFlow always exported flow information on expiration of flows, either due to timeout or due to an indication of flow termination. The other protocols are unspecific about when flow information is exported.
「特定のイベント」の例として、要件文書に記載されている特定のイベントは、「新しいフローの最初のパケットの到着とフローのタイムアウト後の流れの終了」です。かつてのために、唯一のLFAPは、明示的に新しいフローの作成時にメッセージを生成します。 NetFlowは常にフロー終了の指示にタイムアウトに起因する又は起因するいずれかのフローの有効期限に関するフロー情報を、エクスポート。他のプロトコルは、フロー情報をエクスポートしたときについての非特異的です。
On "specific events" in general, all protocols have some mechanism that could be used for notification of asynchronous events. An example for such an event would be that the sampling rate of the meter was changed in response to a change in the load on the exporting process.
一般的には「特定のイベント」で、すべてのプロトコルは、非同期イベントの通知に使用することができ、いくつかのメカニズムを持っています。そのようなイベントの例は、計器のサンプリングレートは、エクスポート処理の負荷の変化に応じて変更されたことであろう。
CRANE has Status Request/Status Response messages, but as defined, Status Requests can only be issued by the server (collector), so they cannot be used by the server to signal asynchronous events. As in IPDR, this could be circumvented by defining templates for meta-information.
CRANEは、ステータス要求/ステータス応答メッセージを持っていますが、定義されているように、ステータス要求をのみ、サーバー（コレクタ）によって発行することができますので、彼らは非同期イベントを通知するために、サーバで使用することはできません。 IPDRのように、これはメタ情報のテンプレートを定義することによって回避することができました。
Diameter could use special Accounting-Request messages for event notification.
直径は、イベント通知のための特別なアカウンティング要求メッセージを使用することができます。
IPDR would presumably define pseudo-"Usage Events" using an XML Schema so that events can be reported along with usage data.
IPDRは、おそらくイベントが使用データと一緒に報告できるように、XMLスキーマを使用して擬似「使用上のイベント」を定義します。
LFAP has Administrative Requests (AR) that can be initiated from either side. The currently defined ARs are all information inquiries or reconfiguration requests, but new ARs could be defined to provide unsolicited information about specific asynchronous events. The LFAP MIB also defines some traps/notifications. SNMP notifications are useful to signal events to a network management system, but they are less attractive as a mechanism to signal events that should be somehow handled by a collector.
LFAPは、どちらの側から開始することができる管理要求（AR）を持っています。現在定義されているのARは、全ての情報の問い合わせや再設定を要求しているが、新しいのARは、特定の非同期イベントに関する未承諾の情報を提供するように定義することができます。 LFAP MIBは、一部のトラップ/通知を定義します。 SNMP通知は、ネットワーク管理システムにイベントを通知するのに有用であるが、彼らは何とかコレクタによって処理されるべきイベントを通知するためのメカニズムとしてはあまり魅力的です。
In NetFlow v9, Option Data FlowSets are defined to convey information about the metering and export processes. The current document specifies that Option Data should be exported periodically, although this requirement will be relaxed for asynchronous events. It should be noted that periodical export of option flowsets (and also of templates) may have been considered necessary because NetFlow can run over an unreliable transport; it seems less natural when a reliable transport such as TCP is used.
NetFlowのV9では、オプションデータフローセットは、計量およびエクスポートプロセスに関する情報を伝えるために定義されています。現在のドキュメントは、この要件は、非同期イベントのために緩和されますが、オプションデータは、定期的にエクスポートすることを指定します。 NetFlowが信頼性の低いトランスポートを介して実行することができますので、（ともテンプレートの）オプションのフローセットの定期的な輸出が必要と考えられてきたことに留意すべきです。 TCPのような信頼性の高いトランスポートを使用する場合には、あまり自然に感じ。
None of the protocols include explicit support for anonymization. All protocols could be extended to convey when and how anonymization is being performed by an exporter, using mechanisms similar to those that would be used to report on sampling.
プロトコルのいずれも匿名の明示的なサポートが含まれていません。すべてのプロトコルは、いつ、どのように匿名でサンプリングを報告するために使用されるものと同様のメカニズムを使用して、輸出国で行われている伝えるために拡張することができます。
CRANE, Diameter, and IPDR all support multiple collectors in a backup configuration. The failover case is analyzed in some detail, with support for data buffering and de-duplication in failover situations.
CRANE、直径、およびIPDRは、すべてのバックアップの構成で複数のコレクタをサポートしています。フェイルオーバーの場合は、フェイルオーバーの状況では、データバッファリングと重複除外をサポートし、いくつかの詳細に分析されています。
NetFlow takes a more simple-minded approach in that it allows multiple (currently: two) collectors to be configured in an exporter. Both collectors will generally receive all data and could use sequence numbers and inter-collector communication to de-duplicate them. This is a simple way to improve availability but may also be considered to be wasteful, both in terms of bandwidth and in terms of other exporter resources. With the current UDP mapping it is easy enough to send multiple copies of datagrams to different collectors, but when SCTP or TCP is used, sending all data over multiple connections will exacerbate performance issues.
コレクタエクスポータに設定する：NetFlowは、それが複数（二現在）を可能にすることで、より単純な志向のアプローチをとります。どちらのコレクターは、一般的にすべてのデータを受信すると、それらを解除複製するシーケンス番号とインターコレクタ通信を使用することができます。これは、帯域幅の面で、その他の輸出資源の両面で、可用性を向上させるための簡単な方法ですが、また無駄であるとみなすことができます。現在のUDPマッピングで、別のコレクターにデータグラムの複数のコピーを送信するのは簡単ですが、SCTPまたはTCPを使用する場合は、複数の接続を介してすべてのデータを送信すると、パフォーマンス上の問題を悪化させるだろう。
Failover in LFAP must take into account that flow information is split into FARs and FUNs. When a (primary) FAS A fails, a secondary FAS B will receive FUNs for flows whose FARs had only been sent to A. If such FUNs are to be handled correctly in the failover case, then either the set of active flows must be kept in sync between the primary and backup FASs, or the exporting CCE must have a way to generate new FARs on failover.
フロー情報を考慮に入れる必要がありますLFAPでのフェイルオーバーはファールスと低速運行に分割されます。 （一次）FAS Aに障害が発生した場合、このような低速運行がフェイルオーバーの場合に正しく処理される場合、二次FAS Bは、その後、アクティブフローのセットのいずれかを保持しなければならない、FARSのみA.に送信されたフローのための低速運行を受信しますプライマリおよびバックアップFASS、またはエクスポートするCCEの間で同期して、フェイルオーバーに新しいファルスを生成する方法を持っている必要があります。
Every candidate protocol has its strengths and weaknesses. If the primary goal of the IPFIX standardization effort were to define a carrier-grade accounting protocol that can also be used to carry IP flow information, then one of CRANE, Diameter and Streaming IPDR would probably be the candidate of choice.
すべての候補プロトコルは、その長所と短所があります。 IPFIXの標準化作業の主な目的は、また、IPフロー情報を運ぶために使用することができ、キャリアグレードのアカウンティングプロトコルを定義した場合、その後、クレーン、直径およびストリーミングIPDRの一つは、おそらく選択の候補となります。
But since the goal is to standardize existing practice in the area of IP Flow Information Export, it makes sense to analyze why previous versions of NetFlow have been so widely implemented and used. The strong position of Cisco in the router market certainly played a major role, but we should not underestimate the value of having a simple and streamlined protocol that "does one thing and does it well". It has been extremely easy to write NetFlow collecting processes, as all the protocol demands from a collector is to sit there and receive data. This model is no longer adequate when one wants to support increased levels of reliability or dynamically changing semantics for data export. But NetFlow remains a simple protocol, mainly by leaving out issues of configuration/negotiation.
目標は、IPフロー情報のエクスポートの領域に存在する練習を標準化することであるので、しかし、それは、NetFlowの以前のバージョンがとても広く実装され、使用されている理由を分析することは理にかなって。ルータ市場におけるシスコの強い位置は確かに大きな役割を果たしたが、我々は「一つのことをして、うまくそれをしない」というシンプルで合理化プロトコルを持つことの価値を過小評価してはいけません。コレクターからすべてのプロトコルの要求がそこに座ってデータを受信するように、NetFlowの収集のプロセスを書くことは非常に簡単になっています。このモデルは1つが、信頼性のレベルが増加または動的にデータエクスポートの変更セマンティクスをサポートしたいと考えていたときにはもはや十分ではありません。しかし、NetFlowは、主な構成/交渉の問題を残すことによって、単純なプロトコルのまま。
So far, the biggest issue with NetFlow is that it could not resolve itself to mandate a reliable (and congestion-friendly) transport. This could easily be fixed, and bring with it some additional possibilities for simplifications. For example it would no longer be necessary to periodically retransmit Template FlowSets, and Option Data FlowSets could become a more versatile way of reporting meta-information about the metering and exporting processes either synchronously or asynchronously. Application-level acknowledgements - possibly as an option - would be a low-impact addition to improve overall reliability.
これまでのところ、NetFlowの持つ最大の問題は、それが信頼性の高い（と渋滞に優しい）の輸送を強制するために自分自身を解決できませんでしたということです。これは簡単に修正し、それを単純化するためのいくつかの可能性を持って来ることができました。例えば、もはや定期的にテンプレートフローセットを再送する必要がないだろう、とオプションデータフローセットは、計量に関するメタ情報を報告し、同期または非同期のプロセスをエクスポートするより汎用性の高い方法になる可能性があります。アプリケーションレベルの肯定応答は、 - おそらくオプションとして - 全体的な信頼性を向上させるために、低衝撃付加であろう。
LFAP is also relatively focused on flow information export, but carries around too much baggage from its youth as the Lightweight Flow Admission Protocol. The bidirectional nature and large number of message types in the protocol are one symptom of this, the separation of flow information into FARs and FUNs - which must be matched at the collector - are another. Data encoding is less space-efficient than that of CRANE, NetFlow or IPDR, and will present a performance issue at high flow rates.
LFAPは、フロー情報のエクスポートにも比較的集中ですが、軽量フローアドミッションプロトコルとして周りの若者からあまりにも多くの荷物を運びます。コレクタに整合されなければならない - - 双方向の性質およびプロトコルのメッセージタイプの多数は、この一の症状、ファルスと低速運行にフロー情報を分離している別のです。データ符号化は、より少ないスペース効率CRANE、NetFlowのかIPDRのそれよりも、高流量でパフォーマンスの問題を提示します。
LFAP's indications of unaccounted data and its MIB are excellent features that would be very useful in many operational situations.
行方不明データとそのMIBのLFAPの兆候は、多くの運用状況で非常に有用であろう優れた機能です。
It is the opinion of the evaluation team that the goals of the IPFIX WG charter would best be served by starting with NetFlow v9, working on lacking mechanisms in the areas of transport, security, reliability, and redundant configurations, and doing so very carefully in order to retain as much simplicity as possible and to avoid overloading the protocol. By starting from the simplest protocol that meets a large percentage of the specific requirements, we can hope to arrive at a protocol that meets all requirements and still allows widespread and cost-effective implementation.
それはIPFIX WG憲章の目標は最高のNetFlow V9から始まる輸送、セキュリティ、信頼性、および冗長構成の分野でのメカニズムを欠いているに取り組んで、そして非常に慎重でそうすることによって提供されることを評価チームの意見であります可能な限りシンプルさを維持するために、プロトコルの過負荷を避けるために。特定の要件の大部分を満たしている最も簡単なプロトコルから開始することにより、我々はすべての要件を満たしていると、まだ広範かつ費用対効果の実現を可能にするプロトコルに到着することを望むことができます。
As evaluated, NetFlow v9 doesn't specify any security mechanisms. The IPFIX protocol specification must specify how the security requirements in section 6.3.3 of [1] can be assured. The IPFIX specification must be specific about the choice of security-supporting protocol(s) and about all relevant issues such as security negotiation, protocol modes permitted, and key management.
評価されたよう、のNetFlow V9は、すべてのセキュリティ・メカニズムを指定していません。 IPFIXプロトコル仕様[1]確保することができるのセクション6.3.3にどのセキュリティ要件を指定する必要があります。 IPFIX仕様は、セキュリティ支持プロトコル（複数可）の選択と、このようなセキュリティネゴシエーション、許可されたプロトコルモード、およびキー管理などについて、関連するすべての問題について具体的でなければなりません。
The other important requirement that isn't fulfilled by NetFlow v9 today is support for a congestion-aware protocol (see section 6.3.1 of [1]). So a mapping to a known congestion-friendly protocol such as TCP, or, as suggested in [16], (PR-)SCTP, is considered as another necessary step in the preparation of the IPFIX specification.
今日のNetFlow V9によって満たされていない他の重要な要件は、混雑認識プロトコルのサポート（[1]のセクション6.3.1を参照）です。そうように示唆されているようにTCP、または、[16]、（PR-）SCTPなどの公知の混雑向けプロトコルへのマッピングは、IPFIX仕様の調製における別の必要なステップであると考えられます。
The security mechanisms of the candidate protocols were discussed in Section 4.10.3.
候補プロトコルのセキュリティメカニズムは、4.10.3で議論されました。
Many of the issues have been discussed with the other members of the IPFIX evaluation team: Juergen Quittek, Mark Fullmer, Ram Gopal, and Reinaldo Penno. Many participants on the ipfix mailing list provided valuable feedback, including Vamsidhar Valluri, Paul Calato, Tal
ユルゲンQuittek、マーク・フルマー、ラムゴパル、およびレイナルドPenno：問題の多くは、IPFIXの評価チームの他のメンバーと議論されてきました。 IPFIXメーリングリスト上の多くの参加者がVamsidhar Valluri、ポールCalato、タルを含む、貴重なフィードバックを提供しました
Givoly, Jeff Meyer, Robert Lowe, Benoit Claise, and Carter Bullard. Bert Wijnen, Steve Bellovin, Russ Housley, and Allison Mankin provided valuable feedback during AD and IESG review.
Givoly、ジェフ・マイヤー、ロバート・ロウ、ブノワClaise、およびカーターブラード。バートWijnen、スティーブBellovin氏、ラスHousley、およびアリソンマンキンはADとIESGレビューの間、貴重なフィードバックを提供しました。
[1] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export", RFC 3917, October 2004.
[1] Quittek、J.、Zseby、T.、Claise、B.、およびS.ザンダー、 "IPフロー情報エクスポートのための要件"、RFC 3917、2004年10月。
[2] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[2] Claise、B.、エド。、 "シスコシステムズのNetFlowサービスエクスポートバージョン9"、RFC 3954、2004年10月。
[3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[3]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[4]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[5]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[6]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[7] Zhang, K. and E. Elkin, "XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0", RFC 3423, November 2002.
[7]チャン、K.およびE.エルキン、 "ネットワーク要素（CRANE）プロトコル仕様バージョン1.0のためのXACCTの一般的な信頼性の高い会計"、RFC 3423、2002年11月。
[8] Zhang, K., "Evaluation of the CRANE Protocol Against IPFIX Requirements", Work in Progress, September 2002.
[8]チャン、K.、 "CRANEプロトコルに対するIPFIX要件の評価"、進歩、2002年9月での作業。
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[9]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[10] Zander, S., "Evaluation of Diameter Protocol against IPFIX Requirements", Work in Progress, September 2002.
[10]ザンダー、S.、 "IPFIX要件に対してDiameterプロトコルの評価"、進歩、2002年9月での作業。
[11] Calato, P. and M. MacFaden, "Light-weight Flow Accounting Protocol Specification Version 5.0", July 2002.
[11] Calato、P.とM. MacFaden、 "軽量フローアカウンティングプロトコル仕様バージョン5.0"、2002年7月。
[12] Calato, P. and M. MacFaden, "Light-weight Flow Accounting Protocol Data Definition Specification Version 5.0", July 2002.
[12] Calato、P.とM. MacFaden、 "軽量フローアカウンティングプロトコルデータ定義仕様バージョン5.0"、2002年7月。
[13] Calato, P., "Evaluation Of Protocol LFAP Against IPFIX Requirements", Work in Progress, September 2002.
[13] Calato、P.、 "プロトコルLFAPに対するIPFIX要件の評価"、進歩、2002年9月での作業。
[14] Calato, P. and M. MacFaden, "Light-weight Flow Accounting Protocol MIB", Work in Progress, September 2002.
[14] Calato、P.とM. MacFaden、 "軽量フローアカウンティングプロトコルMIB"、進歩、2002年9月での作業。
[15] Claise, B., "Evaluation Of NetFlow Version 9 Against IPFIX Requirements", Work in Progress, September 2002.
[15] Claise、B.、 "IPFIX要件に対するNetFlowバージョン9の評価"、進歩、2002年9月での作業。
[16] Djernaes, M., "Cisco Systems NetFlow Services Export Version 9 Transport", Work in Progress, February 2003.
[16] Djernaes、M.、 "シスコシステムズのNetFlowサービスの輸出バージョン9交通"、進歩、2003年2月での作業。
[17] Meyer, J., "Reliable Streaming Internet Protocol Detail Records", Work in Progress, August 2002.
[17]マイヤー、J.、「信頼性の高いストリーミングインターネットプロトコル詳細レコード」、進歩、2002年8月に作業。
[18] Meyer, J., "Evaluation Of Streaming IPDR Against IPFIX Requirements", Work in Progress, September 2002.
[18]マイヤー、J.、 "ストリーミングIPDRに対するIPFIX要件の評価"、進歩、2002年9月での作業。
[19] Internet Protocol Detail Record Organization, "Network Data Management - Usage (NDM-U) For IP-Based Services Version 3.1", April 2002. URL: http://www.ipdr.org/documents/NDM-U_3.1.pdf
[19]インターネットプロトコルの詳細レコード編成、 "ネットワークデータ管理 - IPベースのサービスのバージョン3.1使用上（NDM-U）"、2002年4月URL：http://www.ipdr.org/documents/NDM-U_3。 1.pdf
[20] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[20]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[21]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[22] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[22] Rigney、C.、ウィレンス、S.、ルーベン、A.およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤル"。
[23] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[23]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル（SCTP）部分的な信頼性拡張"、RFC 3758、2004年5月。
[24] DeRose, S., Maler, E. and D. Orchard, "XML 1.0 Recommendation", W3C FirstEdition REC-xml-19980210, February 1998.
[24] DeRose、S.、MALER、E.およびD.オーチャード、 "XML 1.0勧告"、W3C FirstEdition REC-XML-19980210、1998年2月。
[25] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[25]スリニバサン、R.、 "XDR：外部データ表現標準"、RFC 1832、1995年8月。
[26] <http://www.nmops.org/>
「２６」 ＜ｈっｔｐ：／／ｗっｗ。んもｐｓ。おｒｇ／＞
[27] <http://www.ipdr.org/>
「２７」 ＜ｈっｔｐ：／／ｗっｗ。いｐｄｒ。おｒｇ／＞
Appendix A. A Note on References to the Candidate Protocol Documents
候補プロトコルドキュメントへの参照の付録A A注
At the time of the evaluation, the candidate protocol definitions, as well as their respective accompanying advocacy documents, were available as Internet-Drafts. As of the time of publication of this document, some of the protocols have been published as RFCs, others are still being revised as Internet-Drafts, and some will have expired. This document attempts to extract the relevant information from the individual protocol definitions and, in the context of the IPFIX requirements, provide a meaningful comparison between them.
評価の時点では、候補プロトコルの定義だけでなく、それぞれの添付擁護文書は、インターネットドラフトとして利用可能でした。このドキュメントの発行時点では、プロトコルの一部がRFCとして公開されている、他の人はまだインターネットドラフトとして改訂されている、といくつかの有効期限が切れています。この文書は、個々のプロトコル定義から関連情報を抽出し、IPFIX要件の文脈では、それらの間の意味のある比較を提供しようとします。
Since this evaluation proposes to use NetFlow v9 as the basis for the IPFIX protocol, only the reference to this protocol is considered "normative", although strictly spoken, the present document doesn't define any protocol, and the selected protocol will have to be further refined to become the IPFIX protocol.
この評価は、IPFIXプロトコルの基礎としてのNetFlow V9を使用することが提案されているので、このプロトコルへの参照のみを厳密に話さ、本文書は、任意のプロトコルを定義していないが、「規範的」とみなされ、選択されたプロトコルは、である必要がありますさらにIPFIXプロトコルになるために洗練されました。
In the interest of stable references, the bibliography points to RFCs where those have become available (for DIAMETER and CRANE). Other protocols are still available only as Internet-Drafts and may eventually expire. The LFAP drafts - which already have expired - are still available from the www.nmops.org Web site [26] (as well as other places). The IPDR documents are available on the IPDR Web site [27].
安定した参照の関心では、参考文献は、それらが（DIAMETERとCRANEのために）利用できるようになったのRFCを指します。他のプロトコルはまだのみインターネットドラフトとして利用可能であり、最終的に期限切れになることがあります。 LFAPドラフト - すでに有効期限が切れている - まだ[26] www.nmops.org Webサイトから入手できます（だけでなく、他の場所）。 IPDR文書はIPDR Webサイト[27]でご利用いただけます。
Author's Address
著者のアドレス
Simon Leinen SWITCH Limmatquai 138 P.O. Box CH-8021 Zurich Switzerland
サイモン・リネンスイッチリマト河岸138 P. O.ボックスCH-8021チューリッヒスイス
Phone: +41 1 268 1536 EMail: simon@switch.ch
電話：+41 1 268 1536 Eメール：simon@switch.ch
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、www.rfc-editor.orgで、そこに記載される場合を除き、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 ISOC文書の権利に関するISOCの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。