Network Working Group B. Trammell
Request for Comments: 5655 E. Boschi
Category: Standards Track Hitachi Europe
L. Mark
Fraunhofer IFAM
T. Zseby
Fraunhofer FOKUS
A. Wagner
ETH Zurich
October 2009
Network Working Group B. Trammell
Request for Comments: 5655 E. Boschi
Category: Standards Track Hitachi Europe
L. Mark
Fraunhofer IFAM
T. Zseby
Fraunhofer FOKUS
A. Wagner
ETH Zurich
October 2009
Specification of the IP Flow Information Export (IPFIX) File Format
IP流信息导出（IPFIX）文件格式规范
Abstract
摘要
This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools.
本文档描述了基于IP流信息导出（IPFIX）协议的流数据存储文件格式。它对平面文件、二进制流数据文件格式提出了一组要求，然后根据IPFIX消息指定IPFIX文件格式以满足这些要求。此IPFIX文件格式旨在促进各种流存储、处理和分析工具之间的互操作性和可重用性。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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 BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. IPFIX Documents Overview ...................................4
2. Terminology .....................................................5
3. Design Overview .................................................6
4. Motivation ......................................................7
5. Requirements ...................................................10
5.1. Record Format Flexibility .................................10
5.2. Self-Description ..........................................10
5.3. Data Compression ..........................................11
5.4. Indexing and Searching ....................................11
5.5. Error Recovery ............................................12
5.6. Authentication, Confidentiality, and Integrity ............12
5.7. Anonymization and Obfuscation .............................13
5.8. Session Auditability and Replayability ....................13
5.9. Performance Characteristics ...............................14
6. Applicability ..................................................14
6.1. Storage of IPFIX-Collected Flow Data ......................14
6.2. Storage of NetFlow-V9-Collected Flow Data .................15
6.3. Testing IPFIX Collecting Processes ........................15
6.4. IPFIX Device Diagnostics ..................................16
7. Detailed File Format Specification .............................16
7.1. File Reader Specification .................................16
7.2. File Writer Specification .................................17
7.3. Specific File Writer Use Cases ............................18
7.3.1. Collocating a File Writer with a Collecting
Process ............................................18
7.3.2. Collocating a File Writer with a Metering Process ..19
7.3.3. Using IPFIX Files for Archival Storage .............20
7.3.4. Using IPFIX Files as Documents .....................20
7.3.5. Using IPFIX Files for Testing ......................21
7.3.6. Writing IPFIX Files for Device Diagnostics .........22
7.3.7. IPFIX File Manipulation ............................22
7.4. Media Type of IPFIX Files .................................22
8. File Format Metadata Specification .............................22
8.1. Recommended Options Templates for IPFIX Files .............22
8.1.1. Message Checksum Options Template ..................23
8.1.2. File Time Window Options Template ..................23
8.1.3. Export Session Details Options Template ............24
8.1.4. Message Details Options Template ...................26
8.2. Recommended Information Elements for IPFIX Files ..........29
8.2.1. collectionTimeMilliseconds .........................29
8.2.2. collectorCertificate ...............................29
8.2.3. exporterCertificate ................................29
8.2.4. exportSctpStreamId .................................30
8.2.5. maxExportSeconds ...................................30
8.2.6. maxFlowEndMicroseconds .............................30
1. Introduction ....................................................4
1.1. IPFIX Documents Overview ...................................4
2. Terminology .....................................................5
3. Design Overview .................................................6
4. Motivation ......................................................7
5. Requirements ...................................................10
5.1. Record Format Flexibility .................................10
5.2. Self-Description ..........................................10
5.3. Data Compression ..........................................11
5.4. Indexing and Searching ....................................11
5.5. Error Recovery ............................................12
5.6. Authentication, Confidentiality, and Integrity ............12
5.7. Anonymization and Obfuscation .............................13
5.8. Session Auditability and Replayability ....................13
5.9. Performance Characteristics ...............................14
6. Applicability ..................................................14
6.1. Storage of IPFIX-Collected Flow Data ......................14
6.2. Storage of NetFlow-V9-Collected Flow Data .................15
6.3. Testing IPFIX Collecting Processes ........................15
6.4. IPFIX Device Diagnostics ..................................16
7. Detailed File Format Specification .............................16
7.1. File Reader Specification .................................16
7.2. File Writer Specification .................................17
7.3. Specific File Writer Use Cases ............................18
7.3.1. Collocating a File Writer with a Collecting
Process ............................................18
7.3.2. Collocating a File Writer with a Metering Process ..19
7.3.3. Using IPFIX Files for Archival Storage .............20
7.3.4. Using IPFIX Files as Documents .....................20
7.3.5. Using IPFIX Files for Testing ......................21
7.3.6. Writing IPFIX Files for Device Diagnostics .........22
7.3.7. IPFIX File Manipulation ............................22
7.4. Media Type of IPFIX Files .................................22
8. File Format Metadata Specification .............................22
8.1. Recommended Options Templates for IPFIX Files .............22
8.1.1. Message Checksum Options Template ..................23
8.1.2. File Time Window Options Template ..................23
8.1.3. Export Session Details Options Template ............24
8.1.4. Message Details Options Template ...................26
8.2. Recommended Information Elements for IPFIX Files ..........29
8.2.1. collectionTimeMilliseconds .........................29
8.2.2. collectorCertificate ...............................29
8.2.3. exporterCertificate ................................29
8.2.4. exportSctpStreamId .................................30
8.2.5. maxExportSeconds ...................................30
8.2.6. maxFlowEndMicroseconds .............................30
8.2.7. maxFlowEndMilliseconds .............................31
8.2.8. maxFlowEndNanoseconds ..............................31
8.2.9. maxFlowEndSeconds ..................................32
8.2.10. messageMD5Checksum ................................32
8.2.11. messageScope ......................................32
8.2.12. minExportSeconds ..................................33
8.2.13. minFlowStartMicroseconds ..........................33
8.2.14. minFlowStartMilliseconds ..........................34
8.2.15. minFlowStartNanoseconds ...........................34
8.2.16. minFlowStartSeconds ...............................34
8.2.17. opaqueOctets ......................................35
8.2.18. sessionScope ......................................35
9. Signing and Encryption of IPFIX Files ..........................36
9.1. CMS Detached Signatures ...................................36
9.1.1. ContentInfo ........................................37
9.1.2. SignedData .........................................38
9.1.3. SignerInfo .........................................38
9.1.4. EncapsulatedContentInfo ............................39
9.2. Encryption Error Resilience ...............................39
10. Compression of IPFIX Files ....................................39
10.1. Supported Compression Formats ............................40
10.2. Compression Recognition at the File Reader ...............40
10.3. Compression Error Resilience .............................40
11. Recommended File Integration Strategies .......................41
11.1. Encapsulation of Non-IPFIX Data in IPFIX Files ...........41
11.2. Encapsulation of IPFIX Files within Other File Formats ...42
12. Security Considerations .......................................42
12.1. Relationship between IPFIX File and Transport
Encryption ...............................................43
12.2. End-to-End Assertions for IPFIX Files ....................43
12.3. Recommendations for Strength of Cryptography for
IPFIX Files ..............................................44
13. IANA Considerations ...........................................44
14. Acknowledgements ..............................................46
15. References ....................................................47
15.1. Normative References .....................................47
15.2. Informative References ...................................48
Appendix A. Example IPFIX File ...................................49
A.1. Example Options Templates .................................50
A.2. Example Supplemental Options Data .........................52
A.3. Example Message Checksum ..................................54
A.4. File Example Data Set .....................................55
A.5. Complete File Example .....................................55
Appendix B. Applicability of IPFIX Files to NetFlow V9 Flow
Storage ..............................................57
B.1. Comparing NetFlow V9 to IPFIX .............................57
B.1.1. Message Header Format .................................57
B.1.2. Set Header Format .....................................58
8.2.7. maxFlowEndMilliseconds .............................31
8.2.8. maxFlowEndNanoseconds ..............................31
8.2.9. maxFlowEndSeconds ..................................32
8.2.10. messageMD5Checksum ................................32
8.2.11. messageScope ......................................32
8.2.12. minExportSeconds ..................................33
8.2.13. minFlowStartMicroseconds ..........................33
8.2.14. minFlowStartMilliseconds ..........................34
8.2.15. minFlowStartNanoseconds ...........................34
8.2.16. minFlowStartSeconds ...............................34
8.2.17. opaqueOctets ......................................35
8.2.18. sessionScope ......................................35
9. Signing and Encryption of IPFIX Files ..........................36
9.1. CMS Detached Signatures ...................................36
9.1.1. ContentInfo ........................................37
9.1.2. SignedData .........................................38
9.1.3. SignerInfo .........................................38
9.1.4. EncapsulatedContentInfo ............................39
9.2. Encryption Error Resilience ...............................39
10. Compression of IPFIX Files ....................................39
10.1. Supported Compression Formats ............................40
10.2. Compression Recognition at the File Reader ...............40
10.3. Compression Error Resilience .............................40
11. Recommended File Integration Strategies .......................41
11.1. Encapsulation of Non-IPFIX Data in IPFIX Files ...........41
11.2. Encapsulation of IPFIX Files within Other File Formats ...42
12. Security Considerations .......................................42
12.1. Relationship between IPFIX File and Transport
Encryption ...............................................43
12.2. End-to-End Assertions for IPFIX Files ....................43
12.3. Recommendations for Strength of Cryptography for
IPFIX Files ..............................................44
13. IANA Considerations ...........................................44
14. Acknowledgements ..............................................46
15. References ....................................................47
15.1. Normative References .....................................47
15.2. Informative References ...................................48
Appendix A. Example IPFIX File ...................................49
A.1. Example Options Templates .................................50
A.2. Example Supplemental Options Data .........................52
A.3. Example Message Checksum ..................................54
A.4. File Example Data Set .....................................55
A.5. Complete File Example .....................................55
Appendix B. Applicability of IPFIX Files to NetFlow V9 Flow
Storage ..............................................57
B.1. Comparing NetFlow V9 to IPFIX .............................57
B.1.1. Message Header Format .................................57
B.1.2. Set Header Format .....................................58
B.1.3. Template Format .......................................59
B.1.4. Information Model .....................................59
B.1.5. Template Management ...................................59
B.1.6. Transport .............................................59
B.2. A Method for Transforming NetFlow V9 Messages to IPFIX ....60
B.3. NetFlow V9 Transformation Example .........................61
B.1.3. Template Format .......................................59
B.1.4. Information Model .....................................59
B.1.5. Template Management ...................................59
B.1.6. Transport .............................................59
B.2. A Method for Transforming NetFlow V9 Messages to IPFIX ....60
B.3. NetFlow V9 Transformation Example .........................61
This document specifies a file format based upon IPFIX, designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. It begins with an overview of the IPFIX File format, and a quick summary of how IPFIX Files work in Section 3. The detailed specification of the IPFIX File format appears in Section 7; this section includes general specifications for IPFIX File Readers and IPFIX File Writers and specific recommendations for common situations in which they are used. The format makes use of the IPFIX Options mechanism for additional file metadata, in order to avoid requiring any protocol extensions, and to minimize the effort required to adapt IPFIX implementations to use the file format; a detailed definition of the Options Templates used for storage metadata appears in Section 8. Appendix A contains a detailed example IPFIX File.
本文档指定了一种基于IPFIX的文件格式，旨在促进各种流存储、处理和分析工具之间的互操作性和可重用性。它首先概述了IPFIX文件格式，并在第3节中简要介绍了IPFIX文件的工作原理。IPFIX文件格式的详细规范见第7节；本节包括IPFIX文件读取器和IPFIX文件写入器的一般规范，以及使用它们的常见情况的具体建议。该格式利用IPFIX选项机制来获取额外的文件元数据，以避免需要任何协议扩展，并尽可能减少使IPFIX实现适应使用该文件格式所需的工作；用于存储元数据的选项模板的详细定义见第8节。附录A包含一个详细的IPFIX文件示例。
An advantage of file-based storage is that files can be readily encapsulated within each other and other data storage and transmission formats. The IPFIX File format leverages this to provide encryption, described in Section 9 and compression, described in Section 10. Section 11 provides specific recommendations for integration of IPFIX File data with other formats.
基于文件的存储的优点是，文件可以很容易地封装在彼此之间以及其他数据存储和传输格式中。IPFIX文件格式利用这一点提供第9节所述的加密和第10节所述的压缩。第11节提供了IPFIX文件数据与其他格式集成的具体建议。
The IPFIX File format was designed to be applicable to a wide variety of flow storage situations; the motivation behind its creation is described in Section 4. The document outlines of the set of requirements the format is designed to meet in Section 5, and explores the applicability of such a format to various specific application areas in Section 6. These sections are intended to give background on the development of IPFIX Files.
IPFIX文件格式的设计适用于各种流存储情况；第4节描述了其创作背后的动机。文件概述了第5节中设计的该格式所要满足的一系列要求，并在第6节中探讨了该格式对各种特定应用领域的适用性。这些部分旨在介绍IPFIX文件的开发背景。
"Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information" [RFC5101] and its associated documents define the IPFIX protocol, which provides network engineers and administrators with access to IP traffic flow information.
“用于交换IP流量信息的IP流量信息导出（IPFIX）协议规范”[RFC5101]及其相关文件定义了IPFIX协议，该协议为网络工程师和管理员提供了访问IP流量信息的权限。
"Architecture for IP Flow Information Export" [RFC5470] defines the architecture for the export of measured IP flow information out of an IPFIX Exporting Process to an IPFIX Collecting Process, and the basic terminology used to describe the elements of this architecture, per the requirements defined in "Requirements for IP Flow Information Export" [RFC3917]. [RFC5101] then covers the details of the method for transporting IPFIX Data Records and Templates via a congestion-aware transport protocol from an IPFIX Exporting Process to an IPFIX
“IP流信息导出体系结构”[RFC5470]根据“IP流信息导出要求”中定义的要求，定义了将测得的IP流信息从IPFIX导出过程导出到IPFIX收集过程的体系结构，以及用于描述此体系结构元素的基本术语[RFC3917]。[RFC5101]然后介绍通过拥塞感知传输协议将IPFIX数据记录和模板从IPFIX导出过程传输到IPFIX的方法的详细信息
Collecting Process.
收集过程。
"Information Model for IP Flow Information Export" [RFC5102] describes the Information Elements used by IPFIX, including details on Information Element naming, numbering, and data type encoding.
“IP流信息导出的信息模型”[RFC5102]描述了IPFIX使用的信息元素，包括有关信息元素命名、编号和数据类型编码的详细信息。
"IP Flow Information Export (IPFIX) Applicability" [RFC5472] describes the various applications of the IPFIX protocol and their use of information exported via IPFIX, and it relates the IPFIX architecture to other measurement architectures and frameworks.
“IP流信息导出（IPFIX）适用性”[RFC5472]描述了IPFIX协议的各种应用及其对通过IPFIX导出的信息的使用，并将IPFIX体系结构与其他度量体系结构和框架联系起来。
In addition, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements" [RFC5610] specifies a method for encoding Information Model properties within an IPFIX Message stream.
此外，“为IP流信息导出（IPFIX）信息元素导出类型信息”[RFC5610]指定了在IPFIX消息流中编码信息模型属性的方法。
This document references [RFC5101] and [RFC5470] for terminology, defines IPFIX File Writer and IPFIX File Reader in terms of the IPFIX Exporting Process and IPFIX Collecting Process definitions from [RFC5101], and extends the IPFIX Information Model defined in [RFC5102] to provide new Information Elements for IPFIX File metadata. It uses the method described in [RFC5610] to support the self-description of IPFIX Files containing enterprise-specific Information Elements.
本文档参考[RFC5101]和[RFC5470]中的术语，根据[RFC5101]中的IPFIX导出过程和IPFIX收集过程定义定义IPFIX文件编写器和IPFIX文件读取器，并扩展[RFC5102]中定义的IPFIX信息模型，为IPFIX文件元数据提供新的信息元素。它使用[RFC5610]中描述的方法来支持包含企业特定信息元素的IPFIX文件的自描述。
This section defines terminology related to the IPFIX File format. In addition, terms used in this document that are defined in the "Terminology" section of [RFC5101] are to be interpreted as defined there.
本节定义了与IPFIX文件格式相关的术语。此外，[RFC5101]的“术语”部分中定义的本文件中使用的术语应按照此处的定义进行解释。
IPFIX File: An IPFIX File is a serialized stream of IPFIX Messages; this stream may be stored on a filesystem or transported using any technique customarily used for files. Any IPFIX Message stream that would be considered valid when transported over one or more of the specified IPFIX transports (Stream Control Transmission Protocol (SCTP), TCP, or UDP) as defined in [RFC5101] is
IPFIX文件：IPFIX文件是IPFIX消息的序列化流；该流可以存储在文件系统中，也可以使用通常用于文件的任何技术进行传输。通过[RFC5101]中定义的一个或多个指定IPFIX传输（流控制传输协议（SCTP）、TCP或UDP）传输时被视为有效的任何IPFIX消息流
considered an IPFIX File. However, this document extends that definition with recommendations on the construction of IPFIX Files that meet the requirements identified in Section 5.
被认为是一个IPFIX文件。但是，本文件扩展了该定义，并建议构建符合第5节中确定的要求的IPFIX文件。
IPFIX File Reader: An IPFIX File Reader is a process that reads IPFIX Files from a filesystem. An IPFIX File Reader operates as an IPFIX Collecting Process as specified in [RFC5101], except as modified by this document.
IPFIX文件读取器：IPFIX文件读取器是从文件系统读取IPFIX文件的进程。IPFIX文件读取器作为[RFC5101]中规定的IPFIX收集过程进行操作，除非本文档进行了修改。
IPFIX File Writer: An IPFIX File Writer is a process that writes IPFIX Files to a filesystem. An IPFIX File Writer operates as an IPFIX Exporting Process as specified in [RFC5101], except as modified by this document.
IPFIX文件编写器：IPFIX文件编写器是将IPFIX文件写入文件系统的进程。IPFIX文件编写器的操作与[RFC5101]中规定的IPFIX导出过程相同，本文档修改的除外。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
An IPFIX File is simply a data stream containing one or more IPFIX Messages serialized to some filesystem. Though any set of valid IPFIX Messages can be serialized into an IPFIX File, the specification includes guidelines designed to ease storage and retrieval of flow data using the IPFIX File format.
IPFIX文件只是一个数据流，其中包含序列化到某个文件系统的一条或多条IPFIX消息。尽管任何一组有效的IPFIX消息都可以序列化为IPFIX文件，但该规范包含了一些指导原则，旨在简化使用IPFIX文件格式存储和检索流数据的过程。
IPFIX Files contain only IPFIX Messages; any file metadata such as checksums or export session details are stored using Options within the IPFIX Message. This design is completely compatible with the IPFIX protocol on the wire. A schematic of a typical IPFIX File is shown below:
IPFIX文件只包含IPFIX消息；任何文件元数据（如校验和或导出会话详细信息）都使用IPFIX消息中的选项存储。此设计与IPFIX有线协议完全兼容。典型IPFIX文件的示意图如下所示：
+=======================================+
| IPFIX File |
| +===================================+ |
| | IPFIX Message | |
| | +-------------------------------+ | |
| | | IPFIX Message Header | | |
| | +-------------------------------+ | |
| | +-------------------------------+ | |
| | | Options Template Set | | |
| | | Options Template Record | | |
| | | . . . | | |
| | +-------------------------------+ | |
| | +-------------------------------+ | |
| | | Template Set | | |
| | | Template Record | | |
| | | . . . | | |
| | +-------------------------------+ | |
| +===================================+ |
| | IPFIX Message | |
| | +-------------------------------+ | |
| | | IPFIX Message Header | | |
| | +-------------------------------+ | |
| | +-------------------------------+ | |
| | | Data Set | | |
| | | Data Record | | |
| | | . . . | | |
| | +-------------------------------+ | |
| | +-------------------------------+ | |
| | | Data Set | | |
| | | Data Record | | |
| | | . . . | | |
| | +-------------------------------+ | |
| | . . . | |
| +===================================+ |
| . . . |
+=======================================+
+=======================================+
| IPFIX File |
| +===================================+ |
| | IPFIX Message | |
| | +-------------------------------+ | |
| | | IPFIX Message Header | | |
| | +-------------------------------+ | |
| | +-------------------------------+ | |
| | | Options Template Set | | |
| | | Options Template Record | | |
| | | . . . | | |
| | +-------------------------------+ | |
| | +-------------------------------+ | |
| | | Template Set | | |
| | | Template Record | | |
| | | . . . | | |
| | +-------------------------------+ | |
| +===================================+ |
| | IPFIX Message | |
| | +-------------------------------+ | |
| | | IPFIX Message Header | | |
| | +-------------------------------+ | |
| | +-------------------------------+ | |
| | | Data Set | | |
| | | Data Record | | |
| | | . . . | | |
| | +-------------------------------+ | |
| | +-------------------------------+ | |
| | | Data Set | | |
| | | Data Record | | |
| | | . . . | | |
| | +-------------------------------+ | |
| | . . . | |
| +===================================+ |
| . . . |
+=======================================+
Figure 1: Typical File Structure
图1：典型的文件结构
There is a wide variety of applications for the file-based storage of IP flow data, across a continuum of time scales. Tools used in the analysis of flow data and creation of analysis products often use files as a convenient unit of work, with an ephemeral lifetime. A set of flows relevant to a security investigation may be stored in a file for the duration of that investigation, and further exchanged among incident handlers via email or within an external incident
基于文件的IP流数据存储在连续的时间尺度上有各种各样的应用。用于分析流数据和创建分析产品的工具通常将文件作为一种方便的工作单元，使用寿命短暂。与安全调查相关的一组流可在调查期间存储在文件中，并在事件处理者之间通过电子邮件或在外部事件中进一步交换
handling workflow application. Sets of flow data relevant to Internet measurement research may be published as files, much as libpcap [pcap] packet trace files are, to provide common datasets for the repeatability of research efforts; these files would have lifetimes measured in months or years. Operational flow measurement systems also have a need for long-term, archival storage of flow data, either as a primary flow data repository, or as a backing tier for online storage in a relational database management system (RDBMS).
处理工作流应用程序。与互联网测量研究相关的流量数据集可以作为文件发布，就像libpcap[pcap]数据包跟踪文件一样，为研究工作的重复性提供通用数据集；这些文件的生命周期以月或年为单位。可操作的流量测量系统还需要流量数据的长期存档存储，可以作为主要流量数据存储库，也可以作为关系数据库管理系统（RDBMS）中在线存储的后备层。
The variety of applications of flow data, and the variety of presently deployed storage approaches, indicates the need for a standard approach to flow storage with applicability across the continuum of time scales over which flow data is stored. A storage format based around flat files would best address the variety of storage requirements. While much work has been done on structured storage via RDBMS, relational database systems are not a good basis for format standardization owing to the fact that their internal data structures are generally private to a single implementation and subject to change for internal reasons. Also, there are a wide variety of operations available on flat files, and external tools and standards can be leveraged to meet file-based flow storage requirements. Further, flow data is often not very semantically complicated, and is managed in very high volume; therefore, an RDBMS-based flow storage system would not benefit much from the advantages of relational database technology.
流数据应用的多样性以及当前部署的存储方法的多样性表明，需要一种标准的流存储方法，该方法适用于流数据存储的连续时间尺度。基于平面文件的存储格式最能满足各种存储需求。虽然已经通过关系数据库管理系统在结构化存储方面做了大量工作，但关系数据库系统并不是格式标准化的良好基础，因为它们的内部数据结构通常是单个实现的私有数据结构，并且会因内部原因而发生更改。此外，平面文件上有各种各样的操作，可以利用外部工具和标准来满足基于文件的流存储要求。此外，流数据在语义上通常不是非常复杂，并且在非常大的容量中进行管理；因此，基于RDBMS的流存储系统不会从关系数据库技术的优势中获得太多好处。
The simplest way to create a new file format is simply to serialize some internal data model to disk, with either textual or binary representation of data elements, and some framing strategy for delimiting fields and records. "Ad hoc" file formats such as this have several important disadvantages. They impose the semantics of the data model from which they are derived on the file format, and as such, they are difficult to extend, describe, and standardize.
创建新文件格式的最简单方法是将一些内部数据模型序列化到磁盘，使用数据元素的文本或二进制表示，以及一些用于分隔字段和记录的框架策略。像这样的“特殊”文件格式有几个重要的缺点。它们将从中派生的数据模型的语义强加于文件格式，因此很难扩展、描述和标准化。
Indeed, one de facto standard for the storage of flow data is one of these ad hoc formats. A common method of storing data collected via Cisco NetFlow is to serialize a stream of raw NetFlow datagrams into files. These NetFlow PDU files consist of a collection of header-prefixed blocks (corresponding to the datagrams as received on the wire) containing fixed-length binary flow records. NetFlow V5, V7, and V8 data may be mixed within a given file, as the header on each datagram defines the NetFlow version of the records following. While this NetFlow PDU file format has all the disadvantages of an ad hoc format, and is not extensible to data models other than that defined by Cisco NetFlow, it is at least reasonably well understood due to its ubiquity.
事实上，流数据存储的一个事实上的标准就是这些特殊格式之一。存储通过Cisco NetFlow收集的数据的常用方法是将原始NetFlow数据报流序列化为文件。这些NetFlow PDU文件由包含固定长度二进制流记录的头前缀块（对应于在线路上接收的数据报）的集合组成。NetFlow V5、V7和V8数据可能在给定文件中混合，因为每个数据报上的头定义了以下记录的NetFlow版本。虽然这种NetFlow PDU文件格式具有特殊格式的所有缺点，并且不可扩展到Cisco NetFlow定义的数据模型以外的其他数据模型，但由于其普遍性，它至少得到了合理的理解。
Over the past decade, XML has emerged as a new "universal" representation format for structured data. It is intended to be human readable; indeed, that is one reason for its rapid adoption. However, XML has limited usefulness for representing network flow data. Network flow data has a simple, repetitive, non-hierarchical structure that does not benefit much from XML. An XML representation of flow data would be an essentially flat list of the attributes and their values for each flow record.
在过去的十年中，XML已经成为结构化数据的一种新的“通用”表示格式。它的目的是让人可读；事实上，这是它迅速获得通过的原因之一。然而，XML在表示网络流数据方面的用处有限。网络流数据具有简单、重复、非层次结构，这对XML没有多大好处。流数据的XML表示基本上是每个流记录的属性及其值的平面列表。
The XML approach to data encoding is very heavyweight when compared to binary flow encoding. XML's use of start- and end-tags, and plaintext encoding of the actual values, leads to significant inefficiency in encoding size. Typical network traffic datasets can contain millions or billions of flows per hour of traffic represented. Any increase in storage size per record can have dramatic impact on flow data storage and transfer sizes. While data compression algorithms can partially remove the redundancy introduced by XML encoding, they introduce additional overhead of their own.
与二进制流编码相比，XML数据编码方法非常重要。XML使用开始和结束标记，以及对实际值进行明文编码，导致编码大小的效率显著降低。典型的网络流量数据集每小时可以包含数百万或数十亿的流量。每个记录的存储大小的任何增加都会对流数据存储和传输大小产生巨大影响。虽然数据压缩算法可以部分消除XML编码带来的冗余，但它们本身也会带来额外的开销。
A further problem is that XML processing tools require a full XML parser. XML parsers are fully general and therefore complex, resource-intensive, and relatively slow, introducing significant processing time overhead for large network-flow datasets. In contrast, parsers for typical binary flow data encodings are simply structured, since they only need to parse a very small header and then have complete knowledge of all following fields for the particular flow. These can then be read in a very efficient linear fashion.
另一个问题是XML处理工具需要一个完整的XML解析器。XML解析器是完全通用的，因此非常复杂、资源密集且相对较慢，这为大型网络流数据集带来了巨大的处理时间开销。相比之下，典型二进制流数据编码的解析器结构简单，因为它们只需要解析一个非常小的头，然后就可以完全了解特定流的以下所有字段。然后可以以非常有效的线性方式读取这些数据。
This leads us to propose the IPFIX Message format as the basis for a new flow data file format. The IPFIX Working Group, in defining the IPFIX protocol, has already defined an information model and data formatting rules for representation of flow data. Especially at shorter time scales, when a file is a unit of data interchange, the filesystem may be viewed as simply another IPFIX Message transport between processes. This format is especially well suited to representing flow data, as it was designed specifically for flow data export; it is easily extensible, unlike ad hoc serialization, and compact, unlike XML. In addition, IPFIX is an IETF Standards-Track protocol for the export and collection of flow data; using a common format for storage and analysis at the collection side allows implementors to use substantially the same information model and data formatting implementation for transport as well as storage.
这导致我们提出IPFIX消息格式作为新的流数据文件格式的基础。IPFIX工作组在定义IPFIX协议时，已经定义了用于表示流数据的信息模型和数据格式规则。特别是在较短的时间范围内，当文件是数据交换的一个单元时，文件系统可以被看作是进程之间的另一个IPFIX消息传输。这种格式特别适合表示流数据，因为它是专门为流数据导出而设计的；它很容易扩展，不像即席序列化，也很紧凑，不像XML。此外，IPFIX是一个IETF标准跟踪协议，用于导出和收集流数据；在收集端使用公共格式进行存储和分析，使实现者能够使用基本相同的信息模型和数据格式实现进行传输和存储。
In this section, we outline a proposed set of requirements [SAINT2007] for any persistent storage format for flow data. First and foremost, a flow data file format should support storage across the continuum of time scales important to flow storage applications. Each of the requirements enumerated in the sections below is broadly applicable to flow storage applications, though each may be more important at certain time scales. For each, we first identify the requirement, then explain how the IPFIX Message format addresses it, or briefly outline the changes that must be made in order for an IPFIX-based file format to meet the requirement.
在本节中，我们概述了针对流数据的任何持久存储格式提出的一组要求[SAINT2007]。首先也是最重要的一点是，流数据文件格式应支持跨时间尺度的连续存储，这对流存储应用程序非常重要。以下各节中列举的每项要求都广泛适用于流存储应用，尽管在某些时间尺度下，每项要求可能更为重要。对于每一种，我们首先确定需求，然后解释IPFIX消息格式如何满足需求，或者简要概述为使基于IPFIX的文件格式满足需求而必须进行的更改。
Due to the wide variety of flow attributes collected by different network flow attribute measurement systems, the ideal flow storage format will not impose a single data model or a specific record type on the flows it stores. The file format must be flexible and extensible; that is, it must support the definition of multiple record types within the file itself, and must be able to support new field types for data within the records in a graceful way.
由于不同网络流量属性测量系统收集的流量属性种类繁多，理想的流量存储格式不会对其存储的流量施加单一数据模型或特定记录类型。文件格式必须灵活、可扩展；也就是说，它必须支持文件本身中多个记录类型的定义，并且必须能够以优雅的方式支持记录中数据的新字段类型。
IPFIX provides record format flexibility through the use of Templates to describe each Data Record, through the use of an IANA Registry to define its Information Elements, and through the use of enterprise-specific Information Elements.
IPFIX通过使用模板来描述每个数据记录，通过使用IANA注册表来定义其信息元素，以及通过使用特定于企业的信息元素，提供了记录格式的灵活性。
Archived data may be read at a time in the future when any external reference to the meaning of the data may be lost. The ideal flow storage format should be self-describing; that is, a process reading flow data from storage should be able to properly interpret the stored flows without reference to anything other than standard sources (e.g., the standards document describing the file format) and the stored flow data itself.
存档数据可能会在将来某个时候读取，此时对数据含义的任何外部引用可能会丢失。理想的流存储格式应该是自描述的；也就是说，从存储器读取流数据的过程应该能够正确地解释存储的流，而无需参考标准源（例如，描述文件格式的标准文档）和存储的流数据本身以外的任何内容。
The IPFIX Message format is partially self-describing; that is, IPFIX Templates containing only IANA-assigned Information Elements can be completely interpreted according to the IPFIX Information Model without additional external data.
IPFIX消息格式是部分自描述的；也就是说，只包含IANA分配的信息元素的IPFIX模板可以根据IPFIX信息模型完全解释，而无需额外的外部数据。
However, Templates containing private information elements lack detailed type and semantic information; a Collecting Process receiving Data Records described by a Template containing enterprise-specific Information Elements it does not understand can only treat the data contained within those Information Elements as octet arrays.
然而，包含私有信息元素的模板缺乏详细的类型和语义信息；接收由包含企业特定信息元素的模板描述的数据记录的收集过程不能理解，只能将这些信息元素中包含的数据视为八位字节数组。
To be fully self-describing, enterprise-specific Information Elements must be additionally described via IPFIX Options according to the Information Element Type Options Template defined in [RFC5610].
为了完全自描述，必须根据[RFC5610]中定义的信息元素类型选项模板，通过IPFIX选项对特定于企业的信息元素进行额外描述。
Regardless of the representation format, flow data describing traffic on real networks tends to be highly compressible. Compression tends to improve the scalability of flow collection systems, by reducing the disk storage and I/O bandwidth requirement for a given workload. The ideal flow storage format should support applications that wish to leverage this fact by supporting compression of stored data.
不管表示格式如何，描述真实网络上流量的流量数据往往是高度可压缩的。压缩通过减少给定工作负载的磁盘存储和I/O带宽需求，倾向于提高流收集系统的可伸缩性。理想的流存储格式应该支持希望通过支持存储数据压缩来利用这一事实的应用程序。
The IPFIX Message format has no support for data compression, as the IPFIX protocol was designed for speed and simplicity of export. Of course, any flat file is readily compressible using a wide variety of external data compression tools, formats, and algorithms; therefore, this requirement can be met via encapsulation in one of these formats. Section 10 specifies an encapsulation based on bzip2 or gzip, to maximize interoperability.
IPFIX消息格式不支持数据压缩，因为IPFIX协议旨在提高导出速度和简化导出。当然，任何平面文件都可以使用各种外部数据压缩工具、格式和算法进行压缩；因此，可以通过封装这些格式中的一种来满足这一要求。第10节指定了基于bzip2或gzip的封装，以最大限度地提高互操作性。
A few simple optimizations can be made by File Writers to increase the integrity and usability of compressed IPFIX data; these are outlined in Section 10.3.
文件编写器可以进行一些简单的优化，以提高压缩的IPFIX数据的完整性和可用性；这些在第10.3节中概述。
Binary, record-stream-oriented file formats natively support only one form of searching: sequential scan in file order. By choosing the order of records in a file carefully (e.g., by flow end time), a file can be indexed by a single key.
二进制、面向记录流的文件格式本机仅支持一种搜索形式：按文件顺序进行顺序扫描。通过仔细选择文件中记录的顺序（例如，按流结束时间），可以通过单个键对文件进行索引。
Beyond this, properly addressing indexing is an application-specific problem, as it inherently involves trade-offs between storage complexity and retrieval speed, and requirements vary widely based on time scales and the types of queries used from site to site. However, a generic standard flow storage format may provide limited direct support for indexing and searching.
除此之外，正确寻址索引是一个特定于应用程序的问题，因为它本质上涉及到存储复杂性和检索速度之间的权衡，并且要求因时间尺度和站点之间使用的查询类型而异。但是，通用标准流存储格式可能会为索引和搜索提供有限的直接支持。
The ideal flow storage format will support a limited table of contents facility noting that the records in a file contain data relating only to certain keys or values of keys, in order to keep multi-file search implementations from having to scan a file for data it does not contain.
理想的流存储格式将支持有限的目录功能，注意文件中的记录只包含与某些键或键的值相关的数据，以便使多文件搜索实现不必扫描文件中不包含的数据。
The IPFIX Message format has no direct support for indexing. However, the technique described in "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports"
IPFIX消息格式不直接支持索引。然而，“减少IP流信息导出（IPFIX）和数据包采样（PSAMP）报告中的冗余”中描述的技术
[RFC5473] can be used to describe the contents of a file in a limited way. Additionally, as flow data is often sorted and divided by time, the start and end time of the flows in a file may be declared using the File Time Window Options Template defined in Section 8.1.2.
[RFC5473]可用于以有限的方式描述文件的内容。此外，由于流量数据通常按时间进行排序和划分，因此可以使用第8.1.2节中定义的文件时间窗口选项模板来声明文件中流量的开始和结束时间。
When storing flow data for archival purposes, it is important to ensure that hardware or software faults do not introduce errors into the data over time. The ideal flow storage format will support the detection and correction of encoding-level errors in the data.
为存档目的存储流数据时，务必确保硬件或软件故障不会随时间推移导致数据出错。理想的流存储格式将支持检测和纠正数据中的编码级别错误。
Note that more advanced error correction is best handled at a layer below that addressed by this document. Error correction is a topic well addressed by the storage industry in general (e.g., by Redundant Array of Independent Disks (RAID) and other technologies). By specifying a flow storage format based upon files, we can leverage these features to meet this requirement.
请注意，更高级的错误更正最好在本文档所述层的下方处理。错误纠正是存储行业普遍关注的一个主题（例如，通过独立磁盘冗余阵列（RAID）和其他技术）。通过基于文件指定流存储格式，我们可以利用这些功能来满足这一要求。
However, the ideal flow storage format will be resilient against errors, providing an internal facility for the detection of errors and the ability to isolate errors to as few data records as possible.
然而，理想的流存储格式将具有抗错误的弹性，提供用于检测错误的内部设施，并能够将错误隔离到尽可能少的数据记录中。
Note that this requirement interacts with the choice of data compression or encryption algorithm. For example, the use of block compression algorithms can serve to isolate errors to a single compression block, unlike stream compressors, which may fail to resynchronize after a single bit error, invalidating the entire message stream.
请注意，此要求与数据压缩或加密算法的选择相互影响。例如，使用块压缩算法可用于将错误隔离到单个压缩块，这与流压缩器不同，流压缩器可能在发生单比特错误后无法重新同步，从而使整个消息流无效。
The IPFIX Message format does not support data integrity assurance. It is assumed that advanced error correction will be provided externally. Compression and encryption, if used, provide some allowance for detection, if not correction, of errors. For simple error detection support in the absence of compression or encryption, checksums may be attached to messages via IPFIX Options according to the Message Checksum Options Template defined in Section 8.1.1.
IPFIX消息格式不支持数据完整性保证。假定将在外部提供高级错误校正。如果使用压缩和加密，即使不能纠正错误，也可以检测错误。为了在没有压缩或加密的情况下提供简单的错误检测支持，可以根据第8.1.1节中定义的消息校验和选项模板，通过IPFIX选项将校验和附加到消息。
Archival storage of flow data may also require assurance that no unauthorized entity can read or modify the stored data. Cryptography can be applied to this problem to ensure integrity and confidentiality by signing and encryption.
流数据的存档存储可能还需要确保未经授权的实体不能读取或修改存储的数据。密码学可以应用于这个问题，通过签名和加密来确保完整性和机密性。
As with error correction, this problem has been addressed well at a layer below that addressed by this document. We can leverage the fact that existing cryptographic technologies work quite well on data stored in files to meet this requirement.
与纠错一样，这个问题已经在本文档所述的下面一层得到了很好的解决。我们可以利用现有的加密技术对存储在文件中的数据非常有效这一事实来满足这一要求。
Beyond support for the use of Transport Layer Security (TLS) for transport over TCP or Datagram Transport Layer Security (DTLS) for transport over SCTP or UDP, both of which provide transient authentication and confidentiality, the IPFIX protocol does not support this requirement directly. The IETF has specified the Cryptographic Message Syntax (CMS) [RFC3852] for creating detached signatures for integrity and authentication; Section 9 specifies a CMS-based method for signing IPFIX Files. Confidentiality protection is assumed to be met by methods external to this specification, leveraging one of the many such technologies for encrypting files to meet specific application and process requirements; however, notes on improving archival integrity of encrypted IPFIX Files are given in Section 9.2.
除了支持使用传输层安全性（TLS）进行TCP传输或使用数据报传输层安全性（DTLS）进行SCTP或UDP传输（两者都提供瞬时身份验证和机密性）之外，IPFIX协议不直接支持此要求。IETF规定了加密消息语法（CMS）[RFC3852]，用于创建完整性和认证的分离签名；第9节指定了一种基于CMS的IPFIX文件签名方法。假定通过本规范之外的方法满足保密保护要求，利用众多此类技术之一对文件进行加密，以满足特定的应用和流程要求；但是，第9.2节给出了关于改进加密IPFIX文件存档完整性的说明。
To ensure the privacy of individuals and organizations at the endpoints of communications represented by flow records, it is often necessary to obfuscate or anonymize stored and exported flow data. The ideal flow storage format will provide for a notation that a given information element on a given record type represents anonymized, rather than real, data.
为了确保流记录所代表的通信端点处的个人和组织的隐私，通常需要对存储和导出的流数据进行模糊处理或匿名化。理想的流存储格式将提供一种表示法，即给定记录类型上的给定信息元素表示匿名数据，而不是真实数据。
The IPFIX protocol presently has no support for anonymization notation. It should be noted that anonymization is one of the requirements given for IPFIX in [RFC3917]. The decision to qualify this requirement with 'MAY' and not 'MUST' in the requirements document, and its subsequent lack of specification in the current version of the IPFIX protocol, is due to the fact that anonymization algorithms are still an open area of research, and that there currently exist no standardized methods for anonymization.
IPFIX协议目前不支持匿名标记。需要注意的是，匿名化是[RFC3917]中给出的IPFIX要求之一。决定在需求文件中用“可能”而不是“必须”来限定此需求，以及随后在当前版本的IPFIX协议中缺乏规范，这是因为匿名算法仍然是一个开放的研究领域，并且目前没有标准化的匿名方法。
No support is presently defined in [RFC5101] or this IPFIX-based File format for anonymization, as anonymization notation is an area of open work for the IPFIX Working Group.
[RFC5101]或此基于IPFIX的文件格式中目前未定义匿名支持，因为匿名标记是IPFIX工作组的一个开放工作领域。
Certain use cases for archival flow storage require the storage of collection infrastructure details alongside the data itself. These details include information about how and when data was received, and where it was received from. They are useful for auditing as well as for the replaying received data for testing purposes.
存档流存储的某些用例需要在存储数据本身的同时存储收集基础结构的详细信息。这些详细信息包括有关如何和何时接收数据以及从何处接收数据的信息。它们对于审计以及出于测试目的重放接收到的数据非常有用。
The IPFIX protocol contains no direct support for auditability and replayability, though the IPFIX Information Model does define various Information Elements required to represent collection infrastructure details. These details may be stored in IPFIX Files using the Export Session Details Options Template defined in Section 8.1.3, and the Message Details Options Template defined in Section 8.1.4.
IPFIX协议不包含对可审核性和可重放性的直接支持，尽管IPFIX信息模型定义了表示收集基础结构细节所需的各种信息元素。这些详细信息可以使用第8.1.3节中定义的导出会话详细信息选项模板和第8.1.4节中定义的消息详细信息选项模板存储在IPFIX文件中。
The ideal standard flow storage format will not have a significant negative impact on the performance of the application generating or processing flow data stored in the format. This is a non-functional requirement, but it is important to note that a standard that implies a significant performance penalty is unlikely to be widely implemented and adopted.
理想的标准流存储格式不会对生成或处理以该格式存储的流数据的应用程序的性能产生显著的负面影响。这是一项非功能性要求，但需要注意的是，意味着严重性能损失的标准不太可能得到广泛实施和采用。
An examination of the IPFIX protocol would seem to suggest that implementations of it are not particularly prone to slowness; indeed, a template-based data representation is more easily subject to optimization for common cases than representations that embed structural information directly in the data stream (e.g., XML). However, a full analysis of the impact of using IPFIX Messages as a basis for flow data storage on read/write performance will require more implementation experience and performance measurement.
对IPFIX协议的研究似乎表明，它的实现并不特别缓慢；事实上，基于模板的数据表示比直接将结构信息嵌入数据流（如XML）的表示更容易在常见情况下进行优化。但是，要全面分析使用IPFIX消息作为流数据存储基础对读/写性能的影响，需要更多的实施经验和性能度量。
This section describes the specific applicability of IPFIX Files to various use cases. IPFIX Files are particularly useful in a flow collection and processing infrastructure using IPFIX for flow export. We explore the applicability and provide guidelines for using IPFIX Files for the storage of flow data collected by IPFIX Collecting Processes and NetFlow V9 collectors, the testing of IPFIX Collecting Processes, and diagnostics of IPFIX Devices.
本节描述IPFIX文件对各种用例的具体适用性。IPFIX文件在使用IPFIX进行流导出的流收集和处理基础结构中特别有用。我们探讨了使用IPFIX文件存储IPFIX收集进程和NetFlow V9收集器收集的流数据、测试IPFIX收集进程以及诊断IPFIX设备的适用性，并提供了指南。
IPFIX Files can naturally be used to store flow data collected by an IPFIX Collecting Process; indeed, this was one of the primary initial motivations behind the file format described within this document. Using IPFIX Files as such provides a single, standard, well-understood encoding to be used for flow data on disk and on the wire, and allows IPFIX implementations to leverage substantially the same code for flow export and flow storage. In addition, the storage of single Transport Sessions in IPFIX Files is particularly important for network measurement research, allowing repeatability of
IPFIX文件自然可用于存储IPFIX收集过程收集的流数据；事实上，这是本文档中描述的文件格式背后的主要初始动机之一。这样使用IPFIX文件可以为磁盘和线路上的流数据提供一种单一的、标准的、易于理解的编码，并允许IPFIX实现为流导出和流存储利用基本相同的代码。此外，在IPFIX文件中存储单个传输会话对于网络测量研究尤为重要，这使得数据的可重复性成为可能
experiments by providing a format for the storage and exchange of IPFIX flow trace data much as the libpcap [pcap] format is used for experiments on packet trace data.
通过为IPFIX流跟踪数据的存储和交换提供一种格式来进行实验，就像libpcap[pcap]格式用于包跟踪数据的实验一样。
Although the IPFIX protocol is based on the Cisco NetFlow Services, Version 9 (NetFlow V9) protocol [RFC3954], the two have diverged since work began on IPFIX. However, since the NetFlow V9 information model is a compatible subset of the IPFIX Information Model, it is possible to use IPFIX Files to store collected NetFlow V9 flow data. This approach may be particularly useful in multi-vendor, multi-protocol collection infrastructures using both NetFlow V9 and IPFIX to export flow data.
尽管IPFIX协议基于Cisco NetFlow服务，版本9（NetFlow V9）协议[RFC3954]，但自从IPFIX工作开始以来，这两个协议已经出现分歧。但是，由于NetFlow V9信息模型是IPFIX信息模型的兼容子集，因此可以使用IPFIX文件存储收集的NetFlow V9流数据。这种方法在使用NetFlow V9和IPFIX导出流数据的多供应商、多协议收集基础架构中可能特别有用。
The applicability of IPFIX Files to this use case is outlined in Appendix B.
附录B概述了IPFIX文件对该用例的适用性。
IPFIX Files can be used to store IPFIX Messages for the testing of IPFIX Collecting Processes. A variety of test cases may be stored in IPFIX Files. First, IPFIX data collected in real network environments and stored in an IPFIX File can be used as input to check the behavior of new or extended implementations of IPFIX Collectors. Furthermore, IPFIX Files can be used to validate the operation of a given IPFIX Collecting Process in a new environment, i.e., to test with recorded IPFIX data from the target network before installing the Collecting Process in the network.
IPFIX文件可用于存储IPFIX消息，以测试IPFIX收集进程。各种测试用例可能存储在IPFIX文件中。首先，在真实网络环境中收集并存储在IPFIX文件中的IPFIX数据可以用作输入，以检查IPFIX收集器的新实现或扩展实现的行为。此外，IPFIX文件可用于验证新环境中给定IPFIX收集进程的操作，即在网络中安装收集进程之前，使用目标网络中记录的IPFIX数据进行测试。
The IPFIX File format can also be used to store artificial, non-compliant reference messages for specific Collecting Process test cases. Examples for such test cases are sets of IPFIX records with undefined Information Elements, Data Records described by missing Templates, or incorrectly framed Messages or Data Sets. Representative error handling test cases are defined in [RFC5471].
IPFIX文件格式还可用于存储特定收集过程测试用例的人工、不符合规范的参考消息。此类测试用例的示例包括具有未定义信息元素的IPFIX记录集、由缺少的模板描述的数据记录、或框架错误的消息或数据集。[RFC5471]中定义了具有代表性的错误处理测试用例。
Furthermore, fast replay of IPFIX Messages stored in a file can be used for stress/load tests (e.g., high rate of incoming Data Records, large Templates with high Information Element counts), as described in [RFC5471]. The provisioning and use of a set of reference files for testing simplifies the performance of tests and increases the comparability of test results.
此外，存储在文件中的IPFIX消息的快速重播可用于压力/负载测试（例如，高输入数据记录率、具有高信息元素计数的大型模板），如[RFC5471]所述。提供和使用一组用于测试的参考文件简化了测试的性能，并增加了测试结果的可比性。
As an IPFIX File can be used to store any collection of flows, the format may also be used for dumping and storing various types of flow data for IPFIX Device diagnostics (e.g., the open flow cache of a Metering Process or the flow backlog of an Exporting or Collecting Process at the time of a process reset or crash). File-based storage is preferable to remote transmission in such error-recovery situations.
由于IPFIX文件可用于存储任何流集合，因此该格式也可用于转储和存储用于IPFIX设备诊断的各种类型的流数据（例如，计量过程的开放流缓存或在过程重置或崩溃时导出或收集过程的流积压）。在这种错误恢复情况下，基于文件的存储优于远程传输。
Any valid serialized IPFIX Message stream MUST be accepted by a File Reader as a valid IPFIX File. In this way, the filesystem is simply treated as another IPFIX transport alongside SCTP, TCP, and UDP, albeit a potentially high-latency transport, as the File Reader and File Writer do not necessarily run at the same time.
文件读取器必须接受任何有效的序列化IPFIX消息流作为有效的IPFIX文件。通过这种方式，文件系统被简单地视为SCTP、TCP和UDP旁边的另一种IPFIX传输，尽管这可能是一种高延迟传输，因为文件读取器和文件写入器不一定同时运行。
This section specifies the detailed actions of File Readers and File Writers in handling IPFIX Files, and further specifies actions of File Writers in specific use cases. Unless otherwise specified herein, IPFIX File Writers MUST behave as IPFIX Exporting Processes, and IPFIX File Readers MUST behave as IPFIX Collecting Processes, where appropriate.
本节规定了文件读取器和文件写入器在处理IPFIX文件时的详细操作，并进一步规定了文件写入器在特定用例中的操作。除非本文另有规定，否则IPFIX文件编写器的行为必须与IPFIX导出过程相同，而IPFIX文件读取器的行为必须与IPFIX收集过程相同（如果适用）。
An IPFIX File Reader MUST act as an IPFIX Collecting Process as specified in [RFC5101], except as modified by this document.
IPFIX文件读取器必须充当[RFC5101]中指定的IPFIX收集过程，本文档修改的除外。
An IPFIX File Reader MUST accept as valid any serialized IPFIX Message stream that would be considered valid by one or more of the other defined IPFIX transport layers. Practically, this means that the union of IPFIX Template management features supported by SCTP, TCP, and UDP MUST be supported in IPFIX Files. File Readers MUST:
IPFIX文件读取器必须接受任何被一个或多个其他定义的IPFIX传输层视为有效的序列化IPFIX消息流。实际上，这意味着IPFIX文件中必须支持SCTP、TCP和UDP支持的IPFIX模板管理功能的联合。文件读取器必须：
o accept IPFIX Messages containing Template Sets, Options Template Sets, and Data Sets within the same message, as with IPFIX over TCP or UDP;
o 接受包含同一消息中的模板集、选项模板集和数据集的IPFIX消息，如TCP或UDP上的IPFIX；
o accept Template Sets that define Templates already defined within the File, as may occur with retransmission of Templates when using IPFIX over UDP as described in Section 10.3.6 of [RFC5101];
o 接受定义文件中已定义模板的模板集，如[RFC5101]第10.3.6节所述，在UDP上使用IPFIX时，可能会发生模板重传；
o resolve any conflict between a resent definition and a previous definition by assuming that the new Template replaces the old, as consistent with Template expiration and ID reuse when using UDP at the IPFIX transport protocol; and
o 通过假设新模板替换旧模板，解决重新定义和以前定义之间的任何冲突，这与在IPFIX传输协议中使用UDP时模板过期和ID重用一致；和
o accept Template Withdrawals as described in Section 8 of [RFC5101], provided that the Template to be withdrawn is defined, as is the case with IPFIX over TCP and SCTP.
o 接受[RFC5101]第8节所述的模板撤销，前提是要撤销的模板已定义，如TCP和SCTP上的IPFIX。
Considering the filesystem-as-transport view, in the general case, an IPFIX File SHOULD be treated as containing a single Transport Session as defined by [RFC5101]. However, some applications may benefit from the ability to treat a collection of IPFIX Files as a single Transport Session; see especially Section 7.3.3 below. A File Reader MAY be configurable to treat a collection of Files as a single Transport Session. However, a File Reader MUST NOT treat a single IPFIX File as containing multiple Transport Sessions.
将文件系统视为传输视图，在一般情况下，IPFIX文件应被视为包含[RFC5101]定义的单个传输会话。但是，某些应用程序可能会受益于将IPFIX文件集合视为单个传输会话的能力；具体见下文第7.3.3节。文件读取器可配置为将文件集合视为单个传输会话。但是，文件读取器不得将单个IPFIX文件视为包含多个传输会话。
If an IPFIX File uses the technique described in [RFC5473] AND all of the non-Options Templates in the File contain the commonPropertiesId Information Element, a File Reader MAY assume the set of commonPropertiesId definitions provides a complete table of contents for the File for searching purposes.
如果IPFIX文件使用[RFC5473]中所述的技术，并且文件中的所有非选项模板都包含commonPropertiesId信息元素，则文件读取器可能会认为commonPropertiesId定义集为文件提供了完整的目录，用于搜索目的。
An IPFIX File Writer MUST act as an IPFIX Exporting Process as specified in [RFC5101], except as modified by this document. This section contains specifications for IPFIX File Writers in all situations; specifications and recommendations for specific File Writer use cases are found in Section 7.3 below.
IPFIX文件编写器必须充当[RFC5101]中指定的IPFIX导出过程，本文档修改的除外。本节包含所有情况下IPFIX文件编写器的规范；具体文件编写器用例的规范和建议见下文第7.3节。
File Writers SHOULD store the Templates and Options required to decode the data within the File itself, unless modified by the requirements of a specific use case in a subsection of Section 7.3. In this way, a single IPFIX File generally contains a single notional Transport Session as defined by [RFC5101].
文件编写者应在文件本身中存储解码数据所需的模板和选项，除非根据第7.3节小节中特定用例的要求进行修改。这样，单个IPFIX文件通常包含[RFC5101]定义的单个概念传输会话。
File Writers SHOULD emit each Template Set or Options Template Set to appear in the File before any Data Set described by the Templates within that Set, to ensure the File Reader can decode every Data Set without waiting to process subsequent Templates or Options Templates.
文件编写器应在文件中显示每个模板集或选项模板集，然后再显示该模板集中模板所描述的任何数据集，以确保文件读取器可以解码每个数据集，而无需等待处理后续模板或选项模板。
File Writers SHOULD emit Data Records described by Options Templates to appear in the File before any Data Records that depend on the scopes defined by those options.
文件编写器应发出由选项模板描述的数据记录，以显示在依赖于这些选项定义的范围的任何数据记录之前的文件中。
File Writers SHOULD use Template Withdrawals to withdraw Templates if Template IDs need to be reused. Template Withdrawals SHOULD NOT be used unless it is necessary to reuse Template IDs.
如果需要重用模板ID，文件编写器应该使用模板撤消来撤消模板。除非有必要重用模板ID，否则不应使用模板提取。
File Writers SHOULD write IPFIX Messages within an IPFIX File in ascending Export Time order.
文件编写器应按升序导出时间顺序在IPFIX文件中写入IPFIX消息。
File Writers MAY write Data Records to an IPFIX File in any order. However, File Writers that write flow records to an IPFIX File in flowStartTime or flowEndTime order SHOULD be consistent in this ordering within each File.
文件编写器可以按任何顺序将数据记录写入IPFIX文件。但是，以flowStartTime或flowEndTime顺序将流记录写入IPFIX文件的文件编写器在每个文件中的顺序应一致。
The specifications in this section apply to specific situations. Each section below extends or modifies the base File Writer specification in Section 7.2. Considerations for collocation of a File Writer with IPFIX Collecting Processes and Metering Processes are given, as are specific guidelines for using IPFIX Files for archival storage, or as documents. Also covered are the use of IPFIX Files in the testing and diagnostics of IPFIX Devices.
本节中的规范适用于特定情况。下面的每一节都扩展或修改了第7.2节中的基本文件编写器规范。文中给出了文件编写器与IPFIX收集过程和计量过程的配置注意事项，以及将IPFIX文件用于存档存储或用作文档的具体指南。还包括在IPFIX设备的测试和诊断中使用IPFIX文件。
When collocating a File Writer with an IPFIX Collecting Process for archival storage of collected data in IPFIX Files as described in Section 6.1, the following recommendations may improve the usefulness of the stored data.
如第6.1节所述，将文件编写器与IPFIX收集过程配置在一起，以将收集的数据归档存储在IPFIX文件中时，以下建议可能会提高存储数据的有用性。
The simplest way for a File Writer to store the data collected in a single Transport Session is to simply write the incoming IPFIX Messages to an IPFIX File as they are collected. This approach has several drawbacks. First, if the original Exporting Process did not conform to the recommendations in Section 7.2 with respect to Template and Data Record ordering, the written file can be difficult to use later; in this case, File Writers MAY reorder records as received in order to ensure that Templates appear before the Data Records they describe.
文件编写器存储在单个传输会话中收集的数据的最简单方法是在收集传入的IPFIX消息时将其写入IPFIX文件。这种方法有几个缺点。首先，如果原始导出过程不符合第7.2节中关于模板和数据记录排序的建议，则以后可能难以使用书面文件；在这种情况下，文件编写器可能会对收到的记录重新排序，以确保模板出现在它们描述的数据记录之前。
A File Writer collocated with a Collecting Process that starts writing data from a running Transport Session SHOULD write all the Templates currently active within that Transport Session before writing any Data Records described by them.
与从正在运行的传输会话开始写入数据的收集进程并置的文件编写器应在写入该传输会话中当前活动的所有模板之前，写入它们所描述的任何数据记录。
Also, the resulting IPFIX Files will lack information about the IPFIX Transport Session used to export them, such as the network addresses of the Exporting and Collecting Processes and the protocols used to transport them. In this case, if information about the Transport Session is required, the File Writer SHOULD store a single IPFIX Transport Session in an IPFIX File and SHOULD record information about the Transport Session using the Export Session Details Options Template described in Section 8.1.3.
此外，生成的IPFIX文件将缺少有关用于导出它们的IPFIX传输会话的信息，例如导出和收集进程的网络地址以及用于传输它们的协议。在这种情况下，如果需要有关传输会话的信息，文件编写器应将单个IPFIX传输会话存储在IPFIX文件中，并应使用第8.1.3节所述的导出会话详细信息选项模板记录有关传输会话的信息。
Additional per-Message information MAY be recorded by the File Writer using the Message Details Options Template described in Section 8.1.4. Per-Message information includes the time at which each IPFIX Message was received at the Collecting Process, and can be used to resend IPFIX Messages while keeping the original measurement plane traffic profile.
文件编写器可使用第8.1.4节所述的消息详细信息选项模板记录每条消息的附加信息。每条消息信息包括在收集过程中收到每条IPFIX消息的时间，可用于在保留原始测量平面流量配置文件的同时重新发送IPFIX消息。
When collocating a File Writer with a Collecting Process, the Export Time of each Message SHOULD be the Export Time of the Message received by the Collecting Process containing the first Data Record in the Message. Note that File Writers storing IPFIX data collected from an IPFIX Collecting Process using SCTP as the transport protocol SHOULD interleave messages from multiple streams in order to preserve Export Time order, and SHOULD reorder the written messages as necessary to ensure that each Template Set or Options Template Set appears in the File before any Data Set described by the Templates within that Set. Template reordering MUST preserve the sequence of Template Sets with Template Withdrawals in order to ensure consistency of Templates.
将文件编写器与收集进程并置时，每条消息的导出时间应为收集进程接收的包含消息中第一条数据记录的消息的导出时间。请注意，存储从使用SCTP作为传输协议的IPFIX收集过程中收集的IPFIX数据的文件编写器应交错来自多个流的消息，以保持导出时间顺序，并应根据需要对书面消息重新排序，以确保每个模板集或选项模板集出现在文件中，位于该集中模板描述的任何数据集之前。模板重新排序必须保留模板集与模板提取的顺序，以确保模板的一致性。
Note that when adding additional information to IPFIX Messages received from Collecting Processes (e.g., Message Checksum Options, Message Detail Options), the File Writer SHOULD extend the length of the Message for the additional data if possible; otherwise, the Message SHOULD be split into two approximately equal-size Messages aligned on a Data Set or Template Set boundary from the original Message if possible; otherwise, the Message SHOULD be split into two approximately equal-size Messages aligned on a Data Record boundary. Note that, since the Maximum Segment Size (MSS) or MTU of most network links (1500-9000 for common Ethernets) is smaller than the maximum IPFIX Message size (65536) within an IPFIX File, it is expected that message length extension will suffice in most circumstances.
请注意，当向从收集过程接收的IPFIX消息添加附加信息（例如，消息校验和选项、消息详细信息选项）时，如果可能，文件编写器应延长附加数据的消息长度；否则，如果可能，应将消息拆分为两个大小大致相等的消息，并与原始消息在数据集或模板集边界上对齐；否则，应将消息拆分为两个大小大致相等的消息，并在数据记录边界上对齐。请注意，由于大多数网络链路（普通以太网为1500-9000）的最大段大小（MSS）或MTU小于IPFIX文件中的最大IPFIX消息大小（65536），因此预计消息长度扩展在大多数情况下就足够了。
A File Writer collocated with a Collecting Process SHOULD NOT sign a File as specified in Section 9.1 unless the Transport Session over which the data was exported was protected via TLS or DTLS, and the Collecting Process positively identified the Exporting Process by its certificate. See Section 12.2 for more information on this issue.
与收集进程并置的文件编写器不应按照第9.1节的规定对文件进行签名，除非导出数据的传输会话通过TLS或DTL进行了保护，并且收集进程通过其证书明确标识了导出进程。有关此问题的更多信息，请参见第12.2节。
Note that File Writers may also be collocated directly with IPFIX Metering Processes, for writing measured information directly to disk without intermediate IPFIX Exporting or Collecting Processes. This arrangement may be particularly useful when providing data to an
请注意，文件写入程序也可以直接与IPFIX计数进程并置，以便将测量的信息直接写入磁盘，而无需中间IPFIX导出或收集进程。当向用户提供数据时，这种安排可能特别有用
analysis environment with an IPFIX-File-based workflow, when testing Metering Processes during development, or when the authentication of a Metering Process is important.
在开发期间测试计量流程时，或在计量流程的身份验证非常重要时，使用基于IPFIX文件的工作流分析环境。
When collocating a File Writer with a Metering Process, note that Information Elements associated with Exporting or Collecting Processes are meaningless, and SHOULD NOT appear in the Export Session Details Options Template described in Section 8.1.3 or the Message Details Options Template described in Section 8.1.4.
将文件编写器与计量流程并置时，请注意，与导出或收集流程相关联的信息元素没有意义，不应出现在第8.1.3节所述的导出会话详细信息选项模板或第8.1.4节所述的消息详细信息选项模板中。
When collocating a File Writer with a Metering Process, the Export Time of each Message SHOULD be the time at which the first Data Record in the Message was received from the Metering Process.
将文件写入程序与计量进程并置时，每条消息的导出时间应为从计量进程接收到消息中第一条数据记录的时间。
Note that collocating a File Writer with a Metering Process is the only way to provide positive authentication of a Metering Process through signatures as in Section 9.1. See Section 12.2 for more information on this issue.
注意，如第9.1节所述，将文件编写器与计量过程并置是通过签名对计量过程进行正面认证的唯一方法。有关此问题的更多信息，请参见第12.2节。
While in the general case File Writers should store one Transport Session per IPFIX File, some applications storing large collections of data over long periods of time may benefit from the ability to treat a collection of IPFIX Files as a single Transport Session. A File Writer MAY be configurable to write data from a single Transport Session into multiple IPFIX Files; however, File Writers supporting such a configuration option MUST provide a configuration option to support one-file-per-session behavior for interoperability purposes.
虽然在一般情况下，文件编写器应该为每个IPFIX文件存储一个传输会话，但一些长期存储大量数据集合的应用程序可能会受益于将IPFIX文件集合视为单个传输会话的能力。文件写入器可配置为将数据从单个传输会话写入多个IPFIX文件；但是，支持此类配置选项的文件编写器必须提供一个配置选项，以支持每个会话一个文件的行为，以实现互操作性。
File Writers using IPFIX Files for archival storage SHOULD support compression as in Section 10.
使用IPFIX文件进行归档存储的文件编写器应支持第10节中所述的压缩。
When IPFIX Files are used as documents, to store a set of flows relevant to query, investigation, or other common context, or for the publication of traffic datasets relevant to network research, each File MUST be readable as a single Transport Session, self-contained aside from any detached signature as in Section 9.1, and making no reference to metadata stored in separate Files, in order to ensure interoperability.
当IPFIX文件用作文档，用于存储与查询、调查或其他公共上下文相关的一组流，或用于发布与网络研究相关的流量数据集时，每个文件必须作为单个传输会话可读，除了第9.1节中的任何分离签名外，还必须是独立的，并且不参考存储在单独文件中的元数据，以确保互操作性。
When writing Files to be used as documents, File Writers MAY emit the special Data Records described by Options Templates before any other Data Records in the File in the following order to ease the inspection and use of documents by File Readers:
在编写用作文档的文件时，文件编写器可以在文件中的任何其他数据记录之前，按照以下顺序发出选项模板描述的特殊数据记录，以便于文件读取器检查和使用文档：
o Time Window records described by the File Time Window Options Template as defined in Section 8.1.2 below; followed by:
o 下文第8.1.2节中定义的文件时间窗口选项模板描述的时间窗口记录；然后：
o Information Element Type Records as described in [RFC5610]; followed by
o [RFC5610]中所述的信息元素类型记录；然后
o commonPropertiesId definitions as described in [RFC5473]; followed by
o [RFC5473]中所述的公共属性ID定义；然后
o Export Session details records described by the Export Session Details Options Template as defined in Section 8.1.3 below.
o 导出会话详细信息记录由下面第8.1.3节中定义的导出会话详细信息选项模板描述。
The Export Time of each Message within a File used as a document SHOULD be the time at which the Message was written by the File Writer.
用作文档的文件中每条消息的导出时间应为文件编写器写入消息的时间。
If an IPFIX File used as a document uses the technique described in [RFC5473] AND all of the non-Options Templates in the File contain the commonPropertiesId Information Element, a File Reader MAY assume the set of commonPropertiesId definitions provides a complete table of contents for the File for searching purposes.
如果用作文档的IPFIX文件使用[RFC5473]中描述的技术，并且文件中的所有非选项模板都包含commonPropertiesId信息元素，则文件读取器可能会假定commonPropertiesId定义集为文件提供了完整的目录，以供搜索。
IPFIX Files can be used for testing IPFIX Collecting Processes in two ways. First, IPFIX Files can be used to store specific flow data for regression and stress testing of Collectors; there are no special considerations for IPFIX Files used in this way.
IPFIX文件可以通过两种方式用于测试IPFIX收集进程。首先，IPFIX文件可用于存储特定的流量数据，以便对收集器进行回归和压力测试；以这种方式使用的IPFIX文件没有特殊的注意事项。
Second, IPFIX Files are useful for storing reference messages that do not comply to the IPFIX protocol in order to test the error handling and recovery behavior of Collectors. Of course, IPFIX Files intended to be used in this application necessarily MAY violate any of the specifications in this document or in [RFC5101], and such Files MUST NOT be transmitted to Collecting Processes or given as input to File Readers not under test.
其次，IPFIX文件可用于存储不符合IPFIX协议的引用消息，以测试收集器的错误处理和恢复行为。当然，本应用程序中使用的IPFIX文件可能会违反本文件或[RFC5101]中的任何规范，且不得将此类文件传输至采集过程或作为输入提供给未经测试的文件读取器。
Note that an extremely simple IPFIX Exporting Process may be crafted for testing purposes by simply reading an IPFIX File and transmitting it directly to a Collecting Process. Similarly, an extremely simple Collecting Process may be crafted for testing purposes by simply accepting connections and/or IPFIX Messages from Exporting Processes and writing the session's message stream to an IPFIX File.
请注意，出于测试目的，只需读取IPFIX文件并将其直接传输到收集进程，就可以创建一个非常简单的IPFIX导出进程。类似地，可以为测试目的精心设计一个非常简单的收集过程，只需从导出过程中接受连接和/或IPFIX消息，并将会话的消息流写入IPFIX文件。
IPFIX Files can be used in the debugging of devices that use flow data as internal state, as a common format for the representation of flow tables. In such situations, the opaqueOctets information element can be used to store additional non-IPFIX encoded, non-flow information (e.g., stack backtraces, process state, etc.) within the IPFIX File as in Section 11.1; the IPFIX flow table information could also be embedded in a larger proprietary diagnostic format using delimiters as in Section 11.2
IPFIX文件可用于调试将流数据用作内部状态的设备，作为流表表示的通用格式。在这种情况下，opaqueOctets信息元素可用于在IPFIX文件内存储额外的非IPFIX编码的非流信息（例如，堆栈回溯、进程状态等），如第11.1节所述；IPFIX流量表信息也可以使用第11.2节中的分隔符嵌入到更大的专有诊断格式中
For many applications, it may prove useful for implementations to provide functionality for the manipulation of IPFIX Files; for example, to select data from a File, to change the Templates used within a File, or to split or join data in Files. Any such utility should take special care to ensure that its output remains a valid IPFIX File, specifically with respect to Templates and Options, which are scoped to Transport Sessions.
对于许多应用程序，提供IPFIX文件操作功能的实现可能很有用；例如，从文件中选择数据、更改文件中使用的模板或拆分或合并文件中的数据。任何这样的实用程序都应该特别小心，以确保其输出仍然是有效的IPFIX文件，特别是关于模板和选项，它们的作用域是传输会话。
Any operation that splits one File into multiple Files SHOULD write all necessary Templates and Options to each resulting File, and ensure that written Options are valid for each resulting File (e.g., the Time Window Options Template in Section 8.1.2). Any operation that joins multiple Files into a single File should do the same, additionally ensuring that Template IDs do not collide, through the use of different Observation Domain IDs or Template ID rewriting. Combining operations may also want to ensure any desired ordering of flow records is maintained.
将一个文件拆分为多个文件的任何操作应将所有必要的模板和选项写入每个结果文件，并确保写入的选项对每个结果文件有效（例如，第8.1.2节中的时间窗口选项模板）。通过使用不同的观察域ID或模板ID重写，将多个文件合并到单个文件中的任何操作都应该执行相同的操作，另外还要确保模板ID不会发生冲突。组合操作可能还希望确保维持流记录的任何所需顺序。
The media type for IPFIX Files is application/ipfix. The registration information [RFC4288] for this media type is given in the IANA Considerations section.
IPFIX文件的介质类型为应用程序/IPFIX。IANA注意事项部分给出了该媒体类型的注册信息[RFC4288]。
This section defines the Options Templates used for IPFIX File metadata, and the Information Elements they require.
本节定义用于IPFIX文件元数据的选项模板及其所需的信息元素。
The following Options Templates allow IPFIX Message streams to meet the requirements outlined above without extension to the message format or protocol. They are defined in terms of existing Information Elements defined in [RFC5102], the Information Elements
以下选项模板允许IPFIX消息流满足上述要求，而无需扩展消息格式或协议。它们根据[RFC5102]中定义的现有信息元素定义，即信息元素
defined in [RFC5610], as well as Information Elements defined in Section 8.2. IPFIX File Readers and Writers SHOULD support these Options Templates as defined below.
[RFC5610]中定义，以及第8.2节中定义的信息元素。IPFIX文件读取器和写入器应支持以下定义的选项模板。
In addition, IPFIX File Readers and Writers SHOULD support the Options Templates defined in [RFC5610] in order to support self-description of enterprise-specific Information Elements.
此外，IPFIX文件读取器和写入器应支持[RFC5610]中定义的选项模板，以支持企业特定信息元素的自描述。
The Message Checksum Options Template specifies the structure of a Data Record for attaching an MD5 message checksum to an IPFIX Message. An MD5 message checksum as described MAY be used if data integrity is important to the application but file signing is not available or desired. The described Data Record MUST appear only once per IPFIX Message, but MAY appear anywhere within the Message.
消息校验和选项模板指定将MD5消息校验和附加到IPFIX消息的数据记录的结构。如果数据完整性对应用程序很重要，但文件签名不可用或不需要，则可以使用如上所述的MD5消息校验和。描述的数据记录在每条IPFIX消息中只能出现一次，但可以出现在消息中的任何位置。
This Options Template SHOULD contain the following Information Elements:
此选项模板应包含以下信息元素：
+--------------------+----------------------------------------------+
| IE | Description |
+--------------------+----------------------------------------------+
| messageScope | A marker denoting this Option applies to the |
| [scope] | whole IPFIX Message; content is ignored. |
| | This Information Element MUST be defined as |
| | a Scope Field. |
| messageMD5Checksum | The MD5 checksum of the containing IPFIX |
| | Message. |
+--------------------+----------------------------------------------+
+--------------------+----------------------------------------------+
| IE | Description |
+--------------------+----------------------------------------------+
| messageScope | A marker denoting this Option applies to the |
| [scope] | whole IPFIX Message; content is ignored. |
| | This Information Element MUST be defined as |
| | a Scope Field. |
| messageMD5Checksum | The MD5 checksum of the containing IPFIX |
| | Message. |
+--------------------+----------------------------------------------+
The File Time Window Options Template specifies the structure of a Data Record for attaching a time window to an IPFIX File; this Data Record is referred to as a time window record. A time window record defines the earliest flow start time and the latest flow end time of the flow records within a File. One and only one time window record MAY appear within an IPFIX File if the time window information is available; a File Writer MUST NOT write more than one time window record to an IPFIX File. A File Writer that writes a time window record to a File MUST NOT write any Flow with a start time before the beginning of the window or an end time after the end of the window to that File.
文件时间窗口选项模板指定用于将时间窗口附加到IPFIX文件的数据记录的结构；此数据记录称为时间窗口记录。时间窗口记录定义文件中流记录的最早流开始时间和最新流结束时间。如果时间窗口信息可用，IPFIX文件中可能会出现一条且只有一条时间窗口记录；文件编写器不能将多个时间窗口记录写入IPFIX文件。将时间窗口记录写入文件的文件编写器不得将开始时间在窗口开始之前或结束时间在窗口结束之后的任何流写入该文件。
This Options Template SHOULD contain the following Information Elements:
此选项模板应包含以下信息元素：
+---------------+---------------------------------------------------+
| IE | Description |
+---------------+---------------------------------------------------+
| sessionScope | A marker denoting this Option applies to the |
| [scope] | whole IPFIX Transport Session (i.e., the IPFIX |
| | File in the common case); content is ignored. |
| | This Information Element MUST be defined as a |
| | Scope Field. |
| minFlowStart* | Exactly one of minFlowStartSeconds, |
| | minFlowStartMilliseconds, |
| | minFlowStartMicroseconds, or |
| | minFlowStartNanoseconds SHOULD match the |
| | precision of the accompanying maxFlowEnd* |
| | Information Element. The start time of the |
| | earliest flow in the Transport Session (i.e., |
| | File). |
| maxFlowEnd* | Exactly one of maxFlowEndSeconds, |
| | maxFlowEndMilliseconds, maxFlowEndMicroseconds, |
| | or maxFlowEndNanoseconds SHOULD match the |
| | precision of the accompanying minFlowStart* |
| | Information Element. The end time of the latest |
| | flow in the Transport Session (i.e., File). |
+---------------+---------------------------------------------------+
+---------------+---------------------------------------------------+
| IE | Description |
+---------------+---------------------------------------------------+
| sessionScope | A marker denoting this Option applies to the |
| [scope] | whole IPFIX Transport Session (i.e., the IPFIX |
| | File in the common case); content is ignored. |
| | This Information Element MUST be defined as a |
| | Scope Field. |
| minFlowStart* | Exactly one of minFlowStartSeconds, |
| | minFlowStartMilliseconds, |
| | minFlowStartMicroseconds, or |
| | minFlowStartNanoseconds SHOULD match the |
| | precision of the accompanying maxFlowEnd* |
| | Information Element. The start time of the |
| | earliest flow in the Transport Session (i.e., |
| | File). |
| maxFlowEnd* | Exactly one of maxFlowEndSeconds, |
| | maxFlowEndMilliseconds, maxFlowEndMicroseconds, |
| | or maxFlowEndNanoseconds SHOULD match the |
| | precision of the accompanying minFlowStart* |
| | Information Element. The end time of the latest |
| | flow in the Transport Session (i.e., File). |
+---------------+---------------------------------------------------+
The Export Session Details Options Template specifies the structure of a Data Record for recording the details of an IPFIX Transport Session in an IPFIX File. It is intended for use in storing a single complete IPFIX Transport Session in a single IPFIX File. The described Data Record SHOULD appear only once in a given IPFIX File.
导出会话详细信息选项模板指定用于在IPFIX文件中记录IPFIX传输会话详细信息的数据记录的结构。它用于在单个IPFIX文件中存储单个完整的IPFIX传输会话。所述数据记录在给定的IPFIX文件中只应出现一次。
This Options Template SHOULD contain at least the following Information Elements, subject to applicability as noted on each Information Element:
该选项模板应至少包含以下信息元素，并根据每个信息元素上注明的适用性：
+----------------------------+--------------------------------------+
| IE | Description |
+----------------------------+--------------------------------------+
| sessionScope [scope] | A marker denoting this Option |
| | applies to the whole IPFIX Transport |
| | Session (i.e., the IPFIX File in the |
| | common case); content is ignored. |
| | This Information Element MUST be |
| | defined as a Scope Field. |
| exporterIPv4Address | IPv4 address of the IPFIX Exporting |
| | Process from which the Messages in |
| | this Transport Session were |
| | received. Present only for |
| | Exporting Processes with an IPv4 |
| | interface. For multi-homed SCTP |
| | associations, this SHOULD be the |
| | primary path endpoint address of the |
| | Exporting Process. |
| exporterIPv6Address | IPv6 address of the IPFIX Exporting |
| | Process from which the Messages in |
| | this Transport Session were |
| | received. Present only for |
| | Exporting Processes with an IPv6 |
| | interface. For multi-homed SCTP |
| | associations, this SHOULD be the |
| | primary path endpoint address of the |
| | Exporting Process. |
| exporterTransportPort | The source port from which the |
| | Messages in this Transport Session |
| | were received. |
| exporterCertificate | The certificate used by the IPFIX |
| | Exporting Process from which the |
| | Messages in this Transport Session |
| | were received. Present only for |
| | Transport Sessions protected by TLS |
| | or DTLS. |
| collectorIPv4Address | IPv4 address of the IPFIX Collecting |
| | Process that received the Messages |
| | in this Transport Session. Present |
| | only for Collecting Processes with |
| | an IPv4 interface. For multi-homed |
| | SCTP associations, this SHOULD be |
| | the primary path endpoint address of |
| | the Collecting Process. |
| collectorIPv6Address | IPv6 address of the IPFIX Collecting |
| | Process that received the Messages |
| | in this Transport Session. Present |
| | only for Collecting Processes with |
+----------------------------+--------------------------------------+
| IE | Description |
+----------------------------+--------------------------------------+
| sessionScope [scope] | A marker denoting this Option |
| | applies to the whole IPFIX Transport |
| | Session (i.e., the IPFIX File in the |
| | common case); content is ignored. |
| | This Information Element MUST be |
| | defined as a Scope Field. |
| exporterIPv4Address | IPv4 address of the IPFIX Exporting |
| | Process from which the Messages in |
| | this Transport Session were |
| | received. Present only for |
| | Exporting Processes with an IPv4 |
| | interface. For multi-homed SCTP |
| | associations, this SHOULD be the |
| | primary path endpoint address of the |
| | Exporting Process. |
| exporterIPv6Address | IPv6 address of the IPFIX Exporting |
| | Process from which the Messages in |
| | this Transport Session were |
| | received. Present only for |
| | Exporting Processes with an IPv6 |
| | interface. For multi-homed SCTP |
| | associations, this SHOULD be the |
| | primary path endpoint address of the |
| | Exporting Process. |
| exporterTransportPort | The source port from which the |
| | Messages in this Transport Session |
| | were received. |
| exporterCertificate | The certificate used by the IPFIX |
| | Exporting Process from which the |
| | Messages in this Transport Session |
| | were received. Present only for |
| | Transport Sessions protected by TLS |
| | or DTLS. |
| collectorIPv4Address | IPv4 address of the IPFIX Collecting |
| | Process that received the Messages |
| | in this Transport Session. Present |
| | only for Collecting Processes with |
| | an IPv4 interface. For multi-homed |
| | SCTP associations, this SHOULD be |
| | the primary path endpoint address of |
| | the Collecting Process. |
| collectorIPv6Address | IPv6 address of the IPFIX Collecting |
| | Process that received the Messages |
| | in this Transport Session. Present |
| | only for Collecting Processes with |
| | an IPv6 interface. For multi-homed |
| | SCTP associations, this SHOULD be |
| | the primary path endpoint address of |
| | the Collecting Process. |
| collectorTransportPort | The destination port on which the |
| | Messages in this Transport Session |
| | were received. |
| collectorTransportProtocol | The IP Protocol Identifier of the |
| | transport protocol used to transport |
| | Messages within this Transport |
| | Session. |
| collectorProtocolVersion | The version of the export protocol |
| | used to transport Messages within |
| | this Transport Session. Applicable |
| | only in mixed NetFlow V9-IPFIX |
| | collection environments when storing |
| | NetFlow V9 data in IPFIX Messages, |
| | as in Appendix B. |
| collectorCertificate | The certificate used by the IPFIX |
| | Collecting Process that received the |
| | Messages in this Transport Session. |
| | Present only for Transport Sessions |
| | protected by TLS or DTLS. |
| minExportSeconds | The Export Time of the first Message |
| | in the Transport Session. |
| maxExportSeconds | The Export Time of the last Message |
| | in the Transport Session. |
+----------------------------+--------------------------------------+
| | an IPv6 interface. For multi-homed |
| | SCTP associations, this SHOULD be |
| | the primary path endpoint address of |
| | the Collecting Process. |
| collectorTransportPort | The destination port on which the |
| | Messages in this Transport Session |
| | were received. |
| collectorTransportProtocol | The IP Protocol Identifier of the |
| | transport protocol used to transport |
| | Messages within this Transport |
| | Session. |
| collectorProtocolVersion | The version of the export protocol |
| | used to transport Messages within |
| | this Transport Session. Applicable |
| | only in mixed NetFlow V9-IPFIX |
| | collection environments when storing |
| | NetFlow V9 data in IPFIX Messages, |
| | as in Appendix B. |
| collectorCertificate | The certificate used by the IPFIX |
| | Collecting Process that received the |
| | Messages in this Transport Session. |
| | Present only for Transport Sessions |
| | protected by TLS or DTLS. |
| minExportSeconds | The Export Time of the first Message |
| | in the Transport Session. |
| maxExportSeconds | The Export Time of the last Message |
| | in the Transport Session. |
+----------------------------+--------------------------------------+
The Message Details Options Template specifies the structure of a Data Record for attaching additional export details to an IPFIX Message. These details include the time at which a message was received and information about the export and collection infrastructure used to transport the Message. This Options Template also allows the storage of the export session metadata provided the Export Session Details Options Template, for storing information from multiple Transport Sessions in the same IPFIX File.
“邮件详细信息选项”模板指定用于将其他导出详细信息附加到IPFIX邮件的数据记录的结构。这些详细信息包括接收邮件的时间以及有关用于传输邮件的导出和收集基础结构的信息。此选项模板还允许存储导出会话详细信息选项模板提供的导出会话元数据，用于在同一IPFIX文件中存储来自多个传输会话的信息。
This Options Template SHOULD contain at least the following Information Elements, subject to applicability as noted for each Information Element. Note that when used in conjunction with the Export Session Details Options Template, when storing a single complete IPFIX Transport Session in an IPFIX File, this Options Template SHOULD contain only the messageScope and
该选项模板应至少包含以下信息元素，并根据每个信息元素的适用性而定。请注意，当与导出会话详细信息选项模板一起使用时，在IPFIX文件中存储单个完整的IPFIX传输会话时，此选项模板应仅包含messageScope和
collectionTimeMilliseconds Information Elements, and the exportSctpStreamId Information Element for Messages transported via SCTP.
CollectionTimeMillicles信息元素，以及用于通过SCTP传输的消息的exportSctpStreamId信息元素。
+----------------------------+--------------------------------------+
| IE | Description |
+----------------------------+--------------------------------------+
| messageScope [scope] | A marker denoting this Option |
| | applies to the whole IPFIX message; |
| | content is ignored. This |
| | Information Element MUST be defined |
| | as a Scope Field. |
| collectionTimeMilliseconds | The absolute time at which this |
| | Message was received by the IPFIX |
| | Collecting Process. |
| exporterIPv4Address | IPv4 address of the IPFIX Exporting |
| | Process from which this Message was |
| | received. Present only for |
| | Exporting Processes with an IPv4 |
| | interface, and if this information |
| | is not available via the Export |
| | Session Details Options Template. |
| | For multi-homed SCTP associations, |
| | this SHOULD be the primary path |
| | endpoint address of the Exporting |
| | Process. |
| exporterIPv6Address | IPv6 address of the IPFIX Exporting |
| | Process from which this Message was |
| | received. Present only for |
| | Exporting Processes with an IPv6 |
| | interface and if this information is |
| | not available via the Export Session |
| | Details Options Template. For |
| | multi-homed SCTP associations, this |
| | SHOULD be the primary path endpoint |
| | address of the Exporting Process. |
| exporterTransportPort | The source port from which this |
| | Message was received. Present only |
| | if this information is not available |
| | via the Export Session Details |
| | Options Template. |
| exporterCertificate | The certificate used by the IPFIX |
| | Exporting Process from which this |
| | Message was received. Present only |
| | for Transport Sessions protected by |
| | TLS or DTLS. |
| collectorIPv4Address | IPv4 address of the IPFIX Collecting |
| | Process that received this Message. |
+----------------------------+--------------------------------------+
| IE | Description |
+----------------------------+--------------------------------------+
| messageScope [scope] | A marker denoting this Option |
| | applies to the whole IPFIX message; |
| | content is ignored. This |
| | Information Element MUST be defined |
| | as a Scope Field. |
| collectionTimeMilliseconds | The absolute time at which this |
| | Message was received by the IPFIX |
| | Collecting Process. |
| exporterIPv4Address | IPv4 address of the IPFIX Exporting |
| | Process from which this Message was |
| | received. Present only for |
| | Exporting Processes with an IPv4 |
| | interface, and if this information |
| | is not available via the Export |
| | Session Details Options Template. |
| | For multi-homed SCTP associations, |
| | this SHOULD be the primary path |
| | endpoint address of the Exporting |
| | Process. |
| exporterIPv6Address | IPv6 address of the IPFIX Exporting |
| | Process from which this Message was |
| | received. Present only for |
| | Exporting Processes with an IPv6 |
| | interface and if this information is |
| | not available via the Export Session |
| | Details Options Template. For |
| | multi-homed SCTP associations, this |
| | SHOULD be the primary path endpoint |
| | address of the Exporting Process. |
| exporterTransportPort | The source port from which this |
| | Message was received. Present only |
| | if this information is not available |
| | via the Export Session Details |
| | Options Template. |
| exporterCertificate | The certificate used by the IPFIX |
| | Exporting Process from which this |
| | Message was received. Present only |
| | for Transport Sessions protected by |
| | TLS or DTLS. |
| collectorIPv4Address | IPv4 address of the IPFIX Collecting |
| | Process that received this Message. |
| | Present only for Collecting |
| | Processes with an IPv4 interface, |
| | and if this information is not |
| | available via the Export Session |
| | Details Options Template. For |
| | multi-homed SCTP associations, this |
| | SHOULD be the primary path endpoint |
| | address of the Collecting Process. |
| collectorIPv6Address | IPv6 address of the IPFIX Collecting |
| | Process that received this Message. |
| | Present only for Collecting |
| | Processes with an IPv6 interface, |
| | and if this information is not |
| | available via the Export Session |
| | Details Options Template. For |
| | multi-homed SCTP associations, this |
| | SHOULD be the primary path endpoint |
| | address of the Collecting Process. |
| collectorTransportPort | The destination port on which this |
| | Message was received. Present only |
| | if this information is not available |
| | via the Export Session Details |
| | Options Template. |
| collectorTransportProtocol | The IP Protocol Identifier of the |
| | transport protocol used to transport |
| | this Message. Present only if this |
| | information is not available via the |
| | Export Session Details Options |
| | Template. |
| collectorProtocolVersion | The version of the export protocol |
| | used to transport this Message. |
| | Present only if necessary and if |
| | this information is not available |
| | via the Export Session Details |
| | Options Template. |
| collectorCertificate | The certificate used by the IPFIX |
| | Collecting Process that received |
| | this Message. Present only for |
| | Transport Sessions protected by TLS |
| | or DTLS. |
| exportSctpStreamId | The SCTP stream used to transport |
| | this Message. Present only if the |
| | Message was transported via SCTP. |
+----------------------------+--------------------------------------+
| | Present only for Collecting |
| | Processes with an IPv4 interface, |
| | and if this information is not |
| | available via the Export Session |
| | Details Options Template. For |
| | multi-homed SCTP associations, this |
| | SHOULD be the primary path endpoint |
| | address of the Collecting Process. |
| collectorIPv6Address | IPv6 address of the IPFIX Collecting |
| | Process that received this Message. |
| | Present only for Collecting |
| | Processes with an IPv6 interface, |
| | and if this information is not |
| | available via the Export Session |
| | Details Options Template. For |
| | multi-homed SCTP associations, this |
| | SHOULD be the primary path endpoint |
| | address of the Collecting Process. |
| collectorTransportPort | The destination port on which this |
| | Message was received. Present only |
| | if this information is not available |
| | via the Export Session Details |
| | Options Template. |
| collectorTransportProtocol | The IP Protocol Identifier of the |
| | transport protocol used to transport |
| | this Message. Present only if this |
| | information is not available via the |
| | Export Session Details Options |
| | Template. |
| collectorProtocolVersion | The version of the export protocol |
| | used to transport this Message. |
| | Present only if necessary and if |
| | this information is not available |
| | via the Export Session Details |
| | Options Template. |
| collectorCertificate | The certificate used by the IPFIX |
| | Collecting Process that received |
| | this Message. Present only for |
| | Transport Sessions protected by TLS |
| | or DTLS. |
| exportSctpStreamId | The SCTP stream used to transport |
| | this Message. Present only if the |
| | Message was transported via SCTP. |
+----------------------------+--------------------------------------+
The following Information Elements are used by the Options Templates in Section 8.1 to allow IPFIX Message streams to meet the requirements outlined above without extension of the protocol. IPFIX File Readers and Writers SHOULD support these Information Elements as defined below.
第8.1节中的选项模板使用以下信息元素，以允许IPFIX消息流满足上述要求，而无需扩展协议。IPFIX文件读取器和写入器应支持以下定义的信息元素。
In addition, IPFIX File Readers and Writers SHOULD support the Information Elements defined in [RFC5610] in order to support full self-description of Information Elements.
此外，IPFIX文件读取器和写入器应支持[RFC5610]中定义的信息元素，以支持信息元素的完整自描述。
Description: The absolute timestamp at which the data within the scope containing this Information Element was received by a Collecting Process. This Information Element SHOULD be bound to its containing IPFIX Message via IPFIX Options and the messageScope Information Element, as defined below.
描述：收集进程接收包含此信息元素的范围内的数据时的绝对时间戳。此信息元素应通过IPFIX选项和messageScope信息元素绑定到其包含的IPFIX消息，定义如下。
Abstract Data Type: dateTimeMilliseconds
抽象数据类型：DateTimeMillenses
ElementId: 258
元素ID:258
Status: current
状态：当前
Description: The full X.509 certificate, encoded in ASN.1 DER format, used by the Collector when IPFIX Messages were transmitted using TLS or DTLS. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element, or to its containing IPFIX Message via an options record and the messageScope Information Element.
描述：完整的X.509证书，以ASN.1 DER格式编码，在使用TLS或DTL传输IPFIX消息时由收集器使用。此信息元素应通过options记录和sessionScope信息元素绑定到其包含的IPFIX传输会话，或通过options记录和messageScope信息元素绑定到其包含的IPFIX消息。
Abstract Data Type: octetArray
抽象数据类型：Octeraray
ElementId: 274
元素ID:274
Status: current
状态：当前
Description: The full X.509 certificate, encoded in ASN.1 DER format, used by the Collector when IPFIX Messages were transmitted using TLS or DTLS. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and
描述：完整的X.509证书，以ASN.1 DER格式编码，在使用TLS或DTL传输IPFIX消息时由收集器使用。此信息元素应通过选项记录和绑定到其包含的IPFIX传输会话
the sessionScope Information Element, or to its containing IPFIX Message via an options record and the messageScope Information Element.
sessionScope信息元素，或通过options记录和messageScope信息元素发送到其包含的IPFIX消息。
Abstract Data Type: octetArray
抽象数据类型：Octeraray
ElementId: 275
元素ID:275
Status: current
状态：当前
Description: The value of the SCTP Stream Identifier used by the Exporting Process for exporting IPFIX Message data. This is carried in the Stream Identifier field of the header of the SCTP DATA chunk containing the IPFIX Message(s).
描述：导出进程用于导出IPFIX消息数据的SCTP流标识符的值。这在包含IPFIX消息的SCTP数据块头的流标识符字段中进行。
Abstract Data Type: unsigned16
抽象数据类型：unsigned16
Data Type Semantics: identifier
数据类型语义：标识符
ElementId: 259
元素ID:259
Status: current
状态：当前
Description: The absolute Export Time of the latest IPFIX Message within the scope containing this Information Element. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope Information Element.
描述：包含此信息元素的范围内最新IPFIX消息的绝对导出时间。此信息元素应通过IPFIX选项和sessionScope信息元素绑定到其包含的IPFIX传输会话。
Abstract Data Type: dateTimeSeconds
抽象数据类型：dateTimeSeconds
ElementId: 260
元素ID:260
Status: current
状态：当前
Units: seconds
单位：秒
Description: The latest absolute timestamp of the last packet within any Flow within the scope containing this Information Element, rounded up to the microsecond if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope
描述：包含此信息元素的范围内任何流中最后一个数据包的最新绝对时间戳，必要时四舍五入到微秒。此信息元素应通过IPFIX选项和sessionScope绑定到其包含的IPFIX传输会话
Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with microsecond-precision (or better) timestamp Information Elements.
信息元素。此信息元素应仅在包含具有微秒精度（或更好）时间戳信息元素的流记录的传输会话中使用。
Abstract Data Type: dateTimeMicroseconds
抽象数据类型：dateTimeMicroseconds
ElementId: 268
元素ID:268
Status: current
状态：当前
Units: microseconds
单位：微秒
Description: The latest absolute timestamp of the last packet within any Flow within the scope containing this Information Element, rounded up to the millisecond if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with millisecond-precision (or better) timestamp Information Elements.
描述：包含此信息元素的范围内任何流中最后一个数据包的最新绝对时间戳，必要时四舍五入到毫秒。此信息元素应通过IPFIX选项和sessionScope信息元素绑定到其包含的IPFIX传输会话。此信息元素应仅在包含具有毫秒精度（或更好）时间戳信息元素的流记录的传输会话中使用。
Abstract Data Type: dateTimeMilliseconds
抽象数据类型：DateTimeMillenses
ElementId: 269
元素ID:269
Status: current
状态：当前
Units: milliseconds
单位：毫秒
Description: The latest absolute timestamp of the last packet within any Flow within the scope containing this Information Element. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with nanosecond-precision timestamp Information Elements.
描述：包含此信息元素的范围内任何流中最后一个数据包的最新绝对时间戳。此信息元素应通过IPFIX选项和sessionScope信息元素绑定到其包含的IPFIX传输会话。此信息元素应仅在包含具有纳秒精度时间戳信息元素的流记录的传输会话中使用。
Abstract Data Type: dateTimeNanoseconds
抽象数据类型：dateTimeNanoseconds
ElementId: 270
元素ID:270
Status: current
状态：当前
Units: nanoseconds
单位：纳秒
Description: The latest absolute timestamp of the last packet within any Flow within the scope containing this Information Element, rounded up to the second if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope Information Element.
描述：包含此信息元素的范围内任何流中最后一个数据包的最新绝对时间戳，必要时四舍五入到第二个。此信息元素应通过IPFIX选项和sessionScope信息元素绑定到其包含的IPFIX传输会话。
Abstract Data Type: dateTimeSeconds
抽象数据类型：dateTimeSeconds
ElementId: 261
元素ID:261
Status: current
状态：当前
Units: seconds
单位：秒
Description: The MD5 checksum of the IPFIX Message containing this record. This Information Element SHOULD be bound to its containing IPFIX Message via an options record and the messageScope Information Element, as defined below, and SHOULD appear only once in a given IPFIX Message. To calculate the value of this Information Element, first buffer the containing IPFIX Message, setting the value of this Information Element to all zeroes. Then calculate the MD5 checksum of the resulting buffer as defined in [RFC1321], place the resulting value in this Information Element, and export the buffered message. This Information Element is intended as a simple checksum only; therefore collision resistance and algorithm agility are not required, and MD5 is an appropriate message digest.
描述：包含此记录的IPFIX消息的MD5校验和。此信息元素应通过选项记录和messageScope信息元素绑定到其包含的IPFIX消息，如下所述，并且在给定的IPFIX消息中仅出现一次。要计算此信息元素的值，请首先缓冲包含IPFIX消息的缓冲区，将此信息元素的值设置为全零。然后计算[RFC1321]中定义的结果缓冲区的MD5校验和，将结果值放入此信息元素中，并导出缓冲消息。此信息元素仅用作简单的校验和；因此，不需要抗冲突性和算法灵活性，MD5是一个合适的消息摘要。
Abstract Data Type: octetArray (16 bytes)
抽象数据类型：八位数组（16字节）
ElementId: 262
元素ID:262
Status: current
状态：当前
Reference: RFC 1321, The MD5 Message-Digest Algorithm [RFC1321]
参考文献：RFC1321，MD5消息摘要算法[RFC1321]
Description: The presence of this Information Element as scope in an Options Template signifies that the options described by the Template apply to the IPFIX Message that contains them. It is defined for general purpose message scoping of options, and proposed specifically to allow the attachment of checksum and collection information to a message via IPFIX Options. The value
描述：此信息元素作为作用域出现在选项模板中表示模板描述的选项适用于包含它们的IPFIX消息。它是为选项的通用消息范围定义的，并专门建议允许通过IPFIX选项将校验和和收集信息附加到消息中。价值
of this Information Element MUST be written as 0 by the File Writer or Exporting Process. The value of this Information Element MUST be ignored by the File Reader or the Collecting Process.
文件编写器或导出进程必须将此信息元素的写入为0。文件读取器或收集过程必须忽略此信息元素的值。
Abstract Data Type: unsigned8
抽象数据类型：unsigned8
ElementId: 263
元素ID:263
Status: current
状态：当前
Description: The absolute Export Time of the earliest IPFIX Message within the scope containing this Information Element. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element.
Description:包含此信息元素的范围内最早的IPFIX消息的绝对导出时间。此信息元素应通过options记录和sessionScope信息元素绑定到其包含的IPFIX传输会话。
Abstract Data Type: dateTimeSeconds
抽象数据类型：dateTimeSeconds
ElementId: 264
ElementId:264
Status: current
状态：当前
Units: seconds
单位：秒
Description: The earliest absolute timestamp of the first packet within any Flow within the scope containing this Information Element, rounded down to the microsecond if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with microsecond-precision (or better) timestamp Information Elements.
描述：包含此信息元素的范围内任何流中第一个数据包的最早绝对时间戳，必要时舍入到微秒。此信息元素应通过options记录和sessionScope信息元素绑定到其包含的IPFIX传输会话。此信息元素应仅在包含具有微秒精度（或更好）时间戳信息元素的流记录的传输会话中使用。
Abstract Data Type: dateTimeMicroseconds
抽象数据类型：dateTimeMicroseconds
ElementId: 271
元素ID:271
Status: current
状态：当前
Units: microseconds
单位：微秒
Description: The earliest absolute timestamp of the first packet within any Flow within the scope containing this Information Element, rounded down to the millisecond if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with millisecond-precision (or better) timestamp Information Elements.
描述：包含此信息元素的范围内任何流中第一个数据包的最早绝对时间戳，如有必要，舍入到毫秒。此信息元素应通过options记录和sessionScope信息元素绑定到其包含的IPFIX传输会话。此信息元素应仅在包含具有毫秒精度（或更好）时间戳信息元素的流记录的传输会话中使用。
Abstract Data Type: dateTimeMilliseconds
抽象数据类型：DateTimeMillenses
ElementId: 272
元素ID:272
Status: current
状态：当前
Units: milliseconds
单位：毫秒
Description: The earliest absolute timestamp of the first packet within any Flow within the scope containing this Information Element. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with nanosecond-precision timestamp Information Elements.
描述：包含此信息元素的范围内任何流中第一个数据包的最早绝对时间戳。此信息元素应通过options记录和sessionScope信息元素绑定到其包含的IPFIX传输会话。此信息元素应仅在包含具有纳秒精度时间戳信息元素的流记录的传输会话中使用。
Abstract Data Type: dateTimeNanoseconds
抽象数据类型：dateTimeNanoseconds
ElementId: 273
元素ID:273
Status: current
状态：当前
Units: nanoseconds
单位：纳秒
Description: The earliest absolute timestamp of the first packet within any Flow within the scope containing this Information Element, rounded down to the second if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element.
描述：包含此信息元素的范围内任何流中第一个数据包的最早绝对时间戳，必要时向下舍入到第二个数据包。此信息元素应通过options记录和sessionScope信息元素绑定到其包含的IPFIX传输会话。
Abstract Data Type: dateTimeSeconds
抽象数据类型：dateTimeSeconds
ElementId: 265
元素ID:265
Status: current
状态：当前
Units: seconds
单位：秒
Description: This Information Element is used to encapsulate non-IPFIX data into an IPFIX Message stream, for the purpose of allowing a non-IPFIX data processor to store a data stream inline within an IPFIX File. A Collecting Process or File Writer MUST NOT try to interpret this binary data. This Information Element differs from paddingOctets as its contents are meaningful in some non-IPFIX context, while the contents of paddingOctets MUST be 0x00 and are intended only for Information Element alignment.
描述：此信息元素用于将非IPFIX数据封装到IPFIX消息流中，以允许非IPFIX数据处理器在IPFIX文件中内联存储数据流。收集进程或文件编写器不得尝试解释此二进制数据。此信息元素不同于paddingOctets，因为其内容在某些非IPFIX上下文中有意义，而paddingOctets的内容必须为0x00，并且仅用于信息元素对齐。
Abstract Data Type: octetArray
抽象数据类型：Octeraray
ElementId: 266
元素ID:266
Status: current
状态：当前
Description: The presence of this Information Element as scope in an Options Template signifies that the options described by the Template apply to the IPFIX Transport Session that contains them. Note that as all options are implicitly scoped to Transport Session and Observation Domain, this Information Element is equivalent to a "null" scope. It is defined for general purpose session scoping of options, and proposed specifically to allow the attachment of time window and collection information to an IPFIX File via IPFIX Options. The value of this Information Element MUST be written as 0 by the File Writer or Exporting Process. The value of this Information Element MUST be ignored by the File Reader or the Collecting Process.
描述：此信息元素作为作用域出现在选项模板中表示模板描述的选项适用于包含它们的IPFIX传输会话。请注意，由于所有选项都隐式地作用于传输会话和观察域，因此此信息元素相当于“null”作用域。它是为选项的通用会话范围定义的，并专门建议允许通过IPFIX选项将时间窗口和集合信息附加到IPFIX文件。文件编写器或导出进程必须将此信息元素的值写入为0。文件读取器或收集过程必须忽略此信息元素的值。
Abstract Data Type: unsigned8
抽象数据类型：unsigned8
ElementId: 267
元素ID:267
Status: current
状态：当前
In order to ensure the integrity of IPFIX Files and the identity of IPFIX File Writers, File Writers and File Readers SHOULD provide for an interoperable and easily implemented method for signing IPFIX Files, and verifying those signatures. This section specifies method via CMS detached signatures.
为了确保IPFIX文件的完整性和IPFIX文件编写器的身份，文件编写器和文件读取器应提供一种互操作且易于实现的方法，用于对IPFIX文件进行签名和验证这些签名。本节通过CMS分离签名指定方法。
Note that while CMS specifies an encapsulation format that can be used for encryption as well as signing, no method is specified for encapsulation for confidentiality protection. It is assumed that application-specific or process-specific requirements outweigh the need for interoperability for encrypted files.
请注意，尽管CMS指定了一种可用于加密和签名的封装格式，但没有为保密性保护的封装指定任何方法。假定特定于应用程序或特定于流程的要求超过了加密文件互操作性的需要。
The Cryptographic Message Syntax (CMS) [RFC3852] defines an encapsulation syntax for data protection, used to digitally sign, authenticate, or encrypt arbitrary message content. CMS can also be used to create detached signatures, in which the signature is stored in a separate file. This arrangement maximizes interoperability, as File Readers that are not aware of CMS detached signatures and have no requirement for them can simply ignore them; the content of the IPFIX File itself is unchanged by the signature.
加密消息语法（CMS）[RFC3852]定义了用于数据保护的封装语法，用于对任意消息内容进行数字签名、验证或加密。CMS还可用于创建分离的签名，其中签名存储在单独的文件中。这种安排最大限度地提高了互操作性，因为不知道CMS分离签名并且不需要签名的文件读取器可以简单地忽略它们；IPFIX文件本身的内容不会因签名而改变。
The detached signature file for an IPFIX File SHOULD be stored, transported, or otherwise made available (e.g., by FTP or HTTP) alongside the signed IPFIX File, with the same filename as the IPFIX File, except that the file extension ".p7s" is added to the end, conforming to the naming convention in [RFC3851].
IPFIX文件的分离签名文件应与已签名的IPFIX文件一起存储、传输或以其他方式（例如，通过FTP或HTTP）使用与IPFIX文件相同的文件名，但文件扩展名“.p7s”添加到末尾，符合[RFC3851]中的命名约定。
Within the detached signature, the CMS ContentInfo type MUST always be present, and it MUST encapsulate the CMS SignedData content type, which in turn MUST NOT encapsulate the signed IPFIX File content. The CMS detached signature is summarized as follows:
在分离的签名中，CMS ContentInfo类型必须始终存在，并且它必须封装CMS SignedData内容类型，而CMS SignedData内容类型又不能封装已签名的IPFIX文件内容。CMS分离签名总结如下：
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData
}
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData
}
SignedData {
version CMSVersion, -- Always set to 3
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- File Writer certificate(s)
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one signer
}
SignedData {
version CMSVersion, -- Always set to 3
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- File Writer certificate(s)
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one signer
}
SignerInfo {
version CMSVersion, -- Always set to 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes
}
SignerInfo {
version CMSVersion, -- Always set to 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes
}
EncapsulatedContentInfo {
eContentType id-data, -- (1.2.840.113549.1.7.1)
eContent OCTET STRING -- Always absent
}
EncapsulatedContentInfo {
eContentType id-data, -- (1.2.840.113549.1.7.1)
eContent OCTET STRING -- Always absent
}
The details of the contents of each CMS encapsulation are detailed in the subsections below.
每个CMS封装内容的详细信息在下面的小节中详细说明。
[RFC3852] requires the outer-most encapsulation to be ContentInfo; the fields of ContentInfo are as follows:
[RFC3852]要求最外层的封装为ContentInfo；ContentInfo的字段如下所示：
contentType: the type of the associated content. For the detached signature file, the encapsulated type is always SignedData, so the id-signedData (1.2.840.113549.1.7.2) object identifier MUST be present in this field.
contentType：关联内容的类型。对于分离的签名文件，封装类型始终为SignedData，因此此字段中必须存在id SignedData（1.2.840.113549.1.7.2）对象标识符。
content: a SignedData content, detailed in Section 9.1.2.
内容：签名数据内容，详见第9.1.2节。
The SignedData content type contains the signature of the IPFIX File and information to aid in validation; the fields of SignedData are as follows:
SignedData内容类型包含IPFIX文件的签名和有助于验证的信息；SignedData的字段如下所示：
version: MUST be 3.
版本：必须是3。
digestAlgorithms: a collection of one-way hash function identifiers. It MUST contain the identifier used by the File Writer to generate the digital signature.
digestAlgorithms：单向散列函数标识符的集合。它必须包含文件编写器用于生成数字签名的标识符。
encapContentInfo: the signed content, including a content type identifier. Since a detached signature is being created, it does not encapsulate the IPFIX File. The EncapsulatedContentInfo is detailed in Section 9.1.4.
encapContentInfo：已签名的内容，包括内容类型标识符。由于正在创建分离的签名，因此它不会封装IPFIX文件。封装的内容信息详见第9.1.4节。
certificates: a collection of certificates. It SHOULD include the X.509 certificate needed to validate the digital signature file. Certification Authority (CA) and File Writer certificates MUST conform to the certificate profile specified in [RFC5280].
证书：证书的集合。它应该包括验证数字签名文件所需的X.509证书。证书颁发机构（CA）和文件编写器证书必须符合[RFC5280]中指定的证书配置文件。
crls: an optional collection of certificate revocation lists (CRLs). It SHOULD NOT contain any CRLs; any CRLs that are present MUST conform to the certificate profile specified in [RFC5280].
crls：证书吊销列表（CRL）的可选集合。不应包含任何CRL；存在的任何CRL必须符合[RFC5280]中指定的证书配置文件。
signerInfos: a collection of per-signer information; this identifies the File Writer. More than one SignerInfo MAY appear to facilitate transitions between keys or algorithms. The SignerInfo type is detailed in Section 9.1.3.
signerInfos：每个签名者信息的集合；这将标识文件编写器。可能会出现多个SignerInfo来促进键或算法之间的转换。签名信息类型详见第9.1.3节。
The SignerInfo type identifies the File Writer; the fields of SignerInfo are as follows:
SignerInfo类型标识文件编写器；SignerInfo的字段如下所示：
version: MUST be 3.
版本：必须是3。
sid: identifies the File Writer's public key. This identifier MUST match the value included in the subjectKeyIdentifier certificate extension on the File Writer's X.509 certificate.
sid：标识文件编写器的公钥。此标识符必须与文件编写器的X.509证书上的subjectKeyIdentifier证书扩展名中包含的值匹配。
digestAlgorithm: identifies the one-way hash function and associated parameters used to generate the signature.
digestAlgorithm：标识用于生成签名的单向哈希函数和相关参数。
signedAttrs: an optional set of attributes that are signed along with the content.
signedAttrs：随内容一起签名的可选属性集。
digestAlgorithm: identifies the digital signature algorithm and associated parameters used to generate the signature.
digestAlgorithm：标识用于生成签名的数字签名算法和相关参数。
signature: the digital signature of the associated file.
签名：关联文件的数字签名。
unsignedAttrs: an optional set of attributes that are not signed.
unsignedAttrs：未签名的可选属性集。
The EncapsulatedContentInfo structure contains a content type identifier. Since a detached signature is being created, it does not encapsulate the IPFIX File. The fields of EncapsulatedContentInfo are as follows:
封装的ContentInfo结构包含内容类型标识符。由于正在创建分离的签名，因此它不会封装IPFIX文件。封装的ContentInfo的字段如下所示：
eContentType: an object identifier that uniquely specifies the content type. The content type associated with IPFIX File MUST be id-data (1.2.840.113549.1.7.1).
eContentType：唯一指定内容类型的对象标识符。与IPFIX文件关联的内容类型必须是id数据（1.2.840.113549.1.7.1）。
eContent: an optional field containing the signed content. Since this is a detached signature, eContent MUST be absent.
eContent：包含已签名内容的可选字段。因为这是一个分离的签名，所以eContent必须不存在。
Note that single bit errors in the encrypted data stream can result in larger errors in the decrypted stream, depending on the encryption scheme used.
请注意，根据所使用的加密方案，加密数据流中的单位错误可能导致解密数据流中更大的错误。
In applications (e.g., archival storage) in which error resilience is very important, File Writers SHOULD use an encryption scheme that can resynchronize after bit errors. A common example is a block cipher in CBC (Cipher Block Chaining) mode. In this case, File Writers MAY also use the Message Checksum Options Template to attach a checksum to each IPFIX Message in the IPFIX File, in order to support the recognition of errors in the decrypted data.
在错误恢复能力非常重要的应用程序（例如，存档存储）中，文件编写器应该使用一种加密方案，该方案可以在发生位错误后重新同步。一个常见的例子是CBC（密码块链接）模式下的分组密码。在这种情况下，文件编写器还可以使用消息校验和选项模板将校验和附加到IPFIX文件中的每个IPFIX消息，以支持识别解密数据中的错误。
Network traffic measurement data is generally highly compressible. IPFIX Templates tend to increase the information content per record by not requiring the export of irrelevant or non-present fields in records, and the technique described in [RFC5473] also reduces the export of redundant information. However, even with these techniques, generalized compression can decrease storage requirements significantly; therefore, IPFIX File Writers and File Readers SHOULD support compression as described in this section.
网络流量测量数据通常具有高度可压缩性。IPFIX模板通过不需要导出记录中不相关或不存在的字段来增加每条记录的信息内容，[RFC5473]中描述的技术也减少了冗余信息的导出。然而，即使使用这些技术，广义压缩也可以显著降低存储需求；因此，IPFIX文件编写器和文件读取器应支持本节所述的压缩。
IPFIX Files support two compression encapsulation formats: bzip2 [bzip2] and gzip [RFC1952]. bzip2 provides better compression than gzip and, as a block compression algorithm, better error recovery characteristics, at the expense of slower compression. gzip is potentially a better choice when compression time is an issue. These two algorithms and encapsulation formats were chosen for ubiquity and ease of implementation.
IPFIX文件支持两种压缩封装格式：bzip2[bzip2]和gzip[RFC1952]。bzip2提供了比gzip更好的压缩，并且作为一种块压缩算法，具有更好的错误恢复特性，但以较慢的压缩速度为代价。当压缩时间是一个问题时，gzip可能是一个更好的选择。选择这两种算法和封装格式是为了普遍性和易于实现。
IPFIX File Readers and Writers supporting compression MUST support bzip2, and SHOULD support gzip.
支持压缩的IPFIX文件读取器和写入器必须支持bzip2，并且应该支持gzip。
bzip2, gzip, and uncompressed IPFIX Files have distinct magic numbers. IPFIX File Readers SHOULD use these magic numbers to determine what compression, if any, is in use for an IPFIX File, and invoke the proper decompression. bzip2 files are identified by the initial three-octet string 0x42, 0x5A, 0x68 ("BZh"). gzip files are identified by the initial two-octet string 0x1F, 0x8B. IPFIX Files are identified by the initial two-octet string 0x00, 0x0A; these are the version bytes of the first IPFIX Message header in the File.
bzip2、gzip和未压缩的IPFIX文件具有不同的幻数。IPFIX文件读取器应该使用这些神奇的数字来确定IPFIX文件正在使用什么压缩（如果有的话），并调用适当的解压缩。bzip2文件由最初的三个八位字节字符串0x42、0x5A、0x68（“BZh”）标识。gzip文件由最初的两个八位字节字符串0x1F、0x8B标识。IPFIX文件由最初的两个八位字节字符串0x00、0x0A标识；这些是文件中第一个IPFIX消息头的版本字节。
Compression at the file level, like encryption, is not particularly resilient to errors; in the worst case, a single bit error in a stream-compressed file could result in the loss of the entire file.
文件级别的压缩，如加密，对错误的恢复能力不是特别强；在最坏的情况下，流压缩文件中的一个位错误可能会导致整个文件丢失。
Since block compression algorithms that support the identification and isolation of blocks containing errors limit the impact of errors on the recoverability of compressed data, the use of bzip2 in applications where error resilience is important is RECOMMENDED.
由于支持识别和隔离包含错误的块的块压缩算法限制了错误对压缩数据可恢复性的影响，因此建议在错误恢复能力非常重要的应用中使用bzip2。
Since the block boundary of a block-compressed IPFIX File may fall in the middle of an IPFIX Message, resynchronization of an IPFIX Message stream by a File Reader after a compression error requires some care. The beginning of an IPFIX Message may be identified by its header signature (the Version field of the Message Header, 0x00 0x0A, followed by a 16-bit Message Length), but simply searching for the first occurrence of the Version field is insufficient, since these two bytes may occur in valid IPFIX Template or Data Sets.
由于块压缩IPFIX文件的块边界可能落在IPFIX消息的中间，因此，在压缩错误之后，由文件读取器重新同步IPFIX消息流需要一些关心。IPFIX消息的开头可以通过消息头签名（消息头的版本字段0x00 0x0A，后跟16位消息长度）来标识，但仅仅搜索版本字段的第一次出现是不够的，因为这两个字节可能出现在有效的IPFIX模板或数据集中。
Therefore, we specify the following algorithm for File Readers to resynchronize an IPFIX Message Stream after skipping a compressed block containing errors:
因此，我们为文件读取器指定以下算法，以便在跳过包含错误的压缩块后重新同步IPFIX消息流：
1. Search after the error for the first occurrence of the octet string 0x00, 0x0A (the IPFIX Message Header Version field).
1. 在错误后搜索第一个出现的八位字节字符串0x00、0x0A（IPFIX消息头版本字段）。
2. Treat this field as the beginning of a candidate IPFIX Message. Read the two bytes following the Version field as a Message Length, and seek to that offset from the beginning of the candidate IPFIX Message.
2. 将此字段视为候选IPFIX消息的开头。读取Version字段后面的两个字节作为消息长度，并从候选IPFIX消息的开头开始寻找该偏移量。
3. If the first two octets after the candidate IPFIX Message are 0x00, 0x0A (i.e., the IPFIX Message Header Version field of the next message in the stream), or if the end-of-file is reached precisely at the end of the candidate IPFIX Message, presume that the candidate IPFIX Message is valid, and begin reading the IPFIX File from the start of the candidate IPFIX Message.
3. 如果候选IPFIX消息后的前两个八位字节为0x00、0x0A（即流中下一条消息的IPFIX消息头版本字段），或者如果文件结尾正好在候选IPFIX消息的结尾处，则假定候选IPFIX消息有效，并从候选IPFIX消息的开头开始读取IPFIX文件。
4. If not, or if the seek reaches end-of-file or another block containing errors before finding the end of the candidate message, go back to step 1, starting the search two bytes from the start of the candidate IPFIX Message.
4. 如果没有，或者如果搜索在找到候选消息结尾之前到达文件结尾或包含错误的另一个块，请返回步骤1，从候选IPFIX消息开始两个字节开始搜索。
The algorithm above will improperly identify a non-message as a message approximately 1 in 2^32 times, assuming random IPFIX data. It may be expanded to consider multiple candidate IPFIX Messages in order to increase reliability.
假设IPFIX数据为随机数据，上述算法将不正确地将非消息识别为大约1/2^32次的消息。它可以扩展以考虑多个候选IPFIX消息，以提高可靠性。
In applications (e.g., archival storage) in which error resilience is very important, File Writers SHOULD use block compression algorithms, and MAY attempt to align IPFIX Messages within compression blocks to ease resynchronization after errors. File Readers SHOULD use the resynchronization algorithm above to minimize data loss due to compression errors.
在错误恢复能力非常重要的应用程序（例如，存档存储）中，文件编写器应使用块压缩算法，并可尝试在压缩块内对齐IPFIX消息，以便于出错后重新同步。文件读取器应使用上述重新同步算法，以最大限度地减少由于压缩错误导致的数据丢失。
This section describes methods for integrating IPFIX File data with other file formats.
本节介绍将IPFIX文件数据与其他文件格式集成的方法。
At times, it may be useful to export or store non-IPFIX data inline in an IPFIX File or Message stream. To do this cleanly, this data must be encapsulated into IPFIX Messages so that an IPFIX File Reader or Collecting Process can handle it without any need to interpret it. At the same time, this data must not be changed during transmission or storage. The opaqueOctets Information Element, as defined in Section 8.2.17, is provided for this encapsulation.
有时，在IPFIX文件或消息流中内联导出或存储非IPFIX数据可能很有用。要干净地做到这一点，必须将此数据封装到IPFIX消息中，以便IPFIX文件读取器或收集进程可以处理它，而无需对其进行任何解释。同时，在传输或存储期间不得更改此数据。第8.2.17节中定义的不透明八位字节信息元素用于此封装。
Processing the encapsulated non-IPFIX data is left to a separate processing mechanisms that can identify encapsulated non-IPFIX data in an IPFIX Message Stream, but need not have any other IPFIX handling capability, except the ability to skip over all IPFIX Messages that do not encapsulate non-IPFIX data.
处理封装的非IPFIX数据留给一个单独的处理机制，该机制可以在IPFIX消息流中识别封装的非IPFIX数据，但不需要具有任何其他IPFIX处理能力，除了跳过所有未封装非IPFIX数据的IPFIX消息的能力。
The Message Checksum Options Template, described in Section 8.1.1, may be used as a uniform mechanism to identify errors within encapsulated data.
第8.1.1节中描述的消息校验和选项模板可用作识别封装数据中错误的统一机制。
Note that this mechanism can only encapsulate data objects up to 65,515 octets in length. If the space available in one IPFIX Message is not enough for the amount of data to be encapsulated, then the data must be broken into smaller segments that are encapsulated into consecutive IPFIX Messages. Any additional structuring or semantics of the raw data is outside the scope of IPFIX and must be implemented within the encapsulated binary data itself. Furthermore, the raw encapsulated data cannot be assumed by an IPFIX File Reader to have any specific format.
请注意，此机制只能封装长度不超过65515个八位字节的数据对象。如果一条IPFIX消息中的可用空间不足以封装数据量，则必须将数据分成更小的段，然后封装到连续的IPFIX消息中。原始数据的任何附加结构或语义都不在IPFIX的范围内，必须在封装的二进制数据本身中实现。此外，IPFIX文件读取器不能假定原始封装数据具有任何特定格式。
Consequently, it may also be useful to reverse the encapsulation, that is, to export or store IPFIX data inline within a non-IPFIX File or data stream. This makes sense when the other file format is not compatible with the encapsulation described above in Section 11.1. Generally speaking, the encapsulation here will be specific to the format of the containing file. For example, IPFIX Files may be embedded in XML elements using hex or Base64 encoding, or in raw binary files using start and end delimiters or some form of run-length encoding. As there are as many potential encapsulations here as there are potential file formats, the specifics of each are out of scope for this specification.
因此，反向封装也可能有用，即在非IPFIX文件或数据流中内联导出或存储IPFIX数据。当其他文件格式与第11.1节中描述的封装不兼容时，这是有意义的。一般来说，这里的封装将特定于包含文件的格式。例如，IPFIX文件可以使用十六进制或Base64编码嵌入到XML元素中，或者使用开始和结束分隔符或某种形式的运行长度编码嵌入到原始二进制文件中。由于这里潜在的封装和潜在的文件格式一样多，因此每个封装的细节都超出了本规范的范围。
The Security Considerations section of [RFC5101], on which the IPFIX File format is based, is largely concerned with the proper application of TLS and DTLS to ensure confidentiality and integrity when exporting IPFIX Messages. By analogy, this document specifies the use of CMS [RFC3852] detached signatures to provide equivalent integrity protection to TLS and DTLS in Section 9.1. However, aside from merely applying CMS for signatures, there are several security issues which much be considered in certain circumstances; these are covered in the subsections below.
[RFC5101]的安全注意事项部分是IPFIX文件格式的基础，主要涉及TLS和DTL的正确应用，以确保导出IPFIX消息时的机密性和完整性。类似地，本文件规定使用CMS[RFC3852]分离签名，以在第9.1节中为TLS和DTL提供等效完整性保护。然而，除了仅将CMS应用于签名之外，在某些情况下还需要考虑一些安全问题；这些内容在下面的小节中介绍。
The underlying protocol used to exchange the information that will be stored using the format proposed in this document must as well apply appropriate procedures to guarantee the integrity and confidentiality of the exported information. Such issues are addressed in [RFC5101]. Specifically, IPFIX Files that store data taken from an IPFIX Collecting Process using TLS or DTLS for transport security SHOULD be signed as in Section 9.1 and SHOULD be encrypted out of band; storage of such flow data without encryption may present a potential breach of confidentiality. Conversely, flow data considered sensitive enough to require encryption in storage that is later transmitted using IPFIX SHOULD be transmitted using TLS or DTLS for transport security.
用于交换将使用本文件中提议的格式存储的信息的基础协议也必须应用适当的程序，以保证导出信息的完整性和机密性。此类问题在[RFC5101]中有说明。具体而言，存储从使用TLS或DTL进行传输安全的IPFIX收集过程中获取的数据的IPFIX文件应按照第9.1节的规定进行签名，并应在带外加密；在未加密的情况下存储此类流数据可能会违反保密性。相反，被认为敏感到需要在存储中加密的流数据（稍后使用IPFIX传输）应使用TLS或DTL传输，以确保传输安全。
Note that while both TLS and CMS provide the ability to sign an IPFIX Transport Session or an IPFIX File, there exists no method for protecting data integrity end-to-end in the case in which a Collecting Process is collocated with a File Writer. The channel between the Exporting Process to Collecting Process using IPFIX is signed by the Exporting Process key and protected via TLS and DTLS, while the File is signed by the File Writer key and protected via CMS. The identity of the Exporting Process is not asserted in the file, and the records may be modified between the Collecting Process and the File Writer.
请注意，虽然TLS和CMS都提供对IPFIX传输会话或IPFIX文件进行签名的功能，但在收集进程与文件写入程序并置的情况下，不存在端到端保护数据完整性的方法。使用IPFIX的导出进程到收集进程之间的通道由导出进程密钥签名并通过TLS和DTLS进行保护，而文件由文件编写器密钥签名并通过CMS进行保护。导出进程的标识不会在文件中声明，并且可以在收集进程和文件编写器之间修改记录。
There are two potential ways to address this issue. The first is by fiat, and is appropriate only when the application allows the Collecting-Process-to-File-Writer channel to be trusted. In this case, the File Writer's signature is an implicit assertion that the channel to the Exporting Process was protected, that the Exporting Process's signature was verified, and that the data was not changed after collection. For this to work, a File Writer collocated with a Collecting Process SHOULD NOT sign a File as specified in Section 9.1 unless the Transport Session over which the data was exported was protected via TLS or DTLS, and the Collecting Process positively identified the Exporting Process by its certificate. The File Writer SHOULD include the Exporting Process and Collecting Process certificates within the File using the Export Session Detail Options Template in Section 8.1.3 or the Message Detail Options Template in Section 8.1.4 to allow for later verification.
有两种可能的方法来解决这个问题。第一种是通过fiat进行的，并且仅当应用程序允许信任收集进程到文件编写器通道时才适用。在这种情况下，文件编写器的签名是一个隐式断言，即导出进程的通道受到保护，导出进程的签名得到验证，并且数据在收集后没有更改。为此，与收集进程并置的文件编写器不应按照第9.1节的规定对文件进行签名，除非导出数据的传输会话通过TLS或DTL进行保护，并且收集进程通过其证书对导出进程进行了明确标识。文件编写器应使用第8.1.3节中的导出会话详细选项模板或第8.1.4节中的消息详细选项模板将导出过程和收集过程证书包含在文件中，以便以后进行验证。
In situations in which the Collecting Process and/or File Writer cannot be trusted, end-to-end integrity can then be approximated by collocating the File Writer with the Metering Process, and removing the IPFIX protocol completely from the chain. In this case, the File
在收集过程和/或文件编写器不可信的情况下，通过将文件编写器与计量过程并置，并从链中完全删除IPFIX协议，可以近似实现端到端的完整性。在本例中，文件
Writer's signature is an implicit assertion that the Metering Process is identified and is not tampering with the information as observed on the wire.
Writer的签名是一种隐式断言，表明计量过程已被识别，并且未篡改在线观察到的信息。
Verification of these trust relationships is out of scope for this document, and should be considered on a per-implementation basis.
这些信任关系的验证不在本文档的范围内，应在每个实施的基础上进行考虑。
Note that when encrypting files for archival storage, the cryptographic strength is dependent on the length of time over which archival data is expected to be kept. Long-term storage may require re-application of cryptographic protection, periodically resigning and reencrypting files with stronger keys. In this case, it is recommended that the existing signed and/or encypted data be encapsulated within newer, stronger protection. See [RFC4810] for a discussion of this issue.
请注意，在为存档存储加密文件时，加密强度取决于存档数据预计保留的时间长度。长期存储可能需要重新应用加密保护，定期调整并重新加密具有更强密钥的文件。在这种情况下，建议将现有的签名和/或加密数据封装在更新、更强的保护中。有关此问题的讨论，请参见[RFC4810]。
This document specifies the creation of several new IPFIX Information Elements in the IPFIX Information Element registry located at http://www.iana.org, as defined in Section 8.2 above. IANA has assigned the following Information Element numbers for their respective Information Elements as specified below:
本文档指定在位于的IPFIX信息元素注册表中创建几个新的IPFIX信息元素http://www.iana.org，如上文第8.2节所定义。IANA为其各自的信息元素分配了以下信息元素编号，具体如下：
o Information Element number 258 for the collectionTimeMilliseconds Information Element.
o CollectionTimeMillicles信息元素的信息元素编号258。
o Information Element number 274 for the collectorCertificate Information Element.
o collectorCertificate信息元素的信息元素编号274。
o Information Element number 275 for the exporterCertificate Information Element.
o exporterCertificate信息元素的信息元素编号275。
o Information Element number 259 for the exportSctpStreamId Information Element.
o exportSctpStreamId信息元素的信息元素编号259。
o Information Element number 260 for the maxExportSeconds Information Element.
o maxExportSeconds信息元素的信息元素编号260。
o Information Element number 268 for the maxFlowEndMicroseconds Information Element.
o maxFlowEndMicroseconds信息元素的信息元素编号268。
o Information Element number 269 for the maxFlowEndMilliseconds Information Element.
o MaxFlowEndMillicles信息元素的信息元素编号269。
o Information Element number 270 for the maxFlowEndNanoseconds Information Element.
o maxFlowEndNanoseconds信息元素的信息元素编号270。
o Information Element number 261 for the maxFlowEndSeconds Information Element.
o maxFlowEndSeconds信息元素的信息元素编号261。
o Information Element number 262 for the messageMD5Checksum Information Element.
o messageMD5Checksum信息元素的信息元素编号262。
o Information Element number 263 for the messageScope Information Element.
o messageScope信息元素的信息元素编号263。
o Information Element number 264 for the minExportSeconds Information Element.
o minExportSeconds信息元素的信息元素编号264。
o Information Element number 271 for the minFlowStartMicroseconds Information Element.
o minFlowStartMicroseconds信息元素的信息元素编号271。
o Information Element number 272 for the minFlowStartMilliseconds Information Element.
o minFlowStartMilliseconds信息元素的信息元素编号272。
o Information Element number 273 for the minFlowStartNanoseconds Information Element.
o minFlowStartNanoseconds信息元素的信息元素编号273。
o Information Element number 265 for the minFlowStartSeconds Information Element.
o MinFlowStartSecond信息元素的信息元素编号265。
o Information Element number 266 for the opaqueOctets Information Element.
o 用于不透明八位字节信息元素的信息元素编号266。
o Information Element number 267 for the sessionScope Information Element.
o sessionScope信息元素的信息元素编号267。
IANA has created the media type application/ipfix for IPFIX data, as described by the following registration information:
IANA已为ipfix数据创建了媒体类型应用程序/ipfix，如下注册信息所述：
Type name: application
类型名称：应用程序
Subtype name: ipfix
子类型名称：ipfix
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: IPFIX Files are binary, and therefore must be encoded in non-binary contexts.
编码注意事项：IPFIX文件是二进制文件，因此必须在非二进制上下文中进行编码。
Security considerations: See the Security Considerations (Section 12) of RFC 5655, and the Security Considerations of [RFC5101].
安全注意事项：参见RFC 5655的安全注意事项（第12节）和[RFC5101]的安全注意事项。
Interoperability considerations: See the "Detailed Specification" (Section 7) of RFC 5655. The format is designed to be broadly interoperable, as any valid stream of IPFIX Messages over any transport specified in [RFC5101] MUST be recognizable as a valid IPFIX File.
互操作性注意事项：参见RFC 5655的“详细规范”（第7节）。该格式设计为可广泛互操作，因为[RFC5101]中指定的任何传输上的任何有效IPFIX消息流必须可识别为有效的IPFIX文件。
Published specification: RFC 5655, especially Section 7, and [RFC5101].
已发布规范：RFC 5655，特别是第7节和[RFC5101]。
Applications that use this media type: Various IPFIX implementations (see [RFC5153]) support the construction of IPFIX File Readers and Writers.
使用此媒体类型的应用程序：各种IPFIX实现（请参见[RFC5153]）支持构建IPFIX文件读取器和写入器。
Additional information:
其他信息：
Magic number(s): None, although the first two bytes of any IPFIX File are the first two bytes of a message header, the Version field, which as of [RFC5101] are always 10 in network byte order: 0x00, 0x0A.
幻数：无，尽管任何IPFIX文件的前两个字节是消息头的前两个字节，但版本字段（自[RFC5101]起）始终为10，按网络字节顺序排列：0x00，0x0A。
File extension(s): .ipfix
文件扩展名：.ipfix
Macintosh file type code(s): none
Macintosh文件类型代码：无
Person & email address to contact for further information: Brian Trammell <brian.trammell@hitachi-eu.com> for the authors of RFC 5655; Nevil Brownlee <n.brownlee@auckland.ac.nz> for the IPFIX Working Group.
联系人和电子邮件地址，以获取更多信息：Brian Trammell<Brian。trammell@hitachi-eu.com>为RFC5655的作者；内维尔·布朗利。brownlee@auckland.ac.nz>对于IPFIX工作组。
Intended usage: LIMITED USE
预期用途：有限用途
Restrictions on usage: none
使用限制：无
Change controller: Brian Trammell <brian.trammell@hitachi-eu.com> for the authors of RFC 5655; Nevil Brownlee <n.brownlee@auckland.ac.nz> for the IPFIX Working Group.
变更控制员：布莱恩·特拉梅尔<布莱恩。trammell@hitachi-eu.com>为RFC5655的作者；内维尔·布朗利。brownlee@auckland.ac.nz>对于IPFIX工作组。
Thanks to Maurizio Molina, Tom Kosnar, and Andreas Kind for technical assistance with the requirements for a standard flow storage format. Thanks to Benoit Claise, Paul Aitken, Andrew Johnson, Gerhard Muenz, and Nevil Brownlee for their reviews and feedback. Thanks to Pasi Eronen for pointing out [RFC5485], and Russ Housley for writing it;
感谢Maurizio Molina、Tom Kosnar和Andreas Kind在标准流存储格式要求方面提供的技术援助。感谢Benoit Claise、Paul Aitken、Andrew Johnson、Gerhard Muenz和Nevil Brownlee的评论和反馈。感谢Pasi Eronen指出[RFC5485]，感谢Russ Housley撰写了这篇文章；
it specifies a detached signature format, from which Section 9.1 is largely drawn. Thanks to the PRISM project for its support of this work.
它指定了一种分离的签名格式，第9.1节主要是从该格式中提取的。感谢PRISM项目对这项工作的支持。
[RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101]Claise，B.，“用于交换IP流量信息的IP流量信息导出（IPFIX）协议规范”，RFC 5101，2008年1月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102]Quitek，J.，Bryant，S.，Claise，B.，Aitken，P.，和J.Meyer，“IP流信息导出的信息模型”，RFC 5102，2008年1月。
[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月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. Randers-Pehrson, "GZIP file format specification version 4.3", RFC 1952, May 1996.
[RFC1952]Deutsch，P.，Gailly，J-L.，Adler，M.，Deutsch，L.，和G.Randers Pehrson，“GZIP文件格式规范版本4.3”，RFC 1952，1996年5月。
[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月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852]Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
[RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term Archive Service Requirements", RFC 4810, March 2007.
[RFC4810]Wallace，C.，Pordesch，U.，和R.Brandner，“长期档案服务要求”，RFC 48102007年3月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[bzip2] Seward, J., "bzip2 (http://www.bzip.org/)", March 2008.
[bzip2]苏厄德，J.，“bzip2(http://www.bzip.org/)“，2008年3月。
[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., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954]Claise，B.，“Cisco Systems NetFlow服务导出版本9”，RFC 3954，2004年10月。
[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月。
[SAINT2007] Trammell, B., Boschi, E., Mark, L., and T. Zseby, "Requirements for a standardized flow storage solution", in Proceedings of the SAINT 2007 workshop on Internet Measurement Technology, Hiroshima, Japan, January 2007.
[SAINT2007]Trammell，B.，Boschi，E.，Mark，L.，和T.Zseby，“标准化流量存储解决方案的要求”，2007年1月，日本广岛，SAINT 2007互联网测量技术研讨会论文集。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC5485] Housley, R., "Digital Signatures on Internet-Draft Documents", RFC 5485, March 2009.
[RFC5485]Housley，R.，“互联网文件草稿上的数字签名”，RFC 54852009年3月。
[pcap] "libpcap (http://www.tcpdump.org/)", October 2008.
[pcap]“libpcap(http://www.tcpdump.org/)“，2008年10月。
In this section we will explore an example IPFIX File that demonstrates the various features of the IPFIX File format. This File contains flow records described by a single Template. This File also contains a File Time Window record to note the start and end time of the data, and an Export Session Details record to record collection infrastructure information. Each Message within this File also contains a Message Checksum record, as this File may be externally encrypted and/or stored as an archive. The structure of this File is shown in Figure 2.
在本节中，我们将探讨一个示例IPFIX文件，该文件演示了IPFIX文件格式的各种功能。此文件包含由单个模板描述的流记录。此文件还包含一个文件时间窗口记录，用于记录数据的开始和结束时间，以及一个导出会话详细信息记录，用于记录收集基础结构信息。此文件中的每封邮件还包含一条邮件校验和记录，因为此文件可能被外部加密和/或存储为存档。该文件的结构如图2所示。
+=================================================+
| IPFIX Message seq. 0 |
| +---------------------------------------------+ |
| | Template Set (ID 2) 1 rec | |
| | Data Tmpl. ID 256 | |
| +---------------------------------------------+ |
| | Options Template Set (ID 3) 3 recs | |
| | File Time Window Opt. Tmpl. ID 257 | |
| | Message Checksum Opt. Tmpl. ID 259 | |
| | Export Session Details Opt. Tmpl. ID 258 | |
| +---------------------------------------------+ |
| | Data Set (ID 259) [Message Checksum] 1 rec | |
| +---------------------------------------------+ |
+=================================================+
| IPFIX Message seq. 1 |
| +---------------------------------------------+ |
| | Data Set (ID 257) [File Time Window] 1 rec | |
| +---------------------------------------------+ |
| | Data Set (ID 258) [Export Session] 1 rec | |
| +---------------------------------------------+ |
| | Data Set (ID 259) [Message Checksum] 1 rec | |
| +---------------------------------------------+ |
+=================================================+
| IPFIX Message seq. 4 |
| +---------------------------------------------+ |
| | Data Set (ID 256) 50 recs | |
| | contains flow data | |
| +---------------------------------------------+ |
| | Data Set (ID 259) [Message Checksum] 1 rec | |
| +---------------------------------------------+ |
+=================================================+
| IPFIX Message seq. 55 |
| . . . |
+=================================================+
| IPFIX Message seq. 0 |
| +---------------------------------------------+ |
| | Template Set (ID 2) 1 rec | |
| | Data Tmpl. ID 256 | |
| +---------------------------------------------+ |
| | Options Template Set (ID 3) 3 recs | |
| | File Time Window Opt. Tmpl. ID 257 | |
| | Message Checksum Opt. Tmpl. ID 259 | |
| | Export Session Details Opt. Tmpl. ID 258 | |
| +---------------------------------------------+ |
| | Data Set (ID 259) [Message Checksum] 1 rec | |
| +---------------------------------------------+ |
+=================================================+
| IPFIX Message seq. 1 |
| +---------------------------------------------+ |
| | Data Set (ID 257) [File Time Window] 1 rec | |
| +---------------------------------------------+ |
| | Data Set (ID 258) [Export Session] 1 rec | |
| +---------------------------------------------+ |
| | Data Set (ID 259) [Message Checksum] 1 rec | |
| +---------------------------------------------+ |
+=================================================+
| IPFIX Message seq. 4 |
| +---------------------------------------------+ |
| | Data Set (ID 256) 50 recs | |
| | contains flow data | |
| +---------------------------------------------+ |
| | Data Set (ID 259) [Message Checksum] 1 rec | |
| +---------------------------------------------+ |
+=================================================+
| IPFIX Message seq. 55 |
| . . . |
Figure 2: File Example Structure
图2：文件示例结构
The Template describing the data records contains a flow start timestamp, an IPv4 5-tuple, and packet and octet total counts. The Template Set defining this is as shown in Figure 3 below:
描述数据记录的模板包含流开始时间戳、IPv4 5元组以及数据包和八位字节总数。定义这一点的模板集如下图3所示：
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 = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds = 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| dest.IPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceTransportPort = 7 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| dest.TransportPort = 11 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier = 4 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetTotalCount = 85 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetTotalCount = 86 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds = 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| dest.IPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceTransportPort = 7 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| dest.TransportPort = 11 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier = 4 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetTotalCount = 85 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetTotalCount = 86 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: File Example Data Template
图3：文件示例数据模板
This is followed by an Options Template Set containing the Options Templates required to read the File: the File Time Window Options Template (defined in Section 8.1.2 above), the Export Session Details Options Template (defined in Section 8.1.3 above), and the Message Checksum Options Template (defined in Section 8.1.1 above). This Options Template Set is shown in Figure 4 and Figure 5 below:
然后是一个选项模板集，其中包含读取文件所需的选项模板：文件时间窗口选项模板（定义见上文第8.1.2节）、导出会话详细信息选项模板（定义见上文第8.1.3节）和消息校验和选项模板（定义见上文第8.1.1节）。此选项模板集如下图4和图5所示：
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 = 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| sessionScope = 267 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| minFlowStartSeconds = 265 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| maxFlowEndSeconds = 261 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | Template ID = 259 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Count = 2 | Scope Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| messageScope = 263 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| messageMD5Checksum = 262 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| sessionScope = 267 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| minFlowStartSeconds = 265 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| maxFlowEndSeconds = 261 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | Template ID = 259 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Count = 2 | Scope Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| messageScope = 263 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| messageMD5Checksum = 262 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: File Example Options Templates (Time Window and Checksum)
图4：文件示例选项模板（时间窗口和校验和）
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 = 258 | Field Count = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| sessionScope = 267 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| exporterIPv4Address = 130 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| collectorIPv4Address = 211 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| exporterTransportPort = 217 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| col.TransportPort = 216 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| col.TransportProtocol = 215 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| col.ProtocolVersion = 214 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| minExportSeconds = 264 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| maxExportSeconds = 260 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | set padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 258 | Field Count = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| sessionScope = 267 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| exporterIPv4Address = 130 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| collectorIPv4Address = 211 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| exporterTransportPort = 217 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| col.TransportPort = 216 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| col.TransportProtocol = 215 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| col.ProtocolVersion = 214 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| minExportSeconds = 264 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| maxExportSeconds = 260 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | set padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: File Example Options Templates, Continued (Session Details)
图5：文件示例选项模板，续（会话详细信息）
Following the Templates required to decode the File is the supplemental IPFIX Options information used to describe the File's contents and type information. First comes the File Time Window record; it notes that the File contains data from 9 October 2007 between 00:01:13 and 23:56:27 UTC, and appears as in Figure 6:
在解码文件所需的模板之后是用于描述文件内容和类型信息的补充IPFIX选项信息。首先是文件时间窗口记录；它注意到该文件包含2007年10月9日00:01:13和23:56:27 UTC之间的数据，如图6所示：
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 = 257 | Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sessionScope | minFlowStartSeconds
| 0 | 2007-10-09 00:01:13 UTC . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| maxFlowEndSeconds
. . . | 2007-10-09 23:56:27 UTC . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
. . . |
+-+-+-+-+-+-+-+-+
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 = 257 | Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sessionScope | minFlowStartSeconds
| 0 | 2007-10-09 00:01:13 UTC . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| maxFlowEndSeconds
. . . | 2007-10-09 23:56:27 UTC . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
. . . |
+-+-+-+-+-+-+-+-+
Figure 6: File Example Time Window
图6：文件示例时间窗口
This is followed by information about how the data in the File was collected, in the Export Session Details record. This record notes that the session stored in this File was sent via SCTP from an Exporter at 192.0.2.30 port 32769 to a Collector at 192.0.2.40 port 4739, and contains messages exported between 00:01:57 and 23:57:12 UTC on 9 October 2007; it is represented in its Data Set as in Figure 7:
然后在导出会话详细信息记录中显示有关如何收集文件中数据的信息。此记录注意到，此文件中存储的会话是通过SCTP从192.0.2.30端口32769的导出器发送到192.0.2.40端口4739的收集器的，其中包含2007年10月9日00:01:57到23:57:12 UTC之间导出的消息；其数据集如图7所示：
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 = 258 | Length = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sessionScope | exporterIPv4Address
| 0 | 192.0.2.30 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| collectorIPv4Address
. . . | 192.0.2.31 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| exporterTransportPort | cTPort
. . . | 32769 | 4739 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cTProtocol | cPVersion |
. . . | 132 | 10 | . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
minExportSeconds |
. . . 2007-10-09 00:01:57 UTC | . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
maxExportSeconds |
. . . 2007-10-09 23:57:12 UTC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 258 | Length = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sessionScope | exporterIPv4Address
| 0 | 192.0.2.30 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| collectorIPv4Address
. . . | 192.0.2.31 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| exporterTransportPort | cTPort
. . . | 32769 | 4739 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cTProtocol | cPVersion |
. . . | 132 | 10 | . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
minExportSeconds |
. . . 2007-10-09 00:01:57 UTC | . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
maxExportSeconds |
. . . 2007-10-09 23:57:12 UTC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: File Example Export Session Details
图7：文件示例导出会话详细信息
Each IPFIX Message within the File is completed with a Message Checksum record; the structure of this record within its Data Set is as in Figure 8:
文件中的每个IPFIX消息都使用消息校验和记录完成；该记录在其数据集中的结构如图8所示：
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 = 259 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| messageScope | |
| 0 | |
+-+-+-+-+-+-+-+-+ |
| messageMD5Checksum |
| (16-byte MD5 checksum of options message) |
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | set padding (3 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 259 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| messageScope | |
| 0 | |
+-+-+-+-+-+-+-+-+ |
| messageMD5Checksum |
| (16-byte MD5 checksum of options message) |
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | set padding (3 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: File Example Message Checksum
图8：文件示例消息校验和
After the Templates and supplemental Options information comes the data itself. The first record of an example Data Set is shown with its message and set headers in Figure 9:
模板和补充选项信息之后是数据本身。示例数据集的第一条记录及其消息和集合头如图9所示：
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 = 10 | Length = 1296 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time = 2007-10-09 00:01:57 UTC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 1254 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flowStartSeconds |
| 2007-10-09 00:01:13 UTC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv4Address |
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIPv4Address |
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceTransportPort | destinationTransportPort |
| 32770 | 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocolId | totalOctetCount
| 6 | 18000 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| totalPacketCount
. . . | 65 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (49 more records)
. . . |
+-+-+-+-+-+-+-+-+
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 = 10 | Length = 1296 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time = 2007-10-09 00:01:57 UTC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 1254 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flowStartSeconds |
| 2007-10-09 00:01:13 UTC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv4Address |
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIPv4Address |
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceTransportPort | destinationTransportPort |
| 32770 | 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocolId | totalOctetCount
| 6 | 18000 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| totalPacketCount
. . . | 65 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (49 more records)
. . . |
+-+-+-+-+-+-+-+-+
Figure 9: File Example Data Set
图9：文件示例数据集
Bringing together the examples above and adding message headers as appropriate, a hex dump of the first 317 bytes of the example File constructed above would appear as in the annotated Figure 10 below.
将上面的示例放在一起并酌情添加消息头，上面构造的示例文件的前317字节的十六进制转储将显示在下面的注释图10中。
0:|00 0A 00 A0 47 0A B6 E5 00 00 00 00 00 00 00 01
[^ first message header (length 160 bytes) -->
16:|00 02 00 28 01 00 00 08 00 96 00 04 00 08 00 04
[^ data template set -->
32: 00 0C 00 04 00 07 00 02 00 0B 00 02 00 04 00 01
0:|00 0A 00 A0 47 0A B6 E5 00 00 00 00 00 00 00 01
[^ first message header (length 160 bytes) -->
16:|00 02 00 28 01 00 00 08 00 96 00 04 00 08 00 04
[^ data template set -->
32: 00 0C 00 04 00 07 00 02 00 0B 00 02 00 04 00 01
48: 00 55 00 04 00 56 00 04|00 03 00 50 01 01 00 03
[^ opt template set -->
64: 00 01 01 0B 00 01 01 09 00 04 01 05 00 04 01 03
48: 00 55 00 04 00 56 00 04|00 03 00 50 01 01 00 03
[^ opt template set -->
64: 00 01 01 0B 00 01 01 09 00 04 01 05 00 04 01 03
80: 00 02 00 01 01 07 00 01 01 06 00 10 01 02 00 09
80: 00 02 00 01 01 07 00 01 01 06 00 10 01 02 00 09
96: 00 01 01 0B 00 01 00 82 00 04 00 D3 00 04 00 D9
96:00 01 01 0B 00 01 00 82 00 04 00 D3 00 04 00 D9
112: 00 02 00 D8 00 02 00 D7 00 01 00 D0 00 01 01 08
112:00 02 00 D8 00 02 00 D7 00 01 00 D0 00 01 08
128: 00 04 01 04 00 04 00 00|01 03 00 18 00 73 F1 12
[^ checksum record -->
144: D6 C7 58 BE 44 E6 60 06 4E 78 74 AE 7D 00 00 00
128: 00 04 01 04 00 04 00 00|01 03 00 18 00 73 F1 12
[^ checksum record -->
144: D6 C7 58 BE 44 E6 60 06 4E 78 74 AE 7D 00 00 00
176:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01
[^ second message header (length 80 bytes) -->
192:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02
[^ time window rec -> [ session detail rec ^ -->
208: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84
176:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01
[^ second message header (length 80 bytes) -->
192:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02
[^ time window rec -> [ session detail rec ^ -->
208: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84
224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E
[ message checksum record ^ -->
240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00
224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E
[ message checksum record ^ -->
240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00
256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01
[^ third message header (length 1296 bytes) -->
272:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03
[^ set hdr ][^ first data rec -->
288: 80 02 00 50 06 00 00 46 50 00 00 00 41
256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01
[^ third message header (length 1296 bytes) -->
272:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03
[^ set hdr ][^ first data rec -->
288: 80 02 00 50 06 00 00 46 50 00 00 00 41
Figure 10: File Example Hex Dump
图10：十六进制转储文件示例
As the IPFIX Message format is nearly a superset of the NetFlow V9 packet format, IPFIX Files can be used for store NetFlow V9 data relatively easily. This section describes a method for doing so. The differences between the two protocols are outlined in Appendix B.1 below. A simple, lightweight, message-for-message translation method for transforming V9 Packets into IPFIX Messages for storage within IPFIX Files is described in Appendix B.2. An example of this translation method is given in Appendix B.3.
由于IPFIX消息格式几乎是NetFlow V9数据包格式的超集，因此IPFIX文件可以相对轻松地用于存储NetFlow V9数据。本节介绍了执行此操作的方法。以下附录B.1概述了两个协议之间的差异。附录B.2中描述了一种简单、轻量级的消息对消息转换方法，用于将V9数据包转换为IPFIX消息以存储在IPFIX文件中。附录B.3中给出了这种翻译方法的示例。
With a few caveats, the IPFIX protocol is a superset of the NetFlow V9 protocol, having evolved from it largely through a process of feature addition to bring it into compliance with the IPFIX Requirements and the needs of stakeholders within the IPFIX Working Group. This appendix outlines the differences between the two protocols. It is informative only, and presented as an exploration of the two protocols to motivate the usage of IPFIX Files to store V9-collected flow data.
需要注意的是，IPFIX协议是NetFlow V9协议的超集，它主要是通过一个功能添加过程演变而来，以使其符合IPFIX要求和IPFIX工作组中利益相关者的需求。本附录概述了两个协议之间的差异。它仅提供信息，并作为对两个协议的探索而呈现，以鼓励使用IPFIX文件存储V9收集的流数据。
Both NetFlow V9 and IPFIX use streams of messages prefixed by a message header, though the message header differs significantly between the two. Note that in NetFlow V9 terminology, these messages are called packets, and messages must be delimited by datagram boundaries. IPFIX does not have this constraint. The header formats are detailed below:
NetFlow V9和IPFIX都使用以消息头为前缀的消息流，尽管两者的消息头有很大不同。请注意，在NetFlow V9术语中，这些消息称为数据包，并且消息必须由数据报边界分隔。IPFIX没有此约束。标题格式详述如下：
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 | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sysUpTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UNIX Secs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 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 | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sysUpTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UNIX Secs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: NetFlow V9 Packet Header Format
图11:NetFlow V9数据包头格式
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 12: IPFIX Message Header Format
图12:IPFIX消息头格式
Version Number: The IPFIX Version Number MUST be 10, while the NetFlow V9 Version Number MUST be 9.
版本号：IPFIX版本号必须为10，而NetFlow V9版本号必须为9。
Length vs. Count: The Count field in the NetFlow V9 packet header counts records in the message (including Data and Template Records), while the Length field in the IPFIX Message Header counts octets in the message. Note that this implies that NetFlow V9 collectors must rely on datagram boundaries or some other external delimiter; otherwise, they must completely consume a message before finding its end.
长度与计数：NetFlow V9数据包头中的计数字段统计消息中的记录（包括数据和模板记录），而IPFIX消息头中的长度字段统计消息中的八位字节。注意，这意味着NetFlow V9收集器必须依赖于数据报边界或其他一些外部分隔符；否则，它们必须在找到消息的结尾之前完全使用消息。
System Uptime: System uptime in milliseconds is exported in the NetFlow V9 packet header. This field is not present in the IPFIX Message Header, and must be exported using an IPFIX Option if required.
系统正常运行时间：以毫秒为单位的系统正常运行时间在NetFlow V9数据包头中导出。IPFIX消息头中不存在此字段，如果需要，必须使用IPFIX选项导出此字段。
Export Time: Aside from being called UNIX Secs in the NetFlow V9 packet header specification, the export time in seconds since 1 January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX message headers.
导出时间：除了在NetFlow V9数据包头规范中被称为UNIX秒外，自1970年1月1日起在UTC 0000时的导出时间（以秒为单位）同时出现在NetFlow V9和IPFIX消息头中。
Sequence Number: The NetFlow V9 Sequence Number counts packets, while the IPFIX Sequence Number counts records in Data Sets. Both are scoped to Observation Domain.
序列号：NetFlow V9序列号统计数据包，而IPFIX序列号统计数据集中的记录。两者的范围都是观察领域。
Observation Domain ID: Similarly, the NetFlow V9 sourceID has become the IPFIX Observation Domain ID.
观察域ID：同样，NetFlow V9 sourceID已成为IPFIX观察域ID。
Set headers are identical between NetFlow V9 and IPFIX; that is, each Set (FlowSet in NetFlow V9 terminology) is prefixed by a 4-byte set header containing the Set ID and the length of the set in octets.
NetFlow V9和IPFIX之间的集合头是相同的；也就是说，每个集合（NetFlow V9术语中的FlowSet）的前缀是一个4字节的集合头，其中包含集合ID和集合长度（以八位字节为单位）。
Note that the special Set IDs are different between IPFIX and NetFlow V9. IPFIX Template Sets are identified by Set ID 2, while NetFlow V9 Template FlowSets are identified by Set ID 0. Similarly, IPFIX Options Template Sets are identified by Set ID 3, while NetFlow V9 Options Template FlowSets are identified by Set ID 1.
请注意，IPFIX和NetFlow V9之间的特殊集合ID不同。IPFIX模板集由集ID 2标识，而NetFlow V9模板流集由集ID 0标识。类似地，IPFIX选项模板集由集合ID 3标识，而NetFlow V9选项模板流集由集合ID 1标识。
Both protocols reserve Set IDs 0-255, and use Set IDs 256-65535 for Data Sets (or FlowSets, in NetFlow V9 terminology).
这两个协议都保留集合ID 0-255，并将集合ID 256-65535用于数据集（或NetFlow V9术语中的流集）。
Template FlowSets in NetFlow V9 support a subset of functionality of those in IPFIX. Specifically, NetFlow V9 does not have any support for vendor-specific Information Elements as IPFIX does, so there is no enterprise bit or facility for associating a private enterprise number with an information element. NetFlow V9 also does not support variable-length fields.
NetFlow V9中的模板流集支持IPFIX中的一部分功能。具体地说，NetFlow V9不象IPFIX那样支持供应商特定的信息元素，因此没有企业位或工具将私有企业号与信息元素关联起来。NetFlow V9也不支持可变长度字段。
Options Template FlowSets in NetFlow V9 are similar to Options Template Sets in IPFIX subject to the same caveats.
NetFlow V9中的选项模板流集与IPFIX中的选项模板流集类似，但有相同的注意事项。
The NetFlow V9 field type definitions are a compatible subset of, and have evolved in concert with, the IPFIX Information Model. IPFIX Information Element identifiers in the range 1-127 are defined by the IPFIX Information Model [RFC5102] to be compatible with the corresponding NetFlow V9 field types.
NetFlow V9字段类型定义是IPFIX信息模型的兼容子集，并与IPFIX信息模型一起发展。范围为1-127的IPFIX信息元素标识符由IPFIX信息模型[RFC5102]定义，以与相应的NetFlow V9字段类型兼容。
NetFlow V9 has no concept of a Transport Session as in IPFIX, as NetFlow V9 was designed with a connectionless transport in mind. Template IDs are therefore scoped to an Exporting Process lifetime (i.e., an Exporting Process instance between restarts). There is no facility in NetFlow V9 as in IPFIX for Template withdrawal or Template ID reuse. Template retransmission at the Exporter works as in UDP-based IPFIX Exporting Processes.
NetFlow V9没有IPFIX中的传输会话概念，因为NetFlow V9在设计时考虑了无连接传输。因此，模板ID的作用域是导出流程生存期（即，重启之间的导出流程实例）。NetFlow V9中没有与IPFIX中相同的用于模板提取或模板ID重用的工具。导出器处的模板重新传输与基于UDP的IPFIX导出过程中的工作方式相同。
In practice, though NetFlow V9 is designed to be transport-independent, it is transported only over UDP. There is no facility as in IPFIX for full connection-oriented transport without datagram boundaries, due to the use of a record count field as opposed to a message length field in the packet header. There is no support in NetFlow V9 for transport layer security via TLS or DTLS.
实际上，尽管NetFlow V9设计为独立于传输，但它仅通过UDP传输。由于在数据包报头中使用了记录计数字段而不是消息长度字段，因此在IPFIX中没有一种功能可以实现无数据报边界的完全面向连接的传输。NetFlow V9不支持通过TLS或DTL实现传输层安全。
This appendix describes a method for transforming NetFlow V9 Packets into IPFIX Messages, which can be used to store NetFlow V9 data in IPFIX Files. A process transforming NetFlow V9 Packets into IPFIX Messages must handle the fact that NetFlow V9 Packets and IPFIX Messages are framed differently, that sequence numbering works differently, and that the NetFlow V9 field type definitions are only compatible with the IPFIX Information Model below Information Element identifier 128.
本附录描述了将NetFlow V9数据包转换为IPFIX消息的方法，可用于将NetFlow V9数据存储在IPFIX文件中。将NetFlow V9数据包转换为IPFIX消息的过程必须处理以下事实：NetFlow V9数据包和IPFIX消息的框架不同，序列编号工作方式不同，NetFlow V9字段类型定义仅与信息元素标识符128下方的IPFIX信息模型兼容。
For each incoming NetFlow V9 packet, the transformation process must:
对于每个传入的NetFlow V9数据包，转换过程必须：
1. Verify that the Version field of the packet header is 9.
1. 验证数据包头的版本字段是否为9。
2. Verify that the Sequence Number field of the packet header is valid.
2. 验证数据包头的序列号字段是否有效。
3. Scan the packet to:
3. 将数据包扫描到：
1. Verify that it contains no Templates with field types outside the range 1-127;
1. 验证它不包含字段类型超出范围1-127的模板；
2. Verify that it contains no FlowSets with Set IDs between 2 and 255 inclusive;
2. 验证它不包含集合ID介于2和255（含2和255）之间的流集；
3. Verify that it contains the number of records in FlowSets, Template FlowSets, and Options Template FlowSets declared in the Count field of the packet header; and
3. 验证它是否包含在数据包头的计数字段中声明的流集、模板流集和选项模板流集中的记录数；和
4. Count the number of records in Data FlowSets for calculating the IPFIX Sequence Number.
4. 计算数据流集中用于计算IPFIX序列号的记录数。
4. Calculate a Sequence Number for each IPFIX Observation Domain by storing the last Sequence Number sent for each Observation Domain plus the count of records in Data FlowSets in the previous step to be sent as the Sequence Number for the IPFIX Message following this one within that Observation Domain.
4. 通过存储为每个观察域发送的最后一个序列号加上上上一步中数据流集中的记录计数，计算每个IPFIX观察域的序列号，作为该观察域中此步骤之后IPFIX消息的序列号发送。
5. Generate a new IPFIX Message Header with:
5. 生成具有以下内容的新IPFIX消息头：
1. a Version field of 10;
1. 版本字段为10；
2. a Length field with the number of octets in the IPFIX Message, generally available by subtracting 4 from the length of the NetFlow V9 packet as returned from the transport layer (accounting for the difference in message header lengths);
2. 一个长度字段，其中包含IPFIX消息中的八位字节数，通常通过从传输层返回的NetFlow V9数据包长度中减去4来获得（考虑消息头长度的差异）；
3. the Sequence Number calculated for this message by the Sequence Number calculation step; and
3. 序列号计算步骤为此消息计算的序列号；和
4. Export Time and Observation Domain ID taken from the UNIX secs and Source ID fields of the NetFlow V9 packet header, respectively.
4. 分别从NetFlow V9数据包头的UNIX secs和Source ID字段导出时间域ID和观察域ID。
6. Copy each FlowSet from the Netflow V9 packet to the IPFIX Message after the header. Replace Set ID 0 with Set ID 2 for Template Sets, and Set ID 1 with Set ID 3 for Options Template Sets.
6. 将每个流集从Netflow V9数据包复制到标头后的IPFIX消息中。对于模板集，将集合ID 0替换为集合ID 2；对于选项模板集，将集合ID 1替换为集合ID 3。
Note that this process loses system uptime information; if such information is required, the transformation process will have to export that information using IPFIX Options. This may require a more sophisticated transformation process structure.
请注意，此进程会丢失系统正常运行时间信息；如果需要这些信息，转换过程必须使用IPFIX选项导出这些信息。这可能需要更复杂的转换过程结构。
The following two figures show a single NetFlow V9 packet with templates and the corresponding IPFIX Message, exporting a single flow record representing 60,303 octets sent from 192.0.2.2 to 192.0.2.3. This would be the third packet exported in Observation Domain 33 from the NetFlow V9 exporter, containing records starting with the 12th record (packet and record sequence numbers count from 0).
以下两幅图显示了一个带有模板的NetFlow V9数据包和相应的IPFIX消息，导出了一个表示从192.0.2.2发送到192.0.2.3的60303个八位字节的流记录。这将是观察域33中从NetFlow V9导出器导出的第三个数据包，其中包含以第12条记录开始的记录（数据包和记录序列号从0开始计数）。
The ** symbol in the IPFIX example shows those fields that required modification from the NetFlow V9 packet by the transformation process.
IPFIX示例中的**符号显示了需要通过转换过程从NetFlow V9数据包中修改的字段。
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 = 9 | Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime = 3750405 ms (1:02:30.405) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time = 1171557627 epoch sec (2007-02-15 16:40:27) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID = 33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 0 | Set Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4_SRC_ADDR = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4_DST_ADDR = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN_BYTES = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Set Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4_SRC_ADDR |
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4_DST_ADDR |
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN_BYTES |
| 60303 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 9 | Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime = 3750405 ms (1:02:30.405) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time = 1171557627 epoch sec (2007-02-15 16:40:27) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID = 33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 0 | Set Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4_SRC_ADDR = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4_DST_ADDR = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN_BYTES = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Set Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4_SRC_ADDR |
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4_DST_ADDR |
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN_BYTES |
| 60303 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Example NetFlow V9 Packet
图13:NetFlow V9数据包示例
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 = 10 | ** Length = 52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time = 1171557627 epoch sec (2007-02-15 16:40:27) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ** Sequence Number = 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID = 33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ** Set ID = 2 | Set Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Set Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv4Address |
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIPv4Address |
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| octetDeltaCount |
| 60303 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 10 | ** Length = 52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time = 1171557627 epoch sec (2007-02-15 16:40:27) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ** Sequence Number = 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID = 33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ** Set ID = 2 | Set Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Set Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv4Address |
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destinationIPv4Address |
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| octetDeltaCount |
| 60303 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Corresponding Example IPFIX Message
图14：相应的IPFIX消息示例
Authors' Addresses
作者地址
Brian Trammell Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 632 70 13 EMail: brian.trammell@hitachi-eu.com
Brian Trammell Hitachi Europe c/o ETH苏黎世Gloriastrasse 35 8092苏黎世瑞士电话：+41 44 632 70 13电子邮件：Brian。trammell@hitachi-欧盟网站
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 632 70 57 EMail: elisa.boschi@hitachi-eu.com
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092苏黎世瑞士电话：+41 44 632 70 57电子邮件：Elisa。boschi@hitachi-欧盟网站
Lutz Mark Fraunhofer IFAM Wiener Str. 12 28359 Bremen Germany Phone: +49 421 2246206 EMail: lutz.mark@ifam.fraunhofer.de
卢茨马克·弗劳恩霍夫·伊法姆·维纳大街12 28359不来梅德国电话：+49 421 2246206电子邮件：卢茨。mark@ifam.fraunhofer.de
Tanja Zseby Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49 30 3463 7153 EMail: tanja.zseby@fokus.fraunhofer.de
Tanja Zseby Fraunhofer开放通信系统研究所Kaiserin Augusta Allee 31 10589柏林德国电话：+49 30 3463 7153电子邮件：Tanja。zseby@fokus.fraunhofer.de
Arno Wagner ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 632 70 04 EMail: arno@wagner.name
Arno Wagner ETH苏黎世Gloriastrasse 35 8092苏黎世瑞士电话：+41 44 632 70 04电子邮件：arno@wagner.name