Network Working Group S. Handelman
Request for Comments: 2724 S. Stibler
Category: Experimental IBM
N. Brownlee
The University of Auckland
G. Ruth
GTE Internetworking
October 1999
Network Working Group S. Handelman
Request for Comments: 2724 S. Stibler
Category: Experimental IBM
N. Brownlee
The University of Auckland
G. Ruth
GTE Internetworking
October 1999
RTFM: New Attributes for Traffic Flow Measurement
RTFM：交通流测量的新属性
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'. This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes.
RTFM流量测量体系结构为描述和测量网络流量提供了一个通用框架。流量根据其地址属性值定义，并由“流量表”测量。本文档讨论RTFM流及其可以具有的属性，以便通过添加新属性来提供扩展体系结构的逻辑框架。
Extensions described include Address Attributes such as DSCodePoint, SourceASN and DestASN, and Group Attributes such as short-term bit rates and turnaround times. Quality of Service parameters for Integrated Services are also discussed.
描述的扩展包括地址属性，如DSCodePoint、SourceASN和DestASN，以及组属性，如短期比特率和周转时间。还讨论了综合服务的服务质量参数。
Table of Contents
目录
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 RTFM's Definition of Flows . . . . . . . . . . . . . . . . 3
1.2 RTFM's Current Definition of Flows and their Attributes . . 3
1.3 RTFM Flows, Integrated Services, IPPM and Research in Flows 4
2 Flow Abstractions . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Meter Readers and Meters . . . . . . . . . . . . . . . . . 5
2.2 Attribute Types . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Packet Traces . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Aggregate Attributes . . . . . . . . . . . . . . . . . . . 8
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 RTFM's Definition of Flows . . . . . . . . . . . . . . . . 3
1.2 RTFM's Current Definition of Flows and their Attributes . . 3
1.3 RTFM Flows, Integrated Services, IPPM and Research in Flows 4
2 Flow Abstractions . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Meter Readers and Meters . . . . . . . . . . . . . . . . . 5
2.2 Attribute Types . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Packet Traces . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Aggregate Attributes . . . . . . . . . . . . . . . . . . . 8
2.5 Group Attributes . . . . . . . . . . . . . . . . . . . . . 8
2.6 Actions on Exceptions . . . . . . . . . . . . . . . . . . .10
3 Extensions to the 'Basic' RTFM Meter . . . . . . . . . . . . .10
3.1 Flow table extensions . . . . . . . . . . . . . . . . . . .10
3.2 Specifying Distributions in RuleSets . . . . . . . . . . .11
3.3 Reading Distributions . . . . . . . . . . . . . . . . . . .13
4 Extensions to the Rules Table, Attribute Numbers . . . . . . .13
5 Security Considerations . . . . . . . . . . . . . . . . . . . .15
6 References . . . . . . . . . . . . . . . . . . . . . . . . . .16
7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .17
8 Full Copyright Statement . . . . . . . . . . . . . . . . . . .18
2.5 Group Attributes . . . . . . . . . . . . . . . . . . . . . 8
2.6 Actions on Exceptions . . . . . . . . . . . . . . . . . . .10
3 Extensions to the 'Basic' RTFM Meter . . . . . . . . . . . . .10
3.1 Flow table extensions . . . . . . . . . . . . . . . . . . .10
3.2 Specifying Distributions in RuleSets . . . . . . . . . . .11
3.3 Reading Distributions . . . . . . . . . . . . . . . . . . .13
4 Extensions to the Rules Table, Attribute Numbers . . . . . . .13
5 Security Considerations . . . . . . . . . . . . . . . . . . . .15
6 References . . . . . . . . . . . . . . . . . . . . . . . . . .16
7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .17
8 Full Copyright Statement . . . . . . . . . . . . . . . . . . .18
1 Introduction
1导言
The Real-Time Flow Measurement (RTFM) Working Group (WG) has developed a system for measuring and reporting information about traffic flows in the Internet. This document explores the definition of extensions to the flow measurements as currently defined in [RTFM-ARC]. The new attributes described in this document will be useful for monitoring network performance and will expand the scope of RTFM beyond simple measurement of traffic volumes. A companion document to this memo will be written to define MIB structures for the new attributes.
实时流量测量（RTFM）工作组（WG）开发了一个用于测量和报告互联网流量信息的系统。本文件探讨了[RTFM-ARC]中当前定义的流量测量扩展的定义。本文档中描述的新属性将有助于监控网络性能，并将RTFM的范围扩展到流量的简单测量之外。本备忘录的附带文档将用于定义新属性的MIB结构。
This memo was started in 1996 to advance the work of the RTFM group. The goal of this work is to produce a simple set of abstractions, which can be easily implemented and at the same time enhance the value of RTFM Meters. This document also defines a method for organizing the flow abstractions to augment the existing RTFM flow table.
该备忘录始于1996年，旨在推进RTFM小组的工作。这项工作的目标是产生一个简单的抽象集，它可以很容易地实现，同时提高RTFM仪表的价值。本文档还定义了一种组织流抽象的方法，以扩充现有的RTFM流表。
Implementations of the RTFM Meter have been done by Nevil Brownlee in the University of Auckland, NZ, and Stephen Stibler and Sig Handelman at IBM in Hawthorne, NY, USA. The RTFM WG has also defined the role of the Meter Reader whose role is to retrieve flow data from the Meter.
RTFM测量仪的实现已经由NZ奥克兰大学的Nevil Brownlee和美国Hawthorne州NY的IBM公司的Stephen Stibler和SIG HANDELMAN完成。RTFM WG还定义了仪表读取器的作用，其作用是从仪表中检索流量数据。
Note on flows and positioning of meters:
关于流量计流量和定位的注释：
A flow as it traverses the Internet may have some of its characteristics altered as it travels through Routers, Switches, and other network units. It is important to note the spatial location of the Meter when referring to attributes of a flow. An example, a server may send a sequence of packets with a definite order, and inter packet timing with a leaky bucket algorithm. A meter reading downstream of the leaky bucket would record a set with minimal inter packet timing due to the leaky bucket. At the client's location, the packets may arrive out of sequence, with
当流通过路由器、交换机和其他网络单元时，它在互联网上的某些特性可能会发生改变。在提及流量属性时，注意流量计的空间位置非常重要。例如，服务器可以发送具有确定顺序的分组序列，并使用漏桶算法发送分组间定时。漏桶下游的电表读数将记录由于漏桶而具有最小分组间定时的集合。在客户端位置，数据包可能会无序到达，并且
the timings altered. A meter at the client's location would record different attributes for the same flow.
时间改变了。客户位置的仪表将记录同一流量的不同属性。
The RTFM Meter architecture views a flow as a set of packets between two endpoints (as defined by their source and destination attribute values and start and end times), and as BI-DIRECTIONAL (i.e. the meter effectively monitors two sub-flows, one in each direction).
RTFM流量计体系结构将流量视为两个端点之间的一组数据包（由其源和目标属性值以及开始和结束时间定义），并视为双向的（即流量计有效监控两个子流，每个方向一个子流）。
Reasons why RTFM flows are bi-directional:
RTFM流是双向的原因：
- The WG is interested in understanding the behavior of sessions between endpoints.
- 工作组感兴趣的是了解端点之间会话的行为。
- The endpoint attribute values (the "Address" and "Type" ones) are the same for both directions; storing them in bi-directional flows reduces the meter's memory demands.
- 端点属性值（“地址”和“类型”值）在两个方向上相同；将它们存储在双向流中可以减少仪表的内存需求。
- 'One-way' (uni-directional) flows are a degenerate case. Existing RTFM meters can handle this by using one of the computed attributes (e.g. FlowKind) to indicate direction.
- “单向”（单向）流是一种退化情况。现有的RTFM流量计可以通过使用一个计算属性（例如FlowKind）指示方向来处理此问题。
Flows, as described in the "Architecture" document [RTFM-ARC] have the following properties:
“体系结构”文档[RTFM-ARC]中描述的流具有以下属性：
a. They occur between two endpoints, specified as sets of attribute values in the meter's current rule set. A flow is completely identified by its set of endpoint attribute values.
a. 它们出现在两个端点之间，在仪表的当前规则集中指定为属性值集。流完全由其端点属性值集标识。
b. Each flow may also have values for "computed" attributes (Class and Kind). These are directly derived from the endpoint attribute values.
b. 每个流还可能具有“计算”属性（类和种类）的值。这些值直接来自端点属性值。
c. A new flow is created when a packet is to be counted that does not match the attributes of an existing flow. The meter records the time when this new flow is created.
c. 当要对与现有流的属性不匹配的数据包进行计数时，将创建一个新流。流量计记录创建新流量的时间。
d. Attribute values in (a), (b) and (c) are set when the meter sees the first packet for the flow, and are never changed.
d. （a）、（b）和（c）中的属性值是在仪表看到流的第一个数据包时设置的，并且永远不会更改。
e. Each flow has a "LastTime" attribute, which indicates the time the meter last saw a packet for the flow.
e. 每个流都有一个“LastTime”属性，该属性指示仪表最后一次看到流的数据包的时间。
f. Each flow has two packet and two byte counters, one for each flow direction (Forward and Backward). These are updated as packets for the flow are observed by the meter.
f. 每个流有两个数据包和两个字节计数器，每个流方向（向前和向后）一个。当流量计观察到流量数据包时，这些数据包被更新。
g. ALL the attributes have (more or less) the same meaning for a variety of protocols; IPX, AppleTalk, DECnet and CLNS as well as TCP/IP.
g. 对于各种协议，所有属性都具有（或多或少）相同的含义；IPX、AppleTalk、DECnet和CLNS以及TCP/IP。
Current flow attributes - as described above - fit very well into the SNMP data model. They are either static, or are continuously updated counters. They are NEVER reset. In this document they will be referred to as "old-style" attributes.
如上所述，当前流属性非常适合SNMP数据模型。它们要么是静态的，要么是不断更新的计数器。它们永远不会重置。在本文档中，它们将被称为“旧式”属性。
It is easy to add further "old-style" attributes, since they don't require any new features in the architecture. For example:
添加更多的“旧式”属性很容易，因为它们不需要体系结构中的任何新特性。例如：
- Count of the number of "lost" packets (determined by watching sequence number fields for packets in each direction; only available for protocols which have such sequence numbers).
- “丢失”数据包数量的计数（通过观察每个方向数据包的序列号字段确定；仅适用于具有此类序列号的协议）。
- In the future, RTFM could coordinate directly with the Flow Label from the IPv6 header.
- 将来，RTFM可以直接与来自IPv6报头的流标签协调。
The concept of flows has been studied in various different contexts. For the purpose of extending RTFM, a starting point is the work of the Integrated Services WG. We will measure quantities that are often set by Integrated Services configuration programs. We will look at the work of the Benchmarking/IP Performance Metrics Working Group, and also look at the work of Claffy, Braun and Polyzos [C-B-P]. We will demonstrate how RTFM can compute throughput, packet loss, and delays from flows.
流动的概念已经在不同的背景下进行了研究。为了扩展RTFM，一个起点是综合服务工作组的工作。我们将测量通常由集成服务配置程序设置的数量。我们将介绍基准测试/IP性能度量工作组的工作，以及Claffy、Braun和Polyzos[C-B-P]的工作。我们将演示RTFM如何计算流量的吞吐量、数据包丢失和延迟。
An example of the use of capacity and performance information is found in "The Use of RSVP with IETF Integrated Services" [IIS-RSVP]. RSVP's use of Integrated Services revolves around Token Bucket Rate, Token Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum Packet Size, and the Slack term. These are set by TSpec, ADspec and FLowspec (Integrated Services Keywords), and are used in configuration and operation of Integrated Services. RTFM could monitor explicitly Peak Data Rate, Minimum Policed Unit, Maximum Packet Size, and the Slack term. RTFM could infer details of the Token Bucket. The WG will develop measures to work with these service metrics. An initial implementation of IIS Monitoring has been developd at CEFRIEL in Italy [IIS-ACCT].
容量和性能信息的使用示例见“与IETF集成服务一起使用RSVP”[IIS-RSVP]。RSVP对综合服务的使用围绕令牌桶速率、令牌桶大小、峰值数据速率、最小策略单元、最大数据包大小和松弛项展开。这些由TSpec、ADspec和FLowspec（集成服务关键字）设置，用于集成服务的配置和操作。RTFM可以显式监控峰值数据速率、最小策略单元、最大数据包大小和松弛项。RTFM可以推断令牌桶的详细信息。工作组将制定措施来使用这些服务指标。意大利CEFRIEL已经开发了IIS监控的初步实现[IIS-ACCT]。
RTFM will work with several traffic measurements identified by IPPM [IPPM-FRM]. There are three broad areas in which RTFM is useful for IPPM.
RTFM将与IPPM[IPPM-FRM]确定的多个流量测量一起使用。RTFM在IPPM中有三个广泛的应用领域。
- An RTFM Meter could act as a passive device, gathering traffic and performance statistics at appropriate places in networks (server or client locations).
- RTFM电表可以充当被动设备，在网络中的适当位置（服务器或客户端位置）收集流量和性能统计数据。
- RTFM could give detailed analyses of IPPM test flows that pass through the Network segment that RTFM is monitoring.
- RTFM可以对通过RTFM监控的网段的IPPM测试流进行详细分析。
- RTFM could be used to identify the most-used paths in a network mesh, so that detailed IPPM work could be applied to these most used paths.
- RTFM可用于识别网络网格中最常用的路径，以便详细的IPPM工作可应用于这些最常用的路径。
2 Flow Abstractions
2流抽象
Performance attributes include throughput, packet loss, delays, jitter, and congestion measures. RTFM will calculate these attributes in the form of extensions to the RTFM flow attributes according to three general classes:
性能属性包括吞吐量、数据包丢失、延迟、抖动和拥塞度量。RTFM将根据三个通用类，以RTFM流属性扩展的形式计算这些属性：
- 'Trace', attributes of individual packets in a flow or a segment of a flow (e.g. last packet size, last packet arrival time).
- “跟踪”，流或流段中单个数据包的属性（例如，最后一个数据包大小、最后一个数据包到达时间）。
- 'Aggregate', attributes derived from the flow taken as a whole (e.g. mean rate, max packet size, packet size distribution).
- “聚合”，从作为一个整体的流派生的属性（例如，平均速率、最大数据包大小、数据包大小分布）。
- 'Group', attributes that depend on groups of packet values within the flow (e.g. inter-arrival times, short-term traffic rates).
- “组”，取决于流中分组值组的属性（例如，到达时间间隔、短期流量率）。
Note that attributes within each of these classes may have various types of values - numbers, distributions, time series, and so on.
请注意，这些类中的每个属性都可能具有各种类型的值—数字、分布、时间序列等等。
A note on the relation between Meter Readers and Meters.
关于仪表读数器与仪表之间关系的注记。
Several of the measurements enumerated below can be implemented by a Meter Reader that is tied to a meter with very short response time and very high bandwidth. If the Meter Reader and Meter can be arranged in such a way, RTFM could collect Packet Traces with time stamps and provide them directly to the Meter Reader for further processing.
下面列举的几种测量可以通过与响应时间非常短、带宽非常高的仪表相连的仪表读取器来实现。如果抄表器和抄表器可以这样布置，RTFM可以收集带有时间戳的数据包跟踪，并将它们直接提供给抄表器进行进一步处理。
A more useful alternative is to have the Meter calculate some flow statistics locally. This allows a looser coupling between the Meter and Meter Reader. RTFM will monitor an 'extended attribute' depending upon settings in its Rule table. RTFM will not create any "extended attribute" data without explicit instructions in the Rule table.
一个更有用的替代方法是让流量计在本地计算一些流量统计数据。这使得仪表和仪表读数器之间的耦合更加松散。RTFM将根据其规则表中的设置监视“扩展属性”。如果规则表中没有明确的说明，RTFM将不会创建任何“扩展属性”数据。
Section 2 described three different classes of attributes; this section considers the "data types" of these attributes.
第2节描述了三类不同的属性；本节考虑这些属性的“数据类型”。
Packet Traces (as described below) are a special case in that they are tables with each row containing a sequence of values, each of varying type. They are essentially 'compound objects' i.e. lists of attribute values for a string of packets.
数据包跟踪（如下所述）是一种特殊情况，因为它们是表，每行包含一系列不同类型的值。它们本质上是“复合对象”，即数据包字符串的属性值列表。
Aggregate attributes are like the 'old-style' attributes. Their types are:
聚合属性类似于“旧式”属性。它们的类型是：
- Addresses, represented as byte strings (1 to 20 bytes long)
- 地址，以字节字符串表示（1到20字节长）
- Counters, represented as 64-bit unsigned integers
- 计数器，表示为64位无符号整数
- Times, represented as 32-bit unsigned integers
- 时间，表示为32位无符号整数
Addresses are saved when the first packet of a flow is observed. They do not change with time, and they are used as a key to find the flow's entry in the meter's flow table.
当观察到流的第一个数据包时，会保存地址。它们不会随时间而改变，并用作在流量计流量表中查找流量条目的键。
Counters are incremented for each packet, and are never reset. An analysis application can compute differences between readings of the counters, so as to determine rates for these attributes. For example, if we read flow data at five-minute intervals, we can calculate five-minute packet and byte rates for the flow's two directions.
每个数据包的计数器都会递增，并且永远不会重置。分析应用程序可以计算计数器读数之间的差异，从而确定这些属性的速率。例如，如果我们以五分钟的间隔读取流数据，我们可以计算流的两个方向的五分钟数据包和字节速率。
Times are derived from the FirstTime for a flow, which is set when its first packet is observed. LastTime is updated as each packet in the flow is observed.
时间是从流的FirstTime派生的，它是在观察到流的第一个数据包时设置的。LastTime在观察流中的每个数据包时更新。
All the above types have the common feature that they are expressed as single values. At least some of the new attributes will require multiple values. If, for example, we are interested in inter-packet time intervals, we can compute an interval for every packet after the first. If we are interested in packet sizes, a new value is obtained as each packet arrives. When it comes to storing this data we have two options:
以上所有类型都有一个共同特征，即它们都表示为单个值。至少一些新属性需要多个值。例如，如果我们对包间时间间隔感兴趣，那么我们可以计算第一个包之后每个包的时间间隔。如果我们对数据包大小感兴趣，则在每个数据包到达时会获得一个新值。在存储这些数据时，我们有两种选择：
- As a distribution, i.e. in an array of 'buckets'. This method is a compact representation of the data, with the values being stored as counters between a minimum and maximum, with defined steps in each bucket. This fits the RTFM goal of compact data storage.
- 作为一个分布，即在一个“桶”数组中。此方法是数据的紧凑表示，将值存储为介于最小值和最大值之间的计数器，并在每个存储桶中定义步骤。这符合RTFM压缩数据存储的目标。
- As a sequence of single values. This saves all the information, but does not fit well with the RTFM goal of doing as much data reduction as possible within the meter.
- 作为单个值的序列。这保存了所有信息，但与RTFM在仪表内尽可能多地减少数据的目标不太相符。
Studies which would be limited by the use of distributions might well use packet traces instead.
受分布使用限制的研究可能会改用包跟踪。
A method for specifying the distribution parameters, and for encoding the distribution so that it can be easily read, is described in section 3.2.
第3.2节描述了指定分布参数和对分布进行编码以便于读取的方法。
The simplest way of collecting a trace in the meter would be to have a new attribute called, say, "PacketTrace". This could be a table, with a column for each property of interest. For example, one could trace:
在仪表中收集跟踪的最简单方法是使用一个名为“PacketTrace”的新属性。这可以是一个表，每个感兴趣的属性都有一列。例如，可以跟踪：
- Packet Arrival time (TimeTicks from sysUpTime, or microseconds from FirstTime for the flow).
- 数据包到达时间（sysUpTime的时间刻度，或流的FirstTime的微秒）。
- Packet Direction (Forward or Backward)
- 数据包方向（向前或向后）
- Packet Sequence number (for protocols with sequence numbers)
- 数据包序列号（对于具有序列号的协议）
- Packet Flags (for TCP at least)
- 数据包标志（至少适用于TCP）
Note: The following implementation proposal is for the user who is familiar with the writing of rule sets for the RTFM Meter.
注：以下实施方案适用于熟悉RTFM电表规则集编写的用户。
To add a row to the table, we only need a rule which PushPkts the PacketTrace attribute. To use this, one would write a rule set which selected out a small number of flows of interest, with a 'PushPkt PacketTrace' rule for each of them. A MaxTraceRows default value of 2000 would be enough to allow a Meter Reader to read one-second ping traces every 10 minutes or so. More realistically, a MaxTraceRows of 500 would be enough for one-minute pings, read once each hour.
要向表中添加行，我们只需要一个PushPkts PacketTrace属性的规则。要使用它，可以编写一个规则集，其中选择了少量感兴趣的流，每个流都有一个“PushPkt PacketTrace”规则。MaxTraceRows的默认值为2000足以允许仪表读取器每隔10分钟左右读取一秒钟的ping记录道。更现实地说，MaxTraceRows为500就足够进行一分钟的ping，每小时读取一次。
Packet traces are already implemented by the RMON MIB [RMON-MIB, RMON2-MIB], in the Packet Capture Group. They are therefore a low priority for RTFM.
数据包跟踪已经由数据包捕获组中的RMON MIB[RMON-MIB，RMON2-MIB]实现。因此，它们是RTFM的低优先级。
RTFM's "old-style" flow attributes count the bytes and packets for packets which match the rule set for an individual flow. In addition to these totals, for example, RTFM could calculate Packet Size statistics. This data can be stored as distributions, though it may sometimes be sufficient to simply keep a maximum value.
RTFM的“旧式”流属性统计与单个流的规则集相匹配的数据包的字节和数据包。例如，除了这些总数之外，RTFM还可以计算数据包大小统计数据。这些数据可以存储为分布，尽管有时仅保留一个最大值就足够了。
As an example, consider Packet Size. RTFM's packet flows can be examined to determine the maximum packet size found in a flow. This will give the Network Operator an indication of the MTU being used in a flow. It will also give an indication of the sensitivity to loss of a flow, for losing large packets causes more data to be retransmitted.
作为一个例子，考虑数据包大小。可以检查RTFM的数据包流，以确定流中的最大数据包大小。这将向网络运营商提供流中使用的MTU的指示。它还将指示流丢失的敏感性，因为丢失大数据包会导致更多数据被重新传输。
Note that aggregate attributes are a simple extension of the 'old-style' attributes; their values are never reset. For example, an array of counters could hold a 'packet size' distribution. The counters continue to increase, a meter reader will collect their values at regular intervals, and an analysis application will compute and display distributions of the packet size for each collection interval.
请注意，聚合属性是“旧式”属性的简单扩展；它们的值永远不会重置。例如，计数器数组可以保存“数据包大小”分布。计数器继续增加，抄表器将定期收集其值，分析应用程序将计算并显示每个收集间隔的数据包大小分布。
The notion of group attributes is to keep simple statistics for measures that involve more than one packet. This section describes some group attributes which it is feasible to implement in a traffic meter, and which seem interesting and useful.
组属性的概念是为涉及多个数据包的度量保留简单的统计信息。本节描述了一些组属性，这些属性可以在交通量表中实现，并且看起来很有趣和有用。
Short-term bit rate - The data could also be recorded as the maximum and minimum data rate of the flow, found over specific time periods during the lifetime of a flow; this is a special kind of 'distribution'. Bit rate could be used to define the throughput of a flow, and if the RTFM flow is defined to be the sum of all traffic in a network, one can find the throughput of the network.
短期比特率-数据还可以记录为流的最大和最小数据速率，在流的生命周期内的特定时间段内发现；这是一种特殊的“分布”。比特率可用于定义流的吞吐量，如果RTFM流定义为网络中所有流量的总和，则可以找到网络的吞吐量。
If we are interested in '10-second' forward data rates, the meter might compute this for each flow of interest as follows:
如果我们对“10秒”远期数据速率感兴趣，流量计可能会对每个感兴趣的流量进行如下计算：
- maintain an array of counters to hold the flow's 10-second data rate distribution.
- 维护一个计数器数组以保存流的10秒数据速率分布。
- every 10 seconds, compute and save 10-second octet count, and save a copy of the flow's forward octet counter.
- 每隔10秒，计算并保存10秒的八位字节计数，并保存流的前向八位字节计数器的副本。
To achieve this, the meter will have to keep a list of aggregate flows and the intervals at which they require processing. Careful programming is needed to achieve this, but provided the meter is not asked to do it for very large numbers of flows, it has been successfully implemented.
为了实现这一点，流量计必须保存一份总流量列表以及需要处理的时间间隔。要实现这一点，需要仔细编程，但如果不要求流量计对大量流量进行编程，则已成功实现。
Inter-arrival times. The Meter knows the time that it encounters each individual packet. Statistics can be kept to record the inter-arrival times of the packets, which would give an indication of the jitter found in the Flow.
到达时间。仪表知道它遇到每个数据包的时间。可以保存统计信息来记录数据包的到达时间，这将指示流中发现的抖动。
Turn-around statistics. Sine the Meter knows the time that it encounters each individual packet, it can produce statistics of the time intervals between packets in opposite directions are observed on the network. For protocols such as SNMP (where every packet elicits an answering packet) this gives a good indication of turn-around times.
扭转统计数字。只要仪表知道它遇到每个数据包的时间，它就可以统计网络上观察到的相反方向的数据包之间的时间间隔。对于SNMP等协议（其中每个数据包引出一个应答数据包），这很好地指示了周转时间。
Subflow analysis. Since the choice of flow endpoints is controlled by the meter's rule set, it is easy to define an aggregate flow, e.g. "all the TCP streams between hosts A and B." Preliminary implementation work suggests that - at least for this case - it should be possible for the meter to maintain a table of information about all the active streams. This could be used to produce at least the following attributes:
亚流分析。由于流端点的选择由仪表的规则集控制，因此很容易定义聚合流，例如“主机A和B之间的所有TCP流”。初步实施工作表明，至少在这种情况下，仪表应该可以维护一个关于所有活动流的信息表。这可用于产生至少以下属性：
- Number of streams, e.g. streams active for n-second intervals. Determined for TCP and UDP using source-dest port number pairs.
- 流的数量，例如n秒间隔内活动的流。使用源目标端口号对为TCP和UDP确定。
- Number of TCP bytes, determined by taking difference of TCP sequence numbers for each direction of the aggreagate flow.
- TCP字节数，由聚集流每个方向的TCP序列号差值决定。
IIS attributes. Work at CEFRIEL [IIS-ACCT] has produced a traffic meter with a rule set modified 'on the fly' so as to maintain a list of RSVP-reserved flows. For such flows the following attributes have been implemented (these quantities are defined in [GUAR-QOS]):
IIS属性。CEFRIEL[IIS-ACCT]的工作制作了一个流量表，其中一个规则集修改为“动态”，以便维护RSVP保留流的列表。对于此类流，已实现以下属性（这些数量在[GUAR-QOS]中定义）：
- QoSService: Service class for the flow (guaranteed, controlled load) - QoSStyle: Reservation setup style (wildcard filter, fixed filter, shared explicit) - QoSRate: [byte/s] rate for flows with guaranteed service - QoSSlackTerm: [microseconds] Slack Term QoS parameter for flows with guaranteed service - QoSTokenBucketRate: [byte/s] Token Bucket Rate QoS parameter for flows with guaranteed or controlled load service
- QoSService：流的服务类（保证的、受控的负载）-QoSStyle:保留设置样式（通配符筛选器、固定筛选器、共享显式）-QoSRate:[字节/秒]具有保证服务的流的速率-QoSSlackTerm:[微秒]具有保证服务的流的松弛项QoS参数-QoSTokenBucketRate:[字节/秒]具有保证或控制负载服务的流的令牌桶速率QoS参数
The following are also being considered:
还正在考虑下列事项：
- QoSTokenBucketSize: [byte] Size of Token Bucket
- QoSTokenBucketSize:[字节]令牌桶的大小
- QoSPeakDataRate: [byte/s] Maximum rate for incoming data
- QoSPeakDataRate:[字节/秒]传入数据的最大速率
- QoSMinPolicedUnit: [byte] IP datagrams less than this are counted as being this size - QoSMaxDatagramSize: [byte] Size of biggest datagram which conforms to the traffic specification 2.6 Actions on Exceptions
-Qosimpolicedunit:[byte]小于此值的IP数据报被视为此大小-QoSMaxDatagramSize:[byte]符合流量规范2.6异常操作的最大数据报的大小
Some users of RTFM have requested the ability to mark flows as having High Watermarks. The existence of abnormal service conditions, such as non-ending flow, a flow that exceeds a given limit in traffic (e.g. a flow that is exhausting the capacity of the line that carries it) would cause an ALERT to be sent to the Meter Reader for forwarding to the Manager. Operations Support could define service situations in many different environments. This is an area for further discussion on Alert and Trap handling.
RTFM的一些用户要求能够将流标记为具有高水印。异常运行条件的存在，例如非终止流量、超过给定流量限制的流量（例如，正在耗尽承载该流量的线路容量的流量）将导致向抄表器发送警报，以转发给管理器。操作支持可以定义许多不同环境中的服务情况。这是关于警报和陷阱处理的进一步讨论领域。
3 Extensions to the 'Basic' RTFM Meter
“基本”RTFM电表的3个扩展
The Working Group has agreed that the basic RTFM Meter will not be altered by the addition of the new attributes of this document. This section describes the extensions needed to implement the new attributes.
工作组同意，基本RTFM电表不会因添加本文件的新属性而改变。本节介绍实现新属性所需的扩展。
The architecture of RTFM has defined the structure of flows, and this memo does not change that structure. The flow table could have ancillary tables called "Distribution Tables" and "Trace Tables,"
RTFM的体系结构定义了流的结构，本备忘录不会改变该结构。流量表可以有称为“分布表”和“跟踪表”的辅助表
these would contain rows of values and or actions as defined above. Each entry in these tables would be marked with the number of its corresponding flow in the RTFM flow table.
这些将包含上面定义的值行和/或操作行。这些表中的每个条目都将在RTFM流量表中标记相应流量的编号。
Note: The following section is for the user who is familiar with the writing of rule sets for the RTFM Meter.
注：以下部分适用于熟悉RTFM仪表规则集编写的用户。
In order to identify the data in a Packet Flow Table, the attribute name could be pushed into a string at the head of each row. For example, if a table entry has "To Bit Rate" for a particular flow, the "ToBitRate" string would be found at the head of the row. (An alternative method would be to code an identification value for each extended attribute and push that value into the head of the row.) See section 4. for an inital set of ten extended flow attributes.
为了识别数据包流表中的数据，可以将属性名推入每行开头的字符串中。例如，如果一个表条目对特定流具有“To比特率”，那么“ToBitRate”字符串将位于行的开头。（另一种方法是为每个扩展属性编码一个标识值，并将该值推送到行首。）参见第4节。对于包含十个扩展流属性的初始集。
At first sight it would seem neccessary to add extra features to the RTFM Meter architecture to support distributions. This, however, is not neccessarily the case.
乍一看，似乎有必要为RTFM仪表体系结构添加额外的功能，以支持发行版。然而，情况并非必然如此。
What is actually needed is a way to specify, in a ruleset, the distribution parameters. These include the number of counters, the lower and upper bounds of the distribution, whether it is linear or logarithmic, and any other details (e.g. the time interval for short-term rate attributes).
实际上需要的是一种在规则集中指定分布参数的方法。其中包括计数器的数量、分布的上下限（线性或对数）以及任何其他细节（例如短期利率属性的时间间隔）。
Any attribute which is distribution-valued needs to be allocated a RuleAttributeNumber value. These will be chosen so as to extend the list already in the RTFM Meter MIB document [RTFM-MIB].
任何具有分布值的属性都需要分配RuleAttributeEnumber值。这些将被选择，以便扩展RTFM仪表MIB文档[RTFM-MIB]中已有的列表。
Since distribution attributes are multi-valued it does not make sense to test them. This means that a PushPkt (or PushPkttoAct) action must be executed to add a new value to the distribution. The old-style attributes use the 'mask' field to specify which bits of the value are required, but again, this is not the case for distributions. Lastly, the MatchedValue ('value') field of a PushPkt rule is never used. Overall, therefore, the 'mask' and 'value' fields in the PushPkt rule are available to specify distribution parameters.
因为分布属性是多值的，所以测试它们是没有意义的。这意味着必须执行PushPkt（或PushPkttoAct）操作才能向分发添加新值。旧式属性使用“mask”字段来指定需要哪些位的值，但同样，对于分布，情况并非如此。最后，PushPkt规则的MatchedValue（'value'）字段从未使用过。因此，总体而言，PushPkt规则中的“掩码”和“值”字段可用于指定分布参数。
Both these fields are at least six bytes long, the size of a MAC address. All we have to do is specify how these bytes should be used! As a starting point, the following is proposed (bytes are numbered left-to-right.
这两个字段的长度至少为6字节，相当于MAC地址的大小。我们所要做的就是指定如何使用这些字节！作为起点，提出以下建议（字节从左到右编号）。
Mask bytes: 1 Transform 1 = linear, 2 = logarithmic 2 Scale Factor Power of 10 multiplier for Limits and Counts 3-4 Lower Limit Highest value for first bucket 5-6 Upper Limit Highest value for last bucket
掩码字节：1变换1=线性，2=对数2比例因子10乘法器的幂极限，并计数3-4第一个存储桶的下限最高值5-6最后一个存储桶的上限最高值
Value bytes: 1 Buckets Number of buckets. Does not include the 'overflow' bucket 2 Parameter-1 } Parameter use depends 3-4 Parameter-2 } on distribution-valued 5-6 Parameter-3 } attribute
值字节：1个存储桶存储桶的数量。不包括'overflow'bucket 2参数-1}参数使用依赖于3-4参数-2}分布值5-6参数-3}属性
For example, experiments with NeTraMet have used the following rules:
例如，NeTraMet的实验使用了以下规则：
FromPacketSize & 1.0.25!1500 = 60.0!0: PushPkttoAct, Next;
FromPacketSize & 1.0.25!1500 = 60.0!0: PushPkttoAct, Next;
ToInterArrivalTime & 2.3.1!1800 = 60.0.0!0: PushPkttoAct, Next;
ToInterArrivalTime & 2.3.1!1800 = 60.0.0!0: PushPkttoAct, Next;
FromBitRate & 2.3.1!10000 = 60.5.0!0: PushPkttoAct, Next;
FromBitRate & 2.3.1!10000 = 60.5.0!0: PushPkttoAct, Next;
In these mask and value fields a dot indicates that the preceding number is a one-byte integer, the exclamation marks indicate that the preceding number is a two-byte integer, and the last number is two bytes wide since this was the width of the preceding field. (Note that this convention follows that for IP addresses - 130.216 means 130.216.0.0).
在这些掩码和值字段中，一个点表示前面的数字是一个单字节整数，感叹号表示前面的数字是一个双字节整数，最后一个数字是两个字节宽，因为这是前面字段的宽度。（请注意，此约定遵循IP地址的约定-130.216表示130.216.0.0）。
The first rule specifies that a distribution of packet sizes is to be built. It uses an array of 60 buckets, storing values from 1 to 1500 bytes (i.e. linear steps of 25 bytes each bucket). Any packets with size greater than 1500 will be counted in the 'overflow' bucket, hence there are 61 counters for the distribution.
第一条规则指定要构建数据包大小的分布。它使用60个存储桶的数组，存储1到1500字节的值（即每个存储桶25字节的线性步长）。任何大小大于1500的数据包都将计入“溢出”存储桶中，因此分发有61个计数器。
The second rule specifies an interarrival-time distribution, using a logarithmic scale for an array of 60 counters (and an overflow bucket) for rates from 1 ms to 1.8 s. Arrival times are measured in microseconds, hence the scale factor of 3 indicates that the limits are given in milliseconds.
第二条规则指定到达间隔时间分布，使用对数刻度表示60个计数器（和溢出桶）的数组，速率为1 ms到1.8 s。到达时间以微秒为单位，因此比例因子3表示限值以毫秒为单位。
The third rule specifies a bit-rate distribution, with the rate being calculated every 5 seconds (parameter 1). A logarithmic array of 60 counters (and an overflow bucket) are used for rates from 1 kbps to 10 Mbps. The scale factor of 3 indicates that the limits are given in thousands of bits per second (rates are measured in bps).
第三条规则指定比特率分布，速率每5秒计算一次（参数1）。60个计数器的对数数组（和一个溢出桶）用于1 kbps到10 Mbps的速率。比例因子3表示限制以每秒数千位为单位（速率以bps为单位）。
These distribution parameters will need to be stored in the meter so that they are available for building the distribution. They will also need to be read from the meter and saved together with the other flow data.
这些分布参数需要存储在仪表中，以便可用于构建分布。它们还需要从流量计中读取，并与其他流量数据一起保存。
Since RTFM flows are bi-directional, each distribution-valued quantity (e.g. packet size, bit rate, etc.) will actually need two sets of counters, one for packets travelling in each direction. It is tempting to regard these as components of a single 'distribution', but in many cases only one of the two directions will be of interest; it seems better to keep them in separate distributions. This is similar to the old-style counter-valued attributes such as toOctets and fromOctets.
由于RTFM流是双向的，每个分布值数量（例如，数据包大小、比特率等）实际上需要两组计数器，一组用于在每个方向上移动的数据包。人们很容易将其视为单一“分布”的组成部分，但在许多情况下，这两个方向中只有一个值得关注；似乎最好将它们保存在单独的分布中。这类似于老式的计数器值属性，如toOctets和fromOctets。
A distribution should be read by a meter reader as a single, structured object. The components of a distribution object are:
仪表读数器应将分布作为单个结构化对象读取。分发对象的组件包括：
- 'mask' and 'value' fields from the rule which created the distribution
- 创建分发的规则中的“掩码”和“值”字段
- sequence of counters ('buckets' + overflow)
- 计数器序列（'存储桶'+溢出）
These can be easily collected into a BER-encoded octet string, and would be read and referred to as a 'distribution'.
这些数据可以很容易地收集到一个BER编码的八位字节字符串中，然后被读取并称为“分布”。
4 Extensions to the Rules Table, Attribute Numbers
规则表的4个扩展，属性编号
The Rules Table of "old-style" attributes will be extended for the new flow types. A list of actions, and keywords, such as "ToBitRate", "ToPacketSize", etc. will be developed and used to inform an RTFM meter to collect a set of extended values for a particular flow (or set of flows).
“旧样式”属性的规则表将针对新的流类型进行扩展。将制定一份行动列表和关键词，如“ToBitRate”、“ToPacketSize”等，并用于通知RTFM流量计收集特定流量（或一组流量）的一组扩展值。
Note: An implementation suggestion.
注：实施建议。
Value 65 is used for 'Distributions', which has one bit set for each distribution-valued attribute present for the flow, using bit 0 for attribute 66, bit 1 for attribute 67, etc.
值65用于“分布”，它为流中存在的每个分布值属性设置了一个位，为属性66使用位0，为属性67使用位1，等等。
Here are ten possible distribution-valued attributes numbered according to RTFM WG consensus at the 1997 meeting in Munich:
以下是根据1997年慕尼黑会议上RTFM工作组的共识编号的十个可能的分布值属性：
ToPacketSize(66) size of PDUs in bytes (i.e. number FromPacketSize(67) of bytes actually transmitted)
ToPacketSize（66）以字节为单位的PDU大小（即实际传输的字节数FromPacketSize（67））
ToInterarrivalTime(68) microseconds between successive packets FromInterarrivalTime(69) travelling in the same direction
从间隔时间（69）到沿同一方向移动的连续数据包之间的间隔时间（68）微秒
ToTurnaroundTime(70) microseconds between successive packets FromTurnaroundTime(71) travelling in opposite directions
从周转时间（71）到反向运行的连续数据包之间的周转时间（70）微秒
ToBitRate(72) short-term flow rate in bits per second FromBitRate(73) Parameter 1 = rate interval in seconds
ToBitRate（72）从BitRate（73）参数1开始的以比特/秒为单位的短期流量=以秒为单位的速率间隔
ToPDURate(74) short-term flow rate in PDUs per second FromPDURate(75) Parameter 1 = rate interval in seconds
ToPDURate（74）Pdurate（75）参数1=以秒为单位的速率间隔的短期流速（以Pdurate/s为单位）
(76 .. 97) other distributions
（76..97）其他分配
It seems reasonable to allocate a further group of numbers for the IIS attributes described above:
为上述IIS属性再分配一组数字似乎是合理的：
QoSService(98) QoSStyle(99) QoSRate(100) QoSSlackTerm(101) QoSTokenBucketRate(102) QoSTokenBucketSize(103) QoSPeakDataRate(104) QoSMinPolicedUnit(105) QoSMaxPolicedUnit(106)
Qoservice（98）QoSStyle（99）QoSRate（100）Qoslackterm（101）QoSTokenBucketRate（102）QoSTokenBucketSize（103）QoSPeakDataRate（104）QosimpolicedUnit（105）QossmapolicedUnit（106）
The following attributes have also been implemented in NetFlowMet, a version of the RTFM traffic meter:
以下属性也已在NetFlowMet（RTFM流量表的一个版本）中实现：
MeterID(112) Integer identifying the router producing NetFlow data (needed when NetFlowMet takes data from several routers) SourceASN(113) Autonomous System Number for flow's source SourcePrefix(114) CIDR width used by router for determining flow's source network DestASN(115) Autonomous System Number for flow's destination DestPrefix(116) CIDR width used by router for determining flow's destination network
MeterID（112）标识生成NetFlow数据的路由器的整数（NetFlowMet从多个路由器获取数据时需要）SourceASN（113）流的源源前缀的自治系统号（114）路由器用于确定流的源网络DestASN（115）流的目的地destprifix（116）的CIDR宽度路由器用于确定流的目标网络的CIDR宽度
Some of the above, e.g. SourceASN and DestASN, might sensibly be allocated attribute numbers below 64, making them part of the 'base' RTFM meter attributes.
上述部分，例如SourceASN和DestASN，可能会合理地分配到64以下的属性号，使其成为“基本”RTFM仪表属性的一部分。
To support use of the RTFM meter as an 'Edge Device' for implementing Differentiated Services, and/or for metering traffic carried via such services, one more attribute will be useful:
为了支持将RTFM电表用作“边缘设备”以实现差异化服务和/或计量通过此类服务承载的流量，还有一个属性很有用：
DSCodePoint(118) DS Code Point (6 bits) for packets in this flow
DSCodePoint（118）此流中数据包的DS代码点（6位）
Since the DS Code Point is a single field within a packet's IP header, it is not possible to have both Source- and Dest-CodePoint attributes. Possible uses of DSCodePoint include aggregating flows using the same Code Points, and separating flows having the same end-point addresses but using different Code Points.
由于DS代码点是数据包IP报头中的单个字段，因此不可能同时具有源代码点和目的代码点属性。DSCodePoint的可能用途包括使用相同的代码点聚合流，以及分离具有相同端点地址但使用不同代码点的流。
5 Security Considerations
5安全考虑
The attributes considered in this document represent properties of traffic flows; they do not present any security issues in themselves. The attributes may, however, be used in measuring the behaviour of traffic flows, and the collected traffic flow data could be of considerable value. Suitable precautions should be taken to keep such data safe.
本文件中考虑的属性代表交通流的属性；它们本身不存在任何安全问题。然而，这些属性可用于测量交通流的行为，收集的交通流数据可能具有相当大的价值。应采取适当的预防措施以确保此类数据的安全。
6 References
6参考文献
[C-B-P] Claffy, K., Braun, H-W, Polyzos, G., "A Parameterizable Methodology for Internet Traffic Flow Profiling," IEEE Journal on Selected Areas in Communications, Vol. 13, No. 8, October 1995.
[C-B-P]Claffy，K.，Braun，H-W，Polyzos，G.，“互联网流量分析的可参数化方法”，IEEE通信选定领域杂志，第13卷，第8期，1995年10月。
[GUAR-QOS] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[GUAR-QOS]Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[IIS-ACCT] Maiocchi, S: "NeTraMet & NeMaC for IIS Accounting:
Users' Guide", CEFRIEL, Milan, 5 May 1998. (See also
http://www.cefriel.it/ntw)
[IIS-ACCT] Maiocchi, S: "NeTraMet & NeMaC for IIS Accounting:
Users' Guide", CEFRIEL, Milan, 5 May 1998. (See also
http://www.cefriel.it/ntw)
[IIS-RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[IIS-RSVP]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[IPPM-FRM] Paxson, V., Almes, G., Mahdavi, J. and Mathis, M., "Framework for IP Performance Metrics", RFC 2330, May 1998.
[IPPM-FRM]Paxson，V.，Almes，G.，Mahdavi，J.和Mathis，M.，“IP性能度量框架”，RFC 2330，1998年5月。
[RMON-MIB] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 1757, February 1995.
[RMON-MIB]Waldbusser，S.，“远程网络监控管理信息库”，RFC 1757，1995年2月。
[RMON2-MIB] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997.
[RMON2-MIB]Waldbusser，S.，“使用SMIv2的远程网络监控管理信息库版本2”，RFC 2021，1997年1月。
[RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999.
[RTFM-ARC]Brownlee，N.，Mills，C.和G.Ruth，“交通流测量：架构”，RFC2721999年10月。
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.
[RTFM-MIB]北布朗利，“交通流量测量：米MIB”，RFC2720，1999年10月。
7 Authors' Addresses
7作者地址
Sig Handelman IBM Research Division T.J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598
Sig Handelman IBM研究部T.J.Watson研究中心纽约约克敦高地704号信箱，邮编10598
Phone: +1 914 784 7626
EMail: swhandel@us.ibm.com
Phone: +1 914 784 7626
EMail: swhandel@us.ibm.com
Stephen Stibler IBM Research Division T.J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598
Stephen Stibler IBM研究部T.J.Watson研究中心纽约约克敦高地704号邮政信箱10598
Phone: +1 914 784 7191
EMail: stibler@us.ibm.com
Phone: +1 914 784 7191
EMail: stibler@us.ibm.com
Nevil Brownlee Information Technology Systems & Services The University of Auckland Private Bag 92-019 Auckland, New Zealand
NevelBrnnLee信息技术系统与服务奥克兰大学奥克兰私人包92-019，新西兰
Phone: +64 9 373 7599 x8941
EMail: n.brownlee@auckland.ac.nz
Phone: +64 9 373 7599 x8941
EMail: n.brownlee@auckland.ac.nz
Greg Ruth GTE Internteworking 3 Van de Graaff Drive P.O. Box 3073 Burlington, MA 01803, U.S.A.
美国马萨诸塞州伯灵顿市范德格拉夫大道3号，邮政信箱3073号，邮编01803。
Phone: +1 781 262 4831
EMail: gruth@bbn.com
Phone: +1 781 262 4831
EMail: gruth@bbn.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。