Network Working Group S. Herzog
Request for Comments: 3181 PolicyConsulting.Com
Obsoletes: 2751 October 2001
Category: Standards Track
Network Working Group S. Herzog
Request for Comments: 3181 PolicyConsulting.Com
Obsoletes: 2751 October 2001
Category: Standards Track
Signaled Preemption Priority Policy Element
信号抢占优先级策略元素
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as the Resource ReSerVation Protocol (RSVP) and Common Open Policy Service (COPS).
本文档描述了一个抢占优先级策略元素，用于基于策略的信号许可协议（如资源预留协议（RSVP）和公共开放策略服务（COPS））。
Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high-priority flow.
抢占优先级定义了竞争进入网络的流集合中的相对重要性（等级）。网络节点可以通过优先顺序来抢占某些先前承认的低优先级流，而不是为了按顺序（先到先入）来接纳流，以便为更新的、高优先级的流腾出空间。
This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment error in RFC 2751.
此备忘录更正RFC 2751中的RSVP策略数据P型码点分配错误。
Table of Contents
目录
1 Introduction .....................................................2
2 Scope and Applicability ..........................................3
3 Stateless Policy .................................................3
4 Policy Element Format ............................................4
5 Priority Merging Issues ..........................................5
5.1 Priority Merging Strategies ...................................6
5.1.1 Take priority of highest QoS .................................6
5.1.2 Take highest priority ........................................7
5.1.3 Force error on heterogeneous merge ...........................7
5.2 Modifying Priority Elements ...................................7
6 Error Processing .................................................8
7 IANA Considerations ..............................................8
8 Security Considerations ..........................................8
9 References .......................................................9
10 Author's Address ...............................................9
Appendix A: Example ...............................................10
A.1 Computing Merged Priority ....................................10
A.2 Translation (Compression) of Priority Elements ...............11
Full Copyright Statement ..........................................12
1 Introduction .....................................................2
2 Scope and Applicability ..........................................3
3 Stateless Policy .................................................3
4 Policy Element Format ............................................4
5 Priority Merging Issues ..........................................5
5.1 Priority Merging Strategies ...................................6
5.1.1 Take priority of highest QoS .................................6
5.1.2 Take highest priority ........................................7
5.1.3 Force error on heterogeneous merge ...........................7
5.2 Modifying Priority Elements ...................................7
6 Error Processing .................................................8
7 IANA Considerations ..............................................8
8 Security Considerations ..........................................8
9 References .......................................................9
10 Author's Address ...............................................9
Appendix A: Example ...............................................10
A.1 Computing Merged Priority ....................................10
A.2 Translation (Compression) of Priority Elements ...............11
Full Copyright Statement ..........................................12
1 Introduction
1导言
This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as [RSVP] and [COPS]).
本文档描述了一个抢占优先权策略元素，用于基于策略的信号许可协议（如[RSVP]和[COPS]）。
Traditional Capacity based Admission Control (CAC) indiscriminately admits new flows until capacity is exhausted (First Come First Admitted). Policy based Admission Control (PAC) on the other hand attempts to minimize the significance of order of arrival and use policy based admission criteria instead.
传统的基于容量的接纳控制（CAC）不分青红皂白地接纳新流量，直到容量耗尽（先到先得）。另一方面，基于策略的准入控制（PAC）试图最小化到达顺序的重要性，并使用基于策略的准入标准。
One of the more popular policy criteria is the rank of importance of a flow relative to the others competing for admission into a network node. Preemption Priority takes effect only when a set of flows attempting admission through a node represents overbooking of resources such that based on CAC some would have to be rejected. Preemption priority criteria help the node select the most important flows (highest priority) for admission, while rejecting the low priority ones.
更流行的策略标准之一是流相对于竞争进入网络节点的其他流的重要性等级。抢占优先级仅在一组试图通过节点进入的流表示资源超售时生效，这样基于CAC，一些流将不得不被拒绝。抢占优先级标准帮助节点选择最重要的流（最高优先级）进行接纳，同时拒绝低优先级流。
Network nodes which support preemption should consider priorities to preempt some previously admitted low-priority flows in order to make room for a newer, high-priority flow.
支持抢占的网络节点应该考虑优先级以抢占某些先前承认的低优先级流，以便为更新的、高优先级的流腾出空间。
This document describes the format and applicability of the preemption priority represented as a policy element in [RSVP-EXT].
本文档描述了[RSVP-EXT]中作为策略元素表示的抢占优先级的格式和适用性。
2 Scope and Applicability
2范围和适用性
The Framework document for policy-based admission control [RAP] describes the various components that participate in policy decision making (i.e., PDP, PEP and LDP). The emphasis of PREEMPTION_PRI elements is to be simple, stateless, and light-weight such that they could be implemented internally within a node's LDP (Local Decision Point).
基于策略的准入控制框架文件[RAP]描述了参与政策决策的各种组件（即PDP、PEP和LDP）。抢占优先元素的重点是简单、无状态和轻量级，以便它们可以在节点的LDP（本地决策点）内部实现。
Certain base assumptions are made in the usage model for PREEMPTION_PRI elements:
先占权要素的使用模型中做出了某些基本假设：
- They are created by PDPs
- 它们是由PDP创建的
In a model where PDPs control PEPs at the periphery of the policy domain (e.g., in border routers), PDPs reduce sets of relevant policy rules into a single priority criterion. This priority as expressed in the PREEMPTION_PRI element can then be communicated to downstream PEPs of the same policy domain, which have LDPs but no controlling PDP.
在PDP控制策略域外围（如边界路由器）的PEP的模型中，PDP将相关策略规则集简化为单个优先级标准。然后，可以将抢占优先级元素中表示的该优先级传送给相同策略域的下游PEP，其具有LDP但没有控制PDP。
- They can be processed by LDPs
- 它们可以由自民党处理
PREEMPTION_PRI elements are processed by LDPs of nodes that do not have a controlling PDP. LDPs may interpret these objects, forward them as is, or perform local merging to forward an equivalent merged PREEMPTION_PRI policy element. LDPs must follow the merging strategy that was encoded by PDPs in the PREEMPTION_PRI objects. (Clearly, a PDP, being a superset of LDP, may act as an LDP as well).
抢占优先级元素由没有控制PDP的节点的LDP处理。LDP可以解释这些对象，按原样转发它们，或者执行本地合并以转发等效的合并优先权策略元素。LDP必须遵循PDP在抢占优先级对象中编码的合并策略。（显然，PDP作为LDP的超集，也可以充当LDP）。
- They are enforced by PEPs
- 它们由政治公众人物执行
PREEMPTION_PRI elements interact with a node's traffic control module (and capacity admission control) to enforce priorities, and preempt previously admitted flows when the need arises.
抢占\u PRI元素与节点的流量控制模块（和容量许可控制）交互以强制执行优先级，并在需要时抢占先前许可的流。
3 Stateless Policy
3无国籍政策
Signaled Preemption Priority is stateless (does not require past history or external information to be interpreted). Therefore, when carried in COPS messages for the outsourcing of policy decisions, these objects are included as COPS Stateless Policy Data Decision objects (see [COPS, COPS-RSVP]).
信号抢占优先级是无状态的（不需要解释过去的历史或外部信息）。因此，当包含在用于外包策略决策的COPS消息中时，这些对象将作为COPS无状态策略数据决策对象包含（请参见[COPS，COPS-RSVP]）。
4 Policy Element Format
4政策要素格式
The format of Policy Data objects is defined in [RSVP-EXT]. A single Policy Data object may contain one or more policy elements, each representing a different (and perhaps orthogonal) policy.
策略数据对象的格式在[RSVP-EXT]中定义。单个策略数据对象可以包含一个或多个策略元素，每个元素表示不同的（可能是正交的）策略。
The format of preemption priority policy element is as follows:
抢占优先级策略元素的格式如下：
+-------------+-------------+-------------+-------------+
| Length (12) | P-Type = PREEMPTION_PRI |
+------+------+-------------+-------------+-------------+
| Flags | M. Strategy | Error Code | Reserved(0) |
+------+------+-------------+-------------+-------------+
| Preemption Priority | Defending Priority |
+------+------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| Length (12) | P-Type = PREEMPTION_PRI |
+------+------+-------------+-------------+-------------+
| Flags | M. Strategy | Error Code | Reserved(0) |
+------+------+-------------+-------------+-------------+
| Preemption Priority | Defending Priority |
+------+------+-------------+-------------+-------------+
Length: 16 bits Always 12. The overall length of the policy element, in bytes.
长度：16位总是12位。策略元素的总长度，以字节为单位。
P-Type: 16 bits PREEMPTION_PRI = 1
P-Type:16位抢占优先级=1
This value is registered with IANA, see Section 7.
该值在IANA注册，见第7节。
Flags: 8 bits Reserved (always 0).
标志：保留8位（始终为0）。
Merge Strategy: 8 bit 1 Take priority of highest QoS: recommended 2 Take highest priority: aggressive 3 Force Error on heterogeneous merge
合并策略：8位1具有最高QoS的优先级：建议2具有最高优先级：攻击性3强制异构合并出错
Reserved: 8 bits Error code: 8 bits 0 NO_ERROR Value used for regular PREEMPTION_PRI elements 1 PREEMPTION This previously admitted flow was preempted 2 HETEROGENEOUS This element encountered heterogeneous merge
保留：8位错误代码：8位0无错误值用于常规抢占\u PRI元素1抢占此先前允许的流被抢占2异类此元素遇到异类合并
Reserved: 8 bits Always 0.
保留：8位始终为0。
Preemption Priority: 16 bit (unsigned) The priority of the new flow compared with the defending priority of previously admitted flows. Higher values represent higher Priority.
抢占优先级：16位（无符号）新流的优先级与先前允许流的防御优先级相比。值越高表示优先级越高。
Defending Priority: 16 bits (unsigned) Once a flow was admitted, the preemption priority becomes irrelevant. Instead, its defending priority is used to compare with the preemption priority of new flows.
防御优先级：16位（无符号）一旦允许流，抢占优先级就变得不相关。相反，它的防御优先级用于与新流的抢占优先级进行比较。
For any specific flow, its preemption priority must always be less than or equal to the defending priority. A wide gap between preemption and defending priority provides added stability: moderate preemption priority makes it harder for a flow to preempt others, but once it succeeded, the higher defending priority makes it easier for the flow to avoid preemption itself. This provides a mechanism for balancing between order dependency and priority.
对于任何特定流，其抢占优先级必须始终小于或等于防御优先级。抢占和防御优先级之间的巨大差距提供了额外的稳定性：适度的抢占优先级使流更难抢占其他流，但一旦成功，较高的防御优先级使流更容易避免抢占本身。这提供了一种平衡顺序依赖性和优先级的机制。
5 Priority Merging Issues
5优先合并问题
Consider the case where two RSVP reservations merge:
考虑两个RSVP保留合并的情况：
F1: QoS=High, Priority=Low
F2: QoS=Low, Priority=High
F1: QoS=High, Priority=Low
F2: QoS=Low, Priority=High
F1+F2= F3: QoS=High, Priority=???
F1+F2= F3: QoS=High, Priority=???
The merged reservation F3 should have QoS=Hi, but what Priority should it assume? Several negative side-effects have been identified that may affect such a merger:
合并的预订F3应该具有QoS=Hi，但它应该具有什么优先级？已经确定了可能影响此类合并的几个负面副作用：
Free-Riders:
免费搭车者：
If F3 assumes Priority=High, then F1 got a free ride, assuming high priority that was only intended to the low QoS F2. If one associates costs as a function of QoS and priority, F1 receives an "expensive" priority without having to "pay" for it.
如果F3假定优先级=高，则F1获得免费乘坐，假定高优先级仅用于低QoS F2。如果将成本与QoS和优先级联系起来，F1将获得“昂贵”的优先级，而无需为此“付费”。
Denial of Service:
拒绝服务：
If F3 assumes Priority=Low, the merged flow could be preempted or fail even though F2 presented high priority.
如果F3假设优先级=低，则合并流可能被抢占或失败，即使F2呈现高优先级。
Denial of service is virtually the inverse of the free-rider problem. When flows compete for resources, if one flow receives undeserving high priority it may be able to preempt another deserving flow (hence one free-rider turns out to be another's denial of service).
拒绝服务实际上与搭便车问题相反。当流竞争资源时，如果一个流接收到不值得的高优先级，它可能能够抢占另一个值得的流（因此一个搭便车者变成了另一个的拒绝服务）。
Instability:
不稳定性：
The combination of preemption priority, killer reservation and blockade state [RSVP] may increase the instability of admitted flows where a reservation may be preempted, reinstated, and preempted again periodically.
抢占优先级、killer reservation和阻塞状态[RSVP]的组合可能会增加已接纳流的不稳定性，其中可周期性地抢占、恢复和再次抢占保留。
In merging situations LDPs may receive multiple preemption elements and must compute the priority of the merged flow according to the following rules:
在合并情况下，LDP可能接收多个抢占元素，并且必须根据以下规则计算合并流的优先级：
a. Preemption priority and defending priority are merged and computed separately, irrespective of each other.
a. 抢占优先级和防御优先级被合并并分别计算，而不考虑彼此。
b. Participating priority elements are selected.
b. 选择参与的优先元素。
All priority elements are examined according to their merging strategy to decide whether they should participate in the merged result (as specified bellow).
根据合并策略检查所有优先级元素，以决定它们是否应参与合并结果（如下所述）。
c. The highest priority of all participating priority elements is computed.
c. 计算所有参与优先级元素的最高优先级。
The remainder of this section describes the different merging strategies the can be specified in the PREEMPTION_PRI element.
本节的其余部分描述了可以在PREEMPTION_PRI元素中指定的不同合并策略。
The PREEMPTION_PRI element would participate in the merged reservation only if it belongs to a flow that contributed to the merged QoS level (i.e., that its QoS requirement does not constitute a subset another reservation.) A simple way to determine whether a flow contributed to the merged QoS result is to compute the merged QoS with and without it and to compare the results (although this is clearly not the most efficient method).
只有当抢占元素属于有助于合并QoS级别的流（即，其QoS要求不构成另一个保留的子集）时，抢占元素才会参与合并保留确定流是否对合并的QoS结果有贡献的一种简单方法是计算合并的QoS（有或没有），并比较结果（尽管这显然不是最有效的方法）。
The reasoning for this approach is that the highest QoS flow is the one dominating the merged reservation and as such its priority should dominate it as well. This approach is the most amiable to the prevention of priority distortions such as free-riders and denial of service.
这种方法的理由是，最高的QoS流控制合并保留，因此其优先级也应控制合并保留。这种方法最有利于防止优先权扭曲，如搭便车和拒绝服务。
This is a recommended merging strategy.
这是推荐的合并策略。
All PREEMPTION_PRI elements participate in the merged reservation.
所有优先权元素都参与合并保留。
This strategy disassociates priority and QoS level, and therefore is highly subject to free-riders and its inverse image, denial of service.
该策略将优先级和QoS级别分离，因此极易受到搭便车者及其反面形象拒绝服务的影响。
This is not a recommended method, but may be simpler to implement.
这不是推荐的方法，但可能更易于实现。
A PREEMPTION_PRI element may participate in a merged reservation only if all other flows in the merged reservation have the same QoS level (homogeneous flows).
只有当合并保留中的所有其他流具有相同的QoS级别（同质流）时，抢占优先级元素才能参与合并保留。
The reasoning for this approach assumes that the heterogeneous case is relatively rare and too complicated to deal with, thus it better be prohibited.
这种方法的理由是假设异构案例相对较少且过于复杂，无法处理，因此最好将其禁止。
This strategy lends itself to denial of service, when a single receiver specifying a non-compatible QoS level may cause denial of service for all other receivers of the merged reservation.
当指定不兼容的QoS级别的单个接收器可能会导致对合并保留的所有其他接收器的拒绝服务时，此策略有助于拒绝服务。
Note: The determination of heterogeneous flows applies to QoS level only (FLOWSPEC values), and is a matter for local (LDP) definition. Other types of heterogeneous reservations (e.g., conflicting reservation styles) are handled by RSVP and are unrelated to this PREEMPTION_PRI element.
注：异类流的确定仅适用于QoS级别（FLOWSPEC值），并由本地（LDP）定义。其他类型的异构保留（例如，冲突保留样式）由RSVP处理，并且与此抢占优先元素无关。
This is a recommended merging strategy when reservation homogeneity is coordinated and enforced for the entire multicast tree. It is more restrictive than Section 5.1.1, but is easier to implement.
当为整个多播树协调和实施保留同质性时，这是推荐的合并策略。它比第5.1.1节更具限制性，但更易于实施。
When POLICY_DATA objects are protected by integrity, LDPs should not attempt to modify them. They must be forwarded as-is or else their security envelope would be invalidated. In other cases, LDPs may modify and merge incoming PREEMPTION_PRI elements to reduce their size and number according to the following rule:
当策略_数据对象受完整性保护时，LDP不应尝试修改它们。它们必须按原样转发，否则其安全信封将失效。在其他情况下，LDP可根据以下规则修改和合并传入抢占优先级元素，以减小其大小和数量：
Merging is performed for each merging strategy separately.
对每个合并策略分别执行合并。
There is no known algorithm to merge PREEMPTION_PRI element of different merging strategies without loosing valuable information that may affect OTHER nodes.
没有已知的算法可以在不丢失可能影响其他节点的有价值信息的情况下合并不同合并策略的抢占优先元素。
- For each merging strategy, the highest QoS of all participating PREEMPTION_PRI elements is taken and is placed in an outgoing PREEMPTION_PRI element of this merging strategy.
- 对于每个合并策略，采用所有参与抢占优先级元素中的最高QoS，并将其置于该合并策略的传出抢占优先级元素中。
- This approach effectively compresses the number of forwarded PREEMPTION_PRI elements to at most to the number of different merging strategies, regardless of the number of receivers (See the example in Appendix A.2).
- 这种方法有效地将转发抢占元素的数量压缩到最多不同合并策略的数量，而不考虑接收器的数量（参见附录A.2中的示例）。
6 Error Processing
6错误处理
A PREEMPTION_PRI error object is sent back toward the appropriate receivers when an error involving PREEMPTION_PRI elements occur.
当发生涉及抢占优先级元素的错误时，抢占优先级错误对象被发送回相应的接收器。
PREEMPTION
先发制人
When a previously admitted flow is preempted, a copy of the preempting flow's PREEMPTION_PRI element is sent back toward the PDP that originated the preempted PREEMPTION_PRI object. This PDP, having information on both the preempting and the preempted priorities may construct a higher priority PREEMPTION_PRI element in an effort to re-instate the preempted flow.
当先前允许的流被抢占时，抢占流的抢占优先级元素的副本被发送回发起抢占优先级对象的PDP。该PDP具有关于抢占和抢占优先级的信息，可以构造更高优先级的抢占优先级元素，以努力恢复抢占流。
Heterogeneity
异质性
When a flow F1 with Heterogeneous Error merging strategy set in its PREEMPTION_PRI element encounters heterogeneity the PREEMPTION_PRI element is sent back toward receivers with the Heterogeneity error code set.
当在其抢占优先级元素中设置了异构错误合并策略的流F1遇到异构时，抢占优先级元素被发送回具有异构错误代码集的接收器。
7 IANA Considerations
7 IANA考虑因素
Following the policies outlined in [IANA-CONSIDERATIONS], Standard RSVP Policy Elements (P-type values) are assigned by IETF Consensus action as described in [RSVP-EXT].
按照[IANA-注意事项]中概述的政策，标准RSVP政策元素（P型值）由IETF协商一致行动分配，如[RSVP-EXT]中所述。
P-Type PREEMPTION_PRI is assigned the value 1.
P型抢占_PRI的值为1。
8 Security Considerations
8安全考虑
The integrity of PREEMPTION_PRI is guaranteed, as any other policy element, by the encapsulation into a Policy Data object [RSVP-EXT].
与任何其他策略元素一样，通过封装到策略数据对象[RSVP-EXT]中，可以保证抢占优先级的完整性。
Further security mechanisms are not warranted, especially considering that preemption priority aims to provide simple and quick guidance to routers within a trusted zone or at least a single zone (no zone boundaries are crossed).
进一步的安全机制是不必要的，特别是考虑到抢占优先权旨在为受信任区域或至少单个区域内的路由器提供简单而快速的指导（不跨越区域边界）。
9 References
9参考文献
[RFC2751] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 2751, January 2000.
[RFC2751]Herzog，S.，“信号抢占优先权政策要素”，RFC 2751，2000年1月。
[RSVP-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RSVP-EXT]Herzog，S.，“用于政策控制的RSVP扩展”，RFC 2750，2000年1月。
[COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[COPS-RSVP]Boyle，J.，Cohen，R.，Durham，D.，Herzog，S.，Raja，R.和A.Sastry，“RSVP的COPS用法”，RFC 2749，2000年1月。
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy Based Admission Control", RFC 2753, January 2000.
[RAP]Yavatkar，R.，Pendarakis，D.和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月。
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[COPS]Boyle，J.，Cohen，R.，Durham，D.，Herzog，S.，Raja，R.和A.Sastry，“COPS（公共开放政策服务）协议”，RFC 2748，2000年1月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Specification", RFC 2205, September 1997.
[RSVP]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）-功能规范”，RFC 22052997年9月。
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA注意事项]Alvestrand，H.和T.Narten，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
10 Author's Address
10作者地址
Shai Herzog PolicyConsulting.Com 200 Clove Rd. New Rochelle, NY 10801
Shai Herzog Policy Consulting.Com纽约州新罗谢尔市丁香路200号，邮编10801
EMail: herzog@policyconsulting.com
EMail: herzog@policyconsulting.com
Appendix A: Example
附录A：示例
The following examples describe the computation of merged priority elements as well as the translation (compression) of PREEMPTION_PRI elements.
以下示例描述合并优先级元素的计算以及抢占优先级元素的转换（压缩）。
r1
/ QoS=Hi (Pr=3, St=Highest QoS)
/
s1-----A---------B--------r2 QoS=Low (Pr=4, St=Highest PP)
\ \
\ \ QoS=Low (Pr=7, St=Highest QoS)
r4 r3
r1
/ QoS=Hi (Pr=3, St=Highest QoS)
/
s1-----A---------B--------r2 QoS=Low (Pr=4, St=Highest PP)
\ \
\ \ QoS=Low (Pr=7, St=Highest QoS)
r4 r3
QoS=Low (Pr=9, St=Error)
QoS=Low (Pr=9, St=Error)
Example 1: Merging preemption priority elements
示例1：合并抢占优先权元素
Example one describes a multicast scenario with one sender and four receivers each with each own PREEMPTION_PRI element definition.
示例一描述了一个多播场景，其中一个发送方和四个接收方各有自己的抢占优先级元素定义。
r1, r2 and r3 merge in B. The resulting priority is 4.
r1、r2和r3在B中合并。结果优先级为4。
Reason: The PREEMPTION_PRI of r3 doesn't participate (since r3 is not contributing to the merged QoS) and the priority is the highest of the PREEMPTION_PRI from r1 and r2.
原因：r3的抢占优先级不参与（因为r3不参与合并的QoS），并且优先级是r1和r2的抢占优先级中的最高值。
r1, r2, r3 and r4 merge in A. The resulting priority is again 4: r4 doesn't participate because its own QoS=Low is incompatible with the other (r1) QoS=High. An error PREEMPTION_PRI should be sent back to r4 telling it that its PREEMPTION_PRI element encountered heterogeneity.
r1、r2、r3和r4在A中合并。产生的优先级再次为4：r4不参与，因为其自身的QoS=低与另一（r1）QoS=高不兼容。应将错误抢占\u PRI发送回r4，告知其抢占\u PRI元素遇到异构性。
Given this set of participating PREEMPTION_PRI elements, the following compression can take place at the merging node:
给定这组参与抢占的元素，可以在合并节点进行以下压缩：
From:
(Pr=3, St=Highest QoS)
(Pr=7, St=Highest QoS)
(Pr=4, St=Highest PP)
(Pr=9, St=Highest PP)
(Pr=6, St=Highest PP)
To:
(Pr=7, St=Highest QoS)
(Pr=9, St=Highest PP)
From:
(Pr=3, St=Highest QoS)
(Pr=7, St=Highest QoS)
(Pr=4, St=Highest PP)
(Pr=9, St=Highest PP)
(Pr=6, St=Highest PP)
To:
(Pr=7, St=Highest QoS)
(Pr=9, St=Highest PP)
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。