Internet Engineering Task Force (IETF) B. Trammell
Request for Comments: 7373 ETH Zurich
Category: Standards Track September 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) B. Trammell
Request for Comments: 7373 ETH Zurich
Category: Standards Track September 2014
ISSN: 2070-1721
Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types
IP流信息导出（IPFIX）抽象数据类型的文本表示
Abstract
摘要
This document defines UTF-8 representations for IP Flow Information Export (IPFIX) abstract data types (ADTs) to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings.
本文档定义了IP流信息导出（IPFIX）抽象数据类型（ADT）的UTF-8表示，以支持IPFIX信息元素与基于文本编码的协议的互操作使用。
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/rfc7373.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7373.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Identifying Information Elements . . . . . . . . . . . . . . 3
4. Data Type Encodings . . . . . . . . . . . . . . . . . . . . . 3
4.1. octetArray . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. unsigned8, unsigned16, unsigned32, and unsigned64 . . . . 4
4.3. signed8, signed16, signed32, and signed64 . . . . . . . . 5
4.4. float32 and float64 . . . . . . . . . . . . . . . . . . . 6
4.5. boolean . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. macAddress . . . . . . . . . . . . . . . . . . . . . . . 7
4.7. string . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.8. The dateTime ADTs . . . . . . . . . . . . . . . . . . . . 8
4.9. ipv4Address . . . . . . . . . . . . . . . . . . . . . . . 8
4.10. ipv6Address . . . . . . . . . . . . . . . . . . . . . . . 9
4.11. basicList, subTemplateList, and subTemplateMultiList . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . .
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Identifying Information Elements . . . . . . . . . . . . . . 3
4. Data Type Encodings . . . . . . . . . . . . . . . . . . . . . 3
4.1. octetArray . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. unsigned8, unsigned16, unsigned32, and unsigned64 . . . . 4
4.3. signed8, signed16, signed32, and signed64 . . . . . . . . 5
4.4. float32 and float64 . . . . . . . . . . . . . . . . . . . 6
4.5. boolean . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. macAddress . . . . . . . . . . . . . . . . . . . . . . . 7
4.7. string . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.8. The dateTime ADTs . . . . . . . . . . . . . . . . . . . . 8
4.9. ipv4Address . . . . . . . . . . . . . . . . . . . . . . . 8
4.10. ipv6Address . . . . . . . . . . . . . . . . . . . . . . . 9
4.11. basicList, subTemplateList, and subTemplateMultiList . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . .
The IP Flow Information Export (IPFIX) Information Model [RFC7012] provides a set of abstract data types (ADTs) for the IANA "IPFIX Information Elements" registry [IANA-IPFIX], which contains a rich set of Information Elements for description of information about network entities and network traffic data, and abstract data types for these Information Elements. The IPFIX Protocol Specification [RFC7011], in turn, defines a big-endian binary encoding for these abstract data types suitable for use with the IPFIX protocol.
IP流信息导出（IPFIX）信息模型[RFC7012]为IANA“IPFIX信息元素”注册表[IANA-IPFIX]提供了一组抽象数据类型（ADT），其中包含一组丰富的信息元素，用于描述有关网络实体和网络流量数据的信息，以及这些信息元素的抽象数据类型。IPFIX协议规范[RFC7011]反过来定义了适用于IPFIX协议的这些抽象数据类型的大端二进制编码。
However, present and future operations and management protocols and applications may use textual encodings, and generic framing and structure, as in JSON [RFC7159] or XML. A definition of canonical textual encodings for the IPFIX abstract data types would allow this set of Information Elements to be used for such applications and for these applications to interoperate with IPFIX applications at the Information Element definition level.
然而，当前和未来的操作和管理协议及应用程序可能使用文本编码、通用框架和结构，如JSON[RFC7159]或XML。IPFIX抽象数据类型的规范文本编码定义将允许这组信息元素用于此类应用程序，并允许这些应用程序在信息元素定义级别与IPFIX应用程序进行互操作。
Note that templating or other mechanisms used for data description for such applications and protocols are application specific and, therefore, out of scope for this document: only Information Element identification and value representation are defined here.
请注意，用于此类应用程序和协议的数据描述的模板或其他机制是特定于应用程序的，因此超出了本文档的范围：此处仅定义了信息元素标识和值表示。
In most cases where a textual representation will be used, an explicit tradeoff is made for human readability or manipulability over compactness; this assumption is used in defining standard representations of IPFIX ADTs.
在大多数使用文本表示的情况下，显式权衡是为了人类可读性或可操作性而不是紧凑性；此假设用于定义IPFIX ADT的标准表示。
Capitalized terms defined in the IPFIX Protocol Specification [RFC7011] and the IPFIX Information Model [RFC7012] are used in this document as defined in those documents. 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]. In addition, this document defines the following terminology for its own use:
IPFIX协议规范[RFC7011]和IPFIX信息模型[RFC7012]中定义的大写术语在本文件中使用，如这些文件中所定义。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。此外，本文件定义了以下术语，供其自己使用：
Enclosing Context A textual representation of Information Element values is applied to use the IPFIX Information Model within some existing textual format (e.g., XML [W3C-XML] and JSON [RFC7159]). This outer format is referred to as the Enclosing Context within this document. Enclosing Contexts define escaping and quoting rules for represented values.
封闭上下文应用信息元素值的文本表示，以在某些现有文本格式（例如XML[W3C-XML]和JSON[RFC7159]）内使用IPFIX信息模型。此外部格式在本文档中称为封闭上下文。封闭上下文为表示的值定义转义和引用规则。
The "IPFIX Information Elements" registry [IANA-IPFIX] defines a set of Information Elements numbered by Information Element identifiers and named for human readability. These Information Element identifiers are meant for use with the IPFIX protocol and have little meaning when applying the "IPFIX Information Elements" registry to textual representations.
“IPFIX信息元素”注册表[IANA-IPFIX]定义了一组由信息元素标识符编号并以人类可读性命名的信息元素。这些信息元素标识符用于IPFIX协议，在将“IPFIX信息元素”注册表应用于文本表示时没有什么意义。
Instead, applications using textual representations of Information Elements use Information Element names to identify them; see Appendix A for examples illustrating this principle.
相反，使用信息元素的文本表示的应用程序使用信息元素名称来标识它们；参见附录A中说明该原则的示例。
Each subsection of this section defines a textual encoding for the abstract data types defined in [RFC7012]. This section uses ABNF, including the Core Rules in Appendix B of [RFC5234], to describe the format of textual representations of IPFIX abstract data types.
本节的每一小节都定义了[RFC7012]中定义的抽象数据类型的文本编码。本节使用ABNF（包括[RFC5234]附录B中的核心规则）来描述IPFIX抽象数据类型的文本表示格式。
If future documents update [RFC7012] to add new abstract data types to the IPFIX Information Model, and those abstract data types are generally useful, this document will also need to be updated in order to define textual encodings for those abstract data types.
如果将来的文档更新[RFC7012]以向IPFIX信息模型添加新的抽象数据类型，并且这些抽象数据类型通常很有用，那么还需要更新此文档，以便为这些抽象数据类型定义文本编码。
If the Enclosing Context defines a representation for binary objects, that representation SHOULD be used.
如果封闭上下文定义了二进制对象的表示，则应使用该表示。
Otherwise, since the goal of textual representation of Information Elements is human readability over compactness, the values of Information Elements of the octetArray data type are represented as a string of pairs of hexadecimal digits, one pair per byte, in the order the bytes would appear on the wire were the octetArray encoded directly in IPFIX per [RFC7011]. Whitespace may occur between any pair of digits to assist in human readability of the string but is not necessary. In ABNF:
否则，由于信息元素的文本表示的目标是人类可读性而不是紧凑性，因此八进制数据类型的信息元素的值表示为十六进制数字对的字符串，每字节一对，按照[RFC7011]中IPFIX中直接编码的八进制数组在导线上显示的顺序。空白可以出现在任何一对数字之间，以帮助字符串的可读性，但不是必需的。在ABNF中：
hex-octet = 2HEXDIG
hex-octet = 2HEXDIG
octetarray = hex-octet *([WSP] hex-octet)
八进制数组=十六进制八进制*（[WSP]十六进制八进制）
If the Enclosing Context defines a representation for unsigned integers, that representation SHOULD be used.
如果封闭上下文定义了无符号整数的表示形式，则应使用该表示形式。
In the special case where the unsigned Information Element has identifier semantics and refers to a set of codepoints either in an external registry, in a sub-registry, or directly in the description of the Information Element, then the name or short description for that codepoint as a string MAY be used to improve readability.
在特殊情况下，如果未签名的信息元素具有标识符语义，并且在外部注册表、子注册表或直接在信息元素的描述中引用一组代码点，则可以使用作为字符串的该代码点的名称或简短描述来提高可读性。
Otherwise, the values of Information Elements of an unsigned integer type may be represented as either unprefixed base-10 (decimal) strings, base-16 (hexadecimal) strings prefixed by "0x", or base-2 (binary) strings prefixed by "0b". In ABNF:
否则，无符号整数类型的信息元素的值可以表示为前缀为“0x”的非固定基-10（十进制）字符串、基-16（十六进制）字符串或前缀为“0b”的基-2（二进制）字符串。在ABNF中：
unsigned = 1*DIGIT / "0x" 1*HEXDIG / "0b" 1*BIT
unsigned = 1*DIGIT / "0x" 1*HEXDIG / "0b" 1*BIT
Leading zeroes are allowed in any representation and do not signify base-8 (octal) representation. Binary representation is intended for use with Information Elements with flag semantics, but it can be used in any case.
任何表示法中都允许使用前导零，但不表示基数为8（八进制）的表示法。二进制表示法旨在与具有标志语义的信息元素一起使用，但它可以在任何情况下使用。
The encoded value MUST be in range for the corresponding abstract data type or Information Element. Values that are out of range are interpreted as clipped to the implicit range for the Information Element as defined by the abstract data type or to the explicit range of the Information Element if defined. Minimum and maximum values for abstract data types are shown in Table 1 below.
编码值必须在相应抽象数据类型或信息元素的范围内。超出范围的值被解释为剪裁到抽象数据类型定义的信息元素的隐式范围，或剪裁到信息元素的显式范围（如果定义）。抽象数据类型的最小值和最大值如下表1所示。
+------------+---------+----------------------+
| type | minimum | maximum |
+------------+---------+----------------------+
| unsigned8 | 0 | 255 |
| unsigned16 | 0 | 65535 |
| unsigned32 | 0 | 4294967295 |
| unsigned64 | 0 | 18446744073709551615 |
+------------+---------+----------------------+
+------------+---------+----------------------+
| type | minimum | maximum |
+------------+---------+----------------------+
| unsigned8 | 0 | 255 |
| unsigned16 | 0 | 65535 |
| unsigned32 | 0 | 4294967295 |
| unsigned64 | 0 | 18446744073709551615 |
+------------+---------+----------------------+
Table 1: Ranges for Unsigned Abstract Data Types (in Decimal)
表1：无符号抽象数据类型的范围（十进制）
If the Enclosing Context defines a representation for signed integers, that representation SHOULD be used.
如果封闭上下文定义了有符号整数的表示形式，则应使用该表示形式。
Otherwise, the values of Information Elements of signed integer types are represented as optionally prefixed base-10 (decimal) strings. In ABNF:
否则，有符号整数类型的信息元素的值表示为可选的带前缀的base-10（十进制）字符串。在ABNF中：
sign = "+" / "-"
sign = "+" / "-"
signed = [sign] 1*DIGIT
signed = [sign] 1*DIGIT
If the sign is omitted, it is assumed to be positive. Leading zeroes are allowed and do not signify base-8 (octal) encoding. The representation "-0" is explicitly allowed and is equal to zero.
如果省略符号，则假定为正。允许使用前导零，但不表示8进制（八进制）编码。表示法“-0”是明确允许的，并且等于零。
The encoded value MUST be in range for the corresponding abstract data type or Information Element. Values that are out of range are to be interpreted as clipped to the implicit range for the Information Element as defined by the abstract data type or to the explicit range of the Information Element if defined. Minimum and maximum values for abstract data types are shown in Table 2 below.
编码值必须在相应抽象数据类型或信息元素的范围内。超出范围的值将被解释为剪裁到抽象数据类型定义的信息元素的隐式范围或信息元素的显式范围（如果定义）。抽象数据类型的最小值和最大值如下表2所示。
+----------+----------------------+----------------------+
| type | minimum | maximum |
+----------+----------------------+----------------------+
| signed8 | -128 | +127 |
| signed16 | -32768 | +32767 |
| signed32 | -2147483648 | +2147483647 |
| signed64 | -9223372036854775808 | +9223372036854775807 |
+----------+----------------------+----------------------+
+----------+----------------------+----------------------+
| type | minimum | maximum |
+----------+----------------------+----------------------+
| signed8 | -128 | +127 |
| signed16 | -32768 | +32767 |
| signed32 | -2147483648 | +2147483647 |
| signed64 | -9223372036854775808 | +9223372036854775807 |
+----------+----------------------+----------------------+
Table 2: Ranges for Signed Abstract Data Types (in Decimal)
表2：有符号抽象数据类型的范围（十进制）
If the Enclosing Context defines a representation for floating-point numbers, that representation SHOULD be used.
如果封闭上下文定义了浮点数的表示形式，则应使用该表示形式。
Otherwise, the values of Information Elements of float32 or float64 types are represented as optionally sign-prefixed, optionally base-10 exponent-suffixed, floating-point decimal numbers, as in [IEEE.754.2008]. The special strings "NaN", "+inf", and "-inf" represent "not a number", "positive infinity", and "negative infinity", respectively.
否则，float32或float64类型的信息元素的值表示为可选的带符号前缀、可选的带基数10指数后缀的浮点十进制数，如[IEEE.754.2008]所示。特殊字符串“NaN”、“+inf”和“-inf”分别表示“非数字”、“正无穷大”和“负无穷大”。
In ABNF:
在ABNF中：
sign = "+" / "-"
sign = "+" / "-"
exponent = "e" [sign] 1*3DIGIT
exponent=“e”[符号]1*3数字
right-decimal = "." 1*DIGIT
右小数=“”1*位
mantissa = 1*DIGIT [right-decimal]
mantissa = 1*DIGIT [right-decimal]
num = [sign] mantissa [exponent]
num = [sign] mantissa [exponent]
naninf = "NaN" / (sign "inf")
naninf=“NaN”/（符号“inf”）
float = num / naninf
float = num / naninf
The expressed value is ( mantissa * 10 ^ exponent ). If the sign is omitted, it is assumed to be positive. If the exponent is omitted, it is assumed to be zero. Leading zeroes may appear in the mantissa and/or the exponent. Values MUST be within range for single- or double-precision numbers as defined in [IEEE.754.2008]; finite values outside the appropriate range are to be interpreted as clamped to be within the range. Note that no more than three digits are required or allowed for exponents in this encoding due to these ranges.
表示的值为（尾数*10^指数）。如果省略符号，则假定为正。如果省略指数，则假定其为零。前导零可能出现在尾数和/或指数中。数值必须在[IEEE.754.2008]中定义的单精度或双精度数字的范围内；超出适当范围的有限值应解释为限制在该范围内。请注意，由于这些范围，此编码中的指数不需要或不允许超过三位数。
Note that since this representation is meant for human readability, writers MAY sacrifice precision to use a more human-readable representation of a given value, at the expense of the ability to recover the exact bit pattern at the reader. Therefore, decoders MUST NOT assume that the represented values are exactly comparable for equality.
请注意，由于此表示是为了人类可读性，编写器可能会牺牲精度来使用给定值的更具人类可读性的表示，而牺牲在读取器处恢复精确位模式的能力。因此，解码器不得假设所表示的值完全相等。
If the Enclosing Context defines a representation for boolean values, that representation SHOULD be used.
如果封闭上下文定义了布尔值的表示形式，则应使用该表示形式。
Otherwise, a true boolean value is represented by the literal string "true" and a false boolean value by the literal string "false". In ABNF:
否则，真布尔值由文字字符串“真”表示，假布尔值由文字字符串“假”表示。在ABNF中：
boolean-true = "true"
boolean-true = "true"
boolean-false = "false"
boolean-false = "false"
boolean = boolean-true / boolean-false
boolean = boolean-true / boolean-false
Media Access Control (MAC) addresses are represented as IEEE 802 MAC-48 addresses, hexadecimal bytes with the most significant byte first, separated by colons. In ABNF:
媒体访问控制（MAC）地址表示为IEEE 802 MAC-48地址，十六进制字节以最重要的字节开头，用冒号分隔。在ABNF中：
hex-octet = 2HEXDIG
hex-octet = 2HEXDIG
macaddress = hex-octet 5( ":" hex-octet )
macaddress = hex-octet 5( ":" hex-octet )
As Information Elements of the string type are simply Unicode strings (encoded as UTF-8 when appearing in Data Sets in IPFIX Messages [RFC7011]), they are represented directly, using the Unicode encoding rules and quoting and escaping rules of the Enclosing Context.
由于字符串类型的信息元素只是Unicode字符串（当出现在IPFIX消息[RFC7011]的数据集中时，编码为UTF-8），因此使用Unicode编码规则以及封闭上下文的引用和转义规则直接表示它们。
If the Enclosing Context cannot natively represent Unicode characters, the escaping facility provided by the Enclosing Context MUST be used for nonrepresentable characters. Additionally, strings containing characters reserved in the Enclosing Context (e.g., control characters, markup characters, and quotes) MUST be escaped or quoted according to the rules of the Enclosing Context.
如果封闭上下文不能以本机方式表示Unicode字符，则封闭上下文提供的转义功能必须用于不可表示的字符。此外，包含封闭上下文中保留的字符（例如，控制字符、标记字符和引号）的字符串必须根据封闭上下文的规则进行转义或引用。
It is presumed that the Enclosing Context has sufficient restrictions on the use of Unicode to prevent the unsafe use of nonprinting and control characters. As there is no accepted solution for the processing and safe display of mixed-direction strings, mixed-direction strings should be avoided using this encoding. Note also that since this document presents no additional requirements for the normalization of Unicode strings, care must be taken when comparing strings using this encoding; direct byte-pattern comparisons are not sufficient for determining whether two strings are equivalent. See
假定封闭上下文对Unicode的使用有足够的限制，以防止不安全地使用非打印字符和控制字符。由于对于混合方向字符串的处理和安全显示没有公认的解决方案，因此应避免使用此编码。还请注意，由于本文档对Unicode字符串的规范化没有其他要求，因此在比较使用此编码的字符串时必须小心；直接字节模式比较不足以确定两个字符串是否相等。看见
[RFC6885] and [PRECIS] for more on possible unexpected results and related risks in comparing Unicode strings.
[RFC6885]和[PRECIS]了解比较Unicode字符串时可能出现的意外结果和相关风险的更多信息。
Timestamp abstract data types are represented generally as in [RFC3339], with two important differences. First, all IPFIX timestamps are expressed in terms of UTC, so textual representations of these Information Elements are explicitly in UTC as well. Time zone offsets are, therefore, not required or supported. Second, there are four timestamp abstract data types, separated by the precision that they can express. Fractional seconds are omitted in dateTimeSeconds, expressed in milliseconds in dateTimeMilliseconds, and so on.
时间戳抽象数据类型通常在[RFC3339]中表示，但有两个重要区别。首先，所有IPFIX时间戳都以UTC表示，因此这些信息元素的文本表示也以UTC表示。因此，不需要或不支持时区偏移。第二，有四种时间戳抽象数据类型，按它们可以表示的精度分开。分数秒在dateTimeSeconds中省略，在DateTimeMilliconds中以毫秒表示，依此类推。
In ABNF, taken from [RFC3339] and modified as follows:
在ABNF中，取自[RFC3339]，修改如下：
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60
time-msec = "." 3DIGIT
time-usec = "." 6DIGIT
time-nsec = "." 9DIGIT
full-date = date-fullyear "-" date-month "-" date-mday
integer-time = time-hour ":" time-minute ":" time-second
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60
time-msec = "." 3DIGIT
time-usec = "." 6DIGIT
time-nsec = "." 9DIGIT
full-date = date-fullyear "-" date-month "-" date-mday
integer-time = time-hour ":" time-minute ":" time-second
datetimeseconds = full-date "T" integer-time datetimemilliseconds = full-date "T" integer-time "." time-msec datetimemicroseconds = full-date "T" integer-time "." time-usec datetimenanoseconds = full-date "T" integer-time "." time-nsec
datetimeseconds=full date“T”integer time DateTimeMisconds=full date“T”integer time.“time msec datetimemicroseconds=full date“T”integer time.“time usec datetimenanoseconds=full date“T”integer time.“time nsec”
IP version 4 addresses are represented in dotted-quad format, most significant byte first, as it would be in a Uniform Resource Identifier [RFC3986]; the ABNF for an IPv4 address is taken from [RFC3986] and reproduced below:
IP版本4地址以虚线四元格式表示，最高有效字节优先，因为它将以统一资源标识符[RFC3986]表示；IPv4地址的ABNF取自[RFC3986]，如下所示：
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
ipv4address = dec-octet 3( "." dec-octet )
ipv4address=dec八位字节3（“.”dec八位字节）
IP version 6 addresses are represented as in Section 2.2 of [RFC4291], as updated by Section 4 of [RFC5952]. The ABNF for an IPv6 address is taken from [RFC3986] and reproduced below, using the ipv4address production from the previous section:
IP版本6地址如[RFC4291]第2.2节所示，并由[RFC5952]第4节更新。IPv6地址的ABNF取自[RFC3986]，并使用上一节中的ipv4address产品复制如下：
ls32 = ( h16 ":" h16 ) / ipv4address
; least significant 32 bits of address
h16 = 1*4HEXDIG
; 16 bits of address represented in hexadecimal
; zeroes to be suppressed as in RFC 5952
ls32 = ( h16 ":" h16 ) / ipv4address
; least significant 32 bits of address
h16 = 1*4HEXDIG
; 16 bits of address represented in hexadecimal
; zeroes to be suppressed as in RFC 5952
ipv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ h16 ":" h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
ipv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ h16 ":" h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
These abstract data types, defined for IPFIX Structured Data [RFC6313], do not represent actual data types; they are instead designed to provide a mechanism by which complex structure can be represented in IPFIX below the template level. It is assumed that protocols using textual Information Element representation will provide their own structure. Therefore, Information Elements of these data types MUST NOT be used in textual representations.
这些为IPFIX结构化数据[RFC6313]定义的抽象数据类型并不代表实际的数据类型；相反，它们旨在提供一种机制，通过该机制，复杂结构可以在模板级别下的IPFIX中表示。假设使用文本信息元素表示的协议将提供自己的结构。因此，这些数据类型的信息元素不得用于文本表示。
The security considerations for the IPFIX protocol [RFC7011] apply.
IPFIX协议[RFC7011]的安全注意事项适用。
Implementations of decoders of Information Element values using these representations must take care to correctly handle invalid input, but the encodings presented here are not special in that respect.
使用这些表示的信息元素值解码器的实现必须注意正确处理无效输入，但此处提供的编码在这方面并不特殊。
The encoding specified in this document, and representations that may be built upon it, are specifically not intended for the storage of data. However, since storage of data in the format in which it is exchanged is a very common practice, and the ubiquity of tools for indexing and searching text significantly increases the ease of searching and the risk of privacy-sensitive data being accidentally indexed or searched, the privacy considerations in Section 11.8 of
本文件中规定的编码以及可能建立在其上的表示方式，并非专门用于存储数据。然而，由于以交换数据的格式存储数据是一种非常普遍的做法，而且索引和搜索文本的工具无处不在，大大增加了搜索的便利性和隐私敏感数据被意外索引或搜索的风险，因此本手册第11.8节中的隐私注意事项
[RFC7011] are especially important to observe when storing data using the encoding specified in this document that was derived from the measurement of network traffic.
[RFC7011]在使用本文件中指定的编码（源自网络流量测量）存储数据时，要特别注意。
When using representations based on this encoding to transmit or store network traffic data, consider omitting especially privacy-sensitive values by not representing the columns or keys containing those values, as in black-marker anonymization as discussed in Section 4 of [RFC6235]. Other anonymization techniques described in [RFC6235] may also be useful in these situations.
当使用基于该编码的表示来发送或存储网络流量数据时，考虑通过不表示包含这些值的列或密钥来省略特别是隐私敏感值，如在[RCF665]第4节中所讨论的损坏的黑色标记匿名。[RFC6235]中描述的其他匿名技术在这些情况下也可能有用。
The encodings for all abstract data types other than 'string' are defined in such a way as to be representable in the US-ASCII character set and, therefore, should be unproblematic for all Enclosing Contexts. However, the 'string' abstract data type may be vulnerable to problems with ill-formed UTF-8 strings as discussed in Section 6.1.6 of [RFC7011]; see [UTF8-EXPLOIT] for background.
除“字符串”之外的所有抽象数据类型的编码都是以一种可以在US-ASCII字符集中表示的方式定义的，因此，对于所有封闭上下文来说都应该是无问题的。但是，如[RFC7011]第6.1.6节所述，“字符串”抽象数据类型可能容易出现格式错误的UTF-8字符串问题；有关背景信息，请参见[UTF8-APPLICE]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3339]Klyne，G.，Ed.和C.Newman，“互联网上的日期和时间：时间戳”，RFC33392002年7月<http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月<http://www.rfc-editor.org/info/rfc5952>.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>.
[RFC7011]Claise，B.，Trammell，B.，和P.Aitken，“流量信息交换的IP流量信息导出（IPFIX）协议规范”，STD 77，RFC 7011，2013年9月<http://www.rfc-editor.org/info/rfc7011>.
[IANA-IPFIX] IANA, "IPFIX Information Elements", <http://www.iana.org/assignments/ipfix/>.
[IANA-IPFIX]IANA，“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月。
[PRECIS] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols", Work in Progress, draft-ietf-precis-framework-18, September 2014.
[PRECIS]Saint Andre，P.和M.Blanchet，“PRECIS框架：应用协议中国际化字符串的准备和比较”，正在进行的工作，草案-ietf-PRECIS-Framework-18，2014年9月。
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, May 2011, <http://www.rfc-editor.org/info/rfc6235>.
[RFC6235]Boschi，E.和B.Trammell，“IP流匿名化支持”，RFC 62352011年5月<http://www.rfc-editor.org/info/rfc6235>.
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011, <http://www.rfc-editor.org/info/rfc6313>.
[RFC6313]Claise，B.，Dhandapani，G.，Aitken，P.，和S.Yates，“IP流信息导出（IPFIX）中结构化数据的导出”，RFC 63132011年7月<http://www.rfc-editor.org/info/rfc6313>.
[RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)", RFC 6885, March 2013, <http://www.rfc-editor.org/info/rfc6885>.
[RFC6885]Blanchet，M.和A.Sullivan，“编制和比较国际化字符串（PRECIS）的Stringprep修订和问题声明”，RFC 68852013年3月<http://www.rfc-editor.org/info/rfc6885>.
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013, <http://www.rfc-editor.org/info/rfc7012>.
[RFC7012]Claise，B.和B.Trammell，“IP流信息导出（IPFIX）的信息模型”，RFC 7012，2013年9月<http://www.rfc-editor.org/info/rfc7012>.
[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, <http://www.rfc-editor.org/info/rfc7013>.
[RFC7013]Trammell，B.和B.Claise，“IP流信息导出（IPFIX）信息元素的作者和评审指南”，BCP 184，RFC 7013，2013年9月<http://www.rfc-editor.org/info/rfc7013>.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[UTF8-EXPLOIT] Davis, M. and M. Suignard, "Unicode Technical Report #36: Unicode Security Considerations", The Unicode Consortium, November 2012.
[UTF8-EXPLOIT]Davis，M.和M.Suignard，“Unicode技术报告#36：Unicode安全注意事项”，Unicode联盟，2012年11月。
[W3C-XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation REC-xml, November 2008.
[W3C-XML]Bray，T.，Paoli，J.，Sperberg McQueen，C.，Maler，E.，和F.Yergeau，“可扩展标记语言（XML）1.0（第五版）”，W3C建议REC XML，2008年11月。
In this section, we examine an IPFIX Template and a Data Record defined by that Template and show how that Data Record would be represented in JSON according to the specification in this document. Note that this is specifically NOT a recommendation for a particular representation but merely an illustration of the encodings in this document; the quoting and formatting in the example are JSON specific.
在本节中，我们将检查一个IPFIX模板和由该模板定义的数据记录，并展示如何根据本文中的规范用JSON表示该数据记录。请注意，这并不是对特定表示的建议，而只是本文件中编码的说明；示例中的引用和格式是特定于JSON的。
Figure 1 shows a Template in Information Element Specifier (IESpec) format as defined in Section 10.1 of [RFC7013]; a corresponding JSON object representing a record defined by this template in the text format specified in this document is shown in Figure 2.
图1显示了[RFC7013]第10.1节中定义的信息元素说明符（IESpec）格式的模板；图2显示了一个对应的JSON对象，该对象表示该模板以本文档中指定的文本格式定义的记录。
flowStartMilliseconds(152)<dateTimeMilliseconds>[8]
flowEndMilliseconds(153)<dateTimeMilliseconds>[8]
octetDeltaCount(1)<unsigned64>[4]
packetDeltaCount(2)<unsigned64>[4]
sourceIPv6Address(27)<ipv6Address>[16]{key}
destinationIPv6Address(28)<ipv6Address>[16]{key}
sourceTransportPort(7)<unsigned16>[2]{key}
destinationTransportPort(11)<unsigned16>[2]{key}
protocolIdentifier(4)<unsigned8>[1]{key}
tcpControlBits(6)<unsigned16>[2]
flowEndReason(136)<unsigned8>[1]
flowStartMilliseconds(152)<dateTimeMilliseconds>[8]
flowEndMilliseconds(153)<dateTimeMilliseconds>[8]
octetDeltaCount(1)<unsigned64>[4]
packetDeltaCount(2)<unsigned64>[4]
sourceIPv6Address(27)<ipv6Address>[16]{key}
destinationIPv6Address(28)<ipv6Address>[16]{key}
sourceTransportPort(7)<unsigned16>[2]{key}
destinationTransportPort(11)<unsigned16>[2]{key}
protocolIdentifier(4)<unsigned8>[1]{key}
tcpControlBits(6)<unsigned16>[2]
flowEndReason(136)<unsigned8>[1]
Figure 1: Sample Flow Template in IESpec Format
图1:IESpec格式的样本流模板
{
"flowStartMilliseconds": "2012-11-05T18:31:01.135",
"flowEndMilliseconds": "2012-11-05T18:31:02.880",
"octetDeltaCount": 195383,
"packetDeltaCount": 88,
"sourceIPv6Address": "2001:db8:c:1337::2",
"destinationIPv6Address": "2001:db8:c:1337::3",
"sourceTransportPort": 80,
"destinationTransportPort": 32991,
"protocolIdentifier": "tcp",
"tcpControlBits": 19,
"flowEndReason": 3
}
{
"flowStartMilliseconds": "2012-11-05T18:31:01.135",
"flowEndMilliseconds": "2012-11-05T18:31:02.880",
"octetDeltaCount": 195383,
"packetDeltaCount": 88,
"sourceIPv6Address": "2001:db8:c:1337::2",
"destinationIPv6Address": "2001:db8:c:1337::3",
"sourceTransportPort": 80,
"destinationTransportPort": 32991,
"protocolIdentifier": "tcp",
"tcpControlBits": 19,
"flowEndReason": 3
}
Figure 2: JSON Object Containing Sample Flow
图2：包含示例流的JSON对象
Acknowledgments
致谢
Thanks to Paul Aitken, Benoit Claise, Andrew Feren, Juergen Quittek, David Black, and the IESG for their reviews and comments. Thanks to Dave Thaler and Stephan Neuhaus for discussions that improved the floating-point representation section. This work is materially supported by the European Union Seventh Framework Programme under grant agreement 318627 mPlane.
感谢Paul Aitken、Benoit Claise、Andrew Feren、Juergen Quitek、David Black和IESG的评论和评论。感谢Dave Thaler和Stephan Neuhaus的讨论，他们改进了浮点表示部分。根据318627 mPlane赠款协议，这项工作得到了欧盟第七框架计划的实质性支持。
Author's Address
作者地址
Brian Trammell Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
Brian Trammell瑞士联邦理工学院苏黎世Gloriastrasse 35 8092瑞士苏黎世
Phone: +41 44 632 70 13
EMail: ietf@trammell.ch
Phone: +41 44 632 70 13
EMail: ietf@trammell.ch