Network Working Group K. Nichols
Request for Comments: 2638 V. Jacobson
Category: Informational Cisco
L. Zhang
UCLA
July 1999
Network Working Group K. Nichols
Request for Comments: 2638 V. Jacobson
Category: Informational Cisco
L. Zhang
UCLA
July 1999
A Two-bit Differentiated Services Architecture for the Internet
一种用于Internet的两位差分服务体系结构
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document was originally submitted as an internet draft in November of 1997. As one of the documents predating the formation of the IETF's Differentiated Services Working Group, many of the ideas presented here, in concert with Dave Clark's subsequent presentation to the December 1997 meeting of the IETF Integrated Services Working Group, were key to the work which led to RFCs 2474 and 2475 and the section on allocation remains a timely proposal. For this reason, and to provide a reference, it is being submitted in its original form. The forwarding path portion of this document is intended as a record of where we were at in late 1997 and not as an indication of future direction.
本文件最初于1997年11月作为互联网草案提交。作为IETF差异化服务工作组成立之前的文件之一，此处提出的许多想法与Dave Clark随后在1997年12月IETF综合服务工作组会议上的陈述一致，是导致RFC 2474和2475的工作的关键，关于分配的部分仍然是及时的建议。出于这一原因，并为了提供参考，现将其原件提交。本文件的转发路径部分旨在记录我们在1997年末所处的位置，而不是作为未来方向的指示。
The postscript version of this document includes Clark's slides as an appendix. The postscript version of this document also includes many figures that aid greatly in its readability.
本文件的后记版本包括克拉克的幻灯片作为附录。本文件的后记版本还包括许多数字，这些数字大大有助于其可读性。
This document presents a differentiated services architecture for the internet. Dave Clark and Van Jacobson each presented work on differentiated services at the Munich IETF meeting [2,3]. Each explained how to use one bit of the IP header to deliver a new kind of service to packets in the internet. These were two very different kinds of service with quite different policy assumptions. Ensuing discussion has convinced us that both service types have merit and that both service types can be implemented with a set of very similar
本文档介绍了internet的差异化服务体系结构。Dave Clark和Van Jacobson在慕尼黑IETF会议上分别介绍了差异化服务方面的工作[2,3]。每一个都解释了如何使用IP报头的一位向internet中的数据包提供一种新的服务。这是两种完全不同的服务，具有完全不同的政策假设。接下来的讨论使我们确信这两种服务类型都有优点，并且两种服务类型都可以用一组非常相似的代码来实现
mechanisms. We propose an architectural framework that permits the use of both of these service types and exploits their similarities in forwarding path mechanisms. The major goals of this architecture are each shared with one or both of those two proposals: keep the forwarding path simple, push complexity to the edges of the network to the extent possible, provide a service that avoids assumptions about the type of traffic using it, employ an allocation policy that will be compatible with both long-term and short-term provisioning, make it possible for the dominant Internet traffic model to remain best-effort.
机制。我们提出了一个架构框架，允许使用这两种服务类型，并利用它们在转发路径机制中的相似性。该体系结构的主要目标都与这两个方案中的一个或两个方案共享：保持转发路径简单，尽可能将复杂性推到网络边缘，提供避免对使用它的流量类型进行假设的服务，采用与长期和短期资源调配兼容的分配策略，使占主导地位的互联网流量模型保持最大努力。
The major contributions of this document are to present two distinct service types, a set of general mechanisms for the forwarding path that can be used to implement a range of differentiated services and to propose a flexible framework for provisioning a differentiated services network. It is precisely this kind of architecture that is needed for expedient deployment of differentiated services: we need a framework and set of primitives that can be implemented in the short-term and provide interoperable services, yet can provide a "sandbox" for experimentation and elaboration that can lead in time to more levels of differentiation within each service as needed.
本文档的主要贡献是介绍两种不同的服务类型，一组用于转发路径的通用机制，可用于实现一系列差异化服务，并提出一个灵活的框架，用于提供差异化服务网络。正是这种体系结构需要方便地部署差异化服务：我们需要一个框架和一组原语，可以在短期内实现，并提供可互操作的服务，同时还可以提供一个“沙箱”用于实验和细化，可以根据需要及时在每个服务中实现更高级别的差异化。
At the risk of belaboring an analogy, we are motivated to provide services tiers in somewhat the same fashion as the airlines do with first class, business class and coach class. The latter also has tiering built in due to the various restrictions put on the purchase. A part of the analogy we want to stress is that best effort traffic, like coach class seats on an airplane, is still expected to make up the bulk of internet traffic. Business and first class carry a small number of passengers, but are quite important to the economics of the airline industry. The various economic forces and realities combine to dictate the relative allocation of the seats and to try to fill the airplane. We don't expect that differentiated services will comprise all the traffic on the internet, but we do expect that new services will lead to a healthy economic and service environment.
冒着打个比方的风险，我们的动机是以与航空公司在头等舱、公务舱和经济舱相同的方式提供服务等级。由于对购买的各种限制，后者还内置了分层功能。我们想强调的一部分类比是，尽力而为的流量，就像飞机上的长途汽车座位一样，预计仍将构成互联网流量的大部分。商务舱和头等舱载客量很小，但对航空业的经济来说却相当重要。各种经济力量和现实结合起来决定了座位的相对分配，并试图填满飞机。我们并不期望差异化服务将包含互联网上的所有流量，但我们确实期望新服务将带来健康的经济和服务环境。
This document is organized into sections describing service architecture, mechanisms, the bandwidth allocation architecture, how this architecture might interoperate with RSVP/int-serv work, and gives recommendations for deployment.
本文档分为几个部分，描述服务体系结构、机制、带宽分配体系结构、此体系结构如何与RSVP/int serv工作互操作，并给出部署建议。
The current internet delivers one type of service, best-effort, to all traffic. A number of proposals have been made concerning the addition of enhanced services to the Internet. We focus on two particular methods of adding a differentiated level of service to IP, each designated by one bit [1,2,3]. These services represent a radical departure from the Internet's traditional service, but they are also a radical departure from traditional "quality of service" architectures which rely on circuit-based models. Both these proposals seek to define a single common mechanism that is used by interior network routers, pushing most of the complexity and state of differentiated services to the network edges. Both use bandwidth as the resource that is being requested and allocated. Clark and Wroclawski defined an "Assured" service that follows "expected capacity" usage profiles that are statistically provisioned [3]. The assurance that the user of such a service receives is that such traffic is unlikely to be dropped as long as it stays within the expected capacity profile. The exact meaning of "unlikely" depends on how well provisioned the service is. An Assured service traffic flow may exceed its Profile, but the excess traffic is not given the same assurance level. Jacobson defined a "Premium" service that is provisioned according to peak capacity Profiles that are strictly not oversubscribed and that is given its own high-priority queue in routers [2]. A Premium service traffic flow is shaped and hard-limited to its provisioned peak rate and shaped so that bursts are not injected into the network. Premium service presents a "virtual wire" where a flow's bursts may queue at the shaper at the edge of the network, but thereafter only in proportion to the indegree of each router. Despite their many similarities, these two approaches result in fundamentally different services. The former uses buffer management to provide a "better effort" service while the latter creates a service with little jitter and queueing delay and no need for queue management on the Premium packets's queue.
当前的互联网为所有流量提供一种类型的服务，即“尽力而为”。已经提出了一些关于在因特网上增加增强服务的建议。我们关注两种向IP添加区分服务级别的特殊方法，每种方法由一位指定[1,2,3]。这些服务与互联网的传统服务截然不同，但它们也与依赖于基于电路模型的传统“服务质量”体系结构截然不同。这两个方案都试图定义一个内部网络路由器使用的单一通用机制，将区分服务的大部分复杂性和状态推送到网络边缘。两者都使用带宽作为请求和分配的资源。Clark和Wroclawski定义了一个“有保证”的服务，该服务遵循统计配置的“预期容量”使用情况配置文件[3]。这种服务的用户收到的保证是，只要保持在预期的容量配置文件内，就不太可能丢弃这种流量。“不太可能”的确切含义取决于服务的配置情况。有保证的业务流量可能会超过其配置文件，但多余的流量不会获得相同的保证级别。Jacobson定义了一种“高级”服务，该服务是根据峰值容量配置文件提供的，严格来说，峰值容量配置文件没有超额订阅，并且在路由器中被赋予自己的高优先级队列[2]。优质服务业务流被成形并严格限制在其所提供的峰值速率内，并且成形为不将突发注入网络。高级服务提供了一种“虚拟线路”，其中流的突发可能在网络边缘的成形器处排队，但此后仅与每个路由器的等级成比例。尽管这两种方法有许多相似之处，但它们产生了根本不同的服务。前者使用缓冲区管理来提供“更好的努力”服务，而后者创建的服务具有较小的抖动和排队延迟，并且不需要对高级数据包的队列进行队列管理。
An Assured service was introduced in [3] by Clark and Wroclawski, though we have made some alterations in its specification for our architecture. Further refinements and an "Expected Capacity" framework are given in Clark and Fang [10]. This framework is focused on "providing different levels of best-effort service at times of network congestion" but also mentions that it is possible to have a separate router queue to implement a "guaranteed" level of assurance. We believe this framework and our Two-bit architecture are compatible but this needs further exploration. As Premium service has not been documented elsewhere, we describe it next and follow this with a description of the two-bit architecture.
Clark和Wroclawski在[3]中引入了一种有保证的服务，尽管我们对其架构规范做了一些修改。克拉克和方[10]给出了进一步的改进和“预期能力”框架。该框架的重点是“在网络拥塞时提供不同级别的尽力而为服务”，但也提到可以使用单独的路由器队列来实现“保证”级别的保证。我们相信这个框架和我们的两位架构是兼容的，但这需要进一步的探索。由于其他地方还没有对高级服务进行记录，我们接下来将对其进行描述，并在后面介绍两位体系结构。
In [2], a Premium service was presented that is fundamentally different from the Internet's current best effort service. This service is not meant to replace best effort but primarily to meet an emerging demand for a commercial service that can share the network with best effort traffic. This is desirable economically, since the same network can be used for both kinds of traffic. It is expected that Premium traffic would be allocated a small percentage of the total network capacity, but that it would be priced much higher. One use of such a service might be to create "virtual leased lines", saving the cost of building and maintaining a separate network. Premium service, not unlike a standard telephone line, is a capacity which the customer expects to be there when the receiver is lifted, although it may, depending on the household, be idle a good deal of the time. Provisioning Premium traffic in this way reduces the capacity of the best effort internet by the amount of Premium allocated, in the worst case, thus it would have to be priced accordingly. On the other hand, whenever that capacity is not being used it is available to best effort traffic. In contrast to normal best effort traffic which is bursty and requires queue management to deal fairly with congestive episodes, this Premium service by design creates very regular traffic patterns and small or nonexistent queues.
在[2]中，提出了一种与互联网当前的尽力而为服务根本不同的优质服务。这项服务并不是要取代尽力而为，而是主要是为了满足对能够与尽力而为流量共享网络的商业服务的新需求。这在经济上是可取的，因为相同的网络可用于两种流量。预计高级流量将分配到总网络容量的一小部分，但其价格将高得多。这种服务的一个用途可能是创建“虚拟租用线路”，从而节省构建和维护单独网络的成本。与标准电话线不同的是，优质服务是一种容量，当接收器被提起时，客户希望它在那里，尽管根据家庭情况，它可能在很多时候处于空闲状态。在最坏的情况下，以这种方式提供高级流量会将尽力而为的internet的容量减少分配的高级流量，因此必须对其进行相应的定价。另一方面，每当该容量未被使用时，它就可用于尽力而为的流量。与正常的尽力而为的流量不同，正常的尽力而为的流量是突发的，需要队列管理来公平地处理拥塞事件，这种优质服务通过设计创建非常规则的流量模式和小的或不存在的队列。
Premium service levels are specified as a desired peak bit-rate for a specific flow (or aggregation of flows). The user contract with the network is not to exceed the peak rate. The network contract is that the contracted bandwidth will be available when traffic is sent. First-hop routers (or other edge devices) filter the packets entering the network, set the Premium bit of those that match a Premium service specification, and perform traffic shaping on the flow that smooths all traffic bursts before they enter the network. This approach requires no changes in hosts. A compliant router along the path needs two levels of priority queueing, sending all packets with the Premium bit set first. Best-effort traffic is unmarked and queued and sent at the lower priority. This results in two "virtual networks": one which is identical to today's Internet with buffers designed to absorb traffic bursts; and one where traffic is limited and shaped to a contracted peak-rate, but packets move through a network of queues where they experience almost no queueing delay.
高级服务级别指定为特定流（或流的聚合）的期望峰值比特率。与网络签订的用户合同不得超过峰值速率。网络契约是指当发送流量时，契约带宽将可用。第一跳路由器（或其他边缘设备）过滤进入网络的数据包，设置与高级服务规范相匹配的数据包的高级位，并对流执行流量整形，以平滑所有流量突发，然后再进入网络。这种方法不需要更改主机。路径上的兼容路由器需要两级优先级排队，首先发送设置了高级位的所有数据包。尽力而为流量未标记、排队并以较低优先级发送。这导致了两个“虚拟网络”：一个与今天的互联网相同，其缓冲区设计用于吸收流量突发；在这种情况下，通信量是有限的，并形成一个收缩的峰值速率，但数据包通过一个队列网络移动，几乎没有排队延迟。
In this architecture, forwarding path decisions are made separately and more simply than the setting up of the service agreements and traffic profiles. With the exception of policing and shaping at administrative or "trust" boundaries, the only actions that need to be handled in the forwarding path are to classify a packet into one of two queues on a single bit and to service the two queues using
在此架构中，转发路径决策是单独做出的，比服务协议和流量配置文件的设置更简单。除了在管理或“信任”边界上进行管理和整形外，在转发路径中需要处理的唯一操作是在单个位上将数据包分类为两个队列中的一个，并使用
simple priority. Shaping must include both rate and burst parameters; the latter is expected to be small, in the one or two packet range. Policing at boundaries enforces rate compliance, and may be implemented by a simple token bucket. The admission and set-up procedures are expected to evolve, in time, to be dynamically configurable and fairly complex while the mechanisms in the forwarding path remain simple.
简单优先级。整形必须包括速率和突发参数；后者预计在一个或两个数据包范围内较小。边界警务强制执行费率遵从性，可以通过简单的令牌桶实现。接纳和设置过程预计会随着时间的推移而发展，动态可配置且相当复杂，而转发路径中的机制保持简单。
A Premium service built on this architecture can be deployed in a useful way once the forwarding path mechanisms are in place by making static allocations. Traffic flows can be designated for special treatment through network management configuration. Traffic flows should be designated by the source, the destination, or any combination of fields in the packet header. First-hop (of leaf) routers will filter flows on all or part of the header tuple consisting of the source IP address, destination IP address, protocol identifier, source port number, and destination port number. Based on this classification, a first-hop router performs traffic shaping and sets the designated Premium bit of the precedence field. End-hosts are thus not required to be "differentiated services aware", though if and when end-systems become universally "aware", they might do their own shaping and first-hop routers merely police.
一旦通过静态分配使转发路径机制就位，就可以以一种有用的方式部署基于此体系结构的高级服务。通过网络管理配置，可以指定流量进行特殊处理。流量应该由数据包头中的源、目的地或任何字段组合指定。第一跳（叶）路由器将过滤所有或部分头元组上的流，头元组由源IP地址、目标IP地址、协议标识符、源端口号和目标端口号组成。基于此分类，第一跳路由器执行流量整形并设置优先字段的指定高级位。因此，终端主机不需要“区分服务感知”，尽管当终端系统变得普遍“感知”时，它们可能会进行自己的成形和第一跳路由器。
Adherence to the subscribed rate and burst size must be enforced at the entry to the network, either by the end-system or by the first-hop router. Within an intranet, administrative domain, or "trust region" the packets can then be classified and serviced solely on the Premium bit. Where packets cross a boundary, the policing function is critical. The entered region will check the prioritized packet flow for conformance to a rate the two regions have agreed upon, discarding packets that exceed the rate. It is thus in the best interests of a region to ensure conformance to the agreed-upon rate at the egress. This requirement means that Premium traffic is burst-free and, together with the no oversubscription rule, leads directly to the observation that Premium queues can easily be sized to prevent the need to drop packets and thus the need for a queue management policy. At each router, the largest queue size is related to the in-degree of other routers and is thus quite small, on the order of ten packets.
终端系统或第一跳路由器必须在进入网络时强制遵守订阅速率和突发大小。在内部网、管理域或“信任区域”中，数据包可以单独在高级位上进行分类和服务。当数据包跨越边界时，监控功能至关重要。输入的区域将检查优先分组流是否符合两个区域商定的速率，丢弃超过该速率的分组。因此，确保出口符合商定的费率符合区域的最佳利益。这一要求意味着高级流量是无突发的，再加上无超额订阅规则，直接导致观察到高级队列的大小可以轻松调整，以防止丢弃数据包的需要，从而避免队列管理策略的需要。在每个路由器上，最大队列大小与其他路由器的in程度有关，因此非常小，大约为10个数据包。
Premium bandwidth allocations must not be oversubscribed as they represent a commitment by the network and should be priced accordingly. Note that, in this architecture, Premium traffic will also experience considerably less delay variation than either best effort traffic or the Assured data traffic of [3]. Premium rates might be configured on a subscription basis in the near-term, or on-demand when dynamic set-up or signaling is available.
特优带宽分配不得超额认购，因为它们代表了网络的承诺，应相应定价。注意，在该架构中，与尽力而为的流量或[3]的保证数据流量相比，高级流量也将经历相当少的延迟变化。保费费率可以在短期内按订阅配置，也可以在动态设置或信号可用时按需配置。
Figure 1 shows how a Premium packet flow is established within a particular administrative domain, Company A, and sent across the access link to Company A's ISP. Assume that the host's first-hop router has been configured to match a flow from the host's IP address to a destination IP address that is reached through ISP. A Premium flow is configured from a host with a rate which is both smaller than the total Premium allocation Company A has from the ISP, r bytes per second, and smaller than the amount of that allocation has been assigned to other hosts in Company A. Packets are not marked in any special way when they leave the host. The first-hop router clears the Premium bit on all arriving packets, sets the Premium bit on all packets in the designated flow, shapes packets in the Premium flow to a configured rate and burst size, queues best-effort unmarked packets in the low priority queue and shaped Premium packets in the high priority queue, and sends packets from those two queues at simple priority. Intermediate routers internal to Company A enqueue packets in one of two output queues based on the Premium bit and service the queues with simple priority. Border routers perform quite different tasks, depending on whether they are processing an egress flow or an ingress flow. An egress border router may perform some reshaping on the aggregate Premium traffic to conform to rate r, depending on the number of Premium flows aggregated. Ingress border routers only need to perform a simple policing function that can be implemented with a token bucket. In the example, the ISP accepts all Premium packets from A as long as the flow does not exceed r bytes per second.
图1显示了如何在特定的管理域a公司内建立高级数据包流，并通过接入链路发送到a公司的ISP。假设主机的第一跳路由器已配置为匹配从主机IP地址到通过ISP到达的目标IP地址的流。从主机配置特优流的速率既小于公司A从ISP获得的总特优分配（每秒r字节），也小于分配给公司A中其他主机的分配量。数据包离开主机时，不会以任何特殊方式进行标记。第一跳路由器清除所有到达分组上的高级比特，在指定流中的所有分组上设置高级比特，将高级流中的分组整形为配置的速率和突发大小，将尽力而为的未标记分组排队到低优先级队列中，将整形高级分组排队到高优先级队列中，并以简单的优先级从这两个队列发送数据包。A公司内部的中间路由器基于高级位将数据包排队到两个输出队列中的一个队列中，并以简单优先级为队列提供服务。边界路由器执行完全不同的任务，这取决于它们处理的是出口流还是入口流。出口边界路由器可以根据聚合的优质流的数量，对聚合的优质流量执行一些重塑以符合速率r。入口边界路由器只需要执行一个简单的监控功能，该功能可以通过令牌桶实现。在本例中，只要流量不超过每秒r字节，ISP就接受来自的所有高级数据包。
Figure 1. Premium traffic flow from end-host to organization's ISP
图1。从终端主机到组织ISP的高级流量
Clark's and Jacobson's proposals are markedly similar in the location and type of functional blocks that are needed to implement them. Furthermore, they implement quite different services which are not incompatible in a network. The Premium service implements a guaranteed peak bandwidth service with negligible queueing delay that cannot starve best effort traffic and can be allocated in a fairly straightforward fashion. This service would seem to have a strong appeal for commercial applications, video broadcasts, voice-over-IP, and VPNs. On the other hand, this service may prove both too restrictive (in its hard limits) and overdesigned (no overallocation) for some applications. The Assured service implements a service that has the same delay characteristics as (undropped) best effort packets and the firmness of its guarantee depends on how well individual links are provisioned for bursts of Assured packets. On the other hand, it permits traffic flows to use any additional available capacity without penalty and occasional dropped packets for short congestive periods may be acceptable to many users. This service might be what an ISP would provide to individual customers who are
克拉克和雅各布森的建议在实现它们所需的功能块的位置和类型上明显相似。此外，它们实现了完全不同的服务，这些服务在网络中并不不兼容。Premium服务实现了一个有保证的峰值带宽服务，其排队延迟可以忽略不计，不能耗尽最大努力流量，并且可以以相当简单的方式进行分配。这项服务似乎对商业应用、视频广播、IP语音和VPN具有强大的吸引力。另一方面，对于某些应用程序，此服务可能会被证明是限制性太强（在其硬限制中）和设计过度（没有过度分配）。保证服务实现的服务具有与（未减少的）尽力而为数据包相同的延迟特性，其保证的牢固性取决于为保证数据包的突发提供单个链路的程度。另一方面，它允许业务流使用任何额外的可用容量而不受惩罚，许多用户可以接受在短拥挤期内偶尔丢弃的数据包。这项服务可能是ISP提供给个人客户的服务
willing to pay a bit more for internet service that seems unaffected by congestive periods. Both services are only as good as their admission control schemes, though this can be more difficult for traffic which is not peak-rate allocated.
愿意为似乎不受拥挤期影响的互联网服务多付一点钱。这两种服务的性能都与它们的准入控制方案一样好，尽管对于未分配峰值速率的流量来说，这可能更困难。
There may be some additional benefits of deploying both services. To the extent that Premium service is a conservative allocation of resources, unused bandwidth that had been allocated to Premium might provide some "headroom" for underallocated or burst periods of Assured traffic or for best effort. Network elements that deploy both services will be performing RED queue management on all non-Premium traffic, as suggested in [4], and the effects of mixing the Premium streams with best effort might serve to reduce burstiness in the latter. A strength of the Assured service is that it allows bursts to happen in their natural fashion, but this also makes the provisioning, admission control and allocation problem more difficult so it may take more time and experimentation before this admission policy for this service is completely defined. A Premium service could be deployed that employs static allocations on peak rates with no statistical sharing.
部署这两种服务可能还有一些额外的好处。在某种程度上，高级服务是一种保守的资源分配，分配给高级服务的未使用带宽可能会为分配不足或保证流量的突发时段或尽最大努力提供一些“净空”。部署这两种服务的网元将对所有非高级流量执行红色队列管理，如[4]所示，将高级流与尽力而为混合的效果可能有助于减少后者的突发性。有保证的服务的一个优点是它允许突发以其自然方式发生，但这也使得供应、许可控制和分配问题更加困难，因此在完全定义此服务的许可策略之前，可能需要更多的时间和实验。可以部署一个高级服务，在峰值速率上使用静态分配，而不进行统计共享。
As there appear to be a number of advantages to an architecture that permits these two types of service and because, as we shall see, they can be made to share many of the same mechanisms, we propose designating two bit-patterns from the IP header precedence field. We leave the explicit designation of these bit-patterns to the standards process thus we use the shorthand notation of denoting each pattern by a bit, one we will call the Premium or P-bit, the other we call the assurance or A-bit. It is possible for a network to implement only one of these services and to have network elements that only look at the one applicable bit, but we focus on the two service architecture. Further, we assume the case where no changes are made in the hosts, appropriate packet marking all being done in the network, at the first-hop, or leaf, router. We describe the forwarding path architecture in this section, assuming that the service has been allocated through mechanisms we will discuss in section 4.
由于允许这两种类型的服务的体系结构似乎有许多优点，而且正如我们将看到的，它们可以共享许多相同的机制，因此我们建议从IP报头优先级字段指定两位模式。我们将这些位模式的显式指定留给标准流程，因此我们使用一位表示每个模式的简写符号，一个我们称为高级或P位，另一个我们称为保证或a位。网络可能只实现这些服务中的一个，并且网络元素只查看一个适用的位，但是我们重点关注两个服务架构。此外，我们假设在主机中不做任何更改的情况下，在第一跳或叶路由器上，在网络中进行适当的分组标记。我们在本节中描述了转发路径体系结构，假设服务是通过我们将在第4节中讨论的机制分配的。
In a more general sense, Premium service denotes packets that are enqueued at a higher priority than the ordinary best-effort queue. Similarly, Assured service denotes packets that are treated preferentially with respect to the dropping probability within the "normal" queue. There are a number of ways to add more service levels within each of these service types [7], but this document takes the position of specifying the base-level services of Premium and Assured.
在更一般的意义上，高级服务表示以比普通尽力而为队列更高的优先级排队的数据包。类似地，保证服务表示相对于“正常”队列内的丢弃概率优先处理的分组。有许多方法可以在这些服务类型中添加更多的服务级别[7]，但本文档的立场是指定Premium和Assured的基本级别服务。
The forwarding path mechanisms can be broken down into those that happen at the input interface, before packet forwarding, and those that happen at the output interface, after packet forwarding. Intermediate routers only need to implement the post packet forwarding functions, while leaf and border routers must perform functions on arriving packets before forwarding. We describe the mechanisms this way for illustration; other ways of composing their functions are possible.
转发路径机制可分为发生在输入接口的转发前的机制和发生在输出接口的转发后的机制。中间路由器只需要实现包后转发功能，而叶子和边界路由器必须在转发前对到达的包执行功能。我们以这种方式描述了这些机制以供说明；其他组成其功能的方式也是可能的。
Leaf routers are configured with a traffic profile for a particular flow based on its packet header. This functionality has been defined by the RSVP Working Group in RFC 2205. Figure 2 shows what happens to a packet that arrives at the leaf router, before it is passed to the forwarding engine. All arriving packets must have both the A-bit and the P-bit cleared after which packets are classified on their header. If the header does not match any configured values, it is immediately forwarded. Matched flows pass through individual Markers that have been configured from the usage profile for that flow: service class (Premium or Assured), rate (peak for Premium, "expected" for Assured), and permissible burst size (may be optional for Premium). Assured flow packets emerge from the Marker with their A-bits set when the flow is in conformance to its Profile, but the flow is otherwise unchanged. For a Premium flow, the Marker will hold packets when necessary to enforce their configured rate. Thus Premium flow packets emerge from the Marker in a shaped flow with their P-bits set. (It is possible for Premium flow packets to be dropped inside of the Marker as we describe below.) Packets are passed to the forwarding engine when they emerge from Markers. Packets that have either their P or A bits set we will refer to as Marked packets.
叶路由器根据其包头为特定流配置流量配置文件。该功能已由RSVP工作组在RFC 2205中定义。图2显示了到达叶路由器的数据包在传递到转发引擎之前会发生什么。所有到达的数据包必须清除A位和P位，然后在其报头上对数据包进行分类。如果标头与任何配置的值不匹配，则会立即转发。匹配的流通过已从该流的使用配置文件中配置的单个标记：服务级别（特优或有保证）、速率（特优为峰值，“预期”为有保证）和允许的突发大小（特优为可选）。当流符合其概要文件时，有保证的流数据包从标记中出现，并设置其A位，但流在其他方面保持不变。对于高级流，标记将在必要时保留数据包以强制其配置的速率。因此，优质流分组以其P比特集的成形流从标记中出现。（高级流数据包可能被丢弃在标记内部，如下所述。）当数据包从标记中出现时，数据包被传递到转发引擎。设置了P或A位的数据包我们称之为标记数据包。
Figure 2. Block diagram of leaf router input functionality
图2。叶路由器输入功能框图
Figure 3 shows the inner workings of the Marker. For both Assured and Premium packets, a token bucket "fills" at the flow rate that was specified in the usage profile. For Assured service, the token bucket depth is set by the Profile's burst size. For Premium service, the token bucket depth must be limited to the equivalent of only one or two packets. (We suggest a depth of one packet in early deployments.) When a token is present, Assured flow packets have their A-bit set to one, otherwise the packet is passed to the forwarding engine. For Premium-configured Marker, arriving packets that see a token present have their P-bits set and are forwarded, but when no token is present, Premium flow packets are held until a token arrives. If a Premium flow bursts enough to overflow the holding queue, its packets will be dropped. Though the flow set up data can be used to configure a size limit for the holding queue (this would be the meaning of a "burst" in Premium service), it is not necessary. Unconfigured holding queues should be capable of holding at least two bandwidth-
图3显示了标记器的内部工作方式。对于保证数据包和高级数据包，令牌桶都会以使用情况配置文件中指定的流速“填充”。为了保证服务，令牌桶深度由配置文件的突发大小设置。对于高级服务，令牌桶深度必须限制为仅相当于一个或两个数据包。（我们建议在早期部署中深度为一个数据包。）当令牌存在时，保证流数据包将其a位设置为1，否则数据包将传递给转发引擎。对于高级配置标记，看到令牌存在的到达数据包将设置其P位并进行转发，但当不存在令牌时，高级流数据包将一直保持到令牌到达。如果高级流爆发到足以使保留队列溢出，则其数据包将被丢弃。尽管流设置数据可用于配置等待队列的大小限制（这在高级服务中是“突发”的意思），但这并不是必需的。未配置的等待队列应能够容纳至少两个带宽-
delay products, adequate for TCP connections. A smaller value might be used to suit delay requirements of a specific application.
延迟产品，适用于TCP连接。较小的值可用于满足特定应用程序的延迟要求。
Figure 3. Markers to implement the two different services
图3。标记来实现这两种不同的服务
In practice, the token bucket should be implemented in bytes and a token is considered to be present if the number of bytes in the bucket is equal or larger to the size of the packet. For Premium, the bucket can only be allowed to fill to the maximum packet size; while Assured may fill to the configured burst parameter. Premium traffic is held until a sufficient byte credit has accumulated and this holding buffer provides the only real queue the flow sees in the network. For Assured, traffic, we just test if the bytes in the bucket are sufficient for the packet size and set A if so. If not, the only difference is that A is not set. Assured traffic goes into a queue following this step and potentially sees a queue at every hop along its path.
实际上，令牌桶应以字节为单位实现，如果桶中的字节数等于或大于数据包的大小，则认为存在令牌。对于Premium，桶只能填充到最大数据包大小；虽然有保证，但可以填充配置的突发参数。高级流量被保持，直到积累了足够的字节信用，并且此保持缓冲区提供了流在网络中看到的唯一真实队列。为了保证流量，我们只需测试bucket中的字节是否足以满足数据包大小，并设置一个if。如果没有，唯一的区别是没有设置。有保证的流量在此步骤后进入队列，并可能在其路径上的每个跃点处看到队列。
Each output interface of a router must have two queues and must implement a test on the P-bit to select a packet's output queue. The two queues must be serviced by simple priority, Premium packets first. Each output interface must implement the RED-based RIO mechanism described in [3] on the lower priority queue. RIO uses two thresholds for when to begin dropping packets, a lower one based on total queue occupancy for ordinary best effort traffic and one based on the number of packets enqueued that have their A-bit set. This means that any action preferential to Assured service traffic will only be taken when the queue's capacity exceeds the threshold value for ordinary best effort service. In this case, only unmarked packets will be dropped (using the RED algorithm) unless the threshold value for Assured service is also reached. Keeping an accurate count of the number of A-bit packets currently in a queue requires either testing the A-bit at both entry and exit of the queue or some additional state in the router. Figure 4 is a block diagram of the output interface for all routers.
路由器的每个输出接口必须有两个队列，并且必须对P位执行测试以选择数据包的输出队列。这两个队列必须首先由简单优先级、高级数据包提供服务。每个输出接口必须在低优先级队列上实现[3]中描述的基于红色的RIO机制。RIO使用两个阈值来确定何时开始丢弃数据包，一个较低的阈值基于普通尽力而为流量的总队列占用率，另一个阈值基于已设置a位的已排队数据包数。这意味着只有当队列的容量超过普通尽力而为服务的阈值时，才会采取优先于保证服务流量的任何操作。在这种情况下，只有未标记的数据包才会被丢弃（使用RED算法），除非也达到了保证服务的阈值。保持队列中当前A位数据包数量的准确计数需要在队列的入口和出口测试A位，或者在路由器中测试其他一些状态。图4是所有路由器的输出接口框图。
Figure 4. Router output interface for two-bit architecture
图4。两位结构的路由器输出接口
The packet output of a leaf router is thus a shaped stream of packets with P-bits set mingled with an unshaped best effort stream of packets, some of which may have A-bits set. Premium service clearly cannot starve best effort traffic because it is both burst and bandwidth controlled. Assured service might rely only on a conservative allocation to prevent starvation of unmarked traffic, but bursts of Assured traffic might then close out best-effort traffic at bottleneck queues during congestive periods.
因此，叶路由器的分组输出是具有P比特集的成形分组流与未成形尽力而为分组流混合，其中一些分组可能具有a比特集。优质服务显然不能耗尽尽力而为的流量，因为它同时受突发和带宽控制。有保证的服务可能只依赖于保守的分配，以防止无标记的通信量不足，但有保证的通信量的突发可能会在拥塞期间关闭瓶颈队列中的尽力而为通信量。
After [3], we designate the forwarding path objects that test flows against their usage profiles "Profile Meters". Border routers will require Profile Meters at their input interfaces. The bilateral agreement between adjacent administrative domains must specify a peak rate on all P traffic and a rate and burst for A traffic (and possibly a start time and duration). A Profile Meter is required at the ingress of a trust region to ensure that differentiated service packet flows are in compliance with their agreed-upon rates. Non-compliant packets of Premium flows are discarded while non-compliant packets of Assured flows have their A-bits reset. For example, in figure 1, if the ISP has agreed to supply Company A with r bytes/sec of Premium service, P-bit marked packets that enter the ISP through the link from Company A will be dropped if they exceed r. If instead, the service in figure 1 was Assured service, the packets would simply be unmarked, forwarded as best effort.
在[3]之后，我们将根据其使用配置文件测试流的转发路径对象指定为“Profile Meters”。边界路由器在其输入接口处需要配置文件仪表。相邻管理域之间的双边协议必须指定所有P流量的峰值速率以及流量的速率和突发（以及可能的开始时间和持续时间）。在信任区域的入口需要配置文件表，以确保区分服务分组流符合其约定的速率。高级流的不兼容数据包被丢弃，而保证流的不兼容数据包的A位被重置。例如，在图1中，如果ISP已同意向A公司提供r字节/秒的高级服务，则通过A公司的链路进入ISP的P位标记数据包将在超过r字节/秒时丢弃。相反，如果图1中的服务是有保证的服务，则数据包将被取消标记，并作为尽力而为的方式转发。
The simplest border router input interface is a Profile Meter constructed from a token bucket configured with the contracted rate across that ingress link (see figure 5). Each type, Premium or Assured, and each interface must have its own profile meter corresponding to a particular class across a particular boundary. (This is in contrast to models where every flow that crosses the boundary must be separately policed and/or shaped.) The exact mechanisms required at a border router input interface depend on the allocation policy deployed; a more complex approach is presented in section 4.
最简单的边界路由器输入接口是一个配置文件表，它由一个令牌桶构造而成，该令牌桶配置为通过该入口链路的约定速率（见图5）。每种类型（高级或有保证）以及每种接口都必须有自己的剖面仪，对应于特定边界上的特定类别。（这与每个跨越边界的流都必须单独进行策略和/或成形的模型形成对比。）边界路由器输入接口所需的确切机制取决于部署的分配策略；第4节介绍了一种更复杂的方法。
Figure 5. Border router input interface Profile Meters
图5。边界路由器输入接口配置表
Section 2.3 introduced the forwarding path objects of Markers and Profile Meters. In this section we specify the primitive building blocks required to compose them. The primitives are: general classifier, bit-pattern classifier, bit setter, priority queues, policing token bucket and shaping token bucket. These primitives can compose a Marker (either a policing or a shaping token bucket plus a bit setter) and a Profile Meter (a policing token bucket plus a dropper or bit setter).
第2.3节介绍了标记和剖面仪的转发路径对象。在本节中，我们将指定组成它们所需的基本构建块。原语包括：通用分类器、位模式分类器、位设置器、优先级队列、策略令牌桶和整形令牌桶。这些原语可以组成一个标记（一个管理或成形令牌桶加一个位设置器）和一个配置表（一个管理令牌桶加一个滴管或位设置器）。
General Classifier: Leaf or first-hop routers must perform a transport-level signature matching based on a tuple in the packet header, a functionality which is part of any RSVP-capable router. As described above, packets whose tuples match one of the configured flows are conformance tested and have the appropriate service bit set. This function is memory- and processing-intensive, but is kept
通用分类器：叶或第一跳路由器必须基于包头中的元组执行传输级签名匹配，这是任何支持RSVP的路由器的一部分。如上所述，元组与配置流之一匹配的数据包经过一致性测试，并设置了适当的服务位。此功能是内存和处理密集型的，但会保留
at the edges of the network where there are fewer flows.
在流量较少的网络边缘。
Bit-pattern classifier: This primitive comprises a simple two-way decision based on whether a particular bit-pattern in the IP header is set or not. As in figure 4, the P-bit is tested when a packet arrives at a non-leaf router to determine whether to enqueue it in the high priority output queue or the low priority packet queue. The A-bit of packets bound for the low priority queue is tested to 1) increment the count of Assured packets in the queue if set and 2) determine which drop probability will be used for that packet. Packets exiting the low priority queue must also have the A-bit tested so that the count of enqueued Assured packets can be decremented if necessary.
位模式分类器：该原语包括一个简单的双向决策，该决策基于IP报头中是否设置了特定位模式。如图4所示，当数据包到达非叶路由器时，测试P位，以确定是将其排入高优先级输出队列还是低优先级数据包队列。测试为低优先级队列绑定的A位数据包，以1）增加队列中已确定数据包的计数（如果设置），2）确定该数据包将使用哪个丢弃概率。退出低优先级队列的数据包还必须进行A位测试，以便在必要时减少排队的有保证数据包的计数。
Bit setter: The A-bits and P-bits must be set or cleared in several places. A functional block that sets the appropriate bits of the IP header to a configured bit-pattern would be the most general.
位设置器：必须在多个位置设置或清除A位和P位。将IP报头的适当位设置为配置的位模式的功能块是最通用的。
Priority queues: Every network element must include (at least) two levels of simple priority queueing. The high priority queue is for the Premium traffic and the service rule is to send packets in that queue first and to exhaustion. Recall that Premium traffic must never be oversubscribed, thus Premium traffic should see little or no queue.
优先级队列：每个网元必须包括（至少）两级简单优先级队列。高优先级队列用于高级流量，服务规则是首先在该队列中发送数据包，然后耗尽。回想一下，高级流量决不能被超额订阅，因此高级流量应该很少或根本看不到队列。
Shaping token bucket:This is the token bucket required at the leaf router for Premium traffic and shown in figure 3. As we shall see, shaping is also useful at egress points of a trust region. An arriving packet is immediately forwarded if there is a token present in the bucket, otherwise the packet is enqueued until the bucket contains tokens sufficient to send it. Shaping requires clocking mechanisms, packet memory, and some state block for each flow and is thus a memory and computation-intensive process.
成形令牌桶：这是叶路由器为高级流量所需的令牌桶，如图3所示。正如我们将看到的，整形在信任区域的出口点也很有用。如果bucket中存在令牌，则到达的数据包将立即转发，否则数据包将排队，直到bucket包含足以发送它的令牌为止。整形需要时钟机制、数据包内存和每个流的一些状态块，因此是一个内存和计算密集型过程。
Policing token bucket: This is the token bucket required for Profile Meters and shown in figure 5. Policing token buckets never hold arriving packets, but check on arrival to see if a token is available for the packet's service class. If so, the packet is forwarded immediately. If not, the policing action is taken, dropping for Premium and reclassifying or unmarking for Assured.
Policing token bucket：这是配置文件仪表所需的令牌bucket，如图5所示。监控令牌桶从不保存到达的数据包，但在到达时检查令牌是否可用于数据包的服务类。如果是这样，则立即转发数据包。如果没有，则采取监管行动，降低保费，重新分类或取消标记以确保安全。
Clearly, mechanisms are required to communicate the information about the request to the leaf router. This configuration information is the rate, burst, and whether it is a Premium or Assured type. There may also need to be a specific field to set or clear this configuration. This information can be passed in a number of ways,
显然，需要机制将有关请求的信息传递给叶路由器。此配置信息是速率、突发以及是高级还是有保证类型。可能还需要一个特定字段来设置或清除此配置。这些信息可以通过多种方式传递，
including using the semantics of RSVP, SNMP, or directly set by a network administrator in some other way. There must be some mechanisms for authenticating the sender of this information. We expect configuration to be done in a variety of ways in early deployments and a protocol and mechanism for this to be a topic for future standards work.
包括使用RSVP、SNMP的语义，或由网络管理员以其他方式直接设置。必须有一些机制来验证此信息的发送者。我们期望在早期部署中以各种方式进行配置，并且为此制定的协议和机制将成为未来标准工作的主题。
The requirements of shapers motivate their placement at the edges of the network where the state per router can be smaller than in the middle of a network. The greatest burden of flow matching and shaping will be at leaf routers where the speeds and buffering required should be less than those that might be required deeper in the network. This functionality is not required at every network element on the path. Routers that are internal to a trust region will not need to shape traffic. Border routers may need or desire to shape the aggregate flow of Marked packets at their egress in order to ensure that they will not burst into non-compliance with the policing mechanism at the ingress to the other domain (though this may not be necessary if the in-degree of the router is low). Further, the shaping would be applied to an aggregation of all the Premium flows that exit the domain via that path, not to each flow individually.
整形器的要求促使它们放置在网络的边缘，其中每个路由器的状态可以小于网络中间的状态。流量匹配和成形的最大负担将出现在叶路由器上，在叶路由器上，所需的速度和缓冲应小于网络中较深部分可能需要的速度和缓冲。路径上的每个网络元素都不需要此功能。信任区域内部的路由器不需要调整流量。边界路由器可能需要或希望在其出口处形成标记分组的聚合流，以确保它们不会在进入另一个域时突发不符合策略机制（尽管如果路由器的进入程度较低，这可能不是必需的）。此外，成形将应用于经由该路径退出域的所有溢价流的聚合，而不是单独应用于每个流。
These mechanisms are within reach of today's technology and it seems plausible to us that Premium and Assured services are all that is needed in the Internet. If, in time, these services are found insufficient, this architecture provides a migration path for delivering other kinds of service levels to traffic. The A- and P-bits would continue to be used to identify traffic that gets Marked service, but further filter matching could be done on packet headers to differentiate service levels further. Using the bits this way reduces the number of packets that have to have further matching done on them rather than filtering every incoming packet. More queue levels and more complex scheduling could be added for P-bit traffic and more levels of drop priority could be added for A-bit traffic if experience shows them to be necessary and processing speeds are sufficient. We propose that the services described here be considered as "at least" services. Thus, a network element should at least be capable of mapping all P-bit traffic to Premium service and of mapping all A-bit traffic to be treated with one level of priority in the "best effort" queue (it appears that the single level of A-bit traffic should map to a priority that is equivalent to the best level in a multi-level element that is also in the path).
这些机制在当今的技术范围内，我们似乎相信，互联网所需要的就是优质和有保障的服务。如果及时发现这些服务不足，此体系结构将提供一条迁移路径，用于向流量提供其他类型的服务级别。A位和P位将继续用于标识标记了服务的流量，但可以在数据包头上进行进一步的过滤器匹配，以进一步区分服务级别。以这种方式使用位可以减少需要对其进行进一步匹配的数据包数量，而不是过滤每个传入数据包。如果经验表明有必要且处理速度足够，则可以为P位流量添加更多队列级别和更复杂的调度，并为A位流量添加更多丢弃优先级级别。我们建议将此处描述的服务视为“至少”服务。因此，网络元件应当至少能够将所有P比特业务映射到高级服务，并且能够映射将在“尽力而为”队列中以一个优先级处理的所有a比特业务（看起来，一位流量的单一级别应该映射到与路径中的多级元素中的最佳级别等效的优先级）。
On the other hand, what is the downside of deploying an architecture for both classes of service if later experience convinces us that only one of them is needed? The functional blocks of both service
另一方面，如果后来的经验让我们确信只需要其中一种服务，那么为这两种服务部署体系结构的缺点是什么？这两个服务的功能块
classes are similar and can be provided by the same mechanism, parameterized differently. If Assured service is not used, very little is lost. A RED-managed best effort queue has been strongly recommended in [4] and, to the extent that the deployment of this architecture pushes the deployment of RED-managed best effort queues, it is clearly a positive. If Premium service goes unused, the two-queues with simple priority service is not required and the shaping function of the Marker may be unused, thus these would impose an unnecessary implementation cost.
类是相似的，可以由相同的机制提供，但参数化方式不同。如果不使用有保证的服务，损失很小。[4]中强烈建议使用RED管理的尽力而为队列，并且在该体系结构的部署推动了RED管理的尽力而为队列的部署的情况下，这显然是一个积极的结果。如果高级服务未使用，则不需要具有简单优先级服务的两个队列，并且标记的成形功能可能未使用，因此这些将带来不必要的实现成本。
Thus far we have focused on the service definitions and the forwarding path mechanisms. We now turn to the problem of allocating the level of Marked traffic throughout the Internet. We observe that most organizations have fixed portions of their budgets, including data communications, that are determined on an annual or quarterly basis. Some additional monies might be attached to specific projects for discretionary costs that arise in the shorter term. In turn, service providers (ISPs and NSPs) must do their planning on annual and quarterly bases and thus cannot be expected to provide differentiated services purely "on call". Provisioning sets up static levels of Marked traffic while call set-up creates an allocation of Marked traffic for a single flow's duration. Static levels can be provisioned with time-of-day specifications, but cannot be changed in response to a dynamic message. We expect both kinds of bandwidth allocation to be important. The purchasers of Marked services can generally be expected to work on longer-term budget cycles where these services will be accounted for similarly to many information services today. A mail-order house may wish to purchase a fixed allocation of bandwidth in and out of its web-server to give potential customers a "fast" feel when browsing their site. This allocation might be based on hit rates of the previous quarter or some sort of industry-based averages. In addition, there needs to be a dynamic allocation capability to respond to particular events, such as a demonstration, a network broadcast by a company's CEO, or a particular network test. Furthermore, a dynamic capability may be needed in order to meet a precommitted service level when the particular source or destination is allowed to be "anywhere on the Internet". "Dynamic" covers the range from a telephoned or e-mailed request to a signalling type model. A strictly statically allocated scenario is expected to be useful in initial deployment of differentiated services and to make up a major portion of the Marked traffic for the forseeable future.
到目前为止，我们主要关注服务定义和转发路径机制。现在，我们转向在整个互联网上分配标记流量的问题。我们观察到，大多数组织的预算（包括数据通信）都有固定的部分，这些部分是每年或每季度确定的。一些额外的资金可能会附加到特定的项目中，用于短期内产生的可自由支配成本。反过来，服务提供商（ISP和NSP）必须每年和每季度进行规划，因此不能期望纯粹“随叫随到”地提供差异化服务。设置设置标记流量的静态级别，而呼叫设置为单个流的持续时间创建标记流量的分配。可以使用时间规格设置静态级别，但不能响应动态消息而更改。我们希望这两种带宽分配都很重要。标记服务的购买者通常会在较长期的预算周期内工作，这些服务的核算方式与当今的许多信息服务类似。邮购公司可能希望在其web服务器内外购买固定的带宽分配，以便在潜在客户浏览其网站时给他们一种“快速”的感觉。这种分配可能基于上一季度的命中率或某种基于行业的平均值。此外，还需要动态分配功能来响应特定事件，例如演示、公司CEO的网络广播或特定的网络测试。此外，当特定源或目的地被允许在“互联网上的任何地方”时，可能需要动态能力以满足预先提交的服务级别。“动态”涵盖从电话或电子邮件请求到信令类型模型的范围。严格静态分配的场景有望在区分服务的初始部署中发挥作用，并在可预见的未来构成标记流量的主要部分。
Without a "per call" dynamic set up, the preconfiguring of usage profiles can always be construed as "paying for bits you don't use" whether the type of service is Premium or Assured. We prefer to think
如果没有“每次通话”的动态设置，使用情况配置文件的预配置总是可以解释为“为未使用的比特付费”，无论服务类型是高级服务还是有保证的服务。我们更喜欢思考
of this as paying for the level of service that one expects to have available at any time, for example paying for a telephone line. A customer might pay an additional flat fee to have the privilege of calling a wide local area for no additional charge or might pay by the call. Although a customer might pay on a "per call" basis for every call made anywhere, it generally turns out not to be the most economical option for most customers. It's possible similar pricing structures might arise in the internet.
这其中包括为人们期望在任何时候都能获得的服务水平付费，例如为电话线付费。客户可能会支付额外的固定费用，以获得无需额外收费就可以拨打广域电话的特权，或者可能会通过电话付费。尽管客户可能会在“每次通话”的基础上为任何地点的每次通话付费，但对于大多数客户来说，这通常不是最经济的选择。互联网上可能会出现类似的定价结构。
We use Allocation to refer to the process of making Marked traffic commitments anywhere along this continuum from strictly preallocated to dynamic call set-up and we require an Allocation architecture capable of encompassing this entire spectrum in any mix. We further observe that Allocation must follow organizational hierarchies, that is each organization must have complete responsibility for the Allocation of the Marked traffic resource within its domain. Finally, we observe that the only chance of success for incremental deployment lies in an Allocation architecture that is made up of bilateral agreements, as multilateral agreements are much too complex to administer. Thus, the Allocation architecture is made up of agreements across boundaries as to the amount of Marked traffic that will be allowed to pass. This is similar to "settlement" models used today.
我们使用分配指的是在这个连续统一体的任何地方做出标记流量承诺的过程，从严格的预分配到动态呼叫设置，我们需要一个能够在任何混合中包含整个频谱的分配架构。我们进一步观察到，分配必须遵循组织层次结构，即每个组织必须完全负责在其域内分配标记的流量资源。最后，我们注意到，增量部署的唯一成功机会在于由双边协议组成的分配架构，因为多边协议过于复杂，难以管理。因此，分配架构由关于允许通过的标记通信量的跨边界协议组成。这类似于今天使用的“结算”模式。
The goal of differentiated services is controlled sharing of some organization's Internet bandwidth. The control can be done independently by individuals, i.e., users set bit(s) in their packets to distinguish their most important traffic, or it can be done by agents that have some knowledge of the organization's priorities and policies and allocate bandwidth with respect to those policies. Independent labeling by individuals is simple to implement but unlikely to be sufficient since it's unreasonable to expect all individuals to know all their organization's priorities and current network use and always mark their traffic accordingly. Thus this architecture is designed with agents called bandwidth brokers (BB) [2], that can be configured with organizational policies, keep track of the current allocation of marked traffic, and interpret new requests to mark traffic in light of the policies and current allocation.
区分服务的目标是控制共享某些组织的Internet带宽。控制可以由个人独立完成，即用户在其数据包中设置位以区分其最重要的流量，也可以由对组织的优先级和策略有一定了解并根据这些策略分配带宽的代理完成。由个人进行独立标记很容易实现，但不太可能足够，因为期望所有个人都知道其组织的所有优先级和当前网络使用情况并始终相应地标记其流量是不合理的。因此，该体系结构使用称为带宽代理（BB）[2]的代理进行设计，这些代理可以配置组织策略，跟踪标记流量的当前分配，并根据策略和当前分配解释标记流量的新请求。
We note that such agents are inherent in any but the most trivial notions of sharing. Neither individuals nor the routers their packets transit have the information necessary to decide which packets are most important to the organization. Since these agents must exist, they can be used to allocate bandwidth for end-to-end connections with far less state and simpler trust relationships than
我们注意到，除了最琐碎的共享概念外，这些代理都是与生俱来的。个人或其数据包传输的路由器都没有必要的信息来决定哪些数据包对组织最重要。由于这些代理必须存在，因此它们可以用于为端到端连接分配带宽，而端到端连接的状态和信任关系要比其他代理少得多
deploying per flow or per filter guarantees in all network elements on an end-to-end path. BBs make it possible for bandwidth allocation to follow organizational hierarchies and, in concert with the forwarding path mechanisms discussed in section 3, reduce the state required to set up and maintain a flow over architectures that require checking the full flow header at every network element. Organizationally, the BB architecture is motivated by the observation that multilateral agreements rarely work and this architecture allows end-to-end services to be constructed out of purely bilateral agreements. BBs only need to establish relationships of limited trust with their peers in adjacent domains, unlike schemes that require the setting of flow specifications in routers throughout an end-to-end path. In practical technical terms, the BB architecture makes it possible to keep state on an administrative domain basis, rather than at every router and the service definitions of Premium and Assured service make it possible to confine per flow state to just the leaf routers.
在端到端路径上的所有网元中部署每流或每筛选器保证。BBs使带宽分配能够遵循组织层次结构，并与第3节中讨论的转发路径机制相一致，减少建立和维护需要在每个网络元素上检查完整流报头的跨流架构所需的状态。在组织上，BB架构的动机是观察到多边协议很少起作用，这种架构允许端到端服务由纯双边协议构建。BBs只需要与相邻域中的对等方建立有限信任关系，这与需要在整个端到端路径的路由器中设置流规范的方案不同。在实际技术术语中，BB体系结构使其能够在管理域的基础上保持状态，而不是在每个路由器上，并且优质和有保证服务的服务定义使其能够将每个流状态仅限于叶路由器。
BBs have two responsibilities. Their primary one is to parcel out their region's Marked traffic allocations and set up the leaf routers within the local domain. The other is to manage the messages that are sent across boundaries to adjacent regions' BBs. A BB is associated with a particular trust region, one per domain. A BB has a policy database that keeps the information on who can do what when and a method of using that database to authenticate requesters. Only a BB can configure the leaf routers to deliver a particular service to flows, crucial for deploying a secure system. If the deployment of Differentiated Services has advanced to the stage where dynamically allocated, marked flows are possible between two adjacent domains, BBs also provide the hook needed to implement this. Each domain's BB establishes a secure association with its peer in the adjacent domain to negotiate or configure a rate and a service class (Premium or Assured) across the shared boundary and through the peer's domain. As we shall see, it is possible for some types of service and particularly in early implementations, that this "secure association" is not automatic but accomplished through human negotiation and subsequent manual configuration of the adjacent BBs according to the negotiated agreement. This negotiated rate is a capability that a BB controls for all hosts in its region.
BBs有两个职责。他们的主要任务是划分他们所在区域的标记流量分配，并在本地域内设置叶路由器。另一个是管理跨边界发送到相邻区域BBs的消息。BB与特定的信任区域相关联，每个域一个。BB有一个策略数据库，它保存关于谁可以在何时做什么的信息以及使用该数据库对请求者进行身份验证的方法。只有BB可以配置叶路由器以向流提供特定服务，这对于部署安全系统至关重要。如果区分服务的部署已经发展到可以在两个相邻域之间动态分配标记流的阶段，BBs还提供了实现这一点所需的钩子。每个域的BB与相邻域中的对等方建立安全关联，以便跨共享边界并通过对等方的域协商或配置速率和服务类别（高级或有保证）。正如我们将看到的，对于某些类型的服务，特别是在早期实现中，这种“安全关联”可能不是自动的，而是通过人工协商和随后根据协商的协议手动配置相邻BBs来实现的。此协商速率是BB控制其区域内所有主机的能力。
When an allocation is desired for a particular flow, a request is sent to the BB. Requests include a service type, a target rate, a maximum burst, and the time period when service is required. The request can be made manually by a network administrator or a user or it might come from another region's BB. A BB first authenticates the credentials of the requester, then verifies there exists unallocated bandwidth sufficient to meet the request. If a request passes these tests, the available bandwidth is reduced by the requested amount and
当需要为特定流分配时，向BB发送请求。请求包括服务类型、目标速率、最大突发和需要服务的时间段。该请求可以由网络管理员或用户手动发出，也可以来自其他地区的BB。BB首先验证请求者的凭据，然后验证是否存在足够满足请求的未分配带宽。如果请求通过了这些测试，可用带宽将减少请求的数量，并且
the flow specification is recorded. In the case where the flow has a destination outside this trust region, the request must fall within the class allocation through the "next hop" trust region that was established through a bilateral agreement of the two trust regions. The requester's BB informs the adjacent region's BB that it will be using some of this rate allocation. The BB configures the appropriate leaf router with the information about the packet flow to be given a service at the time that the service is to commence. This configuration is "soft state" that the BB will periodically refresh. The BB in the adjacent region is responsible for configuring the border router to permit the allocated packet flow to pass and for any additional configurations and negotiations within and across its borders that will allow the flow to reach its final destination.
记录流量规格。在流的目的地位于该信任区域之外的情况下，请求必须通过通过两个信任区域的双边协议建立的“下一跳”信任区域落在类分配中。请求者的BB通知相邻区域的BB，其将使用部分费率分配。BB使用关于要在服务开始时被给予服务的分组流的信息来配置适当的叶路由器。此配置为BB将定期刷新的“软状态”。相邻区域中的BB负责配置边界路由器以允许分配的分组流通过，并负责在其边界内和边界之间的任何额外配置和协商，以允许流到达其最终目的地。
At DMZs, there must be an unambiguous way to determine the local source of a packet. An interface's source could be determined from its MAC address which would then be used to classify packets as coming across a logical link directly from the source domain corresponding to that MAC address. Thus with this understanding we can continue to use figures illustrating a single pipe between two different domains.
在DMZ，必须有一种明确的方法来确定数据包的本地源。接口的源可以根据其MAC地址来确定，然后使用MAC地址将数据包分类为直接通过与该MAC地址对应的源域的逻辑链路。因此，有了这种理解，我们可以继续使用图示说明两个不同域之间的单个管道。
In this way, all agreements and negotiations are performed between two adjacent domains. An initial request might cause communication between BBs on several domains along a path, but each communication is only between two adjacent BBs. Initially, these agreements will be prenegotiated and fairly static. Some may become more dynamic as the service evolves.
这样，所有协议和协商都在两个相邻的域之间执行。初始请求可能会导致沿路径的多个域上的BBs之间进行通信，但每次通信仅在两个相邻BBs之间进行。最初，这些协议将是预先协商的，并且相当稳定。随着服务的发展，有些可能会变得更加动态。
This section gives examples of BB transactions in a non-trivial, multi-transit-domain Internet. The BB framework allows operating points across a spectrum from "no signalling across boundaries" to "each flow set up dynamically". We might expect to move across this spectrum over time, as the necessary mechanisms are ubiquitously deployed and BBs become more sophisticated, but the statically allocated portions of the spectrum should always have uses. We believe the ability to support this wide spectrum of choices simultaneously will be important both in incremental deployment and in allowing ISPs to make a wide range of offerings and pricings to users. The examples of this section roughly follow the spectrum of increasing sophistication. Note that we assume that domains contract for some amount of Marked traffic which can be requested as either Assured or Premium in each individual flow setup transaction. The examples say "Marked" although actual transactions would have to specify either Assured or Premium.
本节给出了非平凡、多传输域互联网中的BB事务示例。BB框架允许从“无信号跨越边界”到“动态设置每个流”的频谱上的操作点。随着必要机制的普遍部署和BBs变得更加复杂，我们可能期望随着时间的推移跨越这一频谱，但静态分配的频谱部分应该总是有用途的。我们相信，在增量部署和允许ISP向用户提供广泛的服务和收费方面，同时支持这一广泛选择的能力将非常重要。本节的示例大致遵循日益复杂的范围。请注意，我们假设域收缩一定数量的标记流量，在每个单独的流设置事务中，这些标记流量可以作为保证流量或额外流量请求。示例中显示“标记”，但实际交易必须指定“保证”或“保险费”。
A statically configured example with no BB messages exchanged: Here all allocations are statically preallocated through purely bilateral agreements between users (individual TCPs, individual hosts, campus networks, or whole ISPs) [6]. The allocations are in the form of usage profiles of rate, burst, and a time during which that profile is to be active. Users and providers negotiate these Profiles which are then installed in the user domain BB and in the provider domain BB. No BB messages cross the boundary; we assume this negotiation is done by human representatives of each domain. In this case, BBs only have to perform one of their two functions, that of allocating this Profile within their local domain. It is even possible to set all of this suballocations up in advance and then the BB only needs to set up and tear down the Profile at the proper time and to refresh the soft state in the leaf routers. From the user domain BB, the Profile is sent as soft state to the first hop router of the flow during the specified time. These Profiles might be set using RSVP, a variant of RSVP, SNMP, or some vendor-specific mechanism. Although this static approach can work for all Marked traffic, due to the strictly not oversubscribed requirement, it is only appropriate for Premium traffic as long as it is kept to a small percentage of the bottleneck path through a domain or is otherwise constrained to a well-known behavior. Similar restrictions might hold for Assured depending on the expectation associated with the service.
无BB消息交换的静态配置示例：这里，所有分配都是通过用户之间的纯双边协议（单个TCP、单个主机、校园网或整个ISP）静态预分配的[6]。分配以速率、突发和该配置文件处于活动状态的时间的使用配置文件的形式存在。用户和提供商协商这些配置文件，然后将其安装在用户域BB和提供商域BB中。没有BB信息跨越边界；我们假设这个协商是由每个领域的人类代表完成的。在这种情况下，BBs只需执行其两项功能中的一项，即在其本地域内分配此配置文件。甚至可以预先设置所有这些子分配，然后BB只需要在适当的时间设置和删除配置文件，并刷新叶路由器中的软状态。从用户域BB，在指定的时间内，将配置文件作为软状态发送到流的第一跳路由器。可以使用RSVP、RSVP的变体、SNMP或某些特定于供应商的机制来设置这些配置文件。尽管这种静态方法可以适用于所有标记的流量，但由于严格的非超额订阅要求，它只适用于高级流量，只要它保持在通过域的瓶颈路径的一小部分，或者以其他方式受限于众所周知的行为。根据与服务相关联的期望，类似的限制也可能适用。
In figure 6, we show an example of setting a Profile in a leaf router. A usage profile has been negotiated with the ISP for the entire domain and the BB parcels it out among individual flows as requested. The leaf router mechanism is that shown in figure 3, with the token bucket set to the parameters from the usage profile. The ISP's BB would configure its own Profile Meter at the ingress router from that customer to ensure the Profile was maintained. This mechanism was shown in figure 5. We assume that the time duration and start times for any Profile to be active are maintained in the BB. The Profile is sent to the ingress device or cleared from the ingress device by messages sent from the BB. In this example, we assume that van@lbl wants to talk to ddc@mit. The LBL-BB is sent a request from Van asking that premium service be assigned to a flow that is designated as having source address "V:4" and going to destination address "D:8". This flow should be configured for a rate of 128kb/sec and allocated from 1pm to 3pm. The request must be "signed" in a secure, verifiable manner. The request might be sent as data to the LBL-BB, an e-mail message to a network administrator, or in a phone call to a network administrator. The LBL-BB receives this message, verifies that there is 128kb/sec of unused Premium service for the domain from 1-3pm, then sends a message to Leaf1 that sets up an appropriate Profile Meter. The message to Leaf1 might be an RSVP message, or SNMP, or some proprietary method. All the domains passed must have sufficient reserve capacity to meet this request.
在图6中，我们展示了在叶路由器中设置配置文件的示例。已与ISP协商了整个域的使用情况配置文件，BB根据要求将其分配给各个流。叶路由器机制如图3所示，令牌桶设置为使用概要文件中的参数。ISP的BB将在该客户的入口路由器上配置自己的配置文件表，以确保配置文件得到维护。该机制如图5所示。我们假设BB中保留了激活任何配置文件的持续时间和开始时间。配置文件通过BB发送的消息发送到入口设备或从入口设备清除。在这个例子中，我们假设van@lbl想和你谈谈吗ddc@mit. LBL-BB从Van发送请求，请求将高级服务分配给指定为具有源地址“V:4”和前往目标地址“D:8”的流。此流应配置为128kb/秒的速率，并从下午1点分配到下午3点。请求必须以安全、可验证的方式“签名”。请求可以作为数据发送到LBL-BB，也可以通过电子邮件发送给网络管理员，或者通过电话发送给网络管理员。LBL-BB收到此消息，确认从下午1点到3点，该域有128kb/秒未使用的高级服务，然后向Leaf1发送一条消息，设置适当的配置文件表。发送给Leaf1的消息可能是RSVP消息、SNMP或某些专有方法。传递的所有域必须具有足够的保留容量以满足此请求。
Figure 6. Bandwidth Broker setting Profiles in leaf routers
图6。叶路由器中的带宽代理设置配置文件
A statically configured example with BB messages exchanged: Next we present an example where all allocations are statically preallocated but BB messages are exchanged for greater flexibility. Figure 7 shows an end-to-end example for Marked traffic in a statically allocated internet. The numbers at the trust region boundaries indicate the total statically allocated Marked packet rates that will be accepted across those boundaries. For example, 100kbps of Marked traffic can be sent from LBL to ESNet; a Profile Meter at the ESNet egress boundary would have a token bucket set to rate 100kbps. (There MAY be a shaper set at LBL's egress to ensure that the Marked traffic conforms to the aggregate Profile.) The tables inside the transit network "bubbles" show their policy databases and reflect the values after the transaction is complete. In Figure 7, V wants to transmit a flow from LBL to D at MIT at 10 Kbps. As in figure 6, a request for this profile is made of LBL's BB. LBL's BB authenticates the request and checks to see if there is 10kbps left in its Marked allocation going in that direction. There is, so the LBL-BB passes a message to the ESNet-BB saying that it would like to use 10kbps of its Marked allocation for this flow. ESNet authenticates the message, checks its database and sees that it has a 10kbps Marked allocation to NEARNet (the next region in that direction) that is being unused. The policy is that ESNet-BB must always inform ("ask") NEARNet-BB when it is about to use part of its allocation. NEARNET-BB authenticates the message, checks its database and discovers that 20kbps of the allocation to MIT is unused and the policy at that boundary is to not inform MIT when part of the allocation is about to be used ("<50 ok" where the total allocation is 50). The dotted lines indicate the "implied" transaction, that is the transaction that would have happened if the policy hadn't said "don't ask me". Now each BB can pass an "ok" message to this request across its boundary. This allows V to send to D, but not vice versa. It would also be possible for the request to originate from D.
一个静态配置的BB消息交换示例：接下来，我们将展示一个示例，其中所有分配都是静态预分配的，但BB消息是为了更大的灵活性而交换的。图7显示了静态分配internet中标记流量的端到端示例。信任区域边界上的数字表示将跨这些边界接受的静态分配的标记数据包的总速率。例如，100kbps的标记流量可以从LBL发送到ESNet；ESNet出口边界处的剖面仪将有一个令牌桶，其速率设置为100kbps。（LBL出口处可能设置了一个整形器，以确保标记的流量符合聚合配置文件。）公交网络“气泡”内的表显示其策略数据库，并反映交易完成后的值。在图7中，V希望以10 Kbps的速率从LBL传输到MIT的D。如图6所示，对该概要文件的请求是由LBL的BB发出的。LBL的BB对请求进行身份验证，并检查其标记的分配中是否还有10kbps朝该方向移动。存在，因此LBL-BB将一条消息传递给ESNet BB，表示它希望将其标记分配的10kbps用于此流。ESNet对消息进行身份验证，检查其数据库，并查看是否有一个标记为10kbps的分配给未使用的NEARNet（该方向的下一个区域）。该政策规定，当ESNet BB即将使用其部分分配时，必须始终通知（“询问”）近网BB。NEARNET-BB对消息进行身份验证，检查其数据库，发现分配给MIT的20kbps未使用，该边界的策略是在部分分配即将使用时不通知MIT（“50确定”，其中总分配为50）。虚线表示“隐含”交易，即如果政策没有说“不要问我”的话会发生的交易。现在，每个BB都可以通过其边界向该请求传递一条“ok”消息。这允许V发送到D，但不允许V发送到D。也可以由D提出请求。
Figure 7. End-to-end example with static allocation.
图7。具有静态分配的端到端示例。
Consider the same example where the ESNet-BB finds all of its Marked allocation to NEARNet, 10 kbps, in use. With static allocations, ESNet must transmit a "no" to this request back to the LBL-BB. Presumably, the LBL-BB would record this information to complain to ESNet about the overbooking at the end of the month! One solution to this sort of "busy signal" is for ESNet to get better at anticipating its customers needs or require long advance bookings for every flow, but it's also possible for bandwidth brokerage decisions to become dynamic.
考虑同样的例子，其中ESNET BB发现其所有标记的分配到NeNNET，10 kbps，在使用中。对于静态分配，ESNet必须向LBL-BB发送对此请求的“否”。据推测，LBL-BB将记录这些信息，以便在月底向ESNet投诉超额预订！对于这种“繁忙信号”的一种解决方案是，ESNet能够更好地预测其客户的需求，或者要求对每个流量进行长期预订，但带宽代理决策也有可能变得动态。
Figure 8. End-to-end static allocation example with no remaining allocation
图8。无剩余分配的端到端静态分配示例
Dynamic Allocation and additional mechanism: As we shall see, dynamic allocation requires more complex BBs as well as more complex border policing, including the necessity to keep more state. However, it enables an important service with a small increase in state.
动态分配和附加机制：正如我们将看到的，动态分配需要更复杂的BBs以及更复杂的边境治安，包括保持更多状态的必要性。但是，它启用了一项重要的服务，状态略有增加。
The next set of figures (starting with figure 9) show what happens in the case of dynamic allocation. As before, V requests 10kbps to talk to D at MIT. Since the allocation is dynamic, the border policers do not have a preset value, instead being set to reflect the current peak value of Marked traffic permitted to cross that boundary. The request is sent to the LBL-BB.
下一组图（从图9开始）显示了动态分配的情况。和以前一样，V要求10kbps与麻省理工学院的D对话。由于分配是动态的，边界警察没有预设值，而是被设置为反映允许跨越该边界的标记流量的当前峰值。请求被发送到LBL-BB。
Figure 9. First step in end-to-end dynamic allocation example.
图9。端到端动态分配示例中的第一步。
In figure 10, note that ESNet has no allocation set up to NEARNet. This system is capable of dynamic allocations in addition to static, so it asks NEARNet if it can "add 10" to its allocation from ESNet. As in the figure 7 example, MIT's policy is set to "don't ask" for this case, so the dotted lines represent "implicit transactions" where no messages were exchanged. However, NEARNet does update its table to indicate that it is now using 20kbps of the Marked allocation to MIT.
在图10中，请注意ESNet没有为NEARNet设置分配。该系统除了静态分配外，还可以动态分配，因此它会询问NEARNet是否可以从ESNet向其分配“添加10”。如图7所示，对于这种情况，MIT的策略设置为“不询问”，因此虚线表示没有消息交换的“隐式事务”。然而，NEARNet确实更新了它的表，表明它现在正在使用20 kbps的标记分配给MIT。
Figure 10. Second step in end-to-end dynamic allocation example
图10。端到端动态分配示例中的第二步
In figure 11, we see the third step where MIT's "virtual ok" allows the NEARNet-BB to tell its border router to increase the Marked allocation across the ESNet-NEARNet boundary by 10 kbps.
在图11中，我们看到了第三步，麻省理工学院的“虚拟ok”允许近网BB通知其边界路由器将跨越ESNet近网边界的标记分配增加10 kbps。
Figure 11. Third step in end-to-end dynamic allocation example
图11。端到端动态分配示例中的第三步
Figure 11 shows NEARNet-BB's "ok" for that request transmitted back to ESNet-BB. This causes ESNet-BB to send its border router a message to create a 10 kbps subclass for the flow "V->D". This is required in order to ensure that the 10kpbs that has just been dynamically allocated gets used only for that connection. Note that this does require that the per flow state be passed from LBL-BB to ESNet-BB, but this is the only boundary that needs that level of flow information and this further classification will only need to be done at that one boundary router and only on packets coming from LBL. Thus dynamic allocation requires more complex Profile Metering than that shown in figure 5.
图11显示了发送回ESNet BB的请求的NEARNet BB的“ok”。这会导致ESNet BB向其边界路由器发送一条消息，为流“V->D”创建一个10 kbps的子类。这是必需的，以确保刚刚动态分配的10kpbs仅用于该连接。请注意，这确实需要将每流状态从LBL-BB传递到ESNet BB，但这是需要该流信息级别的唯一边界，并且此进一步分类只需要在该边界路由器上进行，并且仅对来自LBL的数据包进行。因此，动态分配需要比图5所示更复杂的配置文件计量。
Figure 12. Fourth step in end-to-end dynamic allocation example.
图12。端到端动态分配示例中的第四步。
In figure 12, the ESNet border router gives the "ok" that a subclass has been created, causing the ESNet-BB to send an "ok" to the LBL-BB which lets V know the request has been approved.
在图12中，ESNet边界路由器给出已创建子类的“ok”，导致ESNet BB向LBL-BB发送“ok”，让V知道请求已被批准。
Figure 13. Final step in end-to-end dynamic allocation example
图13。端到端动态分配示例中的最后一步
For dynamic allocation, a basic version of a CBQ scheduler [5] would have all the required functionality to set up the subclasses. RSVP currently provides a way to move the TSpec for the flow.
对于动态分配，CBQ调度器[5]的基本版本将具有设置子类所需的所有功能。RSVP目前提供了一种为流移动TSpec的方法。
For multicast flows, we assume that packets that are bound for at least one egress can be carried through a domain at that level of service to all egress points. If a particular multicast branch has been subscribed to at best-effort when upstream branches are Marked, it will have its bit settings cleared before it crosses the boundary. The information required for this flow identification is used to augment the existing state that is already kept on this flow because it is a multicast flow. We note that we are already "catching" this flow, but now we must potentially clear the bit-pattern.
对于多播流，我们假设绑定到至少一个出口的数据包可以通过该服务级别的域传送到所有出口点。如果在标记上游分支时已尽最大努力订阅了某个特定的多播分支，则它将在跨越边界之前清除其位设置。此流标识所需的信息用于扩充此流上已保留的现有状态，因为它是多播流。我们注意到我们已经“捕获”了这个流，但是现在我们必须潜在地清除位模式。
Much work has been done in recent years on the definition of related integrated services for the internet and the specification of the RSVP signalling protocol. The two-bit architecture proposed in this work can easily interoperate with those specifications. In this section we first discuss how the forwarding mechanisms described in section 3 can be used to support integrated services. Second, we discuss how RSVP could interoperate with the administrative structure of the BBs to provide better scaling.
近年来，在互联网相关综合业务的定义和RSVP信令协议的规范方面已经做了大量工作。本文中提出的两位体系结构可以轻松地与这些规范进行互操作。在本节中，我们首先讨论如何使用第3节中描述的转发机制来支持集成服务。其次，我们讨论RSVP如何与BBs的管理结构进行互操作，以提供更好的扩展。
We believe that the forwarding path mechanisms described in section 3 are general enough that they can also be used to provide the Controlled-Load service [8] and a version of the Guaranteed Quality of Service [9], as developed by the int-serv WG. First note that Premium service can be thought of as a constrained case of Controlled-Load service where the burst size is limited to one packet and where non-conforming packets are dropped. A network element that has implemented the mechanisms to support premium service can easily support the more general controlled-load service by making one or more minor parameter adjustments, e.g. by lifting the constraint on the token bucket size, or configuring the Premium service rate with the peak traffic rate parameter in the Controlled-Load specification, and by changing the policing action on out-of-profile packets from dropping to sending the packets to the Best-effort queue.
我们认为，第3节中描述的转发路径机制足够通用，它们也可用于提供由int-serv WG开发的受控负载服务[8]和保证服务质量的版本[9]。首先注意，高级服务可以被认为是受控负载服务的受限情况，其中突发大小被限制为一个分组，并且不一致的分组被丢弃。实现了支持高级服务的机制的网元可以通过进行一个或多个较小的参数调整（例如，通过解除对令牌桶大小的限制），轻松支持更一般的受控负载服务，或者使用受控负载规范中的峰值流量率参数配置高级服务速率，并通过将配置文件外数据包的策略操作从丢弃更改为将数据包发送到尽力而为队列。
It is also possible to implement Guaranteed Quality of Service using the mechanisms of Premium service. From RFC 2212 [9]: "The definition of guaranteed service relies on the result that the fluid delay of a flow obeying a token bucket (r, b) and being served by a line with bandwidth R is bounded by b/R as long as R is no less than r. Guaranteed service with a service rate R, where now R is a share of bandwidth rather than the bandwidth of a dedicated line approximates this behavior." The service model of Premium clearly fits this model. RFC 2212 states that "Non-conforming datagrams SHOULD be treated as best-effort datagrams." Thus, a policing Profile Meter that drops non-conforming datagrams would be acceptable, but it's also possible to change the action for non-compliant packets from a drop to sending to the best-effort queue.
还可以使用高级服务机制实现有保证的服务质量。来自RFC 2212[9]：“保证服务的定义依赖于服从令牌桶（r，b）的流的流体延迟的结果而由带宽为R的线路提供服务，只要R不小于R，则以b/R为界。服务速率为R的保证服务，其中R是带宽的一部分，而不是专用线路的带宽，近似于这种行为。“Premium的服务模型显然符合此模型。”。RFC 2212规定“不符合要求的数据报应被视为尽力而为的数据报”。因此，丢弃不符合要求的数据报的监控配置文件表是可以接受的，但也可以将不符合要求的数据包的操作从丢弃改为发送到尽力而为队列。
In this section we discuss how RSVP signaling can be used in conjunction with the BBs described in section 4 to deliver a more scalable end-to-end resource set up for Integrated Services. First we note that the BB architecture has three major differences with the original RSVP resource set up model:
在本节中，我们将讨论如何将RSVP信令与第4节中描述的BBs结合使用，从而为集成服务提供更可扩展的端到端资源设置。首先，我们注意到BB架构与原始RSVP资源设置模型有三个主要区别：
1. There exist apriori bilateral business relations between BBs of adjacent trust regions before one can set up end-to-end resource allocation; real-time signaling is used only to activate/confirm the availability of pre-negotiated Marked bandwidth, and to dynamically readjust the allocation amount when necessary. We note that this real-time signaling across domains is not required, but depends on the nature of the bilateral agreement (e.g., the agreement might state "I'll tell you whenever I'm going to use some of my allocation" or not).
1. 在建立端到端资源分配之前，相邻信任区域的BBs之间存在先验双边业务关系；实时信令仅用于激活/确认预先协商的标记带宽的可用性，并在必要时动态调整分配量。我们注意到，这种跨域的实时信令不是必需的，而是取决于双边协议的性质（例如，协议可能会声明“我将在何时使用我的一些分配”或“不使用时告诉你”）。
2. A few bits in the packet header, i.e. the P-bit and A-bit, are used to mark the service class of each packet, therefore a full packet classification (by checking all relevant fields in the header) need be done only once at the leaf router; after that packets will be served according to their class bit settings.
2. 分组报头中的一些位，即P位和A位，用于标记每个分组的服务类别，因此在叶路由器上只需完成一次完整分组分类（通过检查报头中的所有相关字段）；之后，数据包将根据其类位设置提供服务。
3. RSVP resource set up assumes that resources will be reserved hop-by-hop at each router along the entire end-to-end path.
3. RSVP资源设置假定资源将沿整个端到端路径在每个路由器上逐跳保留。
RSVP messages sent to leaf routers by hosts can be intercepted and sent to the local domain's BB. The BB processes the message and, if the request is approved, forwards a message to the leaf router that sets up appropriate per-flow packet classification. A message should also be sent to the egress border router to add to the aggregate Marked traffic allocation for packet shaping by the Profile Meter on outbound traffic. (Its possible that this is always set to the full
主机发送到叶路由器的RSVP消息可以被截获并发送到本地域的BB。BB处理该消息，并且如果请求被批准，则将消息转发给叶路由器，该叶路由器设置适当的每流分组分类。还应向出口边界路由器发送一条消息，以添加到聚合标记的流量分配中，以便配置文件仪表对出站流量进行分组整形。（这可能总是设置为“完全”
allocation.) An RSVP message must be sent across the boundary to adjacent ISP's border router, either from the local domain's border router or from the local domain's BB. If the ISP is also implementing the RSVP with a BB and diff-serv framework, its border router forwards the message to the ISP's local BB. A similar process (to what happened in the first domain) can be carried out in the ISP domain, then an RSVP message gets forwarded to the next ISP along the path. Inside a domain, packets are served solely according to the Marked bits. The local BB knows exactly how much Premium traffic is permitted to enter at each border router and from which border router packets exit.
RSVP消息必须从本地域的边界路由器或本地域的BB跨边界发送到相邻ISP的边界路由器。如果ISP也使用BB和diff-serv框架实现RSVP，则其边界路由器将消息转发给ISP的本地BB。可以在ISP域中执行类似的过程（与第一个域中发生的过程类似），然后将RSVP消息沿路径转发给下一个ISP。在域内，数据包仅根据标记位提供服务。本地BB确切地知道在每个边界路由器上允许多少高级流量进入，以及从哪个边界路由器数据包退出。
This document has presented a reference architecture for differentiated services. Several variations can be envisioned, particularly for early and partial deployments, but we do not enumerate all of these variations here. There has been a great market demand for differentiated services lately. As one of the many efforts to meet that demand this memo sketches out the framework of a flexible architecture for offering differential services, and in particular defines a simple set of packet forwarding path mechanisms to support two basic types of differential services. Although there remain a number of issues and parameters that need further exploration and refinement, we believe it is both possible and feasible at this time to start deployment of differentiated services incrementally. First, given that the basic mechanisms required in the packet forwarding path are clearly understood, both Assured and Premium services can be implemented today with manually configured BBs and static resource allocation. Initially we recommend conservative choices on the amount of Marked traffic that is admitted into the network. Second, we plan to continue the effort started with this memo and the experimental work of the authors to define and deploy increasingly sophisticated BBs. We hope to turn the experience gained from in-progress trial implementations on ESNet and CAIRN into future proposals to the IETF.
本文档介绍了区分服务的参考体系结构。可以设想几种变化，特别是对于早期部署和部分部署，但我们这里不列举所有这些变化。最近，差异化服务的市场需求很大。作为满足这一需求的众多努力之一，本备忘录勾勒出了提供差异服务的灵活体系结构的框架，并特别定义了一组简单的数据包转发路径机制，以支持两种基本类型的差异服务。尽管仍有许多问题和参数需要进一步探索和完善，但我们认为，目前以增量方式开始部署差异化服务是可能和可行的。首先，考虑到包转发路径中所需的基本机制已被清楚地理解，现在可以通过手动配置BBs和静态资源分配来实现有保证和高级服务。最初，我们建议对允许进入网络的标记通信量进行保守选择。其次，我们计划继续从这份备忘录开始的工作，以及作者的实验工作，以定义和部署日益复杂的BBs。我们希望将从ESNet和CAIRN上正在进行的试验实施中获得的经验转化为IETF的未来建议。
Future revisions of this memo will present the receiver-based and multicast flow allocations in detail. After this step is finished, we believe the basic picture of an scalable, robust, secure resource management and allocation system will be completed. In this memo, we described how the proposed architecture supports two services that seem to us to provide at least a good starting point for trial deployment of differentiated services. Our main intent is to define an architecture with three services, Premium, Assured, and Best effort, that can be determined by specific bit- patterns, but not to preclude additional levels of differentiation within each service. It seems that more experimentation and experience is required before we
本备忘录的未来版本将详细介绍基于接收器和多播流的分配。这一步完成后，我们相信，一个可扩展、健壮、安全的资源管理和分配系统的基本框架将完成。在本备忘录中，我们描述了建议的体系结构如何支持两个服务，在我们看来，这两个服务至少为差异化服务的试用部署提供了一个良好的起点。我们的主要目的是定义一个具有三种服务的体系结构，即高级服务、有保证服务和尽力而为服务，这三种服务可以由特定的位模式确定，但不排除每个服务中额外的差异化级别。看来，我们需要更多的实验和经验
could standardize more than one level per service class. Our base-level approach says that everyone has to provide "at least" Premium service and Assured service as documented. We feel rather strongly about both 1) that we should not try to define, at this time, something beyond the minimalist two service approach and 2) that the architecture we define must be open-ended so that more levels of differentiation might be standardized in the future. We believe this architecture is completely compatible with approaches that would define more levels of differentiation within a particular service, if the benefits of doing so become well understood.
可以标准化每个服务类别的多个级别。我们的基本方法是，每个人都必须提供“至少”优质服务和有保证的服务。我们强烈认为，1）此时不应试图定义超出最低限度的两种服务方法之外的东西，2）我们定义的架构必须是开放式的，以便将来可以标准化更多的差异化级别。我们相信，如果人们充分理解这样做的好处，这种体系结构与在特定服务中定义更多差异化级别的方法完全兼容。
The authors have benefited from many discussions, both in person and electronically and wish to particularly thank Dave Clark who has been responsible for the genesis of many of the ideas presented here, though he does not agree with all of the content this document. We also thank Sally Floyd for comments on an earlier draft. A comment from Jon Crowcroft was partially responsible for our including section 5. Comments from Fred Baker made us try to make it clearer that we are defining two base-level services, irrespective of the bit patterns used to encode them.
作者从许多讨论中受益匪浅，无论是面对面讨论还是电子讨论，并希望特别感谢Dave Clark，他负责这里提出的许多想法的起源，尽管他不同意本文件的所有内容。我们还感谢Sally Floyd对早期草案的评论。Jon Crowcroft的评论对我们的报告（包括第5节）负有部分责任。Fred Baker的评论让我们试图更清楚地说明，我们正在定义两个基本级别的服务，而不考虑用于编码它们的位模式。
There are no security considerations associated with this document.
没有与此文档相关的安全注意事项。
[1] D. Clark, "Adding Service Discrimination to the Internet", Proceedings of the 23rd Annual Telecommunications Policy Research Conference (TPRC), Solomons, MD, October 1995.
[1] D.Clark，“在互联网上增加服务歧视”，第23届年度电信政策研究会议论文集，马里兰州所罗门群岛，1995年10月。
[2] V. Jacobson, "Differentiated Services Architecture", talk in the Int-Serv WG at the Munich IETF, August, 1997.
[2] V.Jacobson，“差异化服务体系结构”，1997年8月在慕尼黑IETF国际服务工作组上的演讲。
[3] Clark, D. and J. Wroclawski, "An Approach to Service Allocation in the Internet", Work in Progress, also talk by D. Clark in the Int-Serv WG at the Munich IETF, August, 1997.
[3] Clark，D.和J.Wroclawski，“互联网中的服务分配方法”，正在进行的工作，D.Clark在慕尼黑IETF的Int Serv工作组中的演讲，1997年8月。
[4] Braden, et al., "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[4] Braden等人，“关于互联网队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[4] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[4] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）-第1版功能规范”，RFC 22052997年9月。
[5] S. Floyd and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, pp 365-386, August 1995.
[5] S.Floyd和V.Jacobson，“分组网络的链路共享和资源管理模型”，IEEE/ACM网络事务，第365-386页，1995年8月。
[6] D. Clark, private communication, October 26, 1997.
[6] D.Clark，《私人通讯》，1997年10月26日。
[7] "Advanced QoS Services for the Intelligent Internet", Cisco Systems White Paper, 1997.
[7] “智能互联网的高级QoS服务”，思科系统白皮书，1997年。
[8] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[8] Wroclawski，J.，“受控负荷网元服务规范”，RFC2211，1997年9月。
[9] Shenker, S., Partirdge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[9] Shenker，S.，Partirdge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[10] D. Clark and W. Fang, "Explicit Allocation of Best Effort packet
Delivery Service", IEEE/ACM Transactions on Networking, August,
1998, Vol6, No 4, pp. 362-373. also at: http://
diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf
[10] D. Clark and W. Fang, "Explicit Allocation of Best Effort packet
Delivery Service", IEEE/ACM Transactions on Networking, August,
1998, Vol6, No 4, pp. 362-373. also at: http://
diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf
Authors' Addresses
作者地址
Kathleen Nichols Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706
Kathleen Nichols Cisco Systems，Inc.加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
Phone: 408-525-4857 EMail: kmn@cisco.com
电话：408-525-4857电子邮件：kmn@cisco.com
Van Jacobson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706
Van Jacobson Cisco Systems，Inc.加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
EMail: van@cisco.com
EMail: van@cisco.com
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095
加利福尼亚州洛杉矶加利福尼亚大学洛杉矶分校张丽霞4531G博尔特大厅，邮编90095
Phone: 310-825-2695 EMail: lixia@cs.ucla.edu
电话：310-825-2695电子邮件：lixia@cs.ucla.edu
Appendix: A Combined Approach to Differential Service in the Internet by David D. Clark
附录：David D.Clark的互联网差异服务组合方法
After the draft-nichols-diff-svc-00 was submitted, the co-authors had a discussion with Dave Clark and John Wroclawski which resulted in Clark's using the presentation slot for the draft at the December 1997 IETF Integrated Services Working Group meeting. A reading of the slides shows that it was Clark's proposal on "mechanisms", "services", and "rules" and how to proceed in the standards process that has guided much of the process in the subsequently formed IETF Differentiated Services Working Group. We believe Dave Clark's talk gave us a solid approach for bringing quality of service to the Internet in a manner that is compatible with its strengths.
提交草案-nichols-diff-svc-00后，合著者与Dave Clark和John Wroclawski进行了讨论，结果Clark在1997年12月IETF综合服务工作组会议上使用了草案的演示时段。对幻灯片的阅读表明，正是克拉克关于“机制”、“服务”和“规则”以及如何在标准过程中继续进行的建议指导了随后成立的IETF差异化服务工作组的大部分过程。我们相信，Dave Clark的演讲为我们提供了一个坚实的方法，以符合互联网优势的方式为互联网带来服务质量。
The slides presented at the December 1997 IETF Integrated Services Working Group are included with the Postscript version.
1997年12月IETF综合服务工作组上展示的幻灯片包含在Postscript版本中。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。