Network Working Group S. Leinen
Request for Comments: 3955 SWITCH
Category: Informational October 2004
Network Working Group S. Leinen
Request for Comments: 3955 SWITCH
Category: Informational October 2004
Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)
IP流信息导出（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）协议的五个候选协议进行了评估。这些协议的特点和分类广泛，并根据具体要求进行评估。最后，建议选择NetFlow v9协议作为IPFIX规范的基础。
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
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
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之外的文件。
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]
o 起重机[7]、[8]o直径[9]、[10]o LFAP[11]、[12]、[13]o NetFlow v9[2]、[15]、[16]o流式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".
XACCT的通用网元可靠计费协议版本1.0[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.
Diameter[9][10]是远程身份验证拨入用户服务（RADIUS）协议[22]的一种演变。RADIUS广泛用于将拨号接入环境中的身份验证和授权外包。Diameter是一种通用的可扩展协议，旨在支持不同应用程序的身份验证、授权和记帐（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.
Diameter是一种对等协议。基本协议定义了14个命令代码，组织为7个请求/响应命令对。据推测，在纯IPFIX应用程序中只会使用其中的一个子集。Diameter包括功能协商和错误通知。Diameter通过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由八个字节的头加上存储数据的空间组成，这取决于数据格式。有许多预定义的AVP数据格式，包括有符号和无符号整数类型，每种类型都有32位和64位变体、IPv4和IPv6地址以及其他格式。宣传文件[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加密的四个安全级别。注意，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有两种不同的流信息消息类型：当在CCE（计量器/导出器）上识别新流时，将发送流记帐请求（FAR）消息。会计信息稍后在一条或多条流更新通知（FUN）消息中发送。收集器必须将每个乐趣与以前在FAR中发送的流ID相匹配。
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以类型/长度/值格式对数据进行编码，每个数据项有四个字节的开销（两个字节用于类型，两个字节用于长度字段）。
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.
[16]中建议使用SCTP传输NetFlow v9。建议的映射描述了如何将控制和数据映射到单个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版[19]的网络数据管理使用（NDM-U）应用程序。它由互联网协议详细记录组织（IPDR，Inc.或IPDR.org）开发。所使用的术语与CRANE的类似，涉及服务元素（SE）、中介系统和业务支持系统（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交付”模式和“确认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.
Riverstone的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
流式IPDR和CRANE将自己描述为协议，以促进网络元素（或者在IPDR的情况下更一般地说是“服务元素”）和中介系统或业务支持系统（BSS）之间的会计信息的可靠传输。他们
reflect a view of the accounting problem and of network system architectures that originates in traditional "vertically integrated" telecommunications.
反映了会计问题和源自传统“垂直整合”电信的网络系统架构的观点。
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基于NDM-U，NDM-U使用XML模式语言对记帐数据结构进行机器可读的规范，同时对实际数据传输使用高效的XDR编码。
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.
Diameter是更广泛用途协议的另一个示例，因为它涵盖了身份验证和授权以及记帐等方面。这就解释了它非常强调安全性和可靠性的原因。该设计还考虑了各种类型的中间剂。
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.
该组中的协议使用外部机制来完全描述流数据的编码格式。对于CRANE和NetFlow，这些机制是“模板”，对于IPDR，是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位整数）只占用四个八位字节。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.
大多数协议在导出数据格式中指定“网络字节顺序”或“big-endian”格式。CRANE是导出程序可以选择字节顺序的唯一协议。主要的好处是，这降低了基于little endian体系结构的出口商的加工需求。
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允许在会话开始时协商用于数据导出的模板，还允许稍后协商模板更新。起重机会议包括一个出口商和几个潜在的收藏家，因此这些谈判可能涉及两个以上的方面。
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有一个版本协商的初始阶段，然后是“数据协商”阶段。在这些启动阶段之后，导出器将向收集器发送远而有趣的消息。但是，任何一方也可以向另一方发送管理请求（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.
Diameter具有通用的协商机制。IPFIX的Diameter的使用还没有得到足够详细的描述，无法确定如何使用协商功能。协商后，协议基本上以单向模式运行，记帐请求（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.
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.translate error, please retry
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的所有当前Cisco实施并非如此）。
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没有提到取样的可能性。这是很自然的，因为他们的目标是电信级会计，在那里抽样将被视为不允许。由于对采样的支持是“可能”的要求，因此可以容忍其缺乏，但严重限制了这些协议在不需要绝对精度的高聚合场所的适用性。这包括流量分析、流量工程和大规模攻击/入侵检测等应用程序，也包括基于使用情况的计费应用程序，其中商定了基于采样的收费。
The Diameter advocate acknowledges the existence of sampling and suggests to define new (grouped) AVPs to carry information about the sampling parameters in use.
Diameter倡导者承认采样的存在，并建议定义新的（分组的）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.
起重机，直径，和IPDR考虑超出协议范围的要求，虽然直径直接承认可能需要与减轻方法相关的新AVP定义。
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必须与绝对时间匹配。尽管每个NetFlow导出数据包头都包含一个“UNIX Secs”字段，但它不能用于UTC同步而不丢失精度，因为该字段只有1秒的分辨率。
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.
所有候选协议都有可以表示所有必需和可选属性的信息模型。Diameter贡献缺少关于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.
Diameter的属性/值对（AVP）具有由IANA管理的32位标识符（AVP代码）。此外，还有一个可选的32位供应商ID，可以包含供应商定义属性的SMI企业编号。如果设置了供应商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中，流属性定义为信息元素。有一个16位的IE类型代码（每个IE的导出协议中都带有该代码）。为特定于供应商的扩展保留一个类型代码。可以使用ASN.1对象ID（OID）定义特定于供应商的IE的任意子类型。
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种字段类型。该文件建议查看Cisco Systems网站的网页，查看当前字段类型列表。最好将字段类型空间的管理委托给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.
所有协议都允许灵活的流记录定义。CRANE和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 v9之外的所有协议都在单个TCP或SCTP传输连接上运行，并继承了这些协议的拥塞友好性。
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、Diameter和IPDR，作为努力成为承运人级会计协议的协议，可以理解地表现出对流量输出过程的几乎完全可靠性的高度重视。所有三个协议都使用应用程序级确认（对于IPDR，可选）将整个收集过程包含在反馈循环中。对于这些协议来说，“缺乏可靠性”（数据流丢失）的迹象有些不自然，因为它们尽一切努力从不丢失任何东西。这些协议似乎适用于人们宁愿丢弃数据包也不愿在未说明原因的情况下转发数据包的情况。
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.
所有协议都可以使用，并且它们的描述实际上建议它们使用较低层的安全机制，例如IPsec和TLS（UDP上的NetFlow v9除外）。可以说，在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.
Diameter文档是关于这些机制的应用，特别是TLS中证书和密码的协商，以及IPsec中IKE[6]的使用的唯一一个足够详细的协议定义。Diameter还要求使用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.
Diameter建议使用额外的端到端安全框架来处理不受信任的第三方代理。我并不完全相信这种额外的安全级别可以证明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]是包含一些更高级别安全机制的唯一其他协议，提供四个级别的安全性，包括无安全性、已验证的对等点、流数据验证和使用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的使用相比没有提供显著的额外安全性。在TLS或IPsec因某种原因不可用的情况下，它可能很有用，尽管在IPFIX场景的上下文中，如果参与的设备能够使用所有必要的加密方法，则可以假定支持这些较低层机制。
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中预见，NDM-U是流式IPDR提案的基础。CRANE、LFAP和NetFlow没有“拉”模式。对于CRANE和LFAP，添加一个不会违反协议的精神，因为它们已经是双向的，事实上LFAP已经预见到使用带有返回指示流命令代码IE的管理请求（AR）消息查询特定的活动流。
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.
Diameter可以使用特殊的记帐请求消息进行事件通知。
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、Diameter和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
NetFlow采用了一种更简单的方法，它允许在一个导出器中配置多个（当前为两个）收集器。两个采集器通常都会接收所有数据，并且可以使用序列号和采集器间通信来消除重复数据。这是一种提高可用性的简单方法，但也可能是
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.
在带宽和其他资源方面都被认为是浪费。使用当前的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中的故障切换必须考虑到流信息分为FAR和FUN。当（主）FAS a出现故障时，辅助FAS B将接收FAR仅发送给a的流的FUN。如果要在故障转移情况下正确处理此类FUN，则必须在主FAS和备份FAS之间保持活动流集的同步，或者导出的CCE必须能够在故障转移时生成新的FAR。
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流量信息，那么CRANE、Diameter和Streaming 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收集过程非常容易，因为收集器的所有协议要求都是坐在那里接收数据。当需要支持更高级别的可靠性或动态更改数据导出的语义时，此模型不再适用。但是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也相对专注于流信息导出，但作为轻量级流许可协议，它的年轻人负担太多。协议中的双向性质和大量消息类型是这方面的一个症状，将流信息分离为FAR和FUN（必须在收集器处匹配）是另一个症状。与CRANE、NetFlow或IPDR相比，数据编码的空间效率较低，并且在高流速下会出现性能问题。
LFAP's indications of unaccounted data and its MIB are excellent features that would be very useful in many operational situations.
LFAP对未解释数据的指示及其MIB是极好的功能，在许多操作情况下非常有用。
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工作组章程的目标最好是从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
许多问题已经与IPFIX评估团队的其他成员进行了讨论：Juergen Quitek、Mark Fullmer、Ram Gopal和Reinaldo Penno。ipfix邮件列表上的许多参与者提供了宝贵的反馈，包括Vamsidhar Valluri、Paul Calato、Tal
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.
吉沃利、杰夫·迈耶、罗伯特·洛、贝诺特·克莱斯和卡特·布拉德。伯特·维恩、史蒂夫·贝洛文、罗斯·霍斯利和埃里森·曼金在广告和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.Zander，“IP流信息导出的要求”，RFC 39172004年10月。
[2] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[2] Claise，B.，Ed.，“思科系统网络流量服务出口版本9”，RFC 3954，2004年10月。
[3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[3] 《传输控制协议》，标准7，RFC 793，1981年9月。
[4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[4] Postel，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] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[6] Harkins，D.和D.Carrel，“互联网密钥交换（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] Zhang，K.和E.Elkin，“XACCT的网元（CRANE）通用可靠计费协议规范1.0版”，RFC 3423，2002年11月。
[8] Zhang, K., "Evaluation of the CRANE Protocol Against IPFIX Requirements", Work in Progress, September 2002.
[8] Zhang，K.“根据IPFIX要求评估起重机协议”，正在进行的工作，2002年9月。
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[9] Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[10] Zander, S., "Evaluation of Diameter Protocol against IPFIX Requirements", Work in Progress, September 2002.
[10] Zander，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.，“根据IPFIX要求评估LFAP协议”，正在进行的工作，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.，“Cisco Systems NetFlow服务导出版本9传输”，正在进行的工作，2003年2月。
[17] Meyer, J., "Reliable Streaming Internet Protocol Detail Records", Work in Progress, August 2002.
[17] Meyer，J.，“可靠的流式互联网协议详细记录”，正在进行的工作，2002年8月。
[18] Meyer, J., "Evaluation Of Streaming IPDR Against IPFIX Requirements", Work in Progress, September 2002.
[18] Meyer，J.，“根据IPFIX要求评估流式IPDR”，正在进行的工作，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] 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
[20] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[20] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[21] Dierks，T.和C.Allen，“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.，Willens，S.，Rubens，A.和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[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] Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（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.Orchard，“XML 1.0建议”，W3C第一版REC-XML-19980210，1998年2月。
[25] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[25] Srinivasan，R.，“XDR：外部数据表示标准”，RFC 1832，1995年8月。
[26] <http://www.nmops.org/>
[26] <http://www.nmops.org/>
[27] <http://www.ipdr.org/>
[27] <http://www.ipdr.org/>
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.
由于本评估建议使用NetFlow v9作为IPFIX协议的基础，因此仅对该协议的引用被视为“规范性”，尽管严格来说，本文件并未定义任何协议，所选协议必须进一步细化，才能成为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].
为了获得稳定的参考文献，参考书目中指出了RFC（适用于直径和起重机）。其他协议仍仅在互联网草案中可用，并可能最终过期。LFAP草案（已经过期）仍然可以从www.nmops.org网站[26]（以及其他地方）获得。IPDR文件可在IPDR网站上查阅[27]。
Author's Address
作者地址
Simon Leinen SWITCH Limmatquai 138 P.O. Box CH-8021 Zurich Switzerland
Simon Leinen SWITCH Limmatquai 138邮政信箱CH-8021瑞士苏黎世
Phone: +41 1 268 1536
EMail: simon@switch.ch
Phone: +41 1 268 1536
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。