Network Working Group G. Armitage
Request for Comments: 3248 Swinburne University of Technology
Category: Informational B. Carpenter
IBM
A. Casati
Lucent Technologies
J. Crowcroft
University of Cambridge
J. Halpern
Consultant
B. Kumar
Corona Networks Inc.
J. Schnizlein
Cisco Systems
March 2002
Network Working Group G. Armitage
Request for Comments: 3248 Swinburne University of Technology
Category: Informational B. Carpenter
IBM
A. Casati
Lucent Technologies
J. Crowcroft
University of Cambridge
J. Halpern
Consultant
B. Kumar
Corona Networks Inc.
J. Schnizlein
Cisco Systems
March 2002
A Delay Bound alternative revision of RFC 2598
RFC2598的延迟限制替代版本
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group. At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB.
出于历史利益考虑，本文件捕获了EF设计团队提出的解决方案，RFC 2598的原始作者首选该解决方案，但工作组在2000年12月未采用该解决方案。EF最初的定义是基于在空载网络上比较转发。这种实验性的延迟界限（DB）PHB要求对由于网络中的其他流量而产生的数据包延迟进行界限。在2000年8月的匹兹堡IETF会议上，差异化服务工作组面临着有关RFC 2598的严重问题，RFC 2598是该工作组对每跳加速转发（EF）行为（PHB）的标准跟踪定义。考虑到DiffServ小组提出的问题，“EF设计团队”自愿开发RFC2598的重新表达。在2000年12月的圣地亚哥IETF会议上，DiffServ工作组决定寻求EF PHB的替代重新表达。
Specification of Requirements
需求说明
This document is for Informational purposes only. If implementors choose to experiment with the DB PHB, key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in RFC 2119 [3].
本文件仅供参考。如果实施者选择试验DB PHB，则关键字“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”的解释如RFC 2119[3]所述。
1 Introduction
1导言
RFC 2598 was the Differentiated Services (DiffServ) working group's first standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB) [1]. As part of the DiffServ working group's ongoing refinement of the EF PHB, various issues were raised with the text in RFC 2598 [2].
RFC2598是区分服务（DiffServ）工作组对每跳加速转发（EF）行为（PHB）的第一个标准跟踪定义[1]。作为DiffServ工作组不断完善EF PHB的一部分，RFC 2598[2]中的文本提出了各种问题。
After the Pittsburgh IETF meeting in August 2000, a volunteer 'EF design team' was formed (the authors of this document) to propose a new expression of the EF PHB. The remainder of this Informational document captures our feedback to the DiffServ working group at the San Diego IETF in December 2000. Our solution focussed on a Delay Bound (DB) based re-expression of RFC 2598 which met the goals of RFC 2598's original authors. The DiffServ working group ultimately chose an alternative re-expression of the EF PHB text, developed by the authors of [2] and revised to additionally encompass our model described here.
2000年8月匹兹堡IETF会议后，成立了一个志愿者“EF设计团队”（本文件的作者），提出EF PHB的新表达。本信息性文档的其余部分捕获了我们对2000年12月圣地亚哥IETF DiffServ工作组的反馈。我们的解决方案专注于基于延迟界限（DB）的RFC2598重新表达，它满足了RFC2598原始作者的目标。DiffServ工作组最终选择了EF PHB文本的另一种重新表达方式，由[2]的作者开发，并进行了修订，以进一步包含此处描述的模型。
Our proposed Delay Bound solution is archived for historical interest. Section 2 covers the minimum, necessary and sufficient description of what we believed qualifies as 'DB' behavior from a single node. Section 3 then discusses a number of issues and assumptions made to support the definition in section 2.
我们提出的延迟限制解决方案是出于历史利益而归档的。第2节涵盖了我们认为符合单个节点“DB”行为的最低、必要和充分的描述。第3节接着讨论了为支持第2节中的定义而提出的一些问题和假设。
For a traffic stream not exceeding a particular configured rate, the goal of the DB PHB is a strict bound on the delay variation of packets through a hop.
对于不超过特定配置速率的业务流，DB PHB的目标是通过跳对分组的延迟变化进行严格限制。
This section will begin with the goals and necessary boundary conditions for DB behavior, then provide a descriptive definition of DB behavior itself, discuss what it means to conform to the DB definition, and assign the experimental DB PHB code point.
本节将从DB行为的目标和必要的边界条件开始，然后提供DB行为本身的描述性定义，讨论符合DB定义的含义，并指定实验DB PHB代码点。
For a traffic stream not exceeding a configured rate the goal of the DB PHB is a strict bound on the delay variation of packets through a hop.
对于不超过配置速率的业务流，DB PHB的目标是通过跳对数据包的延迟变化进行严格限制。
Traffic MUST be policed and/or shaped at the source edge (for example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in order to get such a bound. However, specific policing and/or shaping rules are outside the scope of the DB PHB definition. Such rules MUST be defined in any per-domain behaviors (PDBs) composed from the DB PHB.
必须在源边缘（例如，在进入DS域时，如RFC 2475[5]中所述）对流量进行策略和/或整形，以获得这样的界限。但是，特定的监管和/或塑造规则不在DB PHB定义的范围内。这些规则必须在由DB PHB组成的任何每域行为（PDB）中定义。
A device (hop) delivers DB behavior to appropriately marked traffic received on one or more interfaces (marking is specified in section 2.4). A device SHALL deliver the DB behavior on an interface to DB marked traffic meeting (i.e. less than or equal) a certain arrival rate limit R.
设备（hop）将DB行为传递给在一个或多个接口上接收的适当标记的流量（标记在第2.4节中规定）。设备应将接口上的DB行为传递给DB标记的流量会议（即小于或等于）特定到达率限制R。
If more DB traffic arrives than is acceptable, the device is NOT REQUIRED to deliver the DB behavior. However, although the original source of DB traffic will be shaped, aggregation and upstream jitter ensure that the traffic arriving at any given hop cannot be assumed to be so shaped. Thus a DB implementation SHOULD have some tolerance for burstiness - the ability to provide EF behavior even when the arrival rate exceeds the rate limit R.
如果到达的DB流量超过可接受的数量，则不需要设备提供DB行为。然而，尽管DB流量的原始来源将被成形，但聚合和上行抖动确保到达任何给定跳的流量不能被假定为如此成形。因此，DB实现应该对突发性有一定的容忍度——即使到达率超过速率限制R，也能够提供EF行为。
Different DB implementations are free to exhibit different tolerance to burstiness. (Burstiness MAY be characterized in terms of the number of back-to-back wire-rate packets to which the hop can deliver DB behavior. However, since the goal of characterizing burstiness is to allow useful comparison of DB implementations, vendors and users of DB implementations MAY choose to utilize other burstiness metrics.)
不同的DB实现可以自由地表现出对突发性的不同容忍度。（突发性可以根据hop可以向其传递DB行为的背对背线速率数据包的数量来描述。但是，由于描述突发性的目的是允许对DB实现进行有用的比较，DB实现的供应商和用户可以选择使用其他突发性度量。）
The DB PHB definition does NOT mandate or recommend any particular method for achieving DB behavior. Rather, the DB PHB definition identifies parameters that bound the operating range(s) over which an implementation can deliver DB behavior. Implementors characterize their implementations using these parameters, while network designers and testers use these parameters to assess the utility of different DB implementations.
DB PHB定义不强制要求或推荐实现DB行为的任何特定方法。相反，DB PHB定义标识了一些参数，这些参数限制了实现可以传递DB行为的操作范围。实现人员使用这些参数来描述他们的实现，而网络设计师和测试人员使用这些参数来评估不同DB实现的效用。
For simplicity the definition will be explained using an example where traffic arrives on only one interface and is destined for another (single) interface.
为了简单起见，将使用一个示例来解释该定义，其中通信量仅到达一个接口，并且目的地为另一个（单个）接口。
The crux of this definition is that the difference in time between when a packet might have been delivered, and when it is delivered, will never exceed a specifiable bound.
这一定义的关键在于，数据包可能已交付的时间与交付的时间之差永远不会超过可指定的界限。
Given an acceptable (not exceeding arrival rate limit R) stream of DB packets arriving on an interface:
给定到达接口的DB数据包的可接受（不超过到达率限制R）流：
There is a time sequence E(i) when these packets would be delivered at the output interface in the absence of competing traffic. That is, E(i) are the earliest times that the packets could be delivered by the device.
当这些包在没有竞争流量的情况下在输出接口处传送时，存在时间序列E（i）。也就是说，E（i）是设备能够传送分组的最早时间。
In the presence of competing traffic, the packets will be delayed to some later time D(i).
在存在竞争业务的情况下，分组将被延迟到稍后的时间D（i）。
Competing traffic includes all DB traffic arriving at the device on other ports, and all non-DB traffic arriving at the device on any port.
竞争流量包括在其他端口到达设备的所有DB流量，以及在任何端口到达设备的所有非DB流量。
DB is defined as the behavior which ensures, for all i, that:
DB的定义是，对于所有i，确保：
D(i) - E(i) <= S * MTU/R.
D（i）-E（i）<=S*MTU/R。
MTU is the maximum transmission unit (packet size) of the output. R is the arrival rate that the DB device is prepared to accept on this interface.
MTU是输出的最大传输单位（数据包大小）。R是DB设备准备在此接口上接受的到达率。
Note that D(i) and E(i) simply refer to the times of what can be thought of as "the same packet" under the two treatments (with and without competing traffic).
注意，D（i）和E（i）只是指在两种处理方式下（有和没有竞争流量）可以被认为是“相同数据包”的时间。
The score, S, is a characteristic of the device at the rate, R, in order to meet this defined bound. This score, preferably a small constant, depends on the scheduling mechanism and configuration of the device.
分数S是设备的一个特征，其速率R为满足该定义界限的速率。这个分数，最好是一个小常数，取决于调度机制和设备的配置。
An implementation need not conform to the DB specification over an arbitrary range of parameter values. Instead, implementations MUST specify the rates, R, and scores S, for which they claim conformance with the DB definition in section 2.2, and the implementation-specific configuration parameters needed to deliver conformant behavior. An implementation SHOULD document the traffic burstiness it can tolerate while still providing DB behavior.
实现不需要在任意参数值范围内符合DB规范。相反，实现必须指定速率、R和分数S（它们声称符合第2.2节中的DB定义），以及交付一致性行为所需的实现特定配置参数。实现应该记录它可以容忍的流量突发性，同时仍然提供DB行为。
The score, S, and configuration parameters depend on the implementation error from an ideal scheduler. Discussion of the ability of any particular scheduler to provide DB behavior, and the conditions under which it might do so, is outside the scope of this document.
分数、S和配置参数取决于理想调度器的实现错误。关于任何特定调度器提供DB行为的能力以及它可能提供DB行为的条件的讨论超出了本文档的范围。
The implementor MAY define additional constraints on the range of configurations in which DB behavior is delivered. These constraints MAY include limits on the total DB traffic across the device, or total DB traffic targeted at a given interface from all inputs.
实现者可以在交付DB行为的配置范围上定义附加约束。这些约束可能包括对整个设备的总DB通信量的限制，或者来自所有输入的针对给定接口的总DB通信量的限制。
This document does not specify any requirements on DB implementation's values for R, S, or tolerable burstiness. These parameters will be bounded by real-world considerations such as the actual network being designed and the desired PDB.
本文件未规定对DB实现的R、s或可容忍突发性值的任何要求。这些参数将受到现实世界考虑因素的限制，例如正在设计的实际网络和所需的PDB。
One or more DiffServ codepoint (DSCP) value may be used to indicate a requirement for DB behavior [4].
一个或多个DiffServ代码点（DSCP）值可用于指示对DB行为的要求[4]。
By default we suggest an 'experimental' DSCP of 101111 be used to indicate that DB PHB is required.
默认情况下，我们建议使用101111的“实验性”DSCP来表示需要DB PHB。
This section discusses some issues that might not be immediately obvious from the definition in section 2.
本节讨论了一些从第2节的定义中可能不明显的问题。
Packets marked for DB PHB MAY be remarked at a DS domain boundary only to other codepoints that satisfy the DB PHB. Packets marked for DB PHBs SHOULD NOT be demoted or promoted to another PHB by a DS domain.
标记为DB PHB的分组可以仅在DS域边界处对满足DB PHB的其他码点进行注释。DS域不应将标记为DB PHB的数据包降级或升级到另一个PHB。
When DB packets are tunneled, the tunneling packets must be marked as DB.
当对DB数据包进行隧道时，隧道数据包必须标记为DB。
Other PHBs and PHB groups may be deployed in the same DS node or domain with the DB PHB as long as the requirement of section 2 is met.
只要满足第2节的要求，其他PHB和PHB组可以部署在与DB PHB相同的DS节点或域中。
The definition of DB behavior given in section 2 is quite explicitly given in terms of input rate R and output delay variation D(i) - E(i). A scheduler's output rate does not need to be specified, since (by design) it will be whatever is needed to achieve the target delay variation bounds.
第2节中给出的DB行为的定义非常明确地给出了输入速率R和输出延迟变化D（i）-E（i）。调度器的输出速率不需要指定，因为（根据设计）它将是实现目标延迟变化边界所需的任何值。
Jitter is not the bounded parameter in DB behavior. Jitter can be understood in a number of ways, for example the variability in inter-packet times from one inter-packet interval to the next. However, DB behavior aims to bound a related but different parameter - the variation in delay between the time packets would depart in the absence of competing traffic, E(i), and when they would depart in the presence of competing traffic, D(i).
抖动不是DB行为中的有界参数。抖动可以以多种方式理解，例如，从一个分组间间隔到下一个分组间间隔的分组间时间的可变性。然而，DB行为旨在约束一个相关但不同的参数——时间包之间的延迟变化将在没有竞争流量E（i）的情况下离开，以及在存在竞争流量D（i）的情况下离开。
The definition of 'competing traffic' in section 2.2 covers both the single input/single output case and the more general case where DB traffic is converging on a single output port from multiple input ports. When evaluating the ability of an DB device to offer DB behavior to traffic arriving on one port, DB traffic arriving on other ports is factored in as competing traffic.
第2.2节中“竞争流量”的定义涵盖了单输入/单输出情况，以及DB流量从多个输入端口汇聚到单个输出端口的更一般情况。当评估DB设备向到达一个端口的流量提供DB行为的能力时，到达其他端口的DB流量被视为竞争流量。
When considering DB traffic from a single input that is leaving via multiple ports, it is clear that the behavior is no worse than if all of the traffic could be leaving through each one of those ports individually (subject to limits on how much is permitted).
当考虑来自通过多个端口离开的单个输入的DB通信量时，很明显，该行为并不比所有通信量都可以单独通过这些端口中的每一个端口离开更糟糕（取决于允许的数量限制）。
Where an ingress link has an MTU higher than that of an egress link, it is conceivable packets may be fragmented as they pass through a Diffserv hop. However, the unpredictability of fragmentation is significantly counter to the goal of providing controllable QoS. Therefore we assume that fragmentation of DB packets is being avoided (either through some form of Path MTU discovery, or configuration), and does not need to be specifically considered in the DB behavior definition.
在入口链路的MTU高于出口链路的MTU的情况下，可以想象，当分组通过区分服务跳时，分组可能被分段。然而，碎片的不可预测性与提供可控QoS的目标背道而驰。因此，我们假设避免了DB数据包的碎片化（通过某种形式的路径MTU发现或配置），并且不需要在DB行为定义中特别考虑。
If the DB PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage DB traffic could inflict on other traffic. This will be reflected in the DB device's burst tolerance described in section 2.1.
如果DB PHB由允许无限抢占其他流量（例如，优先级队列）的机制实现，则实现必须包括一些限制DB流量可能对其他流量造成的损害的方法。这将反映在第2.1节所述的DB设备的突发容差中。
Some DB implementations may choose to provide queuing and scheduling at a finer granularity, (for example, per micro flow), than is indicated solely by the packet's DSCP. Such behavior is NOT precluded by the DB PHB definition. However, such behavior is also NOT part of the DB PHB definition. Implementors are free to characterize and publicize the additional per micro flow capabilities of their DB implementations as they see fit.
一些DB实现可以选择以比仅由数据包的DSCP指示的更细的粒度（例如，每个微流）提供排队和调度。DB PHB定义不排除此类行为。但是，这种行为也不是DB PHB定义的一部分。实施者可以自由地描述和公布其DB实施的附加每微流功能，因为他们认为合适。
In the absence of additional information, R is assumed to be limited by the slowest interface on the device.
在没有附加信息的情况下，假定R受到设备上最慢接口的限制。
In addition, an DB device may be characterized by different values of R for different traffic flow scenarios (for example, for traffic aimed at different ports, total incoming R, and possibly total per output port incoming R across all incoming interfaces).
此外，对于不同的业务流场景，DB设备可以具有不同的R值（例如，对于针对不同端口的业务，总传入R，并且可能是所有传入接口上的每个输出端口传入R的总和）。
This document suggests one experimental codepoint, 101111. Because the DSCP is taken from the experimental code space, it may be re-used by other experimental or informational DiffServ proposals.
本文提出了一个实验性的代码点101111。由于DSCP取自实验性代码空间，因此它可能会被其他实验性或信息性DiffServ方案重用。
5. Conclusion.
5. 结论
This document defines DB behavior in terms of a bound on delay variation for traffic streams that are rate shaped on ingress to a DS domain. Two parameters - capped arrival rate (R) and a 'score' (S), are defined and related to the target delay variation bound. All claims of DB 'conformance' for specific implementations of DB behavior are made with respect to particular values for R, S, and the implementation's ability to tolerate small amounts of burstiness in the arriving DB traffic stream.
本文档根据进入DS域时速率变化的流量流的延迟变化范围定义DB行为。定义了两个参数-上限到达率（R）和“分数”（S），并与目标延迟变化范围相关。所有关于DB行为的特定实现的DB“一致性”的声明都是关于R、S的特定值以及实现在到达的DB流量流中容忍少量突发性的能力。
Security Considerations
安全考虑
To protect itself against denial of service attacks, the edge of a DS domain MUST strictly police all DB marked packets to a rate negotiated with the adjacent upstream domain (for example, some value less than or equal to the capped arrival rate R). Packets in excess of the negotiated rate MUST be dropped. If two adjacent domains have not negotiated an DB rate, the downstream domain MUST use 0 as the rate (i.e., drop all DB marked packets).
为了保护自身免受拒绝服务攻击，DS域的边缘必须严格监控所有DB标记的数据包，以与相邻上游域协商的速率（例如，一些小于或等于上限到达速率R的值）。超过协商速率的数据包必须丢弃。如果两个相邻域尚未协商DB速率，则下游域必须使用0作为速率（即，丢弃所有DB标记的数据包）。
Since PDBs constructed from the DB PHB will require that the upstream domain police and shape DB marked traffic to meet the rate negotiated with the downstream domain, the downstream domain's policer should never have to drop packets. Thus these drops (or a summary of these drops) SHOULD be noted (e.g., via rate-limited SNMP traps) as possible security violations or serious misconfiguration.
由于由DB PHB构建的PDB将要求上游域的警察和塑造DB标记的流量，以满足与下游域协商的速率，因此下游域的警察永远不必丢弃数据包。因此，应将这些删除（或这些删除的摘要）视为可能的安全违规或严重错误配置（例如，通过速率限制的SNMP陷阱）。
Overflow events on an DB queue MAY also be logged as indicating possible denial of service attacks or serious network misconfiguration.
数据库队列上的溢出事件也可能被记录为表示可能的拒绝服务攻击或严重的网络配置错误。
Acknowledgments
致谢
This document is the product of the volunteer 'EF Resolve' design team, building on the work of V. Jacobson, K. Nichols, K. Poduri [1] and clarified through discussions with members of the DiffServ working group (particularly the authors of [2]). Non-contentious text (such as the use of DB with tunnels, the security considerations, etc.) were drawn directly from equivalent text in RFC 2598.
本文件是志愿者“EF Resolve”设计团队的成果，以V.Jacobson，K.Nichols，K.Poduri[1]的工作为基础，并通过与DiffServ工作组成员（特别是[2]的作者）的讨论加以澄清。非争议性文本（如DB与隧道的使用、安全考虑等）直接取自RFC 2598中的等效文本。
Intellectual Properties Considerations
知识产权考虑
To establish whether any considerations apply to the idea expressed in this document, readers are encouraged to review notices filed with the IETF and stored at:
为了确定任何考虑因素是否适用于本文件中所表达的想法，鼓励读者审查向IETF提交并存储在以下地址的通知：
http://www.ietf.org/ipr.html
http://www.ietf.org/ipr.html
References
工具书类
[1] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.
[1] Jacobson，V.，Nichols，K.和K.Poduri，“快速转发PHB”，RFC 25981999年6月。
[2] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnan, K. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[2] Davie，B.，Charny，A.，Baker，F.，Bennett，J.C.R.，Benson，K.，Le Boudec，J.Y.，Chiu，A.，Courtney，W.，Davari，S.，Firoiu，V.，Kalmanek，C.，Ramakrishnan，K.和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[4] Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[5] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[5] Black，D.，Blake，S.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
Authors (volunteer EF Design Team members)
作者（志愿者EF设计团队成员）
Grenville Armitage Center for Advanced Internet Architectures Swinburne University of Technology, Melbourne, Australia EMail: garmitage@swin.edu.au
格伦维尔阿米蒂奇高级互联网架构中心，斯文本科技大学，墨尔本，澳大利亚电子邮件：garmitage@swin.edu.au
Brian E. Carpenter (team observer, WG co-chair) IBM Zurich Research Laboratory Saeumerstrasse 4 8803 Rueschlikon Switzerland EMail: brian@hursley.ibm.com
Brian E.Carpenter（团队观察员，工作组联席主席）IBM苏黎世研究实验室Saeumerstrasse 4 8803 Rueschlikon瑞士电子邮件：brian@hursley.ibm.com
Alessio Casati Lucent Technologies Swindon, WI SN5 7DJ United Kingdom EMail: acasati@lucent.com
Alessio Casati Lucent Technologies Swindon，WI SN5 7DJ英国电子邮件：acasati@lucent.com
Jon Crowcroft Marconi Professor of Communications Systems University of Cambridge Computer Laboratory William Gates Building J J Thomson Avenue Cambridge CB3 0FD Phone: +44 (0)1223 763633 EMail: Jon.Crowcroft@cl.cam.ac.uk
Jon Crowcroft Marconi通信系统教授剑桥大学计算机实验室威廉盖茨大厦J J汤姆逊大道剑桥CB3 0FD电话：+ 44（0）1223电子邮件763633：乔恩。Crowcroft@cl.cam.ac.uk
Joel M. Halpern P. O. Box 6049 Leesburg, VA 20178 Phone: 1-703-371-3043 EMail: jmh@joelhalpern.com
Joel M.Halpern邮政信箱6049弗吉尼亚州利斯堡20178电话：1-703-371-3043电子邮件：jmh@joelhalpern.com
Brijesh Kumar Corona Networks Inc., 630 Alder Drive, Milpitas, CA 95035 EMail: brijesh@coronanetworks.com
Brijesh Kumar Corona Networks Inc.，加利福尼亚州米尔皮塔斯阿尔德大道630号，邮编95035电子邮件：brijesh@coronanetworks.com
John Schnizlein Cisco Systems 9123 Loughran Road Fort Washington, MD 20744 EMail: john.schnizlein@cisco.com
John Schnizlein Cisco Systems美国马里兰州华盛顿堡拉夫兰路9123号20744电子邮件：John。schnizlein@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。