Network Working Group T. Zseby
Request for Comments: 5472 Fraunhofer FOKUS
Category: Informational E. Boschi
Hitachi Europe
N. Brownlee
CAIDA
B. Claise
Cisco Systems, Inc.
March 2009
Network Working Group T. Zseby
Request for Comments: 5472 Fraunhofer FOKUS
Category: Informational E. Boschi
Hitachi Europe
N. Brownlee
CAIDA
B. Claise
Cisco Systems, Inc.
March 2009
IP Flow Information Export (IPFIX) Applicability
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
In this document, we describe the applicability of the IP Flow Information eXport (IPFIX) protocol for a variety of applications. We show how applications can use IPFIX, describe the relevant Information Elements (IEs) for those applications, and present opportunities and limitations of the protocol. Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks.
在本文档中，我们描述了IP流信息导出（IPFIX）协议在各种应用中的适用性。我们将展示应用程序如何使用IPFIX，描述这些应用程序的相关信息元素，并介绍协议的机会和局限性。此外，我们还描述了IPFIX框架与其他体系结构和框架的关系。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. Applications of IPFIX ...........................................4
2.1. Accounting .................................................4
2.1.1. Example .............................................5
2.2. Traffic Profiling ..........................................7
2.3. Traffic Engineering ........................................8
2.4. Network Security ...........................................9
2.5. QoS Monitoring ............................................11
2.5.1. Correlating Events from Multiple
Observation Points .................................12
2.5.2. Examples ...........................................12
2.6. Inter-Domain Exchange of IPFIX Data .......................14
2.7. Export of Derived Metrics .................................14
2.8. Summary ...................................................15
3. Relation of IPFIX to Other Frameworks and Protocols ............16
3.1. IPFIX and IPv6 ............................................16
3.2. IPFIX and PSAMP ...........................................16
3.3. IPFIX and RMON ............................................16
3.4. IPFIX and IPPM ............................................18
3.5. IPFIX and AAA .............................................18
3.5.1. Connecting via a AAA Client ........................20
3.5.2. Connecting via an Application Specific
Module (ASM) .......................................21
3.6. IPFIX and RTFM ............................................21
3.6.1. Architecture .......................................21
3.6.2. Flow Definition ....................................22
3.6.3. Configuration and Management .......................22
3.6.4. Data Collection ....................................22
3.6.5. Data Model Details .................................23
3.6.6. Transport Protocol .................................23
3.6.7. Summary ............................................23
4. Limitations ....................................................24
4.1. Using IPFIX for Other Applications than Listed in
RFC 3917 ..................................................24
4.2. Using IPFIX for Billing (Reliability Limitations) .........24
4.3. Using a Different Transport Protocol than SCTP ............25
4.4. Push vs. Pull Mode ........................................25
4.5. Template ID Number ........................................26
4.6. Exporting Bidirectional Flow Information ..................26
4.7. Remote Configuration ......................................27
5. Security Considerations ........................................27
6. Acknowledgements ...............................................28
7. Normative References ...........................................28
8. Informative References .........................................28
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. Applications of IPFIX ...........................................4
2.1. Accounting .................................................4
2.1.1. Example .............................................5
2.2. Traffic Profiling ..........................................7
2.3. Traffic Engineering ........................................8
2.4. Network Security ...........................................9
2.5. QoS Monitoring ............................................11
2.5.1. Correlating Events from Multiple
Observation Points .................................12
2.5.2. Examples ...........................................12
2.6. Inter-Domain Exchange of IPFIX Data .......................14
2.7. Export of Derived Metrics .................................14
2.8. Summary ...................................................15
3. Relation of IPFIX to Other Frameworks and Protocols ............16
3.1. IPFIX and IPv6 ............................................16
3.2. IPFIX and PSAMP ...........................................16
3.3. IPFIX and RMON ............................................16
3.4. IPFIX and IPPM ............................................18
3.5. IPFIX and AAA .............................................18
3.5.1. Connecting via a AAA Client ........................20
3.5.2. Connecting via an Application Specific
Module (ASM) .......................................21
3.6. IPFIX and RTFM ............................................21
3.6.1. Architecture .......................................21
3.6.2. Flow Definition ....................................22
3.6.3. Configuration and Management .......................22
3.6.4. Data Collection ....................................22
3.6.5. Data Model Details .................................23
3.6.6. Transport Protocol .................................23
3.6.7. Summary ............................................23
4. Limitations ....................................................24
4.1. Using IPFIX for Other Applications than Listed in
RFC 3917 ..................................................24
4.2. Using IPFIX for Billing (Reliability Limitations) .........24
4.3. Using a Different Transport Protocol than SCTP ............25
4.4. Push vs. Pull Mode ........................................25
4.5. Template ID Number ........................................26
4.6. Exporting Bidirectional Flow Information ..................26
4.7. Remote Configuration ......................................27
5. Security Considerations ........................................27
6. Acknowledgements ...............................................28
7. Normative References ...........................................28
8. Informative References .........................................28
The IPFIX protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. IP Flow information provides important input data for a variety of applications. The IPFIX protocol is a general data transport protocol that is easily extensible to suit the needs of such applications. In this document, we describe how typical applications can use the IPFIX protocol and show opportunities and limitations of the protocol. Furthermore, we describe the relationship of IPFIX to other frameworks and architectures. Although examples in this document are shown for IPv4 only, the applicability statements apply to IPv4 and IPv6. IPFIX provides appropriate Information Elements for both IP versions.
IPFIX协议定义了如何从路由器、测量探针或其他设备导出IP流信息。IP流信息为各种应用程序提供了重要的输入数据。IPFIX协议是一种通用数据传输协议，易于扩展以满足此类应用的需要。在本文档中，我们将介绍典型应用程序如何使用IPFIX协议，并展示该协议的机会和局限性。此外，我们还描述了IPFIX与其他框架和体系结构的关系。尽管本文档中的示例仅针对IPv4，但适用性声明适用于IPv4和IPv6。IPFIX为两个IP版本提供适当的信息元素。
IPFIX-specific terminology used in this document is defined in Section 2 of [RFC5101]. In this document, as in [RFC5101], the first letter of each IPFIX-specific term is capitalized.
[RFC5101]第2节定义了本文件中使用的IPFIX专用术语。在本文件中，与[RFC5101]中一样，每个IPFIX特定术语的首字母大写。
IPFIX data enables several critical applications. The IPFIX target applications and the requirements that originate from those applications are described in [RFC3917]. Those requirements were used as basis for the design of the IPFIX protocol. This section describes how these target applications can use the IPFIX protocol. Considerations for using IPFIX for other applications than those described in [RFC3917] can be found in Section 4.1.
IPFIX数据支持多个关键应用程序。[RFC3917]中描述了IPFIX目标应用程序以及源自这些应用程序的要求。这些要求被用作IPFIX协议设计的基础。本节介绍这些目标应用程序如何使用IPFIX协议。对于[RFC3917]中所述应用以外的其他应用，使用IPFIX的注意事项见第4.1节。
Usage-based accounting is one of the target applications for IPFIX as defined in [RFC3917]. IPFIX records provide fine-grained measurement results for highly flexible and detailed usage reporting. Such data is used to realize usage-based accounting. Nevertheless, IPFIX does not provide the reliability required by usage-based billing systems as defined in [RFC2975] (see Section 4.2). The accounting scenarios described in this document only provide limited reliability as explained in Section 4.2 and should not be used in environments where reliability as demanded by [RFC2975] is mandatory.
基于使用的计费是[RFC3917]中定义的IPFIX的目标应用程序之一。IPFIX记录为高度灵活和详细的使用情况报告提供了细粒度的测量结果。这些数据用于实现基于使用的会计。然而，IPFIX不提供[RFC2975]中定义的基于使用的计费系统所需的可靠性（见第4.2节）。如第4.2节所述，本文件中描述的会计场景仅提供有限的可靠性，不应在[RFC2975]要求的可靠性为强制性的环境中使用。
In order to realize usage-based accounting with IPFIX, the Flow definition has to be chosen in accordance to the accounting purpose, such as trend analysis, capacity planning, auditing, or billing and cost allocation where some loss of data can be tolerated (see Section 4.2).
为了使用IPFIX实现基于使用情况的会计，必须根据会计目的选择流量定义，如趋势分析、容量规划、审计或计费和成本分配，其中可以容忍一些数据丢失（见第4.2节）。
Flows can be distinguished by various IEs (e.g., packet header fields) from [RFC5102]. Due to the flexible IPFIX Flow definition, arbitrary Flow-based accounting models can be realized without extensions to the IPFIX protocol.
可以通过[RFC5102]中的各种IE（例如，数据包头字段）来区分流。由于灵活的IPFIX流定义，可以实现任意基于流的记帐模型，而无需扩展IPFIX协议。
Accounting can, for instance, be based on individual end-to-end Flows. In this case, it can be realized with a Flow definition determined by the quintuple consisting of source address (sourceIPv4Address), destination address (destinationIPv4Address), protocol (protocolIdentifier), and port numbers (udpSourcePort, udpDestinationPort). Another example is class-dependent accounting (e.g., in a Diffserv network). In this case, Flows could be distinguished just by the Diffserv codepoint (DSCP) (ipDiffServCodePoint) and IP addresses (sourceIPv4Address, destinationIPv4Address). The essential elements needed for accounting are the number of transferred packets and bytes per Flow, which can be represented by the per-flow counter IEs (e.g., packetTotalCount, octetTotalCount).
例如，会计可以基于单个端到端流程。在这种情况下，可以使用由源地址（sourceIPv4Address）、目标地址（destinationip4address）、协议（protocolIdentifier）和端口号（udpSourcePort、udpdestationport）组成的五元组确定的流定义来实现。另一个例子是依赖于类的记帐（例如，在区分服务网络中）。在这种情况下，可以仅通过Diffserv代码点（DSCP）（ipDiffServCodePoint）和IP地址（sourceIPv4Address，destinationip4address）来区分流。记帐所需的基本元素是每个流传输的数据包数和字节数，这些数据包数和字节数可由每个流计数器IEs表示（例如，packetTotalCount、OctettTotalCount）。
For accounting purposes, it would be advantageous to have the ability to use IPFIX Flow Records as accounting input in an Authentication, Authorization, and Accounting (AAA) infrastructure. AAA servers then could provide the mapping between user and Flow information. Again for such scenarios the limited reliability currently provided by IPFIX has to be taken into account.
出于记帐目的，能够在身份验证、授权和记帐（AAA）基础结构中使用IPFIX流记录作为记帐输入是有利的。AAA服务器可以提供用户和流信息之间的映射。同样，对于这种情况，必须考虑IPFIX目前提供的有限可靠性。
Please note: As noted in [RFC3330], the address block 192.0.2.0/24 may be used for example addresses. In the example below, we use two example networks. In order to be conformant to [RFC3330], we divide the given address block into two networks by subnetting with a 25-bit netmask (192.0.2.0/25) as follows:
请注意：如[RFC3330]中所述，地址块192.0.2.0/24可用作示例地址。在下面的示例中，我们使用两个示例网络。为了符合[RFC3330]，我们使用25位网络掩码（192.0.2.0/25）将给定地址块分为两个网络，如下所示：
Network A: 192.0.2.0 ... 192.0.2.127 Network B: 192.0.2.128 ... 192.0.2.255
网络A:192.0.2.0。。。192.0.2.127网络B:192.0.2.128。。。192.0.2.255
Let's suppose someone needs to monitor the individual Flows in a Diffserv network in order to compare traffic amount trend with the terms outlined in a Service Level Agreement (SLA). Flows are distinguished by source and destination address. The information to export in this case is:
假设有人需要监控Diffserv网络中的各个流，以便将流量趋势与服务水平协议（SLA）中概述的术语进行比较。流由源地址和目标地址区分。在这种情况下，要导出的信息是：
- IPv4 source IP address: sourceIPv4Address in [RFC5102], with a length of 4 octets
- IPv4源IP地址：[RFC5102]中的sourceIPv4Address，长度为4个八位字节
- IPv4 destination IP address: destinationIPv4Address in [RFC5102], with a length of 4 octets
- IPv4目标IP地址：[RFC5102]中的destinationIPv4Address，长度为4个八位字节
- DSCP: ipDiffServCodePoint in [RFC5102], with a length of 1 octet
- DSCP:ipDiffServCodePoint位于[RFC5102]中，长度为1个八位组
- Number of octets of the Flow: octetDeltaCount in [RFC5102], with a length of 4 octets
- 流的八位字节数：[RFC5102]中的八位字节DeltaCount，长度为4个八位字节
The Template set will look as follows:
模板集的外观如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 24 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipDiffServCodePoint = 195 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 24 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipDiffServCodePoint = 195 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The information to be exported might be as listed in the following example table:
要导出的信息可能如下例表所示：
Src. IP addr. | Dst. IP addr. | DSCP | Octets Number
--------------+---------------+--------+--------------
192.0.2.12 | 192.0.2.144 | 46 | 120868
192.0.2.24 | 192.0.2.156 | 46 | 310364
192.0.2.36 | 192.0.2.168 | 46 | 241239
Src. IP addr. | Dst. IP addr. | DSCP | Octets Number
--------------+---------------+--------+--------------
192.0.2.12 | 192.0.2.144 | 46 | 120868
192.0.2.24 | 192.0.2.156 | 46 | 310364
192.0.2.36 | 192.0.2.168 | 46 | 241239
In the example we use Diffserv codepoint 46, recommended for the Expedited Forwarding Per Hop Behavior (EF PHB) in [RFC3246].
在本例中，我们使用Diffserv代码点46，推荐用于[RFC3246]中的每跳加速转发行为（EF PHB）。
The Flow Records will then look as follows:
然后，流记录将如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 43 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.144 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 46 | 120868 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.156 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 46 | 310364 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.168 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 46 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 241239 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 43 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.144 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 46 | 120868 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.156 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 46 | 310364 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.168 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 46 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 241239 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Measurement results reported in IPFIX records can provide useful input for traffic profiling. IPFIX records captured over a long period of time can be used to track and anticipate network growth and usage. Such information is valuable for trend analysis and network planning.
IPFIX记录中报告的测量结果可以为流量分析提供有用的输入。长时间捕获的IPFIX记录可用于跟踪和预测网络增长和使用情况。这些信息对于趋势分析和网络规划很有价值。
The parameters of interest are determined by the profiling objectives. Example parameters for traffic profiling are Flow duration, Flow volume, burstiness, the distribution of used services and protocols, the amount of packets of a specific type, etc. [RFC3917].
感兴趣的参数由分析目标确定。流量分析的示例参数包括流量持续时间、流量、突发性、使用的服务和协议的分布、特定类型的数据包数量等[RFC3917]。
The distribution of services and protocols in use can be analyzed by configuring appropriate Flows Keys for Flow discrimination. Protocols can be distinguished by the protocolIdentifier IE. Portnumbers (e.g., udpDestinationPort) often provide information about services in use. Those Flow Keys are defined in [RFC5102]. If
可以通过为流识别配置适当的流密钥来分析正在使用的服务和协议的分布。协议可以通过protocolIdentifier进行区分，即端口号（例如UDPDestationPort）通常提供有关正在使用的服务的信息。这些流键在[RFC5102]中定义。如果
portnumbers are not sufficient for service discrimination, further parts of the packet may be needed. Header fields can be expressed by IEs from [RFC5102].
端口号不足以区分服务，可能需要进一步的数据包部分。标题字段可以用[RFC5102]中的IEs表示。
Packet payload can be reported by using the IE ipPayloadPacketSection in [RFC5477].
可以使用[RFC5477]中的IE IPPayLoadPacket部分报告数据包有效负载。
The Flow duration can be calculated from the Flow Timestamp IEs defined in [RFC5102] (e.g., flowEndMicroseconds - flowStartMicroseconds). The number of packets and number of bytes of a Flow are represented in the per-flow counter IEs (e.g., packetTotalCount, octetTotalCount). The burstiness of a Flow can be calculated from the Flow volume measured at different time intervals.
流量持续时间可根据[RFC5102]中定义的流量时间戳IEs（例如，flowEndMicroseconds-flowStartMicroseconds）计算得出。流的数据包数和字节数在每个流计数器IEs中表示（例如，packetTotalCount、OctettTotalCount）。可以根据在不同时间间隔测量的流量计算流量的突发性。
Traffic engineering aims at the optimization of network resource utilization and traffic performance [RFC2702]. Typical parameters are link utilization, load between specific network, nodes, number, size and entry/exit points of active Flows, and routing information [RFC3917].
流量工程旨在优化网络资源利用率和流量性能[RFC2702]。典型参数包括链路利用率、特定网络之间的负载、节点、活动流的数量、大小和入口/出口点以及路由信息[RFC3917]。
The size of Flows in packets and bytes can be reported by the IEs packetTotalCount and octetTotalCount. Utilization of a physical link can be reported by using a coarse-grained Flow definition (e.g., based on identifier IEs such as egressInterface or ingressInterface) and per-flow counter IEs (e.g., packetTotalCount, octetTotalCount) defined in [RFC5102].
IEs packetTotalCount和OctettTotalCount可以报告以数据包和字节为单位的流的大小。物理链路的利用率可以通过使用粗粒度流定义（例如，基于标识符IEs，如出口接口或入口接口）和[RFC5102]中定义的每个流计数器IEs（例如，packetTotalCount、OctettTotalCount）来报告。
The load between specific network nodes can be reported in the same way if one interface of a network node receives only traffic from exactly one neighbor node (as is usually the case). If the ingress interface is not sufficient for an unambiguous identification of the neighbor node, sub-IP header fields IEs (like sourceMacAddress) can be added as Flow Keys.
如果一个网络节点的一个接口仅接收来自恰好一个邻居节点的流量（通常情况下），则可以以相同的方式报告特定网络节点之间的负载。如果入口接口不足以明确标识邻居节点，则可以添加子IP头字段IEs（如sourceMacAddress）作为流密钥。
The IE observedFlowTotalCount provides the number of all Flows exported for the Observation Domain since the last initialization of the Metering Process [RFC5102]. If this IE is exported at subsequent points in time, one can derive the number of active Flows in a specific time interval from the difference of the reported counters. The configured Flow termination criteria have to be taken into account to interpret those numbers correctly.
IE observedFlowTotalCount提供自计量过程上次初始化以来为观测域导出的所有流的数量[RFC5102]。如果在随后的时间点导出此IE，则可以从报告计数器的差值中导出特定时间间隔内的活动流数。为了正确解释这些数字，必须考虑配置的流量终止标准。
Entry and exit points can be derived from Flow Records if Metering Processes are installed at all edges of the network and results are mapped in accordance to Flow Keys. For this and other analysis methods that require the mapping of records from different
如果在网络的所有边缘安装了计量过程，并且根据流键映射结果，则可以从流记录中导出入口和出口点。对于此分析方法和其他需要映射来自不同数据库的记录的分析方法
Observation Points, the same Flow Keys should be used at all Observation Points. The path that packets take through a network can be investigated by using hash-based sampling techniques as described in [DuGr00] and [RFC5475]. For this, IEs from [RFC5477] are needed.
观察点，所有观察点应使用相同的流量键。可以使用[DuGr00]和[RFC5475]中所述的基于散列的采样技术来调查数据包通过网络的路径。为此，需要[RFC5477]的IEs。
Neither [RFC5102] nor [RFC5477] defines IEs suitable for exporting routing information.
[RFC5102]和[RFC5477]都没有定义适合导出路由信息的IEs。
Attack and intrusion detection are among the IPFIX target applications described in [RFC3917]. Due to the enormous amount of different network attack types, only general requirements could be addressed in [RFC3917].
[RFC3917]中描述的IPFIX目标应用程序包括攻击和入侵检测。由于不同的网络攻击类型数量巨大，因此[RFC3917]中只能满足一般要求。
The number of metrics useful for attack detection is as diverse as attack patterns themselves. Attackers adapt rapidly to circumvent detection methods and try to hide attack patterns using slow or stealth attacks. Furthermore, unusual traffic patterns are not always caused by malicious activities. A sudden traffic increase may be caused by legitimate users who seek access to a recently published web content. Strange traffic patterns may also be caused by misconfiguration.
对攻击检测有用的度量的数量与攻击模式本身一样多种多样。攻击者迅速适应规避检测方法，并尝试使用慢速或隐形攻击隐藏攻击模式。此外，异常流量模式并不总是由恶意活动引起的。流量突然增加可能是因为合法用户寻求访问最近发布的web内容。错误配置也可能导致奇怪的交通模式。
IPFIX can export Flow information for arbitrary Flow definitions as defined in [RFC5101]. Packet information can be exported with IPFIX by using the additional Information Elements described in [RFC5477]. With this, theoretically all information about traffic in the network at the IP layer and above is accessible. This data either can be used directly to detect anomalies or can provide the basis for further post-processing to generate more complex attack detection metrics.
IPFIX可以为[RFC5101]中定义的任意流定义导出流信息。通过使用[RFC5477]中描述的附加信息元素，可以使用IPFIX导出数据包信息。这样，理论上所有关于IP层及以上网络流量的信息都可以访问。这些数据可以直接用于检测异常，也可以为进一步的后处理提供基础，以生成更复杂的攻击检测指标。
Depending on the attack type, different metrics are useful. A sudden increase of traffic load can be a hint that an attack has been launched. The overall traffic at an Observation Point can be monitored using per-flow counter IEs like packetTotalCount or octetTotalCount as described in Section 2.3. The number of active Flows can be monitored by regular reporting of the observedFlowTotalCount defined in [RFC5102].
根据攻击类型，不同的度量是有用的。流量负载的突然增加可能暗示已发起攻击。可使用每流量计数器IEs（如第2.3节所述的packetTotalCount或OctettTotalCount）监测观测点的总流量。可通过定期报告[RFC5102]中定义的observedFlowTotalCount来监控活动流的数量。
A sudden increase of Flows from different sources to one destination may be caused by an attack on a specific host or network node using spoofed addresses. The number of Flows from or to specific networks or hosts can be observed by using source and destination addresses as Flow Keys and observing the number of active Flows as explained above. Many Flows to the same machine, but on different ports, or many Flows to the same port and different machines may be an
使用伪造地址攻击特定主机或网络节点可能会导致从不同来源到一个目的地的流量突然增加。通过使用源地址和目标地址作为流键并观察如上所述的活动流的数量，可以观察到来自或到特定网络或主机的流的数量。多个流到同一台机器，但在不同的端口上，或者多个流到同一个端口和不同的机器可能是一个问题
indicator for vertical or horizontal port scanning activities. The number of Flows to different ports can be reported by using the portnumber Information Elements (udpSourcePort, udpDestinationPort, tcpSourcePort, tcpDestinationPort) defined in [RFC5102] as Flow Keys.
用于垂直或水平端口扫描活动的指示器。通过使用[RFC5102]中定义的端口号信息元素（udpSourcePort、udpDestinationPort、tcpSourcePort、tcpDestinationPort）作为流键，可以报告到不同端口的流数。
An unusual ratio of TCP-SYN to TCP-FIN packets can refer to SYN-flooding. The number of SYN and FIN packets in a Flow can be reported with the IPFIX Information Elements tcpSynTotalCount and tcpFinTotalCount defined in [RFC5102].
TCP-SYN与TCP-FIN数据包的异常比率可指SYN泛洪。流中SYN和FIN数据包的数量可以使用[RFC5102]中定义的IPFIX信息元素tcpSynTotalCount和tcpFinTotalCount进行报告。
Worms may leave signatures in traffic patterns. Detecting such events requires more detailed measurements and post-processing than detecting simple changes in traffic volumes.
蠕虫可能会在流量模式中留下签名。与检测交通量的简单变化相比，检测此类事件需要更详细的测量和后处理。
A difficult task is the separation of good from bad packets to prepare and launch counteraction. This may require a deeper look into packet content by using further header field IEs from [RFC5102] and/or packet payloads from IE ipPayloadPacketSection in [RFC5477].
一项困难的任务是将好数据包与坏数据包分离，以准备和启动反作用。这可能需要通过使用[RFC5102]中的更多报头字段IEs和/或[RFC5477]中IE ipPayloadPacketSection中的数据包有效载荷，对数据包内容进行更深入的研究。
Furthermore, the amount of resources needed for measurement and reporting increases with the level of granularity required to detect an attack. Multi-step analysis techniques may be useful, e.g., to launch an in-depth analysis (e.g., based on packet information) in case the Flow information shows suspicious patterns. In order to supervise traffic to a specific host or network node, it is useful to apply filtering methods such as those described in [RFC5475].
此外，测量和报告所需的资源量随着检测攻击所需的粒度级别的增加而增加。多步骤分析技术可能有用，例如，在流信息显示可疑模式的情况下启动深入分析（例如，基于分组信息）。为了监控到特定主机或网络节点的流量，应用[RFC5475]中所述的过滤方法非常有用。
Mapping the two directions of communication is often useful for checking correct protocol behavior (see Section 4.6). A correlation of IPFIX data from multiple Observation Points (see Section 2.5.1) allows assessing the propagation of an attack and can help to locate its source.
映射通信的两个方向通常有助于检查正确的协议行为（参见第4.6节）。来自多个观测点的IPFIX数据的相关性（见第2.5.1节）允许评估攻击的传播，并有助于定位攻击源。
The integration of previous measurement results helps to review traffic changes over time for detection of traffic anomalies and provides the basis for forensic analysis. A standardized storage format for IPFIX data would support the offline analysis of data from different operators.
整合先前的测量结果有助于审查交通随时间的变化，以检测交通异常，并为法医分析提供基础。IPFIX数据的标准化存储格式将支持对来自不同运营商的数据进行离线分析。
Nevertheless, capturing full packet traces at all Observation Points in the network is not viable due to resource limitations and privacy concerns. Therefore, metrics should be chosen wisely to allow a solid detection with minimal resource consumption. Resources can be saved, for instance, by using coarser-grained Flow definitions, reporting pre-processed metrics (e.g., with additional Information Elements), or deploying sampling methods.
然而，由于资源限制和隐私问题，在网络中的所有观察点捕获完整的数据包跟踪是不可行的。因此，应该明智地选择度量，以允许以最小的资源消耗进行可靠的检测。例如，可以通过使用粗粒度流定义、报告预处理的度量（例如，使用附加信息元素）或部署采样方法来节省资源。
In many cases, only derived metrics provide sufficient evidence about security incidents. For example, comparing the number of SYN and FIN packets for a specific time interval can reveal an ongoing SYN attack, which is not obvious from unprocessed packet and Flow data. Further metrics like the cumulated sum of various counters, distributions of packet attributes, or spectrum coefficients have been used to identify a variety of attacks.
在许多情况下，只有派生的指标才能提供有关安全事件的充分证据。例如，比较特定时间间隔内SYN和FIN数据包的数量可以发现正在进行的SYN攻击，这在未处理的数据包和流数据中并不明显。进一步的度量，如各种计数器的累积和、数据包属性的分布或频谱系数，已被用于识别各种攻击。
In order to detect attacks early, it is useful to process the data as soon as possible in order to generate significant metrics for the detection. Pre-processing of raw packet and Flow data already at the measurement device can speed up the detection process and reduces the amount of data that need to be exported. Furthermore, it is possible to directly report derived metrics by defining appropriate Information Elements. Immediate data export in case of a potential incident is desired. IPFIX supports such source-triggered exporting of information due to the push model approach. Nevertheless, further exporting criteria have to be implemented to export IPFIX records upon incident detection events and not only upon flow-end or fixed-time intervals.
为了及早检测攻击，尽快处理数据以生成重要的检测指标非常有用。对测量设备上已经存在的原始数据包和流数据进行预处理可以加快检测过程，并减少需要导出的数据量。此外，通过定义适当的信息元素，可以直接报告派生的度量。需要在发生潜在事件时立即导出数据。由于推送模型方法，IPFIX支持此类源触发的信息导出。然而，必须实施进一步的导出标准，以便在事件检测事件时导出IPFIX记录，而不仅仅是在流结束或固定时间间隔时。
Intrusion detection would profit from the combination of IPFIX functions with AAA functions (see Section 3.5). Such an interoperation enables further means for attacker detection, advanced defense strategies, and secure inter-domain cooperation.
入侵检测将得益于IPFIX功能与AAA功能的结合（见第3.5节）。这种互操作使攻击者检测、高级防御策略和安全域间合作成为可能。
Quality of service (QoS) monitoring is one target application of the IPFIX protocol [RFC3917]. QoS monitoring is the passive observation of the transmission quality for single Flows or traffic aggregates in the network. One example of its use is the validation of QoS guarantees in service level agreements (SLAs). Typical QoS parameters are loss [RFC2680], one-way [RFC2679] and round-trip delay [RFC2681], and delay variation [RFC3393]. Whenever applicable, the IP Performance Metrics (IPPM) definitions [RFC4148] should be used when reporting QoS metrics.
服务质量（QoS）监控是IPFIX协议[RFC3917]的一个目标应用程序。QoS监控是对网络中单个流或流量聚合的传输质量的被动观察。其使用的一个示例是验证服务级别协议（SLA）中的QoS保证。典型的QoS参数是丢失[RFC2680]、单向[RFC2679]和往返延迟[RFC2681]以及延迟变化[RFC3393]。如果适用，在报告QoS指标时应使用IP性能指标（IPPM）定义[RFC4148]。
The calculation of those QoS metrics requires per-packet processing. Reporting packet information with IPFIX is possible by simply considering a single packet as Flow. [RFC5101] also allows the reporting of multiple identical Information Elements in one Flow Record. Using this feature for reporting information about multiple packets in one record would require additional agreement on semantics regarding the order of Information Elements (e.g., which timestamp belongs to which packet payload in a sequence of Information Elements). [RFC5477] defines useful additional Information Elements for exporting per-packet information with IPFIX.
这些QoS度量的计算需要每个数据包进行处理。只需将单个数据包视为流，就可以使用IPFIX报告数据包信息。[RFC5101]还允许在一个流记录中报告多个相同的信息元素。使用此功能来报告一个记录中多个数据包的信息，需要就信息元素顺序（例如，信息元素序列中哪个时间戳属于哪个数据包负载）的语义达成额外的一致。[RFC5477]定义了用于使用IPFIX导出每个数据包信息的有用附加信息元素。
Some QoS metrics require the correlation of data from multiple Observation Points. For this, the clocks of the involved Metering Processes must be synchronized. Furthermore, it is necessary to recognize that the same packet was observed at different Observation Points.
一些QoS指标要求多个观测点的数据相互关联。为此，相关计量过程的时钟必须同步。此外，有必要认识到在不同的观察点观察到相同的数据包。
This can be done by capturing parts of the packet content (packet header and/or parts of the payload) that do not change on the way to the destination. Based on the packet content, it can be recognized when the same packet arrived at another Observation Point. To reduce the amount of measurement data, a unique packet ID can be calculated from the packet content, e.g., by using a Cyclic Redundancy Check (CRC) or hash function instead of transferring and comparing the unprocessed content. Considerations on collision probability and efficiency of using such packet IDs are described in [GrDM98], [DuGr00], and [ZsZC01].
这可以通过捕获在到达目的地的途中不会改变的部分数据包内容（数据包报头和/或有效负载的部分）来实现。根据数据包内容，当同一数据包到达另一个观测点时，可以识别该数据包。为了减少测量数据量，可以从分组内容计算唯一分组ID，例如，通过使用循环冗余校验（CRC）或散列函数，而不是传输和比较未处理的内容。[GrDM98]、[DuGr00]和[ZsZC01]中描述了对使用此类分组ID的冲突概率和效率的考虑。
IPFIX allows the reporting of several IP and transport header fields (see Sections 5.3 and 5.4 in [RFC5102]). Using only those fields for packet recognition or ID generation can be sufficient in scenarios where those header fields vary a lot among subsequent packets, where a certain amount of packet ID collisions are tolerable, or where packet IDs need to be unique only for a small time interval.
IPFIX允许报告多个IP和传输头字段（参见[RFC5102]中的第5.3节和第5.4节）。在以下情况下，仅使用这些字段进行数据包识别或ID生成就足够了：这些报头字段在后续数据包之间变化很大，可以容忍一定数量的数据包ID冲突，或者数据包ID只需在很短的时间间隔内唯一。
For including packet payload information, the Information Element ipPayloadPacketSection defined in [RFC5477] can be used. The Information Element ipHeaderPacketSection can also be used. However, header fields that can change on the way from source to destination have to be excluded from the packet ID generation because they may differ at different Observation Points.
为了包括数据包有效负载信息，可以使用[RFC5477]中定义的信息元素ipPayloadPacketSection。也可以使用信息元素ipHeaderPacketSection。然而，在从源到目的地的过程中可能发生变化的报头字段必须从包ID生成中排除，因为它们在不同的观察点可能不同。
For reporting packet IDs generated by a CRC or hash function, the Information Element digestHashValue defined in [RFC5477] can be used.
对于报告CRC或哈希函数生成的数据包ID，可以使用[RFC5477]中定义的信息元素digestHashValue。
The following examples show which Information Elements need to be reported by IPFIX to generate specific QoS metrics. As an alternative, the metrics can be generated directly at the exporter and IPFIX can be used to export the metrics (see Section 2.7).
以下示例显示了IPFIX需要报告哪些信息元素以生成特定的QoS度量。另一种方法是，可直接在导出器处生成度量，并可使用IPFIX导出度量（见第2.7节）。
The passive measurement of round-trip time (RTT) can be performed by using packet pair matching techniques as described in [Brow00]. For the measurements, request/response packet pairs from protocols such
可通过使用[Brow00]中所述的包对匹配技术来执行往返时间（RTT）的被动测量。对于测量，来自以下协议的请求/响应数据包对
as DNS, ICMP, SNMP or TCP (SYN/SYN_ACK, DATA/ACK) are utilized to passively observe the RTT [Brow00]. This technique requires the correlation of data from both directions.
由于DNS、ICMP、SNMP或TCP（SYN/SYN_ACK、DATA/ACK）用于被动观察RTT[Brow00]。这种技术需要从两个方向对数据进行关联。
Required Information Elements per packet (DNS example): - Packet arrival time: observationTimeMicroseconds [RFC5477] - DNS header: ipPayloadPacketSection [RFC5477]
每个数据包所需的信息元素（DNS示例）：-数据包到达时间：observationTimeMicroseconds[RFC5477]-DNS标头：ipPayloadPacketSection[RFC5477]
Required functions: - Recognition of request/response packet pairs
所需功能：-识别请求/响应数据包对
Remarks: - Requires Information Elements from [RFC5477]. - observationTimeMicroseconds can be substituted by flowStartMicroseconds [RFC5102] because a single packet can be represented as a Flow. - If time values with a finer granularity are needed, observationTimeNanoseconds can be used.
备注：-需要[RFC5477]中的信息元素-observationTimeMicroseconds可以用flowStartMicroseconds[RFC5102]代替，因为单个数据包可以表示为流。-如果需要粒度更细的时间值，可以使用observationTimeNanoseconds。
Passive one-way delay measurements require the collection of data at two Observation Points. As mentioned above, synchronized clocks are needed to avoid time-differences at the involved Observation Points.
被动单向延迟测量需要在两个观测点收集数据。如上所述，需要同步时钟以避免相关观测点的时差。
The recognition of packets at the second Observation Point can be based on parts of the packet content directly. A more efficient way is to use a packet ID (generated from packet content).
在第二观察点处的分组的识别可以直接基于分组内容的部分。更有效的方法是使用数据包ID（由数据包内容生成）。
Required Information Elements per packet (with packet ID): - Packet arrival time: observationTimeMicroseconds [RFC5477] - Packet ID: digestHashValue [RFC5477]
每个数据包所需的信息元素（带有数据包ID）：-数据包到达时间：observationTimeMicroseconds[RFC5477]-数据包ID:digestHashValue[RFC5477]
Required functions: - Packet ID generation - Delay calculation (from arrival times at the two Observation Points)
所需功能：-数据包ID生成-延迟计算（从两个观测点的到达时间）
Remarks: - Requires Information Elements from [RFC5477]. - observationTimeMicroseconds can be substituted by flowStartMicroseconds [RFC5102], because a single packet can be represented as a Flow. - If time values with a finer granularity are needed, observationTimeNanoseconds can be used.
备注：-需要[RFC5477]中的信息元素-observationTimeMicroseconds可以用flowStartMicroseconds[RFC5102]代替，因为单个数据包可以表示为流。-如果需要粒度更细的时间值，可以使用observationTimeNanoseconds。
- The amount of content used for ID generation influences the number of collisions (different packets that map to the same ID) that can occur. Investigations on this and other considerations on packet ID generation can be found in [GrDM98], [DuGr00], and [ZsZC01].
- 用于ID生成的内容量会影响可能发生的冲突（映射到同一ID的不同数据包）的数量。[GrDM98]、[DuGr00]和[ZsZC01]中对这一点以及包ID生成的其他注意事项进行了研究。
IPFIX data can be used to share information with neighbor providers. A few recommendations should be considered if IPFIX records travel over the public Internet, compared to its usage within a single domain. First of all, security threat levels are higher if data travels over the public Internet. Protection against disclosure or manipulation of data is even more important than for intra-domain usage. Therefore, Transport Layer Security (TLS) or Datagram Transport Layer Security should be used as described in [RFC5101].
IPFIX数据可用于与邻居提供商共享信息。如果IPFIX记录在公共互联网上传播，与它在单个域中的使用情况相比，应该考虑一些建议。首先，如果数据通过公共互联网传播，安全威胁级别更高。防止数据泄露或操纵比域内使用更为重要。因此，应按照[RFC5101]中的说明使用传输层安全性（TLS）或数据报传输层安全性。
Furthermore, data transfer should be congestion-aware in order to allow untroubled coexistence with other data Flows in public or foreign networks. That means transport over Stream Control Transmission Protocol (SCTP) or TCP is required.
此外，数据传输应具有拥塞感知能力，以允许与公共或外部网络中的其他数据流无干扰共存。这意味着需要通过流控制传输协议（SCTP）或TCP进行传输。
Some ISPs are still reluctant to share information due to concerns that competing ISPs might exploit network information from neighbor providers to strengthen their own position in the market. Nevertheless, technical needs have already triggered the exchange of data in the past (e.g., exchange of routing information by BGP). The need to provide inter-domain guarantees is one big incentive to increase inter-domain cooperation. The necessity to defend networks against current and future threats (denial-of-service attacks, worm distributions, etc.) will hopefully increase the willingness to exchange measurement data between providers.
一些ISP仍然不愿意共享信息，因为担心竞争的ISP可能会利用邻居提供商的网络信息来加强自己在市场中的地位。然而，技术需求在过去已经触发了数据交换（例如，BGP交换路由信息）。提供域间担保的需要是增加域间合作的一大诱因。保护网络免受当前和未来威胁（拒绝服务攻击、蠕虫传播等）的必要性有望提高提供商之间交换测量数据的意愿。
The IPFIX protocol is used to transport Flow and packet information to provide the input for the calculation of a variety of metrics (e.g., for QoS validation or attack detection). IPFIX can also be used to transfer these metrics directly, e.g., if the metric calculation is co-located with the Metering and Exporting Processes.
IPFIX协议用于传输流和数据包信息，为各种度量的计算提供输入（例如，用于QoS验证或攻击检测）。IPFIX还可用于直接传输这些度量，例如，如果度量计算与计量和导出过程位于同一位置。
It doesn't matter which measurement and post-processing functions are applied to generate a specific metric. IPFIX can be used to transport the results from passive and active measurements and from post-processing operations. For the reporting of derived metrics, additional Information Elements need to be defined.
应用哪些度量和后处理函数来生成特定度量并不重要。IPFIX可用于传输被动和主动测量以及后处理操作的结果。对于衍生指标的报告，需要定义额外的信息元素。
For most QoS metrics like loss, delay, delay variation, etc., standard IPPM definitions exist. In case such metrics are reported with IPFIX, the IPPM standard definition should be used.
对于大多数QoS指标，如丢失、延迟、延迟变化等，存在标准IPPM定义。如果IPFIX报告了此类指标，则应使用IPPM标准定义。
The following table shows an overview of the Information Elements required for the target applications described in [RFC3917] (M-mandatory, R-recommended, O-optional).
下表概述了[RFC3917]（M-强制、R-推荐、O-可选）中所述目标应用程序所需的信息元素。
| Application | [RFC5102] | [RFC5477] | additional IEs |
+-------------+------------+--------------+-----------------+
| Accounting | M | - | - |
+-------------+------------+--------------+-----------------+
| Traffic | M | O | - |
| Profiling | | | |
+-------------+------------+--------------+-----------------+
| Traffic | M | - | O |
| Engineering | | | (routing info) |
+-------------+------------+--------------+-----------------+
| Attack | M | R | R |
| Detection | | |(derived metrics)|
+-------------+------------+--------------+-----------------+
| QoS | M | M | O |
| Monitoring | |(most metrics)|(derived metrics)|
+-------------+------------+--------------+-----------------+
| Application | [RFC5102] | [RFC5477] | additional IEs |
+-------------+------------+--------------+-----------------+
| Accounting | M | - | - |
+-------------+------------+--------------+-----------------+
| Traffic | M | O | - |
| Profiling | | | |
+-------------+------------+--------------+-----------------+
| Traffic | M | - | O |
| Engineering | | | (routing info) |
+-------------+------------+--------------+-----------------+
| Attack | M | R | R |
| Detection | | |(derived metrics)|
+-------------+------------+--------------+-----------------+
| QoS | M | M | O |
| Monitoring | |(most metrics)|(derived metrics)|
+-------------+------------+--------------+-----------------+
For accounting, the IEs in [RFC5102] are sufficient. As mentioned above, IPFIX does not conform to the reliability requirements demanded by [RFC2975] for usage-based billing systems (see Section 4.2). For traffic profiling, additional IEs from [RFC5477] can be useful to gain more insight into the traffic. For traffic engineering, Flow information from [RFC5102] is sufficient, but it would profit from routing information, which could be exported by IPFIX. Attack detection usually profits from further insight into the traffic. This can be achieved with IEs from [RFC5477]. Furthermore, the reporting of derived metrics in additional IEs would be useful. Most QoS metrics require the use of IEs from [RFC5477]. IEs from [RFC5477] are also useful for the mapping of results from different Observation Points as described in Section 2.5.1.
对于会计，[RFC5102]中的IEs已足够。如上所述，IPFIX不符合[RFC2975]对基于使用的计费系统的可靠性要求（见第4.2节）。对于流量分析，[RFC5477]中的附加IEs有助于更深入地了解流量。对于流量工程，来自[RFC5102]的流量信息是足够的，但它将从路由信息中获益，路由信息可以由IPFIX导出。攻击检测通常得益于对流量的进一步了解。这可以通过[RFC5477]中的IEs实现。此外，在额外的IEs中报告衍生指标将是有用的。大多数QoS指标要求使用[RFC5477]中的IEs。[RFC5477]中的IEs对于绘制第2.5.1节所述不同观测点的结果也很有用。
From the beginning, IPFIX has been designed for IPv4 and IPv6. Therefore, IPFIX can be used in IPv4 and IPv6 networks without limitations. The usage of IPFIX in IPv6 networks has two aspects:
从一开始，IPFIX就是为IPv4和IPv6设计的。因此，IPFIX可以在IPv4和IPv6网络中无限制地使用。IPFIX在IPv6网络中的使用有两个方面：
- Generation and reporting of IPFIX records about IPv6 traffic - Exporting IPFIX records over IPv6
- 生成和报告有关IPv6流量的IPFIX记录-通过IPv6导出IPFIX记录
The generation and reporting of IPFIX records about IPv6 traffic is possible. Appropriate Information Elements for the reporting of IPv6 traffic are defined in [RFC5102]. Exporting IPFIX records over IPv6 is not explicitly addressed in [RFC5101]. Since IPFIX runs over a transport protocol (SCTP, PR-SCTP, UDP, or TCP) and all potential IPFIX transport protocols can run in IPv6 networks, one just needs to provide the chosen transport protocol in the IPv6 network to run IPFIX over IPv6.
可以生成和报告有关IPv6流量的IPFIX记录。[RFC5102]中定义了用于报告IPv6流量的适当信息元素。[RFC5101]中未明确说明通过IPv6导出IPFIX记录的问题。由于IPFIX通过传输协议（SCTP、PR-SCTP、UDP或TCP）运行，并且所有潜在的IPFIX传输协议都可以在IPv6网络中运行，因此只需在IPv6网络中提供所选的传输协议即可通过IPv6运行IPFIX。
PSAMP defines packet selection methods, their configuration at routers and probes, and the reporting of packet information.
PSAMP定义了包选择方法、它们在路由器和探测器上的配置以及包信息的报告。
PSAMP uses IPFIX as a basis for exporting packet information [RFC5476]. [RFC5477] describes further Information Elements for exporting packet information and reporting configuration information.
PSAMP使用IPFIX作为导出数据包信息的基础[RFC5476]。[RFC5477]描述了用于导出数据包信息和报告配置信息的更多信息元素。
The main difference between IPFIX and PSAMP is that IPFIX addresses the export of Flow Records, whereas PSAMP addresses the export of packet records. Furthermore, PSAMP explicitly addresses remote configuration. It defines a MIB for the configuration of packet selection processes. Remote configuration is not (yet) addressed in IPFIX, but one could consider extending the PSAMP MIB to also allow configuration of IPFIX processes.
IPFIX和PSAMP之间的主要区别在于IPFIX处理流记录的导出，而PSAMP处理数据包记录的导出。此外，PSAMP明确地解决了远程配置问题。它定义了用于配置数据包选择过程的MIB。远程配置在IPFIX中还没有解决，但是可以考虑扩展PSAMP MIB来允许IPFIX进程的配置。
Remote Monitoring (RMON) [RFC3577] is a widely used monitoring system that gathers traffic data from RMON Agents in network devices. One major difference between RMON and IPFIX is that RMON uses SNMP for data export, whereas IPFIX defines its own push-oriented protocol. RMON defines MIBs that contain the information to be exported. In IPFIX, the data to be exported is defined as Information Elements.
远程监控（RMON）[RFC3577]是一种广泛使用的监控系统，它从网络设备中的RMON代理收集流量数据。RMON和IPFIX之间的一个主要区别是RMON使用SNMP进行数据导出，而IPFIX定义了自己的面向推的协议。RMON定义包含要导出的信息的MIB。在IPFIX中，要导出的数据定义为信息元素。
The most relevant MIBs for comparison with IPFIX are the Application Performance Measurement MIB (APM-MIB) [RFC3729] and the Transport Performance Metrics MIB (TPM-MIB) [RFC4150]. The APM-MIB has a complex system for tracking user application performance, with reporting about transactions and SLA threshold notification-trigger configuration, and persistence across DHCP lease expirations. It requires a full RMON2-MIB protocolDirTable implementation.
与IPFIX相比，最相关的MIB是应用程序性能度量MIB（APM-MIB）[RFC3729]和传输性能度量MIB（TPM-MIB）[RFC4150]。APM-MIB有一个复杂的系统，用于跟踪用户应用程序性能，报告事务和SLA阈值通知触发器配置，以及DHCP租约到期期间的持久性。它需要完整的RMON2-MIB protocolDirTable实现。
The APM-MIB reports the performance of transactions. A transaction is a service-oriented term and describes the data exchange from the transaction start (when a user requests a service) until its completion. The performance parameters include response times, throughput, streaming responsiveness, and availability of services.
APM-MIB报告事务的性能。事务是一个面向服务的术语，描述从事务开始（当用户请求服务时）到完成的数据交换。性能参数包括响应时间、吞吐量、流响应性和服务可用性。
The RMON transaction concept differs from the IPFIX Flow concept. A Flow is a very generic term that allows one to group IP packets in accordance with common properties. In contrast to this, the term transaction is service-oriented and contains all data exchange required for service completion.
RMON事务概念不同于IPFIX流概念。流是一个非常通用的术语，它允许人们根据公共属性对IP数据包进行分组。与此相反，术语事务是面向服务的，包含完成服务所需的所有数据交换。
In order to report such data with IPFIX, one would probably need a specific combination of multiple Flows and the ability to map those to the transaction. Due to the service-oriented focus of APM, the required metrics also differ. For instance, the RMON APM requires a metric for the responsiveness of services. Such metrics are not addressed in IPFIX.
为了使用IPFIX报告此类数据，可能需要多个流的特定组合以及将这些流映射到事务的能力。由于APM注重面向服务，因此所需的指标也有所不同。例如，RMON APM需要服务响应的度量。IPFIX中未涉及此类指标。
Furthermore, the APM-MIB allows the configuration of the transaction type to be monitored, which is currently not addressed in IPFIX.
此外，APM-MIB允许监视事务类型的配置，这在IPFIX中目前没有解决。
The APM MIB could be considered as an extension of the IPFIX Metering Process where the application performance of a combination of multiple Flows is measured. If appropriate, IEs would be defined in the IPFIX information model and the IPFIX Device would support the APM MIB data collection, the solutions could be complementary. That means one could use IPFIX to export APM MIB transaction information.
APM MIB可以被视为IPFIX计量过程的扩展，在IPFIX计量过程中，测量多个流组合的应用程序性能。如果合适，IEs将在IPFIX信息模型中定义，IPFIX设备将支持APM MIB数据收集，解决方案可以是互补的。这意味着可以使用IPFIX导出APM MIB事务信息。
The TPM-MIB breaks out the APM-MIB transactions into sub-application level transactions. For instance, a web request is broken down into DNS, TCP, and HTTP sub-transactions. Such sub-transactions can be considered as bidirectional Flows. With an appropriate Flow definition and the ability to map both directions of a Flow (see Section 4.6), one could measure and report Flow characteristics of such sub-application level transaction with IPFIX.
TPM-MIB将APM-MIB事务分解为子应用程序级事务。例如，web请求被分解为DNS、TCP和HTTP子事务。此类子事务可被视为双向流。通过适当的流定义和映射流的两个方向的能力（参见第4.6节），可以使用IPFIX测量和报告此类子应用程序级事务的流特征。
The TPM-MIB requires APM-MIB and RMON2-MIB.
TPM-MIB需要APM-MIB和RMON2-MIB。
The IPFIX protocol can be used to carry IPPM network performance metrics or information that can be used to calculate those metrics (see Sections 2.5 and 2.7 for details and references).
IPFIX协议可用于承载IPPM网络性能指标或可用于计算这些指标的信息（有关详细信息和参考信息，请参阅第2.5节和第2.7节）。
AAA defines a protocol and architecture for authentication, authorization, and accounting for service usage [RFC2903]. The DIAMETER protocol [RFC3588] is used for AAA communication, which is needed for network access services (Mobile IP, NASREQ, and ROAMOPS). The AAA architecture [RFC2903] provides a framework for extending AAA support to other services. DIAMETER defines the exchange of messages between AAA entities, e.g., between AAA clients at access devices and AAA servers, and among AAA servers. DIAMETER is used for the transfer of accounting records. In order to form accounting records for usage-based accounting measurement, data from the network is required. IPFIX defines a protocol to export such data from routers, measurement probes, and other devices. Therefore, it looks promising to connect those two architectures.
AAA定义了用于认证、授权和服务使用计费的协议和体系结构[RFC2903]。DIAMETER协议[RFC3588]用于AAA通信，网络接入服务（移动IP、NASREQ和ROAMOPS）需要AAA通信。AAA体系结构[RFC2903]提供了一个框架，用于将AAA支持扩展到其他服务。DIAMETER定义AAA实体之间的消息交换，例如，访问设备上的AAA客户端和AAA服务器之间以及AAA服务器之间的消息交换。直径用于转移会计记录。为了形成基于使用情况的会计计量的会计记录，需要来自网络的数据。IPFIX定义了一个从路由器、测量探针和其他设备导出此类数据的协议。因此，连接这两种体系结构看起来很有希望。
For all scenarios described here, one has to keep in mind that IPFIX does not conform to the reliability requirements for usage-based billing described in [RFC2975] (see Section 4.2). Using IPFIX without reliability extensions together with AAA would result in accounting scenarios that do not conform to usage-based billing requirements described in [RFC2975].
对于这里描述的所有场景，必须记住IPFIX不符合[RFC2975]中描述的基于使用的计费的可靠性要求（参见第4.2节）。将不带可靠性扩展的IPFIX与AAA一起使用会导致会计场景不符合[RFC2975]中描述的基于使用情况的计费要求。
As shown in Section 2.1, accounting applications can directly incorporate an IPFIX Collecting Process to receive IPFIX records with information about the transmitted volume. Nevertheless, if a AAA infrastructure is in place, the cooperation between IPFIX and AAA provides many valuable synergistic benefits. IPFIX records can provide the input for AAA accounting functions and provide the basis for the generation of DIAMETER accounting records. However, as stated in Section 4.2, the use of IPFIX as described in [RFC5101] is currently limited to situations where the purpose of the accounting does not require reliability.
如第2.1节所示，会计应用程序可以直接合并IPFIX收集过程，以接收包含传输卷信息的IPFIX记录。然而，如果AAA基础设施到位，IPFIX和AAA之间的合作将提供许多有价值的协同效益。IPFIX记录可以为AAA会计功能提供输入，并为直径会计记录的生成提供依据。然而，如第4.2节所述，[RFC5101]中所述的IPFIX的使用目前仅限于会计目的不要求可靠性的情况。
Further potential features include the mapping of a user ID to Flow information (by using authentication information) or using the secure authorized exchange of DIAMETER accounting records with neighbor domains. The last feature is especially useful in roaming scenarios where the user connects to a foreign network and the home provider generates the invoice.
进一步的潜在功能包括将用户ID映射到流信息（通过使用身份验证信息）或使用DIAMETER记帐记录与相邻域的安全授权交换。最后一项功能在漫游场景中特别有用，在漫游场景中，用户连接到外部网络，而本地提供商生成发票。
Coupling an IPFIX Collecting Process with AAA functions also has high potential for intrusion and attack detection. AAA controls network access and maintains data about users and nodes. AAA functions can help to identify the source of malicious traffic. Authorization functions are able to deny access to suspicious users or nodes. Therefore, coupling those functions with an IPFIX Collecting Process can provide an efficient defense against network attacks.
将IPFIX收集过程与AAA功能相耦合也具有很高的入侵和攻击检测潜力。AAA控制网络访问并维护有关用户和节点的数据。AAA功能可以帮助识别恶意流量的来源。授权功能能够拒绝可疑用户或节点的访问。因此，将这些功能与IPFIX收集过程耦合可以提供有效的网络攻击防御。
Sharing IPFIX records (either directly or encapsulated in DIAMETER) with neighbor providers allows an efficient inter-domain attack detection. For this, it would be useful to allow remote configuration of measurement and record generation in order to provide information in the required granularity and accuracy. Since remote configuration is currently not addressed in IPFIX, this would require additional work. The AAA infrastructure itself may be used to configure measurement functions in the network as proposed in [RFC3334].
与邻居提供商共享IPFIX记录（直接或封装在直径中）可以实现有效的域间攻击检测。为此，允许远程配置测量和记录生成，以提供所需粒度和精度的信息将是有用的。由于远程配置目前未在IPFIX中解决，这将需要额外的工作。AAA基础设施本身可用于按照[RFC3334]中的建议配置网络中的测量功能。
Furthermore, the transport of IPFIX records with DIAMETER would require the translation of IPFIX Information Elements into DIAMETER attribute value pairs (AVPs) defined in [RFC3588]. Since the DIAMETER AVPs do not comprise all IPFIX Information Elements, it is necessary to define new AVPs to transport them over DIAMETER.
此外，使用直径传输IPFIX记录需要将IPFIX信息元素转换为[RFC3588]中定义的直径属性值对（AVP）。由于DIAMETER AVP不包含所有IPFIX信息元素，因此有必要定义新的AVP以在DIAMETER上传输它们。
Two possibilities exist to connect IPFIX and AAA:
连接IPFIX和AAA有两种可能：
- Connecting via a AAA Client - Connecting via an Application Specific Module (ASM)
- 通过AAA客户端连接-通过特定于应用程序的模块（ASM）连接
Both are explained in the following sections. The approaches only require a few additional functions. They do not require any changes to IPFIX or DIAMETER.
以下各节将对此进行解释。这些方法只需要几个附加功能。它们不需要对IPFIX或直径进行任何更改。
One possibility of connecting IPFIX and AAA is to run a AAA client on the IPFIX Collector. This client can generate DIAMETER accounting messages and send them to a AAA server. The mapping of the Flow information to a user ID can be done in the AAA server by using data from the authentication process. DIAMETER accounting messages can be sent to the accounting application or to other AAA servers (e.g., in roaming scenarios).
连接IPFIX和AAA的一种可能性是在IPFIX收集器上运行AAA客户端。此客户端可以生成DIAMETER记帐消息并将其发送到AAA服务器。通过使用来自身份验证过程的数据，可以在AAA服务器中完成流信息到用户ID的映射。DIAMETER记帐消息可以发送到记帐应用程序或其他AAA服务器（例如，在漫游场景中）。
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
| DIAMETER
|
|
+--+--------+--+
| | AAA-C | |
+ +--------+ |
| |
| Collector |
+--------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
| DIAMETER
|
|
+--+--------+--+
| | AAA-C | |
+ +--------+ |
| |
| Collector |
+--------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
Figure 1: IPFIX Collector connects to AAA server via AAA client
图1:IPFIX Collector通过AAA客户端连接到AAA服务器
Another possibility is to directly connect the IPFIX Collector with the AAA server via an application specific module (ASM). Application specific modules have been proposed by the IRTF AAA architecture research group (AAARCH) in [RFC2903]. They act as an interface between AAA server and service equipment. In this case, the IPFIX Collector is part of the ASM. The ASM acts as an interface between the IPFIX protocol and the input interface of the AAA server. The ASM translates the received IPFIX data into an appropriate format for the AAA server. The AAA server then can add information about the user ID and generate a DIAMETER accounting record. This accounting record can be sent to an accounting application or to other AAA servers.
另一种可能是通过特定于应用程序的模块（ASM）将IPFIX收集器直接连接到AAA服务器。IRTF AAA体系结构研究小组（AAARCH）在[RFC2903]中提出了特定于应用程序的模块。它们充当AAA服务器和服务设备之间的接口。在这种情况下，IPFIX收集器是ASM的一部分。ASM充当IPFIX协议和AAA服务器输入接口之间的接口。ASM将接收到的IPFIX数据转换为AAA服务器的适当格式。AAA服务器随后可以添加有关用户ID的信息，并生成DIAMETER记帐记录。此记帐记录可以发送到记帐应用程序或其他AAA服务器。
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
|
+------------------+
| ASM |
| +------------+ |
| | Collector | |
+------------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
|
+------------------+
| ASM |
| +------------+ |
| | Collector | |
+------------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
Figure 2: IPFIX connects to AAA server via ASM
图2:IPFIX通过ASM连接到AAA服务器
The Realtime Traffic Flow Measurement (RTFM) working group defined an architecture for Flow measurement [RFC2722]. This section compares the RTFM framework with the IPFIX framework.
实时交通流量测量（RTFM）工作组定义了流量测量的体系结构[RFC2722]。本节比较RTFM框架和IPFIX框架。
The RTFM architecture [RFC2722] is very similar to the IPFIX architecture. It defines meter, meter reader, and a manager as building blocks of the measurement architecture. The manager configures the meter, and the meter reader collects data from the meter. In RTFM, the building blocks communicate via SNMP.
RTFM体系结构[RFC2722]与IPFIX体系结构非常相似。它将仪表、仪表读取器和管理器定义为测量体系结构的构建块。管理器配置仪表，仪表读取器从仪表收集数据。在RTFM中，构建块通过SNMP进行通信。
The IPFIX architecture [RFC5470] defines Metering, Exporting, and Collecting Processes. IPFIX speaks about processes instead of devices to clarify that multiple of those processes may be co-located on the same machine.
IPFIX体系结构[RFC5470]定义了计量、导出和收集过程。IPFIX谈到进程而不是设备，以澄清这些进程中的多个可能位于同一台机器上。
These definitions do not contradict each other. One could see the Metering Process as part of the meter, and the Collecting Process as part of the meter reader.
这些定义并不矛盾。可以将计量过程视为仪表的一部分，将采集过程视为仪表读取器的一部分。
One difference is that IPFIX currently does not define a managing process because remote configuration was (at least initially) out of scope for the working group.
一个区别是IPFIX目前没有定义管理流程，因为远程配置（至少最初）超出了工作组的范围。
RTFM and IPFIX both consider Flows as a group of packets that share a common set of properties. A Flow is completely specified by that set of values, together with a termination criterion (like inactivity timeout).
RTFM和IPFIX都将流视为共享共同属性集的一组数据包。流完全由该组值以及终止条件（如不活动超时）指定。
A difference is that RTFM defines Flows as bidirectional. An RTFM meter matches packets from B to A and A to B as separate parts of a single Flow, and it maintains two sets of packet and byte counters, one for each direction.
不同之处在于RTFM将流定义为双向流。RTFM表将B到A和A到B的数据包作为单个流的单独部分进行匹配，并维护两组数据包和字节计数器，每个方向一组。
IPFIX does not explicitly state whether Flows are uni- or bidirectional. Nevertheless, Information Elements for describing Flow properties were defined for only one direction in [RFC5102]. There are several solutions for reporting bidirectional Flow information (see Section 4.6).
IPFIX没有明确说明流是单向流还是双向流。然而，在[RFC5102]中，仅为一个方向定义了描述流动特性的信息元素。有几种用于报告双向流信息的解决方案（见第4.6节）。
In RTFM, remote configuration is the only way to configure a meter. This is done by using SNMP and a specific Meter MIB [RFC2720]. The IPFIX group currently does not address IPFIX remote configuration.
在RTFM中，远程配置是配置仪表的唯一方法。这是通过使用SNMP和特定的仪表MIB[RFC2720]实现的。IPFIX组当前未解决IPFIX远程配置问题。
IPFIX Metering Processes export the layout of data within their Templates, from time to time. IPFIX Collecting Processes use that Template information to determine how they should interpret the IPFIX Flow data they receive.
IPFIX计量流程会不时导出其模板内的数据布局。IPFIX收集流程使用该模板信息来确定如何解释接收到的IPFIX流数据。
One major difference between IPFIX and RTFM is the data collection model. RTFM retrieves data in pull mode, whereas IPFIX uses a push mode model to send data to Collecting Processes.
IPFIX和RTFM之间的一个主要区别是数据收集模型。RTFM以拉模式检索数据，而IPFIX使用推模式模型将数据发送到采集进程。
An RTFM meter reader pulls data from a meter by using SNMP. SNMP security on the meter determines whether a reader is allowed to pull data from it. An IPFIX Exporting Process is configured to export records to a specified list of IPFIX Collecting Processes. The condition of when to send IPFIX records (e.g., Flow termination) has to be configured in the Exporting or Metering Process.
RTFM仪表读取器使用SNMP从仪表中提取数据。仪表上的SNMP安全性决定是否允许读卡器从仪表中提取数据。IPFIX导出进程配置为将记录导出到指定的IPFIX收集进程列表。必须在导出或计量过程中配置何时发送IPFIX记录（例如，流终止）的条件。
RTFM defines all its attributes in the RTFM Meter MIB [RFC2720]. IPFIX Information Elements are defined in [RFC5102].
RTFM在RTFM仪表MIB[RFC2720]中定义其所有属性。[RFC5102]中定义了IPFIX信息元素。
RTFM uses continuously-incrementing 64-bit counters for the storage of the number of packets of a Flow. The counters are never reset and just wrap back to zero if the maximum value is exceeded. Flows can be read at any time. The difference between counter readings gives the counts for activity in the interval between readings.
RTFM使用连续递增的64位计数器来存储流的数据包数。计数器永远不会重置，如果超过最大值，只会返回到零。可以随时读取流。计数器读数之间的差值给出了读数间隔内的活动计数。
IPFIX allows absolute (totalCounter) and relative counters (deltaCounter) [RFC5102]. The totalCounter is never reset and just wraps to zero if values are too large, exactly as the counters used in RTFM. The deltaCounter is reset to zero when the associated Flow Record is exported.
IPFIX允许绝对计数器（totalCounter）和相对计数器（deltaCounter）[RFC5102]。totalCounter永远不会重置，如果值太大，只会换行为零，与RTFM中使用的计数器完全相同。导出关联的流记录时，deltaCounter将重置为零。
RTFM has a Standards-Track Meter MIB [RFC2720], which is used both to configure a meter and to store metering results. The MIB provides a way to read lists of attributes with a single Object Identifier (called a 'package'), which reduces the SNMP overhead for Flow data collection. SNMP, of course, normally uses UDP as its transport protocol. Since RTFM requires a reliable Flow data transport system, an RTFM meter reader must time out and resend unanswered SNMP requests. Apart from being clumsy, this can limit the maximum data transfer rate from meter to meter reader.
RTFM有一个标准的轨道测量仪MIB[RFC2720]，用于配置测量仪和存储测量结果。MIB提供了一种使用单个对象标识符（称为“包”）读取属性列表的方法，这减少了流数据收集的SNMP开销。当然，SNMP通常使用UDP作为其传输协议。由于RTFM需要可靠的流量数据传输系统，RTFM仪表读取器必须超时并重新发送未响应的SNMP请求。除了笨拙之外，这还可能限制从仪表到仪表读取器的最大数据传输速率。
IPFIX is designed to work over a variety of different transport protocols. SCTP [RFC4960] and PR-SCTP [RFC3758] are mandatory. UDP and TCP are optional. In addition, the IPFIX protocol encodes data much more efficiently than SNMP does, hence IPFIX has lower data transport overheads than RTFM.
IPFIX设计用于多种不同的传输协议。SCTP[RFC4960]和PR-SCTP[RFC3758]是强制性的。UDP和TCP是可选的。此外，IPFIX协议比SNMP更有效地编码数据，因此IPFIX比RTFM具有更低的数据传输开销。
IPFIX exports Flow information in a push model by using SCTP, TCP, or UDP. It currently does not address remote configuration. RTFM data collection is using the pull model and runs over SNMP. RTFM
IPFIX使用SCTP、TCP或UDP在推送模型中导出流信息。它当前不处理远程配置。RTFM数据采集使用pull模型并在SNMP上运行。RTFM
addresses remote configuration, which also runs over SNMP. Both frameworks allow a very flexible Flow definition, although RTFM is based on a bidirectional Flow definition.
解决也通过SNMP运行的远程配置问题。这两个框架都允许非常灵活的流定义，尽管RTFM是基于双向流定义的。
The goal of this section is to show the limitations of IPFIX and to give advice where not to use IPFIX or in which cases additional considerations are required.
本节的目的是展示IPFIX的局限性，并给出不使用IPFIX的建议，或者在哪些情况下需要额外考虑。
IPFIX provides a generic export mechanism. Due to its Template-based structure, it is a quite flexible protocol. Network operators and users may want to use it for other applications than those described in [RFC3917].
IPFIX提供了一种通用的导出机制。由于其基于模板的结构，它是一个非常灵活的协议。网络运营商和用户可能希望将其用于[RFC3917]中所述以外的其他应用。
Apart from sending raw Flow information, it can be used to send per-packet data, aggregated or post-processed data. For this, new Templates and Information Elements can be defined if needed. Due to its push mode operation, IPFIX is also suited to send network initiated events like alarms and other notifications. It can be used for exchanging information among network nodes to autonomously improve network operation.
除了发送原始流信息外，它还可用于发送每包数据、聚合数据或后处理数据。为此，如果需要，可以定义新的模板和信息元素。由于其推送模式操作，IPFIX还适合发送网络启动的事件，如警报和其他通知。它可以用于网络节点之间的信息交换，以自主地改善网络运行。
Nevertheless, the IPFIX design is based on the requirements that originate only from the target applications stated in [RFC3917]. Using IPFIX for other purposes requires a careful checking of IPFIX capabilities against application requirements. Only with this, one can decide whether IPFIX is a suitable protocol to meet the needs of a specific application.
然而，IPFIX设计基于[RFC3917]中规定的仅源自目标应用程序的要求。将IPFIX用于其他目的需要根据应用程序要求仔细检查IPFIX功能。只有这样，才能决定IPFIX是否适合满足特定应用程序的需要。
The reliability requirements defined in [RFC3917] are not sufficient to guarantee the level of reliability that is needed for usage-based billing systems as described in [RFC2975]. In particular, IPFIX does not support the following features required by [RFC2975]:
[RFC3917]中定义的可靠性要求不足以保证[RFC2975]中描述的基于使用的计费系统所需的可靠性水平。特别是，IPFIX不支持[RFC2975]所需的以下功能：
- Record loss: IPFIX allows the usage of different transport protocols for the transfer of data records. Resilience against the loss of IPFIX data records can be only provided if TCP or SCTP is used for the transfer of data records.
- 记录丢失：IPFIX允许使用不同的传输协议传输数据记录。只有在使用TCP或SCTP传输数据记录时，才能提供针对IPFIX数据记录丢失的恢复能力。
- Network or device failures: IPFIX does allow the usage of multiple Collectors for one Exporter, but it neither specifies nor demands the use of multiple Collectors for the provisioning of fault tolerance.
- 网络或设备故障：IPFIX允许一个导出器使用多个收集器，但它既不指定也不要求使用多个收集器来提供容错。
- Detection and elimination of duplicate records: This is currently not supported by IPFIX.
- 检测和消除重复记录：IPFIX目前不支持这一点。
- Application layer acknowledgements: IPFIX does not support the control of measurement and Exporting Processes by higher-level applications. Application layer acknowledgements are necessary, e.g., to inform the Exporter in case the application is not able to process the data exported with IPFIX. Such acknowledgements are not supported in IPFIX.
- 应用层确认：IPFIX不支持高级应用程序控制测量和导出过程。应用程序层确认是必要的，例如，在应用程序无法处理IPFIX导出的数据时通知导出程序。IPFIX中不支持此类确认。
Further features like archival accounting and pre-authorization are out of scope of the IPFIX specification but need to be realized in billing system architectures as described in [RFC2975].
归档记帐和预授权等其他功能超出了IPFIX规范的范围，但需要在[RFC2975]中描述的计费系统架构中实现。
SCTP is the preferred protocol for IPFIX, i.e., a conforming implementation must work over SCTP. Although IPFIX can also work over TCP or UDP, both protocols have drawbacks [RFC5101]. Users should make sure they have good reasons before using protocols other than SCTP in a specific environment.
SCTP是IPFIX的首选协议，即一致性实现必须在SCTP上工作。虽然IPFIX也可以在TCP或UDP上工作，但这两种协议都有缺点[RFC5101]。在特定环境中使用SCTP以外的协议之前，用户应确保他们有充分的理由。
IPFIX works in push mode. That means IPFIX records are automatically exported without the need to wait for a request. The responsibility for initiating a data export lies with the Exporting Process.
IPFIX在推送模式下工作。这意味着IPFIX记录将自动导出，而无需等待请求。启动数据导出的责任在于导出过程。
Criteria for exporting data need to be configured at the Exporting Process. Therefore, push mode has more benefits if the trigger for data export is related to events at the Exporting Process (e.g., Flow termination, memory shortage due to large amount of Flows, etc.). If the protocol used pull mode, the Exporting Process would need to wait for a request to send the data. With push mode, it can send data immediately, e.g., before memory shortage would require a discarding of data.
需要在导出过程中配置导出数据的条件。因此，如果数据导出的触发器与导出过程中的事件（例如，流终止、大量流导致的内存不足等）相关，则推送模式具有更多的好处。如果协议使用拉模式，导出过程将需要等待发送数据的请求。使用推送模式，它可以立即发送数据，例如，在内存不足需要丢弃数据之前。
With push mode, one can prevent the overloading of resources at the Exporting Process by simply exporting the information as soon as certain thresholds are about to be exceeded. Therefore, exporting criteria are often related to traffic characteristics (e.g., Flow timeout) or resource limitations (e.g., size of Flow cache). However, traffic characteristics are usually quite dynamic and often impossible to predict. If they are used to trigger Flow export, the exporting rate and the resource consumption for Flow export becomes variable and unpredictable.
使用推送模式，只要在即将超过某些阈值时立即导出信息，就可以防止导出过程中资源过载。因此，导出标准通常与流量特征（例如，流超时）或资源限制（例如，流缓存的大小）相关。然而，交通特征通常是动态的，而且往往无法预测。如果它们用于触发流导出，则流导出的导出速率和资源消耗将变得可变且不可预测。
Pull mode has advantages if the trigger for data export is related to events at the Collecting Process (e.g., a specific application requests immediate input).
如果数据导出的触发器与采集过程中的事件相关（例如，特定应用程序请求立即输入），则Pull模式具有优势。
In a pull mode, a request could simply be forwarded to the Exporting Process. In a push mode, the exporting configuration must be changed to trigger the export of the requested data. Furthermore, with pull mode, one can prevent the overloading of the Collecting Process by the arrival of more records than it can process.
在拉模式下，请求可以简单地转发到导出进程。在推送模式下，必须更改导出配置以触发请求数据的导出。此外，使用pull模式，可以防止收集过程过载，因为到达的记录比它可以处理的要多。
Whether this is a relevant drawback depends on the flexibility of the IPFIX configuration and how IPFIX configuration rules are implemented.
这是否是一个相关的缺点取决于IPFIX配置的灵活性以及IPFIX配置规则的实现方式。
The IPFIX specification limits the different Template ID numbers that can be assigned to the newly generated Template records in an Observation Domain. In particular, Template IDs up to 255 are reserved for Template or option sets (or other sets to be created) and Template IDs from 256 to 65535 are assigned to data sets. In the case of many exports requiring many different Templates, the set of Template IDs could be exhausted.
IPFIX规范限制了可以分配给观察域中新生成的模板记录的不同模板ID号。特别是，为模板或选项集（或要创建的其他集）保留最多255个模板ID，并为数据集分配256到65535个模板ID。在许多导出需要许多不同模板的情况下，可能会耗尽模板ID集。
Although IPFIX does not explicitly state that Flows are unidirectional, Information Elements that describe Flow characteristics are defined only for one direction in [RFC5102]. [RFC5101] allows the reporting of multiple identical Information Elements in one Flow Record. With this, Information Elements for forward and reverse directions can be reported in one Flow Record.
虽然IPFIX没有明确说明流是单向的，但在[RFC5102]中，描述流特性的信息元素仅针对一个方向定义。[RFC5101]允许在一个流记录中报告多个相同的信息元素。这样，可以在一个流量记录中报告正向和反向的信息元素。
However, this is not sufficient. Using this feature for reporting bidirectional Flow information would require an agreement on the semantics of Information Elements (e.g., first counter is the counter for the forward direction, the second counter for the reverse direction).
然而，这是不够的。使用此功能报告双向流信息需要在信息元素的语义上达成一致（例如，第一个计数器为正向计数器，第二个计数器为反向计数器）。
Another option is to use two adjacent Flow Records to report both directions of a bidirectional Flow separately. This approach requires additional means for mapping those records and is quite inefficient due to the redundant reporting of Flow Keys.
另一种选择是使用两个相邻的流记录分别报告双向流的两个方向。这种方法需要额外的方法来映射这些记录，并且由于流键的冗余报告，效率非常低。
Remote configuration was initially out of scope of the IPFIX working group in order to concentrate on the protocol specification. Therefore, there is currently no standardized way to configure IPFIX processes remotely. Nevertheless, due to the broad need for this feature, it is quite likely that solutions for this will be standardized soon.
远程配置最初不在IPFIX工作组的范围内，以便集中于协议规范。因此，目前没有远程配置IPFIX进程的标准化方法。尽管如此，由于对该功能的广泛需求，很可能很快就会对该功能的解决方案进行标准化。
This document describes the usage of IPFIX in various scenarios. Security requirements for IPFIX target applications and security considerations for IPFIX are addressed in [RFC3917] and [RFC5101]. Those requirements have to be met for the usage of IPFIX for all scenarios described in this document. To our current knowledge, the usage scenarios proposed in Section 2 do not induce further security hazards.
本文档描述了IPFIX在各种场景中的使用。[RFC3917]和[RFC5101]介绍了IPFIX目标应用程序的安全要求和IPFIX的安全注意事项。对于本文档中描述的所有场景，IPFIX的使用必须满足这些要求。据我们目前所知，第2节中提出的使用场景不会导致进一步的安全危害。
The threat level to IPIFX itself may depend on the usage scenario of IPFIX. The usage of IPFIX for accounting or attack detection may increase the incentive to attack IPFIX itself. Nevertheless, security considerations have to be taken into account in all described scenarios.
IPIFX本身的威胁级别可能取决于IPFIX的使用场景。使用IPFIX进行计费或攻击检测可能会增加攻击IPFIX本身的动机。然而，在所有描述的场景中都必须考虑安全因素。
As described in the security considerations in [RFC5101], security incidents can become a threat to IPFIX processes themselves, even if IPIFX is not the target of the attack. If an attack generates a large amount of Flows (e.g., by sending packets with spoofed addresses or simulating Flow termination), Exporting and Collecting Processes may get overloaded by the immense amount of records that are exported. A flexible deployment of packet or Flow sampling methods can be useful to prevent the exhaustion of resources.
如[RFC5101]中的安全注意事项所述，即使IPIFX不是攻击的目标，安全事件也可能对IPFIX进程本身构成威胁。如果攻击生成大量流（例如，通过发送带有伪造地址的数据包或模拟流终止），导出和收集过程可能会因导出的大量记录而过载。灵活部署数据包或流采样方法有助于防止资源耗尽。
Section 3 of this document describes how IPFIX can be used in combination with other technologies. New security hazards can arise when two individually secure technologies or architectures are combined. For the combination of AAA with IPFIX, an application specific module (ASM) or an IPFIX Collector can function as a transit point for the messages. One has to ensure that at this point the applied security mechanisms (e.g., encryption of messages) are maintained.
本文档第3节介绍了IPFIX如何与其他技术结合使用。当两种单独的安全技术或体系结构结合在一起时，可能会出现新的安全隐患。对于AAA与IPFIX的组合，应用程序特定模块（ASM）或IPFIX收集器可以用作消息的传输点。必须确保在这一点上维护应用的安全机制（例如，消息加密）。
We would like to thank the following people for their contributions, discussions on the mailing list, and valuable comments:
我们要感谢以下人员的贡献、对邮件列表的讨论和宝贵意见：
Sebastian Zander Robert Loewe Reinaldo Penno Lutz Mark Andy Biermann
塞巴斯蒂安·赞德·罗伯特·洛维·雷纳尔多·佩诺·卢茨·马克·安迪·比尔曼
Part of the work has been developed in the research project 6QM, co-funded with support from the European Commission.
部分工作已在研究项目6QM中完成，该项目由欧盟委员会共同资助。
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005.
[RFC4148]Stephan，E.“IP性能度量（IPPM）度量注册表”，BCP 108，RFC 4148，2005年8月。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101]Claise，B.，Ed.，“交换IP流量信息的IP流量信息导出（IPFIX）协议规范”，RFC 5101，2008年1月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102]Quitek，J.，Bryant，S.，Claise，B.，Aitken，P.，和J.Meyer，“IP流信息导出的信息模型”，RFC 5102，2008年1月。
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5477]Dietz，T.，Claise，B.，Aitken，P.，Dressler，F.，和G.Carle，“数据包抽样出口的信息模型”，RFC 5477，2009年3月。
[Brow00] Brownlee, N., "Packet Matching for NeTraMet Distributions", <http://www.caida.org/tools/measurement/ netramet/packetmatching/>.
[Brow00]Brownlee，N.，“NeTraMet发行版的数据包匹配”<http://www.caida.org/tools/measurement/ netramet/packetmatching/>。
[DuGr00] Duffield, N. and M. Grossglauser, "Trajectory Sampling for Direct Traffic Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000.
[DuGr00]Duffield，N.和M.Grossglauser，“直接交通观测的轨迹采样”，ACM SIGCOMM 2000年会议记录，瑞典斯德哥尔摩，2000年8月28日至9月1日。
[GrDM98] Graham, I., Donnelly, S., Martin, S., Martens, J., and J. Cleary, "Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay Variation on the Internet", INET'98, Geneva, Switzerland, 21-24 July, 1998.
[GrDM98]Graham，I.，Donnelly，S.，Martin，S.，Martens，J.，和J.Cleary，“互联网上单向延迟和延迟变化的非侵入式精确测量”，INET'98，瑞士日内瓦，1998年7月21-24日。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向延迟度量”，RFC 2679，1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向数据包丢失度量”，RFC 2680，1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的往返延迟度量”，RFC 2681，1999年9月。
[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月。
[RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.
[RFC2720]布朗利，N.，“交通流量测量：仪表MIB”，RFC27201999年10月。
[RFC2722] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999.
[RFC2722]北布朗利、C.米尔斯和G.鲁斯，“交通流测量：体系结构”，RFC22721999年10月。
[RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and D. Spence, "Generic AAA Architecture", RFC 2903, August 2000.
[RFC2903]de Laat，C.，Gross，G.，Gommans，L.，Vollbrecht，J.，和D.Spence，“通用AAA架构”，RFC 2903，2000年8月。
[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月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330]IANA，“特殊用途IPv4地址”，RFC33302002年9月。
[RFC3334] Zseby, T., Zander, S., and C. Carle, "Policy-Based Accounting", RFC 3334, October 2002.
[RFC3334]Zseby，T.，Zander，S.和C.Carle，“基于政策的会计”，RFC 33342002年10月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393]Demichelis，C.和P.Chimento，“IP性能度量的IP数据包延迟变化度量（IPPM）”，RFC 3393，2002年11月。
[RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. Romascanu, "Introduction to the Remote Monitoring (RMON) Family of MIB Modules", RFC 3577, August 2003.
[RFC3577]Waldbusser，S.，Cole，R.，Kalbflish，C.，和D.Romascanu，“MIB模块远程监控（RMON）系列介绍”，RFC 3577，2003年8月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004.
[RFC3729]Waldbusser，S.，“应用程序性能度量MIB”，RFC 37292004年3月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（SCTP）部分可靠性扩展”，RFC 3758，2004年5月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917]Quitek，J.，Zseby，T.，Claise，B.，和S.Zander，“IP流信息导出（IPFIX）的要求”，RFC 39172004年10月。
[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005.
[RFC4150]Dietz，R.和R.Cole，“传输性能指标MIB”，RFC 4150，2005年8月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年9月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470]Sadasivan，G.，Brownlee，N.，Claise，B.，和J.Quitek，“IP流信息导出架构”，RFC 54702009年3月。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5475]Zseby，T.，Molina，M.，Duffield，N.，Niccolini，S.，和F.Raspall，“IP数据包选择的采样和过滤技术”，RFC 5475，2009年3月。
[RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476]Claise，B.，编辑，“数据包采样（PSAMP）协议规范”，RFC 54762009年3月。
[ZsZC01] Zseby, T., Zander, S., and G. Carle, "Evaluation of Building Blocks for Passive One-way-delay Measurements", Proceedings of Passive and Active Measurement Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001
[ZsZC01]Zseby，T.，Zander，S.，和G.Carle，“被动单向延迟测量的构件评估”，被动和主动测量研讨会论文集（PAM 2001），荷兰阿姆斯特丹，2001年4月23-24日
Authors' Addresses
作者地址
Tanja Zseby Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7153 EMail: tanja.zseby@fokus.fraunhofer.de
Tanja Zseby Fraunhofer开放通信系统研究所（FOKUS）Kaiserin Augusta Allee 31 10589德国柏林电话：+49 30 3463 7153电子邮件：Tanja。zseby@fokus.fraunhofer.de
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 6327057 EMail: elisa.boschi@hitachi-eu.com
Elisa Boschi Hitachi Europe转交ETH Zurich Gloriastrasse 35 8092苏黎世瑞士电话：+41 44 6327057电子邮件：Elisa。boschi@hitachi-欧盟网站
Nevil Brownlee CAIDA (UCSD/SDSC) 9500 Gilman Drive La Jolla, CA 92093-0505 Phone: +1 858 534 8338 EMail: nevil@caida.org
Nevil Brownlee CAIDA（UCSD/SDSC）加利福尼亚州拉荷亚吉尔曼大道9500号92093-0505电话：+1 858 534 8338电子邮件：nevil@caida.org
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 EMail: bclaise@cisco.com
Benoit Claise Cisco Systems，Inc.De Kleetlaan 6a b1 1831 Diegem比利时电话：+32 2 704 5622电子邮件：bclaise@cisco.com