Internet Engineering Task Force (IETF) F. Le Faucheur
Request for Comments: 6401 J. Polk
Category: Standards Track Cisco
ISSN: 2070-1721 K. Carlberg
G11
October 2011
Internet Engineering Task Force (IETF) F. Le Faucheur
Request for Comments: 6401 J. Polk
Category: Standards Track Cisco
ISSN: 2070-1721 K. Carlberg
G11
October 2011
RSVP Extensions for Admission Priority
接纳优先权的RSVP扩展
Abstract
摘要
Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. When supported over the Internet Protocol suite, this may be facilitated through a network-layer admission control solution that supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer.
一些应用程序需要能够在网络拥塞时为特定会话提供更高的会话建立概率。当通过互联网协议套件得到支持时，这可以通过支持优先访问资源（例如带宽）的网络层准入控制解决方案来实现。这些资源可以明确地预留给优先会话，也可以与其他会话共享。本文档指定了资源预留协议（RSVP）的扩展，可用于在网络层支持此类准入优先级功能。
Based on current security concerns, these extensions are intended for use in a single administrative domain.
基于当前的安全问题，这些扩展旨在用于单个管理域。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6401.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6401.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件的出版。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Overview of RSVP Extensions and Operations . . . . . . . . . . 4
4.1. Operations of Admission Priority . . . . . . . . . . . . . 6
5. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 7
5.1. Admission Priority Policy Element . . . . . . . . . . . . 8
5.1.1. Admission Priority Merging Rules . . . . . . . . . . . 9
5.2. Application-Level Resource Priority Policy Element . . . . 10
5.2.1. Application-Level Resource Priority Modifying and
Merging Rules . . . . . . . . . . . . . . . . . . . . 11
5.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Use of RSVP Authentication between RSVP Neighbors . . . . 13
6.2. Use of INTEGRITY object within the POLICY_DATA Object . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Examples of Bandwidth Allocation Model for
Admission Priority . . . . . . . . . . . . . . . . . 19
A.1. Admission Priority with Maximum Allocation Model (MAM) . . 19
A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 23
A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 26
Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Overview of RSVP Extensions and Operations . . . . . . . . . . 4
4.1. Operations of Admission Priority . . . . . . . . . . . . . 6
5. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 7
5.1. Admission Priority Policy Element . . . . . . . . . . . . 8
5.1.1. Admission Priority Merging Rules . . . . . . . . . . . 9
5.2. Application-Level Resource Priority Policy Element . . . . 10
5.2.1. Application-Level Resource Priority Modifying and
Merging Rules . . . . . . . . . . . . . . . . . . . . 11
5.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Use of RSVP Authentication between RSVP Neighbors . . . . 13
6.2. Use of INTEGRITY object within the POLICY_DATA Object . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Examples of Bandwidth Allocation Model for
Admission Priority . . . . . . . . . . . . . . . . . 19
A.1. Admission Priority with Maximum Allocation Model (MAM) . . 19
A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 23
A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 26
Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 29
Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion.
一些应用程序需要能够在网络拥塞时为特定会话提供更高的会话建立概率。
Solutions to meet this requirement for elevated session establishment probability may involve session-layer capabilities prioritizing access to resources controlled by the session control function. As an example, entities involved in session control (such as SIP user agents, when the Session Initiation Protocol (SIP) [RFC3261], is the session control protocol in use) can influence their treatment of session establishment requests (such as SIP requests). This may include the ability to "queue" session establishment requests when those can not be immediately honored (in some cases with the notion of "bumping", or "displacement", of less important session establishment requests from that queue). It may include additional mechanisms such as alternate routing and exemption from certain network management controls.
满足提高会话建立概率要求的解决方案可能涉及会话层功能，对会话控制功能控制的资源的访问进行优先级排序。例如，会话控制中涉及的实体（例如，当会话发起协议（SIP）[rfc326]是正在使用的会话控制协议时，SIP用户代理）可以影响它们对会话建立请求（例如SIP请求）的处理。这可能包括在无法立即满足会话建立请求时“排队”会话建立请求的能力（在某些情况下，对来自该队列的不太重要的会话建立请求采用“碰撞”或“置换”的概念）。它可能包括额外的机制，例如备用路由和免除某些网络管理控制。
Solutions to meet the requirement for elevated session establishment probability may also take advantage of network-layer admission control mechanisms supporting admission priority. Networks usually have engineered capacity limits that characterize the maximum load that can be handled (say, on any given link) for a class of traffic while satisfying the quality-of-service (QoS) requirements of that traffic class. Admission priority may involve setting aside some network resources (e.g., bandwidth) out of the engineered capacity limits for the prioritized sessions only. Or alternatively, it may involve allowing the prioritized sessions to seize additional resources beyond the engineered capacity limits applied to normal sessions. This document specifies the necessary extensions to support such admission priority when network-layer admission control is performed using the Resource reSerVation Protocol (RSVP) [RFC2205].
满足提高会话建立概率要求的解决方案还可以利用支持接纳优先级的网络层接纳控制机制。网络通常具有工程化的容量限制，其特征是在满足某一类流量的服务质量（QoS）要求的同时，可以为该类流量处理（例如，在任何给定链路上）的最大负载。准入优先级可能涉及在工程容量限制之外留出一些网络资源（例如，带宽），仅用于优先会话。或者，它可能涉及允许优先会话占用超出应用于正常会话的工程容量限制的额外资源。本文件规定了当使用资源预留协议（RSVP）[RFC2205]执行网络层许可控制时，支持此类许可优先级的必要扩展。
[RFC3181] specifies the Signaled Preemption Priority Policy Element that can be signaled in RSVP so that network node may take into account this policy element in order to preempt some previously admitted low-priority sessions in order to make room for a newer, higher-priority session. In contrast, this document specifies new RSVP extensions to increase the probability of session establishment without preemption of existing sessions. This is achieved by engineered capacity techniques in the form of bandwidth allocation models. In particular, this document specifies two new RSVP policy elements allowing the admission priority to be conveyed inside RSVP signaling messages so that RSVP nodes can enforce a selective bandwidth admission control decision based on the session admission
[RFC3181]指定可在RSVP中发送信号的已发送信号的抢占优先级策略元素，以便网络节点可以考虑该策略元素，以便抢占一些先前允许的低优先级会话，以便为更新的、高优先级会话腾出空间。相反，本文档指定了新的RSVP扩展，以增加会话建立的可能性，而不抢占现有会话。这是通过带宽分配模型形式的工程容量技术实现的。特别地，本文档指定了两个新的RSVP策略元素，允许在RSVP信令消息内传送接纳优先级，以便RSVP节点可以基于会话接纳实施选择性带宽接纳控制决策
priority. Appendix A of this document also provides examples of bandwidth allocation models that can be used by RSVP-routers to enforce such admission priority on every link. A given reservation may be signaled with the admission priority extensions specified in the present document, with the preemption priority specified in [RFC3181], or with both.
优先事项本文档的附录A还提供了RSVP路由器可用于在每个链路上强制执行此类准入优先级的带宽分配模型示例。给定的保留可以用本文档中指定的许可优先级扩展、用[RFC3181]中指定的抢占优先级或两者来通知。
This document assumes the terminology defined in [RFC2753]. For convenience, the definitions of a few key terms are repeated here:
本文件采用[RFC2753]中定义的术语。为方便起见，此处重复了几个关键术语的定义：
o Policy Decision Point (PDP): The point where policy decisions are made.
o 政策决策点（PDP）：作出政策决策的点。
o Local Policy Decision Point (LPDP): The PDP local to the network element.
o 本地策略决策点（LPDP）：网元本地的PDP。
o Policy Enforcement Point (PEP): The point where the policy decisions are actually enforced.
o 策略执行点（PEP）：实际执行策略决策的点。
o Policy Ignorant Node (PIN): A network element that does not explicitly support policy control using the mechanisms defined in [RFC2753].
o 策略无知节点（PIN）：不使用[RFC2753]中定义的机制显式支持策略控制的网元。
A subset of RSVP messages are signaled with the Router Alert Option (RAO) ([RFC2113], [RFC2711]). The security aspects and common practices around the use of the current IP Router Alert Option and consequences on the use of IP Router Alert by applications such as RSVP are discussed in [RFC6398]. Based on those, the extensions defined in this document are intended for use within a single administrative domain. Thus, in particular, the extensions defined in this document are not intended for end-to-end use on the Internet.
RSVP消息的子集通过路由器警报选项（RAO）（[RFC2113]、[RFC2711]）发出信号。[RFC6398]中讨论了使用当前IP路由器警报选项的安全方面和常见做法，以及RSVP等应用程序使用IP路由器警报的后果。基于这些，本文档中定义的扩展旨在在单个管理域中使用。因此，本文件中定义的扩展尤其不适用于互联网上的端到端使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Let us consider the case where a session requires elevated probability of establishment, and more specifically that the preference to be granted to this session is in terms of network-layer "admission priority" (as opposed to preference granted through
让我们考虑一个会话需要提高建立概率的情况，更具体地说，要授予这个会话的偏好是根据网络层“准入优先权”（而不是通过授予的优先权）。
preemption of existing sessions). By "admission priority" we mean allowing the priority session to seize network-layer resources from the engineered capacity that has been set aside for priority sessions (and not made available to normal sessions) or, alternatively, allowing the priority session to seize additional resources beyond the engineered capacity limits applied to normal sessions.
抢占现有会话）。“准入优先级”是指允许优先级会话从为优先级会话预留的（且未提供给正常会话的）工程容量中获取网络层资源，或者，允许优先级会话占用超出应用于正常会话的工程容量限制的额外资源。
Session establishment can be made conditional on resource-based and policy-based network-layer admission control achieved via RSVP signaling. In the case where the session control protocol is SIP, the use of RSVP-based admission control in conjunction with SIP is specified in [RFC3312].
会话建立可以基于通过RSVP信令实现的基于资源和基于策略的网络层准入控制。在会话控制协议为SIP的情况下，在[RFC3312]中规定了结合SIP使用基于RSVP的接纳控制。
Devices involved in the session establishment are expected to be aware of the application-level priority requirements of prioritized sessions. For example, considering the case where the session control protocol is SIP, the SIP user agents may be made aware of the resource priority requirements of a given session using the "Resource-Priority" header mechanism specified in [RFC4412]. The end-devices involved in the upper-layer session establishment simply need to copy the application-level resource priority requirements (e.g., as communicated in the SIP "Resource-Priority" header) inside the new RSVP Application-Level Resource Priority Policy Element defined in this document.
会话建立中涉及的设备预计会了解优先级会话的应用程序级优先级要求。例如，考虑会话控制协议是SIP的情况，可以使用[RFC4412]中指定的“资源优先级”报头机制使SIP用户代理知道给定会话的资源优先级要求。上层会话建立中涉及的终端设备只需在本文档中定义的新RSVP应用级资源优先级策略元素内复制应用级资源优先级要求（例如，在SIP“资源优先级”报头中传达）。
Conveying the application-level resource priority requirements inside the RSVP message allows this application-level requirement to be mapped/remapped into a different RSVP "admission priority" at a policy boundary based on the policy applicable in that policy area. In a typical model (see [RFC2753]) where PDPs control PEPs at the periphery of the policy area (e.g., on the first hop router), PDPs would interpret the RSVP Application-Level Resource Priority Policy Element and map the requirement of the prioritized session into an RSVP "admission priority" level. Then, PDPs would convey this information inside the new Admission Priority Policy Element defined in this document. This way, the RSVP admission priority can be communicated to downstream PEPs (i.e., RSVP routers) of the same policy domain that have LPDPs but no controlling PDP. In turn, this means the necessary RSVP Admission priority can be enforced at every RSVP hop, including all the (possibly many) hops that do not have any understanding of application-level resource priority semantics. It is not expected that the RSVP Application-Level Resource Priority Header Policy Element would be taken into account at RSVP hops within a given policy area. It is expected to be used at policy area boundaries only in order to set/reset the RSVP Admission Priority Policy Element.
通过在RSVP消息内传递应用程序级资源优先级要求，可以基于该策略区域中适用的策略，将该应用程序级需求映射/重新映射到策略边界处的不同RSVP“准入优先级”。在一个典型模型（参见[RFC2753]）中，PDP控制策略区域外围（例如，在第一跳路由器上）的PEP，PDP将解释RSVP应用程序级资源优先级策略元素，并将优先会话的需求映射到RSVP“准入优先级”级别。然后，PDP将在本文档中定义的新准入优先级策略元素中传递此信息。这样，可以将RSVP接纳优先级传送到具有lpdp但没有控制PDP的相同策略域的下游pep（即，RSVP路由器）。反过来，这意味着可以在每个RSVP跃点强制执行必要的RSVP接纳优先级，包括所有（可能很多）不了解应用程序级资源优先级语义的跃点。在给定策略区域内的RSVP跃点处，预计不会考虑RSVP应用程序级资源优先级标头策略元素。预计仅在策略区域边界处使用，以设置/重置RSVP准入优先级策略元素。
Remapping by PDPs of the Admission Priority Policy Element from the Application-Level Resource Priority Policy Element may also be used at boundaries with other signaling protocols, such as the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling [RFC5974].
pdp从应用级资源优先级策略元素重新映射接纳优先级策略元素也可以在与其他信令协议的边界处使用，例如用于QoS信令的NSIS信令层协议（NSLP）[RFC5974]。
As can be observed, the framework described above for mapping/ remapping application-level resource priority requirements into an RSVP admission priority can also be used together with [RFC3181] for mapping/remapping application-level resource priority requirements into an RSVP preemption priority (when preemption is indeed deemed necessary by the prioritized session handling policy). In that case, when processing the RSVP Application-Level Resource Priority Policy Element, the PDPs at policy boundaries (or between various QoS signaling protocols) can map it into an RSVP "preemption priority" information. This preemption priority information comprises a setup preemption level and a defending preemption priority level that can then be encoded inside the Preemption Priority Policy Element of [RFC3181].
可以观察到，上述用于将应用级资源优先级要求映射/重新映射为RSVP许可优先级的框架也可以与[RFC3181]一起用于将应用级资源优先级要求映射/重新映射为RSVP抢占优先级（当优先会话处理策略确实认为需要抢占时）。在这种情况下，当处理RSVP应用程序级资源优先级策略元素时，策略边界处（或各种QoS信令协议之间）的PDP可以将其映射为RSVP“抢占优先级”信息。此抢占优先级信息包括设置抢占级别和防御抢占优先级，然后可在[RFC3181]的抢占优先级策略元素中进行编码。
Appendix B provides examples of various hypothetical policies for prioritized session handling, some of them involving admission priority, some of them involving both admission priority and preemption priority. Appendix B also identifies how the application-level resource priority needs to be mapped into RSVP policy elements by the PDPs to realize these policies.
附录B提供了用于优先会话处理的各种假设策略的示例，其中一些涉及准入优先级，一些涉及准入优先级和抢占优先级。附录B还确定了PDP需要如何将应用程序级资源优先级映射到RSVP策略元素，以实现这些策略。
The RSVP Admission Priority Policy Element defined in this document allows admission bandwidth to be allocated preferentially to prioritized sessions. Multiple models of bandwidth allocation MAY be used to that end.
本文档中定义的RSVP准入优先级策略元素允许优先将准入带宽分配给优先会话。为此，可以使用多种带宽分配模型。
A number of bandwidth allocation models have been defined in the IETF for allocation of bandwidth across different classes of traffic trunks in the context of Diffserv-aware MPLS Traffic Engineering. Those include the Maximum Allocation Model (MAM) defined in [RFC4125], the Russian Dolls Model (RDM) specified in [RFC4127], and the Maximum Allocation model with Reservation (MAR) defined in [RFC4126]. However, these same models MAY be applied for allocation of bandwidth across different levels of admission priority as defined in this document. Appendix A provides an illustration of how these bandwidth allocation models can be applied for such purposes and also introduces an additional bandwidth allocation model that we term the Priority Bypass Model (PrBM). It is important to note that the models described and illustrated in Appendix A are only informative and do not represent a recommended course of action.
IETF中定义了许多带宽分配模型，用于在区分服务感知MPLS流量工程的上下文中跨不同类别的流量中继分配带宽。这些包括[RFC4125]中定义的最大分配模型（MAM），[RFC4127]中指定的俄罗斯玩偶模型（RDM），以及[RFC4126]中定义的带保留的最大分配模型（MAR）。然而，这些相同的模型可用于在本文件中定义的不同接纳优先级级别上分配带宽。附录A说明了如何将这些带宽分配模型应用于此类目的，并介绍了我们称之为优先级旁路模型（PrBM）的额外带宽分配模型。需要注意的是，附录A中描述和说明的模型仅提供信息，并不代表建议的行动方案。
We can see in these examples how the RSVP Admission Priority can be used by RSVP routers to influence their admission control decision (for example, by determining which bandwidth pool is to be used by RSVP for performing its bandwidth allocation) and therefore to increase the probability of reservation establishment. In turn, this increases the probability of application-level session establishment for the corresponding session.
在这些示例中，我们可以看到RSVP路由器如何使用RSVP接纳优先级来影响其接纳控制决策（例如，通过确定RSVP将使用哪个带宽池来执行其带宽分配），从而增加预约建立的概率。反过来，这增加了相应会话的应用程序级会话建立的可能性。
The Framework document for policy-based admission control [RFC2753] describes the various components that participate in policy decision making (i.e., PDP, PEP, and LPDP).
基于策略的准入控制框架文件[RFC2753]描述了参与决策的各种组件（即PDP、PEP和LPDP）。
As described in Section 4 of the present document, the Application-Level Resource Priority Policy Element and the Admission Priority Policy Element serve different roles in this framework:
如本文件第4节所述，应用程序级资源优先级策略元素和准入优先级策略元素在此框架中起着不同的作用：
o The Application-Level Resource Priority Policy Element conveys application-level information and is processed by PDPs.
o 应用程序级资源优先级策略元素传递应用程序级信息，并由PDP处理。
o The emphasis of Admission Priority Policy Element is to be simple, stateless, and lightweight such that it can be processed internally within a node's LPDP. It can then be enforced internally within a node's PEP. It is set by PDPs based on processing of the Application-Level Resource Priority Policy Element.
o 接纳优先级策略元素的重点是简单、无状态和轻量级，以便它可以在节点的LPDP内部处理。然后可以在节点的PEP内部强制执行。它由PDPs根据应用程序级资源优先级策略元素的处理进行设置。
[RFC2750] defines extensions for supporting generic policy-based admission control in RSVP. These extensions include the standard format of POLICY_DATA objects and a description of RSVP handling of policy events.
[RFC2750]定义了支持RSVP中基于通用策略的准入控制的扩展。这些扩展包括POLICY_数据对象的标准格式和对策略事件的RSVP处理的描述。
The POLICY_DATA object contains one or more policy elements, each representing a different (and perhaps orthogonal) policy. As an example, [RFC3181] specifies the Preemption Priority Policy Element. This document defines two new policy elements called:
POLICY_数据对象包含一个或多个POLICY元素，每个元素表示不同的（可能是正交的）策略。例如，[RFC3181]指定抢占优先级策略元素。本文档定义了两个新的策略元素，称为：
o the Admission Priority Policy Element
o 准入优先政策要素
o the Application-Level Resource Priority Policy Element
o 应用程序级资源优先级策略元素
The format of the Admission Priority Policy Element is as shown in Figure 1:
准入优先级策略元素的格式如图1所示：
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+
| Length | P-Type = ADMISSION_PRI |
+-------------+-------------+-------------+-------------+
| Flags | M. Strategy | Error Code | Reserved |
+-------------+-------------+-------------+-------------+
| Reserved |Adm. Priority|
+---------------------------+---------------------------+
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+
| Length | P-Type = ADMISSION_PRI |
+-------------+-------------+-------------+-------------+
| Flags | M. Strategy | Error Code | Reserved |
+-------------+-------------+-------------+-------------+
| Reserved |Adm. Priority|
+---------------------------+---------------------------+
Figure 1: Admission Priority Policy Element
图1：准入优先级策略元素
where:
哪里：
o Length: 16 bits
o 长度：16位
* Always 12. The overall length of the policy element, in bytes.
* 总是12岁。策略元素的总长度，以字节为单位。
o P-Type: 16 bits
o P型：16位
* ADMISSION_PRI = 0x05 (see the "IANA Considerations" section).
* 入院率=0x05（参见“IANA注意事项”一节）。
o Flags: Reserved
o 旗帜：保留
* SHALL be set to zero on transmit and SHALL be ignored on reception.
* 传输时应设置为零，接收时应忽略。
o Merge Strategy: 8 bits (applicable to multicast flows)
o 合并策略：8位（适用于多播流）
* values are defined in the corresponding registry maintained by IANA (see the "IANA Considerations" section).
* 值在IANA维护的相应注册表中定义（请参阅“IANA注意事项”部分）。
o Error code: 8 bits (applicable to multicast flows)
o 错误代码：8位（适用于多播流）
* values are defined in the corresponding registry maintained by IANA (see the "IANA Considerations" section).
* 值在IANA维护的相应注册表中定义（请参阅“IANA注意事项”部分）。
o Reserved: 8 bits
o 保留：8位
* SHALL be set to zero on transmit and SHALL be ignored on reception.
* 传输时应设置为零，接收时应忽略。
o Reserved: 24 bits
o 保留：24位
* SHALL be set to zero on transmit and SHALL be ignored on reception
* 传输时应设置为零，接收时应忽略
o Adm. Priority (Admission Priority): 8 bits (unsigned)
o 行政优先级（准入优先级）：8位（无符号）
* The admission control priority of the flow, in terms of access to network bandwidth in order to provide higher probability of session completion to selected flows. Higher values represent higher priority. Bandwidth allocation models such as those described in Appendix A are to be used by the RSVP router to achieve increased probability of session establishment. The admission priority value effectively indicates which bandwidth constraint(s) of the bandwidth constraint model in use is/are applicable to admission of this RSVP reservation.
* 在访问网络带宽方面，流的准入控制优先级，以便为所选流提供更高的会话完成概率。值越高表示优先级越高。RSVP路由器将使用附录A中所述的带宽分配模型，以提高会话建立的概率。接纳优先级值有效地指示正在使用的带宽约束模型的哪些带宽约束适用于接纳该RSVP预留。
Note that the Admission Priority Policy Element does NOT indicate that this RSVP reservation is to preempt any other RSVP reservation. If a priority session justifies both admission priority and preemption priority, the corresponding RSVP reservation needs to carry both an Admission Priority Policy Element and a Preemption Priority Policy Element. The Admission Priority and Preemption Priority are handled by LPDPs and PEPs as separate mechanisms. They can be used one without the other, or they can be used both in combination.
请注意，准入优先级策略元素并不表示此RSVP保留将优先于任何其他RSVP保留。如果优先级会话同时证明了接纳优先级和抢占优先级，则相应的RSVP保留需要同时携带接纳优先级策略元素和抢占优先级策略元素。接纳优先级和抢占优先级由LPDPs和PEP作为单独的机制处理。它们可以一个不使用另一个，也可以两者结合使用。
This section discusses alternatives for dealing with RSVP admission priority in case of merging of reservations. As merging applies to multicast, this section also applies to multicast sessions.
本节讨论在保留合并的情况下处理RSVP准入优先级的备选方案。由于合并适用于多播，因此本节也适用于多播会话。
The rules for merging Admission Priority Policy Elements are defined by the value encoded inside the Merge Strategy field in accordance with the corresponding IANA registry. This registry applies both to the Merge Strategy field of the Admission Priority Policy Element defined in the present document and to the Merge Strategy field of the Preemption Priority Policy Element defined in [RFC3181]. The registry initially contains the values already defined in [RFC3181] (see the "IANA Considerations" section).
合并准入优先级策略元素的规则由合并策略字段中编码的值根据相应的IANA注册表定义。此注册表既适用于本文档中定义的准入优先级策略元素的合并策略字段，也适用于[RFC3181]中定义的抢占优先级策略元素的合并策略字段。注册表最初包含[RFC3181]中已定义的值（请参阅“IANA注意事项”部分）。
The only difference from [RFC3181] is that this document does not recommend a given merge strategy over the others for Admission Priority, while [RFC3181] recommends the first of these merge strategies for Preemption Priority. Note that with the Admission Priority (as is the case with the Preemption Priority), "take highest priority" translates into "take the highest numerical value".
与[RFC3181]的唯一区别在于，本文件不建议将给定的合并策略优先于其他合并策略，而[RFC3181]建议将这些合并策略中的第一个合并策略优先考虑。注意，对于接纳优先级（与抢占优先级一样），“获取最高优先级”转换为“获取最高数值”。
The format of the Application-Level Resource Priority Policy Element is as shown in Figure 2:
应用程序级资源优先级策略元素的格式如图2所示：
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+
| Length | P-Type = APP_RESOURCE_PRI |
+-------------+-------------+-------------+-------------+
// ALRP List //
+---------------------------+---------------------------+
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+
| Length | P-Type = APP_RESOURCE_PRI |
+-------------+-------------+-------------+-------------+
// ALRP List //
+---------------------------+---------------------------+
Figure 2: Application-Level Resource Priority Policy Element
图2：应用程序级资源优先级策略元素
where:
哪里：
o Length:
o 长度：
* The length of the policy element (including the Length and P-Type) is in number of octets (MUST be a multiple of 4) and indicates the end of the ALRP list.
* 策略元素的长度（包括长度和P类型）以八位字节为单位（必须是4的倍数），并指示ALRP列表的结尾。
o P-Type: 16 bits
o P型：16位
* APP_RESOURCE_PRI = 0x06 (see the "IANA Considerations" section).
* APP_RESOURCE_PRI=0x06（请参阅“IANA注意事项”部分）。
o ALRP List:
o ALRP列表：
* List of ALRPs where each ALRP is encoded as shown in Figure 3.
* 每个ALRP编码的ALRP列表，如图3所示。
ALRP:
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+---------------------------+-------------+-------------+
| ALRP Namespace | Reserved |ALRP Value |
+---------------------------+---------------------------+
ALRP:
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+---------------------------+-------------+-------------+
| ALRP Namespace | Reserved |ALRP Value |
+---------------------------+---------------------------+
Figure 3: Application-Level Resource Priority
图3：应用程序级资源优先级
where:
哪里：
o ALRP Namespace (Application-Level Resource Priority Namespace): 16 bits (unsigned)
o ALRP命名空间（应用程序级资源优先级命名空间）：16位（无符号）
* Contains a numerical value identifying the namespace of the application-level resource priority. This value is encoded as per the "Resource Priority Namespaces" IANA registry. (See the "IANA Considerations" section; IANA has extended the registry to include this numerical value).
* 包含标识应用程序级资源优先级的命名空间的数值。此值按照IANA注册表中的“资源优先级名称空间”进行编码。（请参阅“IANA注意事项”一节；IANA已将注册表扩展到包含该数值）。
o Reserved: 8 bits
o 保留：8位
* SHALL be set to zero on transmit and SHALL be ignored on reception.
* 传输时应设置为零，接收时应忽略。
o ALRP Value (Application-Level Resource Priority Value): 8 bits (unsigned)
o ALRP值（应用程序级资源优先级值）：8位（无符号）
* Contains the priority value within the namespace of the application-level resource priority. This value is encoded as per the "Resource Priority Priority-Value" IANA registry. (See the "IANA Considerations" section; IANA has extended the registry to include this numerical value).
* 包含应用程序级资源优先级的命名空间内的优先级值。该值按照IANA注册表中的“资源优先级值”进行编码。（请参阅“IANA注意事项”一节；IANA已将注册表扩展到包含该数值）。
When POLICY_DATA objects are protected by integrity, LPDPs should not attempt to modify them. They MUST be forwarded without modification to ensure their security envelope is not invalidated.
当策略_数据对象受完整性保护时，LPDP不应尝试修改它们。它们必须在未经修改的情况下转发，以确保其安全信封不会失效。
In case of multicast, when POLICY_DATA objects are not protected by integrity, LPDPs MAY merge incoming Application-Level Resource Priority Elements to reduce their size and number. When they do merge those elements, LPDPs MUST do so according to the following rule:
在多播的情况下，当策略_数据对象不受完整性保护时，lpdp可以合并传入的应用程序级资源优先级元素以减小其大小和数量。当它们合并这些元素时，LPDP必须根据以下规则进行合并：
o The ALRP List in the outgoing APP_RESOURCE_PRI element MUST contain all the ALRPs appearing in the ALRP List of an incoming APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than once. In other words, the outgoing ALRP List is the union of the incoming ALRP Lists that are merged.
o 传出APP_RESOURCE_PRI元素中的ALRP列表必须包含传入APP_RESOURCE_PRI元素的ALRP列表中出现的所有ALRP。给定的ALRP不得出现多次。换句话说，传出ALRP列表是合并的传入ALRP列表的并集。
As merging applies to multicast, this rule also applies to multicast sessions.
由于合并适用于多播，此规则也适用于多播会话。
As specified in Section 4.2 of [RFC2750], Policy Ignorant Nodes (PINs) implement a default handling of POLICY_DATA objects ensuring that those objects can traverse PINs in transit from one PEP to another. This applies to the situations where POLICY_DATA objects contain the Admission Priority Policy Element and the ALRP Policy Element specified in this document, so that those objects can traverse PINs.
如[RFC2750]第4.2节所述，策略无关节点（PIN）实现策略_数据对象的默认处理，确保这些对象可以在从一个PEP到另一个PEP的传输过程中遍历PIN。这适用于POLICY_数据对象包含本文档中指定的准入优先级策略元素和ALRP策略元素的情况，以便这些对象可以遍历管脚。
Section 4.2 of [RFC2750] also defines a similar default behavior for policy-capable nodes that do not recognize a particular policy element. This applies to the Admission Priority Policy Element and the ALRP Policy Element specified in this document, so that those elements can traverse policy-capable nodes that do not support these extensions defined in the present document.
[RFC2750]的第4.2节还为不识别特定策略元素的支持策略的节点定义了类似的默认行为。这适用于本文档中指定的准入优先级策略元素和ALRP策略元素，以便这些元素可以遍历不支持本文档中定义的这些扩展的支持策略的节点。
As this document defines extensions to RSVP, the security considerations of RSVP apply. Those are discussed in [RFC2205], [RFC4230], and [RFC6411]. Approaches for addressing those concerns are discussed further below.
由于本文档定义了RSVP的扩展，因此RSVP的安全注意事项适用。这些在[RFC2205]、[RFC4230]和[RFC6411]中讨论。下文将进一步讨论解决这些问题的方法。
A subset of RSVP messages are signaled with the Router Alert Option (RAO) ([RFC2113], [RFC2711]). The security aspects and common practices around the use of the current IP Router Alert Option and consequences on the use of IP Router Alert by applications such as RSVP are discussed in [RFC6398]. As discussed in Section 2, the extensions defined in this document are intended for use within a single administrative domain.
RSVP消息的子集通过路由器警报选项（RAO）（[RFC2113]、[RFC2711]）发出信号。[RFC6398]中讨论了使用当前IP路由器警报选项的安全方面和常见做法，以及RSVP等应用程序使用IP路由器警报的后果。如第2节所述，本文档中定义的扩展旨在在单个管理域中使用。
[RFC6398] discusses router alert protection approaches for service providers. These approaches can be used to protect a given network against the potential risks associated with the leaking of router alert packets resulting from the use of the present extensions in another domain. Also, where RSVP is not used, by simply not enabling RSVP on the routers of a given network, generally that network can isolate itself from any RSVP signaling that may leak from another network that uses the present extensions (since the routers will then typically ignore RSVP messages). Where RSVP is to be used internally within a given network, the network operator can activate, on the edge of his network, mechanisms that either tunnel or, as a last resort, drop incoming RSVP messages in order to protect the given network from RSVP signaling that may leak from another network that uses the present extensions.
[RFC6398]讨论服务提供商的路由器警报保护方法。这些方法可用于保护给定网络免受由于在另一个域中使用现有扩展而导致的路由器警报数据包泄漏的潜在风险。此外，在不使用RSVP的情况下，通过简单地不在给定网络的路由器上启用RSVP，通常该网络可以将自身与可能从使用当前扩展的另一网络泄漏的任何RSVP信令隔离（因为路由器随后通常会忽略RSVP消息）。在给定网络内部使用RSVP的情况下，网络运营商可以在其网络的边缘激活机制，这些机制要么通过隧道传输，要么作为最后手段丢弃传入的RSVP消息，以便保护给定网络免受RSVP信令的影响，RSVP信令可能会从使用当前扩展的另一个网络泄漏。
The ADMISSION_PRI and APP_RESOURCE_PRI Policy Elements defined in this document are signaled by RSVP through encapsulation in a POLICY_DATA object as defined in [RFC2750]. Therefore, like any other policy elements, their integrity can be protected as discussed in Section 6 of [RFC2750] by two optional security mechanisms. The first mechanism relies on RSVP authentication as specified in [RFC2747] and [RFC3097] to provide a chain of trust when all RSVP nodes are policy capable. With this mechanism, the INTEGRITY object is carried inside RSVP messages. The second mechanism relies on the INTEGRITY object within the POLICY_DATA object to guarantee integrity between RSVP PEPs that are not RSVP neighbors.
本文档中定义的准入PRI和应用资源PRI策略元素由RSVP通过封装在[RFC2750]中定义的策略数据对象中发出信号。因此，与任何其他策略元素一样，它们的完整性可以通过两种可选的安全机制得到保护，如[RFC2750]第6节所述。第一种机制依赖于[RFC2747]和[RFC3097]中指定的RSVP身份验证，以在所有RSVP节点都支持策略时提供信任链。通过这种机制，完整性对象被携带在RSVP消息中。第二种机制依赖于POLICY_数据对象中的INTEGRITY对象来保证不是RSVP邻居的RSVP-pep之间的完整性。
RSVP authentication can be used between RSVP neighbors that are policy capable. RSVP authentication (defined in [RFC2747] and [RFC3097]) SHOULD be supported by an implementation of the present document.
RSVP身份验证可在支持策略的RSVP邻居之间使用。RSVP身份验证（在[RFC2747]和[RFC3097]中定义）应得到本文件实施的支持。
With RSVP authentication, the RSVP neighbors use shared keys to compute the cryptographic signature of the RSVP message. [RFC6411] discusses key types and key provisioning methods as well as their respective applicabilities.
通过RSVP身份验证，RSVP邻居使用共享密钥计算RSVP消息的加密签名。[RFC6411]讨论了密钥类型和密钥配置方法及其各自的适用性。
The INTEGRITY object within the POLICY_DATA object can be used to guarantee integrity between non-neighboring RSVP PEPs. This is useful only when some RSVP nodes are Policy Ignorant Nodes (PINs). The INTEGRITY object within the POLICY_DATA object MAY be supported by an implementation of the present document.
策略_数据对象中的完整性对象可用于保证非相邻RSVP PEP之间的完整性。这仅在某些RSVP节点是策略无关节点（PIN）时有用。本文档的实现可能支持策略_数据对象中的完整性对象。
Details for computation of the content of the INTEGRITY object can be found in Appendix B of [RFC2750]. This states that the Policy Decision Point (PDP), at its discretion, and based on the destination PEP/PDP or other criteria, selects an Authentication Key and the hash algorithm to be used. Keys to be used between PDPs can be distributed manually or via a standard key management protocol for secure key distribution.
完整性对象内容的计算详情见[RFC2750]的附录B。这表明，策略决策点（PDP）可自行决定并基于目标PEP/PDP或其他标准选择要使用的认证密钥和哈希算法。PDP之间使用的密钥可以手动分发，也可以通过标准密钥管理协议进行安全密钥分发。
Note that where non-RSVP hops may exist in between RSVP hops, as well as where RSVP-capable PINs may exist in between PEPs, it may be difficult for the PDP to determine what is the destination PDP for a POLICY_DATA object contained in some RSVP messages (such as a Path message). This is because in those cases the next PEP is not known at the time of forwarding the message. In this situation, key shared across multiple PDPs may be used. This is conceptually similar to the use of a key shared across multiple RSVP neighbors as discussed
注意，如果在RSVP跳之间可能存在非RSVP跳，以及在PEP之间可能存在具有RSVP能力的管脚，PDP可能难以确定某些RSVP消息（例如路径消息）中包含的策略数据对象的目标PDP是什么。这是因为在这些情况下，转发消息时不知道下一个政治公众人物。在这种情况下，可以使用跨多个PDP共享的密钥。这在概念上类似于所讨论的在多个RSVP邻居之间共享密钥的使用
in [RFC6411]. We observe also that this issue may not exist in some deployment scenarios where a single (or low number of) PDP is used to control all the PEPs of a region (such as an administrative domain). In such scenarios, it may be easy for a PDP to determine what is the next-hop PDP, even when the next-hop PEP is not known, simply by determining what is the next region that will be traversed (say, based on the destination address).
在[RFC6411]中。我们还观察到，在使用单个（或少量）PDP控制区域（如管理域）的所有PEP的某些部署场景中，可能不存在此问题。在这种情况下，PDP可能很容易确定下一跳PDP是什么，即使下一跳PEP未知，也可以简单地通过确定将要穿越的下一个区域是什么（例如，基于目的地地址）。
As specified in [RFC2750], standard RSVP policy elements (P-type values) are to be assigned by IANA as per "IETF Consensus" policy as outlined in [RFC2434] (this policy is now called "IETF Review" as per [RFC5226]) .
如[RFC2750]中所述，IANA将根据[RFC2434]中所述的“IETF共识”政策分配标准RSVP政策元素（P型值）（根据[RFC5226]，该政策现在称为“IETF审查”）。
IANA has allocated two P-Types from the standard RSVP policy element range:
IANA已从标准RSVP策略元素范围中分配了两种P类型：
o 0x05 ADMISSION_PRI for the Admission Priority Policy Element
o 0x05准入优先级策略元素的准入优先级
o 0x06 APP_RESOURCE_PRI for the Application-Level Resource Priority Policy Element
o 0x06应用程序级资源优先级策略元素的应用程序资源优先级
In Section 5.1, the present document defines a Merge Strategy field inside the Admission Priority Policy Element. This registry is to be specified as also applicable to the Merge Strategy field of the Preemption Priority Policy Elements defined in [RFC3181]. Since it is conceivable that, in the future, values will be added to the registry that only apply to the Admission Priority Policy Element or to the Preemption Priority Policy Element (but not to both), IANA has listed the applicable documents for each value. IANA has allocated the following values:
在第5.1节中，本文档在准入优先级策略元素中定义了一个合并策略字段。该注册表也适用于[RFC3181]中定义的抢占优先权策略元素的合并策略字段。由于可以想象，将来将向注册表添加仅适用于准入优先权策略元素或优先购买优先权策略元素（但不同时适用于两者）的值，IANA列出了每个值的适用文档。IANA已分配以下值：
o 0: Reserved
o 0:保留
o 1: Take priority of highest QoS [RFC3181] [RFC6401]
o 1：采用最高QoS的优先级[RFC3181][RFC6401]
o 2: Take highest priority [RFC3181] [RFC6401]
o 2：采用最高优先级[RFC3181][RFC6401]
o 3: Force Error on heterogeneous merge [RFC3181] [RFC6401]
o 3:异类合并上的强制错误[RFC3181][RFC6401]
Following the policies outlined in [RFC5226], numbers in the range 0-127 are allocated according to the "IETF Review" policy, numbers in the range 128-240 as "First Come First Served", and numbers in the range 241-255 are "Reserved for Private Use".
按照[RFC5226]中概述的政策，0-127范围内的数字根据“IETF审查”政策分配，128-240范围内的数字为“先到先得”，241-255范围内的数字为“专用”。
In Section 5.1, the present document defines an Error Code field inside the Admission Priority Policy Element. IANA has created a registry for this field and allocate the following values:
在第5.1节中，本文件在准入优先级策略元素中定义了一个错误代码字段。IANA已为此字段创建注册表，并分配以下值：
o 0: NO_ERROR - Value used for regular ADMISSION_PRI elements
o 0:无错误-用于常规准入PRI元素的值
o 2: HETEROGENEOUS - This element encountered heterogeneous merge
o 2:异类-此元素遇到异类合并
Following the policies outlined in [RFC5226], numbers in the range 0-127 are allocated according to the "IETF Review" policy, numbers in the range 128-240 as "First Come First Served", and numbers in the range 241-255 are "Reserved for Private Use". Value 1 is Reserved (for consistency with [RFC3181] Error Code values).
按照[RFC5226]中概述的政策，0-127范围内的数字根据“IETF审查”政策分配，128-240范围内的数字为“先到先得”，241-255范围内的数字为“专用”。保留值1（与[RFC3181]错误代码值一致）。
The present document defines an ALRP Namespace field in Section 5.2 that contains a numerical value identifying the namespace of the application-level resource priority. The IANA already maintains the Resource-Priority Namespaces registry (under the SIP Parameters) listing all such namespaces. That registry has been updated to allocate a numerical value to each namespace. To be exact, the IANA has extended the Resource-Priority Namespaces registry in the following ways:
本文档在第5.2节中定义了一个ALRP名称空间字段，该字段包含一个数值，用于标识应用程序级资源优先级的名称空间。IANA已经维护了资源优先级名称空间注册表（在SIP参数下），其中列出了所有此类名称空间。该注册表已更新，以便为每个命名空间分配一个数值。确切地说，IANA通过以下方式扩展了资源优先级名称空间注册表：
o A new column has been added to the registry.
o 已将新列添加到注册表中。
o The title of the new column is "Namespace Numerical Value *".
o 新列的标题是“名称空间数值*”。
o In the Legend, a line has been added stating "Namespace Numerical Value = the unique numerical value identifying the namespace".
o 在图例中，添加了一行，说明“名称空间数值=标识名称空间的唯一数值”。
o In the Legend, a line has been added stating "* : [RFC6401]".
o 在图例中，添加了一行，说明“*：[RFC6401]”。
o An actual numerical value has been allocated to each namespace in the registry and is listed in the new "Namespace Numerical Value *" column.
o 已为注册表中的每个名称空间分配了一个实际的数值，并在新的“名称空间数值*”列中列出。
A numerical value has been allocated by IANA for all existing namespaces. In the future, IANA should automatically allocate a numerical value to any new namespace added to the registry.
IANA已为所有现有名称空间分配了一个数值。将来，IANA应该自动为添加到注册表的任何新名称空间分配一个数值。
The present document defines an ALRP Priority field in Section 5.2 that contains a numerical value identifying the actual application-level resource priority within the application-level resource priority namespace. The IANA already maintains the Resource-Priority Priority-Values registry (under the SIP Parameters) listing all such priorities. That registry has been updated to allocate a numerical value to each priority-value. To be exact, the IANA has extended the Resource-Priority Priority-Values registry in the following ways:
本文档在第5.2节中定义了一个ALRP优先级字段，该字段包含一个数值，用于标识应用程序级资源优先级命名空间中的实际应用程序级资源优先级。IANA已经维护了资源优先级值注册表（在SIP参数下），其中列出了所有此类优先级。该注册表已更新，为每个优先级值分配一个数值。确切地说，IANA通过以下方式扩展了资源优先级值注册表：
o For each namespace, the registry is structured with two columns.
o 对于每个名称空间，注册表由两列构成。
o The title of the first column is "Priority Values (least to greatest)".
o 第一列的标题是“优先级值（从最小到最大）”。
o The first column lists all the values currently defined in the registry (e.g., for the drsn namespace: "routine", "priority", "immediate", "flash", "flash-override", and "flash-override-override")
o 第一列列出了注册表中当前定义的所有值（例如，对于drsn名称空间：“例程”、“优先级”、“立即”、“闪存”、“闪存覆盖”和“闪存覆盖”）
o The title of the second column is "Priority Numerical Value *".
o 第二列的标题为“优先级数值*”。
o At the bottom of the registry, a "Legend" has been added with a line stating "Priority Numerical Value = the unique numerical value identifying the priority within a namespace".
o 在注册表的底部，添加了一个“图例”，其中有一行说明“优先级数值=标识命名空间内优先级的唯一数值”。
o In the Legend, a line has been added stating "* : [RFC6401]".
o 在图例中，添加了一行，说明“*：[RFC6401]”。
o An actual numerical value has been allocated to each priority value and is listed in the new "Priority Numerical Value *" column.
o 已将实际数值分配给每个优先级值，并在新的“优先级数值*”列中列出。
A numerical value has been allocated by IANA to all existing priorities. In the future, IANA should automatically allocate a numerical value to any new namespace added to the registry. The numerical value must be unique within each namespace. Within each namespace, values should be allocated in decreasing order ending with 0 (so that the greatest priority is always allocated value 0). For example, in the drsn namespace, "routine" is allocated numerical value 5, and "flash-override-override" is allocated numerical value 0.
IANA已将数值分配给所有现有优先级。将来，IANA应该自动为添加到注册表的任何新名称空间分配一个数值。数值在每个命名空间中必须是唯一的。在每个名称空间中，应按以0结尾的降序分配值（以便最大优先级始终为分配值0）。例如，在drsn名称空间中，“例程”被分配数值5，“闪存覆盖”被分配数值0。
We would like to thank An Nguyen for his encouragement to address this topic and ongoing comments. Also, this document borrows heavily from some of the work of S. Herzog on the Preemption Priority Policy Element [RFC3181]. Dave Oran and Janet Gunn provided useful input for this document. Ron Bonica, Magnus Westerlund, Cullen Jennings, Ross Callon and Tim Polk provided specific guidance for the applicability statement of the mechanisms defined in this document.
我们要感谢An Nguyen鼓励我们讨论这个话题并不断发表评论。此外，本文件大量借鉴了S.Herzog关于优先购买权策略元素[RFC3181]的一些工作。Dave Oran和Janet Gunn为本文档提供了有用的输入。Ron Bonica、Magnus Westerlund、Cullen Jennings、Ross Callon和Tim Polk为本文件中定义的机制的适用性声明提供了具体指导。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750]Herzog，S.，“策略控制的RSVP扩展”，RFC 2750，2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]Braden，R.和L.Zhang，“RSVP加密身份验证——更新的消息类型值”，RFC 3097，2001年4月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181]Herzog，S.，“信号抢占优先权政策要素”，RFC 31812001年10月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]Camarillo，G.，Marshall，W.，和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4412]Schulzrinne，H.和J.Polk，“会话启动协议（SIP）的通信资源优先级”，RFC 4412，2006年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, October 2011.
[RFC6398]Le Faucheur，F.，Ed.“IP路由器警报注意事项和使用”，BCP 168，RFC 6398，2011年10月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]Katz，D.，“IP路由器警报选项”，RFC 21131997年2月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC27111999年10月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753]Yavatkar，R.，Pendarakis，D.，和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月。
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.
[RFC4125]Le Faucheur，F.和W.Lai，“区分服务感知MPLS流量工程的最大分配带宽约束模型”，RFC 41252005年6月。
[RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons", RFC 4126, June 2005.
[RFC4126]Ash，J.“区分服务感知MPLS流量工程和性能比较的保留带宽约束最大分配模型”，RFC 4126，2005年6月。
[RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
[RFC4127]Le Faucheur，F.“区分服务感知MPLS流量工程的俄罗斯玩偶带宽约束模型”，RFC 4127，2005年6月。
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.
[RFC4230]Tschofenig，H.和R.Graveman，“RSVP安全属性”，RFC 4230，2005年12月。
[RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow", RFC 4495, May 2006.
[RFC4495]Polk，J.和S.Dhesikan，“减少预留流带宽的资源预留协议（RSVP）扩展”，RFC 4495，2006年5月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974]Way，J.，Karagiannis，G.，和A.McDonald，“用于服务质量信令的NSIS信令层协议（NSLP）”，RFC 5974，2010年10月。
[RFC6411] Behringer, M., Le Faucheur, F., and B. Weis, "Applicability of Keying Methods for RSVP Security", RFC 6411, October 2011.
[RFC6411]Behringer，M.，Le Faucheur，F.，和B.Weis，“RSVP安全的键控方法的适用性”，RFC 64112011年10月。
Appendix A. Examples of Bandwidth Allocation Model for Admission Priority
附录A.准入优先级的带宽分配模型示例
Appendices A.1 and A.2 respectively illustrate how the Maximum Allocation Model (MAM) [RFC4125] and the Russian Dolls Model (RDM) [RFC4127] can be used for support of admission priority. The Maximum Allocation model with Reservation (MAR) [RFC4126] can also be used in a similar manner for support of admission priority. Appendix A.3 illustrates how a simple "Priority Bypass Model" can also be used for support of admission priority.
附录A.1和A.2分别说明了如何使用最大分配模型（MAM）[RFC4125]和俄罗斯玩偶模型（RDM）[RFC4127]来支持准入优先级。带保留的最大分配模型（MAR）[RFC4126]也可以以类似的方式用于支持接纳优先级。附录A.3说明了如何使用简单的“优先权旁路模型”来支持入学优先权。
For simplicity, operations with only a single "priority" level (beyond non-priority) are illustrated here; however, the reader will appreciate that operations with multiple priority levels can easily be supported with these models.
为简单起见，此处说明了仅具有单个“优先级”级别（非优先级之外）的操作；然而，读者将理解，这些模型可以很容易地支持具有多个优先级的操作。
In all the figures below:
在所有下图中：
"x" represents a non-priority session "o" represents a priority session
“x”表示非优先级会话“o”表示优先级会话
This section illustrates operations of admission priority when a Maximum Allocation Model (MAM) is used for bandwidth allocation across non-priority traffic and priority traffic. A property of the Maximum Allocation Model is that priority traffic cannot use more than the bandwidth made available to priority traffic (even if the non-priority traffic is not using all of the bandwidth available for it).
本节说明当最大分配模型（MAM）用于跨非优先级业务和优先级业务的带宽分配时，接纳优先级的操作。最大分配模型的一个特性是，优先级流量使用的带宽不能超过优先级流量可用的带宽（即使非优先级流量没有使用所有可用带宽）。
-----------------------
^ ^ ^ | | ^
. . . | | .
Total . . . | | . Bandwidth
(1)(2)(3) | | . available
Engi- . . . | | . for non-priority use
neered .or.or. | | .
. . . | | .
Capacity. . . | | .
v . . | | v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v | | v priority use
-------------------------
-----------------------
^ ^ ^ | | ^
. . . | | .
Total . . . | | . Bandwidth
(1)(2)(3) | | . available
Engi- . . . | | . for non-priority use
neered .or.or. | | .
. . . | | .
Capacity. . . | | .
v . . | | v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v | | v priority use
-------------------------
Figure 4: MAM Bandwidth Allocation
图4:MAM带宽分配
Figure 4 shows a link that is within a routed network and conforms to this document. On this link are two amounts of bandwidth available to two types of traffic: non-priority and priority.
图4显示了路由网络中的链路，该链路符合本文档的要求。在这条链路上有两种带宽可供两种类型的流量使用：非优先级和优先级。
If the non-priority traffic load reaches the maximum bandwidth available for non-priority, no additional non-priority sessions can be accepted even if the bandwidth reserved for priority traffic is not fully utilized currently.
如果非优先级流量负载达到非优先级可用的最大带宽，则即使当前未充分利用为优先级流量保留的带宽，也不能接受额外的非优先级会话。
With the Maximum Allocation Model, in the case where the priority load reaches the maximum bandwidth reserved for priority sessions, no additional priority sessions can be accepted.
使用最大分配模型，在优先级负载达到为优先级会话保留的最大带宽的情况下，不能接受额外的优先级会话。
As illustrated in Figure 4, an operator may map the MAM to the engineered capacity limits according to different policies. At one extreme, where the proportion of priority traffic is reliably known to be fairly small at all times and where there may be some safety margin factored in the engineered capacity limits, the operator may decide to configure the bandwidth available for non-priority use to the full engineered capacity limits, effectively allowing the priority traffic to ride within the safety margin of this engineered capacity. This policy can be seen as an economically attractive approach as all of the engineered capacity is made available to non-priority sessions. This policy is illustrated as (1) in Figure 4. As an example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth available to non-priority traffic to X, and the bandwidth available to priority traffic to 5% of X. At the other extreme, where the proportion of priority traffic may be significant at times and the engineered capacity limits are very tight, the operator may decide to configure the bandwidth available to non-priority traffic and the bandwidth available to priority traffic such that their sum is equal to the engineered capacity limits. This guarantees that the total load across non-priority and priority traffic is always below the engineered capacity and, in turn, guarantees there will never be any QoS degradation. However, this policy is less attractive economically as it prevents non-priority sessions from using the full engineered capacity, even when there is no or little priority load, which is the majority of time. This policy is illustrated as (3) in Figure 4. As an example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth available to non-priority traffic to 95% of X, and the bandwidth available to priority traffic to 5% of X. Of course, an operator may also strike a balance anywhere in between these two approaches. This policy is illustrated as (2) in Figure 4.
如图4所示，运营商可以根据不同的政策将MAM映射到工程容量限制。在一个极端情况下，如果可靠地知道优先级通信量的比例始终相当小，并且在工程容量限制中可能存在一些安全裕度，则运营商可以决定将非优先级使用的可用带宽配置为完全工程容量限值，有效地允许优先通行车辆在该设计通行能力的安全裕度范围内行驶。这项政策可以被视为一种经济上有吸引力的方法，因为所有的工程能力都可用于非优先会议。该策略如图4中的（1）所示。例如，如果给定链路上的工程容量限制为X，则运营商可将非优先级流量可用的带宽配置为X，将优先级流量可用的带宽配置为X的5%。在另一个极端，如果优先级流量的比例有时可能很大，且工程容量限制非常严格，则运营商可决定配置非优先级流量可用的带宽和优先级流量可用的带宽，使其总和等于工程容量限制。这保证了非优先级和优先级流量的总负载始终低于工程容量，进而保证永远不会出现任何QoS降级。然而，这一政策在经济上不太有吸引力，因为它阻止非优先级会话使用全部工程容量，即使在大多数情况下没有或几乎没有优先级负载。该策略如图4中的（3）所示。例如，如果给定链路上的工程容量限制为X，则运营商可以将非优先级流量的可用带宽配置为X的95%，将优先级流量的可用带宽配置为X的5%。当然，运营商也可以在这两种方法之间的任何地方取得平衡。该策略如图4中的（2）所示。
Figure 5 shows some of the non-priority capacity of this link being used.
图5显示了正在使用的该链路的一些非优先级容量。
-----------------------
^ ^ ^ | | ^
. . . | | .
Total . . . | | . Bandwidth
. . . | | . available
Engi- . . . | | . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v | | v priority use
-------------------------
-----------------------
^ ^ ^ | | ^
. . . | | .
Total . . . | | . Bandwidth
. . . | | . available
Engi- . . . | | . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v | | v priority use
-------------------------
Figure 5: Partial Load of Non-Priority Calls
图5：非优先级调用的部分负载
Figure 6 shows the same amount of non-priority load being used at this link and a small amount of priority bandwidth being used.
图6显示了在该链路上使用的相同数量的非优先级负载和使用的少量优先级带宽。
-----------------------
^ ^ ^ | | ^
. . . | | .
Total . . . | | . Bandwidth
. . . | | . available
Engi- . . . | | . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v |oooooooooooooo| v priority use
-------------------------
-----------------------
^ ^ ^ | | ^
. . . | | .
Total . . . | | . Bandwidth
. . . | | . available
Engi- . . . | | . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v |oooooooooooooo| v priority use
-------------------------
Figure 6: Partial Load of Non-Priority Calls and Partial Load of Priority Calls
图6：非优先级呼叫的部分负载和优先级呼叫的部分负载
Figure 7 shows the case where non-priority load equates or exceeds the maximum bandwidth available to non-priority traffic. Note that additional non-priority sessions would be rejected even if the bandwidth reserved for priority sessions is not fully utilized.
图7显示了非优先级负载等于或超过非优先级流量可用的最大带宽的情况。请注意，即使为优先级会话保留的带宽没有得到充分利用，也会拒绝额外的非优先级会话。
-----------------------
^ ^ ^ |xxxxxxxxxxxxxx| ^
. . . |xxxxxxxxxxxxxx| .
Total . . . |xxxxxxxxxxxxxx| . Bandwidth
. . . |xxxxxxxxxxxxxx| . available
Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v |oooooooooooooo| v priority use
-------------------------
-----------------------
^ ^ ^ |xxxxxxxxxxxxxx| ^
. . . |xxxxxxxxxxxxxx| .
Total . . . |xxxxxxxxxxxxxx| . Bandwidth
. . . |xxxxxxxxxxxxxx| . available
Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v |oooooooooooooo| v priority use
-------------------------
Figure 7: Full Non-Priority Load and Partial Load of Priority Calls
图7：优先级调用的完全非优先级负载和部分负载
Figure 8 shows the case where the priority traffic equates or exceeds the bandwidth reserved for such priority traffic.
图8显示了优先级流量等于或超过为此类优先级流量保留的带宽的情况。
In that case, additional priority sessions could not be accepted. Note that this does not mean that such sessions are dropped altogether: they may be handled by mechanisms, which are beyond the scope of this particular document (such as establishment through preemption of existing non-priority sessions or such as queueing of new priority session requests until capacity becomes available again for priority traffic).
在这种情况下，不能接受额外的优先会议。请注意，这并不意味着这些会话将被完全删除：它们可能由机制处理，这超出了本特定文档的范围（例如，通过抢占现有非优先级会话建立，或者，将新的优先级会话请求排队，直到容量再次可用于优先级通信）。
-----------------------
^ ^ ^ |xxxxxxxxxxxxxx| ^
. . . |xxxxxxxxxxxxxx| .
Total . . . |xxxxxxxxxxxxxx| . Bandwidth
. . . |xxxxxxxxxxxxxx| . available
Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . | | .
v . . | | v
. . |--------------| ---
v . |oooooooooooooo| ^
. |oooooooooooooo| . Bandwidth available for
v |oooooooooooooo| v priority use
-------------------------
-----------------------
^ ^ ^ |xxxxxxxxxxxxxx| ^
. . . |xxxxxxxxxxxxxx| .
Total . . . |xxxxxxxxxxxxxx| . Bandwidth
. . . |xxxxxxxxxxxxxx| . available
Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . | | .
v . . | | v
. . |--------------| ---
v . |oooooooooooooo| ^
. |oooooooooooooo| . Bandwidth available for
v |oooooooooooooo| v priority use
-------------------------
Figure 8: Partial Non-Priority Load and Full Priority Load
图8：部分非优先负载和完全优先负载
This section illustrates operations of admission priority when a Russian Dolls Model (RDM) is used for bandwidth allocation across non-priority traffic and priority traffic. A property of the RDM is that priority traffic can use the bandwidth that is not currently used by non-priority traffic.
本节说明了当俄罗斯玩偶模型（RDM）用于跨非优先级流量和优先级流量的带宽分配时，准入优先级的操作。RDM的一个特性是优先级流量可以使用非优先级流量当前未使用的带宽。
As with the MAM, an operator may map the RDM onto the engineered capacity limits according to different policies. The operator may decide to configure the bandwidth available for non-priority use to the full engineered capacity limits. As an example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth available to non-priority traffic to X, and the bandwidth available to non-priority and priority traffic to 105% of X.
与MAM一样，运营商可以根据不同的政策将RDM映射到工程容量限制上。运营商可决定将非优先使用的可用带宽配置为完全工程容量限制。例如，如果给定链路上的工程容量限制为X，则运营商可以将非优先级业务可用的带宽配置为X，将非优先级和优先级业务可用的带宽配置为X的105%。
Alternatively, the operator may decide to configure the bandwidth available to non-priority and priority traffic to the engineered capacity limits. As an example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth available to non-priority traffic to 95% of X, and the bandwidth available to non-priority and priority traffic to X.
或者，运营商可以决定将非优先级和优先级业务的可用带宽配置为工程容量限制。例如，如果给定链路上的工程容量限制为X，则运营商可以将非优先级业务的可用带宽配置为X的95%，将非优先级和优先级业务的可用带宽配置为X。
Finally, the operator may decide to strike a balance in between. The considerations presented for these policies in the previous section in the MAM context are equally applicable to RDM.
最后，运营商可能决定在两者之间取得平衡。上一节在MAM上下文中介绍的这些策略的注意事项同样适用于RDM。
Figure 9 shows the case where only some of the bandwidth available to non-priority traffic is being used, and a small amount of priority traffic is in place. In that situation, both new non-priority sessions and new priority sessions would be accepted.
图9显示了仅使用非优先级流量可用的部分带宽，并且存在少量优先级流量的情况。在这种情况下，将接受新的非优先会议和新的优先会议。
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth
| | . . available for
| | v . non-priority
|--------------| --- . and priority
| | . use
| | .
|oooooooooooooo| v
---------------------------------------
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth
| | . . available for
| | v . non-priority
|--------------| --- . and priority
| | . use
| | .
|oooooooooooooo| v
---------------------------------------
Figure 9: Partial Non-Priority Load and Partial Aggregate Load
图9：部分非优先负载和部分聚合负载
Figure 10 shows the case where all of the bandwidth available to non-priority traffic is being used and a small amount of priority traffic is in place. In that situation, new priority sessions would be accepted, but new non-priority sessions would be rejected.
图10显示了非优先级流量可用的所有带宽都被使用，并且有少量优先级流量存在的情况。在这种情况下，将接受新的优先届会，但新的非优先届会将被拒绝。
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth
|xxxxxxxxxxxxxx| . . available for
|xxxxxxxxxxxxxx| v . non-priority
|--------------| --- . and priority
| | . use
| | .
|oooooooooooooo| v
---------------------------------------
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth
|xxxxxxxxxxxxxx| . . available for
|xxxxxxxxxxxxxx| v . non-priority
|--------------| --- . and priority
| | . use
| | .
|oooooooooooooo| v
---------------------------------------
Figure 10: Full Non-Priority Load and Partial Aggregate Load
图10：完全非优先负载和部分聚合负载
Figure 11 shows the case where only some of the bandwidth available to non-priority traffic is being used, and a heavy load of priority traffic is in place. In that situation, both new non-priority sessions and new priority sessions would be accepted. Note that, as illustrated in Figure 10, priority sessions use some of the bandwidth currently not used by non-priority traffic.
图11显示了仅使用非优先级流量可用的部分带宽，并且优先级流量负载很重的情况。在这种情况下，将接受新的非优先会议和新的优先会议。请注意，如图10所示，优先级会话使用非优先级通信当前未使用的一些带宽。
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
| | . . Bandwidth
| | . . available for
|oooooooooooooo| v . non-priority
|--------------| --- . and priority
|oooooooooooooo| . use
|oooooooooooooo| .
|oooooooooooooo| v
---------------------------------------
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
| | . . Bandwidth
| | . . available for
|oooooooooooooo| v . non-priority
|--------------| --- . and priority
|oooooooooooooo| . use
|oooooooooooooo| .
|oooooooooooooo| v
---------------------------------------
Figure 11: Partial Non-Priority Load and Heavy Aggregate Load
图11：部分非优先荷载和重骨料荷载
Figure 12 shows the case where all of the bandwidth available to non-priority traffic is being used, and all of the remaining available bandwidth is used by priority traffic. In that situation, new non-priority sessions would be rejected, and new priority sessions could not be accepted right away. Those priority sessions may be handled by mechanisms, which are beyond the scope of this particular document (such as established through preemption of existing non-priority sessions or such as queueing of new priority session requests until capacity becomes available again for priority traffic).
图12显示了一种情况，其中非优先级流量使用所有可用带宽，而优先级流量使用所有剩余可用带宽。在这种情况下，新的非优先届会将被拒绝，新的优先届会不能立即被接受。这些优先级会话可以由超出本特定文档范围的机制来处理（例如通过抢占现有非优先级会话建立的机制，或者通过排队等待新的优先级会话请求，直到优先级通信的容量再次可用为止）。
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth
|xxxxxxxxxxxxxx| . . available for
|xxxxxxxxxxxxxx| v . non-priority
|--------------| --- . and priority
|oooooooooooooo| . use
|oooooooooooooo| .
|oooooooooooooo| v
---------------------------------------
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth
|xxxxxxxxxxxxxx| . . available for
|xxxxxxxxxxxxxx| v . non-priority
|--------------| --- . and priority
|oooooooooooooo| . use
|oooooooooooooo| .
|oooooooooooooo| v
---------------------------------------
Figure 12: Full Non-Priority Load and Full Aggregate Load
图12：完全非优先负载和完全聚合负载
This section illustrates operations of admission priority when a simple Priority Bypass Model (PrBM) is used for bandwidth allocation across non-priority traffic and priority traffic. With the PrBM, non-priority traffic is subject to resource-based admission control, while priority traffic simply bypasses the resource-based admission control. In other words:
本节说明了当简单优先级旁路模型（PrBM）用于跨非优先级流量和优先级流量的带宽分配时，接纳优先级的操作。在PrBM中，非优先级流量受到基于资源的准入控制，而优先级流量只是绕过基于资源的准入控制。换言之：
o when a non-priority session arrives, this session is subject to bandwidth admission control and is accepted if the current total load (aggregate over non-priority and priority traffic) is below the engineered/allocated bandwidth.
o 当非优先级会话到达时，该会话受带宽许可控制，并且如果当前总负载（非优先级和优先级通信的聚合）低于工程/分配的带宽，则该会话被接受。
o when a priority session arrives, this session is admitted regardless of the current load.
o 当优先级会话到达时，无论当前负载如何，都会允许该会话。
A property of this model is that a priority session is never rejected.
该模型的一个特性是优先级会话从不被拒绝。
The rationale for this simple scheme is that, in practice, in some networks:
这一简单方案的基本原理是，在某些网络中：
o The volume of priority sessions is very low for the vast majority of time, so it may not be economical to completely set aside bandwidth for priority sessions and preclude the utilization of this bandwidth by normal sessions in normal situations.
o 在绝大多数情况下，优先级会话的容量非常低，因此完全为优先级会话留出带宽并阻止正常会话在正常情况下使用此带宽可能不经济。
o Even in congestion periods where priority sessions may be more heavily used, those sessions always still represent a fairly small proportion of the overall load that can be absorbed within the
o 即使在优先级会话可能被更频繁使用的拥塞期间，这些会话始终代表可在系统内吸收的总负载的相当小的比例
safety margin of the engineered capacity limits. Thus, even if they are admitted beyond the engineered bandwidth threshold, they are unlikely to result in noticeable QoS degradation.
工程能力限值的安全裕度。因此，即使它们被允许超过工程带宽阈值，它们也不太可能导致明显的QoS降低。
As with the MAM and RDM, an operator may map the PrBM onto the engineered capacity limits according to different policies. The operator may decide to configure the bandwidth limit for admission of non-priority traffic to the full engineered capacity limit. As an example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth limit for non-priority traffic to X. Alternatively, the operator may decide to configure the bandwidth limit for non-priority traffic to below the engineered capacity limits (so that the sum of the non-priority and priority traffic stays below the engineered capacity). As an example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth limit for non-priority traffic to 95% of X. Finally, the operator may decide to strike a balance in between. The considerations presented for these policies in the previous sections in the MAM and RDM contexts are equally applicable to the PrBM.
与MAM和RDM一样，运营商可以根据不同的政策将PrBM映射到工程容量限制上。运营商可决定配置带宽限制，以允许非优先级流量达到完全工程容量限制。例如，如果给定链路上的工程容量限制为X，则运营商可将非优先级流量的带宽限制配置为X。或者，运营商可决定将非优先级流量的带宽限制配置为低于工程容量限制（使非优先和优先流量之和保持在设计容量以下）。例如，如果给定链路上的工程容量限制为X，则运营商可将非优先级流量的带宽限制配置为X的95%。最后，运营商可决定在两者之间取得平衡。在MAM和RDM上下文中，前面章节中针对这些策略提出的注意事项同样适用于PrBM。
Figure 13 illustrates the bandwidth allocation with the PrBM.
图13说明了PrBM的带宽分配。
-----------------------
^ ^ | | ^
. . | | .
Total . . | | . Bandwidth limit
(1) (2) | | . (on non-priority + priority)
Engi- . . | | . for admission
neered . or . | | . of non-priority traffic
. . | | .
Capacity. . | | .
v . | | v
. |--------------| ---
. | |
v | |
| |
-----------------------
^ ^ | | ^
. . | | .
Total . . | | . Bandwidth limit
(1) (2) | | . (on non-priority + priority)
Engi- . . | | . for admission
neered . or . | | . of non-priority traffic
. . | | .
Capacity. . | | .
v . | | v
. |--------------| ---
. | |
v | |
| |
Figure 13: Priority Bypass Model Bandwidth Allocation
图13：优先级旁路模型带宽分配
Figure 14 shows some of the non-priority capacity of this link being used. In this situation, both new non-priority and new priority sessions would be accepted.
图14显示了正在使用的该链路的一些非优先级容量。在这种情况下，新的非优先会议和新的优先会议都将被接受。
-----------------------
^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . | | . for admission
neered . or . | | . of non-priority traffic
. . | | .
Capacity. . | | .
v . | | v
. |--------------| ---
. | |
v | |
| |
-----------------------
^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . | | . for admission
neered . or . | | . of non-priority traffic
. . | | .
Capacity. . | | .
v . | | v
. |--------------| ---
. | |
v | |
| |
Figure 14: Partial Load of Non-Priority Calls
图14：非优先级调用的部分负载
Figure 15 shows the same amount of non-priority load being used at this link and a small amount of priority bandwidth being used. In this situation, both new non-priority and new priority sessions would be accepted.
图15显示了在该链路上使用的相同数量的非优先级负载和使用的少量优先级带宽。在这种情况下，新的非优先会议和新的优先会议都将被接受。
-----------------------
^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . |oooooooooooooo| . for admission
neered . or . | | . of non-priority traffic
. . | | .
Capacity. . | | .
v . | | v
. |--------------| ---
. | |
v | |
| |
-----------------------
^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . |oooooooooooooo| . for admission
neered . or . | | . of non-priority traffic
. . | | .
Capacity. . | | .
v . | | v
. |--------------| ---
. | |
v | |
| |
Figure 15: Partial Load of Non-Priority Calls and Partial Load of Priority Calls
图15：部分加载非优先级调用和部分加载优先级调用
Figure 16 shows the case where aggregate non-priority and priority load exceeds the bandwidth limit for admission of non-priority traffic. In this situation, any new non-priority session is rejected, while any new priority session is admitted.
图16显示了聚合非优先级和优先级负载超过允许非优先级流量的带宽限制的情况。在这种情况下，拒绝任何新的非优先级会话，而允许任何新的优先级会话。
-----------------------
^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . |oooooooooooooo| . for admission
neered . or . |xxxooxxxooxxxo| . of non-priority traffic
. . |xxoxxxxxxoxxxx| .
Capacity. . |oxxxooooxxxxoo| .
v . |xxoxxxooxxxxxx| v
. |--------------| ---
. |oooooooooooooo|
v | |
| |
-----------------------
^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . |oooooooooooooo| . for admission
neered . or . |xxxooxxxooxxxo| . of non-priority traffic
. . |xxoxxxxxxoxxxx| .
Capacity. . |oxxxooooxxxxoo| .
v . |xxoxxxooxxxxxx| v
. |--------------| ---
. |oooooooooooooo|
v | |
| |
Figure 16: Full Non-Priority Load
图16：完全非优先负载
This section provides examples of how RSVP extensions defined in this document can be used (in conjunction with other RSVP functionality and SIP functionality) to enforce different hypothetical policies for handling prioritized sessions in a given administrative domain. This appendix does not provide additional specification. It is only included in this document for illustration purposes.
本节提供了如何使用本文档中定义的RSVP扩展（与其他RSVP功能和SIP功能结合使用）来强制执行不同的假设策略，以处理给定管理域中的优先级会话的示例。本附录不提供其他规范。本文件中仅包含此项说明。
We assume an environment where SIP is used for session control and RSVP is used for resource reservation.
我们假设一个环境，其中SIP用于会话控制，RSVP用于资源预留。
We refer here to "Session Queueing" as the set of "session-layer" capabilities that may be implemented by SIP user agents to influence their treatment of SIP requests. This may include the ability to "queue" session requests when those cannot be immediately honored (in some cases with the notion of "bumping", or "displacement", of less important session requests from that queue). It may include additional mechanisms such as alternate routing and exemption from certain network management controls.
这里，我们将“会话排队”称为一组“会话层”功能，这些功能可由SIP用户代理实现，以影响其对SIP请求的处理。这可能包括在无法立即执行会话请求时“排队”会话请求的能力（在某些情况下，使用该队列中不太重要的会话请求的“碰撞”或“置换”概念）。它可能包括额外的机制，例如备用路由和免除某些网络管理控制。
We only mention below the RSVP policy elements that are to be enforced by PEPs. It is assumed that these policy elements are set at a policy area boundary by PDPs. The Admission Priority and
以下仅提及政治公众人物将实施的RSVP政策要素。假设这些策略元素由PDP设置在策略区域边界。入学优先次序及
Preemption Priority RSVP policy elements are set by PDPs as a result of processing the Application-Level Resource Priority Policy Element (which is carried in RSVP messages).
抢占优先级RSVP策略元素由PDP设置，作为处理应用程序级资源优先级策略元素（在RSVP消息中携带）的结果。
If one wants to implement a prioritized service purely based on Session Queueing, one can achieve this by signaling prioritized sessions:
如果想要实现纯粹基于会话排队的优先级服务，可以通过向优先级会话发送信号来实现：
o using the "Resource-Priority" header in SIP
o 在SIP中使用“资源优先级”头
o not using the Admission-Priority Policy Element in RSVP
o 未在RSVP中使用准入优先级策略元素
o not using the Preemption Policy Element in RSVP
o 未在RSVP中使用抢占策略元素
If one wants to implement a prioritized service based on Session Queueing and "prioritized access to network-layer resources", one can achieve this by signaling prioritized sessions:
如果想要实现基于会话排队和“优先访问网络层资源”的优先服务，可以通过向优先会话发送信号来实现：
o using the "Resource-Priority" header in SIP
o 在SIP中使用“资源优先级”头
o using the Admission-Priority Policy Element in RSVP
o 在RSVP中使用准入优先级策略元素
o not using the Preemption Policy Element in RSVP
o 未在RSVP中使用抢占策略元素
Establishment of prioritized sessions will not result in preemption of any session. Different bandwidth allocation models can be used to offer different "prioritized access to network-layer resources". Just as examples, this includes setting aside capacity exclusively for prioritized sessions as well as simple bypass of admission limits for prioritized sessions.
建立优先会话不会导致抢占任何会话。不同的带宽分配模型可用于提供不同的“优先访问网络层资源”。例如，这包括专门为优先会话留出容量，以及简单地绕过优先会话的准入限制。
If one wants to implement a prioritized service based on Session Queueing and "prioritized access to network-layer resources", and wants to ensure that (say) "Prioritized-1" sessions can preempt "Prioritized-2" sessions, but non-prioritized sessions are not affected by preemption, one can do that by signaling prioritized sessions:
如果想要实现基于会话排队和“对网络层资源的优先访问”的优先服务，并且想要确保（比如）“优先-1”会话可以抢占“优先-2”会话，但非优先会话不受抢占的影响，那么可以通过发信号通知优先会话来做到这一点：
o using the "Resource-Priority" header in SIP
o 在SIP中使用“资源优先级”头
o using the Admission-Priority Policy Element in RSVP
o 在RSVP中使用准入优先级策略元素
o using the Preemption Policy Element in RSVP with:
o 将RSVP中的抢占策略元素用于：
* setup (Prioritized-1) > defending (Prioritized-2)
* 设置（优先级-1）>防御（优先级-2）
* setup (Prioritized-2) <= defending (Prioritized-1)
* 设置（优先级为-2）<=防御（优先级为-1）
* setup (Prioritized-1) <= defending (Non-Prioritized)
* 设置（优先级-1）<=防御（非优先级）
* setup (Prioritized-2) <= defending (Non-Prioritized)
* 设置（优先级为-2）<=防御（非优先级）
If one wants to implement a prioritized service based on Session Queueing and "prioritized access to network-layer resources", and wants to ensure that prioritized sessions can preempt regular sessions, one could do that by signaling Prioritized sessions:
如果想要实现基于会话排队和“优先访问网络层资源”的优先服务，并且想要确保优先会话可以抢占常规会话，那么可以通过向优先会话发送信号来实现：
o using the "Resource-Priority" header in SIP
o 在SIP中使用“资源优先级”头
o using the Admission-Priority Policy Element in RSVP
o 在RSVP中使用准入优先级策略元素
o using the Preemption Policy Element in RSVP with:
o 将RSVP中的抢占策略元素用于：
* setup (Prioritized) > defending (Non-Prioritized)
* 设置（优先）>防御（非优先）
* setup (Non-Prioritized) <= defending (Prioritized)
* 设置（非优先）<=防御（优先）
If one wants to implement a prioritized service based on Session Queueing and "prioritized access to network-layer resources", and wants to ensure that prioritized sessions can partially preempt regular sessions (i.e., reduce their reservation size), one could do that by signaling prioritized sessions:
如果想要实现基于会话排队和“对网络层资源的优先访问”的优先服务，并且想要确保优先会话可以部分抢占常规会话（即，减少其保留大小），可以通过向优先会话发送信号来实现：
o using the "Resource-Priority" header in SIP
o 在SIP中使用“资源优先级”头
o using the Admission-Priority Policy Element in RSVP
o 在RSVP中使用准入优先级策略元素
o using the Preemption Policy Element in RSVP with:
o 将RSVP中的抢占策略元素用于：
* setup (Prioritized) > defending (Non-Prioritized)
* 设置（优先）>防御（非优先）
* setup (Non-Prioritized) <= defending (Prioritized)
* 设置（非优先）<=防御（优先）
o activate [RFC4495] RSVP bandwidth reduction mechanisms
o 激活[RFC4495]RSVP带宽缩减机制
Authors' Addresses
作者地址
Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France
弗朗索瓦·勒·福彻思科系统公司绿边，法国索菲亚·安提波利斯大道400号，邮编：06410
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
James Polk Cisco Systems 2200 East President George Bush Highway Richardson, TX 75082-3550 United States
美国德克萨斯州理查森市东总统乔治·布什公路2200号詹姆斯·波尔克思科系统公司75082-3550
Phone: +1 972 813 5208
EMail: jmpolk@cisco.com
Phone: +1 972 813 5208
EMail: jmpolk@cisco.com
Ken Carlberg G11 123a Versailles Circle Towson, MD 21204 United States
Ken Carlberg G11 123a美国马里兰州托森凡尔赛宫环21204
EMail: carlberg@g11.org.uk
EMail: carlberg@g11.org.uk