Network Working Group R. Bless
Request for Comments: 3754 Univ. of Karlsruhe
Category: Informational K. Wehrle
Univ. of Tuebingen
April 2004
Network Working Group R. Bless
Request for Comments: 3754 Univ. of Karlsruhe
Category: Informational K. Wehrle
Univ. of Tuebingen
April 2004
IP Multicast in Differentiated Services (DS) Networks
区分服务（DS）网络中的IP组播
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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document discusses the problems of IP Multicast use in Differentiated Services (DS) networks, expanding on the discussion in RFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results.
本文档讨论了区分服务（DS）网络中IP多播使用的问题，扩展了RFC 2475（“区分服务体系结构”）中的讨论。本文还提出了这些问题的可能解决方案，描述了潜在的实现模型，并给出了仿真结果。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Management of Differentiated Services. . . . . . . . . . 2
2. Problems of IP Multicast in DS Domains . . . . . . . . . . . . 3
2.1. Neglected Reservation Subtree Problem (NRS Problem). . . 4
2.2. Heterogeneous Multicast Groups . . . . . . . . . . . . . 12
2.3. Dynamics of Any-Source Multicast . . . . . . . . . . . . 13
3. Solutions for Enabling IP-Multicast in Differentiated
Services Networks. . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Solution for the NRS Problem . . . . . . . . . . . . . . 13
3.2. Solution for Supporting Heterogeneous Multicast Groups . 15
3.3. Solution for Any-Source Multicast. . . . . . . . . . . . 16
4. Scalability Considerations . . . . . . . . . . . . . . . . . . 16
5. Deployment Considerations. . . . . . . . . . . . . . . . . . . 17
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
7. Implementation Model Example . . . . . . . . . . . . . . . . . 18
8. Proof of the Neglected Reservation Subtree Problem . . . . . . 19
8.1. Implementation of the Proposed Solution. . . . . . . . . 20
8.2. Test Environment and Execution . . . . . . . . . . . . . 21
9. Simulative Study of the NRS Problem and Limited Effort PHB . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Management of Differentiated Services. . . . . . . . . . 2
2. Problems of IP Multicast in DS Domains . . . . . . . . . . . . 3
2.1. Neglected Reservation Subtree Problem (NRS Problem). . . 4
2.2. Heterogeneous Multicast Groups . . . . . . . . . . . . . 12
2.3. Dynamics of Any-Source Multicast . . . . . . . . . . . . 13
3. Solutions for Enabling IP-Multicast in Differentiated
Services Networks. . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Solution for the NRS Problem . . . . . . . . . . . . . . 13
3.2. Solution for Supporting Heterogeneous Multicast Groups . 15
3.3. Solution for Any-Source Multicast. . . . . . . . . . . . 16
4. Scalability Considerations . . . . . . . . . . . . . . . . . . 16
5. Deployment Considerations. . . . . . . . . . . . . . . . . . . 17
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
7. Implementation Model Example . . . . . . . . . . . . . . . . . 18
8. Proof of the Neglected Reservation Subtree Problem . . . . . . 19
8.1. Implementation of the Proposed Solution. . . . . . . . . 20
8.2. Test Environment and Execution . . . . . . . . . . . . . 21
9. Simulative Study of the NRS Problem and Limited Effort PHB . . 23
9.1. Simulation Scenario. . . . . . . . . . . . . . . . . . . 24
9.2. Simulation Results for Different Router Types. . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 31
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 34
9.1. Simulation Scenario. . . . . . . . . . . . . . . . . . . 24
9.2. Simulation Results for Different Router Types. . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 31
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 34
This document discusses the problems of IP Multicast use in Differentiated Services (DS) networks, expanding on the discussion in RFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results.
本文档讨论了区分服务（DS）网络中IP多播使用的问题，扩展了RFC 2475（“区分服务体系结构”）中的讨论。本文还提出了这些问题的可能解决方案，描述了潜在的实现模型，并给出了仿真结果。
The "Differentiated Services" (DiffServ or DS) approach [1, 2, 3] defines certain building blocks and mechanisms to offer qualitatively better services than the traditional best-effort delivery service in an IP network. In the DiffServ Architecture [2], scalability is achieved by avoiding complexity and maintenance of per-flow state information in core nodes, and by pushing unavoidable complexity to the network edges. Therefore, individual flows belonging to the same service are aggregated, thereby eliminating the need for complex classification or managing state information per flow in interior nodes.
“差异化服务”（DiffServ或DS）方法[1、2、3]定义了某些构建块和机制，以提供比IP网络中的传统尽力而为交付服务质量更好的服务。在DiffServ体系结构[2]中，可伸缩性是通过避免核心节点中每流状态信息的复杂性和维护，以及将不可避免的复杂性推到网络边缘来实现的。因此，属于同一服务的各个流被聚合，从而消除了对内部节点中每个流的复杂分类或管理状态信息的需要。
On the other hand, the reduced complexity in DS nodes makes it more complex to use those "better" services together with IP Multicast (i.e., point-to-multipoint or multipoint-to-multipoint communication). Problems emerging from this fact are described in section 2. Although the basic DS forwarding mechanisms also work with IP Multicast, some facts have to be considered which are related to the provisioning of multicast resources. It is important to integrate IP Multicast functionality into the architecture from the beginning, and to provide simple solutions for those problems that will not defeat the already gained advantages.
另一方面，DS节点复杂性的降低使得将这些“更好”的服务与IP多播（即点对多点或多点对多点通信）一起使用变得更加复杂。第2节描述了由此产生的问题。虽然基本DS转发机制也适用于IP多播，但必须考虑一些与多播资源供应相关的事实。重要的是从一开始就将IP多播功能集成到体系结构中，并为这些问题提供简单的解决方案，这些解决方案不会破坏已经获得的优势。
At least for Per-Domain Behaviors and services based on the EF PHB, admission control and resource reservation are required [14, 15]. Installation and updating of traffic profiles in boundary nodes is necessary. Most network administrators cannot accomplish this task manually, even for long term service level agreements (SLAs). Furthermore, offering services on demand requires some kind of signaling and automatic admission control procedures.
至少对于基于EF PHB的每域行为和服务，需要准入控制和资源保留[14,15]。有必要在边界节点中安装和更新流量配置文件。大多数网络管理员无法手动完成此任务，即使是长期服务级别协议（SLA）。此外，按需提供服务需要某种信令和自动准入控制程序。
However, no standardized resource management architecture for DiffServ domains exists. The remainder of this document assumes that at least some logical resource management entity is available to perform resource-based admission control and allotment functions. This entity may also be realized in a distributed fashion, e.g., within the routers themselves. Detailed aspects of the resource management realization within a DiffServ domain, as well as the interactions between resource management and routers or end-systems (e.g., signaling for resources), are out of scope of this document.
但是，不存在用于区分服务域的标准化资源管理体系结构。本文档的其余部分假设至少有一些逻辑资源管理实体可用于执行基于资源的许可控制和分配功能。该实体也可以以分布式方式实现，例如，在路由器本身内。DiffServ域内资源管理实现的详细方面，以及资源管理与路由器或终端系统之间的交互（例如，资源信令），不在本文档的范围内。
Protocols for signaling a reservation request to a Differentiated Services Domain are required. For accomplishing end-system signaling to DS domains, RSVP [4] may be used with new DS specific reservation objects [5]. RSVP provides support for multicast scenarios and is already supported by many systems. However, application of RSVP in a DiffServ multicast context may lead to problems that are also described in the next section. The NSIS Working Group is currently defining new signaling protocols that may show a different behavior, but the WG has its current focus more on unicast flows than on multicast flows.
需要用于向区分服务域发送保留请求的信令协议。为了完成到DS域的终端系统信令，RSVP[4]可与新的DS特定保留对象[5]一起使用。RSVP提供对多播场景的支持，并且已经被许多系统支持。然而，在DiffServ多播上下文中应用RSVP可能会导致下一节中描述的问题。NSIS工作组目前正在定义新的信令协议，这些协议可能会显示出不同的行为，但工作组目前的重点更多是单播流，而不是多播流。
Although potential problems and the complexity of providing multicast with Differentiated Services are considered in a separate section of [2], both aspects have to be discussed in greater detail. The simplicity of the DiffServ Architecture and its DS node types is necessary to reach high scalability, but it also causes fundamental problems in conjunction with the use of IP Multicast in DS domains. The following subsections describe these problems for which a generic solution is proposed in section 3. This solution is as scalable as IP Multicast and needs no resource separation by using different codepoint values for unicast and multicast traffic.
尽管在[2]的单独一节中考虑了使用差异化服务提供多播的潜在问题和复杂性，但必须更详细地讨论这两个方面。DiffServ体系结构及其DS节点类型的简单性是实现高可伸缩性的必要条件，但它也会导致在DS域中使用IP多播时出现根本性问题。以下小节描述了第3节中提出的通用解决方案的这些问题。该解决方案与IP多播一样具有可扩展性，并且通过对单播和多播流量使用不同的代码点值，不需要资源分离。
Because Differentiated Services are unidirectional by definition, the point-to-multipoint communication is also considered as unidirectional. In traditional IP Multicast, any node can send packets spontaneously and asynchronously to a multicast group specified by their multicast group address, i.e., traditional IP Multicast offers a multipoint-to-multipoint service, also referred to as Any-Source Multicast. Implications of this feature are discussed in section 2.3.
因为区分服务的定义是单向的，所以点对多点通信也被认为是单向的。在传统IP多播中，任何节点都可以自发地、异步地向其多播组地址指定的多播组发送数据包，即传统IP多播提供多点对多点服务，也称为任意源多播。第2.3节讨论了此功能的含义。
For subsequent considerations we assume, unless stated otherwise, at least a unidirectional point-to-multipoint communication scenario in which the sender generates packets which experience a "better" Per-Hop-Behavior than the traditional default PHB, resulting in a service of better quality than the default best-effort service. In order to
出于后续考虑，除非另有说明，否则我们假设至少存在单向点对多点通信场景，其中发送方生成的数据包体验到比传统默认PHB“更好”的每跳行为，从而产生比默认尽力而为服务更好的服务质量。为了
accomplish this, a traffic profile corresponding to the traffic conditioning specification has to be installed in the sender's first DS-capable boundary node. Furthermore, it must be assured that the corresponding resources are available on the path from the sender to all the receivers, possibly requiring adaptation of traffic profiles at involved domain boundaries. Moreover, on demand resource reservations may be receiver-initiated.
为此，必须在发送方的第一个支持DS的边界节点中安装与流量调节规范相对应的流量配置文件。此外，必须确保相应的资源在从发送方到所有接收方的路径上可用，这可能需要在涉及的域边界处对流量剖面进行自适应。此外，可由接收机发起按需资源预留。
Typically, resources for Differentiated Services must be reserved before they are used. But in a multicast scenario, group membership is often highly dynamic, thereby limiting the use of a sender-initiated resource reservation in advance. Unfortunately, dynamic addition of new members of the multicast group using Differentiated Services can adversely affect other existing traffic if resources were not explicitly reserved before use. A practical proof of this problem is given in section 8.
通常，差异化服务的资源在使用之前必须保留。但在多播场景中，组成员身份通常是高度动态的，因此限制了发送方预先发起的资源保留的使用。不幸的是，如果在使用之前没有明确保留资源，则使用区分服务动态添加多播组的新成员可能会对其他现有流量产生不利影响。第8节给出了该问题的实际证明。
IP Multicast packet replication usually takes place when the packet is handled by the forwarding core (cf. Fig. 1), i.e., when it is forwarded and replicated according to the multicast forwarding table. Thus, a DiffServ capable node would also copy the content of the DS field [1] into the IP packet header of every replicate. Consequently, replicated packets get exactly the same DS codepoint (DSCP) as the original packet, and therefore experience the same forwarding treatment as the incoming packets of this multicast group. This is also illustrated in Fig. 1, where each egress interface comprises functions for (BA-) classification, traffic conditioning (TC), and queueing.
IP多播分组复制通常在分组由转发核心处理时发生（参见图1），即，当分组根据多播转发表被转发和复制时。因此，具有区分服务功能的节点还将DS字段[1]的内容复制到每个复制的IP分组报头中。因此，复制的数据包与原始数据包获得完全相同的DS码点（DSCP），因此与该多播组的传入数据包经历相同的转发处理。这也在图1中示出，其中每个出口接口包括用于（BA-）分类、流量调节（TC）和排队的功能。
Interface A IP Forwarding Interface B
+-----------+ +--------------+ +-----------+
MC-flow | | | replication | | egress |
---->| ingress |---->|------+-------|----->|(class.,TC,|---->
| | | | | | queueing) |
+-----------+ | | | +-----------+
| | |
| | | Interface C
| | | +-----------+
| | | | egress |
| +-------|----->|(class.,TC,|---->
| | | queueing) |
+--------------+ +-----------+
Interface A IP Forwarding Interface B
+-----------+ +--------------+ +-----------+
MC-flow | | | replication | | egress |
---->| ingress |---->|------+-------|----->|(class.,TC,|---->
| | | | | | queueing) |
+-----------+ | | | +-----------+
| | |
| | | Interface C
| | | +-----------+
| | | | egress |
| +-------|----->|(class.,TC,|---->
| | | queueing) |
+--------------+ +-----------+
Figure 1: Multicast packet replication in a DS node
图1:DS节点中的多播数据包复制
Normally, the replicating node cannot test whether a corresponding resource reservation exists for a particular flow of replicated packets on an output link (i.e., its corresponding interface). This is because flow-specific information (e.g., traffic profiles) is usually not available in every boundary and interior node.
通常，复制节点无法测试输出链路（即其对应接口）上的特定复制数据包流是否存在相应的资源保留。这是因为特定于流量的信息（例如，交通概况）通常在每个边界和内部节点中都不可用。
When a new receiver joins an IP Multicast group, a multicast routing protocol (e.g., DVMRP [6], PIM-DM [7] or PIM-SM [8]) grafts a new branch to an existing multicast tree in order to connect the new receiver to the tree. As a result of tree expansion, missing per-flow classification, and policing mechanisms, the new receiver will implicitly use the service of better quality, because of the "better" copied DSCP.
当新的接收器加入IP多播组时，多播路由协议（例如，DVMRP[6]、PIM-DM[7]或PIM-SM[8]）将新的分支嫁接到现有多播树上，以便将新的接收器连接到该树上。由于树扩展、缺少每流分类和监控机制，新的接收方将隐式使用质量更好的服务，因为复制的DSCP“更好”。
If the additional amount of resources which are consumed by the new part of the multicast tree are not taken into account by the domain resource management (cf. section 1.1), the currently provided quality of service of other receivers (with correct reservations) will be affected adversely or even violated. This negative effect on existing traffic contracts by a neglected resource reservation -- in the following designated as the Neglected Reservation Subtree Problem (NRS Problem) -- must be avoided under all circumstances. Strong admission control policies at the domain boundary will not help to prevent this problem either, because the new flow that inadmissibly consumes resources has its origin inside the domain.
如果域资源管理（参见第1.1节）未考虑多播树的新部分所消耗的额外资源量，则其他接收器（具有正确保留）当前提供的服务质量将受到不利影响，甚至受到违反。在任何情况下，都必须避免被忽略的资源保留对现有交通合同的负面影响——以下称为被忽略的保留子树问题（NRS问题）。域边界上的强许可控制策略也无助于防止此问题，因为不可接受地消耗资源的新流源于域内。
One can distinguish two major cases of the NRS Problem. They show a different behavior depending on the location of the branching point. In order to compare their different effects, a simplistic example of a share of bandwidth is illustrated in Fig. 2 and is used in the following explanations. Neither the specific PHB types nor their assigned bandwidth share are important; however, their relative priority with respect to each other is of importance.
我们可以区分NRS问题的两个主要案例。它们根据分支点的位置显示不同的行为。为了比较它们的不同效果，图2中示出了带宽共享的简单示例，并在以下解释中使用。特定PHB类型及其分配的带宽共享都不重要；然而，它们彼此之间的相对优先权很重要。
40% 40% 20%
+--------------------+---------------------+------------+
|Expedited Forwarding| Assured Forwarding | Best-Effort|
+--------------------+---------------------+------------+
---------------------------------------------------------->
output link bandwidth
40% 40% 20%
+--------------------+---------------------+------------+
|Expedited Forwarding| Assured Forwarding | Best-Effort|
+--------------------+---------------------+------------+
---------------------------------------------------------->
output link bandwidth
Figure 2: An example bandwidth share of different behavior aggregates
图2：不同行为聚合的带宽共享示例
The bandwidth of the considered output link is shared by three types of services (i.e., by three behavior aggregates): Expedited Forwarding, Assured Forwarding, and the traditional Best-Effort service. In this example, we assume that routers perform strict priority queueing, where EF has the highest, AF the middle, and Best-Effort the lowest assigned scheduling priority. Though not mandatory for an EF implementation, a strict non-preemptive priority scheduler is one implementation option as described in section 5.1.1 of RFC 3247 [15]. Were Weighted Fair Queueing (WFQ) to be used, the described effects would essentially also occur, but with minor differences. In the following scenarios, it is illustrated that PHBs of equal or lower priority (in comparison to the multicast flow's PHB) are affected by the NRS problem.
所考虑的输出链路的带宽由三种类型的服务（即三种行为聚合）共享：快速转发、保证转发和传统的尽力而为服务。在这个例子中，我们假设路由器执行严格的优先级排队，其中EF具有最高的调度优先级，AF处于中间，Best Effort具有最低的调度优先级。尽管对于EF实现不是强制性的，但严格的非抢占式优先级调度程序是RFC 3247[15]第5.1.1节所述的一种实现选项。如果使用加权公平排队（WFQ），所描述的效果基本上也会发生，但差别较小。在以下场景中，说明了优先级相同或更低的PHB（与多播流的PHB相比）受到NRS问题的影响。
The Neglected Reservation Subtree problem appears in two different cases:
被忽略的保留子树问题出现在两种不同的情况下：
o Case 1: If the branching point of the new subtree (at first only a branch) and the previous multicast tree is a (egress) boundary node, as shown in Fig. 3, the additional multicast flow now increases the total amount of used resources for the corresponding behavior aggregate on the affected output link. The total amount will be greater than the originally reserved amount. Consequently, the policing component in the egress boundary node drops packets until the traffic aggregate is in accordance with the traffic contract. But while dropping packets, the router can not identify the responsible flow (because of missing flow classification functionality), and thus randomly discards packets, whether they belong to a correctly behaving flow or not. As a result, there will no longer be any service guarantee for the flows with properly reserved resources.
o 情况1：如图3所示，如果新子树（最初仅为一个分支）和前一个多播树的分支点是（出口）边界节点，则附加多播流现在增加了受影响输出链路上相应行为聚合的已用资源总量。总金额将大于原始保留金额。因此，出口边界节点中的策略组件丢弃分组，直到业务聚合符合业务契约。但是在丢弃数据包时，路由器无法识别负责的流（因为缺少流分类功能），因此随机丢弃数据包，不管它们是否属于行为正确的流。因此，对于具有适当保留资源的流，将不再有任何服务保证。
Sender
+---+
| S | DS domains
+---+ / \
.||............... / \ ................
. || .<- ->. .
. || . . .
. +---+ +--+ +--+ *) +--+ +--+ +--+ +------+
. |FHN|===|IN|=====|BN|###########|BN|####|IN|######|BN|####|Recv.B|
. +---+ +--+ +--+\\ +--+ +--+ +--+ +------+
. \\ \ . \\ . \ .
. +--+ +--+ . \\ . \ .
. |IN|-----|IN| . \\ . +--+ .
. +--+ +--+ . \\ ..........|BN|..
. || \ . +------+ +--+
. || \ . |Recv.A|
.+--+ +--+. +------+
|BN|........|BN|
+--+ +--+
||
Sender
+---+
| S | DS domains
+---+ / \
.||............... / \ ................
. || .<- ->. .
. || . . .
. +---+ +--+ +--+ *) +--+ +--+ +--+ +------+
. |FHN|===|IN|=====|BN|###########|BN|####|IN|######|BN|####|Recv.B|
. +---+ +--+ +--+\\ +--+ +--+ +--+ +------+
. \\ \ . \\ . \ .
. +--+ +--+ . \\ . \ .
. |IN|-----|IN| . \\ . +--+ .
. +--+ +--+ . \\ ..........|BN|..
. || \ . +------+ +--+
. || \ . |Recv.A|
.+--+ +--+. +------+
|BN|........|BN|
+--+ +--+
||
S: Sender Recv.x: Receiver x FHN: First-Hop Node BN: Boundary Node IN: Interior Node ===: Multicast branch with reserved bandwidth ###: Multicast branch without reservation *) Bandwidth of EF aggregated on the output link is higher than actual reservation, EF aggregate will be limited in bandwidth without considering the responsible flow.
S:Sender Recv.x:Receiver x FHN:First Hop Node BN:Boundary Node IN:Interior Node===：具有保留带宽的多播分支######：没有保留的多播分支*）输出链路上聚合的EF带宽高于实际保留，EF聚合将在带宽上受到限制，而不考虑责任流。
Figure 3: The NRS Problem (case 1) occurs when Receiver B joins
图3:NRS问题（案例1）发生在接收器B加入时
In figure 3, it is assumed that receiver A is already attached to the egress boundary node (BN) of the first domain. Furthermore, resources are properly reserved along the path to receiver A and used by correspondingly marked packets. When receiver B joins the same group as receiver A, packets are replicated and forwarded along the new branch towards the second domain with the same PHB as for receiver A. If this PHB is EF, the new branch possibly exhausts allotted resources for the EF PHB, adversely affecting other EF users that receive their packets over the link that is marked with the *). The BN usually ensures that outgoing traffic aggregates to the next domain are conforming to the agreed traffic conditioning specification. The egress BN will, therefore, drop packets of the PHB type that are used for the multicast flow.
在图3中，假设接收机A已经连接到第一域的出口边界节点（BN）。此外，沿着到接收器A的路径适当地保留资源，并由相应地标记的分组使用。当接收器B加入与接收器A相同的组时，数据包被复制并沿着新分支转发到第二个域，该域具有与接收器A相同的PHB。如果该PHB是EF，则新分支可能会耗尽EF PHB的分配资源，对通过标有*）的链路接收其数据包的其他EF用户造成不利影响。BN通常确保到下一个域的传出流量聚合符合商定的流量调节规范。因此，出口BN将丢弃用于多播流的PHB类型的分组。
Other PHBs of lower or higher priority are not affected adversely in this case. The following example in Fig. 4. illustrates this for two PHBs.
在这种情况下，其他优先级较低或较高的PHB不会受到不利影响。下面的示例如图4所示。对两个PHB进行了说明。
+------------------+---------------------+--------------+------+
| Expedited Forw. | Expedited Forw. | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| EF with and without reservation share | 40 % | 20% |
| 40% of reserved EF aggregate. | | |
| -> EF packets with reservation and | | |
| without reservation will be | | |
| discarded! | | |
+------------------+---------------------+--------------+------+
+------------------+---------------------+--------------+------+
| Expedited Forw. | Expedited Forw. | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| EF with and without reservation share | 40 % | 20% |
| 40% of reserved EF aggregate. | | |
| -> EF packets with reservation and | | |
| without reservation will be | | |
| discarded! | | |
+------------------+---------------------+--------------+------+
(a) Excess flow has EF codepoint
(a) 过量流量具有EF代码点
+------------------+---------------------+--------------+------+
| Expedited Forw. | Assured Forwarding | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| | AF with & without reservation share| 20 % |
| | 40% of reserved EF aggregate. | |
| 40% | -> EF packets with reservation and | |
| | without reservation will be | |
| | discarded! | |
+------------------+---------------------+--------------+------+
+------------------+---------------------+--------------+------+
| Expedited Forw. | Assured Forwarding | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| | AF with & without reservation share| 20 % |
| | 40% of reserved EF aggregate. | |
| 40% | -> EF packets with reservation and | |
| | without reservation will be | |
| | discarded! | |
+------------------+---------------------+--------------+------+
(b) Excess flow has AF codepoint
(b) 过量流量具有AF代码点
Figure 4: Resulting share of bandwidth in a egress boundary node with a neglected reservation of (a) an Expedited Forwarding flow or (b) an Assured Forwarding flow.
图4：出口边界节点中的带宽共享，忽略了（a）加速转发流或（b）保证转发流的保留。
Fig. 4 shows the resulting share of bandwidth in cases when (a) Expedited Forwarding and (b) Assured Forwarding is used by the additional multicast branch causing the NRS Problem. Assuming that the additional traffic would use another 30% of the link bandwidth, Fig. 4 (a) illustrates that the resulting aggregate of Expedited Forwarding (70% of the outgoing link bandwidth) is throttled down to its originally reserved 40%. In this case, the amount of dropped EF bandwidth is equal to the amount of excess bandwidth. Consequently, the original Expedited Forwarding
图4示出了导致NRS问题的附加多播分支使用（a）加速转发和（b）保证转发的情况下产生的带宽份额。假设额外的业务将使用另外30%的链路带宽，图4（a）示出所得到的加速转发聚合（70%的传出链路带宽）被限制到其最初保留的40%。在这种情况下，丢弃的EF带宽量等于多余带宽量。因此，最初的加速转发
aggregate (which had 40% of the link bandwidth reserved) is also affected by packet losses. The other services, e.g., Assured Forwarding or Best-Effort, are not disadvantaged.
聚合（保留了40%的链路带宽）也会受到数据包丢失的影响。其他服务，如保证转发或尽力而为，并不处于不利地位。
Fig. 4 (b) shows the same situation for Assured Forwarding. The only difference is that now Assured Forwarding is solely affected by discards, as the other services will still get their guarantees. In either case, packet losses are restricted to the misbehaving service class by the traffic meter and policing mechanisms in boundary nodes. Moreover, the latter problem (case 1) occurs only in egress boundary nodes because they are responsible for ensuring that the traffic leaving the Differentiated Services domain is not more than the following ingress boundary node will accept. Therefore, those violations of SLAs will already be detected and processed in egress boundary nodes.
图4（b）示出了保证转发的相同情况。唯一的区别是，现在有保证的转发只受丢弃的影响，因为其他服务仍将获得它们的保证。在这两种情况下，数据包丢失都由流量表和边界节点中的策略机制限制在行为异常的服务类。此外，后一个问题（情况1）仅发生在出口边界节点中，因为它们负责确保离开区分服务域的流量不超过以下入口边界节点将接受的流量。因此，这些违反SLA的行为将在出口边界节点中被检测和处理。
o Case 2: The Neglected Reservation Subtree problem can also occur if the branching point between the previous multicast tree and the new subtree is located in an interior node (as shown in Fig. 5). In Fig. 5, it is assumed that receivers A and B have already joined the multicast group and have reserved resources accordingly. The interior node in the second domain starts replication of multicast packets as soon as receiver C joins. Because the router is not equipped with metering or policing functions, it will not recognize any amount of excess traffic and will forward the new multicast flow. If the latter belongs to a higher priority service, such as Expedited Forwarding, bandwidth of the aggregate is higher than the aggregate's reservation at the new branch and will use bandwidth from lower priority services.
o 情况2：如果前一个多播树和新子树之间的分支点位于内部节点中（如图5所示），则也会出现被忽略的保留子树问题。在图5中，假设接收机A和B已经加入多播组并且相应地具有保留资源。一旦接收器C加入，第二域中的内部节点就开始多播分组的复制。由于路由器未配备计量或监控功能，因此它将无法识别任何数量的多余流量，并将转发新的多播流。如果后者属于更高优先级的服务，如快速转发，则聚合的带宽高于聚合在新分支的保留，并将使用来自低优先级服务的带宽。
Sender
+---+
| S | DS domains
+---+ / \
.||............... / \ ................
. || .<- ->. .
. || . . .
. +---+ +--+ +--+ +--+ +--+ +--+ +------+
. |FHN|===|IN|=====|BN|===========|BN|====|IN|======|BN|===|Recv.B|
. +---+ +--+ +--+\\ +--+ +--+ +--+ +------+
. \\ \ . \\ . # .
. +--+ +--+ . \\ . # *) .
. |IN|-----|IN| . \\ . +--+ .
. +--+ +--+ . \\ ..........|BN|..
. || \ . +------+ +--+
. || \ . |Recv.A| #
.+--+ +--+. +------+ #
|BN|........|BN| +------+
+--+ +--+ |Recv.C|
|| +------+
Sender
+---+
| S | DS domains
+---+ / \
.||............... / \ ................
. || .<- ->. .
. || . . .
. +---+ +--+ +--+ +--+ +--+ +--+ +------+
. |FHN|===|IN|=====|BN|===========|BN|====|IN|======|BN|===|Recv.B|
. +---+ +--+ +--+\\ +--+ +--+ +--+ +------+
. \\ \ . \\ . # .
. +--+ +--+ . \\ . # *) .
. |IN|-----|IN| . \\ . +--+ .
. +--+ +--+ . \\ ..........|BN|..
. || \ . +------+ +--+
. || \ . |Recv.A| #
.+--+ +--+. +------+ #
|BN|........|BN| +------+
+--+ +--+ |Recv.C|
|| +------+
FHN: First-Hop Node, BN: Boundary Node, Recv.x: Receiver x
S: Sender, IN: Interior Node
===: Multicast branch with reserved bandwidth
###: Multicast branch without reservation
*) Bandwidth of EF aggregated on the output link is higher than
actual reservation, EF aggregate will be limited in bandwidth
without considering the responsible flow
FHN: First-Hop Node, BN: Boundary Node, Recv.x: Receiver x
S: Sender, IN: Interior Node
===: Multicast branch with reserved bandwidth
###: Multicast branch without reservation
*) Bandwidth of EF aggregated on the output link is higher than
actual reservation, EF aggregate will be limited in bandwidth
without considering the responsible flow
Figure 5: Neglected Reservation Subtree problem case 2 after join of receiver C
图5：连接接收方C后被忽略的保留子树问题案例2
The additional amount of EF without a corresponding reservation is forwarded together with the aggregate which has a reservation. This results in no packet losses for Expedited Forwarding as long as the resulting aggregate is not higher than the output link bandwidth. Because of its higher priority, Expedited Forwarding gets as much bandwidth as needed and as is available. The effects on other PHBs are illustrated by the following example in Fig. 6.
没有相应保留的额外EF量与具有保留的聚合一起转发。只要得到的聚合不高于输出链路带宽，这就不会导致快速转发的数据包丢失。由于其更高的优先级，快速转发可以获得所需的和可用的带宽。图6中的以下示例说明了对其他phb的影响。
+------------------+---------------------+--------------+------+
| Expedited Forw. | Expedited Forw. | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| 40% | 30% | 30% | 0% |
+------------------+---------------------+--------------+------+
EF with reservation and the excess flow use together 70%
of the link bandwidth because EF, with or without reservation,
has the highest priority.
+------------------+---------------------+--------------+------+
| Expedited Forw. | Expedited Forw. | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| 40% | 30% | 30% | 0% |
+------------------+---------------------+--------------+------+
EF with reservation and the excess flow use together 70%
of the link bandwidth because EF, with or without reservation,
has the highest priority.
(a) Excess flow has EF codepoint
(a) 过量流量具有EF代码点
+------------------+---------------------+--------------+------+
| Expedited Forw. | Assured Forw. | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| 40% | 60% | 0% |
| | (10% loss) | |
+------------------+---------------------+--------------+------+
AF with reservation and the excess flow use together 60%
of the link bandwidth because EF has the highest priority
(-> 40%). 10% of AF packets will be lost.
+------------------+---------------------+--------------+------+
| Expedited Forw. | Assured Forw. | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| 40% | 60% | 0% |
| | (10% loss) | |
+------------------+---------------------+--------------+------+
AF with reservation and the excess flow use together 60%
of the link bandwidth because EF has the highest priority
(-> 40%). 10% of AF packets will be lost.
(b) Excess flow has AF codepoint
(b) 过量流量具有AF代码点
Figure 6: Resulting share of bandwidth in an interior node with a neglected reservation of (a) an Expedited Forwarding flow or (b) an Assured Forwarding flow
图6：忽略保留（a）加速转发流或（b）保证转发流的内部节点中的带宽共享
The result of case 2 is that there is no restriction for Expedited Forwarding, but as Fig. 6 (a) shows, other services will be extremely disadvantaged by this use of non-reserved resources. Their bandwidth is used by the new additional flow. In this case, the additional 30% Expedited Forwarding traffic preempts resources from the Assured Forwarding traffic, which in turn preempts
情况2的结果是没有对快速转发的限制，但如图6（a）所示，其他服务将因使用非保留资源而处于极端不利的地位。它们的带宽被新的附加流使用。在这种情况下，额外的30%加速转发流量抢占了来自保证转发流量的资源，而保证转发流量又抢占了资源
resources from the best-effort traffic, resulting in 10% packet losses for the Assured Forwarding aggregate, and a complete loss of best-effort traffic. The example in Fig. 6 (b) shows that this can also happen with lower priority services like Assured Forwarding. When a reservation for a service flow with lower priority is neglected, other services (with even lower priority) can be reduced in their quality (in this case the best-effort service). As shown in the example, the service's aggregate causing the NRS problem can itself be affected by packet losses (10% of the Assured Forwarding aggregate is discarded). Besides the described problems of case 2, case 1 will occur in the DS boundary node of the next DS domain that performs traffic metering and policing for the service aggregate.
来自尽力而为流量的资源，导致保证转发聚合的10%数据包丢失，以及尽力而为流量的完全丢失。图6（b）中的示例显示，对于较低优先级的服务，如有保证的转发，也可以发生这种情况。当忽略对优先级较低的服务流的保留时，其他服务（优先级更低）的质量可能会降低（在本例中为尽力而为服务）。如示例所示，导致NRS问题的服务聚合本身可能会受到数据包丢失的影响（10%的保证转发聚合被丢弃）。除了案例2所描述的问题外，案例1将出现在下一个DS域的DS边界节点中，该DS域为服务聚合执行流量计量和策略。
Directly applying RSVP to Differentiated Services would also result in temporary occurrence of the NRS Problem. A receiver has to join the IP multicast group to receive the sender's PATH messages, before being able to send a resource reservation request (RESV message). Thus, the join message on the link for receiving PATH messages can cause the NRS Problem, if this situation is not handled in a special way (e.g., by marking all PATH messages with codepoint 0 and dropping or re-marking all other data packets of the multicast flow).
将RSVP直接应用于差异化服务也会导致NRS问题的暂时发生。接收方必须加入IP多播组才能接收发送方的路径消息，然后才能发送资源保留请求（RESV消息）。因此，如果不以特殊方式处理这种情况（例如，通过使用代码点0标记所有路径消息并丢弃或重新标记多播流的所有其他数据分组），则用于接收路径消息的链路上的连接消息可导致NRS问题。
Heterogeneous multicast groups contain one or more receivers, which would like to get another service or quality of service as the sender provides or other receiver subsets currently use. A very important characteristic which should be supported by Differentiated Services is that participants requesting a best-effort quality only should also be able to participate in a group communication which otherwise utilizes a better service class. The next better support for heterogeneity provides concurrent use of more than two different service classes within a group. Things tend to get even more complex when not only different service classes are required, but also different values for quality parameters within a certain service class.
异构多播组包含一个或多个接收者，这些接收者希望获得发送者提供的其他服务或服务质量，或者当前使用的其他接收者子集。差异化服务应支持的一个非常重要的特征是，仅要求尽力而为质量的参与者也应能够参与组通信，否则，组通信将使用更好的服务级别。对异构性的下一个更好的支持是在一个组中同时使用两个以上的不同服务类。当不仅需要不同的服务类，而且还需要某个服务类中不同的质量参数值时，事情往往变得更加复杂。
A further problem is to support heterogeneous groups with different service classes in a consistent way. It is possible that some services will not be comparable to each other so that one service cannot be replaced by the other, and both services have to be provided over the same link within this group.
另一个问题是以一致的方式支持具有不同服务类的异构组。有些服务可能无法相互比较，因此一种服务不能被另一种服务替代，并且两种服务都必须通过该组内的同一链路提供。
Because an arbitrary new receiver that wants to get the different service can be grafted to any point of the current multicast delivery tree, even interior nodes may have to replicate packets using the different service. At a first glance, this seems to be a
由于想要获得不同服务的任意新接收器可以嫁接到当前多播交付树的任何点，因此即使内部节点也可能必须使用不同的服务复制数据包。乍一看，这似乎是一个错误
contradiction with respect to simplicity of the interior nodes, because they do not even have a profile available and should now convert the service of quality of individual receivers. Consequently, in order to accomplish this, interior nodes have to change the codepoint value during packet replication.
与内部节点的简单性相矛盾，因为它们甚至没有可用的配置文件，现在应该转换单个接收器的服务质量。因此，为了实现这一点，内部节点必须在数据包复制期间更改代码点值。
Basically, within an IP multicast group, any participant (actually, it can be any host not even receiving packets of this multicast group) can act as a sender. This is an important feature which should also be available in case a specific service other than best-effort is used within the group. Differentiated Services possess, conceptually, a unidirectional character. Therefore, for every multicast tree implied by a sender, resources must be reserved separately if simultaneous sending should be possible with a better service. This is even true if shared multicast delivery trees are used (e.g., with PIM-SM or Core Based Trees). If not enough resources are reserved for a service within a multicast tree allowing simultaneous sending of more than one participant, the NRS problem will occur again. The same argument applies to half-duplex reservations which would share the reserved resources by several senders, because it cannot be ensured by the network that exactly one sender sends packets to the group. Accordingly, the corresponding RSVP reservation styles "Wildcard Filter" and "Shared-Explicit Filter" [4] cannot be supported within Differentiated Services. The Integrated Services approach is able to ensure the half-duplex nature of the traffic, because every router can check each packet for its conformance with the installed reservation state.
基本上，在IP多播组中，任何参与者（实际上，它可以是甚至没有接收该多播组的数据包的任何主机）都可以充当发送者。这是一项重要功能，在集团内使用除best effort以外的特定服务时，也应提供该功能。区分服务在概念上具有单向性。因此，对于发送方暗示的每个多播树，如果可以使用更好的服务同时发送，则必须单独保留资源。如果使用共享多播交付树（例如，与PIM-SM或基于核心的树一起使用），这甚至是正确的。如果在允许同时发送多个参与者的多播树中没有为服务保留足够的资源，那么NRS问题将再次发生。同样的论点也适用于半双工保留，它将由多个发送者共享保留的资源，因为网络无法确保只有一个发送者向组发送数据包。因此，在区分服务中不支持相应的RSVP保留样式“通配符筛选器”和“共享显式筛选器”[4]。集成服务方法能够确保通信量的半双工性质，因为每个路由器都可以检查每个数据包是否符合已安装的保留状态。
3. Solutions for Enabling IP-Multicast in Differentiated Services Networks
3. 在区分服务网络中实现IP多播的解决方案
The problems described in the previous section are mainly caused by the simplicity of the Differentiated Services architecture. Solutions that do not introduce additional complexity need to be introduced so as to not diminish the scalability of the DiffServ approach. This document suggests a straightforward solution for most of the problems.
上一节中描述的问题主要是由区分服务体系结构的简单性引起的。需要引入不引入额外复杂性的解决方案，以便不降低区分服务方法的可伸缩性。本文档为大多数问题提供了一个简单的解决方案。
The proposed solution consists conceptually of the following three steps that are described in more detail later.
建议的解决方案在概念上包括以下三个步骤，稍后将详细介绍这三个步骤。
1. A new receiver joins a multicast group that is using a DiffServ service. Multicast routing protocols accomplish the connection of the new branch to the (possibly already existing) multicast delivery tree as usual.
1. 新接收器加入使用DiffServ服务的多播组。多播路由协议通常完成新分支到（可能已经存在）多播交付树的连接。
2. The unauthorized use of resources is avoided by re-marking at branching nodes all additional packets departing down the new branch. At first, the new receiver will get all packets of the multicast group without quality of service. The management entity of the correspondent DiffServ domain may get informed about the extension of the multicast tree.
2. 通过在分支节点上重新标记沿新分支离开的所有附加数据包，可以避免未经授权使用资源。首先，新的接收器将获得多播组的所有数据包，而没有服务质量。对应的区分服务域的管理实体可以获得关于多播树的扩展的通知。
3. If a pre-issued reservation is available for the new branch or somebody (receiver, sender or a third party) issues one, the management entity instructs the branching router to set the corresponding codepoint for the demanded service.
3. 如果预发布的预留可用于新分支或有人（接收方、发送方或第三方）发布预留，则管理实体指示分支路由器为所需服务设置相应的代码点。
Usage of resources which were not previously reserved must be prevented. In the following example, we consider a case where the join of a new receiver to a DS multicast group requires grafting of a new branch to an already existing multicast delivering tree. The connecting node that joins both trees converts the codepoint (and therefore the Per-Hop Behavior) to a codepoint of a PHB which is similar to the default PHB in order to provide a best-effort-like service for the new branch. More specifically, this particular PHB can provide a service that is even worse than the best-effort service of the default PHB. See RFC 3662 [16] for a corresponding Lower Effort Per-Domain Behavior.
必须防止使用以前未保留的资源。在下面的例子中，我们考虑一个新的接收者到DS组播组的连接需要将一个新分支嫁接到已经存在的多播传送树的情况。连接两棵树的连接节点将代码点（以及每跳行为）转换为与默认PHB类似的PHB的代码点，以便为新分支提供尽力而为的服务。更具体地说，这个特定的PHB可以提供比默认PHB的尽力而为服务更差的服务。请参阅RFC 3662[16]，了解每个域的相应较低工作量行为。
The conversion to this specific PHB could be necessary in order to avoid unfairness being introduced within the best-effort service aggregate, and, which results from the higher amount of resource usage of the incoming traffic belonging to the multicast group. If the rate at which re-marked packets are injected into the outgoing aggregate is not reduced, those re-marked packets will probably cause discarding of other flow's packets in the outgoing aggregate if resources are scarce.
为了避免在尽力而为服务聚合中引入不公平，可能需要转换到该特定PHB，这是由于属于多播组的传入流量的资源使用量较高而导致的。如果重新标记的数据包注入传出聚合的速率没有降低，那么如果资源稀缺，这些重新标记的数据包可能会导致丢弃传出聚合中其他流的数据包。
Therefore, the re-marked packets from this multicast group should be discarded more aggressively than other packets in this outgoing aggregate. This could be accomplished by using an appropriately configured PHB (and a related DSCP) for those packets. In order to distinguish this kind of PHB from the default PHB, it is referred to as the Limited Effort (LE) PHB (which can be realized by an appropriately configured AF PHB [9] or Class Selector Compliant PHB [1]) throughout this document. Merely dropping packets more aggressively at the re-marking node is not sufficient, because there may be enough resources in the outgoing behavior aggregate (BA) to
因此，与此传出聚合中的其他数据包相比，应该更积极地丢弃此多播组中重新标记的数据包。这可以通过为这些数据包使用适当配置的PHB（和相关的DSCP）来实现。为了将此类PHB与默认PHB区分开来，在本文档中称之为有限工作（LE）PHB（可通过适当配置的AF PHB[9]或符合类选择器的PHB[1]实现）。仅仅在重新标记节点更积极地丢弃数据包是不够的，因为传出行为聚合（BA）中可能有足够的资源来
transmit every re-marked packet without having to discard any other packets within the same BA. However, resources in the next node may be short for this particular BA. Those "excess" packets, therefore, must be identifiable at this node.
传输每个重新标记的数据包，而不必丢弃同一BA内的任何其他数据包。但是，下一个节点中的资源可能会短于此特定BA。因此，这些“多余”数据包必须在此节点上可识别。
Re-marking packets is only required at branching nodes, whereas all other nodes of the multicast tree (such with outdegree 1) replicate packets as usual. Because a branching node may also be an interior node of a domain, re-marking of packets requires conceptually per-flow classification. Though this seems to be in contradiction to the DiffServ philosophy of a core that avoids per-flow states, IP multicast flows are different from unicast flows: traditional IP multicast forwarding and multicast routing are required to install states per multicast group for every outgoing link anyway. Therefore, re-marking in interior nodes is scalable to the same extent as IP multicast (cf. section 4).
只需要在分支节点处重新标记数据包，而多播树的所有其他节点（如outdegree 1）都像往常一样复制数据包。因为分支节点也可以是域的内部节点，所以包的重新标记在概念上需要每个流分类。虽然这似乎与避免每个流状态的核心的DiffServ理念相矛盾，但IP多播流不同于单播流：传统的IP多播转发和多播路由要求为每个传出链路的每个多播组安装状态。因此，内部节点中的重新标记可扩展到与IP多播相同的程度（参见第4节）。
Re-marking with standard DiffServ mechanisms [10] for every new branch requires activation of a default traffic profile. The latter accomplishes re-marking by using a combination of an MF-classifier and a marker at an outgoing link that constitutes a new branch. The classifier will direct all replicated packets to a marker that sets the new codepoint. An alternative implementation is described in section 7.
使用标准DiffServ机制[10]为每个新分支重新标记需要激活默认流量配置文件。后者通过使用MF分类器和组成新分支的传出链路上的标记的组合来完成重新标记。分类器将所有复制的数据包定向到设置新代码点的标记。第7节描述了一种替代实现。
The better service will only be provided if a reservation request was processed and approved by the resource management function. That means an admission control test must be performed before resources are actually used by the new branch. In case the admission test is successful, the re-marking node will be instructed by the resource management to stop re-marking and to use the original codepoint again (conceptually by removing the profile).
只有资源管理职能部门处理并批准预订请求，才能提供更好的服务。这意味着在新分支实际使用资源之前必须执行准入控制测试。如果接纳测试成功，资源管理将指示重新标记节点停止重新标记并再次使用原始代码点（概念上是通过删除配置文件）。
In summary, only those receivers will obtain a better service within a DiffServ multicast group, which previously reserved the corresponding resources in the new branch with assistance of the resource management. Otherwise, they get a quality which might be even lower than best-effort.
总之，只有那些接收者才能在DiffServ多播组中获得更好的服务，DiffServ多播组先前在资源管理的帮助下在新分支中保留了相应的资源。否则，他们得到的质量可能甚至低于尽力而为。
In this document, considerations are limited to provisioning different service classes, but not different quality parameters within a certain service class.
在本文档中，注意事项仅限于提供不同的服务类，而不是特定服务类中的不同质量参数。
The proposed concept from section 3.1 provides a limited solution of the heterogeneity problem. Receivers are allowed to obtain a Limited Effort service without a reservation, so that at least two different
第3.1节提出的概念为异质性问题提供了有限的解决方案。允许接收者无保留地获得有限努力服务，以便至少有两种不同的服务
service classes within a multicast group are possible. Therefore, it is possible for any receiver to participate in the multicast session without getting any quality of service. This is useful if a receiver just wants to see whether the content of the multicast group is interesting enough, before requesting a better service which must be paid for (like snooping into a group without prior reservation).
多播组中的服务类是可能的。因此，任何接收器都有可能参与多播会话而不获得任何服务质量。如果接收者在请求必须付费的更好的服务（比如在没有事先预约的情况下窥探一个组）之前，只是想看看多播组的内容是否足够有趣，那么这是很有用的。
Alternatively, a receiver might not be able to receive this better quality of service (e.g., because it is mobile and uses a wireless link of limited capacity), but it may be satisfied with the reduced quality, instead of getting no content at all.
或者，接收机可能无法接收这种更好的服务质量（例如，因为它是移动的，并且使用容量有限的无线链路），但是它可能对降低的质量感到满意，而不是完全不获取内容。
Additionally, applying the RSVP concept of listening for PATH messages before sending any RESV message is feasible again. Without using the proposed solution, this would have caused the NRS Problem.
此外，在发送任何RESV消息之前应用侦听路径消息的RSVP概念也是可行的。如果不使用建议的解决方案，这将导致NRS问题。
Theoretically, the proposed approach in section 7 also supports more than two different services within one multicast group, because the additional field in the multicast routing table can store any DSCP value. However, this would work only if PHBs can be ordered, so that the "best" PHB among different required PHBs downstream is chosen to be forwarded on a specific link. This is mainly a management issue and is out of the scope of this document.
理论上，第7节中提出的方法还支持一个多播组中的两个以上不同服务，因为多播路由表中的附加字段可以存储任何DSCP值。然而，这只有在可以订购PHB的情况下才起作用，以便在不同的下游所需PHB中选择“最佳”PHB在特定链路上转发。这主要是一个管理问题，超出了本文件的范围。
More advanced concepts may also support conditional re-marking in dependence on the group address and DSCP value. This is useful if the group uses different PHBs (e.g., for flows to different transport protocol ports) and the re-marking should thus additionally depend on the DSCP value of an incoming packet.
更高级的概念还可能支持依赖于组地址和DSCP值的条件重新标记。如果组使用不同的PHB（例如，用于流向不同传输协议端口的流），则这是有用的，因此重新标记还应取决于传入数据包的DSCP值。
Every participant would have to initiate an explicit reservation to ensure the possibility of sending to the group with a better service quality, regardless of whether other senders within the group already use the same service class simultaneously. This would require a separate reservation for each sender-rooted multicast tree.
每个参与者都必须发起明确的预约，以确保能够以更好的服务质量发送给该组，而不管该组中的其他发送者是否已经同时使用相同的服务类。这将需要为每个发送方根组播树单独预留。
However, in the specific case of best-effort service (the default PHB), it is nevertheless possible for participants to send packets to the group anytime without requiring any additional mechanisms. The reason for this is that the first DS-capable boundary node will mark those packets with the DSCP of the default PHB because of a missing traffic profile for this particular sender. The first DS capable boundary nodes should therefore always classify multicast packets based on both the sender's address and the multicast group address.
然而，在尽力而为服务（默认PHB）的特定情况下，参与者仍然可以随时向组发送数据包，而不需要任何额外的机制。这是因为第一个支持DS的边界节点将使用默认PHB的DSCP标记这些数据包，因为缺少此特定发送方的流量配置文件。因此，第一个支持DS的边界节点应始终基于发送方地址和多播组地址对多播分组进行分类。
The proposed solution does not add complexity to the DS architecture or to a DS node, nor does it change the scalability properties of DiffServ. With current IP multicast routing protocols, a multicast router has to manage and hold state information per traversing multicast flow. The suggested solution scales to the same extent as IP multicast itself, because the proposed re-marking may occur per branch of a multicast flow. This re-marking is logically associated with an addition to the multicast routing state that is required anyway. In this respect, re-marking of packets for multicast flows in interior nodes is not considered as a scalability problem or to be in contradiction to the DiffServ approach itself. It is important to distinguish the multicast case from existing justifiable scalability concerns relating to re-marking packets of unicast flows within interior routers. Moreover, the decision of when to change a re-marking policy is not performed by the router, but by some management entity at a time scale which is different from the time scale at the packet forwarding level.
建议的解决方案不会增加DS架构或DS节点的复杂性，也不会改变DiffServ的可伸缩性属性。在当前的IP多播路由协议中，多播路由器必须管理和保存每个遍历多播流的状态信息。建议的解决方案可扩展到与IP多播本身相同的程度，因为建议的重新标记可能发生在多播流的每个分支上。此重新标记在逻辑上与所需的多播路由状态的添加相关联。在这方面，内部节点中多播流的分组重新标记不被视为可伸缩性问题，也不被视为与区分服务方法本身相矛盾。重要的是要将多播情况与现有合理的可伸缩性问题区分开来，这些问题涉及在内部路由器内重新标记单播流的数据包。此外，何时改变重新标记策略的决定不是由路由器执行的，而是由一些管理实体在与分组转发级别的时间尺度不同的时间尺度上执行的。
The solution proposed in section 3.1 can be deployed on most router platforms available today. Architectures that perform routing and forwarding functions in software could be updated by a new software release.
第3.1节中提出的解决方案可以部署在目前可用的大多数路由器平台上。在软件中执行路由和转发功能的架构可以通过新的软件版本进行更新。
However, there may be some specialized hardware platforms that are currently not able to deploy the proposed solution from section 7. This may be the case when a multicast packet is directly duplicated on the backplane of the router, so that all outgoing interfaces read the packet in parallel. Consequently, the codepoint cannot be changed for a subset of these outgoing interfaces and the NRS problem can not be solved directly in the branching point.
但是，可能有一些专用硬件平台目前无法部署第7节中提出的解决方案。当一个多播数据包被直接复制到路由器的底板上，以便所有输出接口并行读取数据包时，可能会出现这种情况。因此，不能为这些输出接口的子集更改代码点，并且不能在分支点中直接解决NRS问题。
In this case, there exist several alternative solutions:
在这种情况下，存在几种替代解决方案：
1. As mentioned in section 3.1, if traffic conditioning mechanisms can be applied on the outgoing packets at the individual output interfaces, a combination of classifier and marker may be used for each branch.
1. 如第3.1节所述，如果流量调节机制可应用于各个输出接口处的传出数据包，则分类器和标记的组合可用于每个分支。
2. The change of the codepoint for subtrees without properly allocated resources could take place in the following downstream router. There, for every incoming packet of the considered multicast group, the codepoint would be changed to the value that the previous router should have set. If a LAN (e.g., a high-speed switching LAN) is attached to the considered outgoing interface, then on every router connected to the LAN, packets of the considered group should be changed
2. 在没有适当分配资源的情况下，子树的代码点变化可能发生在以下下游路由器中。在那里，对于所考虑的多播组的每个传入数据包，代码点将被更改为前一个路由器应该设置的值。如果LAN（例如，高速交换LAN）连接到所考虑的输出接口，那么在连接到LAN的每个路由器上，所考虑组的数据包都应该更改
on the incoming interface by standard DiffServ mechanisms.
通过标准DiffServ机制在传入接口上。
Future releases of router architectures may support the change of the codepoint directly in the replication process as proposed in section 7.
路由器体系结构的未来版本可能支持在第7节中建议的复制过程中直接更改代码点。
Basically, the security considerations in [1] apply. The proposed solution does not imply new security aspects. If a join of arbitrary end-systems to a multicast group is not desired (thereby receiving a lower than best-effort quality) the application usually has to exclude these participants. This can be accomplished by using authentication, authorization, or ciphering techniques at the application level -- like in traditional IP multicast scenarios.
基本上，[1]中的安全注意事项适用。提议的解决方案并不意味着新的安全方面。如果不希望将任意终端系统连接到多播组（因此接收的质量低于最佳努力），则应用程序通常必须排除这些参与者。这可以通过在应用程序级别使用身份验证、授权或加密技术来实现——就像在传统的IP多播场景中一样。
Moreover, it is important to consider the security of corresponding management mechanisms, because they are used to activate re-marking of multicast flows. On the one hand, functions for instructing the router to mark or re-mark packets of multicast flows are attractive targets to perform theft of service attacks. On the other hand, their security depends on the router management mechanisms which are used to realize this functionality. Router management should generally be protected against unauthorized use, therefore preventing those attacks as well.
此外，重要的是要考虑相应的管理机制的安全性，因为它们被用来激活组播流的重新标记。一方面，用于指示路由器标记或重新标记多播流的分组的功能是执行服务盗窃攻击的有吸引力的目标。另一方面，它们的安全性取决于用于实现此功能的路由器管理机制。路由器管理通常应防止未经授权的使用，从而防止这些攻击。
One possibility of implementing the proposed solution from section 3.1 is described in the following. It has to be emphasized that other realizations are also possible, and this description should not be understood as a restriction on potential implementations. The benefit of the following described implementation is that it does not require any additional classification of multicast groups within an aggregate. It serves as a proof of concept that no additional complexity is necessary to implement the proposed general solution described in section 3.
实施第3.1节中提出的解决方案的一种可能性如下所述。必须强调的是，其他实现也是可能的，并且此描述不应理解为对潜在实现的限制。下面描述的实现的好处是，它不需要对聚合中的多播组进行任何额外的分类。这是一个概念证明，实现第3节中所述的建议通用解决方案不需要额外的复杂性。
Because every multicast flow has to be considered by the multicast routing process (in this context, this notion signifies the multicast forwarding part and not the multicast route calculation and maintenance part, cf. Fig. 1), the addition of an extra byte in each multicast routing table entry containing the DS field, and thus its DS codepoint value per output link (resp. virtual interface, see Fig. 8), results in nearly no additional cost. Packets will be replicated by the multicast forwarding process, so this is also the right place for setting the correct DSCP values of the replicated packets. Their DSCP values are not copied from the incoming original packet, but
由于每个多播流必须由多播路由过程来考虑（在此上下文中，该概念表示多播转发部分而不是多播路由计算和维护部分，参见图1），因此在包含DS字段的每个多播路由表条目中添加额外字节，因此，其每个输出链路的DS码点值（分别为虚拟接口，见图8）几乎不会产生额外成本。数据包将通过多播转发过程进行复制，因此这也是设置已复制数据包的正确DSCP值的正确位置。它们的DSCP值不是从传入的原始数据包复制的，而是
from the additional DS field in the multicasting routing table entry for the corresponding output link (only the DSCP value must be copied, while the two remaining bits are ignored and are present for simplification reasons only). This field initially contains the codepoint of the LE PHB if incoming packets for this specific group do not carry the codepoint of the default PHB.
从对应输出链路的多播路由表条目中的附加DS字段（仅必须复制DSCP值，而忽略其余两位，仅出于简化原因而存在）。如果此特定组的传入数据包不包含默认PHB的代码点，则此字段最初包含LE PHB的代码点。
When a packet arrives with the default PHB, the outgoing replicates should also get the same codepoint in order to retain the behavior of current common multicast groups using the default PHB. A router configuration message changes the DSCP values in the multicast routing table and may also carry the new DSCP value which should be set in the replicated packets. It should be noted that although re-marking may also be performed by interior nodes, the forwarding performance will not be decreased, because the decision of when and what to re-mark is made by the management (control plane).
当数据包以默认PHB到达时，传出副本也应获得相同的代码点，以便保留使用默认PHB的当前公共多播组的行为。路由器配置消息更改多播路由表中的DSCP值，还可能携带应在复制的数据包中设置的新DSCP值。应当注意的是，尽管重新标记也可以由内部节点执行，但是转发性能不会降低，因为管理层（控制平面）决定何时以及重新标记什么。
Multicast Other List
Destination Fields of
Address virtual Inter- DS
interfaces face ID Field
+--------------------------------+ +-------------------+
| X | .... | *-------------------->| C | (DSCP,CU) |
|--------------------------------| +-------------------+
| Y | .... | *-----------+ | D | (DSCP,CU) |
|--------------------------------| | +-------------------+
| ... | .... | ... | |
. . . . | +-------------------+
. ... . .... . ... . +-------->| B | (DSCP,CU) |
+--------------------------------+ +-------------------+
| ... | .... | ... | | D | (DSCP,CU) |
+--------------------------------+ +-------------------+
| ... | ... |
. . .
. . .
Multicast Other List
Destination Fields of
Address virtual Inter- DS
interfaces face ID Field
+--------------------------------+ +-------------------+
| X | .... | *-------------------->| C | (DSCP,CU) |
|--------------------------------| +-------------------+
| Y | .... | *-----------+ | D | (DSCP,CU) |
|--------------------------------| | +-------------------+
| ... | .... | ... | |
. . . . | +-------------------+
. ... . .... . ... . +-------->| B | (DSCP,CU) |
+--------------------------------+ +-------------------+
| ... | .... | ... | | D | (DSCP,CU) |
+--------------------------------+ +-------------------+
| ... | ... |
. . .
. . .
Figure 8: Multicast routing table with additional fields for DSCP values
图8：包含DSCP值附加字段的多播路由表
In the following, it is shown that the NRS problem actually exists and occurs in reality. Hence, the problem and its solution was investigated using a standard Linux Kernel (v2.4.18) and the Linux-based implementation KIDS [11].
下文表明，NRS问题实际上存在并发生在现实中。因此，使用标准Linux内核（v2.4.18）和基于Linux的实现来研究这个问题及其解决方案[11]。
Furthermore, the proposed solution for the NRS problem has been implemented by enhancing the multicast routing table, as well as the
此外，提出的NRS问题解决方案已通过增强多播路由表以及
multicast routing behavior in the Linux kernel. In the following section, the modifications are briefly described.
Linux内核中的多播路由行为。在下一节中，简要描述这些修改。
Additional measurements with the simulation model simulatedKIDS [12] will be presented in section 9. They show the effects of the NRS problem in more detail and also the behavior of the BAs using or not using the Limited Effort PHB for re-marking.
第9节将介绍使用模拟模型simulatedKIDS[12]进行的其他测量。它们更详细地显示了NRS问题的影响，以及BAs使用或不使用有限努力PHB进行重新标记的行为。
As described in section 3.1, the proposed solution for avoiding the NRS Problem is an extension of each routing table entry in every Multicast router by one byte. In the Linux OS, the multicast routing table is implemented by the "Multicast Forwarding Cache (MFC)". The MFC is a hash table consisting of an "mfc-cache"-entry for each combination of the following three parameters: sender's IP address, multicast group address, and incoming interface.
如第3.1节所述，为避免NRS问题而提出的解决方案是将每个多播路由器中的每个路由表条目扩展一个字节。在Linux操作系统中，多播路由表由“多播转发缓存（MFC）”实现。MFC是一个哈希表，由“MFC缓存”组成，每个“MFC缓存”项用于以下三个参数的组合：发送方的IP地址、多播组地址和传入接口。
The routing information in a "mfc-cache"-entry is kept in an array of TTLs for each virtual interface. When the TTL is zero, a packet matching to this "mfc-cache"-entry will not be forwarded on this virtual interface. Otherwise, if the TTL is less than the packet's TTL, the latter will be forwarded on the interface with a decreased TTL.
“mfc缓存”项中的路由信息保存在每个虚拟接口的TTL数组中。当TTL为零时，与此“mfc缓存”条目匹配的数据包将不会在此虚拟接口上转发。否则，如果TTL小于数据包的TTL，后者将在接口上以降低的TTL转发。
In order to set an appropriate codepoint if bandwidth is allocated on an outgoing link, we added a second array of bytes -- similar to the TTL array -- for specifying the codepoint that should be used on a particular virtual interface. The first six bits of the byte contain the DSCP that should be used, and the seventh bit indicates whether the original codepoint in the packet has to be changed to the specified one (=0) or has to be left unchanged (=1). The default entry of the codepoint byte is zero; so initially, all packets will be re-marked to the default DSCP.
为了在传出链路上分配带宽时设置适当的代码点，我们添加了第二个字节数组——类似于TTL数组——用于指定应在特定虚拟接口上使用的代码点。字节的前六位包含应使用的DSCP，第七位指示数据包中的原始代码点是必须更改为指定的代码点（=0）还是必须保持不变（=1）。代码点字节的默认条目为零；因此，最初，所有数据包都将被重新标记为默认DSCP。
Furthermore, we modified the multicast forwarding code for considering this information while replicating multicast packets. To change an "mfc-cache"-entry we implemented a daemon for exchanging the control information with a management entity (e.g., a bandwidth broker). Currently, the daemon uses a proprietary protocol, but migration to the COPS protocol (RFC 2748) is planned.
此外，为了在复制多播数据包时考虑这些信息，我们修改了多播转发代码。为了更改“mfc缓存”条目，我们实现了一个守护进程，用于与管理实体（例如，带宽代理）交换控制信息。目前，守护进程使用专有协议，但计划迁移到COPS协议（RFC 2748）。
Sender
+---+ FHN: First Hop Node
| S | BN: Boundary Node
+---+
+#
+#
+#
+---+ +--+ +------+
|FHN|++++++++++++|BN|+++++++++++| host |
| |############| |***********| B |
+---+ +--+## +------+
+# #
+# #
+# #
+------+ +------+
|host A| |host C|
+------+ +------+
Sender
+---+ FHN: First Hop Node
| S | BN: Boundary Node
+---+
+#
+#
+#
+---+ +--+ +------+
|FHN|++++++++++++|BN|+++++++++++| host |
| |############| |***********| B |
+---+ +--+## +------+
+# #
+# #
+# #
+------+ +------+
|host A| |host C|
+------+ +------+
+++ EF flow (group1) with reservation
### EF flow (group2) with reservation
*** EF flow (group2) without reservation
+++ EF flow (group1) with reservation
### EF flow (group2) with reservation
*** EF flow (group2) without reservation
Figure 8.1: Evaluation of NRS-Problem described in Figure 3
图8.1：图3中描述的NRS问题评估
In order to prove case 1 of the NRS problem, as described in section 2.1, the testbed shown in Figure 8.1 was built. It is a reduced version of the network shown in Figure 5 and consists of two DS-capable nodes, an ingress boundary node and an egress boundary node. The absence of interior nodes does not have any effect on to the proof of the described problem.
为了证明NRS问题的案例1，如第2.1节所述，建立了图8.1所示的试验台。它是图5所示网络的简化版本，由两个支持DS的节点组成，一个入口边界节点和一个出口边界节点。缺少内部节点对所述问题的证明没有任何影响。
The testbed is comprised of two Personal Computers (Pentium III at 450 Mhz, 128 MB Ram, 3 network cards Intel eepro100) used as DiffServ nodes, as well as one sender and three receiver systems (also PCs). On the routers, KIDS has been installed and an mrouted (Multicast Routing Daemon) was used to perform multicast routing. The network was completely built of separate 10BaseT Ethernet segments in full-duplex mode. In [11], we evaluated the performance of the software routers and found out that even a PC at 200Mhz had no problem handling up to 10Mbps DS traffic on each link. Therefore, the presented measurements are not a result of performance bottlenecks caused by these software routers.
该试验台由两台用作DiffServ节点的个人计算机（450 Mhz的奔腾III、128 MB Ram、3块网卡Intel eepro100）以及一个发送器和三个接收器系统（也是PC）组成。在路由器上，安装了KIDS，并使用mrouted（多播路由守护进程）执行多播路由。该网络完全由全双工模式下的独立10BaseT以太网段构成。在[11]中，我们评估了软件路由器的性能，发现即使是200Mhz的PC也可以处理每条链路上高达10Mbps的DS流量。因此，所提出的测量不是这些软件路由器造成的性能瓶颈的结果。
The sender generated two shaped UDP traffic flows of 500kbps (packets of 1.000 byte constant size) each and sent them to multicast group 1 (233.1.1.1) and 2 (233.2.2.2). In both measurements, receiver A had a reservation along the path to the sender for each flow, receiver B had reserved for flow 1, and C for flow 2. Therefore, two static profiles are installed in the ingress boundary node with 500kbps EF bandwidth and a token bucket size of 10.000 bytes for each flow.
发送方生成了两个500kbps的成型UDP通信流（1.000字节恒定大小的数据包），并将其发送到多播组1（233.1.1.1）和2（233.2.2）。在这两次测量中，接收器A沿每个流的发送器路径保留，接收器B为流1保留，C为流2保留。因此，入口边界节点中安装了两个静态配置文件，每个流的EF带宽为500kbps，令牌桶大小为10.000字节。
In the egress boundary node, one profile has been installed for the output link to host B and one related for the output link to host C. Each of them permits up to 500kbps Expedited Forwarding, but only the aggregate of Expedited Forwarding traffic carried on the outgoing link is considered.
在出口边界节点中，已为到主机B的输出链路安装了一个配置文件，并为到主机C的输出链路安装了一个相关配置文件。每个配置文件都允许高达500kbps的快速转发，但仅考虑传出链路上承载的快速转发流量的总和。
In measurement 1, the hosts A and B joined to group 1, while A, B, and C joined to group 2. Those joins are using a reservation for the group towards the sender. Only the join of host B to group 2 has no admitted reservation. As described in section 2.1, this will cause the NRS problem (case 1). Metering and policing mechanisms in the egress boundary node throttle down the EF aggregate to the reserved 500kbps, and do not depend on whether or not individual flows have been reserved.
在测量1中，主机A和B加入到组1，而A、B和C加入到组2。这些联接正在使用组对发件人的保留。只有主机B加入到组2时没有允许的预订。如第2.1节所述，这将导致NRS问题（情况1）。出口边界节点中的计量和监管机制将EF聚合节流至保留的500kbps，并且不取决于是否保留了单个流。
+--------+--------+--------+
| Host A | Host B | Host C |
+---------+--------+--------+--------+
| Group 1 | 500kbps| 250kbps| 500kbps|
+---------+--------+--------+--------+
| Group 2 | 500kbps| 250kbps| |
+---------+--------+--------+--------+
+--------+--------+--------+
| Host A | Host B | Host C |
+---------+--------+--------+--------+
| Group 1 | 500kbps| 250kbps| 500kbps|
+---------+--------+--------+--------+
| Group 2 | 500kbps| 250kbps| |
+---------+--------+--------+--------+
Figure 8.2: Results of measurement 1 (without the proposed solution): Average bandwidth of each flow. --> Flows of group 1 and 2 on the link to host B share the reserved aggregate of group 1.
图8.2：测量1的结果（无建议的解决方案）：每个流的平均带宽。-->连接到主机B的链路上的组1和组2的流共享组1的保留聚合。
Figure 8.2 shows the obtained results. Host A and C received their flows without any interference. But host B received data from group 1 with only half of the reserved bandwidth, so one half of the packets have been discarded. Figure 8.2 also shows that receiver B got the total amount of bandwidth for group 1 and 2, that is exactly the reserved 500kbps. Flow 2 got Expedited Forwarding without actually having reserved any bandwidth and additionally violated the guarantee of group 1 on that link.
图8.2显示了获得的结果。主机A和C在没有任何干扰的情况下接收到它们的流。但主机B从组1接收到的数据只有保留带宽的一半，因此有一半的数据包被丢弃。图8.2还显示，接收器B获得了组1和组2的总带宽，即保留的500kbps。流2在没有实际保留任何带宽的情况下获得了加速转发，并且还违反了该链路上组1的保证。
For measurement 2, the previously presented solution (cf. section 3.1) has been installed in the boundary node. Now, while duplicating the packets, whether the codepoint has to be changed to Best-Effort (or Limited Effort) or whether it can be just duplicated is checked. In this measurement, it changed the codepoint for group 2 on the link to Host B to Best-Effort.
对于测量2，先前提出的解决方案（参见第3.1节）已安装在边界节点中。现在，在复制数据包时，检查是否必须将代码点更改为最大努力（或有限努力）或是否可以仅复制。在此测量中，它将到主机B的链路上的组2的代码点更改为Best Effort。
+--------+--------+--------+
| Host A | Host B | Host C |
+---------+--------+--------+--------+
| Group 1 | 500kbps| 500kbps| 500kbps|
+---------+--------+--------+--------+
| Group 2 | 500kbps| 500kbps| |
+---------+--------+--------+--------+
+--------+--------+--------+
| Host A | Host B | Host C |
+---------+--------+--------+--------+
| Group 1 | 500kbps| 500kbps| 500kbps|
+---------+--------+--------+--------+
| Group 2 | 500kbps| 500kbps| |
+---------+--------+--------+--------+
Figure 8.3: Results of measurement 1 (with the proposed solution): Average bandwidth of each flow. --> Flow of group 1 on the link to host B gets the reserved bandwidth of group 1. The flow of group 2 has been re-marked to Best-Effort.
图8.3：测量结果1（使用建议的解决方案）：每个流的平均带宽。-->连接到主机B的链路上的组1流获得组1的保留带宽。第2组的流程已重新标记为“尽力而为”。
Results of this measurement are presented in Figure 8.3. Each host received its flows with the reserved bandwidth and without any packet loss. Packets from group 2 are re-marked in the boundary node so that they have been treated as best-effort traffic. In this case, they got the same bandwidth as the Expedited Forwarding flow, and because there was not enough other traffic on the link present, there was no need to discard packets.
测量结果如图8.3所示。每个主机都以保留的带宽接收其流，并且没有任何数据包丢失。来自组2的数据包在边界节点中被重新标记，以便它们被视为尽力而为的流量。在这种情况下，它们获得了与加速转发流相同的带宽，并且由于链路上没有足够的其他流量，因此不需要丢弃数据包。
The above measurements confirm that the Neglected Reservation Subtree problem is to be taken seriously and that the presented solution will solve it.
上述测量结果证实，应认真对待被忽略的保留子树问题，并且提出的解决方案将解决该问题。
This section shows some results from a simulative study which shows the correctness of the proposed solution and the effect of re-marking the responsible flow to Limited Effort. A proof of the NRS problem has also been given in section 8 and in [13]. This section shows the benefit for the default Best Effort traffic when Limited Effort is used for re-marking instead of Best Effort. The results strongly motivate the use of Limited Effort.
本节展示了模拟研究的一些结果，这些结果表明了所提出解决方案的正确性以及将责任流重新标记为有限努力的效果。第8节和[13]中也给出了NRS问题的证明。本节显示了当有限努力用于重新标记而不是最大努力时，默认最大努力流量的好处。结果强烈地激发了有限努力的使用。
In the following scenario, the boundary nodes had a link speed of 10 Mpbs and Interior Routers had a link speed of 12 Mbps. In boundary nodes, a 5 Mbps aggregate for EF has been reserved.
在以下场景中，边界节点的链路速度为10 Mbps，内部路由器的链路速度为12 Mbps。在边界节点中，为EF保留了5 Mbps的聚合。
When Limited Effort was used, LE got 10% capacity (0.5Mpbs) from the original BE aggregate and BE 90% (4.5Mbps) of the original BE aggregate capacity. The bandwidth between LE and BE is shared by using WFQ scheduling.
当使用有限的努力时，LE从原始BE骨料中获得10%的容量（0.5Mpbs），并达到原始BE骨料容量的90%（4.5Mbps）。LE和BE之间的带宽通过WFQ调度共享。
The following topology was used, where Sx is a sender, BRx a boundary node, IRx an interior node, and Dx a destination/receiver.
使用了以下拓扑，其中Sx是发送方，BRx是边界节点，IRx是内部节点，Dx是目的地/接收方。
+--+ +--+ +---+ +--+
|S1| |S0| /=|BR5|=====|D0|
+--+ +--+ // +---+ +--+
\\ || //
\\ || //
+--+ \+---+ +---+ +---+ +---+ +--+
|S2|===|BR1|=====|IR1|=====|IR2|======|BR3|=====|D1|
+--+ +---+ /+---+ +---+ +---+ +--+
// \\ +--+
// \\ /=|D2|
+--+ +---+ // \\ // +--+
|S3|===|BR2|=/ +---+/
+--+ +---+ /=|BR4|=\
|| +--+ // +---+ \\ +--+
+--+ |D4|=/ \=|D3|
|S4| +--+ +--+
+--+
+--+ +--+ +---+ +--+
|S1| |S0| /=|BR5|=====|D0|
+--+ +--+ // +---+ +--+
\\ || //
\\ || //
+--+ \+---+ +---+ +---+ +---+ +--+
|S2|===|BR1|=====|IR1|=====|IR2|======|BR3|=====|D1|
+--+ +---+ /+---+ +---+ +---+ +--+
// \\ +--+
// \\ /=|D2|
+--+ +---+ // \\ // +--+
|S3|===|BR2|=/ +---+/
+--+ +---+ /=|BR4|=\
|| +--+ // +---+ \\ +--+
+--+ |D4|=/ \=|D3|
|S4| +--+ +--+
+--+
Figure 9.1: Simulation Topology
图9.1：仿真拓扑
The following table shows the flows in the simulation runs, e.g., EF0 is sent from Sender S0 to Destination D0 with a rate of 4 Mbps using an EF reservation.
下表显示了模拟运行中的流，例如，使用EF保留，EF0以4 Mbps的速率从发送方S0发送到目的地D0。
In the presented cases (I to IV), different amounts of BE traffic were used to show the effects of Limited Effort in different cases. The intention of these four cases is described after the table.
在所介绍的案例（I至IV）中，不同数量的BE流量用于显示不同案例中有限努力的效果。这四个案例的意图见下表。
In all simulation models, EF sources generated constant rate traffic with constant packet sizes using UDP.
在所有仿真模型中，EF源使用UDP生成具有恒定数据包大小的恒定速率流量。
The BE sources also generated constant rate traffic, where BE0 used UDP, and BE1 used TCP as a transport protocol.
BE源还生成恒定速率流量，其中BE0使用UDP，BE1使用TCP作为传输协议。
+----+--------+-------+----------+-----------+-----------+---------+
|Flow| Source | Dest. | Case I | Case II | Case III | Case IV |
+----+--------+-------+----------+-----------+-----------+---------+
| EF0| S0 | D0 | 4 Mbps | 4 Mbps | 4 Mbps | 4 Mbps |
+----+--------+-------+----------+-----------+-----------+---------+
| EF1| S1 | D1 | 2 Mbps | 2 Mbps | 2 Mbps | 2 Mbps |
+----+--------+-------+----------+-----------+-----------+---------+
| EF2| S2 | D2 | 5 Mbps | 5 Mbps | 5 Mbps | 5 Mbps |
+----+--------+-------+----------+-----------+-----------+---------+
| BE0| S3 | D3 | 1 Mbps | 2.25 Mbps | 0.75 Mbps |3.75 Mbps|
+----+--------+-------+----------+-----------+-----------+---------+
| BE1| S4 | D4 | 4 Mbps | 2.25 Mbps | 0.75 Mbps |3.75 Mbps|
+----+--------+-------+----------+-----------+-----------+---------+
+----+--------+-------+----------+-----------+-----------+---------+
|Flow| Source | Dest. | Case I | Case II | Case III | Case IV |
+----+--------+-------+----------+-----------+-----------+---------+
| EF0| S0 | D0 | 4 Mbps | 4 Mbps | 4 Mbps | 4 Mbps |
+----+--------+-------+----------+-----------+-----------+---------+
| EF1| S1 | D1 | 2 Mbps | 2 Mbps | 2 Mbps | 2 Mbps |
+----+--------+-------+----------+-----------+-----------+---------+
| EF2| S2 | D2 | 5 Mbps | 5 Mbps | 5 Mbps | 5 Mbps |
+----+--------+-------+----------+-----------+-----------+---------+
| BE0| S3 | D3 | 1 Mbps | 2.25 Mbps | 0.75 Mbps |3.75 Mbps|
+----+--------+-------+----------+-----------+-----------+---------+
| BE1| S4 | D4 | 4 Mbps | 2.25 Mbps | 0.75 Mbps |3.75 Mbps|
+----+--------+-------+----------+-----------+-----------+---------+
Table 9.1: Direction, amount and Codepoint of flows in the four simulation cases (case I to IV)
表9.1：四种模拟情况下（情况一至四）的流动方向、数量和代码点
The four cases (I to IV) used in the simulation runs had the following characteristics:
模拟运行中使用的四种情况（I至IV）具有以下特点：
Case I: In this scenario, the BE sources sent together exactly 5 Mbps, so there is no congestion in the BE queue.
案例一：在这种情况下，BE源一起发送的速度正好为5 Mbps，因此BE队列中没有拥塞。
Case II: BE is sending less than 5 Mbps, so there is space available in the BE queue for re-marked traffic. BE0 and BE1 are sending together 4.5 Mbps, which is exactly the share of BE when LE is used. So, when multicast packets are re-marked to LE because of the NRS problem, the LE should get 0.5 Mbps and BE 4.5 Mbps, which is still enough for BE0 and BE1. LE should not show a greedy behavior and should not use resources from BE.
案例二：BE发送的流量小于5 Mbps，因此BE队列中有空间用于重新标记的流量。BE0和BE1同时发送4.5 Mbps，这正是使用LE时BE的份额。因此，当由于NRS问题将多播数据包重新标记为LE时，LE应获得0.5 Mbps和4.5 Mbps，这对于BE0和BE1仍然足够。LE不应该表现出贪婪的行为，也不应该使用BE的资源。
Case III: In this case, BE is very low. BE0 and BE1 use together only 1.5 Mbps. So when LE is used, it should be able to use the unused bandwidth resources from BE.
案例三：在这种情况下，BE非常低。BE0和BE1一起仅使用1.5 Mbps。因此，当使用LE时，它应该能够使用be中未使用的带宽资源。
Case IV: BE0 and BE1 send together 7.5 Mbps so there is congestion in the BE queue. In this case, LE should get 0.5 Mbps (not more and not less).
情况四：BE0和BE1同时发送7.5 Mbps，因此BE队列中存在拥塞。在这种情况下，LE应获得0.5 Mbps（不大于或小于）。
In each scenario, loss rate and throughput of the considered flows and aggregates have been metered.
在每种情况下，对所考虑的流量和总量的损失率和吞吐量进行了计量。
When the branching point of a newly added multicast subtree is located in an interior node, the NRS problem can occur as described in section 2.1 (Case 2).
当新添加的多播子树的分支点位于内部节点时，NRS问题可能会发生，如第2.1节（情况2）所述。
In the simulation runs presented in the following four subsections, D3 joins to the multicast group of sender S0 without making any reservation or resource allocation. Consequently, a new branch is added to the existing multicast tree. The branching point issued by the join of D3 is located in IR2. On the link to BR3, no bandwidth was allocated for the new flow (EF0).
在以下四小节中介绍的模拟运行中，D3加入发送方S0的多播组，而不进行任何保留或资源分配。因此，一个新的分支被添加到现有的多播树中。D3的联接发出的分支点位于IR2中。在到BR3的链路上，没有为新流（EF0）分配带宽。
The metered throughput of flows on the link between IR2 and BR3 in the four different cases is shown in the following four subsections. The situation before the new receiver joins is shown in the second column. The situation after the join without the proposed solution is shown in column three. The fourth column presents the results when the proposed solution of section 3.1 is used and the responsible flow is re-marked to LE.
以下四小节显示了四种不同情况下IR2和BR3之间链路上的流量计量吞吐量。新接收器加入之前的情况显示在第二列中。第三列显示了连接后没有建议解决方案的情况。第四列显示了使用第3.1节中建议的解决方案时的结果，并将责任流重新标记为LE。
9.2.1.1. Case I:
9.2.1.1. 案例一：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.007 Mbps | LE0: 0.504 Mbps |
|achieved| EF1: 2.001 Mbps | EF1: 2.003 Mbps | EF1: 2.000 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 5.009 Mbps | EF2: 5.000 Mbps |
|put | BE0: 1.000 Mbps | BE0: 0.601 Mbps | BE0: 1.000 Mbps |
| | BE1: 4.000 Mbps | BE1: 0.399 Mbps | BE1: 3.499 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.003 Mbps | EF: 11.019 Mbps | EF: 7.000 Mbps |
|through-| BE: 5.000 Mbps | BE: 1.000 Mbps | BE: 4.499 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 87.4 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 34.8 % | BE0: 0 % |
| | BE1: 0 % | BE1: 59.1 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.007 Mbps | LE0: 0.504 Mbps |
|achieved| EF1: 2.001 Mbps | EF1: 2.003 Mbps | EF1: 2.000 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 5.009 Mbps | EF2: 5.000 Mbps |
|put | BE0: 1.000 Mbps | BE0: 0.601 Mbps | BE0: 1.000 Mbps |
| | BE1: 4.000 Mbps | BE1: 0.399 Mbps | BE1: 3.499 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.003 Mbps | EF: 11.019 Mbps | EF: 7.000 Mbps |
|through-| BE: 5.000 Mbps | BE: 1.000 Mbps | BE: 4.499 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 87.4 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 34.8 % | BE0: 0 % |
| | BE1: 0 % | BE1: 59.1 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
9.2.1.2. Case II:
9.2.1.2. 案例二：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.003 Mbps | LE0: 0.500 Mbps |
|achieved| EF1: 2.000 Mbps | EF1: 2.001 Mbps | EF1: 2.001 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 5.005 Mbps | EF2: 5.002 Mbps |
|put | BE0: 2.248 Mbps | BE0: 0.941 Mbps | BE0: 2.253 Mbps |
| | BE1: 2.252 Mbps | BE1: 0.069 Mbps | BE1: 2.247 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.002 Mbps | EF: 11.009 Mbps | EF: 7.003 Mbps. |
|through-| BE: 4.500 Mbps | BE: 1.010 Mbps | BE: 4.500 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 87.4 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 58.0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 57.1 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.003 Mbps | LE0: 0.500 Mbps |
|achieved| EF1: 2.000 Mbps | EF1: 2.001 Mbps | EF1: 2.001 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 5.005 Mbps | EF2: 5.002 Mbps |
|put | BE0: 2.248 Mbps | BE0: 0.941 Mbps | BE0: 2.253 Mbps |
| | BE1: 2.252 Mbps | BE1: 0.069 Mbps | BE1: 2.247 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.002 Mbps | EF: 11.009 Mbps | EF: 7.003 Mbps. |
|through-| BE: 4.500 Mbps | BE: 1.010 Mbps | BE: 4.500 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 87.4 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 58.0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 57.1 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
9.2.1.3. Case III:
9.2.1.3. 案例三：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 3.998 Mbps | LE0: 3.502 Mbps |
|achieved| EF1: 2.000 Mbps | EF1: 2.001 Mbps | EF1: 2.001 Mbps |
|through-| EF2: 5.000 Mbps | EF2: 5.002 Mbps | EF2: 5.003 Mbps |
|put | BE0: 0.749 Mbps | BE0: 0.572 Mbps | BE0: 0.748 Mbps |
| | BE1: 0.749 Mbps | BE1: 0.429 Mbps | BE1: 0.748 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.000 Mbps | EF: 11.001 Mbps | EF: 7.004 Mbps |
|through-| BE: 1.498 Mbps | BE: 1.001 Mbps | BE: 1.496 Mbps |
|put | LE: --- | LE: --- | LE: 3.502 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 12.5 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 19.7 % | BE0: 0 % |
| | BE1: 0 % | BE1: 32.6 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 3.998 Mbps | LE0: 3.502 Mbps |
|achieved| EF1: 2.000 Mbps | EF1: 2.001 Mbps | EF1: 2.001 Mbps |
|through-| EF2: 5.000 Mbps | EF2: 5.002 Mbps | EF2: 5.003 Mbps |
|put | BE0: 0.749 Mbps | BE0: 0.572 Mbps | BE0: 0.748 Mbps |
| | BE1: 0.749 Mbps | BE1: 0.429 Mbps | BE1: 0.748 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.000 Mbps | EF: 11.001 Mbps | EF: 7.004 Mbps |
|through-| BE: 1.498 Mbps | BE: 1.001 Mbps | BE: 1.496 Mbps |
|put | LE: --- | LE: --- | LE: 3.502 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 12.5 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 19.7 % | BE0: 0 % |
| | BE1: 0 % | BE1: 32.6 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
9.2.1.4. Case IV:
9.2.1.4. 案例四：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.001 Mbps | LE0: 0.500 Mbps |
|achieved| EF1: 2.018 Mbps | EF1: 2.000 Mbps | EF1: 2.003 Mbps |
|through-| EF2: 5.005 Mbps | EF2: 5.001 Mbps | EF2: 5.007 Mbps |
|put | BE0: 2.825 Mbps | BE0: 1.000 Mbps | BE0: 3.425 Mbps |
| | BE1: 2.232 Mbps | BE1: --- | BE1: 1.074 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.023 Mbps | EF: 11.002 Mbps | EF: 7.010 Mbps |
|through-| BE: 5.057 Mbps | BE: 1.000 Mbps | BE: 4.499 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 75.0 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 23.9 % | BE0: 73.3 % | BE0: 0 % |
| | BE1: 41.5 % | BE1: --- | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.001 Mbps | LE0: 0.500 Mbps |
|achieved| EF1: 2.018 Mbps | EF1: 2.000 Mbps | EF1: 2.003 Mbps |
|through-| EF2: 5.005 Mbps | EF2: 5.001 Mbps | EF2: 5.007 Mbps |
|put | BE0: 2.825 Mbps | BE0: 1.000 Mbps | BE0: 3.425 Mbps |
| | BE1: 2.232 Mbps | BE1: --- | BE1: 1.074 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.023 Mbps | EF: 11.002 Mbps | EF: 7.010 Mbps |
|through-| BE: 5.057 Mbps | BE: 1.000 Mbps | BE: 4.499 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 75.0 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 23.9 % | BE0: 73.3 % | BE0: 0 % |
| | BE1: 41.5 % | BE1: --- | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
NOTE: BE1 has undefined throughput and loss in situation "after join (no re-marking)", because TCP is going into retransmission back-off timer phase and closes the connection after 512 seconds.
注意：BE1在“加入后（无重新标记）”的情况下具有未定义的吞吐量和丢失，因为TCP将进入重传回退计时器阶段，并在512秒后关闭连接。
When the branching point of a newly added multicast subtree is located in a boundary node, the NRS problem can occur as described in section 2.1 (Case 1).
当新添加的多播子树的分支点位于边界节点中时，NRS问题可能会发生，如第2.1节（情况1）所述。
In the simulation runs presented in the following four subsections, D3 joins to the multicast group of sender S1 without making any reservation or resource allocation. Consequently, a new branch is added to the existing multicast tree. The branching point issued by the join of D3 is located in BR3. On the link to BR4, no bandwidth was allocated for the new flow (EF1).
在以下四小节中介绍的模拟运行中，D3加入发送方S1的多播组，而不进行任何保留或资源分配。因此，一个新的分支被添加到现有的多播树中。D3的联接发出的分支点位于BR3中。在到BR4的链路上，没有为新流（EF1）分配带宽。
The metered throughput of the flows on the link between BR3 and BR4 in the four different cases is shown in the following four subsections. The situation before the new receiver joins is shown in the second column. The situation after the join but without the proposed solution is shown in column three. The fourth column presents results when the proposed solution of section 3.1 is used and the responsible flow is re-marked to LE.
以下四小节显示了四种不同情况下BR3和BR4之间链路上的流量计量吞吐量。新接收器加入之前的情况显示在第二列中。第三列显示了连接后但没有建议解决方案的情况。第四列显示了使用第3.1节中建议的解决方案时的结果，并将责任流重新标记为LE。
9.2.2.1. Case I:
9.2.2.1. 案例一：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.489 Mbps | LE1: 0.504 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 3.512 Mbps | EF2: 5.002 Mbps |
|put | BE0: 1.000 Mbps | BE0: 1.000 Mbps | BE0: 1.004 Mbps |
| | BE1: 4.000 Mbps | BE1: 4.002 Mbps | BE1: 3.493 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.002 Mbps | EF: 5.001 Mbps | EF: 5.002 Mbps |
|through-| BE: 5.000 Mbps | BE: 5.002 Mbps | BE: 4.497 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 25.6 % | LE1: 73.4 % |
|loss | EF2: 0 % | EF2: 29.7 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.489 Mbps | LE1: 0.504 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 3.512 Mbps | EF2: 5.002 Mbps |
|put | BE0: 1.000 Mbps | BE0: 1.000 Mbps | BE0: 1.004 Mbps |
| | BE1: 4.000 Mbps | BE1: 4.002 Mbps | BE1: 3.493 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.002 Mbps | EF: 5.001 Mbps | EF: 5.002 Mbps |
|through-| BE: 5.000 Mbps | BE: 5.002 Mbps | BE: 4.497 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 25.6 % | LE1: 73.4 % |
|loss | EF2: 0 % | EF2: 29.7 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
9.2.2.2. Case II:
9.2.2.2. 案例二：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.520 Mbps | LE1: 0.504 Mbps |
|through-| EF2: 5.003 Mbps | EF2: 3.482 Mbps | EF2: 5.002 Mbps |
|put | BE0: 2.249 Mbps | BE0: 2.249 Mbps | BE0: 2.245 Mbps |
| | BE1: 2.252 Mbps | BE1: 2.252 Mbps | BE1: 2.252 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.003 Mbps | EF: 5.002 Mbps | EF: 5.002 Mbps |
|through-| BE: 4.501 Mbps | BE: 4.501 Mbps | BE: 4.497 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 24.0 % | LE1: 74.8 % |
|loss | EF2: 0 % | EF2: 30.4 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.520 Mbps | LE1: 0.504 Mbps |
|through-| EF2: 5.003 Mbps | EF2: 3.482 Mbps | EF2: 5.002 Mbps |
|put | BE0: 2.249 Mbps | BE0: 2.249 Mbps | BE0: 2.245 Mbps |
| | BE1: 2.252 Mbps | BE1: 2.252 Mbps | BE1: 2.252 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.003 Mbps | EF: 5.002 Mbps | EF: 5.002 Mbps |
|through-| BE: 4.501 Mbps | BE: 4.501 Mbps | BE: 4.497 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 24.0 % | LE1: 74.8 % |
|loss | EF2: 0 % | EF2: 30.4 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
9.2.2.3. Case III:
9.2.2.3. 案例三：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.084 Mbps | LE1: 2.000 Mbps |
|through-| EF2: 5.001 Mbps | EF2: 3.919 Mbps | EF2: 5.000 Mbps |
|put | BE0: 0.749 Mbps | BE0: 0.752 Mbps | BE0: 0.750 Mbps |
| | BE1: 0.749 Mbps | BE1: 0.748 Mbps | BE1: 0.750 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.001 Mbps | EF: 5.003 Mbps | EF: 5.000 Mbps |
|through-| BE: 1.498 Mbps | BE: 1.500 Mbps | BE: 1.500 Mbps |
|put | LE: --- | LE: --- | LE: 2.000 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 45.7 % | LE1: 0 % |
|loss | EF2: 0 % | EF2: 21.7 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.084 Mbps | LE1: 2.000 Mbps |
|through-| EF2: 5.001 Mbps | EF2: 3.919 Mbps | EF2: 5.000 Mbps |
|put | BE0: 0.749 Mbps | BE0: 0.752 Mbps | BE0: 0.750 Mbps |
| | BE1: 0.749 Mbps | BE1: 0.748 Mbps | BE1: 0.750 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.001 Mbps | EF: 5.003 Mbps | EF: 5.000 Mbps |
|through-| BE: 1.498 Mbps | BE: 1.500 Mbps | BE: 1.500 Mbps |
|put | LE: --- | LE: --- | LE: 2.000 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 45.7 % | LE1: 0 % |
|loss | EF2: 0 % | EF2: 21.7 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
9.2.2.4. Case IV:
9.2.2.4. 案例四：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.201 Mbps | LE1: 0.500 Mbps |
|through-| EF2: 5.048 Mbps | EF2: 3.803 Mbps | EF2: 5.004 Mbps |
|put | BE0: 2.638 Mbps | BE0: 2.535 Mbps | BE0: 3.473 Mbps |
| | BE1: 2.379 Mbps | BE1: 2.536 Mbps | BE1: 1.031 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.048 Mbps | EF: 5.004 Mbps | EF: 5.004 Mbps |
|through-| BE: 5.017 Mbps | BE: 5.071 Mbps | BE: 4.504 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 40.0 % | LE1: 68.6 % |
|loss | EF2: 0 % | EF2: 23.0 % | EF2: 0 % |
|rate | BE0: 30.3 % | BE0: 32.1 % | BE0: 0 % |
| | BE1: 33.3 % | BE1: 32.7 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.201 Mbps | LE1: 0.500 Mbps |
|through-| EF2: 5.048 Mbps | EF2: 3.803 Mbps | EF2: 5.004 Mbps |
|put | BE0: 2.638 Mbps | BE0: 2.535 Mbps | BE0: 3.473 Mbps |
| | BE1: 2.379 Mbps | BE1: 2.536 Mbps | BE1: 1.031 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.048 Mbps | EF: 5.004 Mbps | EF: 5.004 Mbps |
|through-| BE: 5.017 Mbps | BE: 5.071 Mbps | BE: 4.504 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 40.0 % | LE1: 68.6 % |
|loss | EF2: 0 % | EF2: 23.0 % | EF2: 0 % |
|rate | BE0: 30.3 % | BE0: 32.1 % | BE0: 0 % |
| | BE1: 33.3 % | BE1: 32.7 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
The authors wish to thank Mark Handley and Bill Fenner for their valuable comments on this document. Special thanks go to Milena Neumann for her extensive efforts in performing the simulations. We would also like to thank the KIDS simulation team [12].
作者希望感谢Mark Handley和Bill Fenner对本文件的宝贵意见。特别感谢Milena Neumann为执行模拟所做的大量努力。我们还要感谢儿童模拟团队[12]。
[1] 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.
[1] Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[2] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[2] Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[3] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[3] Nichols，K.和B.Carpenter，“按域区分服务行为的定义及其规范规则”，RFC 3086，2001年4月。
[4] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1", RFC 2205, September 1997.
[4] Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源保留协议（RSVP）——版本1”，RFC 22052997年9月。
[5] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[5] Bernet，Y.，“RSVP数据类对象的格式”，RFC 2996，2000年11月。
[6] Waitzman, D., Partridge, C. and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[6] Waitzman，D.，Partridge，C.和S.Deering，“距离向量多播路由协议”，RFC 1075，1988年11月。
[7] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, L., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[7] Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Liu，L.，Sharma，P.和L.Wei，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[8] Adams, A., Nicholas, J. and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM) Protocol Specification (Revised)", Work in Progress.
[8] Adams，A.，Nicholas，J.和W.Siadak，“协议独立多播-密集模式（PIM-DM）协议规范（修订版）”，正在进行的工作。
[9] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group" RFC 2597, June 1999.
[9] Heinanen，J.，Baker，F.，Weiss，W.和J.Wroclawski，“保证转运PHB集团”RFC 25971999年6月。
[10] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal Management Model for DiffServ Routers", RFC 3290, May 2002.
[10] Bernet，Y.，Blake，S.，Grossman，D.和A.Smith，“区分服务路由器的非正式管理模型”，RFC 3290，2002年5月。
[11] R. Bless, K. Wehrle. Evaluation of Differentiated Services using an Implementation under Linux, Proceedings of the Intern. Workshop on Quality of Service (IWQOS'99), London, 1999.
[11] R.上帝保佑，K.韦勒。使用Linux下的实现对差异化服务进行评估，《实习学报》。服务质量研讨会（IWQOS'99），伦敦，1999年。
[12] K. Wehrle, J. Reber, V. Kahmann. A simulation suite for Internet nodes with the ability to integrate arbitrary Quality of Service behavior, Proceedings of Communication Networks And Distributed Systems Modeling And Simulation Conference (CNDS 2001), Phoenix (AZ), January 2001.
[12] 韦勒，雷伯，卡曼。具有集成任意服务质量行为能力的互联网节点模拟套件，《通信网络与分布式系统建模与仿真会议论文集》（CNDS 2001），凤凰城（AZ），2001年1月。
[13] R. Bless, K. Wehrle. Group Communication in Differentiated Services Networks, Internet QoS for the Global Computing 2001 (IQ 2001), IEEE International Symposium on Cluster Computing and the Grid, May 2001, Brisbane, Australia, IEEE Press.
[13] R.上帝保佑，K.韦勒。差异化服务网络中的群组通信，2001年全球计算的互联网QoS（IQ 2001），IEEE集群计算和网格国际研讨会，2001年5月，澳大利亚布里斯班，IEEE出版社。
[14] Davie, B., Charny, A., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[14] Davie，B.，Charny，A.，Bennett，J.C.R.，Benson，K.，Le Boudec，J.Y.，Courtney，W.，Davari，S.，Firoiu，V.和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[15] Charny, A., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C. and K.K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002.
[15] Charny，A.，Bennett，J.C.R.，Benson，K.，Le Boudec，J.Y.，Chiu，A.，Courtney，W.，Davari，S.，Firoiu，V.，Kalmanek，C.和K.K.Ramakrishnan，“EF PHB（每跳快速转发行为）新定义的补充信息”，RFC 3247，2002年3月。
[16] Bless, R., Nichols, K. and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
[16] Bless，R.，Nichols，K.和K.Wehrle，“区分服务的低域行为（PDB）”，RFC 36622003年12月。
Comments and questions related to this document can be addressed to one of the authors listed below.
与本文件相关的意见和问题可向下列作者之一提出。
Roland Bless Institute of Telematics Universitaet Karlsruhe (TH) Zirkel 2 76128 Karlsruhe, Germany
罗兰·布莱斯远程信息处理研究所卡尔斯鲁厄大学（TH）Zirkel 2 76128卡尔斯鲁厄，德国
Phone: +49 721 608 6413
EMail: bless@tm.uka.de
URI: http://www.tm.uka.de/~bless
Phone: +49 721 608 6413
EMail: bless@tm.uka.de
URI: http://www.tm.uka.de/~bless
Klaus Wehrle University of Tuebingen WSI - Computer Networks and Internet / Protocol Engineering & Distributed Systems Morgenstelle 10c 72076 Tuebingen, Germany
克劳斯Weele大学TuebEnEN WSI -计算机网络和互联网/协议工程和分布式系统MgunsTele10C 72076 TuEBEGEN，德国
EMail: Klaus.Wehrle@uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/~wehrle/
EMail: Klaus.Wehrle@uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/~wehrle/
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。