Internet Engineering Task Force (IETF) B. Claise, Ed.
Request for Comments: 7012 Cisco Systems, Inc.
Obsoletes: 5102 B. Trammell, Ed.
Category: Standards Track ETH Zurich
ISSN: 2070-1721 September 2013
Internet Engineering Task Force (IETF) B. Claise, Ed.
Request for Comments: 7012 Cisco Systems, Inc.
Obsoletes: 5102 B. Trammell, Ed.
Category: Standards Track ETH Zurich
ISSN: 2070-1721 September 2013
Information Model for IP Flow Information Export (IPFIX)
IP流信息导出（IPFIX）的信息模型
Abstract
摘要
This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102.
本文档定义了IP流信息导出（IPFIX）协议信息模型的数据类型和管理策略。该信息模型作为IANA“IPFIX信息元素”注册表进行维护，初始内容由RFC 5102定义。IPFIX协议使用此信息模型对测量的流量信息以及与流量观测点、流量计量过程和导出过程相关的信息进行编码。尽管此模型是为IPFIX协议开发的，但它是以开放的方式定义的，允许在其他协议、接口和应用程序中轻松使用。本文件淘汰了RFC 5102。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7012.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7012.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Changes since RFC 5102 .....................................4
1.2. IPFIX Documents Overview ...................................4
2. Properties of IPFIX Protocol Information Elements ...............5
2.1. Information Element Specification Template .................5
2.2. Scope of Information Elements ..............................7
2.3. Naming Conventions for Information Elements ................8
3. Type Space ......................................................9
3.1. Abstract Data Types ........................................9
3.1.1. unsigned8 ...........................................9
3.1.2. unsigned16 ..........................................9
3.1.3. unsigned32 ..........................................9
3.1.4. unsigned64 ..........................................9
3.1.5. signed8 ............................................10
3.1.6. signed16 ...........................................10
3.1.7. signed32 ...........................................10
3.1.8. signed64 ...........................................10
3.1.9. float32 ............................................10
3.1.10. float64 ...........................................10
3.1.11. boolean ...........................................10
3.1.12. macAddress ........................................10
3.1.13. octetArray ........................................10
3.1.14. string ............................................11
3.1.15. dateTimeSeconds ...................................11
3.1.16. dateTimeMilliseconds ..............................11
3.1.17. dateTimeMicroseconds ..............................11
3.1.18. dateTimeNanoseconds ...............................11
3.1.19. ipv4Address .......................................11
3.1.20. ipv6Address .......................................11
1. Introduction ....................................................3
1.1. Changes since RFC 5102 .....................................4
1.2. IPFIX Documents Overview ...................................4
2. Properties of IPFIX Protocol Information Elements ...............5
2.1. Information Element Specification Template .................5
2.2. Scope of Information Elements ..............................7
2.3. Naming Conventions for Information Elements ................8
3. Type Space ......................................................9
3.1. Abstract Data Types ........................................9
3.1.1. unsigned8 ...........................................9
3.1.2. unsigned16 ..........................................9
3.1.3. unsigned32 ..........................................9
3.1.4. unsigned64 ..........................................9
3.1.5. signed8 ............................................10
3.1.6. signed16 ...........................................10
3.1.7. signed32 ...........................................10
3.1.8. signed64 ...........................................10
3.1.9. float32 ............................................10
3.1.10. float64 ...........................................10
3.1.11. boolean ...........................................10
3.1.12. macAddress ........................................10
3.1.13. octetArray ........................................10
3.1.14. string ............................................11
3.1.15. dateTimeSeconds ...................................11
3.1.16. dateTimeMilliseconds ..............................11
3.1.17. dateTimeMicroseconds ..............................11
3.1.18. dateTimeNanoseconds ...............................11
3.1.19. ipv4Address .......................................11
3.1.20. ipv6Address .......................................11
3.1.21. basicList .........................................11
3.1.22. subTemplateList ...................................11
3.1.23. subTemplateMultiList ..............................12
3.2. Data Type Semantics .......................................12
3.2.1. quantity ...........................................12
3.2.2. totalCounter .......................................12
3.2.3. deltaCounter .......................................12
3.2.4. identifier .........................................13
3.2.5. flags ..............................................13
4. Information Element Identifiers ................................13
5. Information Elements ...........................................14
6. Extending the Information Model ................................15
7. IANA Considerations ............................................15
7.1. IPFIX Information Elements ................................16
7.2. MPLS Label Type Identifier ................................17
7.3. XML Namespace and Schema ..................................17
7.4. Addition, Revision, and Deprecation .......................18
8. Security Considerations ........................................19
9. Acknowledgments ................................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................20
Contributors ......................................................23
3.1.21. basicList .........................................11
3.1.22. subTemplateList ...................................11
3.1.23. subTemplateMultiList ..............................12
3.2. Data Type Semantics .......................................12
3.2.1. quantity ...........................................12
3.2.2. totalCounter .......................................12
3.2.3. deltaCounter .......................................12
3.2.4. identifier .........................................13
3.2.5. flags ..............................................13
4. Information Element Identifiers ................................13
5. Information Elements ...........................................14
6. Extending the Information Model ................................15
7. IANA Considerations ............................................15
7.1. IPFIX Information Elements ................................16
7.2. MPLS Label Type Identifier ................................17
7.3. XML Namespace and Schema ..................................17
7.4. Addition, Revision, and Deprecation .......................18
8. Security Considerations ........................................19
9. Acknowledgments ................................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................20
Contributors ......................................................23
The IP Flow Information Export (IPFIX) protocol serves as a means for transmitting information related to network traffic measurement. The IPFIX Protocol Specification [RFC7011] defines how Information Elements are transmitted and also specifies the encoding of a set of basic data types for these Information Elements. However, the list of Information Elements that can be transmitted by the protocol, such as Flow attributes (source IP address, number of packets, etc.) and information about the Metering Process and Exporting Process (packet Observation Point, sampling rate, Flow timeout interval, etc.), is not specified in [RFC7011].
IP流信息导出（IPFIX）协议用作传输与网络流量测量相关的信息的手段。IPFIX协议规范[RFC7011]定义了信息元素的传输方式，并规定了这些信息元素的一组基本数据类型的编码。然而，[RFC7011]中未规定协议可传输的信息元素列表，例如流属性（源IP地址、数据包数量等）以及关于计量过程和导出过程的信息（数据包观察点、采样率、流超时间隔等）。
The IANA "IPFIX Information Elements" registry [IANA-IPFIX] is the current complete reference for IPFIX Information Elements. The initial values for this registry were provided by [RFC5102].
IANA“IPFIX信息元素”注册表[IANA-IPFIX]是IPFIX信息元素的当前完整参考。此注册表的初始值由[RFC5102]提供。
This document complements the IPFIX Protocol Specification [RFC7011] by providing an overview of the IPFIX information model and specifying data types for it. IPFIX-specific terminology used in this document is defined in Section 2 of [RFC7011]. As in [RFC7011], these IPFIX-specific terms have the first letter of a word capitalized when used in this document.
本文档对IPFIX协议规范[RFC7011]进行了补充，概述了IPFIX信息模型并指定了其数据类型。[RFC7011]第2节定义了本文件中使用的IPFIX专用术语。与[RFC7011]一样，这些IPFIX专用术语在本文件中使用时，单词的首字母大写。
The use of the term 'information model' is not fully in line with the definition of this term in [RFC3444], as the IPFIX information model does not specify relationships between Information Elements, nor does it specify a concrete encoding of Information Elements. For an encoding suitable for use with the IPFIX protocol, see [RFC7011]. Besides the encoding used by the IPFIX protocol, other encodings of IPFIX Information Elements can be applied, for example, XML-based encodings.
术语“信息模型”的使用与[RFC3444]中该术语的定义不完全一致，因为IPFIX信息模型未指定信息元素之间的关系，也未指定信息元素的具体编码。有关适用于IPFIX协议的编码，请参阅[RFC7011]。除了IPFIX协议使用的编码之外，还可以应用IPFIX信息元素的其他编码，例如，基于XML的编码。
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]中所述进行解释。
This document obsoletes the Proposed Standard revision of the IPFIX information model specification [RFC5102]. The following changes have been made to this document with respect to the previous document:
本文件废除了IPFIX信息模型规范[RFC5102]的拟议标准修订版。与上一份文件相比，本文件做了以下更改：
- At the time of this publication, technical and editorial errata reported for [RFC5102] have been reviewed and addressed as needed.
- 在本出版物出版时，已根据需要对[RFC5102]报告的技术和编辑勘误表进行了审查和处理。
- All references to [RFC5101] have been updated to [RFC7011], reflecting changes to [RFC5101].
- 对[RFC5101]的所有引用已更新为[RFC7011]，反映了对[RFC5101]的更改。
- Information Element definitions have been removed, as the reference for these is now [IANA-IPFIX]; a historical note on categorizations of Information Elements as defined in [RFC5102] has been retained in Section 5.
- 信息元素定义已被删除，因为这些定义的参考现在是[IANA-IPFIX]；第5节保留了[RFC5102]中定义的信息元素分类的历史注释。
- The process for modifying [IANA-IPFIX] has been improved and is now described in [RFC7013]; Section 6 has been updated accordingly, and a new Section 7.3 provides IANA considerations for this process.
- 修改[IANA-IPFIX]的过程已得到改进，现参见[RFC7013]；第6节已相应更新，新的第7.3节提供了IANA对此过程的注意事项。
- Definitions of timestamp data types have been clarified.
- 时间戳数据类型的定义已经澄清。
- Appendices A and B have been removed.
- 附录A和B已删除。
The IPFIX protocol provides network administrators with access to network flow information. The architecture for the export of measured flow information out of an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], per the requirements defined in [RFC3917]. The IPFIX Protocol Specification [RFC7011]
IPFIX协议为网络管理员提供了访问网络流信息的权限。[RFC5470]根据[RFC3917]中定义的要求，将测量流量信息从IPFIX导出过程导出到收集过程的架构在[RFC5470]中定义。IPFIX协议规范[RFC7011]
defines how IPFIX Data Records and templates are carried via a number of transport protocols from IPFIX Exporting Processes to IPFIX Collecting Processes.
定义如何通过多个传输协议将IPFIX数据记录和模板从IPFIX导出进程传送到IPFIX收集进程。
Four IPFIX optimizations/extensions are currently specified: a bandwidth-saving method for the IPFIX protocol [RFC5473], an efficient method for exporting bidirectional flows [RFC5103], a method for the definition and export of complex data structures [RFC6313], and the specification of the Protocol on IPFIX Mediators [IPFIX-MED-PROTO] based on the IPFIX Mediation Framework [RFC6183].
目前指定了四种IPFIX优化/扩展：IPFIX协议的带宽节约方法[RFC5473]、导出双向流的有效方法[RFC5103]、定义和导出复杂数据结构的方法[RFC6313]、以及IPFIX中介协议的规范[IPFIX-MED-PROTO]基于IPFIX中介框架[RFC6183]。
IPFIX has a formal description of IPFIX Information Elements -- their names, data types, and additional semantic information -- as specified in this document. The export of the Information Element types is specified in [RFC5610].
IPFIX对IPFIX信息元素有一个正式的描述——它们的名称、数据类型和附加的语义信息——如本文所述。[RFC5610]中规定了信息元素类型的导出。
[RFC6728] specifies a data model for configuring and monitoring devices that are IPFIX and Packet Sampling (PSAMP) compliant using the Network Configuration Protocol (NETCONF), while [RFC6615] specifies MIB modules for monitoring.
[RFC6728]指定用于使用网络配置协议（NETCONF）配置和监视符合IPFIX和数据包采样（PSAMP）的设备的数据模型，而[RFC6615]指定用于监视的MIB模块。
In terms of development, [RFC5153] provides guidelines for the implementation and use of the IPFIX protocol, while [RFC5471] provides guidelines for testing.
在开发方面，[RFC5153]提供了IPFIX协议的实施和使用指南，[RFC5471]提供了测试指南。
Finally, [RFC5472] describes what types of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks.
最后，[RFC5472]描述了什么类型的应用程序可以使用IPFIX协议，以及它们如何使用提供的信息。它还展示了IPFIX框架与其他体系结构和框架的关系。
Information in messages of the IPFIX protocol is modeled in terms of Information Elements of the IPFIX information model. The IPFIX Information Elements mentioned in Section 5 are specified in [IANA-IPFIX].
IPFIX协议消息中的信息根据IPFIX信息模型的信息元素进行建模。[IANA-IPFIX]中规定了第5节中提到的IPFIX信息元素。
All Information Elements specified for the IPFIX protocol MUST have the following properties defined:
为IPFIX协议指定的所有信息元素必须定义以下属性：
name - A unique and meaningful name for the Information Element.
名称-信息元素的唯一且有意义的名称。
elementId - A numeric identifier of the Information Element. If this identifier is used without an enterprise identifier (see [RFC7011] and the definition of enterpriseId listed below), then it is globally unique, and the list of allowed values is administered by IANA. It is used for compact identification of an Information Element when encoding Templates in the protocol.
elementId—信息元素的数字标识符。如果使用该标识符时没有企业标识符（请参见[RFC7011]和下面列出的enterpriseId定义），则该标识符是全局唯一的，且允许值列表由IANA管理。它用于在协议中编码模板时对信息元素进行紧凑标识。
description - The semantics of this Information Element. Describes how this Information Element is derived from the Flow or other information available to the observer. Information Elements of dataType string or octetArray that have length constraints (fixed length, minimum and/or maximum length) MUST note these constraints in their descriptions.
描述-此信息元素的语义。描述如何从观察者可用的流或其他信息中派生此信息元素。具有长度约束（固定长度、最小和/或最大长度）的数据类型字符串或八进制数组的信息元素必须在其描述中注明这些约束。
dataType - One of the types listed in Section 3.1 of this document or registered in the IANA "IPFIX Information Element Data Types" subregistry. The type space for attributes is constrained to facilitate implementation. The existing type space encompasses most primitive types used in modern programming languages, as well as some derived types (such as ipv4Address) that are common to this domain.
数据类型-本文件第3.1节中列出的类型之一，或在IANA“IPFIX信息元素数据类型”子区中注册的类型之一。属性的类型空间受到约束，以便于实现。现有的类型空间包含现代编程语言中使用的大多数基本类型，以及该域常见的一些派生类型（如ipv4Address）。
status - The status of the specification of this Information Element. Allowed values are 'current' and 'deprecated'. All newly defined Information Elements have 'current' status. The process for moving Information Elements to the 'deprecated' status is defined in Section 5.3 of [RFC7013].
状态-此信息元素规范的状态。允许的值为“当前”和“已弃用”。所有新定义的信息元素都具有“当前”状态。[RFC7013]第5.3节定义了将信息元素移动到“弃用”状态的过程。
Enterprise-specific Information Elements MUST have the following property defined:
特定于企业的信息元素必须定义以下属性：
enterpriseId - Enterprises may wish to define Information Elements without registering them with IANA, for example, for enterprise-internal purposes. For such Information Elements, the Information Element identifier described above is not sufficient when the Information Element is used outside the enterprise. If specifications of enterprise-specific Information Elements are made public and/or if enterprise-specific identifiers are used by the IPFIX protocol outside the enterprise, then the enterprise-specific identifier MUST be made globally unique by combining it with an enterprise identifier. Valid values for the enterpriseId are defined by IANA as Structure of Management Information (SMI) network management private enterprise numbers, defined at [IANA-PEN].
enterpriseId-例如，出于企业内部目的，企业可能希望在不向IANA注册的情况下定义信息元素。对于此类信息元素，当信息元素在企业外部使用时，上述信息元素标识符是不够的。如果企业特定信息元素的规范已公开和/或如果企业外部的IPFIX协议使用了企业特定标识符，则必须通过将企业特定标识符与企业标识符组合，使其具有全局唯一性。IANA将enterpriseId的有效值定义为[IANA-PEN]中定义的管理信息结构（SMI）网络管理私有企业编号。
All Information Elements specified for the IPFIX protocol either in this document or by any future extension MAY have the following properties defined:
本文档中或任何未来扩展为IPFIX协议指定的所有信息元素可能定义了以下属性：
dataTypeSemantics - The integral types are qualified by additional semantic details. Valid values for the data type semantics are either specified in Section 3.2 of this document or will be specified in a future extension of the information model.
dataTypeSemantics-整数类型由附加的语义细节限定。数据类型语义的有效值在本文档第3.2节中指定，或者将在信息模型的未来扩展中指定。
units - If the Information Element is a measure of some kind, the units identify what the measure is.
单位-如果信息元素是某种度量，则单位识别度量是什么。
range - Some Information Elements may only be able to take on a restricted set of values that can be expressed as a range (e.g., 0 through 511, inclusive). If this is the case, the valid inclusive range SHOULD be specified; values for this Information Element outside the range are invalid and MUST NOT be exported.
范围-某些信息元素可能只能接受一组有限的值，这些值可以表示为一个范围（例如，0到511，包括）。如果是这种情况，则应指定有效的包含范围；超出范围的此信息元素的值无效，不能导出。
reference - Identifies additional specifications that more precisely define this item or provide additional context for its use.
参考-确定更精确定义此项或为其使用提供附加上下文的附加规范。
The following two Information Element properties are defined to allow the management of an Information Elements registry with Information Element definitions that may be updated over time, per the process defined in Section 5.2 of [RFC7013]:
根据[RFC7013]第5.2节中定义的流程，定义了以下两个信息元素属性，以允许管理信息元素注册表，其中的信息元素定义可能会随着时间的推移而更新：
revision - The revision number of an Information Element, starting at 0 for Information Elements at time of definition and incremented by one for each revision.
修订-信息元素的修订号，定义时信息元素从0开始，每次修订增加1。
date - The date of the entry of this revision of the Information Element into the registry.
日期-将此版本的信息元素输入注册表的日期。
A template for specifying Information Elements is given in Section 9.1 of [RFC7013].
[RFC7013]第9.1节给出了指定信息元素的模板。
By default, most Information Elements have a scope specified in their definitions. Within Data Records defined by Options Templates, the IPFIX protocol allows further limiting of the Information Element scope. The new scope is specified by one or more scope fields and defined as the combination of all specified scope values; see Section 3.4.2.1 on IPFIX scopes in [RFC7011].
默认情况下，大多数信息元素都在其定义中指定了范围。在由选项模板定义的数据记录中，IPFIX协议允许进一步限制信息元素的范围。新范围由一个或多个范围字段指定，并定义为所有指定范围值的组合；参见[RFC7011]中关于IPFIX范围的第3.4.2.1节。
The following naming conventions were used for naming Information Elements in this document. It is recommended that extensions of the model use the same conventions.
以下命名约定用于命名本文档中的信息元素。建议模型的扩展使用相同的约定。
o Names of Information Elements SHOULD be descriptive.
o 信息元素的名称应具有描述性。
o Names of Information Elements MUST be unique within the "IPFIX Information Elements" registry [IANA-IPFIX]. Enterprise-specific Information Elements SHOULD be prefixed with a vendor name.
o 在“IPFIX信息元素”注册表[IANA-IPFIX]中，信息元素的名称必须是唯一的。特定于企业的信息元素应以供应商名称作为前缀。
o Names of Information Elements MUST start with lowercase letters.
o 信息元素的名称必须以小写字母开头。
o Composed names MUST use capital letters for the first letter of each component (except for the first one). All other letters are lowercase, even for acronyms. Exceptions are made for acronyms containing a mixture of lowercase and capital letters, such as 'IPv4' and 'IPv6'. Examples are "sourceMacAddress" and "destinationIPv4Address".
o 组合名称必须使用大写字母作为每个组件的第一个字母（第一个除外）。所有其他字母都是小写的，即使是首字母缩写。包含小写字母和大写字母的首字母缩写词除外，如“IPv4”和“IPv6”。例如“sourceMacAddress”和“destinationIPv4Address”。
o Middleboxes [RFC3234] may change Flow properties, such as the Differentiated Services Code Point (DSCP) value or the source IP address. If an IPFIX Observation Point is located in the path of a Flow before one or more middleboxes that potentially modify packets of the Flow, then it may be desirable to also report Flow properties after the modification performed by the middleboxes. An example is an Observation Point before a packet marker changing a packet's IPv4 Type of Service (TOS) field that is encoded in Information Element ipClassOfService. Then the value observed and reported by Information Element ipClassOfService is valid at the Observation Point but not after the packet passed the packet marker. For reporting the change value of the TOS field, the IPFIX information model uses Information Elements that have a name prefix "post", for example, "postIpClassOfService". Information Elements with prefix "post" report on Flow properties that are not necessarily observed at the Observation Point but that are obtained within the Flow's Observation Domain by other means considered to be sufficiently reliable, for example, by analyzing the packet marker's marking tables.
o 中间盒[RFC3234]可能会更改流属性，例如区分服务代码点（DSCP）值或源IP地址。如果IPFIX观察点位于一个或多个可能修改流数据包的中间盒之前的流路径中，则可能需要在中间盒执行修改后报告流属性。例如，包标记更改包的IPv4服务类型（TOS）字段之前的观察点，该字段编码在信息元素ipClassOfService中。然后，信息元素ipClassOfService观察和报告的值在观察点有效，但在数据包通过数据包标记后无效。为了报告TOS字段的更改值，IPFIX信息模型使用具有名称前缀“post”的信息元素，例如“postIpClassOfService”。前缀为“post”的信息元素报告了不一定在观察点观察到的流属性，但通过其他被认为足够可靠的方式（例如，通过分析分组标记的标记表）在流的观察域内获得的流属性。
This section describes the abstract data types that can be used for the specification of IPFIX Information Elements in Section 4. Section 3.1 describes the set of abstract data types.
本节描述了可用于第4节中IPFIX信息元素规范的抽象数据类型。第3.1节描述了一组抽象数据类型。
Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, and signed64 are integral data types. As described in Section 3.2, their data type semantics can be further specified, for example, by 'totalCounter', 'deltaCounter', 'identifier', or 'flags'.
抽象数据类型unsigned8、unsigned16、unsigned32、unsigned64、signed8、signed16、signed32和signed64是整型数据类型。如第3.2节所述，它们的数据类型语义可以进一步指定，例如，通过“totalCounter”、“deltaCounter”、“identifier”或“flags”。
This section describes the set of valid abstract data types of the IPFIX information model, independent of encoding. Note that further abstract data types may be specified by future updates to this document. Changes to the associated IPFIX "Information Element Data Types" subregistry [IANA-IPFIX] specified in [RFC5610] require a Standards Action [RFC5226].
本节描述IPFIX信息模型的有效抽象数据类型集，与编码无关。请注意，本文档的后续更新可能会指定更多的抽象数据类型。[RFC5610]中指定的关联IPFIX“信息元素数据类型”子区域[IANA-IPFIX]的更改需要标准操作[RFC5226]。
The current encodings of these data types for use with the IPFIX protocol are defined in [RFC7011]; encodings allowing the use of the IPFIX Information Elements [IANA-IPFIX] with other protocols may be defined in the future by referencing this document.
[RFC7011]中定义了用于IPFIX协议的这些数据类型的当前编码；允许将IPFIX信息元素[IANA-IPFIX]与其他协议一起使用的编码可在将来通过参考本文件进行定义。
The type "unsigned8" represents a non-negative integer value in the range of 0 to 255.
类型“unsigned8”表示0到255范围内的非负整数值。
The type "unsigned16" represents a non-negative integer value in the range of 0 to 65535.
类型“unsigned16”表示0到65535范围内的非负整数值。
The type "unsigned32" represents a non-negative integer value in the range of 0 to 4294967295.
类型“unsigned32”表示0到4294967295范围内的非负整数值。
The type "unsigned64" represents a non-negative integer value in the range of 0 to 18446744073709551615.
类型“unsigned64”表示0到18446744073709551615范围内的非负整数值。
The type "signed8" represents an integer value in the range of -128 to 127.
类型“signed8”表示-128到127范围内的整数值。
The type "signed16" represents an integer value in the range of -32768 to 32767.
类型“signed16”表示-32768到32767范围内的整数值。
The type "signed32" represents an integer value in the range of -2147483648 to 2147483647.
类型“signed32”表示-2147483648到2147483647范围内的整数值。
The type "signed64" represents an integer value in the range of -9223372036854775808 to 9223372036854775807.
类型“signed64”表示-9223372036854775808到9223372036854775807范围内的整数值。
The type "float32" corresponds to an IEEE single-precision 32-bit floating-point type as defined in [IEEE.754.2008].
类型“float32”对应于[IEEE.754.2008]中定义的IEEE单精度32位浮点类型。
The type "float64" corresponds to an IEEE double-precision 64-bit floating-point type as defined in [IEEE.754.2008].
类型“float64”对应于[IEEE.754.2008]中定义的IEEE双精度64位浮点类型。
The type "boolean" represents a binary value. The only allowed values are "true" and "false".
类型“boolean”表示二进制值。唯一允许的值是“真”和“假”。
The type "macAddress" represents a MAC-48 address as defined in [IEEE.802-3.2012].
“macAddress”类型表示[IEEE.802-3.2012]中定义的MAC-48地址。
The type "octetArray" represents a finite-length string of octets.
类型“Octeraray”表示有限长度的八位字节字符串。
The type "string" represents a finite-length string of valid characters from the Unicode coded character set [ISO.10646]. Unicode incorporates ASCII [RFC20] and the characters of many other international character sets.
类型“string”表示Unicode编码字符集[ISO.10646]中有效字符的有限长度字符串。Unicode包含ASCII[RFC20]和许多其他国际字符集的字符。
The type "dateTimeSeconds" represents a time value expressed with second-level precision.
类型“dateTimeSeconds”表示以二级精度表示的时间值。
The type "dateTimeMilliseconds" represents a time value expressed with millisecond-level precision.
类型“DateTimeMillicles”表示以毫秒级精度表示的时间值。
The type "dateTimeMicroseconds" represents a time value expressed with microsecond-level precision.
类型“dateTimeMicroseconds”表示以微秒级精度表示的时间值。
The type "dateTimeNanoseconds" represents a time value expressed with nanosecond-level precision.
类型“dateTimeNanoseconds”表示以纳秒级精度表示的时间值。
The type "ipv4Address" represents an IPv4 address.
类型“ipv4Address”表示IPv4地址。
The type "ipv6Address" represents an IPv6 address.
类型“ipv6Address”表示IPv6地址。
The type "basicList" supports structured data export as described in [RFC6313]; see Section 4.5.1 of that document for encoding details.
“basicList”类型支持[RFC6313]中所述的结构化数据导出；编码详情见该文件第4.5.1节。
The type "subTemplateList" supports structured data export as described in [RFC6313]; see Section 4.5.2 of that document for encoding details.
“subTemplateList”类型支持[RFC6313]中所述的结构化数据导出；编码详情见该文件第4.5.2节。
The type "subTemplateMultiList" supports structured data export as described in [RFC6313]; see Section 4.5.3 of that document for encoding details.
“subTemplateMultiList”类型支持[RFC6313]中所述的结构化数据导出；编码详情见该文件第4.5.3节。
This section describes the set of valid data type semantics of the IPFIX information model. A subregistry of data type semantics [IANA-IPFIX] is established in [RFC5610]; the restrictions on the use of semantics below are compatible with those specified in Section 3.10 of that document. These semantics apply only to numeric types, as noted in the description of each semantic below.
本节描述IPFIX信息模型的有效数据类型语义集。[RFC5610]中建立了数据类型语义子区[IANA-IPFIX]；下文对语义使用的限制与该文件第3.10节中规定的限制一致。这些语义仅适用于数字类型，如下面每个语义的描述所述。
Further data type semantics may be specified by future updates to this document. Changes to the associated "IPFIX Information Element Semantics" subregistry [IANA-IPFIX] require a Standards Action [RFC5226].
进一步的数据类型语义可能由本文档的未来更新指定。对相关“IPFIX信息元素语义”子区域[IANA-IPFIX]的更改需要标准操作[RFC5226]。
"quantity" is a numeric (integral or floating point) value representing a measured value pertaining to the record. This is distinguished from counters that represent an ongoing measured value whose "odometer" reading is captured as part of a given record. This is the default semantic type of all numeric data types.
“数量”是一个数字（整数或浮点）值，表示与记录有关的测量值。这与表示持续测量值的计数器不同，其“里程表”读数作为给定记录的一部分被捕获。这是所有数值数据类型的默认语义类型。
"totalCounter" is an integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type. For example, an unsigned64 with counter semantics will continue to increment until reaching the value of 2**64 - 1. At this point, the next increment will wrap its value to zero and continue counting from zero. The semantics of a total counter is similar to the semantics of counters used in the Simple Network Management Protocol (SNMP), such as Counter32 as defined in [RFC2578]. The only difference between total counters and counters used in SNMP is that the total counters have an initial value of 0. A total counter counts independently of the export of its value.
“totalCounter”是报告计数器值的整数值。计数器是无符号的，并在达到类型限制后返回零。例如，具有计数器语义的unsigned64将继续递增，直到达到2**64-1的值。此时，下一个增量将其值包装为零，并继续从零开始计数。总计数器的语义与简单网络管理协议（SNMP）中使用的计数器的语义相似，例如[RFC2578]中定义的计数器32。总计数器与SNMP中使用的计数器之间的唯一区别是，总计数器的初始值为0。总计数器的计数与其值的输出无关。
"deltaCounter" is an integral value reporting the value of a counter. Counters are unsigned and wrap back to zero after reaching the limit of the type. For example, an unsigned64 with counter semantics will continue to increment until reaching the value of 2**64 - 1. At this
“deltaCounter”是报告计数器值的整数值。计数器是无符号的，并在达到类型限制后返回零。例如，具有计数器语义的unsigned64将继续递增，直到达到2**64-1的值。在这
point, the next increment will wrap its value to zero and continue counting from zero. The semantics of a delta counter is similar to the semantics of counters used in SNMP, such as Counter32 as defined in [RFC2578]. The only difference between delta counters and counters used in SNMP is that the delta counters have an initial value of 0. A delta counter is reset to 0 each time it is exported and/or expires without export.
点，下一个增量将其值包装为零，并继续从零开始计数。增量计数器的语义类似于SNMP中使用的计数器的语义，如[RFC2578]中定义的计数器32。增量计数器和SNMP中使用的计数器之间的唯一区别是增量计数器的初始值为0。每次导出增量计数器和/或在不导出的情况下过期时，增量计数器都会重置为0。
"identifier" is an integral value that serves as an identifier. Specifically, mathematical operations on two identifiers (aside from the equality operation) are meaningless. For example, Autonomous System ID 1 * Autonomous System ID 2 is meaningless. Identifiers MUST be one of the signed or unsigned data types.
“标识符”是用作标识符的整数值。具体来说，对两个标识符的数学运算（除了相等运算）是没有意义的。例如，自治系统ID 1*自治系统ID 2是无意义的。标识符必须是有符号或无符号数据类型之一。
"flags" is an integral value that represents a set of bit fields. Logical operations are appropriate on such values, but other mathematical operations are not. Flags MUST always be of an unsigned data type.
“标志”是表示一组位字段的整数值。逻辑运算适用于此类值，但其他数学运算则不适用。标志必须始终为无符号数据类型。
All Information Elements defined in the IANA "IPFIX Information Elements" registry [IANA-IPFIX] have their identifiers assigned by IANA.
IANA“IPFIX信息元素”注册表[IANA-IPFIX]中定义的所有信息元素的标识符均由IANA分配。
The values of these identifiers are in the range of 1-32767. Within this range, Information Element identifier values in the sub-range of 1-127 are compatible with field types used by NetFlow version 9 [RFC3954] for historical reasons.
这些标识符的值在1-32767范围内。在此范围内，由于历史原因，子范围1-127中的信息元素标识符值与NetFlow版本9[RFC3954]使用的字段类型兼容。
In general, IANA will add newly registered Information Elements to the registry, assigning the lowest available Information Element identifier in the range of 128-32767.
通常，IANA会将新注册的信息元素添加到注册表中，分配128-32767范围内的最低可用信息元素标识符。
Enterprise-specific Information Element identifiers have the same range of 1-32767, but they are coupled with an additional enterprise identifier. For enterprise-specific Information Elements, Information Element identifier 0 is also reserved. Enterprise-specific Information Element identifiers can be chosen by an enterprise arbitrarily within the range of 1-32767. The same identifier may be assigned by other enterprises for different purposes; these Information Elements are distinct because the Information Element identifier is coupled with an enterprise identifier.
特定于企业的信息元素标识符具有相同的范围1-32767，但它们与附加的企业标识符耦合。对于特定于企业的信息元素，还保留了信息元素标识符0。企业可以在1-32767范围内任意选择特定于企业的信息元素标识符。同一标识符可由其他企业分配用于不同目的；这些信息元素是不同的，因为信息元素标识符与企业标识符耦合。
Enterprise identifiers are to be registered as SMI network management private enterprise code numbers with IANA. The registry can be found at [IANA-PEN].
企业标识符将在IANA注册为SMI网络管理专用企业代码。注册表可在[IANA-PEN]找到。
[IANA-IPFIX] is now the normative reference for IPFIX Information Elements. When [RFC5102] was published, it defined, in its Section 5, the initial contents of that registry.
[IANA-IPFIX]现在是IPFIX信息元素的规范性参考。[RFC5102]发布时，它在第5节中定义了该注册表的初始内容。
As a historical note, Information Elements (IEs) were organized into categories in [RFC5102] according to their semantics and their applicability; these categories were not carried forward into [IANA-IPFIX] as an organizing principle. The categories (with example IEs) were:
作为历史记录，在[RFC5102]中，信息元素根据其语义和适用性被组织成类别；这些类别没有作为组织原则转入[IANA-IPFIX]。类别（以IEs为例）为：
1. Identifiers (e.g., ingressInterface) 2. Metering and Exporting Process Configuration (e.g., exporterIPv4Address) 3. Metering and Exporting Process Statistics (e.g., exportedOctetTotalCount) 4. IP Header Fields (e.g., sourceIPv4Address) 5. Transport Header Fields (e.g., sourceTransportPort) 6. Sub-IP Header Fields (e.g., sourceMacAddress) 7. Derived Packet Properties (e.g., bgpSourceAsNumber) 8. Min/Max Flow Properties (e.g., minimumIpTotalLength) 9. Flow Timestamps (e.g., flowStartTimeMilliseconds) 10. Per-Flow Counters (e.g., octetDeltaCount) 11. Miscellaneous Flow Properties (e.g., flowEndReason) 12. Padding (paddingOctets)
1. 标识符（如入口接口）2。计量和导出过程配置（例如exporterIPv4Address）3。计量和导出过程统计信息（例如，ExportedActettTotalCount）4。IP头字段（例如，sourceIPv4Address）5。传输头字段（例如sourceTransportPort）6。子IP头字段（例如sourceMacAddress）7。派生数据包属性（例如bgpSourceAsNumber）8。最小/最大流量特性（例如最小最大长度）9。流量时间戳（例如，FlowStartTimeMills）10。每流量计数器（例如，八位DeltaCount）11。其他流量特性（如flowEndReason）12。填料（填料塔）
Information Elements derived from fields of packets or from Packet Treatment can typically serve as Flow Keys used for mapping packets to Flows. These Information Elements were placed in categories 4-7 in the original categorization.
从数据包字段或数据包处理派生的信息元素通常可以用作流键，用于将数据包映射到流。在原始分类中，这些信息元素被归入第4-7类。
Information Elements not serving as Flow Keys may have different values for each packet in a Flow. For Information Elements with values derived from fields of packets or from Packet Treatment, and for which the value may change from packet to packet within a single Flow, the exported value of an Information Element is by default determined by the first packet observed for the corresponding Flow; the description of the Information Element may, however, explicitly specify different semantics. This simple rule allows the writing of all Information Elements related to header fields once, when the first packet of the Flow is observed. For further observed packets
对于流中的每个分组，不用作流密钥的信息元素可以具有不同的值。对于具有从分组字段或分组处理导出的值的信息元素，并且对于其值可以在单个流中从分组到分组改变，默认情况下，信息元素的导出值由针对相应流观察到的第一个分组确定；然而，信息元素的描述可以明确指定不同的语义。这个简单的规则允许在观察到流的第一个数据包时一次性写入与报头字段相关的所有信息元素。进一步观察数据包
of the same Flow, only Flow properties that depend on more than one packet need to be updated; these Information Elements were placed in categories 8-11 in the original categorization.
对于相同的流，仅需要更新依赖于多个分组的流属性；这些信息元素在原始分类中被归入第8-11类。
Information Elements with a name having the "post" prefix (e.g., postIpClassOfService) do not necessarily report properties that were actually observed at the Observation Point but may be retrieved by other means within the Observation Domain. These Information Elements can be used if there are middlebox functions within the Observation Domain changing Flow properties after packets passed the Observation Point; they may also be reported directly by the Observation Point if the Observation Point is situated where it can observe packets on both sides of the middlebox.
名称带有“post”前缀的信息元素（例如PostPClassofService）不一定报告在观测点实际观测到的属性，但可以通过观测域内的其他方式检索。如果观测域中存在中间盒函数，在数据包通过观测点后改变流属性，则可以使用这些信息元素；如果观察点位于可以观察中间盒两侧数据包的位置，则观察点也可以直接报告这些数据包。
A key requirement for IPFIX is to allow for extension of the Information Model via the "IP Flow Information Export (IPFIX) Entities" registry [IANA-IPFIX]. New Information Element definitions can be added to this registry subject to Expert Review [RFC5226], with additional process considerations as described in [RFC7013]; that document also provides guidelines for authors and reviewers of new Information Element definitions.
IPFIX的一个关键要求是允许通过“IP流信息导出（IPFIX）实体”注册表[IANA-IPFIX]扩展信息模型。经专家审查[RFC5226]后，可将新的信息元素定义添加到此注册表中，并考虑[RFC7013]中所述的其他过程注意事项；该文件还为新信息元素定义的作者和审阅者提供了指南。
For new Information Elements, the type space defined in Section 3 can be used. If required, new abstract data types can be added to the "IPFIX Information Element Data Types" subregistry [IANA-IPFIX] as defined in [RFC5610]. New abstract data types and semantics are subject to Standards Action [RFC5226] and MUST be defined in IETF Standards Track documents updating this document.
对于新的信息元素，可以使用第3节中定义的类型空间。如果需要，可以将新的抽象数据类型添加到[RFC5610]中定义的“IPFIX信息元素数据类型”子区域[IANA-IPFIX]。新的抽象数据类型和语义受标准行动[RFC5226]的约束，必须在更新本文件的IETF标准跟踪文件中定义。
Enterprises may wish to define Information Elements without registering them with IANA. IPFIX explicitly supports enterprise-specific Information Elements. Enterprise-specific Information Elements are described in Sections 2.1 and 4; guidelines for using them appear in [RFC7013].
企业可能希望在不向IANA注册的情况下定义信息元素。IPFIX明确支持特定于企业的信息元素。第2.1节和第4节描述了特定于企业的信息元素；使用指南见[RFC7013]。
As this document obsoletes [RFC5102], IANA has updated the references in the "IP Flow Information Export (IPFIX) Entities" registry [IANA-IPFIX], the "IPFIX MPLS label type" subregistry of that registry, the urn:ietf:params:xml:ns:ipfix-info XML namespace, and the urn:ietf:params:xml:schema:ipfix-info XML schema to refer to this document.
由于本文件废除了[RFC5102]，IANA已更新了“IP流信息导出（IPFIX）实体”注册表[IANA-IPFIX]、该注册表的“IPFIX MPLS标签类型”子目录、urn:ietf:params:xml:ns:IPFIX info xml命名空间和urn:ietf:params:xml:schema:IPFIX info xml架构中的引用，以引用本文件。
However, [RFC5102] still provides a historical reference for the initial entries in the "IPFIX Information Elements" registry. Therefore, IANA has kept [RFC5102] as the requestor of those Information Elements in the "IPFIX Information Elements" registry that list [RFC5102] as their requestor and added the following explanatory note to the "IPFIX Information Elements" registry:
但是，[RFC5102]仍然为“IPFIX信息元素”注册表中的初始条目提供历史参考。因此，IANA将[RFC5102]保留为“IPFIX信息元素”注册表中列出[RFC5102]作为其请求者的信息元素的请求者，并在“IPFIX信息元素”注册表中添加了以下说明：
"RFC 7012 has obsoleted RFC 5102; references to RFC 5102 in this registry remain as part of the historical record".
“RFC 7012已淘汰RFC 5102；本注册表中对RFC 5102的引用仍作为历史记录的一部分”。
The Information Element Specification Template (Section 2.1) requires two new columns not present in [RFC5102]. IANA has created a new Revision column in the "IPFIX Information Elements" registry and set the Revision of existing Information Elements to 0. IANA has also created a new Date column in that registry and set the Date of all existing Information Elements to the publication date of this document.
信息元素规范模板（第2.1节）需要[RFC5102]中没有的两个新列。IANA已在“IPFIX信息元素”注册表中创建了一个新的修订列，并将现有信息元素的修订设置为0。IANA还在该注册表中创建了一个新的日期列，并将所有现有信息元素的日期设置为本文档的发布日期。
To identify Information Elements with identifiers 127 or below as NetFlow version 9 [RFC3954] compatible, IANA has set the Name of all existing Reserved Information Elements with identifier 127 or less to "Assigned for NetFlow v9 compatibility" and the Reference of those Information Elements to [RFC3954].
为了将标识符为127或以下的信息元素识别为与NetFlow版本9[RFC3954]兼容，IANA已将标识符为127或以下的所有现有保留信息元素的名称设置为“分配给NetFlow v9兼容”，并将这些信息元素的引用设置为[RFC3954]。
As IANA now has change control of the schema used for the IANA "IPFIX Information Elements" registry [IANA-IPFIX], IANA has deprecated the previous XML schema for the description of Information Elements urn:ietf:params:xml:schema:ipfix-info [IPFIX-XML-SCHEMA].
由于IANA现在对用于IANA“IPFIX信息元素”注册表[IANA-IPFIX]的模式具有更改控制权，IANA已不推荐使用以前的XML模式来描述信息元素urn:ietf:params:XML:schema:IPFIX info[IPFIX-XML-schema]。
To support the process described in Section 7.4, IANA has established a mailing list for communicating with the IE-DOCTORS, named ie-doctors@ietf.org.
为了支持第7.4节所述的流程，IANA建立了一个邮件列表，用于与IE-DOCTORS通信，名为IE-doctors@ietf.org.
The remaining subsections of this section contain no actions for IANA.
本节其余小节不包含IANA的任何操作。
This document refers to Information Elements, for which the Internet Assigned Numbers Authority (IANA) has created the IPFIX "Information Elements" registry [IANA-IPFIX]. The columns of this registry must, at minimum, be able to store the information defined in the template detailed in Section 2.1; it may contain other information as necessary for the management of the registry.
本文件涉及信息元素，互联网分配号码管理局（IANA）已为其创建了IPFIX“信息元素”注册表[IANA-IPFIX]。该注册表的列必须至少能够存储第2.1节中详细说明的模板中定义的信息；它可能包含管理登记处所需的其他信息。
The process for making additions or other changes to the "IPFIX Information Elements" registry is given in Section 7.4.
第7.4节给出了对“IPFIX信息元素”注册表进行添加或其他更改的过程。
Information Element #46, named mplsTopLabelType, carries MPLS label types. Values for 5 different types have initially been defined. For ensuring the extensibility of this information, IANA has created a new subregistry for MPLS label types and filled it with the initial list from the description Information Element #46, mplsTopLabelType.
名为mplsTopLabelType的信息元素#46携带MPLS标签类型。最初定义了5种不同类型的值。为了确保此信息的可扩展性，IANA为MPLS标签类型创建了一个新的子区，并使用描述信息元素46，mplsTopLabelType中的初始列表填充该子区。
New assignments for MPLS label types are administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts must double-check the label type definitions with already-defined label types for completeness, accuracy, and redundancy. The specification of new MPLS label types MUST be published using a well-established and persistent publication medium.
MPLS标签类型的新分配由IANA通过专家评审[RFC5226]进行管理，即由IETF区域总监指定的专家组之一进行评审。专家组必须使用已定义的标签类型对标签类型定义进行双重检查，以确保完整性、准确性和冗余性。新MPLS标签类型的规范必须使用成熟的持久发布介质发布。
The prior version of this document [RFC5102] specified an XML schema for IPFIX Information Element definitions [IPFIX-XML-SCHEMA] that was used in the generation of the document text itself. When the IANA "IPFIX Information Elements" registry [IANA-IPFIX] was created, change control on the registry and the schema used to validate it passed to IANA.
此文档的早期版本[RFC5102]为IPFIX信息元素定义[IPFIX-XML-schema]指定了一个XML模式，该模式用于生成文档文本本身。创建IANA“IPFIX信息元素”注册表[IANA-IPFIX]时，将注册表上的更改控制和用于验证它的模式传递给IANA。
The use of a machine-readable syntax for the registry enables the creation of IPFIX tools that can automatically adapt to extensions to the information model. It should be noted that the use of XML in Exporters, Collectors, or other tools is not mandatory for the deployment of IPFIX. In particular, Exporting Processes do not produce or consume XML as part of their operation. IPFIX Collectors MAY take advantage of the machine-readability of the information model versus hard-coding their behavior or inventing proprietary means for accommodating extensions. However, in order to avoid unnecessary load on the IANA infrastructure serving the registry, Collectors SHOULD NOT poll the IANA registry [IANA-IPFIX] directly at runtime.
使用注册表的机器可读语法可以创建IPFIX工具，这些工具可以自动适应信息模型的扩展。应该注意的是，在导出器、收集器或其他工具中使用XML对于IPFIX的部署不是强制性的。特别是，导出过程不会在其操作中生成或使用XML。IPFIX收集器可以利用信息模型的机器可读性，而不是硬编码其行为或发明专有方法来容纳扩展。但是，为了避免在为注册表提供服务的IANA基础设施上产生不必要的负载，收集器不应在运行时直接轮询IANA注册表[IANA-IPFIX]。
The reference to the current schema is embedded in the registry [IANA-IPFIX]; this schema may change from time to time as necessary to support the maintenance of the registry. As such, the schema urn:ietf:params:xml:schema:ipfix-info [IPFIX-XML-SCHEMA] specified in [RFC5102] has been deprecated.
对当前模式的引用嵌入到注册表[IANA-IPFIX]中；此架构可能会根据需要不时更改，以支持注册表的维护。因此，[RFC5102]中指定的模式urn:ietf:params:xml:schema:ipfix info[ipfix-xml-schema]已被弃用。
New assignments for the "IPFIX Information Elements" registry are administered by IANA through Expert Review [RFC5226]. These experts are referred to as IE-DOCTORS and are appointed by the IESG. The process they follow is defined in [RFC7013].
“IPFIX信息元素”登记册的新任务由IANA通过专家评审进行管理[RFC5226]。这些专家被称为IE医生，由IESG任命。[RFC7013]中定义了它们遵循的过程。
Information Element identifiers in the range of 1-127 are compatible with field types used by NetFlow version 9 [RFC3954] for historical reasons and must not be assigned unless the Information Element is compatible with the NetFlow version 9 protocol, as determined by one of the IE-DOCTORS designated by the IESG as a NetFlow version 9 expert.
由于历史原因，1-127范围内的信息元素标识符与NetFlow版本9[RFC3954]使用的字段类型兼容，并且除非信息元素与NetFlow版本9协议兼容（由IESG指定为NetFlow版本9专家的IE-Doctor之一确定），否则不得分配信息元素标识符。
Future assignments added to the "IPFIX Information Elements" registry that require subregistries for enumerated values (e.g., Section 7.2) must have those subregistries added simultaneously with the new assignment; additions to these subregistries must be subject to Expert Review [RFC5226]. Unless specified at assignment time, the experts for the subregistry will be the same as for the "IPFIX Information Elements" registry as a whole.
添加到“IPFIX信息元素”注册表的未来分配，如果需要枚举值的子区域（例如，第7.2节），则必须在新分配的同时添加这些子区域；这些次区域的新增项目必须经过专家审查[RFC5226]。除非在指定时间指定，否则次区域的专家将与整个“IPFIX信息要素”登记册的专家相同。
When IANA receives a request to add, revise, or deprecate an Information Element in the "IPFIX Information Elements" registry, it forwards the request to the IE-DOCTORS for review.
当IANA收到在“IPFIX信息元素”注册表中添加、修改或弃用信息元素的请求时，它会将该请求转发给IE-DOCTORS进行审查。
When IANA receives an approval for a request to add an Information Element definition from the IE-DOCTORS, it adds that Information Element to the registry. The approved request may include changes made by the requestor and/or reviewers as compared to the original request.
当IANA收到IE-DOCTORS对添加信息元素定义请求的批准时，它会将该信息元素添加到注册表中。批准的请求可能包括请求者和/或审核者相对于原始请求所做的更改。
When IANA receives an approval for a request to revise an Information Element definition from the IE-DOCTORS, it changes that Information Element's definition in the registry and updates the Revision and Date columns as appropriate. The approved request may include changes from the original request. If the original Information Element was added to the registry with IETF consensus (i.e., was defined by an RFC), the revision will require IETF consensus as well.
当IANA收到IE-DOCTORS对修改信息元素定义请求的批准时，它会在注册表中更改该信息元素的定义，并根据需要更新修订和日期列。批准的请求可能包括对原始请求的更改。如果原始信息元素以IETF共识（即由RFC定义）添加到注册表中，则修订也需要IETF共识。
When IANA receives an approval for a request to deprecate an Information Element definition from the IE-DOCTORS, it changes that Information Element's definition in the registry and updates the Revision and Date columns as appropriate. The approved request may include changes from the original request. If the original Information Element was added to the registry with IETF consensus (i.e., was defined by an RFC), the deprecation will require IETF consensus as well.
当IANA收到IE-DOCTORS对不推荐信息元素定义请求的批准时，它会在注册表中更改该信息元素的定义，并根据需要更新修订和日期列。批准的请求可能包括对原始请求的更改。如果原始信息元素以IETF共识添加到注册表中（即，由RFC定义），则弃用也需要IETF共识。
The IPFIX information model itself does not directly introduce security issues. Rather, it defines a set of attributes that may, for privacy or business issues, be considered sensitive information.
IPFIX信息模型本身不会直接引入安全问题。相反，它定义了一组属性，对于隐私或业务问题，这些属性可能被视为敏感信息。
For example, exporting values of header fields may make attacks possible for the receiver of this information; this would otherwise only be possible for direct observers of the reported Flows along the data path.
例如，导出报头字段的值可能使该信息的接收者可能遭受攻击；否则，只有直接观察沿数据路径报告的流的人才能这样做。
The underlying protocol used to exchange the information described here must therefore apply appropriate procedures to guarantee the integrity and confidentiality of the exported information. These protocols are defined in separate documents, specifically the IPFIX protocol document [RFC7011].
因此，用于交换此处所述信息的基础协议必须采用适当的程序来保证导出信息的完整性和机密性。这些协议在单独的文件中定义，特别是IPFIX协议文件[RFC7011]。
This document is substantially based on [RFC5102]. The editors thank the authors of that document; those authors are listed below as contributors. Special thanks go to Paul Aitken for the detailed review. Finally, the authors thank the IPFIX WG chairs: Nevil Brownlee and Juergen Quittek.
本文件主要基于[RFC5102]。编辑们感谢该文件的作者；这些作者被列为贡献者。特别感谢Paul Aitken的详细评论。最后，作者感谢IPFIX工作组主席Nevil Brownlee和Juergen Quitek。
[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月。
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011.
[RFC6313]Claise，B.，Dhandapani，G.，Aitken，P.，和S.Yates，“IP流信息导出（IPFIX）中结构化数据的导出”，RFC 63132011年7月。
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013.
[RFC7011]Claise，B.，Ed.，Trammell，B.，Ed.，和P.Aitken，“流量信息交换的IP流量信息导出（IPFIX）协议规范”，STD 77，RFC 7011，2013年9月。
[RFC7013] Trammell, B., and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, September 2013.
[RFC7013]Trammell，B.和B.Claise，“IP流信息导出（IPFIX）信息元素的作者和评审员指南”，BCP 184，RFC 7013，2013年9月。
[IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <http://www.iana.org/assignments/ipfix/>.
[IANA-IPFIX]IANA，“IP流信息导出（IPFIX）实体”<http://www.iana.org/assignments/ipfix/>.
[IEEE.754.2008] Institute of Electrical and Electronics Engineers, "IEEE Standard for Floating-Point Arithmetic", IEEE Standard 754, August 2008.
[IEEE.754.2008]电气和电子工程师协会，“IEEE浮点运算标准”，IEEE标准754，2008年8月。
[IEEE.802-3.2012] Institute of Electrical and Electronics Engineers, "IEEE Standard for Ethernet", IEEE Standard 802.3, 2012.
[IEEE.802-3.2012]电气和电子工程师协会，“以太网IEEE标准”，IEEE标准802.32012。
[IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, "Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators", Work in Progress, July 2013.
[IPFIX-MED-PROTO]Claise，B.，Kobayashi，A.，和B.Trammell，“IPFIX中介上IP流信息导出（IPFIX）协议的操作”，正在进行的工作，2013年7月。
[IPFIX-XML-SCHEMA] IANA, "IETF XML Registry", <http://www.iana.org/assignments/xml-registry/>.
[IPFIX-XML-SCHEMA]IANA，“IETF XML注册表”<http://www.iana.org/assignments/xml-registry/>.
[ISO.10646] International Organization for Standardization, "Information technology - Universal Coded Character Set (UCS)", ISO/IEC 10646:2012, November 2012.
[ISO.10646]国际标准化组织，“信息技术-通用编码字符集（UCS）”，ISO/IEC 10646:2012，2012年11月。
[IANA-PEN] IANA, "Private Enterprise Numbers", <http://www.iana.org/assignments/enterprise-numbers>.
[IANA-PEN]IANA，“私营企业编号”<http://www.iana.org/assignments/enterprise-numbers>.
[RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20, October 1969.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，RFC201969年10月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 32342002年2月。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003.
[RFC3444]Pras，A.和J.Schoenwaeld，“关于信息模型和数据模型之间的差异”，RFC 3444，2003年1月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917]Quitek，J.，Zseby，T.，Claise，B.，和S.Zander，“IP流信息导出（IPFIX）的要求”，RFC 39172004年10月。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954]Claise，B.，Ed.，“Cisco Systems NetFlow服务导出版本9”，RFC 3954，2004年10月。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101]Claise，B.，Ed.，“交换IP流量信息的IP流量信息导出（IPFIX）协议规范”，RFC 5101，2008年1月。
[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月。
[RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008.
[RFC5103]Trammell，B.和E.Boschi，“使用IP流量信息导出（IPFIX）的双向流量导出”，RFC 5103，2008年1月。
[RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. Aitken, "IP Flow Information Export (IPFIX) Implementation Guidelines", RFC 5153, April 2008.
[RFC5153]Boschi，E.，Mark，L.，Quitek，J.，Stieemering，M.，和P.Aitken，“IP流信息导出（IPFIX）实施指南”，RFC 5153，2008年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[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月。
[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月。
[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011.
[RFC6183]Kobayashi，A.，Claise，B.，Muenz，G.，和K.Ishibashi，“IP流信息导出（IPFIX）中介：框架”，RFC 6183，2011年4月。
[RFC6615] Dietz, T., Ed., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 6615, June 2012.
[RFC6615]Dietz，T.，Ed.，Kobayashi，A.，Claise，B.，和G.Muenz，“IP流信息导出的托管对象定义”，RFC 66152012年6月。
[RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols", RFC 6728, October 2012.
[RFC6728]Muenz，G.，Claise，B.，和P.Aitken，“IP流信息导出（IPFIX）和数据包采样（PSAMP）协议的配置数据模型”，RFC 6728，2012年10月。
Contributors
贡献者
Juergen Quittek NEC Kurfuersten-Anlage 36 Heidelberg 69115 Germany
德国海德堡Juergen Quittek NEC Kurfuersten安拉格36号海德堡69115
Phone: +49 6221 90511-15
EMail: quittek@nw.neclab.eu
URI: http://www.neclab.eu/
Phone: +49 6221 90511-15
EMail: quittek@nw.neclab.eu
URI: http://www.neclab.eu/
Stewart Bryant Cisco Systems, Inc. 10 New Square, Bedfont Lakes Feltham, Middlesex TW18 8HA United Kingdom
Stewart Bryant Cisco Systems，Inc.位于英国米德尔塞克斯州贝德丰湖费尔瑟姆新广场10号，邮编：TW18 8HA
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Edinburgh EH6 6LX Scotland
Paul Aitken Cisco Systems，Inc.96爱丁堡商业码头EH6 6LX苏格兰
Phone: +44 131 561 3616
EMail: paitken@cisco.com
Phone: +44 131 561 3616
EMail: paitken@cisco.com
Jeff Meyer PayPal 2211 N. First St. San Jose, CA 95131-2021 US
杰夫·迈耶·贝宝美国加利福尼亚州第一圣何塞北2211号，邮编95131-2021
Phone: +1 408 976-9149
EMail: jemeyer@paypal.com
URI: http://www.paypal.com
Phone: +1 408 976-9149
EMail: jemeyer@paypal.com
URI: http://www.paypal.com
Authors' Addresses
作者地址
Benoit Claise (editor) Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium
Benoit Claise（编辑）Cisco Systems，Inc.De Kleetlaan 6a b1 1831 Diegem比利时
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Brian Trammell (editor) Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
Brian Trammell（编辑）瑞士联邦理工学院苏黎世Gloriastrasse 35 8092瑞士苏黎世
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch