Network Working Group Y. Bernet
Request for Comments: 2998 P. Ford
Category: Informational Microsoft
R. Yavatkar
Intel
F. Baker
Cisco
L. Zhang
UCLA
M. Speer
Sun Microsystems
R. Braden
ISI
B. Davie
Cisco
J. Wroclawski
MIT LCS
E. Felstaine
SANRAD
November 2000
Network Working Group Y. Bernet
Request for Comments: 2998 P. Ford
Category: Informational Microsoft
R. Yavatkar
Intel
F. Baker
Cisco
L. Zhang
UCLA
M. Speer
Sun Microsystems
R. Braden
ISI
B. Davie
Cisco
J. Wroclawski
MIT LCS
E. Felstaine
SANRAD
November 2000
A Framework for Integrated Services Operation over Diffserv Networks
区分服务网络上的综合业务运营框架
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
摘要
The Integrated Services (Intserv) architecture provides a means for the delivery of end-to-end Quality of Service (QoS) to applications over heterogeneous networks. To support this end-to-end model, the Intserv architecture must be supported over a wide variety of different types of network elements. In this context, a network that supports Differentiated Services (Diffserv) may be viewed as a network element in the total end-to-end path. This document describes a framework by which Integrated Services may be supported over Diffserv networks.
集成服务（integratedservices，Intserv）体系结构提供了一种通过异构网络向应用程序提供端到端服务质量（QoS）的方法。为了支持这种端到端模型，必须在各种不同类型的网元上支持Intserv体系结构。在此上下文中，支持区分服务（Diffserv）的网络可被视为总端到端路径中的网络元件。本文档描述了一个框架，通过该框架可以在Diffserv网络上支持集成服务。
Table of Contents
目录
1. Introduction ................................................. 3
1.1 Integrated Services Architecture ............................ 3
1.2 RSVP ........................................................ 3
1.3 Diffserv .................................................... 4
1.4 Roles of Intserv, RSVP and Diffserv ......................... 4
1.5 Components of Intserv, RSVP and Diffserv .................... 5
1.6 The Framework ............................................... 6
1.7 Contents .................................................... 6
2. Benefits of Using Intserv with Diffserv ...................... 7
2.1 Resource Based Admission Control ............................ 7
2.2 Policy Based Admission Control .............................. 8
2.3 Assistance in Traffic Identification/Classification ......... 8
2.3.1 Host Marking .............................................. 9
2.3.2 Router Marking ............................................ 9
2.4 Traffic Conditioning ........................................ 10
3. The Framework ................................................ 10
3.1 Reference Network ........................................... 11
3.1.1 Hosts ..................................................... 11
3.1.2 End-to-End RSVP Signaling ................................. 12
3.1.3 Edge Routers .............................................. 12
3.1.4 Border Routers ............................................ 12
3.1.5 Diffserv Network Region ................................... 13
3.1.6 Non-Diffserv Network Regions .............................. 13
3.2 Service Mapping ............................................. 13
3.2.1 Default Mapping ........................................... 14
3.2.2 Network Driven Mapping .................................... 14
3.2.3 Microflow Separation ...................................... 14
3.3 Resource Management in Diffserv Regions ..................... 15
4. Detailed Examples of the Operation of
Intserv over Diffserv Regions ................................ 16
4.1 Statically Provisioned Diffserv Network Region .............. 16
4.1.1 Sequence of Events in Obtaining End-to-end QoS ............ 16
4.2 RSVP-Aware Diffserv Network Region .......................... 18
4.2.1 Aggregated or Tunneled RSVP ............................... 19
4.2.3 Per-flow RSVP ............................................. 20
4.2.4 Granularity of Deployment of RSVP Aware Routers ........... 20
4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region ..... 21
5. Implications of the Framework for Diffserv Network Regions ... 21
5.1 Requirements from Diffserv Network Regions .................. 21
5.2 Protection of Intserv Traffic from Other Traffic ............ 22
6. Multicast .................................................... 22
6.1 Remarking of packets in branch point routers ................ 24
6.2 Multicast SLSs and Heterogeneous Trees ...................... 25
7. Security Considerations ...................................... 26
7.1 General RSVP Security ....................................... 26
7.2 Host Marking ................................................ 26
1. Introduction ................................................. 3
1.1 Integrated Services Architecture ............................ 3
1.2 RSVP ........................................................ 3
1.3 Diffserv .................................................... 4
1.4 Roles of Intserv, RSVP and Diffserv ......................... 4
1.5 Components of Intserv, RSVP and Diffserv .................... 5
1.6 The Framework ............................................... 6
1.7 Contents .................................................... 6
2. Benefits of Using Intserv with Diffserv ...................... 7
2.1 Resource Based Admission Control ............................ 7
2.2 Policy Based Admission Control .............................. 8
2.3 Assistance in Traffic Identification/Classification ......... 8
2.3.1 Host Marking .............................................. 9
2.3.2 Router Marking ............................................ 9
2.4 Traffic Conditioning ........................................ 10
3. The Framework ................................................ 10
3.1 Reference Network ........................................... 11
3.1.1 Hosts ..................................................... 11
3.1.2 End-to-End RSVP Signaling ................................. 12
3.1.3 Edge Routers .............................................. 12
3.1.4 Border Routers ............................................ 12
3.1.5 Diffserv Network Region ................................... 13
3.1.6 Non-Diffserv Network Regions .............................. 13
3.2 Service Mapping ............................................. 13
3.2.1 Default Mapping ........................................... 14
3.2.2 Network Driven Mapping .................................... 14
3.2.3 Microflow Separation ...................................... 14
3.3 Resource Management in Diffserv Regions ..................... 15
4. Detailed Examples of the Operation of
Intserv over Diffserv Regions ................................ 16
4.1 Statically Provisioned Diffserv Network Region .............. 16
4.1.1 Sequence of Events in Obtaining End-to-end QoS ............ 16
4.2 RSVP-Aware Diffserv Network Region .......................... 18
4.2.1 Aggregated or Tunneled RSVP ............................... 19
4.2.3 Per-flow RSVP ............................................. 20
4.2.4 Granularity of Deployment of RSVP Aware Routers ........... 20
4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region ..... 21
5. Implications of the Framework for Diffserv Network Regions ... 21
5.1 Requirements from Diffserv Network Regions .................. 21
5.2 Protection of Intserv Traffic from Other Traffic ............ 22
6. Multicast .................................................... 22
6.1 Remarking of packets in branch point routers ................ 24
6.2 Multicast SLSs and Heterogeneous Trees ...................... 25
7. Security Considerations ...................................... 26
7.1 General RSVP Security ....................................... 26
7.2 Host Marking ................................................ 26
8. Acknowledgments .............................................. 27
9. References ................................................... 27
10. Authors' Addresses .......................................... 29
11. Full Copyright Statement ................................... 31
8. Acknowledgments .............................................. 27
9. References ................................................... 27
10. Authors' Addresses .......................................... 29
11. Full Copyright Statement ................................... 31
Work on QoS-enabled IP networks has led to two distinct approaches: the Integrated Services architecture (Intserv) [10] and its accompanying signaling protocol, RSVP [1], and the Differentiated Services architecture (Diffserv) [8]. This document describes ways in which a Diffserv network can be used in the context of the Intserv architecture to support the delivery of end-to-end QOS.
对支持QoS的IP网络的研究产生了两种截然不同的方法：综合服务体系结构（Intserv）[10]及其附带的信令协议RSVP[1]，以及区分服务体系结构（Diffserv）[8]。本文档描述了在Intserv体系结构的上下文中使用Diffserv网络以支持端到端QOS交付的方法。
The integrated services architecture defined a set of extensions to the traditional best effort model of the Internet with the goal of allowing end-to-end QOS to be provided to applications. One of the key components of the architecture is a set of service definitions; the current set of services consists of the controlled load and guaranteed services. The architecture assumes that some explicit setup mechanism is used to convey information to routers so that they can provide requested services to flows that require them. While RSVP is the most widely known example of such a setup mechanism, the Intserv architecture is designed to accommodate other mechanisms.
集成服务体系结构定义了一组对Internet传统尽力而为模型的扩展，其目标是允许向应用程序提供端到端的QOS。体系结构的关键组件之一是一组服务定义；当前服务集由受控负载和保证服务组成。该体系结构假设使用一些显式的设置机制将信息传递给路由器，以便路由器能够向需要它们的流提供请求的服务。虽然RSVP是这种设置机制最广为人知的例子，但Intserv体系结构设计用于容纳其他机制。
Intserv services are implemented by "network elements". While it is common for network elements to be individual nodes such as routers or links, more complex entities, such as ATM "clouds" or 802.3 networks may also function as network elements. As discussed in more detail below, a Diffserv network (or "cloud") may be viewed as a network element within a larger Intserv network.
Intserv服务由“网元”实现。虽然网络元件通常是单独的节点，例如路由器或链路，但更复杂的实体，例如ATM“云”或802.3网络也可以用作网络元件。如下文更详细地讨论的，区分服务网络（或“云”）可被视为更大的Intserv网络内的网络元素。
RSVP is a signaling protocol that applications may use to request resources from the network. The network responds by explicitly admitting or rejecting RSVP requests. Certain applications that have quantifiable resource requirements express these requirements using Intserv parameters as defined in the appropriate Intserv service specification. As noted above, RSVP and Intserv are separable. RSVP is a signaling protocol which may carry Intserv information. Intserv defines the models for expressing service types, quantifying resource requirements and for determining the availability of the requested resources at relevant network elements (admission control).
RSVP是一种信令协议，应用程序可以使用它从网络请求资源。网络通过明确承认或拒绝RSVP请求进行响应。某些具有可量化资源需求的应用程序使用适当的Intserv服务规范中定义的Intserv参数表达这些需求。如上所述，RSVP和Intserv是可分离的。RSVP是一种可以携带Intserv信息的信令协议。Intserv定义了用于表示服务类型、量化资源需求和确定相关网元上所请求资源的可用性（准入控制）的模型。
The current prevailing model of RSVP usage is based on a combined RSVP/Intserv architecture. In this model, RSVP signals per-flow resource requirements to network elements, using Intserv parameters. These network elements apply Intserv admission control to signaled requests. In addition, traffic control mechanisms on the network element are configured to ensure that each admitted flow receives the service requested in strict isolation from other traffic. To this end, RSVP signaling configures microflow (MF) [8] packet classifiers in Intserv capable routers along the path of the traffic flow. These classifiers enable per-flow classification of packets based on IP addresses and port numbers.
当前流行的RSVP使用模型基于组合RSVP/Intserv体系结构。在该模型中，RSVP使用Intserv参数将每个流的资源需求信号发送给网元。这些网元将Intserv准入控制应用于发信号的请求。此外，网元上的流量控制机制被配置为确保每个被接纳的流在与其他流量严格隔离的情况下接收所请求的服务。为此，RSVP信令沿着业务流路径在支持Intserv的路由器中配置微流（MF）[8]分组分类器。这些分类器支持基于IP地址和端口号的数据包按流分类。
The following factors have impeded deployment of RSVP (and the Intserv architecture) in the Internet at large:
以下因素阻碍了RSVP（和Intserv体系结构）在整个互联网中的部署：
1. The use of per-flow state and per-flow processing raises scalability concerns for large networks.
1. 每流状态和每流处理的使用引起了大型网络的可伸缩性问题。
2. Only a small number of hosts currently generate RSVP signaling. While this number is expected to grow dramatically, many applications may never generate RSVP signaling.
2. 目前只有少数主机生成RSVP信令。虽然这个数字预计会急剧增长，但许多应用程序可能永远不会生成RSVP信令。
3. The necessary policy control mechanisms -- access control, authentication, and accounting -- have only recently become available [17].
3. 必要的策略控制机制——访问控制、身份验证和记帐——直到最近才可用[17]。
In contrast to the per-flow orientation of RSVP, Diffserv networks classify packets into one of a small number of aggregated flows or "classes", based on the Diffserv codepoint (DSCP) in the packet's IP header. This is known as behavior aggregate (BA) classification [8]. At each Diffserv router, packets are subjected to a "per-hop behavior" (PHB), which is invoked by the DSCP. The primary benefit of Diffserv is its scalability. Diffserv eliminates the need for per-flow state and per-flow processing and therefore scales well to large networks.
与RSVP的每流方向不同，Diffserv网络基于数据包IP报头中的Diffserv码点（DSCP）将数据包分类为少量聚合流或“类”之一。这被称为行为聚合（BA）分类[8]。在每个Diffserv路由器上，数据包都受到“每跳行为”（PHB）的约束，该行为由DSCP调用。Diffserv的主要优点是其可扩展性。Diffserv消除了对每流状态和每流处理的需要，因此可以很好地扩展到大型网络。
We view Intserv, RSVP and Diffserv as complementary technologies in the pursuit of end-to-end QoS. Together, these mechanisms can facilitate deployment of applications such as IP-telephony, video-on-demand, and various non-multimedia mission-critical applications. Intserv enables hosts to request per-flow, quantifiable resources, along end-to-end data paths and to obtain feedback regarding admissibility of these requests. Diffserv enables scalability across large networks.
我们将Intserv、RSVP和Diffserv视为追求端到端QoS的补充技术。总之，这些机制可以促进应用程序的部署，如IP电话、视频点播和各种非多媒体任务关键型应用程序。Intserv使主机能够沿端到端数据路径按流请求可量化的资源，并获得有关这些请求可接受性的反馈。Diffserv支持跨大型网络的可扩展性。
Before proceeding, it is helpful to identify the following components of the QoS technologies described:
在继续之前，识别所述QoS技术的以下组件是有帮助的：
RSVP signaling - This term refers to the standard RSVP signaling protocol. RSVP signaling is used by hosts to signal application resource requirements to the network (and to each other). Network elements use RSVP signaling to return an admission control decision to hosts. RSVP signaling may or may not carry Intserv parameters.
RSVP信令-该术语指标准RSVP信令协议。主机使用RSVP信令向网络（以及相互）发送应用程序资源需求的信号。网络元件使用RSVP信令将接纳控制决策返回给主机。RSVP信令可能携带也可能不携带Intserv参数。
Admission control at a network element may or may not be based on the Intserv model.
网元处的准入控制可以基于也可以不基于Intserv模型。
MF traffic control - This term refers to traffic control which is applied independently to individual traffic flows and therefore requires recognizing individual traffic flows via MF classification.
MF交通控制-该术语指独立应用于单个交通流的交通控制，因此需要通过MF分类识别单个交通流。
Aggregate traffic control - This term refers to traffic control which is applied collectively to sets of traffic flows. These sets of traffic flows are recognized based on BA (DSCP) classification. In this document, we use the terms "aggregate traffic control" and "Diffserv" interchangeably.
聚合流量控制-该术语指的是对一组流量集中应用的流量控制。这些交通流集合是基于BA（DSCP）分类识别的。在本文中，我们交替使用术语“聚合流量控制”和“区分服务”。
Aggregate RSVP. While the existing definition of RSVP supports only per-flow reservations, extensions to RSVP are being developed to enable RSVP reservations to be made for aggregated traffic, i.e., sets of flows that may be recognized by BA classification. This use of RSVP may be useful in controlling the allocation of bandwidth in Diffserv networks.
总RSVP。虽然RSVP的现有定义仅支持每流保留，但正在开发RSVP的扩展，以允许对聚合流量（即可由BA分类识别的流集）进行RSVP保留。RSVP的这种使用可能有助于控制区分服务网络中的带宽分配。
Per-flow RSVP. The conventional usage of RSVP to perform resource reservations for individual microflows.
每流量RSVP。RSVP的传统用法是为单个微流执行资源预留。
RSVP/Intserv - This term is used to refer to the prevailing model of RSVP usage which includes RSVP signaling with Intserv parameters, Intserv admission control and per-flow traffic control at network elements.
RSVP/Intserv-该术语用于指RSVP使用的主流模型，包括具有Intserv参数的RSVP信令、Intserv准入控制和网元上的每流流量控制。
Diffserv Region. A set of contiguous routers which support BA classification and traffic control. While such a region may also support MF classification, the goal of this document is to describe how such a region may be used in delivery of end-to-end QOS when only BA classification is performed inside the Diffserv region.
区分服务区域。一组支持BA分类和流量控制的连续路由器。虽然这样的区域也可以支持MF分类，但本文的目标是描述当在Diffserv区域内仅执行BA分类时，如何在端到端QOS的交付中使用这样的区域。
Non-Diffserv Region. The portions of the network outside the Diffserv region. Such a region may also offer a variety of different types of classification and traffic control.
非区分服务区域。区分服务区域之外的网络部分。这样的区域还可以提供各种不同类型的分类和交通控制。
Note that, for the purposes of this document, the defining features of a Diffserv region is the type of classification and traffic control that is used for the delivery of end-to-end QOS for a particular application. Thus, while it may not be possible to identify a certain region as "purely Diffserv" with respect to all traffic flowing through the region, it is possible to define it in this way from the perspective of the treatment of traffic from a single application.
注意，在本文档中，区分服务区域的定义特征是用于为特定应用提供端到端QOS的分类和流量控制类型。因此，虽然可能不可能将某个区域识别为关于流经该区域的所有业务的“纯区分服务”，但是可以从处理来自单个应用的业务的角度以这种方式对其进行定义。
In the framework we present, end-to-end, quantitative QoS is provided by applying the Intserv model end-to-end across a network containing one or more Diffserv regions. The Diffserv regions may, but are not required to, participate in end-to-end RSVP signaling for the purpose of optimizing resource allocation and supporting admission control.
在我们提出的框架中，端到端定量QoS是通过在包含一个或多个Diffserv区域的网络上端到端应用Intserv模型来提供的。为了优化资源分配和支持接纳控制，区分服务区域可以但不需要参与端到端RSVP信令。
From the perspective of Intserv, Diffserv regions of the network are treated as virtual links connecting Intserv capable routers or hosts (much as an 802.1p network region is treated as a virtual link in [5]). Within the Diffserv regions of the network routers implement specific PHBs (aggregate traffic control). The total amount of traffic that is admitted into the Diffserv region that will receive a certain PHB may be limited by policing at the edge. As a result we expect that the Diffserv regions of the network will be able to support the Intserv style services requested from the periphery. In our framework, we address the support of end-to-end Integrated Services over the Diffserv regions of the network. Our goal is to enable seamless inter-operation. As a result, the network administrator is free to choose which regions of the network act as Diffserv regions. In one extreme the Diffserv region is pushed all the way to the periphery, with hosts alone having full Intserv capability. In the other extreme, Intserv is pushed all the way to the core, with no Diffserv region.
从Intserv的角度来看，网络的Diffserv区域被视为连接支持Intserv的路由器或主机的虚拟链路（就像[5]中802.1p网络区域被视为虚拟链路一样）。在网络的区分服务区域内，路由器实现特定的PHB（聚合流量控制）。允许进入将接收特定PHB的Diffserv区域的总流量可能会受到边缘警务的限制。因此，我们期望网络的Diffserv区域能够支持从外围请求的Intserv类型的服务。在我们的框架中，我们解决了在网络的Diffserv区域上支持端到端集成服务的问题。我们的目标是实现无缝互操作。因此，网络管理员可以自由选择网络的哪些区域作为区分服务区域。在一个极端中，区分服务区域被一直推到外围，只有主机具有完整的Intserv功能。在另一个极端，Intserv被一直推到核心，没有区分服务区域。
In section 3 we discuss the benefits that can be realized by using the aggregate traffic control provided by Diffserv network regions in the broader context of the Intserv architecture. In section 4, we present the framework and the reference network. Section 5 details two possible realizations of the framework. Section 6 discusses the implications of the framework for Diffserv. Section 7 presents some issues specific to multicast flows.
在第3节中，我们讨论了在更广泛的Intserv体系结构背景下使用Diffserv网络区域提供的聚合流量控制可以实现的好处。在第4节中，我们介绍了框架和参考网络。第5节详细介绍了框架的两种可能实现。第6节讨论了Diffserv框架的含义。第7节介绍了特定于多播流的一些问题。
The primary benefit of Diffserv aggregate traffic control is its scalability. In this section, we discuss the benefits that interoperation with Intserv can bring to a Diffserv network region. Note that this discussion is in the context of servicing quantitative QoS applications specifically. By this we mean those applications that are able to quantify their traffic and QoS requirements.
Diffserv聚合流量控制的主要好处是其可扩展性。在本节中，我们将讨论与Intserv的互操作可以为Diffserv网络区域带来的好处。请注意，此讨论是在专门为定量QoS应用程序提供服务的上下文中进行的。我们指的是那些能够量化其流量和QoS需求的应用程序。
In Intserv networks, quantitative QoS applications use an explicit setup mechanism (e.g., RSVP) to request resources from the network. The network may accept or reject these requests in response. This is "explicit admission control". Explicit and dynamic admission control helps to assure that network resources are optimally used. To further understand this issue, consider a Diffserv network region providing only aggregate traffic control with no signaling. In the Diffserv network region, admission control is applied in a relatively static way by provisioning policing parameters at network elements. For example, a network element at the ingress to a Diffserv network region could be provisioned to accept only 50 Kbps of traffic for the EF DSCP.
在Intserv网络中，定量QoS应用程序使用显式设置机制（如RSVP）从网络请求资源。网络可以接受或拒绝这些请求作为响应。这就是“显式准入控制”。显式动态准入控制有助于确保网络资源得到最佳利用。为了进一步理解这个问题，考虑DiffServ网络区域，只提供没有信令的聚合业务控制。在Diffserv网络区域中，通过在网元上提供策略参数，以相对静态的方式应用准入控制。例如，可以将Diffserv网络区域入口处的网元设置为仅接受EF DSCP的50 Kbps流量。
While such static forms of admission control do protect the network to some degree, they can be quite ineffective. For example, consider that there may be 10 IP telephony sessions originating outside the Diffserv network region, each requiring 10 Kbps of EF service from the Diffserv network region. Since the network element protecting the Diffserv network region is provisioned to accept only 50 Kbps of traffic for the EF DSCP, it will discard half the offered traffic. This traffic will be discarded from the aggregation of traffic marked EF, with no regard to the microflow from which it originated. As a result, it is likely that of the ten IP telephony sessions, none will obtain satisfactory service when in fact, there are sufficient resources available in the Diffserv network region to satisfy five sessions.
虽然这种静态形式的准入控制在一定程度上保护了网络，但它们可能非常无效。例如，考虑到可能存在来自DiffServ网络区域之外的10个IP电话会话，每个都需要来自DiffServ网络区域的10 kbps的EF服务。由于保护Diffserv网络区域的网元配置为仅接受EF DSCP的50 Kbps流量，因此它将丢弃所提供流量的一半。该流量将从标记为EF的流量聚合中丢弃，而不考虑其来源的微流。因此，在十个IP电话会话中，如果事实上，Diffserv网络区域中有足够的可用资源来满足五个会话，则很可能没有一个会话能够获得令人满意的服务。
In the case of explicitly signaled, dynamic admission control, the network will signal rejection in response to requests for resources that would exceed the 50 Kbps limit. As a result, upstream network elements (including originating hosts) and applications will have the information they require to take corrective action. The application might respond by refraining from transmitting, or by requesting admission for a lesser traffic profile. The host operating system might respond by marking the application's traffic for the DSCP that corresponds to best-effort service. Upstream network elements might respond by re-marking packets on the rejected flow to a lower service
在明确发出信号的动态许可控制的情况下，网络将发出信号拒绝，以响应超过50 Kbps限制的资源请求。因此，上游网元（包括原始主机）和应用程序将拥有采取纠正措施所需的信息。应用程序的响应可能是避免传输，或者请求允许较小的流量配置文件。主机操作系统可能会通过为对应于尽力而为服务的DSCP标记应用程序的通信量来响应。上游网络元件可以通过将被拒绝流上的分组重新标记到较低的服务来响应
level. In some cases, it may be possible to reroute traffic over alternate paths or even alternate networks (e.g., the PSTN for voice calls). In any case, the integrity of those flows that were admitted would be preserved, at the expense of the flows that were not admitted. Thus, by appointing an Intserv-conversant admission control agent for the Diffserv region of the network it is possible to enhance the service that the network can provide to quantitative QoS applications.
数量在某些情况下，可以通过备用路径甚至备用网络（例如，用于语音呼叫的PSTN）重新路由流量。在任何情况下，被接纳的流的完整性都将得到保护，代价是不被接纳的流。因此，通过为网络的Diffserv区域指定熟悉Intserv的接纳控制代理，可以增强网络可以向定量QoS应用提供的服务。
In network regions where RSVP is used, resource requests can be intercepted by RSVP-aware network elements and can be reviewed against policies stored in policy databases. These resource requests securely identify the user and the application for which the resources are requested. Consequently, the network element is able to consider per-user and/or per-application policy when deciding whether or not to admit a resource request. So, in addition to optimizing the use of resources in a Diffserv network region (as discussed in 3.1) RSVP conversant admission control agents can be used to apply specific customer policies in determining the specific customer traffic flows entitled to use the Diffserv network region's resources. Customer policies can be used to allocate resources to specific users and/or applications.
在使用RSVP的网络区域中，支持RSVP的网络元素可以拦截资源请求，并可以根据存储在策略数据库中的策略进行审查。这些资源请求安全地标识请求资源的用户和应用程序。因此，网络单元能够在决定是否承认资源请求时考虑每个用户和/或每个应用策略。因此，除了优化区分服务网络区域中资源的使用（如3.1中所述），熟悉RSVP的准入控制代理还可用于应用特定的客户策略，以确定有权使用区分服务网络区域资源的特定客户流量。客户策略可用于将资源分配给特定用户和/或应用程序。
By comparison, in Diffserv network regions without RSVP signaling, policies are typically applied based on the Diffserv customer network from which traffic originates, not on the originating user or application within the customer network.
相比之下，在没有RSVP信令的Diffserv网络区域中，通常基于业务发起的Diffserv客户网络而不是客户网络中的发起用户或应用程序应用策略。
Within Diffserv network regions, traffic is allotted service based on the DSCP marked in each packet's IP header. Thus, in order to obtain a particular level of service within the Diffserv network region, it is necessary to effect the marking of the correct DSCP in packet headers. There are two mechanisms for doing so, host marking and router marking. In the case of host marking, the host operating system marks the DSCP in transmitted packets. In the case of router marking, routers in the network are configured to identify specific traffic (typically based on MF classification) and to mark the DSCP as packets transit the router. There are advantages and disadvantages to each scheme. Regardless of the scheme used, explicit signaling offers significant benefits.
在Diffserv网络区域内，流量根据每个数据包的IP报头中标记的DSCP分配服务。因此，为了在Diffserv网络区域内获得特定级别的服务，有必要在分组报头中对正确的DSCP进行标记。这样做有两种机制，主机标记和路由器标记。在主机标记的情况下，主机操作系统在传输的数据包中标记DSCP。在路由器标记的情况下，网络中的路由器被配置为识别特定的通信量（通常基于MF分类），并将DSCP标记为通过路由器的数据包。每种方案都有优点和缺点。无论使用何种方案，显式信令都提供了显著的好处。
In the case of host marking, the host operating system marks the DSCP in transmitted packets. This approach has the benefit of shifting per-flow classification and marking to the source of the traffic, where it scales best. It also enables the host to make decisions regarding the mark that is appropriate for each transmitted packet and hence the relative importance attached to each packet. The host is generally better equipped to make this decision than the network. Furthermore, if IPSEC encryption is used, the host may be the only device in the network that is able to make a meaningful determination of the appropriate marking for each packet, since various fields such as port numbers would be unavailable to routers for MF classification.
在主机标记的情况下，主机操作系统在传输的数据包中标记DSCP。这种方法的优点是将每流分类和标记转移到交通源，在那里它的规模最大。它还使主机能够作出关于适合于每个传输分组的标记的决定，从而决定对每个分组的相对重视程度。主机通常比网络更有能力做出这一决定。此外，如果使用IPSEC加密，则主机可能是网络中能够对每个分组的适当标记进行有意义的确定的唯一设备，因为诸如端口号之类的各种字段将不可用于路由器的MF分类。
Host marking requires that the host be aware of the interpretation of DSCPs by the network. This information can be configured into each host. However, such configuration imposes a management burden. Alternatively, hosts can use an explicit signaling protocol such as RSVP to query the network to obtain a suitable DSCP or set of DSCPs to apply to packets for which a certain Intserv service has been requested. An example of how this can be achieved is described in [14].
主机标记要求主机知道网络对DSCP的解释。可以在每个主机中配置此信息。然而，这种配置会带来管理负担。或者，主机可以使用诸如RSVP之类的显式信令协议来查询网络以获得合适的DSCP或DSCP集，以应用于已请求特定Intserv服务的分组。[14]中描述了如何实现这一点的示例。
In the case of router marking, MF classification criteria must be configured in the router in some way. This may be done dynamically (e.g., using COPS provisioning), by request from the host operating system, or statically via manual configuration or via automated scripts.
在路由器标记的情况下，必须以某种方式在路由器中配置MF分类标准。这可以通过主机操作系统的请求动态完成（例如，使用COPS配置），也可以通过手动配置或自动脚本静态完成。
There are significant difficulties in doing so statically. In many cases, it is desirable to allot service to traffic based on the application and/or user originating the traffic. At times it is possible to identify packets associated with a specific application by the IP port numbers in the headers. It may also be possible to identify packets originating from a specific user by the source IP address. However, such classification criteria may change frequently. Users may be assigned different IP addresses by DHCP. Applications may use transient ports. To further complicate matters, multiple users may share an IP address. These factors make it very difficult to manage static configuration of the classification information required to mark traffic in routers.
静态地这样做有很大的困难。在许多情况下，希望基于发起业务的应用程序和/或用户将服务分配给业务。有时，可以通过报头中的IP端口号来识别与特定应用程序关联的数据包。还可以通过源IP地址识别源自特定用户的分组。然而，此类分类标准可能会经常变化。DHCP可以为用户分配不同的IP地址。应用程序可以使用瞬态端口。更复杂的是，多个用户可能共享一个IP地址。这些因素使得管理路由器中标记流量所需的分类信息的静态配置非常困难。
An attractive alternative to static configuration is to allow host operating systems to signal classification criteria to the router on behalf of users and applications. As we will show later in this
静态配置的一个有吸引力的替代方案是允许主机操作系统代表用户和应用程序向路由器发送分类标准信号。正如我们将在本章后面介绍的
document, RSVP signaling is ideally suited for this task. In addition to enabling dynamic and accurate updating of MF classification criteria, RSVP signaling enables classification of IPSEC [13] packets (by use of the SPI) which would otherwise be unrecognizable.
文档中，RSVP信令非常适合此任务。除了支持MF分类标准的动态和准确更新外，RSVP信令还支持IPSEC[13]数据包的分类（通过使用SPI），否则这些数据包将无法识别。
Intserv-capable network elements are able to condition traffic at a per-flow granularity, by some combination of shaping and/or policing. Pre-conditioning traffic in this manner before it is submitted to the Diffserv region of the network is beneficial. In particular, it enhances the ability of the Diffserv region of the network to provide quantitative services using aggregate traffic control.
支持Intserv的网元能够通过某种整形和/或监管组合，以每流粒度调节流量。在将流量提交到网络的区分服务区域之前，以这种方式预先调节流量是有益的。特别是，它增强了网络区分服务区域使用聚合流量控制提供定量服务的能力。
In the general framework we envision an Internet in which the Integrated Services architecture is used to deliver end-to-end QOS to applications. The network includes some combination of Intserv capable nodes (in which MF classification and per-flow traffic control is applied) and Diffserv regions (in which aggregate traffic control is applied). Individual routers may or may not participate in RSVP signaling regardless of where in the network they reside.
在通用框架中，我们设想了一个使用集成服务体系结构向应用程序提供端到端QOS的Internet。该网络包括一些支持Intserv的节点（其中应用了MF分类和按流流量控制）和Diffserv区域（其中应用了聚合流量控制）的组合。单个路由器可能参与也可能不参与RSVP信令，无论它们位于网络中的何处。
We will consider two specific realizations of the framework. In the first, resources within the Diffserv regions of the network are statically provisioned and these regions include no RSVP aware devices. In the second, resources within the Diffserv region of the network are dynamically provisioned and select devices within the Diffserv network regions participate in RSVP signaling.
我们将考虑框架的两个具体实现。在第一种情况下，网络的Diffserv区域内的资源是静态供应的，并且这些区域不包括RSVP感知设备。在第二种情况下，动态地供应网络的Diffserv区域内的资源，并且Diffserv网络区域内的选择设备参与RSVP信令。
The two realizations of the framework will be discussed in the context of the following reference network:
将在以下参考网络的背景下讨论框架的两种实现：
________ ______________ ________
/ \ / \ / \
/ \ / \ / \
|---| | |---| |---| |---| |---| | |---|
|Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx |
|---| | |-- | |---| |---| |---| | |---|
\ / \ / \ /
\________/ \______________/ \________/
________ ______________ ________
/ \ / \ / \
/ \ / \ / \
|---| | |---| |---| |---| |---| | |---|
|Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx |
|---| | |-- | |---| |---| |---| | |---|
\ / \ / \ /
\________/ \______________/ \________/
Non-Diffserv region Diffserv region Non-Diffserv region
非区分服务区域区分服务区域非区分服务区域
Figure 1: Sample Network Configuration
图1：示例网络配置
The reference network includes a Diffserv region in the middle of a larger network supporting Intserv end-to-end. The Diffserv region contains a mesh of routers, at least some of which provide aggregate traffic control. The regions outside the Diffserv region (non-Diffserv regions) contain meshes of routers and attached hosts, at least some of which support the Integrated Services architecture.
参考网络包括在支持ItServ端到端的较大网络中间的DiffServ区域。Diffserv区域包含一个路由器网格，其中至少一些路由器提供聚合流量控制。区分服务区域（非区分服务区域）之外的区域包含路由器和连接主机的网格，其中至少一些支持集成服务体系结构。
In the interest of simplicity we consider a single QoS sender, Tx communicating across this network with a single QoS receiver, Rx. The edge routers (ER1, ER2) which are adjacent to the Diffserv region interface to the border routers (BR1, BR2) within the Diffserv region.
为了简单起见，我们考虑单个QoS发送器，Tx在这个网络上与单个QoS接收器Rx通信。与区分服务区域相邻的边缘路由器（ER1，ER2）与区分服务区域内的边界路由器（BR1，BR2）接口。
From an economic viewpoint, we may consider that the Diffserv region sells service to the network outside the Diffserv region, which in turn provides service to hosts. Thus, we may think of the non-Diffserv regions as clients or customers of the Diffserv region. In the following, we use the term "customer" for the non-Diffserv regions. Note that the boundaries of the regions may or may not align with administrative domain boundaries, and that a single region might contain multiple administrative domains.
从经济学的角度来看，我们可以认为DiffServ区域向区分服务区域之外的网络销售服务，服务又向主机提供服务。因此，我们可以将非区分服务区域视为区分服务区域的客户或客户。在下文中，我们将术语“客户”用于非区分服务区域。请注意，区域的边界可能与管理域边界对齐，也可能不对齐，并且单个区域可能包含多个管理域。
We now define the major components of the reference network.
我们现在定义参考网络的主要组件。
We assume that both sending and receiving hosts use RSVP to communicate the quantitative QoS requirements of QoS-aware applications running on the host. In principle, other mechanisms may be used to establish resource reservations in Intserv-capable nodes,
我们假设发送主机和接收主机都使用RSVP来传递主机上运行的QoS感知应用程序的定量QoS需求。原则上，其他机制可用于在支持Intserv的节点中建立资源保留，
but RSVP is clearly the prevalent mechanism for this purpose.
但RSVP显然是实现这一目的的普遍机制。
Typically, a QoS process within the host operating system generates RSVP signaling on behalf of applications. This process may also invoke local traffic control.
通常，主机操作系统内的QoS过程代表应用程序生成RSVP信令。此过程还可以调用本地流量控制。
As discussed above, traffic control in the host may mark the DSCP in transmitted packets, and shape transmitted traffic to the requirements of the Intserv service in use. Alternatively, the first Intserv-capable router downstream from the host may provide these traffic control functions.
如上所述，主机中的业务控制可以在所发送的分组中标记DSCP，并根据所使用的Intserv服务的要求塑造所发送的业务。或者，主机下游的第一个支持Intserv的路由器可以提供这些业务控制功能。
We assume that RSVP signaling messages travel end-to-end between hosts Tx and Rx to support RSVP/Intserv reservations outside the Diffserv network region. We require that these end-to-end RSVP messages are at least carried across the Diffserv region. Depending on the specific realization of the framework, these messages may be processed by none, some or all of the routers in the Diffserv region.
我们假设RSVP信令消息在主机Tx和Rx之间端到端传输，以支持区分服务网络区域外的RSVP/Intserv保留。我们要求这些端到端RSVP消息至少在Diffserv区域中传输。根据框架的具体实现，这些消息可能不由Diffserv区域中的任何、部分或全部路由器处理。
ER1 and ER2 are edge routers, residing adjacent to the Diffserv network regions. The functionality of the edge routers varies depending on the specific realization of the framework. In the case in which the Diffserv network region is RSVP unaware, edge routers act as admission control agents to the Diffserv network. They process signaling messages from both Tx and Rx, and apply admission control based on resource availability within the Diffserv network region and on customer defined policy. In the case in which the Diffserv network region is RSVP aware, the edge routers apply admission control based on local resource availability and on customer defined policy. In this case, the border routers act as the admission control agent to the Diffserv network region.
ER1和ER2是边缘路由器，位于区分服务网络区域附近。边缘路由器的功能根据框架的具体实现而有所不同。在区分服务网络区域不知道RSVP的情况下，边缘路由器充当区分服务网络的准入控制代理。它们处理来自Tx和Rx的信令消息，并根据Diffserv网络区域内的资源可用性和客户定义的策略应用准入控制。在区分服务网络区域是RSVP感知的情况下，边缘路由器基于本地资源可用性和客户定义的策略应用接纳控制。在这种情况下，边界路由器充当区分服务网络区域的准入控制代理。
We will later describe the functionality of the edge routers in greater depth for each of the two realizations of the framework.
稍后，我们将更深入地描述框架的两种实现的边缘路由器的功能。
BR1 and BR2 are border routers, residing in the Diffserv network region. The functionality of the border routers varies depending on the specific realization of the framework. In the case in which the Diffserv network region is RSVP-unaware, these routers act as pure Diffserv routers. As such, their sole responsibility is to police submitted traffic based on the service level specified in the DSCP and the agreement negotiated with the customer (aggregate
BR1和BR2是边界路由器，位于Diffserv网络区域。边界路由器的功能根据框架的具体实现而有所不同。在区分服务网络区域不知道RSVP的情况下，这些路由器充当纯区分服务路由器。因此，他们的唯一责任是根据DSCP中规定的服务级别以及与客户协商的协议（合计）对提交的流量进行监控
trafficcontrol). In the case in which the Diffserv network region is RSVP-aware, the border routers participate in RSVP signaling and act as admission control agents for the Diffserv network region.
交通管制）。在区分服务网络区域感知RSVP的情况下，边界路由器参与RSVP信令并充当区分服务网络区域的接纳控制代理。
We will later describe the functionality of the border routers in greater depth for each of the two realizations of the framework.
稍后，我们将更深入地描述框架的两种实现中的每一种的边界路由器的功能。
The Diffserv network region supports aggregate traffic control and is assumed not to be capable of MF classification. Depending on the specific realization of the framework, some number of routers within the Diffserv region may be RSVP aware and therefore capable of per-flow signaling and admission control. If devices in the Diffserv region are not RSVP aware, they will pass RSVP messages transparently with negligible performance impact (see [6]).
Diffserv网络区域支持聚合流量控制，并且假定不能够进行MF分类。取决于框架的具体实现，区分服务区域内的一些路由器可以是RSVP感知的，因此能够进行每流信令和准入控制。如果Diffserv区域中的设备不知道RSVP，它们将透明地传递RSVP消息，而对性能的影响可以忽略不计（请参见[6]）。
The Diffserv network region provides two or more levels of service based on the DSCP in packet headers. It may be a single administrative domain or may span multiple domains.
Diffserv网络区域基于数据包头中的DSCP提供两个或两个以上级别的服务。它可以是单个管理域，也可以跨越多个域。
The network outside of the Diffserv region consists of Intserv capable hosts and other network elements. Other elements may include routers and perhaps various types of network (e.g., 802, ATM, etc.). These network elements may reasonably be assumed to support Intserv, although this might not be required in the case of over-provisioning. Even if these elements are not Intserv capable, we assume that they will pass RSVP messages unhindered. Routers outside of the Diffserv network region are not precluded from providing aggregate traffic control to some subset of the traffic passing through them.
Diffserv区域之外的网络由支持Intserv的主机和其他网元组成。其他元件可包括路由器和可能各种类型的网络（例如，802、ATM等）。可以合理地假设这些网元支持Intserv，尽管在过度供应的情况下可能不需要这样做。即使这些元素不支持Intserv，我们也假定它们将不受阻碍地传递RSVP消息。不排除Diffserv网络区域之外的路由器为通过它们的某些流量子集提供聚合流量控制。
Intserv service requests specify an Intserv service type and a set of quantitative parameters known as a "flowspec". At each hop in an Intserv network, the Intserv service requests are interpreted in a form meaningful to the specific link layer medium. For example at an 802.1 hop, the Intserv parameters are mapped to an appropriate 802.1p priority level [5].
Intserv服务请求指定一个Intserv服务类型和一组称为“flowspec”的定量参数。在Intserv网络中的每个跃点，Intserv服务请求以对特定链路层介质有意义的形式被解释。例如，在802.1跳中，Intserv参数映射到适当的802.1p优先级[5]。
In our framework, Diffserv regions of the network are analogous to the 802.1p capable switched segments described in [5]. Requests for Intserv services must be mapped onto the underlying capabilities of the Diffserv network region. Aspects of the mapping include:
在我们的框架中，网络的区分服务区域类似于[5]中描述的支持802.1p的交换段。对Intserv服务的请求必须映射到Diffserv网络区域的底层功能。映射的各个方面包括：
- selecting an appropriate PHB, or set of PHBs, for the requested service; - performing appropriate policing (including, perhaps, shaping or remarking) at the edges of the Diffserv region; - exporting Intserv parameters from the Diffserv region (e.g., for the updating of ADSPECs); - performing admission control on the Intserv requests that takes into account the resource availability in the Diffserv region.
- 为请求的服务选择适当的PHB或一组PHB；-在区分服务区域的边缘执行适当的监管（可能包括塑造或评论）；-从Diffserv区域导出Intserv参数（例如，用于更新ADSPEC）；-在考虑区分服务区域中的资源可用性的情况下，对Intserv请求执行准入控制。
Exactly how these functions are performed will be a function of the way bandwidth is managed inside the Diffserv network region, which is a topic we discuss in Section 4.3.
这些功能的具体执行方式取决于区分服务网络区域内带宽的管理方式，这是我们在第4.3节中讨论的主题。
When the PHB (or set of PHBs) has been selected for a particular Intserv flow, it may be necessary to communicate the choice of DSCP for the flow to other network elements. Two schemes may be used to achieve this end, as discussed below.
当为特定Intserv流选择了PHB（或一组PHB）时，可能需要将流的DSCP选择传达给其他网元。如下文所述，可使用两种方案来实现这一目的。
In this scheme, there is some standard, well-known mapping from Intserv service type to a DSCP that will invoke the appropriate behavior in the Diffserv network.
在该方案中，存在一些标准的、众所周知的从Intserv服务类型到DSCP的映射，该映射将调用Diffserv网络中的适当行为。
In this scheme, RSVP conversant routers in the Diffserv network region (perhaps at its edge) may override the well-known mapping described in 4.2.1. In the case that DSCPs are marked at the ingress to the Diffserv region, the DSCPs can simply be remarked at the boundary routers. However, in the case that DSCP marking occurs upstream of the Diffserv region, either in a host or a router, then the appropriate mapping needs to be communicated upstream, to the marking device. This may be accomplished using RSVP, as described in [14].
在该方案中，区分服务网络区域（可能在其边缘）中的熟悉RSVP的路由器可以覆盖4.2.1中描述的众所周知的映射。在区分服务区域入口处标记DSCP的情况下，可以简单地在边界路由器处标记DSCP。然而，如果DSCP标记发生在Diffserv区域的上游（在主机或路由器中），则需要将适当的映射传送到标记设备的上游。如[14]所述，这可以使用RSVP实现。
The decision regarding where to mark DSCP and whether to override the well-known service mapping is a mater of policy to be decided by the administrator of the Diffserv network region in cooperation with the administrator of the network adjacent to the Diffserv region.
关于在何处标记DSCP以及是否覆盖众所周知的服务映射的决定是由区分服务网络区域的管理员与邻近区分服务区域的网络管理员合作决定的策略问题。
Boundary routers residing at the edge of the Diffserv region will typically police traffic submitted from the outside the Diffserv region in order to protect resources within the Diffserv region. This policing will be applied on an aggregate basis, with no regard for the individual microflows making up each aggregate. As a result,
位于区分服务区域边缘的边界路由器通常会对从区分服务区域外部提交的流量进行监控，以保护区分服务区域内的资源。这一监管将以总量为基础，不考虑构成每个总量的单个微流。因此
it is possible for a misbehaving microflow to claim more than its fair share of resources within the aggregate, thereby degrading the service provided to other microflows. This problem may be addressed by:
行为不端的微流有可能要求超过其在总资源中的公平份额，从而降低向其他微流提供的服务。这个问题可以通过以下方式解决：
1. Providing per microflow policing at the edge routers - this is generally the most appropriate location for microflow policing, since it pushes per-flow work to the edges of the network, where it scales better. In addition, since Intserv-capable routers outside the Diffserv region are responsible for providing microflow service to their customers and the Diffserv region is responsible for providing aggregate service to its customers, this distribution of functionality mirrors the distribution of responsibility.
1. 在边缘路由器上提供每微流监控-这通常是微流监控的最合适位置，因为它将每流工作推送到网络的边缘，在那里可以更好地扩展。此外，由于Diffserv区域外支持Intserv的路由器负责向其客户提供微流服务，而Diffserv区域负责向其客户提供聚合服务，因此这种功能分布反映了责任分布。
2. Providing per microflow policing at the border routers - this approach tends to be less scalable than the previous approach. It also imposes a management burden on the Diffserv region of the network. However, it may be appropriate in certain cases, for the Diffserv boundary routers to offer per microflow policing as a value-add to its Intserv customers.
2. 在边界路由器上提供按微流量管理-这种方法的可扩展性往往不如以前的方法。它还对网络的区分服务区域施加了管理负担。然而，在某些情况下，Diffserv边界路由器可能适合提供每微流监控，作为对其Intserv客户的增值。
3. Relying on upstream shaping and policing - in certain cases, the customer may trust the shaping of certain groups of hosts sufficiently to not warrant reshaping or policing at the boundary of the Diffserv region. Note that, even if the hosts are shaping microflows properly, these shaped flows may become distorted as they transit through the non-Diffserv region of the network. Depending on the degree of distortion, it may be necessary to somewhat over-provision the aggregate capacities in the Diffserv region, or to re-police using either 1 or 2 above. The choice of one mechanism or another is a matter of policy to be decided by the administrator of the network outside the Diffserv region.
3. 依赖上游整形和监管-在某些情况下，客户可能充分信任特定主机组的整形，从而不保证在区分服务区域边界处整形或监管。注意，即使主机正确地塑造微流，这些塑造的流在通过网络的非区分服务区域时也可能会失真。根据失真程度，可能需要在一定程度上过度提供Diffserv区域中的总容量，或使用上述1或2进行重新监管。选择一种或另一种机制是由Diffserv区域之外的网络管理员决定的策略问题。
A variety of options exist for management of resources (e.g., bandwidth) in the Diffserv network regions to meet the needs of end-to-end Intserv flows. These options include:
Diffserv网络区域中的资源（例如带宽）管理有多种选择，以满足端到端Intserv流的需要。这些选择包括：
- statically provisioned resources; - resources dynamically provisioned by RSVP; - resources dynamically provisioned by other means (e.g., a form of Bandwidth Broker).
- 静态配置的资源；-由RSVP动态配置的资源；-通过其他方式（例如，一种形式的带宽代理）动态调配的资源。
Some of the details of using each of these different approaches are discussed in the following section.
下面一节将讨论使用这些不同方法的一些细节。
In this section we provide detailed examples of our framework in action. We discuss two examples, one in which the Diffserv network region is RSVP unaware, the other in which the Diffserv network region is RSVP aware.
在本节中，我们将提供我们的框架的详细示例。我们讨论了两个例子，一个是区分服务网络区域不知道RSVP，另一个是区分服务网络区域知道RSVP。
In this example, no devices in the Diffserv network region are RSVP aware. The Diffserv network region is statically provisioned. The customer(s) of the Diffserv network regions and the owner of the Diffserv network region have negotiated a static contract (service level specification, or SLS) for the transmit capacity to be provided to the customer at each of a number of standard Diffserv service levels. The "transmit capacity" may be simply an amount of bandwidth or it could be a more complex "profile" involving a number of factors such as burst size, peak rate, time of day etc.
在此示例中，Diffserv网络区域中的任何设备都不支持RSVP。区分服务网络区域是静态配置的。Diffserv网络区域的客户和Diffserv网络区域的所有者已就在多个标准Diffserv服务级别中的每个级别向客户提供的传输容量协商了静态合同（服务级别规范，或SLS）。“传输容量”可以是简单的带宽量，也可以是涉及诸如突发大小、峰值速率、一天中的时间等许多因素的更复杂的“配置文件”。
It is helpful to consider each edge router in the customer network as consisting of two halves, a standard Intserv half, which interfaces to the customer's network regions and a Diffserv half which interfaces to the Diffserv network region. The Intserv half is able to identify and process traffic on per-flow granularity.
将客户网络中的每个边缘路由器看作是由两个半部组成的，一个标准的ItServ半，它连接到客户的网络区域和DiffServ半部分，后者与DiffServ网络区域连接。Intserv的一半能够识别和处理每个流粒度上的流量。
The Diffserv half of the router can be considered to consist of a number of virtual transmit interfaces, one for each Diffserv service level negotiated in the SLS. The router contains a table that indicates the transmit capacity provisioned, per the SLS at each Diffserv service level. This table, in conjunction with the default mapping described in 4.2.1, is used to perform admission control decisions on Intserv flows which cross the Diffserv network region.
路由器的Diffserv半部分可被视为由多个虚拟传输接口组成，SLS中协商的每个Diffserv服务级别对应一个虚拟传输接口。路由器包含一个表，该表指示在每个Diffserv服务级别为每个SLS提供的传输容量。此表与4.2.1中描述的默认映射一起，用于对跨Diffserv网络区域的Intserv流执行准入控制决策。
The following sequence illustrates the process by which an application obtains end-to-end QoS when RSVP is used by the hosts.
以下序列说明了当主机使用RSVP时，应用程序获得端到端QoS的过程。
1. The QoS process on the sending host Tx generates an RSVP PATH message that describes the traffic offered by the sending application.
1. 发送主机Tx上的QoS进程生成一条RSVP PATH消息，该消息描述发送应用程序提供的通信量。
2. The PATH message is carried toward the receiving host, Rx. In the network region to which the sender is attached, standard RSVP/Intserv processing is applied at capable network elements.
2. 路径消息被传送到接收主机Rx。在发送方所连接的网络区域中，标准RSVP/Intserv处理应用于有能力的网络元件。
3. At the edge router ER1, the PATH message is subjected to standard RSVP processing and PATH state is installed in the router. The PATH
3. 在边缘路由器ER1处，路径消息经受标准RSVP处理，并且路径状态安装在路由器中。路径
message is sent onward to the Diffserv network region.
消息向前发送到Diffserv网络区域。
4. The PATH message is ignored by routers in the Diffserv network region and then processed at ER2 according to standard RSVP processing rules.
4. Diffserv网络区域中的路由器忽略路径消息，然后根据标准RSVP处理规则在ER2进行处理。
5. When the PATH message reaches the receiving host Rx, the operating system generates an RSVP RESV message, indicating interest in offered traffic of a certain Intserv service type.
5. 当PATH消息到达接收主机Rx时，操作系统生成一条RSVP RESV消息，表示对提供的特定Intserv服务类型的流量感兴趣。
6. The RESV message is carried back towards the Diffserv network region and the sending host. Consistent with standard RSVP/Intserv processing, it may be rejected at any RSVP-capable node in the path if resources are deemed insufficient to carry the traffic requested.
6. RESV消息被带回Diffserv网络区域和发送主机。与标准RSVP/Intserv处理一致，如果认为资源不足以承载请求的流量，则可能会在路径中任何支持RSVP的节点上拒绝该请求。
7. At ER2, the RESV message is subjected to standard RSVP/Intserv processing. It may be rejected if resources on the downstream interface of ER2 are deemed insufficient to carry the resources requested. If it is not rejected, it will be carried transparently through the Diffserv network region, arriving at ER1.
7. 在ER2，RESV消息接受标准RSVP/Intserv处理。如果ER2下游接口上的资源被认为不足以承载请求的资源，则可能会被拒绝。如果未被拒绝，它将透明地通过Diffserv网络区域传输，到达ER1。
8. In ER1, the RESV message triggers admission control processing. ER1 compares the resources requested in the RSVP/Intserv request to the resources available in the Diffserv network region at the corresponding Diffserv service level. The corresponding service level is determined by the Intserv to Diffserv mapping discussed previously. The availability of resources is determined by the capacity provisioned in the SLS. ER1 may also apply a policy decision such that the resource request may be rejected based on the customer's specific policy criteria, even though the aggregate resources are determined to be available per the SLS.
8. 在ER1中，RESV消息触发准入控制处理。ER1将RSVP/Intserv请求中请求的资源与相应Diffserv服务级别的Diffserv网络区域中可用的资源进行比较。相应的服务级别由前面讨论的Intserv到Diffserv映射确定。资源的可用性由SLS中提供的容量决定。ER1还可以应用策略决策，使得资源请求可以基于客户的特定策略标准被拒绝，即使根据SLS确定聚合资源可用。
9. If ER1 approves the request, the RESV message is admitted and is allowed to continue upstream towards the sender. If it rejects the request, the RESV is not forwarded and the appropriate RSVP error messages are sent. If the request is approved, ER1 updates its internal tables to indicate the reduced capacity available at the admitted service level on its transmit interface.
9. 如果ER1批准该请求，则RESV消息被接纳并允许继续向发送方上游发送。如果拒绝请求，则不转发RESV，并发送相应的RSVP错误消息。如果请求获得批准，ER1将更新其内部表格，以在其传输接口上指示在允许的服务级别上可用的减少容量。
10. The RESV message proceeds through the network region to which the sender is attached. Any RSVP node in this region may reject the reservation request due to inadequate resources or policy. If the request is not rejected, the RESV message will arrive at the sending host, Tx.
10. RESV消息通过发送方所连接的网络区域继续发送。由于资源或策略不足，此区域中的任何RSVP节点都可能拒绝保留请求。如果请求未被拒绝，RESV消息将到达发送主机Tx。
11. At Tx, the QoS process receives the RESV message. It interprets receipt of the message as indication that the specified traffic flow has been admitted for the specified Intserv service type (in the
11. 在Tx，QoS进程接收RESV消息。它将消息的接收解释为指示指定的Intserv服务类型（在
Intserv-capable nodes). It may also learn the appropriate DSCP marking to apply to packets for this flow from information provided in the RESV.
支持Intserv的节点）。它还可以从RESV中提供的信息中了解适用于该流的数据包的适当DSCP标记。
12. Tx may mark the DSCP in the headers of packets that are transmitted on the admitted traffic flow. The DSCP may be the default value which maps to the Intserv service type specified in the admitted RESV message, or it may be a value explicitly provided in the RESV.
12. Tx可以在在允许的业务流上传输的分组的报头中标记DSCP。DSCP可以是默认值，映射到允许的RESV消息中指定的Intserv服务类型，也可以是RESV中明确提供的值。
In this manner, we obtain end-to-end QoS through a combination of networks that support RSVP/Intserv and networks that support Diffserv.
通过这种方式，我们通过支持RSVP/Intserv的网络和支持Diffserv的网络的组合来获得端到端的QoS。
In this example, the customer's edge routers are standard RSVP routers. The border router, BR1 is RSVP aware. In addition, there may be other routers within the Diffserv network region which are RSVP aware. Note that although these routers are able to participate in some form of RSVP signaling, they classify and schedule traffic in aggregate, based on DSCP, not on the per-flow classification criteria used by standard RSVP/Intserv routers. It can be said that their control-plane is RSVP while their data-plane is Diffserv. This approach exploits the benefits of RSVP signaling while maintaining much of the scalability associated with Diffserv.
在此示例中，客户的边缘路由器是标准RSVP路由器。边界路由器BR1可识别RSVP。此外，Diffserv网络区域内可能存在其他可感知RSVP的路由器。请注意，尽管这些路由器能够参与某种形式的RSVP信令，但它们根据DSCP（而不是标准RSVP/Intserv路由器使用的每流分类标准）对流量进行分类和调度。可以说，它们的控制平面是RSVP，而数据平面是Diffserv。这种方法利用了RSVP信令的优点，同时保持了与Diffserv相关的大部分可伸缩性。
In the preceding example, there is no signaling between the Diffserv network region and network elements outside it. The negotiation of an SLS is the only explicit exchange of resource availability information between the two network regions. ER1 is configured with the information represented by the SLS and as such, is able to act as an admission control agent for the Diffserv network region. Such configuration does not readily support dynamically changing SLSs, since ER1 requires reconfiguration each time the SLS changes. It is also difficult to make efficient use of the resources in the Diffserv network region. This is because admission control does not consider the availability of resources in the Diffserv network region along the specific path that would be impacted.
在前面的示例中，区分服务网络区域和其外部的网络元素之间没有信令。SLS的协商是两个网络区域之间资源可用性信息的唯一显式交换。ER1被配置为具有由SLS表示的信息，并且因此能够充当区分服务网络区域的接纳控制代理。这种配置不容易支持动态变化的SLS，因为ER1需要在每次SLS变化时重新配置。区分服务网络区域的资源也很难得到有效利用。这是因为接纳控制不考虑DiffServ网络区域中的资源的可用性，这将受到特定路径的影响。
By contrast, when the Diffserv network region is RSVP aware, the admission control agent is part of the Diffserv network. As a result, changes in the capacity available in the Diffserv network region can be indicated to the Intserv-capable nodes outside the Diffserv region via RSVP. By including routers interior to the Diffserv network region in RSVP signaling, it is possible to simultaneously improve the efficiency of resource usage within the Diffserv region and to improve the level of confidence that the
相反，当区分服务网络区域是RSVP感知的时，接纳控制代理是区分服务网络的一部分。因此，可以通过RSVP向Diffserv区域外的支持Intserv的节点指示Diffserv网络区域中可用容量的变化。通过在RSVP信令中包括Diffserv网络区域内部的路由器，可以同时提高Diffserv区域内的资源使用效率，并提高所述路由器的置信水平
resources requested at admission control are indeed available at this particular point in time. This is because admission control can be linked to the availability of resources along the specific path that would be impacted. We refer to this benefit of RSVP signaling as "topology aware admission control". A further benefit of supporting RSVP signaling within the Diffserv network region is that it is possible to effect changes in the provisioning of the Diffserv network region (e.g., allocating more or less bandwidth to the EF queue in a router) in response to resource requests from outside of the Diffserv region.
允许控制请求的资源在此特定时间点确实可用。这是因为准入控制可以链接到将受到影响的特定路径上的资源可用性。我们将RSVP信令的这一优点称为“拓扑感知接纳控制”。在区分服务网络区域内支持RSVP信令的另一个好处是，响应于来自区分服务区域外部的资源请求，可以对区分服务网络区域的供应进行改变（例如，将更多或更少的带宽分配给路由器中的EF队列）。
Various mechanisms may be used within the Diffserv network region to support dynamic provisioning and topology aware admission control. These include aggregated RSVP, per-flow RSVP and bandwidth brokers, as described in the following paragraphs.
可以在区分服务网络区域内使用各种机制来支持动态供应和拓扑感知的接纳控制。这些包括聚合RSVP、每流RSVP和带宽代理，如以下段落所述。
A number of documents [3,6,15,16] propose mechanisms for extending RSVP to reserve resources for an aggregation of flows between edges of a network. Border routers may interact with core routers and other border routers using aggregated RSVP to reserve resources between edges of the Diffserv network region. Initial reservation levels for each service level may be established between major border routers, based on anticipated traffic patterns. Border routers could trigger changes in reservation levels as a result of the cumulative per-flow RSVP requests from the non-Diffserv regions reaching high or low-water marks.
许多文件[3,6,15,16]提出了扩展RSVP的机制，以便为网络边缘之间的流聚合保留资源。边界路由器可以使用聚合的RSVP与核心路由器和其他边界路由器交互，以在区分服务网络区域的边缘之间保留资源。根据预期的业务模式，可以在主要边界路由器之间建立每个服务级别的初始保留级别。由于来自非区分服务区域的累积每流RSVP请求达到高或低水位线，边界路由器可能会触发保留级别的变化。
In this approach, admission of per-flow RSVP requests from nodes outside the Diffserv region would be counted against the appropriate aggregate reservations for the corresponding service level. The size of the aggregate reservations may or may not be dynamically adjusted to deal with the changes in per-flow reservations.
在这种方法中，来自Diffserv区域之外的节点的每流RSVP请求的允许将根据相应服务级别的适当聚合保留进行计数。聚合保留的大小可以动态调整，也可以不动态调整，以处理每流保留的变化。
The advantage of this approach is that it offers dynamic, topology aware admission control to the Diffserv network region without requiring the level of RSVP signaling processing that would be required to support per-flow RSVP.
这种方法的优点是，它向Diffserv网络区域提供动态、拓扑感知的接纳控制，而不需要支持每流RSVP所需的RSVP信令处理级别。
We note that resource management of a Diffserv region using aggregated RSVP is most likely to be feasible only within a single administrative domain, as each domain will probably choose its own mechanism to manage its resources.
我们注意到，使用聚合RSVP的Diffserv区域的资源管理很可能仅在单个管理域内可行，因为每个域可能会选择自己的机制来管理其资源。
In this approach, described in [3], routers in the Diffserv network region respond to the standard per-flow RSVP signaling originating from the Intserv-capable nodes outside the Diffserv region. This approach provides the benefits of the previous approach (dynamic, topology aware admission control) without requiring aggregated RSVP support. Resources are also used more efficiently as a result of the per-flow admission control. However, the demands on RSVP signaling resources within the Diffserv network region may be significantly higher than in an aggregated RSVP approach.
在[3]中所述的这种方法中，区分服务网络区域中的路由器响应来自区分服务区域外具有Intserv能力的节点的标准每流RSVP信令。这种方法提供了前一种方法（动态、拓扑感知的许可控制）的优点，而不需要聚合RSVP支持。由于单流准入控制，资源的使用效率也更高。然而，区分服务网络区域内对RSVP信令资源的需求可能显著高于聚合RSVP方法中的需求。
Note that per-flow RSVP and aggregated RSVP are not mutually exclusive in a single Diffserv region. It is possible to use per-flow RSVP at the edges of the Diffserv region and aggregation only in some "core" region within the Diffserv region.
请注意，每个流RSVP和聚合RSVP在单个Diffserv区域中并不相互排斥。可以在区分服务区域的边缘使用每流RSVP，并且仅在区分服务区域内的某个“核心”区域中使用聚合。
In 4.2.2 and 4.2.3 some subset of the routers within the Diffserv network is RSVP signaling aware (though traffic control is aggregated as opposed to per-flow). The relative number of routers in the core that participate in RSVP signaling is a provisioning decision that must be made by the network administrator.
在4.2.2和4.2.3中，Diffserv网络中的一些路由器子集是RSVP信令感知的（尽管流量控制是聚合的，而不是每个流）。核心中参与RSVP信令的路由器的相对数量是网络管理员必须做出的供应决策。
In one extreme case, only the border routers participate in RSVP signaling. In this case, either the Diffserv network region must be extremely over-provisioned and therefore, inefficiently used, or else it must be carefully and statically provisioned for limited traffic patterns. The border routers must enforce these patterns.
在一种极端情况下，只有边界路由器参与RSVP信令。在这种情况下，Diffserv网络区域必须过度配置，因此使用效率低下，或者必须小心地静态配置以用于有限的流量模式。边界路由器必须执行这些模式。
In the other extreme case, each router in the Diffserv network region might participate in RSVP signaling. In this case, resources can be used with optimal efficiency, but signaling processing requirements and associated overhead increase. As noted above, RSVP aggregation is one way to limit the signaling overhead at the cost of some loss of optimality in resource utilization.
在另一种极端情况下，Diffserv网络区域中的每个路由器都可能参与RSVP信令。在这种情况下，可以以最佳效率使用资源，但信令处理需求和相关开销会增加。如上所述，RSVP聚合是限制信令开销的一种方法，其代价是资源利用率的某些最佳性损失。
It is likely that some network administrators will compromise by enabling RSVP signaling on some subset of routers in the Diffserv network region. These routers will likely represent major traffic switching points with over-provisioned or statically provisioned regions of RSVP unaware routers between them.
一些网络管理员可能会通过在Diffserv网络区域中的某些路由器子集上启用RSVP信令进行妥协。这些路由器很可能代表主要的流量交换点，它们之间有RSVP非感知路由器的过度配置或静态配置区域。
Border routers might not use any form of RSVP signaling within the Diffserv network region but might instead use custom protocols to interact with an "oracle". The oracle is an agent that has sufficient knowledge of resource availability and network topology to make admission control decisions. The set of RSVP aware routers in the previous two examples can be considered collectively as a form of distributed oracle. In various definitions of the "bandwidth broker" [4], it is able to act as a centralized oracle.
边界路由器可能不会在Diffserv网络区域内使用任何形式的RSVP信令，但可能会使用自定义协议与“oracle”进行交互。oracle是一个代理，它对资源可用性和网络拓扑有足够的了解，可以做出准入控制决策。前两个示例中的RSVP感知路由器集可以被视为分布式oracle的一种形式。在“带宽代理”[4]的各种定义中，它可以充当集中式oracle。
We have described a framework in which RSVP/Intserv style QoS can be provided across end-to-end paths that include Diffserv network regions. This section discusses some of the implications of this framework for the Diffserv network region.
我们描述了一个框架，在该框架中，可以跨包括区分服务网络区域的端到端路径提供RSVP/Intserv风格的QoS。本节讨论此框架对区分服务网络区域的一些影响。
A Diffserv network region must meet the following requirements in order for it to support the framework described in this document.
Diffserv网络区域必须满足以下要求，才能支持本文档中描述的框架。
1. A Diffserv network region must be able to provide support for the standard Intserv QoS services between its border routers. It must be possible to invoke these services by use of standard PHBs within the Diffserv region and appropriate behavior at the edge of the Diffserv region.
1. Diffserv网络区域必须能够在其边界路由器之间提供对标准Intserv QoS服务的支持。必须能够通过使用Diffserv区域内的标准PHB和Diffserv区域边缘的适当行为来调用这些服务。
2. Diffserv network regions must provide admission control information to their "customer" (non-Diffserv) network regions. This information can be provided by a dynamic protocol or through static service level agreements enforced at the edges of the Diffserv region.
2. 区分服务网络区域必须向其“客户”（非区分服务）网络区域提供准入控制信息。这些信息可以通过动态协议提供，也可以通过在Diffserv区域边缘强制执行的静态服务级别协议提供。
3. Diffserv network regions must be able to pass RSVP messages, in such a manner that they can be recovered at the egress of the Diffserv network region. The Diffserv network region may, but is not required to, process these messages. Mechanisms for transparently carrying RSVP messages across a transit network are described in [3,6,15,16].
3. Diffserv网络区域必须能够传递RSVP消息，以使其能够在Diffserv网络区域的出口处恢复。Diffserv网络区域可以（但不需要）处理这些消息。[3,6,15,16]中描述了通过传输网络透明地传输RSVP消息的机制。
To meet these requirements, additional work is required in the areas of:
为满足这些要求，需要在以下领域开展额外工作：
1. Mapping Intserv style service specifications to services that can be provided by Diffserv network regions.
1. 将Intserv风格的服务规范映射到Diffserv网络区域可以提供的服务。
2. Definition of the functionality required in network elements to support RSVP signaling with aggregate traffic control (for network elements residing in the Diffserv network region). 3. Definition of mechanisms to efficiently and dynamically provision resources in a Diffserv network region (e.g., aggregated RSVP, tunneling, MPLS, etc.). This might include protocols by which an "oracle" conveys information about resource availability within a Diffserv region to border routers. One example of such a mechanism is the so-called "bandwidth broker" proposed in [19,20,21].
2. 定义网元中支持RSVP信令和聚合流量控制所需的功能（对于驻留在Diffserv网络区域中的网元）。3.定义在区分服务网络区域中高效、动态地提供资源的机制（例如，聚合RSVP、隧道、MPLS等）。这可能包括“oracle”将区分服务区域内的资源可用性信息传递给边界路由器的协议。这种机制的一个例子是[19,20,21]中提出的所谓“带宽代理”。
Network administrators must be able to share resources in the Diffserv network region between three types of traffic:
网络管理员必须能够在三种类型的流量之间共享Diffserv网络区域中的资源：
a. End-to-end Intserv traffic. This is typically traffic associated with quantitative QoS applications. It requires a specific quantity of resources with a high degree of assurance.
a. 端到端Intserv流量。这通常是与定量QoS应用程序相关联的流量。它需要具有高度保证的特定数量的资源。
b. Non-Intserv traffic. The Diffserv region may allocate resources to traffic that does not make use of Intserv techniques to quantify its requirements, e.g., through the use of static provisioning and SLSs enforced at the edges of the region. Such traffic might be associated with applications whose QoS requirements are not readily quantifiable but which require a "better than best-effort" level of service.
b. 非Intserv流量。区分服务区域可将资源分配给不使用Intserv技术来量化其需求的业务，例如，通过使用在区域边缘强制实施的静态供应和sls。此类流量可能与QoS要求不易量化但需要“比最佳努力更好”服务水平的应用程序相关。
c. All other (best-effort) traffic. These three classes of traffic must be isolated from each other by the appropriate configuration of policers and classifiers at ingress points to the Diffserv network region, and by appropriate provisioning within the Diffserv network region. To provide protection for Intserv traffic in Diffserv regions of the network, we suggest that the DSCPs assigned to such traffic not overlap with the DSCPs assigned to other traffic.
c. 所有其他（尽最大努力）流量。这三类流量必须通过在Diffserv网络区域的入口点处适当配置策略和分类器，以及通过在Diffserv网络区域内适当配置来相互隔离。为了保护网络区分服务区域中的Intserv流量，我们建议分配给此类流量的DSCP不要与分配给其他流量的DSCP重叠。
The use of integrated services over Diffserv networks is significantly more complex for multicast sessions than for unicast sessions. With respect to a multicast connection, each participating region has a single ingress router and zero, one or several egress routers. The difficulties of multicast are associated with Diffserv regions that contain several egress routers. (Support of multicast functionality outside the Diffserv region is relatively straightforward since every Intserv-capable router along the multicast tree stores state for each flow.)
在区分服务网络上使用综合服务对于多播会话比单播会话要复杂得多。对于多播连接，每个参与区域具有单个入口路由器和零个、一个或多个出口路由器。组播的困难与包含多个出口路由器的区分服务区域有关。（在Diffserv区域之外支持多播功能相对简单，因为多播树上的每个支持Intserv的路由器都存储每个流的状态。）
Consider the following reference network:
考虑下面的参考网络：
Non-Diffserv region 2
________
/ \
| | |---|
________ _____________ | |-|Rx1|
/ \ / |--\ |---| | |---|
/ \ / /|BR2\-----\ER2| /
|---| | |---| |---| |--|/ |---| \--|____/
|Tx |-| |ER1|---|BR1|--|RR| | ________
|---| | |-- | |---| |--|\ |---| /--| \
\ / \ \|BR3/-----|ER3| | |---|
\________/ \__________|--/ |---| |-|Rx2|
| | |---|
Non-Diffserv region 1 Diffserv region \ /
\______/
Non-Diffserv region 2
________
/ \
| | |---|
________ _____________ | |-|Rx1|
/ \ / |--\ |---| | |---|
/ \ / /|BR2\-----\ER2| /
|---| | |---| |---| |--|/ |---| \--|____/
|Tx |-| |ER1|---|BR1|--|RR| | ________
|---| | |-- | |---| |--|\ |---| /--| \
\ / \ \|BR3/-----|ER3| | |---|
\________/ \__________|--/ |---| |-|Rx2|
| | |---|
Non-Diffserv region 1 Diffserv region \ /
\______/
Non-Diffserv region 3
非区分服务区域3
Figure 2: Sample Multicast Network Configuration
图2：示例多播网络配置
The reference network is similar to that of Figure 1. However, in Figure 2, copies of the packets sent by Tx are delivered to several receivers outside of the Diffserv region, namely to Rx1 and Rx2. Moreover, packets are copied within the Diffserv region in a "branch point" router RR. In the reference network BR1 is the ingress router to the Diffserv region whereas BR2 and BR3 are the egress routers.
参考网络与图1相似。然而，在图2中，由Tx发送的数据包的副本被传送到Diffserv区域之外的几个接收器，即Rx1和Rx2。此外，在“分支点”路由器RR中的区分服务区域内复制数据包。在参考网络中，BR1是到区分服务区域的入口路由器，而BR2和BR3是出口路由器。
In the simplest case the receivers, Rx1 and Rx2 in the reference network, require identical reservations. The Diffserv framework [18] supports service level specifications (SLS) from an ingress router to one, some or all of the egress routers. This calls for a "one to many" SLS within the Diffserv region, from BR1 to BR2 and BR3. Given that the SLS is granted by the Diffserv region, the ingress router BR1, or perhaps an upstream node such as ER1, marks packets entering the Diffserv region with the appropriate DSCP. The packets are routed to the egresses of the Diffserv domain using the original multicast address.
在最简单的情况下，参考网络中的接收机Rx1和Rx2需要相同的预留。Diffserv框架[18]支持从入口路由器到一个、部分或全部出口路由器的服务级别规范（SLS）。这就需要在区分服务区域内从BR1到BR2和BR3的“一对多”SLS。假设SLS是由区分服务区域授予的，则入口路由器BR1，或者可能是诸如ER1的上游节点，用适当的DSCP标记进入区分服务区域的分组。使用原始多播地址将数据包路由到Diffserv域的出口。
The two major problems, explained in the following, are associated with heterogeneous multicast trees containing branch points within the Diffserv region, i.e., multicast trees where the level of resource requirement is not uniform among all receivers. An example of such a scenario in the network of Figure 2 is the case where both Rx1 and Rx2 need to receive multicast data from Tx1 but only one of the receivers has requested a level of service above best effort. We consider such scenarios in the following paragraphs.
下面解释的两个主要问题与包含区分服务区域内的分支点的异构多播树有关，即多播树，其中所有接收器的资源需求水平不一致。图2的网络中的这种场景的一个示例是这样的情况，其中Rx1和Rx2都需要从Tx1接收多播数据，但是只有一个接收机请求了高于最大努力的服务水平。我们在下面的段落中考虑这样的情景。
In the above scenario, the packets that arrive at BR1 are marked with an appropriate DSCP for the requested Intserv service and are sent to RR. Packets arriving at the branch point must be sent towards BR2 with the same DSCP otherwise the service to Rx1 is degraded. However, the packets going from RR towards BR3 need not maintain the high assurance level anymore. They may be demoted to best effort so that the QoS provided to other packets along this branch of the tree is not disrupted. Several problems can be observed in the given scenario:
在上述场景中，到达BR1的数据包被标记为请求的Intserv服务的适当DSCP，并被发送到RR。到达分支点的数据包必须使用相同的DSCP发送到BR2，否则Rx1的服务将降级。然而，从RR到BR3的数据包不再需要保持高保证级别。可以将它们降级为尽力而为，以便沿树的这一分支向其他数据包提供的QoS不会中断。在给定场景中可以观察到几个问题：
- In the Diffserv region, DSCP marking is done at edge routers (ingress), whereas a branch point router might be a core router, which does not mark packets.
- 在Diffserv区域，DSCP标记在边缘路由器（入口）上完成，而分支点路由器可能是核心路由器，它不标记数据包。
- Being a core Diffserv router, RR classifies based on aggregate traffic streams (BA), as opposed to per flow (MF) classification. Hence, it does not necessarily have the capability to distinguish those packets which belong to a specific multicast tree and require demotion from the other packets in the behavior aggregate, which carry the same DSCP.
- 作为核心区分服务路由器，RR基于聚合流量流（BA）进行分类，而不是按流量（MF）分类。因此，它不一定能够将属于特定多播树且需要降级的数据包与行为聚合中的其他数据包区分开来，这些数据包携带相同的DSCP。
- Since RR may be RSVP-unaware, it may not participate in the admission control process, and would thus not store any per-flow state about the reservations for the multicast tree. Hence, even if RR were able to perform MF classification and DSCP remarking, it would not know enough about downstream reservations to remark the DSCP intelligently.
- 由于RR可能不知道RSVP，因此它可能不参与接纳控制过程，因此不会存储关于多播树的保留的任何每流状态。因此，即使RR能够执行MF分类和DSCP注释，它对下游保留的了解也不足以智能地注释DSCP。
These problems could be addressed by a variety of mechanisms. We list some below, while noting that none is ideal in all cases and that further mechanisms may be developed in the future:
这些问题可以通过各种机制加以解决。我们在下面列出了一些，同时指出，没有一个在所有情况下都是理想的，未来可能会制定进一步的机制：
1. If some Intserv-capable routers are placed within the Diffserv region, it might be possible to administer the network topology and routing parameters so as to ensure that branch points occur only within such routers. These routers would support MF classification and remarking and hold per-flow state for the heterogeneous reservations for which they are the branch point. Note that in this case, branch point routers would have essentially the same functionality as ingress routers of an RSVP-aware Diffserv domain.
1. 如果一些支持Intserv的路由器位于Diffserv区域内，则可以管理网络拓扑和路由参数，以确保分支点仅出现在此类路由器内。这些路由器将支持MF分类以及它们作为分支点的异构保留的每流状态的注释和保持。请注意，在这种情况下，分支点路由器将具有与RSVP感知区分服务域的入口路由器基本相同的功能。
2. Packets sent on the "non-reserved" branch (from RR towards BR3) are marked with the "wrong" DSCP; that is, they are not demoted to best effort but retain their DSCP. This in turn requires over reservation of resources along that link or runs the risk of degrading service to packets that legitimately bear the same DSCP
2. 在“非保留”分支（从RR到BR3）上发送的数据包被标记为“错误的”DSCP；也就是说，他们不会降级为尽力而为，而是保留他们的DSCP。这反过来又需要沿该链路过度保留资源，否则就有可能使服务降级到合法承载相同DSCP的数据包
along this path. However, it allows the Diffserv routers to remain free of per-flow state.
沿着这条路走。但是，它允许Diffserv路由器保持每流状态。
3. A combination of mechanism 1 and 2 may be an effective compromise. In this case, there are some Intserv-capable routers in the core of the network, but the network cannot be administered so that ALL branch points fall at such routers.
3. 机制1和2的组合可能是一种有效的折衷方案。在这种情况下，网络核心中有一些支持Intserv的路由器，但无法管理网络，因此所有分支点都落在这些路由器上。
4. Administrators of Diffserv regions may decide not to enable heterogeneous sub-trees in their domains. In the case of different downstream reservations, a ResvErr message would be sent according to the RSVP rules. This is similar to the approach taken for Intserv over IEEE 802 Networks [2,5].
4. Diffserv区域的管理员可能决定不在其域中启用异构子树。在不同下游保留的情况下，将根据RSVP规则发送ResvErr消息。这类似于IEEE 802网络上的Intserv所采用的方法[2,5]。
5. In [3], a scheme was introduced whereby branch point routers in the interior of the aggregation region (i.e., the Diffserv region) keep reduced state information regarding the reservations by using measurement based admission control. Under this scheme, packets are tagged by the more knowledgeable Intserv edges routers with scheduling information that is used in place of the detailed Intserv state. If the Diffserv region and branch point routers are designed following that framework, demotion of packets becomes possible.
5. 在[3]中，引入了一种方案，其中聚集区域（即Diffserv区域）内部的分支点路由器通过使用基于测量的接纳控制来保持关于保留的减少的状态信息。在该方案下，信息包由知识更丰富的Intserv边缘路由器使用调度信息进行标记，该调度信息用于代替详细的Intserv状态。如果区分服务区域和分支点路由器按照该框架设计，则数据包降级成为可能。
Multicast flows with heterogeneous reservations present some challenges in the area of SLSs. For example, a common example of an SLS is one where a certain amount of traffic is allowed to enter a Diffserv region marked with a certain DSCP, and such traffic may be destined to any egress router of that region. We call such an SLS a homogeneous, or uniform, SLS. However, in a multicast environment, a single packet that is admitted to the Diffserv region may consume resources along many paths in the region as it is replicated and forwarded towards many egress routers; alternatively, it may flow along a single path. This situation is further complicated by the possibility described above and depicted in Figure 2, in which a multicast packet might be treated as best effort along some branches while receiving some higher QOS treatment along others. We simply note here that the specification of meaningful SLSs which meet the needs of heterogeneous flows and which can be met be providers is likely to be challenging.
具有异构保留的组播流在SLS领域提出了一些挑战。例如，SLS的常见示例是其中允许一定量的业务进入用特定DSCP标记的Diffserv区域，并且这种业务可以目的地到该区域的任何出口路由器。我们称这样的SLS为均质或均匀SLS。然而，在多播环境中，当允许进入区分服务区域的单个分组被复制并转发到多个出口路由器时，该分组可沿该区域中的多条路径消耗资源；或者，它可以沿着单个路径流动。上述和图2所示的可能性使这种情况更加复杂，其中多播分组可能被视为沿着一些分支的最大努力，同时沿着其他分支接收一些更高的QOS处理。在此，我们只需注意，满足异构流需求且可由提供者满足的有意义SLS的规范可能具有挑战性。
Dynamic SLSs may help to address these issues. For example, by using RSVP to signal the resources that are required along different branches of a multicast tree, it may be possible to more closely approach the goal of allocating appropriate resources only where they are needed rather than overprovisioning or underprovisioning along certain branches of a tree. This is essentially the approach
动态SLS可能有助于解决这些问题。例如，通过使用RSVP向多播树的不同分支发送所需资源的信号，可以更接近仅在需要时分配适当资源的目标，而不是沿着树的某些分支过度配置或不足配置资源。这基本上是一种方法
described in [15].
如[15]所述。
We are proposing that RSVP signaling be used to obtain resources in both Diffserv and non-Diffserv regions of a network. Therefore, all RSVP security considerations apply [9]. In addition, network administrators are expected to protect network resources by configuring secure policers at interfaces with untrusted customers.
我们建议使用RSVP信令在网络的区分服务和非区分服务区域获取资源。因此，所有RSVP安全注意事项均适用[9]。此外，网络管理员需要通过在与不受信任的客户的接口处配置安全策略来保护网络资源。
Though it does not mandate host marking of the DSCP, our proposal does allow it. Allowing hosts to set the DSCP directly may alarm network administrators. The obvious concern is that hosts may attempt to "steal" resources. In fact, hosts may attempt to exceed negotiated capacity in Diffserv network regions at a particular service level regardless of whether they invoke this service level directly (by setting the DSCP) or indirectly (by submitting traffic that classifies in an intermediate marking router to a particular DSCP).
虽然它不强制要求DSCP的主机标记，但我们的提案允许这样做。允许主机直接设置DSCP可能会警告网络管理员。显而易见，主机可能会试图“窃取”资源。事实上，主机可能会试图在特定服务级别上超过Diffserv网络区域中的协商容量，而不管它们是直接调用该服务级别（通过设置DSCP）还是间接调用（通过向特定DSCP提交在中间标记路由器中分类的流量）。
In either case, it will generally be necessary for each Diffserv network region to protect its resources by policing to assure that customers do not use more resources than they are entitled to, at each service level (DSCP). The exception to this rule is when the host is known to be trusted, e.g., a server that is under the control of the network administrators. If an untrusted sending host does not perform DSCP marking, the boundary router (or trusted intermediate routers) must provide MF classification, mark and police. If an untrusted sending host does perform marking, the boundary router needs only to provide BA classification and to police to ensure that the customer is not exceeding the aggregate capacity negotiated for the service level.
在这两种情况下，通常每个Diffserv网络区域都需要通过监控来保护其资源，以确保客户在每个服务级别（DSCP）上使用的资源不会超过其应有的数量。此规则的例外情况是，已知主机是受信任的，例如，受网络管理员控制的服务器。如果不受信任的发送主机不执行DSCP标记，边界路由器（或受信任的中间路由器）必须提供MF分类、标记和报警。如果不受信任的发送主机执行标记，边界路由器只需提供BA分类并报警，以确保客户不超过为服务级别协商的总容量。
In summary, there are no additional security concerns raised by marking the DSCP at the edge of the network since Diffserv providers will have to police at their boundaries anyway. Furthermore, this approach reduces the granularity at which border routers must police, thereby pushing finer grain shaping and policing responsibility to the edges of the network, where it scales better and provides other benefits described in Section 3.3.1. The larger Diffserv network regions are thus focused on the task of protecting their networks, while the Intserv-capable nodes are focused on the task of shaping and policing their own traffic to be in compliance with their negotiated Intserv parameters.
总之，在网络边缘标记DSCP不会引起额外的安全问题，因为Diffserv提供商无论如何都必须在其边界进行监控。此外，这种方法降低了边界路由器必须监控的粒度，从而将更细粒度的塑造和监控责任推到网络边缘，在那里它可以更好地扩展，并提供第3.3.1节所述的其他好处。因此，较大的区分服务网络区域专注于保护其网络的任务，而具有Intserv能力的节点专注于塑造和管理其自身的流量以符合其协商的Intserv参数的任务。
Authors thank the following individuals for their comments that led to improvements to the previous version(s) of this document: David Oran, Andy Veitch, Curtis Villamizer, Walter Weiss, Francois le Faucheur and Russell White.
作者感谢以下个人的意见，这些意见改进了本文件的前一版本：David Oran、Andy Veitch、Curtis Villamizer、Walter Weiss、Francois le Faucheur和Russell White。
Many of the ideas in this document have been previously discussed in the original Intserv architecture document [10].
本文档中的许多想法之前已在原始Intserv体系结构文档[10]中讨论过。
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) Version 1 Functional Specification", RFC 2205, September 1997.
[1] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）版本1功能规范”，RFC 22052997年9月。
[2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission Control Over IEEE 802 Style Networks", RFC 2814, May 2000.
[2] Yavatkar，R.，Hoffman，D.，Bernet，Y.，Baker，F.和M.Speer，“SBM（子网带宽管理器）：IEEE 802风格网络上基于RSVP的准入控制协议”，RFC 2814，2000年5月。
[3] Berson, S. and R. Vincent, "Aggregation of Internet Integrated Services State", Work in Progress.
[3] Berson，S.和R.Vincent，“互联网综合服务州聚合”，正在进行中。
[4] Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999.
[4] Nichols，K.，Jacobson，V.和L.Zhang，“互联网的两位差异化服务架构”，RFC 2638，1999年7月。
[5] Seaman, M., Smith, A., Crawley, E. and J. Wroclawski, "Integrated Service Mappings on IEEE 802 Networks", RFC 2815, May 2000.
[5] Seaman，M.，Smith，A.，Crawley，E.和J.Wroclawski，“IEEE 802网络上的综合服务映射”，RFC 2815，2000年5月。
[6] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based QoS Requests", Work in Progress.
[6] Guerin，R.，Blake，S.和Herzog，S.，“聚合基于RSVP的QoS请求”，正在进行中。
[7] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[7] Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[8] Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[9] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[9] Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[10] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[10] Braden，R.，Clark，D.和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC16331994年6月。
[11] Garrett, M. and M. Borden, "Interoperation of Controlled-Load Service and Guaranteed Service with ATM", RFC 2381, August 1998.
[11] Garrett，M.和M.Borden，“受控负载服务和保证服务与ATM的互操作”，RFC 2381，1998年8月。
[12] Weiss, Walter, Private communication, November 1998.
[12] 韦斯，沃尔特，《私人通讯》，1998年11月。
[13] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[13] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[14] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[14] Bernet，Y.，“RSVP数据类对象的格式”，RFC 2996，2000年11月。
[15] Baker, F., Iturralde, C., le Faucheur, F., and Davie, B. "RSVP Reservation Aggregation", Work in Progress.
[15] Baker，F.，Iturralde，C.，le Faucheur，F.，和Davie，B.“RSVP保留汇总”，工作正在进行中。
[16] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[16] Terzis，A.，Krawczyk，J.，Wroclawski，J.和L.Zhang，“IP隧道上的RSVP操作”，RFC 2746，2000年1月。
[17] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, D. and A. Sastry, "COPS Usage for RSVP", RFC 2749, January 2000.
[17] Boyle，J.，Cohen，R.，Durham，D.，Herzog，S.，Rajan，D.和A.Sastry，“警察对RSVP的使用”，RFC 2749，2000年1月。
[18] Bernet, Y., "A Framework for Differentiated Services", Work in Progress.
[18] Bernet，Y.，“差异化服务框架”，正在进行中。
[19] Jacobson Van, "Differentiated Services Architecture", talk in the Int-Serv WG at the Munich IETF, August 1997.
[19] Jacobson Van，“差异化服务体系结构”，1997年8月在慕尼黑IETF国际服务工作组上的演讲。
[20] Jacobson, V., Nichols K. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, June 1999.
[20] Jacobson，V.，Nichols K.和L.Zhang，“互联网的两位差异化服务架构”，RFC 2638，1999年6月。
[21] First Internet2 bandwidth broker operability event
http://www.merit.edu/internet/working.groups/i2-qbone-bb/
inter-op/index.htm
[21] First Internet2 bandwidth broker operability event
http://www.merit.edu/internet/working.groups/i2-qbone-bb/
inter-op/index.htm
Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052
Yoram Bernet微软一路微软雷德蒙，华盛顿州98052
Phone: +1 425-936-9568
EMail: yoramb@microsoft.com
Phone: +1 425-936-9568
EMail: yoramb@microsoft.com
Raj Yavatkar Intel Corporation JF3-206 2111 NE 25th. Avenue Hillsboro, OR 97124
拉吉·雅瓦卡尔英特尔公司JF3-206 2111东北25号。希尔斯博罗大道，或97124
Phone: +1 503-264-9077
EMail: raj.yavatkar@intel.com
Phone: +1 503-264-9077
EMail: raj.yavatkar@intel.com
Peter Ford Microsoft One Microsoft Way Redmond, WA 98052
Peter Ford Microsoft One Microsoft Way Redmond，华盛顿州，98052
Phone: +1 425-703-2032
EMail: peterf@microsoft.com
Phone: +1 425-703-2032
EMail: peterf@microsoft.com
Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, CA 93111
弗雷德·贝克思科系统公司，加利福尼亚州圣巴巴拉市拉多大道519号，邮编：93111
Phone: +1 408-526-4257
EMail: fred@cisco.com
Phone: +1 408-526-4257
EMail: fred@cisco.com
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095
加利福尼亚州洛杉矶加利福尼亚大学洛杉矶分校张丽霞4531G博尔特大厅，邮编90095
Phone: +1 310-825-2695
EMail: lixia@cs.ucla.edu
Phone: +1 310-825-2695
EMail: lixia@cs.ucla.edu
Michael Speer Sun Microsystems 901 San Antonio Road, UMPK15-215 Palo Alto, CA 94303
加利福尼亚州帕洛阿尔托市圣安东尼奥路901号迈克尔·斯佩尔太阳微系统公司，邮编94303
Phone: +1 650-786-6368
EMail: speer@Eng.Sun.COM
Phone: +1 650-786-6368
EMail: speer@Eng.Sun.COM
Bob Braden USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695
Bob Braden USC/信息科学研究所4676金钟路Marina del Rey，加利福尼亚州90292-6695
Phone: +1 310-822-1511
EMail: braden@isi.edu
Phone: +1 310-822-1511
EMail: braden@isi.edu
Bruce Davie Cisco Systems 250 Apollo Drive Chelmsford, MA 01824
布鲁斯·戴维斯思科系统公司马萨诸塞州切姆斯福德阿波罗大道250号01824
Phone: +1 978-244-8000
EMail: bsd@cisco.com
Phone: +1 978-244-8000
EMail: bsd@cisco.com
Eyal Felstaine SANRAD Inc. 24 Raul Wallenberg st Tel Aviv, Israel
以色列特拉维夫劳尔瓦伦堡大街24号Eyal Felstaine SANRAD公司
Phone: +972-50-747672
Email: eyal@sanrad.com
Phone: +972-50-747672
Email: eyal@sanrad.com
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
约翰·沃克罗夫斯基麻省理工学院计算机科学实验室，马萨诸塞州剑桥545技术广场，邮编：02139
Phone: +1 617-253-7885
EMail: jtw@lcs.mit.edu
Phone: +1 617-253-7885
EMail: jtw@lcs.mit.edu
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编辑功能的资金目前由互联网协会提供。