Network Working Group J. Quittek
Request for Comments: 3917 NEC Europe Ltd.
Category: Informational T. Zseby
Fraunhofer FOKUS
B. Claise
Cisco Systems
S. Zander
Swinburne University
October 2004
Network Working Group J. Quittek
Request for Comments: 3917 NEC Europe Ltd.
Category: Informational T. Zseby
Fraunhofer FOKUS
B. Claise
Cisco Systems
S. Zander
Swinburne University
October 2004
Requirements for IP Flow Information Export (IPFIX)
IP流信息导出（IPFIX）要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes.
此备忘录定义了从路由器、流量测量探测器和中间盒导出测量IP流信息的要求。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. IP Traffic Flow. . . . . . . . . . . . . . . . . . . . 3
2.2. Observation Point. . . . . . . . . . . . . . . . . . . 4
2.3. Metering Process . . . . . . . . . . . . . . . . . . . 4
2.4. Flow Record. . . . . . . . . . . . . . . . . . . . . . 5
2.5. Exporting Process. . . . . . . . . . . . . . . . . . . 5
2.6. Collecting Process . . . . . . . . . . . . . . . . . . 5
3. Applications Requiring IP Flow Information Export . . . . . . 6
3.1. Usage-based Accounting . . . . . . . . . . . . . . . . 6
3.2. Traffic Profiling. . . . . . . . . . . . . . . . . . . 7
3.3. Traffic Engineering. . . . . . . . . . . . . . . . . . 7
3.4. Attack/Intrusion Detection . . . . . . . . . . . . . . 7
3.5. QoS Monitoring . . . . . . . . . . . . . . . . . . . . 8
4. Distinguishing Flows. . . . . . . . . . . . . . . . . . . . . 8
4.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. IP Traffic Flow. . . . . . . . . . . . . . . . . . . . 3
2.2. Observation Point. . . . . . . . . . . . . . . . . . . 4
2.3. Metering Process . . . . . . . . . . . . . . . . . . . 4
2.4. Flow Record. . . . . . . . . . . . . . . . . . . . . . 5
2.5. Exporting Process. . . . . . . . . . . . . . . . . . . 5
2.6. Collecting Process . . . . . . . . . . . . . . . . . . 5
3. Applications Requiring IP Flow Information Export . . . . . . 6
3.1. Usage-based Accounting . . . . . . . . . . . . . . . . 6
3.2. Traffic Profiling. . . . . . . . . . . . . . . . . . . 7
3.3. Traffic Engineering. . . . . . . . . . . . . . . . . . 7
3.4. Attack/Intrusion Detection . . . . . . . . . . . . . . 7
3.5. QoS Monitoring . . . . . . . . . . . . . . . . . . . . 8
4. Distinguishing Flows. . . . . . . . . . . . . . . . . . . . . 8
4.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . 9
4.3. IP Header Fields . . . . . . . . . . . . . . . . . . . 9
4.4. Transport Header Fields. . . . . . . . . . . . . . . . 10
4.5. MPLS Label . . . . . . . . . . . . . . . . . . . . . . 10
4.6. DiffServ Code Point. . . . . . . . . . . . . . . . . . 10
5. Metering Process. . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Reliability. . . . . . . . . . . . . . . . . . . . . . 10
5.2. Sampling . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Overload Behavior. . . . . . . . . . . . . . . . . . . 11
5.4. Timestamps . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Time Synchronization . . . . . . . . . . . . . . . . . 12
5.6. Flow Expiration. . . . . . . . . . . . . . . . . . . . 13
5.7. Multicast Flows. . . . . . . . . . . . . . . . . . . . 13
5.8. Packet Fragmentation . . . . . . . . . . . . . . . . . 13
5.9. Ignore Port Copy . . . . . . . . . . . . . . . . . . . 13
6. Data Export . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Information Model. . . . . . . . . . . . . . . . . . . 14
6.2. Data Model . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Data Transfer. . . . . . . . . . . . . . . . . . . . . 16
6.3.1. Congestion Awareness. . . . . . . . . . . . . . 16
6.3.2. Reliability . . . . . . . . . . . . . . . . . . 17
6.3.3. Security. . . . . . . . . . . . . . . . . . . . 18
6.4. Push and Pull Mode Reporting . . . . . . . . . . . . . 18
6.5. Regular Reporting Interval . . . . . . . . . . . . . . 18
6.6. Notification on Specific Events. . . . . . . . . . . . 18
6.7. Anonymization. . . . . . . . . . . . . . . . . . . . . 18
7. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Configuration of the Metering Process. . . . . . . . . 19
7.2. Configuration of the Exporting Process . . . . . . . . 19
8. General Requirements. . . . . . . . . . . . . . . . . . . . . 20
8.1. Openness . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Scalability. . . . . . . . . . . . . . . . . . . . . . 20
8.3. Several Collecting Processes . . . . . . . . . . . . . 20
9. Special Device Considerations . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10.1. Disclosure of Flow Information Data. . . . . . . . . . 23
10.2. Forgery of Flow Records. . . . . . . . . . . . . . . . 24
10.3. Denial of Service (DoS) Attacks. . . . . . . . . . . . 24
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
12. Appendix: Derivation of Requirements from Applications. . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . 31
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
4.3. IP Header Fields . . . . . . . . . . . . . . . . . . . 9
4.4. Transport Header Fields. . . . . . . . . . . . . . . . 10
4.5. MPLS Label . . . . . . . . . . . . . . . . . . . . . . 10
4.6. DiffServ Code Point. . . . . . . . . . . . . . . . . . 10
5. Metering Process. . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Reliability. . . . . . . . . . . . . . . . . . . . . . 10
5.2. Sampling . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Overload Behavior. . . . . . . . . . . . . . . . . . . 11
5.4. Timestamps . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Time Synchronization . . . . . . . . . . . . . . . . . 12
5.6. Flow Expiration. . . . . . . . . . . . . . . . . . . . 13
5.7. Multicast Flows. . . . . . . . . . . . . . . . . . . . 13
5.8. Packet Fragmentation . . . . . . . . . . . . . . . . . 13
5.9. Ignore Port Copy . . . . . . . . . . . . . . . . . . . 13
6. Data Export . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Information Model. . . . . . . . . . . . . . . . . . . 14
6.2. Data Model . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Data Transfer. . . . . . . . . . . . . . . . . . . . . 16
6.3.1. Congestion Awareness. . . . . . . . . . . . . . 16
6.3.2. Reliability . . . . . . . . . . . . . . . . . . 17
6.3.3. Security. . . . . . . . . . . . . . . . . . . . 18
6.4. Push and Pull Mode Reporting . . . . . . . . . . . . . 18
6.5. Regular Reporting Interval . . . . . . . . . . . . . . 18
6.6. Notification on Specific Events. . . . . . . . . . . . 18
6.7. Anonymization. . . . . . . . . . . . . . . . . . . . . 18
7. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Configuration of the Metering Process. . . . . . . . . 19
7.2. Configuration of the Exporting Process . . . . . . . . 19
8. General Requirements. . . . . . . . . . . . . . . . . . . . . 20
8.1. Openness . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Scalability. . . . . . . . . . . . . . . . . . . . . . 20
8.3. Several Collecting Processes . . . . . . . . . . . . . 20
9. Special Device Considerations . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10.1. Disclosure of Flow Information Data. . . . . . . . . . 23
10.2. Forgery of Flow Records. . . . . . . . . . . . . . . . 24
10.3. Denial of Service (DoS) Attacks. . . . . . . . . . . . 24
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
12. Appendix: Derivation of Requirements from Applications. . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . 31
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
There are several applications that require flow-based IP traffic measurements. Such measurements could be performed by a router while forwarding the traffic, by a middlebox [RFC3234], or by a traffic measurement probe attached to a line or a monitored port. This memo defines requirements for exporting traffic flow information out of these boxes for further processing by applications located on other devices. They serve as input to the standardization of the IPFIX protocol specifications.
有几个应用程序需要基于流的IP流量测量。这种测量可以由路由器在转发流量时执行，也可以由中间盒[RFC3234]执行，或者由连接到线路或受监控端口的流量测量探头执行。此备忘录定义了从这些框中导出交通流信息以供位于其他设备上的应用程序进一步处理的要求。它们作为IPFIX协议规范标准化的输入。
In section 3, a selection of such applications is presented. The following sections list requirements derived from these applications.
第3节介绍了此类应用的选择。以下各节列出了从这些应用程序派生的需求。
In its early discussions the IPFIX Working Group chose to evaluate existing flow export protocols at the same time it was developing this 'requirements' document.
在早期讨论中，IPFIX工作组选择在开发此“需求”文档的同时评估现有的流导出协议。
Flow export, however, is not performed by a protocol acting alone, it also requires a system of co-operating processes. In producing IPFIX requirements, therefore, the Working Group decided to specify what was required by these various processes - the metering process, the exporting process, etc. In these specifications we use lower-case for the words must, may, and should, to indicate that IPFIX implementors have some freedom as to how to meet the requirements.
然而，流导出不是由单独的协议执行的，它还需要一个协作过程系统。因此，在制定IPFIX要求时，工作组决定具体说明这些不同过程所需的内容——计量过程、导出过程等。在这些规范中，我们使用小写字母表示“必须”、“可以”和“应该”，以表明IPFIX实施者在如何满足要求方面有一定的自由。
The Working Group's goal is to produce standards-track RFCs describing the IPFIX information model and export protocol RFCs. As well as meeting the requirements set out in this document, the information model and protocol documents will provide a full specification of the IPFIX system, and will use uppercase keywords as in [RFC 2119].
工作组的目标是生成描述IPFIX信息模型和导出协议RFC的标准跟踪RFC。除了满足本文件规定的要求外，信息模型和协议文件还将提供IPFIX系统的完整规范，并将使用[RFC 2119]中的大写关键字。
The following terminology is used in this document:
本文件使用以下术语：
There are several definitions of the term 'flow' being used by the Internet community. Within this document we use the following one:
互联网社区使用的术语“流”有几种定义。在本文件中，我们使用以下内容：
A flow is defined as a set of IP packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of:
流定义为在一定时间间隔内通过网络中观察点的一组IP数据包。属于特定流的所有数据包都有一组公共属性。每个属性定义为将函数应用于以下值的结果：
1. one or more packet header field (e.g., destination IP address), transport header field (e.g., destination port number), or application header field (e.g., RTP header fields [RFC3550])
1. 一个或多个数据包头字段（例如，目的地IP地址）、传输头字段（例如，目的地端口号）或应用程序头字段（例如，RTP头字段[RFC3550]）
2. one or more characteristics of the packet itself (e.g., number of MPLS labels, etc.)
2. 数据包本身的一个或多个特征（例如，MPLS标签的数量等）
3. one or more of fields derived from packet treatment (e.g., next hop IP address, the output interface, etc.)
3. 从数据包处理派生的一个或多个字段（例如，下一跳IP地址、输出接口等）
A packet is defined to belong to a flow if it completely satisfies all the defined properties of the flow.
如果数据包完全满足流的所有定义属性，则它被定义为属于流。
This definition covers the range from a flow containing all packets observed at a network interface to a flow consisting of just a single packet between two applications with a specific sequence number. Please note that the flow definition does not necessarily match a general application-level end-to-end stream. However, an application may derive properties of application-level streams by processing measured flow data. Also, please note that although packet properties may depend on application headers, there is no requirement defined in this document related to application headers.
此定义涵盖了从包含在网络接口上观察到的所有数据包的流到仅包含具有特定序列号的两个应用程序之间的单个数据包的流的范围。请注意，流定义不一定与一般应用程序级别的端到端流匹配。然而，应用程序可以通过处理测量的流数据来导出应用程序级流的属性。另外，请注意，尽管数据包属性可能取决于应用程序头，但本文档中没有定义与应用程序头相关的要求。
The observation point is a location in the network where IP packets can be observed. Examples are a line to which a probe is attached, a shared medium such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router.
观察点是网络中可以观察IP数据包的位置。例如，探针连接的线路、共享介质（如基于以太网的LAN）、路由器的单个端口或路由器的一组接口（物理或逻辑）。
Note that one observation point may be a superset of several other observation points. For example one observation point can be an entire line card. This would be the superset of the individual observation points at the line card's interfaces.
请注意，一个观测点可能是其他几个观测点的超集。例如，一个观察点可以是一张完整的线卡。这将是线路卡接口处单个观测点的超集。
The metering process generates flow records. Input to the process are packet headers observed at an observation point and packet treatment at the observation point, for example the selected output interface. The metering process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining flow records.
计量过程生成流量记录。流程的输入是在观察点观察到的数据包头和在观察点（例如所选的输出接口）进行的数据包处理。计量过程由一组功能组成，包括数据包头捕获、时间戳、采样、分类和维护流记录。
The maintenance of flow records may include creating new records, updating existing ones, computing flow statistics, deriving further flow properties, detecting flow expiration, passing flow records to the exporting process, and deleting flow records.
流记录的维护可能包括创建新记录、更新现有记录、计算流统计信息、导出进一步的流属性、检测流过期、将流记录传递给导出过程以及删除流记录。
The sampling function and the classifying function may be applied more than once with different parameters. Figure 1 shows the sequence in which the functions are applied. Sampling is not illustrated in the figure; it may be applied before any other function.
采样函数和分类函数可以使用不同的参数多次应用。图1显示了应用函数的顺序。图中未说明取样；它可以在任何其他功能之前应用。
packet header capturing
|
timestamping
|
v
+----->+
| |
| classifying
| |
+------+
|
maintaining flow records
|
v
packet header capturing
|
timestamping
|
v
+----->+
| |
| classifying
| |
+------+
|
maintaining flow records
|
v
Figure 1: Functions of the metering process
图1：计量过程的功能
A flow record contains information about a specific flow that was metered at an observation point. A flow record contains measured properties of the flow (e.g., the total number of bytes of all packets of the flow) and usually characteristic properties of the flow (e.g., source IP address).
流量记录包含有关在观测点测量的特定流量的信息。流记录包含流的测量属性（例如，流的所有数据包的总字节数）和流的通常特征属性（例如，源IP地址）。
The exporting process sends flow records to one or more collecting processes. The flow records are generated by one or more metering processes.
导出进程将流记录发送到一个或多个收集进程。流量记录由一个或多个计量过程生成。
The collecting process receives flow records from one or more exporting processes. The collecting process might store received flow records or further process them, but these actions are out of the scope of this document.
收集进程从一个或多个导出进程接收流记录。收集过程可能存储收到的流记录或进一步处理它们，但这些操作不在本文档的范围内。
This section describes a selection of applications requiring IP flow information export. Because requirements for flow export listed in further sections below are derived from these applications, their selection is crucial. The goal of this requirements document is not to cover all possible applications with all their flow export requirements, but to cover applications which are considered to be of significant importance in today's and/or future IP networks, and for which requirements can be met with reasonable technical effort.
本节介绍需要导出IP流信息的应用程序的选择。由于以下各节中列出的流量输出要求源自这些应用程序，因此其选择至关重要。本要求文件的目标不是涵盖所有可能的应用及其所有流量输出要求，而是涵盖被认为在当今和/或未来IP网络中具有重要意义的应用，以及可以通过合理的技术努力满足要求的应用。
The list of applications should lead to a better understanding of the requirements which is particularly important when designing or implementing traffic flow metering functions. A detailed overview of which requirement was derived from which application(s) is given in the appendix.
应用程序列表应有助于更好地理解设计或实施交通流量计量功能时特别重要的要求。附录中给出了从应用程序中导出的需求的详细概述。
Please note that the described applications can have a large number of differing implementations. Requirement details or requirement significance (required (must), recommended (should), optional (may)) could differ for specific implementations and/or for specific application scenarios. Therefore we derive the requirements from the general functionality of the selected applications. Some particular cases will even mandate more stringent requirements than the ones defined in this document. For example, usage-based accounting is certainly the application that will probably mandate the highest degree of reliability amongst the applications discussed below. The reliability requirements defined in sections 5.1 and 6.3.2. are not sufficient to guarantee the level of reliability that is needed for many usage-based accounting systems. Particular reliability requirements for accounting systems are discussed in [RFC2975].
请注意，所描述的应用程序可以有大量不同的实现。对于特定的实现和/或特定的应用场景，需求细节或需求重要性（必需（必须）、建议（应该）、可选（可能））可能会有所不同。因此，我们从所选应用程序的一般功能中导出需求。一些特殊情况甚至要求比本文件中定义的要求更严格。例如，在下面讨论的应用程序中，基于使用情况的会计肯定是要求可靠性最高的应用程序。第5.1节和第6.3.2节中规定的可靠性要求。不足以保证许多基于使用的会计系统所需的可靠性水平。[RFC2975]中讨论了会计系统的特殊可靠性要求。
Several new business models for selling IP services and IP-based services are currently under investigation. Beyond flat rate services which do not need accounting, accounting can be based on time or volume. Accounting data can serve as input for billing systems. Accounting can be performed per user or per user group, it can be performed just for basic IP service or individually per high-level service and/or per content type delivered. For advanced/future services, accounting may also be performed per class of service, per application, per time of day, per (label switched) path used, etc.
目前正在调查几种销售IP服务和基于IP的服务的新商业模式。除了不需要记帐的固定费率服务外，记帐可以基于时间或数量。会计数据可以作为计费系统的输入。记帐可以按用户或按用户组执行，也可以仅为基本IP服务执行，也可以按高级服务和/或按交付的内容类型单独执行。对于高级/未来服务，还可以按照服务类别、应用程序、时间、使用的（标签交换）路径等进行计费。
Traffic profiling is the process of characterizing IP flows by using a model that represents key parameters of the flows such as flow duration, volume, time, and burstiness. It is a prerequisite for network planning, network dimensioning, trend analysis, business model development, and other activities. It depends heavily on the particular traffic profiling objective(s), which statistics, and which accuracy are required from the measurements. Typical information needed for traffic profiling is the distribution of used services and protocols in the network, the amount of packets of a specific type (e.g., percentage of IPv6 packets) and specific flow profiles.
流量分析是通过使用表示流的关键参数（如流持续时间、流量、时间和突发性）的模型来描述IP流的过程。它是网络规划、网络尺寸确定、趋势分析、业务模型开发和其他活动的先决条件。这在很大程度上取决于特定的流量分析目标、哪些统计数据以及测量所需的准确性。流量分析所需的典型信息是网络中使用的服务和协议的分布、特定类型的数据包数量（例如，IPv6数据包的百分比）和特定的流分析。
Since objectives for traffic profiling can vary, this application requires a high flexibility of the measurement infrastructure, especially regarding the options for measurement configuration and packet classification.
由于流量分析的目标可能不同，因此该应用程序需要测量基础设施的高度灵活性，特别是关于测量配置和数据包分类的选项。
Traffic Engineering (TE) comprises methods for measurement, modelling, characterization and control of a network. The goal of TE is the optimization of network resource utilization and traffic performance [RFC2702]. Since control and administrative reaction to measurement results requires access to the involved network nodes, TE mechanisms and the required measurement function usually are performed within one administrative domain. Typical parameters required for TE are link utilization, load between specific network nodes, number, size and entry/exit points of the active flows and routing information.
交通工程（TE）包括网络的测量、建模、表征和控制方法。TE的目标是优化网络资源利用率和流量性能[RFC2702]。由于对测量结果的控制和管理反应需要访问相关的网络节点，因此TE机制和所需的测量功能通常在一个管理域内执行。TE所需的典型参数是链路利用率、特定网络节点之间的负载、活动流的数量、大小和入口/出口点以及路由信息。
Capturing flow information plays an important role for network security, both for detection of security violation, and for subsequent defense. In case of a Denial of Service (DOS) attack, flow monitoring can allow detection of unusual situations or suspicious flows. In a second step, flow analysis can be performed in order to gather information about the attacking flows, and for deriving a defense strategy.
捕获流信息对于网络安全起着重要作用，无论是检测安全违规还是后续防御。在拒绝服务（DOS）攻击的情况下，流监视可以检测异常情况或可疑流。在第二步中，可以执行流分析，以收集关于攻击流的信息，并导出防御策略。
Intrusion detection is a potentially more demanding application which would not only look at specific characteristics of flows, but may also use a stateful packet flow analysis for detecting specific, suspicious activities, or unusually frequent activities. Such activities may be characterized by specific communication patterns, detectable by characteristic sequences of certain packet types.
入侵检测是一个潜在的要求更高的应用程序，它不仅可以查看流的特定特征，还可以使用有状态数据包流分析来检测特定的、可疑的活动或异常频繁的活动。这种活动可以由特定的通信模式来表征，通过特定分组类型的特征序列来检测。
QoS monitoring is the passive measurement of quality parameters for IP flows. In contrast to active measurements, passive measurements utilize the existing traffic in the network for QoS analysis. Since no test traffic is sent, passive measurements can only be applied in situations where the traffic of interest is already present in the network. One example application is the validation of QoS parameters negotiated in a service level specification. Note that passive/active measurement is also referred to as non-intrusive/intrusive measurement or as measurement of observed/synthetic traffic.
QoS监控是对IP流质量参数的被动测量。与主动测量相比，被动测量利用网络中的现有流量进行QoS分析。由于没有发送测试流量，被动测量只能应用于感兴趣的流量已经存在于网络中的情况。一个示例应用是验证服务级别规范中协商的QoS参数。注意，被动/主动测量也称为非侵入式/侵入式测量或观测/合成流量测量。
Passive measurements cannot provide the kind of controllable experiments that can be achieved with active measurements. On the other hand passive measurements do not suffer from undesired side effects caused by sending test traffic (e.g., additional load, potential differences in treatment of test traffic and real customer traffic).
被动测量不能提供主动测量可以实现的可控实验。另一方面，被动测量不会遭受由发送测试流量引起的不希望的副作用（例如，额外负载、测试流量和实际客户流量处理的潜在差异）。
QoS monitoring often requires the correlation of data from multiple observation points (e.g., for measuring one-way metrics). This requires proper clock synchronization of the involved metering processes. For some measurements, flow records and/or notifications on specific events at the different observation points must be correlated, for example the arrival of a certain packet. For this, the provisioning of post-processing functions (e.g., the generation of packet IDs) at the metering processes would be useful. Since QoS monitoring can lead to a huge amount of measurement result data, it would highly benefit from mechanisms to reduce the measurement data, like aggregation of results and sampling.
QoS监控通常需要多个观测点的数据关联（例如，用于测量单向度量）。这需要相关计量过程的适当时钟同步。对于某些测量，不同观测点的特定事件的流量记录和/或通知必须相互关联，例如某个数据包的到达。为此，在计量过程中提供后处理功能（例如，生成分组id）将是有用的。由于QoS监控可能会产生大量的测量结果数据，因此减少测量数据的机制（如结果聚合和采样）将非常有益。
Please note that not all requirements for QoS monitoring are covered by the IPFIX requirements specified in the following sections. The IPFIX requirements are targeted at per flow information including summaries of per-packet properties for packets within a flow, but not per-packet information itself. For example jitter measurement requires timestamping each packet and reporting of all timestamps of a flow, but the IPFIX requirements only cover timestamps of first and last packet of a flow.
请注意，并非所有QoS监控要求都包含在以下章节中指定的IPFIX要求中。IPFIX要求针对每个流信息，包括流中数据包的每个数据包属性摘要，但不是每个数据包信息本身。例如，抖动测量要求对每个数据包加上时间戳并报告流的所有时间戳，但IPFIX要求仅涵盖流的第一个和最后一个数据包的时间戳。
Packets are mapped to flows by evaluating their properties. Packets with common properties are considered to belong to the same flow. A packet showing at least one difference in the set of properties is considered to belong to a different flow.
数据包通过评估其属性映射到流。具有公共属性的数据包被认为属于同一个流。显示属性集合中至少一个差异的数据包被认为属于不同的流。
The following subsections list a set of properties which a metering process must, should, or may be able to evaluate for mapping packets to flows. Please note that requiring the ability to evaluate a certain property does not imply that this property must be evaluated for each packet. In other words, meeting the IPFIX requirements means that the metering process in general must be able, via its configuration, to somehow support to distinguish flows via all the must fields, even if in certain circumstances/for certain applications, only a subset of the must fields is needed and effectively used to distinguish flows.
以下小节列出了一组属性，计量过程必须、应该或可能能够评估这些属性，以便将数据包映射到流。请注意，要求能够评估某个属性并不意味着必须为每个数据包评估该属性。换句话说，满足IPFIX要求意味着计量过程通常必须能够通过其配置以某种方式支持通过所有必须字段区分流量，即使在某些情况下/对于某些应用，只需要必须字段的一个子集并有效地用于区分流量。
Which combination of properties is used for distinguishing flows and how these properties are evaluated depends on the configuration of the metering process. The configured choice of evaluated properties strongly depends on the environment and purpose of the measurement and on the information required by the collecting process. But in any case, a collecting process must be able to clearly identify, for each received flow record, which set of properties was used for distinguishing this flow from other ones.
用于区分流量的属性组合以及如何评估这些属性取决于计量过程的配置。评估属性的配置选择在很大程度上取决于测量的环境和目的以及收集过程所需的信息。但在任何情况下，收集过程都必须能够为每个接收到的流记录清楚地识别用于区分此流和其他流的属性集。
For specific deployments, only a subset of the required properties listed below can be used to distinguish flows. For example, in order to aggregate the flow records and reduce the number of flow records exported. On the other hand, some other deployments will require distinguishing flows by some extra parameters, such as the TTL field of the IP header or the BGP Autonomous System number [RFC1771] of the IP destination address.
对于特定部署，只能使用下面列出的所需属性的子集来区分流。例如，为了聚合流记录并减少导出的流记录数。另一方面，一些其他部署将需要通过一些额外参数来区分流，例如IP头的TTL字段或IP目标地址的BGP自治系统号[RFC1771]。
If encryption is used, the metering process might not be able to access all header fields. A metering process must meet the requirements stated in this section 4 only for packets that have the relevant header fields not encrypted.
如果使用加密，计量过程可能无法访问所有标题字段。计量过程必须满足第4节中规定的要求，仅适用于具有未加密的相关报头字段的数据包。
The metering process must be able to separate flows by the incoming interface or by the outgoing interface or by both of them.
计量过程必须能够通过输入接口或输出接口或两者分离流量。
The metering process must be able to separate flows by the following fields of the IP header:
计量过程必须能够通过IP报头的以下字段分离流量：
1. source IP address
1. 源IP地址
2. destination IP address
2. 目标IP地址
3. protocol type (TCP, UDP, ICMP, ...)
3. 协议类型（TCP、UDP、ICMP等）
For source address and destination address, separating by full match must be supported as well as separation by prefix match.
对于源地址和目标地址，必须支持按完全匹配分隔以及按前缀匹配分隔。
The metering process should be able to separate flows by the IP version number if the observation point is located at a device that is supporting more than one IP version.
如果观测点位于支持多个IP版本的设备上，则计量过程应能够通过IP版本号分离流量。
The metering process must be able to separate flows by the port numbers of the transport header in case of TCP or UDP being used as transport protocol. The metering process should be able to separate flows by the port numbers of the transport header in case of SCTP [RFC2960].
在TCP或UDP用作传输协议的情况下，计量过程必须能够通过传输头的端口号分离流。在SCTP[RFC2960]的情况下，计量过程应能够通过传输头的端口号分离流量。
For separation, both, source and destination port number must be supported for distinguishing flows, individually as well as in combination.
对于分离，必须同时支持源端口号和目标端口号，以单独或组合区分流。
If the observation point is located at a device supporting Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering process must be able to separate flows by the MPLS label.
如果观测点位于支持多协议标签交换（MPLS，请参见[RFC3031]）的设备上，则计量过程必须能够通过MPLS标签分离流。
If the observation point is located at a device supporting Differentiated Services (DiffServ) then the metering process must be able to separate flows by the DiffServ Code Point (DSCP, see [RFC2474]).
如果观察点位于支持区分服务（DiffServ）的设备上，则计量过程必须能够通过区分服务代码点（DSCP，请参阅[RFC2474]）分离流。
The following are requirements for the metering process. All measurements must be conducted from the point of view of the observation point.
以下是计量过程的要求。所有测量必须从观察点的角度进行。
The metering process must either be reliable or the absence of reliability must be known and indicated. The metering process is reliable if each packet passing the observation point is metered according to the configuration of the metering process. If, e.g.,
计量过程必须是可靠的，或者必须知道并指出缺乏可靠性。如果根据计量过程的配置对通过观测点的每个数据包进行计量，则计量过程是可靠的。如果，例如。，
due to some overload, not all passing packets can be included into the metering process, then the metering process must be able to detect this failure and to report it.
由于一些过载，并不是所有通过的数据包都可以包含在计量过程中，那么计量过程必须能够检测到此故障并报告它。
Sampling describes the systematic or random selection of a subset of elements (the sample) out of a set of elements (the parent population). Usually the purpose of applying sampling techniques is to estimate a parameter of the parent population by using only the elements of the subset. Sampling techniques can be applied for instance to select a subset of packets out of all packets of a flow or to select a subset of flows out of all flows on a link. Sampling methods differ in their sampling strategy (e.g., systematic or random) and in the event that triggers the selection of an element. The selection of one packet can for instance be triggered by its arrival time (time-based sampling), by its position in the flow (count-based sampling) or by the packet content (content-based sampling).
抽样描述了从一组元素（父总体）中系统地或随机地选择元素子集（样本）。通常，应用抽样技术的目的是仅使用子集的元素来估计父总体的参数。例如，可以应用采样技术从流的所有分组中选择分组的子集，或者从链路上的所有流中选择流的子集。采样方法在其采样策略（例如，系统或随机）和触发元素选择的事件方面有所不同。例如，一个分组的选择可由其到达时间（基于时间的采样）、其在流中的位置（基于计数的采样）或分组内容（基于内容的采样）触发。
The metering process may support packet sampling. If sampling is supported, the sampling configuration must be well defined. The sampling configuration includes the sampling method and all its parameters.
计量过程可以支持分组采样。如果支持采样，则必须明确定义采样配置。采样配置包括采样方法及其所有参数。
If the sampling configuration is changed during operation, the new sampling configuration with its parameters must be indicated to all collecting processes receiving the affected flow records. Changing the sampling configuration includes: adding a sampling function to the metering process, removing a sampling function from the metering process, change sampling method, and change sampling parameter(s).
如果在操作过程中更改了采样配置，则必须向接收受影响流量记录的所有采集过程指示新的采样配置及其参数。更改采样配置包括：向计量过程添加采样功能、从计量过程中删除采样功能、更改采样方法和更改采样参数。
In case of any change in the sampling configuration, all flow records metered by the previous sampling configuration must be terminated and exported according to the export configuration. The metering process must not merge the flow records generated with the new sampling configuration with the flow records generated with the previous sampling configuration.
如果采样配置发生任何变化，则必须根据导出配置终止并导出以前采样配置测量的所有流量记录。计量过程不得将新取样配置生成的流量记录与先前取样配置生成的流量记录合并。
In case of an overload, for example lack of memory or processing power, the metering process may change its behavior in order to cope with the lack of resources. Possible reactions include:
在过载的情况下，例如缺少内存或处理能力，计量过程可能会改变其行为以应对资源的缺乏。可能的反应包括：
- Reduce the number of flows to be metered. This can be achieved by more coarse-grained flow measurement or by a restriction of the flow records to a subset of the set of original ones.
- 减少要计量的流量数量。这可以通过更粗粒度的流测量或将流记录限制为原始记录集的子集来实现。
- Start sampling packets before they are processed by the metering process or - if sampling is already performed - reduce the sampling frequency.
- 在计量过程处理数据包之前开始采样，或者-如果已经执行采样-降低采样频率。
- Stop metering.
- 停止计量。
- Reducing the resource usage of competing processes on the same device. Example: reducing the packet forwarding throughput
- 减少同一设备上竞争进程的资源使用。示例：降低数据包转发吞吐量
Overload behavior is not restricted to the four options listed above. But in case the overload behavior induces a change of the metering process behavior, the overload behavior must be clearly defined.
重载行为不限于上面列出的四个选项。但如果过载行为导致计量过程行为发生变化，则必须明确定义过载行为。
For some flows, the change of behavior might have an impact on the data that would be stored in the associated flow records after the change, for example if the packet classification is changed or the sampling frequency. These flows must be considered as terminated and the associated flow records must be exported separately from new ones generated after the behavior change. The terminated flow records and new ones generated after the behavior change must not be merged by the metering process. The collecting process must be able to distinguish the affected flow records generated before and after the change of behavior. This requirement does not apply to flows and associated flow records not affected by the change of metering process behavior.
对于某些流，行为的更改可能会对更改后存储在关联流记录中的数据产生影响，例如，如果数据包分类或采样频率发生更改。这些流必须被视为已终止，并且关联的流记录必须与行为更改后生成的新记录分开导出。计量过程不得合并行为更改后生成的终止流记录和新记录。收集过程必须能够区分行为改变前后生成的受影响流量记录。本要求不适用于不受计量过程行为变化影响的流量和相关流量记录。
The metering process must be able to generate timestamps for the first and the last observation of a packet of a flow at the observation point. The timestamp resolution must be at least the one of the sysUpTime [RFC3418], which is one centisecond.
计量过程必须能够在观测点为流数据包的第一次和最后一次观测生成时间戳。时间戳分辨率必须至少为系统正常运行时间[RFC3418]中的一个，即1厘米秒。
It must be possible to synchronize timestamps generated by a metering process with Coordinated Universal Time (UTC).
必须能够将计量过程生成的时间戳与协调世界时（UTC）同步。
Note that the possibility of synchronizing timestamps of each single metering process with UTC implies the possibility of synchronizing timestamps generated by different metering processes.
请注意，将每个计量过程的时间戳与UTC同步的可能性意味着同步不同计量过程生成的时间戳的可能性。
Note that this does not necessarily imply that timestamps generated by the metering process are UTC timestamps. For example, this requirement can be met by using local system clock values as timestamps and adding an additional timestamp when exporting a report to a collecting process. Then the collecting process can synchronize the timestamps by calculating the offset between UTC and the system clock of the metering process.
请注意，这并不一定意味着计量过程生成的时间戳是UTC时间戳。例如，可以通过使用本地系统时钟值作为时间戳并在将报告导出到收集进程时添加额外的时间戳来满足此要求。然后，采集过程可以通过计算UTC和计量过程的系统时钟之间的偏移来同步时间戳。
The metering process must be able to detect flow expirations. A flow is considered to be expired if no packet of this flow has been observed for a given timeout interval. The metering process may support means for detecting the expiration of a flow before a timeout occurs, for example by detecting the FIN or RST bits in a TCP connection. The procedure for detecting a flow expiration must be clearly defined.
计量过程必须能够检测流量过期。如果在给定的超时时间间隔内未观察到此流的数据包，则认为该流已过期。计量过程可以支持用于在超时发生之前检测流过期的装置，例如通过检测TCP连接中的FIN或RST位。必须明确定义检测流量过期的程序。
For multicast flows containing packets replicated to multiple output interfaces, the metering process should be able to maintain discrete flow records per different output interface. For example, the metering process should be able to report an incoming multicast packet that is replicated to four output interfaces in four different flow records that differ by the output interface.
对于包含复制到多个输出接口的数据包的多播流，计量过程应该能够维护每个不同输出接口的离散流记录。例如，计量过程应该能够报告传入的多播数据包，该数据包被复制到四个不同的流记录中的四个输出接口，这四个流记录因输出接口而异。
In case of IP packet fragmentation and depending on the classification scheme, only the zero-offset fragment of a single initial packet might contain sufficient information to classify the packet. Note that this fragment should be the first one generated by the router imposing the fragmentation [RFC791], but might not be the first one observed by the IPFIX device, due to reordering reasons. The metering process may keep state of IP packet fragmentation in order to map fragments that do not contain sufficient header information correctly to flows.
在IP分组分段的情况下，根据分类方案，只有单个初始分组的零偏移片段可能包含足够的信息来对分组进行分类。请注意，此片段应该是由实施碎片[RFC791]的路由器生成的第一个片段，但由于重新排序的原因，可能不是IPFIX设备观察到的第一个片段。计量过程可以保持IP分组分段的状态，以便将不包含足够报头信息的分段正确地映射到流。
The metering process may be able to ignore packets which are generated by a port copy function acting at the device where the observation point of a flow is located.
计量过程可以能够忽略由在流的观察点所在的设备处起作用的端口复制功能生成的分组。
The following are requirements for exporting flow records out of the exporting process. Beside requirements on the data transfer, we separate requirements concerning the information model from requirements concerning the data model. Furthermore, we list requirements on reporting times and notification on specific events, and on anonymization of flow records.
以下是从导出过程中导出流记录的要求。除了对数据传输的要求外，我们还将有关信息模型的要求与有关数据模型的要求分开。此外，我们还列出了关于特定事件的报告时间和通知以及流记录匿名化的要求。
The information model for the flow information export is the list of attributes of a flow to be contained in the report (including the semantics of the attributes).
流信息导出的信息模型是要包含在报告中的流的属性列表（包括属性的语义）。
This section lists attributes an exporting process must, should or may be able to report. This does not imply that each exported flow record must contain all required attributes. But it implies that it must be possible to configure the exporting process in a way that the information of all required attributes can be transmitted from the exporting process to the receiving collecting process(es) for each exported flow.
本节列出了导出过程必须、应该或可能报告的属性。这并不意味着每个导出的流记录必须包含所有必需的属性。但这意味着必须能够以一种方式配置导出流程，即可以将每个导出流的所有必需属性的信息从导出流程传输到接收收集流程。
In other words, meeting the IPFIX requirements means that the exporting process in general must be able, via its configuration, to somehow support to report all the must fields, even if in certain circumstances or for certain applications, only a subset of the set of all must fields is needed and effectively reported.
换句话说，满足IPFIX要求意味着导出过程通常必须能够通过其配置以某种方式支持报告所有必须字段，即使在某些情况下或对于某些应用程序，只需要并有效报告所有必须字段集合的子集。
Beyond that, the exporting process might offer to report further attributes not mentioned here. A particular flow record may contain some of the "required" attributes as well as some additional ones, for example covering future technologies.
除此之外，导出过程可能会报告此处未提及的其他属性。特定的流记录可能包含一些“必需”属性以及一些附加属性，例如涵盖未来技术的属性。
This document does not impose that the following attributes are reported for every single flow record, especially for repetitive attributes. For example, if the observation point is the incoming packet stream at the IP interface with the ifIndex value 3, then this observation point does not have to be exported as part of every single flow record. Exporting it just once might give sufficient information to the collecting process.
本文件并未强制要求为每个单独的流记录报告以下属性，尤其是重复属性。例如，如果观察点是IP接口处ifIndex值为3的传入数据包流，则该观察点不必作为每个流记录的一部分导出。仅导出一次可能会为收集过程提供足够的信息。
The exporting process must be able to report the following attributes for each metered flow:
导出过程必须能够报告每个计量流量的以下属性：
1. IP version number This requirement only applies if the observation point is located at a device supporting more than one version of IP.
1. IP版本号仅当观测点位于支持多个IP版本的设备上时，此要求才适用。
2. source IP address 3. destination IP address 4. IP protocol type (TCP,UDP,ICMP,...) 5. if protocol type is TCP or UDP: source TCP/UDP port number 6. if protocol type is TCP or UDP: destination TCP/UDP port number 7. packet counter If a packet is fragmented, each fragment is counted as an individual packet. 8. byte counter The sum of the total length in bytes of all IP packets belonging to the flow. The total length of a packet covers IP header and IP payload. 9. type of service octet (in case of IPv4), traffic class octet (in case of IPv6). According to [RFC2474], these octets include the DiffServ Code Point that has a length of 6 bits. 10. in case of IPv6: Flow Label 11. if MPLS is supported at the observation point: the top MPLS label or the corresponding forwarding equivalence class (FEC, [RFC3031]) bound to that label. The FEC is typically defined by an IP prefix. 12. timestamp of the first packet of the flow 13. timestamp of the last packet of the flow 14. if sampling is used: sampling configuration 15. unique identifier of the observation point 16. unique identifier of the exporting process
2. 源IP地址3。目标IP地址4。IP协议类型（TCP、UDP、ICMP等）5。如果协议类型为TCP或UDP：源TCP/UDP端口号6。如果协议类型为TCP或UDP：目标TCP/UDP端口号7。数据包计数器如果一个数据包是分段的，则每个数据包都被计算为一个单独的数据包。8.字节计数器属于流的所有IP数据包的总长度（以字节为单位）之和。数据包的总长度包括IP报头和IP有效负载。9服务八位组类型（IPv4情况下）、流量类八位组（IPv6情况下）。根据[RFC2474]，这些八位字节包括长度为6位的DiffServ码点。10如果是IPv6：流标签11。如果在观察点支持MPLS：顶部MPLS标签或绑定到该标签的相应转发等价类（FEC，[RFC3031]）。FEC通常由IP前缀定义。12流13的第一分组的时间戳。流14的最后一个分组的时间戳。如果使用采样：采样配置15。观察点16的唯一标识符。导出过程的唯一标识符
The exporting process should be able to report the following attributes for each metered flow:
导出过程应能够报告每个计量流量的以下属性：
17. if protocol type is ICMP: ICMP type and code 18. input interface (ifIndex) This requirement does not apply if the observation point is located at a probe device. 19. output interface (ifIndex) This requirement does not apply if the observation point is located at a probe device. 20. multicast replication factor the number of outgoing packets originating from a single incoming multicast packet. This is a dynamic property of multicast flows, that may change over time. For unicast flows it has the constant value 1. The reported value must be the value of the factor at the time the flow record is exported.
17. 如果协议类型为ICMP：ICMP类型和代码18。输入接口（ifIndex）如果观测点位于探头装置上，则此要求不适用。19输出接口（ifIndex）如果观测点位于探头装置上，则此要求不适用。20多播复制因子源于单个传入多播数据包的传出数据包数。这是多播流的一个动态属性，可能会随时间而变化。对于单播流，它具有常量值1。报告的值必须是导出流量记录时的系数值。
The exporting process may be able to report the following attributes for each metered flow:
导出过程可能能够报告每个计量流量的以下属性：
21. Time To Live (in case of IPv4) or Hop Limit (in case of IPv6)
21. 生存时间（对于IPv4）或跃点限制（对于IPv6）
22. IP header flags 23. TCP header flags 24. dropped packet counter at the observation point If a packet is fragmented, each fragment must be counted as an individual packet. 25. fragmented packet counter counter of all packets for which the fragmented bit is set in the IP header 26. next hop IP address 27. source BGP Autonomous System number (see [RFC1771]) 28. destination BGP Autonomous System number 29. next hop BGP Autonomous System number
22. IP报头标志23。TCP头标志24。观察点丢弃的数据包计数器如果一个数据包是碎片，则每个碎片都必须作为一个单独的数据包计数。25在IP报头26中为其设置分段比特的所有分组的分段分组计数器。下一跳IP地址27。来源BGP自治系统编号（见[RFC1771]）28。目的地BGP自治系统编号29。下一跳BGP自治系统编号
The data model describes how information is represented in flow records.
数据模型描述了如何在流记录中表示信息。
The data model must be extensible for future attributes to be added. Even if a set of attributes is fixed in the flow record, the data model must provide a way of extending the record by configuration or for certain implementations.
数据模型必须是可扩展的，以便将来添加属性。即使流记录中的一组属性是固定的，数据模型也必须提供一种通过配置或某些实现扩展记录的方法。
The data model used for exporting flow information must be flexible concerning the flow attributes contained in flow records. A flexible record format would offer the possibility of defining records in a flexible (customizable) way regarding the number and type of contained attributes.
用于导出流信息的数据模型必须灵活考虑流记录中包含的流属性。灵活的记录格式可以以灵活（可定制）的方式定义包含属性的数量和类型。
The data model should be independent of the underlying transport protocol, i.e., the data transfer.
数据模型应独立于底层传输协议，即数据传输。
Requirements for the data transfer include reliability, congestion awareness, and security requirements. For meeting these requirements the exporting process can utilize existing security features provided by the device hosting the process and/or provided by the transport network. For example it can use existing security technologies for authentication and encryption or it can rely on physical protection of a separated network for transferring flow information.
数据传输的要求包括可靠性、拥塞感知和安全要求。为了满足这些要求，导出过程可以利用托管该过程的设备和/或传输网络提供的现有安全功能。例如，它可以使用现有的安全技术进行身份验证和加密，也可以依靠独立网络的物理保护来传输流信息。
For the data transfer, a congestion aware protocol must be supported.
对于数据传输，必须支持拥塞感知协议。
Loss of flow records during the data transfer from the exporting process to the collecting process must be indicated at the collecting process. This indication must allow the collecting process to gauge the number of flow records lost. Possible reasons for flow records loss include but are not limited to:
在从导出过程到收集过程的数据传输过程中，必须在收集过程中指出流记录的丢失。此指示必须允许收集过程测量丢失的流量记录数。流量记录丢失的可能原因包括但不限于：
1. Metering process limitations: lack of memory, processing power, etc. These limitations are already covered in section 5.1.
1. 计量过程限制：缺少内存、处理能力等。这些限制已在第5.1节中介绍。
2. Exporting process limitations: lack of memory, processing power, etc.
2. 导出进程限制：缺少内存、处理能力等。
3. Data transfer problems: packets that carry flow records sent from the exporting process to the collecting process, are dropped by the network. Examples are connection failures and losses by a transport protocol that specifically offers congestion avoidance without persistent transport-level reliability.
3. 数据传输问题：携带从导出进程发送到收集进程的流记录的数据包被网络丢弃。例如，传输协议导致的连接故障和丢失，该协议专门提供拥塞避免，而没有持久的传输级别可靠性。
4. Collecting process limitations: it may be experiencing congestion and not able to buffer new flows records.
4. 收集进程限制：它可能遇到拥塞，无法缓冲新的流记录。
5. Operation and Maintenance: the collecting process is taken down for maintenance or other administrative purposes.
5. 操作和维护：出于维护或其他管理目的，停止收集过程。
Please note that if an unreliable transport protocol is used, reliability can be provided by higher layers. If reliability is provided by higher layers, only lack of overall reliability must be indicated. For example reordering could be dealt with by adding a sequence number to each packet.
请注意，如果使用了不可靠的传输协议，则更高的层可以提供可靠性。如果可靠性由更高的层提供，则只需指出缺乏整体可靠性。例如，可以通过向每个数据包添加序列号来处理重新排序。
The data transfer between exporting process and collecting process must be open to reliability extensions including at least
导出过程和收集过程之间的数据传输必须对可靠性扩展开放，包括至少
- retransmission of lost flow records, - detection of disconnection and fail-over, and - acknowledgement of flow records by the collecting process.
- 重新传输丢失的流量记录，-检测断开连接和故障转移，以及-收集过程确认流量记录。
This extensibility may be used to provide additional reliability. The extended protocol must still meet the requirements described in this section, particularly, it must still be congestion aware. Therefore, extensions using retransmissions must use exponential backoff.
这种可扩展性可用于提供额外的可靠性。扩展协议必须仍然满足本节所述的要求，尤其是，它必须仍然具有拥塞感知能力。因此，使用重传的扩展必须使用指数退避。
Confidentiality of IPFIX data transferred from an exporting process to a collecting process must be ensured.
必须确保从导出过程传输到收集过程的IPFIX数据的机密性。
Integrity of IPFIX data transferred from an exporting process to a collecting process must be ensured.
必须确保从导出过程传输到收集过程的IPFIX数据的完整性。
Authenticity of IPFIX data transferred from an exporting process to a collecting process must be ensured.
必须确保从导出过程传输到收集过程的IPFIX数据的真实性。
The security requirements have been derived from an analysis of potential security threads. The analysis is summarized in Section 10.
安全需求是通过对潜在安全线程的分析得出的。第10节对分析进行了总结。
In general, there are two ways of deciding on reporting times: push mode and pull mode. In push mode, the exporting process decides without an external trigger when to send flow records. In pull mode, sending flow records is triggered by an explicit request from a collecting process. The exporting process must support push mode reporting, it may support pull mode reporting.
一般来说，决定报告时间有两种方式：推模式和拉模式。在推送模式下，导出过程在没有外部触发器的情况下决定何时发送流记录。在拉模式下，发送流记录由收集进程的显式请求触发。导出过程必须支持推模式报告，它可能支持拉模式报告。
The exporting process should be capable of reporting measured traffic data regularly according to a given interval length.
导出过程应能够根据给定的间隔长度定期报告测量的流量数据。
The exporting process may be capable of sending notifications to a collecting process, if a specific event occurs. Such an event can be, for instance, the arrival of the first packet of a new flow, or the termination of a flow after flow timeout.
如果发生特定事件，导出进程可能能够向收集进程发送通知。例如，这样的事件可以是新流的第一个分组的到达，或者流超时后流的终止。
The exporting process may be capable of anonymizing source and destination IP addresses in flow data before exporting them. It may support anonymization of port numbers and other fields. Please note that anonymization is not originally an application requirement, but derived from general requirements for treatment of measured traffic data within a network.
导出过程可以能够在导出流数据中的源和目的地IP地址之前对其进行匿名化。它可能支持端口号和其他字段的匿名化。请注意，匿名化最初不是应用程序的要求，而是源自网络内测量流量数据处理的一般要求。
For several applications anonymization cannot be applied, for example for accounting and traffic engineering. However, for protecting the network user's privacy, anonymization should be applied whenever
对于一些应用程序，匿名不能应用，例如会计和流量工程。然而，为了保护网络用户的隐私，无论何时都应该使用匿名
possible. In many cases it is sufficient if anonymization is performed at the collecting process after flow information has been exported. This provides a reasonable protection of privacy as long as confidentiality of the export is provided.
可能的在许多情况下，在导出流信息之后，如果在收集过程中执行匿名化就足够了。这提供了合理的隐私保护，只要提供了出口的机密性。
It would be desirable to request that all IPFIX exporters provide anonymization of flow records, but algorithms for anonymization are still a research issue. Several are known but the security they provide and their other properties are not yet studied sufficiently. Also, there is no standardized method for anonymization. Therefore, the requirement for the exporting process supporting anonymization is qualified with 'may' and not with 'must'.
要求所有IPFIX导出程序提供流记录的匿名化是可取的，但匿名化算法仍然是一个研究问题。有几种已知，但它们提供的安全性及其其他特性尚未得到充分研究。此外，没有标准化的匿名方法。因此，支持匿名化的出口流程要求用“可能”而不是“必须”限定。
If anonymized flow data is exported, this must be clearly indicated to all receiving collecting processes, such that they can distinguish anonymized data from non-anonymized data.
如果导出匿名流数据，则必须向所有接收收集过程明确指出，以便它们能够区分匿名数据和非匿名数据。
If configuration is done remotely, security should be provided for the configuration process covering confidentiality, integrity, and authenticity. The means used for remote configuration are out of the scope of this document.
如果远程进行配置，则应为配置过程提供安全性，包括机密性、完整性和真实性。用于远程配置的方法不在本文档的范围内。
The metering process must provide a way of configuring traffic measurement. The following parameters of the metering process should be configurable:
计量过程必须提供一种配置流量计量的方法。计量过程的以下参数应可配置：
1. specification of the observation point e.g., an interface or a list of interfaces to be monitored. 2. specifications of flows to be metered 3. flow timeouts
1. 观察点的规范，例如，要监测的接口或接口列表。2.待计量流量的规格3。流超时
The following parameters may be configurable:
以下参数可以配置：
4. sampling method and parameters, if feature is supported 5. overload behavior, if feature is supported
4. 采样方法和参数，如果支持功能5。重载行为（如果支持此功能）
The exporting process must provide a way of configuring the data export. The following parameters of the exporting process should be configurable:
导出过程必须提供配置数据导出的方法。导出过程的以下参数应是可配置的：
1. reporting data format Specifying the reporting data format must include a
1. 指定报告数据格式的报告数据格式必须包括
selection of attributes to be reported for each flow. 2. the collecting process(es) to which flows are reported 3. the reporting interval This requirement only applies if the exporting process supports reporting in regular intervals. 4. notifications to be sent to the collecting process(es) This requirement only applies if the exporting process supports notifications. 5. flow anonymization This requirement only applies if the exporting process supports flow anonymization.
为每个流选择要报告的属性。2.向其报告流的收集过程3。仅当导出流程支持定期报告时，此要求才适用于报告间隔。4.发送给收集流程的通知仅当导出流程支持通知时，此要求才适用。5.流匿名仅当导出过程支持流匿名时，此要求才适用。
IPFIX specifications should be open to future technologies. This includes extensibility of configuration of the metering process and the exporting process.
IPFIX规范应该对未来的技术开放。这包括计量过程和导出过程配置的可扩展性。
Openness is also required concerning the extensibility of the data model, as stated in section 6.2.
如第6.2节所述，数据模型的可扩展性也需要开放性。
Data collection from hundreds of different exporting processes must be supported. The collecting process must be able to distinguish several hundred exporting processes by their identifiers.
必须支持从数百个不同的导出过程收集数据。收集过程必须能够通过标识符区分数百个导出过程。
The exporting process may be able to export flow information to more than one collecting process. If an exporting process is able to export flow records to multiple collecting processes then it must be able to ensure that the flow records can be identified so that duplicates can be detected between different collecting processes and double counting problems can be avoided.
导出过程可以将流信息导出到多个收集过程。如果导出流程能够将流程记录导出到多个采集流程，则必须能够确保能够识别流程记录，以便在不同采集流程之间检测到重复项，并避免重复计数问题。
This document intends to avoid constraining the architecture of probes, routers, and other devices hosting observation points, metering processes, exporting processes, and/or collecting processes. It can be expected that typically observation point, metering process, and exporting process are co-located at a single device. However, the requirements defined in this document do not exclude devices that derive from this configuration. Figure 2 shows some examples.
本文档旨在避免限制探测器、路由器和承载观测点、计量过程、导出过程和/或收集过程的其他设备的体系结构。可以预期，通常观测点、计量过程和输出过程位于单个设备上。然而，本文件中定义的要求并不排除由此配置衍生的设备。图2显示了一些示例。
All examples are composed of one or more of the following elements: observation point (O), metering process (M), exporting process (E), and collecting process (C). The observation points shown in the figure are always the most fine-granular ones supported by the respective device.
所有示例都由以下一个或多个元素组成：观测点（O）、计量过程（M）、导出过程（E）和收集过程（C）。图中所示的观察点始终是由相应设备支持的最细粒度的观察点。
+---+ +-----+ +---------+ +---------+
| E-+-> | E--+-> | E----+-> <-+--E E--+->
| | | | | | | / \ | | | | |
| M | | M | | M M | | M M |
| | | | /|\ | | /|\ /|\ | | /|\ /|\ |
| O | | OOO | | OOO OOO | | OOO OOO |
+---+ +-----+ +---------+ +---------+
Probe Basic Complex Multiple
Router Router Exporting
Processes
+---+ +-----+ +---------+ +---------+
| E-+-> | E--+-> | E----+-> <-+--E E--+->
| | | | | | | / \ | | | | |
| M | | M | | M M | | M M |
| | | | /|\ | | /|\ /|\ | | /|\ /|\ |
| O | | OOO | | OOO OOO | | OOO OOO |
+---+ +-----+ +---------+ +---------+
Probe Basic Complex Multiple
Router Router Exporting
Processes
+---+ +---+ +---+
| E-+-> | E-+-> | E-+------------->---+
| | | | | | | | | +---+ +-+-----+
+-+-+ | M | | M | | E-+------->-+-C-M-E-+->
| | | | | | | | | | +---+ +-+-----+
+-+-+ +-+-+ | O | | M | | E-+->---+
| | | | +---+ | | | | | |
| M | +-+-+ | O | | M |
| | | | | | +---+ | | | +-----+
| O | | O | | O | ->-+-C-E-+->
+---+ +---+ +---+ +-----+
+---+ +---+ +---+
| E-+-> | E-+-> | E-+------------->---+
| | | | | | | | | +---+ +-+-----+
+-+-+ | M | | M | | E-+------->-+-C-M-E-+->
| | | | | | | | | | +---+ +-+-----+
+-+-+ +-+-+ | O | | M | | E-+->---+
| | | | +---+ | | | | | |
| M | +-+-+ | O | | M |
| | | | | | +---+ | | | +-----+
| O | | O | | O | ->-+-C-E-+->
+---+ +---+ +---+ +-----+
Protocol Remote Concentrator Proxy Converter Observation
协议远程集中器代理转换器观察
Figure 2: IPFIX-related Devices
图2:IPFIX相关设备
A very simple device is a probe. A typical probe contains a single observation point, a single metering process, and a single exporting process.
一个非常简单的装置是探针。典型的探头包含一个观察点、一个计量过程和一个导出过程。
A basic router extends this structure by multiple observation points. Here, the observation point of a particular flow may be one of the displayed most fine-granular observation points, but also it may be a set of them.
基本路由器通过多个观察点扩展此结构。此处，特定流量的观测点可能是显示的最细粒度观测点之一，但也可能是一组观测点。
A more complex router may host more than one metering process, for example one per line card. Please note that here, the observation point of a single flow cannot exceed the set of most fine-granular observation points linked to a single metering process, because only the metering process can merge packets observed at different fine-
更复杂的路由器可以承载一个以上的计量过程，例如，每个线路卡一个。请注意，在这里，单个流的观察点不能超过链接到单个计量过程的最细粒度观察点集，因为只有计量过程可以合并在不同细粒度上观察到的数据包-
granular observation points to a joint flow. An observation point containing all most fine-granular observation points of this router is not possible with this structure. Alternatively, a complex router may host different exporting processes for flow records generated by different metering processes.
颗粒观察点指向节理流。在这种结构下，包含此路由器所有最细粒度观察点的观察点是不可能的。或者，复杂路由器可以为不同计量过程生成的流量记录承载不同的导出过程。
A protocol converter makes use of a metering process that can be accessed only by protocol(s) other than the one defined for IPFIX, for example, the SNMP and the Meter MIB module [RFC2720]. Then the exporting process receives flow records from a remote metering process and exports these records using the IPFIX protocol. Please note that this document does not make any particular assumption on how metering processes and export processes exchange information, as long as all individual requirements for these processes are met. Also the locations of metering processes are not of any relevance for this document (in contrast to the locations of observation points and the exporting processes).
协议转换器使用计量过程，该计量过程只能由为IPFIX定义的协议以外的协议访问，例如SNMP和计量MIB模块[RFC2720]。然后，导出进程从远程计量进程接收流记录，并使用IPFIX协议导出这些记录。请注意，只要满足计量流程和导出流程的所有单独要求，本文件不会对计量流程和导出流程如何交换信息做出任何特定假设。此外，计量过程的位置与本文件无关（与观测点和导出过程的位置相反）。
In the example of remote packet observation in Figure 2 the metering process and the observation point are not co-located. Packet headers captured at an observation point may be exported as raw data to a device hosting metering process and exporting process. Again, this document does not make any particular assumption on how packet headers are transferred from observation points to metering processes, as long as all requirements for the metering processes are met.
在图2中的远程数据包观察示例中，计量过程和观察点并非位于同一位置。在观测点捕获的包头可以作为原始数据导出到承载计量过程和导出过程的设备。同样，只要满足计量过程的所有要求，本文件不会对如何将数据包头从观测点传输到计量过程做出任何特定假设。
An intermediate structure between protocol converter and remote observation (not shown in the Figure) would be a split metering process, for example performing timestamping and sampling at the device hosting the observation point and performing packet classification at another device hosting the exporting process.
协议转换器和远程观测（图中未显示）之间的中间结构将是分离计量过程，例如，在承载观测点的设备上执行时间戳和采样，并在承载导出过程的另一个设备上执行分组分类。
A concentrator receives flow records via the IPFIX protocol, merges them into more aggregated flow records, and exports them again using the IPFIX protocol. Please note that for the final flow records the resulting observation point may be a superset of the more fine-granular observation points at the first level devices. The metering process of the final flow records is composed by the (partial) metering processes at the first level devices and the partial metering process at the concentrator.
集中器通过IPFIX协议接收流记录，将它们合并到更多聚合流记录中，然后使用IPFIX协议再次导出它们。请注意，对于最终流量记录，产生的观测点可能是一级设备上更细粒度观测点的超集。最终流量记录的计量过程由一级装置的（部分）计量过程和选矿厂的部分计量过程组成。
Finally, a very simple IPFIX-related device is a proxy. It just receives flow records using the IPFIX protocol and sends them further using the same protocol. A proxy might be useful for traversing firewalls or other gateways.
最后，一个非常简单的IPFIX相关设备是代理。它只是使用IPFIX协议接收流记录，并使用相同的协议进一步发送它们。代理对于穿越防火墙或其他网关可能很有用。
An IPFIX protocol must be capable of transporting data over the public Internet. Therefore it cannot be excluded that an attacker captures or modifies packets or inserts additional packets.
IPFIX协议必须能够通过公共互联网传输数据。因此，不能排除攻击者捕获或修改数据包或插入其他数据包。
This section describes security requirements for IPFIX. Like other requirements, the security requirements differ among the considered applications. The incentive to modify collected data for accounting or intrusion detection for instance is usually higher than the incentive to change data collected for traffic profiling. A detailed list of the required security features per application can be found in the appendix.
本节介绍IPFIX的安全要求。与其他要求一样，所考虑的应用程序的安全要求也不同。例如，修改收集的数据用于记帐或入侵检测的动机通常高于更改收集的数据用于流量分析的动机。每个应用程序所需安全功能的详细列表见附录。
The suggestion of concrete solutions for achieving the required security properties should be part of an IPFIX architecture and protocol. It is out of scope of this document. Also methods for remote configuration of the metering processes and exporting processes are out of scope. Therefore, threats that are caused by data exchange for remote configuration are not considered here.
关于实现所需安全属性的具体解决方案的建议应该是IPFIX体系结构和协议的一部分。这超出了本文件的范围。此外，用于远程配置计量进程和导出进程的方法也超出了范围。因此，此处不考虑远程配置的数据交换造成的威胁。
The following potential security hazards for an IPFIX protocol have been identified: disclosure of IP flow information, forgery of flow records, and Denial of Service (DoS) attacks.
已确定IPFIX协议的以下潜在安全危害：泄露IP流信息、伪造流记录和拒绝服务（DoS）攻击。
The content of data exchanged by an IPFIX protocol (for example IPFIX flow records) should be kept confidential between the involved parties (exporting process and collecting process). Observation of IPFIX flow records gives an attacker information about the active flows in the network, communication endpoints and traffic patterns. This information cannot only be used to spy on user behavior but also to plan and conceal future attacks. Therefore, the requirements specified in section 6.3.3. include confidentiality of the transferred data. This can be achieved for instance by encryption.
IPFIX协议交换的数据内容（例如IPFIX流记录）应在相关方（导出过程和收集过程）之间保密。观察IPFIX流记录可向攻击者提供有关网络中活动流、通信端点和流量模式的信息。这些信息不仅可用于监视用户行为，还可用于计划和隐藏未来的攻击。因此，应满足第6.3.3节中规定的要求。包括传输数据的保密性。这可以通过加密来实现。
Also the privacy of users acting as sender or receiver of the measured traffic needs to be protected when they use the Internet. In many countries the right to store user-specific data (including the user's traffic profiles) is restricted by law or by regulations.
此外，当用户使用互联网时，作为测量流量的发送者或接收者的用户的隐私也需要得到保护。在许多国家，存储用户特定数据（包括用户的流量配置文件）的权利受到法律或法规的限制。
In addition to encryption, this kind of privacy can also be protected by anonymizing flow records. For many traffic flow measurements, anonymized data is as useful as precise data. Therefore, it is desirable to support anonymization in IPFIX implementations. It is beyond the scope of the IPFIX Working Group to develop and
除了加密之外，这种隐私还可以通过匿名流记录来保护。对于许多交通流测量，匿名数据与精确数据一样有用。因此，希望在IPFIX实现中支持匿名化。IPFIX工作组的范围不包括开发和
standardize anonymization methods. However, the requirements for extensibility of the IPFIX protocol are sufficient to support anonymized flow records when appropriate methods are standardized.
标准化匿名化方法。然而，当适当的方法标准化时，IPFIX协议的可扩展性要求足以支持匿名流记录。
If flow records are used in accounting and/or security applications, there are potentially strong incentives to forge exported IPFIX flow records (for example, to save money or prevent the detection of an attack). This can be done either by altering flow records on the path or by injecting forged flow records that pretend to be originated by the original exporting process.
如果在会计和/或安全应用程序中使用流记录，则可能存在伪造导出的IPFIX流记录的强烈动机（例如，为了省钱或防止检测到攻击）。这可以通过改变路径上的流记录或注入伪造的流记录来实现，伪造的流记录假装是由原始导出过程生成的。
Special caution is required if security applications rely on flow measurements. With forged flow records it is possible to trick security applications. For example, an application may be lead to falsely conclude that a DoS attack is in progress. If such an injection of IPFIX traffic flow records fools the security application, causing it to erroneously conclude that a DoS attack is underway, then the countermeasures employed by the security application may actually deny useful non-malicious services.
如果安全应用依赖于流量测量，则需要特别小心。使用伪造的流记录，可以欺骗安全应用程序。例如，应用程序可能会错误地得出DoS攻击正在进行的结论。如果这种IPFIX流量记录的注入欺骗了安全应用程序，导致其错误地得出DoS攻击正在进行的结论，那么安全应用程序所采用的对策实际上可能会拒绝有用的非恶意服务。
In order to make an IPFIX protocol resistant against such attacks, authentication and integrity must be provided, as specified in section 6.3.3.
为了使IPFIX协议抵抗此类攻击，必须按照第6.3.3节的规定提供身份验证和完整性。
DoS attacks on routers or other middleboxes that have the IPFIX protocol implemented would also affect the IPFIX protocol and impair the sending of IPFIX records. Nevertheless, since such hazards are not induced specifically by the IPFIX protocol the prevention of such attacks is out of scope of this document.
对已实施IPFIX协议的路由器或其他中间盒的DoS攻击也会影响IPFIX协议并损害IPFIX记录的发送。尽管如此，由于IPFIX协议并未具体引发此类危害，因此此类攻击的预防不在本文件的范围之内。
However, IPFIX itself also causes potential hazards for DoS attacks. All processes that expect the reception of traffic can be target of a DoS attack. With the exporting process this is only the case if it supports the pull mode (which can be an optional feature of the IPFIX protocol according to this document). The collecting process always expects data and therefore can be flooded by flow records.
但是，IPFIX本身也会导致DoS攻击的潜在危险。所有期望接收流量的进程都可能成为DoS攻击的目标。在导出过程中，只有支持拉模式（根据本文档，拉模式可以是IPFIX协议的可选功能）时才会出现这种情况。收集过程总是需要数据，因此可能会被流记录淹没。
Many thanks to Georg Carle for contributing to the application analysis, to K.C. Norseth for several fine-tunings, to Sandra Tartarelli for checking the appendix, and to a lot of people on the mailing list for providing valuable comments and suggestions including Nevil Brownlee, Carter Bullard, Paul Calato, Ram Gopal, Tal Givoly, Jeff Meyer, Reinaldo Penno, Sonia Panchen, Simon Leinen, David Plonka, Ganesh Sadasivan, Kevin Zhang, and many more.
非常感谢Georg Carle为应用程序分析做出的贡献，感谢K.C.Norseth进行了几次微调，感谢Sandra Tartarelli检查了附录，感谢邮件列表上的许多人提供了宝贵的意见和建议，包括Nevil Brownlee、Carter Bullard、Paul Calato、Ram Gopal、Tal Givoly、Jeff Meyer，雷纳尔多·佩诺、索尼娅·班禅、西蒙·莱宁、大卫·普隆卡、加内什·萨达西万、凯文·张等等。
The following table documents, how the requirements stated in sections 3-7 are derived from requirements of the applications listed in section 2.
下表说明了第3-7节中所述的要求是如何从第2节中所列的应用要求中派生出来的。
Used abbreviations: M = must S = should O = may (optional) - = DONT CARE
使用的缩写词：M=必须S=应该O=可以（可选）-=不在乎
-----------------------------------------------------------------------.
IPFIX |
----------------------------------------------------------------. |
E: QoS Monitoring | |
----------------------------------------------------------. | |
D: Attack/Intrusion Detection | | |
----------------------------------------------------. | | |
C: Traffic Engineering | | | |
----------------------------------------------. | | | |
B: Traffic Profiling | | | | |
----------------------------------------. | | | | |
A: Usage-based Accounting | | | | | |
----------------------------------. | | | | | |
| | | | | | |
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4. | DISTINGUISHING FLOWS |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4. | Combination of | M | M | M | M | M | M |
| | required attributes | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.1. | in/out IF | S | M | M | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | src/dst address | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | Masking of IP addresses | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | transport protocol | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | version field | - | S | S | O | O | S |
| | | | | (b) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
-----------------------------------------------------------------------.
IPFIX |
----------------------------------------------------------------. |
E: QoS Monitoring | |
----------------------------------------------------------. | |
D: Attack/Intrusion Detection | | |
----------------------------------------------------. | | |
C: Traffic Engineering | | | |
----------------------------------------------. | | | |
B: Traffic Profiling | | | | |
----------------------------------------. | | | | |
A: Usage-based Accounting | | | | | |
----------------------------------. | | | | | |
| | | | | | |
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4. | DISTINGUISHING FLOWS |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4. | Combination of | M | M | M | M | M | M |
| | required attributes | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.1. | in/out IF | S | M | M | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | src/dst address | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | Masking of IP addresses | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | transport protocol | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | version field | - | S | S | O | O | S |
| | | | | (b) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.3. | src/dst port | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.4. | MPLS label (a) | S | S | M | O | S | M |
| | | | | (c) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.5. | DSCP (a) | M | S | M | O | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5. | METERING PROCESS |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.1. | Reliability | M | S | S | S | S | |
|-------+-------------------------+-----+-----+-----+-----+-----+ M |
| 5.1. | Indication of | - | M | M | M | M | |
| | missing reliability | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.2. | Sampling (d,e) | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.3. | Overload Behavior (f) | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.4. | Timestamps | M | O | O | S | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.5. | Time synchronization | M | S | S | S | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.6. | Flow timeout | M | S | - | O | O | M |
| | | (g) | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.7. | Multicast flows | S | O | O | O | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.8. | Packet fragmentation | O | O | - | - | - | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.9. | Ignore port copy | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6. | DATA EXPORT |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | INFORMATION MODEL |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | IP Version | - | M | M | O | O | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | src/dst address | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | transport protocol | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | src/dst port | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Packet counter (h) | S | M | M | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.3. | src/dst port | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.4. | MPLS label (a) | S | S | M | O | S | M |
| | | | | (c) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.5. | DSCP (a) | M | S | M | O | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5. | METERING PROCESS |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.1. | Reliability | M | S | S | S | S | |
|-------+-------------------------+-----+-----+-----+-----+-----+ M |
| 5.1. | Indication of | - | M | M | M | M | |
| | missing reliability | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.2. | Sampling (d,e) | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.3. | Overload Behavior (f) | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.4. | Timestamps | M | O | O | S | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.5. | Time synchronization | M | S | S | S | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.6. | Flow timeout | M | S | - | O | O | M |
| | | (g) | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.7. | Multicast flows | S | O | O | O | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.8. | Packet fragmentation | O | O | - | - | - | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.9. | Ignore port copy | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6. | DATA EXPORT |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | INFORMATION MODEL |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | IP Version | - | M | M | O | O | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | src/dst address | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | transport protocol | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | src/dst port | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Packet counter (h) | S | M | M | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Byte counter | M | M | M | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | ToS (IPv4) or traffic | M | S | M | O | M | M |
| | class octet (IPv6) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Flow Label (IPv6) | M | S | M | O | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | MPLS label (a) | S | S | M | O | S | M |
| | | | | (c) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Timestamps for | M | O | O | S | S | M |
| | first/last packet | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Sampling configuration | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | observation point | M | M | M | M | M | M |
| | identifier | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | export process | M | M | M | M | M | M |
| | identifier | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | ICMP type and code (i) | S | S | - | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | input/output interface | S | S | S | S | S | S |
| | (j) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Multicast | O | S | S | - | S | S |
| | replication factor | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | TTL | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | IP header flags | - | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | TCP header flags | - | O | O | O | - | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Dropped Packet | O | O | O | O | O | O |
| | Counter (h,k) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Fragment counter | - | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | next hop IP address | O | O | O | O | - | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | src / dst / next hop | - | O | O | - | - | O |
| | BGP AS # | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Byte counter | M | M | M | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | ToS (IPv4) or traffic | M | S | M | O | M | M |
| | class octet (IPv6) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Flow Label (IPv6) | M | S | M | O | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | MPLS label (a) | S | S | M | O | S | M |
| | | | | (c) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Timestamps for | M | O | O | S | S | M |
| | first/last packet | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Sampling configuration | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | observation point | M | M | M | M | M | M |
| | identifier | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | export process | M | M | M | M | M | M |
| | identifier | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | ICMP type and code (i) | S | S | - | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | input/output interface | S | S | S | S | S | S |
| | (j) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Multicast | O | S | S | - | S | S |
| | replication factor | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | TTL | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | IP header flags | - | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | TCP header flags | - | O | O | O | - | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Dropped Packet | O | O | O | O | O | O |
| | Counter (h,k) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Fragment counter | - | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | next hop IP address | O | O | O | O | - | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | src / dst / next hop | - | O | O | - | - | O |
| | BGP AS # | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.2. | DATA MODEL |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.2. | Flexibility | M | S | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.2. | Extensibility | M | S | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3. | DATA TRANSFER |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.1.| Congestion aware | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.2.| Reliability | M | S | S | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.3.| Confidentiality | M | S | S | M | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.4.| Integrity | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.5.| Authenticity | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4. | REPORTING TIMES |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4. | Push mode | M | O | O | M | S | M |
| | | | (l) | (l) | |(l,m)| |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4. | Pull mode | O | O | O | O | O | O |
| | | | (l) | (l) | | (l) | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4.1.| Regular interval | S | S | S | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.6. | Notifications | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.7. | Anonymization (n) | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7. | CONFIGURATION |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7. | Secure remote | S | S | S | S | S | S |
| | configuration (a) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config observation point| S | S | S | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config flow | S | S | S | S | S | S |
| | specifications | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config flow timeouts | S | S | S | S | O | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.2. | DATA MODEL |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.2. | Flexibility | M | S | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.2. | Extensibility | M | S | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3. | DATA TRANSFER |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.1.| Congestion aware | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.2.| Reliability | M | S | S | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.3.| Confidentiality | M | S | S | M | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.4.| Integrity | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.5.| Authenticity | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4. | REPORTING TIMES |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4. | Push mode | M | O | O | M | S | M |
| | | | (l) | (l) | |(l,m)| |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4. | Pull mode | O | O | O | O | O | O |
| | | | (l) | (l) | | (l) | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4.1.| Regular interval | S | S | S | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.6. | Notifications | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.7. | Anonymization (n) | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7. | CONFIGURATION |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7. | Secure remote | S | S | S | S | S | S |
| | configuration (a) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config observation point| S | S | S | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config flow | S | S | S | S | S | S |
| | specifications | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config flow timeouts | S | S | S | S | O | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config sampling | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config overload | O | O | O | O | O | O |
| | behavior (a) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.2. | Config report | S | S | S | S | S | S |
| | data format | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.2. | Config | S | S | S | S | S | S |
| | notifications | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8. | GENERAL REQUIREMENTS |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8.1. | Openness | S | S | S | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8.2. | Scalability: | | | | | | |
| | data collection | M | S | M | O | S | M |
| | from hundreds of | | | | | | |
| | measurement devices | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8.3. | Several collectors | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config sampling | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config overload | O | O | O | O | O | O |
| | behavior (a) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.2. | Config report | S | S | S | S | S | S |
| | data format | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.2. | Config | S | S | S | S | S | S |
| | notifications | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8. | GENERAL REQUIREMENTS |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8.1. | Openness | S | S | S | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8.2. | Scalability: | | | | | | |
| | data collection | M | S | M | O | S | M |
| | from hundreds of | | | | | | |
| | measurement devices | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8.3. | Several collectors | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
Remarks:
评论：
(a) If feature is supported. (b) The differentiation of IPv4 and IPv6 is for TE of importance. So we tended to make this a must. Nevertheless, a should seems to be sufficient to perform most TE tasks and allows us to have a should for IPFIX instead of a must. (c) For TE in an MPLS network the label is essential. Therefore a must is given here leading to a must in IPFIX. (d) If sampling is supported, the methods and parameters must be well defined. (e) If sampling is supported, sampling configuration changes must be indicated to all collecting processes. (f) If overload behavior is supported and it induces changes in the metering process behavior, the overload behavior must be clearly defined. (g) Precise time-based accounting requires reaction to a flow timeout. (h) If a packet is fragmented, each fragment is counted as an individual packet. (i) If protocol type is ICMP.
(a) 如果功能受支持。（b） IPv4和IPv6的区别对于TE非常重要。因此，我们倾向于将此视为必须。尽管如此，should似乎足以执行大多数TE任务，并允许我们为IPFIX设置should，而不是必选项。（c） 对于MPLS网络中的TE，标签是必不可少的。因此，这里给出了一个必须，这导致了IPFIX中的一个必须。（d） 如果支持采样，则必须明确定义方法和参数。（e） 如果支持采样，则必须向所有采集过程指示采样配置更改。（f） 如果支持过载行为并导致计量过程行为发生变化，则必须明确定义过载行为。（g） 精确的基于时间的记帐需要对流超时作出反应。（h） 如果一个数据包是碎片化的，则每个碎片都被计算为一个单独的数据包。（i） 如果协议类型为ICMP。
(j) This requirement does not apply if the observation point is located at a probe device. (k) Only if measurement is done on data path i.e., has access to forwarding decision. (l) Either push or pull has to be supported. (m) Required, in order to immediately report drop indications for SLA validation. (n) Anonymization must be clearly indicated to all receiving collecting processes.
(j) 如果观察点位于探头装置上，则此要求不适用。（k） 仅当测量是在数据路径上进行的，即有权访问转发决策。（l） 必须支撑推或拉。（m） 需要，以便立即报告SLA验证的下降指示。（n） 必须向所有接收收集流程明确说明匿名化。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 32342002年2月。
[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月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
[RFC2975]Aboba，B.，Arkko，J.，和D.Harrington，“会计管理导论”，RFC 29752000年10月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418]Presohn，R.，“简单网络管理协议（SNMP）的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月。
[RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.
[RFC2720]布朗利，N.，“交通流量测量：仪表MIB”，RFC27201999年10月。
Juergen Quittek NEC Europe Ltd., Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany
Juergen Quittek NEC欧洲有限公司，网络实验室Kurfuersten Anlage 36 69115德国海德堡
Phone: +49 6221 90511 15
EMail: quittek@netlab.nec.de
Phone: +49 6221 90511 15
EMail: quittek@netlab.nec.de
Tanja Zseby Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin Germany
Tanja Zseby Fraunhofer开放通信系统研究所（FOKUS）Kaiserin Augusta Allee 31 10589德国柏林
Phone: +49 30 3463 7153
EMail: zseby@fokus.fhg.de
Phone: +49 30 3463 7153
EMail: zseby@fokus.fhg.de
Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium
Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem比利时
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Sebastian Zander Centre for Advanced Internet Architectures, Mail H31 Swinburne University of Technology PO Box 218 John Street, Hawthorn Victoria 3122, Australia
Sebastian Zander高级互联网架构中心，邮件H31斯文本科技大学邮政信箱218约翰街，山楂维多利亚3122，澳大利亚
Phone: +61 3 9214 8089
EMail: szander@swin.edu.au
Phone: +61 3 9214 8089
EMail: szander@swin.edu.au
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。