Network Working Group E. Boschi
Request for Comments: 5473 Hitachi Europe
Category: Informational L. Mark
Fraunhofer IFAM
B. Claise
Cisco Systems, Inc.
March 2009
Network Working Group E. Boschi
Request for Comments: 5473 Hitachi Europe
Category: Informational L. Mark
Fraunhofer IFAM
B. Claise
Cisco Systems, Inc.
March 2009
Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports
减少IP流信息导出（IPFIX）和数据包采样（PSAMP）报告中的冗余
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well.
本文档描述了使用IP流信息导出（IPFIX）协议导出流或包信息的带宽节约方法。由于数据包采样（PSAMP）协议基于IPFIX，这些注意事项对于PSAMP导出也是有效的。
This method works by separating information common to several Flow Records from information specific to an individual Flow Record. Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier.
此方法的工作原理是将多个流记录的公共信息与单个流记录的特定信息分离。公共流信息在由选项模板定义的数据记录中仅导出一次，而其余特定流信息通过唯一标识符与公共信息关联。
Table of Contents
目录
1. Introduction ....................................................3
1.1. IPFIX Documents Overview ...................................3
1.2. PSAMP Documents Overview ...................................4
2. Terminology .....................................................4
2.1. Terminology Summary Table ..................................5
2.2. IPFIX Flows versus PSAMP Packets ...........................5
3. Specifications for Bandwidth-Saving Information Export ..........5
3.1. Problem Statement and High-Level Solution ..................6
3.2. Data Reduction Technique ...................................7
4. Transport Protocol Choice .......................................8
4.1. PR-SCTP ....................................................9
4.2. UDP ........................................................9
4.3. TCP ........................................................9
5. commonPropertiesID Management ...................................9
6. The Collecting Process Side ....................................10
6.1. UDP .......................................................11
6.2. TCP .......................................................12
7. Advanced Techniques ............................................12
7.1. Multiple Data Reduction ...................................12
7.2. Cascading Common Properties ...............................15
8. Export and Evaluation Considerations ...........................15
8.1. Transport Protocol Choice .................................16
8.2. Reduced Size Encoding .....................................16
8.3. Efficiency Gain ...........................................16
9. Security Considerations ........................................17
10. Acknowledgments ...............................................17
11. References ....................................................17
11.1. Normative References .....................................17
11.2. Informative References ...................................18
Appendix A. Examples ..............................................19
A.1. Per-Flow Data Reduction ...................................19
A.2. Per-Packet Data Reduction .................................23
A.3. Common Properties Withdrawal Message ......................26
1. Introduction ....................................................3
1.1. IPFIX Documents Overview ...................................3
1.2. PSAMP Documents Overview ...................................4
2. Terminology .....................................................4
2.1. Terminology Summary Table ..................................5
2.2. IPFIX Flows versus PSAMP Packets ...........................5
3. Specifications for Bandwidth-Saving Information Export ..........5
3.1. Problem Statement and High-Level Solution ..................6
3.2. Data Reduction Technique ...................................7
4. Transport Protocol Choice .......................................8
4.1. PR-SCTP ....................................................9
4.2. UDP ........................................................9
4.3. TCP ........................................................9
5. commonPropertiesID Management ...................................9
6. The Collecting Process Side ....................................10
6.1. UDP .......................................................11
6.2. TCP .......................................................12
7. Advanced Techniques ............................................12
7.1. Multiple Data Reduction ...................................12
7.2. Cascading Common Properties ...............................15
8. Export and Evaluation Considerations ...........................15
8.1. Transport Protocol Choice .................................16
8.2. Reduced Size Encoding .....................................16
8.3. Efficiency Gain ...........................................16
9. Security Considerations ........................................17
10. Acknowledgments ...............................................17
11. References ....................................................17
11.1. Normative References .....................................17
11.2. Informative References ...................................18
Appendix A. Examples ..............................................19
A.1. Per-Flow Data Reduction ...................................19
A.2. Per-Packet Data Reduction .................................23
A.3. Common Properties Withdrawal Message ......................26
The IPFIX working group has specified a protocol to export IP Flow information [RFC5101]. This protocol is designed to export information about IP traffic Flows and related measurement data, where a Flow is defined by a set of key attributes (e.g., source and destination IP address, source and destination port, etc.). However, thanks to its template mechanism, the IPFIX protocol can export any type of information, as long as the Information Element is specified in the IPFIX information model [RFC5101] or registered with IANA.
IPFIX工作组指定了导出IP流信息的协议[RFC5101]。该协议旨在导出有关IP流量和相关测量数据的信息，其中流量由一组关键属性（例如，源和目标IP地址、源和目标端口等）定义。但是，由于其模板机制，IPFIX协议可以导出任何类型的信息，只要信息元素在IPFIX信息模型[RFC5101]中指定或在IANA注册即可。
Regardless of the fields' contents, Flow Records with common properties export the same fields in every single Data Record. These common properties may represent values common to a collection of Flows or packets, or values that are invariant over time. Note that the common properties don't represent the list of Flow Keys, which are used to define a Flow definition; however, the common properties may contain some of the Flow Keys. The reduction of redundant data from the export stream can result in a significant reduction of the transferred data.
无论字段的内容如何，具有公共属性的流记录都会在每个数据记录中导出相同的字段。这些公共属性可以表示流或数据包集合的公共值，或者表示随时间变化不变的值。请注意，公共属性并不表示用于定义流定义的流键列表；但是，公共属性可能包含一些流键。导出流中冗余数据的减少可导致传输数据的显著减少。
This document specifies a way to export these invariant or common properties only once, while the rest of the Flow-specific properties are exported in regular Data Records. Unique common properties identifiers are used to link Data Records and the common attributes.
本文档指定了一种仅导出一次这些不变属性或公共属性的方法，而其余特定于流的属性将在常规数据记录中导出。唯一的公共属性标识符用于链接数据记录和公共属性。
The proposed method is applicable to IPFIX Flow and to PSAMP per-packet information, without any changes to both the IPFIX and PSAMP protocol specifications.
所提出的方法适用于IPFIX流和每个包的PSAMP信息，而不改变IPFIX和PSAMP协议规范。
The IPFIX protocol [RFC5101] provides network administrators with access to IP Flow information. The architecture for the export of measured IP Flow information out of an IPFIX exporting process to a collecting process is defined in the IPFIX Architecture [RFC5470], per the requirements defined in RFC 3917 [RFC3917]. The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records and templates are carried via a congestion-aware transport protocol from IPFIX exporting processes to IPFIX collecting processes. IPFIX has a formal description of IPFIX Information Elements, their names, types, and additional semantic information, as specified in the IPFIX information model [RFC5102]. Finally, the IPFIX applicability statement [RFC5472] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks.
IPFIX协议[RFC5101]为网络管理员提供了访问IP流信息的权限。根据RFC 3917[RFC3917]中定义的要求，IPFIX体系结构[RFC5470]中定义了将测量的IP流信息从IPFIX导出过程导出到收集过程的体系结构。IPFIX体系结构[RFC5470]指定如何通过拥塞感知传输协议将IPFIX数据记录和模板从IPFIX导出进程传送到IPFIX收集进程。按照IPFIX信息模型[RFC5102]的规定，IPFIX对IPFIX信息元素、它们的名称、类型和附加语义信息有一个正式的描述。最后，IPFIX适用性声明[RFC5472]描述了什么类型的应用程序可以使用IPFIX协议以及它们如何使用提供的信息。它还展示了IPFIX框架与其他体系结构和框架的关系。
The document "A Framework for Packet Selection and Reporting" [RFC5474] describes the PSAMP framework for network elements to select subsets of packets by statistical and other methods, and to export a stream of reports on the selected packets to a collector. The set of packet selection techniques (sampling, filtering, and hashing) supported by PSAMP is described in "Sampling and Filtering Techniques for IP Packet Selection" [RFC5475]. The PSAMP protocol [RFC5476] specifies the export of packet information from a PSAMP exporting process to a PSAMP collecting process. Like IPFIX, PSAMP has a formal description of its Information Elements, their names, types, and additional semantic information. The PSAMP information model is defined in [RFC5477]. Finally, [PSAMP-MIB] describes the PSAMP Management Information Base.
文档“分组选择和报告框架”[RFC5474]描述了PSAMP框架，用于网络元件通过统计和其他方法选择分组子集，并将所选分组的报告流导出到收集器。PSAMP支持的一组数据包选择技术（采样、过滤和散列）在“IP数据包选择的采样和过滤技术”[RFC5475]中描述。PSAMP协议[RFC5476]指定将数据包信息从PSAMP导出进程导出到PSAMP收集进程。与IPFIX一样，PSAMP对其信息元素、名称、类型和附加语义信息进行了形式化描述。PSAMP信息模型在[RFC5477]中定义。最后，[PSAMP-MIB]描述了PSAMP管理信息库。
IPFIX-specific terminology used in this document is defined in Section 2 of the IPFIX protocol specification [RFC5101] and Section 3 of the PSAMP protocol specification [RFC5476]. As in [RFC5101] and [RFC5476], these IPFIX-specific terms have the first letter of a word capitalized when used in this document.
本文件中使用的IPFIX专用术语在IPFIX协议规范[RFC5101]第2节和PSAMP协议规范[RFC5476]第3节中有定义。与[RFC5101]和[RFC5476]中一样，这些IPFIX专用术语在本文档中使用时，单词的首字母大写。
In addition, the following new terms are defined in this document:
此外，本文件中定义了以下新术语：
commonPropertiesID: The commonPropertiesID is an identifier of a set of common properties that is locally unique per Observation Domain and Transport Session. Typically, this Information Element is used to link to information reported in separate Data Records. See the IPFIX information model [RFC5102] for the Information Element definition.
commonPropertiesID：commonPropertiesID是一组公共属性的标识符，这些属性在每个观察域和传输会话中都是本地唯一的。通常，此信息元素用于链接到单独数据记录中报告的信息。有关信息元素定义，请参阅IPFIX信息模型[RFC5102]。
Common Properties: Common Properties are a collection of one or more attributes shared by a set of different Flow Records. Each set of Common Properties is uniquely identifiable by means of a commonPropertiesID.
公共属性：公共属性是一组不同流记录共享的一个或多个属性的集合。通过commonPropertiesID，每一组公共属性都是唯一可识别的。
Specific Properties: Specific Properties are a collection of one or more attributes reported in a Flow Record that are not included in the Common Properties defined for that Flow Record.
特定属性：特定属性是流记录中报告的一个或多个属性的集合，这些属性不包括在为该流记录定义的公共属性中。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
+------------------+---------------------------------------------+
| | Contents |
| +--------------------+------------------------+
| Set | Template | Record |
+------------------+--------------------+------------------------+
| Data Set | / | Data Record(s) |
+------------------+--------------------+------------------------+
| Template Set | Template Record(s) | / |
+------------------+--------------------+------------------------+
| Options Template | Options Template | / |
| Set | Record(s) | |
+------------------+--------------------+------------------------+
+------------------+---------------------------------------------+
| | Contents |
| +--------------------+------------------------+
| Set | Template | Record |
+------------------+--------------------+------------------------+
| Data Set | / | Data Record(s) |
+------------------+--------------------+------------------------+
| Template Set | Template Record(s) | / |
+------------------+--------------------+------------------------+
| Options Template | Options Template | / |
| Set | Record(s) | |
+------------------+--------------------+------------------------+
Terminology Summary Table
术语汇总表
A Data Set is composed of Data Record(s). No Template Record is included. A Template Record or an Options Template Record defines the Data Record.
数据集由数据记录组成。不包括模板记录。模板记录或选项模板记录定义数据记录。
A Template Set contains only Template Record(s).
模板集仅包含模板记录。
An Options Template Set contains only Options Template Record(s).
选项模板集仅包含选项模板记录。
As described in the PSAMP protocol specification [RFC5476], the major difference between IPFIX and PSAMP is that the IPFIX protocol exports Flow Records while the PSAMP protocol exports Packet Records. From a pure export point of view, IPFIX will not distinguish a Flow Record composed of several packets aggregated together from a Flow Record composed of a single packet. So, the PSAMP export can be seen as a special IPFIX Flow Record containing information about a single packet.
如PSAMP协议规范[RFC5476]所述，IPFIX和PSAMP之间的主要区别在于IPFIX协议导出流记录，而PSAMP协议导出数据包记录。从纯导出的角度来看，IPFIX不会区分由多个数据包聚合而成的流记录和由单个数据包组成的流记录。因此，PSAMP导出可以看作是一个特殊的IPFIX流记录，其中包含关于单个数据包的信息。
For this document's clarity, the term Flow Record represents a generic term expressing an IPFIX Flow Record or a PSAMP Packet Record, as foreseen by its definition. However, when appropriate, a clear distinction between Flow Record or Packet Record will be made.
为了清楚起见，术语流记录表示一个通用术语，表示IPFIX流记录或PSAMP数据包记录，如其定义所预见的。然而，在适当的情况下，将明确区分流量记录和数据包记录。
Several Flow Records often share a set of Common Properties. Repeating the information about these Common Properties for every Flow Record introduces a huge amount of redundancy. This document proposes a method to reduce this redundancy.
多个流记录通常共享一组公共属性。为每个流记录重复有关这些公共属性的信息会引入大量冗余。本文件提出了一种减少这种冗余的方法。
The PSAMP specifications are used for the export of per-packet information, exporting the specific observed packet in an IPFIX Flow Record. This can be considered as a special Flow Record case, composed of a single packet. Therefore, the method described in this document is also applicable to per-packet data reduction, e.g., for export of One-Way Delay (OWD) measurements (see Appendix), trajectory sampling, etc.
PSAMP规范用于导出每个数据包信息，导出IPFIX流记录中的特定观察数据包。这可以看作是一种特殊的流记录情况，由单个数据包组成。因此，本文件中描述的方法也适用于每包数据减少，例如，输出单向延迟（OWD）测量（见附录）、轨迹采样等。
Consider a set of properties "A", e.g., common sourceAddressA and sourcePortA, equivalent for each Flow Record exported. Figure 1 shows how this information is repeated with classical IPFIX Flow Records, expressing the waste of bandwidth to export redundant information.
考虑一组属性“A”，例如，公共源代码AdvestRSA和SooSeCurtA，相当于导出的每个流记录。图1显示了如何使用经典IPFIX流记录重复此信息，表示导出冗余信息浪费带宽。
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow1 information> |
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow2 information> |
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow3 information> |
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow4 information> |
+----------------+-------------+---------------------------+
| ... | ... | ... |
+----------------+-------------+---------------------------+
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow1 information> |
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow2 information> |
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow3 information> |
+----------------+-------------+---------------------------+
| sourceAddressA | sourcePortA | <Flow4 information> |
+----------------+-------------+---------------------------+
| ... | ... | ... |
+----------------+-------------+---------------------------+
Figure 1: Common and Specific Properties Exported Together
图1：共同和特定属性一起导出
Figure 2 shows how this information is exported when applying the specifications of this document. The Common Properties are separated from the Specific Properties for each Flow Record. The Common Properties would be exported only once in a specific Data Record (defined by an Options Template), while each Flow Record contains a pointer to the Common Properties A, along with its Flow-specific information. In order to maintain the relationship between these sets of properties, we introduce indices (in this case, the index for properties A) for the Common Properties that are unique for all Common Properties entries within an Observation Domain. The purpose of the indices is to serve as a "key" identifying "rows" of the Common Properties table. The rows are then referenced by the Specific Properties by using the appropriate value for the Common Properties identifier.
图2显示了应用此文档的规范时如何导出此信息。公共属性与每个流记录的特定属性分开。公共属性在特定数据记录（由选项模板定义）中仅导出一次，而每个流记录包含指向公共属性a的指针及其流特定信息。为了维护这些属性集之间的关系，我们为公共属性引入了索引（在本例中为属性A的索引），这些索引对于观察域中的所有公共属性条目都是唯一的。索引的目的是作为标识公共属性表的“行”的“键”。然后，通过使用公共属性标识符的适当值，特定属性将引用这些行。
+------------------------+-----------------+-------------+
| index for properties A | sourceAddressA | sourcePortA |
+------------------------+-----------------+-------------+
| ... | ... | ... |
+------------------------+-----------------+-------------+
+------------------------+-----------------+-------------+
| index for properties A | sourceAddressA | sourcePortA |
+------------------------+-----------------+-------------+
| ... | ... | ... |
+------------------------+-----------------+-------------+
+------------------------+---------------------------+
| index for properties A | <Flow1 information> |
+------------------------+---------------------------+
| index for properties A | <Flow2 information> |
+------------------------+---------------------------+
| index for properties A | <Flow3 information> |
+------------------------+---------------------------+
| index for properties A | <Flow4 information> |
+------------------------+---------------------------+
+------------------------+---------------------------+
| index for properties A | <Flow1 information> |
+------------------------+---------------------------+
| index for properties A | <Flow2 information> |
+------------------------+---------------------------+
| index for properties A | <Flow3 information> |
+------------------------+---------------------------+
| index for properties A | <Flow4 information> |
+------------------------+---------------------------+
Figure 2: Common and Specific Properties Exported Separately
图2：分别导出的公共和特定属性
This unique export of the Common Properties results in a decrease of the bandwidth requirements for the path between the Exporter and the Collector.
公共属性的这种独特导出导致导出器和收集器之间路径的带宽需求减少。
The IPFIX protocol [RFC5101] is Template based. Templates define how data should be exported, describing data fields together with their type and meaning. IPFIX specifies two types of Templates: the Template Record and the Options Template Record. The difference between the two is that the Options Template Record includes the notion of scope, defining how to scope the applicability of the Data Record. The scope, which is only available in the Options Template Record, gives the context of the reported Information Elements in the Data Records. The Template Records and Options Template Records are necessary to decode the Data Records. Indeed, by only looking at the Data Records themselves, it is impossible to distinguish a Data Record defined by Template Record from a Data Record defined by an Options Template Record. To export information more efficiently, this specification proposes to group Flow Records by their common properties. We define Common Properties as a collection of attributes shared by a set of different Flow Records.
IPFIX协议[RFC5101]基于模板。模板定义了数据的导出方式，描述了数据字段及其类型和含义。IPFIX指定两种类型的模板：模板记录和选项模板记录。两者之间的区别在于，选项模板记录包含范围的概念，定义了如何确定数据记录的适用范围。范围（仅在选项模板记录中可用）提供了数据记录中报告的信息元素的上下文。模板记录和选项模板记录是解码数据记录所必需的。实际上，仅通过查看数据记录本身，不可能将模板记录定义的数据记录与选项模板记录定义的数据记录区分开来。为了更有效地导出信息，本规范建议按流记录的公共属性对其进行分组。我们将公共属性定义为一组不同流记录共享的属性集合。
An implementation using the proposed specification MUST follow the IPFIX transport protocol specifications defined in the IPFIX protocol [RFC5101].
使用建议规范的实现必须遵循IPFIX协议[RFC5101]中定义的IPFIX传输协议规范。
As explained in Figure 3, the information is split into two parts, using two different Data Records. Common Properties MUST be exported via Data Records defined by an Options Template Record. Like Template Records, they MUST be sent only once per SCTP association or TCP connection, and MUST be sent reliably via SCTP if SCTP is the transport protocol. These properties represent values common to several Flow Records (e.g., IP source and destination address). The Common Properties Data Records MUST be sent prior to the corresponding Specific Properties Data Records. The Data Records reporting Specific Properties MUST be associated with the Data Records reporting the Common Properties using a unique identifier for the Common Properties, the commonPropertiesID Information Element [RFC5102]. The commonPropertiesID Information Element MUST be included in the scope of the Options Template Record, and also included in the associated Template Record.
如图3所示，使用两个不同的数据记录将信息分为两部分。公共属性必须通过选项模板记录定义的数据记录导出。与模板记录一样，每个SCTP关联或TCP连接只能发送一次，如果SCTP是传输协议，则必须通过SCTP可靠地发送。这些属性表示多个流记录的公共值（例如，IP源和目标地址）。公共属性数据记录必须在相应的特定属性数据记录之前发送。报告特定属性的数据记录必须使用公共属性的唯一标识符commonPropertiesID信息元素[RFC5102]与报告公共属性的数据记录相关联。commonPropertiesID信息元素必须包含在选项模板记录的范围内，也必须包含在关联的模板记录中。
+---------------------------+ +---------------------+
| Common Properties | | Specific Properties | Template
| Options Template Record | | Template Record | Definition
| | | |
| scope: commonPropertiesID | | commonPropertiesID |
| Common Properties | | Specific Properties |
+------------+--------------+ +----------+----------+
.............|...............................|.......................
| |
+------------v-------------+ +----------v----------+
| Common Properties | | Specific Properties |+ Exported
| Data Record |------> Data Records || Data
+--------------------------+ +---------------------+| Records
+---------------------+
+---------------------------+ +---------------------+
| Common Properties | | Specific Properties | Template
| Options Template Record | | Template Record | Definition
| | | |
| scope: commonPropertiesID | | commonPropertiesID |
| Common Properties | | Specific Properties |
+------------+--------------+ +----------+----------+
.............|...............................|.......................
| |
+------------v-------------+ +----------v----------+
| Common Properties | | Specific Properties |+ Exported
| Data Record |------> Data Records || Data
+--------------------------+ +---------------------+| Records
+---------------------+
Figure 3: Template Record and Data Record Dependencies
图3：模板记录和数据记录依赖关系
From the IPFIX protocol, there are no differences between the per-Flow or per-packet data reduction, except maybe the terminology where the Specific Properties could be called packet Specific Properties in the previous figure.
从IPFIX协议来看，每流或每包数据缩减之间没有区别，除了上图中特定属性可能被称为包特定属性的术语之外。
This document follows the IPFIX transport protocol specifications defined in the IPFIX protocol [RFC5101]. However, depending on the transport protocol choice, this document imposes some additional constraints. If Partial Reliable Stream Control Transmission Protocol (PR-SCTP) [RFC3758] is selected as the IPFIX protocol, the following PR-SCTP subsection specifications MUST be respected. If UDP is selected as the IPFIX protocol, the following UDP subsection
本文档遵循IPFIX协议[RFC5101]中定义的IPFIX传输协议规范。但是，根据传输协议的选择，本文档施加了一些附加约束。如果选择部分可靠流控制传输协议（PR-SCTP）[RFC3758]作为IPFIX协议，则必须遵守以下PR-SCTP小节规范。如果选择UDP作为IPFIX协议，则以下UDP小节
specifications MUST be respected. If TCP is selected as the IPFIX protocol, the following TCP subsection specifications MUST be respected.
必须遵守规范。如果选择TCP作为IPFIX协议，则必须遵守以下TCP小节规范。
The active Common Properties MUST be sent after the SCTP association establishment and before the corresponding Specific Properties Data Records. In the case of SCTP association re-establishment, all active Common Properties MUST be resent before the corresponding Specific Properties Data Records.
活动公共属性必须在SCTP关联建立之后和相应特定属性数据记录之前发送。在SCTP关联重新建立的情况下，必须在相应的特定属性数据记录之前重新发送所有活动的公共属性。
The Common Properties Data Records MUST be sent reliably.
公共属性数据记录必须可靠地发送。
Common Properties Data Records MUST be resent on a regular basis. The periodicity MUST be configurable. The default value for the frequency of Common Properties transmission (refresh timeout) is 10 minutes.
必须定期重新提交公共属性数据记录。周期必须是可配置的。公共属性传输频率（刷新超时）的默认值为10分钟。
The Exporting Process SHOULD transmit the Common Properties definition in advance of any Data Record that uses these Common Properties to help ensure that the Collector has the Common Properties definition before receiving the first associated Data Record.
导出过程应在使用这些公共属性的任何数据记录之前传输公共属性定义，以帮助确保收集器在接收第一个关联数据记录之前具有公共属性定义。
If a commonPropertiesID is not used anymore, the Exporting Process stops resending the related Common Properties Data Record. The old commonPropertiesID MUST NOT be used until its lifetime (see Section 6.1) has expired.
如果不再使用commonPropertiesID，则导出过程将停止重新发送相关的CommonProperties数据记录。旧的commonPropertiesID在其使用寿命（见第6.1节）到期之前不得使用。
Common Properties MUST be sent after the TCP connection establishment, and before the corresponding Specific Properties Data Records. In the case of TCP connection re-establishment, all active Common Properties MUST be resent before the corresponding Specific Properties Data Records.
公共属性必须在TCP连接建立之后、相应的特定属性数据记录之前发送。在重新建立TCP连接的情况下，必须在相应的特定属性数据记录之前重新发送所有活动的公共属性。
The commonPropertiesID is an identifier of a set of common properties that is locally unique per Observation Domain and Transport Session. The Exporting Process MUST manage the commonPropertiesIDs allocations for its Observation Domains and Transport Session. Different
commonPropertiesID是一组公共属性的标识符，这些属性在每个观察域和传输会话中都是本地唯一的。导出进程必须管理其观察域和传输会话的CommonPropertiesID分配。不同的
Observation Domains from the same Exporter MAY use the same commonPropertiesID value to refer to different sets of Common Properties.
来自同一导出器的观察域可以使用相同的commonPropertiesID值来引用不同的公共属性集。
The commonPropertiesID values MAY be assigned sequentially, but it is NOT REQUIRED. Particular commonPropertiesID ranges or values MAY have explicit meanings for the IPFIX Device. For example, commonPropertiesID values may be assigned based on the result of a hash function, etc.
commonPropertiesID值可以按顺序分配，但不是必需的。特定的commonPropertiesID范围或值对于IPFIX设备可能具有明确的含义。例如，可以基于散列函数等的结果来分配commonPropertiesID值。
Using a 64-bit commonPropertiesID Information Element allows the export of 2**64 active sets of Common Properties, per Observation Domain and per Transport Session.
使用64位commonPropertiesID信息元素可以导出每个观察域和每个传输会话的2**64个活动公共属性集。
commonPropertiesIDs that are not used anymore SHOULD be withdrawn. The Common Properties Withdrawal message is a Data Record defined by an Options Template consisting of only one scope field -- namely, the commonPropertiesID (with a type of 137 [RFC5102]) and no non-scope fields.
不再使用的CommonPropertiesID应收回。公共属性撤销消息是由选项模板定义的数据记录，该模板只包含一个作用域字段，即commonPropertiesID（类型为137[RFC5102]），没有非作用域字段。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 14 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID N | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field count = 1 |0| commonPropertiesID = 137 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 14 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID N | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field count = 1 |0| commonPropertiesID = 137 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Common Properties Withdrawal Message
图4：公共属性撤销消息
If UDP is selected as the transport protocol, the Common Properties Withdrawal messages MUST NOT be used, as this method is inefficient due to the unreliable nature of UDP.
如果选择UDP作为传输协议，则不得使用公共属性撤回消息，因为由于UDP的不可靠性，此方法效率低下。
This section describes the Collecting Process when using SCTP and PR-SCTP as the transport protocol. Any necessary changes to the Collecting Process, specifically related to TCP or UDP transport protocols, are specified in the subsections.
本节描述使用SCTP和PR-SCTP作为传输协议时的收集过程。收集过程的任何必要更改，特别是与TCP或UDP传输协议相关的更改，都在小节中指定。
The Collecting Process MUST store the commonPropertiesID information for the duration of the association so that it can interpret the corresponding Data Records that are received in subsequent Data Sets.
收集过程必须在关联期间存储commonPropertiesID信息，以便能够解释在后续数据集中接收到的相应数据记录。
The Collecting Process can either store the Data Records as they arrive, without reconstructing the initial Flow Record, or reconstruct the initial Flow Record. In the former case, there might be less storage capacity required at the Collector side. In the latter case, the Collector job is more complex and time-consuming due to the higher resource demand for record processing in real time.
收集过程可以在数据记录到达时存储数据记录，而不重建初始流记录，也可以重建初始流记录。在前一种情况下，收集器端可能需要较少的存储容量。在后一种情况下，收集器作业更加复杂和耗时，因为实时处理记录需要更高的资源需求。
If the Collecting Process has received the Specific Properties Data Record before the associated Common Properties Data Record, the Collecting Process SHOULD store the Specific Properties Data Record and await the retransmission or out-of-order arrival of the Common Properties Data Record.
如果采集过程在相关公共属性数据记录之前已收到特定属性数据记录，则采集过程应存储特定属性数据记录，并等待公共属性数据记录的重新传输或无序到达。
commonPropertiesIDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives an Options Template Record with a scope containing a commonPropertiesID that has already been received but that has not previously been withdrawn (i.e., a commonPropertiesID from the same Exporter Observation Domain received on the SCTP association), then the Collecting Process MUST shut down the association.
每个SCTP关联和每个观察域的公共属性ID都是唯一的。如果收集过程接收到一个选项模板记录，该记录的作用域包含一个commonPropertiesID，该ID已经收到，但之前尚未撤回（即，来自SCTP关联上收到的同一导出器观察域的commonPropertiesID），则收集过程必须关闭该关联。
When an SCTP association is closed, the Collecting Process MUST discard all commonPropertiesIDs received over that association and stop decoding IPFIX Messages that use those commonPropertiesIDs.
当SCTP关联关闭时，收集进程必须丢弃通过该关联接收的所有CommonPropertiesID，并停止对使用这些CommonPropertiesID的IPFIX消息进行解码。
If a Collecting Process receives a Common Properties Withdrawal message, the Collecting Process MUST delete the corresponding Common Properties associated with the specific SCTP association and specific Observation Domain, and stop interpreting Data Records referring to those Common Properties. The receipt of Data Records referring to Common Properties that have been withdrawn MUST be ignored and SHOULD be logged by the Collecting Process.
如果采集过程收到公共属性撤销消息，则采集过程必须删除与特定SCTP关联和特定观测域关联的相应公共属性，并停止解释引用这些公共属性的数据记录。必须忽略已撤销的公共财产相关数据记录的接收，并由收集流程记录。
If the Collecting Process receives a Common Properties Withdrawal message for Common Properties that it has not received before on this SCTP association, it MUST reset the SCTP association and discard the IPFIX Message, and it SHOULD log the error as it does for malformed IPFIX Messages.
如果收集进程在此SCTP关联上收到以前从未收到的公用属性的公用属性撤消消息，则必须重置SCTP关联并丢弃IPFIX消息，并且应像记录格式错误的IPFIX消息一样记录错误。
The Collecting Process MUST associate a lifetime with each Common Property received via UDP. Common Properties not refreshed by the Exporting Process within the lifetime are expired at the Collecting Process.
收集进程必须将生存期与通过UDP接收的每个公共属性相关联。导出进程在生存期内未刷新的公共属性在收集进程中过期。
If the Common Properties are not refreshed before that lifetime has expired, the Collecting Process MUST discard the corresponding definition of the commonPropertiesID and any current and future associated Data Records. In this case, an alarm MUST be logged.
如果在该生存期到期之前未刷新公共属性，则收集过程必须放弃公共属性ID的相应定义以及任何当前和未来关联的数据记录。在这种情况下，必须记录报警。
The Collecting Process MUST NOT decode any further Data Records that are associated with the expired Common Properties. If a Common Property is refreshed with a definition that differs from the previous definition, the Collecting Process SHOULD log a warning and replace the previously received Common Property with the new one. The Common Property lifetime at the Collecting Process MUST be at least 3 times higher than the refresh timeout of the Template used to export the Common Property definition, configured on the Exporting Process.
收集过程不得解码与过期公共属性关联的任何其他数据记录。如果使用与以前定义不同的定义刷新公共属性，则收集过程应记录警告，并用新的公共属性替换以前收到的公共属性。收集进程的公共属性生存期必须至少比导出进程上配置的用于导出公共属性定义的模板的刷新超时高3倍。
The Collecting Process SHOULD accept Data Records without the associated Common Properties required to decode the Data Record. If the Common Properties have not been received at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Common Properties definitions are received. The short period of time MUST be lower than the lifetime of definitions associated with identifiers considered unique within the UDP session.
收集过程应接受没有解码数据记录所需的相关公共属性的数据记录。如果在接收数据记录时未接收到公共属性，则收集过程应在短时间内存储数据记录，并在接收到公共属性定义后对其进行解码。短时间段必须低于与UDP会话中唯一标识符关联的定义的生存期。
When the TCP connection is reset, either gracefully or abnormally, the Collecting Processes MUST delete all commonPropertiesID values and associated Common Properties data corresponding to that connection.
当TCP连接正常或异常重置时，收集进程必须删除所有commonPropertiesID值以及与该连接对应的关联公共属性数据。
If a Collection Process receives a Common Properties Withdrawal message, the Collection Process MUST expire the related Common Properties data.
如果收集进程收到公用属性撤消消息，则收集进程必须使相关公用属性数据过期。
A Flow Record can refer to one or more Common Properties sets; the use of multiple Common Properties can lead to more efficient exports. When sets of Common Properties are identified in the data, it may be found that there is more than one set of non-overlapping properties.
流记录可以引用一个或多个公共属性集；使用多个公共属性可以提高导出效率。当在数据中标识公共属性集时，可能会发现存在多个非重叠属性集。
Note that in the case of multiple Common Properties in one Data Record, the different sets of Common Properties MUST be disjoint (i.e., MUST NOT have Information Elements in common) to avoid potential collisions.
请注意，如果一个数据记录中有多个公共属性，则不同的公共属性集必须是不相交的（即，不能有公共的信息元素），以避免潜在的冲突。
Consider a set of properties "A", e.g., common sourceAddressA and sourcePortA, and another set of properties "B", e.g., destinationAddressB and destinationPortB. Figure 5 shows how this information is repeated with classical IPFIX export in several Flow Records.
考虑一组属性“A”，例如，公共源代码AddiSRSA和SoSeCurtPa，以及另一组属性“B”，例如，DestialAddiSRB和DestialPotoB。图5显示了如何在几个流记录中使用经典IPFIX导出重复此信息。
+--------+--------+---------+---------+---------------------+
|srcAddrA|srcPortA|destAddrB|destPortB| <Flow1 information> |
+--------+--------+---------+---------+---------------------+
|srcAddrA|srcPortA|destAddrC|destPortC| <Flow2 information> |
+--------+--------+---------+---------+---------------------+
|srcAddrD|srcPortD|destAddrB|destPortB| <Flow3 information> |
+--------+--------+---------+---------+---------------------+
|srcAddrD|srcPortD|destAddrC|destPortC| <Flow4 information> |
+--------+--------+---------+---------+---------------------+
| ... | ... | ... | ... | ... |
+--------+--------+---------+---------+---------------------+
+--------+--------+---------+---------+---------------------+
|srcAddrA|srcPortA|destAddrB|destPortB| <Flow1 information> |
+--------+--------+---------+---------+---------------------+
|srcAddrA|srcPortA|destAddrC|destPortC| <Flow2 information> |
+--------+--------+---------+---------+---------------------+
|srcAddrD|srcPortD|destAddrB|destPortB| <Flow3 information> |
+--------+--------+---------+---------+---------------------+
|srcAddrD|srcPortD|destAddrC|destPortC| <Flow4 information> |
+--------+--------+---------+---------+---------------------+
| ... | ... | ... | ... | ... |
+--------+--------+---------+---------+---------------------+
Figure 5: Common and Specific Properties Exported Together
图5：共同和特定属性一起导出
Besides A and B, other sets of Properties might be repeated as well (e.g., Properties C and D in the figure above).
除了A和B之外，还可以重复其他属性集（例如上图中的属性C和D）。
We can separate the Common Properties into properties A composed of sourceAddressA and sourcePortA, properties D composed of sourceAddressD and sourcePortD, properties B composed of destinationAddressB and destinationPortB, and properties C composed of destinationAddressC and destinationPortC. These four records can be expanded to four combinations of Data Records to reduce redundancy without the need to define four complete sets of Common Properties (see the figure below). The more Common Properties sets that are defined, the more combinations that are available.
我们可以将公共属性分为由sourceAddressA和sourcePortA组成的属性A、由sourceAddressD和sourcePortD组成的属性D、由destinationAddressB和destinationPortB组成的属性B以及由destinationAddressC和destinationPortC组成的属性C。这四条记录可以扩展为四种数据记录组合，以减少冗余，而无需定义四套完整的公共属性（参见下图）。定义的公共特性集越多，可用的组合就越多。
+-------------------+-----------------+-------------+
| index for prop. A | sourceAddressA | sourcePortA |
+-------------------+-----------------+-------------+
| index for prop. D | sourceAddressD | sourcePortD |
+-------------------+-----------------+-------------+
+-------------------+-----------------+-------------+
| index for prop. A | sourceAddressA | sourcePortA |
+-------------------+-----------------+-------------+
| index for prop. D | sourceAddressD | sourcePortD |
+-------------------+-----------------+-------------+
+-------------------+---------------------+------------------+
| index for prop. B | destinationAddressB | destinationPortB |
+-------------------+---------------------+------------------+
| index for prop. C | destinationAddressC | destinationPortC |
+-------------------+---------------------+------------------+
+-------------------+---------------------+------------------+
| index for prop. B | destinationAddressB | destinationPortB |
+-------------------+---------------------+------------------+
| index for prop. C | destinationAddressC | destinationPortC |
+-------------------+---------------------+------------------+
+------------------+------------------+-----------------------+
|index for prop. A |index for prop. B | <Flow1 information> |
+------------------+------------------+-----------------------+
|index for prop. A |index for prop. C | <Flow2 information> |
+------------------+------------------+-----------------------+
|index for prop. D |index for prop. B | <Flow3 information> |
+------------------+------------------+-----------------------+
|index for prop. D |index for prop. C | <Flow4 information> |
+------------------+------------------+-----------------------+
+------------------+------------------+-----------------------+
|index for prop. A |index for prop. B | <Flow1 information> |
+------------------+------------------+-----------------------+
|index for prop. A |index for prop. C | <Flow2 information> |
+------------------+------------------+-----------------------+
|index for prop. D |index for prop. B | <Flow3 information> |
+------------------+------------------+-----------------------+
|index for prop. D |index for prop. C | <Flow4 information> |
+------------------+------------------+-----------------------+
Figure 6: Multiple Common (above) and Specific Properties (below) Exported Separately
图6：分别导出的多个通用（上图）和特定属性（下图）
The advantage of the multiple Common Properties is that the objective of reducing the bandwidth is met while the number of indices is kept to a minimum. Defining an extra index for all records would not save bandwidth in the case of Figure 5 and is generally a less efficient solution.
多个公共属性的优点是，在索引数量保持最小的情况下，满足了减少带宽的目标。在图5中，为所有记录定义一个额外的索引不会节省带宽，通常是一个效率较低的解决方案。
If a set of Flow Records share multiple sets of Common Properties, multiple commonPropertiesID instances MAY be used to increase export efficiency even further, as displayed in Figure 7.
如果一组流记录共享多组公共属性，则可以使用多个commonPropertiesID实例进一步提高导出效率，如图7所示。
+--------------------------- + +---------------------+
| Common Properties | | Specific Properties | Template
| Options Template Record | | Template Record | Definition
| | | |
| Scope: commonPropertiesID1 | | commonPropertiesID1 |
| Scope: commonPropertiesID2 | | commonPropertiesID2 |
| Common Properties | | Specific Properties |
+------------+---------------+ +---------+-----------+
.............|...............................|.......................
| |
+------------v-------------+ +----------v----------+
| Common Properties | | Specific Properties |+ Exported
| Data Record |------> Data Records || Data
+------------------------- + +---------------------+| Records
+---------------------+
+--------------------------- + +---------------------+
| Common Properties | | Specific Properties | Template
| Options Template Record | | Template Record | Definition
| | | |
| Scope: commonPropertiesID1 | | commonPropertiesID1 |
| Scope: commonPropertiesID2 | | commonPropertiesID2 |
| Common Properties | | Specific Properties |
+------------+---------------+ +---------+-----------+
.............|...............................|.......................
| |
+------------v-------------+ +----------v----------+
| Common Properties | | Specific Properties |+ Exported
| Data Record |------> Data Records || Data
+------------------------- + +---------------------+| Records
+---------------------+
Figure 7: Multiple Data Reduction
图7：多重数据缩减
An Exporting Process MUST NOT export any set of Common Properties that contains, either directly or via other cascaded Common Properties, references to itself in its own definition (i.e., a circular definition). When the Collecting Process receives Common Properties that reference other Common Properties, it MUST resolve the references to Common Properties. If the Common Properties aren't available at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Common Properties are received.
导出过程不得导出任何一组公共属性，这些公共属性直接或通过其他级联公共属性在其自身定义（即循环定义）中引用自身。当收集进程接收到引用其他公共属性的公共属性时，它必须解析对公共属性的引用。如果在接收数据记录时公共属性不可用，则收集过程应在短时间内存储数据记录，并在接收到公共属性后对其进行解码。
If the Collecting Process could not decode a cascading Common Properties definition because the referenced Common Properties are not available before the short period of time, then the Collecting Process SHOULD log the error.
如果收集进程无法解码级联公共属性定义，因为引用的公共属性在短时间内不可用，则收集进程应记录错误。
If the Collecting Process could not decode a cascading Common Properties definition because it detects a circular definition, then the Collecting Process SHOULD log the error.
如果收集进程由于检测到循环定义而无法解码级联公共属性定义，则收集进程应记录错误。
Information Element ordering MUST be preserved when creating and expanding Common Properties.
创建和扩展公共属性时，必须保留信息元素顺序。
The objective of the method specified in this document is the reduction in the amount of measurement data that has to be transferred from the Exporter to the Collector. Note that the efficiency of this method may vary, as discussed in this section. In
本文件中规定的方法的目的是减少必须从出口商传输到收集者的测量数据量。请注意，如本节所述，此方法的效率可能会有所不同。在里面
addition, there might be less storage capacity required at the Collector side if the Collector decides to store the Data Records as they arrive, without reconstructing the initial Flow Record.
此外，如果收集器决定在数据记录到达时存储数据记录，而不重建初始流记录，则收集器端可能需要较少的存储容量。
On the other hand, this method requires additional resources on both the Exporter and the Collector. The Exporter has to manage Common Properties information and to assign commonPropertiesID values. The Collector has to process records described by two templates instead of just one. Additional effort is also required when post processing the measurement data, in order to correlate Flow Records with Common Properties information.
另一方面，此方法需要导出器和收集器上的额外资源。导出器必须管理公共属性信息并分配公共属性ID值。收集器必须处理由两个模板而不是一个模板描述的记录。在对测量数据进行后处理时，还需要额外的工作，以便将流量记录与公共属性信息关联起来。
The proposed method is most effective using a reliable transport protocol for the transfer of the Common Properties. Therefore, the use of PR-SCTP with full reliability or TCP is recommended for the transmission of IPFIX Messages containing Common Properties. Note that use of UDP is less efficient for the transmission of Common Properties, as they have to be resent regularly.
所提出的方法是最有效的，使用可靠的传输协议来传输公共属性。因此，建议使用完全可靠的PR-SCTP或TCP传输包含公共属性的IPFIX消息。请注意，使用UDP传输公共属性的效率较低，因为它们必须定期重新发送。
The transfer of the commonPropertiesIDs originates some overhead and might even increase the amount of exported data if the length of the commonPropertiesID field is not shorter than the length of the replaced fields.
commonPropertiesID的传输会产生一些开销，如果commonPropertiesID字段的长度不小于替换字段的长度，甚至可能会增加导出的数据量。
In cases where the range of the commonPropertiesID can be restricted, it is RECOMMENDED to apply reduced size encoding to the commonPropertiesID to achieve a further gain in bandwidth efficiency.
在可以限制commonPropertiesID的范围的情况下，建议对commonPropertiesID应用减小大小的编码以实现带宽效率的进一步增益。
While the goal of this specification is to reduce the bandwidth, the efficiency might be limited. Indeed, the efficiency gain is based on the abundance of redundant information in Flows and would be directly proportional to the reuse of the defined commonPropertiesID values, with a theoretical limit where all the Data Records would use a single commonPropertiesID. In other words, the more we reuse a commonPropertiesID value, the better the efficiency gain. While the Exporting Process can evaluate the direct gain for the Flow Records to be exported, it cannot predict whether future Flow Records would contain the information specified by active commonPropertiesID values. This implies that the efficiency factor of this specification is higher for specific applications where filtering is involved, such as one-way delay or trajectory sampling.
虽然本规范的目标是减少带宽，但效率可能会受到限制。事实上，效率增益是基于流中冗余信息的丰富程度，并与定义的commonPropertiesID值的重用成正比，理论上所有数据记录都将使用单个commonPropertiesID。换句话说，我们越是重用commonPropertiesID值，效率就越高。虽然导出过程可以评估要导出的流记录的直接增益，但无法预测未来的流记录是否包含由活动commonPropertiesID值指定的信息。这意味着对于涉及滤波的特定应用，如单向延迟或轨迹采样，本规范的效率系数更高。
Note that this technique might even lead to an increase in bandwidth usage under certain conditions. Taking into account the overhead of exporting the commonPropertiesID values, if the commonPropertiesID values are not used in future Data Records, this technique would actually increase the export bandwidth. A typical case would be the assignments of Common Properties based on past observed traffic, hoping that future Flows would contain the same characteristics.
请注意，在某些情况下，此技术甚至可能导致带宽使用率的增加。考虑到导出commonPropertiesID值的开销，如果commonPropertiesID值不在未来的数据记录中使用，此技术实际上会增加导出带宽。一个典型的例子是基于过去观测到的流量分配公共属性，希望未来的流量将包含相同的特征。
The efficiency gain depends also on the difference between the length of the replaced fields and the length of the commonPropertiesID. The shorter the length of the commonPropertiesID is (with respect to the total length of the Common Properties fields), the bigger the gain is.
效率增益还取决于被替换字段的长度与公共属性ID的长度之间的差异。公共属性ID的长度越短（相对于公共属性字段的总长度），增益越大。
The example in Appendix A.2 below uses IPFIX to export measurement data for each received packet. In that case, for a Flow of 1000 packets, the amount of data can be decreased more than 26 percent.
下面附录A.2中的示例使用IPFIX导出每个接收数据包的测量数据。在这种情况下，对于1000个数据包的流，数据量可以减少26%以上。
The same security considerations as for the IPFIX protocol [RFC5101] apply.
适用与IPFIX协议[RFC5101]相同的安全注意事项。
The authors would like to thank Guido Pohl for initiating this work and for his contribution to early versions of this document. Thanks also to Andrew Johnson, Gehrard Muenz, Brian Trammell, and Paul Aitken for their comments and feedback.
作者要感谢Guido Pohl发起这项工作，并感谢他对本文件早期版本的贡献。还要感谢安德鲁·约翰逊、格哈德·穆恩斯、布莱恩·特拉梅尔和保罗·艾特肯的评论和反馈。
[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月。
[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月。
[RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476]Claise，B.，编辑，“数据包采样（PSAMP）协议规范”，RFC 54762009年3月。
[PSAMP-MIB] Dietz, T., Ed. and B. Claise, "Definitions of Managed Objects for Packet Sampling", Work in Progress, June 2006.
[PSAMP-MIB]Dietz，T.，Ed.和B.Claise，“数据包采样管理对象的定义”，正在进行的工作，2006年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（SCTP）部分可靠性扩展”，RFC 3758，2004年5月。
[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月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[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月。
[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月。
[RFC5474] Duffield, N., Ed., "A Framework for Packet Selection and Reporting", RFC 5474, March 2009.
[RFC5474]Duffield，N.，Ed.“数据包选择和报告框架”，RFC 5474，2009年3月。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5475]Zseby，T.，Molina，M.，Duffield，N.，Niccolini，S.，和F.Raspall，“IP数据包选择的采样和过滤技术”，RFC 5475，2009年3月。
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5477]Dietz，T.，Claise，B.，Aitken，P.，Dressler，F.，和G.Carle，“数据包抽样出口的信息模型”，RFC 5477，2009年3月。
In this section, we show how Flow information can be exported efficiently using the method described in this document. Let's suppose we have to periodically export data about two IPv6 Flows.
在本节中，我们将展示如何使用本文档中描述的方法高效导出流信息。假设我们必须定期导出关于两个IPv6流的数据。
In this example, we report the following information:
在本例中，我们报告以下信息：
Flow| dstIPv6Address | dst- |nPkts|nBytes
| | Port | |
----------------------------------------------------------------
A |2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80 | 30 | 6000
| | | |
A |2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80 | 50 | 9500
| | | |
B |2001:DB8:80AD:5800:0058:00AA:00B7:AF2B | 1932 | 60 | 8000
| | | |
A |2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80 | 40 | 6500
| | | |
A |2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80 | 60 | 9500
| | | |
B |2001:DB8:80AD:5800:0058:00AA:00B7:AF2B | 1932 | 54 | 7600
Flow| dstIPv6Address | dst- |nPkts|nBytes
| | Port | |
----------------------------------------------------------------
A |2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80 | 30 | 6000
| | | |
A |2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80 | 50 | 9500
| | | |
B |2001:DB8:80AD:5800:0058:00AA:00B7:AF2B | 1932 | 60 | 8000
| | | |
A |2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80 | 40 | 6500
| | | |
A |2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80 | 60 | 9500
| | | |
B |2001:DB8:80AD:5800:0058:00AA:00B7:AF2B | 1932 | 54 | 7600
Figure 8: Flow Information Example
图8：流信息示例
The Common Properties in this case are the destination IPv6 address and the destination port. We first define an Options Template that contains the following Information Elements:
本例中的公共属性是目标IPv6地址和目标端口。我们首先定义一个包含以下信息元素的选项模板：
o Scope: commonPropertiesID in [RFC5102], with a type of 137 and a length of 8 octets.
o 范围：[RFC5102]中的commonPropertiesID，类型为137，长度为8个八位字节。
o The destination IPv6 address: destinationIPv6Address in [RFC5102], with a type of 28 and a length of 16 octets.
o 目标IPv6地址：[RFC5102]中的destinationIPV6地址，类型为28，长度为16个八位字节。
o The destination port: destinationTransportPort in [RFC5102], with a type of 11, and a length of 2 octets.
o 目标端口：[RFC5102]中的destinationTransportPort，类型为11，长度为2个八位字节。
Figure 9 shows the Options Template defining the Common Properties with commonPropertiesID as scope:
图9显示了将commonPropertiesID定义为作用域的公共属性的选项模板：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 24 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field count = 1 |0| commonPropertiesID = 137 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 8 |0| destinationIPv6Address = 28|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 16 |0|destinationTransportPort = 11|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | (Padding) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 24 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field count = 1 |0| commonPropertiesID = 137 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 8 |0| destinationIPv6Address = 28|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 16 |0|destinationTransportPort = 11|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | (Padding) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Common Properties Options Template
图9：公共属性选项模板
The Specific Properties Template consists of the information not contained in the Options Templates, i.e., Flow-specific information; in this case, the number of packets and the number of bytes to be reported. Additionally, this Template contains the commonPropertiesID. In Data Records, the value of this field will contain one of the unique indices of the Option Records exported before. It contains the following Information Elements (see also Figure 10):
特定属性模板包括选项模板中未包含的信息，即流特定信息；在这种情况下，要报告的数据包数和字节数。此外，此模板还包含commonPropertiesID。在数据记录中，此字段的值将包含之前导出的选项记录的唯一索引之一。它包含以下信息元素（另请参见图10）：
o commonPropertiesID with a length of 8 octets.
o commonPropertiesID，长度为8个八位字节。
o The number of packets of the Flow: inPacketDeltaCount in [RFC5102], with a length of 4 octets.
o 流的数据包数：[RFC5102]中的inPacketDeltaCount，长度为4个八位字节。
o The number of octets of the Flow: inOctetDeltaCount in [RFC5102], with a length of 4 octets.
o 流的八位字节数：[RFC5102]中的inOctetDeltaCount，长度为4个八位字节。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 20 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 258 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| commonPropertiesID = 137 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inPacketDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 20 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 258 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| commonPropertiesID = 137 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inPacketDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Specific Properties Template
图10：特定属性模板
Considering the data shown at the beginning of this example, the following two Data Records will be exported:
考虑到本示例开头显示的数据，将导出以下两个数据记录：
Common- | dstAddress | dst-
PropertiesID | | Port
-------------+-----------------------------------------+-------
101 | 2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80
| |
102 | 2001:DB8:80AD:5800:0058:00AA:00B7:AF2B | 1932
Common- | dstAddress | dst-
PropertiesID | | Port
-------------+-----------------------------------------+-------
101 | 2001:DB8:80AD:5800:0058:0800:2023:1D71 | 80
| |
102 | 2001:DB8:80AD:5800:0058:00AA:00B7:AF2B | 1932
Figure 11
图11
The Data Records reporting the Common Properties will look like:
报告公共属性的数据记录如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 257 | Length = 60 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- 101 -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- 2001:DB8:80AD:5800:0058:0800:2023:1D71 -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 80 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+
| 102 |
+- -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+
| |
+- -+
| 2001:DB8:80AD:5800:0058:00AA:00B7:AF2B |
+- -+
| |
+- -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 1932 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 257 | Length = 60 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- 101 -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- 2001:DB8:80AD:5800:0058:0800:2023:1D71 -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 80 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+
| 102 |
+- -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+
| |
+- -+
| 2001:DB8:80AD:5800:0058:00AA:00B7:AF2B |
+- -+
| |
+- -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 1932 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Data Records reporting Common Properties
图12：报告公共属性的数据记录
The Data Records will in turn be:
数据记录将依次为：
commonPropertiesID | inPacketDeltaCount | inOctetDeltaCount
---------------------------------------------------------------
101 | 30 | 6000
101 | 50 | 9500
102 | 60 | 8000
101 | 40 | 6500
101 | 60 | 9500
102 | 54 | 7600
commonPropertiesID | inPacketDeltaCount | inOctetDeltaCount
---------------------------------------------------------------
101 | 30 | 6000
101 | 50 | 9500
102 | 60 | 8000
101 | 40 | 6500
101 | 60 | 9500
102 | 54 | 7600
Figure 13
图13
Figure 14 shows the first Data Record listed in the table:
图14显示了表中列出的第一条数据记录：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 258 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- 101 -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 30 | 6000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 258 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- 101 -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 30 | 6000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Data Record reporting Common Properties
图14：报告公共属性的数据记录
An example of the per-packet data reduction is the measurement of One-Way Delay (OWD), where the exact same specific packet must be observed at the source and destination of the path to be measured. The OWD is computed by subtracting the time of observation of the same packet at the two end-points with synchronized clocks. As the OWD is measured for a specific application on which a Service Level Agreement (SLA) is bound, this translates into the observation of multiple packets with Specific Properties. In order to match the identical packet at both Observation Points, a series of packets with a set of properties (for example, all the packets of a specific source and destination IP addresses, of a specific Diffserv codepoint (DSCP) value, and of a specific destination transport port) must be observed at both ends of the measurements. This implies that the source and destination must export a series of Flow Records composed of two types of information: some common information for all packets, and some unique information about each packet in order to generate a unique identifier for each packet passing this Observation Point (for example, a hash value on the invariant fields of the packet). So, the source and destination composing the measurement's end-points can individually and independently apply the redundancy technique described in this document in order to save some bandwidth for their respective Flow Records exports.
每包数据减少的一个例子是单向延迟（OWD）的测量，其中必须在要测量的路径的源和目的地观察到完全相同的特定包。OWD的计算方法是用同步时钟减去两个端点处相同数据包的观测时间。由于OWD是针对绑定了服务级别协议（SLA）的特定应用程序测量的，因此这就转化为对具有特定属性的多个数据包的观察。为了在两个观察点上匹配相同的数据包，必须在测量的两端观察一系列具有一组属性的数据包（例如，特定源和目标IP地址、特定Diffserv codepoint（DSCP）值和特定目标传输端口的所有数据包）。这意味着源和目的地必须导出一系列由两类信息组成的流记录：所有数据包的一些公共信息和每个数据包的一些唯一信息，以便为通过该观察点的每个数据包生成唯一标识符（例如，数据包不变字段上的散列值）。因此，构成测量终点的源和目的地可以单独且独立地应用本文档中描述的冗余技术，以便为各自的流记录导出节省一些带宽。
The Templates required for exporting measurement data of this kind are illustrated in the figures below. Figure 15 shows the Options Template containing the information concerning Flows using the commonPropertiesID as scope. In the Common Properties Template, we export the following Information Elements:
导出此类测量数据所需的模板如下图所示。图15显示了包含关于使用commonPropertiesID作为作用域的流的信息的选项模板。在公共属性模板中，我们导出以下信息元素：
o The source IPv4 Address: sourceIPv4Address in [RFC5102], with a type of 8 and a length of 4 octets.
o 源IPv4地址：[RFC5102]中的sourceIPv4Address，类型为8，长度为4个八位字节。
o The destination IPv4 Address: destinationIPv4Address in [RFC5102], with a type of 12 and a length of 4 octets.
o 目标IPv4地址：[RFC5102]中的destinationIPv4Address，类型为12，长度为4个八位字节。
o The Class of Service field: ClassOfServiceIPv4 in [RFC5102], with a type of 5 and a length of 1 octet.
o 服务类别字段：[RFC5102]中的ClassOfServiceIPv4]，类型为5，长度为1个八位字节。
o The Protocol Identifier: protocolIdentifier in [RFC5102], with a type of 4 and a length of 1 octet.
o 协议标识符：[RFC5102]中的protocolIdentifier，类型为4，长度为1个八位字节。
o The source port: sourceTransportPort in [RFC5102], with a type of 7 and a length of 2 octets.
o 源端口：[RFC5102]中的sourceTransportPort，类型为7，长度为2个八位字节。
o The destination port: destinationTransportPort in [RFC5102], with a type of 11 and a length of 2 octets.
o 目标端口：[RFC5102]中的destinationTransportPort，类型为11，长度为2个八位字节。
The commonPropertiesID Information Element is used as the Scope Field.
commonPropertiesID信息元素用作范围字段。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 40 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field count = 1 |0| commonPropertiesID = 137 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0| sourceIPv4Address = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| destinationIPv4Address = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| classOfServiceIPv4 = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| protocolIdentifier = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| transportSourcePort = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0|transportDestinationPort = 11|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 40 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field count = 1 |0| commonPropertiesID = 137 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0| sourceIPv4Address = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| destinationIPv4Address = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| classOfServiceIPv4 = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| protocolIdentifier = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |0| transportSourcePort = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0|transportDestinationPort = 11|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Example Flow Properties Template
图15：流属性模板示例
For passive OWD measurement, the Packet Properties Template or Specific Properties Template consists of at least the timestamp and packet ID. Additionally, this template contains a commonPropertiesID field to associate the packet with a Flow.
对于被动OWD测量，数据包属性模板或特定属性模板至少包含时间戳和数据包ID。此外，该模板包含一个commonPropertiesID字段，用于将数据包与流关联。
Figure 16 displays the template with the packet properties. In this example, we export the following Information Elements:
图16显示了带有数据包属性的模板。在本例中，我们导出以下信息元素：
o commonPropertiesID. In this case, reduced size encoding is used, and the Information Element is declared with a length of 4 octets instead of 8.
o 公共财产。在这种情况下，使用了缩减大小编码，并且信息元素的声明长度为4个八位字节，而不是8个八位字节。
o The packet timestamp: observationTimeMilliseconds in the PSAMP information model [RFC5477], with a type of 323 and a length of 8 octets.
o 数据包时间戳：PSAMP信息模型[RFC5477]中的ObservationTime毫秒，类型为323，长度为8个八位字节。
o digestHashValue in the PSAMP information model [RFC5477], with a type of 326 and a length of 8 octets.
o PSAMP信息模型[RFC5477]中的digestHashValue，类型为326，长度为8个八位字节。
o The packet length: ipTotalLength in the IPFIX information model [RFC5102], with a type of 224 and a length of 8 octets.
o 数据包长度：IPFIX信息模型[RFC5102]中的ipTotalLength，类型为224，长度为8个八位字节。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 36 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| commonPropertiesID = 137 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| observationTimeMillis.= 323 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| digestHashValue = 326 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipTotalLength = 224 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 36 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| commonPropertiesID = 137 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| observationTimeMillis.= 323 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| digestHashValue = 326 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipTotalLength = 224 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Example Packet Properties Template
图16：示例数据包属性模板
At the collection point, packet records from the two measurement points are gathered and correlated by means of the packet ID. The resulting delay Data Records are exported in a similar manner as the packet data. One-Way Delay data is associated with Flow information by the commonPropertiesID field. The OWD properties contain the Packet Pair ID (which is the packet ID of the two contributing packet
在收集点，来自两个测量点的数据包记录通过数据包ID进行收集和关联。产生的延迟数据记录以与数据包数据类似的方式导出。单向延迟数据通过commonPropertiesID字段与流量信息关联。OWD属性包含数据包对ID（这是两个贡献数据包的数据包ID）
records), the timestamp of the packet passing the reference monitor point in order to reconstruct a time series, the calculated delay value, and the commonPropertiesID.
记录），通过参考监控点的数据包的时间戳，以便重建时间序列、计算的延迟值和公共属性ID。
In this example, using IPFIX to export the measurement data for each received packet, 38 bytes have to be transferred (sourceAddressV4=4, destinationAddressV4=4, classOfServiceV4=1, protocolIdentifier=1, sourceTransportPort=2, destinationTransportPort=2, observationTimeMilliseconds=8, digestHashValue=8, ipTotalLength=8). Without considering the IPFIX protocol overhead, a Flow of 1000 packets produces 38000 bytes of measurement data. Using the proposed optimization, each packet produces an export of only 28 bytes (observationTimeMilliseconds=8, digestHashValue=8, ipTotalLength=8, commonPropertiesID=4). The export of the Flow information produces 18 bytes (sourceAddressV4=4, destinationAddressV4=4, classOfServiceV4=1, protocolIdentifier=1, sourceTransportPort=2, destinationTransportPort=2, commonPropertiesID=4). For a Flow of 1000 packets, this sums to 28018 bytes. This is a decrease of more than 26 percent.
在本例中，使用IPFIX导出每个接收到的数据包的测量数据时，必须传输38个字节（sourceAddressV4=4，destinationAddressV4=4，classOfServiceV4=1，protocolIdentifier=1，sourceTransportPort=2，destinationTransportPort=2，ObservationTime毫秒=8，digestHashValue=8，ipTotalLength=8）。在不考虑IPFIX协议开销的情况下，1000个数据包的流产生38000字节的测量数据。使用建议的优化，每个数据包只产生28字节的导出（ObservationTimeMillenses=8，digestHashValue=8，ipTotalLength=8，commonPropertiesID=4）。流信息的导出产生18个字节（sourceAddressV4=4，destinationAddressV4=4，classOfServiceV4=1，protocolIdentifier=1，sourceTransportPort=2，destinationTransportPort=2，commonPropertiesID=4）。对于1000个数据包的流，其总和为28018字节。降幅超过26%。
This section shows an example commonPropertiesID Withdrawal message. Figure 17 depicts the Options Template Record with the commonPropertiesID as unique scope field, and no non-scope fields.
本节显示commonPropertiesID撤销消息的示例。图17描述了选项模板记录，其中commonPropertiesID是唯一的作用域字段，没有非作用域字段。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 14 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 259 | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field count = 1 |0| commonPropertiesID 137 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 14 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 259 | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field count = 1 |0| commonPropertiesID 137 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Example Common Properties Withdrawal Template
图17：通用属性提取模板示例
Figure 18 shows the Option Data Record withdrawing commonPropertiesID N:
图18显示了提取commonPropertiesID N的选项数据记录：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 259 | Length = 12 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- N -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 259 | Length = 12 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- N -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Record Withdrawing commonPropertiesID N
图18：记录撤消公共属性ID N
Authors' Addresses
作者地址
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland
Elisa Boschi Hitachi Europe，转交ETH苏黎世Gloriastrasse 35 8092苏黎世瑞士
Phone: +41 44 6327057
EMail: elisa.boschi@hitachi-eu.com
Phone: +41 44 6327057
EMail: elisa.boschi@hitachi-eu.com
Lutz Mark Fraunhofer IFAM Wiener Str. 12 28359 Bremen Germany
德国不莱梅卢茨马克·弗劳恩霍夫伊法姆·维纳大街12 28359号
Phone: +49 421 2246206
EMail: lutz.mark@ifam.fraunhofer.de
Phone: +49 421 2246206
EMail: lutz.mark@ifam.fraunhofer.de
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 Belgium
比利时Benoit Claise思科系统有限公司De Kleetlaan 6a b1 Diegem 1813
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Phone: +32 2 704 5622
EMail: bclaise@cisco.com