Network Working Group B. Claise, Ed.
Request for Comments: 5101 Cisco Systems, Inc.
Category: Standards Track January 2008
Network Working Group B. Claise, Ed.
Request for Comments: 5101 Cisco Systems, Inc.
Category: Standards Track January 2008
Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
用于交换IP流量信息的IP流量信息导出（IPFIX）协议规范
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process.
本文档规定了IP流量信息导出（IPFIX）协议，该协议用于通过网络传输IP流量信息。为了将IP业务流信息从导出过程传输到信息收集过程，需要流数据的通用表示和通信它们的标准方式。本文档描述了IPFIX数据和模板记录如何通过多个传输协议从IPFIX导出过程传输到IPFIX收集过程。
Table of Contents
目录
1. Introduction ....................................................3
1.1. IPFIX Documents Overview ...................................4
2. Terminology .....................................................4
2.1. Terminology Summary Table ..................................9
3. IPFIX Message Format ...........................................10
3.1. Message Header Format .....................................11
3.2. Field Specifier Format ....................................13
3.3. Set and Set Header Format .................................14
3.3.1. Set Format .........................................14
3.3.2. Set Header Format ..................................15
3.4. Record Format .............................................16
3.4.1. Template Record Format .............................16
3.4.2. Options Template Record Format .....................18
3.4.2.1. Scope .....................................19
3.4.2.2. Options Template Record Format ............20
3.4.3. Data Record Format .................................22
4. Specific Reporting Requirements ................................23
4.1. The Metering Process Statistics Option Template ...........23
1. Introduction ....................................................3
1.1. IPFIX Documents Overview ...................................4
2. Terminology .....................................................4
2.1. Terminology Summary Table ..................................9
3. IPFIX Message Format ...........................................10
3.1. Message Header Format .....................................11
3.2. Field Specifier Format ....................................13
3.3. Set and Set Header Format .................................14
3.3.1. Set Format .........................................14
3.3.2. Set Header Format ..................................15
3.4. Record Format .............................................16
3.4.1. Template Record Format .............................16
3.4.2. Options Template Record Format .....................18
3.4.2.1. Scope .....................................19
3.4.2.2. Options Template Record Format ............20
3.4.3. Data Record Format .................................22
4. Specific Reporting Requirements ................................23
4.1. The Metering Process Statistics Option Template ...........23
4.2. The Metering Process Reliability Statistics Option
Template ..................................................24
4.3. The Exporting Process Reliability Statistics
Option Template ...........................................25
4.4. The Flow Keys Option Template .............................26
5. IPFIX Message Header "Export Time" and Flow Record Time ........27
6. Linkage with the Information Model .............................28
6.1. Encoding of IPFIX Data Types ..............................28
6.1.1. Integral Data Types ................................28
6.1.2. Address Types ......................................28
6.1.3. float32 ............................................28
6.1.4. float64 ............................................28
6.1.5. boolean ............................................28
6.1.6. string and octetarray ..............................28
6.1.7. dateTimeSeconds ....................................29
6.1.8. dateTimeMilliseconds ...............................29
6.1.9. dateTimeMicroseconds ...............................29
6.1.10.dateTimeNanoseconds.................................29
6.2. Reduced Size Encoding of Integer and Float Types ..........29
7. Variable-Length Information Element ............................30
8. Template Management ............................................31
9. The Collecting Process's Side ..................................34
10. Transport Protocol ............................................36
10.1. Transport Compliance and Transport Usage .................36
10.2. SCTP .....................................................37
10.2.1. Congestion Avoidance ..............................37
10.2.2. Reliability .......................................37
10.2.3. MTU ...............................................37
10.2.4. Exporting Process .................................38
10.2.4.1. Association Establishment ................38
10.2.4.2. Association Shutdown .....................38
10.2.4.3. Stream ...................................38
10.2.4.4. Template Management ......................39
10.2.5. Collecting Process ................................39
10.2.6. Failover ..........................................39
10.3. UDP ......................................................39
10.3.1. Congestion Avoidance ..............................39
10.3.2. Reliability .......................................40
10.3.3. MTU ...............................................40
10.3.4. Port Numbers ......................................40
10.3.5. Exporting Process .................................40
10.3.6. Template Management ...............................40
10.3.7. Collecting Process ................................41
10.3.8. Failover ..........................................42
10.4. TCP ......................................................42
10.4.1. Connection Management .............................42
10.4.1.1. Connection Establishment .................42
10.4.1.2. Graceful Connection Release ..............43
4.2. The Metering Process Reliability Statistics Option
Template ..................................................24
4.3. The Exporting Process Reliability Statistics
Option Template ...........................................25
4.4. The Flow Keys Option Template .............................26
5. IPFIX Message Header "Export Time" and Flow Record Time ........27
6. Linkage with the Information Model .............................28
6.1. Encoding of IPFIX Data Types ..............................28
6.1.1. Integral Data Types ................................28
6.1.2. Address Types ......................................28
6.1.3. float32 ............................................28
6.1.4. float64 ............................................28
6.1.5. boolean ............................................28
6.1.6. string and octetarray ..............................28
6.1.7. dateTimeSeconds ....................................29
6.1.8. dateTimeMilliseconds ...............................29
6.1.9. dateTimeMicroseconds ...............................29
6.1.10.dateTimeNanoseconds.................................29
6.2. Reduced Size Encoding of Integer and Float Types ..........29
7. Variable-Length Information Element ............................30
8. Template Management ............................................31
9. The Collecting Process's Side ..................................34
10. Transport Protocol ............................................36
10.1. Transport Compliance and Transport Usage .................36
10.2. SCTP .....................................................37
10.2.1. Congestion Avoidance ..............................37
10.2.2. Reliability .......................................37
10.2.3. MTU ...............................................37
10.2.4. Exporting Process .................................38
10.2.4.1. Association Establishment ................38
10.2.4.2. Association Shutdown .....................38
10.2.4.3. Stream ...................................38
10.2.4.4. Template Management ......................39
10.2.5. Collecting Process ................................39
10.2.6. Failover ..........................................39
10.3. UDP ......................................................39
10.3.1. Congestion Avoidance ..............................39
10.3.2. Reliability .......................................40
10.3.3. MTU ...............................................40
10.3.4. Port Numbers ......................................40
10.3.5. Exporting Process .................................40
10.3.6. Template Management ...............................40
10.3.7. Collecting Process ................................41
10.3.8. Failover ..........................................42
10.4. TCP ......................................................42
10.4.1. Connection Management .............................42
10.4.1.1. Connection Establishment .................42
10.4.1.2. Graceful Connection Release ..............43
10.4.1.3. Restarting Interrupted Connections .......43
10.4.1.4. Failover .................................43
10.4.2. Data Transmission .................................43
10.4.2.1. IPFIX Message Encoding ...................43
10.4.2.2. Template Management ......................44
10.4.2.3. Congestion Handling and Reliability ......44
10.4.3. Collecting Process ................................45
11. Security Considerations .......................................46
11.1. Applicability of TLS and DTLS ............................47
11.2. Usage ....................................................48
11.3. Authentication ...........................................48
11.4. Protection against DoS Attacks ...........................48
11.5. When DTLS or TLS Is Not an Option ........................50
11.6. Logging an IPFIX Attack ..................................50
11.7. Securing the Collector ...................................51
12. IANA Considerations ...........................................51
Appendix A. IPFIX Encoding Examples ...............................52
A.1. Message Header Example.....................................52
A.2. Template Set Examples......................................53
A.2.1. Template Set Using IETF-Specified Information
Elements ...........................................53
A.2.2. Template Set Using Enterprise-Specific Information
Elements ...........................................53
A.3. Data Set Example ..........................................55
A.4. Options Template Set Examples .............................56
A.4.1. Options Template Set Using IETF-Specified
Information Elements ...............................56
A.4.2. Options Template Set Using Enterprise-Specific
Information Elements ...............................56
A.4.3. Options Template Set Using an Enterprise-Specific
Scope ..............................................57
A.4.4. Data Set Using an Enterprise-Specific Scope ........58
A.5. Variable-Length Information Element Examples ..............59
A.5.1. Example of Variable-Length Information Element
with Length Inferior to 255 Octets .................59
A.5.2. Example of Variable-Length Information Element
with Length 255 to 65535 Octets ....................59
References ........................................................59
Normative References ...........................................59
Informative References .........................................60
Acknowledgments ...................................................61
10.4.1.3. Restarting Interrupted Connections .......43
10.4.1.4. Failover .................................43
10.4.2. Data Transmission .................................43
10.4.2.1. IPFIX Message Encoding ...................43
10.4.2.2. Template Management ......................44
10.4.2.3. Congestion Handling and Reliability ......44
10.4.3. Collecting Process ................................45
11. Security Considerations .......................................46
11.1. Applicability of TLS and DTLS ............................47
11.2. Usage ....................................................48
11.3. Authentication ...........................................48
11.4. Protection against DoS Attacks ...........................48
11.5. When DTLS or TLS Is Not an Option ........................50
11.6. Logging an IPFIX Attack ..................................50
11.7. Securing the Collector ...................................51
12. IANA Considerations ...........................................51
Appendix A. IPFIX Encoding Examples ...............................52
A.1. Message Header Example.....................................52
A.2. Template Set Examples......................................53
A.2.1. Template Set Using IETF-Specified Information
Elements ...........................................53
A.2.2. Template Set Using Enterprise-Specific Information
Elements ...........................................53
A.3. Data Set Example ..........................................55
A.4. Options Template Set Examples .............................56
A.4.1. Options Template Set Using IETF-Specified
Information Elements ...............................56
A.4.2. Options Template Set Using Enterprise-Specific
Information Elements ...............................56
A.4.3. Options Template Set Using an Enterprise-Specific
Scope ..............................................57
A.4.4. Data Set Using an Enterprise-Specific Scope ........58
A.5. Variable-Length Information Element Examples ..............59
A.5.1. Example of Variable-Length Information Element
with Length Inferior to 255 Octets .................59
A.5.2. Example of Variable-Length Information Element
with Length 255 to 65535 Octets ....................59
References ........................................................59
Normative References ...........................................59
Informative References .........................................60
Acknowledgments ...................................................61
A data network with IP traffic primarily consists of IP flows passing through the network elements. It is often interesting, useful, or even required to have access to information about these flows that pass through the network elements for administrative or other
具有IP流量的数据网络主要由通过网元的IP流组成。为了管理或其他目的，访问通过网络元素的这些流的信息通常是有趣的、有用的，甚至是必需的
purposes. The IPFIX Collecting Process should be able to receive the flow information passing through multiple network elements within the data network. This requires uniformity in the method of representing the flow information and the means of communicating the flows from the network elements to the collection point. This document specifies the protocol to achieve these aforementioned requirements. This document specifies in detail the representation of different flows, the additional data required for flow interpretation, packet format, transport mechanisms used, security concerns, etc.
目的。IPFIX采集过程应能够接收通过数据网络内多个网元的流量信息。这要求在表示流信息的方法和将流从网络元件传送到收集点的方式上具有一致性。本文件规定了实现上述要求的协议。本文档详细说明了不同流的表示、流解释所需的附加数据、数据包格式、使用的传输机制、安全问题等。
The IPFIX protocol provides network administrators with access to IP flow information. The architecture for the export of measured IP flow information out of an IPFIX Exporting Process to a Collecting Process is defined in [IPFIX-ARCH], per the requirements defined in [RFC3917]. This document specifies how IPFIX data records and templates are carried via a number of transport protocols from IPFIX Exporting Processes to IPFIX Collecting Processes. IPFIX has a formal description of IPFIX Information Elements, their name, type and additional semantic information, as specified in [RFC5102]. Finally, [IPFIX-AS] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks.
IPFIX协议为网络管理员提供了访问IP流信息的权限。根据[RFC3917]中定义的要求，[IPFIX-ARCH]中定义了将测量的IP流信息从IPFIX导出过程导出到收集过程的体系结构。本文档指定了如何通过多个传输协议将IPFIX数据记录和模板从IPFIX导出进程传送到IPFIX收集进程。IPFIX对IPFIX信息元素、它们的名称、类型和附加语义信息进行了正式描述，如[RFC5102]中所述。最后，[IPFIX-AS]描述了什么类型的应用程序可以使用IPFIX协议，以及它们如何使用提供的信息。它还展示了IPFIX框架与其他体系结构和框架的关系。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The definitions of the basic terms like IP Traffic Flow, Exporting Process, Collecting Process, Observation Points, etc. are semantically identical to those found in the IPFIX requirements document [RFC3917]. Some of the terms have been expanded for more clarity when defining the protocol. Additional terms required for the protocol have also been defined. Definitions in this document and in [IPFIX-ARCH] are equivalent, except that definitions that are only relevant to the IPFIX protocol only appear here.
IP流量、导出过程、收集过程、观测点等基本术语的定义在语义上与IPFIX需求文件[RFC3917]中的定义相同。为了在定义协议时更加清晰，对一些术语进行了扩展。还定义了议定书所需的其他术语。本文档和[IPFIX-ARCH]中的定义是等效的，但仅与IPFIX协议相关的定义仅出现在此处。
The terminology summary table in Section 2.1 gives a quick overview of the relationships between some of the different terms defined.
第2.1节中的术语汇总表快速概述了定义的一些不同术语之间的关系。
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 [RFC3550]).
1. 一个或多个数据包头字段（例如，目的地IP地址）、传输头字段（例如，目的地端口号）或应用程序头字段（例如，RTP头字段[RFC3550]）。
2. one or more characteristics of the packet itself (e.g., number of MPLS labels, etc...).
2. 数据包本身的一个或多个特征（例如，MPLS标签的数量等）。
3. one or more of fields derived from packet treatment (e.g., next hop IP address, the output interface, etc...).
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. belong to the packet header (e.g., destination IP address),
1. 属于数据包头（例如，目标IP地址），
2. are a property of the packet itself (e.g., packet length),
2. 是数据包本身的属性（例如，数据包长度），
3. are derived from packet treatment (e.g., Autonomous System (AS) number),
3. 来自数据包处理（例如，自治系统（AS）编号），
and that are used to define a Flow are termed Flow Keys.
用于定义流的被称为流键。
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进行唯一标识。
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消息封装在传输层。
Message Header
消息头
The Message Header is the first part of an IPFIX Message, which provides basic information about the message, such as the IPFIX version, length of the message, message sequence number, etc.
消息头是IPFIX消息的第一部分，它提供有关消息的基本信息，如IPFIX版本、消息长度、消息序列号等。
Template Record
模板记录
A Template Record defines the structure and interpretation of fields in a Data Record.
模板记录定义数据记录中字段的结构和解释。
Data Record
数据记录
A Data Record is a record that contains values of the parameters corresponding to a Template Record.
数据记录是包含与模板记录对应的参数值的记录。
Options Template Record
选项模板记录
An Options Template Record is a Template Record that defines the structure and interpretation of fields in a Data Record, including defining how to scope the applicability of the Data Record.
选项模板记录是定义数据记录中字段的结构和解释的模板记录，包括定义如何确定数据记录的适用范围。
Set
设置
Set is a generic term for a collection of records that have a similar structure. In an IPFIX Message, one or more Sets follow the Message Header.
集合是具有类似结构的记录集合的通用术语。在IPFIX消息中，消息头后面有一个或多个集合。
There are three different types of Sets: Template Set, Options Template Set, and Data Set.
有三种不同类型的集：模板集、选项模板集和数据集。
Template Set
模板集
A Template Set is a collection of one or more Template Records that have been grouped together in an IPFIX Message.
模板集是在IPFIX消息中分组在一起的一个或多个模板记录的集合。
Options Template Set
选项模板集
An Options Template Set is a collection of one or more Options Template Records that have been grouped together in an IPFIX Message.
选项模板集是在IPFIX消息中分组在一起的一个或多个选项模板记录的集合。
Data Set
数据集
A Data Set is one or more Data Records, of the same type, that are grouped together in an IPFIX Message. Each Data Record is previously defined by a Template Record or an Options Template Record.
数据集是在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 [RFC5102] 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信息模型[RFC5102]定义了IPFIX的基本信息元素集。与信息元素关联的类型指示对其可能包含的内容的约束，并确定在IPFIX中使用的有效编码机制。
Transport Session
运输会议
In Stream Control Transmission Protocol (SCTP), the transport session is known as the SCTP association, which is uniquely identified by the SCTP endpoints [RFC4960]; in TCP, the transport session is known as the TCP connection, which is uniquely identified by the combination of IP addresses and TCP ports used. In UDP, the transport session is known as the UDP session, which is uniquely identified by the combination of IP addresses and UDP ports used.
在流控制传输协议（SCTP）中，传输会话称为SCTP关联，由SCTP端点唯一标识[RFC4960]；在TCP中，传输会话称为TCP连接，它由IP地址和使用的TCP端口的组合唯一标识。在UDP中，传输会话称为UDP会话，它由所使用的IP地址和UDP端口的组合唯一标识。
+------------------+---------------------------------------------+
| | contents |
| +--------------------+------------------------+
| Set | Template | record |
+------------------+--------------------+------------------------+
| Data Set | / | Data Record(s) |
+------------------+--------------------+------------------------+
| Template Set | Template Record(s) | / |
+------------------+--------------------+------------------------+
| Options Template | Options Template | / |
| Set | Record(s) | |
+------------------+--------------------+------------------------+
+------------------+---------------------------------------------+
| | contents |
| +--------------------+------------------------+
| Set | Template | record |
+------------------+--------------------+------------------------+
| Data Set | / | Data Record(s) |
+------------------+--------------------+------------------------+
| Template Set | Template Record(s) | / |
+------------------+--------------------+------------------------+
| Options Template | Options Template | / |
| Set | Record(s) | |
+------------------+--------------------+------------------------+
Figure A: Terminology Summary Table
图A：术语汇总表
A Data Set is composed of Data Record(s). No Template Record is included. A Template Record or an Options Template Record defines the Data Record.
数据集由数据记录组成。不包括模板记录。模板记录或选项模板记录定义数据记录。
A Template Set contains only Template Record(s).
模板集仅包含模板记录。
An Options Template Set contains only Options Template Record(s).
选项模板集仅包含选项模板记录。
An IPFIX Message consists of a Message Header, followed by one or more Sets. The Sets can be any of the possible three types: Data Set, Template Set, or Options Template Set.
IPFIX消息由消息头和一个或多个集合组成。这些集合可以是三种类型中的任意一种：数据集、模板集或选项模板集。
The format of the IPFIX Message is shown in Figure B.
IPFIX消息的格式如图B所示。
+----------------------------------------------------+
| Message Header |
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
...
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
+----------------------------------------------------+
| Message Header |
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
...
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
Figure B: IPFIX Message Format
图B:IPFIX消息格式
The Exporter MUST code all binary integers of the Message Header and the different Sets in network-byte order (also known as the big-endian byte ordering).
导出器必须以网络字节顺序（也称为big-endian字节顺序）对消息头和不同集合的所有二进制整数进行编码。
Following are some examples of IPFIX Messages:
以下是IPFIX消息的一些示例：
1. An IPFIX Message consisting of interleaved Template, Data, and Options Template Sets -- A newly created Template is exported as soon as possible. So, if there is already an IPFIX Message with a Data Set that is being prepared for export, the Template and Option Template Sets are interleaved with this information, subject to availability of space.
1. IPFIX消息由交错模板、数据和选项模板集组成——新创建的模板将尽快导出。因此，如果已经有一条IPFIX消息，其中包含准备导出的数据集，则模板和选项模板集将根据可用空间与此信息交叉。
+--------+--------------------------------------------------------+
| | +----------+ +---------+ +-----------+ +---------+ |
|Message | | Template | | Data | | Options | | Data | |
| Header | | Set | | Set | ... | Template | | Set | |
| | | | | | | Set | | | |
| | +----------+ +---------+ +-----------+ +---------+ |
+--------+--------------------------------------------------------+
+--------+--------------------------------------------------------+
| | +----------+ +---------+ +-----------+ +---------+ |
|Message | | Template | | Data | | Options | | Data | |
| Header | | Set | | Set | ... | Template | | Set | |
| | | | | | | Set | | | |
| | +----------+ +---------+ +-----------+ +---------+ |
+--------+--------------------------------------------------------+
Figure C: IPFIX Message, Example 1
图C:IPFIX消息，示例1
2. An IPFIX Message consisting entirely of Data Sets -- After the appropriate Template Records have been defined and transmitted to the Collecting Process, the majority of IPFIX Messages consist solely of Data Sets.
2. 一个完全由数据集组成的IPFIX消息——在定义了适当的模板记录并将其传输到收集过程之后，大多数IPFIX消息都只由数据集组成。
+--------+----------------------------------------------+
| | +---------+ +---------+ +---------+ |
|Message | | Data | | Data | | Data | |
| Header | | Set | ... | Set | ... | Set | |
| | +---------+ +---------+ +---------+ |
+--------+----------------------------------------------+
+--------+----------------------------------------------+
| | +---------+ +---------+ +---------+ |
|Message | | Data | | Data | | Data | |
| Header | | Set | ... | Set | ... | Set | |
| | +---------+ +---------+ +---------+ |
+--------+----------------------------------------------+
Figure D: IPFIX Message, Example 2
图D:IPFIX消息，示例2
3. An IPFIX Message consisting entirely of Template and Options Template Sets.
3. 完全由模板和选项模板集组成的IPFIX消息。
+--------+-------------------------------------------------+
| | +----------+ +----------+ +----------+ |
|Message | | Template | | Template | | Options | |
| Header | | Set | ... | Set | ... | Template | |
| | | | | | | Set | |
| | +----------+ +----------+ +----------+ |
+--------+-------------------------------------------------+
+--------+-------------------------------------------------+
| | +----------+ +----------+ +----------+ |
|Message | | Template | | Template | | Options | |
| Header | | Set | ... | Set | ... | Template | |
| | | | | | | Set | |
| | +----------+ +----------+ +----------+ |
+--------+-------------------------------------------------+
Figure E: IPFIX Message, Example 3
图E:IPFIX消息，示例3
The format of the IPFIX Message Header is shown in Figure F.
IPFIX消息头的格式如图F所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure F: IPFIX Message Header Format
图F:IPFIX消息头格式
Message Header Field Descriptions:
消息头字段描述：
Version
版本
Version of Flow Record format exported in this message. The value of this field is 0x000a for the current version, incrementing by one the version used in the NetFlow services export version 9 [RFC3954].
在此消息中导出的流记录格式的版本。对于当前版本，此字段的值为0x000a，将NetFlow服务导出版本9[RFC3954]中使用的版本增加1。
Length
长
Total length of the IPFIX Message, measured in octets, including Message Header and Set(s).
IPFIX消息的总长度，以八位字节为单位，包括消息头和集合。
Export Time
导出时间
Time, in seconds, since 0000 UTC Jan 1, 1970, at which the IPFIX Message Header leaves the Exporter.
自1970年1月1日UTC 0000起，IPFIX消息头离开导出器的时间（秒）。
Sequence Number
序列号
Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent on this PR-SCTP stream from the current Observation Domain by the Exporting Process. Check the specific meaning of this field in the subsections of Section 10 when UDP or TCP is selected as the transport protocol. This value SHOULD be used by the Collecting Process to identify whether any IPFIX Data Records have been missed. Template and Options Template Records do not increase the Sequence Number.
导出进程从当前观测域在此PR-SCTP流上发送的所有IPFIX数据记录的增量序列计数器，模数为2^32。当选择UDP或TCP作为传输协议时，请检查第10节小节中此字段的具体含义。收集过程应使用此值来确定是否丢失了任何IPFIX数据记录。模板和选项模板记录不会增加序列号。
Observation Domain ID
观察域ID
A 32-bit identifier of the Observation Domain that is locally unique to the Exporting Process. The Exporting Process uses the Observation Domain ID to uniquely identify to the Collecting Process the Observation Domain that metered the Flows. It is RECOMMENDED that this identifier also be unique per IPFIX Device. Collecting Processes SHOULD use the Transport Session and the Observation Domain ID field to separate different export streams originating from the same Exporting Process. The Observation Domain ID SHOULD be 0 when no specific Observation Domain ID is relevant for the entire IPFIX Message, for example, when exporting the Exporting Process Statistics, or in case of a hierarchy of Collectors when aggregated Data Records are exported.
观察域的32位标识符，在本地对导出进程是唯一的。导出进程使用观察域ID向收集进程唯一标识测量流的观察域。建议每个IPFIX设备的此标识符也是唯一的。收集进程应使用传输会话和观察域ID字段来分离来自同一导出进程的不同导出流。如果没有特定的观察域ID与整个IPFIX消息相关，例如，在导出导出过程统计信息时，或者在导出聚合数据记录时，如果是收集器层次结构，则观察域ID应为0。
Vendors need the ability to define proprietary Information Elements, because, for example, they are delivering a pre-standards product, or the Information Element is, in some way, commercially sensitive. This section describes the Field Specifier format for both IETF-specified Information Elements [RFC5102] and enterprise-specific Information Elements.
供应商需要能够定义专有信息元素，因为，例如，他们正在交付预标准产品，或者信息元素在某种程度上具有商业敏感性。本节介绍IETF指定信息元素[RFC5102]和企业特定信息元素的字段说明符格式。
The Information Elements are identified by the Information Element identifier. When the Enterprise bit is set to 0, the corresponding Information Element identifier will report an IETF-specified Information Element, and the Enterprise Number MUST NOT be present. When the Enterprise bit is set to 1, the corresponding Information Element identifier will report an enterprise-specific Information Element; the Enterprise Number MUST be present. An example of this is shown in Section A.4.2.
信息元素由信息元素标识符标识。当企业位设置为0时，相应的信息元素标识符将报告IETF指定的信息元素，且企业编号不得存在。当企业位设置为1时，对应的信息元素标识符将报告企业特定的信息元素；企业编号必须存在。第A.4.2节给出了一个示例。
The Field Specifier format is shown in Figure G.
字段说明符格式如图G所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Information Element ident. | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Information Element ident. | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure G: Field Specifier Format
图G：字段说明符格式
Where:
哪里：
E
E
Enterprise bit. This is the first bit of the Field Specifier. If this bit is zero, the Information Element Identifier identifies an IETF-specified Information Element, and the four-octet Enterprise Number field MUST NOT be present. If this bit is one, the Information Element identifier identifies an enterprise-specific Information Element, and the Enterprise Number filed MUST be present.
企业比特。这是字段说明符的第一位。如果该位为零，则信息元素标识符标识IETF指定的信息元素，且四个八位字节的企业编号字段不得存在。如果该位为1，则信息元素标识符标识特定于企业的信息元素，并且必须存在企业编号字段。
Information Element identifier
信息元素标识符
A numeric value that represents the type of Information Element. Refer to [RFC5102].
表示信息元素类型的数值。请参阅[RFC5102]。
Field Length
场长
The length of the corresponding encoded Information Element, in octets. Refer to [RFC5102]. The field length may be smaller than the definition in [RFC5102] if the reduced size encoding is used (see Section 6.2). The value 65535 is reserved for variable-length Information Elements (see Section 7).
对应编码信息元素的长度，以八位字节为单位。请参阅[RFC5102]。如果使用缩小尺寸编码，则字段长度可能小于[RFC5102]中的定义（见第6.2节）。值65535保留用于可变长度信息元素（参见第7节）。
Enterprise Number
企业编号
IANA enterprise number [PEN] of the authority defining the Information Element identifier in this Template Record.
IANA在此模板记录中定义信息元素标识符的机构的企业编号[PEN]。
A Set is a generic term for a collection of records that have a similar structure. There are three different types of Sets: Template Sets, Options Template Sets, and Data Sets. Each of these Sets consists of a Set Header and one or more records. The Set Format and the Set Header Format are defined in the following sections.
集合是具有类似结构的记录集合的通用术语。有三种不同类型的集：模板集、选项模板集和数据集。这些集合中的每一个都由集合标题和一个或多个记录组成。集合格式和集合标题格式在以下部分中定义。
A Set has the format shown in Figure H. The record types can be either Template Records, Options Template Records, or Data Records. The record types MUST NOT be mixed within a Set.
集合的格式如图H所示。记录类型可以是模板记录、选项模板记录或数据记录。记录类型不能在一个集合中混合。
+--------------------------------------------------+
| Set Header |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
...
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| Padding (opt.) |
+--------------------------------------------------+
+--------------------------------------------------+
| Set Header |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
...
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| Padding (opt.) |
+--------------------------------------------------+
Figure H: Set Format
图H：集合格式
The Set Field Definitions are as follows:
集合字段定义如下所示：
Set Header
设置标题
The Set Header Format is defined in Section 3.3.2.
第3.3.2节定义了集合标题格式。
Record
记录
One of the record Formats: Template Record, Options Template Record, or Data Record Format.
记录格式之一：模板记录、选项模板记录或数据记录格式。
Padding
衬料
The Exporting Process MAY insert some padding octets, so that the subsequent Set starts at an aligned boundary. For security reasons, the padding octet(s) MUST be composed of zero (0) valued octets. The padding length MUST be shorter than any allowable record in this Set. If padding of the IPFIX Message is desired in combination with very short records, then the padding Information Element 'paddingOctets' [RFC5102] can be used for padding records such that their length is increased to a multiple of 4 or 8 octets. Because Template Sets are always 4-octet aligned by definition, padding is only needed in case of other alignments e.g., on 8-octet boundaries.
导出过程可能会插入一些填充八位字节，以便后续集合从对齐的边界开始。出于安全原因，填充八位字节必须由零（0）值八位字节组成。填充长度必须小于此集合中任何允许的记录。如果需要将IPFIX消息的填充与非常短的记录相结合，则填充信息元素“paddingOctets”[RFC5102]可用于填充记录，以便将其长度增加到4或8个八位字节的倍数。由于模板集根据定义始终是4-八位字节对齐的，因此仅在其他对齐的情况下（例如，在8-八位字节边界上）才需要填充。
Every Set contains a common header. This header is defined in Figure I.
每个集合都包含一个公共标题。该标题在图I中定义。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure I: Set Header Format
图一：设置标题格式
The Set Header Field Definitions are as follows:
设置表头字段定义如下：
Set ID
设置ID
Set ID value identifies the Set. A value of 2 is reserved for the Template Set. A value of 3 is reserved for the Option Template Set. All other values from 4 to 255 are reserved for future use. Values above 255 are used for Data Sets. The Set ID values of 0 and 1 are not used for historical reasons [RFC3954].
集合ID值标识集合。为模板集保留值2。选项模板集保留值3。4到255之间的所有其他值保留供将来使用。大于255的值用于数据集。由于历史原因，设置的ID值0和1未被使用[RFC3954]。
Length
长
Total length of the Set, in octets, including the Set Header, all records, and the optional padding. Because an individual Set MAY contain multiple records, the Length value MUST be used to determine the position of the next Set.
集合的总长度（以八位字节为单位），包括集合标题、所有记录和可选填充。由于单个集合可能包含多个记录，因此必须使用“长度”值来确定下一个集合的位置。
IPFIX defines three record formats, defined in the next sections: the Template Record Format, the Options Template Record Format, and the Data Record Format.
IPFIX定义了三种记录格式，将在下一节中定义：模板记录格式、选项模板记录格式和数据记录格式。
One of the essential elements in the IPFIX record format is the Template Record. Templates greatly enhance the flexibility of the record format because they allow the Collecting Process to process IPFIX Messages without necessarily knowing the interpretation of all Data Records. A Template Record contains any combination of IANA-assigned and/or enterprise-specific Information Elements identifiers.
IPFIX记录格式中的一个基本元素是模板记录。模板极大地增强了记录格式的灵活性，因为它们允许收集过程处理IPFIX消息，而不必知道所有数据记录的解释。模板记录包含IANA分配和/或企业特定信息元素标识符的任意组合。
The format of the Template Record is shown in Figure J. It consists of a Template Record Header and one or more Field Specifiers. The definition of the Field Specifiers is given in Figure G above.
模板记录的格式如图J所示。它由模板记录头和一个或多个字段说明符组成。上面的图G给出了字段说明符的定义。
+--------------------------------------------------+
| Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
+--------------------------------------------------+
| Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
Figure J: Template Record Format
图J：模板记录格式
The format of the Template Record Header is shown in Figure K.
模板记录头的格式如图K所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (> 255) | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (> 255) | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure K: Template Record Header Format
图K：模板记录头格式
The Template Record Header Field Definitions are as follows:
模板记录标题字段定义如下：
Template ID
模板ID
Each of the newly generated Template Records is given a unique Template ID. This uniqueness is local to the Transport Session and Observation Domain that generated the Template ID. Template IDs 0-255 are reserved for Template Sets, Options Template Sets, and other reserved Sets yet to be created. Template IDs of Data Sets are numbered from 256 to 65535. There are no constraints regarding the order of the Template ID allocation.
每个新生成的模板记录都有一个唯一的模板ID。此唯一性是生成模板ID的传输会话和观察域的本地唯一性。模板ID 0-255保留用于模板集、选项模板集和其他尚未创建的保留集。数据集的模板ID编号从256到65535。关于模板ID分配的顺序没有任何约束。
Field Count
字段计数
Number of fields in this Template Record.
此模板记录中的字段数。
The example in Figure L shows a Template Set with mixed standard and enterprise-specific Information Elements. It consists of a Set Header, a Template Header, and several Field Specifiers.
图L中的示例显示了一个模板集，其中混合了标准和企业特定的信息元素。它由一个集合头、一个模板头和几个字段说明符组成。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.1 | Field Length 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 1.2 | Field Length 1.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.N | Field Length 1.N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 2.1 | Field Length 2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.2 | Field Length 2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.M | Field Length 2.M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.1 | Field Length 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 1.2 | Field Length 1.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.N | Field Length 1.N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 2.1 | Field Length 2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.2 | Field Length 2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.M | Field Length 2.M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure L: Template Set Example
图L：模板集示例
Information Element Identifiers 1.2 and 2.1 are defined by the IETF (Enterprise bit = 0) and, therefore, do not need an Enterprise Number to identify them.
信息元素标识符1.2和2.1由IETF（企业位=0）定义，因此不需要企业编号来识别它们。
Thanks to the notion of scope, The Options Template Record gives the Exporter the ability to provide additional information to the Collector that would not be possible with Flow Records alone.
由于范围的概念，选项模板记录使导出器能够向收集器提供单独使用流记录无法提供的附加信息。
One Options Template Record example is the "Flow Keys", which reports the Flow Keys for a Template, which is defined as the scope. Another example is the "Template configuration", which reports the configuration sampling parameter(s) for the Template, which is defined as the scope.
一个选项模板记录示例是“流键”，它报告定义为范围的模板的流键。另一个例子是“模板配置”，它报告模板的配置采样参数，该参数被定义为范围。
The scope, which is only available in the Options Template Set, gives the context of the reported Information Elements in the Data Records. Note that the IPFIX Message Header already contains the Observation Domain ID (the identifier of the Observation Domain). If not zero, this Observation Domain ID can be considered as an implicit scope for the Data Records in the IPFIX Message. The Observation Domain ID MUST be zero when the IPFIX Message contains Data Records with different Observation Domain ID values defined as scopes.
范围（仅在选项模板集中可用）提供了数据记录中报告的信息元素的上下文。请注意，IPFIX消息头已经包含观察域ID（观察域的标识符）。如果不是零，则可以将此观察域ID视为IPFIX消息中数据记录的隐式作用域。当IPFIX消息包含定义为作用域的不同观察域ID值的数据记录时，观察域ID必须为零。
Multiple Scope Fields MAY be present in the Options Template Record, in which case, the composite scope is the combination of the scopes. For example, if the two scopes are defined as "metering process" and "template", the combined scope is this Template for this Metering Process. The order of the Scope Fields, as defined in the Options Template Record, is irrelevant in this case. However, if the order of the Scope Fields in the Options Template Record is relevant, the order of the Scope Fields MUST be used. For example, if the first scope defines the filtering function, while the second scope defines the sampling function, the order of the scope is important. Applying the sampling function first, followed by the filtering function, would lead to potentially different Data Records than applying the filtering function first, followed by the sampling function. In this case, the Collector deduces the function order by looking at the order of the scope in the Options Template Record.
选项模板记录中可能存在多个范围字段，在这种情况下，复合范围是范围的组合。例如，如果将这两个范围定义为“计量流程”和“模板”，则组合的范围就是此计量流程的模板。在本例中，选项模板记录中定义的范围字段顺序与此无关。但是，如果选项模板记录中范围字段的顺序相关，则必须使用范围字段的顺序。例如，如果第一个作用域定义过滤函数，而第二个作用域定义采样函数，则作用域的顺序很重要。先应用采样函数，再应用过滤函数，可能会导致与先应用过滤函数，再应用采样函数可能不同的数据记录。在这种情况下，收集器通过查看选项模板记录中作用域的顺序来推断函数顺序。
The scope is an Information Element specified in the IPFIX Information Model [RFC5102]. An IPFIX-compliant implementation of the Collecting Process SHOULD support this minimum set of Information Elements as scope: LineCardId, TemplateId, exporterIPv4Address, exporterIPv6Address, and ingressInterface. Note that other Information Elements, such as meteringProcessId, exportingProcessId, observationDomainId, etc. are also valid scopes. The IPFIX protocol doesn't prevent the use of any Information Elements for scope. However, some Information Element types don't make sense if specified as scope; for example, the counter Information Elements.
范围是IPFIX信息模型[RFC5102]中指定的信息元素。符合IPFIX的收集过程实现应支持以下最小信息元素集：LineCardId、TemplateId、exporterIPv4Address、exporterIPv6Address和ingressInterface。请注意，其他信息元素，如meteringProcessId、exportingProcessId、observationDomainId等也是有效的作用域。IPFIX协议不阻止对范围使用任何信息元素。但是，如果指定为范围，则某些信息元素类型没有意义；例如，计数器信息元素。
Finally, note that the Scope Field Count MUST NOT be zero.
最后，请注意范围字段计数不能为零。
An Options Template Record contains any combination of IANA-assigned and/or enterprise-specific Information Elements identifiers.
选项模板记录包含IANA分配和/或企业特定信息元素标识符的任意组合。
The format of the Options Template Record is shown in Figure M. It consists of an Options Template Record Header and one or more Field Specifiers. The definition of the Field Specifiers is given in Figure G above.
选项模板记录的格式如图M所示。它由一个选项模板记录头和一个或多个字段说明符组成。上面的图G给出了字段说明符的定义。
+--------------------------------------------------+
| Options Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
+--------------------------------------------------+
| Options Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
Figure M: Options Template Record Format
图M：选项模板记录格式
The format of the Options Template Record Header is shown in Figure N.
选项模板记录头的格式如图N所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (> 255) | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (> 255) | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure N: Options Template Record Header Format
图N：选项模板记录头格式
The Options Template Record Header Field Definitions are as follows:
选项模板记录标题字段定义如下：
Template ID
模板ID
Template ID of this Options Template Record. This value is greater than 255.
此选项模板记录的模板ID。此值大于255。
Field Count
字段计数
Number of all fields in this Options Template Record, including the Scope Fields.
此选项模板记录中所有字段的数目，包括范围字段。
Scope Field Count
范围字段计数
Number of scope fields in this Options Template Record. The Scope Fields are normal Fields except that they are interpreted as scope at the Collector. The Scope Field Count MUST NOT be zero.
此选项模板记录中的范围字段数。范围字段是普通字段，只是在收集器中将其解释为范围。作用域字段计数不能为零。
The example in Figure O shows an Option Template Set with mixed IETF and enterprise-specific Information Elements. It consists of a Set Header, an Option Template Header, and several Field Specifiers.
图O中的示例显示了一个选项模板集，其中混合了IETF和特定于企业的信息元素。它由一个集合头、一个选项模板头和几个字段说明符组成。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 258 | Field Count = N + M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = N |0| Scope 1 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length |0| Scope 2 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 2 Field Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |1| Scope N Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope N Field Length | Scope N Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Scope N Enterprise Number |1| Option 1 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option 1 Field Length | Option 1 Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Option 1 Enterprise Number | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |0| Option M Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option M Field Length | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 258 | Field Count = N + M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = N |0| Scope 1 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length |0| Scope 2 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 2 Field Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |1| Scope N Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope N Field Length | Scope N Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Scope N Enterprise Number |1| Option 1 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option 1 Field Length | Option 1 Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Option 1 Enterprise Number | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |0| Option M Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option M Field Length | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure O: Option Template Set Example
图O：选项模板集示例
The Data Records are sent in Data Sets. The format of the Data Record is shown in Figure P. It consists only of one or more Field Values. The Template ID to which the Field Values belong is encoded in the Set Header field "Set ID", i.e., "Set ID" = "Template ID".
数据记录以数据集的形式发送。数据记录的格式如图P所示。它仅由一个或多个字段值组成。字段值所属的模板ID编码在集合标题字段“集合ID”中，即“集合ID”=“模板ID”。
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
Figure P: Data Record Format
图P：数据记录格式
Note that Field Values do not necessarily have a length of 16 bits. Field Values are encoded according to their data type specified in [RFC5102].
请注意，字段值的长度不一定为16位。字段值根据[RFC5102]中指定的数据类型进行编码。
Interpretation of the Data Record format can be done only if the Template Record corresponding to the Template ID is available at the Collecting Process.
只有在采集过程中与模板ID对应的模板记录可用时，才能解释数据记录格式。
The example in Figure Q shows a Data Set. It consists of a Set Header and several Field Values.
图Q中的示例显示了一个数据集。它由一个集合标题和几个字段值组成。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = Template ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 1 | Record 1 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 1 | Record 2 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 1 | Record 3 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = Template ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 1 | Record 1 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 1 | Record 2 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 1 | Record 3 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure Q: Data Set, Containing Data Records
图Q：包含数据记录的数据集
Some specific Options Templates and Options Template Records are necessary to provide extra information about the Flow Records and about the Metering Process.
需要一些特定的选项模板和选项模板记录来提供有关流量记录和计量过程的额外信息。
The Option Template and Options Template Records defined in these subsections, which impose some constraints on the Metering Process and Exporting Process implementations, MAY be implemented. If implemented, the specific Option Templates SHOULD be implemented as specified in these subsections.
可以实现这些小节中定义的选项模板和选项模板记录，它们对计量过程和导出过程实施施加了一些约束。如果已实施，则应按照这些小节中的规定实施特定选项模板。
The minimum set of Information Elements is always specified in these Specific IPFIX Options Templates. Nevertheless, extra Information Elements may be used in these specific Options Templates.
信息元素的最小集合始终在这些特定的IPFIX选项模板中指定。然而，这些特定选项模板中可能会使用额外的信息元素。
The Metering Process Statistics Option Template specifies the structure of a Data Record for reporting Metering Process statistics. It SHOULD contain the following Information Elements that are defined in [RFC5102]:
计量过程统计信息选项模板指定用于报告计量过程统计信息的数据记录的结构。它应包含[RFC5102]中定义的以下信息元素：
observationDomainId An identifier of an Observation Domain that is locally unique to the Exporting Process. This Information Element MUST be defined as a Scope Field.
observationDomainId导出过程在本地唯一的观察域标识符。此信息元素必须定义为范围字段。
exportedMessageTotalCount The total number of IPFIX Messages that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization.
exportedMessageTotalCount自导出进程重新初始化以来导出进程成功发送到收集进程的IPFIX消息总数。
exportedFlowTotalCount The total number of Flow Records that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization.
exportedFlowTotalCount自导出进程重新初始化以来导出进程成功发送到收集进程的流记录总数。
exportedOctetTotalCount The total number of octets that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization.
ExportedOcteTotalCount自导出进程重新初始化以来导出进程成功发送到收集进程的八位字节总数。
The Exporting Process SHOULD export the Data Record specified by the Metering Process Statistics Option Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable.
导出流程应定期或基于某些导出策略导出计量流程统计选项模板指定的数据记录。此周期或出口政策应可配置。
Note that if several Metering Processes are available on the Exporter Observation Domain, the Information Element meteringProcessId MUST be specified as an additional Scope Field.
请注意，如果Exporter观察域上有多个计量过程可用，则必须将信息元素meteringProcessId指定为附加范围字段。
The Metering Process Reliability Option Template specifies the structure of a Data Record for reporting lack of reliability in the Metering Process. It SHOULD contain the following Information Elements that are defined in [RFC5102]:
计量过程可靠性选项模板指定用于报告计量过程中可靠性不足的数据记录的结构。它应包含[RFC5102]中定义的以下信息元素：
observationDomainId An identifier of an Observation Domain that is locally unique to the Exporting Process. This Information Element MUST be defined as a Scope Field.
observationDomainId导出过程在本地唯一的观察域标识符。此信息元素必须定义为范围字段。
ignoredPacketTotalCount The total number of IP packets that the Metering Process did not process.
ignoredPacketTotalCount计数进程未处理的IP数据包总数。
ignoredOctetTotalCount The total number of octets in observed IP packets that the Metering Process did not process.
IgnoreDocteTotalCount计数进程未处理的观察到的IP数据包中的八位字节总数。
time first ignored The timestamp of the first IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowStart" timestamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used.
time first忽略计量过程忽略的第一个IP数据包的时间戳。对于此时间戳，可以使用任何“flowStart”时间戳信息元素FlowStartMillSeconds、flowStartMicroseconds、flowStartNanoseconds和flowStartDeltaMicroseconds。
time last ignored The timestamp of the last IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowEnd" timestamp Information Elements flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds can be used.
time last ignored计量过程忽略的最后一个IP数据包的时间戳。对于此时间戳，可以使用任何“flowEnd”时间戳信息元素FlowEndMillistics、flowEndMicroseconds、flowEndNanoseconds和flowEndDeltaMicroseconds。
The Exporting Process SHOULD export the Data Record specified by the Metering Process Reliability Statistics Option Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable.
导出过程应定期或基于某些导出策略导出计量过程可靠性统计选项模板指定的数据记录。此周期或出口政策应可配置。
Note that if several Metering Processes are available on the Exporter Observation Domain, the Information Element meteringProcessId MUST be specified as an additional Scope Field.
请注意，如果Exporter观察域上有多个计量过程可用，则必须将信息元素meteringProcessId指定为附加范围字段。
The Exporting Process Reliability Option Template specifies the structure of a Data Record for reporting lack of reliability in the Exporting process. It SHOULD contain the following Information Elements that are defined in [RFC5102]:
导出过程可靠性选项模板指定用于报告导出过程中可靠性不足的数据记录的结构。它应包含[RFC5102]中定义的以下信息元素：
Exporting Process ID The identifier of the Exporting Process for which lack of reliability is reported. There are three Information Elements specified in [RFC5102] that can be used for this purpose: exporterIPv4Address, exporterIPv6Address, or
导出进程ID报告可靠性不足的导出进程的标识符。[RFC5102]中指定的三个信息元素可用于此目的：exporterIPv4Address、exporterIPv6Address或
exportingProcessId. This Information Element MUST be defined as a Scope Field.
exportingProcessId。此信息元素必须定义为范围字段。
notSentFlowTotalCount The total number of Flows that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process.
notSentFlowTotalCount由计量进程生成并由计量进程或导出进程丢弃而不是发送到收集进程的流总数。
notSentPacketTotalCount The total number of packets in Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process.
notSentPacketTotalCount流记录中由计量进程生成并由计量进程或导出进程丢弃而不是发送到收集进程的数据包总数。
notSentOctetTotalCount The total number of octets in packets in Flow Records that were generated by the Metering Process and dropped by the Metering Process or by the Exporting Process instead of being sent to the Collecting Process.
NotSentOcteTotalCount流记录中数据包的八位字节总数，这些数据包是由计量过程生成的，并由计量过程或导出过程丢弃，而不是发送到收集过程。
time first flow dropped The timestamp of the first Flow was dropped by the Metering Process. For this timestamp, any of the "flowStart" timestamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used.
第一个流丢弃的时间计量过程丢弃第一个流的时间戳。对于此时间戳，可以使用任何“flowStart”时间戳信息元素FlowStartMillSeconds、flowStartMicroseconds、flowStartNanoseconds和flowStartDeltaMicroseconds。
time last flow dropped The timestamp of the last IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowEnd" timestamp Information Elements flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds can be used.
time last flow丢弃了计量过程忽略的最后一个IP数据包的时间戳。对于此时间戳，可以使用任何“flowEnd”时间戳信息元素FlowEndMillistics、flowEndMicroseconds、flowEndNanoseconds和flowEndDeltaMicroseconds。
The Exporting Process SHOULD export the Data Record specified by the Exporting Process Reliability Statistics Option Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable.
导出过程应定期或基于某些导出策略导出导出过程可靠性统计选项模板指定的数据记录。此周期或出口政策应可配置。
The Flow Keys Option Template specifies the structure of a Data Record for reporting the Flow Keys of reported Flows. A Flow Keys
“流键”选项模板指定用于报告所报告流的流键的数据记录的结构。A流键
Data Record extends a particular Template Record that is referenced by its templateId identifier. The Template Record is extended by specifying which of the Information Elements contained in the corresponding Data Records describe Flow properties that serve as Flow Keys of the reported Flow.
数据记录扩展由其templateId标识符引用的特定模板记录。通过指定相应数据记录中包含的哪些信息元素描述用作报告流的流键的流属性，可以扩展模板记录。
The Flow Keys Option Template SHOULD contain the following Information Elements that are defined in [RFC5102]:
流键选项模板应包含[RFC5102]中定义的以下信息元素：
templateId An identifier of a Template. This Information Element MUST be defined as a Scope Field.
templateId模板的标识符。此信息元素必须定义为范围字段。
flowKeyIndicator Bitmap with the positions of the Flow Keys in the Data Records.
flowKeyIndicator位图，显示数据记录中的流键位置。
The IPFIX Message Header "Export Time" field is the time in seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message Header leaves the Exporter. The time-related Information Elements specified in [RFC5102] MAY use this "Export Time" as base time and specify an offset relative to it, instead of using a common base time, such as 0000 UTC Jan 1, 1970. All Information Elements that do not have their base time defined by their data type MUST have the base time clearly specified in their description.
IPFIX消息头“导出时间”字段是自1970年1月1日UTC 0000起IPFIX消息头离开导出器的时间（以秒为单位）。[RFC5102]中指定的与时间相关的信息元素可以使用此“导出时间”作为基准时间，并指定相对于它的偏移量，而不是使用公共基准时间，例如0000 UTC 1970年1月1日。所有未按数据类型定义基准时间的信息元素必须在其说明中明确指定基准时间。
For example, Data Records requiring a microsecond precision can export the flow start and end times with the flowStartMicroseconds and flowEndMicroseconds Information Elements [RFC5102], containing the time since 0000 UTC Jan 1, 1970. An alternate solution is to export the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [RFC5102] in the Data Record, which respectively report the flow start and end time offsets compared to the IPFIX Message Header "Export Time". The latter solution lowers the export bandwidth requirement while it increases the load on the Exporter, as the Exporting Process must calculate the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds of every single Data Record before exporting the IPFIX Message.
例如，需要微秒精度的数据记录可以使用flowStartMicroseconds和flowEndMicroseconds信息元素[RFC5102]导出流量开始和结束时间，其中包含自1970年1月1日UTC 0000起的时间。另一种解决方案是导出数据记录中的flowStartDeltaMicroseconds和flowEndDeltaMicroseconds信息元素[RFC5102]，它们分别报告与IPFIX消息头“导出时间”相比的流开始和结束时间偏移。后一种解决方案降低了导出带宽要求，同时增加了导出器的负载，因为导出过程必须在导出IPFIX消息之前计算每个数据记录的flowStartDeltaMicroseconds和flowEndDeltaMicroseconds。
It must be noted that using time-related Information Elements with offset times, compared to the IPFIX Message Header "Export Time", imposes some time constraints on the Data Records contained in the IPFIX Message. In the example of flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [RFC5102], the Data Record must be exported within a maximum of 71 minutes after its creation. Otherwise, the 32-bit counter would not be sufficient to contain the flow start time offset.
必须注意的是，与IPFIX消息头“导出时间”相比，使用具有偏移时间的时间相关信息元素会对IPFIX消息中包含的数据记录施加一些时间限制。在flowStartDeltaMicroseconds和flowEndDeltaMicroseconds信息元素[RFC5102]的示例中，数据记录必须在创建后最多71分钟内导出。否则，32位计数器将不足以包含流开始时间偏移。
The Information Elements [RFC5102] MUST be sent in canonical format in network-byte order (also known as the big-endian byte ordering).
信息元素[RFC5102]必须以网络字节顺序（也称为大端字节顺序）的标准格式发送。
The following sections will define the encoding of the data types specified in [RFC5102].
以下章节将定义[RFC5102]中指定的数据类型的编码。
Integral data types -- octet, signed8, unsigned16, signed16, unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded using the default canonical format in network-byte order. Signed Integral data types are represented in two's complement notation.
整型数据类型--八位字节、signed8、unsigned16、signed16、unsigned32、signed32、signed64和unsigned64--必须使用默认的规范格式以网络字节顺序进行编码。有符号整数数据类型用二的补码表示法表示。
Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be encoded the same way as the integral data types. The macAddress is treated as a 6-octet integer, the ipv4Address as a 4-octet integer, and the ipv6Address as a 16-octet integer.
地址类型（macAddress、ipv4Address和ipv6Address）的编码方式必须与整型数据类型相同。macAddress被视为6个八位整数，ipv4Address被视为4个八位整数，ipv6地址被视为16个八位整数。
The float32 data type MUST be encoded as an IEEE single-precision 32-bit floating point-type, as specified in [IEEE.754.1985].
float32数据类型必须按照[IEEE.754.1985]中的规定编码为IEEE单精度32位浮点类型。
The float64 data type MUST be encoded as an IEEE double-precision 64-bit floating point-type, as specified in [IEEE.754.1985].
必须按照[IEEE.754.1985]中的规定，将float64数据类型编码为IEEE双精度64位浮点类型。
The boolean data type is specified according to the TruthValue in [RFC2579]: it is an integer with the value 1 for true and a value 2 for false. Every other value is undefined. The boolean data type MUST be encoded in a single octet.
布尔数据类型是根据[RFC2579]中的TruthValue指定的：它是一个整数，值1表示真，值2表示假。其他所有值都未定义。布尔数据类型必须编码为单个八位字节。
The data type string represents a finite length string of valid characters of the Unicode character encoding set. The string data type MUST be encoded in UTF-8 format. The string is sent as an array of octets using an Information Element of fixed or variable length.
数据类型字符串表示Unicode字符编码集的有效字符的有限长度字符串。字符串数据类型必须以UTF-8格式编码。字符串使用固定或可变长度的信息元素作为八位字节数组发送。
The length of the Information Element specifies the length of the octetarray.
信息元素的长度指定八进制数组的长度。
The data type dateTimeseconds represents a time value in units of seconds normalized to the GMT timezone. It MUST be encoded in a 32-bit integer containing the number of seconds since 0000 UTC Jan 1, 1970. The 32-bit integer allows the time encoding up to 136 years.
数据类型dateTimeseconds表示标准化为GMT时区的以秒为单位的时间值。它必须编码为32位整数，包含自1970年1月1日UTC 0000起的秒数。32位整数允许时间编码长达136年。
The data type dateTimeMilliseconds represents a time value in units of milliseconds normalized to the GMT timezone. It MUST be encoded in a 64-bit integer containing the number of milliseconds since 0000 UTC Jan 1, 1970.
数据类型DateTimeMillistics表示一个时间值，单位为毫秒，标准化为GMT时区。它必须编码为64位整数，包含自1970年1月1日UTC 0000起的毫秒数。
The data type dateTimeMicroseconds represents a time value in units of microseconds normalized to the GMT timezone. It MUST be encoded in a 64-bit integer, according to the NTP format given in [RFC1305].
数据类型dateTimeMicroseconds表示一个时间值，单位为微秒，标准化为GMT时区。必须根据[RFC1305]中给出的NTP格式，将其编码为64位整数。
The data type of dateTimeNanoseconds represents a time value in units of nanoseconds normalized to the GMT time zone. It MUST be encoded in a 64-bit integer, according to the NTP format given in [RFC1305].
dateTimeNanoseconds的数据类型表示时间值，单位为纳秒，标准化为GMT时区。必须根据[RFC1305]中给出的NTP格式，将其编码为64位整数。
Information Elements containing integer, string, float, and octetarray types in the information model MAY be encoded using fewer octets than those implied by their type in the information model definition [RFC5102], based on the assumption that the smaller size is sufficient to carry any value the Exporter may need to deliver. This reduces the network bandwidth requirement between the Exporter and the Collector. Note that the Information Element definitions [RFC5102] will always define the maximum encoding size.
信息模型中包含整数、字符串、浮点和八位数组类型的信息元素可以使用比信息模型定义[RFC5102]中其类型隐含的八位字节更少的八位字节进行编码，前提是较小的大小足以承载导出器可能需要传递的任何值。这降低了导出器和收集器之间的网络带宽要求。请注意，信息元素定义[RFC5102]将始终定义最大编码大小。
For instance, the information model [RFC5102] defines byteCount as an unsigned64 type, which would require 64 bits. However, if the Exporter will never locally encounter the need to send a value larger than 4294967295, it may chose to send the value instead as an unsigned32. For example, a core router would require an unsigned64 byteCount, while an unsigned32 might be sufficient for an access router.
例如，信息模型[RFC5102]将字节计数定义为无符号64类型，需要64位。但是，如果导出器在本地从未遇到发送大于4294967295的值的需要，则它可能会选择将该值作为未签名32发送。例如，核心路由器需要一个未签名的64字节数，而访问路由器可能需要一个未签名的32字节数。
This behavior is indicated by the Exporter by specifying a type size with a smaller length than that associated with the assigned type of the Information Element. In the example above, the Exporter would place a length of 4 versus 8 in the Template.
导出器通过指定长度小于与信息元素的指定类型关联的长度的类型大小来指示此行为。在上面的示例中，导出器将在模板中放置长度为4而不是8。
If reduced sizing is used, it MUST only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16. The signed versus unsigned property of the reported value MUST be preserved. The reduction in size can be to any number of octets smaller than the original type if the data value still fits, i.e., so that only leading zeroes are dropped. For example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).
如果使用缩减大小，则它只能应用于以下整数类型：unsigned64、signed64、unsigned32、signed32、unsigned16和signed16。必须保留报告值的signed vs unsigned属性。如果数据值仍然合适，则大小可以减少到比原始类型小的任何数量的八位字节，即，只删除前导零。例如，无符号64的大小可以减少到7、6、5、4、3、2或1个八位组。
Reduced sizing can also be used to reduce float64 to float32. The float32 not only has a reduced number range, but due to the smaller mantissa, is also less precise.
减小大小也可用于将float64减少到float32。float32不仅减少了数字范围，而且由于尾数较小，精度也较低。
The reduced size encoding MUST NOT be applied to dateTimeMicroseconds or to dateTimeNanoseconds because these represent an inherent structure that would be destroyed by using less than the original number of bytes.
缩减大小的编码不能应用于dateTimeMicroseconds或dateTimeNanoseconds，因为它们表示一种固有的结构，如果使用的字节数少于原始字节数，就会破坏这种结构。
The IPFIX Template mechanism is optimized for fixed-length Information Elements [RFC5102]. Where an Information Element has a variable length, the following mechanism MUST be used to carry the length information for both the IETF and proprietary Information Elements.
IPFIX模板机制针对固定长度的信息元素进行了优化[RFC5102]。如果信息元素具有可变长度，则必须使用以下机制来承载IETF和专有信息元素的长度信息。
In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that length of the Information Element will be carried in the Information Element content itself.
在模板集中，信息元素字段长度记录为65535。此保留长度值通知收集过程信息元素的长度将在信息元素内容本身中携带。
In most cases, the length of the Information Element will be less than 255 octets. The following length-encoding mechanism optimizes the overhead of carrying the Information Element length in this majority case. The length is carried in the octet before the Information Element, as shown in Figure R.
在大多数情况下，信息元素的长度将小于255个八位字节。以下长度编码机制优化了在这种情况下承载信息元素长度的开销。长度以信息元素前的八位字节表示，如图R所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (< 255)| Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (< 255)| Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure R: Variable-Length Information Element (length < 255 octets)
图R：可变长度信息元素（长度<255个八位字节）
If the length of the Information Element is greater than or equal to 255 octets, the length is encoded into 3 octets before the Information Element. The first octet is 255, and the length is carried in the second and third octets, as shown in Figure S.
如果信息元素的长度大于或等于255个八位字节，则将该长度编码为信息元素之前的3个八位字节。第一个八位字节是255，长度在第二个和第三个八位字节中进行，如图S所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | Length (0 to 65535) | IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | Length (0 to 65535) | IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure S: Variable-Length Information Element (length 0 to 65535 octets)
图S：可变长度信息元素（长度为0到65535个八位字节）
The octets carrying the length (either the first or the first three octets) MUST NOT be included in the length of the Information Element.
携带长度的八位字节（第一个或前三个八位字节）不得包含在信息元素的长度中。
This section describes Template Management when using SCTP and PR-SCTP as the transport protocol. Any necessary changes to Template Management specifically related to TCP or UDP transport protocols are specified in Section 10.
本节介绍使用SCTP和PR-SCTP作为传输协议时的模板管理。第10节中规定了与TCP或UDP传输协议相关的模板管理的任何必要更改。
The Exporting Process assigns and maintains the Template IDs per SCTP association for the Exporter's Observation Domains. A newly created Template Record is assigned an unused Template ID by the Exporting Process.
导出过程根据导出器的观察域的SCTP关联分配和维护模板ID。导出过程会为新创建的模板记录分配一个未使用的模板ID。
If a specific Information Element is required by a Template, but is not available in observed packets, the Exporting Process MAY choose to export Flow Records without this Information Element in a Data Record defined by a new Template.
如果模板需要特定的信息元素，但在观察到的数据包中不可用，则导出过程可以选择在新模板定义的数据记录中导出没有此信息元素的流记录。
If an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process. For example, if a selected packet goes through two hash functions, and if the two hash values are sent within a single Template, the first occurrence of the hash value should belong to the first hash function in the Metering Process. For example, when exporting the two source IP addresses of an IPv4 in IPv4 packets, the first sourceIPv4Address Information Element occurrence should be the IPv4 address of the outer header, while the second occurrence should be the inner header one.
如果模板中不止一次需要一个信息元素，则该信息元素的不同出现应遵循计量过程处理的逻辑顺序。例如，如果选定的数据包经过两个哈希函数，并且如果两个哈希值在单个模板内发送，则哈希值的第一次出现应属于计量过程中的第一个哈希函数。例如，在IPv4数据包中导出IPv4的两个源IP地址时，出现的第一个sourceIPv4Address信息元素应为外部报头的IPv4地址，而第二个应为内部报头的IPv4地址。
Template Sets and Options Template Sets may be sent on any SCTP stream. Template Sets and Options Template Sets MUST be sent reliably, using SCTP-ordered delivery. As such, the Collecting Process MUST store the Template Record information for the duration of the SCTP association so that it can interpret the corresponding Data Records that are received in subsequent Data Sets.
模板集和选项模板集可以在任何SCTP流上发送。模板集和选项模板集必须使用SCTP有序交付可靠发送。因此，收集过程必须在SCTP关联期间存储模板记录信息，以便能够解释在后续数据集中接收到的相应数据记录。
The Exporting Process SHOULD transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID, to help ensure that the Collector has the Template Record before receiving the first Data Record. Data Records that correspond to a Template Record MAY appear in the same and/or subsequent IPFIX Message(s).
导出过程应在使用该（选项）模板ID的任何数据集之前传输模板集和选项模板集，以帮助确保收集器在接收第一条数据记录之前拥有模板记录。与模板记录相对应的数据记录可能出现在相同和/或后续IPFIX消息中。
Different Observation Domains from the same SCTP association may use the same Template ID value to refer to different Templates.
来自同一SCTP关联的不同观察域可以使用相同的模板ID值来引用不同的模板。
The Templates that are not used anymore SHOULD be deleted. Before reusing a Template ID, the Template MUST be deleted. In order to delete an allocated Template, the Template is withdrawn through the use of a Template Withdrawal Message.
不再使用的模板应删除。在重用模板ID之前，必须删除该模板。为了删除分配的模板，通过使用模板撤回消息撤回模板。
The Template Withdrawal Message MUST NOT be sent until sufficient time has elapsed to allow the Collecting Process to receive and process the last Data Record using this Template information. This time MUST be configurable. A suitable default value is 5 seconds after the last Data Record has been sent.
在经过足够的时间以允许收集过程使用此模板信息接收和处理最后的数据记录之前，不得发送模板撤回消息。这个时间必须是可配置的。合适的默认值为发送最后一条数据记录后5秒。
The Template ID from a withdrawn Template MUST NOT be reused until sufficient time has elapsed to allow for the Collecting Process to receive and process the Template Withdrawal Message.
在经过足够的时间以允许收集流程接收和处理模板撤回消息之前，不得重复使用已撤回模板中的模板ID。
A Template Withdrawal Message is a Template Record for that Template ID with a Field Count of 0. The format of the Template Withdrawal Message is shown in Figure T.
模板撤回消息是该模板ID的模板记录，字段计数为0。模板撤回消息的格式如图T所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = (2 or 3) | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID N | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID ... | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID M | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = (2 or 3) | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID N | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID ... | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID M | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure T: Template Withdrawal Message Format
图T：模板撤回消息格式
The Set ID field MUST contain the value 2 for Template Set Withdrawal and the value 3 for Options Template Set Withdrawal. Multiple Template IDs MAY be withdrawn with a single Template Withdrawal Message, in that case, padding MAY be used.
集合ID字段必须包含值2（用于模板集合提取）和值3（用于选项模板集合提取）。可以使用单个模板撤销消息撤销多个模板ID，在这种情况下，可以使用填充。
The Template Withdrawal Message withdraws the Template IDs for the Observation Domain ID specified in the IPFIX Message Header.
模板撤回消息撤回IPFIX消息头中指定的观察域ID的模板ID。
The Template Withdrawal Message may be sent on any SCTP stream. The Template Withdrawal Message MUST be sent reliably, using SCTP-ordered delivery.
模板撤回消息可以在任何SCTP流上发送。必须使用SCTP有序交付可靠地发送模板撤回消息。
The Template Withdrawal Message MUST NOT contain new Template or Options Template Records.
模板撤回消息不得包含新模板或选项模板记录。
If the measurement parameters change such that a new Template is required, the Template MUST be withdrawn (using a Template Withdraw Message and a new Template definition) or an unused Template ID MUST be used. Examples of the measurement changes are: a new sampling rate, a new Flow expiration process, a new filtering definition, etc.
如果测量参数发生变化，需要新模板，则必须撤回模板（使用模板撤回消息和新模板定义）或使用未使用的模板ID。测量更改的示例包括：新的采样率、新的流过期过程、新的过滤定义等。
When the SCTP association shuts down or the Exporting Process restarts, all Template assignments are lost and Template IDs MUST be reassigned.
当SCTP关联关闭或导出过程重新启动时，所有模板分配都将丢失，必须重新分配模板ID。
If the Metering Process restarts, the Exporting Process MUST either reuse the previously assigned Template ID for each Template, or it MUST withdraw the previously issued Template IDs by sending Template Withdraw Message(s) before reusing them.
如果计量过程重新启动，则导出过程必须为每个模板重复使用以前分配的模板ID，或者必须在重复使用之前通过发送模板撤销消息来撤销以前发布的模板ID。
A Template Withdrawal Message to withdraw all Templates for the Observation Domain ID specified in the IPFIX Message Header MAY be used. Its format is shown in Figure U.
可以使用模板撤销消息来撤销IPFIX消息头中指定的观察域ID的所有模板。其格式如图U所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 2 | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 2 | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure U: All Data Templates Withdrawal Message Format
图U：所有数据模板撤回消息格式
A Template Withdrawal Message to withdraw all Options Templates for the Observation Domain ID specified in the IPFIX Message Header MAY be used. Its format is shown in Figure V.
可以使用模板撤回消息来撤回IPFIX消息头中指定的观测域ID的所有选项模板。其格式如图V所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 3 | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 3 | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure V: All Options Templates Withdrawal Message Format
图五：所有选项模板撤回消息格式
When the SCTP association restarts, the Exporting Process MUST resend all the Template Records.
当SCTP关联重新启动时，导出过程必须重新发送所有模板记录。
This section describes the Collecting Process when using SCTP and PR-SCTP as the transport protocol. Any necessary changes to the Collecting Process specifically related to TCP or UDP transport protocols are specified in Section 10.
本节描述使用SCTP和PR-SCTP作为传输协议时的收集过程。第10节规定了与TCP或UDP传输协议相关的收集过程的任何必要更改。
The Collecting Process SHOULD listen for a new association request from the Exporting Process. The Exporting Process will request a number of streams to use for export. An Exporting Process MAY request and support more than one stream per SCTP association.
收集进程应侦听来自导出进程的新关联请求。导出过程将请求许多流用于导出。导出进程可以请求并支持每个SCTP关联的多个流。
If the Collecting Process receives a malformed IPFIX Message, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error. Note that non-zero Set padding does not constitute a malformed IPFIX Message.
如果收集进程接收到格式错误的IPFIX消息，它必须重置SCTP关联，放弃IPFIX消息，并应记录错误。请注意，非零集填充并不构成格式错误的IPFIX消息。
Template Sets and Option Template Sets are only sent once. The Collecting Process MUST store the Template Record information for the duration of the association so that it can interpret the corresponding Data Records that are received in subsequent Data Sets.
模板集和选项模板集仅发送一次。收集过程必须在关联期间存储模板记录信息，以便能够解释在后续数据集中接收到的相应数据记录。
Template IDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives a Template that has already been received but that has not previously been withdrawn (i.e., a Template Record from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shut down the association.
每个SCTP关联和每个观察域的模板ID都是唯一的。如果收集过程接收到一个已经收到但之前尚未撤回的模板（即，来自同一导出器观察域的模板记录，在SCTP关联上接收到相同的模板ID），则收集过程必须关闭关联。
When an SCTP association is closed, the Collecting Process MUST discard all Templates received over that association and stop decoding IPFIX Messages that use those Templates.
当SCTP关联关闭时，收集过程必须丢弃通过该关联接收的所有模板，并停止对使用这些模板的IPFIX消息进行解码。
The Collecting Process normally receives Template Records from the Exporting Process before receiving Data Records. The Data Records are then decoded and stored by the Collector. If the Template Records have not been received at the time Data Records are received, the Collecting Process MAY store the Data Records for a short period of time and decode them after the Template Records are received. A Collecting Process MUST NOT assume that the Data Set and the associated Template Set (or Options Template Set) are exported in the same IPFIX Message.
收集流程通常在接收数据记录之前从导出流程接收模板记录。数据记录随后由采集器解码和存储。如果在接收数据记录时未接收到模板记录，则收集过程可在短时间内存储数据记录，并在接收到模板记录后对其进行解码。收集过程不得假定数据集和关联的模板集（或选项模板集）在同一IPFIX消息中导出。
The Collecting Process MUST note the Information Element identifier of any Information Element that it does not understand and MAY discard that Information Element from the Flow Record.
收集过程必须注意它不理解的任何信息元素的信息元素标识符，并且可以从流记录中丢弃该信息元素。
The Collector MUST accept padding in Data Records and Template Records. The padding size is the Set Length minus the size of the Set Header (4 octets for the Set ID and the Set Length), modulo the Record size deduced from the Template Record.
收集器必须接受数据记录和模板记录中的填充。padding size是集合长度减去集合头的大小（集合ID和集合长度为4个八位字节），以模板记录推断的记录大小为模。
The IPFIX protocol has a Sequence Number field in the Export header that increases with the number of IPFIX Data Records in the IPFIX Message. A Collector may detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. A Collector SHOULD provide a logging mechanism for tracking out-of-sequence IPFIX Messages. Such out-of-sequence IPFIX Messages may be due to Exporter resource exhaustion where it cannot transmit messages at their creation rate, an Exporting Process reset, congestion on the network link between the Exporter and Collector, Collector resource exhaustion where it cannot process the IPFIX Messages at their arrival rate, out-of-order packet reception, duplicate packet reception, or an attacker injecting false messages.
IPFIX协议在导出标头中有一个序列号字段，该字段随IPFIX消息中IPFIX数据记录的数量而增加。收集器可以通过跟踪序列号来检测无序、丢弃或重复的IPFIX消息。收集器应提供一种日志机制，用于跟踪无序的IPFIX消息。此类无序IPFIX消息可能是由于导出器资源耗尽（无法以创建速率传输消息）、导出进程重置、导出器和收集器之间的网络链路拥塞、收集器资源耗尽（无法以到达速率处理IPFIX消息）造成的，无序数据包接收、重复数据包接收或攻击者注入虚假消息。
If a Collecting Process receives a Template Withdrawal Message, the Collecting Process MUST delete the corresponding Template Records associated with the specific SCTP association and specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates.
如果收集流程收到模板撤回消息，则收集流程必须删除与特定SCTP关联和特定观察域关联的相应模板记录，并停止解码使用撤回模板的IPFIX消息。
If the Collecting Process receives a Template Withdraw message for a Template Record it has not received before on this SCTP association, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages.
如果收集进程在此SCTP关联上收到以前从未收到的模板记录的模板撤消消息，则它必须重置SCTP关联，放弃IPFIX消息，并应像记录格式错误的IPFIX消息一样记录错误。
A Collecting Process that receives IPFIX Messages from several Observation Domains on the same Transport Session MUST be aware that the uniqueness of the Template ID is not guaranteed across Observation Domains.
在同一传输会话上从多个观察域接收IPFIX消息的收集进程必须知道，不能保证跨观察域的模板ID的唯一性。
The Collector MUST support the use of Templates containing multiple occurrences of the similar Information Elements.
收集器必须支持使用包含类似信息元素多次出现的模板。
The IPFIX Protocol Specification has been designed to be transport protocol independent. Note that the Exporter can export to multiple Collecting Processes using independent transport protocols.
IPFIX协议规范设计为独立于传输协议。请注意，导出器可以使用独立的传输协议导出到多个收集进程。
The IPFIX Message Header 16-bit Length field limits the length of an IPFIX Message to 65535 octets, including the header. A Collecting Process MUST be able to handle IPFIX Message lengths of up to 65535 octets.
IPFIX消息头16位长度字段将IPFIX消息的长度限制为65535个八位字节，包括消息头。收集进程必须能够处理多达65535个八位字节的IPFIX消息长度。
We need to differentiate between what must be implemented (so that operators can interoperably deploy compliant implementations from different vendors) and what should or could be used in various operational environments. We must also make sure that ALL implementations can operate in a congestion-aware and congestion-avoidance mode.
我们需要区分必须实现的内容（以便运营商可以互操作地部署来自不同供应商的兼容实现）和应该或可以在各种操作环境中使用的内容。我们还必须确保所有实现都可以在拥塞感知和拥塞避免模式下运行。
SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] MUST be implemented by all compliant implementations. UDP [UDP] MAY also be implemented by compliant implementations. TCP [TCP] MAY also be implemented by compliant implementations.
使用[RFC3758]中指定的PR-SCTP扩展的SCTP[RFC4960]必须由所有符合要求的实现来实现。UDP[UDP]也可以通过兼容的实现来实现。TCP[TCP]也可以通过兼容实现来实现。
PR-SCTP SHOULD be used in deployments where Exporters and Collectors are communicating over links that are susceptible to congestion. PR-SCTP is capable of providing any required degree of reliability.
PR-SCTP应用于导出器和收集器通过易发生拥塞的链路进行通信的部署中。PR-SCTP能够提供任何所需的可靠性。
TCP MAY be used in deployments where Exporters and Collectors communicate over links that are susceptible to congestion, but PR-SCTP is preferred due to its ability to limit back pressure on Exporters and its message versus stream orientation.
TCP可用于导出器和收集器通过易受拥塞影响的链路进行通信的部署中，但由于PR-SCTP能够限制导出器的背压以及其消息与流的方向，因此首选PR-SCTP。
UDP MAY be used, although it is not a congestion-aware protocol. However, the IPFIX traffic between Exporter and Collector MUST run in an environment where IPFIX traffic has been provisioned for, or is contained through some other means.
可以使用UDP，尽管它不是拥塞感知协议。但是，导出器和收集器之间的IPFIX流量必须在已为IPFIX流量设置或通过其他方式包含IPFIX流量的环境中运行。
This section describes how IPFIX can be transported over SCTP [RFC4960] using the PR-SCTP [RFC3758] extension.
本节介绍如何使用PR-SCTP[RFC3758]扩展通过SCTP[RFC4960]传输IPFIX。
The SCTP transport protocol provides the required level of congestion avoidance by design.
SCTP传输协议通过设计提供了所需的拥塞避免级别。
SCTP will detect congestion in the end-to-end path between the IPFIX Exporting Process and the IPFIX Collecting Process, and limit the transfer rate accordingly. When an IPFIX Exporting Process has records to export, but detects that transmission by SCTP is temporarily impossible, it can either wait until sending is possible again, or it can decide to drop the record. In the latter case, the dropped export data MUST be accounted for, so that the amount of dropped export data can be reported.
SCTP将检测IPFIX导出进程和IPFIX收集进程之间的端到端路径中的拥塞，并相应地限制传输速率。当IPFIX导出进程有记录要导出，但检测到暂时无法通过SCTP进行传输时，它可以等待直到可以再次发送，也可以决定删除该记录。在后一种情况下，必须说明丢弃的导出数据，以便报告丢弃的导出数据量。
The SCTP transport protocol is by default reliable, but has the capability to deliver messages with partial reliability [RFC3758].
默认情况下，SCTP传输协议是可靠的，但能够以部分可靠性传递消息[RFC3758]。
Using reliable SCTP messages for the IPFIX export is not in itself a guarantee that all Data Records will be delivered. If there is congestion on the link from the Exporting Process to the Collecting Process, or if a significant number of retransmissions are required, the send queues on the Exporting Process may fill up; the Exporting Process MAY either suspend, export, or discard the IPFIX Messages. If Data Records are discarded the IPFIX Sequence Numbers used for export MUST reflect the loss of data.
为IPFIX导出使用可靠的SCTP消息本身并不能保证所有数据记录都会被传递。如果从导出过程到收集过程的链路上存在拥塞，或者如果需要大量的重新传输，则导出过程上的发送队列可能会填满；导出过程可以挂起、导出或放弃IPFIX消息。如果数据记录被丢弃，用于导出的IPFIX序列号必须反映数据丢失。
SCTP provides the required IPFIX Message fragmentation service based on path MTU discovery.
SCTP基于路径MTU发现提供所需的IPFIX消息分段服务。
The IPFIX Exporting Process SHOULD initiate an SCTP association with the IPFIX Collecting Process. By default, the Collecting Process listens for connections on SCTP port 4739. By default, the Collecting Process listens for secure connections on SCTP port 4740 (refer to the Security Considerations section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting and Collecting Processes to use a different SCTP port.
IPFIX导出进程应启动与IPFIX收集进程的SCTP关联。默认情况下，收集进程侦听SCTP端口4739上的连接。默认情况下，收集进程侦听SCTP端口4740上的安全连接（请参阅安全注意事项部分）。默认情况下，导出进程尝试连接到其中一个端口。必须能够将导出和收集过程配置为使用不同的SCTP端口。
The Exporting Process MAY establish more than one association (connection "bundle" in SCTP terminology) to the Collecting Process.
导出过程可能与收集过程建立多个关联（SCTP术语中的连接“bundle”）。
An Exporting Process MAY support more than one active association to different Collecting Processes (including the case of different Collecting Processes on the same host).
导出进程可能支持多个与不同收集进程的活动关联（包括同一主机上不同收集进程的情况）。
When an Exporting Process is shut down, it SHOULD shut down the SCTP association.
当导出进程关闭时，它应该关闭SCTP关联。
When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD shut down its end of the association. The Collecting Process SHOULD continue to receive and process IPFIX Messages until the Exporting Process has closed its end of the association.
当收集进程不再希望接收IPFIX消息时，它应该关闭其关联结束。收集进程应继续接收和处理IPFIX消息，直到导出进程结束其关联。
When a Collecting Process detects that the SCTP association has been abnormally terminated, it MUST continue to listen for a new association establishment.
当收集进程检测到SCTP关联已异常终止时，它必须继续侦听新的关联建立。
When an Exporting Process detects that the SCTP association to the Collecting Process is abnormally terminated, it SHOULD try to re-establish the association.
当导出进程检测到与收集进程的SCTP关联异常终止时，它应该尝试重新建立关联。
Association timeouts SHOULD be configurable.
关联超时应该是可配置的。
An Exporting Process MAY request more than one SCTP stream per association. Each of these streams may be used for the transmission of IPFIX Messages containing Data Sets, Template Sets, and/or Options Template Sets.
一个导出进程可以为每个关联请求多个SCTP流。这些流中的每一个都可用于传输包含数据集、模板集和/或选项模板集的IPFIX消息。
Depending on the requirements of the application, the Exporting Process may send Data Sets with full or partial reliability, using ordered or out-of-order delivery, over any SCTP stream established during SCTP Association setup.
根据应用程序的要求，导出过程可以通过SCTP关联设置期间建立的任何SCTP流，使用有序或无序交付，发送具有完全或部分可靠性的数据集。
An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as per Section 4 of the PR-SCTP [RFC3758] specification when using partial reliability to transmit IPFIX Messages containing only Data Sets.
当使用部分可靠性传输仅包含数据集的IPFIX消息时，IPFIX导出过程可根据PR-SCTP[RFC3758]规范第4节使用任何PR-SCTP服务定义。
However, Exporting Processes SHOULD mark such IPFIX Messages for retransmission for as long as resource or other constraints allow.
但是，只要资源或其他限制允许，导出过程应将此类IPFIX消息标记为重新传输。
When the transport protocol is SCTP, the default Template Management described in Section 8 is used.
当传输协议为SCTP时，使用第8节中描述的默认模板管理。
When the transport protocol is SCTP, the default Collector processing described in Section 9 is used.
当传输协议为SCTP时，使用第9节中描述的默认收集器处理。
If the Collecting Process does not acknowledge the attempt by the Exporting Process to establish an association, the Exporting Process should retry using the SCTP exponential backoff feature. The Exporter MAY log an alarm if the time to establish the association exceeds a specified threshold, configurable on the Exporter.
如果收集进程未确认导出进程尝试建立关联，则导出进程应使用SCTP指数退避功能重试。如果建立关联的时间超过了导出器上可配置的指定阈值，则导出器可能会记录警报。
If Collecting Process failover is supported by the Exporting Process, a second SCTP association MAY be opened in advance.
如果导出进程支持收集进程故障转移，则可以提前打开第二个SCTP关联。
This section describes how IPFIX can be transported over UDP [UDP].
本节介绍如何通过UDP[UDP]传输IPFIX。
UDP has no integral congestion-avoidance mechanism. Its use over congestion-sensitive network paths is therefore not recommended. UDP MAY be used in deployments where Exporters and Collectors always communicate over dedicated links that are not susceptible to congestion, i.e., over provisioned links compared to the maximum export rate from the Exporters.
UDP没有完整的拥塞避免机制。因此，不建议在对拥塞敏感的网络路径上使用它。UDP可用于导出器和收集器始终通过不易发生拥塞的专用链路进行通信的部署，即与导出器的最大导出速率相比，过度配置的链路。
UDP is not a reliable transport protocol, and cannot guarantee delivery of messages. IPFIX Messages sent from the Exporting Process to the Collecting Process using UDP may therefore be lost. UDP MUST NOT be used unless the application can tolerate some loss of IPFIX Messages.
UDP不是可靠的传输协议，无法保证消息的传递。因此，使用UDP从导出进程发送到收集进程的IPFIX消息可能会丢失。除非应用程序能够容忍某些IPFIX消息丢失，否则不得使用UDP。
The Collecting Process SHOULD deduce the loss and reordering of IPFIX Data Records by looking at the discontinuities in the IPFIX Sequence Number. In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the UDP Transport Session prior to the receipt of this IPFIX Message, modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. Templates sent from the Exporting Process to the Collecting Process using UDP as a transport MUST be re-sent at regular intervals, in case previous copies were lost.
收集过程应通过查看IPFIX序列号中的不连续性来推断IPFIX数据记录的丢失和重新排序。对于UDP，IPFIX序列号包含在收到此IPFIX消息之前为UDP传输会话发送的IPFIX数据记录总数，模为2^32。收集器应通过跟踪序列号来检测无序、丢弃或重复的IPFIX消息。使用UDP作为传输从导出进程发送到收集进程的模板必须定期重新发送，以防以前的副本丢失。
The maximum size of exported messages MUST be configured such that the total packet size does not exceed the path MTU. If the path MTU is unknown, a maximum packet size of 512 octets SHOULD be used.
导出消息的最大大小必须配置为总数据包大小不超过路径MTU。如果路径MTU未知，则应使用512个八位字节的最大数据包大小。
By default, the Collecting Process listens on the UDP port 4739. By default, the Collecting Process listens for secure connections on UDP port 4740 (refer to the "Security Considerations" section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting and Collecting Processes to use a different UDP port.
默认情况下，收集进程侦听UDP端口4739。默认情况下，收集进程侦听UDP端口4740上的安全连接（请参阅“安全注意事项”部分）。默认情况下，导出进程尝试连接到其中一个端口。必须能够将导出和收集过程配置为使用不同的UDP端口。
The Exporting Process MAY duplicate the IPFIX Message to the several Collecting Processes.
导出进程可能会将IPFIX消息复制到多个收集进程。
When IPFIX uses UDP as the transport protocol, Template Sets and Option Template Sets MUST be re-sent at regular intervals. The frequency of the (Options) Template transmission MUST be configurable. The default value for the frequency of the (Options) Template transmission is 10 minutes. The Exporting Process SHOULD transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID to help ensure that the
当IPFIX使用UDP作为传输协议时，必须定期重新发送模板集和选项模板集。（选项）模板传输的频率必须是可配置的。（选项）模板传输频率的默认值为10分钟。导出过程应在使用该（选项）模板ID的任何数据集之前传输模板集和选项模板集，以帮助确保
Collector has the Template Record before receiving the first Data Record.
收集器在接收第一条数据记录之前拥有模板记录。
In the event of configuration changes, the Exporting Process SHOULD send multiple copies of the new Template definitions, in different IPFIX Messages, at an accelerated rate. In such a case, it SHOULD transmit the changed Template Record(s) and Options Template Record(s), without any data, in advance to help ensure that the Collector will have the correct Template information before receiving the first data.
在配置发生更改的情况下，导出过程应以不同的IPFIX消息以更快的速度发送新模板定义的多个副本。在这种情况下，它应该提前发送更改的模板记录和选项模板记录，而不发送任何数据，以帮助确保收集器在接收第一个数据之前拥有正确的模板信息。
If the Option Template scope is defined in another Template, then both Templates SHOULD be sent in the same IPFIX Message. For example, if a Flow Key Option Template (see Section 4.4) is sent in an Option Template, then the associated Template SHOULD be sent in the same IPFIX Message.
如果选项模板范围在另一个模板中定义，则两个模板应在同一个IPFIX消息中发送。例如，如果在选项模板中发送流键选项模板（参见第4.4节），则相关模板应在相同的IPFIX消息中发送。
Following a configuration change that can modify the interpretation of the Data Records (for example, a sampling rate change) a new Template ID MUST be used, and the old Template ID MUST NOT be reused until its lifetime (see Section 10.3.7) has expired.
在可能修改数据记录解释的配置更改（例如，采样率更改）之后，必须使用新模板ID，并且在旧模板ID的使用期限（见第10.3.7节）到期之前，不得重复使用旧模板ID。
If UDP is selected as the transport protocol, the Template Withdraw Messages MUST NOT be used, as this method is inefficient due to the unreliable nature of UDP.
如果选择UDP作为传输协议，则不得使用模板撤回消息，因为由于UDP的不可靠性，此方法效率低下。
The Collecting Process MUST associate a lifetime with each Template (or another definition of an identifier considered unique within the Transport Session) received via UDP. Templates (and similar definitions) not refreshed by the Exporting Process within the lifetime are expired at the Collecting Process. If the Template (or other definition) is not refreshed before that lifetime has expired, the Collecting Process MUST discard that definition and any current and future associated Data Records. In which case, an alarm MUST be logged. The Collecting Process MUST NOT decode any further Data Records that are associated with the expired Template. If a Template is refreshed with a Template Record that differs from the previously received Template Record, the Collecting Process SHOULD log a warning and replace the previously received Template Record with the new one. The Template lifetime at the Collecting Process MUST be at least 3 times higher than the Template refresh timeout configured on the Exporting Process.
收集过程必须将生存期与通过UDP接收的每个模板（或传输会话中认为唯一的标识符的另一个定义）相关联。导出过程在生存期内未刷新的模板（和类似定义）在收集过程中过期。如果模板（或其他定义）在该生存期到期之前未刷新，则收集过程必须放弃该定义以及任何当前和未来关联的数据记录。在这种情况下，必须记录报警。收集过程不得解码与过期模板关联的任何其他数据记录。如果使用与以前收到的模板记录不同的模板记录刷新模板，则收集过程应记录警告，并用新的模板记录替换以前收到的模板记录。收集进程的模板生存期必须至少比导出进程上配置的模板刷新超时高3倍。
Template IDs are unique per UDP session and per Observation Domain. At any given time, the Collecting Process SHOULD maintain the following for all the current Template Records and Options Template
每个UDP会话和每个观察域的模板ID都是唯一的。在任何给定时间，收集过程都应为所有当前模板记录和模板选项维护以下内容
Records: <IPFIX Device, Exporter source UDP port, Observation Domain ID, Template ID, Template Definition, Last Received>.
记录：<IPFIX设备、导出器源UDP端口、观察域ID、模板ID、模板定义、上次接收>。
The Collecting Process SHOULD accept Data Records without the associated Template Record (or other definitions) required to decode the Data Record. If the Template Records (or other definitions such as Common Properties) have not been received at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Template Records (or other definitions) are received. The short period of time MUST be lower than the lifetime of definitions associated with identifiers considered unique within the UDP session.
收集过程应接受没有解码数据记录所需的相关模板记录（或其他定义）的数据记录。如果在收到数据记录时未收到模板记录（或其他定义，如公共属性），则收集过程应在短时间内存储数据记录，并在收到模板记录（或其他定义）后对其进行解码。短时间段必须低于与UDP会话中唯一标识符关联的定义的生存期。
If the Collecting Process receives a malformed IPFIX Message, it MUST discard the IPFIX Message and SHOULD log the error.
如果收集进程接收到格式错误的IPFIX消息，它必须丢弃IPFIX消息并记录错误。
Because UDP is not a connection-oriented protocol, the Exporting Process is unable to determine from the transport protocol that the Collecting Process is no longer able to receive the IPFIX Messages. Therefore, it cannot invoke a failover mechanism. However, the Exporting Process MAY duplicate the IPFIX Message to several Collecting Processes.
由于UDP不是面向连接的协议，因此导出进程无法从传输协议确定收集进程不再能够接收IPFIX消息。因此，它无法调用故障转移机制。但是，导出进程可能会将IPFIX消息复制到多个收集进程。
This section describes how IPFIX can be transported over TCP [TCP].
本节介绍如何通过TCP[TCP]传输IPFIX。
The IPFIX Exporting Process initiates a TCP connection to the Collecting Process. By default, the Collecting Process listens for connections on TCP port 4739. By default, the Collecting Process listens for secure connections on TCP port 4740 (refer to the Security Considerations section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting Process and the Collecting Process to use a different TCP port.
IPFIX导出进程启动到收集进程的TCP连接。默认情况下，收集进程侦听TCP端口4739上的连接。默认情况下，收集进程侦听TCP端口4740上的安全连接（请参阅安全注意事项部分）。默认情况下，导出进程尝试连接到其中一个端口。必须能够将导出进程和收集进程配置为使用不同的TCP端口。
An Exporting Process MAY support more than one active connection to different Collecting Processes (including the case of different Collecting Processes on the same host).
导出进程可能支持到不同收集进程的多个活动连接（包括同一主机上不同收集进程的情况）。
The Exporter MAY log an alarm if the time to establish the connection exceeds a specified threshold, configurable on the Exporter.
如果建立连接的时间超过导出器上可配置的指定阈值，导出器可能会记录警报。
When an Exporting Process is shut down, it SHOULD shut down the TCP connection.
当导出进程关闭时，它应该关闭TCP连接。
When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD close its end of the connection. The Collecting Process SHOULD continue to read IPFIX Messages until the Exporting Process has closed its end.
当收集进程不再希望接收IPFIX消息时，它应该关闭其连接端。收集进程应继续读取IPFIX消息，直到导出进程结束。
When a Collecting Process detects that the TCP connection to the Exporting Process has terminated abnormally, it MUST continue to listen for a new connection.
当收集进程检测到与导出进程的TCP连接异常终止时，它必须继续侦听新连接。
When an Exporting Process detects that the TCP connection to the Collecting Process has terminated abnormally, it SHOULD try to re-establish the connection. Connection timeouts and retry schedules SHOULD be configurable. In the default configuration, an Exporting Process MUST NOT attempt to establish a connection more frequently than once per minute.
当导出进程检测到与收集进程的TCP连接异常终止时，它应该尝试重新建立连接。连接超时和重试计划应该是可配置的。在默认配置中，导出进程尝试建立连接的频率不得超过每分钟一次。
If the Collecting Process does not acknowledge the attempt by the Exporting Process to establish a connection, it will retry using the TCP exponential backoff feature.
如果收集进程不确认导出进程建立连接的尝试，它将使用TCP指数退避功能重试。
If Collecting Process failover is supported by the Exporting Process, a second TCP connection MAY be opened in advance.
如果导出进程支持收集进程故障转移，则可以提前打开第二个TCP连接。
Once a TCP connection is established, the Exporting Process starts sending IPFIX Messages to the Collecting Process.
建立TCP连接后，导出进程将开始向收集进程发送IPFIX消息。
IPFIX Messages are sent over the TCP connection without any special encoding. The Length field in the IPFIX Message Header defines the end of each IPFIX Message and thus the start of the next IPFIX Message. This means that IPFIX Messages cannot be interleaved.
IPFIX消息通过TCP连接发送，无需任何特殊编码。IPFIX消息头中的长度字段定义每个IPFIX消息的结束，从而定义下一条IPFIX消息的开始。这意味着IPFIX消息不能交错。
In the case of TCP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent from this TCP connection, from the current Observation Domain by the Exporting Process, prior to the receipt of this IPFIX Message, modulo 2^32.
对于TCP，IPFIX序列号包含在收到此IPFIX消息（模2^32）之前，导出进程从当前观测域从该TCP连接发送的IPFIX数据记录总数。
If an Exporting Process exports data from multiple Observation Domains, it should be careful to choose IPFIX Message lengths appropriately to minimize head-of-line blocking between different Observation Domains. Multiple TCP connections MAY be used to avoid head-of-line between different Observation Domains.
如果导出进程从多个观察域导出数据，则应小心选择适当的IPFIX消息长度，以最小化不同观察域之间的行首阻塞。可以使用多个TCP连接来避免不同观测域之间的线首冲突。
For each Template, the Exporting Process MUST send the Template Record before exporting Data Records that refer to that Template.
对于每个模板，导出过程必须在导出引用该模板的数据记录之前发送模板记录。
Template IDs are unique per TCP connection and per Observation Domain. A Collecting Process MUST record all Template and Options Template Records for the duration of the connection, as an Exporting Process is not required to re-export Template Records.
每个TCP连接和每个观察域的模板ID都是唯一的。收集流程必须记录连接期间的所有模板和选项模板记录，因为重新导出模板记录不需要导出流程。
When the TCP connection restarts, the Exporting Process MUST resend all the Template Records.
当TCP连接重新启动时，导出过程必须重新发送所有模板记录。
When a TCP connection is closed, the Collecting Process MUST discard all Templates received over that connection and stop decoding IPFIX Messages that use those Templates.
当TCP连接关闭时，收集过程必须放弃通过该连接接收的所有模板，并停止对使用这些模板的IPFIX消息进行解码。
The Templates that are not used anymore SHOULD be deleted. Before reusing a Template ID, the Template MUST be deleted. In order to delete an allocated Template, the Template is withdrawn through the use of a Template Withdrawal Message over the TCP connection.
不再使用的模板应删除。在重用模板ID之前，必须删除该模板。为了删除分配的模板，通过TCP连接使用模板撤回消息撤回模板。
If the Collecting Process receives a malformed IPFIX Message, it MUST reset the TCP connection, discard the IPFIX Message, and SHOULD log the error.
如果收集进程接收到格式错误的IPFIX消息，它必须重置TCP连接，放弃IPFIX消息，并应记录错误。
TCP ensures reliable delivery of data from the Exporting Process to the Collecting Process. TCP also controls the rate at which data can be sent from the Exporting Process to the Collecting Process, using a mechanism that takes into account both congestion in the network and the capabilities of the receiver.
TCP确保数据从导出进程可靠地传递到收集进程。TCP还控制数据从导出进程发送到收集进程的速率，使用一种同时考虑网络拥塞和接收器能力的机制。
Therefore, an IPFIX Exporting Process may not be able to send IPFIX Messages at the rate that the Metering Process generates it, either because of congestion in the network or because the Collecting Process cannot handle IPFIX Messages fast enough. As long as congestion is transient, the Exporting Process can buffer IPFIX Messages for transmission. But such buffering is necessarily limited, both because of resource limitations and because of
因此，IPFIX导出进程可能无法以计量进程生成IPFIX消息的速率发送IPFIX消息，这可能是因为网络拥塞或收集进程无法足够快地处理IPFIX消息。只要拥塞是暂时的，导出过程就可以缓冲IPFIX消息进行传输。但这种缓冲必然是有限的，这既是因为资源限制，也是因为
timeliness requirements, so ongoing and/or severe congestion may lead to a situation where the Exporting Process is blocked.
及时性要求，因此持续和/或严重拥堵可能导致出口流程受阻。
When an Exporting Process has Data Records to export but the transmission buffer is full, and it wants to avoid blocking, it can decide to drop some Data Records. The dropped Data Records MUST be accounted for, so that the amount can later be exported.
当导出进程有数据记录要导出，但传输缓冲区已满，并且希望避免阻塞时，它可以决定删除一些数据记录。必须对丢弃的数据记录进行说明，以便以后可以导出该金额。
When an Exporting Process finds that the rate at which records should be exported is consistently higher than the rate at which TCP sending permits, it should provide back pressure to the Metering Processes. The Metering Process could then adapt by temporarily reducing the amount of data it generates, for example, using sampling or aggregation.
当导出过程发现应导出记录的速率始终高于TCP发送允许的速率时，它应向计量过程提供背压。然后，计量过程可以通过临时减少其生成的数据量（例如，使用采样或聚合）进行调整。
The Collecting Process SHOULD listen for a new TCP connection from the Exporting Process.
收集进程应侦听来自导出进程的新TCP连接。
If the Collecting Process receives a malformed IPFIX Message, it MUST reset the TCP connection, discard the IPFIX Message, and SHOULD log the error. Note that non-zero Set padding does not constitute a malformed IPFIX Message.
如果收集进程接收到格式错误的IPFIX消息，它必须重置TCP连接，放弃IPFIX消息，并应记录错误。请注意，非零集填充并不构成格式错误的IPFIX消息。
Template Sets and Option Template Sets are only sent once. The Collecting Process MUST store the Template Record information for the duration of the connection so that it can interpret the corresponding Data Records that are received in subsequent Data Sets.
模板集和选项模板集仅发送一次。采集过程必须在连接期间存储模板记录信息，以便能够解释在后续数据集中接收到的相应数据记录。
Template IDs are unique per TCP connection and per Observation Domain. If the Collecting Process receives a Template that has already been received but that has not previously been withdrawn (i.e., a Template Record from the same Exporter Observation Domain with the same Template ID received on the TCP connection), then the Collecting Process MUST shut down the connection.
每个TCP连接和每个观察域的模板ID都是唯一的。如果收集过程接收到一个已经接收到但之前尚未撤回的模板（即，来自同一导出器观察域的模板记录，在TCP连接上接收到相同的模板ID），则收集过程必须关闭连接。
When a TCP connection is closed, the Collecting Process MUST discard all Templates received over that connection and stop decoding IPFIX Messages that use those Templates.
当TCP连接关闭时，收集过程必须放弃通过该连接接收的所有模板，并停止对使用这些模板的IPFIX消息进行解码。
If a Collecting Process receives a Template Withdrawal Message, the Collecting Process MUST delete the corresponding Template Records associated with the specific TCP connection and specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates.
如果收集过程接收到模板撤回消息，则收集过程必须删除与特定TCP连接和特定观察域关联的相应模板记录，并停止对使用撤回模板的IPFIX消息进行解码。
If the Collecting Process receives a Template Withdrawal Message for a Template Record it has not received before on this TCP connection, it MUST reset the TCP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages.
如果收集进程在此TCP连接上收到以前从未收到的模板记录的模板撤回消息，则它必须重置TCP关联，放弃IPFIX消息，并应像记录格式错误的IPFIX消息一样记录错误。
The security considerations for the IPFIX protocol have been derived from an analysis of potential security threats, as discussed in the "Security Considerations" section of IPFIX requirements [RFC3917]. The requirements for IPFIX security are as follows:
IPFIX协议的安全注意事项源自对潜在安全威胁的分析，如IPFIX要求[RFC3917]的“安全注意事项”部分所述。IPFIX安全性要求如下：
1. IPFIX must provide a mechanism to ensure the confidentiality of IPFIX data transferred from an Exporting Process to a Collecting Process, in order to prevent disclosure of Flow Records transported via IPFIX.
1. IPFIX必须提供一种机制来确保从导出进程传输到收集进程的IPFIX数据的机密性，以防止通过IPFIX传输的流记录被泄露。
2. IPFIX must provide a mechanism to ensure the integrity of IPFIX data transferred from an Exporting Process to a Collecting Process, in order to prevent the injection of incorrect data or control information (e.g., Templates) into an IPFIX Message stream.
2. IPFIX必须提供一种机制，以确保从导出进程传输到收集进程的IPFIX数据的完整性，以防止将不正确的数据或控制信息（如模板）注入IPFIX消息流。
3. IPFIX must provide a mechanism to authenticate IPFIX Collecting and Exporting Processes, to prevent the collection of data from an unauthorized Exporting Process or the export of data to an unauthorized Collecting Process.
3. IPFIX必须提供对IPFIX收集和导出进程进行身份验证的机制，以防止从未经授权的导出进程收集数据或将数据导出到未经授权的收集进程。
Because IPFIX can be used to collect information for network forensics and billing purposes, attacks designed to confuse, disable, or take information from an IPFIX collection system may be seen as a prime objective during a sophisticated network attack.
由于IPFIX可用于收集用于网络取证和计费目的的信息，因此在复杂的网络攻击过程中，旨在混淆、禁用或获取IPFIX收集系统信息的攻击可能被视为主要目标。
An attacker in a position to inject false messages into an IPFIX Message stream can either affect the application using IPFIX (by falsifying data), or the IPFIX Collecting Process itself (by modifying or revoking Templates, or changing options); for this reason, IPFIX Message integrity is important.
能够向IPFIX消息流中注入虚假消息的攻击者可以影响使用IPFIX的应用程序（通过伪造数据），也可以影响IPFIX收集过程本身（通过修改或撤销模板或更改选项）；因此，IPFIX消息完整性非常重要。
The IPFIX Messages themselves may also contain information of value to an attacker, including information about the configuration of the network as well as end-user traffic and payload data, so care must be taken to confine their visibility to authorized users. When an Information Element containing end-user payload information is exported, it SHOULD be transmitted to the Collecting Process using a means that secures its contents against eavesdropping. Suitable mechanisms include the use of either a direct point-to-point connection or the use of an encryption mechanism. It is the
IPFIX消息本身也可能包含对攻击者有价值的信息，包括有关网络配置以及最终用户流量和有效负载数据的信息，因此必须注意将其可见性限制在授权用户。当导出包含最终用户有效负载信息的信息元素时，应使用防止其内容被窃听的方法将其传输到收集过程。合适的机制包括使用直接点对点连接或使用加密机制。它是
responsibility of the Collecting Process to provide a satisfactory degree of security for this collected data, including, if necessary, anonymization of any reported data.
收集过程的责任是为收集的数据提供令人满意的安全性，如有必要，包括对任何报告的数据进行匿名。
Transport Layer Security (TLS) [RFC4346] and Datagram Transport Layer Security (DTLS) [RFC4347] were designed to provide the confidentiality, integrity, and authentication assurances required by the IPFIX protocol, without the need for pre-shared keys.
传输层安全性（TLS）[RFC4346]和数据报传输层安全性（DTLS）[RFC4347]旨在提供IPFIX协议所需的机密性、完整性和身份验证保证，而无需预共享密钥。
With the mandatory SCTP and PR-SCTP transport protocols for IPFIX, DTLS [RFC4347] MUST be implemented. If UDP is selected as the IPFIX transport protocol, DTLS [RFC4347] MUST be implemented. If TCP is selected as the IPFIX transport protocol, TLS [RFC4346] MUST be implemented.
对于IPFIX的强制SCTP和PR-SCTP传输协议，必须实现DTL[RFC4347]。如果选择UDP作为IPFIX传输协议，则必须实现DTLS[RFC4347]。如果选择TCP作为IPFIX传输协议，则必须实现TLS[RFC4346]。
Note that DTLS is selected as the security mechanism for SCTP and PR-SCTP. Though TLS bindings to SCTP are defined in [RFC3436], they require all communication to be over reliable, bidirectional streams, and require one TLS connection per stream. This arrangement is not compatible with the rationale behind the choice of SCTP as an IPFIX transport protocol.
请注意，选择DTLS作为SCTP和PR-SCTP的安全机制。尽管[RFC3436]中定义了与SCTP的TLS绑定，但它们要求所有通信都通过可靠的双向流，并且每个流需要一个TLS连接。这种安排不符合选择SCTP作为IPFIX传输协议的基本原理。
Note that using DTLS [RFC4347] has a vulnerability, i.e., a true man in the middle may attempt to take data out of an association and fool the sender into thinking that the data was actually received by the peer. In generic TLS for SCTP (and/or TCP), this is not possible. This means that the removal of a message may become hidden from the sender or receiver. Another vulnerability of using PR-SCTP with DTLS is that someone could inject SCTP control information to shut down the SCTP association, effectively generating a loss of IPFIX Messages if those are buffered outside of the SCTP association. In the future, techniques such as [dtls-for-sctp] could be used to overcome these vulnerabilities.
注意，使用DTLS [RCF437]有一个弱点，即中间的一个真正的人可能试图从关联中取出数据并愚弄发送者以为数据实际上是由对等体接收的。在SCTP（和/或TCP）的通用TLS中，这是不可能的。这意味着删除消息可能对发送方或接收方隐藏。将PR-SCTP与DTLS结合使用的另一个漏洞是，有人可能会注入SCTP控制信息以关闭SCTP关联，如果这些消息在SCTP关联之外缓冲，则会导致IPFIX消息丢失。将来，可以使用[dtls for sctp]等技术来克服这些漏洞。
When using DTLS over SCTP, the Exporting Process MUST ensure that each IPFIX Message is sent over the same SCTP stream that would be used when sending the same IPFIX Message directly over SCTP. Note that DTLS may send its own control messages on stream 0 with full reliability; however, this will not interfere with the processing of stream 0 IPFIX Messages at the Collecting Process, because DTLS consumes its own control messages before passing IPFIX Messages up to the application layer.
在SCTP上使用DTL时，导出过程必须确保每个IPFIX消息都是通过相同的SCTP流发送的，当直接通过SCTP发送相同的IPFIX消息时，将使用相同的SCTP流。注意，DTL可以在流0上以完全可靠的方式发送自己的控制消息；但是，这不会干扰收集过程中流0 IPFIX消息的处理，因为DTL在将IPFIX消息传递到应用层之前会使用自己的控制消息。
The IPFIX Exporting Process initiates the communication to the IPFIX Collecting Process, and acts as a TLS or DTLS client according to [RFC4346] and [RFC4347], while the IPFIX Collecting Process acts as a TLS or DTLS server. The DTLS client opens a secure connection on the SCTP port 4740 of the DTLS server if SCTP or PR-SCTP is selected as the transport protocol. The TLS client opens a secure connection on the TCP port 4740 of the TLS server if TCP is selected as the transport protocol. The DTLS client opens a secure connection on the UDP port 4740 of the DTLS server if UDP is selected as the transport protocol.
IPFIX导出进程启动与IPFIX收集进程的通信，并根据[RFC4346]和[RFC4347]充当TLS或DTLS客户端，而IPFIX收集进程充当TLS或DTLS服务器。如果选择SCTP或PR-SCTP作为传输协议，DTLS客户端将在DTLS服务器的SCTP端口4740上打开安全连接。如果选择TCP作为传输协议，TLS客户端将在TLS服务器的TCP端口4740上打开安全连接。如果选择UDP作为传输协议，DTLS客户端将在DTLS服务器的UDP端口4740上打开安全连接。
IPFIX Exporting Processes and IPFIX Collecting Processes are identified by the fully qualified domain name of the interface on which IPFIX Messages are sent or received, for purposes of X.509 client and server certificates as in [RFC3280].
对于[RFC3280]中的X.509客户端和服务器证书，IPFIX导出进程和IPFIX收集进程由发送或接收IPFIX消息的接口的完全限定域名标识。
To prevent man-in-the-middle attacks from impostor Exporting or Collecting Processes, the acceptance of data from an unauthorized Exporting Process, or the export of data to an unauthorized Collecting Process, strong mutual authentication via asymmetric keys MUST be used for both TLS and DTLS. Each of the IPFIX Exporting and Collecting Processes MUST verify the identity of its peer against its authorized certificates, and MUST verify that the peer's certificate matches its fully qualified domain name, or, in the case of SCTP, the fully qualified domain name of one of its endpoints.
为了防止冒名顶替者导出或收集过程中的中间人攻击、从未经授权的导出过程中接受数据或将数据导出到未经授权的收集过程中，TLS和DTL都必须使用通过非对称密钥的强相互身份验证。每个IPFIX导出和收集进程都必须根据其授权证书验证其对等方的身份，并且必须验证对等方的证书是否与其完全限定的域名匹配，或者在SCTP的情况下，其一个端点的完全限定的域名匹配。
The fully qualified domain name used to identify an IPFIX Collecting Process or Exporting Process may be stored either in a subjectAltName extension of type dNSName, or in the most specific Common Name field of the Subject field of the X.509 certificate. If both are present, the subjectAltName extension is given preference.
用于标识IPFIX收集进程或导出进程的完全限定域名可以存储在dNSName类型的subjectAltName扩展名中，或者存储在X.509证书的Subject字段的最特定的Common name字段中。如果两者都存在，则首选subjectAltName扩展名。
Internationalized domain names (IDN) in either the subjectAltName extension of type dNSName or the most specific Common Name field of the Subject field of the X.509 certificate MUST be encoded using Punycode [RFC3492] as described in Section 4 of [RFC3490], "Conversion Operations".
dNSName类型的subjectAltName扩展名或X.509证书的Subject字段的最特定通用名字段中的国际化域名（IDN）必须使用Punycode[RFC3492]进行编码，如[RFC3490]“转换操作”第4节所述。
An attacker may mount a denial-of-service (DoS) attack against an IPFIX collection system either directly, by sending large amounts of traffic to a Collecting Process, or indirectly, by generating large amounts of traffic to be measured by a Metering Process.
攻击者可以通过直接向收集进程发送大量流量，或通过生成大量流量由计量进程测量，间接对IPFIX收集系统发起拒绝服务（DoS）攻击。
Direct denial-of-service attacks can also involve state exhaustion, whether at the transport layer (e.g., by creating a large number of pending connections), or within the IPFIX Collecting Process itself (e.g., by sending Flow Records pending Template or scope information, a large amount of Options Template Records, etc.).
直接拒绝服务攻击还可能涉及状态耗尽，无论是在传输层（例如，通过创建大量挂起的连接），还是在IPFIX收集过程本身（例如，通过发送流记录挂起模板或范围信息、大量选项模板记录等）。
SCTP mandates a cookie-exchange mechanism designed to defend against SCTP state exhaustion denial-of-service attacks. Similarly, TCP provides the "SYN cookie" mechanism to mitigate state exhaustion; SYN cookies SHOULD be used by any Collecting Process accepting TCP connections. DTLS also provides cookie exchange to protect against DTLS server state exhaustion.
SCTP强制使用cookie交换机制，旨在防御SCTP状态耗尽拒绝服务攻击。类似地，TCP提供“SYN cookie”机制来缓解状态耗尽；任何接受TCP连接的收集进程都应该使用SYN cookies。DTLS还提供cookie交换以防止DTLS服务器状态耗尽。
The reader should note that there is no way to prevent fake IPFIX Message processing (and state creation) for UDP & SCTP communication. The use of TLS and DTLS can obviously prevent the creation of fake states, but they are themselves prone to state exhaustion attacks. Therefore, Collector rate limiting SHOULD be used to protect TLS & DTLS (like limiting the number of new TLS or DTLS session per second to a sensible number).
读者应该注意，没有办法防止UDP和SCTP通信的假IPFIX消息处理（和状态创建）。TLS和DTL的使用显然可以防止伪状态的创建，但它们本身容易受到状态耗尽攻击。因此，应使用收集器速率限制来保护TLS和DTL（如将每秒新TLS或DTL会话的数量限制为合理的数量）。
IPFIX state exhaustion attacks can be mitigated by limiting the rate at which new connections or associations will be opened by the Collecting Process, the rate at which IPFIX Messages will be accepted by the Collecting Process, and adaptively limiting the amount of state kept, particularly records waiting on Templates. These rate and state limits MAY be provided by a Collecting Process; if provided, the limits SHOULD be user configurable.
IPFIX状态耗尽攻击可以通过限制收集进程打开新连接或关联的速率、收集进程接受IPFIX消息的速率以及自适应地限制保留的状态量（尤其是等待模板的记录）来缓解。这些速率和状态限制可通过收集过程提供；如果提供，限制应为用户可配置的。
Additionally, an IPFIX Collecting Process can eliminate the risk of state exhaustion attacks from untrusted nodes by requiring TLS or DTLS mutual authentication, causing the Collecting Process to accept IPFIX Messages only from trusted sources.
此外，IPFIX收集进程可以通过要求TLS或DTLS相互身份验证消除来自不受信任节点的状态耗尽攻击风险，从而导致收集进程仅接受来自受信任源的IPFIX消息。
With respect to indirect denial of service, the behavior of IPFIX under overload conditions depends on the transport protocol in use. For IPFIX over TCP, TCP congestion control would cause the flow of IPFIX Messages to back off and eventually stall, blinding the IPFIX system. PR-SCTP improves upon this situation somewhat, as some IPFIX Messages would continue to be received by the Collecting Process due to the avoidance of head-of-line blocking by SCTP's multiple streams and partial reliability features, possibly affording some visibility of the attack. The situation is similar with UDP, as some datagrams may continue to be received at the Collecting Process, effectively applying sampling to the IPFIX Message stream, implying that some forensics may be left.
关于间接拒绝服务，IPFIX在过载条件下的行为取决于使用的传输协议。对于TCP上的IPFIX，TCP拥塞控制将导致IPFIX消息流后退并最终停止，从而使IPFIX系统失明。PR-SCTP在某种程度上改善了这种情况，因为由于SCTP的多个流和部分可靠性特征避免了线首阻塞，收集过程将继续接收一些IPFIX消息，这可能会提供一些攻击可见性。这种情况与UDP类似，因为在收集过程中可能会继续接收一些数据报，从而有效地对IPFIX消息流应用采样，这意味着可能会留下一些取证。
To minimize IPFIX Message loss under overload conditions, some mechanism for service differentiation could be used to prioritize IPFIX traffic over other traffic on the same link. Alternatively, IPFIX Messages can be transported over a dedicated network. In this case, care must be taken to ensure that the dedicated network can handle the expected peak IPFIX Message traffic.
为了最大限度地减少过载条件下的IPFIX消息丢失，可以使用某种服务差异化机制，将IPFIX流量优先于同一链路上的其他流量。或者，IPFIX消息可以通过专用网络传输。在这种情况下，必须注意确保专用网络能够处理预期的峰值IPFIX消息流量。
The use of DTLS or TLS might not be possible in some cases due to performance issues or other operational concerns.
在某些情况下，由于性能问题或其他操作问题，可能无法使用DTL或TLS。
Without TLS or DTLS mutual authentication, IPFIX Exporting Processes and Collecting Processes can fall back on using IP source addresses to authenticate their peers. A policy of allocating Exporting Process and Collecting Process IP addresses from specified address ranges, and using ingress filtering to prevent spoofing, can improve the usefulness of this approach. Again, completely segregating IPFIX traffic on a dedicated network, where possible, can improve security even further. In any case, the use of open Collecting Processes (those that will accept IPFIX Messages from any Exporting Process regardless of IP address or identity) is discouraged.
如果没有TLS或DTLS相互身份验证，IPFIX导出进程和收集进程可能会依赖于使用IP源地址对其对等方进行身份验证。分配导出进程并从指定的地址范围收集进程IP地址的策略，以及使用入口过滤防止欺骗的策略，可以提高此方法的实用性。同样，如果可能，在专用网络上完全隔离IPFIX流量可以进一步提高安全性。在任何情况下，都不鼓励使用开放收集进程（这些进程将接受来自任何导出进程的IPFIX消息，无论其IP地址或身份如何）。
Modern TCP and SCTP implementations are resistant to blind insertion attacks (see [RFC1948], [RFC4960]); however, UDP offers no such protection. For this reason, IPFIX Message traffic transported via UDP and not secured via DTLS SHOULD be protected via segregation to a dedicated network.
现代TCP和SCTP实现能够抵抗盲插入攻击（请参见[RFC1948]、[RFC4960]）；但是，UDP不提供此类保护。因此，通过UDP传输且未通过DTLS保护的IPFIX消息流量应通过隔离到专用网络进行保护。
IPFIX Collecting Processes MUST detect potential IPFIX Message insertion or loss conditions by tracking the IPFIX Sequence Number, and SHOULD provide a logging mechanism for reporting out-of-sequence messages. Note that an attacker may be able to exploit the handling of out-of-sequence messages at the Collecting Process, so care should be taken in handling these conditions. For example, a Collecting Process that simply resets the expected Sequence Number upon receipt of a later Sequence Number could be temporarily blinded by deliberate injection of later Sequence Numbers.
IPFIX收集过程必须通过跟踪IPFIX序列号来检测潜在的IPFIX消息插入或丢失情况，并应提供用于报告无序消息的日志机制。请注意，攻击者可能会利用收集过程中对无序消息的处理进行攻击，因此在处理这些情况时应小心。例如，在接收到后续序列号时简单地重置预期序列号的收集过程可能会通过故意注入后续序列号而暂时失明。
IPFIX Exporting and Collecting Processes SHOULD log any connection attempt that fails due to authentication failure, whether due to being presented an unauthorized or mismatched certificate during TLS or DTLS mutual authentication, or due to a connection attempt from an unauthorized IP address when TLS or DTLS is not in use.
IPFIX导出和收集过程应记录由于身份验证失败而失败的任何连接尝试，无论是由于在TLS或DTLS相互身份验证期间提供了未经授权或不匹配的证书，还是由于在TLS或DTLS未使用时从未经授权的IP地址进行连接尝试。
IPFIX Exporting and Collecting Processes SHOULD detect and log any SCTP association reset or TCP connection reset.
IPFIX导出和收集过程应检测并记录任何SCTP关联重置或TCP连接重置。
The security of the Collector and its implementation is important to achieve overall security. However, it is outside the scope of this document.
收集器及其实现的安全性对于实现总体安全性非常重要。但是，它不在本文件的范围内。
IPFIX Messages 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.
IPFIX消息使用两个具有指定值的字段。这些是IPFIX版本号，指示用于导出IPFIX消息的IPFIX协议的哪个版本，以及IPFIX集合ID，指示IPFIX消息中每组信息的类型。
The IPFIX Version Number value of 10 is reserved for the IPFIX protocol specified in this document. Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. The Set ID value of 2 is reserved for the Template Set. The Set ID value of 3 is reserved for the Option Template Set. All other Set ID values from 4 to 255 are reserved for future use. Set ID values above 255 are used for Data Sets.
IPFIX版本号值10为本文档中指定的IPFIX协议保留。由于历史原因，集合ID值0和1未被使用[RFC3954]。集合ID值2是为模板集合保留的。设置ID值3是为选项模板集保留的。从4到255的所有其他设置ID值保留供将来使用。大于255的集合ID值用于数据集。
New assignments in either IPFIX Version Number or IPFIX Set ID assignments require a Standards Action [RFC2434], i.e., they are to be made via Standards Track RFCs approved by the IESG.
IPFIX版本号或IPFIX集合ID分配中的新分配需要标准操作[RFC2434]，即，通过IESG批准的标准跟踪RFC进行。
This appendix, which is a not a normative reference, contains IPFIX encoding examples.
本附录不是规范性参考，包含IPFIX编码示例。
Let's consider the example of an IPFIX Message composed of a Template Set, a Data Set (which contains three Data Records), an Options Template Set and a Data Set (which contains 2 Data Records related to the previous Options Template Record).
让我们考虑由模板集、数据集（包含三个数据记录）、选项模板集和数据集（包含与先前选项模板记录相关的2个数据记录）组成的IPFIX消息的示例。
IPFIX Message:
IPFIX消息：
+--------+------------------------------------------. . .
| | +--------------+ +------------------+
|Message | | Template | | Data |
| Header | | Set | | Set | . . .
| | | (1 Template) | | (3 Data Records) |
| | +--------------+ +------------------+
+--------+------------------------------------------. . .
+--------+------------------------------------------. . .
| | +--------------+ +------------------+
|Message | | Template | | Data |
| Header | | Set | | Set | . . .
| | | (1 Template) | | (3 Data Records) |
| | +--------------+ +------------------+
+--------+------------------------------------------. . .
. . .-------------------------------------------+
+------------------+ +------------------+ |
| Options | | Data | |
. . . | Template Set | | Set | |
| (1 Template) | | (2 Data Records) | |
+------------------+ +------------------+ |
. . .-------------------------------------------+
. . .-------------------------------------------+
+------------------+ +------------------+ |
| Options | | Data | |
. . . | Template Set | | Set | |
| (1 Template) | | (2 Data Records) | |
+------------------+ +------------------+ |
. . .-------------------------------------------+
The Message Header is composed of:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0x000a | Length = 152 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Header is composed of:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0x000a | Length = 152 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We want to report the following Information Elements:
我们要报告以下信息要素：
- The IPv4 source IP address: sourceIPv4Address in [RFC5102], with a length of 4 octets
- IPv4源IP地址：[RFC5102]中的sourceIPv4Address，长度为4个八位字节
- The IPv4 destination IP address: destinationIPv4Address in [RFC5102], with a length of 4 octets
- IPv4目标IP地址：[RFC5102]中的destinationIPv4Address，长度为4个八位字节
- The next-hop IP address (IPv4): ipNextHopIPv4Address in [RFC5102], with a length of 4 octets
- 下一跳IP地址（IPv4）：ipNextHopIPv4Address位于[RFC5102]中，长度为4个八位字节
- The number of packets of the Flow: inPacketDeltaCount in [RFC5102], with a length of 4 octets
- 流的数据包数：[RFC5102]中的inPacketDeltaCount，长度为4个八位字节
- The number of octets of the Flow: inOctetDeltaCount in [RFC5102], with a length of 4 octets
- 流的八位字节数：[RFC5102]中的inOctetDeltaCount，长度为4个八位字节
Therefore, the Template Set will be composed of the following:
因此，模板集将由以下内容组成：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 28 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipNextHopIPv4Address = 15 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inPacketDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 28 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipNextHopIPv4Address = 15 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inPacketDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We want to report the following Information Elements:
我们要报告以下信息要素：
- The IPv4 source IP address: sourceIPv4Address in [RFC5102], with a length of 4 octets
- IPv4源IP地址：[RFC5102]中的sourceIPv4Address，长度为4个八位字节
- The IPv4 destination IP address: destinationIPv4Address in [RFC5102], with a length of 4 octets
- IPv4目标IP地址：[RFC5102]中的destinationIPv4Address，长度为4个八位字节
- An enterprise-specific Information Element representing proprietary information, with a type of 15 and a length of 4
- 表示专有信息的企业特定信息元素，类型为15，长度为4
- The number of packets of the Flow: inPacketDeltaCount in [RFC5102], with a length of 4 octets
- 流的数据包数：[RFC5102]中的inPacketDeltaCount，长度为4个八位字节
- The number of octets of the Flow: inOctetDeltaCount in [RFC5102], with a length of 4 octets
- 流的八位字节数：[RFC5102]中的inOctetDeltaCount，长度为4个八位字节
Therefore, the Template Set will be composed of the following:
因此，模板集将由以下内容组成：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 32 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 257 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element Id. = 15| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inPacketDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 32 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 257 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element Id. = 15| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inPacketDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, we report the following three Flow Records:
在本例中，我们报告以下三个流记录：
Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets
| | | Number | Number
------------------------------------------------------------------
192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385
192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934
192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534
Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets
| | | Number | Number
------------------------------------------------------------------
192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385
192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934
192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.254 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5009 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5344385 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 748 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 388934 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.65 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6534 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.254 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5009 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5344385 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 748 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 388934 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.65 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6534 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that padding is not necessary in this example.
请注意，在本例中不需要填充。
Per line card (the router being composed of two line cards), we want to report the following Information Elements:
对于每个线路卡（路由器由两个线路卡组成），我们要报告以下信息元素：
- Total number of IPFIX Messages: exportedPacketCount [RFC5102], with a length of 2 octets
- IPFIX消息总数：exportedPacketCount[RFC5102]，长度为2个八位字节
- Total number of exported Flows: exportedFlowCount [RFC5102], with a length of 2 octets
- 导出流的总数：exportedFlowCount[RFC5102]，长度为2个八位字节
The line card, which is represented by the lineCardId Information Element [RFC5102], is used as the Scope Field.
LineCard信息元素[RFC5102]表示的线路卡用作范围字段。
Therefore, the Options Template Set will be:
因此，选项模板集将为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 258 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| lineCardId = 141 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| exportedFlowCount = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 258 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| lineCardId = 141 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| exportedFlowCount = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.4.2. Options Template Set Using Enterprise-Specific Information Elements
A.4.2. 使用企业特定信息元素的选项模板集
Per line card (the router being composed of two line cards), we want to report the following Information Elements:
对于每个线路卡（路由器由两个线路卡组成），我们要报告以下信息元素：
- Total number of IPFIX Messages: exportedPacketCount [RFC5102], with a length of 2 octets
- IPFIX消息总数：exportedPacketCount[RFC5102]，长度为2个八位字节
- An enterprise-specific number of exported Flows, with a type of 42 and a length of 4 octets
- 企业特定数量的导出流，类型为42，长度为4个八位字节
The line card, which is represented by the lineCardId Information Element [RFC5102], is used as the Scope Field.
LineCard信息元素[RFC5102]表示的线路卡用作范围字段。
The format of the Options Template Set is as follows:
选项模板集的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 259 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| lineCardId = 141 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |1|Information Element Id. = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | Enterprise number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Enterprise number | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 259 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| lineCardId = 141 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |1|Information Element Id. = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | Enterprise number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Enterprise number | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, we want to export the same information as in the example in Section A.4.1:
在本例中，我们希望导出与第A.4.1节中的示例相同的信息：
- Total number of IPFIX Messages: exportedPacketCount [RFC5102], with a length of 2 octets
- IPFIX消息总数：exportedPacketCount[RFC5102]，长度为2个八位字节
- Total number of exported Flows: exportedFlowCount [RFC5102], with a length of 2 octets
- 导出流的总数：exportedFlowCount[RFC5102]，长度为2个八位字节
But this time, the information pertains to a proprietary scope, identified by enterprise-specific Information Element number 123.
但这一次，信息属于专有范围，由企业特定信息元素编号123标识。
The format of the Options Template Set is now as follows:
选项模板集的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 260 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 | Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Enterprise Number |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| exportedFlowCount = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 260 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 | Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Enterprise Number |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| exportedFlowCount = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, we report the following two Data Records:
在本例中，我们报告以下两个数据记录：
Line Card ID | IPFIX Message | Exported Flow Records
-------------------------------------------------------------------
Line Card 1 (lineCardId=1) | 345 | 10201
Line Card 2 (lineCardId=2) | 690 | 20402
Line Card ID | IPFIX Message | Exported Flow Records
-------------------------------------------------------------------
Line Card 1 (lineCardId=1) | 345 | 10201
Line Card 2 (lineCardId=2) | 690 | 20402
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 260 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 345 | 10201 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 690 | 20402 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 260 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 345 | 10201 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 690 | 20402 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.5.1. Example of Variable-Length Information Element with Length Inferior to 255 Octets
A.5.1. 长度小于255个八位字节的可变长度信息元素示例
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 5 octet Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 5 octet Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.5.2. Example of Variable-Length Information Element with Length 255 to 65535 Octets
A.5.2. 长度为255到65535个八位字节的可变长度信息元素示例
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | 1000 | IE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1000 octet Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | 1000 | IE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1000 octet Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
References
工具书类
Normative References
规范性引用文件
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC1305，1992年3月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[RFC3436]Jungmaier，A.，Rescorla，E.，和M.Tuexen，“流控制传输协议上的传输层安全”，RFC 3436，2002年12月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（SCTP）部分可靠性扩展”，RFC 3758，2004年5月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年9月。
[RFC5102] Quittek, J., Bryant S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102]Quitek，J.，Bryant S.，Claise，B.，Aitken，P.，和J.Meyer，“IP流信息导出的信息模型”，RFC 5102，2008年1月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]Postel，J.，“传输控制协议”，STD 7，RFC 793，1981年9月。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[UDP]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
Informative References
资料性引用
[IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture Model for IP Flow Information Export", Work in Progress, September 2006.
[IPFIX-ARCH]Sadasivan，G.，Brownlee，N.，Claise，B.，和J.Quitek，“IP流信息导出的架构模型”，正在进行的工作，2006年9月。
[IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", Work in Progress, June 2007.
[IPFIX-AS]Zseby，T.，Boschi，E.，Brownlee，N.，和B.Claise，“IPFIX适用性”，正在进行的工作，2007年6月。
[PEN] IANA Private Enterprise Numbers registry http://www.iana.org/assignments/enterprise-numbers.
[PEN]IANA私营企业编号登记处http://www.iana.org/assignments/enterprise-numbers.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948]Bellovin，S.，“防御序列号攻击”，RFC 1948，1996年5月。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917]Quitek，J.，Zseby，T.，Claise，B.，和S.Zander，“IP流信息导出（IPFIX）的要求”，RFC 39172004年10月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954]Claise，B.，Ed.，“Cisco Systems NetFlow服务导出版本9”，RFC 3954，2004年10月。
[IEEE.754.1985] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 1985.
[IEEE.754.1985]电气和电子工程师协会，“二进制浮点运算标准”，IEEE标准754，1985年8月。
[dtls-for-sctp] Tuexen, M. and E. Rescola, "Datagram Transport Layer Security for Stream Control Transmission Protocol", Work in Progress, November 2007.
[dtls for sctp]Tuexen，M.和E.Rescola，“流控制传输协议的数据报传输层安全”，正在进行的工作，2007年11月。
Acknowledgments
致谢
We would like to thank the following persons: Ganesh Sadasivan for his significant contribution during the initial phases of the protocol specification; Juergen Quittek for the coordination job within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, and Andrew Johnson for the thorough reviews; Randall Stewart and Peter Lei for their SCTP expertise and contributions; Martin Djernaes for the first essay on the SCTP section; Michael Behringer and Eric Vyncke for their advice and knowledge in security; Michael Tuexen for his help regarding the DTLS section; Elisa Boschi for her contribution regarding the improvement of SCTP sections; Mark Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul Calato, and many more, for the technical reviews and feedback.
我们要感谢以下人员：Ganesh Sadasivan在协议规范的初始阶段做出了重大贡献；Juergen Quitek负责IPFIX和PSAMP内的协调工作；内维尔·布朗利、戴夫·普隆卡、保罗·艾特肯和安德鲁·约翰逊进行了全面审查；Randall Stewart和Peter Lei的SCTP专业知识和贡献；Martin Djernaes撰写了关于SCTP部分的第一篇文章；Michael Behringer和Eric Vyncke在安全方面的建议和知识；Michael Tuexen感谢他在DTLS部分的帮助；Elisa Boschi对SCTP部分改进的贡献；Mark Fullmer、Sebastian Zander、Jeff Meyer、Maurizio Molina、Carter Bullard、Tal Givoly、Lutz Mark、David Moore、Robert Lowe、Paul Calato以及更多人，用于技术评审和反馈。
Authors' Addresses
作者地址
Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 EMail: bclaise@cisco.com
Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem比利时电话：+32 2 704 5622电子邮件：bclaise@cisco.com
Stewart Bryant Cisco Systems, Inc. 250, Longwater, Green Park, Reading, RG2 6GB, United Kingdom Phone: +44 (0)20 8824-8828 EMail: stbryant@cisco.com
Stewart Bryant Cisco Systems，Inc.250，Longwater，Green Park，Reading，RG2 6GB，英国电话：+44（0）20 8824-8828电子邮件：stbryant@cisco.com
Simon Leinen SWITCH Werdstrasse 2 P.O. Box CH-8021 Zurich Switzerland Phone: +41 44 268 1536 EMail: simon.leinen@switch.ch
Simon Leinen SWITCH Werdstrasse 2邮政信箱CH-8021苏黎世瑞士电话：+41 44 268 1536电子邮件：Simon。leinen@switch.ch
Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 4342-128 EMail: Thomas.Dietz@nw.neclab.eu
Thomas Dietz NEC欧洲有限公司NEC实验室欧洲网络研究部Kurfuersten Anlage 36 69115德国海德堡电话：+49 6221 4342-128电子邮件：Thomas。Dietz@nw.neclab.eu
Brian H. Trammell CERT Network Situational Awareness Software Engineering Institute 4500 Fifth Avenue Pittsburgh, PA 15213 United States Phone: +1 412 268 9748 EMail: bht@cert.org
Brian H.Trammell CERT网络态势感知软件工程研究所美国宾夕法尼亚州匹兹堡第五大道4500号15213电话：+1 412 268 9748电子邮件：bht@cert.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见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.