Internet Engineering Task Force (IETF) B. Claise, Ed.
Request for Comments: 7011 Cisco Systems, Inc.
STD: 77 B. Trammell, Ed.
Obsoletes: 5101 ETH Zurich
Category: Standards Track P. Aitken
ISSN: 2070-1721 Cisco Systems, Inc.
September 2013
Internet Engineering Task Force (IETF) B. Claise, Ed.
Request for Comments: 7011 Cisco Systems, Inc.
STD: 77 B. Trammell, Ed.
Obsoletes: 5101 ETH Zurich
Category: Standards Track P. Aitken
ISSN: 2070-1721 Cisco Systems, Inc.
September 2013
Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information
用于流信息交换的IP流信息导出（IPFIX）协议规范
Abstract
摘要
This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are 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. This document obsoletes RFC 5101.
本文件规定了IP流量信息导出（IPFIX）协议，该协议作为通过网络传输流量信息的手段。为了将交通流信息从导出过程传输到收集过程，需要流数据的通用表示和通信它们的标准方式。本文档描述了IPFIX数据和模板记录如何通过多个传输协议从IPFIX导出过程传输到IPFIX收集过程。本文件淘汰了RFC 5101。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7011.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7011.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................5
1.1. Changes since RFC 5101 .....................................5
1.2. IPFIX Documents Overview ...................................6
2. Terminology .....................................................7
2.1. Terminology Summary Table .................................13
3. IPFIX Message Format ...........................................13
3.1. Message Header Format .....................................15
3.2. Field Specifier Format ....................................16
3.3. Set and Set Header Format .................................18
3.3.1. Set Format .........................................18
3.3.2. Set Header Format ..................................19
3.4. Record Format .............................................20
3.4.1. Template Record Format .............................20
3.4.2. Options Template Record Format .....................23
3.4.2.1. Scope .....................................23
3.4.2.2. Options Template Record Format ............24
3.4.3. Data Record Format .................................27
4. Specific Reporting Requirements ................................28
4.1. The Metering Process Statistics Options Template ..........29
4.2. The Metering Process Reliability Statistics
Options Template ..........................................29
4.3. The Exporting Process Reliability Statistics
Options Template ..........................................31
4.4. The Flow Keys Options Template ............................32
5. Timing Considerations ..........................................32
5.1. IPFIX Message Header Export Time and Flow Record Time .....32
5.2. Supporting Timestamp Wraparound ...........................33
1. Introduction ....................................................5
1.1. Changes since RFC 5101 .....................................5
1.2. IPFIX Documents Overview ...................................6
2. Terminology .....................................................7
2.1. Terminology Summary Table .................................13
3. IPFIX Message Format ...........................................13
3.1. Message Header Format .....................................15
3.2. Field Specifier Format ....................................16
3.3. Set and Set Header Format .................................18
3.3.1. Set Format .........................................18
3.3.2. Set Header Format ..................................19
3.4. Record Format .............................................20
3.4.1. Template Record Format .............................20
3.4.2. Options Template Record Format .....................23
3.4.2.1. Scope .....................................23
3.4.2.2. Options Template Record Format ............24
3.4.3. Data Record Format .................................27
4. Specific Reporting Requirements ................................28
4.1. The Metering Process Statistics Options Template ..........29
4.2. The Metering Process Reliability Statistics
Options Template ..........................................29
4.3. The Exporting Process Reliability Statistics
Options Template ..........................................31
4.4. The Flow Keys Options Template ............................32
5. Timing Considerations ..........................................32
5.1. IPFIX Message Header Export Time and Flow Record Time .....32
5.2. Supporting Timestamp Wraparound ...........................33
6. Linkage with the Information Model .............................34
6.1. Encoding of IPFIX Data Types ..............................34
6.1.1. Integral Data Types ................................34
6.1.2. Address Types ......................................34
6.1.3. float32 ............................................34
6.1.4. float64 ............................................34
6.1.5. boolean ............................................35
6.1.6. string and octetArray ..............................35
6.1.7. dateTimeSeconds ....................................35
6.1.8. dateTimeMilliseconds ...............................35
6.1.9. dateTimeMicroseconds ...............................35
6.1.10. dateTimeNanoseconds ...............................36
6.2. Reduced-Size Encoding .....................................36
7. Variable-Length Information Element ............................37
8. Template Management ............................................38
8.1. Template Withdrawal and Redefinition ......................40
8.2. Sequencing Template Management Actions ....................42
8.3. Additional Considerations for Template Management
over SCTP .................................................43
8.4. Additional Considerations for Template Management
over UDP ..................................................44
9. The Collecting Process's Side ..................................45
9.1. Collecting Process Handling of Malformed IPFIX Messages ...46
9.2. Additional Considerations for SCTP Collecting Processes ...46
9.3. Additional Considerations for UDP Collecting Processes ....46
10. Transport Protocol ............................................47
10.1. Transport Compliance and Transport Usage .................47
10.2. SCTP .....................................................48
10.2.1. Congestion Avoidance ..............................48
10.2.2. Reliability .......................................49
10.2.3. MTU ...............................................49
10.2.4. Association Establishment and Shutdown ............49
10.2.5. Failover ..........................................50
10.2.6. Streams ...........................................50
10.3. UDP ......................................................50
10.3.1. Congestion Avoidance ..............................50
10.3.2. Reliability .......................................51
10.3.3. MTU ...............................................51
10.3.4. Session Establishment and Shutdown ................51
10.3.5. Failover and Session Duplication ..................51
10.4. TCP ......................................................52
10.4.1. Congestion Avoidance ..............................52
10.4.2. Reliability .......................................52
10.4.3. MTU ...............................................52
10.4.4. Connection Establishment and Shutdown .............53
10.4.5. Failover ..........................................53
6. Linkage with the Information Model .............................34
6.1. Encoding of IPFIX Data Types ..............................34
6.1.1. Integral Data Types ................................34
6.1.2. Address Types ......................................34
6.1.3. float32 ............................................34
6.1.4. float64 ............................................34
6.1.5. boolean ............................................35
6.1.6. string and octetArray ..............................35
6.1.7. dateTimeSeconds ....................................35
6.1.8. dateTimeMilliseconds ...............................35
6.1.9. dateTimeMicroseconds ...............................35
6.1.10. dateTimeNanoseconds ...............................36
6.2. Reduced-Size Encoding .....................................36
7. Variable-Length Information Element ............................37
8. Template Management ............................................38
8.1. Template Withdrawal and Redefinition ......................40
8.2. Sequencing Template Management Actions ....................42
8.3. Additional Considerations for Template Management
over SCTP .................................................43
8.4. Additional Considerations for Template Management
over UDP ..................................................44
9. The Collecting Process's Side ..................................45
9.1. Collecting Process Handling of Malformed IPFIX Messages ...46
9.2. Additional Considerations for SCTP Collecting Processes ...46
9.3. Additional Considerations for UDP Collecting Processes ....46
10. Transport Protocol ............................................47
10.1. Transport Compliance and Transport Usage .................47
10.2. SCTP .....................................................48
10.2.1. Congestion Avoidance ..............................48
10.2.2. Reliability .......................................49
10.2.3. MTU ...............................................49
10.2.4. Association Establishment and Shutdown ............49
10.2.5. Failover ..........................................50
10.2.6. Streams ...........................................50
10.3. UDP ......................................................50
10.3.1. Congestion Avoidance ..............................50
10.3.2. Reliability .......................................51
10.3.3. MTU ...............................................51
10.3.4. Session Establishment and Shutdown ................51
10.3.5. Failover and Session Duplication ..................51
10.4. TCP ......................................................52
10.4.1. Congestion Avoidance ..............................52
10.4.2. Reliability .......................................52
10.4.3. MTU ...............................................52
10.4.4. Connection Establishment and Shutdown .............53
10.4.5. Failover ..........................................53
11. Security Considerations .......................................54
11.1. Applicability of TLS and DTLS ............................55
11.2. Usage ....................................................56
11.3. Mutual Authentication ....................................56
11.4. Protection against DoS Attacks ...........................57
11.5. When DTLS or TLS Is Not an Option ........................58
11.6. Logging an IPFIX Attack ..................................58
11.7. Securing the Collector ...................................59
11.8. Privacy Considerations for Collected Data ................59
12. Management Considerations .....................................60
13. IANA Considerations ...........................................61
Appendix A. IPFIX Encoding Examples ...............................62
A.1. Message Header Example ....................................62
A.2. Template Set Examples .....................................63
A.2.1. Template Set Using IANA Information Elements ..........63
A.2.2. Template Set Using Enterprise-Specific Information
Elements ..............................................64
A.3. Data Set Example ..........................................65
A.4. Options Template Set Examples .............................66
A.4.1. Options Template Set Using IANA Information Elements ..66
A.4.2. Options Template Set Using Enterprise-Specific
Information Elements ..................................66
A.4.3. Options Template Set Using an Enterprise-Specific
Scope .................................................67
A.4.4. Data Set Using an Enterprise-Specific Scope ...........68
A.5. Variable-Length Information Element Examples ..............69
A.5.1. Example of Variable-Length Information Element with
Length Less Than 255 Octets ...........................69
A.5.2. Example of Variable-Length Information Element with
3-Octet Length Encoding ...............................70
Normative References ..............................................71
Informative References ............................................71
Acknowledgments ...................................................74
Contributors ......................................................75
11. Security Considerations .......................................54
11.1. Applicability of TLS and DTLS ............................55
11.2. Usage ....................................................56
11.3. Mutual Authentication ....................................56
11.4. Protection against DoS Attacks ...........................57
11.5. When DTLS or TLS Is Not an Option ........................58
11.6. Logging an IPFIX Attack ..................................58
11.7. Securing the Collector ...................................59
11.8. Privacy Considerations for Collected Data ................59
12. Management Considerations .....................................60
13. IANA Considerations ...........................................61
Appendix A. IPFIX Encoding Examples ...............................62
A.1. Message Header Example ....................................62
A.2. Template Set Examples .....................................63
A.2.1. Template Set Using IANA Information Elements ..........63
A.2.2. Template Set Using Enterprise-Specific Information
Elements ..............................................64
A.3. Data Set Example ..........................................65
A.4. Options Template Set Examples .............................66
A.4.1. Options Template Set Using IANA Information Elements ..66
A.4.2. Options Template Set Using Enterprise-Specific
Information Elements ..................................66
A.4.3. Options Template Set Using an Enterprise-Specific
Scope .................................................67
A.4.4. Data Set Using an Enterprise-Specific Scope ...........68
A.5. Variable-Length Information Element Examples ..............69
A.5.1. Example of Variable-Length Information Element with
Length Less Than 255 Octets ...........................69
A.5.2. Example of Variable-Length Information Element with
3-Octet Length Encoding ...............................70
Normative References ..............................................71
Informative References ............................................71
Acknowledgments ...................................................74
Contributors ......................................................75
Traffic on a data network can be seen as consisting of flows passing through network elements. For administrative or other purposes, it is often interesting, useful, or even necessary to have access to information about these flows that pass through the network elements. A 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 a protocol to achieve these requirements. This document specifies in detail the representation of different flows, as well as the additional data required for flow interpretation, packet format, transport mechanisms used, security concerns, etc.
数据网络上的流量可以看作是由通过网络元素的流组成的。出于管理或其他目的，访问有关通过网络元素的这些流的信息通常是有趣的、有用的，甚至是必要的。采集过程应能够接收通过数据网络内多个网元的流量信息。这要求在表示流信息的方法和将流从网络元件传送到收集点的方式上具有一致性。本文件规定了实现这些要求的协议。本文档详细说明了不同流的表示，以及流解释所需的附加数据、数据包格式、使用的传输机制、安全问题等。
This document obsoletes the Proposed Standard revision of the IPFIX Protocol Specification [RFC5101]. The protocol specified by this document is interoperable with the protocol as specified in [RFC5101]. The following changes have been made to this document with respect to the previous document:
本文件废除了IPFIX协议规范[RFC5101]的拟议标准修订版。本文件规定的协议可与[RFC5101]中规定的协议进行互操作。与上一份文件相比，本文件做了以下更改：
- All outstanding technical and editorial errata on [RFC5101] have been addressed.
- [RFC5101]上所有未解决的技术和编辑勘误表均已解决。
- As the [IANA-IPFIX] registry is now the normative reference for all Information Element definitions (see [RFC7012]), all definitions of Information Elements in Section 4 have been replaced with references to that registry.
- 由于[IANA-IPFIX]注册表现在是所有信息元素定义的规范性参考（见[RFC7012]），因此第4节中的所有信息元素定义均已替换为该注册表的参考。
- The encoding of the dateTimeSeconds, dateTimeMilliseconds, dateTimeMicroseconds, and dateTimeNanoseconds data types, and the related encoding of the IPFIX Message Header Export Time field, have been clarified, especially with respect to the epoch upon which the timestamp data types are based.
- dateTimeSeconds、DateTimeMilliconds、dateTimeMicroseconds和dateTimeNanoseconds数据类型的编码，以及IPFIX消息头导出时间字段的相关编码已经阐明，特别是关于时间戳数据类型所基于的历元。
- A new Section 5.2 has been added to address wraparound of these timestamp data types after they overflow in the years 2032-2038.
- 增加了新的第5.2节，以解决这些时间戳数据类型在2032-2038年溢出后的概括问题。
- Clarifications on encoding, especially in Section 6, have been made: all IPFIX values are encoded in network byte order.
- 已经对编码进行了澄清，特别是在第6节中：所有IPFIX值都是按网络字节顺序编码的。
- Template management, as described in Section 8, has been simplified and clarified: the specification has been relaxed with respect to [RFC5101], especially concerning potential failures in Template ID reuse. Additional corner cases in template management have been addressed. The new template management language is interoperable with that in [RFC5101] to the extent that the behavior was defined in the prior specification.
- 如第8节所述，模板管理已得到简化和澄清：规范已针对[RFC5101]放松，特别是关于模板ID重用中的潜在故障。模板管理中的其他角落案例已得到解决。新的模板管理语言可以与[RFC5101]中的模板管理语言进行互操作，其行为在先前的规范中定义。
- Section 11.3 (Mutual Authentication) has been improved to refer to current practices in Transport Layer Security (TLS) mutual authentication; references to Punycode were removed, as these are covered in [RFC6125].
- 第11.3节（相互认证）已经改进，以参考传输层安全（TLS）相互认证的当前实践；删除了对Punycode的引用，因为[RFC6125]中包含了这些引用。
- Editorial improvements, including structural changes to Sections 8, 9, and 10 to improve readability, have been applied. Behavior common to all transport protocols has been separated out, with exceptions per transport specifically noted. All template management language (on both Exporting and Collecting Processes) has been unified in Section 8.
- 编辑方面的改进，包括对第8、9和10节进行结构修改，以提高可读性。所有传输协议的共同行为已被分离出来，每个传输都有例外。第8节统一了所有模板管理语言（在导出和收集过程中）。
- A new Section 12 on management considerations has been added.
- 增加了关于管理考虑的新的第12节。
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 [RFC5470], 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协议为网络管理员提供了访问IP流信息的权限。[RFC5470]根据[RFC3917]中定义的要求，定义了将测量的IP流信息从IPFIX导出过程导出到收集过程的体系结构。本文档指定了如何通过多个传输协议将IPFIX数据记录和模板从IPFIX导出进程传送到IPFIX收集进程。
Four IPFIX optimizations/extensions are currently specified: a bandwidth-saving method for the IPFIX protocol [RFC5473], an efficient method for exporting bidirectional flows [RFC5103], a method for the definition and export of complex data structures [RFC6313], and the specification of the Protocol on IPFIX Mediators [IPFIX-MED-PROTO] based on the IPFIX Mediation Framework [RFC6183].
目前指定了四种IPFIX优化/扩展：IPFIX协议的带宽节约方法[RFC5473]、导出双向流的有效方法[RFC5103]、定义和导出复杂数据结构的方法[RFC6313]、以及IPFIX中介协议的规范[IPFIX-MED-PROTO]基于IPFIX中介框架[RFC6183]。
A "file-based transport" for IPFIX, which defines how IPFIX Messages can be stored in files for document-based workflows and for archival purposes, is discussed in [RFC5655].
[RFC5655]中讨论了IPFIX的“基于文件的传输”，它定义了如何将IPFIX消息存储在文件中，以用于基于文档的工作流和存档目的。
IPFIX has a formal description of IPFIX Information Elements -- their names, data types, and additional semantic information -- as specified in [RFC7012]. The registry is maintained by IANA [IANA-IPFIX]. The inline export of the Information Element type information is specified in [RFC5610].
IPFIX对IPFIX信息元素（它们的名称、数据类型和附加语义信息）有一个正式的描述，如[RFC7012]中所述。该注册表由IANA[IANA-IPFIX]维护。[RFC5610]中规定了信息元素类型信息的内联导出。
The framework for packet selection and reporting [RFC5474] enables network elements to select subsets of packets by statistical and other methods, and to export a stream of reports on the selected packets to a Collector. The set of packet selection techniques (Sampling, Filtering, and hashing) standardized by the Packet Sampling (PSAMP) protocol is described in [RFC5475]. The PSAMP protocol [RFC5476], which uses IPFIX as its export protocol, specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collector. Instead of exporting PSAMP Packet Reports, the stream of selected packets may also serve as input to the generation of IPFIX Flow Records. Like IPFIX, PSAMP has a formal description of its Information Elements: their names, types, and additional semantic information. The PSAMP information model is defined in [RFC5477].
分组选择和报告框架[RFC5474]使网络元件能够通过统计和其他方法选择分组子集，并将所选分组的报告流导出到收集器。[RFC5475]中描述了由数据包采样（PSAMP）协议标准化的数据包选择技术集（采样、过滤和哈希）。PSAMP协议[RFC5476]使用IPFIX作为其导出协议，指定将数据包信息从PSAMP导出进程导出到PSAMP收集器。除了导出PSAMP数据包报告，所选数据包的流还可以作为IPFIX流记录生成的输入。与IPFIX一样，PSAMP对其信息元素有一个正式的描述：它们的名称、类型和附加语义信息。PSAMP信息模型在[RFC5477]中定义。
[RFC6615] specifies a MIB module for monitoring, and [RFC6728] specifies a data model for configuring and monitoring IPFIX and PSAMP-compliant devices using the Network Configuration Protocol (NETCONF). [RFC6727] specifies the PSAMP MIB module as an extension of the IPFIX SELECTOR MIB module defined in [RFC6615].
[RFC6615]指定用于监控的MIB模块，[RFC6728]指定用于使用网络配置协议（NETCONF）配置和监控IPFIX和PSAMP兼容设备的数据模型。[RFC6727]将PSAMP MIB模块指定为[RFC6615]中定义的IPFIX选择器MIB模块的扩展。
In terms of development, [RFC5153] provides guidelines for the implementation and use of the IPFIX protocol, while [RFC5471] provides guidelines for testing. Finally, [RFC5472] describes what types 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.
在开发方面，[RFC5153]提供了IPFIX协议的实施和使用指南，[RFC5471]提供了测试指南。最后，[RFC5472]描述了什么类型的应用程序可以使用IPFIX协议，以及它们如何使用提供的信息。它还展示了IPFIX框架与其他体系结构和框架的关系。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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 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 [RFC5470] are equivalent; definitions that are only relevant to the IPFIX protocol only appear here.
交通流、导出过程、收集过程、观测点等基本术语的定义在语义上与IPFIX需求文件[RFC3917]中的定义相同。为了在定义协议时更加清晰，对一些术语进行了扩展。还定义了议定书所需的其他术语。本文件和[RFC5470]中的定义等效；仅与IPFIX协议相关的定义仅出现在此处。
The terminology summary table in Section 2.1 gives a quick overview of the relationships among some of the different terms defined.
第2.1节中的术语汇总表快速概述了定义的一些不同术语之间的关系。
Observation Point
观测点
An Observation Point is a location in the network where 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.
观察点是网络中可以观察数据包的位置。示例包括连接探针的线路；共享介质，例如基于以太网的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也是唯一的。
Packet Treatment
包处理
"Packet Treatment" refers to action(s) performed on a packet by a forwarding device or other middlebox, including forwarding, dropping, delaying for traffic-shaping purposes, etc.
“数据包处理”是指转发设备或其他中间盒对数据包执行的操作，包括转发、丢弃、出于流量整形目的的延迟等。
Traffic Flow or Flow
交通流
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 packets or frames 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:
流被定义为在一定时间间隔内通过网络中观察点的一组数据包或帧。属于特定流的所有数据包都有一组公共属性。每个属性定义为将函数应用于以下值的结果：
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 the 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.
如果数据包完全满足流的所有定义属性，则它被定义为属于流。
Note that the set of packets represented by a Flow may be empty; that is, a Flow may represent zero or more packets. As sampling is a Packet Treatment, this definition 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), or
1. 属于数据包头（例如，目标IP地址），或
2. are a property of the packet itself (e.g., packet length), or
2. 是数据包本身的属性（例如，数据包长度），或
3. are derived from Packet Treatment (e.g., Autonomous System (AS) number),
3. 来自数据包处理（例如，自治系统（AS）编号），
and that are used to define a Flow (i.e., are the properties common to all packets in the Flow) are termed Flow Keys. As an example, the traditional '5-tuple' Flow Key of source and destination IP address, source and destination transport port, and transport protocol, groups together all packets belonging to a single direction of communication on a single socket.
用于定义流的属性（即流中所有数据包的公共属性）称为流键。例如，源和目标IP地址、源和目标传输端口以及传输协议的传统“5元组”流密钥将属于单个套接字上单个通信方向的所有数据包分组在一起。
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 contains 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, characteristics, and Packet Treatment observed at one or more Observation Points.
计量过程生成流量记录。流程的输入是在一个或多个观察点观察到的数据包头、特征和数据包处理。
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 IPFIX Messages to one or more Collecting Processes. The Flow Records in the Messages are generated by one or more Metering Processes.
导出进程向一个或多个收集进程发送IPFIX消息。消息中的流记录由一个或多个计量过程生成。
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 as well as arbitrary numbers of Observation Points and Metering Processes.
IPFIX设备承载至少一个导出进程。它可以承载进一步的导出过程以及任意数量的观测点和计量过程。
Collecting Process
收集过程
A Collecting Process receives IPFIX Messages from one or more Exporting Processes. The Collecting Process might process or store Flow Records received within these Messages, but such actions are out of scope for this document.
收集进程从一个或多个导出进程接收IPFIX消息。收集过程可能会处理或存储在这些消息中接收到的流记录，但此类操作超出了本文档的范围。
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 that originates at the Exporting Process and 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; the Message Header 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
设置
A Set is a collection of records that have a similar structure, prefixed by a header. In an IPFIX Message, zero or more Sets follow the Message Header. There are three different types of Sets: Template Sets, Options Template Sets, and Data Sets.
集合是具有类似结构的记录的集合，以标题为前缀。在IPFIX消息中，消息头后面有零个或多个集合。有三种不同类型的集：模板集、选项模板集和数据集。
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. Information Elements are defined in the IANA "IPFIX Information Elements" registry [IANA-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记录中的属性的独立于协议和编码的描述。信息元素在IANA“IPFIX信息元素”注册表[IANA-IPFIX]中定义。与信息元素关联的类型指示对其可能包含的内容的约束，并确定在IPFIX中使用的有效编码机制。
Transport Session
运输会议
In the 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端口的组合唯一标识。
Figure A shows a summary of IPFIX terminology.
图A显示了IPFIX术语的摘要。
+------------------+---------------------------------------------+
| | 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 zero or more Sets. The Sets can be any of these three possible 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消息格式
Following are some examples of IPFIX Messages:
以下是IPFIX消息的一些示例：
1. An IPFIX Message consisting of interleaved Template, Data, and Options Template Sets, as shown in Figure C. Here, Template and Options Template Sets are transmitted "on demand", before the first Data Set whose structure they define.
1. 由交叉模板、数据和选项模板集组成的IPFIX消息，如图C所示。此处，模板和选项模板集在定义其结构的第一个数据集之前“按需”传输。
+--------+--------------------------------------------------------+
| | +----------+ +---------+ +-----------+ +---------+ |
|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, sent after the appropriate Template Records have been defined and transmitted to the Collecting Process, as shown in Figure D.
2. 一个完全由数据集组成的IPFIX消息，在定义适当的模板记录并将其传输到收集过程后发送，如图D所示。
+--------+----------------------------------------------+
| | +---------+ +---------+ +---------+ |
|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, as shown in Figure E. Such a message can be used to define or redefine Templates and Options Templates in bulk.
3. IPFIX消息完全由模板和选项模板集组成，如图E所示。此类消息可用于批量定义或重新定义模板和选项模板。
+--------+-------------------------------------------------+
| | +----------+ +----------+ +----------+ |
|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消息头格式
Each Message Header field is exported in network byte order. The fields are defined as follows:
每个消息头字段都以网络字节顺序导出。这些字段定义如下：
Version
版本
Version of IPFIX to which this Message conforms. 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].
此消息所符合的IPFIX版本。对于当前版本，此字段的值为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 at which the IPFIX Message Header leaves the Exporter, expressed in seconds since the UNIX epoch of 1 January 1970 at 00:00 UTC, encoded as an unsigned 32-bit integer.
IPFIX消息头离开导出器的时间，以秒为单位，从1970年1月1日UTC 00:00的UNIX纪元开始，编码为无符号32位整数。
Sequence Number
序列号
Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent in the current stream from the current Observation Domain by the Exporting Process. Each SCTP Stream counts sequence numbers separately, while all messages in a TCP connection or UDP session are considered to be part of the same stream. This value can 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.
增量序列计数器，以导出进程从当前观测域在当前流中发送的所有IPFIX数据记录的2^32为模。每个SCTP流分别统计序列号，而TCP连接或UDP会话中的所有消息都被视为同一流的一部分。收集过程可以使用此值来确定是否丢失了任何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 Exporter. 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 the 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 IANA-registered Information Elements [IANA-IPFIX] and enterprise-specific Information Elements.
供应商需要能够定义专有信息元素，因为，例如，他们正在交付预标准产品，或者信息元素在某种程度上具有商业敏感性。本节介绍IANA注册信息元素[IANA-IPFIX]和企业特定信息元素的字段说明符格式。
The Information Elements are identified by the Information Element identifier. When the Enterprise bit is set to 0, the corresponding Information Element appears in [IANA-IPFIX], and the Enterprise Number MUST NOT be present. When the Enterprise bit is set to 1, the corresponding Information Element identifier identified an enterprise-specific Information Element; the Enterprise Number MUST be present. An example of this is shown in Appendix A.2.2.
信息元素由信息元素标识符标识。当企业位设置为0时，相应的信息元素出现在[IANA-IPFIX]中，且企业编号不得存在。当企业位设置为1时，对应的信息元素标识符标识企业特定的信息元素；企业编号必须存在。附录A.2.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 Information Element in [IANA-IPFIX], 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 field MUST be present.
企业比特。这是字段说明符的第一位。如果该位为零，则信息元素标识符标识[IANA-IPFIX]中的信息元素，且四个八位字节的企业编号字段不得存在。如果该位为1，则信息元素标识符标识特定于企业的信息元素，并且必须存在“企业编号”字段。
Information Element identifier
信息元素标识符
A numeric value that represents the Information Element. Refer to [IANA-IPFIX].
表示信息元素的数值。请参阅[IANA-IPFIX]。
Field Length
场长
The length of the corresponding encoded Information Element, in octets. Refer to [IANA-IPFIX]. The Field Length may be smaller than that listed in [IANA-IPFIX] if the reduced-size encoding is used (see Section 6.2). The value 65535 is reserved for variable-length Information Elements (see Section 7).
对应编码信息元素的长度，以八位字节为单位。请参阅[IANA-IPFIX]。如果使用缩小尺寸编码，则字段长度可能小于[IANA-IPFIX]中列出的长度（见第6.2节）。值65535保留用于可变长度信息元素（参见第7节）。
Enterprise Number
企业编号
IANA enterprise number [IANA-PEN] of the authority defining the Information Element identifier in this Template Record.
定义此模板记录中信息元素标识符的机构的IANA企业编号[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：集合格式
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 octets with value zero (0). 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' can be used for padding
导出过程可能会插入一些填充八位字节，以便后续集合从对齐的边界开始。出于安全原因，填充八位字节必须由值为零（0）的八位字节组成。填充长度必须小于此集合中任何允许的记录。如果需要将IPFIX消息的填充与非常短的记录相结合，则填充信息元素“paddingocets”可用于填充
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 the case of other alignments, e.g., on 8-octet boundaries.
记录长度增加到4或8个八位字节的倍数。由于模板集根据定义始终是4-octet对齐的，因此仅在其他对齐的情况下（例如，在8-octet边界上）才需要填充。
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
图一：设置标题格式
Each Set Header field is exported in network format. The fields are defined as follows:
每个集合标题字段都以网络格式导出。这些字段定义如下：
Set ID
设置ID
Identifies the Set. A value of 2 is reserved for Template Sets. A value of 3 is reserved for Options Template Sets. Values from 4 to 255 are reserved for future use. Values 256 and above are used for Data Sets. The Set ID values of 0 and 1 are not used, for historical reasons [RFC3954].
标识集合。为模板集保留值2。选项模板集保留的值为3。4到255之间的值保留供将来使用。值256及以上用于数据集。由于历史原因[RFC3954]，未使用设置的ID值0和1。
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, as 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 Element 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. Field Specifiers are defined 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 Template Record is given a unique Template ID in the range 256 to 65535. This uniqueness is local to the Transport Session and Observation Domain that generated the Template ID. Since Template IDs are used as Set IDs in the Sets they describe (see Section 3.4.3), values 0-255 are reserved for special Set types (e.g., Template Sets themselves), and Templates and Options Templates (see Section 3.4.2) cannot share Template IDs within a Transport Session and Observation Domain. There are no constraints regarding the order of the Template ID allocation. As Exporting Processes are free to allocate Template IDs as they see fit, Collecting Processes MUST NOT assume incremental Template IDs, or anything about the contents of a Template based on its Template ID alone.
每个模板记录都有一个范围为256到65535的唯一模板ID。此唯一性是生成模板ID的传输会话和观察域的本地唯一性。由于模板ID在其描述的集合中用作集合ID（请参见第3.4.3节），因此0-255的值保留给特殊集合类型（例如，模板集合本身）以及模板和选项模板（请参见第3.4.2节）无法在传输会话和观察域中共享模板ID。关于模板ID分配的顺序没有任何约束。由于导出流程可以自由分配模板ID，因此收集流程不得假定增量模板ID，或仅基于模板ID的模板内容。
Field Count
字段计数
Number of fields in this Template Record.
此模板记录中的字段数。
The example in Figure L shows a Template Set with mixed IANA-assigned and enterprise-specific Information Elements. It consists of a Set Header, a Template Header, and several Field Specifiers.
图L中的示例显示了一个模板集，其中混合了IANA分配的信息元素和特定于企业的信息元素。它由一个集合头、一个模板头和几个字段说明符组成。
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 id.s 1.2 and 2.1 appear in [IANA-IPFIX] (Enterprise bit = 0) and therefore do not need an Enterprise Number to identify them.
信息元素id.s 1.2和2.1出现在[IANA-IPFIX]（企业位=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.
由于范围的概念，选项模板记录使导出器能够向收集器提供单独使用流记录无法提供的附加信息。
See Section 4 for specific Options Templates used for reporting metadata about IPFIX Exporting and Metering Processes.
有关用于报告IPFIX导出和计量过程元数据的特定选项模板，请参见第4节。
The scope, which is only available in the Options Template Set, gives the context of the reported Information Elements in the Data Records.
范围（仅在选项模板集中可用）提供了数据记录中报告的信息元素的上下文。
The scope is one or more Information Elements, specified in the Options Template Record. At a minimum, Collecting Processes SHOULD support as scope the observationDomainId, exportingProcessId, meteringProcessId, templateId, lineCardId, exporterIPv4Address, exporterIPv6Address, and ingressInterface Information Elements. 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).
范围是在选项模板记录中指定的一个或多个信息元素。收集过程至少应支持observationDomainId、exportingProcessId、meteringProcessId、templateId、lineCardId、exporterIPv4Address、exporterIPv6Address和入口接口信息元素。IPFIX协议不阻止对范围使用任何信息元素。但是，如果将某些信息元素类型指定为范围（例如，计数器信息元素），则这些类型没有意义。
The IPFIX Message Header already contains the Observation Domain ID. If not zero, this Observation Domain ID can be considered as an implicit scope for the Data Records in the IPFIX Message.
IPFIX消息头已包含观察域ID。如果不是零，则此观察域ID可被视为IPFIX消息中数据记录的隐式作用域。
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 meteringProcessId and templateId, the combined scope is this Template for this Metering Process. If a different order of Scope Fields would result in a Record having a different semantic meaning, then the order of Scope Fields MUST be preserved by the Exporting Process. For example, in the context of PSAMP [RFC5476], 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.
选项模板记录中可能存在多个范围字段，在这种情况下，复合范围是范围的组合。例如，如果这两个作用域是meteringProcessId和templateId，则组合的作用域就是此计量流程的此模板。如果范围字段的不同顺序会导致记录具有不同的语义，则导出过程必须保留范围字段的顺序。例如，在PSAMP[RFC5476]的上下文中，如果第一个作用域定义过滤函数，而第二个作用域定义采样函数，则作用域的顺序很重要。先应用采样函数，再应用过滤函数，可能会导致与先应用过滤函数，再应用采样函数可能不同的数据记录。
An Options Template Record contains any combination of IANA-assigned and/or enterprise-specific Information Element 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. Field Specifiers are defined 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
Each Options Template Record is given a unique Template ID in the range 256 to 65535. This uniqueness is local to the Transport Session and Observation Domain that generated the Template ID. Since Template IDs are used as Set IDs in the sets they describe (see Section 3.4.3), values 0-255 are reserved for special Set types (e.g., Template Sets themselves), and Templates and Options Templates cannot share Template IDs within a Transport Session and Observation Domain. There are no constraints regarding the order of the Template ID allocation. As Exporting Processes are free to allocate Template IDs as they see fit, Collecting Processes MUST NOT assume incremental Template IDs, or anything about the contents of an Options Template based on its Template ID alone.
每个选项模板记录都有一个范围为256到65535的唯一模板ID。此唯一性是生成模板ID的传输会话和观察域的本地唯一性。由于模板ID在其描述的集合中用作集合ID（见第3.4.3节），因此0-255的值保留给特殊集合类型（例如，模板集合本身），模板和选项模板不能在传输会话和观察域内共享模板ID。关于模板ID分配的顺序没有任何约束。由于导出流程可以自由地分配模板ID，因此收集流程不得假定增量模板ID，或仅基于模板ID的选项模板内容的任何内容。
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. A scope field count of N specifies that the first N Field Specifiers in the Template Record are Scope Fields. The Scope Field Count MUST NOT be zero.
此选项模板记录中的范围字段数。范围字段是普通字段，只是在收集器中将其解释为范围。范围字段计数N指定模板记录中的前N个字段说明符是范围字段。作用域字段计数不能为零。
The example in Figure O shows an Options Template Set with mixed IANA-assigned and enterprise-specific Information Elements. It consists of a Set Header, an Options Template Header, and several Field Specifiers.
图O中的示例显示了一个选项模板集，其中混合了IANA分配的信息元素和特定于企业的信息元素。它由一个集合标题、一个选项模板标题和几个字段说明符组成。
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: Options 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 as specified in [RFC7012].
请注意，字段值的长度不一定为16位。字段值根据[RFC7012]中规定的数据类型进行编码。
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 Options 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 Options 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 Collecting Process MUST check the possible combinations of Information Elements within the Options Template Records to correctly interpret the following Options Templates.
收集过程必须检查选项模板记录中信息元素的可能组合，以正确解释以下选项模板。
The Metering Process Statistics Options Template specifies the structure of a Data Record for reporting Metering Process statistics. It SHOULD contain the following Information Elements, as defined in [IANA-IPFIX]:
计量过程统计信息选项模板指定用于报告计量过程统计信息的数据记录的结构。它应该包含[IANA-IPFIX]中定义的以下信息元素：
(scope) observationDomainId
（范围）observationDomainId
This Information Element MUST be defined as a Scope Field and MUST be present, unless the Observation Domain ID of the enclosing Message is non-zero.
此信息元素必须定义为范围字段，并且必须存在，除非封闭消息的观察域ID为非零。
(scope) meteringProcessId
（范围）meteringProcessId
If present, this Information Element MUST be defined as a Scope Field.
如果存在，则必须将此信息元素定义为范围字段。
exportedMessageTotalCount
exportedMessageTotalCount
exportedFlowRecordTotalCount
exportedFlowRecordTotalCount
exportedOctetTotalCount
ExportedActettotalCount
The Exporting Process SHOULD export the Data Record specified by the Metering Process Statistics Options 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 Statistics Options Template specifies the structure of a Data Record for reporting lack of reliability in the Metering Process. It SHOULD contain the following Information Elements, as defined in [IANA-IPFIX]:
计量过程可靠性统计选项模板指定用于报告计量过程中可靠性不足的数据记录的结构。它应该包含[IANA-IPFIX]中定义的以下信息元素：
(scope) observationDomainId
（范围）observationDomainId
This Information Element MUST be defined as a Scope Field and MUST be present, unless the Observation Domain ID of the enclosing Message is non-zero.
此信息元素必须定义为范围字段，并且必须存在，除非封闭消息的观察域ID为非零。
(scope) meteringProcessId
（范围）meteringProcessId
If present, this Information Element MUST be defined as a Scope Field.
如果存在，则必须将此信息元素定义为范围字段。
ignoredPacketTotalCount
ignoredPacketTotalCount
ignoredOctetTotalCount
IgnoreDocteTotalCount
time first packet ignored
忽略第一个数据包的时间
The timestamp of the first packet that was ignored by the Metering Process. For this timestamp, any of the following timestamp Information Elements can be used:
计量过程忽略的第一个数据包的时间戳。对于该时间戳，可以使用以下任何时间戳信息元素：
observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds.
观测时间秒、观测时间毫秒、观测时间微秒或观测时间纳秒。
time last packet ignored
忽略最后一个数据包的时间
The timestamp of the last packet that was ignored by the Metering Process. For this timestamp, any of the following timestamp Information Elements can be used:
计量过程忽略的最后一个数据包的时间戳。对于该时间戳，可以使用以下任何时间戳信息元素：
observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds.
观测时间秒、观测时间毫秒、观测时间微秒或观测时间纳秒。
The Exporting Process SHOULD export the Data Record specified by the Metering Process Reliability Statistics Options 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指定为附加范围字段。
Since the Metering Process Reliability Statistics Options Template contains two identical timestamp Information Elements, and since the order of the Information Elements in the Template Records is not guaranteed, the Collecting Process interprets the time interval of ignored packets as the range between the two values; see Section 5.2 for wraparound considerations.
由于计量过程可靠性统计选项模板包含两个相同的时间戳信息元素，并且由于不保证模板记录中信息元素的顺序，因此收集过程将被忽略分组的时间间隔解释为两个值之间的范围；参见第5.2节，了解概括考虑事项。
The Exporting Process Reliability Statistics Options Template specifies the structure of a Data Record for reporting lack of reliability in the Exporting Process. It SHOULD contain the following Information Elements, as defined in [IANA-IPFIX]:
“导出过程可靠性统计信息选项”模板指定用于报告导出过程中可靠性不足的数据记录的结构。它应该包含[IANA-IPFIX]中定义的以下信息元素：
(scope) Exporting Process Identifier
（范围）导出过程标识符
The identifier of the Exporting Process for which reliability is reported. Any of the exporterIPv4Address, exporterIPv6Address, or exportingProcessId Information Elements can be used for this field. This Information Element MUST be defined as a Scope Field.
报告可靠性的导出过程的标识符。此字段可以使用exporterIPv4Address、exporterIPv6Address或exportingProcessId信息元素中的任何一个。此信息元素必须定义为范围字段。
notSentFlowTotalCount
notSentFlowTotalCount
notSentPacketTotalCount
notSentPacketTotalCount
notSentOctetTotalCount
notSentOctetTotalCount
time first flow dropped
第一次流量下降的时间
The time at which the first Flow Record was dropped by the Exporting Process. For this timestamp, any of the following timestamp Information Elements can be used:
导出进程删除第一个流记录的时间。对于该时间戳，可以使用以下任何时间戳信息元素：
observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds.
观测时间秒、观测时间毫秒、观测时间微秒或观测时间纳秒。
time last flow dropped
上次流量下降的时间
The time at which the last Flow Record was dropped by the Exporting Process. For this timestamp, any of the following timestamp Information Elements can be used:
导出进程丢弃最后一个流记录的时间。对于该时间戳，可以使用以下任何时间戳信息元素：
observationTimeSeconds, observationTimeMilliseconds, observationTimeMicroseconds, or observationTimeNanoseconds.
观测时间秒、观测时间毫秒、观测时间微秒或观测时间纳秒。
The Exporting Process SHOULD export the Data Record specified by the Exporting Process Reliability Statistics Options Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable.
导出过程应定期或基于某些导出策略导出导出过程可靠性统计选项模板指定的数据记录。此周期或出口政策应可配置。
Since the Exporting Process Reliability Statistics Options Template contains two identical timestamp Information Elements, and since the order of the Information Elements in the Template Records is not guaranteed, the Collecting Process interprets the time interval of dropped packets as the range between the two values; see Section 5.2 for wraparound considerations.
由于导出过程可靠性统计选项模板包含两个相同的时间戳信息元素，并且由于不保证模板记录中信息元素的顺序，因此收集过程将丢弃分组的时间间隔解释为两个值之间的范围；参见第5.2节，了解概括考虑事项。
The Flow Keys Options Template specifies the structure of a Data Record for reporting the Flow Keys of reported Flows. A Flow Keys Data Record extends a particular Template Record that is referenced by its templateId. 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 Options Template SHOULD contain the following Information Elements, as defined in [IANA-IPFIX]:
流程键选项模板应包含[IANA-IPFIX]中定义的以下信息元素：
(scope) templateId
（范围）templateId
This Information Element MUST be defined as a Scope Field.
此信息元素必须定义为范围字段。
flowKeyIndicator
流量键指示器
The IPFIX Message Header Export Time field is the time at which the IPFIX Message Header leaves the Exporter, using the same encoding as the dateTimeSeconds abstract data type [RFC7012], i.e., expressed in seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, encoded as an unsigned 32-bit integer.
IPFIX消息头导出时间字段是IPFIX消息头离开导出器的时间，使用与dateTimeSeconds抽象数据类型[RFC7012]相同的编码，即以秒为单位表示，从UNIX纪元开始，1970年1月1日00:00 UTC，编码为无符号32位整数。
Certain time-related Information Elements may be expressed as an offset from this Export Time. For example, Data Records requiring a microsecond precision can export the flow start and end times with the flowStartMicroseconds and flowEndMicroseconds Information Elements, which encode the absolute time in microseconds in terms of the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit field. An alternate solution is to export the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements in the Data Record, which respectively report the flow start and end time as negative offsets from the Export Time, as an unsigned 32-bit integer. This latter solution lowers the export bandwidth requirement, saving four bytes per timestamp, while increasing the load on the Exporter,
某些与时间相关的信息元素可以表示为与此导出时间的偏移量。例如，需要微秒精度的数据记录可以使用flowStartMicroseconds和flowEndMicroseconds信息元素导出流开始和结束时间，这些信息元素以微秒为单位在64位字段中以NTP历元（1900年1月1日00:00 UTC）的形式对绝对时间进行编码。另一种解决方案是将数据记录中的flowStartDeltaMicroseconds和flowEndDeltaMicroseconds信息元素导出，这两个信息元素分别将流开始和结束时间报告为导出时间的负偏移量，并作为无符号32位整数。后一种解决方案降低了导出带宽要求，每个时间戳节省4个字节，同时增加了导出器的负载，
as the Exporting Process must calculate the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds of every single Data Record before exporting the IPFIX Message.
由于导出过程必须在导出IPFIX消息之前计算每个数据记录的flowStartDeltaMicroseconds和flowEndDeltaMicroseconds。
It must be noted that timestamps based on the Export Time impose some time constraints on the Data Records contained within the IPFIX Message. In the example of flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements, the Data Record can only contain records with timestamps within 71 minutes of the Export Time. Otherwise, the 32-bit counter would not be sufficient to contain the flow start time offset.
必须注意，基于导出时间的时间戳对IPFIX消息中包含的数据记录施加了一些时间限制。在flowStartDeltaMicroseconds和flowEndDeltaMicroseconds信息元素的示例中，数据记录只能包含时间戳在导出时间71分钟内的记录。否则，32位计数器将不足以包含流开始时间偏移。
The dateTimeSeconds abstract data type [RFC7012] and the Export Time Message Header field (Section 3.1) are encoded as 32-bit unsigned integers, expressed as seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. These values will wrap around on 7 February 2106 at 06:28:16 UTC.
dateTimeSeconds抽象数据类型[RFC7012]和导出时间消息头字段（第3.1节）被编码为32位无符号整数，表示为自UNIX纪元1970年1月1日00:00 UTC起的秒数，如[POSIX.1]中所定义。这些值将于2016年2月7日UTC 06:28:16结束。
In order to support continued use of the IPFIX protocol beyond this date, Exporting Processes SHOULD export dateTimeSeconds values and the Export Time Message Header field as the number of seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, modulo 2^32. Collecting Processes SHOULD use the current date, or other contextual information, to properly interpret dateTimeSeconds values and the Export Time Message Header field.
为了支持在此日期之后继续使用IPFIX协议，导出进程应将dateTimeSeconds值和导出时间消息头字段导出为UNIX epoch（1970年1月1日UTC 00:00时，模2^32）之后的秒数。收集过程应使用当前日期或其他上下文信息来正确解释dateTimeSeconds值和导出时间消息头字段。
There are similar considerations for the NTP-based dateTimeMicroseconds and dateTimeNanoseconds abstract data types [RFC7012]. Exporting Processes SHOULD export dateTimeMicroseconds and dateTimeNanoseconds values as if the NTP era [RFC5905] is implicit; Collecting Processes SHOULD use the current date, or other contextual information, to determine the NTP era in order to properly interpret dateTimeMicroseconds and dateTimeNanoseconds values in received Data Records.
基于NTP的dateTimeMicroseconds和dateTimeNanoseconds抽象数据类型也有类似的注意事项[RFC7012]。导出进程应该导出dateTimeMicroseconds和dateTimeNanoseconds值，就像NTP era[RFC5905]是隐式的一样；收集过程应使用当前日期或其他上下文信息来确定NTP纪元，以便正确解释接收到的数据记录中的dateTimeMicroseconds和dateTimeNanoseconds值。
The dateTimeMilliseconds abstract data type will wrap around in approximately 500 billion years; the specification of the behavior of this abstract data type after that time is left as a subject of a future revision of this specification.
DateTimeMills抽象数据类型将在大约5000亿年后结束；在此之后，此抽象数据类型的行为规范将作为本规范未来修订的主题。
The long-term storage of files [RFC5655] for archival purposes is affected by timestamp wraparound, as the use of the current date to interpret timestamp values in files stored on the order of multiple decades in the past may lead to incorrect values; therefore, it is RECOMMENDED that such files be stored with contextual information to assist in the interpretation of these timestamps.
出于存档目的，文件[RFC5655]的长期存储受到时间戳环绕的影响，因为使用当前日期解释过去几十年顺序存储的文件中的时间戳值可能会导致不正确的值；因此，建议使用上下文信息存储此类文件，以帮助解释这些时间戳。
As with values in the IPFIX Message Header and Set Header, values of all Information Elements [RFC7012], except for those of the string and octetArray data types, are encoded in canonical format in network byte order (also known as big-endian byte ordering).
与IPFIX消息头和Set头中的值一样，所有信息元素[RFC7012]的值（字符串和八进制数据类型除外）都以网络字节顺序（也称为big-endian字节顺序）的标准格式进行编码。
The following sections define the encoding of the data types specified in [RFC7012].
以下各节定义了[RFC7012]中指定的数据类型的编码。
Integral data types -- unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, and signed64 -- MUST be encoded using the default canonical format in network byte order. Signed integral data types are represented in two's complement notation.
整型数据类型——unsigned8、unsigned16、unsigned32、unsigned64、signed8、signed16、signed32和signed64——必须使用默认的规范格式以网络字节顺序进行编码。有符号整数数据类型用二的补码表示法表示。
Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be encoded the same way as the integral data types, as six, four, and sixteen octets in network byte order, respectively.
地址类型——macAddress、ipv4Address和ipv6Address——必须以与整数数据类型相同的方式进行编码，分别以网络字节顺序编码为6、4和16个八位字节。
The float32 data type MUST be encoded as an IEEE binary32 floating point type as specified in [IEEE.754.2008], in network byte order as specified in Section 3.6 of [RFC1014]. Note that on little-endian machines, byte swapping of the native representation is necessary before export. Note that the method for doing this may be implementation platform dependent.
float32数据类型必须按照[IEEE.754.2008]中规定的IEEE二进制32浮点类型编码，按照[RFC1014]第3.6节中规定的网络字节顺序编码。请注意，在little endian机器上，在导出之前需要对本机表示进行字节交换。请注意，执行此操作的方法可能依赖于实现平台。
The float64 data type MUST be encoded as an IEEE binary64 floating point type as specified in [IEEE.754.2008], in network byte order as specified in Section 3.7 of [RFC1014]. Note that on little-endian machines, byte swapping of the native representation is necessary before export. Note that the method for doing this may be implementation platform dependent.
float64数据类型必须按照[IEEE.754.2008]中规定的IEEE二进制64浮点类型进行编码，按照[RFC1014]第3.7节中规定的网络字节顺序进行编码。请注意，在little endian机器上，在导出之前需要对本机表示进行字节交换。请注意，执行此操作的方法可能依赖于实现平台。
The boolean data type is specified according to the TruthValue in [RFC2579]. It is encoded as a single-octet integer per Section 6.1.1, with the value 1 for true and value 2 for false. Every other value is undefined.
根据[RFC2579]中的TruthValue指定布尔数据类型。根据第6.1.1节，它被编码为单个八位整数，值1表示真，值2表示假。其他所有值都未定义。
The "string" data type represents a finite-length string of valid characters of the Unicode character encoding set. The string data type MUST be encoded in UTF-8 [RFC3629] format. The string is sent as an array of zero or more octets using an Information Element of fixed or variable length. IPFIX Exporting Processes MUST NOT send IPFIX Messages containing ill-formed UTF-8 string values for Information Elements of the string data type; Collecting Processes SHOULD detect and ignore such values. See [UTF8-EXPLOIT] for background on this issue.
“字符串”数据类型表示Unicode字符编码集的有效字符的有限长度字符串。字符串数据类型必须以UTF-8[RFC3629]格式编码。该字符串使用固定或可变长度的信息元素作为零个或多个八位字节的数组发送。IPFIX导出进程不得发送包含字符串数据类型信息元素格式错误的UTF-8字符串值的IPFIX消息；收集过程应该检测并忽略这些值。有关此问题的背景信息，请参阅[UTF8-APPLICE]。
The octetArray data type has no encoding rules; it represents a raw array of zero or more octets, with the interpretation of the octets defined in the Information Element definition.
八进制数组数据类型没有编码规则；它表示零个或多个八位字节的原始数组，并解释信息元素定义中定义的八位字节。
The dateTimeSeconds data type is an unsigned 32-bit integer in network byte order containing the number of seconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. dateTimeSeconds is encoded identically to the IPFIX Message Header Export Time field. It can represent dates between 1 January 1970 and 7 February 2106 without wraparound; see Section 5.2 for wraparound considerations.
dateTimeSeconds数据类型是一个网络字节顺序的无符号32位整数，包含自UNIX纪元1970年1月1日00:00 UTC以来的秒数，如[POSIX.1]中所定义。dateTimeSeconds的编码与IPFIX消息头导出时间字段的编码相同。它可以表示1970年1月1日至2106年2月7日之间的日期，无需换行符；参见第5.2节，了解概括考虑事项。
The dateTimeMilliseconds data type is an unsigned 64-bit integer in network byte order containing the number of milliseconds since the UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. It can represent dates beginning on 1 January 1970 and for approximately the next 500 billion years without wraparound.
DateTimeMillicles数据类型是一个网络字节顺序的无符号64位整数，包含自UNIX纪元1970年1月1日00:00 UTC以来的毫秒数，如[POSIX.1]中所定义。它可以表示从1970年1月1日开始的日期，以及大约未来5000亿年的日期，而不进行概括。
The dateTimeMicroseconds data type is a 64-bit field encoded according to the NTP Timestamp format as defined in Section 6 of [RFC5905]. This field is made up of two unsigned 32-bit integers in network byte order: Seconds and Fraction. The Seconds field is the number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC.
dateTimeMicroseconds数据类型是根据[RFC5905]第6节中定义的NTP时间戳格式编码的64位字段。此字段由两个无符号32位整数组成，按网络字节顺序排列：秒和分数。秒字段是自NTP纪元1900年1月1日00:00 UTC以来的秒数。
The Fraction field is the fractional number of seconds in units of 1/(2^32) seconds (approximately 233 picoseconds). It can represent dates between 1 January 1900 and 8 February 2036 in the current NTP era; see Section 5.2 for wraparound considerations.
分数字段是秒的分数，单位为1/（2^32）秒（约233皮秒）。它可以表示当前NTP时代1900年1月1日至2036年2月8日之间的日期；参见第5.2节，了解概括考虑事项。
Note that dateTimeMicroseconds and dateTimeNanoseconds share an identical encoding. The dateTimeMicroseconds data type is intended only to represent timestamps of microsecond precision. Therefore, the bottom 11 bits of the Fraction field SHOULD be zero and MUST be ignored for all Information Elements of this data type (as 2^11 x 233 picoseconds = .477 microseconds).
请注意，dateTimeMicroseconds和dateTimeNanoseconds共享相同的编码。dateTimeMicroseconds数据类型仅用于表示微秒精度的时间戳。因此，分数字段的底部11位应为零，并且对于此数据类型的所有信息元素都必须忽略（2^11 x 233皮秒=.477微秒）。
The dateTimeNanoseconds data type is a 64-bit field encoded according to the NTP Timestamp format as defined in Section 6 of [RFC5905]. This field is made up of two unsigned 32-bit integers in network byte order: Seconds and Fraction. The Seconds field is the number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The Fraction field is the fractional number of seconds in units of 1/(2^32) seconds (approximately 233 picoseconds). It can represent dates between 1 January 1900 and 8 February 2036 in the current NTP era; see Section 5.2 for wraparound considerations.
dateTimeNanoseconds数据类型是根据[RFC5905]第6节中定义的NTP时间戳格式编码的64位字段。此字段由两个无符号32位整数组成，按网络字节顺序排列：秒和分数。秒字段是自NTP纪元1900年1月1日00:00 UTC以来的秒数。分数字段是秒的分数，单位为1/（2^32）秒（约233皮秒）。它可以表示当前NTP时代1900年1月1日至2036年2月8日之间的日期；参见第5.2节，了解概括考虑事项。
Note that dateTimeMicroseconds and dateTimeNanoseconds share an identical encoding. There is no restriction on the interpretation of the Fraction field for the dateTimeNanoseconds data type.
请注意，dateTimeMicroseconds和dateTimeNanoseconds共享相同的编码。dateTimeNanoseconds数据类型的分数字段的解释没有限制。
Information Elements encoded as signed, unsigned, or float data types MAY be encoded using fewer octets than those implied by their type in the information model definition, 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 [IANA-IPFIX] always define the maximum encoding size.
编码为有符号、无符号或浮点数据类型的信息元素可以使用比其在信息模型定义中的类型所隐含的八位字节更少的八位字节进行编码，前提是较小的大小足以承载导出器可能需要传递的任何值。这降低了导出器和收集器之间的网络带宽要求。请注意，信息元素定义[IANA-IPFIX]始终定义最大编码大小。
For instance, the information model defines octetDeltaCount 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 choose to send the value as unsigned32 instead.
例如，信息模型将octetDeltaCount定义为unsigned64类型，需要64位。但是，如果导出程序在本地从未遇到发送大于4294967295的值的需要，则它可能会选择将该值作为unsigned32发送。
This behavior is indicated by the Exporter by specifying a size in the Template 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。
Reduced-size encoding MAY 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-size encoding MAY 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. In this case, the float64 would be reduced in size to 4 octets.
缩减大小编码可用于将float64缩减为float32。float32不仅减少了数字范围，而且由于尾数较小，精度也较低。在这种情况下，float64的大小将减少到4个八位字节。
Reduced-size encoding MUST NOT be applied to any other data type defined in [RFC7012] that implies a fixed length, as these types either have internal structure (such as ipv4Address or dateTimeMicroseconds) or restricted ranges that are not suitable for reduced-size encoding (such as dateTimeMilliseconds).
缩减大小编码不得应用于[RFC7012]中定义的表示固定长度的任何其他数据类型，因为这些类型要么具有内部结构（如ipv4Address或dateTimeMicroseconds），要么具有不适合缩减大小编码的受限范围（如DateTimeMillimes）。
Information Elements of type octetArray and string may be exported using any length, subject to restrictions on length specific to each Information Element, as noted in that Information Element's description.
octetArray和string类型的信息元素可以使用任何长度导出，但必须遵守每个信息元素特定的长度限制，如该信息元素的描述中所述。
The IPFIX Template mechanism is optimized for fixed-length Information Elements [RFC7012]. Where an Information Element has a variable length, the following mechanism MUST be used to carry the length information for both the IANA-assigned and enterprise-specific Information Elements.
IPFIX模板机制针对固定长度的信息元素进行了优化[RFC7012]。如果信息元素具有可变长度，则必须使用以下机制为IANA分配的信息元素和特定于企业的信息元素传递长度信息。
In the Template Set, the Information Element Field Length is recorded as 65535. This reserved length value notifies the Collecting Process that the length value 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 more common 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 (IE) (Length < 255 Octets)
图R：可变长度信息元素（IE）（长度<255个八位字节）
The length may also be encoded into 3 octets before the Information Element, allowing the length of the Information Element to be greater than or equal to 255 octets. In this case, the first octet of the Length field MUST be 255, and the length is carried in the second and third octets, as shown in Figure S.
长度也可以在信息元素之前编码为3个八位字节，允许信息元素的长度大于或等于255个八位字节。在这种情况下，长度字段的第一个八位字节必须是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 (IE) (Length 0 to 65535 Octets)
图S：可变长度信息元素（IE）（长度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 the management of Templates and Options Templates at the Exporting and Collecting Processes. The goal of Template management is to ensure, to the extent possible, that the Exporting Process and Collecting Process have a consistent view of the Templates and Options Templates used to encode and decode the Records sent from the Exporting Process to the Collecting Process.
本节介绍导出和收集过程中模板和选项模板的管理。模板管理的目标是尽可能确保导出流程和收集流程对用于编码和解码从导出流程发送到收集流程的记录的模板和选项模板具有一致的视图。
Achieving this goal is complicated somewhat by two factors: 1) the need to support the reuse of Template IDs within a Transport Session and 2) the need to support unreliable transmission for Templates when UDP is used as the transport protocol for IPFIX Messages.
实现这一目标有两个因素，这有点复杂：1）需要支持在传输会话中重用模板ID；2）当UDP用作IPFIX消息的传输协议时，需要支持模板的不可靠传输。
The Template Management mechanisms defined in this section apply to the export of IPFIX Messages on SCTP, TCP, or UDP. Additional considerations specific to SCTP and UDP transport are given in Sections 8.3 and 8.4, respectively.
本节中定义的模板管理机制适用于在SCTP、TCP或UDP上导出IPFIX消息。第8.3节和第8.4节分别给出了特定于SCTP和UDP传输的其他注意事项。
The Exporting Process assigns and maintains Template IDs per Transport Session and Observation Domain. A newly created Template Record is assigned an unused Template ID by the Exporting Process. The Collecting Process MUST store all received Template Record information for the duration of each Transport Session until reuse or withdrawal as described in Section 8.1, or expiry over UDP as described in Section 8.4, so that it can interpret the corresponding Data Records.
导出过程为每个传输会话和观察域分配并维护模板ID。导出过程会为新创建的模板记录分配一个未使用的模板ID。收集过程必须在每个传输会话期间存储所有接收到的模板记录信息，直到第8.1节所述的重用或撤销，或第8.4节所述的UDP到期，以便能够解释相应的数据记录。
The Collecting Process MUST NOT assume that the Template IDs from a given Exporting Process refer to the same Templates as they did in previous Transport Sessions from the same Exporting Process; a Collecting Process MUST NOT use Templates from one Transport Session to decode Data Sets in a subsequent Transport Session.
收集过程不得假设来自给定导出过程的模板ID引用的模板与来自同一导出过程的以前传输会话中引用的模板相同；收集过程不得使用一个传输会话中的模板对后续传输会话中的数据集进行解码。
If a specific Information Element is required by a Template but is not present in observed packets, the Exporting Process MAY choose to export Flow Records without this Information Element in a Data Record described 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 packet, the first sourceIPv4Address Information Element occurrence should be the IPv4 address of the outer header, while the second occurrence should be the address of the inner header. Collecting Processes MUST properly handle Templates with multiple identical Information Elements.
如果模板中不止一次需要一个信息元素，则该信息元素的不同出现应遵循计量过程处理的逻辑顺序。例如，如果选定的数据包经过两个哈希函数，并且如果两个哈希值在单个模板内发送，则哈希值的第一次出现应属于计量过程中的第一个哈希函数。例如，在导出IPv4-in-IPv4数据包的两个源IP地址时，出现的第一个sourceIPv4Address信息元素应为外部报头的IPv4地址，而出现的第二个信息元素应为内部报头的地址。收集过程必须正确处理具有多个相同信息元素的模板。
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
导出过程应在使用该（选项）模板ID的任何数据集之前传输模板集和选项模板集，以帮助确保收集器在接收第一条数据记录之前拥有模板记录。与模板记录相对应的数据记录可能会出现在相同和/或
subsequent IPFIX Message(s). However, 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消息。但是，收集过程不得假定数据集和关联的模板集（或选项模板集）在同一IPFIX消息中导出。
Though a Collecting Process normally receives Template Records from the Exporting Process before receiving Data Records, this is not always the case, e.g., in the case of reordering or Collecting Process restart over UDP. In these cases, the Collecting Process MAY buffer Data Records for which it has no Templates, to wait for Template Records describing them; however, note that in the presence of Template withdrawal and redefinition (Section 8.1) this may lead to incorrect interpretation of Data Records.
虽然收集进程通常在接收数据记录之前从导出进程接收模板记录，但情况并非总是如此，例如，在通过UDP重新排序或收集进程重新启动的情况下。在这些情况下，收集过程可能会缓冲没有模板的数据记录，以等待描述它们的模板记录；但是，请注意，如果存在模板撤销和重新定义（第8.1节），这可能会导致对数据记录的错误解释。
Different Observation Domains within a Transport Session MAY use the same Template ID value to refer to different Templates; Collecting Processes MUST properly handle this case.
传输会话中的不同观察域可以使用相同的模板ID值来引用不同的模板；收集过程必须正确处理此情况。
Options Templates and Templates that are related or interdependent (e.g., by sharing common properties as described in [RFC5473]) SHOULD be sent together in the same IPFIX Message.
选项模板和相关或相互依赖的模板（例如，通过共享[RFC5473]中所述的公共属性）应在同一IPFIX消息中一起发送。
Templates that will not be used further by an Exporting Process MAY be withdrawn by sending a Template Withdrawal. After receiving a Template Withdrawal, a Collecting Process MUST stop using the Template to interpret subsequently exported Data Sets. Note that this mechanism does not apply when UDP is used to transport IPFIX Messages; for that case, see Section 8.4.
导出过程将不再使用的模板可以通过发送模板撤回来撤回。收到模板撤回后，收集过程必须停止使用模板解释随后导出的数据集。请注意，当UDP用于传输IPFIX消息时，此机制不适用；对于这种情况，请参见第8.4节。
A Template Withdrawal consists of a Template Record for the Template ID to be withdrawn, with a Field Count of 0. The format of a Template Withdrawal 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 Format
图T：模板提取格式
The Set ID field MUST contain the value 2 for Template Set Withdrawal or the value 3 for Options Template Set Withdrawal. Multiple Template IDs MAY be withdrawn with a single Template Withdrawal; in that case, padding MAY be used.
集合ID字段必须包含值2（用于模板集合提取）或值3（用于选项模板集合提取）。一次模板撤销可以撤销多个模板ID；在这种情况下，可以使用填充。
Template Withdrawals MAY appear interleaved with Template Sets, Options Template Sets, and Data Sets within an IPFIX Message. In this case, the Templates and Template Withdrawals shall be interpreted as taking effect in the order in which they appear in the IPFIX Message. An Exporting Process SHOULD NOT send a Template Withdrawal until sufficient time has elapsed to allow receipt and processing of any Data Records described by the withdrawn Templates; see Section 8.2 for details regarding the sequencing of Template management actions.
模板提取可能与IPFIX消息中的模板集、选项模板集和数据集交错出现。在这种情况下，模板和模板撤回应按照其在IPFIX消息中出现的顺序解释为生效。导出流程不应发送模板撤回，直到有足够的时间允许接收和处理撤回模板描述的任何数据记录；有关模板管理行动顺序的详细信息，请参见第8.2节。
The end of a Transport Session implicitly withdraws all the Templates used within the Transport Session, and Templates must be resent during subsequent Transport Sessions between an Exporting Process and Collecting Process. This applies to SCTP and TCP only; see Sections 8.4 and 10.3.4 for discussions of Transport Session and Template lifetime over UDP.
传输会话的结束隐式地提取传输会话中使用的所有模板，并且在导出进程和收集进程之间的后续传输会话期间必须重新发送模板。这仅适用于SCTP和TCP；有关UDP上传输会话和模板生存期的讨论，请参见第8.4节和第10.3.4节。
All Templates for a given Observation Domain MAY also be withdrawn using an All Templates Withdrawal, as shown in Figure U. All Options Templates for a given Observation Domain MAY likewise be withdrawn using an All Options Templates Withdrawal, as shown in Figure V.
给定观测域的所有模板也可以使用“全部模板”撤销，如图U所示。给定观测域的所有选项模板也可以使用“全部选项模板”撤销，如图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 = 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 Templates Withdrawal Set Format
图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 = 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 Set Format
图五：所有选项模板提取集格式
Template IDs MAY be reused for new Templates by sending a new Template Record or Options Template Record for a given Template ID after withdrawing the Template.
通过在提取模板后发送给定模板ID的新模板记录或选项模板记录，可以将模板ID重新用于新模板。
If a Collecting Process receives a Template Withdrawal for a Template or Options Template it does not presently have stored, this indicates a malfunctioning or improperly implemented Exporting Process. The continued receipt and interpretation of Data Records are still possible, but the Collecting Process MUST ignore the Template Withdrawal and SHOULD log the error.
如果收集流程收到当前未存储的模板或选项模板的模板撤消，则表示导出流程出现故障或执行不当。仍然可以继续接收和解释数据记录，但收集过程必须忽略模板撤销，并记录错误。
If a Collecting Process receives a new Template Record or Options Template Record for an already-allocated Template ID, and that Template or Options Template is identical to the already-received Template or Options Template, it SHOULD log the retransmission; however, this is not an error condition, as it does not affect the interpretation of Data Records.
如果收集流程接收到已分配模板ID的新模板记录或选项模板记录，且该模板或选项模板与已接收的模板或选项模板相同，则应记录重传；但是，这不是错误情况，因为它不会影响数据记录的解释。
If a Collecting Process receives a new Template Record or Options Template Record for an already-allocated Template ID, and that Template or Options Template is different from the already-received Template or Options Template, this indicates a malfunctioning or improperly implemented Exporting Process. The continued receipt and unambiguous interpretation of Data Records for this Template ID are no longer possible, and the Collecting Process SHOULD log the error. Further Collecting Process actions are out of scope for this specification.
如果收集流程接收到已分配模板ID的新模板记录或选项模板记录，并且该模板或选项模板与已接收的模板或选项模板不同，则表示导出流程出现故障或执行不当。无法继续接收和明确解释此模板ID的数据记录，收集过程应记录错误。进一步收集过程操作超出本规范的范围。
Since there is no guarantee of the ordering of exported IPFIX Messages across SCTP Streams or over UDP, an Exporting Process MUST sequence all Template management actions (i.e., Template Records defining new Templates and Template Withdrawals withdrawing them) using the Export Time field in the IPFIX Message Header.
由于无法保证跨SCTP流或UDP对导出的IPFIX消息进行排序，因此导出过程必须使用IPFIX消息头中的导出时间字段对所有模板管理操作（即定义新模板的模板记录和提取模板的模板记录）进行排序。
An Exporting Process MUST NOT export a Data Set described by a new Template in an IPFIX Message with an Export Time before the Export Time of the IPFIX Message containing that Template. If a new Template and a Data Set described by it appear in the same IPFIX Message, the Template Set containing the Template MUST appear before the Data Set in the Message.
导出过程不能在包含该模板的IPFIX消息的导出时间之前导出由IPFIX消息中的新模板描述的数据集。如果新模板及其描述的数据集出现在同一IPFIX消息中，则包含该模板的模板集必须出现在消息中的数据集之前。
An Exporting Process MUST NOT export any Data Sets described by a withdrawn Template in IPFIX Messages with an Export Time after the Export Time of the IPFIX Message containing the Template Withdrawal withdrawing that Template.
导出过程不得导出IPFIX消息中已撤销模板描述的任何数据集，导出时间在包含模板撤销的IPFIX消息的导出时间之后，该模板撤销了该模板。
Put another way, a Template describes Data Records contained in IPFIX Messages when the Export Time of such messages is between a specific start and end time, inclusive. The start time is the Export Time of the IPFIX Message containing the Template Record. The end time is one of two times: if the template is withdrawn during the session, then it is the Export Time of the IPFIX Message containing the Template Withdrawal for the template; otherwise, it is the end of the Transport Session.
换句话说，当IPFIX消息的导出时间介于特定的开始时间和结束时间（包括开始时间和结束时间）之间时，模板描述IPFIX消息中包含的数据记录。开始时间是包含模板记录的IPFIX消息的导出时间。结束时间是两次中的一次：如果模板在会话期间被撤回，则是包含模板撤回的IPFIX消息的导出时间；否则，传输会话将结束。
Even if sent in order, IPFIX Messages containing Template management actions could arrive at the Collecting Process out of order, i.e., if sent via UDP or via different SCTP Streams. Given this, Template Withdrawals and subsequent reuse of Template IDs can significantly complicate the problem of determining Template lifetimes at the Collecting Process. A Collecting Process MAY implement a buffer and use Export Time information to disambiguate the order of Template management actions. This buffer, if implemented, SHOULD be configurable to impart a delay on the order of the maximum reordering delay experienced at the Collecting Process. Note, in this case, that the Collecting Process's clock is irrelevant: it is only comparing the Export Times of Messages to each other.
即使按顺序发送，包含模板管理操作的IPFIX消息也可能无序到达收集过程，即，如果通过UDP或不同的SCTP流发送。有鉴于此，模板提取和模板ID的后续重用会使收集过程中确定模板生命周期的问题变得非常复杂。收集过程可以实现缓冲区并使用导出时间信息来消除模板管理操作顺序的歧义。此缓冲区（如果实现）应可配置为按照收集过程中经历的最大重新排序延迟的顺序提供延迟。注意，在这种情况下，收集进程的时钟是不相关的：它只是相互比较消息的导出时间。
The specifications in this section apply only to SCTP; in cases of contradiction with specifications in Section 8 or Section 8.1, this section takes precedence.
本节中的规范仅适用于SCTP；如果与第8节或第8.1节中的规范相矛盾，则以本节为准。
Template Sets and Options Template Sets MAY be sent on any SCTP Stream. Data Sets sent on a given SCTP Stream MAY be represented by Template Records exported on any SCTP Stream.
模板集和选项模板集可以在任何SCTP流上发送。在给定SCTP流上发送的数据集可以由在任何SCTP流上导出的模板记录表示。
Template Sets and Options Template Sets MUST be sent reliably, using SCTP ordered delivery.
模板集和选项模板集必须使用SCTP有序交付可靠发送。
Template Withdrawals MAY be sent on any SCTP Stream. Template Withdrawals MUST be sent reliably, using SCTP ordered delivery. Template IDs MAY be reused by sending a Template Withdrawal and/or a new Template Record on a different SCTP Stream than the stream on which the original Template was sent.
模板提取可以在任何SCTP流上发送。模板取款必须使用SCTP有序交付可靠发送。可以通过在不同于发送原始模板的流的SCTP流上发送模板撤回和/或新模板记录来重用模板ID。
Additional Template Management considerations are provided in [RFC6526], which specifies an extension to explicitly link Templates with SCTP Streams. In exchange for more restrictive rules on the assignment of Template Records to SCTP Streams, this extension allows fast, reliable reuse of Template IDs and estimation of Data Record loss per Template.
[RFC6526]中提供了其他模板管理注意事项，其中指定了一个扩展，用于显式链接模板与SCTP流。作为对将模板记录分配给SCTP流的更严格规则的交换，此扩展允许快速、可靠地重用模板ID和估计每个模板的数据记录丢失。
The specifications in this section apply only to UDP; in cases of contradiction with specifications in Section 8 or Section 8.1, this section takes precedence.
本节中的规范仅适用于UDP；如果与第8节或第8.1节中的规范相矛盾，则以本节为准。
Since UDP provides no method for reliable transmission of Templates, Exporting Processes using UDP as the transport protocol MUST periodically retransmit each active Template at regular intervals. The Template retransmission interval MUST be configurable via, for example, the templateRefreshTimeout and optionsTemplateRefreshTimeout parameters as defined in [RFC6728]. Default settings for these values are deployment- and application-specific.
由于UDP不提供可靠传输模板的方法，因此使用UDP作为传输协议的导出进程必须定期重新传输每个活动模板。模板重新传输间隔必须可通过[RFC6728]中定义的templateRefreshTimeout和OptionTemplateRefreshTimeout参数进行配置。这些值的默认设置是特定于部署和应用程序的。
Before exporting any Data Records described by a given Template Record or Options Template Record, especially in the case of Template ID reuse as described in Section 8.1, the Exporting Process SHOULD send multiple copies of the Template Record in a separate IPFIX Message, in order to help ensure that the Collecting Process has received it.
在导出给定模板记录或选项模板记录所描述的任何数据记录之前，尤其是在第8.1节所述的模板ID重用的情况下，导出过程应在单独的IPFIX消息中发送模板记录的多个副本，以帮助确保收集过程已接收到它。
In order to minimize resource requirements for Templates that are no longer being used by the Exporting Process, the Collecting Process MAY associate a lifetime with each Template received in a Transport Session. Templates not refreshed by the Exporting Process within the lifetime can then be discarded by the Collecting Process. The Template lifetime at the Collecting Process MAY be exposed by a configuration parameter or MAY be derived from observation of the interval of periodic Template retransmissions from the Exporting Process. In this latter case, the Template lifetime SHOULD default to at least 3 times the observed retransmission rate.
为了最小化导出过程不再使用的模板的资源需求，收集过程可以将生存期与传输会话中接收到的每个模板相关联。在生命周期内未被导出进程刷新的模板可以被收集进程丢弃。收集过程中的模板生存期可以通过配置参数公开，或者可以通过观察来自导出过程的周期性模板重新传输的间隔来导出。在后一种情况下，模板生存期应默认为至少观察到的重传速率的3倍。
Template Withdrawals (Section 8.1) MUST NOT be sent by Exporting Processes exporting via UDP and MUST be ignored by Collecting Processes collecting via UDP. Template IDs MAY be reused by Exporting Processes by exporting a new Template for the Template ID after waiting at least 3 times the retransmission delay. Note that Template ID reuse may lead to incorrect interpretation of Data Records if the retransmission and lifetime are not properly configured.
模板提取（第8.1节）不得通过导出通过UDP导出的进程发送，并且必须通过收集通过UDP收集的进程忽略。在等待至少3倍的重传延迟后，通过导出模板ID的新模板，可以通过导出过程重用模板ID。请注意，如果未正确配置重传和生存期，模板ID重用可能会导致对数据记录的错误解释。
When a Collecting Process receives a new Template Record or Options Template Record via UDP for an already-allocated Template ID, and that Template or Options Template is identical to the already-received Template or Options Template, it SHOULD NOT log the retransmission, as this is the normal operation of Template refresh over UDP.
当收集流程通过UDP接收到已分配模板ID的新模板记录或选项模板记录，并且该模板或选项模板与已接收的模板或选项模板相同时，它不应记录重传，因为这是UDP上模板刷新的正常操作。
When a Collecting Process receives a new Template Record or Options Template Record for an already-allocated Template ID, and that Template or Options Template is different from the already-received Template or Options Template, the Collecting Process MUST replace the Template or Options Template for that Template ID with the newly received Template or Options Template. This is the normal operation of Template ID reuse over UDP.
当采集流程收到已分配模板ID的新模板记录或选项模板记录，且该模板或选项模板与已收到的模板或选项模板不同时，收集过程必须用新收到的模板或选项模板替换该模板ID的模板或选项模板。这是UDP上模板ID重用的正常操作。
As 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 Records: <IPFIX Device, Exporter source UDP port, Collector IP address, Collector destination UDP port, Observation Domain ID, Template ID, Template Definition, Last Received>.
由于每个UDP会话和每个观察域的模板ID都是唯一的，因此在任何给定时间，收集过程都应为所有当前模板记录和选项模板记录维护以下内容：<IPFIX设备、导出器源UDP端口、收集器IP地址、收集器目标UDP端口、观察域ID、模板ID、，模板定义，上次收到>。
This section describes the handling of the IPFIX protocol at the Collecting Process common to all transport protocols. Additional considerations for SCTP and UDP are provided in Sections 9.2 and 9.3, respectively. Template management at Collecting Processes is covered in Section 8.
本节描述了所有传输协议通用的收集过程中IPFIX协议的处理。第9.2节和第9.3节分别提供了SCTP和UDP的其他注意事项。第8节介绍了收集过程中的模板管理。
The Collecting Process MUST listen for association requests / connections to start new Transport Sessions from the Exporting Process.
收集进程必须侦听关联请求/连接，才能从导出进程启动新的传输会话。
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 received Data Records.
收集过程必须注意它不理解的任何信息元素的信息元素标识符，并且可以从接收到的数据记录中丢弃该信息元素。
The Collecting Process 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 minimum 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 can 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 the Collecting Process receives a malformed IPFIX Message, it MUST discard the IPFIX Message and SHOULD log the error. A malformed IPFIX Message is one that cannot be interpreted due to nonsensical length values (e.g., a variable-length Information Element longer than its enclosing Set, a Set longer than its enclosing IPFIX Message, or an IPFIX Message shorter than an IPFIX Message Header) or a reserved Version value (which may indicate that a future version of IPFIX is being used for export but in practice occurs most often when non-IPFIX data is sent to an IPFIX Collecting Process). Note that non-zero Set padding does not constitute a malformed IPFIX Message.
如果收集进程接收到格式错误的IPFIX消息，它必须丢弃IPFIX消息并记录错误。格式错误的IPFIX消息是由于无意义的长度值（例如，长度可变的信息元素大于其封闭集、长度大于其封闭的IPFIX消息或长度小于IPFIX消息头）或保留版本值而无法解释的消息（这可能表明正在使用未来版本的IPFIX进行导出，但实际上，最常见的情况是将非IPFIX数据发送到IPFIX收集进程）。请注意，非零集填充并不构成格式错误的IPFIX消息。
As the most likely cause of malformed IPFIX Messages is a poorly implemented Exporting Process, or the sending of non-IPFIX data to an IPFIX Collecting Process, human intervention is likely necessary to correct the issue. In the meantime, the Collecting Process MAY attempt to rectify the situation any way it sees fit, including:
由于IPFIX消息格式不正确的最可能原因是导出过程执行不善，或者向IPFIX收集过程发送非IPFIX数据，因此可能需要人为干预来纠正此问题。同时，收集过程可尝试以其认为合适的任何方式纠正情况，包括：
- terminating the TCP connection or SCTP connection
- 正在终止TCP连接或SCTP连接
- using the receiver window to reduce network load from the malfunctioning Exporting Process
- 使用receiver窗口减少因导出过程出现故障而导致的网络负载
- buffering and saving malformed IPFIX Message(s) to assist in diagnosis
- 缓冲和保存格式错误的IPFIX消息以帮助诊断
- attempting to resynchronize the stream, e.g., as described in Section 10.3 of [RFC5655]
- 尝试重新同步流，如[RFC5655]第10.3节所述
Resynchronization should only be attempted if the Collecting Process has reason to believe that the error is transient. On the other hand, the Collecting Process SHOULD stop processing IPFIX Messages from clearly malfunctioning Exporting Processes (e.g., those from which the last few IPFIX Messages have been malformed).
只有在收集过程有理由相信错误是暂时的情况下，才应尝试重新同步。另一方面，收集进程应停止处理明显出现故障的导出进程中的IPFIX消息（例如，最后几条IPFIX消息格式错误的导出进程）。
As an Exporting Process may request and support more than one stream per SCTP association, the Collecting Process MUST support the opening of multiple SCTP Streams.
由于导出进程可能请求并支持每个SCTP关联的多个流，因此收集进程必须支持打开多个SCTP流。
A Transport Session for IPFIX Messages transported over UDP is defined from the point of view of the Exporting Process and roughly corresponds to the time during which a given Exporting Process sends IPFIX Messages over UDP to a given Collecting Process. Since this is
通过UDP传输的IPFIX消息的传输会话是从导出进程的角度定义的，大致对应于给定导出进程通过UDP向给定收集进程发送IPFIX消息的时间。既然这是
difficult to detect at the Collecting Process, the Collecting Process MAY discard all Transport Session state after no IPFIX Messages are received from a given Exporting Process within a given Transport Session during a configurable idle timeout.
在收集过程中很难检测到，在可配置的空闲超时期间，在给定的传输会话内没有从给定的导出过程接收到IPFIX消息后，收集过程可能会放弃所有传输会话状态。
The Collecting Process SHOULD accept Data Records without the associated Template Record (or other definitions such as Common Properties) required to decode the Data Record. If the Template Records or other definitions 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 or other definitions are received, comparing Export Times of IPFIX Messages containing the Template Records with those containing the Data Records as discussed in Section 8.2. Note that this mechanism may lead to incorrectly interpreted records in the presence of Template ID reuse or other identifiers with limited lifetimes.
收集过程应接受没有解码数据记录所需的关联模板记录（或其他定义，如公共属性）的数据记录。如果在接收数据记录时未接收到模板记录或其他定义，则收集过程可在短时间内存储数据记录，并在接收到模板记录或其他定义后对其进行解码，如第8.2节所述，比较包含模板记录的IPFIX消息与包含数据记录的IPFIX消息的导出时间。请注意，在存在模板ID重用或其他生命周期有限的标识符的情况下，此机制可能会导致错误解释的记录。
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消息长度。
While an Exporting Process or Collecting Process may support multiple transport protocols, Transport Sessions are bound to a transport protocol. Transport Session state MUST NOT be migrated by an Exporting Process or Collecting Process among Transport Sessions using different transport protocols between the same Exporting Process and Collecting Process pair. In other words, an Exporting Process supporting multiple transport protocols is conceptually multiple Exporting Processes, one per supported transport protocol. Likewise, a Collecting Process supporting multiple transport protocols is conceptually multiple Collecting Processes, one per supported transport protocol.
虽然导出进程或收集进程可能支持多个传输协议，但传输会话绑定到传输协议。在同一导出进程和收集进程对之间使用不同传输协议的传输会话之间，导出进程或收集进程不得迁移传输会话状态。换句话说，支持多个传输协议的导出过程在概念上是多个导出过程，每个支持的传输协议一个导出过程。同样，支持多个传输协议的收集过程在概念上是多个收集过程，每个支持的传输协议一个。
SCTP [RFC4960] using the Partially Reliable SCTP (PR-SCTP) extension as 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]中规定的部分可靠SCTP（PR-SCTP）扩展的SCTP[RFC4960]必须由所有符合要求的实现实现。UDP[UDP]也可以通过兼容的实现来实现。TCP[TCP]也可以通过兼容实现来实现。
SCTP should be used in deployments where Exporters and Collectors are communicating over links that are susceptible to congestion. SCTP is capable of providing any required degree of reliability when used with the PR-SCTP extension.
SCTP应用于导出器和收集器通过易受拥塞影响的链路进行通信的部署中。当与PR-SCTP扩展一起使用时，SCTP能够提供任何所需的可靠性。
TCP may be used in deployments where Exporters and Collectors communicate over links that are susceptible to congestion, but SCTP is preferred, due to its ability to limit back pressure on Exporters and its message-versus-stream orientation.
TCP可用于导出器和收集器通过易受拥塞影响的链路进行通信的部署中，但SCTP是首选，因为它能够限制导出器的背压以及消息相对于流的方向。
UDP may be used, although it is not a congestion-aware protocol. However, in this case the IPFIX traffic between the Exporter and Collector must be separately contained or provisioned to minimize the risk of congestion-related loss.
可以使用UDP，尽管它不是拥塞感知协议。但是，在这种情况下，导出器和收集器之间的IPFIX流量必须单独包含或配置，以将拥塞相关损失的风险降至最低。
By default, the Collecting Process listens for connections on SCTP, TCP, and/or UDP port 4739. By default, the Collecting Process listens for secure connections on SCTP, TCP, and/or UDP port 4740 (refer to the Security Considerations section). By default, the Exporting Process attempts to connect to one of these ports. It MUST be possible to configure both the Exporting and Collecting Processes to use different ports than the default.
默认情况下，收集进程侦听SCTP、TCP和/或UDP端口4739上的连接。默认情况下，收集进程侦听SCTP、TCP和/或UDP端口4740上的安全连接（请参阅安全注意事项部分）。默认情况下，导出进程将尝试连接到其中一个端口。必须能够将导出和收集过程配置为使用不同于默认端口的端口。
This section describes how IPFIX is transported over SCTP [RFC4960] using the PR-SCTP [RFC3758] extension.
本节介绍如何使用PR-SCTP[RFC3758]扩展通过SCTP[RFC4960]传输IPFIX。
SCTP provides the required level of congestion avoidance by design.
SCTP通过设计提供所需的拥塞避免级别。
SCTP detects congestion in the end-to-end path between the IPFIX Exporting Process and the IPFIX Collecting Process, and limits 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 decide to drop the record. In the latter case, the dropped export data SHOULD be accounted for, so that the amount of dropped export data can be reported using the mechanism described in Section 4.3.
SCTP检测IPFIX导出进程和IPFIX收集进程之间的端到端路径中的拥塞，并相应地限制传输速率。当IPFIX导出进程有记录要导出，但检测到SCTP暂时无法传输时，它可以等待，直到可以再次发送，或者决定删除该记录。在后一种情况下，应考虑丢弃的导出数据，以便使用第4.3节中描述的机制报告丢弃的导出数据量。
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 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.
使用可靠的SCTP消息进行IPFIX导出本身并不能保证所有数据记录都能被传递。如果从导出过程到收集过程的链路上存在拥塞，或者如果需要大量的重新传输，则导出过程上的发送队列可能会填满；导出过程可以挂起、导出或放弃IPFIX消息。如果数据记录被丢弃，用于导出的IPFIX序列号必须反映数据丢失。
SCTP provides the required IPFIX Message fragmentation service based on Path MTU (PMTU) discovery.
SCTP基于路径MTU（PMTU）发现提供所需的IPFIX消息分段服务。
The IPFIX Exporting Process initiates an SCTP association with the IPFIX Collecting Process. The Exporting Process MAY establish more than one association (connection "bundle" in SCTP terminology) to the Collecting Process.
IPFIX导出进程启动与IPFIX收集进程的SCTP关联。导出过程可能与收集过程建立多个关联（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.
关联超时应该是可配置的。
If the Collecting Process does not acknowledge an attempt by the Exporting Process to establish an association, SCTP will automatically retry association establishment using exponential backoff. The Exporter MAY log an alarm if the underlying SCTP association establishment times out; this timeout should be configurable on the Exporter.
如果收集进程未确认导出进程建立关联的尝试，SCTP将使用指数退避自动重试关联建立。如果基础SCTP关联建立超时，导出程序可能会记录警报；应在导出器上配置此超时。
The Exporting Process MAY open a backup SCTP association to a Collecting Process in advance, if it supports Collecting Process failover.
如果导出进程支持收集进程故障切换，则可以提前打开与收集进程的备份SCTP关联。
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 specification [RFC3758] 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消息标记为重新传输。
This section describes how IPFIX is 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., links that are over-provisioned 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 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.
收集过程应通过查看IPFIX序列号中的不连续性来推断IPFIX数据记录的丢失和重新排序。对于UDP，IPFIX序列号包含在收到此IPFIX消息之前为传输会话发送的IPFIX数据记录总数，模为2^32。收集器应通过跟踪序列号来检测无序、丢弃或重复的IPFIX消息。
Exporting Processes exporting IPFIX Messages via UDP MUST include a valid UDP checksum [UDP] in UDP datagrams including IPFIX Messages.
导出进程通过UDP导出IPFIX消息必须在包含IPFIX消息的UDP数据报中包含有效的UDP校验和[UDP]。
The maximum size of exported messages MUST be configured such that the total packet size does not exceed the PMTU. If the PMTU is unknown, a maximum packet size of 512 octets SHOULD be used.
必须配置导出消息的最大大小，以便总数据包大小不超过PMTU。如果PMTU未知，则应使用512个八位字节的最大数据包大小。
As UDP is a connectionless protocol, there is no real session establishment or shutdown for IPFIX over UDP. An Exporting Process starts sending IPFIX Messages to a Collecting Process at one point in time and stops sending them at another point in time. This can lead to some complications in Template management, as outlined in Section 8.4 above.
由于UDP是一种无连接协议，因此通过UDP的IPFIX没有真正的会话建立或关闭。导出进程在一个时间点开始向收集进程发送IPFIX消息，并在另一个时间点停止发送它们。如上文第8.4节所述，这可能会导致模板管理出现一些复杂情况。
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 is transported over TCP [TCP].
本节介绍如何通过TCP[TCP]传输IPFIX。
TCP 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控制数据从导出进程发送到收集进程的速率，使用一种同时考虑网络拥塞和接收器能力的机制。
Therefore, an IPFIX Exporting Process may not be able to send IPFIX Messages at the rate that the Metering Process generates them, 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 timeliness requirements, so ongoing and/or severe congestion may lead to a situation where the Exporting Process is blocked.
因此，IPFIX导出进程可能无法以计量进程生成IPFIX消息的速率发送IPFIX消息，这可能是因为网络拥塞或收集进程无法足够快地处理IPFIX消息。只要拥塞是暂时的，导出过程就可以缓冲IPFIX消息进行传输。但由于资源限制和及时性要求，这种缓冲必然受到限制，因此持续和/或严重的拥塞可能导致出口过程受阻。
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 number of lost records can later be reported as described in Section 4.3.
当导出进程有数据记录要导出，但传输缓冲区已满，并且希望避免阻塞时，它可以决定删除一些数据记录。必须对丢失的数据记录进行说明，以便以后可以按照第4.3节所述报告丢失记录的数量。
TCP ensures reliable delivery of data from the Exporting Process to the Collecting Process.
TCP确保数据从导出进程可靠地传递到收集进程。
As TCP offers a stream service instead of a datagram or sequential packet service, IPFIX Messages transported over TCP are instead separated using the Length field in the IPFIX Message Header. The Exporting Process can choose any valid length for exported IPFIX Messages, as TCP handles segmentation.
由于TCP提供流服务而不是数据报或顺序数据包服务，因此通过TCP传输的IPFIX消息将使用IPFIX消息头中的长度字段进行分隔。导出过程可以为导出的IPFIX消息选择任何有效长度，因为TCP处理分段。
Exporting Processes may choose IPFIX Message lengths lower than the maximum in order to ensure timely export of Data Records.
导出进程可以选择小于最大值的IPFIX消息长度，以确保及时导出数据记录。
The IPFIX Exporting Process initiates a TCP connection to the Collecting Process. 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). An Exporting Process MAY support more than one active connection to the same Collecting Process to avoid head-of-line blocking across Observation Domains.
IPFIX导出进程启动到收集进程的TCP连接。导出进程可能支持到不同收集进程的多个活动连接（包括同一主机上不同收集进程的情况）。导出进程可以支持多个到同一个收集进程的活动连接，以避免跨观察域的行首阻塞。
The Exporter MAY log an alarm if the underlying TCP connection establishment times out; this timeout should be configurable on the Exporter.
如果底层TCP连接建立超时，导出器可能会记录警报；应在导出器上配置此超时。
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 an attempt by the Exporting Process to establish a connection, TCP will automatically retry connection establishment using exponential backoff. The Exporter MAY log an alarm if the underlying TCP connection establishment times out; this timeout should be configurable on the Exporter.
如果收集进程未确认导出进程建立连接的尝试，TCP将使用指数退避自动重试建立连接。如果底层TCP连接建立超时，导出器可能会记录警报；应在导出器上配置此超时。
The Exporting Process MAY open a backup TCP connection to a Collecting Process in advance, if it supports Collecting Process failover.
如果导出进程支持收集进程故障切换，则可以提前打开到收集进程的备份TCP连接。
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 the IPFIX requirements document [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), or the duplication of Messages, in 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 affect either 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 assumed to be unavailable to attackers, or the use of an encryption mechanism. It is the responsibility of the Collecting Process to provide a satisfactory degree of security for this collected data, including, if necessary, encryption and/or anonymization of any reported data; see Section 11.8.
IPFIX消息本身也可能包含对攻击者有价值的信息，包括有关网络配置以及最终用户流量和有效负载数据的信息，因此必须注意将其可见性限制在授权用户。当导出包含最终用户有效负载信息的信息元素时，应使用防止其内容被窃听的方法将其传输到收集过程。合适的机制包括使用假定攻击者不可用的直接点对点连接，或使用加密机制。收集过程负责为收集的数据提供令人满意的安全性，包括在必要时对任何报告的数据进行加密和/或匿名化；见第11.8节。
Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347] were designed to provide the confidentiality, integrity, and authentication assurances required by the IPFIX protocol, without the need for pre-shared keys.
传输层安全性（TLS）[RFC5246]和数据报传输层安全性（DTLS）[RFC6347]旨在提供IPFIX协议所需的机密性、完整性和身份验证保证，而无需预共享密钥。
IPFIX Exporting Processes and Collecting Processes using TCP MUST support TLS version 1.1 and SHOULD support TLS version 1.2 [RFC5246], including the mandatory ciphersuite(s) specified in each version. IPFIX Exporting Processes and Collecting Processes using UDP or SCTP MUST support DTLS version 1.0 and SHOULD support DTLS version 1.2 [RFC6347], including the mandatory ciphersuite(s) specified in each version.
使用TCP的IPFIX导出进程和收集进程必须支持TLS版本1.1，并应支持TLS版本1.2[RFC5246]，包括每个版本中指定的强制密码套件。使用UDP或SCTP的IPFIX导出进程和收集进程必须支持DTLS 1.0版，并应支持DTLS 1.2版[RFC6347]，包括每个版本中指定的强制密码套件。
Note that DTLS is selected as the security mechanism for SCTP. Though TLS bindings to SCTP are defined in [RFC3436], they require that all communication be over reliable, bidirectional streams, and they also 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的安全机制。尽管[RFC3436]中定义了与SCTP的TLS绑定，但它们要求所有通信都通过可靠的双向流，并且它们还要求每个流有一个TLS连接。这种安排不符合选择SCTP作为IPFIX传输协议的基本原理。
Note that using DTLS has a man-in-the-middle vulnerability not present in TLS, allowing a message to be removed from the stream without the knowledge of either the sender or receiver. Additionally, when using DTLS over SCTP, an attacker could inject SCTP control information and shut down the SCTP association, causing a loss of IPFIX Messages if those messages are buffered outside of the SCTP association. Techniques such as those described in [RFC6083] could be used to overcome these vulnerabilities.
请注意，使用DTLS存在TLS中不存在的中间人漏洞，允许在发送方或接收方不知情的情况下从流中删除消息。此外，当通过SCTP使用DTL时，攻击者可能会注入SCTP控制信息并关闭SCTP关联，如果这些消息在SCTP关联之外缓冲，则会导致IPFIX消息丢失。[RFC6083]中描述的技术可用于克服这些漏洞。
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消息传递到应用层之前会使用自己的控制消息。
When using DTLS over SCTP or UDP, the Heartbeat Extension [RFC6520] SHOULD be used, especially on long-lived Transport Sessions, to ensure that the association remains active.
当通过SCTP或UDP使用DTL时，应使用心跳扩展[RFC6520]，特别是在长时间传输会话上，以确保关联保持活动状态。
Exporting and Collecting Processes MUST NOT request, offer, or use any version of the Secure Socket Layer (SSL), or any version of TLS prior to 1.1, due to known security vulnerabilities in prior versions of TLS; see Appendix E of [RFC5246] for more information.
导出和收集过程不得请求、提供或使用任何版本的安全套接字层（SSL）或1.1之前的任何版本的TLS，因为先前版本的TLS中存在已知的安全漏洞；更多信息请参见[RFC5246]的附录E。
The IPFIX Exporting Process initiates the communication to the IPFIX Collecting Process and acts as a TLS or DTLS client according to [RFC5246] and [RFC6347], while the IPFIX Collecting Process acts as a TLS or DTLS server. The DTLS client opens a secure connection on SCTP port 4740 of the DTLS server if SCTP is selected as the transport protocol. The TLS client opens a secure connection on TCP port 4740 of the TLS server if TCP is selected as the transport protocol. The DTLS client opens a secure connection on UDP port 4740 of the DTLS server if UDP is selected as the transport protocol.
IPFIX导出进程启动与IPFIX收集进程的通信，并根据[RFC5246]和[RFC6347]充当TLS或DTLS客户端，而IPFIX收集进程充当TLS或DTLS服务器。如果选择SCTP作为传输协议，DTLS客户端将在DTLS服务器的SCTP端口4740上打开安全连接。如果选择TCP作为传输协议，TLS客户端将在TLS服务器的TCP端口4740上打开安全连接。如果选择UDP作为传输协议，DTLS客户端将在DTLS服务器的UDP端口4740上打开安全连接。
When using TLS or DTLS, IPFIX Exporting Processes and IPFIX Collecting Processes SHOULD be identified by a certificate containing the DNS-ID as discussed in Section 6.4 of [RFC6125]; the inclusion of Common Names (CN-IDs) in certificates identifying IPFIX Exporting Processes or Collecting Processes is NOT RECOMMENDED.
当使用TLS或DTL时，IPFIX导出过程和IPFIX收集过程应通过包含DNS-ID的证书进行标识，如[RFC6125]第6.4节所述；不建议在标识IPFIX导出进程或收集进程的证书中包含通用名称（CN ID）。
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, mutual authentication MUST be used for both TLS and DTLS. Exporting Processes MUST verify the reference identifiers of the Collecting Processes to which they are exporting IPFIX Messages against those stored in the certificates. Likewise, Collecting Processes MUST verify the reference identifiers of the Exporting Processes from which they are receiving IPFIX Messages against those stored in the certificates. Exporting Processes MUST NOT export to non-verified Collecting Processes, and Collecting Processes MUST NOT accept IPFIX Messages from non-verified Exporting Processes.
为了防止冒名顶替者导出或收集过程中的中间人攻击、从未经授权的导出过程中接受数据或将数据导出到未经授权的收集过程中，TLS和DTL都必须使用相互身份验证。导出进程必须根据证书中存储的引用标识符验证其将IPFIX消息导出到的收集进程的引用标识符。同样，收集进程必须根据证书中存储的引用标识符验证从中接收IPFIX消息的导出进程的引用标识符。导出进程不得导出到未经验证的收集进程，收集进程不得接受来自未经验证的导出进程的IPFIX消息。
Exporting Processes and Collecting Processes MUST support the verification of certificates against an explicitly authorized list of peer certificates identified by Common Name and SHOULD support the verification of reference identifiers by matching the DNS-ID or CN-ID with a DNS lookup of the peer.
导出进程和收集进程必须支持根据由公共名称标识的明确授权的对等证书列表验证证书，并应通过将DNS-ID或CN-ID与对等方的DNS查找相匹配来支持参考标识符的验证。
IPFIX Exporting Processes and Collecting Processes MUST use non-NULL ciphersuites for authentication, integrity, and confidentiality.
IPFIX导出进程和收集进程必须使用非空密码套件进行身份验证、完整性和机密性。
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 DoS 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, or a large amount of Options Template Records, etc.).
直接DoS攻击还可能涉及状态耗尽，无论是在传输层（例如，通过创建大量挂起的连接）还是在IPFIX收集进程本身（例如，通过发送流记录挂起的模板或范围信息，或大量选项模板记录等）。
SCTP mandates a cookie-exchange mechanism designed to defend against SCTP state exhaustion DoS 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状态耗尽DoS攻击。类似地，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 and 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 and DTLS (like limiting the number of new TLS or DTLS sessions 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; limiting the rate at which IPFIX Messages will be accepted by the Collecting Process; and adaptively limiting the amount of state kept, particularly for records waiting for Templates. These rate and state limits MAY be provided by a Collecting Process, and 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. 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
关于间接拒绝服务，IPFIX在过载条件下的行为取决于使用的传输协议。对于TCP上的IPFIX，TCP拥塞控制将导致IPFIX消息流后退并最终停止，从而使IPFIX系统失明。SCTP在某种程度上改善了这种情况，因为由于SCTP的多个流避免了线头阻塞，一些IPFIX消息将继续被收集进程接收
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 and implying that some information about the attack will be available.
和部分可靠性特征，可能提供攻击的一些可见性。这种情况与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 [RFC4960] and [RFC6528]); 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实现能够抵抗盲插入攻击（参见[RFC4960]和[RFC6528]）；但是，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, a complete set of security guidelines for Collector implementation is outside the scope of this document.
收集器的安全性及其实现对于实现总体安全性非常重要；但是，收集器实现的一整套安全指南不在本文档的范围之内。
As IPFIX uses length-prefix encodings, Collector implementors should take care to ensure the detection of inconsistent values that could impact IPFIX Message decoding, and proper operation in the presence of such inconsistent values.
由于IPFIX使用长度前缀编码，收集器实现人员应注意确保检测到可能影响IPFIX消息解码的不一致值，并确保在存在此类不一致值时正确操作。
Specifically, IPFIX Message, Set, and variable-length Information Element lengths must be checked for consistency to avoid buffer-sizing vulnerabilities.
具体而言，必须检查IPFIX消息、集合和可变长度信息元素长度的一致性，以避免缓冲区大小调整漏洞。
Collector implementors should also pay special attention to UTF-8 encoding of string data types, as vulnerabilities may exist in the interpretation of ill-formed UTF-8 values; see Section 6.1.6.
收集器实现者还应特别注意字符串数据类型的UTF-8编码，因为在解释格式错误的UTF-8值时可能存在漏洞；见第6.1.6节。
Flow data exported by Exporting Processes and collected by Collecting Processes typically contains information about traffic on the observed network. This information may be personally identifiable and privacy-sensitive. The storage of this data must be protected via technical as well as policy means to ensure that the privacy of the users of the measured network is protected. A complete specification of such means is out of scope for this document and is specific to the application and storage technology used.
通过导出进程导出的流数据和通过收集进程收集的流数据通常包含有关观察到的网络上的流量的信息。这些信息可能是个人可识别的，并且对隐私敏感。必须通过技术和政策手段保护该数据的存储，以确保测量网络用户的隐私受到保护。此类方法的完整规范不在本文件的范围内，具体适用于所使用的应用和存储技术。
[RFC6615] specifies a MIB module that defines managed objects for monitoring IPFIX Devices, including basic configuration. This MIB can be used to measure the impact of IPFIX export on the monitoring network; it contains tables covering:
[RFC6615]指定MIB模块，该模块定义用于监视IPFIX设备的托管对象，包括基本配置。此MIB可用于测量IPFIX导出对监控网络的影响；它包含的表格包括：
Transport Session, Cache definition, Observation Point definition, Template and Options Template definition, export features (failover, load-balancing, duplicate), and export statistics per Process, Session, and Template
传输会话、缓存定义、观察点定义、模板和选项模板定义、导出功能（故障切换、负载平衡、重复）以及每个进程、会话和模板的导出统计信息
From an operational aspect, an important function of this MIB module is provided by the Transport Session Statistical table, which contains the rate (in bytes per second) at which the Collector receives or the Exporter sends out IPFIX Messages. Of particular interest to operations, the Transport Session Statistical table in Section 5.8.1 of this MIB module exposes the rate of collection or export of IPFIX Messages, which allows the measurement of the bandwidth used by IPFIX export.
从操作角度来看，传输会话统计表提供了此MIB模块的一个重要功能，其中包含收集器接收或导出器发送IPFIX消息的速率（以字节/秒为单位）。操作人员特别感兴趣的是，本MIB模块第5.8.1节中的传输会话统计表公开了IPFIX消息的收集或导出速率，允许测量IPFIX导出使用的带宽。
[RFC6727] describes extensions to the IPFIX-SELECTOR-MIB module specified in [RFC6615] and contains managed objects for providing information on applied packet selection functions and their parameters (filtering and sampling).
[RFC6727]描述了[RFC6615]中指定的IPFIX-SELECTOR-MIB模块的扩展，并包含用于提供应用的数据包选择函数及其参数（过滤和采样）信息的托管对象。
Since the IPFIX-SELECTOR-MIB [RFC6615] and PSAMP-MIB [RFC6727] modules only contain read-only objects, they cannot be used for configuration of IPFIX Devices. [RFC6728] specifies a configuration data model for the IPFIX and PSAMP protocols, using the Network Configuration Protocol (NETCONF). This data model covers Selection Processes, Caches, Exporting Processes, and Collecting Processes on IPFIX and PSAMP Devices, and is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG. The configuration data is encoded in Extensible Markup Language (XML).
由于IPFIX-SELECTOR-MIB[RFC6615]和PSAMP-MIB[RFC6727]模块仅包含只读对象，因此它们不能用于配置IPFIX设备。[RFC6728]使用网络配置协议（NETCONF）指定IPFIX和PSAMP协议的配置数据模型。该数据模型涵盖IPFIX和PSAMP设备上的选择过程、缓存、导出过程和收集过程，使用UML（统一建模语言）类图定义，并使用YANG正式指定。配置数据以可扩展标记语言（XML）编码。
A few mechanisms specified alongside the IPFIX protocol can help monitor and reduce bandwidth used for IPFIX Export:
IPFIX协议旁边指定的一些机制可以帮助监视和减少用于IPFIX导出的带宽：
- a bandwidth-saving method for exporting redundant information in IPFIX [RFC5473]
- IPFIX[RFC5473]中导出冗余信息的一种节省带宽的方法
- an efficient method for exporting bidirectional flows [RFC5103]
- 一种有效的双向流导出方法[RFC5103]
- a method for the definition and export of complex data structures [RFC6313]
- 定义和导出复杂数据结构的方法[RFC6313]
Alternatively, PSAMP [RFC5474] can be used to export packets sampled by statistical and other methods, which may be applicable to many monitoring areas for which IPFIX is also suited. PSAMP also provides control over the impact on the measured network through its sampling rate. The set of packet selection techniques (Sampling, Filtering, and hashing) standardized by PSAMP is described in [RFC5475]. PSAMP also defines an explicitly configurable export rate limit in Section 8.4 of [RFC5474].
或者，PSAMP[RFC5474]可用于导出通过统计和其他方法采样的数据包，这可能适用于IPFIX也适用的许多监控区域。PSAMP还通过其采样率控制对测量网络的影响。[RFC5475]中描述了PSAMP标准化的一组数据包选择技术（采样、过滤和散列）。PSAMP还在[RFC5474]第8.4节中定义了明确可配置的出口率限制。
IANA has updated the "IPFIX Information Elements" registry [IANA-IPFIX] so that all references that previously pointed to RFC 5101 now point to this document instead.
IANA已经更新了“IPFIX信息元素”注册表[IANA-IPFIX]，因此以前指向RFC 5101的所有引用现在都指向本文档。
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 Information Elements used by IPFIX, and sub-registries of Information Element values, are managed by IANA [IANA-IPFIX], as are the Private Enterprise Numbers used by enterprise-specific Information Elements [IANA-PEN]. This document makes no changes to these registries.
IPFIX使用的信息元素和信息元素值的子注册表由IANA[IANA-IPFIX]管理，企业特定信息元素[IANA-PEN]使用的私有企业编号也是如此。本文件不对这些注册表进行任何更改。
The IPFIX Version Number value of 0x000a (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 Options 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版本号值0x000a（10）为本文档中指定的IPFIX协议保留。由于历史原因[RFC3954]，未使用设置ID值0和1。集合ID值2是为模板集合保留的。设置ID值3是为选项模板集保留的。从4到255的所有其他设置ID值保留供将来使用。大于255的集合ID值用于数据集。
New assignments in either the "IPFIX Version Number" or "IPFIX Set IDs" sub-registries require a Standards Action [RFC5226], i.e., they are to be made via Standards Track RFCs approved by the IESG.
“IPFIX版本号”或“IPFIX集合ID”子注册表中的新分配需要标准操作[RFC5226]，即，它们将通过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 another Data Set (which contains two Data Records related to the previous Options Template Record).
让我们考虑由模板集、数据集（包含三个数据记录）、选项模板集和另一个数据集（包含与先前选项模板记录相关的两个数据记录）组成的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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
我们要报告以下信息要素：
- IPv4 source IP address: sourceIPv4Address [IANA-IPFIX], with a length of 4 octets
- IPv4源IP地址：sourceIPv4Address[IANA-IPFIX]，长度为4个八位字节
- IPv4 destination IP address: destinationIPv4Address [IANA-IPFIX], with a length of 4 octets
- IPv4目标IP地址：destinationIPv4Address[IANA-IPFIX]，长度为4个八位字节
- Next-hop IP address (IPv4): ipNextHopIPv4Address [IANA-IPFIX], with a length of 4 octets
- 下一跳IP地址（IPv4）：ipNextHopIPv4Address[IANA-IPFIX]，长度为4个八位字节
- Number of packets of the Flow: packetDeltaCount [IANA-IPFIX], with a length of 4 octets
- 流的数据包数：packetDeltaCount[IANA-IPFIX]，长度为4个八位字节
- Number of octets of the Flow: octetDeltaCount [IANA-IPFIX], with a length of 4 octets
- 流的八位字节数：八位DeltaCount[IANA-IPFIX]，长度为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| packetDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 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| packetDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We want to report the following Information Elements:
我们要报告以下信息要素：
- IPv4 source IP address: sourceIPv4Address [IANA-IPFIX], with a length of 4 octets
- IPv4源IP地址：sourceIPv4Address[IANA-IPFIX]，长度为4个八位字节
- IPv4 destination IP address: destinationIPv4Address [IANA-IPFIX], with a length of 4 octets
- IPv4目标IP地址：destinationIPv4Address[IANA-IPFIX]，长度为4个八位字节
- An enterprise-specific Information Element representing proprietary information, with a type of 15 and a length of 4 octets
- 表示专有信息的企业特定信息元素，类型为15，长度为4个八位字节
- Number of packets of the Flow: packetDeltaCount [IANA-IPFIX], with a length of 4 octets
- 流的数据包数：packetDeltaCount[IANA-IPFIX]，长度为4个八位字节
- Number of octets of the Flow: octetDeltaCount [IANA-IPFIX], with a length of 4 octets
- 流的八位字节数：八位DeltaCount[IANA-IPFIX]，长度为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| packetDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 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| packetDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 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: exportedMessageTotalCount [IANA-IPFIX], with a length of 2 octets
- IPFIX消息总数：exportedMessageTotalCount[IANA-IPFIX]，长度为2个八位字节
- Total number of exported Flows: exportedFlowRecordTotalCount [IANA-IPFIX], with a length of 2 octets
- 导出流的总数：exportedFlowRecordTotalCount[IANA-IPFIX]，长度为2个八位字节
The line card, which is represented by the lineCardId Information Element [IANA-IPFIX], is used as the Scope Field.
LineCard信息元素[IANA-IPFIX]表示的线路卡用作范围字段。
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|exportedMessageTotalCount=41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0|exportedFlowRecordTotalCo.=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|exportedMessageTotalCount=41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0|exportedFlowRecordTotalCo.=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: exportedMessageTotalCount [IANA-IPFIX], with a length of 2 octets
- IPFIX消息总数：exportedMessageTotalCount[IANA-IPFIX]，长度为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 [IANA-IPFIX], is used as the Scope Field.
LineCard信息元素[IANA-IPFIX]表示的线路卡用作范围字段。
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|exportedMessageTotalCount=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|exportedMessageTotalCount=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 Appendix A.4.1:
在此示例中，我们希望导出与附录A.4.1中示例相同的信息：
- Total number of IPFIX Messages: exportedMessageTotalCount [IANA-IPFIX], with a length of 2 octets
- IPFIX消息总数：exportedMessageTotalCount[IANA-IPFIX]，长度为2个八位字节
- Total number of exported Flows: exportedFlowRecordTotalCount [IANA-IPFIX], with a length of 2 octets
- 导出流的总数：exportedFlowRecordTotalCount[IANA-IPFIX]，长度为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|exportedMessageTotalCount=41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0|exportedFlowRecordTotalCo.=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|exportedMessageTotalCount=41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0|exportedFlowRecordTotalCo.=42|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, we report the following two Data Records:
在本例中，我们报告以下两个数据记录：
Enterprise field 123 | IPFIX Message | Exported Flow Records
---------------------------------------------------------------
1 | 345 | 10201
2 | 690 | 20402
Enterprise field 123 | IPFIX Message | Exported Flow Records
---------------------------------------------------------------
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Less Than 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 3-Octet Length Encoding
A.5.2. 具有3-Octet长度编码的可变长度信息元素示例
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Normative References
规范性引用文件
[IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <http://www.iana.org/assignments/ipfix/>.
[IANA-IPFIX]IANA，“IP流信息导出（IPFIX）实体”<http://www.iana.org/assignments/ipfix/>.
[RFC1014] Sun Microsystems, Inc., "XDR: External Data Representation Standard", RFC 1014, June 1987.
[RFC1014]太阳微系统公司，“XDR：外部数据表示标准”，RFC10141987年6月。
[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月。
[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月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[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月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012.
[RFC6520]Seggelmann，R.，Tuexen，M.和M.Williams，“传输层安全性（TLS）和数据报传输层安全性（DTLS）心跳扩展”，RFC 6520，2012年2月。
[RFC7012] Claise, B., Ed., and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013.
[RFC7012]Claise，B.，Ed.，和B.Trammell，Ed.，“IP流信息导出（IPFIX）的信息模型”，RFC 7012，2013年9月。
[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
资料性引用
[IEEE.754.2008] Institute of Electrical and Electronics Engineers, "IEEE Standard for Floating-Point Arithmetic", IEEE Standard 754, August 2008.
[IEEE.754.2008]电气和电子工程师协会，“IEEE浮点运算标准”，IEEE标准754，2008年8月。
[IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, "Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators", Work in Progress, July 2013.
[IPFIX-MED-PROTO]Claise，B.，Kobayashi，A.，和B.Trammell，“IPFIX中介上IP流信息导出（IPFIX）协议的操作”，正在进行的工作，2013年7月。
[IANA-PEN] IANA, "Private Enterprise Numbers", <http://www.iana.org/assignments/enterprise-numbers/>.
[IANA-PEN]IANA，“私营企业编号”<http://www.iana.org/assignments/enterprise-numbers/>.
[POSIX.1] IEEE 1003.1-2008, "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX(R))", 2008.
[POSIX.1]IEEE 1003.1-2008，“IEEE信息技术标准-便携式操作系统接口（POSIX（R））”，2008年。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[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月。
[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月。
[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月。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101]Claise，B.，Ed.，“交换IP流量信息的IP流量信息导出（IPFIX）协议规范”，RFC 5101，2008年1月。
[RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008.
[RFC5103]Trammell，B.和E.Boschi，“使用IP流量信息导出（IPFIX）的双向流量导出”，RFC 5103，2008年1月。
[RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. Aitken, "IP Flow Information Export (IPFIX) Implementation Guidelines", RFC 5153, April 2008.
[RFC5153]Boschi，E.，Mark，L.，Quitek，J.，Stieemering，M.，和P.Aitken，“IP流信息导出（IPFIX）实施指南”，RFC 5153，2008年4月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470]Sadasivan，G.，Brownlee，N.，Claise，B.，和J.Quitek，“IP流信息导出架构”，RFC 54702009年3月。
[RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP Flow Information Export (IPFIX) Testing", RFC 5471, March 2009.
[RFC5471]Schmoll，C.，Aitken，P.，和B.Claise，“IP流信息导出（IPFIX）测试指南”，RFC 54712009年3月。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472]Zseby，T.，Boschi，E.，Brownlee，N.，和B.Claise，“IP流信息导出（IPFIX）适用性”，RFC 54722009年3月。
[RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009.
[RFC5473]Boschi，E.，Mark，L.，和B.Claise，“减少IP流信息导出（IPFIX）和数据包采样（PSAMP）报告中的冗余”，RFC 5473，2009年3月。
[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009.
[RFC5474]Duffield，N.，Ed.，Chiou，D.，Claise，B.，Greenberg，A.，Grossglauser，M.，和J.Rexford，“数据包选择和报告框架”，RFC 54742009年3月。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5475]Zseby，T.，Molina，M.，Duffield，N.，Niccolini，S.，和F.Raspall，“IP数据包选择的采样和过滤技术”，RFC 5475，2009年3月。
[RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476]Claise，B.，Ed.，Johnson，A.，和J.Quittek，“数据包采样（PSAMP）协议规范”，RFC 54762009年3月。
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5477]Dietz，T.，Claise，B.，Aitken，P.，Dressler，F.，和G.Carle，“数据包抽样出口的信息模型”，RFC 5477，2009年3月。
[RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, July 2009.
[RFC5610]Boschi，E.，Trammell，B.，Mark，L.，和T.Zseby，“为IP流信息导出（IPFIX）信息元素导出类型信息”，RFC 56102009年7月。
[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, October 2009.
[RFC5655]Trammell，B.，Boschi，E.，Mark，L.，Zseby，T.，和A.Wagner，“IP流信息导出（IPFIX）文件格式规范”，RFC 56552009年10月。
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011.
[RFC6083]Tuexen，M.，Seggelmann，R.，和E.Rescorla，“流控制传输协议（SCTP）的数据报传输层安全性（DTLS）”，RFC 6083，2011年1月。
[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011.
[RFC6183]Kobayashi，A.，Claise，B.，Muenz，G.，和K.Ishibashi，“IP流信息导出（IPFIX）中介：框架”，RFC 6183，2011年4月。
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011.
[RFC6313]Claise，B.，Dhandapani，G.，Aitken，P.，和S.Yates，“IP流信息导出（IPFIX）中结构化数据的导出”，RFC 63132011年7月。
[RFC6526] Claise, B., Aitken, P., Johnson, A., and G. Muenz, "IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream", RFC 6526, March 2012.
[RFC6526]Claise，B.，Aitken，P.，Johnson，A.，和G.Muenz，“每个流控制传输协议（SCTP）流的IP流信息导出（IPFIX）”，RFC 6526，2012年3月。
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012.
[RFC6528]Gont，F.和S.Bellovin，“防御序列号攻击”，RFC 6528，2012年2月。
[RFC6615] Dietz, T., Ed., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 6615, June 2012.
[RFC6615]Dietz，T.，Ed.，Kobayashi，A.，Claise，B.，和G.Muenz，“IP流信息导出的托管对象定义”，RFC 66152012年6月。
[RFC6727] Dietz, T., Ed., Claise, B., and J. Quittek, "Definitions of Managed Objects for Packet Sampling", RFC 6727, October 2012.
[RFC6727]Dietz，T.，Ed.，Claise，B.，和J.Quittek，“用于数据包采样的托管对象的定义”，RFC 6727，2012年10月。
[RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols", RFC 6728, October 2012.
[RFC6728]Muenz，G.，Claise，B.，和P.Aitken，“IP流信息导出（IPFIX）和数据包采样（PSAMP）协议的配置数据模型”，RFC 6728，2012年10月。
[UTF8-EXPLOIT] Davis, M. and M. Suignard, "Unicode Technical Report #36: Unicode Security Considerations", The Unicode Consortium, July 2012.
[UTF8-EXPLOIT]Davis，M.和M.Suignard，“Unicode技术报告#36：Unicode安全注意事项”，Unicode联盟，2012年7月。
Acknowledgments
致谢
We would like to thank Ganesh Sadasivan for his significant contribution during the initial phases of the protocol specification. Additional thanks go to Juergen Quittek for coordination between IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, 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, Andrew Feren, Gerhard Muenz, Sue Hares, and many more, for the technical reviews and feedback. Finally, a special mention to Adrian Farrel for his attention to management and operational aspects.
我们要感谢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、Andrew Feren、Gerhard Muenz、Sue Hares，以及更多的技术评审和反馈。最后，我要特别提到阿德里安·法雷尔对管理和运营方面的关注。
Contributors
贡献者
Stewart Bryant Cisco Systems 10 New Square, Bedfont Lakes Feltham, Middlesex TW18 8HA United Kingdom
斯图尔特·布莱恩特·思科系统10新广场，英国米德尔塞克斯州贝德丰湖费尔瑟姆，TW18 8HA
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
Simon Leinen SWITCH Werdstrasse 2 P.O. Box 8021 Zurich Switzerland
Simon Leinen SWITCH Werdstrasse 2号邮政信箱8021瑞士苏黎世
Phone: +41 44 268 1536
EMail: simon.leinen@switch.ch
Phone: +41 44 268 1536
EMail: simon.leinen@switch.ch
Thomas Dietz NEC Europe Ltd. NEC Laboratories Europe Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg Germany
Thomas Dietz NEC欧洲有限公司NEC实验室欧洲网络研究部Kurfuersten Anlage 36 69115德国海德堡
Phone: +49 6221 4342-128
EMail: Thomas.Dietz@nw.neclab.eu
Phone: +49 6221 4342-128
EMail: Thomas.Dietz@nw.neclab.eu
Authors' Addresses
作者地址
Benoit Claise (editor) Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium
Benoit Claise（编辑）Cisco Systems，Inc.De Kleetlaan 6a b1 1831 Diegem比利时
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Brian Trammell (editor) Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
Brian Trammell（编辑）瑞士联邦理工学院苏黎世Gloriastrasse 35 8092瑞士苏黎世
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Commercial Street, Edinburgh EH6 6LX United Kingdom
Paul Aitken Cisco Systems，Inc.英国爱丁堡商业码头商业街96号EH6 6LX
Phone: +44 131 561 3616
EMail: paitken@cisco.com
Phone: +44 131 561 3616
EMail: paitken@cisco.com