Network Working Group G. Huston
Request for Comments: 2990 Telstra
Category: Informational November 2000
Network Working Group G. Huston
Request for Comments: 2990 Telstra
Category: Informational November 2000
Next Steps for the IP QoS Architecture
IP QoS体系结构的下一步
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
While there has been significant progress in the definition of Quality of Service (QoS) architectures for internet networks, there are a number of aspects of QoS that appear to need further elaboration as they relate to translating a set of tools into a coherent platform for end-to-end service delivery. This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets.
虽然在互联网网络服务质量（QoS）体系结构的定义方面取得了重大进展，但QoS的许多方面似乎需要进一步阐述，因为它们涉及将一组工具转换为端到端服务交付的一致平台。本文件强调了与internet网络中QoS机制的部署和使用相关的未决架构问题，并指出了进一步的标准工作可能有助于QoS internet部署的领域。
This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board.
本文件是互联网体系结构委员会合作实践的成果。
Table of Contents
目录
1. Introduction ........................................... 2
2. State and Stateless QoS ................................ 4
3. Next Steps for QoS Architectures ....................... 6
3.1 QoS-Enabled Applications ........................... 7
3.2 The Service Environment ............................ 9
3.3 QoS Discovery ...................................... 10
3.4 QoS Routing and Resource Management ................ 10
3.5 TCP and QoS ........................................ 11
3.6 Per-Flow States and Per-Packet classifiers ......... 13
3.7 The Service Set .................................... 14
3.8 Measuring Service Delivery ......................... 14
3.9 QoS Accounting ..................................... 15
3.10 QoS Deployment Diversity .......................... 16
3.11 QoS Inter-Domain signaling ........................ 17
1. Introduction ........................................... 2
2. State and Stateless QoS ................................ 4
3. Next Steps for QoS Architectures ....................... 6
3.1 QoS-Enabled Applications ........................... 7
3.2 The Service Environment ............................ 9
3.3 QoS Discovery ...................................... 10
3.4 QoS Routing and Resource Management ................ 10
3.5 TCP and QoS ........................................ 11
3.6 Per-Flow States and Per-Packet classifiers ......... 13
3.7 The Service Set .................................... 14
3.8 Measuring Service Delivery ......................... 14
3.9 QoS Accounting ..................................... 15
3.10 QoS Deployment Diversity .......................... 16
3.11 QoS Inter-Domain signaling ........................ 17
3.12 QoS Deployment Logistics .......................... 17
4. The objective of the QoS architecture .................. 18
5. Towards an end-to-end QoS architecture ................. 19
6. Conclusions ............................................ 21
7. Security Considerations ................................ 21
8. References ............................................. 22
9. Acknowledgments ........................................ 23
10. Author's Address ....................................... 23
11. Full Copyright Statement ............................... 24
3.12 QoS Deployment Logistics .......................... 17
4. The objective of the QoS architecture .................. 18
5. Towards an end-to-end QoS architecture ................. 19
6. Conclusions ............................................ 21
7. Security Considerations ................................ 21
8. References ............................................. 22
9. Acknowledgments ........................................ 23
10. Author's Address ....................................... 23
11. Full Copyright Statement ............................... 24
The default service offering associated with the Internet is characterized as a best-effort variable service response. Within this service profile the network makes no attempt to actively differentiate its service response between the traffic streams generated by concurrent users of the network. As the load generated by the active traffic flows within the network varies, the network's best effort service response will also vary.
与Internet关联的默认服务产品的特点是尽力而为的可变服务响应。在该服务配置文件中，网络不尝试在网络并发用户生成的业务流之间主动区分其服务响应。由于网络内的主动业务流产生的负载不同，网络的尽力而为服务响应也会不同。
The objective of various Internet Quality of Service (QoS) efforts is to augment this base service with a number of selectable service responses. These service responses may be distinguished from the best-effort service by some form of superior service level, or they may be distinguished by providing a predictable service response which is unaffected by external conditions such as the number of concurrent traffic flows, or their generated traffic load.
各种Internet服务质量（QoS）工作的目标是使用大量可选择的服务响应来增强此基本服务。这些服务响应可以通过某种形式的高级服务级别与尽力而为服务进行区分，或者可以通过提供不受外部条件（例如并发业务流的数量或其生成的业务负载）影响的可预测服务响应来区分。
Any network service response is an outcome of the resources available to service a load, and the level of the load itself. To offer such distinguished services there is not only a requirement to provide a differentiated service response within the network, there is also a requirement to control the service-qualified load admitted into the network, so that the resources allocated by the network to support a particular service response are capable of providing that response for the imposed load. This combination of admission control agents and service management elements can be summarized as "rules plus behaviors". To use the terminology of the Differentiated Service architecture [4], this admission control function is undertaken by a traffic conditioner (an entity which performs traffic conditioning functions and which may contain meters, markers, droppers, and shapers), where the actions of the conditioner are governed by explicit or implicit admission control agents.
任何网络服务响应都是可用于服务负载的资源以及负载本身级别的结果。为了提供这种区分服务，不仅需要在网络内提供区分服务响应，还需要控制接入网络的服务合格负载，因此，由网络分配以支持特定服务响应的资源能够为施加的负载提供该响应。接纳控制代理和服务管理元素的这种组合可以概括为“规则加行为”。使用差异化服务体系结构的术语[4]，该准入控制功能由流量调节器（执行流量调节功能的实体，可能包含仪表、标记、滴管和整形器）承担，调节器的动作由显式或隐式接纳控制代理控制。
As a general observation of QoS architectures, the service load control aspect of QoS is perhaps the most troubling component of the architecture. While there are a wide array of well understood service response mechanisms that are available to IP networks,
作为对QoS架构的一般观察，QoS的服务负载控制方面可能是架构中最麻烦的组件。虽然IP网络上有许多众所周知的服务响应机制，
matching a set of such mechanisms within a controlled environment to respond to a set of service loads to achieve a completely consistent service response remains an area of weakness within existing IP QoS architectures. The control elements span a number of generic requirements, including end-to-end application signaling, end-to-network service signaling and resource management signaling to allow policy-based control of network resources. This control may also span a particular scope, and use 'edge to edge' signaling, intended to support particular service responses within a defined network scope.
在受控环境中匹配一组这样的机制以响应一组服务负载以实现完全一致的服务响应仍然是现有IP QoS体系结构中的一个弱点。控制元件跨越许多通用需求，包括端到端应用信令、端到网络服务信令和资源管理信令，以允许基于策略的网络资源控制。该控制还可以跨越特定范围，并使用“边到边”信令，旨在支持定义的网络范围内的特定服务响应。
One way of implementing this control of imposed load to match the level of available resources is through an application-driven process of service level negotiation (also known as application signaled QoS). Here, the application first signals its service requirements to the network, and the network responds to this request. The application will proceed if the network has indicated that it is able to carry the additional load at the requested service level. If the network indicates that it cannot accommodate the service requirements the application may proceed in any case, on the basis that the network will service the application's data on a best effort basis. This negotiation between the application and the network can take the form of explicit negotiation and commitment, where there is a single negotiation phase, followed by a commitment to the service level on the part of the network. This application-signaled approach can be used within the Integrated Services architecture, where the application frames its service request within the resource reservation protocol (RSVP), and then passes this request into the network. The network can either respond positively in terms of its agreement to commit to this service profile, or it can reject the request. If the network commits to the request with a resource reservation, the application can then pass traffic into the network with the expectation that as long as the traffic remains within the traffic load profile that was originally associated with the request, the network will meet the requested service levels. There is no requirement for the application to periodically reconfirm the service reservation itself, as the interaction between RSVP and the network constantly refreshes the reservation while it remains active. The reservation remains in force until the application explicitly requests termination of the reservation, or the network signals to the application that it is unable to continue with a service commitment to the reservation [3]. There are variations to this model, including an aggregation model where a proxy agent can fold a number of application-signaled reservations into a common aggregate reservation along a common sub-path, and a matching deaggregator can reestablish the collection of individual resource reservations upon leaving the aggregate region [5]. The essential feature of this Integrated Services model is the "all or nothing" nature of the
通过应用程序驱动的服务级别协商过程（也称为应用程序信号QoS），实现对施加负载的控制以匹配可用资源级别的一种方法。这里，应用程序首先向网络发送其服务需求的信号，网络响应该请求。如果网络已指示其能够以请求的服务级别承载额外负载，则应用程序将继续。如果网络表明其无法满足服务要求，则应用程序在任何情况下都可以继续，前提是网络将尽最大努力为应用程序的数据提供服务。应用程序和网络之间的协商可以采取明确协商和承诺的形式，其中只有一个协商阶段，然后是对网络服务级别的承诺。这种应用信号方法可以在集成服务体系结构中使用，其中应用程序在资源预留协议（RSVP）中帧化其服务请求，然后将该请求传递到网络中。网络可以根据其承诺此服务配置文件的协议作出积极响应，也可以拒绝请求。如果网络以资源保留的方式提交请求，则应用程序可以将流量传递到网络，只要流量保持在最初与请求关联的流量负载配置文件内，网络就会满足请求的服务级别。由于RSVP和网络之间的交互在保留保持活动的同时不断刷新保留，因此应用程序不需要定期重新确认服务保留本身。保留将保持有效，直到应用程序明确请求终止保留，或者网络向应用程序发出信号，表明其无法继续保留的服务承诺[3]。该模型有多种变体，包括聚合模型，其中代理可以沿公共子路径将多个应用程序通知的保留折叠为公共聚合保留，并且匹配的解聚合器可以在离开聚合区域时重新建立单个资源保留的集合[5]。此集成服务模型的基本特征是
model. Either the network commits to the reservation, in which case the requestor does not have to subsequently monitor the network's level of response to the service, or the network indicates that it cannot meet the resource reservation.
模型网络提交保留，在这种情况下，请求者不必随后监视网络对服务的响应级别，或者网络指示它无法满足资源保留。
An alternative approach to load control is to decouple the network load control function from the application. This is the basis of the Differentiated Services architecture. Here, a network implements a load control function as part of the function of admission of traffic into the network, admitting no more traffic within each service category as there are assumed to be resources in the network to deliver the intended service response. Necessarily there is some element of imprecision in this function given that traffic may take an arbitrary path through the network. In terms of the interaction between the network and the application, this takes the form of a service request without prior negotiation, where the application requests a particular service response by simply marking each packet with a code to indicate the desired service. Architecturally, this approach decouples the end systems and the network, allowing a network to implement an active admission function in order to moderate the workload that is placed upon the network's resources without specific reference to individual resource requests from end systems. While this decoupling of control allows a network's operator greater ability to manage its resources and a greater ability to ensure the integrity of its services, there is a greater potential level of imprecision in attempting to match applications' service requirements to the network's service capabilities.
负载控制的另一种方法是将网络负载控制功能与应用程序解耦。这是区分服务体系结构的基础。这里，网络实现负载控制功能，作为允许业务进入网络的功能的一部分，在每个服务类别内不允许更多的业务，因为假定网络中存在用于交付预期服务响应的资源。考虑到流量可能通过网络的任意路径，此函数必然存在一些不精确的因素。就网络和应用程序之间的交互而言，这采取了服务请求的形式，而无需事先协商，其中应用程序通过简单地用代码标记每个分组以指示所需服务来请求特定的服务响应。在体系结构上，这种方法将终端系统和网络解耦，允许网络实现主动接纳功能，以缓和网络资源上的工作负载，而无需特定参考来自终端系统的单个资源请求。虽然这种控制解耦使网络运营商能够更好地管理其资源并确保其服务的完整性，但在尝试将应用程序的服务需求与网络的服务能力相匹配时，存在更大的潜在不精确性。
These two approaches to load control can be characterized as state-based and stateless approaches respectively.
这两种负载控制方法可以分别描述为基于状态的方法和无状态的方法。
The architecture of the Integrated Services model equates the cumulative sum of honored service requests to the current reserved resource levels of the network. In order for a resource reservation to be honored by the network, the network must maintain some form of remembered state to describe the resources that have been reserved, and the network path over which the reserved service will operate. This is to ensure integrity of the reservation. In addition, each active network element within the network path must maintain a local state that allows incoming IP packets to be correctly classified into a reservation class. This classification allows the packet to be placed into a packet flow context that is associated with an appropriate service response consistent with the original end-to-end service reservation. This local state also extends to the function
集成服务模型的体系结构将已满足的服务请求的累计总和与网络的当前保留资源级别相等。为了使网络遵守资源保留，网络必须保持某种形式的记忆状态，以描述已保留的资源以及保留服务将在其上运行的网络路径。这是为了确保保留的完整性。此外，网络路径中的每个活动网元必须保持本地状态，以允许将传入的IP数据包正确分类为保留类。该分类允许将分组放入与与原始端到端服务保留一致的适当服务响应相关联的分组流上下文中。这个局部状态也扩展到函数
of metering packets for conformance on a flow-by-flow basis, and the additional overheads associated with maintenance of the state of each of these meters.
以流量为基础的计量数据包一致性，以及与维护每个仪表状态相关的额外开销。
In the second approach, that of a Differentiated Services model, the packet is marked with a code to trigger the appropriate service response from the network elements that handles the packet, so that there is no strict requirement to install a per-reservation state on these network elements. Also, the end application or the service requestor is not required to provide the network with advance notice relating to the destination of the traffic, nor any indication of the intended traffic profile or the associated service profile. In the absence of such information any form of per-application or per-path resource reservation is not feasible. In this model there is no maintained per-flow state within the network.
在第二种方法（区分服务模型的方法）中，用代码标记分组，以从处理分组的网络元件触发适当的服务响应，因此不严格要求在这些网络元件上安装每个保留状态。此外，终端应用程序或服务请求者不需要向网络提供与业务的目的地有关的预先通知，也不需要提供预期业务简档或相关联的服务简档的任何指示。在缺乏此类信息的情况下，任何形式的每应用程序或每路径资源保留都是不可行的。在该模型中，网络内没有维持每流状态。
The state-based Integrated Services architectural model admits the potential to support greater level of accuracy, and a finer level of granularity on the part of the network to respond to service requests. Each individual application's service request can be used to generate a reservation state within the network that is intended to prevent the resources associated with the reservation to be reassigned or otherwise preempted to service other reservations or to service best effort traffic loads. The state-based model is intended to be exclusionary, where other traffic is displaced in order to meet the reservation's service targets.
基于状态的集成服务体系结构模型允许在网络部分支持更高级别的准确性和更精细级别的粒度以响应服务请求。每个单独应用程序的服务请求可用于在网络内生成预定状态，该预定状态旨在防止与预定相关联的资源被重新分配或以其他方式抢占以服务其他预定或服务尽力而为的流量负载。基于状态的模型旨在排除其他流量，以满足预订的服务目标。
As noted in RFC2208 [2], there are several areas of concern about the deployment of this form of service architecture. With regard to concerns of per-flow service scalability, the resource requirements (computational processing and memory consumption) for running per-flow resource reservations on routers increase in direct proportion to the number of separate reservations that need to be accommodated. By the same token, router forwarding performance may be impacted adversely by the packet-classification and scheduling mechanisms intended to provide differentiated services for these resource-reserved flows. This service architecture also poses some challenges to the queuing mechanisms, where there is the requirement to allocate absolute levels of egress bandwidth to individual flows, while still supporting an unmanaged low priority best effort traffic class.
如RFC2208[2]所述，这种形式的服务体系结构的部署有几个方面值得关注。关于每流服务可伸缩性的问题，在路由器上运行每流资源预留的资源需求（计算处理和内存消耗）与需要容纳的单独预留的数量成正比地增加。同样，路由器转发性能可能会受到用于为这些资源保留流提供区分服务的分组分类和调度机制的不利影响。这种服务体系结构还对排队机制提出了一些挑战，在排队机制中，需要将出口带宽的绝对级别分配给各个流，同时仍然支持非托管的低优先级尽力而为流量类别。
The stateless approach to service management is more approximate in the nature of its outcomes. Here there is no explicit negotiation between the application's signaling of the service request and the network's capability to deliver a particular service response. If the network is incapable of meeting the service request, then the request simply will not be honored. In such a situation there is no requirement for the network to inform the application that the
服务管理的无状态方法在其结果的性质上更近似。在这里，应用程序的服务请求信令和网络提供特定服务响应的能力之间没有明确的协商。如果网络无法满足服务请求，那么请求将不会得到满足。在这种情况下，网络不需要通知应用程序
request cannot be honored, and it is left to the application to determine if the service has not been delivered. The major attribute of this approach is that it can possess excellent scaling properties from the perspective of the network. If the network is capable of supporting a limited number of discrete service responses, and the routers uses per-packet marking to trigger the service response, then the processor and memory requirements in each router do not increase in proportion to the level of traffic passed through the router. Of course this approach does introduce some degree of compromise in that the service response is more approximate as seen by the end client, and scaling the number of clients and applications in such an environment may not necessarily result in a highly accurate service response to every client's application.
请求无法得到满足，由应用程序确定服务是否尚未交付。这种方法的主要特点是，从网络的角度来看，它可以具有良好的缩放特性。如果网络能够支持有限数量的离散服务响应，并且路由器使用每个分组标记来触发服务响应，则每个路由器中的处理器和内存需求不会随着通过路由器的流量水平成比例增加。当然，这种方法确实引入了某种程度的折衷，因为服务响应比终端客户机看到的更接近，并且在这种环境中扩展客户机和应用程序的数量不一定会导致对每个客户机的应用程序的高度准确的服务响应。
It is not intended to describe these service architectures in further detail within this document. The reader is referred to RFC1633 [3] for an overview of the Integrated Services Architecture (IntServ) and RFC2475 [4] for an overview of the Differentiated Services architecture (DiffServ).
本文档不打算进一步详细描述这些服务体系结构。读者可参考RFC1633[3]了解集成服务体系结构（IntServ）的概述，参考RFC2475[4]了解区分服务体系结构（DiffServ）的概述。
These two approaches are the endpoints of what can be seen as a continuum of control models, where the fine-grained precision of the per application invocation reservation model can be aggregated into larger, more general and potentially more approximate aggregate reservation states, and the end-to-end element-by-element reservation control can be progressively approximated by treating a collection of subnetworks or an entire transit network as an aggregate service element. There are a number of work in progress efforts which are directed towards these aggregated control models, including aggregation of RSVP [5], the RSVP DCLASS Object [6] to allow Differentiated Services Code Points (DSCPs) to be carried in RSVP message objects, and operation of Integrated Services over Differentiated Services networks [7].
这两种方法是控制模型连续体的端点，其中每个应用程序调用保留模型的细粒度精度可以聚合为更大、更通用且可能更近似的聚合保留状态，并且，通过将子网集合或整个公交网络视为聚合服务元素，可以逐步逼近端到端元素对元素的预留控制。有许多针对这些聚合控制模型的正在进行的工作，包括聚合RSVP[5]、RSVP DCLASS对象[6]以允许在RSVP消息对象中携带区分服务代码点（DSCP），以及在区分服务网络上操作集成服务[7]。
Both the Integrated Services architecture and the Differentiated Services architecture have some critical elements in terms of their current definition which appear to be acting as deterrents to widespread deployment. Some of these issues will probably be addressed within the efforts to introduce aggregated control and response models into these QoS architectures, while others may require further refinement through standards-related activities.
集成服务体系结构和差异化服务体系结构在其当前定义中都有一些关键要素，这些要素似乎对广泛部署起到了阻碍作用。其中一些问题可能会在将聚合控制和响应模型引入这些QoS体系结构的工作中得到解决，而其他问题可能需要通过与标准相关的活动进一步细化。
One of the basic areas of uncertainty with QoS architectures is whether QoS is a per-application service, whether QoS is a transport-layer option, or both. Per-application services have obvious implications of extending the QoS architecture into some form of Application Protocol Interface (API), so that applications could negotiate a QoS response from the network and alter their behavior according to the outcome of the response. Examples of this approach include GQOS [8], and RAPI [9]. As a transport layer option, it could be envisaged that any application could have its traffic carried by some form of QoS-enabled network services by changing the host configuration, or by changing the configuration at some other network control point, without making any explicit changes to the application itself. The strength of the transport layer approach is that there is no requirement to substantially alter application behavior, as the application is itself unaware of the administratively assigned QoS. The weakness of this approach is that the application is unable to communicate what may be useful information to the network or to the policy systems that are managing the network's service responses. In the absence of such information the network may provide a service response that is far superior than the application's true requirements, or far inferior than what is required for the application to function correctly. An additional weakness of a transport level approach refers to those class of applications that can adapt their traffic profile to meet the available resources within the network. As a transport level mechanism, such network availability information as may be available to the transport level is not passed back to the application.
QoS体系结构的一个基本不确定性领域是，QoS是否是每个应用程序的服务，QoS是否是传输层选项，或者两者兼而有之。每应用程序服务具有明显的含义，即将QoS体系结构扩展到某种形式的应用程序协议接口（API），以便应用程序可以协商来自网络的QoS响应，并根据响应的结果改变其行为。这种方法的示例包括GQOS[8]和RAPI[9]。作为传输层选项，可以设想，任何应用程序都可以通过改变主机配置，或通过改变某个其他网络控制点的配置，而无需对应用程序本身进行任何明确的更改，使其流量由某种形式的支持QoS的网络服务承载。传输层方法的优点是不需要实质性地改变应用程序的行为，因为应用程序本身不知道管理分配的QoS。这种方法的缺点是，应用程序无法将可能有用的信息传达给网络或管理网络服务响应的策略系统。在缺乏此类信息的情况下，网络可提供远高于应用程序真实需求的服务响应，或远低于应用程序正常运行所需的服务响应。传输级方法的另一个缺点是，这类应用程序可以调整其流量配置以满足网络中的可用资源。作为传输级机制，传输级可能可用的此类网络可用性信息不会传回应用程序。
In the case of the Integrated Services architecture, this transport layer approach does not appear to be an available option, as the application does require some alteration to function correctly in this environment. The application must be able to provide to the service reservation module a profile of its anticipated traffic, or in other words the application must be able to predict its traffic load. In addition, the application must be able to share the reservation state with the network, so that if the network state fails, the application can be informed of the failure. The more general observation is that a network can only formulate an accurate response to an application's requirements if the application is willing to offer precise statement of its traffic profile, and is willing to be policed in order to have its traffic fit within this profile.
在集成服务体系结构的情况下，这种传输层方法似乎不是一个可用的选项，因为应用程序确实需要一些更改才能在此环境中正常运行。应用程序必须能够向服务预订模块提供其预期流量的概要文件，或者换句话说，应用程序必须能够预测其流量负载。此外，应用程序必须能够与网络共享保留状态，以便在网络状态出现故障时，应用程序可以被告知故障。更一般的观察结果是，只有当应用程序愿意提供其流量配置文件的精确声明，并且愿意接受策略以使其流量适合此配置文件时，网络才能对应用程序的需求做出准确的响应。
In the case of the Differentiated Services architecture there is no explicit provision for the application to communicate with the network regarding service levels. This does allow the use of a
在区分服务体系结构的情况下，没有关于应用程序与网络通信的服务级别的明确规定。这确实允许使用
transport level option within the end system that does not require explicit alteration of the application to mark its generated traffic with one of the available Differentiated Services service profiles. However, whether the application is aware of such service profiles or not, there is no level of service assurance to the application in such a model. If the Differentiated Services boundary traffic conditioners enter a load shedding state, the application is not signaled of this condition, and is not explicitly aware that the requested service response is not being provided by the network. If the network itself changes state and is unable to meet the cumulative traffic loads admitted by the ingress traffic conditioners, neither the ingress traffic conditioners, nor the client applications, are informed of this failure to maintain the associated service quality. While there is no explicit need to alter application behavior in this architecture, as the basic DiffServ mechanism is one that is managed within the network itself, the consequence is that an application may not be aware whether a particular service state is being delivered to the application.
终端系统内的传输级别选项，不需要显式更改应用程序以使用一个可用的差异化服务配置文件标记其生成的流量。然而，无论应用程序是否知道这样的服务配置文件，在这样的模型中应用程序都没有服务保证级别。如果区分服务边界流量调节器进入减载状态，则应用程序不会收到该状态的信号，并且不会明确地意识到所请求的服务响应不是由网络提供的。如果网络本身改变状态并且无法满足入口流量调节器允许的累积流量负载，则入口流量调节器和客户端应用程序都不会被通知此故障以维持相关的服务质量。虽然在这种体系结构中没有明确的需要改变应用程序行为，但由于基本的区分服务机制是在网络本身内部管理的，因此，应用程序可能不知道是否正在向应用程序交付特定的服务状态。
There is potential in using an explicit signaling model, such as used by IntServ, but carrying a signal which allows the network to manage the application's traffic within an aggregated service class [6]. Here the application does not pass a complete picture of its intended service profile to the network, but instead is providing some level of additional information to the network to assist in managing its resources, both in terms of the generic service class that the network can associate with the application's traffic, and the intended path of the traffic through the network.
使用显式信令模型（如IntServ使用的）是有潜力的，但它携带的信号允许网络在聚合服务类内管理应用程序的通信量[6]。在这里，应用程序没有将其预期服务配置文件的完整图片传递给网络，而是向网络提供某种级别的附加信息，以帮助管理其资源，这两个方面都是网络可以与应用程序的流量关联的通用服务类，以及通过网络的流量的预期路径。
An additional factor for QoS enabled applications is that of receiver capability negotiation. There is no value in the sender establishing a QoS-enabled path across a network to the receiver if the receiver is incapable of absorbing the consequent data flow. This implies that QoS enabled applications also require some form of end-to-end capability negotiation, possibly through a generic protocol to allow the sender to match its QoS requirements to the minimum of the flow resources that can be provided by the network and the flow resources that can be processed by the receiver. In the case of the Integrated services architecture the application end-to-end interaction can be integrated into the RSVP negotiation. In the case of the Differentiated Services architecture there is no clear path of integrating such receiver control into the signaling model of the architecture as it stands.
支持QoS的应用程序的另一个因素是接收器能力协商。如果接收方不能吸收随后的数据流，则发送方在网络上建立到接收方的QoS启用路径没有任何价值。这意味着支持QoS的应用程序还需要某种形式的端到端能力协商，可能通过通用协议，以允许发送方将其QoS要求与网络可以提供的最小流资源和接收方可以处理的流资源相匹配。在集成服务体系结构的情况下，应用程序端到端交互可以集成到RSVP协商中。在区分服务架构的情况下，没有明确的路径将这种接收器控制集成到现有架构的信令模型中。
If high quality services are to be provided, where `high quality' is implied as being `high precision with a fine level of granularity', then the implication is that all parts of the network that may be involved with servicing the request either have to be over-
如果要提供高质量的服务，其中“高质量”被暗示为“高精度，细粒度”，那么这意味着可能涉及服务请求的网络所有部分都必须结束-
provisioned such that no load state can compromise the service quality, or the network element must undertake explicit allocation of resources to each flow that is associated with each service request.
设置为没有负载状态会影响服务质量，或者网元必须向与每个服务请求相关联的每个流进行资源的显式分配。
For end-to-end service delivery it does appear that QoS architectures will need to extend to the level of the application requesting the service profile. It appears that further refinement of the QoS architecture is required to integrate DiffServ network services into an end-to-end service delivery model, as noted in [7].
对于端到端服务交付，QoS架构似乎需要扩展到请求服务配置文件的应用程序级别。如[7]所述，似乎需要进一步完善QoS体系结构，以将区分服务网络服务集成到端到端服务交付模型中。
The outcome of the considerations of these two approaches to QoS architecture within the network is that there appears to be no single comprehensive service environment that possesses both service accuracy and scaling properties.
考虑到网络内QoS架构的这两种方法的结果是，似乎没有一种综合服务环境同时具有服务准确性和可伸缩性。
The maintained reservation state of the Integrated Services architecture and the end-to-end signaling function of RSVP are part of a service management architecture, but it is not cost effective, or even feasible, to operate a per-application reservation and classification state across the high speed core of a network [2].
综合服务体系结构的维护保留状态和RSVP的端到端信令功能是服务管理体系结构的一部分，但在网络的高速核心上操作每个应用程序的保留和分类状态是不经济的，甚至是不可行的[2]。
While the aggregated behavior state of the Differentiated Services architecture does offer excellent scaling properties, the lack of end-to-end signaling facilities makes such an approach one that cannot operate in isolation within any environment. The Differentiated Services architecture can be characterized as a boundary-centric operational model. With this boundary-centric architecture, the signaling of resource availability from the interior of the network to the boundary traffic conditioners is not defined, nor is the signaling from the traffic conditioners to the application that is resident on the end system. This has been noted as an additional work item in the IntServ operations over DiffServ work, concerning "definition of mechanisms to efficiently and dynamically provision resources in a DiffServ network region". This might include protocols by which an "oracle" (...) conveys information about resource availability within a DiffServ region to border routers." [7]
尽管差异化服务体系结构的聚合行为状态确实提供了出色的可伸缩性，但由于缺乏端到端信令设施，这种方法无法在任何环境中独立运行。区分服务体系结构可以描述为以边界为中心的操作模型。在这种以边界为中心的体系结构中，没有定义从网络内部到边界流量调节器的资源可用性信令，也没有定义从流量调节器到驻留在终端系统上的应用程序的信令。这已被作为区分服务上的IntServ操作工作中的一个附加工作项，涉及“定义在区分服务网络区域中高效、动态地提供资源的机制”。这可能包括“oracle”（…）将区分服务区域内的资源可用性信息传递给边界路由器的协议。”[7]
What appears to be required within the Differentiated Services service model is both resource availability signaling from the core of the network to the DiffServ boundary and some form of signaling from the boundary to the client application.
区分服务服务模型中似乎需要的是从网络核心到区分服务边界的资源可用性信令，以及从边界到客户端应用程序的某种形式的信令。
There is no robust mechanism for network path discovery with specific service performance attributes. The assumption within both IntServ and DiffServ architectures is that the best effort routing path is used, where the path is either capable of sustaining the service load, or not.
对于具有特定服务性能属性的网络路径发现，没有可靠的机制。IntServ和DiffServ架构中的假设是使用尽力而为的路由路径，其中该路径要么能够维持服务负载，要么不能。
Assuming that the deployment of service differentiating infrastructure will be piecemeal, even if only in the initial stages of a QoS rollout, such an assumption may be unwarranted. If this is the case, then how can a host application determine if there is a distinguished service path to the destination? No existing mechanisms exist within either of these architectures to query the network for the potential to support a specific service profile. Such a query would need to examine a number of candidate paths, rather than simply examining the lowest metric routing path, so that this discovery function is likely to be associated with some form of QoS routing functionality.
假设区分服务的基础设施的部署将是零碎的，即使只是在QoS推出的初始阶段，这种假设可能是没有根据的。如果是这种情况，那么主机应用程序如何确定是否存在到目标的可分辨服务路径？这两种体系结构中都不存在查询网络是否有可能支持特定服务配置文件的机制。这样的查询需要检查许多候选路径，而不是简单地检查最低度量路由路径，因此该发现功能可能与某种形式的QoS路由功能相关联。
From this perspective, there is still further refinement that may be required in the model of service discovery and the associated task of resource reservation.
从这个角度来看，在服务发现模型和相关的资源保留任务中还需要进一步的改进。
To date QoS routing has been developed at some distance from the task of development of QoS architectures. The implicit assumption within the current QoS architectural models is that the routing best effort path will be used for both best effort traffic and distinguished service traffic.
迄今为止，QoS路由的开发与QoS体系结构的开发有一定的距离。当前QoS体系结构模型中的隐含假设是，路由尽力而为路径将用于尽力而为流量和区分服务流量。
There is no explicit architectural option to allow the network service path to be aligned along other than the single best routing metric path, so that available network resources can be efficiently applied to meet service requests. Considerations of maximizing network efficiency would imply that some form of path selection is necessary within a QoS architecture, allowing the set of service requirements to be optimally supported within the network's aggregate resource capability.
除了单个最佳路由度量路径外，没有明确的体系结构选项允许网络服务路径沿其他路径对齐，以便有效地应用可用网络资源以满足服务请求。最大化网络效率的考虑意味着在QoS体系结构中需要某种形式的路径选择，允许在网络的总资源能力中最佳地支持服务需求集。
In addition to path selection, SPF-based interior routing protocols allow for the flooding of link metric information across all network elements. This mechanism appears to be a productive direction to provide the control-level signaling between the interior of the network and the network admission elements, allowing the admission
除了路径选择之外，基于SPF的内部路由协议允许链路度量信息在所有网络元素中泛滥。该机制似乎是在网络内部和网络接入元件之间提供控制级信令的有效方向，允许接入
systems to admit traffic based on current resource availability rather than on necessarily conservative statically defined admission criteria.
系统根据当前资源可用性而不是必要的保守静态定义的接纳标准接纳流量。
There is a more fundamental issue here concerning resource management and traffic engineering. The approach of single path selection with static load characteristics does not match a networked environment which contains a richer mesh of connectivity and dynamic load characteristics. In order to make efficient use of a rich connectivity mesh, it is necessary to be able to direct traffic with a common ingress and egress point across a set of available network paths, spreading the load across a broader collection of network links. At its basic form this is essentially a traffic engineering problem. To support this function it is necessary to calculate per-path dynamic load metrics, and allow the network's ingress system the ability to distribute incoming traffic across these paths in accordance with some model of desired traffic balance. To apply this approach to a QoS architecture would imply that each path has some form of vector of quality attributes, and incoming traffic is balanced across a subset of available paths where the quality attribute of the traffic is matched with the quality vector of each available path. This augmentation to the semantics of the traffic engineering is matched by a corresponding shift in the calculation and interpretation of the path's quality vector. In this approach what needs to be measured is not the path's resource availability level (or idle proportion), but the path's potential to carry additional traffic at a certain level of quality. This potential metric is one that allows existing lower priority traffic to be displaced to alternative paths. The path's quality metric can be interpreted as a metric describing the displacement capability of the path, rather than a resource availability metric.
这里有一个关于资源管理和流量工程的更基本的问题。具有静态负载特性的单路径选择方法与包含更丰富的连通性和动态负载特性网格的网络环境不匹配。为了有效利用丰富的连接性网格，必须能够通过一组可用网络路径上的公共入口和出口点来引导流量，从而将负载分散到更广泛的网络链路集合中。基本上，这是一个交通工程问题。为了支持此功能，有必要计算每条路径的动态负载指标，并允许网络的入口系统能够根据所需流量平衡的某种模型在这些路径上分配传入流量。将此方法应用于QoS体系结构将意味着每个路径具有某种形式的质量属性向量，并且传入流量在可用路径子集之间平衡，其中流量的质量属性与每个可用路径的质量向量匹配。这种对交通工程语义的扩展与路径质量向量的计算和解释的相应变化相匹配。在这种方法中，需要测量的不是路径的资源可用性级别（或空闲比例），而是路径在一定质量级别承载额外流量的潜力。该潜在指标允许将现有的低优先级流量转移到替代路径。路径的质量度量可以解释为描述路径置换能力的度量，而不是资源可用性度量。
This area of active network resource management, coupled with dynamic network resource discovery, and the associated control level signaling to network admission systems appears to be a topic for further research at this point in time.
主动网络资源管理的这一领域，加上动态网络资源发现，以及与网络接入系统相关的控制级信令，似乎是目前需要进一步研究的课题。
A congestion-managed rate-adaptive traffic flow (such as used by TCP) uses the feedback from the ACK packet stream to time subsequent data transmissions. The resultant traffic flow rate is an outcome of the service quality provided to both the forward data packets and the reverse ACK packets. If the ACK stream is treated by the network with a different service profile to the outgoing data packets, it remains an open question as to what extent will the data forwarding service be compromised in terms of achievable throughput. High rates of jitter on the ACK stream can cause ACK compression, that in turn
拥塞管理速率自适应业务流（如TCP使用的）使用来自ACK分组流的反馈来计时后续数据传输。结果业务流速率是提供给前向数据分组和反向ACK分组两者的服务质量的结果。如果网络使用与传出数据分组不同的服务简档来处理ACK流，则数据转发服务在可实现吞吐量方面会受到多大程度的损害仍然是一个开放的问题。ACK流上的高抖动率会导致ACK压缩，这反过来
will cause high burst rates on the subsequent data send. Such bursts will stress the service capacity of the network and will compromise TCP throughput rates.
将导致后续数据发送的高突发率。这样的突发将增加网络的服务能力，并降低TCP吞吐量。
One way to address this is to use some form of symmetric service, where the ACK packets are handled using the same service class as the forward data packets. If symmetric service profiles are important for TCP sessions, how can this be structured in a fashion that does not incorrectly account for service usage? In other words, how can both directions of a TCP flow be accurately accounted to one party?
解决此问题的一种方法是使用某种形式的对称服务，其中ACK数据包使用与转发数据包相同的服务类进行处理。如果对称服务配置文件对于TCP会话很重要，那么如何以一种不会错误地考虑服务使用的方式来构造对称服务配置文件呢？换句话说，一个TCP流的两个方向如何能够准确地向一方说明？
Additionally, there is the interaction between the routing system and the two TCP data flows. The Internet routing architecture does not intrinsically preserve TCP flow symmetry, and the network path taken by the forward packets of a TCP session may not exactly correspond to the path used by the reverse packet flow.
此外，路由系统和两个TCP数据流之间存在交互。Internet路由体系结构本质上并不保持TCP流对称性，TCP会话的前向数据包采用的网络路径可能与反向数据包流使用的路径不完全对应。
TCP also exposes an additional performance constraint in the manner of the traffic conditioning elements in a QoS-enabled network. Traffic conditioners within QoS architectures are typically specified using a rate enforcement mechanism of token buckets. Token bucket traffic conditioners behave in a manner that is analogous to a First In First Out queue. Such traffic conditioning systems impose tail drop behavior on TCP streams. This tail drop behavior can produce TCP timeout retransmission, unduly penalizing the average TCP goodput rate to a level that may be well below the level specified by the token bucket traffic conditioner. Token buckets can be considered as TCP-hostile network elements.
TCP还以支持QoS的网络中流量调节元素的方式暴露了额外的性能约束。QoS体系结构中的流量调节器通常使用令牌桶的速率强制机制来指定。令牌桶流量调节器的行为方式类似于先进先出队列。这种流量调节系统对TCP流施加尾部丢弃行为。这种尾部丢弃行为可能会产生TCP超时重传，不适当地将平均TCP goodput速率惩罚到一个可能远低于令牌桶流量调节器指定的水平的水平。令牌桶可被视为TCP恶意网络元素。
The larger issue exposed in this consideration is that provision of some form of assured service to congestion-managed traffic flows requires traffic conditioning elements that operate using weighted RED-like control behaviors within the network, with less deterministic traffic patterns as an outcome. A requirement to manage TCP burst behavior through token bucket control mechanisms is most appropriately managed in the sender's TCP stack.
在这一考虑中暴露的更大问题是，向拥塞管理的交通流提供某种形式的有保证服务需要使用网络内加权红色控制行为的交通调节元件，其结果是不太确定的交通模式。通过令牌桶控制机制管理TCP突发行为的需求最适合在发送方的TCP堆栈中进行管理。
There are a number of open areas in this topic that would benefit from further research. The nature of the interaction between the end-to-end TCP control system and a collection of service differentiation mechanisms with a network is has a large number of variables. The issues concern the time constants of the control systems, the amplitude of feedback loops, and the extent to which each control system assumes an operating model of other active control systems that are applied to the same traffic flow, and the mode of convergence to a stable operational state for each control system.
在这个主题中有许多开放的领域可以从进一步的研究中受益。端到端TCP控制系统和一系列服务差异化机制与网络之间的交互本质是有大量变量的。这些问题涉及控制系统的时间常数、反馈回路的振幅、每个控制系统假设应用于相同交通流的其他主动控制系统的运行模式的程度，以及每个控制系统收敛到稳定运行状态的模式。
Both the IntServ and DiffServ architectures use packet classifiers as an intrinsic part of their architecture. These classifiers can be considered as coarse or fine level classifiers. Fine-grained classifiers can be considered as classifiers that attempt to isolate elements of traffic from an invocation of an application (a `micro-flow') and use a number of fields in the IP packet header to assist in this, typically including the source and destination IP addresses and source and source and destination port addresses. Coarse-grained classifiers attempt to isolate traffic that belongs to an aggregated service state, and typically use the DiffServ code field as the classifying field. In the case of DiffServ there is the potential to use fine-grained classifiers as part of the network ingress element, and coarse-gained classifiers within the interior of the network.
IntServ和DiffServ体系结构都使用包分类器作为其体系结构的固有部分。这些分类器可以被视为粗分类器或细分类器。细粒度分类器可被视为试图将流量元素与应用程序调用（“微流”）隔离开来的分类器，并使用IP数据包报头中的许多字段来帮助实现这一点，通常包括源和目标IP地址以及源和源及目标端口地址。粗粒度分类器试图隔离属于聚合服务状态的流量，通常使用DiffServ代码字段作为分类字段。在区分服务的情况下，有可能使用细粒度分类器作为网络入口元素的一部分，并在网络内部使用粗粒度分类器。
Within flow-sensitive IntServ deployments, every active network element that undertakes active service discrimination is requirement to operate fine-grained packet classifiers. The granularity of the classifiers can be relaxed with the specification of aggregate classifiers [5], but at the expense of the precision and accuracy of the service response.
在流敏感IntServ部署中，每个进行主动服务识别的主动网元都需要操作细粒度数据包分类器。分类器的粒度可以通过聚合分类器的规范来放宽[5]，但代价是服务响应的精度和准确性。
Within the IntServ architecture the fine-grained classifiers are defined to the level of granularity of an individual traffic flow, using the packet's 5-tuple of (source address, destination address, source port, destination port, protocol) as the means to identify an individual traffic flow. The DiffServ Multi-Field (MF) classifiers are also able to use this 5-tuple to map individual traffic flows into supported behavior aggregates.
在IntServ体系结构中，使用数据包的5元组（源地址、目的地址、源端口、目的端口、协议）作为识别单个业务流的手段，将细粒度分类器定义为单个业务流的粒度级别。DiffServ多字段（MF）分类器还能够使用此5元组将单个流量映射到受支持的行为聚合中。
The use of IPSEC, NAT and various forms of IP tunnels result in a occlusion of the flow identification within the IP packet header, combining individual flows into a larger aggregate state that may be too coarse for the network's service policies. The issue with such mechanisms is that they may occur within the network path in a fashion that is not visible to the end application, compromising the ability for the application to determine whether the requested service profile is being delivered by the network. In the case of IPSEC there is a proposal to carry the IPSEC Security Parameter Index (SPI) in the RSVP object [10], as a surrogate for the port addresses. In the case of NAT and various forms of IP tunnels, there appears to be no coherent way to preserve fine-grained classification characteristics across NAT devices, or across tunnel encapsulation.
IPSEC、NAT和各种形式的IP隧道的使用导致IP分组报头内的流标识被阻塞，从而将单个流组合成一个更大的聚合状态，该状态对于网络的服务策略来说可能过于粗糙。此类机制的问题在于，它们可能以终端应用程序不可见的方式出现在网络路径中，从而影响应用程序确定所请求的服务配置文件是否由网络交付的能力。对于IPSEC，建议在RSVP对象[10]中携带IPSEC安全参数索引（SPI），作为端口地址的代理。在NAT和各种形式的IP隧道的情况下，似乎没有一致的方法跨NAT设备或跨隧道封装来保持细粒度分类特征。
IP packet fragmentation also affects the ability of the network to identify individual flows, as the trailing fragments of the IP packet will not include the TCP or UDP port address information. This admits
IP数据包碎片还影响网络识别单个流的能力，因为IP数据包的后续碎片将不包括TCP或UDP端口地址信息。这承认
the possibility of trailing fragments of a packet within a distinguished service class being classified into the base best effort service category, and delaying the ultimate delivery of the IP packet to the destination until the trailing best effort delivered fragments have arrived.
可分辨服务类中的数据包的尾部片段被分类为基本尽力而为服务类别，并延迟IP数据包到目的地的最终交付，直到尾部尽力而为交付的片段到达。
The observation made here is that QoS services do have a number of caveats that should be placed on both the application and the network. Applications should perform path MTU discovery in order to avoid packet fragmentation. Deployment of various forms of payload encryption, header address translation and header encapsulation should be undertaken with due attention to their potential impacts on service delivery packet classifiers.
这里观察到的是，QoS服务确实有许多警告，应该在应用程序和网络上提出。应用程序应执行路径MTU发现，以避免数据包碎片。部署各种形式的有效载荷加密、报头地址转换和报头封装时，应适当注意它们对服务交付数据包分类器的潜在影响。
The underlying question posed here is how many distinguished service responses are adequate to provide a functionally adequate range of service responses?
这里提出的基本问题是，有多少杰出的服务响应足以提供功能上适当的服务响应范围？
The Differentiated Services architecture does not make any limiting restrictions on the number of potential services that a network operator can offer. The network operator may be limited to a choice of up to 64 discrete services in terms of the 6 bit service code point in the IP header but as the mapping from service to code point can be defined by each network operator, there can be any number of potential services.
区分服务体系结构对网络运营商可以提供的潜在服务数量没有任何限制。根据IP报头中的6位服务代码点，网络运营商可能被限制为最多64个离散服务的选择，但是由于每个网络运营商可以定义从服务到代码点的映射，因此可能存在任意数量的潜在服务。
As always, there is such a thing as too much of a good thing, and a large number of potential services leads to a set of issues around end-to-end service coherency when spanning multiple network domains. A small set of distinguished services can be supported across a large set of service providers by equipment vendors and by application designers alike. An ill-defined large set of potential services often serves little productive purpose. This does point to a potential refinement of the QoS architecture to define a small core set of service profiles as "well-known" service profiles, and place all other profiles within a "private use" category.
与往常一样，好事太多，大量潜在服务会导致跨多个网络域时端到端服务一致性方面的一系列问题。设备供应商和应用程序设计人员都可以跨一大组服务提供商支持一小组杰出的服务。一个定义不清的大型潜在服务集通常没有什么生产意义。这确实指出了QoS体系结构的一个潜在改进，即将一小部分核心服务配置文件定义为“众所周知的”服务配置文件，并将所有其他配置文件放在“私有使用”类别中。
There is a strong requirement within any QoS architecture for network management approaches that provide a coherent view of the operating state of the network. This differs from a conventional element-by-element management view of the network in that the desire here is to be able to provide a view of the available resources along a
在任何QoS体系结构中，都强烈要求网络管理方法能够提供网络运行状态的一致视图。这不同于传统的网络逐元素管理视图，因为这里的愿望是能够提供沿网络的可用资源的视图
particular path within a network, and map this view to an admission control function which can determine whether to admit a service differentiated flow along the nominated network path.
并将该视图映射到允许控制功能，该功能可确定是否允许沿指定网络路径的服务区分流。
As well as managing the admission systems through resource availability measurement, there is a requirement to be able to measure the operating parameters of the delivered service. Such measurement methodologies are required in order to answer the question of how the network operator provides objective measurements to substantiate the claim that the delivered service quality conformed to the service specifications. Equally, there is a requirement for a measurement methodology to allow the client to measure the delivered service quality so that any additional expense that may be associated with the use of premium services can be justified in terms of superior application performance.
除了通过测量资源可用性来管理准入系统外，还需要能够测量所提供服务的运行参数。为了回答网络运营商如何提供客观测量以证实所提供的服务质量符合服务规范的要求这一问题，需要使用这种测量方法。同样，还需要一种测量方法，以允许客户测量所提供的服务质量，从而使与使用优质服务相关的任何额外费用都可以在卓越的应用程序性能方面得到证明。
Such measurement methodologies appear to fall within the realm of additional refinement to the QoS architecture.
这种测量方法似乎属于对QoS体系结构进行进一步细化的领域。
It is reasonable to anticipate that such forms of premium service and customized service will attract an increment on the service tariff. The provision of a distinguished service is undertaken with some level of additional network resources to support the service, and the tariff premium should reflect this altered resource allocation. Not only does such an incremental tariff shift the added cost burden to those clients who are requesting a disproportionate level of resources, but it provides a means to control the level of demand for premium service levels.
可以合理预期，这种形式的优质服务和定制服务将吸引服务费率的增加。卓越服务的提供是通过一定程度的额外网络资源来支持该服务的，费率溢价应反映这种改变的资源分配。这种递增的电价不仅将增加的成本负担转移到那些要求不相称的资源水平的客户身上，而且还提供了一种控制优质服务水平需求水平的手段。
If there are to be incremental tariffs on the use of premium services, then some accounting of the use of the premium service would appear to be necessary relating use of the service to a particular client. So far there is no definition of such an accounting model nor a definition as to how to gather the data to support the resource accounting function.
如果对优质服务的使用有递增的关税，那么就有必要对优质服务的使用进行一些会计核算，将服务的使用与特定客户联系起来。到目前为止，还没有这种会计模型的定义，也没有关于如何收集数据以支持资源会计功能的定义。
The impact of this QoS service model may be quite profound to the models of Internet service provision. The commonly adopted model in both the public internet and within enterprise networks is that of a model of access, where the clients service tariff is based on the characteristics of access to the services, rather than that of the actual use of the service. The introduction of QoS services creates a strong impetus to move to usage-based tariffs, where the tariff is based on the level of use of the network's resources. This, in turn, generates a requirement to meter resource use, which is a form of usage accounting. This topic was been previously studied within the
这种QoS服务模型对Internet服务提供模型的影响可能非常深远。公共互联网和企业网络中普遍采用的模型是接入模型，其中客户服务费率基于对服务的接入特性，而不是服务的实际使用特性。QoS服务的引入有力地推动了向基于使用情况的收费转变，其中的收费基于网络资源的使用水平。这反过来又产生了衡量资源使用的需求，这是一种使用会计的形式。本主题之前已在
IETF under the topic of "Internet Accounting" [11], and further refinement of the concepts used in this model, as they apply to QoS accounting may prove to be a productive initial step in formulating a standards-based model for QoS accounting.
IETF以“互联网计费”为主题[11]，并进一步完善该模型中使用的概念，因为它们适用于QoS计费，这可能证明是制定基于标准的QoS计费模型的一个富有成效的初始步骤。
It is extremely improbable that any single form of service differentiation technology will be rolled out across the Internet and across all enterprise networks.
任何单一形式的服务差异化技术都不可能在互联网和所有企业网络上推广。
Some networks will deploy some form of service differentiation technology while others will not. Some of these service platforms will interoperate seamlessly and other less so. To expect all applications, host systems, network routers, network policies, and inter-provider arrangements to coalesce into a single homogeneous service environment that can support a broad range of service responses is an somewhat unlikely outcome given the diverse nature of the available technologies and industry business models. It is more likely that we will see a number of small scale deployment of service differentiation mechanisms and some efforts to bridge these environments together in some way.
一些网络将部署某种形式的服务差异化技术，而其他网络则不会。其中一些服务平台将实现无缝互操作，而其他平台则不那么无缝互操作。鉴于可用技术和行业商业模式的多样性，期望所有应用程序、主机系统、网络路由器、网络策略和供应商间安排合并到一个单一的同质服务环境中，以支持广泛的服务响应是一种不太可能的结果。更有可能的是，我们将看到一些服务差异化机制的小规模部署，以及以某种方式将这些环境连接在一起的一些努力。
In this heterogeneous service environment the task of service capability discovery is as critical as being able to invoke service responses and measure the service outcomes. QoS architectures will need to include protocol capabilities in supporting service discovery mechanisms.
在这种异构服务环境中，服务能力发现的任务与能够调用服务响应和度量服务结果一样重要。QoS体系结构将需要在支持服务发现机制中包含协议功能。
In addition, such a heterogeneous deployment environment will create further scaling pressure on the operational network as now there is an additional dimension to the size of the network. Each potential path to each host is potentially qualified by the service capabilities of the path. While one path may be considered as a candidate best effort path, another path may offer a more precise match between the desired service attributes and the capabilities of the path to sustain the service. Inter-domain policy also impacts upon this path choice, where inter-domain transit agreements may specifically limit the types and total level of quality requests than may be supported between the domains. Much of the brunt of such scaling pressures will be seen in the inter-domain and intra-domain routing domain where there are pressures to increase the number of attributes of a routing entry, and also to use the routing protocol in some form of service signaling role.
此外，这种异构部署环境将对操作网络造成进一步的扩展压力，因为现在网络的大小有了额外的维度。每个主机的每个潜在路径都可能由该路径的服务功能限定。虽然一条路径可被视为候选尽力而为路径，但另一条路径可在所需服务属性和路径的能力之间提供更精确的匹配以维持服务。域间策略也会影响此路径选择，域间传输协议可能会特别限制域间支持的质量请求的类型和总级别。这种扩展压力的主要影响将出现在域间和域内路由域中，其中存在增加路由条目属性数量的压力，以及在某种形式的服务信令角色中使用路由协议的压力。
QoS Path selection is both an intra-domain (interior) and an inter-domain (exterior) issue. Within the inter-domain space, the current routing technologies allow each domain to connect to a number of other domains, and to express its policies with respect to received traffic in terms of inter-domain route object attributes. Additionally, each domain may express its policies with respect to sending traffic through the use of boundary route object filters, allowing a domain to express its preference for selecting one domain's advertised routes over another. The inter-domain routing space is a state of dynamic equilibrium between these various route policies.
QoS路径选择既是域内（内部）问题，也是域间（外部）问题。在域间空间中，当前的路由技术允许每个域连接到多个其他域，并根据域间路由对象属性表达其关于接收流量的策略。此外，每个域可以通过使用边界路由对象过滤器来表达其关于发送流量的策略，从而允许域表达其选择一个域的广告路由而不是另一个域的广告路由的偏好。域间路由空间是这些不同路由策略之间的动态平衡状态。
The introduction of differentiated services adds a further dimension to this policy space. For example, while a providers may execute an interconnection agreement with one party to exchange best effort traffic, it may execute another agreement with a second party to exchange service qualified traffic. The outcome of this form of interconnection is that the service provider will require external route advertisements to be qualified by the accepted service profiles. Generalizing from this scenario, it is reasonable to suggest that we will require the qualification of routing advertisements with some form of service quality attributes. This implies that we will require some form of quality vector-based forwarding function, at least in the inter-domain space, and some associated routing protocol can pass a quality of service vector in an operationally stable fashion.
差异化服务的引入为这一政策空间增加了另一个维度。例如，虽然提供商可以与一方签署互连协议以交换尽力而为的流量，但它可以与第二方签署另一协议以交换服务合格的流量。这种互连形式的结果是，服务提供商将要求外部线路广告符合公认的服务配置文件。从这个场景中概括，我们有理由建议，我们将要求路由广告具有某种形式的服务质量属性。这意味着我们将需要某种形式的基于质量向量的转发功能，至少在域间空间中是这样，并且一些相关的路由协议可以以操作稳定的方式传递服务质量向量。
The implication of this requirement is that the number of objects being managed by routing systems must expand dramatically, as the size and number of objects managed within the routing domain increases, and the calculation of a dynamic equilibrium of import and export policies between interconnected providers will also be subject to the same level of scaling pressure.
这一要求的含义是，随着路由域内管理的对象的大小和数量增加，路由系统管理的对象数量必须急剧增加，而互联供应商之间进出口政策动态平衡的计算也将受到相同程度的规模压力。
This has implications within the inter-domain forwarding space as well, as the forwarding decision in such a services differentiated environment is then qualified by some form of service quality vector. This is required in order to pass exterior traffic to the appropriate exterior interconnection gateway.
这在域间转发空间中也有影响，因为在这种服务区分环境中的转发决策随后由某种形式的服务质量向量限定。这是将外部通信量传递到适当的外部互连网关所必需的。
How does the widespread deployment of service-aware networks commence? Which gets built first - host applications or network infrastructure?
服务感知网络的广泛部署是如何开始的？首先构建的是哪一个-主机应用程序还是网络基础设施？
No network operator will make the significant investment in deployment and support of distinguished service infrastructure unless there is a set of clients and applications available to make immediate use of such facilities. Clients will not make the investment in enhanced services unless they see performance gains in applications that are designed to take advantage of such enhanced services. No application designer will attempt to integrate service quality features into the application unless there is a model of operation supported by widespread deployment that makes the additional investment in application complexity worthwhile and clients who are willing to purchase such applications. With all parts of the deployment scenario waiting for the others to move, widespread deployment of distinguished services may require some other external impetus.
任何网络运营商都不会在部署和支持卓越服务基础设施方面进行重大投资，除非有一组客户机和应用程序可立即使用这些设施。客户不会投资于增强型服务，除非他们看到旨在利用此类增强型服务的应用程序的性能有所提高。任何应用程序设计者都不会尝试将服务质量功能集成到应用程序中，除非存在一种由广泛部署支持的操作模型，从而使对应用程序复杂性的额外投资变得值得，并且客户愿意购买此类应用程序。由于部署场景的所有部分都在等待其他部分的移动，因此卓越服务的广泛部署可能需要一些其他外部动力。
Further aspects of this deployment picture lie in the issues of network provisioning and the associated task of traffic engineering. Engineering a network to meet the demands of best effort flows follows a well understood pattern of matching network points of user concentrations to content delivery network points with best effort paths. Integrating QoS-mediated traffic engineering into the provisioning model suggests a provisioning requirement that also requires input from a QoS demand model.
此部署图的进一步方面在于网络供应问题和相关的流量工程任务。设计网络以满足尽力而为流的需求遵循一种众所周知的模式，即将用户集中的网络点与具有尽力而为路径的内容交付网络点相匹配。将QoS介导的流量工程集成到供应模型中提出了一个供应需求，该需求还需要来自QoS需求模型的输入。
What is the precise nature of the problem that QoS is attempting to solve? Perhaps this is one of the more fundamental questions underlying the QoS effort, and the diversity of potential responses is a pointer to the breadth of scope of the QoS effort.
QoS试图解决的问题的确切性质是什么？也许这是QoS工作背后更基本的问题之一，潜在响应的多样性是QoS工作范围的一个指针。
All of the following responses form a part of the QoS intention:
以下所有响应构成QoS意图的一部分：
- To control the network service response such that the response to a specific service element is consistent and predictable.
- 控制网络服务响应，以使对特定服务元素的响应一致且可预测。
- To control the network service response such that a service element is provided with a level of response equal to or above a guaranteed minimum.
- 控制网络服务响应，使得服务元素具有等于或高于保证最小值的响应水平。
- To allow a service element to establish in advance the service response that can or will be obtained from the network.
- 允许服务元素预先建立可以或将从网络获得的服务响应。
- To control the contention for network resources such that a service element is provided with a superior level of network resource.
- 控制对网络资源的争用，以便为服务元素提供更高级别的网络资源。
- To control the contention for network resources such that a service element does not obtain an unfair allocation of resources (to some definition of 'fairness').
- 控制对网络资源的争用，以使服务元素不会获得不公平的资源分配（根据“公平”的某些定义）。
- To allow for efficient total utilization of network resources while servicing a spectrum of directed network service outcomes.
- 在为一系列定向网络服务结果提供服务的同时，实现网络资源的高效总体利用。
Broadly speaking, the first three responses can be regarded as 'application-centric', and the latter as 'network-centric'. It is critical to bear in mind that none of these responses can be addressed in isolation within any effective QoS architecture. Within the end-to-end architectural model of the Internet, applications make minimal demands on the underlying IP network. In the case of TCP, the protocol uses an end-to-end control signal approach to dynamically adjust to the prevailing network state. QoS architectures add a somewhat different constraint, in that the network is placed in an active role within the task of resource allocation and service delivery, rather than being a passive object that requires end systems to adapt.
广义而言，前三个响应可以被视为“以应用程序为中心”，后一个响应可以被视为“以网络为中心”。必须记住，在任何有效的QoS体系结构中，这些响应都不能单独处理。在互联网的端到端架构模型中，应用程序对底层IP网络的需求最小。在TCP的情况下，该协议使用端到端控制信号方法来动态调整以适应当前的网络状态。QoS体系结构增加了一些不同的约束，因为网络在资源分配和服务交付任务中处于主动角色，而不是被动对象，需要终端系统进行调整。
The challenge facing the QoS architecture lies in addressing the weaknesses noted above, and in integrating the various elements of the architecture into a cohesive whole that is capable of sustaining end-to-end service models across a wide diversity of internet platforms. It should be noted that such an effort may not necessarily result in a single resultant architecture, and that it is possible to see a number of end-to-end approaches based on different combinations of the existing components.
QoS体系结构面临的挑战在于解决上述弱点，并将体系结构的各个元素集成到一个具有凝聚力的整体中，该整体能够跨多种互联网平台维持端到端服务模型。应该注意的是，这样的努力可能不一定会产生单一的结果体系结构，并且可以看到基于现有组件的不同组合的大量端到端方法。
One approach is to attempt to combine both architectures into an end-to-end model, using IntServ as the architecture which allows applications to interact with the network, and DiffServ as the architecture to manage admission the network's resources [7]. In this approach, the basic tension that needs to be resolved lies in difference between the per-application view of the IntServ architecture and the network boundary-centric view of the DiffServ architecture.
一种方法是尝试将两种体系结构组合成端到端模型，使用IntServ作为允许应用程序与网络交互的体系结构，使用DiffServ作为管理网络资源的体系结构[7]。在这种方法中，需要解决的基本问题在于IntServ体系结构的每个应用程序视图和DiffServ体系结构的以网络边界为中心的视图之间的差异。
One building block for such an end-to-end service architecture is a service signaling protocol. The RSVP signaling protocol can address the needs of applications that require a per-service end-to-end service signaling environment. The abstracted model of RSVP is that of a discovery signaling protocol that allows an application to use a single transaction to communicate its service requirements to both the network and the remote party, and through the response mechanism, to allow these network elements to commit to the service
这种端到端服务架构的一个构建块是服务信令协议。RSVP信令协议可以满足需要每服务端到端服务信令环境的应用的需求。RSVP的抽象模型是发现信令协议的模型，该协议允许应用程序使用单个事务向网络和远程方传达其服务需求，并通过响应机制，允许这些网元提交服务
requirements. The barriers to deployment for this model lie in an element-by element approach to service commitment, implying that each network element must undertake some level of signaling and processing as dictated by this imposed state. For high precision services this implies per-flow signaling and per-flow processing to support this service model. This fine-grained high precision approach to service management is seen as imposing an unacceptable level of overhead on the central core elements of large carrier networks.
要求。该模型部署的障碍在于服务承诺的元素对元素的方法，这意味着每个网络元素必须按照该强制状态的指示进行某种级别的信令和处理。对于高精度服务，这意味着支持此服务模型的每流信令和每流处理。这种细粒度高精度的服务管理方法被视为对大型运营商网络的核心要素施加了不可接受的开销水平。
The DiffServ approach uses a model of abstraction which attempts to create an external view of a compound network as a single subnetwork. From this external perspective the network can be perceived as two boundary service points, ingress and egress. The advantage of this approach is that there exists the potential to eliminate the requirement for per-flow state and per-flow processing on the interior elements of such a network, and instead provide aggregate service responses.
DiffServ方法使用一个抽象模型，试图将复合网络创建为单个子网络的外部视图。从这个外部角度来看，网络可以被视为两个边界服务点，入口和出口。这种方法的优点是，有可能消除对这种网络内部元素的每流状态和每流处理的要求，而是提供聚合服务响应。
One approach is for applications to use RSVP to request that their flows be admitted into the network. If a request is accepted, it would imply that there is a committed resource reservation within the IntServ-capable components of the network, and that the service requirements have been mapped into a compatible aggregate service class within the DiffServ-capable network [7]. The DiffServ core must be capable of carrying the RSVP messages across the DiffServ network, so that further resource reservation is possible within the IntServ network upon egress from the DiffServ environment. The approach calls for the DiffServ network to use per-flow multi-field (MF) classifier, where the MF classification is based on the RSVP-signaled flow specification. The service specification of the RSVP-signaled resource reservation is mapped into a compatible aggregate DiffServ behavior aggregate and the MF classifier marks packets according to the selected behavior. Alternatively the boundary of the IntServ and DiffServ networks can use the IntServ egress to mark the flow packets with the appropriate DSCP, allowing the DiffServ ingress element to use the BA classifier, and dispense with the per-flow MF classifier.
一种方法是应用程序使用RSVP请求允许其流进入网络。如果请求被接受，则意味着网络中支持IntServ的组件中存在提交的资源保留，并且服务需求已映射到支持DiffServ的网络中的兼容聚合服务类[7]。DiffServ核心必须能够跨DiffServ网络承载RSVP消息，以便在从DiffServ环境退出时，可以在IntServ网络内进行进一步的资源预留。该方法要求DiffServ网络使用每流多场（MF）分类器，其中MF分类基于RSVP信号流规范。RSVP信号资源预留的服务规范映射到兼容的聚合DiffServ行为聚合中，MF分类器根据所选行为标记数据包。或者，IntServ和DiffServ网络的边界可以使用IntServ出口来用适当的DSCP标记流分组，从而允许DiffServ入口元素使用BA分类器，并且免除每流MF分类器。
A high precision end-to-end QoS model requires that any admission failure within the DiffServ network be communicated to the end application, presumably via RSVP. This allows the application to take some form of corrective action, either by modifying it's service requirements or terminating the application. If the service agreement between the DiffServ network is statically provisioned, then this static information can be loaded into the IntServ boundary systems, and IntServ can manage the allocation of available DiffServ behavior aggregate resources. If the service agreement is
高精度端到端QoS模型要求DiffServ网络中的任何接纳失败都可以通过RSVP传送给终端应用程序。这允许应用程序通过修改其服务需求或终止应用程序来采取某种形式的纠正措施。如果区分服务网络之间的服务协议是静态提供的，那么该静态信息可以加载到IntServ边界系统中，并且IntServ可以管理可用区分服务行为聚合资源的分配。如果服务协议是
dynamically variable, some form of signaling is required between the two networks to pass this resource availability information back into the RSVP signaling environment.
动态可变，两个网络之间需要某种形式的信令，以将此资源可用性信息传递回RSVP信令环境。
None of these observations are intended to be any reason to condemn the QoS architectures as completely impractical, nor are they intended to provide any reason to believe that the efforts of deploying QoS architectures will not come to fruition.
这些观察结果都不是谴责QoS体系结构完全不切实际的理由，也不是认为部署QoS体系结构的努力不会取得成果的理由。
What this document is intended to illustrate is that there are still a number of activities that are essential precursors to widespread deployment and use of such QoS networks, and that there is a need to fill in the missing sections with something substantial in terms of adoption of additional refinements to the existing QoS model.
本文件旨在说明的是，仍然有许多活动是广泛部署和使用此类QoS网络的必要前提，并且有必要在缺失的部分补充一些实质性内容，以采用对现有QoS模型的额外改进。
The architectural direction that appears to offer the most promising outcome for QoS is not one of universal adoption of a single architecture, but instead use a tailored approach where aggregated service elements are used in the core of a network where scalability is a major design objective and use per-flow service elements at the edge of the network where accuracy of the service response is a sustainable outcome.
为QoS提供最有希望的结果的架构方向不是普遍采用单一架构，而是使用定制的方法，在可伸缩性是主要设计目标的网络核心中使用聚合服务元素，在服务响应的准确性是可持续结果的网络边缘使用按流服务元素。
Architecturally, this points to no single QoS architecture, but rather to a set of QoS mechanisms and a number of ways these mechanisms can be configured to interoperate in a stable and consistent fashion.
在体系结构上，这并不指向单一的QoS体系结构，而是指向一组QoS机制以及可以将这些机制配置为以稳定和一致的方式进行互操作的多种方式。
The Internet is not an architecture that includes a strict implementation of fairness of access to the common transmission and switching resource. The introduction of any form of fairness, and, in the case of QoS, weighted fairness, implies a requirement for transparency in the implementation of the fairness contract between the network provider and the network's users. This requires some form of resource accounting and auditing, which, in turn, requires the use of authentication and access control. The balancing factor is that a shared resource should not overtly expose the level of resource usage of any one user to any other, so that some level of secrecy is required in this environment
互联网不是一个包括严格实现对公共传输和交换资源的访问公平性的体系结构。引入任何形式的公平性，以及在QoS的情况下引入加权公平性，意味着在网络提供商和网络用户之间的公平合同的实施过程中需要透明度。这需要某种形式的资源核算和审核，而这又需要使用身份验证和访问控制。平衡因素是，共享资源不应向任何其他用户公开任何一个用户的资源使用级别，因此在此环境中需要一定程度的保密性
The QoS environment also exposes the potential of theft of resources through the unauthorized admission of traffic with an associated service profile. QoS signaling protocols which are intended to
QoS环境还暴露了通过未经授权地允许具有相关服务配置文件的流量来窃取资源的可能性。QoS信令协议，旨在
undertake resource management and admission control require the use of identity authentication and integrity protection in order to mitigate this potential for theft of resources.
进行资源管理和准入控制需要使用身份验证和完整性保护，以减少资源被盗的可能性。
Both forms of QoS architecture require the internal elements of the network to be able to undertake classification of traffic based on some form of identification that is carried in the packet header in the clear. Classifications systems that use multi-field specifiers, or per-flow specifiers rely on the carriage of end-to-end packet header fields being carried in the clear. This has conflicting requirements for security architectures that attempt to mask such end-to-end identifiers within an encrypted payload.
这两种形式的QoS体系结构都要求网络的内部元件能够基于在clear中的数据包报头中携带的某种形式的标识对流量进行分类。使用多字段说明符或每流说明符的分类系统依赖于在clear中携带的端到端数据包头字段。这对试图在加密负载内屏蔽此类端到端标识符的安全架构有着相互冲突的要求。
QoS architectures can be considered as a means of exerting control over network resource allocation. In the event of a rapid change in resource availability (e.g. disaster) it is an undesirable outcome if the remaining resources are completely allocated to a single class of service to the exclusion of all other classes. Such an outcome constitutes a denial of service, where the traffic control system (routing) selects paths that are incapable of carrying any traffic of a particular service class.
QoS体系结构可以看作是对网络资源分配施加控制的一种手段。在资源可用性发生快速变化的情况下（例如灾难），如果剩余资源完全分配给单一服务类别，而排除所有其他类别，则是不希望出现的结果。这种结果构成拒绝服务，其中流量控制系统（路由）选择无法承载特定服务类别的任何流量的路径。
[1] Bradner, S., "The Internet Standards Process- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程-第3版”，BCP 9，RFC 2026，1996年10月。
[2] Mankin, A., Baker, F., Braden, R., O'Dell, M., Romanow, A., Weinrib, A. and L. Zhang, "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement", RFC 2208, September 1997.
[2] Mankin，A.，Baker，F.，Braden，R.，O'Dell，M.，Romanow，A.，Weinrib，A.和L.Zhang，“资源保留协议（RSVP）版本1适用性声明”，RFC 2208，1997年9月。
[3] Braden. R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[3] 布雷登。R.，Clark，D.和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC163331994年6月。
[4] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[4] Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[5] Baker, F., Iturralde, C., Le Faucher, F., Davie, B., "Aggregation of RSVP for IPv4 and IPv6 Reservations", Work in Progress.
[5] Baker，F.，Iturralde，C.，Le Faucher，F.，Davie，B.，“IPv4和IPv6保留的RSVP聚合”，正在进行的工作。
[6] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[6] Bernet，Y.，“RSVP数据类对象的格式”，RFC 2996，2000年11月。
[7] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Framework for Integrated Services Operation Over DiffServ Networks", RFC 2998, November 2000.
[7] Bernet，Y.，Yavatkar，R.，Ford，P.，Baker，F.，Zhang，L.，Speer，M.，Braden，R.，Davie，B.，Wroclawski，J.和E.Felstaine，“区分服务网络上的综合服务运营框架”，RFC 29982000年11月。
[8] "Quality of Service Technical Overview", Microsoft Technical Library, Microsoft Corporation, September 1999.
[8] “服务质量技术概述”，微软技术图书馆，微软公司，1999年9月。
[9] "Resource Reservation Protocol API (RAPI)", Open Group Technical Standard, C809 ISBN 1-85912-226-4, The Open Group, December 1998.
[9] “资源预留协议API（RAPI）”，开放组技术标准，C809 ISBN 1-85912-226-4，开放组，1998年12月。
[10] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2007, September 1997.
[10] Berger，L.和T.O'Malley，“IPSEC数据流的RSVP扩展”，RFC 2007，1997年9月。
[11] Mills, C., Hirsh, D. and G. Ruth, "Internet Accounting: Background", RFC 1272, November 1991.
[11] Mills，C.，Hirsh，D.和G.Ruth，“互联网会计：背景”，RFC1272，1991年11月。
Valuable contributions to this document came from Yoram Bernet, Brian Carpenter, Jon Crowcroft, Tony Hain and Henning Schulzrinne.
约拉姆·伯内特、布赖恩·卡彭特、乔恩·克劳克罗夫特、托尼·海恩和亨宁·舒尔兹林内对本文件做出了宝贵贡献。
Geoff Huston Telstra 5/490 Northbourne Ave Dickson ACT 2602 AUSTRALIA
Geoff Huston Telstra 5/490 Northbourne Ave Dickson ACT 2602澳大利亚
EMail: gih@telstra.net
EMail: gih@telstra.net
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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编辑功能的资金目前由互联网协会提供。