Network Working Group G. Sadasivan
Request for Comments: 5470 Rohati Systems
Category: Informational N. Brownlee
CAIDA | The University of Auckland
B. Claise
Cisco Systems, Inc.
J. Quittek
NEC
March 2009
Network Working Group G. Sadasivan
Request for Comments: 5470 Rohati Systems
Category: Informational N. Brownlee
CAIDA | The University of Auckland
B. Claise
Cisco Systems, Inc.
J. Quittek
NEC
March 2009
Architecture for IP Flow Information Export
IP流信息导出体系结构
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector.
本备忘录定义了IP流信息导出（IPFIX）体系结构，用于选择性监控IP流，以及将测量的IP流信息从IPFIX设备导出到收集器。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Document Scope .............................................3
1.2. IPFIX Documents Overview ...................................3
2. Terminology .....................................................4
3. Examples of Flows ...............................................8
4. IPFIX Reference Model ..........................................10
5. IPFIX Functional and Logical Blocks ............................12
5.1. Metering Process ..........................................12
5.1.1. Flow Expiration ....................................12
5.1.2. Flow Export ........................................13
5.2. Observation Point .........................................13
5.3. Selection Criteria for Packets ............................13
5.3.1. Sampling Functions, Si .............................14
5.3.2. Filter Functions, Fi ...............................15
5.4. Observation Domain ........................................15
5.5. Exporting Process .........................................15
5.6. Collecting Process ........................................16
5.7. Summary ...................................................17
6. Overview of the IPFIX Protocol .................................18
6.1. Information Model Overview ................................19
6.2. Flow Records ..............................................19
6.3. Control Information .......................................20
6.4. Reporting Responsibilities ................................21
7. IPFIX Protocol Details .........................................21
7.1. The IPFIX Basis Protocol ..................................21
7.2. IPFIX Protocol on the Collecting Process ..................22
7.3. Support for Applications ..................................22
8. Export Models ..................................................23
8.1. Export with Reliable Control Connection ...................23
8.2. Collector Failure Detection and Recovery ..................23
8.3. Collector Redundancy ......................................24
9. IPFIX Flow Collection in Special Situations ....................24
10. Security Considerations .......................................25
10.1. Data Security ............................................25
10.1.1. Host-Based Security ...............................26
10.1.2. Authentication-Only ...............................26
10.1.3. Encryption ........................................26
10.2. IPFIX End-Point Authentication ...........................27
10.3. IPFIX Overload ...........................................27
10.3.1. Denial-of-Service (DoS) Attack Prevention .........27
11. IANA Considerations ...........................................28
11.1. Numbers Used in the Protocol .............................28
11.2. Numbers Used in the Information Model ....................29
12. Acknowledgements ..............................................29
1. Introduction ....................................................3
1.1. Document Scope .............................................3
1.2. IPFIX Documents Overview ...................................3
2. Terminology .....................................................4
3. Examples of Flows ...............................................8
4. IPFIX Reference Model ..........................................10
5. IPFIX Functional and Logical Blocks ............................12
5.1. Metering Process ..........................................12
5.1.1. Flow Expiration ....................................12
5.1.2. Flow Export ........................................13
5.2. Observation Point .........................................13
5.3. Selection Criteria for Packets ............................13
5.3.1. Sampling Functions, Si .............................14
5.3.2. Filter Functions, Fi ...............................15
5.4. Observation Domain ........................................15
5.5. Exporting Process .........................................15
5.6. Collecting Process ........................................16
5.7. Summary ...................................................17
6. Overview of the IPFIX Protocol .................................18
6.1. Information Model Overview ................................19
6.2. Flow Records ..............................................19
6.3. Control Information .......................................20
6.4. Reporting Responsibilities ................................21
7. IPFIX Protocol Details .........................................21
7.1. The IPFIX Basis Protocol ..................................21
7.2. IPFIX Protocol on the Collecting Process ..................22
7.3. Support for Applications ..................................22
8. Export Models ..................................................23
8.1. Export with Reliable Control Connection ...................23
8.2. Collector Failure Detection and Recovery ..................23
8.3. Collector Redundancy ......................................24
9. IPFIX Flow Collection in Special Situations ....................24
10. Security Considerations .......................................25
10.1. Data Security ............................................25
10.1.1. Host-Based Security ...............................26
10.1.2. Authentication-Only ...............................26
10.1.3. Encryption ........................................26
10.2. IPFIX End-Point Authentication ...........................27
10.3. IPFIX Overload ...........................................27
10.3.1. Denial-of-Service (DoS) Attack Prevention .........27
11. IANA Considerations ...........................................28
11.1. Numbers Used in the Protocol .............................28
11.2. Numbers Used in the Information Model ....................29
12. Acknowledgements ..............................................29
13. References ....................................................30
13.1. Normative References .....................................30
13.2. Informative References ...................................30
13. References ....................................................30
13.1. Normative References .....................................30
13.2. Informative References ...................................30
There are several applications, e.g., usage-based accounting, traffic profiling, traffic engineering, attack/intrusion detection, quality-of-service (QoS) monitoring, that require Flow-based IP traffic measurements. It is therefore important to have a standard way of exporting information related to IP Flows. This document defines an architecture for IP traffic Flow monitoring, measuring, and exporting. It provides a high-level description of an IPFIX Device's key components and their functions.
有几个应用程序需要基于流量的IP流量测量，例如，基于使用情况的计费、流量分析、流量工程、攻击/入侵检测、服务质量（QoS）监测。因此，有一种导出与IP流相关的信息的标准方法非常重要。本文档定义了IP流量监视、测量和导出的体系结构。它提供了IPFIX设备关键组件及其功能的高级描述。
This document defines the architecture for IPFIX. Its main objectives are to:
本文档定义了IPFIX的体系结构。其主要目标是：
o Describe the key IPFIX architectural components, consisting of (at least) IPFIX Devices and Collectors communicating using the IPFIX protocol.
o 描述关键的IPFIX体系结构组件，包括（至少）使用IPFIX协议通信的IPFIX设备和收集器。
o Define the IPFIX architectural requirements, e.g., recovery, security, etc.
o 定义IPFIX体系结构要求，例如恢复、安全性等。
o Describe the characteristics of the IPFIX protocol.
o 描述IPFIX协议的特征。
The IPFIX protocol provides network administrators with access to IP Flow information. This document specifies the architecture for the export of measured IP Flow information from an IPFIX Exporting Process to a Collecting Process, per the requirements defined in RFC 3917 [1]. The IPFIX protocol document, RFC 5101 [3], specifies how IPFIX data records and templates are carried via a congestion-aware transport protocol, from IPFIX Exporting Process to IPFIX Collecting Process. IPFIX has a formal description of IPFIX information elements (fields), their name, type, and additional semantic information, as specified in RFC 5102 [2]. Finally, RFC 5472 [4] describes what type of applications can use the IPFIX protocol and how they can use the information provided. Furthermore, it shows how the IPFIX framework relates to other architectures and frameworks.
IPFIX协议为网络管理员提供了访问IP流信息的权限。本文件规定了根据RFC 3917[1]中定义的要求，将测量的IP流信息从IPFIX导出过程导出到收集过程的体系结构。IPFIX协议文档RFC 5101[3]规定了IPFIX数据记录和模板如何通过拥塞感知传输协议从IPFIX导出过程传输到IPFIX收集过程。IPFIX对IPFIX信息元素（字段）、它们的名称、类型和附加语义信息进行了形式化描述，如RFC 5102[2]中所述。最后，RFC 5472[4]描述了什么类型的应用程序可以使用IPFIX协议，以及它们如何使用提供的信息。此外，它还展示了IPFIX框架与其他体系结构和框架的关系。
Note that the IPFIX system does not provide for remote configuration of an IPFIX device. Instead, implementors must provide an effective way to configure their IPFIX devices.
请注意，IPFIX系统不提供IPFIX设备的远程配置。相反，实施者必须提供一种有效的方式来配置他们的IPFIX设备。
The definitions of basic IPFIX terms such as IP Traffic Flow, Exporting Process, Collecting Process, Observation Point, etc., are semantically identical with those found in the IPFIX requirements document, RFC 3917 [1]. Some of the terms have been expanded for more clarity when defining the protocol. Additional definitions required for the architecture have also been defined. For terms that are defined here and in RFC 5101 [3], the definitions are equivalent in both documents.
基本IPFIX术语（如IP流量、导出过程、收集过程、观察点等）的定义在语义上与IPFIX需求文档RFC 3917[1]中的定义相同。为了在定义协议时更加清晰，对一些术语进行了扩展。还定义了体系结构所需的其他定义。对于此处和RFC 5101[3]中定义的术语，两个文件中的定义相同。
* Observation Point
* 观测点
An Observation Point is a location in the network where IP packets can be observed. Examples include: a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router.
观察点是网络中可以观察IP数据包的位置。示例包括：连接探针的线路、共享介质（如基于以太网的LAN）、路由器的单个端口或路由器的一组接口（物理或逻辑）。
Note that every Observation Point is associated with an Observation Domain (defined below), and that one Observation Point may be a superset of several other Observation Points. For example, one Observation Point can be an entire line card. That would be the superset of the individual Observation Points at the line card's interfaces.
请注意，每个观察点都与一个观察域（定义如下）关联，并且一个观察点可能是多个其他观察点的超集。例如，一个观察点可以是一张完整的线卡。这将是线路卡接口处单个观测点的超集。
* Observation Domain
* 观测域
An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. For example, a router line card may be an Observation Domain if it is composed of several interfaces, each of which is an Observation Point. In the IPFIX Message it generates, the Observation Domain includes its Observation Domain ID, which is unique per Exporting Process. That way, the Collecting Process can identify the specific Observation Domain from the Exporter that sends the IPFIX Messages. Every Observation Point is associated with an Observation Domain. It is recommended that Observation Domain IDs also be unique per IPFIX Device.
观测域是一组最大的观测点，可通过计量过程聚合流量信息。例如，如果一个路由器线路卡由几个接口组成，每个接口都是一个观察点，那么它可能是一个观察域。在它生成的IPFIX消息中，观察域包含其观察域ID，该ID在每个导出进程中都是唯一的。这样，收集过程可以从发送IPFIX消息的导出器中识别特定的观察域。每个观测点都与一个观测域相关联。建议每个IPFIX设备的观测域ID也是唯一的。
* IP Traffic Flow or Flow
* IP流量或流量
There are several definitions of the term 'flow' being used by the Internet community. Within the context of IPFIX we use the following definition:
互联网社区使用的术语“流”有几种定义。在IPFIX的上下文中，我们使用以下定义：
A Flow is defined as a set of IP packets passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties. Each property is defined as the result of applying a function to the values of:
流定义为在一定时间间隔内通过网络中观察点的一组IP数据包。属于特定流的所有数据包都有一组公共属性。每个属性定义为将函数应用于以下值的结果：
1. one or more packet header fields (e.g., destination IP address), transport header fields (e.g., destination port number), or application header fields (e.g., RTP header fields [5]).
1. 一个或多个数据包头字段（例如，目的地IP地址）、传输头字段（例如，目的地端口号）或应用程序头字段（例如，RTP头字段[5]）。
2. one or more characteristics of the packet itself (e.g., number of MPLS labels)
2. 数据包本身的一个或多个特征（例如，MPLS标签的数量）
3. one or more fields derived from packet treatment (e.g., next hop IP address, output interface)
3. 来自数据包处理的一个或多个字段（例如，下一跳IP地址、输出接口）
A packet is defined as belonging to a Flow if it completely satisfies all the defined properties of the Flow.
如果数据包完全满足流的所有定义属性，则它被定义为属于流。
This definition covers the range from a Flow containing all packets observed at a network interface to a Flow consisting of just a single packet between two applications. It includes packets selected by a sampling mechanism.
该定义涵盖了从包含网络接口上观察到的所有数据包的流到仅包含两个应用程序之间的单个数据包的流的范围。它包括由采样机制选择的数据包。
* Flow Key
* 流动键
Each of the fields that:
每个字段：
1. belongs to the packet header (e.g., destination IP address),
1. 属于数据包头（例如，目标IP地址），
2. is a property of the packet itself (e.g., packet length),
2. 是数据包本身的属性（例如，数据包长度），
3. is derived from packet treatment (e.g., Autonomous System (AS) number), and
3. 来自数据包处理（例如，自治系统（AS）编号），以及
4. is used to define a Flow
4. 用于定义流
is termed a Flow Key.
被称为流键。
* Flow Record
* 流量记录
A Flow Record contains information about a specific Flow that was observed at an Observation Point. A Flow Record contains measured properties of the Flow (e.g., the total number of bytes for all the Flow's packets) and usually characteristic properties of the Flow (e.g., source IP address).
流量记录包含有关在观测点观测到的特定流量的信息。流记录包含流的测量属性（例如，所有流的数据包的总字节数）和流的通常特征属性（例如，源IP地址）。
* Metering Process
* 计量过程
The Metering Process generates Flow Records. Inputs to the process are packet headers and characteristics observed at an Observation Point, and packet treatment at the Observation Point (for example, the selected output interface).
计量过程生成流量记录。流程的输入是在观察点观察到的数据包头和特征，以及在观察点（例如，所选输出接口）观察到的数据包处理。
The Metering Process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining Flow Records.
计量过程由一组功能组成，包括数据包头捕获、时间戳、采样、分类和维护流记录。
The maintenance of Flow Records may include creating new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records.
流记录的维护可能包括创建新记录、更新现有记录、计算流统计信息、导出进一步的流属性、检测流过期、将流记录传递给导出过程以及删除流记录。
* Exporting Process
* 导出过程
The Exporting Process sends Flow Records to one or more Collecting Processes. The Flow Records are generated by one or more Metering Processes.
导出进程将流记录发送到一个或多个收集进程。流量记录由一个或多个计量过程生成。
* Exporter
* 出口商
A device that hosts one or more Exporting Processes is termed an Exporter.
承载一个或多个导出进程的设备称为导出器。
* IPFIX Device
* IPFIX设备
An IPFIX Device hosts at least one Exporting Process. It may host further Exporting Processes and arbitrary numbers of Observation Points and Metering Processes.
IPFIX设备承载至少一个导出进程。它可以承载进一步的导出过程以及任意数量的观测点和计量过程。
* Collecting Process
* 收集过程
A Collecting Process receives Flow Records from one or more Exporting Processes. The Collecting Process might process or store received Flow Records, but such actions are out of scope for this document.
收集进程从一个或多个导出进程接收流记录。收集过程可能会处理或存储收到的流记录，但此类操作超出了本文档的范围。
* Collector
* 收藏家
A device that hosts one or more Collecting Processes is termed a Collector.
承载一个或多个收集进程的设备称为收集器。
* Template
* 样板
A Template is an ordered sequence of <type, length> pairs used to completely specify the structure and semantics of a particular set of information that needs to be communicated from an IPFIX Device to a Collector. Each Template is uniquely identifiable by means of a Template ID.
模板是<type，length>对的有序序列，用于完全指定需要从IPFIX设备传输到收集器的特定信息集的结构和语义。每个模板都可以通过模板ID进行唯一标识。
* Control Information, Data Stream
* 控制信息、数据流
The information that needs to be exported from the IPFIX Device can be classified into the following categories:
需要从IPFIX设备导出的信息可分为以下类别：
Control Information
控制信息
This includes the Flow definition, selection criteria for packets within the Flow sent by the Exporting Process, and templates describing the data to be exported. Control Information carries all the information needed for the end-points to understand the IPFIX protocol, and specifically for the Collector to understand and interpret the data sent by the sending Exporter.
这包括流定义、导出过程发送的流中数据包的选择标准，以及描述要导出的数据的模板。控制信息包含端点理解IPFIX协议所需的所有信息，特别是收集器理解和解释发送导出器发送的数据所需的所有信息。
Data Stream
数据流
This includes Flow Records carrying the field values for the various observed Flows at each of the Observation Points.
这包括流量记录，其中包含每个观测点的各种观测流量的现场值。
* IPFIX Message
* IPFIX消息
An IPFIX Message is a message originating at the Exporting Process that carries the IPFIX records of this Exporting Process and whose destination is a Collecting Process. An IPFIX Message is encapsulated at the transport layer.
IPFIX消息是源于导出进程的消息，它携带此导出进程的IPFIX记录，其目标是收集进程。IPFIX消息封装在传输层。
* Information Element
* 信息元素
An Information Element is a protocol and encoding-independent description of an attribute that may appear in an IPFIX Record. The IPFIX information model, RFC 5102 [2], defines the base set of Information Elements for IPFIX. The type associated with an Information Element indicates constraints on what it may contain and also determines the valid encoding mechanisms for use in IPFIX.
信息元素是可能出现在IPFIX记录中的属性的协议和编码独立描述。IPFIX信息模型RFC 5102[2]定义了IPFIX的基本信息元素集。与信息元素关联的类型指示对其可能包含的内容的约束，并确定在IPFIX中使用的有效编码机制。
Some examples of Flows are listed below. In the IPv4 examples, we use interface addresses in three different 26-bit (/26) subnets. In the IPv6 examples, we use 'mac addr-nn' in the low-order 64 bits to indicate the IEEE MAC (Media Access Control) address of host interface nn.
下面列出了一些流量示例。在IPv4示例中，我们在三个不同的26位（/26）子网中使用接口地址。在IPv6示例中，我们使用低阶64位的“mac addr nn”来表示主机接口nn的IEEE mac（媒体访问控制）地址。
Example 1: Flow Keys define the different fields by which Flows are distinguished. The different combination of their field values creates unique Flows. If {source IP address, destination IP address, DSCP} are Flow Keys, then all of these are different Flows:
示例1：流键定义用于区分流的不同字段。其字段值的不同组合创建了独特的流。如果{源IP地址、目标IP地址、DSCP}是流密钥，则所有这些都是不同的流：
1. {192.0.2.1, 192.0.2.65, 4}
2. {192.0.2.23, 192.0.2.67, 4}
3. {192.0.2.23, 192.0.2.67, 2}
4. {192.0.2.129, 192.0.2.67, 4}
1. {192.0.2.1, 192.0.2.65, 4}
2. {192.0.2.23, 192.0.2.67, 4}
3. {192.0.2.23, 192.0.2.67, 2}
4. {192.0.2.129, 192.0.2.67, 4}
5. {2001:DB8::0:mac-addr-01, 2001:DB8::1:mac-addr-11, 4}
6. {2001:DB8::0:mac-addr-02, 2001:DB8::1:mac-addr-13, 4}
7. {2001:DB8::0:mac-addr-02, 2001:DB8::1:mac-addr-13, 2}
8. {2001:DB8::2:mac-addr-21, 2001:DB8::1:mac-addr-13, 4}
5. {2001:DB8::0:mac-addr-01, 2001:DB8::1:mac-addr-11, 4}
6. {2001:DB8::0:mac-addr-02, 2001:DB8::1:mac-addr-13, 4}
7. {2001:DB8::0:mac-addr-02, 2001:DB8::1:mac-addr-13, 2}
8. {2001:DB8::2:mac-addr-21, 2001:DB8::1:mac-addr-13, 4}
Example 2: A mask function can be applied to all the packets that pass through an Observation Point, in order to aggregate some values. This could be done by defining the set of Flow Keys as {source IP address, destination IP address, DSCP} as in Example 1 above, and applying functions that mask out the source and destination IP addresses (least significant 6 bits for IPv4, 64 bits for IPv6). The eight Flows from Example 1 would now be aggregated into six Flows by merging the Flows 1+2 and 5+6 into single Flows:
示例2：掩码函数可以应用于通过观察点的所有数据包，以便聚合一些值。这可以通过将流密钥集定义为{源IP地址、目标IP地址、DSCP}来实现，如上面的示例1所示，并应用屏蔽源和目标IP地址的函数（IPv4的最低有效位为6位，IPv6的最低有效位为64位）。通过将流1+2和5+6合并为单个流，示例1中的八个流现在将聚合为六个流：
1. {192.0.2.0/26, 192.0.2.64/26, 4}
2. {192.0.2.0/26, 192.0.2.64/26, 2}
3. {192.0.2.128/26, 192.0.2.64/26, 4}
1. {192.0.2.0/26, 192.0.2.64/26, 4}
2. {192.0.2.0/26, 192.0.2.64/26, 2}
3. {192.0.2.128/26, 192.0.2.64/26, 4}
4. {2001:DB8::0/64, 2001:DB8::1/64, 4}
5. {2001:DB8::0/64, 2001:DB8::1/64, 2}
6. {2001:DB8::2/64, 2001:DB8::1/64, 4}
4. {2001:DB8::0/64, 2001:DB8::1/64, 4}
5. {2001:DB8::0/64, 2001:DB8::1/64, 2}
6. {2001:DB8::2/64, 2001:DB8::1/64, 4}
Example 3: A filter defined by some Flow Key values can be applied on all packets that pass the Observation Point, in order to select only certain Flows. The filter is defined by choosing fixed values for specific Keys from the packet.
示例3：由一些流键值定义的过滤器可以应用于通过观察点的所有数据包，以便仅选择某些流。过滤器是通过从数据包中为特定密钥选择固定值来定义的。
All the packets that go from a customer network 192.0.2.0/26 to another customer network 192.0.2.64/26 with DSCP value of 4 define a Flow. All other combinations don't define a Flow and are not taken
DSCP值为4的从客户网络192.0.2.0/26到另一客户网络192.0.2.64/26的所有数据包定义一个流。所有其他组合不定义流，也不采用
into account. The three Flows from Example 2 would now be reduced to one Flow by filtering out Flows 2 and 3, leaving only Flow 1, {192.0.2.0/26, 192.0.2.64/26, 4}.
考虑到。现在，通过过滤掉流2和3，将来自示例2的三个流减少为一个流，只留下流1，{192.0.2.0/26，192.0.2.64/26，4}。
Similarly, for the IPv6 packets in the examples above, one could filter out Flows 5 and 6 to leave Flow 4.
类似地，对于上面示例中的IPv6分组，可以过滤掉流5和6以保留流4。
The above examples can be thought of as a function F() taking as input {source IP address, destination IP address, DSCP}. The function selects only the packets that satisfy all three of the following conditions:
上面的例子可以看作是一个函数F（），它以{源IP地址，目标IP地址，DSCP}作为输入。该函数仅选择满足以下三个条件的数据包：
1. Mask out the least significant 6 bits of source IP address, match against 192.0.2.0.
1. 屏蔽源IP地址的最低有效6位，与192.0.2.0匹配。
2. Mask out the least significant 6 bits of destination IP address, match against 192.0.2.64.
2. 屏蔽目标IP地址的最低有效6位，与192.0.2.64匹配。
3. Only accept DSCP value equal to 4.
3. 仅接受等于4的DSCP值。
Depending on the values of {source IP address, destination IP address, DSCP} of the different observed packets, the Metering Process function F() would choose/filter/aggregate different sets of packets, which would create different Flows. For example, for various combinations of values of {source IP address, destination IP address, DSCP}, F(source IP address, destination IP address, DSCP) would result in the definition of one or more Flows.
根据不同观测数据包的{源IP地址、目标IP地址、DSCP}的值，计量处理函数F（）将选择/过滤/聚合不同的数据包集，这将创建不同的流。例如，对于{source IP address，destination IP address，DSCP}，F（source IP address，destination IP address，DSCP）的值的各种组合将导致一个或多个流的定义。
The figure below shows the reference model for IPFIX. This figure covers the various possible scenarios that can exist in an IPFIX system.
下图显示了IPFIX的参考模型。此图涵盖了IPFIX系统中可能存在的各种场景。
+----------------+ +----------------+
|[*Application 1]| ... |[*Application n]|
+--------+-------+ +-------+--------+
^ ^
| |
+ = = = = -+- = = = = +
^
|
+------------------------+ +-------+------------------+
|IPFIX Exporter | | Collector(1) |
|[Exporting Process(es)] |<---------->| [Collecting Process(es)] |
+------------------------+ +--------------------------+
.... ....
+------------------------+ +---------------------------+
|IPFIX Device(i) | | Collector(j) |
|[Observation Point(s)] |<--------->| [Collecting Process(es)] |
|[Metering Process(es)] | +---->| [*Application(s)] |
|[Exporting Process(es)] | | +---------------------------+
+------------------------+ .
.... . ....
+------------------------+ | +--------------------------+
|IPFIX Device(m) | | | Collector(n) |
|[Observation Point(s)] |<----+---->| [Collecting Process(es)] |
|[Metering Process(es)] | | [*Application(s)] |
|[Exporting Process(es)] | +--------------------------+
+------------------------+
+----------------+ +----------------+
|[*Application 1]| ... |[*Application n]|
+--------+-------+ +-------+--------+
^ ^
| |
+ = = = = -+- = = = = +
^
|
+------------------------+ +-------+------------------+
|IPFIX Exporter | | Collector(1) |
|[Exporting Process(es)] |<---------->| [Collecting Process(es)] |
+------------------------+ +--------------------------+
.... ....
+------------------------+ +---------------------------+
|IPFIX Device(i) | | Collector(j) |
|[Observation Point(s)] |<--------->| [Collecting Process(es)] |
|[Metering Process(es)] | +---->| [*Application(s)] |
|[Exporting Process(es)] | | +---------------------------+
+------------------------+ .
.... . ....
+------------------------+ | +--------------------------+
|IPFIX Device(m) | | | Collector(n) |
|[Observation Point(s)] |<----+---->| [Collecting Process(es)] |
|[Metering Process(es)] | | [*Application(s)] |
|[Exporting Process(es)] | +--------------------------+
+------------------------+
The various functional components are indicated within brackets [].
The functional components within [*] are not part of the IPFIX
architecture. The interfaces shown by "<----->" are defined by the
IPFIX architecture, but those shown by "<= = = =>" are not.
The various functional components are indicated within brackets [].
The functional components within [*] are not part of the IPFIX
architecture. The interfaces shown by "<----->" are defined by the
IPFIX architecture, but those shown by "<= = = =>" are not.
Figure 1: IPFIX Reference Model
图1:IPFIX参考模型
The figure below shows a typical IPFIX Device where the IPFIX components are shown in rectangular boxes.
下图显示了一个典型的IPFIX设备，其中IPFIX组件显示在矩形框中。
+--------------------------------------------------+
| IPFIX Device |
| +-----+ |
| +------- ... ------------+---------> | |
| | | | | |
| +----+----+ +----+----+ | | |
| |Metering | |Metering | | E | |
| |Process 1| |Process N| | x | |
| +---------+ +---------+ | p | |
| ^ ^ | o | |
| +------+--------+ +---------+------+ | r | |
| | Obsv Domain 1 | | Obsv Domain N | | t | |
| |+-----+-------+| |+-------+------+| | i | |
| ||Obsv Pt 1..j || ... ||Obsv Pt j+1..M|| | n | |
| |+-------------+| |+--------------+| | g | | Export
Packets | +------^--------+ +---------^------+ | | | packets
--->----+--------+---------- ... ---------+ | | | to
In | | +--------->
| . . . . . | | |Collector
| | | |
| +------ ... -------------+---------> | |
| | | | | |
| +----+----+ +----+----+ | P | |
| |Metering | |Metering | | r | |
| |Process 1| |Process N| | o | |
| +---------+ +---------+ | c | |
| ^ ^ | e | |
| +------+--------+ +---------+------+ | s | |
| | Obsv Domain 1 | | Obsv Domain N | | s | |
| |+-----+-------+| |+-------+------+| | | |
| ||Obsv Pt 1..k || ... ||Obsv Pt k+1..M|| | | |
| |+-------------+| |+--------------+| | | |
Packets | +------^--------+ +---------^------+ +-----+ |
--->----+--------+---------- ... ---------+ |
In | |
+--------------------------------------------------+
+--------------------------------------------------+
| IPFIX Device |
| +-----+ |
| +------- ... ------------+---------> | |
| | | | | |
| +----+----+ +----+----+ | | |
| |Metering | |Metering | | E | |
| |Process 1| |Process N| | x | |
| +---------+ +---------+ | p | |
| ^ ^ | o | |
| +------+--------+ +---------+------+ | r | |
| | Obsv Domain 1 | | Obsv Domain N | | t | |
| |+-----+-------+| |+-------+------+| | i | |
| ||Obsv Pt 1..j || ... ||Obsv Pt j+1..M|| | n | |
| |+-------------+| |+--------------+| | g | | Export
Packets | +------^--------+ +---------^------+ | | | packets
--->----+--------+---------- ... ---------+ | | | to
In | | +--------->
| . . . . . | | |Collector
| | | |
| +------ ... -------------+---------> | |
| | | | | |
| +----+----+ +----+----+ | P | |
| |Metering | |Metering | | r | |
| |Process 1| |Process N| | o | |
| +---------+ +---------+ | c | |
| ^ ^ | e | |
| +------+--------+ +---------+------+ | s | |
| | Obsv Domain 1 | | Obsv Domain N | | s | |
| |+-----+-------+| |+-------+------+| | | |
| ||Obsv Pt 1..k || ... ||Obsv Pt k+1..M|| | | |
| |+-------------+| |+--------------+| | | |
Packets | +------^--------+ +---------^------+ +-----+ |
--->----+--------+---------- ... ---------+ |
In | |
+--------------------------------------------------+
Figure 2: IPFIX Device
图2:IPFIX设备
Every Observation Point in an IPFIX Device, participating in Flow measurements, must be associated with at least one Metering Process. Every packet coming into an Observation Point goes into each of the Metering Processes associated with the Observation Point. Broadly, each Metering Process observes the packets that pass an Observation Point, does timestamping, and classifies the packets into Flow(s) based on the selection criteria.
IPFIX设备中参与流量测量的每个观测点必须至少与一个计量过程相关联。进入观察点的每个包进入与该观察点相关联的每个计量过程。大体上，每个计量过程观察通过观察点的分组，进行时间戳，并基于选择标准将分组分类为流。
The Metering Process is a functional block that manages all the Flows generated from an Observation Domain. The typical functions of a Metering Process may include:
计量过程是一个功能块，用于管理从观测域生成的所有流。计量过程的典型功能可能包括：
o Maintaining database(s) of all the Flow Records from an Observation Domain. This includes creating new Flow Records, updating existing ones, computing Flow Records statistics, deriving further Flow properties, and adding non-Flow-specific information based on the packet treatment (in some cases, fields like AS numbers, router state, etc.)
o 维护观测域中所有流量记录的数据库。这包括创建新的流记录、更新现有的流记录、计算流记录统计信息、导出进一步的流属性，以及基于数据包处理（在某些情况下，如数字、路由器状态等字段）添加非流特定信息
o Maintaining statistics about the Metering Process itself, such as Flow Records generated, packets observed, etc.
o 维护计量过程本身的统计信息，如生成的流量记录、观察到的数据包等。
A Flow is considered to have expired under the following conditions:
在以下条件下，流量被视为已过期：
1. If no packets belonging to the Flow have been observed for a certain period of time. This time period should be configurable at the Metering Process, with a minimum value of 0 seconds for immediate expiration. Note that a zero timeout would report a Flow as a sequence of single-packet Flows.
1. 如果在一段时间内没有观察到属于该流的数据包。该时间段应可在计量过程中配置，最小值为0秒，以便立即到期。请注意，零超时会将流报告为单个数据包流的序列。
2. If the IPFIX Device experiences resource constraints, a Flow may be prematurely expired (e.g., lack of memory to store Flow Records).
2. 如果IPFIX设备遇到资源限制，则流可能会提前过期（例如，缺少存储流记录的内存）。
3. For long-running Flows, the Metering Process should expire the Flow on a regular basis or based on some expiration policy. This periodicity or expiration policy should be configurable at the Metering Process. When a long-running Flow is expired, its Flow Record may still be maintained by the Metering Process so that the Metering Process does not need to create a new Flow Record for further observed packets of the same Flow.
3. 对于长时间运行的流，计量过程应该定期或基于某些过期策略使流过期。应在计量过程中配置此周期或到期策略。当长时间运行的流过期时，其流记录仍可由计量过程维护，以便计量过程不需要为相同流的进一步观察的分组创建新的流记录。
The Exporting Process decides when and whether to export an expired Flow. A Flow can be exported because it expired for any of the reasons mentioned in Section 5.1.1, "Flow Expiration". For example: the Exporting Process exports a portion of the expired Flows every 'x' seconds.
导出过程决定何时以及是否导出过期流。流因第5.1.1节“流过期”中提到的任何原因而过期，因此可以导出流。例如：导出过程每“x”秒导出一部分过期流。
For long-lasting Flows, the Exporting Process should export the Flow Records on a regular basis or based on some export policy. This periodicity or export policy should be configurable at the Exporting Process.
对于长期流动，出口流程应定期或根据某些出口政策出口流动记录。此周期或导出策略应在导出过程中进行配置。
A Flow Record can be better analysed if the Observation Point from which it was measured is known. As such, it is recommended that IPFIX Devices send this information to Collectors. In cases where there is a single Observation Point or where the Observation Point information is not relevant, the Metering Process may choose not to add the Observation Point information to the Flow Records.
如果已知流量记录的观测点，则可以更好地分析流量记录。因此，建议IPFIX设备将此信息发送给收集器。如果存在单个观测点或观测点信息不相关，计量过程可选择不将观测点信息添加到流量记录中。
A Metering Process may define rules so that only certain packets within an incoming stream of packets are chosen for measurement at an Observation Point. This may be done by one of the two methods defined below or a combination of them, in either order. A combination of each of these methods can be adopted to select the packets, i.e., one can define a set of methods {F1, S1, F2, S2, S3} executed in a specified sequence at an Observation Point to select particular Flows.
计量过程可以定义规则，以便在观察点处仅选择入站分组流中的某些分组进行测量。这可以通过以下定义的两种方法中的一种或两种方法的组合（按任意顺序）来完成。可以采用这些方法中的每一种的组合来选择分组，即，可以定义一组方法{F1、S1、F2、S2、S3}，这些方法在观察点以指定顺序执行以选择特定流。
The figure below shows the operations that may be applied as part of a typical Metering Process.
下图显示了可作为典型计量过程一部分应用的操作。
+---------------------------+
| packet header capturing |
+---------------------------+
|
v
+---------------------------+
| timestamping |
+---------------------------+
|
v
+---------------> +
| |
| v
| +----------------------------------------------+
| | sampling Si (1:1 in case of no sampling) |
| +----------------------------------------------+
| |
| v
| +----------------------------------------------+
| | filtering Fi (select all when no criteria) |
| +----------------------------------------------+
| |
| v
+-----------------+
|
v
+---------------------------+
| Flows |
+---------------------------+
+---------------------------+
| packet header capturing |
+---------------------------+
|
v
+---------------------------+
| timestamping |
+---------------------------+
|
v
+---------------> +
| |
| v
| +----------------------------------------------+
| | sampling Si (1:1 in case of no sampling) |
| +----------------------------------------------+
| |
| v
| +----------------------------------------------+
| | filtering Fi (select all when no criteria) |
| +----------------------------------------------+
| |
| v
+-----------------+
|
v
+---------------------------+
| Flows |
+---------------------------+
Figure 3: Selection Criteria for Packets
图3：数据包的选择标准
Note that packets could be selected before or after any IP processing, i.e., before there is any IP checksum validation, IP filtering, etc., or after one or more of these steps. This has an impact on what kinds of traffic (or erroneous conditions) IPFIX can observe. It is recommended that packets are selected after their checksums have been verified.
请注意，可以在任何IP处理之前或之后选择数据包，即，在进行任何IP校验和验证、IP过滤等之前，或在这些步骤中的一个或多个之后选择数据包。这会影响IPFIX可以观察到的通信量（或错误情况）。建议在校验和验证后选择数据包。
A sampling function determines which packets within a stream of incoming packets are selected for measurement, i.e., packets that satisfy the sampling criteria for this Metering Process.
采样函数确定在传入分组流中选择哪些分组进行测量，即满足该计量过程的采样标准的分组。
Example: sample every 100th packet that was received at an Observation Point.
示例：在观察点每收到100个数据包进行采样。
Choosing all the packets is a special case where the sampling rate is 1:1.
选择所有数据包是采样率为1:1的特殊情况。
A Filter Function selects only those incoming packets that satisfy a function on fields defined by the packet header fields, fields obtained while doing the packet processing, or properties of the packet itself.
过滤函数仅选择满足由数据包头字段定义的字段、在进行数据包处理时获得的字段或数据包本身属性上的函数的那些传入数据包。
Example: Mask/Match of the fields that define a filter. A filter might be defined as {Protocol == TCP, Destination Port < 1024}.
示例：定义筛选器的字段的掩码/匹配。筛选器可以定义为{Protocol==TCP，目标端口<1024}。
Several such filters could be used in any sequence to select packets. Note that packets selected by a (sequence of) filter functions may be further classified by other filter functions, i.e., the selected packets may belong to several Flows, any or all of which are exported.
可以在任何序列中使用多个这样的过滤器来选择数据包。注意，由（一系列）过滤函数选择的分组可由其他过滤函数进一步分类，即，所选分组可属于多个流，其中任何或全部被导出。
The Observation Domain is a logical block that presents a single identity for a group of Observation Points within an IPFIX Device. Each {Observation Point, Metering Process} pair belongs to a single Observation Domain. An IPFIX Device could have multiple Observation Domains, each of which has a subset of the total set of Observation Points in it. Each Observation Domain must carry a unique ID within the context of an IPFIX Device. Note that in the case of multiple Observation Domains, a unique ID per Observation Domain must be transmitted as a parameter to the Exporting Function. That unique ID is referred to as the IPFIX Observation Domain ID.
观测域是一个逻辑块，为IPFIX设备内的一组观测点提供单一标识。每个{观测点，计量过程}对属于单个观测域。IPFIX设备可以有多个观测域，每个观测域中都有一组观测点的子集。在IPFIX设备的上下文中，每个观察域必须具有唯一的ID。请注意，在多个观察域的情况下，必须将每个观察域的唯一ID作为参数传输给导出函数。该唯一ID称为IPFIX观察域ID。
The Exporting Process is the functional block that sends data to one or more IPFIX Collectors using the IPFIX protocol. On one side, the Exporting Process interfaces with Metering Process(es) to get Flow Records; while on the other side, it talks to a Collecting Process on the Collector(s).
导出过程是使用IPFIX协议向一个或多个IPFIX采集器发送数据的功能块。一方面，输出过程与计量过程接口，以获取流量记录；而在另一端，它与收集器上的收集进程对话。
There may be additional rules defined within an Observation Domain so that only certain Flow Records are exported. This may be done by either one or a combination of Si and Fi, as described in Section 5.3, "Selection Criteria for Packets".
在观察域中可能定义了其他规则，以便仅导出某些流记录。如第5.3节“数据包选择标准”所述，这可以通过Si和Fi的一种或组合来实现。
Example: Only the Flow Records that meet the following selection criteria are exported:
示例：仅导出满足以下选择条件的流记录：
1. All Flow Records whose destination IP address matches {192.0.33.5}.
1. 目标IP地址与{192.0.33.5}匹配的所有流记录。
2. Every other (i.e., sampling rate 1 in 2) Flow Record whose destination IP address matches {192.0.11.30}.
2. 目标IP地址与{192.0.11.30}匹配的每隔一个（即采样率1/2）流记录。
Collecting Processes use a Flow Record's Template ID to interpret that Flow Record's Information Elements. To allow this, an IPFIX Exporter must ensure that an IPFIX Collector knows the Template ID for each incoming Flow Record. To interpret incoming Flow Records, an IPFIX Collector may also need to know the function F() that was used by the Metering Process for each Flow.
收集流程使用流记录的模板ID来解释该流记录的信息元素。为此，IPFIX导出器必须确保IPFIX收集器知道每个传入流记录的模板ID。要解释传入的流记录，IPFIX收集器可能还需要知道计量过程为每个流使用的函数F（）。
The functions of the Collecting Process must include:
收集过程的功能必须包括：
o Identifying, accepting, and decoding the IPFIX Messages from different <Exporting Process, Observation Domain> pairs.
o 识别、接受和解码来自不同<导出过程，观察域>对的IPFIX消息。
o Storing the Control Information and Flow Records received from an IPFIX Device.
o 存储从IPFIX设备接收的控制信息和流量记录。
At a high level, the Collecting Process:
在高层次上，收集过程：
1. Receives and stores the Control Information.
1. 接收并存储控制信息。
2. Decodes and stores the Flow Records using the Control Information.
2. 使用控制信息解码和存储流记录。
The figure below shows the functions performed in sequence by the various functional blocks in an IPFIX Device.
下图显示了IPFIX设备中各功能块按顺序执行的功能。
Packet(s) coming into Observation Point(s)
| |
v v
+----------------+-------------------------+ +-----+-------+
| Metering Process on an | | |
| Observation Point | | |
| | | |
| packet header capturing | | |
| | |...| Metering |
| timestamping | | Process N |
| | | | |
| +----->+ | | |
| | | | | |
| | sampling Si (1:1 in case of no | | |
| | | sampling) | | |
| | filtering Fi (select all when | | |
| | | no criteria) | | |
| +------+ | | |
| | | | |
| | Timing out Flows | | |
| | Handle resource overloads | | |
+--------|---------------------------------+ +-----|-------+
| |
Flow Records (identified by Observation Domain) Flow Records
| |
Packet(s) coming into Observation Point(s)
| |
v v
+----------------+-------------------------+ +-----+-------+
| Metering Process on an | | |
| Observation Point | | |
| | | |
| packet header capturing | | |
| | |...| Metering |
| timestamping | | Process N |
| | | | |
| +----->+ | | |
| | | | | |
| | sampling Si (1:1 in case of no | | |
| | | sampling) | | |
| | filtering Fi (select all when | | |
| | | no criteria) | | |
| +------+ | | |
| | | | |
| | Timing out Flows | | |
| | Handle resource overloads | | |
+--------|---------------------------------+ +-----|-------+
| |
Flow Records (identified by Observation Domain) Flow Records
| |
+---------+---------------------------------+
|
+--------------------|----------------------------------------------+
| | Exporting Process |
|+-------------------|-------------------------------------------+ |
|| v IPFIX Protocol | |
||+-----------------------------+ +----------------------------+| |
|||Rules for | |Functions || |
||| Picking/sending Templates | |-Packetise selected Control || |
||| Picking/sending Flow Records|->| & data Information into || |
||| Encoding Template & data | | IPFIX export packets. || |
||| Selecting Flows to export(*)| |-Handle export errors || |
||+-----------------------------+ +----------------------------+| |
|+----------------------------+----------------------------------+ |
| | |
| exported IPFIX Messages |
| | |
| +------------+-----------------+ |
| | Anonymise export packet(*) | |
| +------------+-----------------+ |
| | |
| +------------+-----------------+ |
| | Transport Protocol | |
| +------------+-----------------+ |
| | |
+-----------------------------+-------------------------------------+
|
v
IPFIX export packet to Collector
+---------+---------------------------------+
|
+--------------------|----------------------------------------------+
| | Exporting Process |
|+-------------------|-------------------------------------------+ |
|| v IPFIX Protocol | |
||+-----------------------------+ +----------------------------+| |
|||Rules for | |Functions || |
||| Picking/sending Templates | |-Packetise selected Control || |
||| Picking/sending Flow Records|->| & data Information into || |
||| Encoding Template & data | | IPFIX export packets. || |
||| Selecting Flows to export(*)| |-Handle export errors || |
||+-----------------------------+ +----------------------------+| |
|+----------------------------+----------------------------------+ |
| | |
| exported IPFIX Messages |
| | |
| +------------+-----------------+ |
| | Anonymise export packet(*) | |
| +------------+-----------------+ |
| | |
| +------------+-----------------+ |
| | Transport Protocol | |
| +------------+-----------------+ |
| | |
+-----------------------------+-------------------------------------+
|
v
IPFIX export packet to Collector
(*) indicates that the block is optional.
（*）表示该块是可选的。
Figure 4: IPFIX Device functional blocks
图4:IPFIX设备功能块
An IPFIX Device consists of a set of cooperating processes that implement the functional blocks described in the previous section. Alternatively, an IPFIX Device can be viewed simply as a network entity that implements the IPFIX protocol. At the IPFIX Device, the protocol functionality resides in the Exporting Process. The IPFIX Exporting Process gets Flow Records from a Metering Process, and sends them to the Collector(s).
IPFIX设备由一组协作进程组成，这些进程实现上一节中描述的功能块。或者，IPFIX设备可以简单地看作是实现IPFIX协议的网络实体。在IPFIX设备上，协议功能驻留在导出过程中。IPFIX导出进程从计量进程获取流记录，并将其发送到收集器。
At a high level, an IPFIX Device performs the following tasks:
在较高级别上，IPFIX设备执行以下任务：
1. Encodes Control Information into Templates.
1. 将控制信息编码到模板中。
2. Encodes packets observed at the Observation Points into Flow Records.
2. 将在观察点观察到的数据包编码为流记录。
3. Packetises the selected Templates and Flow Records into IPFIX Messages.
3. 将所选模板和流记录打包为IPFIX消息。
4. Sends IPFIX Messages to the Collector.
4. 向收集器发送IPFIX消息。
The IPFIX protocol communicates information from an IPFIX Exporter to an IPFIX Collector. That information includes not only Flow Records, but also information about the Metering Process. Such information (referred to as Control Information) includes details of the data fields in Flow Records. It may also include statistics from the Metering Process, such as the number of packets lost (i.e., not metered).
IPFIX协议将信息从IPFIX导出器传送到IPFIX收集器。该信息不仅包括流量记录，还包括有关计量过程的信息。此类信息（称为控制信息）包括流记录中数据字段的详细信息。它还可以包括来自计量过程的统计，例如丢失（即，未计量）的分组的数量。
For details of the IPFIX protocol, please refer to RFC 5101 [3].
有关IPFIX协议的详细信息，请参阅RFC 5101[3]。
The IP Flow Information eXport (IPFIX) protocol serves for transmitting information related to measured IP traffic over the Internet. The protocol specification in RFC 5101 [3] defines how Information Elements are transmitted. For Information Elements, it specifies the encoding of a set of basic data types. However, the list of fields that can be transmitted by the protocol, such as Flow attributes (source IP address, number of packets, etc.) and information about the Metering and Exporting Process (packet Observation Point, sampling rate, Flow timeout interval, etc.), is not specified in RFC 5101 [3]. Instead, it is defined in the IPFIX information model in RFC 5102 [2].
IP流信息导出（IPFIX）协议用于通过Internet传输与测量的IP流量相关的信息。RFC 5101[3]中的协议规范定义了信息元素的传输方式。对于信息元素，它指定一组基本数据类型的编码。然而，RFC 5101[3]中未规定协议可传输的字段列表，例如流属性（源IP地址、数据包数量等）以及有关计量和导出过程的信息（数据包观察点、采样率、流超时间隔等）。相反，它是在RFC 5102[2]中的IPFIX信息模型中定义的。
The information model provides a complete description of the properties of every IPFIX Information Element. It does this by specifying each element's name, Field Type, data type, etc., and providing a description of each element. Element descriptions give the semantics of the element, i.e., say how it is derived from a Flow or other information available within an IPFIX Device.
信息模型提供了每个IPFIX信息元素属性的完整描述。它通过指定每个元素的名称、字段类型、数据类型等并提供每个元素的描述来实现这一点。元素描述给出了元素的语义，即它是如何从IPFIX设备中的流或其他可用信息中派生出来的。
The following rules provide guidelines to be followed while encoding the Flow Records information:
以下规则提供了对流记录信息进行编码时应遵循的准则：
A Flow Record contains enough information so that the Collecting Process can identify the corresponding <Per-Flow Control Information, Configuration Control Information>.
流记录包含足够的信息，以便收集过程能够识别相应的<Per-Flow Control information，Configuration Control information>。
The Exporting Process encodes a given Information Element (as specified in RFC 5102 [2]), based on the encoding standards prescribed by RFC 5101 [3].
导出过程根据RFC 5101[3]规定的编码标准对给定信息元素（如RFC 5102[2]中规定）进行编码。
The following rules provide guidelines to be followed while encoding the Control Information:
以下规则提供了编码控制信息时应遵循的准则：
o Per-Flow Control Information should be encoded such that the Collecting Process can capture the structure and semantics of the corresponding Flow data for each of the Flow Records exported by the IPFIX Device.
o 每个流控制信息应进行编码，以便收集过程能够捕获IPFIX设备导出的每个流记录的相应流数据的结构和语义。
o Configuration Control Information is conveyed to a Collector so that its Collecting Process can capture the structure and semantics of the corresponding configuration data. The configuration data, which is also Control Information, should carry additional information on the Observation Domain within which the configuration takes effect.
o 配置控制信息被传送到收集器，以便其收集过程能够捕获相应配置数据的结构和语义。配置数据（也是控制信息）应包含配置生效的观测域的附加信息。
For example, sampling using the same sampling algorithm, say 1 in 100 packets, is configured on two Observation Points O1 and O2. The configuration in this case may be encoded as {ID, observation points (O1,O2), sampling algorithm, interval (1 in 100)}, where ID is the Observation Domain ID for the domain containing O1 and O2. The Observation Domain ID uniquely identifies this configuration, and must be sent within the Flow Records in order to be able to match the right configuration control information.
例如，在两个观察点O1和O2上配置使用相同采样算法的采样，例如100个包中的1个。这种情况下的配置可以被编码为{ID，观测点（O1，O2），采样算法，间隔（100中的1）}，其中ID是包含O1和O2的域的观测域ID。观察域ID唯一标识此配置，并且必须在流记录中发送，以便能够匹配正确的配置控制信息。
The Control Information is used by the Collecting Process to:
收集过程使用控制信息来：
o Decode and interpret Flow Records.
o 解码和解释流量记录。
o Understand the state of the Exporting Process.
o 了解导出过程的状态。
Sending Control Information from the Exporting Process in a timely and reliable manner is critical to the proper functioning of the IPFIX Collecting Process. The following approaches may be taken for the export of Control Information:
及时可靠地从导出流程发送控制信息对于IPFIX收集流程的正常运行至关重要。出口管制信息可采取以下方法：
1. Send all the Control Information pertaining to Flow Records prior to sending the Flow Records themselves. This includes any incremental changes to the definition of the Flow Records.
1. 在发送流记录之前，先发送与流记录相关的所有控制信息。这包括对流记录定义的任何增量更改。
2. Notify, on a near real-time basis, the state of the IPFIX Device to the Collecting Process. This includes all changes such as a configuration change that affects the Flow behaviour, changes to Exporting Process resources that alter export rates, etc., which the Collector needs to be aware of.
2. 以近乎实时的方式向采集进程通知IPFIX设备的状态。这包括收集器需要注意的所有更改，如影响流行为的配置更改、更改导出过程资源以改变导出速率等。
3. Since it is vital that a Collecting Process maintains accurate knowledge of the Exporter's state, the export of the Control Information should be done such that it reaches the Collector reliably. One way to achieve this is to send the Control Information over a reliable transport.
3. 由于收集过程保持对出口商状态的准确了解至关重要，因此控制信息的输出应确保其可靠地到达收集器。实现这一点的一种方法是通过可靠的传输发送控制信息。
From time to time, an IPFIX Device may not be able to observe all the packets reaching one of its Observation Points. This could occur if a Metering Process finds itself temporarily short of resources. For example, it might run out of packet buffers for IPFIX export.
有时，IPFIX设备可能无法观察到到达其观察点之一的所有数据包。如果计量过程发现自己暂时缺少资源，则可能发生这种情况。例如，它可能会耗尽IPFIX导出的数据包缓冲区。
In such situations, the IPFIX Device should attempt to count the number of packet losses that have occurred, and report them to its Collector(s). If it is not possible to count losses accurately, e.g., when transport layer (i.e., non-IPFIX) errors are detected, the IPFIX Device should report this fact, and perhaps indicate the time period during which some packets might not have been observed.
在这种情况下，IPFIX设备应尝试统计已发生的数据包丢失数量，并将其报告给其收集器。如果不可能准确地计算丢失，例如，当检测到传输层（即，非IPFIX）错误时，IPFIX设备应报告这一事实，并可能指示可能未观察到某些数据包的时间段。
When the IPFIX Working Group was chartered, there were existing common practices in the area of Flow export, for example, NetFlow, CRANE (Common Reliable Accounting for Network Element), LFAP (Light-weight Flow Admission Protocol), RTFM (Real-time Traffic Flow Measurement), etc. IPFIX's charter required the Working Group to consider those existing practices, and select the one that was the closest fit to the IPFIX requirements in RFC 3917 [1]. Additions or modifications would then be made to the selected protocol to fit it exactly into the IPFIX architecture.
IPFIX工作组成立时，流量输出领域存在现有的通用做法，例如NetFlow、CRANE（网元通用可靠计费）、LFAP（轻型流量准入协议）、RTFM（实时流量测量），IPFIX的宪章要求工作组考虑那些现有的实践，并选择最适合于RFC 3917（1）中的IpFIX要求的一个。然后对所选协议进行添加或修改，使其完全适合IPFIX体系结构。
The Working Group went through an extensive evaluation of the various existing protocols that were available, weighing the level of compliance with the requirements, and selected one of the candidates as the basis for the IPFIX protocol. For more details of the evaluation process, please see RFC 3955 [6].
工作组对现有的各种协议进行了广泛评估，权衡了遵守要求的程度，并选择了一个候选协议作为IPFIX协议的基础。有关评估过程的更多详细信息，请参阅RFC 3955[6]。
In the basis protocol, Flow Records are defined by Templates, where a Template is an ordered set of the Information Elements appearing in a Flow Record, together with their field sizes within those records.
在basis协议中，流记录由模板定义，其中模板是出现在流记录中的信息元素的有序集合，以及这些记录中的字段大小。
This approach provides the following advantages:
这种方法具有以下优点：
o Using the Template mechanism, new fields can be added to IPFIX Flow Records without changing the structure of the export record format.
o 使用模板机制，可以将新字段添加到IPFIX流记录中，而无需更改导出记录格式的结构。
o Templates that are sent to the Collecting Process carry structural information about the exported Flow Record fields. Therefore, if the Collector does not understand the semantics of new fields, it can ignore them, but still interpret the Flow Record.
o 发送到收集流程的模板包含有关导出的流记录字段的结构信息。因此，如果收集器不理解新字段的语义，它可以忽略它们，但仍然解释流记录。
o Because the template mechanism is flexible, it allows the export of only the required fields from the Flows to the Collecting Process. This helps to reduce the exported Flow data volume and possibly provide memory savings at the Exporting Process and Collecting Process. Sending only the required information can also reduce network load.
o 因为模板机制是灵活的，所以它只允许将所需字段从流导出到收集过程。这有助于减少导出的流数据量，并可能在导出过程和收集过程中节省内存。仅发送所需信息也可以减少网络负载。
The Collecting Process is responsible for:
收集过程负责：
1. Receiving and decoding Flow Records from the IPFIX Devices.
1. 从IPFIX设备接收和解码流记录。
2. Reporting on the loss of Flow Records sent to the Collecting Process by an IPFIX Exporting Process.
2. 报告IPFIX导出进程发送到收集进程的流记录丢失。
Complete details of the IPFIX protocol are given in RFC 5101 [3].
IPFIX协议的完整细节见RFC 5101[3]。
Applications that use the information collected by IPFIX may be Billing or Intrusion Detection sub-systems, etc. These applications may be an integral part of the Collecting Process, or they may be co-located with the Collecting Process. The way by which these applications interface with IPFIX systems to get the desired information is out of scope for this document.
使用IPFIX收集的信息的应用程序可能是计费或入侵检测子系统等。这些应用程序可能是收集过程的组成部分，也可能与收集过程位于同一位置。这些应用程序与IPFIX系统接口以获取所需信息的方式超出了本文档的范围。
As mentioned in RFC 3917 [1], an IPFIX Device must be able to transport its Control Information and Data Stream over a congestion-aware transport protocol.
如RFC 3917[1]所述，IPFIX设备必须能够通过拥塞感知传输协议传输其控制信息和数据流。
If the network in which the IPFIX Device and Collecting Process are located does not guarantee reliability, at least the Control Information should be exported over a reliable transport. The Data Stream may be exported over a reliable or unreliable transport protocol.
如果IPFIX设备和采集过程所在的网络不能保证可靠性，则至少应通过可靠的传输导出控制信息。数据流可以通过可靠或不可靠的传输协议导出。
Possible transport protocols include:
可能的传输协议包括：
o SCTP: Supports reliable and unreliable transport.
o SCTP：支持可靠和不可靠的传输。
o TCP: Provides reliable transport only.
o TCP：仅提供可靠的传输。
o UDP: Provides unreliable transport only. Network operators would need to avoid congestion by keeping traffic within their own administrative domains. For example, one could use a dedicated network (or Ethernet link) to carry IPFIX traffic from Exporter to Collector.
o UDP：仅提供不可靠的传输。网络运营商需要通过将流量保持在自己的管理域内来避免拥塞。例如，可以使用专用网络（或以太网链路）将IPFIX流量从导出器传输到收集器。
The transport connection (in the case of a connection-oriented protocol) is pre-configured between the IPFIX Device and the Collector. The IPFIX protocol does not provide any mechanism for configuring the Exporting and Collecting Processes.
在IPFIX设备和收集器之间预先配置传输连接（在面向连接的协议的情况下）。IPFIX协议不提供任何配置导出和收集过程的机制。
Once connected, an IPFIX Collector receives Control Information and uses that information to interpret Flow Records. The IPFIX Device should set a keepalive (e.g., the keepalive timeout in the case of TCP, the HEARTBEAT interval in the case of SCTP) to a sufficiently low value so that it can quickly detect a Collector failure. Note, however, that extremely short keepalive intervals can incorrectly abort the connection during transient periods of congestion. They can also cause some level of additional network load during otherwise idle periods.
一旦连接，IPFIX收集器将接收控制信息并使用该信息解释流记录。IPFIX设备应将keepalive（例如，TCP情况下的keepalive超时，SCTP情况下的心跳间隔）设置为足够低的值，以便能够快速检测收集器故障。但是，请注意，极短的保留间隔可能会在短暂的拥塞期间错误地中止连接。在其他空闲期间，它们还可能导致一定程度的额外网络负载。
Collector failure refers to the crash or restart of the Collecting Process or of the Collector itself. A Collector failure is detected at the IPFIX Device by the break in the connection-oriented transport protocol session; depending on the transport protocol, the connection timeout mechanisms differ. On detecting a keepalive timeout in a
收集器故障是指收集进程或收集器本身崩溃或重新启动。通过面向连接的传输协议会话中的中断，在IPFIX设备上检测到收集器故障；根据传输协议的不同，连接超时机制也不同。在服务器中检测keepalive超时
single Collector scenario, the IPFIX Device should stop sending Flow Records to the Collector and try to reestablish the transport connection. If Collecting Process failover is supported by the Exporting Process, backup session(s) may be opened in advance, and Control Information sent to the failover Collecting Process.
在单收集器情况下，IPFIX设备应停止向收集器发送流记录，并尝试重新建立传输连接。如果导出进程支持收集进程故障转移，则可以提前打开备份会话，并将控制信息发送到故障转移收集进程。
There could be one or more secondary Collectors with priority assigned to them. The primary Collector crash is detected at the IPFIX Device. On detecting loss of connectivity, the IPFIX Device opens a Data Stream with the secondary Collector of the next highest priority. If that secondary was not opened in advance, both the Control Information and Data Stream must be sent to it. That Collector might then become the primary, or the Exporting Process might try to reestablish the original session.
可能有一个或多个二级收集器具有分配给它们的优先级。在IPFIX设备上检测到主收集器崩溃。在检测到连接丢失时，IPFIX设备将打开一个具有次高优先级的辅助采集器的数据流。如果未提前打开该辅助服务器，则必须向其发送控制信息和数据流。然后，该收集器可能会成为主收集器，或者导出过程可能会尝试重新建立原始会话。
Configuring redundant Collectors is an alternative to configuring backup Collectors. In this model, all Collectors simultaneously receive the Control Information and Data Streams. Multiple {Control Information, Data Stream} pairs could be sent, each to a different Collector, from the same IPFIX Device. Since the IPFIX protocol requires a congestion-aware transport, achieving redundancy using multicast is not an option.
配置冗余收集器是配置备份收集器的替代方法。在该模型中，所有采集器同时接收控制信息和数据流。可以从同一IPFIX设备向不同的收集器发送多个{控制信息、数据流}对。由于IPFIX协议需要拥塞感知传输，因此使用多播实现冗余不是一个选项。
An IPFIX Device can generate, receive, and/or alter two special types of traffic, which are listed below.
IPFIX设备可以生成、接收和/或改变以下两种特殊类型的通信量。
Tunnel traffic:
隧道交通：
The IPFIX Device could be the head, midpoint, or end-point of a tunnel. In such cases, the IPFIX Device could be handling Generic Routing Encapsulation (GRE) [8], IPinIP [7], or Layer Two Tunneling Protocol version 3 [9] traffic.
IPFIX设备可以是隧道的头部、中点或终点。在这种情况下，IPFIX设备可以处理通用路由封装（GRE）[8]、IPinIP[7]或第二层隧道协议版本3[9]流量。
VPN traffic:
VPN流量：
The IPFIX Device could be a provider-edge device that receives traffic from customer sites belonging to different Virtual Private Networks.
IPFIX设备可以是提供商边缘设备，从属于不同虚拟专用网络的客户站点接收流量。
Similarly, IPFIX could be implemented on devices which perform one or more of the following special services:
类似地，IPFIX可以在执行以下一项或多项特殊服务的设备上实施：
o Explicitly drop packets. For example, a device that provides firewall service drops packets based on some administrative policy.
o 显式丢弃数据包。例如，提供防火墙服务的设备根据某些管理策略丢弃数据包。
o Alter the values of fields used as IPFIX Flow Keys of interest. For example, a device that provides NAT service can change the source and/or destination IP address.
o 更改用作感兴趣的IPFIX流键的字段的值。例如，提供NAT服务的设备可以更改源和/或目标IP地址。
In cases such as those listed above, there should be clear guidelines as to:
在上述情况下，应制定明确的指导方针：
o How and when to classify the packets as Flows in the IPFIX Device.
o 如何以及何时在IPFIX设备中将数据包分类为流。
o If multiple encapsulations are used to define Flows, how to convey the same fields (e.g., IP address) in different layers.
o 如果使用多个封装来定义流，那么如何在不同的层中传递相同的字段（例如，IP地址）。
o How to differentiate Flows based on different private domains. For example, overlapping IP addresses in Layer-3 VPNs.
o 如何根据不同的私有域区分流。例如，第3层VPN中的重叠IP地址。
o What extra information needs to be exported so that the Collector can make a clear interpretation of the received Flow Records.
o 需要导出哪些额外信息，以便收集器能够对接收到的流量记录进行清晰的解释。
Flow information can be used for various purposes, such as usage-based accounting, traffic profiling, traffic engineering, and intrusion detection. The security requirements may differ significantly for such applications. To be able to satisfy the security needs of various IPFIX users, an IPFIX system must provide different levels of security protection.
流信息可用于各种目的，例如基于使用情况的计费、流量分析、流量工程和入侵检测。此类应用的安全要求可能会有很大差异。为了能够满足不同IPFIX用户的安全需求，IPFIX系统必须提供不同级别的安全保护。
IPFIX data comprises Control Information and Data Streams generated by the IPFIX Device.
IPFIX数据包括IPFIX设备生成的控制信息和数据流。
The IPFIX data may exist in both the IPFIX Device and the Collector. In addition, the data is also transferred on the wire from the IPFIX Device to the Collector when it is exported. To provide security, the data should be protected from common network attacks.
IPFIX数据可能同时存在于IPFIX设备和收集器中。此外，数据在导出时还通过导线从IPFIX设备传输到采集器。为了提供安全性，应保护数据免受常见网络攻击。
The protection of IPFIX data within the end system (IPFIX Device and Collector) is out of scope for this document. It is assumed that the end system operator will provide adequate security for the IPFIX data.
终端系统（IPFIX设备和采集器）内IPFIX数据的保护不在本文档范围内。假定终端系统操作员将为IPFIX数据提供足够的安全性。
The IPFIX architecture must allow different levels of protection to the IPFIX data on the wire. Wherever security functions are required, it is recommended that users should leverage lower layers using either TLS or DTLS (Datagram Transport Layer Security), if these can successfully satisfy the security requirement of IPFIX data protection.
IPFIX体系结构必须允许对线路上的IPFIX数据进行不同级别的保护。如果需要安全功能，建议用户使用TLS或DTL（数据报传输层安全性）利用较低的层，前提是这些层能够成功满足IPFIX数据保护的安全要求。
To protect the data on the wire, three levels of granularity should be supported; these are described in the following subsections.
为了保护线路上的数据，应支持三级粒度；以下各小节将对此进行说明。
Security may not be required when the transport between the IPFIX Device and the Collector is perceived as safe. This option allows the protocol to run most efficiently without extra overhead, and an IPFIX system must support it.
当IPFIX设备和收集器之间的传输被认为是安全的时，可能不需要安全性。此选项允许协议在没有额外开销的情况下最高效地运行，IPFIX系统必须支持此选项。
Authentication-only protection provides IPFIX users with the assurance of data integrity and authenticity. The data exchanged between the IPFIX Device and the Collector is protected by an authentication signature. Any modification of the IPFIX data will be detected by the recipient, resulting in the discarding of the received data. However, the authentication-only option doesn't offer data confidentiality.
仅限身份验证的保护为IPFIX用户提供了数据完整性和真实性的保证。IPFIX设备和收集器之间交换的数据受身份验证签名保护。接收方将检测到对IPFIX数据的任何修改，从而丢弃接收到的数据。但是，仅身份验证选项不提供数据机密性。
The IPFIX user should not use authentication-only when sensitive or confidential information is being exchanged. An IPFIX solution should support this option. The authentication-only option should provide replay attack protection. Some means to achieve this level of security are:
IPFIX用户不应仅在交换敏感或机密信息时使用身份验证。IPFIX解决方案应支持此选项。仅身份验证选项应提供重播攻击保护。实现此安全级别的一些方法包括：
o Encapsulating Security Payload (with a null encryption algorithm)
o 封装安全有效负载（使用空加密算法）
o Transport Layer Security (with a null encryption algorithm)
o 传输层安全性（使用空加密算法）
o IP Authentication Header
o IP认证头
Data encryption provides the best protection for IPFIX data. The IPFIX data is encrypted at the sender, and only the intended recipient can decrypt and have access to the data. This option must be used when the transport between the IPFIX Device and the Collector is unsafe, and the IPFIX data needs to be protected. It is
数据加密为IPFIX数据提供了最佳保护。IPFIX数据在发送方进行加密，只有预期的接收方才能解密并访问数据。当IPFIX设备和收集器之间的传输不安全，并且需要保护IPFIX数据时，必须使用此选项。它是
recommended that the underlying transport layer's security functions be used for this purpose. Some means to achieve this level of security are:
建议为此目的使用底层传输层的安全功能。实现此安全级别的一些方法包括：
o Encapsulating Security Payload
o 封装安全有效负荷
o Transport Layer Security Protocol
o 传输层安全协议
The data encryption option adds overhead to the IPFIX data transfer. It may limit the rate that an Exporter can report its Flow Records to the Collector, due to the resource requirement for running encryption.
数据加密选项增加了IPFIX数据传输的开销。由于运行加密的资源需求，它可能会限制导出程序向收集器报告其流记录的速率。
It is important to make sure that the IPFIX Device is talking to the "right" Collector rather than to a masquerading Collector. The same logic also holds true from the Collector's point of view, i.e., it may want to make sure it is collecting the Flow Records from the "right" IPFIX Device. An IPFIX system should allow the end-point authentication capability so that either one-way or mutual authentication can be performed between the IPFIX Device and Collector.
务必确保IPFIX设备与“正确”的采集器而不是伪装采集器通信。从收集器的角度来看，同样的逻辑也适用，即，它可能希望确保从“正确”的IPFIX设备收集流记录。IPFIX系统应允许端点身份验证功能，以便在IPFIX设备和收集器之间执行单向或双向身份验证。
The IPFIX architecture should use any existing transport protection protocols, such as TLS, to fulfil the authentication requirement.
IPFIX体系结构应使用任何现有的传输保护协议（如TLS）来满足身份验证要求。
An IPFIX Device could become overloaded under various conditions. This may be because of exhaustion of internal resources used for Flow generation and/or export. Such overloading may cause loss of data from the Exporting Process, either from lack of export bandwidth (possibly caused by an unusually high number of observed Flows) or from network congestion in the path from Exporter to Collector.
IPFIX设备可能在各种情况下过载。这可能是因为用于流生成和/或导出的内部资源耗尽。这种过载可能会导致导出过程中的数据丢失，原因可能是缺少导出带宽（可能是由于观察到的流量异常多）或从导出器到收集器的路径中的网络拥塞。
IPFIX Collectors should be able to detect the loss of exported Flow Records, and should at least record the number of lost Flow Records.
IPFIX收集器应该能够检测导出流记录的丢失，并且至少应该记录丢失流记录的数量。
Since one of the potential usages for IPFIX is for intrusion detection, it is important for the IPFIX architecture to support some kind of DoS resistance.
由于IPFIX的潜在用途之一是用于入侵检测，因此IPFIX体系结构支持某种DoS抵抗非常重要。
The network itself may be under attack, resulting in an overwhelming number of IPFIX Messages. An IPFIX system should try to capture as much information as possible. However, when a large number of IPFIX Messages are generated in a short period of time, the IPFIX system may become overloaded.
网络本身可能受到攻击，导致大量IPFIX消息。IPFIX系统应尽可能多地捕获信息。但是，当在短时间内生成大量IPFIX消息时，IPFIX系统可能会过载。
The IPFIX Device and Collector may be subject to generic DoS attacks, just as any system on any open network. These types of attacks are not IPFIX specific. Preventing and responding to such types of attacks are out of the scope of this document.
就像任何开放网络上的任何系统一样，IPFIX设备和收集器可能受到一般DoS攻击。这些类型的攻击不是特定于IPFIX的。防止和响应此类攻击不在本文档的范围内。
There are some specific attacks on the IPFIX portion of the IPFIX Device or Collector:
IPFIX设备或收集器的IPFIX部分存在一些特定攻击：
o The attacker could overwhelm the Collector with spoofed IPFIX Export packets. One way to solve this problem is to periodically synchronise the sequence numbers of the Flow Records between the Exporting and Collecting Processes.
o 攻击者可以使用伪造的IPFIX导出数据包来淹没收集器。解决此问题的一种方法是在导出和收集过程之间定期同步流记录的序列号。
o The attacker could provide false reports to the Collector by sending spoofed packets.
o 攻击者可以通过发送伪造的数据包向收集器提供虚假报告。
The problems mentioned above can be solved to a large extent if the control packets are encrypted both ways, thereby providing more information that the Collector could use to identify and ignore spoofed data packets.
如果控制分组以两种方式进行加密，则上述问题可以在很大程度上得到解决，从而提供收集器可用于识别和忽略伪造数据分组的更多信息。
The IPFIX Architecture, as set out in this document, has two sets of assigned numbers, as outlined in the following subsections.
如本文档所述，IPFIX体系结构有两组分配编号，如下小节所述。
IPFIX Messages, as described in RFC 5101 [3], use two fields with assigned values. These are the IPFIX Version Number, indicating which version of the IPFIX Protocol was used to export an IPFIX Message, and the IPFIX Set ID, indicating the type for each set of information within an IPFIX Message.
如RFC 5101[3]所述，IPFIX消息使用两个具有赋值的字段。这些是IPFIX版本号，指示用于导出IPFIX消息的IPFIX协议的哪个版本，以及IPFIX集合ID，指示IPFIX消息中每组信息的类型。
Values for the IPFIX Version Number and the IPFIX Set ID, together with the considerations for assigning them, are defined in RFC 5101 [3].
IPFIX版本号和IPFIX集合ID的值以及分配它们的注意事项在RFC 5101[3]中定义。
Fields of the IPFIX protocol carry information about traffic measurement. They are modelled as elements of the IPFIX information model RFC 5102 [2]. Each Information Element describes a field that may appear in an IPFIX Message. Within an IPFIX Message, the field type is indicated by its Field Type.
IPFIX协议的字段携带有关流量测量的信息。它们被建模为IPFIX信息模型RFC 5102[2]的元素。每个信息元素描述一个可能出现在IPFIX消息中的字段。在IPFIX消息中，字段类型由其字段类型指示。
Values for the IPFIX Information Element IDs, together with the considerations for assigning them, are defined in RFC 5102 [2].
IPFIX信息元素ID的值以及分配它们的注意事项在RFC 5102[2]中定义。
The document editors wish to thank all the people contributing to the discussion of this document on the mailing list, and the design teams for many valuable comments. In particular, the following made significant contributions:
文档编辑希望感谢所有在邮件列表中参与讨论本文档的人员，以及设计团队提出的许多宝贵意见。特别是，以下方面作出了重大贡献：
Tanja Zseby Paul Calato Dave Plonka Jeffrey Meyer K.C.Norseth Vamsi Valluri Cliff Wang Ram Gopal Jc Martin Carter Bullard Reinaldo Penno Simon Leinen Kevin Zhang Paul Aitken Brian Trammell
Tanja Zseby Paul Calato Dave Plonka Jeffrey Meyer K.C.Norseth Vamsi Valluri Cliff Wang Ram Gopal Jc Martin Carter Bullard Reinaldo Penno Simon Leinen Kevin Zhang Paul Aitken Brian Trammell
Special thanks to Dave Plonka for the multiple thorough reviews.
特别感谢Dave Plonka的多次全面审查。
[1] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[1] Quittek，J.，Zseby，T.，Claise，B.，和S.Zander，“IP流信息导出（IPFIX）的要求”，RFC 39172004年10月。
[2] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information for Model IP Flow Information Export", RFC 5102, January 2008.
[2] Quittek，J.，Bryant，S.，Claise，B.，Aitken，P.，和J.Meyer，“模型IP流信息导出的信息”，RFC 5102，2008年1月。
[3] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[3] Claise，B.，“IP流量信息交换的IP流量信息导出（IPFIX）协议规范”，RFC 5101，2008年1月。
[4] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", RFC 5472, March 2009.
[4] Zseby，T.，Boschi，E.，Brownlee，N.，和B.Claise，“IPFIX适用性”，RFC 54722009年3月。
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[5] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[6] Leinen, S., "Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)", RFC 3955, October 2004.
[6] Leinen，S.，“IP流信息导出（IPFIX）候选协议的评估”，RFC 3955，2004年10月。
[7] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[7] 辛普森，W.，“IP隧道中的IP”，RFC 1853，1995年10月。
[8] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[8] Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[9] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[9] Lau，J.，Townsley，M.，和I.Goyret，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
Authors' Addresses
作者地址
Ganesh Sadasivan Rohati Systems 1192 Borregas Ave. Sunnyvale, CA 94089 USA
美国加利福尼亚州桑尼维尔Borregas大道1192号Ganesh Sadasivan Rohati Systems，邮编94089
EMail: gsadasiv@rohati.com
EMail: gsadasiv@rohati.com
Nevil Brownlee CAIDA | The University of Auckland Private Bag 92019 Auckland 1142 New Zealand
Nevil Brownlee CAIDA·奥克兰大学私人包92019奥克兰1142新西兰
Phone: +64 9 373 7599 x88941
EMail: n.brownlee@auckland.ac.nz
Phone: +64 9 373 7599 x88941
EMail: n.brownlee@auckland.ac.nz
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium
Benoit Claise Cisco Systems，Inc.De Kleetlaan 6a b1 1831 Diegem比利时
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Juergen Quittek NEC Laboratories Europe, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Juergen Quittek NEC Laboratories Europe，NEC Europe Ltd.Kurfuersten Anlage 36德国海德堡69115
Phone: +49 6221 4342-115
EMail: quittek@nw.neclab.eu
URI: http://www.neclab.eu/
Phone: +49 6221 4342-115
EMail: quittek@nw.neclab.eu
URI: http://www.neclab.eu/