Internet Engineering Task Force (IETF) A. Bader
Request for Comments: 5977 L. Westberg
Category: Experimental Ericsson
ISSN: 2070-1721 G. Karagiannis
University of Twente
C. Kappler
ck technology concepts
T. Phelan
Sonus
October 2010
Internet Engineering Task Force (IETF) A. Bader
Request for Comments: 5977 L. Westberg
Category: Experimental Ericsson
ISSN: 2070-1721 G. Karagiannis
University of Twente
C. Kappler
ck technology concepts
T. Phelan
Sonus
October 2010
RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv
RMD-QOSM：区分服务中用于资源管理的NSIS服务质量模型
Abstract
摘要
This document describes a Next Steps in Signaling (NSIS) Quality-of-Service (QoS) Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to Edge nodes in the RMD network. The RMD Ingress Edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress Edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the Edge nodes.
本文档描述了使用区分服务（RMD）概念中的资源管理的网络的信令（NSIS）服务质量（QoS）模型的下一步。RMD是一种将接纳控制和抢占功能添加到区分服务（Diffserv）网络中的技术。RMD QoS模型允许RMD网络外部的设备向RMD网络中的边缘节点发送预约请求信号。RMD入口边缘节点将传入流分类为业务类，并为每个流沿着数据路径向出口边缘节点发出对应业务类的资源请求信号。出口节点重构原始请求，并继续沿着数据路径将它们转发到最终目的地。此外，RMD定义了通知函数，用于向边缘节点指示域内的过载情况。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc5977.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5977.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Overview of RMD and RMD-QOSM ....................................7
3.1. RMD ........................................................7
3.2. Basic Features of RMD-QOSM ................................10
3.2.1. Role of the QNEs ...................................10
3.2.2. RMD-QOSM/QoS-NSLP Signaling ........................11
3.2.3. RMD-QOSM Applicability and Considerations ..........13
4. RMD-QOSM, Detailed Description .................................15
4.1. RMD-QSPEC Definition ......................................16
4.1.1. RMD-QOSM <QoS Desired> and <QoS Reserved> ..........16
4.1.2. PHR Container ......................................17
4.1.3. PDR Container ......................................20
4.2. Message Format ............................................23
4.3. RMD Node State Management .................................23
4.3.1. Aggregated Operational and Reservation
States at the QNE Edges ............................23
4.3.2. Measurement-Based Method ...........................25
4.3.3. Reservation-Based Method ...........................27
4.4. Transport of RMD-QOSM Messages ............................28
4.5. Edge Discovery and Message Addressing .....................31
4.6. Operation and Sequence of Events ..........................32
4.6.1. Basic Unidirectional Operation .....................32
4.6.1.1. Successful Reservation ....................34
4.6.1.2. Unsuccessful Reservation ..................46
4.6.1.3. RMD Refresh Reservation ...................50
4.6.1.4. RMD Modification of Aggregated
Reservations ..............................54
4.6.1.5. RMD Release Procedure .....................55
4.6.1.6. Severe Congestion Handling ................64
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Overview of RMD and RMD-QOSM ....................................7
3.1. RMD ........................................................7
3.2. Basic Features of RMD-QOSM ................................10
3.2.1. Role of the QNEs ...................................10
3.2.2. RMD-QOSM/QoS-NSLP Signaling ........................11
3.2.3. RMD-QOSM Applicability and Considerations ..........13
4. RMD-QOSM, Detailed Description .................................15
4.1. RMD-QSPEC Definition ......................................16
4.1.1. RMD-QOSM <QoS Desired> and <QoS Reserved> ..........16
4.1.2. PHR Container ......................................17
4.1.3. PDR Container ......................................20
4.2. Message Format ............................................23
4.3. RMD Node State Management .................................23
4.3.1. Aggregated Operational and Reservation
States at the QNE Edges ............................23
4.3.2. Measurement-Based Method ...........................25
4.3.3. Reservation-Based Method ...........................27
4.4. Transport of RMD-QOSM Messages ............................28
4.5. Edge Discovery and Message Addressing .....................31
4.6. Operation and Sequence of Events ..........................32
4.6.1. Basic Unidirectional Operation .....................32
4.6.1.1. Successful Reservation ....................34
4.6.1.2. Unsuccessful Reservation ..................46
4.6.1.3. RMD Refresh Reservation ...................50
4.6.1.4. RMD Modification of Aggregated
Reservations ..............................54
4.6.1.5. RMD Release Procedure .....................55
4.6.1.6. Severe Congestion Handling ................64
4.6.1.7. Admission Control Using Congestion
Notification Based on Probing .............70
4.6.2. Bidirectional Operation ............................73
4.6.2.1. Successful and Unsuccessful Reservations ..77
4.6.2.2. Refresh Reservations ......................82
4.6.2.3. Modification of Aggregated Intra-Domain
QoS-NSLP Operational Reservation States ...82
4.6.2.4. Release Procedure .........................83
4.6.2.5. Severe Congestion Handling ................84
4.6.2.6. Admission Control Using Congestion
Notification Based on Probing .............87
4.7. Handling of Additional Errors .............................89
5. Security Considerations ........................................89
5.1. Introduction ..............................................89
5.2. Security Threats ..........................................91
5.2.1. On-Path Adversary ..................................92
5.2.2. Off-Path Adversary .................................94
5.3. Security Requirements .....................................94
5.4. Security Mechanisms .......................................94
6. IANA Considerations ............................................97
6.1. Assignment of QSPEC Parameter IDs .........................97
7. Acknowledgments ................................................97
8. References .....................................................97
8.1. Normative References ......................................97
8.2. Informative References ....................................98
Appendix A. Examples .............................................101
A.1. Example of a Re-Marking Operation during Severe
Congestion in the Interior Nodes .........................101
A.2. Example of a Detailed Severe Congestion Operation in the
Egress Nodes .............................................107
A.3. Example of a Detailed Re-Marking Admission Control
(Congestion Notification) Operation in Interior Nodes ....111
A.4. Example of a Detailed Admission Control (Congestion
Notification) Operation in Egress Nodes ..................112
A.5. Example of Selecting Bidirectional Flows for Termination
during Severe Congestion .................................113
A.6. Example of a Severe Congestion Solution for
Bidirectional Flows Congested Simultaneously on Forward
and Reverse Paths ........................................113
A.7. Example of Preemption Handling during Admission Control ..117
A.8. Example of a Retransmission Procedure within the RMD
Domain ...................................................120
A.9. Example on Matching the Initiator QSPEC to the Local
RMD-QSPEC ................................................122
4.6.1.7. Admission Control Using Congestion
Notification Based on Probing .............70
4.6.2. Bidirectional Operation ............................73
4.6.2.1. Successful and Unsuccessful Reservations ..77
4.6.2.2. Refresh Reservations ......................82
4.6.2.3. Modification of Aggregated Intra-Domain
QoS-NSLP Operational Reservation States ...82
4.6.2.4. Release Procedure .........................83
4.6.2.5. Severe Congestion Handling ................84
4.6.2.6. Admission Control Using Congestion
Notification Based on Probing .............87
4.7. Handling of Additional Errors .............................89
5. Security Considerations ........................................89
5.1. Introduction ..............................................89
5.2. Security Threats ..........................................91
5.2.1. On-Path Adversary ..................................92
5.2.2. Off-Path Adversary .................................94
5.3. Security Requirements .....................................94
5.4. Security Mechanisms .......................................94
6. IANA Considerations ............................................97
6.1. Assignment of QSPEC Parameter IDs .........................97
7. Acknowledgments ................................................97
8. References .....................................................97
8.1. Normative References ......................................97
8.2. Informative References ....................................98
Appendix A. Examples .............................................101
A.1. Example of a Re-Marking Operation during Severe
Congestion in the Interior Nodes .........................101
A.2. Example of a Detailed Severe Congestion Operation in the
Egress Nodes .............................................107
A.3. Example of a Detailed Re-Marking Admission Control
(Congestion Notification) Operation in Interior Nodes ....111
A.4. Example of a Detailed Admission Control (Congestion
Notification) Operation in Egress Nodes ..................112
A.5. Example of Selecting Bidirectional Flows for Termination
during Severe Congestion .................................113
A.6. Example of a Severe Congestion Solution for
Bidirectional Flows Congested Simultaneously on Forward
and Reverse Paths ........................................113
A.7. Example of Preemption Handling during Admission Control ..117
A.8. Example of a Retransmission Procedure within the RMD
Domain ...................................................120
A.9. Example on Matching the Initiator QSPEC to the Local
RMD-QSPEC ................................................122
This document describes a Next Steps in Signaling (NSIS) QoS Model for networks that use the Resource Management in Diffserv (RMD) framework ([RMD1], [RMD2], [RMD3], and [RMD4]). RMD adds admission control to Diffserv networks and allows nodes external to the networks to dynamically reserve resources within the Diffserv domains.
本文档描述了使用区分服务（RMD）框架中的资源管理的网络的信令（NSIS）QoS模型的下一步（[RMD1]、[RMD2]、[RMD3]和[RMD4]）。RMD向Diffserv网络添加了准入控制，并允许网络外部的节点在Diffserv域内动态地保留资源。
The Quality-of-Service NSIS Signaling Layer Protocol (QoS-NSLP) [RFC5974] specifies a generic protocol for carrying QoS signaling information end-to-end in an IP network. Each network along the end-to-end path is expected to implement a specific QoS Model (QOSM) specified by the QSPEC template [RFC5975] that interprets the requests and installs the necessary mechanisms, in a manner that is appropriate to the technology in use in the network, to ensure the delivery of the requested QoS. This document specifies an NSIS QoS Model for RMD networks (RMD-QOSM), and an RMD-specific QSPEC (RMD-QSPEC) for expressing reservations in a suitable form for simple processing by internal nodes.
服务质量NSIS信令层协议（QoS NSLP）[RFC5974]规定了在IP网络中端到端承载QoS信令信息的通用协议。沿端到端路径的每个网络预计将实现由QSPEC模板[RFC5975]指定的特定QoS模型（QOSM），该模型以适合于网络中使用的技术的方式解释请求并安装必要的机制，以确保交付请求的QoS。本文件规定了RMD网络的NSIS QoS模型（RMD-QOSM）和特定于RMD的QSPEC（RMD-QSPEC），用于以适当的形式表示保留，以便内部节点进行简单处理。
They are used in combination with the QoS-NSLP to provide QoS signaling service in an RMD network. Figure 1 shows an RMD network with the respective entities.
它们与QoS NSLP结合使用，以在RMD网络中提供QoS信令服务。图1显示了具有相应实体的RMD网络。
Stateless or reduced-state Egress
Ingress RMD Nodes Node
Node (Interior Nodes; I-Nodes) (Stateful
(Stateful | | | RMD QoS
RMD QoS-NLSP | | | NSLP Node)
Node) V V V
+-------+ Data +------+ +------+ +------+ +------+
|-------|--------|------|------|------|-------|------|---->|------|
| | Flow | | | | | | | |
|Ingress| |I-Node| |I-Node| |I-Node| |Egress|
| | | | | | | | | |
+-------+ +------+ +------+ +------+ +------+
=================================================>
<=================================================
Signaling Flow
Stateless or reduced-state Egress
Ingress RMD Nodes Node
Node (Interior Nodes; I-Nodes) (Stateful
(Stateful | | | RMD QoS
RMD QoS-NLSP | | | NSLP Node)
Node) V V V
+-------+ Data +------+ +------+ +------+ +------+
|-------|--------|------|------|------|-------|------|---->|------|
| | Flow | | | | | | | |
|Ingress| |I-Node| |I-Node| |I-Node| |Egress|
| | | | | | | | | |
+-------+ +------+ +------+ +------+ +------+
=================================================>
<=================================================
Signaling Flow
Figure 1: Actors in the RMD-QOSM
图1:RMD-QOSM中的参与者
Many network scenarios, such as the "Wired Part of Wireless Network" scenario, which is described in Section 8.4 of [RFC3726], require that the impact of the used QoS signaling protocol on the network performance should be minimized. In such network scenarios, the performance of each network node that is used in a communication path
许多网络场景，如[RFC3726]第8.4节所述的“无线网络的有线部分”场景，要求将所使用的QoS信令协议对网络性能的影响降至最低。在这种网络场景中，通信路径中使用的每个网络节点的性能
has an impact on the end-to-end performance. As such, the end-to-end performance of the communication path can be improved by optimizing the performance of the Interior nodes. One of the factors that can contribute to this optimization is the minimization of the QoS signaling protocol processing load and the minimization of the number of states on each Interior node.
对端到端性能有影响。因此，可以通过优化内部节点的性能来改进通信路径的端到端性能。有助于这种优化的因素之一是最小化QoS信令协议处理负载和最小化每个内部节点上的状态数。
Another requirement that is imposed by such network scenarios is that whenever a severe congestion situation occurs in the network, the used QoS signaling protocol should be able to solve them. In the case of a route change or link failure, a severe congestion situation may occur in the network. Typically, routing algorithms are able to adapt and change their routing decisions to reflect changes in the topology and traffic volume. In such situations, the rerouted traffic will have to follow a new path. Interior nodes located on this new path may become overloaded, since they suddenly might need to support more traffic than for which they have capacity. These severe congestion situations will severely affect the overall performance of the traffic passing through such nodes.
此类网络场景施加的另一个要求是，每当网络中出现严重拥塞情况时，所使用的QoS信令协议应该能够解决这些问题。在路由改变或链路故障的情况下，网络中可能会出现严重的拥塞情况。通常，路由算法能够调整和更改其路由决策，以反映拓扑和流量的变化。在这种情况下，重新路由的流量必须遵循新路径。位于这条新路径上的内部节点可能会过载，因为它们可能突然需要支持比其容量更多的流量。这些严重的拥塞情况将严重影响通过这些节点的流量的总体性能。
RMD-QOSM is an edge-to-edge (intra-domain) QoS Model that, in combination with the QoS-NSLP and QSPEC specifications, is designed to support the requirements mentioned above:
RMD-QOSM是一种边到边（域内）QoS模型，结合QoS NSLP和QSPEC规范，旨在支持上述要求：
o Minimal impact on Interior node performance;
o 对内部节点性能的影响最小；
o Increase of scalability;
o 可扩展性的提高；
o Ability to deal with severe congestion
o 处理严重拥堵的能力
Internally to the RMD network, RMD-QOSM together with QoS-NSLP [RFC5974] defines a scalable QoS signaling model in which per-flow QoS-NSLP and NSIS Transport Layer Protocol (NTLP) states are not stored in Interior nodes but per-flow signaling is performed (see [RFC5974]) at the Edges.
在RMD网络内部，RMD-QOSM与QoS NSLP[RFC5974]一起定义了一个可扩展的QoS信令模型，其中每流QoS NSLP和NSIS传输层协议（NTLP）状态不存储在内部节点中，而是在边缘执行每流信令（参见[RFC5974]）。
In the RMD-QOSM, only routers at the Edges of a Diffserv domain (Ingress and Egress nodes) support the (QoS-NSLP) stateful operation; see Section 4.7 of [RFC5974]. Interior nodes support either the (QoS-NSLP) stateless operation or a reduced-state operation with coarser granularity than the Edge nodes.
在RMD-QOSM中，只有位于区分服务域（入口和出口节点）边缘的路由器支持（QoS NSLP）有状态操作；见[RFC5974]第4.7节。内部节点支持（QoS NSLP）无状态操作或比边缘节点粒度更粗的简化状态操作。
After the terminology in Section 2, we give an overview of RMD and the RMD-QOSM in Section 3. This document specifies several RMD-QOSM/ QoS-NSLP signaling schemes. In particular, Section 3.2.3 identifies which combination of sections are used for the specification of each RMD-QOSM/QoS-NSLP signaling scheme. In Section 4 we give a detailed description of the RMD-QOSM, including the role of QoS NSIS entities
在第2节中的术语之后，我们将在第3节中概述RMD和RMD-QOSM。本文件规定了几种RMD-QOSM/QoS NSLP信令方案。特别是，第3.2.3节确定了用于每个RMD-QOSM/QoS NSLP信令方案规范的章节组合。在第4节中，我们详细描述了RMD-QOSM，包括QoS NSIS实体的角色
(QNEs), the definition of the QSPEC, mapping of QSPEC generic parameters onto RMD-QOSM parameters, state management in QNEs, and operation and sequence of events. Section 5 discusses security issues.
（QNEs）、QSPEC的定义、QSPEC通用参数到RMD-QOSM参数的映射、QNEs中的状态管理以及事件的操作和顺序。第5节讨论安全问题。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The terminology defined by GIST [RFC5971] and QoS-NSLP [RFC5974] applies to this document.
GIST[RFC5971]和QoS NSLP[RFC5974]定义的术语适用于本文件。
In addition, the following terms are used:
此外，还使用了以下术语：
NSIS domain: an NSIS signaling-capable domain.
NSIS域：支持NSIS信令的域。
RMD domain: an NSIS domain that is capable of supporting the RMD-QOSM signaling and operations.
RMD域：能够支持RMD-QOSM信令和操作的NSIS域。
Edge node: a QoS-NSLP node on the boundary of some administrative domain that connects one NSIS domain to a node in either another NSIS domain or a non-NSIS domain.
边缘节点：某个管理域边界上的QoS NSLP节点，将一个NSIS域连接到另一个NSIS域或非NSIS域中的节点。
NSIS-aware node: a node that is aware of NSIS signaling and RMD-QOSM operations, such as severe congestion detection and Differentiated Service Code Point (DSCP) marking.
NSIS感知节点：感知NSIS信令和RMD-QOSM操作的节点，如严重拥塞检测和区分服务码点（DSCP）标记。
NSIS-unaware node: a node that is unaware of NSIS signaling, but is aware of RMD-QOSM operations such as severe congestion detection and DSCP marking.
NSIS不知道节点：不知道NSIS信令，但知道RMD-QOSM操作（如严重拥塞检测和DSCP标记）的节点。
Ingress node: an Edge node in its role in handling the traffic as it enters the NSIS domain.
入口节点：在进入NSIS域时处理流量的边缘节点。
Egress node: an Edge node in its role in handling the traffic as it leaves the NSIS domain.
出口节点：在离开NSIS域时处理流量的边缘节点。
Interior node: a node in an NSIS domain that is not an Edge node.
内部节点：NSIS域中不是边缘节点的节点。
Congestion: a temporal network state that occurs when the traffic (or when traffic associated with a particular Per-Hop Behavior (PHB)) passing through a link is slightly higher than the capacity allocated for the link (or allocated for the particular PHB). If no measures are taken, then the traffic passing through this link may temporarily slightly degrade in QoS. This type of congestion is usually solved using admission control mechanisms.
拥塞：当通过链路的流量（或与特定每跳行为（PHB）相关联的流量）略高于为链路分配的容量（或为特定PHB分配的容量）时发生的暂时网络状态。如果未采取措施，则通过此链路的流量可能会暂时稍微降低QoS。这种类型的拥塞通常使用准入控制机制来解决。
Severe congestion: the congestion situation on a particular link within the RMD domain where a significant increase in its real packet queue situation occurs, such as when due to a link failure rerouted traffic has to be supported by this particular link.
严重拥塞：RMD域内特定链路上的拥塞情况，其实际数据包队列情况显著增加，例如由于链路故障，该特定链路必须支持重新路由的流量。
The Differentiated Services (Diffserv) architecture ([RFC2475], [RFC2638]) was introduced as a result of efforts to avoid the scalability and complexity problems of IntServ [RFC1633]. Scalability is achieved by offering services on an aggregate rather than per-flow basis and by forcing as much of the per-flow state as possible to the Edges of the network. The service differentiation is achieved using the Differentiated Services (DS) field in the IP header and the Per-Hop Behavior (PHB) as the main building blocks. Packets are handled at each node according to the PHB indicated by the DS field in the message header.
引入区分服务（Diffserv）体系结构（[RFC2475]，[RFC2638]）是为了避免IntServ[RFC1633]的可伸缩性和复杂性问题。可伸缩性是通过以聚合方式而不是按流方式提供服务，并通过将尽可能多的按流状态强制到网络边缘来实现的。使用IP报头中的Differentied Services（DS）字段和每跳行为（PHB）作为主要构建块来实现服务差异化。根据消息头中DS字段指示的PHB，在每个节点处理数据包。
The Diffserv architecture does not specify any means for devices outside the domain to dynamically reserve resources or receive indications of network resource availability. In practice, service providers rely on short active time Service Level Agreements (SLAs) that statically define the parameters of the traffic that will be accepted from a customer.
Diffserv体系结构未指定域外设备动态保留资源或接收网络资源可用性指示的任何方式。在实践中，服务提供商依赖于短期活动时间服务水平协议（SLA），该协议静态地定义将从客户处接受的流量参数。
RMD was introduced as a method for dynamic reservation of resources within a Diffserv domain. It describes a method that is able to provide admission control for flows entering the domain and a congestion handling algorithm that is able to terminate flows in case of congestion due to a sudden failure (e.g., link, router) within the domain.
RMD是一种在区分服务域内动态保留资源的方法。它描述了一种能够为进入域的流提供准入控制的方法和一种拥塞处理算法，该算法能够在由于域内的突发故障（例如链路、路由器）导致拥塞时终止流。
In RMD, scalability is achieved by separating a fine-grained reservation mechanism used in the Edge nodes of a Diffserv domain from a much simpler reservation mechanism needed in the Interior nodes. Typically, it is assumed that Edge nodes support per-flow QoS states in order to provide QoS guarantees for each flow. Interior nodes use only one aggregated reservation state per traffic class or no states at all. In this way, it is possible to handle large numbers of flows in the Interior nodes. Furthermore, due to the limited functionality supported by the Interior nodes, this solution allows fast processing of signaling messages.
在RMD中，可伸缩性是通过将Diffserv域的边缘节点中使用的细粒度保留机制与内部节点中需要的更简单的保留机制分离来实现的。通常，假定边缘节点支持每个流的QoS状态，以便为每个流提供QoS保证。内部节点对每个流量类只使用一个聚合保留状态，或者根本不使用任何状态。通过这种方式，可以处理内部节点中的大量流。此外，由于内部节点支持的功能有限，此解决方案允许快速处理信令消息。
The possible RMD-QOSM applicabilities are described in Section 3.2.3. Two main basic admission control modes are supported: reservation-based and measurement-based admission control that can be used in
第3.2.3节描述了可能的RMD-QOSM适用性。支持两种主要的基本准入控制模式：基于预约的准入控制和基于测量的准入控制，可用于
combination with a severe congestion-handling solution. The severe congestion-handling solution is used in the situation that a link/node becomes severely congested due to the fact that the traffic supported by a failed link/node is rerouted and has to be processed by this link/node. Furthermore, RMD-QOSM supports both unidirectional and bidirectional reservations.
与严重拥塞处理解决方案相结合。严重拥塞处理解决方案用于链路/节点由于故障链路/节点支持的流量被重新路由且必须由该链路/节点处理而变得严重拥塞的情况。此外，RMD-QOSM支持单向和双向预约。
Another important feature of RMD-QOSM is that the intra-domain sessions supported by the Edges can be either per-flow sessions or per-aggregate sessions. In the case of the per-flow intra-domain sessions, the maintained per-flow intra-domain states have a one-to-one dependency to the per-flow end-to-end states supported by the same Edge. In the case of the per-aggregate sessions the maintained per-aggregate states have a one-to-many relationship to the per-flow end-to-end states supported by the same Edge.
RMD-QOSM的另一个重要特性是边缘支持的域内会话可以是每流会话或每聚合会话。在按流域内会话的情况下，维护的按流域内状态与同一边缘支持的按流端到端状态具有一对一的依赖关系。对于每聚合会话，维护的每聚合状态与同一边缘支持的每流端到端状态具有一对多关系。
In the reservation-based method, each Interior node maintains only one reservation state per traffic class. The Ingress Edge nodes aggregate individual flow requests into PHB traffic classes, and signal changes in the class reservations as necessary. The reservation is quantified in terms of resource units (or bandwidth). These resources are requested dynamically per PHB and reserved on demand in all nodes in the communication path from an Ingress node to an Egress node.
在基于保留的方法中，每个内部节点仅为每个流量类维护一个保留状态。入口边缘节点将单个流量请求聚合到PHB流量类别中，并根据需要在类别保留中发出信号更改。保留是根据资源单元（或带宽）进行量化的。这些资源根据PHB动态请求，并在从入口节点到出口节点的通信路径中的所有节点中按需保留。
The measurement-based algorithm continuously measures traffic levels and the actual available resources, and admits flows whose resource needs are within what is available at the time of the request. The measurement-based algorithm is used to support a predictive service where the service commitment is somewhat less reliable than the service that can be supported by the reservation-based method.
基于测量的算法持续测量流量级别和实际可用资源，并允许其资源需求在请求时可用的范围内的流。基于度量的算法用于支持预测性服务，其中服务承诺的可靠性略低于基于预约的方法所支持的服务。
A main assumption that is made by such measurement-based admission control mechanisms is that the aggregated PHB traffic passing through an RMD Interior node is high and therefore, current measurement characteristics are considered to be an indicator of future load. Once an admission decision is made, no record of the decision need be kept at the Interior nodes. The advantage of measurement-based resource management protocols is that they do not require pre-reservation state nor explicit release of the reservations at the Interior nodes. Moreover, when the user traffic is variable, measurement-based admission control could provide higher network utilization than, e.g., peak-rate reservation. However, this can introduce an uncertainty in the availability of the resources. It is important to emphasize that the RMD measurement-based schemes described in this document do not use any refresh procedures, since these approaches are used in stateless nodes; see Section 4.6.1.3.
这种基于测量的接纳控制机制的主要假设是，通过RMD内部节点的聚合PHB流量较高，因此，当前测量特性被认为是未来负载的指标。一旦做出接纳决定，就不需要在内部节点上保存该决定的记录。基于度量的资源管理协议的优点是，它们不需要预保留状态，也不需要在内部节点显式释放保留。此外，当用户流量可变时，基于测量的接纳控制可以提供比例如峰值速率预留更高的网络利用率。然而，这可能会给资源的可用性带来不确定性。需要强调的是，本文档中描述的基于RMD度量的方案不使用任何刷新过程，因为这些方法用于无状态节点；见第4.6.1.3节。
Two types of measurement-based admission control schemes are possible:
可以采用两种基于测量的接纳控制方案：
* Congestion notification function based on probing:
* 基于探测的拥塞通知功能：
This method can be used to implement a simple measurement-based admission control within a Diffserv domain. In this scenario, the Interior nodes are not NSIS-aware nodes. In these Interior nodes, thresholds are set for the traffic belonging to different PHBs in the measurement-based admission control function. In this scenario, an end-to-end NSIS message is used as a probe packet, meaning that the <DSCP> field in the header of the IP packet that carries the NSIS message is re-marked when the predefined congestion threshold is exceeded. Note that when the predefined congestion threshold is exceeded, all packets are re-marked by a node, including NSIS messages. In this way, the Edges can admit or reject flows that are requesting resources. The frequency and duration that the congestion level is above the threshold resulting in re-marking is tracked and used to influence the admission control decisions.
该方法可用于在区分服务域内实现简单的基于测量的接纳控制。在此场景中，内部节点不是NSIS感知节点。在这些内部节点中，在基于测量的接纳控制功能中为属于不同phb的流量设置阈值。在此场景中，端到端NSIS消息用作探测数据包，这意味着当超过预定义的拥塞阈值时，将重新标记承载NSIS消息的IP数据包报头中的<DSCP>字段。请注意，当超过预定义的拥塞阈值时，节点会重新标记所有数据包，包括NSIS消息。这样，边缘可以接纳或拒绝请求资源的流。拥塞水平高于阈值导致重新标记的频率和持续时间被跟踪并用于影响接纳控制决策。
* NSIS measurement-based admission control:
* 基于NSIS测量的准入控制：
In this case, the measurement-based admission control functionality is implemented in NSIS-aware stateless routers. The main difference between this type of admission control and the congestion notification based on probing is related to the fact that this type of admission control is applied mainly on NSIS-aware nodes. With the measurement-based scheme, the requested peak bandwidth of a flow is carried by the admission control request. The admission decision is considered as positive if the currently carried traffic, as characterized by the measured statistics, plus the requested resources for the new flow exceeds the system capacity with a probability smaller than a value alpha. Otherwise, the admission decision is negative. It is important to emphasize that due to the fact that the RMD Interior nodes are stateless, they do not store information of previous admission control requests.
在这种情况下，基于测量的接纳控制功能在NSIS感知的无状态路由器中实现。这种类型的接纳控制与基于探测的拥塞通知之间的主要区别在于，这种类型的接纳控制主要应用于NSIS感知节点。在基于测量的方案中，请求的流量峰值带宽由准入控制请求承载。如果当前承载的流量（以测量的统计数据为特征）加上新流量的请求资源以小于alpha值的概率超过系统容量，则接纳决策被认为是积极的。否则，录取决定是否定的。需要强调的是，由于RMD内部节点是无状态的，因此它们不存储以前的准入控制请求的信息。
This could lead to a situation where the admission control accuracy is decreased when multiple simultaneous flows (sharing a common Interior node) are requesting admission control simultaneously. By applying measuring techniques, e.g., see [JaSh97] and [GrTs03], which use current and past information on NSIS sessions that requested resources from an NSIS-aware Interior node, the decrease in admission control accuracy can be limited. RMD describes the following procedures:
这可能导致当多个同时流（共享公共内部节点）同时请求接纳控制时接纳控制精度降低的情况。通过应用测量技术（例如，参见[JaSh97]和[GrTs03]），使用NSIS会话的当前和过去信息，从NSIS感知内部节点请求资源，可以限制准入控制精度的降低。RMD描述了以下程序：
* classification of an individual resource reservation or a resource query into Per-Hop Behavior (PHB) groups at the Ingress node of the domain,
* 在域的入口节点将单个资源保留或资源查询分类为每跳行为（PHB）组，
* hop-by-hop admission control based on a PHB within the domain. There are two possible modes of operation for internal nodes to admit requests. One mode is the stateless or measurement-based mode, where the resources within the domain are queried. Another mode of operation is the reduced-state reservation or reservation-based mode, where the resources within the domain are reserved.
* 基于域内PHB的逐跳准入控制。内部节点允许请求有两种可能的操作模式。一种模式是无状态或基于度量的模式，其中查询域内的资源。另一种操作模式是简化状态保留或基于保留的模式，其中保留域内的资源。
* a method to forward the original requests across the domain up to the Egress node and beyond.
* 将原始请求跨域转发到出口节点及其以外的方法。
* a congestion-control algorithm that notifies the Egress Edge nodes about congestion. It is able to terminate the appropriate number of flows in the case a of congestion due to a sudden failure (e.g., link or router failure) within the domain.
* 一种向出口边缘节点通知拥塞的拥塞控制算法。如果域内突然发生故障（例如链路或路由器故障）导致拥塞，它能够终止适当数量的流。
The protocol model of the RMD-QOSM is shown in Figure 2. The figure shows QoS NSIS initiator (QNI) and QoS NSIS Receiver (QNR) nodes, not part of the RMD network, that are the ultimate initiator and receiver of the QoS reservation requests. It also shows QNE nodes that are the Ingress and Egress nodes in the RMD domain (QNE Ingress and QNE Egress), and QNE nodes that are Interior nodes (QNE Interior).
RMD-QOSM的协议模型如图2所示。该图显示了QoS NSIS启动器（QNI）和QoS NSIS接收器（QNR）节点，它们不是RMD网络的一部分，是QoS保留请求的最终启动器和接收器。它还显示了作为RMD域中的入口和出口节点的QNE节点（QNE入口和QNE出口），以及作为内部节点的QNE节点（QNE内部）。
All nodes of the RMD domain are usually QoS-NSLP-aware nodes. However, in the scenarios where the congestion notification function based on probing is used, then the Interior nodes are not NSIS aware. Edge nodes store and maintain QoS-NSLP and NTLP states and therefore are stateful nodes. The NSIS-aware Interior nodes are NTLP stateless. Furthermore, they are either QoS-NSLP stateless (for NSIS measurement-based operation) or reduced-state nodes storing per PHB aggregated QoS-NSLP states (for reservation-based operation).
RMD域的所有节点通常都是QoS NSLP感知节点。但是，在使用基于探测的拥塞通知功能的场景中，内部节点不知道NSIS。边缘节点存储和维护QoS NSLP和NTLP状态，因此是有状态节点。NSIS感知的内部节点是NTLP无状态的。此外，它们要么是QoS NSLP无状态（用于基于NSIS测量的操作），要么是存储每个PHB聚合QoS NSLP状态的精简状态节点（用于基于保留的操作）。
Note that the RMD domain MAY contain Interior nodes that are not NSIS-aware nodes (not shown in the figure).
请注意，RMD域可能包含非NSIS感知节点的内部节点（图中未显示）。
These nodes are assumed to have sufficient capacity for flows that might be admitted. Furthermore, some of these NSIS-unaware nodes MAY be used for measuring the traffic congestion level on the data path. These measurements can be used by RMD-QOSM in the congestion control based on probing operation and/or severe congestion operation (see Section 4.6.1.6).
假设这些节点具有足够的容量来容纳可能被接纳的流。此外，这些NSIS不知道节点中的一些可用于测量数据路径上的业务拥塞水平。RMD-QOSM可在基于探测操作和/或严重拥塞操作的拥塞控制中使用这些测量值（见第4.6.1.6节）。
|------| |-------| |------| |------|
| e2e |<->| e2e |<------------------------->| e2e |<->| e2e |
| QoS | | QoS | | QoS | | QoS |
| | |-------| |------| |------|
| | |-------| |-------| |-------| |------| | |
| | | local |<->| local |<->| local |<->| local| | |
| | | QoS | | QoS | | QoS | | QoS | | |
| | | | | | | | | | | |
| NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP |
|st.ful| |st.ful | |st.less/ |st.less/ |st.ful| |st.ful|
| | | | |red.st.| |red.st.| | | | |
| | |-------| |-------| |-------| |------| | |
|------| |-------| |-------| |-------| |------| |------|
------------------------------------------------------------------
|------| |-------| |-------| |-------| |------| |------|
| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP |
|st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful|
|------| |-------| |-------| |-------| |------| |------|
QNI QNE QNE QNE QNE QNR
(End) (Ingress) (Interior) (Interior) (Egress) (End)
|------| |-------| |------| |------|
| e2e |<->| e2e |<------------------------->| e2e |<->| e2e |
| QoS | | QoS | | QoS | | QoS |
| | |-------| |------| |------|
| | |-------| |-------| |-------| |------| | |
| | | local |<->| local |<->| local |<->| local| | |
| | | QoS | | QoS | | QoS | | QoS | | |
| | | | | | | | | | | |
| NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP |
|st.ful| |st.ful | |st.less/ |st.less/ |st.ful| |st.ful|
| | | | |red.st.| |red.st.| | | | |
| | |-------| |-------| |-------| |------| | |
|------| |-------| |-------| |-------| |------| |------|
------------------------------------------------------------------
|------| |-------| |-------| |-------| |------| |------|
| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP |
|st.ful| |st.ful | |st.less| |st.less| |st.ful| |st.ful|
|------| |-------| |-------| |-------| |------| |------|
QNI QNE QNE QNE QNE QNR
(End) (Ingress) (Interior) (Interior) (Egress) (End)
st.ful: stateful, st.less: stateless st.less red.st.: stateless or reduced-state
st.ful:有状态，st.less:无状态st.less红色。st:无状态或简化状态
Figure 2: Protocol model of stateless/reduced-state operation
图2：无状态/简化状态操作的协议模型
The basic RMD-QOSM/QoS-NSLP signaling is shown in Figure 3. The signaling scenarios are accomplished using the QoS-NSLP processing rules defined in [RFC5974], in combination with the Resource Management Function (RMF) triggers sent via the QoS-NSLP-RMF API described in [RFC5974].
基本RMD-QOSM/QoS NSLP信令如图3所示。信令场景使用[RFC5974]中定义的QoS NSLP处理规则以及[RFC5974]中描述的通过QoS NSLP RMF API发送的资源管理功能（RMF）触发器来完成。
Due to the fact that within the RMD domain a QoS Model that is different than the end-to-end QoS Model applied at the Edges of the RMD domain can be supported, the RMD Interior node reduced-state reservations can be updated independently of the per-flow end-to-end reservations (see Section 4.7 of [RFC5974]). Therefore, two different RESERVE messages are used within the RMD domain. One RESERVE message that is associated with the per-flow end-to-end reservations and is used by the Edges of the RMD domain and one that is associated with the reduced-state reservations within the RMD domain.
由于在RMD域内可以支持不同于在RMD域边缘应用的端到端QoS模型的QoS模型，因此RMD内部节点缩减状态保留可以独立于每流端到端保留进行更新（参见[RFC5974]第4.7节）。因此，在RMD域中使用了两个不同的保留消息。一条保留消息与每流端到端保留相关联，并由RMD域的边缘使用，另一条与RMD域内减少的状态保留相关联。
A RESERVE message is created by a QNI with an Initiator QSPEC describing the reservation and forwarded along the path towards the QNR.
保留消息由QNI创建，启动器QSPEC描述保留并沿路径转发至QNR。
When the original RESERVE message arrives at the Ingress node, an RMD-QSPEC is constructed based on the initial QSPEC in the message (usually the Initiator QSPEC). The RMD-QSPEC is sent in a intra-domain, independent RESERVE message through the Interior nodes towards the QNR. This intra-domain RESERVE message uses the GIST datagram signaling mechanism. Note that the RMD-QOSM cannot directly specify that the GIST Datagram mode SHOULD be used. This can however be notified by using the GIST API Transfer-Attributes, such as unreliable, low level of security and use of local policy.
当原始保留消息到达入口节点时，基于消息中的初始QSPEC（通常是启动器QSPEC）构造RMD-QSPEC。RMD-QSPEC在域内独立保留消息中通过内部节点发送到QNR。此域内保留消息使用GIST数据报信令机制。请注意，RMD-QOSM不能直接指定应使用GIST数据报模式。但是，这可以通过使用GIST API传输属性来通知，例如不可靠、低安全级别和使用本地策略。
Meanwhile, the original RESERVE message is sent to the Egress node on the path to the QNR using the reliable transport mode of NTLP. Each QoS-NSLP node on the data path processes the intra-domain RESERVE message and checks the availability of resources with either the reservation-based or the measurement-based method.
同时，原始保留消息使用NTLP的可靠传输模式发送到QNR路径上的出口节点。数据路径上的每个QoS NSLP节点处理域内保留消息，并使用基于保留或基于度量的方法检查资源的可用性。
QNE Ingress QNE Interior QNE Interior QNE Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | | |
-------->| RESERVE | | |
+--------------------------------------------->|
| RESERVE' | | |
+-------------->| | |
| | RESERVE' | |
| +-------------->| |
| | | RESERVE' |
| | +------------->|
| | | RESPONSE'|
|<---------------------------------------------+
| | | | RESERVE
| | | +------->
| | | |RESPONSE
| | | |<-------
| | | RESPONSE |
|<---------------------------------------------+
RESPONSE| | | |
<--------| | | |
QNE Ingress QNE Interior QNE Interior QNE Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | | |
-------->| RESERVE | | |
+--------------------------------------------->|
| RESERVE' | | |
+-------------->| | |
| | RESERVE' | |
| +-------------->| |
| | | RESERVE' |
| | +------------->|
| | | RESPONSE'|
|<---------------------------------------------+
| | | | RESERVE
| | | +------->
| | | |RESPONSE
| | | |<-------
| | | RESPONSE |
|<---------------------------------------------+
RESPONSE| | | |
<--------| | | |
Figure 3: Sender-initiated reservation with reduced-state Interior nodes
图3：减少状态内部节点的发送方发起的保留
When the message reaches the Egress node, and the reservation is successful in each Interior node, an intra-domain (local) RESPONSE' is sent towards the Ingress node and the original (end-to-end) RESERVE message is forwarded to the next domain. When the Egress node receives a RESPONSE message from the downstream end, it is forwarded directly to the Ingress node.
当消息到达出口节点，并且在每个内部节点中保留成功时，域内（本地）响应“被发送到入口节点，并且原始（端到端）保留消息被转发到下一个域。当出口节点从下游端接收到响应消息时，它直接转发到入口节点。
If an intermediate node cannot accommodate the new request, it indicates this by marking a single bit in the message, and continues forwarding the message until the Egress node is reached. From the Egress node, an intra-domain RESPONSE' and an original RESPONSE message are sent directly to the Ingress node.
如果中间节点不能容纳新请求，它将通过在消息中标记单个位来指示这一点，并继续转发消息，直到到达出口节点。从出口节点，域内响应'和原始响应消息直接发送到入口节点。
As a consequence, in the stateless/reduced-state domain only sender-initiated reservations can be performed and functions requiring per-flow NTLP or QoS-NSLP states, like summary and reduced refreshes, cannot be used. If per-flow identification is needed, i.e., associating the flow IDs for the reserved resources, Edge nodes act on behalf of Interior nodes.
因此，在无状态/简化状态域中，只能执行发送方发起的保留，并且不能使用需要每流NTLP或QoS NSLP状态的功能，如摘要和简化刷新。如果需要每个流标识，即关联保留资源的流ID，则边缘节点代表内部节点。
The RMD-QOSM is a Diffserv-based bandwidth management methodology that is not able to provide a full Diffserv support. The reason for this is that the RMD-QOSM concept can only support the (Expedited Forwarding) EF-like functionality behavior, but is not able to support the full set of (Assured Forwarding) AF-like functionality. The bandwidth information REQUIRED by the EF-like functionality behavior can be supported by RMD-QOSM carrying the bandwidth information in the <QoS Desired> parameter (see [RFC5975]). The full set of (Assured Forwarding) AF-like functionality requires information that is specified in two token buckets. The RMD-QOSM is not supporting the use of two token buckets and therefore, it is not able to support the full set of AF-functionality. Note however, that RMD-QOSM could also support a single AF PHB, when the traffic or the upper limit of the traffic can be characterized by a single bandwidth parameter. Moreover, it is considered that in case of tunneling, the RMD-QOSM supports only the uniform tunneling mode for Diffserv (see [RFC2983]).
RMD-QOSM是一种基于区分服务的带宽管理方法，无法提供完全的区分服务支持。原因是RMD-QOSM概念只能支持（加速转发）类似EF的功能行为，但不能支持全套（保证转发）类似AF的功能。类EF功能行为所需的带宽信息可由RMD-QOSM支持，RMD-QOSM携带<QoS Desired>参数中的带宽信息（参见[RFC5975]）。全套（保证转发）类似AF的功能需要在两个令牌桶中指定的信息。RMD-QOSM不支持使用两个令牌桶，因此无法支持全套AF功能。然而，注意，当业务量或业务量上限可以由单个带宽参数表征时，RMD-QOSM也可以支持单个AF PHB。此外，考虑到在隧道情况下，RMD-QOSM仅支持区分服务的统一隧道模式（参见[RFC2983]）。
The RMD domain MUST be engineered in such a way that each QNE Ingress maintains information about the smallest MTU that is supported on the links within the RMD domain.
RMD域的设计方式必须确保每个QNE入口维护关于RMD域内链路上支持的最小MTU的信息。
A very important consideration on using RMD-QOSM is that within one RMD domain only one of the following RMD-QOSM schemes can be used at a time. Thus, an RMD router can never process and use two different RMD-QOSM signaling schemes at the same time.
使用RMD-QOSM的一个非常重要的考虑因素是，在一个RMD域内，一次只能使用以下RMD-QOSM方案中的一个。因此，RMD路由器决不能同时处理和使用两种不同的RMD-QOSM信令方案。
However, all RMD QNEs supporting this specification MUST support the combination of the "per-flow RMD reservation-based" and the "severe congestion handling by proportional data packet marking" scheme. If the RMD QNEs support more RMD-QOSM schemes, then the operator of that RMD domain MUST preconfigure all the QNE Edge nodes within one domain such that the <SCH> field included in the "PHR container" (Section
然而，所有支持本规范的RMD QNE必须支持“基于每流RMD预留”和“通过比例数据包标记进行严重拥塞处理”方案的组合。如果RMD QNE支持更多RMD-QOSM方案，则该RMD域的操作员必须预先配置一个域内的所有QNE边缘节点，以便“PHR容器”（第节）中包含的<SCH>字段
4.1.2) and the "PDR Container" (Section 4.1.3) will always use the same value, such that within one RMD domain only one of the below described RMD-QOSM schemes is used at a time.
4.1.2）和“PDR容器”（第4.1.3节）将始终使用相同的值，以便在一个RMD域内，一次仅使用下述RMD-QOSM方案中的一个。
The congestion situations (see Section 2) are solved using an admission control mechanism, e.g., "per-flow congestion notification based on probing", while the severe congestion situations (see Section 2), are solved using the severe congestion handling mechanisms, e.g., "severe congestion handling by proportional data packet marking".
拥塞情况（见第2节）使用准入控制机制解决，例如“基于探测的每流拥塞通知”，而严重拥塞情况（见第2节）使用严重拥塞处理机制解决，例如“通过比例数据包标记进行严重拥塞处理”。
The RMD domain MUST be engineered in such a way that RMD-QOSM messages could be transported using the GIST Query and DATA messages in Q-mode; see [RFC5971]. This means that the Path MTU MUST be engineered in such a way that the RMD-QOSM message are transported without fragmentation. Furthermore, the RMD domain MUST be engineered in such a way to guarantee capacity for the GIST Query and Data messages in Q-mode, within the rate control limits imposed by GIST; see [RFC5971].
RMD域的设计必须确保RMD-QOSM消息可以在Q模式下使用GIST查询和数据消息进行传输；参见[RFC5971]。这意味着路径MTU的设计方式必须确保RMD-QOSM消息的传输不会出现碎片。此外，RMD域的设计必须确保GIST查询和数据消息在Q模式下的容量在GIST规定的速率控制限制内；参见[RFC5971]。
The RMD domain has to be configured such that the GIST context-free flag (C-flag) MUST be set (C=1) for QUERY messages and DATA messages sent in Q-mode; see [RFC5971].
必须对RMD域进行配置，以便必须为以Q模式发送的查询消息和数据消息设置GIST上下文无关标志（C-flag）（C=1）；参见[RFC5971]。
Moreover, the same deployment issues and extensibility considerations described in [RFC5971] and [RFC5978] apply to this document.
此外，[RFC5971]和[RFC5978]中描述的部署问题和可扩展性注意事项同样适用于本文档。
It is important to note that the concepts described in Sections 4.6.1.6.2, 4.6.2.5.2, 4.6.1.6.2, and 4.6.2.5.2 contributed to the PCN WG standardization.
需要注意的是，第4.6.1.6.2节、第4.6.2.5.2节、第4.6.1.6.2节和第4.6.2.5.2节中描述的概念有助于PCN WG标准化。
The available RMD-QOSM/QoS-NSLP signaling schemes are:
可用的RMD-QOSM/QoS NSLP信令方案有：
* "per-flow congestion notification based on probing" (see Sections 4.3.2, 4.6.1.7, and 4.6.2.6). Note that this scheme uses, for severe congestion handling, the "severe congestion handling by proportional data packet marking" (see Sections 4.6.1.6.2 and 4.6.2.5.2). Furthermore, the Interior nodes are considered to be Diffserv aware, but NSIS-unaware nodes (see Section 4.3.2).
* “基于探测的每次流量拥塞通知”（见第4.3.2、4.6.1.7和4.6.2.6节）。注意，对于严重拥塞处理，该方案使用“按比例数据包标记的严重拥塞处理”（见第4.6.1.6.2和4.6.2.5.2节）。此外，内部节点被视为区分服务感知节点，但NSIS感知节点（见第4.3.2节）。
* "per-flow RMD NSIS measurement-based admission control" (see Sections 4.3.2, 4.6.1, and 4.6.2). Note that this scheme uses, for severe congestion handling, the "severe congestion handling by proportional data packet marking" (see Sections 4.6.1.6.2 and 4.6.2.5.2). Furthermore, the Interior nodes are considered to be NSIS-aware nodes (see Section 4.3.2).
* “基于流量RMD NSIS测量的准入控制”（见第4.3.2、4.6.1和4.6.2节）。注意，对于严重拥塞处理，该方案使用“按比例数据包标记的严重拥塞处理”（见第4.6.1.6.2和4.6.2.5.2节）。此外，内部节点被视为NSIS感知节点（见第4.3.2节）。
* "per-flow RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure (see Sections 4.3.3, 4.6.1, 4.6.1.6.1, and 4.6.2.5.1). Note that this scheme uses, for severe congestion handling, the "severe congestion handling by the RMD-QOSM refresh" procedure (see Sections 4.6.1.6.1 and 4.6.2.5.1). Furthermore, the intra-domain sessions supported by the Edge nodes are per-flow sessions (see Section 4.3.3).
* “基于每流RMD预留”与“通过RMD-QOSM刷新进行严重拥塞处理”程序相结合（见第4.3.3节、第4.6.1节、第4.6.1.6.1节和第4.6.2.5.1节）。注意，对于严重拥塞处理，该方案使用“RMD-QOSM刷新的严重拥塞处理”程序（见第4.6.1.6.1和4.6.2.5.1节）。此外，边缘节点支持的域内会话是按流会话（见第4.3.3节）。
* "per-flow RMD reservation-based" in combination with the "severe the congestion handling by proportional data packet marking" procedure (see Sections 4.3.3, 4.6.1, 4.6.1.6.2, and 4.6.2.5.2). Note that this scheme uses, for severe congestion handling, the "severe congestion handling by proportional data packet marking" procedure (see Sections 4.6.1.6.2 and 4.6.2.5.2). Furthermore, the intra-domain sessions supported by the Edge nodes are per-flow sessions (see Section 4.3.3).
* “基于每流RMD预留”与“通过比例数据包标记进行严重拥塞处理”程序相结合（见第4.3.3节、第4.6.1节、第4.6.1.6.2节和第4.6.2.5.2节）。注意，对于严重拥塞处理，该方案使用“按比例数据包标记的严重拥塞处理”程序（见第4.6.1.6.2节和第4.6.2.5.2节）。此外，边缘节点支持的域内会话是按流会话（见第4.3.3节）。
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure (see Sections 4.3.1, 4.6.1, 4.6.1.6.1, and 4.6.2.5.1). Note that this scheme uses, for severe congestion handling, the "severe congestion handling by the RMD-QOSM refresh" procedure (see Sections 4.6.1.6.1 and 4.6.2.5.1). Furthermore, the intra-domain sessions supported by the Edge nodes are per-aggregate sessions (see Section 4.3.1). Moreover, this scheme can be considered to be a reservation-based scheme, since the RMD Interior nodes are reduced-state nodes, i.e., they do not store NTLP/GIST states, but they do store per PHB-aggregated QoS-NSLP reservation states.
* “基于每个总RMD预留”与“通过RMD-QOSM刷新进行严重拥塞处理”程序相结合（见第4.3.1、4.6.1、4.6.1.6.1和4.6.2.5.1节）。注意，对于严重拥塞处理，该方案使用“RMD-QOSM刷新的严重拥塞处理”程序（见第4.6.1.6.1和4.6.2.5.1节）。此外，边缘节点支持的域内会话是每个聚合会话（参见第4.3.1节）。此外，该方案可被视为基于保留的方案，因为RMD内部节点是简化状态节点，即，它们不存储NTLP/GIST状态，但它们存储每个PHB聚合QoS NSLP保留状态。
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure (see Sections 4.3.1, 4.6.1, 4.6.1.6.2, and 4.6.2.5.2). Note that this scheme uses, for severe congestion handling, the "severe congestion handling by proportional data packet marking" procedure (see Sections 4.6.1.6.2 and 4.6.2.5.2). Furthermore, the intra-domain sessions supported by the Edge nodes are per-aggregate sessions (see Section 4.3.1). Moreover, this scheme can be considered to be a reservation-based scheme, since the RMD Interior nodes are reduced-state nodes, i.e., they do not store NTLP/GIST states, but they do store per PHB-aggregated QoS-NSLP reservation states.
* 结合“按比例数据包标记的严重拥塞处理”程序（见第4.3.1节、第4.6.1节、第4.6.1.6.2节和第4.6.2.5.2节），“基于每个总RMD预留”。注意，对于严重拥塞处理，该方案使用“按比例数据包标记的严重拥塞处理”程序（见第4.6.1.6.2节和第4.6.2.5.2节）。此外，边缘节点支持的域内会话是每个聚合会话（参见第4.3.1节）。此外，该方案可被视为基于保留的方案，因为RMD内部节点是简化状态节点，即，它们不存储NTLP/GIST状态，但它们存储每个PHB聚合QoS NSLP保留状态。
This section describes the RMD-QOSM in more detail. In particular, it defines the role of stateless and reduced-state QNEs, the RMD-QOSM QSPEC Object, the format of the RMD-QOSM QoS-NSLP messages, and how QSPECs are processed and used in different protocol operations.
本节更详细地描述了RMD-QOSM。特别是，它定义了无状态和简化状态QNE的角色、RMD-QOSM QSPEC对象、RMD-QOSM QoS NSLP消息的格式，以及如何在不同的协议操作中处理和使用QSPEC。
The RMD-QOSM uses the QSPEC format specified in [RFC5975]. The Initiator/Local QSPEC bit, i.e., <I> is set to "Local" (i.e., "1") and the <QSPEC Proc> is set as follows:
RMD-QOSM使用[RFC5975]中规定的QSPEC格式。启动器/本地QSPEC位，即<i>设置为“本地”（即“1”），并且<QSPEC Proc>设置如下：
* Message Sequence = 0: Sender initiated * Object combination = 0: <QoS Desired> for RESERVE and <QoS Reserved> for RESPONSE
* 消息序列=0:发送方发起的*对象组合=0:<QoS期望>用于保留，而<QoS保留>用于响应
The <QSPEC Version> used by RMD-QOSM is the default version, i.e., "0", see [RFC5975]. The <QSPEC Type> value used by the RMD-QOSM is specified in [RFC5975] and is equal to "2". The <Traffic Handling Directives> contains the following fields:
RMD-QOSM使用的<QSPEC版本>是默认版本，即“0”，请参阅[RFC5975]。[RFC5975]中规定了RMD-QOSM使用的<QSPEC类型>值，该值等于“2”。<Traffic Handling Directions>包含以下字段：
<Traffic Handling Directives> = <PHR container> <PDR container>
<Traffic Handling Directives> = <PHR container> <PDR container>
The Per-Hop Reservation container (PHR container) and the Per-Domain Reservation container (PDR container) are specified in Sections 4.1.2 and 4.1.3, respectively. The <PHR container> contains the traffic handling directives for intra-domain communication and reservation. The <PDR container> contains additional traffic handling directives that are needed for edge-to-edge communication. The parameter IDs used by the <PHR container> and <PDR container> are assigned by IANA; see Section 6.
每跳保留容器（PHR容器）和每域保留容器（PDR容器）分别在第4.1.2节和第4.1.3节中规定。<PHR container>包含域内通信和保留的流量处理指令。<PDR container>包含边到边通信所需的附加流量处理指令。<PHR container>和<PDR container>使用的参数ID由IANA分配；见第6节。
The RMD-QOSM <QoS Desired> and <QoS Reserved>, are specified in Section 4.1.1. The RMD-QOSM <QoS Desired> and <QoS Reserved> and the <PHR container> are used and processed by the Edge and Interior nodes. The <PDR container> field is only processed by Edge nodes.
第4.1.1节规定了RMD-QOSM<QoS Desired>和<QoS Reserved>。边缘和内部节点使用和处理RMD-QOSM<QoS Desired>和<QoS Reserved>以及<PHR container>。<PDR container>字段仅由边缘节点处理。
The RESERVE message contains only the <QoS Desired> object [RFC5975]. The <QoS Reserved> object is carried by the RESPONSE message.
保留消息仅包含<QoS Desired>对象[RFC5975]。响应消息携带<QoS Reserved>对象。
In RMD-QOSM, the <QoS Desired> and <QoS Reserved> objects contain the following parameters:
在RMD-QOSM中，<QoS Desired>和<QoS Reserved>对象包含以下参数：
<QoS Desired> = <TMOD-1> <PHB Class> <Admission Priority>
<QoS Reserved> = <TMOD-1> <PHB Class> <Admission Priority>
<QoS Desired> = <TMOD-1> <PHB Class> <Admission Priority>
<QoS Reserved> = <TMOD-1> <PHB Class> <Admission Priority>
The bit format of the <PHB Class> (see [RFC5975] and Figures 4 and 5) and <Admission Priority> complies with the bit format specified in [RFC5975].
<PHB类>（参见[RFC5975]以及图4和图5）和<Allocation Priority>的位格式符合[RFC5975]中规定的位格式。
Note that for the RMD-QOSM, a reservation established without an <Admission Priority> parameter is equivalent to a reservation established with an <Admission Priority> whose value is 1.
注意，对于RMD-QOSM，不使用<Admission Priority>参数建立的保留等同于使用值为1的<Admission Priority>建立的保留。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 X 0|
+---+---+---+---+---+---+---+---+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 X 0|
+---+---+---+---+---+---+---+---+
Figure 4: DSCP parameter
图4:DSCP参数
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB ID code |0 0 X X|
+---+---+---+---+---+---+---+---+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB ID code |0 0 X X|
+---+---+---+---+---+---+---+---+
Figure 5: PHB ID Code parameter
图5:PHB ID代码参数
This section describes the parameters used by the PHR container, which are used by the RMD-QOSM functionality available at the Interior nodes.
本节描述PHR容器使用的参数，这些参数由内部节点上可用的RMD-QOSM功能使用。
<PHR container> = <O> <K> <S> <M>, <Admitted Hops>, <B> <Hop_U> <Time
Lag> <SCH> <Max Admitted Hops>
<PHR container> = <O> <K> <S> <M>, <Admitted Hops>, <B> <Hop_U> <Time
Lag> <SCH> <Max Admitted Hops>
The bit format of the PHR container can be seen in Figure 6. Note that in Figure 6 <Hop_U> is represented as <U>. Furthermore, in Figure 6, <Max Admitted Hops> is represented as <Max Adm Hops>.
PHR容器的位格式如图6所示。注意，在图6中，<Hop_>表示为<U>。此外，在图6中，<Max accounted Hops>表示为<Max Adm Hops>。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| Parameter ID |r|r|r|r| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|M| Admitted Hops|B|U| Time Lag |O|K| SCH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Adm Hops | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| Parameter ID |r|r|r|r| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|M| Admitted Hops|B|U| Time Lag |O|K| SCH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Adm Hops | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: PHR container
图6:PHR容器
Parameter ID: 12-bit field, indicating the PHR type: PHR_Resource_Request, PHR_Release_Request, PHR_Refresh_Update.
参数ID:12位字段，表示PHR类型：PHR_资源请求、PHR_释放请求、PHR_刷新更新。
"PHR_Resource_Request" (Parameter ID = 17): initiate or update the traffic class reservation state on all nodes located on the communication path between the QNE(Ingress) and QNE(Egress) nodes.
“PHR_Resource_Request”（参数ID=17）：在位于QNE（入口）和QNE（出口）节点之间的通信路径上的所有节点上启动或更新流量等级保留状态。
"PHR_Release_Request" (Parameter ID = 18): explicitly release, by subtraction, the reserved resources for a particular flow from a traffic class reservation state.
“PHR_Release_Request”（参数ID=18）：通过减法从流量类保留状态显式释放特定流的保留资源。
"PHR_Refresh_Update" (Parameter ID = 19): refresh the traffic class reservation soft state on all nodes located on the communication path between the QNE(Ingress) and QNE(Egress) nodes according to a resource reservation request that was successfully processed during a previous refresh period.
“PHR_Refresh_Update”（参数ID=19）：根据在上一个刷新期间成功处理的资源保留请求，刷新位于QNE（入口）和QNE（出口）节点之间的通信路径上的所有节点上的流量类保留软状态。
<S> (Severe Congestion): 1 bit. In the case of a route change, refreshing RESERVE messages follow the new data path, and hence resources are requested there. If the resources are not sufficient to accommodate the new traffic, severe congestion occurs. Severe congested Interior nodes SHOULD notify Edge QNEs about the congestion by setting the <S> bit.
<S> （严重拥塞）：1位。在路由更改的情况下，刷新保留消息会跟随新的数据路径，因此会在那里请求资源。如果资源不足以容纳新的流量，就会发生严重的拥塞。严重拥塞的内部节点应通过设置<S>位通知边缘QNE拥塞情况。
<O> (Overload): 1 bit. This field is used during the severe congestion handling scheme that is using the RMD-QOSM refresh procedure. This bit is set when an overload on a QNE Interior node is detected and when this field is carried by the "PHR_Refresh_Update" container. <O> SHOULD be set to"1" if the <S> bit is set. For more details, see Section 4.6.1.6.1.
<O> （过载）：1位。此字段在使用RMD-QOSM刷新过程的严重拥塞处理方案期间使用。当检测到QNE内部节点上的过载并且“PHR_Refresh_Update”容器携带此字段时，设置此位<O> 如果设置了<S>位，则应设置为“1”。有关更多详细信息，请参见第4.6.1.6.1节。
<M>: 1 bit. In the case of unsuccessful resource reservation or resource query in an Interior QNE, this QNE sets the <M> bit in order to notify the Egress QNE.
<M> ：1位。在内部QNE中的资源保留或资源查询失败的情况下，该QNE设置<M>位以通知出口QNE。
<Admitted Hops>: 8-bit field. The <Admitted Hops> counts the number of hops in the RMD domain where the reservation was successful. The <Admitted Hops> is set to "0" when a RESERVE message enters a domain and it MUST be incremented by each Interior QNE, provided that the <Hop_U> bit is not set. However, when a QNE that does not have sufficient resources to admit the reservation is reached, the <M> bit is set, and the <Admitted Hops> value is frozen, by setting the <Hop_U> bit to "1". Note that the <Admitted Hops> parameter in combination with the <Max Admitted Hops> and <K> parameters are used during the RMD partial release procedures (see Section 4.6.1.5.2).
<允许跳数>：8位字段。<Allocated Hops>统计RMD域中预订成功的跃点数。当保留消息进入域时，<acempted Hops>设置为“0”，并且必须由每个内部QNE递增，前提是未设置<Hop_>位。然而，当到达没有足够资源允许保留的QNE时，通过将<Hop_>位设置为“1”，设置<M>位，并冻结<acempted Hops>值。请注意，在RMD部分释放程序期间，使用<允许跳数>参数以及<最大允许跳数>和<K>参数（见第4.6.1.5.2节）。
<Hop_U> (NSLP_Hops unset): 1 bit. The QNE(Ingress) node MUST set the
<Hop_U> parameter to 0. This parameter SHOULD be set to "1" by a
node when the node does not increase the <Admitted Hops> value. This
is the case when an RMD-QOSM reservation-based node is not admitting
the reservation request. When <Hop_U> is set to "1", the <Admitted
<Hop_U> (NSLP_Hops unset): 1 bit. The QNE(Ingress) node MUST set the
<Hop_U> parameter to 0. This parameter SHOULD be set to "1" by a
node when the node does not increase the <Admitted Hops> value. This
is the case when an RMD-QOSM reservation-based node is not admitting
the reservation request. When <Hop_U> is set to "1", the <Admitted
Hops> SHOULD NOT be changed. Note that this flag, in combination with the <Admitted Hops> flag, are used to locate the last node that successfully processed a reservation request (see Section 4.6.1.2).
不应更改跃点>。请注意，此标志与<允许的跃点>标志一起用于定位成功处理预订请求的最后一个节点（见第4.6.1.2节）。
<B>: 1 bit. When set to "1", it indicates a bidirectional reservation.
<B> ：1位。当设置为“1”时，表示双向预约。
<Time Lag>: It represents the ratio between the "T_Lag" parameter, which is the time difference between the departure time of the last sent "PHR_Refresh_Update" control information container and the departure time of the "PHR_Release_Request" control information container, and the length of the refresh period, "T_period", see Section 4.6.1.5.
<Time Lag>：它表示“T_Lag”参数（即上次发送的“PHR_Refresh_Update”控制信息容器的离开时间与“PHR_Release_Request”控制信息容器的离开时间之间的时间差）与刷新周期长度“T_周期”之间的比率，见第4.6.1.5节。
<K>: 1 bit. When set to "1", it indicates that the resources/bandwidth carried by a tearing RESERVE MUST NOT be released, and the resources/bandwidth carried by a non-tearing RESERVE MUST NOT be reserved/refreshed. For more details, see Section 4.6.1.5.2.
<K> ：1位。当设置为“1”时，表示撕裂保留所携带的资源/带宽不能被释放，非撕裂保留所携带的资源/带宽不能被保留/刷新。有关更多详细信息，请参见第4.6.1.5.2节。
<Max Admitted Hops>: 8 bits. The <Admitted Hops> value that has been carried by the <PHR container> field used to identify the RMD reservation-based node that admitted or processed a "PHR_Resource_Request".
<最大允许跳数>：8位。由<PHR container>字段携带的<accounted Hops>值，用于标识允许或处理“PHR_资源_请求”的基于RMD保留的节点。
<SCH>: 3 bits. The <SCH> value that is used to specify which of the 6 RMD-QOSM scenarios (see Section 3.2.3) MUST be used within the RMD domain. The operator of an RMD domain MUST preconfigure all the QNE Edge nodes within one domain such that the <SCH> field included in the "PHR container", will always use the same value, such that within one RMD domain only one of the below described RMD-QOSM schemes can be used at a time. All the QNE Interior nodes MUST interpret this field before processing any other PHR container payload fields. The currently defined <SCH> values are:
<SCH>：3位。用于指定RMD域内必须使用6种RMD-QOSM方案（见第3.2.3节）中的哪种方案的<SCH>值。RMD域的操作员必须预先配置一个域内的所有QNE边缘节点，以便“PHR容器”中包含的<SCH>字段始终使用相同的值，以便在一个RMD域内一次只能使用以下描述的RMD-QOSM方案中的一个。所有QNE内部节点必须在处理任何其他PHR容器有效载荷字段之前解释此字段。当前定义的<SCH>值为：
o 0: RMD-QOSM scheme MUST be "per-flow congestion notification based on probing";
o 0:RMD-QOSM方案必须是“基于探测的每个流量拥塞通知”；
o 1: RMD-QOSM scheme MUST be "per-flow RMD NSIS measurement-based admission control",
o 1:RMD-QOSM方案必须是“基于每流RMD NSIS测量的准入控制”，
o 2: RMD-QOSM scheme MUST be "per-flow RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
o 2:RMD-QOSM方案必须是“基于每流RMD预留”的方案，并结合“通过RMD-QOSM刷新进行严重拥塞处理”程序；
o 3 : RMD-QOSM scheme MUST be "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure;
o 3:RMD-QOSM方案必须是“基于每流RMD预留”的方案，并结合“按比例数据包标记的严重拥塞处理”程序；
o 4: RMD-QOSM scheme MUST be "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
o 4:RMD-QOSM方案必须是“基于每个总RMD预留”的方案，并结合“通过RMD-QOSM刷新进行严重拥塞处理”程序；
o 5: RMD-QOSM scheme MUST be "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure;
o 5:RMD-QOSM方案必须是“基于每个聚合RMD预留”的方案，并结合“通过比例数据包标记进行严重拥塞处理”程序；
o 6 - 7: reserved.
o 6-7：保留。
The default value of the <SCH> field MUST be set to the value equal to 3.
<SCH>字段的默认值必须设置为等于3的值。
This section describes the parameters of the PDR container, which are used by the RMD-QOSM functionality available at the Edge nodes.
本节介绍PDR容器的参数，这些参数由边缘节点上可用的RMD-QOSM功能使用。
The bit format of the PDR container can be seen in Figure 7.
PDR容器的位格式如图7所示。
<PDR container> = <O> <S> <M>
<Max Admitted Hops> <B> <SCH> [<PDR Bandwidth>]
<PDR container> = <O> <S> <M>
<Max Admitted Hops> <B> <SCH> [<PDR Bandwidth>]
In Figure 7, note that <Max Admitted Hops> is represented as <Max Adm Hops>.
在图7中，请注意，<Max accounted Hops>表示为<Max Adm Hops>。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| Parameter ID |r|r|r|r| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|M| Max Adm Hops |B|O| SCH | EMPTY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDR Bandwidth(32-bit IEEE floating point.number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| Parameter ID |r|r|r|r| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|M| Max Adm Hops |B|O| SCH | EMPTY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDR Bandwidth(32-bit IEEE floating point.number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: PDR container
图7:PDR容器
Parameter ID: 12-bit field identifying the type of <PDR container> field.
参数ID:12位字段，标识<PDR container>字段的类型。
"PDR_Reservation_Request" (Parameter ID = 20): generated by the QNE(Ingress) node in order to initiate or update the QoS-NSLP per-domain reservation state in the QNE(Egress) node.
“PDR_保留_请求”（参数ID=20）：由QNE（入口）节点生成，以便在QNE（出口）节点中启动或更新QoS NSLP每域保留状态。
"PDR_Refresh_Request" (Parameter ID = 21): generated by the QNE(Ingress) node and sent to the QNE(Egress) node to refresh, in case needed, the QoS-NSLP per-domain reservation states located in the QNE(Egress) node.
“PDR_刷新_请求”（参数ID=21）：由QNE（入口）节点生成并发送到QNE（出口）节点，以在需要时刷新QNE（出口）节点中的QoS NSLP每域保留状态。
"PDR_Release_Request" (Parameter ID = 22): generated and sent by the QNE(Ingress) node to the QNE(Egress) node to release the per-domain reservation states explicitly.
“PDR_Release_Request”（参数ID=22）：由QNE（入口）节点生成并发送到QNE（出口）节点，以明确释放每个域的保留状态。
"PDR_Reservation_Report" (Parameter ID = 23): generated and sent by the QNE(Egress) node to the QNE(Ingress) node to report that a "PHR_Resource_Request" and a "PDR_Reservation_Request" traffic handling directive field have been received and that the request has been admitted or rejected.
“PDR_Reservation_Report”（参数ID=23）：由QNE（出口）节点生成并发送到QNE（入口）节点，以报告已接收到“PHR_资源_请求”和“PDR_Reservation_请求”流量处理指令字段，且请求已被接纳或拒绝。
"PDR_Refresh_Report" (Parameter ID = 24) generated and sent by the QNE(Egress) node in case needed, to the QNE(Ingress) node to report that a "PHR_Refresh_Update" traffic handling directive field has been received and has been processed.
QNE（出口）节点在需要时生成并发送到QNE（入口）节点的“PDR_刷新_报告”（参数ID=24），以报告“PHR_刷新_更新”流量处理指令字段已接收并已处理。
"PDR_Release_Report" (Parameter ID = 25) generated and sent by the QNE(Egress) node in case needed, to the QNE(Ingress) node to report that a "PHR_Release_Request" and a "PDR_Release_Request" traffic handling directive field have been received and have been processed.
QNE（出口）节点在需要时生成并发送到QNE（入口）节点的“PDR_释放_报告”（参数ID=25），以报告“PHR_释放_请求”和“PDR_释放_请求”流量处理指令字段已接收并已处理。
"PDR_Congestion_Report" (Parameter ID = 26): generated and sent by the QNE(Egress) node to the QNE(Ingress) node and used for congestion notification.
“PDR_拥塞报告”（参数ID=26）：由QNE（出口）节点生成并发送到QNE（入口）节点，用于拥塞通知。
<S> (PDR Severe Congestion): 1 bit. Specifies if a severe congestion situation occurred. It can also carry the <S> parameter of the <PHR_Resource_Request> or <PHR_Refresh_Update> fields.
<S> （PDR严重拥塞）：1位。指定是否发生严重拥塞情况。它还可以携带<PHR\u Resource\u Request>或<PHR\u Refresh\u Update>字段的<S>参数。
<O> (Overload): 1 bit. This field is used during the severe congestion handling scheme that is using the RMD-QOSM refresh procedure. This bit is set when an overload on a QNE Interior node is detected and when this field is carried by the "PDR_Congestion_Report" container. <O> SHOULD be set to "1" if the <S> bit is set. For more details, see Section 4.6.1.6.1.
<O> （过载）：1位。此字段在使用RMD-QOSM刷新过程的严重拥塞处理方案期间使用。当检测到QNE内部节点上的过载并且“PDR_拥塞_报告”容器携带此字段时，设置此位<O> 如果设置了<S>位，则应设置为“1”。有关更多详细信息，请参见第4.6.1.6.1节。
<M> (PDR Marked): 1 bit. Carries the <M> value of the "PHR_Resource_Request" or "PHR_Refresh_Update" traffic handling directive field.
<M> （PDR标记）：1位。携带“PHR_资源_请求”或“PHR_刷新_更新”流量处理指令字段的<M>值。
<B>: 1 bit. Indicates bidirectional reservation.
<B> ：1位。表示双向预订。
<Max Admitted Hops>: 8 bits. The <Admitted Hops> value that has been carried by the <PHR container> field used to identify the RMD reservation-based node that admitted or processed a "PHR_Resource_Request".
<最大允许跳数>：8位。由<PHR container>字段携带的<accounted Hops>值，用于标识允许或处理“PHR_资源_请求”的基于RMD保留的节点。
<PDR Bandwidth>: 32 bits. This field specifies the bandwidth that either applies when the <B> flag is set to "1" and when this parameter is carried by a RESPONSE message or when a severe congestion occurs and the QNE Edges maintain an aggregated intra-domain QoS-NSLP operational state and it is carried by a NOTIFY message. In the situation that the <B> flag is set to "1", this parameter specifies the requested bandwidth that has to be reserved by a node in the reverse direction and when the intra-domain signaling procedures require a bidirectional reservation procedure. In the severe congestion situation, this parameter specifies the bandwidth that has to be released.
<PDR带宽>：32位。此字段指定当<B>标志设置为“1”且响应消息携带此参数时，或当发生严重拥塞且QNE边缘保持聚合域内QoS NSLP操作状态且由NOTIFY消息携带时应用的带宽。在<B>标志被设置为“1”的情况下，该参数指定节点必须在反向和域内信令过程需要双向预留过程时预留的请求带宽。在严重拥塞情况下，此参数指定必须释放的带宽。
<SCH>: 3 bits. The <SCH> value that is used to specify which of the 6 RMD scenarios (see Section 3.2.3) MUST be used within the RMD domain. The operator of an RMD domain MUST preconfigure all the QNE Edge nodes within one domain such that the <SCH> field included in the "PDR container", will always use the same value, such that within one RMD domain only one of the below described RMD-QOSM schemes can be used at a time. All the QNE Interior nodes MUST interpret this field before processing any other <PDR container> payload fields. The currently defined <SCH> values are:
<SCH>：3位。用于指定RMD域内必须使用6种RMD方案中的哪一种（见第3.2.3节）的<SCH>值。RMD域的操作员必须预先配置一个域内的所有QNE边缘节点，以便“PDR容器”中包含的<SCH>字段始终使用相同的值，以便在一个RMD域内一次只能使用以下描述的RMD-QOSM方案中的一个。在处理任何其他<PDR container>有效负载字段之前，所有QNE内部节点必须解释此字段。当前定义的<SCH>值为：
o 0: RMD-QOSM scheme MUST be "per-flow congestion notification based on probing";
o 0:RMD-QOSM方案必须是“基于探测的每个流量拥塞通知”；
o 1: RMD-QOSM scheme MUST be "per-flow RMD NSIS measurement-based admission control";
o 1:RMD-QOSM方案必须是“基于每流RMD NSIS测量的准入控制”；
o 2: RMD-QOSM scheme MUST be "per-flow RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
o 2:RMD-QOSM方案必须是“基于每流RMD预留”的方案，并结合“通过RMD-QOSM刷新进行严重拥塞处理”程序；
o 3 : RMD-QOSM scheme MUST be "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure;
o 3:RMD-QOSM方案必须是“基于每流RMD预留”的方案，并结合“按比例数据包标记的严重拥塞处理”程序；
o 4: RMD-QOSM scheme MUST be "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
o 4:RMD-QOSM方案必须是“基于每个总RMD预留”的方案，并结合“通过RMD-QOSM刷新进行严重拥塞处理”程序；
o 5: RMD-QOSM scheme MUST be "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure;
o 5:RMD-QOSM方案必须是“基于每个聚合RMD预留”的方案，并结合“通过比例数据包标记进行严重拥塞处理”程序；
o 6 - 7: reserved.
o 6-7：保留。
The default value of the <SCH> field MUST be set to the value equal to 3.
<SCH>字段的默认值必须设置为等于3的值。
The format of the messages used by the RMD-QOSM complies with the QoS-NSLP and QSPEC template specifications. The QSPEC used by RMD-QOSM is denoted in this document as RMD-QSPEC and is described in Section 4.1.
RMD-QOSM使用的消息格式符合QoS NSLP和QSPEC模板规范。RMD-QOSM使用的QSPEC在本文件中表示为RMD-QSPEC，并在第4.1节中描述。
The QoS-NSLP state creation and management is specified in [RFC5974]. This section describes the state creation and management functions of the Resource Management Function (RMF) in the RMD nodes.
[RFC5974]中规定了QoS NSLP状态的创建和管理。本节介绍RMD节点中资源管理功能（RMF）的状态创建和管理功能。
The QNE Edges maintain both the intra-domain QoS-NSLP operational and reservation states, while the QNE Interior nodes maintain only reservation states. The structure of the intra-domain QoS-NSLP operational state used by the QNE Edges is specified in [RFC5974].
QNE边缘保持域内QoS NSLP操作和保留状态，而QNE内部节点仅保持保留状态。[RFC5974]中规定了QNE边缘使用的域内QoS NSLP操作状态的结构。
In this case, the intra-domain sessions supported by the Edges are per-aggregate sessions that have a one-to-many relationship to the per-flow end-to-end states supported by the same Edge.
在这种情况下，边缘支持的域内会话是每聚合会话，该会话与同一边缘支持的每流端到端状态具有一对多关系。
Note that the method of selecting the end-to-end sessions that form an aggregate is not specified in this document. An example of how this can be accomplished is by monitoring the GIST routing states used by the end-to-end sessions and grouping the ones that use the same <PHB Class>, QNE Ingress and QNE Egress addresses, and the value of the priority level. Note that this priority level should be deduced from the priority parameters carried by the initial QSPEC object.
请注意，本文档中未指定选择形成聚合的端到端会话的方法。如何实现这一点的一个示例是通过监视端到端会话使用的GIST路由状态，并对使用相同<PHB Class>、QNE入口和QNE出口地址以及优先级值的会话进行分组。请注意，此优先级应根据初始QSPEC对象携带的优先级参数推导得出。
The operational state of this aggregated intra-domain session MUST contain a list with BOUND-SESSION-IDs.
此聚合域内会话的操作状态必须包含具有绑定会话ID的列表。
The structure of the list depends on whether a unidirectional reservation or a bidirectional reservation is supported.
列表的结构取决于支持单向保留还是双向保留。
When the operational state (at QNE Ingress and QNE Egress) supports unidirectional reservations, then this state MUST contain a list with BOUND-SESSION-IDs maintaining the <SESSION-ID> values of its bound end-to-end sessions. The Binding_Code associated with this BOUND-
当操作状态（QNE入口和QNE出口）支持单向保留时，该状态必须包含一个绑定会话ID的列表，该列表维护其绑定的端到端会话的<SESSION-ID>值。与此绑定关联的绑定\u代码-
SESSION-ID is set to code (Aggregated sessions). Thus, the operational state maintains a list of BOUND-SESSION-ID entries. Each entry is created when an end-to-end session joins the aggregated intra-domain session and is removed when an end-to-end session leaves the aggregate.
会话ID设置为代码（聚合会话）。因此，操作状态维护绑定会话ID条目的列表。每个条目在端到端会话加入聚合的域内会话时创建，在端到端会话离开聚合时删除。
It is important to emphasize that, in this case, the operational state (at QNE Ingress and QNE Egress) that is maintained by each end-to-end session bound to the aggregated intra-domain session MUST contain in the BOUND-SESSION-ID, the <SESSION-ID> value of the bound tunneled intra-domain (aggregate) session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Aggregated sessions).
必须强调的是，在这种情况下，绑定到聚合域内会话的每个端到端会话所保持的操作状态（在QNE入口和QNE出口）必须包含绑定隧道域内（聚合）会话的<session-ID>值。与此绑定会话ID关联的绑定代码设置为代码（聚合会话）。
When the operational state (at QNE Ingress and QNE Egress) supports bidirectional reservations, the operational state MUST contain a list of BOUND-SESSION-ID sets. Each set contains two BOUND-SESSION-IDs. One of the BOUND-SESSION-IDs maintains the <SESSION-ID> value of one of bound end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Aggregated sessions). Another BOUND-SESSION-ID, within the same set entry, maintains the SESSION-ID of the bidirectional bound end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Bidirectional sessions).
当操作状态（QNE入口和QNE出口）支持双向保留时，操作状态必须包含绑定会话ID集列表。每个集合包含两个绑定的会话ID。一个绑定会话ID维护一个绑定的端到端会话的<SESSION-ID>值。与此绑定会话ID关联的绑定代码设置为代码（聚合会话）。同一集合项中的另一个绑定会话ID维护双向绑定端到端会话的会话ID。与此绑定会话ID关联的绑定代码设置为代码（双向会话）。
Note that, in each set, a one-to-one relation exists between each BOUND-SESSION-ID with Binding_Code set to (Aggregate sessions) and each BOUND-SESSION-ID with Binding_Code set to (bidirectional sessions). Each set is created when an end-to-end session joins the aggregated operational state and is removed when an end-to-end session leaves the aggregated operational state.
注意，在每个集合中，Binding_Code设置为（聚合会话）的每个绑定SESSION-ID与Binding_Code设置为（双向会话）的每个绑定SESSION-ID之间存在一对一的关系。每个集合在端到端会话加入聚合操作状态时创建，在端到端会话离开聚合操作状态时删除。
It is important to emphasize that, in this case, the operational state (at QNE Ingress and QNE Egress) that is maintained by each end-to-end session bound to the aggregated intra-domain session it MUST contain two types of BOUND-SESSION-IDs. One is the BOUND-SESSION-ID that MUST contain the <SESSION-ID> value of the bound tunneled aggregated intra-domain session that is using the Binding_Code set to (Aggregated sessions). The other BOUND-SESSION-ID maintains the SESSION-ID of the bound bidirectional end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Bidirectional sessions).
必须强调的是，在这种情况下，绑定到聚合域内会话的每个端到端会话所保持的操作状态（QNE入口和QNE出口）必须包含两种类型的绑定会话ID。一个是绑定会话ID，它必须包含绑定隧道聚合域内会话的<SESSION-ID>值，该会话使用的是设置为（聚合会话）的绑定\u代码。另一个绑定会话ID维护绑定的双向端到端会话的会话ID。与此绑定会话ID关联的绑定代码设置为代码（双向会话）。
When the QNE Edges use aggregated QoS-NSLP reservation states, then the <PHB Class> value and the size of the aggregated reservation, e.g., reserved bandwidth, have to be maintained. Note that this type of aggregation is an edge-to-edge aggregation and is similar to the aggregation type specified in [RFC3175].
当QNE边缘使用聚合QoS NSLP保留状态时，必须保持<PHB Class>值和聚合保留的大小，例如保留带宽。请注意，这种类型的聚合是边到边聚合，与[RFC3175]中指定的聚合类型类似。
The size of the aggregated reservations needs to be greater or equal to the sum of bandwidth of the inter-domain (end-to-end) reservations/sessions it aggregates (e.g., see Section 1.4.4 of [RFC3175]).
聚合保留的大小需要大于或等于其聚合的域间（端到端）保留/会话的带宽总和（例如，参见[RFC3175]第1.4.4节）。
A policy can be used to maintain the amount of REQUIRED bandwidth on a given aggregated reservation by taking into account the sum of the underlying inter-domain (end-to-end) reservations, while endeavoring to change reservation less frequently. This MAY require a trend analysis. If there is a significant probability that in the next interval of time the current aggregated reservation is exhausted, the Ingress router MUST predict the necessary bandwidth and request it. If the Ingress router has a significant amount of bandwidth reserved, but has very little probability of using it, the policy MAY predict the amount of bandwidth REQUIRED and release the excess. To increase or decrease the aggregate, the RMD modification procedures SHOULD be used (see Section 4.6.1.4).
策略可用于通过考虑基础域间（端到端）保留的总和来维持给定聚合保留上所需的带宽量，同时尽量减少更改保留的频率。这可能需要进行趋势分析。如果在下一个时间间隔内，当前聚合的保留很可能耗尽，则入口路由器必须预测必要的带宽并请求它。如果入口路由器保留了大量带宽，但使用它的可能性很小，则策略可以预测所需的带宽量并释放多余的带宽。为了增加或减少骨料，应使用RMD修改程序（见第4.6.1.4节）。
The QNE Interior nodes are reduced-state nodes, i.e., they do not store NTLP/GIST states, but they do store per PHB-aggregated QoS-NSLP reservation states. These reservation states are maintained and refreshed in the same way as described in Section 4.3.3.
QNE内部节点是简化状态节点，即，它们不存储NTLP/GIST状态，但它们存储每个PHB聚合QoS NSLP保留状态。这些保留状态的维护和刷新方式与第4.3.3节所述相同。
The QNE Edges maintain per-flow intra-domain QoS-NSLP operational and reservation states that contain similar data structures as those described in Section 4.3.1. The main difference is associated with the different types of the used Message-Routing-Information (MRI) and the bound end-to-end sessions. The structure of the maintained BOUND-SESSION-IDs depends on whether a unidirectional reservation or a bidirectional reservation is supported.
QNE边缘保持每流域内QoS NSLP操作和保留状态，这些状态包含与第4.3.1节所述数据结构类似的数据结构。主要区别在于使用的消息路由信息（MRI）和绑定的端到端会话的不同类型。维护的绑定会话ID的结构取决于支持单向保留还是双向保留。
When unidirectional reservations are supported, the operational state associated with this per-flow intra-domain session MUST contain in the BOUND-SESSION-ID the <SESSION-ID> value of its bound end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Tunneled and end-to-end sessions).
当支持单向保留时，与此每流域内会话相关联的操作状态必须在绑定会话ID中包含其绑定端到端会话的<session-ID>值。与此绑定会话ID关联的绑定_代码设置为代码（隧道和端到端会话）。
When bidirectional reservations are supported, the operational state (at QNE Ingress and QNE Egress) MUST contain two types of BOUND-SESSION-IDs. One is the BOUND-SESSION-ID that maintains the <SESSION-ID> value of the bound tunneled per-flow intra-domain session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Tunneled and end-to-end sessions).
当支持双向保留时，操作状态（QNE入口和QNE出口）必须包含两种类型的绑定会话ID。一个是BOUND-SESSION-ID，它维护每个域内会话流的绑定隧道的<SESSION-ID>值。与此绑定会话ID关联的绑定_代码设置为代码（隧道和端到端会话）。
The other BOUND-SESSION-ID maintains the SESSION-ID of the bound bidirectional end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Bidirectional sessions).
另一个绑定会话ID维护绑定的双向端到端会话的会话ID。与此绑定会话ID关联的绑定代码设置为代码（双向会话）。
Furthermore, the QoS-NSLP reservation state maintains the <PHB Class> value, the value of the bandwidth requested by the end-to-end session bound to the intra-domain session, and the value of the priority level.
此外，QoS NSLP保留状态维护<PHB Class>值、绑定到域内会话的端到端会话请求的带宽值以及优先级的值。
The measurement-based method can be classified in two schemes:
基于测量的方法可分为两种方案：
* Congestion notification based on probing:
* 基于探测的拥塞通知：
In this scheme, the Interior nodes are Diffserv-aware but not NSIS-aware nodes. Each Interior node counts the bandwidth that is used by each PHB traffic class. This counter value is stored in an RMD_QOSM state. For each PHB traffic class, a predefined congestion notification threshold is set. The predefined congestion notification threshold is set according to an engineered bandwidth limitation based, e.g., on a Service Level Agreement or a capacity limitation of specific links. The threshold is usually less than the capacity limit, i.e., admission threshold, in order to avoid congestion due to the error of estimating the actual traffic load. The value of this threshold SHOULD be stored in another RMD_QOSM state.
在该方案中，内部节点是区分服务感知节点，而非NSIS感知节点。每个内部节点统计每个PHB流量类别使用的带宽。此计数器值存储在RMD_QOSM状态中。对于每个PHB流量类别，将设置预定义的拥塞通知阈值。预定义的拥塞通知阈值根据例如基于服务水平协议或特定链路的容量限制的工程带宽限制来设置。阈值通常小于容量限制，即接纳阈值，以避免由于估计实际交通负荷的错误而造成的拥塞。该阈值的值应存储在另一个RMD_QOSM状态中。
In this scenario, an end-to-end NSIS message is used as a probe packet. In this case, the <DSCP> field of the GIST message is re-marked when the predefined congestion notification threshold is exceeded in an Interior node. It is required that the re-marking happens to all packets that belong to the congested PHB traffic class so that the probe can't pass the congested router without being re-marked. In this way, it is ensured that the end-to-end NSIS message passed through the node that is congested. This feature is very useful when flow-based ECMP (Equal Cost Multiple Path) routing is used to detect only flows that are passing through the congested node.
在此场景中，端到端NSIS消息用作探测数据包。在这种情况下，当内部节点中超过预定义的拥塞通知阈值时，GIST消息的<DSCP>字段被重新标记。需要对属于拥塞PHB流量类别的所有数据包进行重新标记，以便探测器在没有重新标记的情况下无法通过拥塞路由器。这样，可以确保端到端NSIS消息通过拥塞的节点。当基于流的ECMP（等成本多路径）路由用于仅检测通过拥塞节点的流时，此功能非常有用。
* NSIS measurement-based admission control:
* 基于NSIS测量的准入控制：
The measurement-based admission control is implemented in NSIS-aware stateless routers. Thus, the main difference between this type of the measurement-based admission control and the congestion notification-based admission control is the fact that the Interior nodes are NSIS-aware nodes. In particular, the QNE Interior nodes operating in NSIS measurement-based mode are QoS-NSLP stateless nodes, i.e., they do not support any QoS-NSLP or NTLP/GIST states. These measurement-based nodes store two RMD-QOSM states per PHR
基于测量的接纳控制在NSIS感知的无状态路由器中实现。因此，这种基于测量的接纳控制与基于拥塞通知的接纳控制之间的主要区别在于内部节点是NSIS感知节点这一事实。特别地，在基于NSIS测量的模式下操作的QNE内部节点是QoS-NSLP无状态节点，即，它们不支持任何QoS-NSLP或NTLP/GIST状态。这些基于测量的节点每个PHR存储两个RMD-QOSM状态
group. These states reflect the traffic conditions at the node and are not affected by QoS-NSLP signaling. One state stores the measured user traffic load associated with the PHR group and another state stores the maximum traffic load threshold that can be admitted per PHR group. When a measurement-based node receives a intra-domain RESERVE message, it compares the requested resources to the available resources (maximum allowed minus current load) for the requested PHR group. If there are insufficient resources, it sets the <M> bit in the RMD-QSPEC. No change to the RMD-QSPEC is made when there are sufficient resources.
组这些状态反映了节点的流量状况，不受QoS NSLP信令的影响。一个状态存储与PHR组相关联的测量用户流量负载，另一个状态存储每个PHR组可以允许的最大流量负载阈值。当基于度量的节点收到域内保留消息时，它会将请求的资源与请求的PHR组的可用资源（允许的最大值减去当前负载）进行比较。如果资源不足，则在RMD-QSPEC中设置<M>位。当资源充足时，不会对RMD-QSPEC进行任何更改。
The QNE Edges maintain intra-domain QoS-NSLP operational and reservation states that contain similar data structures as described in Section 4.3.1.
QNE边缘保持域内QoS NSLP操作和保留状态，这些状态包含第4.3.1节所述的类似数据结构。
In this case, the intra-domain sessions supported by the Edges are per-flow sessions that have a one-to-one relationship to the per-flow end-to-end states supported by the same Edge.
在这种情况下，边缘支持的域内会话是与同一边缘支持的每流端到端状态具有一对一关系的每流会话。
The QNE Interior nodes operating in reservation-based mode are QoS-NSLP reduced-state nodes, i.e., they do not store NTLP/GIST states but they do store per PHB-aggregated QoS-NSLP states.
在基于预约模式下运行的QNE内部节点是QoS NSLP简化状态节点，即，它们不存储NTLP/GIST状态，但它们存储每个PHB聚合QoS NSLP状态。
The reservation-based PHR installs and maintains one reservation state per PHB, in all the nodes located in the communication path. This state is identified by the <PHB Class> value and it maintains the number of currently reserved resource units (or bandwidth). Thus, the QNE Ingress node signals only the resource units requested by each flow. These resource units, if admitted, are added to the currently reserved resources per PHB.
基于保留的PHR在位于通信路径中的所有节点中为每个PHB安装并维护一个保留状态。此状态由<PHB Class>值标识，并保持当前保留资源单元（或带宽）的数量。因此，QNE入口节点仅向每个流请求的资源单元发送信号。如果允许，这些资源单元将添加到每个PHB当前保留的资源中。
For each PHB, a threshold is maintained that specifies the maximum number of resource units that can be reserved. This threshold could, for example, be statically configured.
对于每个PHB，都会保留一个阈值，指定可以保留的最大资源单元数。例如，可以静态配置此阈值。
An example of how the admission control and its maintenance process occurs in the Interior nodes is described in Section 3 of [CsTa05].
[CsTa05]第3节描述了内部节点中准入控制及其维护过程的示例。
The simplified concept that is used by the per-traffic class admission control process in the Interior nodes, is based on the following equation:
内部节点中每交通量类别准入控制过程使用的简化概念基于以下等式：
last + p <= T,
最后+p<=T，
where p is the requested bandwidth rate, T is the admission threshold, which reflects the maximum traffic volume that can be admitted in the traffic class, and last is a counter that records the aggregated sum of the signaled bandwidth rates of previous admitted flows.
其中p是请求的带宽速率，T是接纳阈值，它反映了在业务类别中可以接纳的最大业务量，最后一个是记录先前接纳的流的信令带宽速率的总和的计数器。
The PHB group reservation states maintained in the Interior nodes are soft states, which are refreshed by sending periodic refresh intra-domain RESERVE messages, which are initiated by the Ingress QNEs. If a refresh message corresponding to a number of reserved resource units (i.e., bandwidth) is not received, the aggregated reservation state is decreased in the next refresh period by the corresponding amount of resources that were not refreshed. The refresh period can be refined using a sliding window algorithm described in [RMD3].
内部节点中维护的PHB组保留状态是软状态，通过发送由入口qne发起的周期性刷新域内保留消息来刷新软状态。如果未接收到对应于多个保留资源单元（即，带宽）的刷新消息，则在下一个刷新周期中，聚合保留状态将减少未刷新的相应资源量。可以使用[RMD3]中描述的滑动窗口算法来优化刷新周期。
The reserved resources for a particular flow can also be explicitly released from a PHB reservation state by means of a intra-domain RESERVE release/tear message, which is generated by the Ingress QNEs.
还可以通过由入口qne生成的域内保留释放/撕裂消息，从PHB保留状态显式地释放用于特定流的保留资源。
The use of explicit release enables the instantaneous release of the resources regardless of the length of the refresh period. This allows a longer refresh period, which also reduces the number of periodic refresh messages.
显式释放的使用允许即时释放资源，而不考虑刷新周期的长度。这允许更长的刷新周期，这也减少了定期刷新消息的数量。
Note that both in the case of measurement- and (per-flow and aggregated) RMD reservation-based methods, the way in which the maximum bandwidth thresholds are maintained is out of the specification of this document. However, when admission priorities are supported, the Maximum Allocation [RFC4125] or the Russian Dolls [RFC4127] bandwidth allocation models MAY be used. In this case, three types of priority traffic classes within the same PHB, e.g., Expedited Forwarding, can be differentiated. These three different priority traffic classes, which are associated with the same PHB, are denoted in this document as PHB_low_priority, PHB_normal_priority, and PHB_high_priority, and are identified by the <PHB Class> value and the priority value, which is carried in the <Admission Priority> RMD-QSPEC parameter.
请注意，对于基于测量和（每流和聚合）RMD保留的方法，保持最大带宽阈值的方式不符合本文档的规范。然而，当支持接纳优先级时，可以使用最大分配[RFC4125]或俄罗斯玩偶[RFC4127]带宽分配模型。在这种情况下，可以区分同一PHB内的三种类型的优先级流量类别，例如，快速转发。与同一PHB相关联的这三种不同的优先级流量等级在本文件中表示为PHB_低优先级、PHB_正常优先级和PHB_高优先级，并通过<PHB Class>值和优先级值进行标识，优先级值在<Admission priority>RMD-QSPEC参数中携带。
As mentioned in Section 1, the RMD-QOSM aims to support a number of additional requirements, e.g., Minimal impact on Interior node performance. Therefore, RMD-QOSM is designed to be very lightweight signaling with regard to the number of signaling message round trips and the amount of state established at involved signaling nodes with and without reduced state on QNEs. The actions allowed by a QNE Interior node are minimal (i.e., only those specified by the RMD-QOSM).
如第1节所述，RMD-QOSM旨在支持许多附加要求，例如，对内部节点性能的影响最小。因此，RMD-QOSM被设计为关于信令消息往返次数和在涉及的信令节点上建立的状态量的非常轻的信令，在QNE上有或没有减少的状态。QNE内部节点允许的操作是最小的（即，仅RMD-QOSM指定的操作）。
For example, only the QNE Ingress and the QNE Egress nodes are allowed to initiate certain signaling messages. QNE Interior nodes are, for example, allowed to modify certain signaling message payloads. Moreover, RMD signaling is targeted towards intra-domain signaling only. Therefore, RMD-QOSM relies on the security and reliability support that is provided by the bound end-to-end session, which is running between the boundaries of the RMD domain (i.e., the RMD-QOSM QNE Edges), and the security provided by the D-mode. This implies the use of the Datagram Mode.
例如，仅允许QNE入口和QNE出口节点启动某些信令消息。例如，QNE内部节点被允许修改某些信令消息有效载荷。此外，RMD信令仅针对域内信令。因此，RMD-QOSM依赖于在RMD域边界（即RMD-QOSM QNE边缘）和D模式提供的安全性之间运行的绑定端到端会话提供的安全性和可靠性支持。这意味着使用数据报模式。
Therefore, the intra-domain messages used by the RMD-QOSM are intended to operate in the NTLP/GIST Datagram mode (see [RFC5971]). The NSLP functionality available in all RMD-QOSM-aware QoS-NSLP nodes requires the intra-domain GIST, via the QoS-NSLP RMF API see [RFC5974], to:
因此，RMD-QOSM使用的域内消息旨在以NTLP/GIST数据报模式运行（参见[RFC5971]）。所有RMD QOSM感知QoS NSLP节点中可用的NSLP功能需要域内GIST，通过QoS NSLP RMF API参见[RFC5974]，以：
* operate in unreliable mode. This can be satisfied by passing this requirement from the QoS-NSLP layer to the GIST layer via the API Transfer-Attributes.
* 在不可靠模式下运行。这可以通过API传输属性将此需求从QoS NSLP层传递到GIST层来满足。
* not create a message association state. This requirement can be satisfied by a local policy, e.g., the QNE is configured to not create a message association state.
* 不创建消息关联状态。本地策略可以满足此要求，例如，QNE配置为不创建消息关联状态。
* not create any NTLP routing state by the Interior nodes. This can be satisfied by passing this requirement from the QoS-NSLP layer to the GIST layer via the API. However, between the QNE Egress and QNE Ingress routing states SHOULD be created that are associated with intra-domain sessions and that can be used for the communication of GIST Data messages sent by a QNE Egress directly to a QNE Ingress. This type of routing state associated with an intra-domain session can be generated and used in the following way:
* 内部节点不创建任何NTLP路由状态。这可以通过API将此需求从QoS NSLP层传递到GIST层来满足。然而，应在QNE出口和QNE入口之间创建与域内会话相关联且可用于QNE出口直接发送到QNE入口的GIST数据消息的通信的路由状态。与域内会话关联的这种类型的路由状态可以通过以下方式生成和使用：
* When the QNE Ingress has to send an initial intra-domain RESERVE message, the QoS-NSLP sends this message by including, in the GIST API SendMessage primitive, the Unreliable and No security attributes. In order to optimize this procedure, the RMD domain MUST be engineered in such a way that GIST will piggyback this NSLP message on a GIST Query message. Furthermore, GIST sets the C-flag (C=1), see [RFC5971] and uses the Q-mode. The GIST functionality in each QNE Interior node will receive the GIST Query message and by using the RecvMessage GIST API primitive it will pass the intra-domain RESERVE message to the QoS-NSLP functionality. At the same time, the GIST functionality uses the Routing-State-Check boolean to find out if the QoS-NSLP needs to create a routing state. The QoS-NSLP sets this boolean to inform GIST to not create a routing state and to forward the GIST Query further downstream with the
* 当QNE入口必须发送初始域内保留消息时，QoS NSLP通过在GIST API SendMessage原语中包括不可靠和无安全属性来发送该消息。为了优化这个过程，RMD域的设计必须使GIST能够将这个NSLP消息搭载在GIST查询消息上。此外，GIST设置C标志（C=1），参见[RFC5971]，并使用Q模式。每个QNE内部节点中的GIST功能将接收GIST查询消息，并通过使用RecVMMessage GIST API原语，将域内保留消息传递给QoS NSLP功能。同时，GIST功能使用路由状态检查布尔值来确定QoS NSLP是否需要创建路由状态。QoS NSLP将此布尔值设置为通知GIST不要创建路由状态，并使用
modified QoS-NSLP payload, which will include the modified intra-domain RESERVE message. The intra-domain RESERVE is sent in the same way up to the QNE Egress. The QNE Egress needs to create a routing state.
修改的QoS NSLP有效负载，其中将包括修改的域内保留消息。域内保留以相同的方式发送到QNE出口。QNE出口需要创建路由状态。
Therefore, at the same moment that the GIST functionality passes the intra-domain RESERVE message, via the GIST RecvMessage primitive, to the QoS-NSLP, the QoS-NSLP sets the Routing-State-Check boolean such that a routing state is created. The GIST creates the routing state using normal GIST procedures. After this phase, the QNE Ingress and QNE Egress have, for the particular session, routing states that can route traffic directly from QNE Ingress to QNE Egress and from QNE Egress to QNE Ingress. The routing state at the QNE Egress can be used by the QoS-NSLP and GIST to send an intra-domain RESPONSE or intra-domain NOTIFY directly to the QNE Ingress using GIST Data messages. Note that this routing state is refreshed using normal GIST procedures. Note that in the above description, it is considered that the QNE Ingress can piggyback the initial RESERVE (NSLP) message on the GIST Query message. If the piggybacking of this NSLP (initial RESERVE) message would not be possible on the GIST Query message, then the GIST Query message sent by the QNE Ingress node would not contain any NSLP data. This GIST Query message would only be processed by the QNE Egress to generate a routing state.
因此，在GIST功能通过GIST RecvMessage原语将域内保留消息传递给QoS NSLP的同时，QoS NSLP设置路由状态检查布尔值，以便创建路由状态。GIST使用常规GIST过程创建路由状态。在该阶段之后，对于特定会话，QNE入口和QNE出口具有路由状态，该路由状态可以将业务直接从QNE入口路由到QNE出口，以及从QNE出口路由到QNE入口。QNE出口处的路由状态可由QoS NSLP和GIST使用，以使用GIST数据消息直接向QNE入口发送域内响应或域内通知。请注意，此路由状态是使用正常GIST过程刷新的。注意，在上述描述中，认为QNE入口可以在GIST查询消息上搭载初始保留（NSLP）消息。如果无法在GIST查询消息上搭载此NSLP（初始保留）消息，则QNE入口节点发送的GIST查询消息将不包含任何NSLP数据。此GIST查询消息将仅由QNE出口处理以生成路由状态。
After the QNE Ingress is informed that the routing state at the QNE Egress is initiated, it would have to send the initial RESERVE message using similar procedures as for the situation that it would send an intra-domain RESERVE message that is not an initial RESERVE, see next bullet. This procedure is not efficient and therefore it is RECOMMENDED that the RMD domain MUST be engineered in such a way that the GIST protocol layer, which is processed on a QNE Ingress, will piggyback an initial RESERVE (NSLP) message on a GIST Query message that uses the Q-mode.
在QNE入口被告知QNE出口处的路由状态已启动后，它必须使用与发送非初始保留的域内保留消息的情况类似的过程来发送初始保留消息，请参阅下一个项目符号。此过程效率不高，因此建议RMD域的设计方式必须确保在QNE入口上处理的GIST协议层将在使用Q模式的GIST查询消息上搭载初始保留（NSLP）消息。
* When the QNE Ingress needs to send an intra-domain RESERVE message that is not an initial RESERVE, then the QoS-NSLP sends this message by including in the GIST API SendMessage primitive such attributes that the use of the Datagram Mode is implied, e.g., the Unreliable attribute. Furthermore, the Local policy attribute is set such that GIST sends the intra-domain RESERVE message in a Q-mode even if there is a routing state at the QNE Ingress. In this way, the GIST functionality uses its local policy to send the intra-domain RESERVE message by piggybacking it on a GIST Data message and sending it in Q-mode even if there is a routing state for this session. The intra-domain RESERVE message is piggybacked on the GIST Data message that is forwarded and processed by the QNE Interior nodes up to the QNE Egress.
* 当QNE入口需要发送不是初始保留的域内保留消息时，QoS NSLP通过在GIST API SendMessage原语中包括暗示使用数据报模式的属性（例如，不可靠属性）来发送该消息。此外，本地策略属性被设置为使得GIST以Q模式发送域内保留消息，即使在QNE入口处存在路由状态。通过这种方式，GIST功能使用其本地策略来发送域内保留消息，方法是将其搭载在GIST数据消息上，并以Q模式发送，即使该会话存在路由状态。域内保留消息承载在GIST数据消息上，GIST数据消息由QNE内部节点转发和处理，直至QNE出口。
The transport of the original (end-to-end) RESERVE message is accomplished in the following way:
原始（端到端）保留消息的传输通过以下方式完成：
At the QNE Ingress, the original (end-to-end) RESERVE message is forwarded but ignored by the stateless or reduced-state nodes, see Figure 3.
在QNE入口，原始（端到端）保留消息被转发，但被无状态或简化状态节点忽略，见图3。
The intermediate (Interior) nodes are bypassed using multiple levels of NSLPID values (see [RFC5974]). This is accomplished by marking the end-to-end RESERVE message, i.e., modifying the QoS-NSLP default NSLPID value to another NSLPID predefined value.
使用多级NSLPID值绕过中间（内部）节点（请参见[RFC5974]）。这是通过标记端到端保留消息来实现的，即，将QoS NSLP默认NSLPID值修改为另一个NSLPID预定义值。
The marking MUST be accomplished by the Ingress by modifying the QoS_NSLP default NSLPID value to a NSLPID predefined value. In this way, the Egress MUST stop this marking process by reassigning the QoS-NSLP default NSLPID value to the original (end-to-end) RESERVE message. Note that the assignment of these NSLPID values is a QoS-NSLP issue, which SHOULD be accomplished via IANA [RFC5974].
标记必须由入口通过将QoS\u NSLP默认NSLPID值修改为NSLPID预定义值来完成。这样，出口必须通过将QoS NSLP default NSLPID值重新分配给原始（端到端）保留消息来停止该标记过程。注意，这些NSLPID值的分配是一个QoS NSLP问题，应通过IANA[RFC5974]完成。
Mainly, the Egress node discovery can be performed by using either the GIST discovery mechanism [RFC5971], manual configuration, or any other discovery technique. The addressing of signaling messages depends on which GIST transport mode is used. The RMD-QOSM/QoS-NSLP signaling messages that are processed only by the Edge nodes use the peer-peer addressing of the GIST Connection (C) mode.
主要地，出口节点发现可以通过使用GIST发现机制[RFC5971]、手动配置或任何其他发现技术来执行。信令消息的寻址取决于使用哪种GIST传输模式。仅由边缘节点处理的RMD-QOSM/QoS NSLP信令消息使用GIST连接（C）模式的对等寻址。
RMD-QOSM/QoS-NSLP signaling messages that are processed by all nodes of the Diffserv domain, i.e., Edges and Interior nodes, use the end-to-end addressing of the GIST Datagram (D) mode. Note that the RMD-QOSM cannot directly specify that the GIST Connection or the GIST Datagram mode SHOULD be used. This can only be specified by using, via the QoS-NSLP-RMF API, the GIST API Transfer-Attributes, such as Reliable or Unreliable, high or low level of security, and by the use of local policies. RMD QoS signaling messages that are addressed to the data path end nodes are intercepted by the Egress nodes. In particular, at the ingress and for downstream intra-domain messages, the RMD-QOSM instructs the GIST functionality, via the GIST API to do the following:
由Diffserv域的所有节点（即边缘和内部节点）处理的RMD-QOSM/QoS NSLP信令消息使用GIST数据报（D）模式的端到端寻址。请注意，RMD-QOSM不能直接指定应使用GIST连接或GIST数据报模式。这只能通过QoS NSLP RMF API使用GIST API传输属性（如可靠或不可靠、高或低安全级别）以及使用本地策略来指定。寻址到数据路径端节点的RMD QoS信令消息被出口节点截获。具体而言，对于入口和下游域内消息，RMD-QOSM通过GIST API指示GIST功能执行以下操作：
* use unreliable and low level security Transfer-Attributes,
* 使用不可靠的低级别安全传输属性，
* do not create a GIST routing state, and
* 不要创建GIST路由状态，并且
* use the D-mode MRI.
* 使用D型MRI。
The intra-domain RESERVE messages can then be transported by using the Query D-mode; see Section 4.4.
然后可以使用查询D模式传输域内保留消息；见第4.4节。
At the QNE Egress, and for upstream intra-domain messages, the RMD-QOSM instructs the GIST functionality, via the GIST API, to use among others:
在QNE出口处，对于上游域内消息，RMD-QOSM通过GIST API指示GIST功能除其他外使用：
* unreliable and low level security Transfer-Attributes
* 不可靠和低级别的安全传输属性
* the routing state associated with the intra-domain session to send an upstream intra-domain message directly to the QNE Ingress; see Section 4.4.
* 与域内会话相关联的用于直接向QNE入口发送上游域内消息的路由状态；见第4.4节。
This section describes the basic unidirectional operation and sequence of events/triggers of the RMD-QOSM. The following basic operation cases are distinguished:
本节描述RMD-QOSM的基本单向操作和事件/触发器顺序。区分以下基本操作情况：
* Successful reservation (Section 4.6.1.1), * Unsuccessful reservation (Section 4.6.1.2), * RMD refresh reservation (Section 4.6.1.3), * RMD modification of aggregated reservation (Section 4.6.1.4), * RMD release procedure (Section 4.6.1.5.), * Severe congestion handling (Section 4.6.1.6.), * Admission control using congestion notification based on probing (Section 4.6.1.7.).
* 成功预订（第4.6.1.1节），*未成功预订（第4.6.1.2节），*RMD刷新预订（第4.6.1.3节），*RMD修改汇总预订（第4.6.1.4节），*RMD发布程序（第4.6.1.5节），*严重拥堵处理（第4.6.1.6节），*使用基于探测的拥塞通知进行准入控制（第4.6.1.7节）。
The QNEs at the Edges of the RMD domain support the RMD QoS Model and end-to-end QoS Models, which process the RESERVE message differently.
RMD域边缘的QNE支持RMD QoS模型和端到端QoS模型，它们以不同的方式处理保留消息。
Note that the term end-to-end QoS Model applies to any QoS Model that is initiated and terminated outside the RMD-QOSM-aware domain. However, there might be situations where a QoS Model is initiated and/or terminated by the QNE Edges and is considered to be an end-to-end QoS Model. This can occur when the QNE Edges can also operate as either QNI or as QNR and at the same time they can operate as either sender or receiver of the data path.
请注意，术语端到端QoS模型适用于在RMD QOSM感知域之外启动和终止的任何QoS模型。然而，可能存在QoS模型由QNE边缘发起和/或终止并且被认为是端到端QoS模型的情况。当QNE边缘也可以作为QNI或QNR操作，同时它们可以作为数据路径的发送方或接收方操作时，就会发生这种情况。
It is important to emphasize that the content of this section is used for the specification of the following RMD-QOSM/QoS-NSLP signaling schemes, when basic unidirectional operation is assumed:
需要强调的是，当假设基本单向操作时，本节内容用于以下RMD-QOSM/QoS NSLP信令方案的规范：
* "per-flow congestion notification based on probing";
* “基于探测的每流拥塞通知”；
* "per-flow RMD NSIS measurement-based admission control";
* “基于流量RMD NSIS测量的准入控制”；
* "per-flow RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
* “基于每流RMD预留”与“通过RMD-QOSM刷新进行严重拥塞处理”程序相结合；
* "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure;
* “基于每流RMD预留”与“按比例数据包标记的严重拥塞处理”程序相结合；
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
* 结合“通过RMD-QOSM刷新进行严重拥塞处理”程序的“基于每个总RMD预订”；
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure.
* “基于每聚合RMD保留”与“按比例数据包标记的严重拥塞处理”程序相结合。
For more details, please see Section 3.2.3.
有关更多详细信息，请参见第3.2.3节。
In particular, the functionality described in Sections 4.6.1.1, 4.6.1.2, 4.6.1.3, 4.6.1.5, 4.6.1.4, and 4.6.1.6 applies to the RMD reservation-based and to the NSIS measurement-based admission control methods. The described functionality in Section 4.6.1.7 applies to the admission control procedure that uses the congestion notification based on probing. The QNE Edge nodes maintain either per-flow QoS-NSLP operational and reservation states or aggregated QoS-NSLP operational and reservation states.
特别是，第4.6.1.1、4.6.1.2、4.6.1.3、4.6.1.5、4.6.1.4和4.6.1.6节中描述的功能适用于基于RMD保留和基于NSIS测量的准入控制方法。第4.6.1.7节中描述的功能适用于使用基于探测的拥塞通知的准入控制程序。QNE边缘节点维护每流QoS NSLP操作和保留状态或聚合QoS NSLP操作和保留状态。
When the QNE Edges maintain aggregated QoS-NSLP operational and reservation states, the RMD-QOSM functionality MAY accomplish an RMD modification procedure (see Section 4.6.1.4), instead of the reservation initiation procedure that is described in this subsection. Note that it is RECOMMENDED that the QNE implementations of RMD-QOSM process the QoS-NSLP signaling messages with a higher priority than data packets. This can be accomplished as described in Section 3.3.4 of [RFC5974] and it can be requested via the QoS-NSLP-RMF API described in [RFC5974]. The signaling scenarios described in this section are accomplished using the QoS-NSLP processing rules defined in [RFC5974], in combination with the RMF triggers sent via the QoS-NSLP-RMF API described in [RFC5974].
当QNE边缘保持聚合QoS NSLP操作和保留状态时，RMD-QOSM功能可以完成RMD修改程序（参见第4.6.1.4节），而不是本小节中描述的保留启动程序。注意，建议RMD-QOSM的QNE实现以比数据分组更高的优先级处理QoS NSLP信令消息。这可以按照[RFC5974]第3.3.4节所述完成，并且可以通过[RFC5974]中所述的QoS NSLP RMF API进行请求。本节中描述的信令场景是使用[RFC5974]中定义的QoS NSLP处理规则以及[RFC5974]中描述的通过QoS NSLP RMF API发送的RMF触发器完成的。
According to Section 3.2.3, it is specified that only the "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" scheme MUST be implemented within one RMD domain. However, all RMD QNEs supporting this specification MUST support the combination the "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" scheme. If the RMD QNEs support more RMD-QOSM schemes, then the operator of that RMD domain MUST preconfigure all the QNE Edge nodes within one domain such that the <SCH> field included in the "PHR container" (Section
根据第3.2.3节，规定在一个RMD域内只能实施“基于每流RMD预留”和“通过比例数据包标记进行严重拥塞处理”方案。然而，所有支持本规范的RMD QNE必须支持“基于每流RMD预留”与“通过比例数据包标记进行严重拥塞处理”方案的组合。如果RMD QNE支持更多RMD-QOSM方案，则该RMD域的操作员必须预先配置一个域内的所有QNE边缘节点，以便“PHR容器”（第节）中包含的<SCH>字段
4.1.2) and the "PDR Container" (Section 4.1.3) will always use the same value, such that within one RMD domain only one of the below described RMD-QOSM schemes is used at a time.
4.1.2）和“PDR容器”（第4.1.3节）将始终使用相同的值，以便在一个RMD域内，一次仅使用下述RMD-QOSM方案中的一个。
All QNE nodes located within the RMD domain MUST read and interpret the <SCH> field included in the "PHR container" before processing all the other "PHR container" payload fields. Moreover, all QNE Edge nodes located at the boarder of the RMD domain, MUST read and interpret the <SCH> field included in the "PDR container" before processing all the other <PDR container> payload fields.
位于RMD域内的所有QNE节点在处理所有其他“PHR容器”有效载荷字段之前，必须读取并解释“PHR容器”中包含的<SCH>字段。此外，位于RMD域边界的所有QNE边缘节点必须在处理所有其他<PDR container>有效载荷字段之前读取并解释“PDR container”中包含的<SCH>字段。
This section describes the operation of the RMD-QOSM where a reservation is successfully accomplished.
本节描述了成功完成预订的RMD-QOSM的操作。
The QNI generates the initial RESERVE message, and it is forwarded by the NTLP as usual [RFC5971].
QNI生成初始保留消息，并像往常一样由NTLP转发[RFC5971]。
When an end-to-end reservation request (RESERVE) arrives at the Ingress node (QNE) (see Figure 8), it is processed based on the end-to-end QoS Model. Subsequently, the combination of <TMOD-1>, <PHB Class>, and <Admission Priority> is derived from the <QoS Desired> object of the initial QSPEC.
当端到端预留请求（RESERVE）到达入口节点（QNE）（见图8）时，将根据端到端QoS模型对其进行处理。随后，<TMOD-1>、<PHB Class>和<Admission Priority>的组合从初始QSPEC的<QoS Desired>对象派生而来。
The QNE Ingress MUST maintain information about the smallest MTU that is supported on the links within the RMD domain.
QNE入口必须维护RMD域内链路上支持的最小MTU的信息。
The <Maximum Packet Size-1 (MPS)> value included in the end-to-end QoS Model <TMOD-1> parameter is compared with the smallest MTU value that is supported by the links within the RMD domain. If the "Maximum Packet Size-1 (MPS)" is larger than this smallest MTU value within the RMD domain, then the end-to-end reservation request is rejected (see Section 4.6.1.1.2). Otherwise, the admission process continues.
端到端QoS模型<TMOD-1>参数中包含的<Maximum Packet Size-1（MPS）>值与RMD域内链路支持的最小MTU值进行比较。如果“最大数据包大小-1（MPS）”大于RMD域内的最小MTU值，则拒绝端到端保留请求（见第4.6.1.1.2节）。否则，录取过程将继续。
The <TMOD-1> parameter contained in the original initiator QSPEC is mapped into the equivalent RMD-Qspec <TMOD-1> parameter representing only the peak bandwidth in the local RMD-QSPEC. This can be accomplished by setting the RMD-QSPEC <TMOD-1> fields as follows: token rate (r) = peak traffic rate (p), the bucket depth (b) = large, and the minimum policed unit (m) = large.
原始启动器QSPEC中包含的<TMOD-1>参数映射到仅表示本地RMD-QSPEC中峰值带宽的等效RMD QSPEC<TMOD-1>参数。这可以通过如下设置RMD-QSPEC<TMOD-1>字段来实现：令牌速率（r）=峰值业务速率（p），桶深度（b）=大，最小策略单位（m）=大。
Note that the bucket size, (b), is measured in bytes. Values of this parameter may range from 1 byte to 250 gigabytes; see [RFC2215]. Thus, the maximum value that (b) could be is in the order of 250
请注意，bucket大小（b）以字节为单位。此参数的值可能在1字节到250 GB之间；见[RFC2215]。因此，（b）的最大值为250左右
gigabytes. The minimum policed unit, [m], is an integer measured in bytes and must be less than or equal to the Maximum Packet Size (MPS). Thus, the maximum value that (m) can be is (MPS). [Part94] and [TaCh99] describe a method of calculating the values of some Token Bucket parameters, e.g., calculation of large values of (m) and (b), when the token rate (r), peak rate (p), and MPS are known.
千兆字节。最小策略单位[m]是以字节为单位的整数，必须小于或等于最大数据包大小（MPS）。因此，（m）可以是（MPS）的最大值。[Part94]和[TaCh99]描述了当已知令牌速率（r）、峰值速率（p）和MPS时，计算一些令牌桶参数值的方法，例如，计算（m）和（b）的大值。
The <Peak Data Rate-1 (p)> value of the end-to-end QoS Model <TMOD-1> parameter is copied into the <Peak Data Rate-1 (p)> value of the <Peak Data Rate-1 (p)> value of the local RMD-Qspec <TMOD-1>.
端到端QoS模型<TMOD-1>参数的<Peak Data Rate-1（p）>值被复制到本地RMD Qspec<TMOD-1>的<Peak Data Rate-1（p）>值中。
The MPS value of the end-to-end QoS Model <TMOD-1> parameter is copied into the MPS value of the local RMD-Qspec <TMOD-1>.
端到端QoS模型<TMOD-1>参数的MPS值被复制到本地RMD Qspec<TMOD-1>的MPS值中。
If the initial QSPEC does not contain the <PHB Class> parameter, then the selection of the <PHB Class> that is carried by the intra-domain RMD-QSPEC is defined by a local policy similar to the procedures discussed in [RFC2998] and [RFC3175].
如果初始QSPEC不包含<PHB Class>参数，则域内RMD-QSPEC携带的<PHB Class>选择由本地策略定义，类似于[RFC2998]和[RFC3175]中讨论的过程。
For example, in the situation that the initial QSPEC is used by the IntServ Controlled Load QOSM, then the Expedited Forwarding (EF) PHB is appropriate to set the <PHB Class> parameter carried by the intra-domain RMD-QSPEC (see [RFC3175]).
例如，在初始QSPEC由IntServ控制的负载QOSM使用的情况下，则加速转发（EF）PHB适合设置域内RMD-QSPEC携带的<PHB Class>参数（参见[RFC3175]）。
If the initial QSPEC does not carry the <Admission Priority> parameter, then the <Admission Priority> parameter in the RMD-QSPEC will not be populated. If the initial QSPEC does not carry the <Admission Priority> parameter, but it carries other priority parameters, then it is considered that Edges, as being stateful nodes, are able to control the priority of the sessions that are entering or leaving the RMD domain in accordance with the priority parameters.
如果初始QSPEC未携带<Admission Priority>参数，则RMD-QSPEC中的<Admission Priority>参数将不会被填充。如果初始QSPEC不携带<准入优先级>参数，但携带其他优先级参数，则认为作为有状态节点的边缘能够根据优先级参数控制进入或离开RMD域的会话的优先级。
Note that the RMF reservation states (see Section 4.3) in the QNE Edges store the value of the <Admission Priority> parameter that is used within the RMD domain in case of preemption and severe congestion situations (see Section 4.6.1.6).
请注意，QNE边缘中的RMF保留状态（参见第4.3节）存储了在抢占和严重拥塞情况下RMD域中使用的<准入优先级>参数值（参见第4.6.1.6节）。
If the RMD domain supports preemption during the admission control process, then the QNE Ingress node can support the building blocks specified in [RFC5974] and during the admission control process use the example preemption handling algorithm described in Appendix A.7.
如果RMD域在准入控制过程中支持抢占，则QNE入口节点可以支持[RFC5974]中指定的构建块，并且在准入控制过程中使用附录A.7中描述的示例抢占处理算法。
Note that in the above described case, the QNE Egress uses, if available, the tunneled initial priority parameters, which can be interpreted by the QNE Egress.
注意，在上述情况下，如果可用，QNE出口使用隧道初始优先级参数，该参数可由QNE出口解释。
If the initial QSPEC carries the <Excess Treatment> parameter, then the QNE Ingress and QNE Egress nodes MUST control the excess traffic that is entering or leaving the RMD domain in accordance with the <Excess Treatment> parameter. Note that the RMD-QSPEC does not carry the <Excess Treatment> parameter.
如果初始QSPEC携带<过量处理>参数，则QNE入口和QNE出口节点必须根据<过量处理>参数控制进入或离开RMD域的过量流量。请注意，RMD-QSPEC不包含<过度处理>参数。
If the requested <TMOD-1> parameter carried by the initial QSPEC, cannot be satisfied, then an end-to-end RESPONSE message has to be generated. However, in order to decide whether the end-to-end reservation request was locally (at the QNE Ingress) satisfied, a local (at the QNE_Ingress) RMD-QOSM admission control procedure also has to be performed. In other words, the RMD-QOSM functionality has to verify whether the value included in the <Peak Data Rate-1 (p)> field of RMD-QOSM <TMOD-1> can be reserved and stored in the RMD-QOSM reservation states (see Sections 4.6.1.1.2 and 4.3).
如果无法满足初始QSPEC携带的请求<TMOD-1>参数，则必须生成端到端响应消息。然而，为了确定端到端预约请求是否在本地（在QNE入口）得到满足，还必须执行本地（在QNE_入口）RMD-QOSM接纳控制程序。换句话说，RMD-QOSM功能必须验证RMD-QOSM<TMOD-1>的<Peak Data Rate-1（p）>字段中包含的值是否可以保留并存储在RMD-QOSM保留状态中（参见第4.6.1.1.2和4.3节）。
An initial QSPEC object MUST be included in the end-to-end RESPONSE message. The parameters included in the QSPEC <QoS Reserved> object are copied from the original <QoS Desired> values.
端到端响应消息中必须包含初始QSPEC对象。QSPEC<QoS Reserved>对象中包含的参数是从原始<QoS Desired>值复制而来的。
The <E> flag associated with the QSPEC <QoS Reserved> object and the <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter are set. In addition, the <INFO-SPEC> object is included in the end-to-end RESPONSE message. The error code used by this <INFO-SPEC> is:
设置与QSPEC<QoS Reserved>对象关联的<E>标志和与本地RMD-QSPEC<TMOD-1>参数关联的<E>标志。此外，<INFO-SPEC>对象包含在端到端响应消息中。此<INFO-SPEC>使用的错误代码为：
Error severity class: Transient Failure Error code value: Reservation failure
错误严重性等级：瞬时故障错误代码值：保留故障
Furthermore, all of the other RESPONSE parameters are set according to the end-to-end QoS Model or according to [RFC5974] and [RFC5975].
此外，根据端到端QoS模型或根据[RFC5974]和[RFC5975]设置所有其他响应参数。
If the request was satisfied locally (see Section 4.3), the Ingress QNE node generates two RESERVE messages: one intra-domain and one end-to-end RESERVE message. Note however, that when the aggregated QoS-NSLP operational and reservation states are used by the QNE Ingress, then the generation of the intra-domain RESERVE message depends on the availability of the aggregated QoS-NSLP operational state. If this aggregated QoS-NSLP operational state is available, then the RMD modification of aggregated reservations described in Section 4.6.1.4 is used.
如果请求在本地得到满足（参见第4.3节），入口QNE节点将生成两条保留消息：一条域内保留消息和一条端到端保留消息。然而，请注意，当QNE入口使用聚合QoS NSLP操作和保留状态时，域内保留消息的生成取决于聚合QoS NSLP操作状态的可用性。如果此聚合QoS NSLP操作状态可用，则使用第4.6.1.4节中描述的聚合保留的RMD修改。
It is important to note that when the "per-flow RMD reservation-based" scenario is used within the RMD domain, the retransmission within the RMD domain SHOULD be disallowed. The reason for this is related to the fact that the QNI Interior nodes are not able to differentiate between a retransmitted RESERVE message associated with a certain session and an initial RESERVE message belonging to another session. However, the QNE Ingress have to report a failure situation
需要注意的是，当在RMD域内使用“基于每流RMD保留”方案时，RMD域内的重传应被禁止。其原因与QNI内部节点不能区分与特定会话相关联的重传保留消息和属于另一会话的初始保留消息这一事实有关。但是，QNE入口必须报告故障情况
upstream. When the QNE Ingress transmits the (intra-domain or end-to-end) RESERVE with the <RII> object set, it waits for a RESPONSE from the QNE Egress for a QOSNSLP_REQUEST_RETRY period.
上游当QNE入口使用<RII>对象集传输（域内或端到端）保留时，它等待来自QNE出口的QOSNP请求重试周期的响应。
If the QNE Ingress transmitted an intra-domain or end-to-end RESERVE message with the <RII> object set and it fails to receive the associated intra-domain or end-to-end RESPONSE, respectively, after the QOSNSLP_REQUEST_RETRY period expires, it considers that the reservation failed. In this case, the QNE Ingress SHOULD generate an end-to-end RESPONSE message that will include, among others, an <INFO-SPEC> object. The error code used by this <INFO-SPEC> object is:
如果QNE入口使用<RII>对象集发送域内或端到端保留消息，并且在QOSNP请求重试期到期后，它无法分别接收相关的域内或端到端响应，则它认为保留失败。在这种情况下，QNE入口应生成端到端响应消息，其中包括<INFO-SPEC>对象。此<INFO-SPEC>对象使用的错误代码为：
Error severity class: Transient Failure Error code value: Reservation failure
错误严重性等级：瞬时故障错误代码值：保留故障
Furthermore, all of the other RESPONSE parameters are set according to the end-to-end QoS Model or according to [RFC5974] and [RFC5975].
此外，根据端到端QoS模型或根据[RFC5974]和[RFC5975]设置所有其他响应参数。
Note however, that if the retransmission within the RMD domain is not disallowed, then the procedure described in Appendix A.8 SHOULD be used on QNE Interior nodes; see also [Chan07]. In this case, the stateful QNE Ingress uses the retransmission procedure described in [RFC5974].
然而，请注意，如果不允许RMD域内的重传，则应在QNE内部节点上使用附录A.8中描述的程序；另见[07]。在这种情况下，有状态QNE入口使用[RFC5974]中描述的重传过程。
If a rerouting takes place, then the stateful QNE Ingress is following the procedures specified in [RFC5974].
如果发生重新路由，则有状态QNE进入遵循[RFC5974]中指定的过程。
At this point, the intra-domain and end-to-end operational states MUST be initiated or modified according to the REQUIRED binding procedures. The way of how the BOUND-SESSION-IDs are initiated and maintained in the intra-domain and end-to-end QoS-NSLP operational states is described in Sections 4.3.1 and 4.3.2.
此时，必须根据所需的绑定过程启动或修改域内和端到端操作状态。第4.3.1节和第4.3.2节描述了如何在域内和端到端QoS NSLP操作状态中启动和维护绑定会话ID的方法。
These two messages are bound together in the following way. The end-to-end RESERVE SHOULD contain, in the BOUND-SESSION-ID, the SESSION-ID of its bound intra-domain session.
这两条消息按以下方式绑定在一起。端到端保留应在绑定会话ID中包含其绑定的域内会话的会话ID。
Furthermore, if the QNE Edge nodes maintain intra-domain per-flow QoS-NSLP reservation states, then the value of Binding_Code MUST be set to code "Tunnel and end-to-end sessions" (see Section 4.3.2).
此外，如果QNE边缘节点保持域内每流QoS NSLP保留状态，则必须将Binding_代码的值设置为代码“隧道和端到端会话”（参见第4.3.2节）。
In addition to this, the intra-domain and end-to-end RESERVE messages are bound using the Message binding procedure described in [RFC5974].
除此之外，使用[RFC5974]中描述的消息绑定过程绑定域内和端到端保留消息。
In particular the <MSG-ID> object is included in the intra-domain RESERVE message and its bound <BOUND-MSG-ID> object is carried by the end-to-end RESERVE message. Furthermore, the <Message_Binding_Type> flag is SET (value is 1), such that the message dependency is bidirectional.
特别是<MSG-ID>对象包含在域内保留消息中，其绑定<bound-MSG-ID>对象由端到端保留消息携带。此外，设置<Message_Binding_Type>标志（值为1），使得消息依赖是双向的。
If the QoS-NSLP Edges maintain aggregated intra-domain QoS-NSLP operational states, then the value of Binding_Code MUST be set to code "Aggregated sessions".
如果QoS NSLP边缘保持聚合的域内QoS NSLP操作状态，则必须将Binding_Code的值设置为Code“aggregated sessions”。
Furthermore, in this case, the retransmission within the RMD domain is allowed and the procedures described in Appendix A.8 SHOULD be used on QNE Interior nodes. This is necessary due to the fact that when retransmissions are disallowed, then the associated with (micro) flows belonging to the aggregate will loose their reservations. Note that, in this case, the stateful QNE Ingress uses the retransmission procedure described in [RFC5974].
此外，在这种情况下，允许RMD域内的重传，并且应在QNE内部节点上使用附录A.8中描述的程序。这是必要的，因为当不允许重传时，属于聚合的相关（微）流将失去其保留。注意，在这种情况下，有状态QNE入口使用[RFC5974]中描述的重传过程。
The intra-domain RESERVE message is associated with the (local NTLP) SESSION-ID mentioned above. The selection of the IP source and IP destination address of this message depends on how the different inter-domain (end-to-end) flows are aggregated by the QNE Ingress node (see Section 4.3.1). As described in Section 4.3.1, the QNE Edges maintain either per-flow, or aggregated QoS-NSLP reservation states for the RMD QoS Model, which are identified by (local NTLP) SESSION-IDs (see [RFC5971]). Note that this NTLP SESSION-ID is a different one than the SESSION-ID associated with the end-to-end RESERVE message.
域内保留消息与上述（本地NTLP）会话ID相关联。此消息的IP源和IP目标地址的选择取决于QNE入口节点如何聚合不同的域间（端到端）流（参见第4.3.1节）。如第4.3.1节所述，QNE边缘维护RMD QoS模型的每流或聚合QoS NSLP保留状态，这些状态由（本地NTLP）会话ID标识（请参见[RFC5971]）。请注意，此NTLP会话ID与与端到端保留消息关联的会话ID不同。
If no QoS-NSLP aggregation procedure at the QNE Edges is supported, then the IP source and IP destination address of this message MUST be equal to the IP source and IP destination addresses of the data flow. The intra-domain RESERVE message is sent using the NTLP datagram mode (see Sections 4.4 and 4.5). Note that the GIST Datagram mode can be selected using the unreliable GIST API Transfer-Attributes. In addition, the intra-domain RESERVE (RMD-QSPEC) message MUST include a PHR container (PHR_Resource_Request) and the RMD QOSM <QoS Desired> object.
如果QNE边缘不支持QoS NSLP聚合过程，则此消息的IP源和IP目标地址必须等于数据流的IP源和IP目标地址。域内保留消息使用NTLP数据报模式发送（见第4.4节和第4.5节）。请注意，可以使用不可靠的GIST API传输属性选择GIST数据报模式。此外，域内保留（RMD-QSPEC）消息必须包括PHR容器（PHR_资源_请求）和RMD QOSM<QoS Desired>对象。
The end-to-end RESERVE message includes the initial QSPEC and it is sent towards the Egress QNE.
端到端保留消息包括初始QSPEC，并将其发送到出口QNE。
Note that after completing the initial discovery phase, the GIST Connection mode can be used between the QNE Ingress and QNE Egress. Note that the GIST Connection mode can be selected using the reliable GIST API Transfer-Attributes.
注意，在完成初始发现阶段之后，可以在QNE入口和QNE出口之间使用GIST连接模式。请注意，可以使用可靠的GIST API传输属性选择GIST连接模式。
The end-to-end RESERVE message is forwarded using the GIST forwarding procedure to bypass the Interior stateless or reduced-state QNE nodes; see Figure 8. The bypassing procedure is described in Section 4.4.
使用GIST转发过程转发端到端保留消息，以绕过内部无状态或简化状态QNE节点；参见图8。第4.4节描述了旁路程序。
At the QNE Ingress, the end-to-end RESERVE message is marked, i.e., modifying the QoS-NSLP default NSLPID value to another NSLPID predefined value that will be used by the GIST message carrying the end-to-end RESPONSE message to bypass the QNE Interior nodes. Note that the QNE Interior nodes (see [RFC5971]) are configured to handle only certain NSLP-IDs (see [RFC5974]).
在QNE入口处，标记端到端保留消息，即，将QoS NSLP默认NSLPID值修改为另一个NSLPID预定义值，该值将由携带端到端响应消息的GIST消息用于绕过QNE内部节点。请注意，QNE内部节点（请参阅[RFC5971]）配置为仅处理某些NSLP ID（请参阅[RFC5974]）。
Furthermore, note that the initial discovery phase and the process of sending the end-to-end RESERVE message towards the QNE Egress MAY be done simultaneously. This can be accomplished only if the GIST implementation is configured to perform that, e.g., via a local policy. However, the selection of the discovery procedure cannot be selected by the RMD-QOSM.
此外，注意，初始发现阶段和向QNE出口发送端到端保留消息的过程可以同时完成。仅当GIST实现被配置为执行该操作（例如，通过本地策略）时，这才能实现。但是，RMD-QOSM无法选择发现过程。
The (initial) intra-domain RESERVE message MUST be sent by the QNE Ingress and it MUST contain the following values (see the QoS-NSLP-RMF API described in [RFC5974]):
（初始）域内保留消息必须由QNE入口发送，并且必须包含以下值（参见[RFC5974]中描述的QoS NSLP RMF API）：
* the <RSN> object, whose value is generated and processed as described in [RFC5974];
* <RSN>对象，其值按照[RFC5974]中所述生成和处理；
* the <SCOPING> flag MUST NOT be set, meaning that a default scoping of the message is used. Therefore, the QNE Edges MUST be configured as RMD boundary nodes and the QNE Interior nodes MUST be configured as Interior (intermediary) nodes;
* 不能设置<SCOPING>标志，这意味着使用消息的默认作用域。因此，QNE边缘必须配置为RMD边界节点，QNE内部节点必须配置为内部（中间）节点；
* the <RII> MUST be included in this message, see [RFC5974];
* 此消息中必须包含<RII>，请参阅[RFC5974]；
* the <REPLACE> flag MUST be set to FALSE = 0;
* <REPLACE>标志必须设置为FALSE=0；
* The value of the <Message ID> value carried by the <MSG-ID> object is set according to [RFC5974]. The value of the <Message_Binding_Type> is set to "1".
* <MSG-ID>对象携带的<Message ID>值根据[RFC5974]设置。<Message\u Binding\u Type>的值设置为“1”。
* the value of the <REFRESH-PERIOD> object MUST be calculated and set by the QNE Ingress node as described in Section 4.6.1.3;
* <REFRESH-PERIOD>对象的值必须由QNE入口节点计算和设置，如第4.6.1.3节所述；
* the value of the <PACKET-CLASSIFIER> object is associated with the path-coupled routing Message Routing Message (MRM), since RMD-QOSM is used with the path-coupled MRM. The flag that has to be set is the <T> flag (traffic class) meaning that the packet classification of packets is based on the <DSCP> value included in the IP header of the packets. Note that the <DSCP> value used in
* <PACKET-CLASSIFIER>对象的值与路径耦合的路由消息（MRM）相关联，因为RMD-QOSM与路径耦合的MRM一起使用。必须设置的标志是<T>标志（流量类别），这意味着数据包的数据包分类基于数据包的IP报头中包含的<DSCP>值。请注意，中使用的<DSCP>值
the MRI can be derived by the value of <PHB Class> parameter, which MUST be carried by the intra-domain RESERVE message. Note that the QNE Ingress being a QNI for the intra-domain session it can pass this value to GIST, via the GIST API.
MRI可以通过<PHB Class>参数的值导出，该参数必须由域内保留消息携带。请注意，QNE入口是域内会话的QNI，它可以通过GIST API将此值传递给GIST。
* the PHR resource units MUST be included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter of the <QoS Desired> object.
* PHR资源单元必须包含在<QoS Desired>对象的本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段中。
When the QNE Edges use per-flow intra-domain QoS-NSLP states, then the <Peak Data Rate-1 (p)> value included in the initial QSPEC <TMOD-1> parameter is copied into the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter.
当QNE边缘使用每流域内QoS NSLP状态时，初始QSPEC<TMOD-1>参数中包含的<Peak Data Rate-1（p）>值被复制到本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>值中。
When the QNE Edges use aggregated intra-domain QoS-NSLP operational states, then the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter can be obtained by using the bandwidth aggregation method described in Section 4.3.1;
当QNE边缘使用聚合的域内QoS NSLP操作状态时，则可以通过使用第4.3.1节中描述的带宽聚合方法获得本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>值；
* the value of the <PHB Class> parameter can be defined by using the method of copying the <PHB Class> parameter carried by the initial QSPEC into the <PHB Class> carried by the RMD-QSPEC, which is described above in this subsection.
* <PHB Class>参数的值可以通过使用将初始QSPEC携带的<PHB Class>参数复制到RMD-QSPEC携带的<PHB Class>中的方法来定义，如本小节所述。
* the value of the <Parameter ID> field of the PHR container MUST be set to "17", (i.e., PHR_Resource_Request).
* PHR容器的<Parameter ID>字段的值必须设置为“17”（即PHR_资源_请求）。
* the value of the <Admitted Hops> parameter in the PHR container MUST be set to "1". Note that during a successful reservation, each time an RMD-QOSM-aware node processes the RMD-QSPEC, the <Admitted Hops> parameter is increased by one.
* PHR容器中<允许跳数>参数的值必须设置为“1”。请注意，在成功预约期间，每次RMD QOSM感知节点处理RMD-QSPEC时，<acempted Hops>参数增加1。
* the value of the <Hop_U> parameter in the PHR container MUST be set to "0".
* PHR容器中<Hop_>参数的值必须设置为“0”。
* the value of the <Max Admitted Hops> is set to "0".
* <Max acempted Hops>的值设置为“0”。
* If the initial QSPEC carried an <Admission Priority> parameter, then this parameter SHOULD be copied into the RMD-QSPEC and carried by the (initiating) intra-domain RESERVE.
* 如果初始QSPEC带有<准入优先级>参数，则该参数应复制到RMD-QSPEC中，并由（启动的）域内保留区携带。
Note that for the RMD-QOSM, a reservation established without an <Admission Priority> parameter is equivalent to a reservation with <Admission Priority> value of 1.
注意，对于RMD-QOSM，不使用<Admission Priority>参数建立的预留相当于<Admission Priority>值为1的预留。
Note that, in this case, each admission priority is associated with a priority traffic class. The three priority traffic classes (PHB_low_priority, PHB_normal_priority, and PHB_high_priority) MAY be associated with the same PHB (see Section 4.3.3).
注意，在这种情况下，每个接纳优先级与优先级业务类别相关联。三个优先级流量等级（PHB_低优先级、PHB_正常优先级和PHB_高优先级）可能与同一PHB相关（见第4.3.3节）。
* In a single RMD domain case, the PDR container MAY not be included in the message.
* 在单个RMD域的情况下，PDR容器可能不包括在消息中。
Note that the intra-domain RESERVE message does not carry the <BOUND-SESSION-ID> object. The reason for this is that the end-to-end RESERVE carries, in the <BOUND-SESSION-ID> object, the <SESSION-ID> value of the intra-domain session.
请注意，域内保留消息不携带<BOUND-SESSION-ID>对象。原因是端到端保留在<BOUND-SESSION-ID>对象中携带域内会话的<SESSION-ID>值。
When an end-to-end RESPONSE message is received by the QNE Ingress node, which was sent by a QNE Egress node (see Section 4.6.1.1.3), then it is processed according to [RFC5974] and end-to-end QoS Model rules.
当QNE入口节点接收到由QNE出口节点发送的端到端响应消息（参见第4.6.1.1.3节）时，根据[RFC5974]和端到端QoS模型规则对其进行处理。
When an intra-domain RESPONSE message is received by the QNE Ingress node, which was sent by a QNE Egress (see Section 4.6.1.1.3), it uses the QoS-NSLP procedures to match it to the earlier sent intra-domain RESERVE message. After this phase, the RMD-QSPEC has to be identified and processed.
当QNE入口节点接收到由QNE出口发送的域内响应消息（参见第4.6.1.1.3节）时，它使用QoS NSLP过程将其与先前发送的域内保留消息相匹配。在此阶段之后，必须识别和处理RMD-QSPEC。
The RMD QOSM reservation has been successful if the <M> bit carried by the "PDR Container" is equal to "0" (i.e., not set).
如果“PDR容器”携带的<M>位等于“0”（即未设置），则RMD QOSM保留已成功。
Furthermore, the <INFO-SPEC> object is processed as defined in the QoS-NSLP specification. In the case of successful reservation, the <INFO-SPEC> object MUST have the following values:
此外，<INFO-SPEC>对象按照QoS NSLP规范中的定义进行处理。在成功预订的情况下，<INFO-SPEC>对象必须具有以下值：
* Error severity class: Success * Error code value: Reservation successful
* 错误严重性等级：成功*错误代码值：预订成功
If the end-to-end RESPONSE message has to be forwarded to a node outside the RMD-QOSM-aware domain, then the values of the objects contained in this message (i.e., <RII> <RSN>, <INFO-SPEC>, [<QSPEC>]) MUST be set by the QoS-NSLP protocol functions of the QNE. If an end-to-end QUERY is received by the QNE Ingress, then the same bypassing procedure has to be used as the one applied for an end-to-end RESERVE message. In particular, it is forwarded using the GIST forwarding procedure to bypass the Interior stateless or reduced-state QNE nodes.
如果必须将端到端响应消息转发到RMD QOSM感知域之外的节点，则此消息中包含的对象的值（即，<RII><RSN>，<INFO-SPEC>，[<QSPEC>]）必须由QNE的QoS NSLP协议功能设置。如果QNE入口接收到端到端查询，则必须使用与应用于端到端保留消息相同的旁路过程。特别是，它使用GIST转发过程来绕过内部无状态或简化状态QNE节点进行转发。
Each QNE Interior node MUST use the QoS-NSLP and RMD-QOSM parameters of the intra-domain RESERVE (RMD-QSPEC) message as follows (see QoS-NSLP-RMF API described in [RFC5974]):
每个QNE内部节点必须使用域内保留（RMD-QSPEC）消息的QoS NSLP和RMD-QOSM参数，如下所示（参见[RFC5974]中描述的QoS NSLP RMF API）：
* the values of the <RSN>, <RII>, <PACKET-CLASSIFIER>, <REFRESH-PERIOD>, objects MUST NOT be changed.
* 不得更改<RSN>、<RII>、<PACKET-CLASSIFIER>、<REFRESH-PERIOD>对象的值。
The Interior node is informed by the <PACKET-CLASSIFIER> object that the packet classification SHOULD be done on the <DSCP> value. The flag that has to be set in this case is the <T> flag (traffic class). The value of the <DSCP> value MUST be obtained via the MRI parameters that the QoS-NSLP receives from GIST. A QNE Interior MUST be able to associate the value carried by the RMD-QSPEC <PHB Class> parameter and the <DSCP> value obtained via GIST. This is REQUIRED, because there are situations in which the <PHB Class> parameter is not carrying a <DSCP> value but a PHB ID code, see Section 4.1.1.
内部节点由<PACKET-CLASSIFIER>对象通知，应该根据<DSCP>值进行分组分类。在这种情况下必须设置的标志是<T>标志（流量类别）。<DSCP>值的值必须通过QoS NSLP从GIST接收的MRI参数获得。QNE内部必须能够将RMD-QSPEC<PHB Class>参数携带的值与通过GIST获得的<DSCP>值相关联。这是必需的，因为在某些情况下，<PHB Class>参数携带的不是<DSCP>值，而是PHB ID代码，请参见第4.1.1节。
* the flag <REPLACE> MUST be set to FALSE = 0;
* 标志<REPLACE>必须设置为FALSE=0；
* when the RMD reservation-based methods, described in Section 4.3.1 and 4.3.3, are used, the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter is used by the QNE Interior node for admission control. Furthermore, if the <Admission Priority> parameter is carried by the RMD-QOSM <QoS Desired> object, then this parameter is processed as described in the following bullets.
* 当使用第4.3.1节和第4.3.3节中描述的基于RMD保留的方法时，QNE内部节点使用本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>值进行准入控制。此外，如果RMD-QOSM<QoS Desired>对象携带<Allocation Priority>参数，则按照以下项目符号中所述处理该参数。
* in the case of the RMD reservation-based procedure, and if these resources are admitted (see Sections 4.3.1 and 4.3.3), they are added to the currently reserved resources. Furthermore, the value of the <Admitted Hops> parameter in the PHR container has to be increased by one.
* 对于基于RMD保留的程序，如果允许这些资源（参见第4.3.1节和第4.3.3节），它们将添加到当前保留的资源中。此外，PHR容器中<acempted Hops>参数的值必须增加1。
* If the bandwidth allocated for the PHB_high_priority traffic is fully utilized, and a high priority request arrives, other policies on allocating bandwidth can be used, which are beyond the scope of this document.
* 如果为PHB_高优先级流量分配的带宽得到充分利用，并且高优先级请求到达，则可以使用其他分配带宽的策略，这些策略超出了本文档的范围。
* If the RMD domain supports preemption during the admission control process, then the QNE Interior node can support the building blocks specified in the [RFC5974] and during the admission control process use the preemption handling algorithm specified in Appendix A.7.
* 如果RMD域在准入控制过程中支持抢占，则QNE内部节点可支持[RFC5974]中规定的构建块，并在准入控制过程中使用附录A.7中规定的抢占处理算法。
* in the case of the RMD measurement-based method (see Section 4.3.2), and if the requested into the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter is admitted, using a measurement-based admission control (MBAC) algorithm, then the number of this resource will be used to update the MBAC algorithm according to the operation described in Section 4.3.2.
* 对于基于RMD测量的方法（见第4.3.2节），如果使用基于测量的允许控制（MBAC）算法，允许将请求输入本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>值，然后，根据第4.3.2节中描述的操作，该资源的数量将用于更新MBAC算法。
When the end-to-end RESERVE message is received by the egress node, it is only forwarded further, towards QNR, if the processing of the intra-domain RESERVE(RMD-QSPEC) message was successful at all nodes in the RMD domain. In this case, the QNE Egress MUST stop the marking process that was used to bypass the QNE Interior nodes by reassigning the QoS-NSLP default NSLPID value to the end-to-end RESERVE message (see Section 4.4). Furthermore, the carried <BOUND-SESSION-ID> object associated with the intra-domain session MUST be removed after processing. Note that the received end-to-end RESERVE was tunneled within the RMD domain. Therefore, the tunneled initial QSPEC carried by the end-to-end RESERVE message has to be processed/set according to the [RFC5975] specification.
当出口节点接收到端到端保留消息时，如果域内保留（RMD-QSPEC）消息的处理在RMD域中的所有节点上成功，则仅向QNR进一步转发该消息。在这种情况下，QNE出口必须通过将QoS NSLP default NSLPID值重新分配给端到端保留消息来停止用于绕过QNE内部节点的标记过程（参见第4.4节）。此外，处理后必须删除与域内会话关联的所携带的<BOUND-SESSION-ID>对象。请注意，接收到的端到端保留是在RMD域中进行隧道传输的。因此，端到端保留消息携带的隧道初始QSPEC必须根据[RFC5975]规范进行处理/设置。
If a rerouting takes place, then the stateful QNE Egress is following the procedures specified in [RFC5974].
如果发生重新路由，则有状态QNE出口遵循[RFC5974]中指定的过程。
At this point, the intra-domain and end-to-end operational states MUST be initiated or modified according to the REQUIRED binding procedures.
此时，必须根据所需的绑定过程启动或修改域内和端到端操作状态。
The way in which the BOUND-SESSION-IDs are initiated and maintained in the intra-domain and end-to-end QoS-NSLP operational states is described in Sections 4.3.1 and 4.3.2.
第4.3.1节和第4.3.2节描述了在域内和端到端QoS NSLP操作状态下启动和维护绑定会话ID的方式。
If the processing of the intra-domain RESERVE(RMD-QSPEC) was not successful at all nodes in the RMD domain, then the inter-domain (end-to-end) reservation is considered to have failed.
如果域内保留（RMD-QSPEC）的处理在RMD域中的所有节点上都未成功，则域间（端到端）保留被视为已失败。
Furthermore, if the initial QSPEC object used an object combination of type 1 or 2 where the <QoS Available> is populated, and the intra-domain RESERVE(RMD-QSPEC) was not successful at all nodes in the RMD domain MUST be considered that the <QoS Available> is not satisfied and that the inter-domain (end-to-end) reservation is considered to have failed.
此外，如果初始QSPEC对象使用类型1或类型2的对象组合，其中填充了<QoS Available>，并且域内保留（RMD-QSPEC）在RMD域中的所有节点上都未成功，则必须考虑<QoS Available>未得到满足，并且域间（端到端）存在冲突预订被认为已失败。
Furthermore, note that when the QNE Egress uses per-flow intra-domain QoS-NSLP operational states (see Sections 4.3.2 and 4.3.3), the QNE Egress SHOULD support the message binding procedure described in [RFC5974], which can be used to synchronize the arrival of the end-
此外，请注意，当QNE出口使用每流域内QoS NSLP操作状态（参见第4.3.2和4.3.3节）时，QNE出口应支持[RFC5974]中描述的消息绑定过程，该过程可用于同步终端的到达-
to-end RESERVE and the intra-domain RESERVE (RMD-QSPEC) messages, see Section 5.7, and QoS-NSLP-RMF API described in [RFC5974]. Note that the intra-domain RESERVE message carries the <MSG-ID> object and its bound end-to-end RESERVE message carries the <BOUND-MSG-ID> object. Both these objects carry the <Message_Binding_Type> flag set to the value of "1". If these two messages do not arrive during the time defined by the MsgIDWait timer, then the reservation is considered to have failed. Note that the timer has to be preconfigured and it has to have the same value in the RMD domain. In this case, an end-to-end RESPONSE message, see QoS-NSLP-RMF API described in [RFC5974], is sent towards the QNE Ingress with the following <INFO-SPEC> values:
要结束保留和域内保留（RMD-QSPEC）消息，请参阅第5.7节，以及[RFC5974]中描述的QoS NSLP RMF API。请注意，域内保留消息携带<MSG-ID>对象，其绑定端到端保留消息携带<bound-MSG-ID>对象。这两个对象都带有设置为值“1”的<Message\u Binding\u Type>标志。如果这两条消息没有在MsgIDWait计时器定义的时间内到达，则认为预订失败。请注意，计时器必须预先配置，并且在RMD域中必须具有相同的值。在这种情况下，向QNE入口发送端到端响应消息（参见[RFC5974]中描述的QoS NSLP RMF API），其值如下所示：
Error class: Transient Failure Error code: Mismatch synchronization between end-to-end RESERVE and intra-domain RESERVE
错误类别：瞬时故障错误代码：端到端保留和域内保留之间的同步不匹配
When the intra-domain RESERVE (RMD-QSPEC) is received by the QNE
Egress node of the session associated with the intra-domain
RESERVE(RMD-QSPEC) (the PHB session) with the session included in its
<BOUND-SESSION-ID> object MUST be bound according to the
specification given in [RFC5974]. The SESSION-ID included in the
BOUND-SESSION-ID parameter stored in the intra-domain QoS-NSLP
operational state object is the SESSION-ID of the session associated
with the end-to-end RESERVE message(s). Note that if the QNE Edge
nodes maintain per-flow intra-domain QoS-NSLP operational states,
then the value of Binding_Code = (Tunnel and end-to-end sessions) is
used. If the QNE Edge nodes maintain per-aggregated QoS-NSLP intra-
domain reservation states, then the value of Binding_Code =
(Aggregated sessions), see Sections 4.3.1 and 4.3.2.
When the intra-domain RESERVE (RMD-QSPEC) is received by the QNE
Egress node of the session associated with the intra-domain
RESERVE(RMD-QSPEC) (the PHB session) with the session included in its
<BOUND-SESSION-ID> object MUST be bound according to the
specification given in [RFC5974]. The SESSION-ID included in the
BOUND-SESSION-ID parameter stored in the intra-domain QoS-NSLP
operational state object is the SESSION-ID of the session associated
with the end-to-end RESERVE message(s). Note that if the QNE Edge
nodes maintain per-flow intra-domain QoS-NSLP operational states,
then the value of Binding_Code = (Tunnel and end-to-end sessions) is
used. If the QNE Edge nodes maintain per-aggregated QoS-NSLP intra-
domain reservation states, then the value of Binding_Code =
(Aggregated sessions), see Sections 4.3.1 and 4.3.2.
If the RMD domain supports preemption during the admission control process, then the QNE Egress node can support the building blocks specified in the [RFC5974] and during the admission control process use the example preemption handling algorithm described in Appendix A.7.
如果RMD域在准入控制过程中支持抢占，那么QNE出口节点可以支持[RFC5974]中指定的构建块，并且在准入控制过程中使用附录A.7中描述的示例抢占处理算法。
The end-to-end RESERVE message is generated/forwarded further upstream according to the [RFC5974] and [RFC5975] specifications. Furthermore, the <B> (BREAK) QoS-NSLP flag in the end-to-end RESERVE message MUST NOT be set, see the QoS-NSLP-RMF API described in QoS-NSLP.
端到端保留消息根据[RFC5974]和[RFC5975]规范生成/转发到更上游。此外，不得设置端到端保留消息中的<B>（中断）QoS NSLP标志，请参阅QoS NSLP中描述的QoS NSLP RMF API。
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | |
--->| | | RESERVE |
|------------------------------------------------------------>|
|RESERVE(RMD-QSPEC) | | |
|------------------->| | |
| |RESERVE(RMD-QSPEC) | |
| |------------------>| |
| | | RESERVE(RMD-QSPEC) |
| | |------------------->|
| |RESPONSE(RMD-QSPEC)| |
|<------------------------------------------------------------|
| | | RESERVE
| | | |-->
| | | RESPONSE
| | | |<--
| |RESPONSE | |
|<------------------------------------------------------------|
RESPONSE | | |
<---| | | |
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | |
--->| | | RESERVE |
|------------------------------------------------------------>|
|RESERVE(RMD-QSPEC) | | |
|------------------->| | |
| |RESERVE(RMD-QSPEC) | |
| |------------------>| |
| | | RESERVE(RMD-QSPEC) |
| | |------------------->|
| |RESPONSE(RMD-QSPEC)| |
|<------------------------------------------------------------|
| | | RESERVE
| | | |-->
| | | RESPONSE
| | | |<--
| |RESPONSE | |
|<------------------------------------------------------------|
RESPONSE | | |
<---| | | |
Figure 8: Basic operation of successful reservation procedure used by the RMD-QOSM
图8:RMD-QOSM使用的成功预订程序的基本操作
The QNE Egress MUST generate an intra-domain RESPONSE (RMD-Qspec) message. The intra-domain RESPONSE (RMD-QSPEC) message MUST be sent to the QNE Ingress node, i.e., the previous stateful hop by using the procedures described in Sections 4.4 and 4.5.
QNE出口必须生成域内响应（RMD Qspec）消息。域内响应（RMD-QSPEC）消息必须通过使用第4.4节和第4.5节中描述的过程发送到QNE入口节点，即前一个有状态跃点。
The values of the RMD-QSPEC that are carried by the intra-domain RESPONSE message MUST be used and/or set in the following way (see the QoS-NSLP-RMF API described in [RFC5974]):
域内响应消息携带的RMD-QSPEC值必须按以下方式使用和/或设置（请参阅[RFC5974]中描述的QoS NSLP RMF API）：
* the <RII> object carried by the intra-domain RESERVE message, see Section 4.6.1.1.1, has to be copied and carried by the intra-domain RESPONSE message.
* 域内保留消息携带的<RII>对象（见第4.6.1.1.1节）必须由域内响应消息复制和携带。
* the value of the <Parameter ID> field of the PDR container MUST be set to "23" (i.e., PDR_Reservation_Report);
* PDR容器的<Parameter ID>字段的值必须设置为“23”（即PDR_Reservation_Report）；
* the value of the <M> field of the PDR container MUST be equal to the value of the <M> parameter of the PHR container that was carried by its associated intra-domain RESERVE(RMD-QSPEC) message. This is REQUIRED since the value of the <M> parameter is used to indicate the status if the RMD reservation request to the Ingress Edge.
* PDR容器的<M>字段的值必须等于其关联的域内保留（RMD-QSPEC）消息所携带的PHR容器的<M>参数的值。这是必需的，因为<M>参数的值用于指示RMD保留请求到入口边缘时的状态。
If the binding between the intra-domain session and the end-to-end session uses a Binding_Code that is (Aggregated sessions), and there is no aggregated QoS-NSLP operational state associated with the intra-domain session available, then the RMD modification of aggregated reservation procedure described in Section 4.6.1.4 can be used.
如果域内会话和端到端会话之间的绑定使用绑定代码（聚合会话），并且没有与域内会话相关联的聚合QoS NSLP操作状态可用，则可以使用第4.6.1.4节中描述的聚合保留过程的RMD修改。
If the QNE Egress receives an end-to-end RESPONSE message, it is processed and forwarded towards the QNE Ingress. In particular, the non-default values of the objects contained in the end-to-end RESPONSE message MUST be used and/or set by the QNE Egress as follows (see the QoS-NSLP-RMF API described in [RFC5974]):
如果QNE出口接收到端到端响应消息，则处理该消息并将其转发到QNE入口。具体而言，QNE出口必须使用和/或设置端到端响应消息中包含的对象的非默认值，如下所示（参见[RFC5974]中描述的QoS NSLP RMF API）：
* the values of the <RII>, <RSN>, <INFO-SPEC>, [<QSPEC>] objects are set according to [RFC5974] and/or [RFC5975]. The <INFO-SPEC> object SHOULD be set by the QoS-NSLP functionality. In the case of successful reservation, the <INFO-SPEC> object SHOULD have the following values:
* <RII>、<RSN>、<INFO-SPEC>、[<QSPEC>]对象的值根据[RFC5974]和/或[RFC5975]设置。<INFO-SPEC>对象应由QoS NSLP功能设置。在成功预订的情况下，<INFO-SPEC>对象应具有以下值：
Error severity class: Success Error code value: Reservation successful
错误严重性类别：成功错误代码值：保留成功
* furthermore, an initial QSPEC object MUST be included in the end-to-end RESPONSE message. The parameters included in the QSPEC <QoS Reserved> object are copied from the original <QoS Desired> values.
* 此外，端到端响应消息中必须包含初始QSPEC对象。QSPEC<QoS Reserved>对象中包含的参数是从原始<QoS Desired>值复制而来的。
The end-to-end RESPONSE message is delivered as normal, i.e., is addressed and sent to its upstream QoS-NSLP neighbor, i.e., the QNE Ingress node.
端到端响应消息按正常方式传递，即寻址并发送到其上游QoS NSLP邻居，即QNE入口节点。
Note that if a QNE Egress receives an end-to-end QUERY that was bypassed through the RMD domain, it MUST stop the marking process that was used to bypass the QNE Interior nodes. This can be done by reassigning the QoS-NSLP default NSLPID value to the end-to-end QUERY message; see Section 4.4.
请注意，如果QNE出口接收到通过RMD域绕过的端到端查询，则必须停止用于绕过QNE内部节点的标记过程。这可以通过将QoS NSLP默认NSLPID值重新分配给端到端查询消息来实现；见第4.4节。
This subsection describes the operation where a request for reservation cannot be satisfied by the RMD-QOSM.
本小节描述了RMD-QOSM无法满足预订请求的操作。
The QNE Ingress, the QNE Interior, and QNE Egress nodes process and forward the end-to-end RESERVE message and the intra-domain RESERVE(RMD-QSPEC) message in a similar way, as specified in Section 4.6.1.1. The main difference between the unsuccessful operation and successful operation is that one of the QNE nodes does not admit the
QNE入口、QNE内部和QNE出口节点以类似方式处理和转发端到端保留消息和域内保留（RMD-QSPEC）消息，如第4.6.1.1节所述。失败操作和成功操作之间的主要区别在于其中一个QNE节点不允许
request, e.g., due to lack of resources. This also means that the QNE Edge node MUST NOT forward the end-to-end RESERVE message towards the QNR node.
请求，例如，由于缺乏资源。这也意味着QNE边缘节点不得向QNR节点转发端到端保留消息。
Note that the described functionality applies to the RMD reservation-based methods (see Sections 4.3.1 and 4.3.2) and to the NSIS measurement-based admission control method (see Section 4.3.2).
注意，所述功能适用于基于RMD保留的方法（见第4.3.1和4.3.2节）和基于NSIS测量的准入控制方法（见第4.3.2节）。
The QNE Edge nodes maintain either per-flow QoS-NSLP reservation states or aggregated QoS-NSLP reservation states. When the QNE Edges maintain aggregated QoS-NSLP reservation states, the RMD-QOSM functionality MAY accomplish an RMD modification procedure (see Section 4.6.1.4), instead of the reservation initiation procedure that is described in this subsection.
QNE边缘节点维护每流QoS NSLP保留状态或聚合QoS NSLP保留状态。当QNE边缘保持聚合QoS NSLP保留状态时，RMD-QOSM功能可以完成RMD修改程序（参见第4.6.1.4节），而不是本小节中描述的保留启动程序。
When an end-to-end RESERVE message arrives at the QNE Ingress and if (1) the "Maximum Packet Size-1 (MPS)" included in the end-to-end QoS Model <TMOD-1> is larger than this smallest MTU value within the RMD domain or (2) there are no resources available, the QNE Ingress MUST reject this end-to-end RESERVE message and send an end-to-end RESPONSE message back to the sender, as described in the QoS-NSLP specification, see [RFC5974] and [RFC5975].
当端到端保留消息到达QNE入口时，如果（1）端到端QoS模型<TMOD-1>中包含的“最大数据包大小-1（MPS）”大于RMD域中的最小MTU值，或者（2）没有可用资源，QNE入口必须拒绝此端到端保留消息，并将端到端响应消息发送回发送方，如QoS NSLP规范所述，请参阅[RFC5974]和[RFC5975]。
When an end-to-end RESPONSE message is received by an Ingress node (see Section 4.6.1.2.3), the values of the <RII>, <RSN>, <INFO-SPEC>, and [<QSPEC>] objects are processed according to the QoS-NSLP procedures.
当入口节点接收到端到端响应消息时（参见第4.6.1.2.3节），将根据QoS NSLP过程处理<RII>、<RSN>、<INFO-SPEC>和[<QSPEC>]对象的值。
If the end-to-end RESPONSE message has to be forwarded upstream to a node outside the RMD-QOSM-aware domain, then the values of the objects contained in this message (i.e., <RII<, <RSN>, <INFO-SPEC>, [<QSPEC>]) MUST be set by the QoS-NSLP protocol functions of the QNE.
如果端到端响应消息必须向上游转发到RMD QOSM感知域之外的节点，则此消息中包含的对象的值（即，<RII<，<RSN>，<INFO-SPEC>，[<QSPEC>]）必须由QNE的QoS NSLP协议功能设置。
When an intra-domain RESPONSE message is received by the QNE Ingress node, which was sent by a QNE Egress (see Section 4.6.1.2.3), it uses the QoS-NSLP procedures to match it to the intra-domain RESERVE message that was previously sent. After this phase, the RMD-QSPEC has to be identified and processed. Note that, in this case, the RMD Resource Management Function (RMF) is notified that the reservation has been unsuccessful, by reading the <M> parameter of the PDR container. Note that when the QNE Edges maintain a per-flow QoS-NSLP reservation state, the RMD-QOSM functionality, has to start an RMD release procedure (see Section 4.6.1.5). When the QNE Edges maintain aggregated QoS-NSLP reservation states, the RMD-QOSM functionality MAY start an RMD modification procedure (see Section 4.6.1.4).
当QNE入口节点接收到由QNE出口发送的域内响应消息（参见第4.6.1.2.3节）时，它使用QoS NSLP过程将其与先前发送的域内保留消息相匹配。在此阶段之后，必须识别和处理RMD-QSPEC。注意，在这种情况下，通过读取PDR容器的<M>参数，RMD资源管理功能（RMF）被通知预约已失败。注意，当QNE边缘保持每流QoS NSLP保留状态时，RMD-QOSM功能必须启动RMD发布程序（见第4.6.1.5节）。当QNE边缘保持聚合QoS NSLP保留状态时，RMD-QOSM功能可启动RMD修改程序（参见第4.6.1.4节）。
In the case of the RMD reservation-based scenario, and if the intra-domain reservation request is not admitted by the QNE Interior node, then the <Hop_U> and <M> parameters of the PHR container MUST be set to "1". The <Admitted Hops> counter MUST NOT be increased. Moreover, the value of the <Max Admitted Hops> counter MUST be set equal to the <Admitted Hops> value.
在基于RMD保留的场景中，如果QNE内部节点不允许域内保留请求，则PHR容器的<Hop_>和<M>参数必须设置为“1”。不得增加<允许跳数>计数器。此外，<Max acempted Hops>计数器的值必须设置为等于<acempted Hops>值。
Furthermore, the <E> flag associated with the QSPEC <QoS Desired> object and the <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter SHOULD be set. In the case of the RMD measurement-based scenario, the <M> parameter of the PHR container MUST be set to "1". Furthermore, the <E> flag associated with the QSPEC <QoS Desired> object and the <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter SHOULD be set. Note that the <M> flag seems to be set in a similar way to the <E> flag used by the local RMD-QSPEC <TMOD-1> parameter. However, the ways in which the two flags are processed by a QNE are different.
此外，应设置与QSPEC<QoS Desired>对象关联的<E>标志和与本地RMD-QSPEC<TMOD-1>参数关联的<E>标志。在基于RMD测量的情况下，PHR容器的<M>参数必须设置为“1”。此外，应设置与QSPEC<QoS Desired>对象关联的<E>标志和与本地RMD-QSPEC<TMOD-1>参数关联的<E>标志。请注意，<M>标志的设置方式似乎与本地RMD-QSPEC<TMOD-1>参数使用的<E>标志类似。但是，QNE处理这两个标志的方式不同。
In general, if a QNE Interior node receives an RMD-QSPEC <TMOD-1> parameter with the <E> flag set and a PHR container type "PHR_Resource_Request", with the <M> parameter set to "1", then this "PHR Container" and the RMD-QOSM <QoS Desired> object) MUST NOT be processed. Furthermore, when the <K> parameter that is included in the "PHR Container" and carried by a RESERVE message is set to "1", then this "PHR Container" and the RMD-QOSM <QoS Desired> object) MUST NOT be processed.
通常，如果QNE内部节点接收到设置了<E>标志的RMD-QSPEC<TMOD-1>参数和设置了<M>参数为“1”的PHR容器类型“PHR_资源_请求”，则不得处理该“PHR容器”和RMD-QOSM<QoS所需>对象）。此外，当包含在“PHR容器”中并由保留消息携带的<K>参数设置为“1”时，则不得处理该“PHR容器”和RMD-QOSM<QoS期望>对象）。
In the RMD reservation-based (Section 4.3.3) and RMD NSIS measurement-based scenarios (Section 4.3.2), when the <M> marked intra-domain RESERVE(RMD-QSPEC) is received by the QNE Egress node (see Figure 9), the session associated with the intra-domain RESERVE(RMD-QSPEC) (the PHB session) and the end-to-end session MUST be bound.
在基于RMD保留的场景（第4.3.3节）和基于RMD NSIS度量的场景（第4.3.2节）中，当QNE出口节点接收到<M>标记的域内保留（RMD-QSPEC）时（见图9），必须绑定与域内保留（RMD-QSPEC）（PHB会话）和端到端会话相关的会话。
Moreover, if the initial QSPEC object (used by the end-to-end QoS Model) used an object combination of type 1 or 2 where the <QoS Available> is populated, and the intra-domain RESERVE(RMD-QSPEC) was not successful at all nodes in the RMD domain, i.e., the intra-domain RESERVE(RMD-QSPEC) message is marked, it MUST be considered that the <QoS Available> is not satisfied and that the inter-domain (end-to-end) reservation is considered as to have failed.
此外，如果初始QSPEC对象（由端到端QoS模型使用）使用类型1或2的对象组合，其中填充了<QoS Available>，并且域内保留（RMD-QSPEC）在RMD域中的所有节点上都未成功，即标记了域内保留（RMD-QSPEC）消息，必须考虑到<QoS Available>未得到满足，并且域间（端到端）保留被认为已失败。
When the QNE Egress uses per-flow intra-domain QoS-NSLP operational states (see Sections 4.3.2 and 4.3.3), then the QNE Egress node MUST generate an end-to-end RESPONSE message that has to be sent to its previous stateful QoS-NSLP hop (see the QoS-NSLP-RMF API described in [RFC5974]).
当QNE出口使用每流域内QoS NSLP操作状态（参见第4.3.2和4.3.3节）时，QNE出口节点必须生成端到端响应消息，该消息必须发送到其先前的有状态QoS NSLP跳（参见[RFC5974]中描述的QoS NSLP RMF API）。
* the values of the <RII>, <RSN> and <INFO-SPEC> objects are set by the standard QoS-NSLP protocol functions. In the case of an unsuccessful reservation, the <INFO-SPEC> object SHOULD have the following values:
* <RII>、<RSN>和<INFO-SPEC>对象的值由标准QoS NSLP协议函数设置。如果预订失败，<INFO-SPEC>对象应具有以下值：
Error severity class: Transient Failure Error code value: Reservation failure
错误严重性等级：瞬时故障错误代码值：保留故障
The QSPEC that was carried by the end-to-end RESERVE message that belongs to the same session as this end-to-end RESPONSE message is included in this message.
此消息中包含由属于与此端到端响应消息相同会话的端到端保留消息承载的QSPEC。
In particular, the parameters included in the QSPEC <QoS Reserved> object of the end-to-end RESPONSE message are copied from the initial <QoS Desired> values included in its associated end-to-end RESERVE message. The <E> flag associated with the QSPEC <QoS Reserved> object and the <E> flag associated with the <TMOD-1> parameter included in the end-to-end RESPONSE are set.
具体而言，端到端响应消息的QSPEC<QoS Reserved>对象中包括的参数是从其相关的端到端保留消息中包括的初始<QoS Desired>值复制而来的。设置与QSPEC<QoS Reserved>对象关联的<E>标志以及与端到端响应中包含的<TMOD-1>参数关联的<E>标志。
In addition to the above, similar to the successful operation, see Section 4.6.1.1.3, the QNE Egress MUST generate an intra-domain RESPONSE message that has to be sent to its previous stateful QoS-NSLP hop.
除上述内容外，与成功操作类似，参见第4.6.1.1.3节，QNE出口必须生成域内响应消息，该消息必须发送到其先前的有状态QoS NSLP跳。
The values of the <RII>, <RSN> and <INFO-SPEC> objects are set by the standard QoS-NSLP protocol functions. In the case of an unsuccessful reservation, the <INFO-SPEC> object SHOULD have the following values (see the QoS-NSLP-RMF API described in [RFC5974]):
<RII>、<RSN>和<INFO-SPEC>对象的值由标准QoS NSLP协议函数设置。在预订失败的情况下，<INFO-SPEC>对象应具有以下值（参见[RFC5974]中描述的QoS NSLP RMF API）：
Error severity class: Transient Failure Error code value: Reservation failure
错误严重性等级：瞬时故障错误代码值：保留故障
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | |
--->| | | RESERVE |
|------------------------------------------------------------>|
|RESERVE(RMD-QSPEC:M=0) | |
|------------------->| | |
| |RESERVE(RMD-QSPEC:M=1) |
| |------------------>| |
| | | RESERVE(RMD-QSPEC:M=1)
| | |------------------->|
| |RESPONSE(RMD-QOSM) | |
|<------------------------------------------------------------|
| |RESPONSE | |
|<------------------------------------------------------------|
RESPONSE | | |
<---| | | |
RESERVE(RMD-QSPEC: Tear=1, M=1, <Admitted Hops>=<Max Admitted Hops>
|------------------->| | |
|RESERVE(RMD-QSPEC: Tear=1, M=1, K=1) |
| |------------------>| |
| RESERVE(RMD-QSPEC: Tear=1, M=1, K=1)|
| | |------------------->|
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | |
--->| | | RESERVE |
|------------------------------------------------------------>|
|RESERVE(RMD-QSPEC:M=0) | |
|------------------->| | |
| |RESERVE(RMD-QSPEC:M=1) |
| |------------------>| |
| | | RESERVE(RMD-QSPEC:M=1)
| | |------------------->|
| |RESPONSE(RMD-QOSM) | |
|<------------------------------------------------------------|
| |RESPONSE | |
|<------------------------------------------------------------|
RESPONSE | | |
<---| | | |
RESERVE(RMD-QSPEC: Tear=1, M=1, <Admitted Hops>=<Max Admitted Hops>
|------------------->| | |
|RESERVE(RMD-QSPEC: Tear=1, M=1, K=1) |
| |------------------>| |
| RESERVE(RMD-QSPEC: Tear=1, M=1, K=1)|
| | |------------------->|
Figure 9: Basic operation during unsuccessful reservation initiation used by the RMD-QOSM
图9:RMD-QOSM使用的预订启动失败期间的基本操作
The values of the RMD-QSPEC MUST be used and/or set in the following way (see the QoS-NSLP-RMF API described in [RFC5974]):
必须按照以下方式使用和/或设置RMD-QSPEC的值（参见[RFC5974]中描述的QoS NSLP RMF API）：
* the value of the <PDR Control Type> of the PDR container MUST be set to "23" (PDR_Reservation_Report);
* PDR容器的<PDR控制类型>的值必须设置为“23”（PDR_保留_报告）；
* the value of the <Max Admitted Hops> parameter of the PHR container included in the received <M> marked intra-domain RESERVE (RMD-QSPEC) MUST be included in the <Max Admitted Hops> parameter of the PDR container;
* 包含在接收的<M>标记的域内保留（RMD-QSPEC）中的PHR容器的<Max acempted Hops>参数的值必须包含在PDR容器的<Max acempted Hops>参数中；
* the value of the <M> parameter of the PDR container MUST be "1".
* PDR容器的<M>参数值必须为“1”。
In the case of the RMD measurement-based method, see Section 4.3.2, QoS-NSLP reservation states in the RMD domain are not typically maintained, therefore, this method typically does not use an intra-domain refresh procedure.
对于基于RMD测量的方法，请参见第4.3.2节，RMD域中的QoS NSLP保留状态通常不保持，因此，该方法通常不使用域内刷新过程。
However, there are measurement-based optimization schemes, see [GrTs03], that MAY use the refresh procedures described in Sections 4.6.1.3.1 and 4.6.1.3.3. However, this measurement-based optimization scheme can only be applied in the RMD domain if the QNE Edges are configured to perform intra-domain refresh procedures and if all the QNE Interior nodes are configured to perform the measurement-based optimization schemes.
但是，也有基于测量的优化方案，见[GrTs03]，可使用第4.6.1.3.1节和第4.6.1.3.3节中所述的刷新程序。然而，如果QNE边缘被配置为执行域内刷新过程，并且如果所有QNE内部节点被配置为执行基于测量的优化方案，则该基于测量的优化方案只能应用于RMD域。
In the description given in this subsection, it is assumed that the RMD measurement-based scheme does not use the refresh procedures.
在本小节给出的描述中，假设基于RMD测量的方案不使用刷新过程。
When the QNE Edges maintain aggregated or per-flow QoS-NSLP operational and reservation states (see Sections 4.3.1 and 4.3.3), then the refresh procedures are very similar. If the RESERVE messages arrive within the soft state timeout period, the corresponding number of resource units are not removed. However, the transmission of the intra-domain and end-to-end (refresh) RESERVE message are not necessarily synchronized. Furthermore, the generation of the end-to-end RESERVE message, by the QNE Edges, depends on the locally maintained refreshed interval (see [RFC5974]).
当QNE边缘保持聚合或按流QoS NSLP操作和保留状态时（参见第4.3.1节和第4.3.3节），则刷新过程非常相似。如果保留消息在软状态超时时间内到达，则不会删除相应数量的资源单元。然而，域内和端到端（刷新）保留消息的传输不一定同步。此外，QNE边缘生成端到端保留消息取决于本地维护的刷新间隔（参见[RFC5974]）。
The Ingress node MUST be able to generate an intra-domain (refresh) RESERVE(RMD-QSPEC) at any time defined by the refresh period/timer. Before generating this message, the RMD QoS signaling model functionality is using the RMD traffic class (PHR) resource units for refreshing the RMD traffic class state.
入口节点必须能够在刷新周期/计时器定义的任何时间生成域内（刷新）保留（RMD-QSPEC）。在生成此消息之前，RMD QoS信令模型功能正在使用RMD流量类（PHR）资源单元来刷新RMD流量类状态。
Note that the RMD traffic class refresh periods MUST be equal in all QNE Edge and QNE Interior nodes and SHOULD be smaller (default: more than two times smaller) than the refresh period at the QNE Ingress node used by the end-to-end RESERVE message. The intra-domain RESERVE (RMD-QSPEC) message MUST include an RMD-QOSM <QoS Desired> and a PHR container (i.e., PHR_Refresh_Update).
请注意，在所有QNE边缘和QNE内部节点中，RMD流量类刷新周期必须相等，并且应该小于端到端保留消息所使用的QNE入口节点处的刷新周期（默认值：小于两倍以上）。域内保留（RMD-QSPEC）消息必须包括RMD-QOSM<QoS Desired>和PHR容器（即PHR_Refresh_Update）。
An example of this refresh operation can be seen in Figure 10.
此刷新操作的示例如图10所示。
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
|RESERVE(RMD-QSPEC) | | |
|------------------->| | |
| |RESERVE(RMD-QSPEC) | |
| |------------------>| |
| | | RESERVE(RMD-QSPEC) |
| | |------------------->|
| | | |
| |RESPONSE(RMD-QSPEC)| |
|<------------------------------------------------------------|
| | | |
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
|RESERVE(RMD-QSPEC) | | |
|------------------->| | |
| |RESERVE(RMD-QSPEC) | |
| |------------------>| |
| | | RESERVE(RMD-QSPEC) |
| | |------------------->|
| | | |
| |RESPONSE(RMD-QSPEC)| |
|<------------------------------------------------------------|
| | | |
Figure 10: Basic operation of RMD-specific refresh procedure
图10:RMD特定刷新过程的基本操作
Most of the non-default values of the objects contained in this message MUST be used and set by the QNE Ingress in the same way as described in Section 4.6.1.1. The following objects are used and/or set differently:
QNE入口必须以第4.6.1.1节所述的相同方式使用和设置此消息中包含的大多数对象的非默认值。以下对象的使用和/或设置方式不同：
* the PHR resource units MUST be included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter. The <Peak Data Rate-1 (p)> field value of the local RMD-QSPEC <TMOD-1> parameter depends on how the different inter-domain (end-to-end) flows are aggregated by the QNE Ingress node (e.g., the sum of all the PHR-requested resources of the aggregated flows); see Section 4.3.1. If no QoS-NSLP aggregation is accomplished by the QNE Ingress node, the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter SHOULD be equal to the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of its associated new (initial) intra-domain RESERVE (RMD-QSPEC) message; see Section 4.3.3.
* PHR资源单位必须包含在本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段中。本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段值取决于QNE入口节点如何聚合不同的域间（端到端）流（例如，聚合流的所有PHR请求资源的总和）；见第4.3.1节。如果QNE入口节点未完成QoS NSLP聚合，则本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>值应等于其相关联的新（初始）域内保留（RMD-QSPEC）消息的本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>值；见第4.3.3节。
* the value of the Container field of the <PHR Container> MUST be set to "19", i.e., "PHR_Refresh_Update".
* <PHR Container>的Container字段的值必须设置为“19”，即“PHR\u Refresh\u Update”。
When the intra-domain RESPONSE (RMD-QSPEC) message (see Section 4.6.1.3.3), is received by the QNE Ingress node, then:
当QNE入口节点接收到域内响应（RMD-QSPEC）消息（见第4.6.1.3.3节）时，则：
* the values of the <RII>, <RSN>, <INFO-SPEC>, and [RFC5975] objects are processed by the standard QoS-NSLP protocol functions (see Section 4.6.1.1);
* <RII>、<RSN>、<INFO-SPEC>和[RFC5975]对象的值由标准QoS NSLP协议函数处理（见第4.6.1.1节）；
* the "PDR Container" has to be processed by the RMD-QOSM functionality in the QNE Ingress node. The RMD-QOSM functionality is notified by the <PDR M> parameter of the PDR container that the refresh procedure has been successful or unsuccessful. All
* “PDR容器”必须由QNE入口节点中的RMD-QOSM功能处理。RMD-QOSM功能由PDR容器的<PDR M>参数通知刷新过程已成功或失败。全部的
sessions associated with this RMD-specific refresh session MUST be informed about the success or failure of the refresh procedure. (When aggregated QoS-NSLP operational and reservation states are used (see Section 4.3.1), there will be more than one session.) In the case of failure, the QNE Ingress node has to generate (in a standard QoS-NSLP way) an error end-to-end RESPONSE message that will be sent towards the QNI.
必须将刷新过程的成功或失败通知与此RMD特定刷新会话关联的会话。（当使用聚合QoS NSLP操作和保留状态时（参见第4.3.1节），将有多个会话。）在故障情况下，QNE入口节点必须（以标准QoS NSLP方式）生成将发送到QNI的错误端到端响应消息。
The intra-domain RESERVE (RMD-QSPEC) message is received and processed by the QNE Interior nodes. Any QNE Edge or QNE Interior node that receives a <PHR_Refresh_Update> field MUST identify the traffic class state (PHB) (using the <PHB Class> parameter). Most of the parameters in this refresh intra-domain RESERVE (RMD-QSPEC) message MUST be used and/or set by a QNE Interior node in the same way as described in Section 4.6.1.1.
域内保留（RMD-QSPEC）消息由QNE内部节点接收和处理。任何接收到<PHR\u Refresh\u Update>字段的QNE边缘或QNE内部节点必须识别流量类别状态（PHB）（使用<PHB class>参数）。QNE内部节点必须以第4.6.1.1节所述的相同方式使用和/或设置此刷新域内保留（RMD-QSPEC）消息中的大多数参数。
The following objects are used and/or set differently:
以下对象的使用和/或设置方式不同：
* the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired> is used by the QNE Interior node for refreshing the RMD traffic class state. These resources (included in the <Peak Data Rate-1 (p)> value of local RMD-QSPEC <TMOD-1>), if reserved, are added to the currently reserved resources per PHB and therefore they will become a part of the per-traffic class (PHB) reservation state (see Sections 4.3.1 and 4.3.3). If the refresh procedure cannot be fulfilled then the <M> and <S> fields carried by the PHR container MUST be set to "1".
* QNE内部节点使用RMD-QOSM<QoS Desired>的本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>值来刷新RMD流量等级状态。这些资源（包括在本地RMD-QSPEC<TMOD-1>的<Peak Data Rate-1（p）>值中）如果保留，将添加到每个PHB当前保留的资源中，因此它们将成为每个流量等级（PHB）保留状态的一部分（见第4.3.1节和第4.3.3节）。如果无法完成刷新过程，则PHR容器携带的<M>和<S>字段必须设置为“1”。
* furthermore, the <E> flag associated with <QoS Desired> object and the <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter SHOULD be set.
* 此外，应设置与<QoS Desired>对象关联的<E>标志和与本地RMD-QSPEC<TMOD-1>参数关联的<E>标志。
Any PHR container of type "PHR_Refresh_Update", and its associated local RMD-QSPEC <TMOD-1>, whether or not it is marked and independent of the <E> flag value of the local RMD-QSPEC <TMOD-1> parameter, is always processed, but marked bits are not changed.
“PHR_Refresh_Update”类型的任何PHR容器及其关联的本地RMD-QSPEC<TMOD-1>，无论是否标记且独立于本地RMD-QSPEC<TMOD-1>参数的<E>标志值，都将始终进行处理，但标记位不会更改。
The intra-domain RESERVE(RMD-QSPEC) message is received and processed by the QNE Egress node. A new intra-domain RESPONSE (RMD-QSPEC) message is generated by the QNE Egress node and MUST include a PDR (type PDR_Refresh_Report).
域内保留（RMD-QSPEC）消息由QNE出口节点接收和处理。QNE出口节点生成新的域内响应（RMD-QSPEC）消息，该消息必须包含PDR（类型PDR_Refresh_Report）。
The (refresh) intra-domain RESPONSE (RMD-QSPEC) message MUST be sent to the QNE Ingress node, i.e., the previous stateful hop. The (refresh) intra-domain RESPONSE (RMD-QSPEC) message MUST be explicitly routed to the QNE Ingress node, i.e., the previous stateful hop, using the procedures described in Section 4.5.
必须将（刷新）域内响应（RMD-QSPEC）消息发送到QNE入口节点，即前一个有状态跃点。（刷新）域内响应（RMD-QSPEC）消息必须使用第4.5节中描述的过程显式路由到QNE入口节点，即前一个有状态跃点。
* the values of the <RII>, <RSN>, and <INFO-SPEC> objects are set by the standard QoS-NSLP protocol functions, see [RFC5974].
* <RII>、<RSN>和<INFO-SPEC>对象的值由标准QoS NSLP协议函数设置，请参见[RFC5974]。
* the value of the <PDR Control Type> parameter of the PDR container MUST be set "24" (i.e., PDR_Refresh_Report). In case of successful reservation, the <INFO-SPEC> object SHOULD have the following values:
* PDR容器的<PDR Control Type>参数的值必须设置为“24”（即PDR_Refresh_Report）。如果成功预订，<INFO-SPEC>对象应具有以下值：
Error severity Class: Success Error code value: Reservation successful
错误严重性类别：成功错误代码值：保留成功
* In the case of unsuccessful reservation the <INFO-SPEC> object SHOULD have the following values:
* 如果预订失败，<INFO-SPEC>对象应具有以下值：
Error severity class: Transient Failure Error code value: Reservation failure
错误严重性等级：瞬时故障错误代码值：保留故障
The RMD-QSPEC that was carried by the intra-domain RESERVE belonging to the same session as this intra-domain RESPONSE is included in the intra-domain RESPONSE message. The parameters included in the QSPEC <QoS Reserved> object are copied from the original <QoS Desired> values. If the reservation is unsuccessful, then the <E> flag associated with the QSPEC <QoS Reserved> object and the <E> flag associated with the local RMD-QSPEC <TMOD-1> parameter are set. Furthermore, the <M> and <S> PDR container bits are set to "1".
域内响应消息中包括域内保留所携带的RMD-QSPEC，该保留属于与该域内响应相同的会话。QSPEC<QoS Reserved>对象中包含的参数是从原始<QoS Desired>值复制而来的。如果保留不成功，则设置与QSPEC<QoS Reserved>对象关联的<E>标志和与本地RMD-QSPEC<TMOD-1>参数关联的<E>标志。此外，<M>和<S>PDR容器位被设置为“1”。
In the case when the QNE Edges maintain QoS-NSLP-aggregated operational and reservation states and the aggregated reservation has to be modified (see Section 4.3.1) the following procedure is applied:
如果QNE边缘保持QoS NSLP聚合操作和保留状态，并且必须修改聚合保留（参见第4.3.1节），则应用以下程序：
* When the modification request requires an increase of the reserved resources, the QNE Ingress node MUST include the corresponding value into the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired>, which is sent together with a "PHR_Resource_Request" control information. If a QNE Edge or QNE Interior node is not able to reserve the number of requested resources, the "PHR_Resource_Request" that is associated with the local RMD-QSPEC <TMOD-1> parameter MUST be <M> marked,
* 当修改请求需要增加保留资源时，QNE入口节点必须将相应值包括在RMD-QOSM<QoS Desired>的本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>值中，该参数与“PHR\u Resource\u request”控制信息一起发送。如果QNE边缘或QNE内部节点无法保留请求的资源数量，则必须标记与本地RMD-QSPEC<TMOD-1>参数关联的“PHR_资源_请求”，
i.e., the <M> bit is set to the value of "1". In this situation, the RMD-specific operation for unsuccessful reservation will be applied (see Section 4.6.1.2).
i、 例如，<M>位设置为“1”的值。在这种情况下，将对未成功预订应用RMD特定操作（见第4.6.1.2节）。
* When the modification request requires a decrease of the reserved resources, the QNE Ingress node MUST include this value into the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired>. Subsequently, an RMD release procedure SHOULD be accomplished (see Section 4.6.1.5). Note that if the complete bandwidth associated with the aggregated reservation maintained at the QNE Ingress does not have to be released, then the <TEAR> flag MUST be set to OFF. This is because the NSLP operational states associated with the aggregated reservation states at the Edge QNEs MUST NOT be turned off. However, if the complete bandwidth associated with the aggregated reservation maintained at the QNE Ingress has to be released, then the <TEAR> flag MUST be set to ON.
* 当修改请求需要减少保留资源时，QNE入口节点必须将该值包括在RMD-QOSM<QoS Desired>的本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>值中。随后，应完成RMD发布程序（见第4.6.1.5节）。注意，如果不必释放与QNE入口处维护的聚合保留相关联的完整带宽，则必须将<TEAR>标志设置为OFF。这是因为不能关闭与边缘QNE处的聚合保留状态关联的NSLP操作状态。但是，如果必须释放与QNE入口处维护的聚合保留相关联的完整带宽，则必须将<TEAR>标志设置为ON。
It is important to emphasize that this RMD modification scheme only applies to the following two RMD-QOSM schemes:
需要强调的是，此RMD修改方案仅适用于以下两个RMD-QOSM方案：
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
* 结合“通过RMD-QOSM刷新进行严重拥塞处理”程序的“基于每个总RMD预订”；
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure.
* “基于每聚合RMD保留”与“按比例数据包标记的严重拥塞处理”程序相结合。
This procedure is applied to all RMD mechanisms that maintain reservation states. If a refresh RESERVE message does not arrive at a QNE Interior node within the refresh timeout period, then the bandwidth requested by this refresh RESERVE message is not updated. This means that the reserved bandwidth associated with the reduced state is decreased in the next refresh period by the amount of the corresponding bandwidth that has not been refreshed, see Section 4.3.3.
此过程适用于所有维护保留状态的RMD机制。如果刷新保留消息在刷新超时时间内未到达QNE内部节点，则不会更新此刷新保留消息请求的带宽。这意味着与减少状态相关的保留带宽在下一个刷新周期中减少了未刷新的相应带宽量，参见第4.3.3节。
This soft state behavior provides certain robustness for the system ensuring that unused resources are not reserved for a long time. Resources can be removed by an explicit release at any time. However, in the situation that an end-to-end (tear) RESERVE is retransmitted (see Section 5.2.4 in [RFC5974]), then this message MUST NOT initiate an intra-domain (tear) RESERVE message. This is because the amount of bandwidth within the RMD domain associated with
这种软状态行为为系统提供了一定的健壮性，确保未使用的资源不会被长时间保留。资源可以在任何时候通过显式发布删除。但是，在端到端（tear）保留被重新传输的情况下（参见[RFC5974]中的第5.2.4节），则该消息不得启动域内（tear）保留消息。这是因为RMD域中与
the (tear) end-to-end RESERVE has already been released, and therefore, this amount of bandwidth within the RMD domain MUST NOT once again be released.
（撕裂）端到端预留已经释放，因此，RMD域内的这一带宽量不能再次释放。
When the RMD-RMF of a QNE Edge or QNE Interior node processes a "PHR_Release_Request" PHR container, it MUST identify the <PHB Class> parameter and estimate the time period that elapsed after the previous refresh, see also Section 3 of [CsTa05].
当QNE边缘或QNE内部节点的RMD-RMF处理“PHR_Release_Request”PHR容器时，它必须识别<PHB Class>参数并估计上次刷新后经过的时间段，另请参见[CsTa05]的第3节。
This MAY be done by indicating the time lag, say "T_Lag", between the last sent "PHR_Refresh_Update" and the "PHR_Release_Request" control information container by the QNE Ingress node, see [RMD1] and [CsTa05] for more details. The value of "T_Lag" is first normalized to the length of the refresh period, say "T_period". The ratio between the "T_Lag" and the length of the refresh period, "T_period", is calculated. This ratio is then introduced into the <Time Lag> field of the "PHR_Release_Request". When the above mentioned procedure of indicating the "T_Lag" is used and when a node (QNE Egress or QNE Interior) receives the "PHR_Release_Request" PHR container, it MUST store the arrival time. Then, it MUST calculate the time difference, "T_diff", between the arrival time and the start of the current refresh period, "T_period". Furthermore, this node MUST derive the value of the "T_Lag", from the <Time Lag> parameter. "T_Lag" can be found by multiplying the value included in the <Time Lag> parameter with the length of the refresh period, "T_period". If the derived time lag, "T_Lag", is smaller than the calculated time difference, "T_diff", then this node MUST decrease the PHB reservation state with the number of resource units indicated in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired> that has been sent together with the "PHR_Release_Request" "PHR Container", but not below zero.
这可以通过指示QNE入口节点最后发送的“PHR_刷新_更新”和“PHR_释放_请求”控制信息容器之间的时间延迟（如“T_滞后”）来实现，有关更多详细信息，请参阅[RMD1]和[CsTa05]。“T_Lag”的值首先被标准化为刷新周期的长度，例如“T_周期”。计算“T_滞后”与刷新周期长度“T_周期”之间的比率。然后将该比率引入“PHR\U释放请求”的<Time Lag>字段中。当使用上述指示“T_滞后”的程序时，当节点（QNE出口或QNE内部）接收到“PHR_释放请求”PHR容器时，它必须存储到达时间。然后，它必须计算到达时间和当前刷新周期开始时间之间的时间差“T_diff”。此外，该节点必须从<Time Lag>参数中导出“T_Lag”的值。“T_Lag”可以通过将<Time Lag>参数中包含的值乘以刷新周期的长度“T_period”来找到。如果导出的时间延迟“T_lag”小于计算的时间差“T_diff”，则该节点必须减少PHB保留状态，并在与请求一起发送的RMD-QOSM<QoS Desired>的本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段中指示资源单元的数量“PHR\U释放请求”“PHR容器”，但不低于零。
An RMD-specific release procedure can be triggered by an end-to-end RESERVE with a <TEAR> flag set to ON (see Section 4.6.1.5.1), or it can be triggered by either an intra-domain RESPONSE, an end-to-end RESPONSE, or an end-to-end NOTIFY message that includes a marked (i.e., PDR <M> and/or PDR <S> parameters are set to ON) "PDR_Reservation_Report" or "PDR_Congestion_Report" and/or an <INFO-SPEC> object.
RMD特定的释放程序可以通过将<TEAR>标志设置为ON（见第4.6.1.5.1节）的端到端保留触发，也可以通过域内响应、端到端响应或端到端通知消息触发，其中包括标记的（即，PDR<M>和/或PDR<S>参数设置为ON）“PDR_Reservation_Report”或“PDR报告”和/或<INFO-SPEC>对象。
This RMD-explicit release procedure can be triggered by a tear (<TEAR> flag set to ON) end-to-end RESERVE message. When a tear (<TEAR> flag set ON) end-to-end RESERVE message arrives to the QNE Ingress, the QNE Ingress node SHOULD process the message in a standard QoS-NSLP way (see [RFC5974]). In addition to this, the RMD RMF is notified, as specified in [RFC5974].
此RMD显式释放过程可由端到端保留消息触发。当tear（<tear>标志设置为ON）端到端保留消息到达QNE入口时，QNE入口节点应以标准QoS NSLP方式处理该消息（请参阅[RFC5974]）。除此之外，根据[RFC5974]中的规定，还将通知RMD RMF。
Like the scenario described in Section 4.6.1.1., a bypassing procedure has to be initiated by the QNE Ingress node. The bypassing procedure is performed according to the description given in Section 4.4. At the QNE Ingress, the end-to-end RESERVE message is marked, i.e., modifying the QoS-NSLP default NSLPID value to another NSLPID predefined value that will be used by the GIST message that carries the end-to-end RESERVE message to bypass the QNE Interior nodes.
与第4.6.1.1节中描述的场景类似，必须由QNE入口节点启动旁路程序。根据第4.4节中给出的说明执行旁路程序。在QNE入口，标记端到端保留消息，即，将QoS NSLP默认NSLPID值修改为另一个NSLPID预定义值，该值将由携带端到端保留消息的GIST消息用于绕过QNE内部节点。
Before generating an intra-domain tear RESERVE, the RMD-QOSM has to release the requested RMD-QOSM bandwidth from the RMD traffic class state maintained at the QNE Ingress.
在生成域内撕裂保留之前，RMD-QOSM必须从QNE入口处维护的RMD业务类别状态释放请求的RMD-QOSM带宽。
This can be achieved by identifying the traffic class (PHB) and then subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state. The <Time Lag> is used as explained in the introductory part of Section 4.6.1.5.
这可以通过识别流量类别（PHB），然后从RMD流量类别状态中存储的资源总保留量中减去本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段中包含的RMD流量类别请求资源量来实现。如第4.6.1.5节介绍部分所述，使用<Time Lag>。
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | |
--->| | | RESERVE |
|------------------------------------------------------------>|
|RESERVE(RMD-QSPEC:Tear=1) | |
|------------------->| | |
| |RESERVE(RMD-QSPEC:Tear=1) |
| |------------------->| |
| | RESERVE(RMD-QSPEC:Tear=1)
| | |------------------->|
| | | RESERVE
| | | |-->
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
RESERVE | | |
--->| | | RESERVE |
|------------------------------------------------------------>|
|RESERVE(RMD-QSPEC:Tear=1) | |
|------------------->| | |
| |RESERVE(RMD-QSPEC:Tear=1) |
| |------------------->| |
| | RESERVE(RMD-QSPEC:Tear=1)
| | |------------------->|
| | | RESERVE
| | | |-->
Figure 11: Explicit release triggered by RESERVE used by the RMD-QOSM
图11:RMD-QOSM使用的保留触发的显式释放
After that, the REQUIRED bandwidth is released from the RMD-QOSM traffic class state at the QNE Ingress, an intra-domain RESERVE (RMD-QOSM) message has to be generated. The intra-domain RESERVE (RMD-QSPEC) message MUST include an <RMD QoS object combination> field and a PHR container, (i.e., "PHR_Release_Request") and it MAY include a PDR container, (i.e., PDR_Release_Request). An example of this operation can be seen in Figure 11.
在此之后，所需带宽在QNE入口从RMD-QOSM流量等级状态释放，必须生成域内保留（RMD-QOSM）消息。域内保留（RMD-QSPEC）消息必须包括<RMD QoS对象组合>字段和PHR容器（即“PHR_释放请求”），并且它可能包括PDR容器（即PDR_释放请求）。此操作的示例如图11所示。
Most of the non-default values of the objects contained in the tear intra-domain RESERVE message are set by the QNE Ingress node in the same way as described in Section 4.6.1.1. The following objects are set differently (see the QoS-NSLP-RMF API described in [RFC5974]):
QNE入口节点以第4.6.1.1节所述的相同方式设置域内保留消息中包含的大多数对象的非默认值。以下对象的设置不同（请参阅[RFC5974]中描述的QoS NSLP RMF API）：
* The <RII> object MUST NOT be included in this message. This is because the QNE Ingress node does not need to receive a response from the QNE Egress node;
* 此消息中不得包含<RII>对象。这是因为QNE入口节点不需要接收来自QNE出口节点的响应；
* if the release procedure is not applied for the RMD modification of aggregated reservation procedure (see Section 4.6.1.4), then the <TEAR> flag MUST be set to ON;
* 如果发布程序不适用于汇总保留程序的RMD修改（见第4.6.1.4节），则必须将<TEAR>标志设置为ON；
* the PHR resource units MUST be included into the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired>;
* PHR资源单元必须包含在RMD-QOSM<QoS Desired>的本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>值中；
* the value of the <Admitted Hops> parameter MUST be set to "1";
* <Allocated Hops>参数的值必须设置为“1”；
* the value of the <Time Lag> parameter of the PHR container is calculated by the RMD-QOSM functionality (see Section 4.6.1.5) the value of the <Control Type> parameter of the PHR container is set to "18" (i.e., PHR_Release_Request).
* PHR容器的<Time Lag>参数值由RMD-QOSM功能计算（见第4.6.1.5节）。PHR容器的<Control Type>参数值设置为“18”（即PHR\u Release\u Request）。
Any QNE Interior node that receives the combination of the RMD-QOSM <QoS Desired> object and the "PHR_Release_Request" control information container MUST identify the traffic class (PHB) and release the requested resources included in the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter. This can be achieved by subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state. The value of the <Time Lag> parameter of the "PHR_Release_Request" container is used during the release procedure as explained in the introductory part of Section 4.6.1.5.
接收RMD-QOSM<QoS Desired>对象和“PHR_Release_Request”控制信息容器组合的任何QNE内部节点必须识别业务类别（PHB），并释放本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>值中包含的请求资源。这可以通过将本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段中包含的RMD traffic class请求的资源量从RMD traffic class状态中存储的总保留资源量中减去来实现。“PHR_Release_Request”容器的<Time Lag>参数值在发布过程中使用，如第4.6.1.5节介绍部分所述。
The intra-domain tear RESERVE (RMD-QSPEC) message is received and processed by the QNE Egress node. The RMD-QOSM <QoS Desired> and the "PHR RMD-QOSM control" container (and if available the "PDR Container") are read and processed by the RMD QoS node.
域内撕裂保留（RMD-QSPEC）消息由QNE出口节点接收和处理。RMD QoS节点读取并处理RMD-QOSM<QoS Desired>和“PHR RMD-QOSM控制”容器（以及如果可用的“PDR容器”）。
The value of the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired> and the value of the <Time Lag> field of the PHR container MUST be used by the RMD release procedure.
RMD释放程序必须使用RMD-QOSM<QoS Desired>的本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段值和PHR容器的<Time Lag>字段值。
This can be achieved by subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field value of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state.
这可以通过从RMD通信类状态中存储的资源总保留量中减去本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段值中包含的RMD通信类请求资源量来实现。
The end-to-end RESERVE message is forwarded by the next hop (i.e., the QNE Egress) only if the intra-domain tear RESERVE (RMD-QSPEC) message arrives at the QNE Egress node. Furthermore, the QNE Egress MUST stop the marking process that was used to bypass the QNE Interior nodes by reassigning the QoS-NSLP default NSLPID value to the end-to-end RESERVE message (see Section 4.4).
仅当域内撕裂保留（RMD-QSPEC）消息到达QNE出口节点时，端到端保留消息才由下一跳（即，QNE出口）转发。此外，QNE出口必须通过将QoS NSLP default NSLPID值重新分配给端到端保留消息来停止用于绕过QNE内部节点的标记过程（参见第4.4节）。
Note that when the QNE Edges maintain aggregated QoS-NSLP reservation states, the RMD-QOSM functionality MAY start an RMD modification procedure (see Section 4.6.1.4) that uses the explicit release procedure, described above in this subsection. Note that if the complete bandwidth associated with the aggregated reservation maintained at the QNE Ingress has to be released, then the <TEAR> flag MUST be set to ON. Otherwise, the <TEAR> flag MUST be set to OFF, see Section 4.6.1.4.
请注意，当QNE边缘保持聚合QoS NSLP保留状态时，RMD-QOSM功能可启动RMD修改程序（见第4.6.1.4节），该程序使用本小节上文所述的显式发布程序。请注意，如果必须释放与QNE入口处维护的聚合保留相关联的完整带宽，则必须将<TEAR>标志设置为ON。否则，<TEAR>标志必须设置为OFF，见第4.6.1.4节。
This RMD explicit release procedure can be triggered by either an intra-domain RESPONSE message with a PDR container carrying among others the <M> and <S> parameters with values <M>=1 and <S>=0 (see Section 4.6.1.2), an intra-domain (refresh) RESPONSE message carrying a PDR container with <M>=1 and <S>=1 (see Section 4.6.1.6.1), or an end-to-end NOTIFY message (see Section 4.6.1.6) with an <INFO-SPEC> object with the following values:
RMD显式释放程序可由域内响应消息触发，其中PDR容器携带值<M>=1和<S>=0的<M>和<S>参数（参见第4.6.1.2节），域内（刷新）响应消息携带值<M>=1和<S>=1的PDR容器（参见第4.6.1.6.1节），或带有<INFO-SPEC>对象且具有以下值的端到端通知消息（见第4.6.1.6节）：
Error severity class: Informational Error code value: Congestion situation
错误严重性类别：信息性错误代码值：拥塞情况
When the aggregated intra-domain QoS-NSLP operational states are used, an end-to-end NOTIFY message used to trigger an RMD release procedure MAY contain a PDR container that carries an <M> and an <S> with values <M>=1 and <S>=1, and a bandwidth value in the <PDR Bandwidth> parameter included in a "PDR_Refresh_Report" or "PDR_Congestion_Report" container.
当使用聚合的域内QoS NSLP操作状态时，用于触发RMD释放过程的端到端通知消息可以包含PDR容器，该PDR容器携带值为<M>=1和<S>=1的<M>和<S>，以及包含在“PDR\u刷新报告”或“PDR\u拥塞报告”中的<PDR bandwidth>参数中的带宽值容器
Note that in all explicit release procedures, before generating an intra-domain tear RESERVE, the RMD-QOSM has to release the requested RMD-QOSM bandwidth from the RMD traffic class state maintained at the QNE Ingress. This can be achieved by identifying the traffic class (PHB) and then subtracting the amount of RMD traffic class requested
注意，在所有显式释放过程中，在生成域内撕裂保留之前，RMD-QOSM必须从QNE入口处维护的RMD业务类别状态释放请求的RMD-QOSM带宽。这可以通过识别流量等级（PHB），然后减去请求的RMD流量等级来实现
resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state.
资源，包括在本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段中，来自RMD traffic class状态中存储的资源总保留量。
Figure 12 shows the situation that the intra-domain tear RESERVE is generated after being triggered by either an intra-domain (refresh) RESPONSE message that carries a PDR container with <M>=1 and <S>=1 or by an end-to-end NOTIFY message that does not carry a PDR container, but an <INFO-SPEC> object. The error code values carried by this NOTIFY message are:
图12显示了一种情况，即域内催泪储备是在由域内（刷新）响应消息触发后生成的，该响应消息包含<M>=1和<S>=1的PDR容器，或者由端到端通知消息触发的，该消息不包含PDR容器，而是<INFO-SPEC>对象。此通知消息携带的错误代码值为：
Error severity class: Informational Error code value: Congestion situation
错误严重性类别：信息性错误代码值：拥塞情况
Most of the non-default values of the objects contained in the tear intra-domain RESERVE(RMD-QSPEC) message are set by the QNE Ingress node in the same way as described in Section 4.6.1.1.
包含在域内保留（RMD-QSPEC）消息中的对象的大多数非默认值由QNE入口节点以与第4.6.1.1节所述相同的方式设置。
The following objects MUST be used and/or set differently (see the QoS-NSLP-RMF described in [RFC5974]):
必须以不同方式使用和/或设置以下对象（请参阅[RFC5974]中描述的QoS NSLP RMF）：
* the value of the <M> parameter of the PHR container MUST be set to "1".
* PHR容器的<M>参数值必须设置为“1”。
* the value of the <S> parameter of the "PHR container" MUST be set to "1".
* “PHR容器”的<S>参数值必须设置为“1”。
* the RESERVE message MAY include a PDR container. Note that this is needed if a bidirectional scenario is used; see Section 4.6.2.
* 保留消息可以包括PDR容器。注意，如果使用双向场景，则需要这样做；见第4.6.2节。
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| NOTIFY | | |
|<-------------------------------------------------------|
|RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) | |
| ---------------->|RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) |
| | | |
| |----------------->| |
| | RESERVE(RMD-QSPEC:Tear=1,M=1,S=1)
| | |----------------->|
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| NOTIFY | | |
|<-------------------------------------------------------|
|RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) | |
| ---------------->|RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) |
| | | |
| |----------------->| |
| | RESERVE(RMD-QSPEC:Tear=1,M=1,S=1)
| | |----------------->|
Figure 12: Basic operation during RMD-explicit release procedure triggered by NOTIFY used by the RMD-QOSM
图12:RMD-QOSM使用的NOTIFY触发的RMD显式发布过程期间的基本操作
Note that if the values of the <M> and <S> parameters included in the PHR container carried by a intra-domain tear RESERVE(RMD-QOSM) are set as ((<M>=0 and <S>=1) or (<M>=0 and <S>=0) or (<M>=1 and <S>=1)),
注意，如果域内撕裂储备（RMD-QOSM）携带的PHR容器中包括的<M>和<S>参数的值被设置为（（<M>=0和<S>=1）或（<M>=0和<S>=0）或（<M>=1和<S>=1）），
then the <Max Admitted Hops> value SHOULD NOT be compared to the <Admitted Hops> value and the value of the <K> field MUST NOT be set. Any QNE Edge or QNE Interior node that receives the intra-domain tear RESERVE MUST check the <K> field included in the PHR container. If the <K> field is "0", then the traffic class state (PHB) has to be identified, using the <PHB Class> parameter, and the requested resources included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter have to be released.
然后，不应将<Max accounted Hops>值与<accounted Hops>值进行比较，<K>字段的值不得设置。任何接收域内撕裂保留的QNE边缘或QNE内部节点必须检查PHR容器中包含的<K>字段。如果<K>字段为“0”，则必须使用<PHB class>参数识别流量等级状态（PHB），并且必须释放本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段中包含的请求资源。
This can be achieved by subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources stored in the RMD traffic class state. The value of the <Time Lag> parameter of the PHR field is used during the release procedure, as explained in the introductory part of Section 4.6.1.5. Afterwards, the QNE Egress node MUST terminate the tear intra-domain RESERVE(RMD-QSPEC) message.
这可以通过将本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段中包含的RMD traffic class请求的资源量从RMD traffic class状态中存储的总保留资源量中减去来实现。如第4.6.1.5节介绍部分所述，在释放过程中使用PHR字段的<Time Lag>参数值。之后，QNE出口节点必须终止域内保留（RMD-QSPEC）消息。
The RMD-specific release procedure that is triggered by an intra-domain RESPONSE message with an <M>=1 and <S>=0 PDR container (see Section 4.6.1.2) generates an intra-domain tear RESERVE message that uses the combination of the <Max Admitted Hops> and <Admitted_Hops> fields to calculate and specify when the <K> value carried by the "PHR Container" can be set. When the <K> field is set, then the "PHR Container" and the RMD-QOSM <QoS Desired> carried by an intra-domain tear RESERVE MUST NOT be processed.
RMD特定释放程序由具有<M>=1和<S>=0 PDR容器（见第4.6.1.2节）的域内响应消息触发，生成域内撕裂保留消息，该消息使用<Max acempted Hops>和<acempted_Hops>字段的组合来计算和指定“PHR容器”携带的<K>值的时间可以设置。当设置<K>字段时，则不能处理域内撕裂保留所携带的“PHR容器”和RMD-QOSM<QoS Desired>。
The RMD-specific explicit release procedure that uses the combination of <Max Admitted Hops>, <Admitted_Hops> and <K> fields to release resources/bandwidth in only a part of the RMD domain, is denoted as RMD partial release procedure.
特定于RMD的显式释放过程使用<Max acempted Hops>、<acempted_Hops>和<K>字段的组合来仅在RMD域的一部分中释放资源/带宽，被表示为RMD部分释放过程。
This explicit release procedure can be used, for example, during unsuccessful reservation (see Section 4.6.1.2). When the RMD-QOSM/QoS-NSLP signaling model functionality of a QNE Ingress node receives a PDR container with values <M>=1 and <S>=0, of type "PDR_Reservation_Report", it MUST start an RMD partial release procedure.
例如，在未成功预订期间，可使用此明确的放行程序（见第4.6.1.2节）。当QNE入口节点的RMD-QOSM/QoS NSLP信令模型功能接收到“PDR_Reservation_Report”类型的值为<M>=1和<S>=0的PDR容器时，它必须启动RMD部分释放过程。
In this situation, after the REQUIRED bandwidth is released from the RMD-QOSM traffic class state at the QNE Ingress, an intra-domain RESERVE (RMD-QOSM) message has to be generated. An example of this operation can be seen in Figure 13.
在这种情况下，在QNE入口处从RMD-QOSM业务类别状态释放所需带宽之后，必须生成域内保留（RMD-QOSM）消息。此操作的示例如图13所示。
Most of the non-default values of the objects contained in the tear intra-domain RESERVE(RMD-QSPEC) message are set by the QNE Ingress node in the same way as described in Section 4.6.1.1.
包含在域内保留（RMD-QSPEC）消息中的对象的大多数非默认值由QNE入口节点以与第4.6.1.1节所述相同的方式设置。
The following objects MUST be used and/or set differently:
必须以不同方式使用和/或设置以下对象：
* the value of the <M> parameter of the PHR container MUST be set to "1".
* PHR容器的<M>参数值必须设置为“1”。
* the RESERVE message MAY include a PDR container.
* 保留消息可以包括PDR容器。
* the value of the <Max Admitted Hops> carried by the "PHR Container" MUST be set equal to the <Max Admitted Hops> value carried by the "PDR Container" (with <M>=1 and <S>=0) carried by the received intra-domain RESPONSE message that triggers the release procedure.
* “PHR容器”携带的<Max acempted Hops>值必须设置为等于触发释放过程的接收域内响应消息携带的“PDR容器”（具有<M>=1和<S>=0）携带的<Max acempted Hops>值。
Any QNE Edge or QNE Interior node that receives the intra-domain tear RESERVE has to check the value of the <K> field in the "PHR Container" before releasing the requested resources.
接收域内撕裂保留的任何QNE边缘或QNE内部节点必须在释放请求的资源之前检查“PHR Container”中<K>字段的值。
If the value of the <K> field is "1", then all the QNEs located downstream, including the QNE Egress, MUST NOT process the carried "PHR Container" and the RMD-QOSM <QoS Desired> object by the intra-domain tearing RESERVE.
如果<K>字段的值为“1”，则位于下游的所有QNE（包括QNE出口）不得通过域内撕裂保留处理所携带的“PHR容器”和RMD-QOSM<QoS Desired>对象。
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
Node that marked
PHR_Resource_Request
<PHR> object
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| | | |
| RESPONSE (RMD-QSPEC: M=1) | |
|<------------------------------------------------------------|
RESERVE(RMD-QSPEC: Tear=1, M=1, <Admit Hops>=<Max Admitted Hops>, K=0)
|------------------->| | |
| |RESERVE(RMD-QSPEC: Tear=1, M=1, K=1) |
| |------------------>| |
| | RESERVE(RMD-QSPEC: Tear=1, M=1, K=1)|
| | |------------------->|
| | | |
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
Node that marked
PHR_Resource_Request
<PHR> object
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| | | |
| RESPONSE (RMD-QSPEC: M=1) | |
|<------------------------------------------------------------|
RESERVE(RMD-QSPEC: Tear=1, M=1, <Admit Hops>=<Max Admitted Hops>, K=0)
|------------------->| | |
| |RESERVE(RMD-QSPEC: Tear=1, M=1, K=1) |
| |------------------>| |
| | RESERVE(RMD-QSPEC: Tear=1, M=1, K=1)|
| | |------------------->|
| | | |
Figure 13: Basic operation during RMD explicit release procedure triggered by RESPONSE used by the RMD-QOSM
图13:RMD-QOSM使用的响应触发的RMD显式发布过程期间的基本操作
If the <K> field value is "0", any QNE Edge or QNE Interior node that receives the intra-domain tear RESERVE can release the resources by subtracting the amount of RMD traffic class requested resources, included in the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter, from the total reserved amount of resources
如果<K>字段值为“0”，则接收域内撕裂保留的任何QNE边缘或QNE内部节点都可以通过从资源的总保留量中减去RMD流量类请求的资源量来释放资源，该资源量包括在本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段中
stored in the RMD traffic class state. The value of the <Time Lag> parameter of the PHR field is used during the release procedure as explained in the introductory part of Section 4.6.1.5.
存储在RMD流量类状态中。如第4.6.1.5节介绍部分所述，在释放过程中使用PHR字段的<Time Lag>参数值。
Furthermore, the QNE MUST perform the following procedures.
此外，QNE必须执行以下程序。
If the values of the <M> and <S> parameters included in the "PHR_Release_Request" PHR container are (<M=1> and <S>=0) then the <Max Admitted Hops> value MUST be compared with the calculated <Admitted Hops> value. Note that each time that the intra-domain tear RESERVE is processed and before being forwarded by a QNE, the <Admitted Hops> value included in the PHR container is increased by one.
如果“PHR_释放请求”PHR容器中包含的<M>和<S>参数值为（<M=1>和<S>=0），则必须将<Max acempted Hops>值与计算的<acempted Hops>值进行比较。注意，每次处理域内撕裂保留并且在被QNE转发之前，PHR容器中包括的<acempted Hops>值增加1。
When these two values are equal, the intra-domain RESERVE(RMD-QSPEC) that is forwarded further towards the QNE Egress MUST set the <K> value of the carried "PHR Container" to "1".
当这两个值相等时，进一步向QNE出口转发的域内保留（RMD-QSPEC）必须将所携带的“PHR容器”的<K>值设置为“1”。
The reason for doing this is that the QNE node that is currently processing this message was the last QNE node that successfully processed the RMD-QOSM <QoS Desired>) and PHR container of its associated initial reservation request (i.e., initial intra-domain RESERVE(RMD-QSPEC) message). Its next QNE downstream node was unable to successfully process the initial reservation request; therefore, this QNE node marked the <M> and <Hop_U> parameters of the "PHR_Resource_Request".
这样做的原因是，当前正在处理此消息的QNE节点是成功处理RMD-QOSM<QoS Desired>）及其关联初始保留请求（即初始域内保留（RMD-QSPEC）消息）的PHR容器的最后一个QNE节点。其下一个QNE下游节点无法成功处理初始预约请求；因此，该QNE节点标记了“PHR_资源_请求”的<M>和<Hop_>参数。
Finally, note that the QNE Egress node MUST terminate the intra-domain RESERVE(RMD-QSPEC) message.
最后，请注意，QNE出口节点必须终止域内保留（RMD-QSPEC）消息。
Moreover, note that the above described RMD partial release procedure applies to the situation that the QNE Edges maintain a per-flow QoS-NSLP reservation state.
此外，注意，上述RMD部分释放过程适用于QNE边缘保持每流QoS NSLP保留状态的情况。
When the QNE Edges maintain aggregated intra-domain QoS-NSLP operational states and a severe congestion occurs, then the QNE Ingress MAY receive an end-to-end NOTIFY message (see Section 4.6.1.6) with a PDR container that carries the <M>=0 and <S>=1 fields and a bandwidth value in the <PDR Bandwidth> parameter included in a "PDR_Congestion_Report" container. Furthermore, the same end-to-end NOTIFY message carries an <INFO-SPEC> object with the following values:
当QNE边缘保持聚合的域内QoS NSLP操作状态且发生严重拥塞时，QNE入口可能会接收端到端通知消息（参见第4.6.1.6节），其中PDR容器包含<M>=0和<S>=1字段以及包含在“PDR\U拥塞报告”中的<PDR带宽>参数中的带宽值容器此外，相同的端到端通知消息携带具有以下值的<INFO-SPEC>对象：
Error severity class: Informational Error code value: Congestion situation
错误严重性类别：信息性错误代码值：拥塞情况
The end-to-end session associated with this NOTIFY message maintains the BOUND-SESSION-ID of the bound aggregated session; see Section 4.3.1. The RMD-QOSM at the QNE Ingress MUST start an RMD modification procedures (see Section 4.6.1.4) that uses the RMD explicit release procedure, described above in this section. In particular, the RMD explicit release procedure releases the bandwidth value included in the <PDR Bandwidth> parameter, within the "PDR_Congestion_Report" container, from the reserved bandwidth associated with the aggregated intra-domain QoS-NSLP operational state.
与此NOTIFY消息关联的端到端会话维护绑定聚合会话的绑定会话ID；见第4.3.1节。QNE入口的RMD-QOSM必须启动RMD修改程序（见第4.6.1.4节），该程序使用本节上文所述的RMD明确发布程序。具体而言，RMD显式释放过程从与聚合的域内QoS NSLP操作状态相关联的保留带宽中释放“PDR_拥塞_报告”容器中的<PDR bandwidth>参数中包括的带宽值。
This section describes the operation of the RMD-QOSM when a severe congestion occurs within the Diffserv domain.
本节描述在区分服务域内发生严重拥塞时RMD-QOSM的操作。
When a failure in a communication path, e.g., a router or a link failure occurs, the routing algorithms will adapt to failures by changing the routing decisions to reflect changes in the topology and traffic volume. As a result, the rerouted traffic will follow a new path, which MAY result in overloaded nodes as they need to support more traffic. This MAY cause severe congestion in the communication path. In this situation, the available resources, are not enough to meet the REQUIRED QoS for all the flows along the new path.
当通信路径中发生故障（例如路由器或链路故障）时，路由算法将通过改变路由决策来适应故障，以反映拓扑和通信量的变化。因此，重新路由的流量将遵循新路径，这可能导致节点过载，因为它们需要支持更多流量。这可能会导致通信路径严重拥塞。在这种情况下，可用资源不足以满足沿新路径的所有流所需的QoS。
Therefore, one or more flows SHOULD be terminated, or forwarded in a lower priority queue.
因此，应终止一个或多个流，或在低优先级队列中转发。
Interior nodes notify Edge nodes by data marking or marking the refresh messages.
内部节点通过数据标记或标记刷新消息来通知边缘节点。
This procedure applies to all RMD scenarios that use an RMD refresh procedure. The QoS-NSLP and RMD are able to cope with congested situations using the refresh procedure; see Section 4.6.1.3.
此过程适用于使用RMD刷新过程的所有RMD场景。QoS NSLP和RMD能够使用刷新过程处理拥塞情况；见第4.6.1.3节。
If the refresh is not successful in an QNE Interior node, Edge nodes are notified by setting <S>=1 (<M>=1) marking the refresh messages and by setting the <O> field in the "PHR_Refresh_Update" container, carried by the intra-domain RESERVE message.
如果在QNE内部节点中刷新未成功，则通过设置标记刷新消息的<S>=1（<M>=1）并通过设置域内保留消息携带的“PHR\u refresh\u Update”容器中的<O>字段来通知边缘节点。
Note that the overload situation can be detected by using the example given in Appendix A.1. In this situation, when the given signaled_overload_rate parameter given in Appendix A.1 is higher than 0, the value of the <Overload> field is set to "1". The calculation
注意，可以使用附录A.1中给出的示例检测过载情况。在这种情况下，当附录A.1中给出的给定信号过载速率参数大于0时，<overload>字段的值设置为“1”。计算
of this is given in Appendix A.1 and denoted as the signaled_overload_rate parameter. The flows can be terminated by the RMD release procedure described in Section 4.6.1.5.
附录A.1中给出了这一点，并表示为信号过载率参数。可通过第4.6.1.5节所述的RMD发布程序终止流量。
The intra-domain RESPONSE message that is sent by the QNE Egress towards the QNE Ingress will contain a PDR container with a Parameter ID = 26, i.e., "PDR_Congestion_Report". The values of the <M>, <S>, and <O> fields of this container SHOULD be set equal to the values of the <M>, <S>, and <O> fields, respectively, carried by the "PHR_Refresh_Update" container. Part of the flows, corresponding to the <O>, are terminated, or forwarded in a lower priority queue.
QNE出口向QNE入口发送的域内响应消息将包含参数ID=26的PDR容器，即“PDR_拥塞_报告”。此容器的<M>、<S>和<O>字段的值应分别设置为等于“PHR\u Refresh\u Update”容器携带的<M>、<S>和<O>字段的值。与<O>相对应的部分流在较低优先级队列中终止或转发。
The flows can be terminated by the RMD release procedure described in Section 4.6.1.5.
可通过第4.6.1.5节所述的RMD发布程序终止流量。
Furthermore, note that the above functionalities also apply to the scenario in which the QNE Edge nodes maintain either per-flow QoS-NSLP reservation states or aggregated QoS-NSLP reservation states.
此外，请注意，上述功能还适用于QNE边缘节点维护每流QoS NSLP保留状态或聚合QoS NSLP保留状态的场景。
In general, relying on the soft state refresh mechanism solves the congestion within the time frame of the refresh period. If this mechanism is not fast enough, additional functions SHOULD be used, which are described in Section 4.6.1.6.2.
通常，依靠软状态刷新机制可以解决刷新周期时间范围内的拥塞问题。如果该机制不够快，应使用第4.6.1.6.2节所述的附加功能。
4.6.1.6.2. Severe Congestion Handling by Proportional Data Packet Marking
4.6.1.6.2. 按比例数据包标记的严重拥塞处理
This severe congestion handling method requires the following functionalities.
这种严重拥塞处理方法需要以下功能。
The detection and marking/re-marking functionality described in this section applies to NSIS-aware and NSIS-unaware nodes. This means however, that the "not NSIS-aware" nodes MUST be configured such that they can detect the congestion/severe congestion situations and re-mark packets in the same way the "NSIS-aware" nodes do.
本节中描述的检测和标记/重新标记功能适用于NSIS感知和NSIS不感知节点。然而，这意味着，必须配置“非NSIS感知”节点，以便它们能够检测拥塞/严重拥塞情况，并以与“NSIS感知”节点相同的方式重新标记数据包。
The Interior node detecting severe congestion re-marks data packets passing the node. For this re-marking, two additional DSCPs can be allocated for each traffic class. One DSCP MAY be used to indicate that the packet passed a congested node. This type of DSCP is denoted in this document as an "affected DSCP" and is used to indicate that a packet passed through a severe congested node.
检测到严重拥塞的内部节点重新标记通过该节点的数据包。对于此重新标记，可以为每个流量类别分配两个额外的DSCP。一个DSCP可用于指示分组通过拥塞节点。此类型的DSCP在本文档中表示为“受影响的DSCP”，用于指示数据包通过严重拥塞的节点。
The use of this DSCP type eliminates the possibility that, e.g., due to flow-based ECMP-enabled (Equal Cost Multiple Paths) routing, the Egress node either does not detect packets passed a severely
这种DSCP类型的使用消除了以下可能性：例如，由于基于流的ECMP启用（等成本多路径）路由，出口节点或者不检测通过数据包的数据包
congested node or erroneously detects packets that actually did not pass the severely congested node. Note that this type of DSCP MUST only be used if all the nodes within the RMD domain are configured to use it. Otherwise, this type of DSCP MUST NOT be applied. The other DSCP MUST be used to indicate the degree of congestion by marking the bytes proportionally to the degree of congestion. This type of DSCP is denoted in this document as "encoded DSCP".
拥塞节点或错误地检测实际上没有通过严重拥塞节点的数据包。请注意，只有当RMD域中的所有节点都配置为使用此类型的DSCP时，才必须使用此类型的DSCP。否则，不得应用此类DSCP。另一个DSCP必须通过按拥塞程度成比例标记字节来指示拥塞程度。这种类型的DSCP在本文件中表示为“编码DSCP”。
In this document, note that the terms "marked packets" or "marked bytes" refer to the "encoded DSCP". The terms "unmarked packets" or "unmarked bytes" represent the packets or the bytes belonging to these packets that their DSCP is either the "affected DSCP" or the original DSCP. Furthermore, in the algorithm described below, it is considered that the router MAY drop received packets. The counting/measuring of marked or unmarked bytes described in this section is accomplished within measurement periods. All nodes within an RMD domain use the same, fixed-measurement interval, say T seconds, which MUST be preconfigured.
在本文档中，请注意术语“标记的数据包”或“标记的字节”指的是“编码的DSCP”。术语“未标记数据包”或“未标记字节”表示数据包或属于这些数据包的字节，这些数据包的DSCP是“受影响的DSCP”或原始DSCP。此外，在下面描述的算法中，认为路由器可以丢弃接收到的分组。本节中描述的有标记或无标记字节的计数/测量在测量周期内完成。RMD域中的所有节点都使用相同的固定测量间隔，例如T秒，必须预先配置。
It is RECOMMENDED that the total number of additional (local and experimental) DSCPs needed for severe congestion handling within an RMD domain SHOULD be as low as possible, and it SHOULD NOT exceed the limit of 8. One possibility to reduce the number of used DSCPs is to use only the "encoded DSCP" and not to use "affected DSCP" marking. Another possible solution is, for example, to allocate one DSCP for severe congestion indication for each of the AF classes that can be supported by RMD-QOSM.
建议RMD域内严重拥塞处理所需的附加（本地和实验）DSCP总数应尽可能少，且不应超过8的限制。减少使用的DSCP数量的一种可能性是仅使用“编码的DSCP”，而不使用“受影响的DSCP”标记。另一个可能的解决方案是，例如，为RMD-QOSM支持的每个AF类分配一个DSCP用于严重拥塞指示。
An example of a re-marking procedure can be found in Appendix A.1.
附录a.1中给出了重新标记程序的示例。
When the QNE Edges maintain a per-flow intra-domain QoS-NSLP operational state (see Sections 4.3.2 and 4.3.3), then the following procedure is followed. The QNE Egress node applies a predefined policy to solve the severe congestion situation, by selecting a number of inter-domain (end-to-end) flows that SHOULD be terminated or forwarded in a lower priority queue.
当QNE边缘保持每流域内QoS NSLP操作状态时（参见第4.3.2节和第4.3.3节），则遵循以下程序。QNE出口节点通过选择应在低优先级队列中终止或转发的多个域间（端到端）流，应用预定义的策略来解决严重的拥塞情况。
When the RMD domain does not use the "affected DSCP" marking, the Egress MUST generate an Ingress/Egress pair aggregated state, for each Ingress and for each supported PHB. This is because the Edges MUST be able to detect in which Ingress/Egress pair a severe congestion occurs. This is because, otherwise, the QNE Egress will not have any information on which flows or groups of flows were affected by the severe congestion.
当RMD域不使用“受影响的DSCP”标记时，出口必须为每个入口和每个受支持的PHB生成入口/出口对聚合状态。这是因为边缘必须能够检测发生严重拥塞的入口/出口对。这是因为，否则，QNE出口将没有任何关于哪些流或流组受到严重拥塞影响的信息。
When the RMD domain supports the "affected DSCP" marking, the Egress is able to detect all flows that are affected by the severe congestion situation. Therefore, when the RMD domain supports the "affected DSCP" marking, the Egress MAY not generate and maintain the Ingress/Egress pair aggregated reservation states. Note that these aggregated reservation states MAY not be associated with aggregated intra-domain QoS-NSLP operational states.
当RMD域支持“受影响的DSCP”标记时，出口能够检测到受严重拥塞情况影响的所有流。因此，当RMD域支持“受影响的DSCP”标记时，出口可能不会生成和保持入口/出口对聚合保留状态。请注意，这些聚合保留状态可能与聚合的域内QoS NSLP操作状态不关联。
The Ingress/Egress pair aggregated reservation state can be derived by detecting which flows are using the same PHB and are sent by the same Ingress (via the per-flow end-to-end QoS-NSLP states).
可以通过检测哪些流使用相同的PHB并且由相同的入口发送（通过每流端到端QoS NSLP状态），来导出入口/出口对聚合保留状态。
Some flows, belonging to the same PHB traffic class might get other priority than other flows belonging to the same PHB traffic class. This difference in priority can be notified to the Egress and Ingress nodes by either the RESERVE message that carries the QSPEC associated with the end-to-end QoS Model, e.g.,, <Preemption Priority> and <Defending Priority> parameter or using a locally defined policy. The priority value is kept in the reservation states (see Section 4.3), which might be used during admission control and/or severe congestion handling procedures. The terminated flows are selected from the flows having the same PHB traffic class as the PHB of the marked (as "encoded DSCP") and "affected DSCP" (when applied in the complete RMD domain) packets and (when the Ingress/Egress pair aggregated states are available) that belong to the same Ingress/Egress pair aggregate.
与属于相同PHB流量类别的其他流相比，属于相同PHB流量类别的某些流可能获得其他优先级。可通过携带与端到端QoS模型相关联的QSPEC的保留消息（例如，<抢占优先级>和<防御优先级>参数）或使用本地定义的策略，向出口和入口节点通知该优先级差异。优先级值保持在保留状态（见第4.3节），这可能在准入控制和/或严重拥堵处理过程中使用。终止流从具有与标记的（作为“编码的DSCP”）和“受影响的DSCP”（当应用于完整RMD域时）分组的PHB相同PHB业务类别的流中选择，并且（当入口/出口对聚合状态可用时）属于同一入口/出口对聚合。
For flows associated with the same PHB traffic class, the priority of the flow plays a significant role. An example of calculating the number of flows associated with each priority class that have to be terminated is explained in Appendix A.2.
对于与相同PHB流量类别关联的流，流的优先级起着重要作用。附录A.2中解释了计算与每个必须终止的优先级等级相关联的流量数量的示例。
For the flows (sessions) that have to be terminated, the QNE Egress node generates and sends an end-to-end NOTIFY message to the QNE Ingress node (its upstream stateful QoS-NSLP peer) to indicate the severe congestion in the communication path.
对于必须终止的流（会话），QNE出口节点生成并向QNE入口节点（其上游有状态QoS NSLP对等方）发送端到端通知消息，以指示通信路径中的严重拥塞。
The non-default values of the objects contained in the NOTIFY message MUST be set by the QNE Egress node as follows (see QoS-NSLP-RMF API described in [RFC5974]):
通知消息中包含的对象的非默认值必须由QNE出口节点设置，如下所示（请参阅[RFC5974]中描述的QoS NSLP RMF API）：
* the values of the <INFO-SPEC> object is set by the standard QoS-NSLP protocol functions.
* <INFO-SPEC>对象的值由标准QoS NSLP协议函数设置。
* the <INFO-SPEC> object MUST include information that notifies that the end-to-end flow MUST be terminated. This information is as follows:
* <INFO-SPEC>对象必须包含通知必须终止端到端流的信息。这些资料如下：
Error severity class: Informational Error code value: Congestion situation
错误严重性类别：信息性错误代码值：拥塞情况
When the QNE Edges maintain a per-aggregate intra-domain QoS-NSLP operational state (see Section 4.3.1), the QNE Edge has to calculate, per each aggregate intra-domain QoS-NSLP operational state, the total bandwidth that has to be terminated in order to solve the severe congestion. The total bandwidth to be released is calculated in the same way as in the situation in which the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states. Note that for the aggregated sessions that are affected, the QNE Egress node generates and sends one end-to-end NOTIFY message to the QNE Ingress node (its upstream stateful QoS-NSLP peer) to indicate the severe congestion in the communication path. Note that this end-to-end NOTIFY message is associated with one of the end-to-end sessions that is bound to the aggregated intra-domain QoS-NSLP operational state.
当QNE边缘保持每个聚合域内QoS NSLP操作状态时（参见第4.3.1节），QNE边缘必须根据每个聚合域内QoS NSLP操作状态计算必须终止的总带宽，以解决严重拥塞。要释放的总带宽的计算方式与QNE边缘保持每流域内QoS NSLP操作状态的情况相同。注意，对于受影响的聚合会话，QNE出口节点生成并向QNE入口节点（其上游有状态QoS NSLP对等方）发送一条端到端通知消息，以指示通信路径中的严重拥塞。请注意，此端到端通知消息与绑定到聚合域内QoS NSLP操作状态的端到端会话之一相关联。
The non-default values of the objects contained in the NOTIFY message MUST be set by the QNE Egress node in the same way as the ones used by the end-to-end NOTIFY message described above for the situation that the QNE Egress maintains a per-flow intra-domain operational state. In addition to this, the end-to-end NOTIFY MUST carry the RMD-QSPEC, which contains a PDR container with a Parameter ID = 26, i.e., "PDR_Congestion_Report". The value of the <S> SHOULD be set. Furthermore, the value of the <PDR Bandwidth> parameter MUST contain the bandwidth associated with the aggregated QoS-NSLP operational state, which has to be released.
在QNE出口保持每流域内操作状态的情况下，包含在通知消息中的对象的非默认值必须由QNE出口节点以与上面描述的端到端通知消息所使用的相同的方式来设置。除此之外，端到端通知必须携带RMD-QSPEC，其中包含参数ID=26的PDR容器，即“PDR\U拥塞报告”。应设置<S>的值。此外，<PDR Bandwidth>参数的值必须包含与必须释放的聚合QoS NSLP操作状态相关联的带宽。
Furthermore, the number of end-to-end sessions that have to be terminated will be calculated as in the situation that the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states. Similarly for each, to be terminated, ongoing flow, the Egress will notify the Ingress in the same way as in the situation that the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states.
此外，必须终止的端到端会话的数目将在QNE边缘保持每流域内QoS NSLP操作状态的情况下计算。类似地，对于每个待终止的正在进行的流，出口将以与QNE边缘保持每流域内QoS NSLP操作状态的情况相同的方式通知入口。
Note that the QNE Egress SHOULD restore the original <DSCP> values of the re-marked packets; otherwise, multiple actions for the same event might occur. However, this value MAY be left in its re-marking form if there is an SLA agreement between domains that a downstream domain handles the re-marking problem.
注意，QNE出口应恢复重新标记的分组的原始<DSCP>值；否则，可能会对同一事件执行多个操作。但是，如果下游域处理重新标记问题的域之间存在SLA协议，则此值可能保留在其重新标记形式中。
An example of a detailed severe congestion operation in the Egress Nodes can be found in Appendix A.2.
出口节点中详细的严重拥塞操作示例见附录a.2。
Upon receiving the (end-to-end) NOTIFY message, the QNE Ingress node resolves the severe congestion by a predefined policy, e.g., by refusing new incoming flows (sessions), terminating the affected and notified flows (sessions), and blocking their packets or shifting them to an alternative RMD traffic class (PHB).
当接收到（端到端）通知消息时，QNE入口节点通过预定义的策略解决严重拥塞，例如，通过拒绝新的传入流（会话）、终止受影响和通知的流（会话）以及阻塞其分组或将其转移到替代RMD业务类别（PHB）。
This operation is depicted in Figure 14, where the QNE Ingress, for each flow (session) to be terminated, receives a NOTIFY message that carries the "Congestion situation" error code.
此操作如图14所示，其中QNE入口对于要终止的每个流（会话）接收一条带有“拥塞情况”错误代码的通知消息。
When the QNE Ingress node receives the end-to-end NOTIFY message, it associates this NOTIFY message with its bound intra-domain session (see Sections 4.3.2 and 4.3.3) via the BOUND-SESSION-ID information included in the end-to-end per-flow QoS-NSLP state. The QNE Ingress uses the operation described in Section 4.6.1.5.2 to terminate the intra-domain session.
当QNE入口节点接收到端到端通知消息时，它通过端到端每流QoS NSLP状态中包含的绑定会话ID信息将该通知消息与其绑定的域内会话（参见第4.3.2和4.3.3节）相关联。QNE入口使用第4.6.1.5.2节中描述的操作来终止域内会话。
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
QNE(Ingress) QNE(Interior) QNE(Interior) QNE(Egress)
user | | | |
data | user data | | |
------>|----------------->| user data | user data |
| |---------------->S(# marked bytes) |
| | S----------------->|
| | S(# unmarked bytes)|
| | S----------------->|Term.
| NOTIFY S |flow?
|<-----------------|-----------------S------------------|YES
|RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) S |
| ---------------->|RESERVE(RMD-QSPEC:T=1,M=1,S=1) |
| | S |
| |---------------->S |
| | RESERVE(RMD-QSPEC:Tear=1,M=1,S=1)
| | S----------------->|
user | | | |
data | user data | | |
------>|----------------->| user data | user data |
| |---------------->S(# marked bytes) |
| | S----------------->|
| | S(# unmarked bytes)|
| | S----------------->|Term.
| NOTIFY S |flow?
|<-----------------|-----------------S------------------|YES
|RESERVE(RMD-QSPEC:Tear=1,M=1,S=1) S |
| ---------------->|RESERVE(RMD-QSPEC:T=1,M=1,S=1) |
| | S |
| |---------------->S |
| | RESERVE(RMD-QSPEC:Tear=1,M=1,S=1)
| | S----------------->|
Figure 14: RMD severe congestion handling
图14:RMD严重拥塞处理
Note that the above functionality applies to the RMD reservation-based (see Section 4.3.3) and to both measurement-based admission control methods (i.e., congestion notification based on probing and the NSIS measurement-based admission control; see Section 4.3.2).
请注意，上述功能适用于基于RMD保留（见第4.3.3节）和基于测量的准入控制方法（即基于探测的拥塞通知和基于NSIS测量的准入控制；见第4.3.2节）。
In the case that the QNE Edges support aggregated intra-domain QoS-NSLP operational states, the following actions take place. The QNE Ingress MAY receive an end-to-end NOTIFY message with a PDR container that carries an <S> marked and a bandwidth value in the <PDR
在QNE边缘支持聚合的域内QoS NSLP操作状态的情况下，将执行以下操作。QNE入口可以接收带有PDR容器的端到端通知消息，该PDR容器在<PDR中携带<S>标记和带宽值
Bandwidth> parameter included in a "PDR_Congestion_Report" container. Furthermore, the same end-to-end NOTIFY message carries an <INFO-SPEC> object with the "Congestion situation" error code.
“PDR\U拥塞报告”容器中包含的带宽>参数。此外，相同的端到端通知消息携带带有“拥塞情况”错误代码的<INFO-SPEC>对象。
When the QNE Ingress node receives this end-to-end NOTIFY message, it associates the NOTIFY message with the aggregated intra-domain QoS-NSLP operational state via the BOUND-SESSION-ID information included in the end-to-end per-flow QoS-NSLP operational state, see Section 4.3.1.
当QNE入口节点接收到此端到端通知消息时，它通过端到端每流QoS NSLP操作状态中包含的绑定会话ID信息，将通知消息与聚合的域内QoS NSLP操作状态相关联，请参见第4.3.1节。
The RMD-QOSM at the QNE Ingress node by using the total bandwidth value to be released included in the <PDR Bandwidth> parameter MUST reduce the bandwidth associated and reserved by the RMD aggregated session. This is accomplished by triggering the RMD modification for aggregated reservations procedure described in Section 4.6.1.4.
QNE入口节点处的RMD-QOSM通过使用<PDR bandwidth>参数中包含的要释放的总带宽值，必须减少RMD聚合会话关联和保留的带宽。这是通过触发第4.6.1.4节所述的汇总保留程序的RMD修改来实现的。
In addition to the above, the QNE Ingress MUST select a number of inter-domain (end-to-end) flows (sessions) that MUST be terminated. This is accomplished in the same way as in the situation that the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states.
除上述内容外，QNE入口必须选择许多必须终止的域间（端到端）流（会话）。这与QNE边缘保持每流域内QoS NSLP操作状态的情况相同。
The terminated end-to-end sessions are selected from the end-to-end sessions bound to the aggregated intra-domain QoS-NSLP operational state. Note that the end-to-end session associated with the received end-to-end NOTIFY message that notified the severe congestion MUST also be selected for termination.
终止的端到端会话是从绑定到聚合域内QoS NSLP操作状态的端到端会话中选择的。请注意，还必须选择与接收到的通知严重拥塞的端到端通知消息关联的端到端会话进行终止。
For the flows (sessions) that have to be terminated, the QNE Ingress node generates and sends an end-to-end NOTIFY message upstream towards the sender (QNI). The values carried by this message are:
对于必须终止的流（会话），QNE入口节点生成并向发送方（QNI）上游发送端到端通知消息。此消息包含的值为：
* the values of the <INFO-SPEC> object set by the standard QoS-NSLP protocol functions.
* 标准QoS NSLP协议函数设置的<INFO-SPEC>对象的值。
* the <INFO-SPEC> object MUST include information that notifies that the end-to-end flow MUST be terminated. This information is as follows:
* <INFO-SPEC>对象必须包含通知必须终止端到端流的信息。这些资料如下：
Error severity class: Informational Error code value: Congestion situation
错误严重性类别：信息性错误代码值：拥塞情况
4.6.1.7. Admission Control Using Congestion Notification Based on Probing
4.6.1.7. 基于探测的拥塞通知接纳控制
The congestion notification function based on probing can be used to implement a simple measurement-based admission control within a Diffserv domain. At Interior nodes along the data path, congestion
基于探测的拥塞通知功能可用于在区分服务域内实现简单的基于测量的接纳控制。在沿数据路径的内部节点，拥塞
notification thresholds are set in the measurement-based admission control function for the traffic belonging to different PHBs. These Interior nodes are not NSIS-aware nodes.
在基于测量的准入控制功能中为属于不同PHB的流量设置通知阈值。这些内部节点不是NSIS感知节点。
When an end-to-end reservation request (RESERVE) arrives at the Ingress node (QNE), see Figure 15, it is processed based on the procedures defined by the end-to-end QoS Model.
当端到端保留请求（RESERVE）到达入口节点（QNE）时，请参见图15，它将根据端到端QoS模型定义的过程进行处理。
The <DSCP> field of the GIST datagram message that is used to transport this probe RESERVE message, SHOULD be marked with the same value of DSCP as the data path packets associated with the same session. In this way, it is ensured that the end-to-end RESERVE (probe) packet passed through the node that it is congested. This feature is very useful when ECMP-based routing is used to detect only flows that are passing through the congested router.
用于传输此探测保留消息的GIST数据报消息的<DSCP>字段应标记为与同一会话关联的数据路径数据包相同的DSCP值。这样，确保端到端保留（探测）分组通过其拥塞的节点。当基于ECMP的路由仅用于检测通过拥塞路由器的流时，此功能非常有用。
When a (end-to-end) RESPONSE message is received by the Ingress node,it will be processed based on the procedures defined by the end-to-end QoS Model.
当入口节点接收到（端到端）响应消息时，将根据端到端QoS模型定义的过程对其进行处理。
These Interior nodes do not need to be NSIS-aware nodes and they do not need to process the NSIS functionality of NSIS messages. Note that the "not NSIS-aware" nodes MUST be configured such that they can detect the congestion/severe congestion situations and re-mark packets in the same way the "NSIS-aware" nodes do.
这些内部节点不需要是NSIS感知节点，也不需要处理NSIS消息的NSIS功能。请注意，“非NSIS感知”节点的配置必须确保它们能够检测拥塞/严重拥塞情况，并以与“NSIS感知”节点相同的方式重新标记数据包。
Using standard functionalities, congestion notification thresholds are set for the traffic that belongs to different PHBs (see Section 4.3.2). The end-to-end RESERVE message, see Figure 15, is used as a probe packet.
使用标准功能，为属于不同PHB的流量设置拥塞通知阈值（见第4.3.2节）。端到端保留消息（见图15）用作探测数据包。
The <DSCP> field of all data packets and of the GIST message carrying the RESERVE message will be re-marked when the corresponding "congestion notification" threshold is exceeded (see Section 4.3.2). Note that when the data rate is higher than the congestion notification threshold, the data packets are also re-marked. An example of the detailed operation of this procedure is given in Appendix A.2.
当超过相应的“拥塞通知”阈值时（见第4.3.2节），所有数据包和承载保留消息的GIST消息的<DSCP>字段将被重新标记。注意，当数据速率高于拥塞通知阈值时，数据包也会被重新标记。附录A.2中给出了该程序的详细操作示例。
As emphasized in Section 4.6.1.6.2.2, the Egress node, by using the per-flow end-to-end QoS-NSLP states, can derive which flows are using the same PHB and are sent by the same Ingress.
如第4.6.1.6.2.2节所强调的，出口节点通过使用每流端到端QoS NSLP状态，可以得出哪些流使用相同的PHB，哪些流由相同的入口发送。
For each Ingress, the Egress SHOULD generate an Ingress/Egress pair aggregated (RMF) reservation state for each supported PHB. Note that this aggregated reservation state does not require that an aggregated intra-domain QoS-NSLP operational state is needed also.
对于每个入口，出口应为每个支持的PHB生成入口/出口对聚合（RMF）保留状态。请注意，此聚合保留状态并不要求还需要聚合的域内QoS NSLP操作状态。
Appendix A.4 contains an example of how and when a (probe) RESERVE message that arrives at the Egress is admitted or rejected.
附录A.4包含一个示例，说明到达出口的（探测）保留消息如何以及何时被接纳或拒绝。
If the request is rejected, then the Egress node SHOULD generate an (end-to-end) RESPONSE message to notify that the reservation is unsuccessful. In particular, it will generate an <INFO-SPEC> object of:
如果请求被拒绝，则出口节点应生成（端到端）响应消息，以通知预约失败。特别是，它将生成以下对象的<INFO-SPEC>：
Error severity class: Transient Failure Error code value: Reservation failure
错误严重性等级：瞬时故障错误代码值：保留故障
The QSPEC that was carried by the end-to-end RESERVE that belongs to the same session as this end-to-end RESPONSE is included in this message. The parameters included in the QSPEC <QoS Reserved> object are copied from the original <QoS Desired> values. The <E> flag associated with the <QoS Reserved> object and the <E> flag associated with local RMD-QSPEC <TMOD-1> parameter are also set. This RESPONSE message will be sent to the Ingress node and it will be processed based on the end-to-end QoS Model.
此消息中包含由属于与此端到端响应相同会话的端到端保留所承载的QSPEC。QSPEC<QoS Reserved>对象中包含的参数是从原始<QoS Desired>值复制而来的。还设置了与<QoS Reserved>对象关联的<E>标志和与本地RMD-QSPEC<TMOD-1>参数关联的<E>标志。该响应消息将被发送到入口节点，并将根据端到端QoS模型进行处理。
Note that the QNE Egress SHOULD restore the original <DSCP> values of the re-marked packets; otherwise, multiple actions for the same event might occur. However, this value MAY be left in its re-marking form if there is an SLA agreement between domains that a downstream domain handles the re-marking problem. Note that the break <B> flag carried by the end-to-end RESERVE message MUST NOT be set.
注意，QNE出口应恢复重新标记的分组的原始<DSCP>值；否则，可能会对同一事件执行多个操作。但是，如果下游域处理重新标记问题的域之间存在SLA协议，则此值可能保留在其重新标记形式中。请注意，不得设置端到端保留消息携带的中断<B>标志。
QNE(Ingress) Interior Interior QNE(Egress)
(not NSIS aware) (not NSIS aware)
user | | | |
data | user data | | |
------>|----------------->| user data | |
| |---------------->| user data |
| | |----------------->|
user | | | |
data | user data | | |
------>|----------------->| user data | user data |
| |---------------->S(# marked bytes) |
| | S----------------->|
| | S(# unmarked bytes)|
| | S----------------->|
| | S |
RESERVE | | S |
------->| | S |
|----------------------------------->S |
| | RESERVE(re-marked DSCP in GIST)
| | S----------------->|
| |RESPONSE(unsuccessful INFO-SPEC) |
|<------------------------------------------------------|
RESPONSE(unsuccessful INFO-SPEC) | |
<------| | | |
QNE(Ingress) Interior Interior QNE(Egress)
(not NSIS aware) (not NSIS aware)
user | | | |
data | user data | | |
------>|----------------->| user data | |
| |---------------->| user data |
| | |----------------->|
user | | | |
data | user data | | |
------>|----------------->| user data | user data |
| |---------------->S(# marked bytes) |
| | S----------------->|
| | S(# unmarked bytes)|
| | S----------------->|
| | S |
RESERVE | | S |
------->| | S |
|----------------------------------->S |
| | RESERVE(re-marked DSCP in GIST)
| | S----------------->|
| |RESPONSE(unsuccessful INFO-SPEC) |
|<------------------------------------------------------|
RESPONSE(unsuccessful INFO-SPEC) | |
<------| | | |
Figure 15: Using RMD congestion notification function for admission control based on probing
图15：使用RMD拥塞通知功能进行基于探测的准入控制
This section describes the basic bidirectional operation and sequence of events/triggers of the RMD-QOSM. The following basic operation cases are distinguished:
本节描述RMD-QOSM的基本双向操作和事件/触发器顺序。区分以下基本操作情况：
* Successful and unsuccessful reservation (Section 4.6.2.1); * Refresh reservation (Section 4.6.2.2); * Modification of aggregated reservation (Section 4.6.2.3); * Release procedure (Section 4.6.2.4); * Severe congestion handling (Section 4.6.2.5); * Admission control using congestion notification based on probing (Section 4.6.2.6).
* 成功和不成功的预订（第4.6.2.1节）；*刷新预订（第4.6.2.2节）；*修改合计保留（第4.6.2.3节）；*发布程序（第4.6.2.4节）*严重拥堵处理（第4.6.2.5节）；*使用基于探测的拥塞通知进行准入控制（第4.6.2.6节）。
It is important to emphasize that the content of this section is used for the specification of the following RMD-QOSM/QoS-NSLP signaling schemes, when basic unidirectional operation is assumed:
需要强调的是，当假设基本单向操作时，本节内容用于以下RMD-QOSM/QoS NSLP信令方案的规范：
* "per-flow congestion notification based on probing";
* “基于探测的每流拥塞通知”；
* "per-flow RMD NSIS measurement-based admission control",
* “基于每流RMD NSIS测量的准入控制”，
* "per-flow RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
* “基于每流RMD预留”与“通过RMD-QOSM刷新进行严重拥塞处理”程序相结合；
* "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure;
* “基于每流RMD预留”与“按比例数据包标记的严重拥塞处理”程序相结合；
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by the RMD-QOSM refresh" procedure;
* 结合“通过RMD-QOSM刷新进行严重拥塞处理”程序的“基于每个总RMD预订”；
* "per-aggregate RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" procedure.
* “基于每聚合RMD保留”与“按比例数据包标记的严重拥塞处理”程序相结合。
For more details, please see Section 3.2.3.
有关更多详细信息，请参见第3.2.3节。
In particular, the functionality described in Sections 4.6.2.1, 4.6.2.2, 4.6.2.3, 4.6.2.4, and 4.6.2.5 applies to the RMD reservation-based and NSIS measurement-based admission control methods. The described functionality in Section 4.6.2.6 applies to the admission control procedure that uses the congestion notification based on probing. The QNE Edge nodes maintain either per-flow QoS-NSLP operational and reservation states or aggregated QoS-NSLP operational and reservation states.
特别是，第4.6.2.1节、第4.6.2.2节、第4.6.2.3节、第4.6.2.4节和第4.6.2.5节中描述的功能适用于基于RMD保留和基于NSIS测量的准入控制方法。第4.6.2.6节中描述的功能适用于使用基于探测的拥塞通知的准入控制程序。QNE边缘节点维护每流QoS NSLP操作和保留状态或聚合QoS NSLP操作和保留状态。
RMD-QOSM assumes that asymmetric routing MAY be applied in the RMD domain. Combined sender-receiver initiated reservation cannot be efficiently done in the RMD domain because upstream NTLP states are not stored in Interior routers.
RMD-QOSM假设可以在RMD域中应用非对称路由。由于上游NTLP状态未存储在内部路由器中，因此无法在RMD域中有效地执行由发送方-接收方发起的组合预约。
Therefore, the bidirectional operation SHOULD be performed by two sender-initiated reservations (sender&sender). We assume that the QNE Edge nodes are common for both upstream and downstream directions, therefore, the two reservations/sessions can be bound at the QNE Edge nodes. Note that if this is not the case, then the bidirectional procedure could be managed and maintained by nodes located outside the RMD domain, by using other procedures than the ones defined in RMD-QOSM.
因此，双向操作应由两个发送方发起的保留（发送方和发送方）执行。我们假设QNE边缘节点对于上游和下游方向都是公共的，因此，两个保留/会话可以绑定在QNE边缘节点上。注意，如果情况并非如此，则可通过使用RMD-QOSM中定义的程序以外的其他程序，由位于RMD域之外的节点管理和维护双向程序。
This (intra-domain) bidirectional sender&sender procedure can then be applied between the QNE Edge (QNE Ingress and QNE Egress) nodes of the RMD QoS signaling model. In the situation in which a security association exists between the QNE Ingress and QNE Egress nodes (see Figure 15), and the QNE Ingress node has the REQUIRED <Peak Data Rate-1 (p)> values of the local RMD-QSPEC <TMOD-1> parameters for both directions, i.e., QNE Ingress towards QNE Egress and QNE Egress
该（域内）双向发送方和发送方过程随后可应用于RMD QoS信令模型的QNE边缘（QNE入口和QNE出口）节点之间。在QNE入口和QNE出口节点之间存在安全关联的情况下（见图15），并且QNE入口节点具有两个方向的本地RMD-QSPEC<TMOD-1>参数的所需<峰值数据速率-1（p）>值，即QNE入口到QNE出口和QNE出口
towards QNE Ingress, then the QNE Ingress MAY include both <Peak Data Rate-1 (p)> values of the local RMD-QSPEC <TMOD-1> parameters (needed for both directions) into the RMD-QSPEC within a RESERVE message. In this way, the QNE Egress node is able to use the QoS parameters needed for the "Egress towards Ingress" direction (QoS-2). The QNE Egress is then able to create a RESERVE with the right QoS parameters included in the QSPEC, i.e., RESERVE (QoS-2). Both directions of the flows are bound by inserting <BOUND-SESSION-ID> objects at the QNE Ingress and QNE Egress, which will be carried by bound end-to-end RESERVE messages.
对于QNE入口，则QNE入口可在保留消息内将本地RMD-QSPEC<TMOD-1>参数（两个方向都需要）的两个<Peak Data Rate-1（p）>值包括到RMD-QSPEC中。这样，QNE出口节点能够使用“出口到入口”方向（QoS-2）所需的QoS参数。然后，QNE出口能够使用QSPEC中包括的正确QoS参数创建保留，即保留（QoS-2）。通过在QNE入口和QNE出口插入<bound-SESSION-ID>对象来绑定流的两个方向，这将由绑定的端到端保留消息携带。
|------ RESERVE (QoS-1, QoS-2)----|
| V
| Interior/stateless QNEs
+---+ +---+
|------->|QNE|-----|QNE|------
| +---+ +---+ |
| V
+---+ +---+
|QNE| |QNE|
+---+ +---+
^ |
| | +---+ +---+ V
| |-------|QNE|-----|QNE|-----|
| +---+ +---+
Ingress/ Egress/
stateful QNE stateful QNE
|
<--------- RESERVE (QoS-2) -------|
|------ RESERVE (QoS-1, QoS-2)----|
| V
| Interior/stateless QNEs
+---+ +---+
|------->|QNE|-----|QNE|------
| +---+ +---+ |
| V
+---+ +---+
|QNE| |QNE|
+---+ +---+
^ |
| | +---+ +---+ V
| |-------|QNE|-----|QNE|-----|
| +---+ +---+
Ingress/ Egress/
stateful QNE stateful QNE
|
<--------- RESERVE (QoS-2) -------|
Figure 16: The intra-domain bidirectional reservation scenario in the RMD domain
图16:RMD域中的域内双向保留场景
Note that it is RECOMMENDED that the QNE implementations of RMD-QOSM process the QoS-NSLP signaling messages with a higher priority than data packets. This can be accomplished as described in Section 3.3.4 in [RFC5974] and the QoS-NSLP-RMF API [RFC5974].
注意，建议RMD-QOSM的QNE实现以比数据分组更高的优先级处理QoS NSLP信令消息。这可以按照[RFC5974]第3.3.4节和QoS NSLP RMF API[RFC5974]中的描述完成。
A bidirectional reservation, within the RMD domain, is indicated by the PHR <B> and PDR <B> flags, which are set in all messages. In this case, two <BOUND-SESSION-ID> objects SHOULD be used.
RMD域内的双向保留由在所有消息中设置的PHR<B>和PDR<B>标志指示。在这种情况下，应使用两个<BOUND-SESSION-ID>对象。
When the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states, the end-to-end RESERVE message carries two BOUND-SESSION-IDs. One BOUND-SESSION-ID carries the SESSION-ID of the tunneled intra-domain (per-flow) session that is using a Binding_Code with value set to code (Tunneled and end-to-end sessions). Another
当QNE边缘保持每流域内QoS NSLP操作状态时，端到端保留消息携带两个绑定会话ID。一个bind-SESSION-ID携带隧道域内（每个流）会话的SESSION-ID，该会话使用值设置为Code的Binding_代码（隧道会话和端到端会话）。另一个
BOUND-SESSION-ID carries the SESSION-ID of the bound bidirectional end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Bidirectional sessions).
绑定会话ID携带绑定的双向端到端会话的会话ID。与此绑定会话ID关联的绑定代码设置为代码（双向会话）。
When the QNE Edges maintain aggregated intra-domain QoS-NSLP operational states, the end-to-end RESERVE message carries two BOUND-SESSION-IDs. One BOUND-SESSION-ID carries the SESSION-ID of the tunneled aggregated intra-domain session that is using a Binding_Code with value set to code (Aggregated sessions). Another BOUND-SESSION-ID carries the SESSION-ID of the bound bidirectional end-to-end session. The Binding_Code associated with this BOUND-SESSION-ID is set to code (Bidirectional sessions).
当QNE边缘保持聚合的域内QoS NSLP操作状态时，端到端保留消息携带两个绑定会话ID。一个绑定会话ID携带隧道聚合域内会话的会话ID，该会话使用值设置为Code（聚合会话）的绑定代码。另一个绑定会话ID携带绑定的双向端到端会话的会话ID。与此绑定会话ID关联的绑定代码设置为代码（双向会话）。
The intra-domain and end-to-end QoS-NSLP operational states are initiated/modified depending on the binding type (see Sections 4.3.1, 4.3.2, and 4.3.3).
根据绑定类型启动/修改域内和端到端QoS NSLP操作状态（参见第4.3.1、4.3.2和4.3.3节）。
If no security association exists between the QNE Ingress and QNE Egress nodes, the bidirectional reservation for the sender&sender scenario in the RMD domain SHOULD use the scenario specified in [RFC5974] as "bidirectional reservation for sender&sender scenario". This is because in this scenario, the RESERVE message sent from the QNE Ingress to QNE Egress does not have to carry the QoS parameters needed for the "Egress towards Ingress" direction (QoS-2).
如果QNE入口和QNE出口节点之间不存在安全关联，RMD域中发送方和发送方场景的双向保留应使用[RFC5974]中指定的场景作为“发送方和发送方场景的双向保留”。这是因为在此场景中，从QNE入口发送到QNE出口的保留消息不必携带“出口到入口”方向（QoS-2）所需的QoS参数。
In the following sections, it is considered that the QNE Edge nodes are common for both upstream and downstream directions and therefore, the two reservations/sessions can be bound at the QNE Edge nodes. Furthermore, it is considered that a security association exists between the QNE Ingress and QNE Egress nodes, and the QNE Ingress node has the REQUIRED <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameters for both directions, i.e., QNE Ingress towards QNE Egress and QNE Egress towards QNE Ingress.
在以下部分中，认为QNE边缘节点对于上游和下游方向都是公共的，因此，两个保留/会话可以在QNE边缘节点处绑定。此外，认为QNE入口和QNE出口节点之间存在安全关联，并且QNE入口节点具有两个方向的本地RMD-QSPEC<TMOD-1>参数的所需<峰值数据速率-1（p）>值，即，QNE入口朝向QNE出口和QNE出口朝向QNE入口。
According to Section 3.2.3, it is specified that only the "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" scheme MUST be implemented within one RMD domain. However, all RMD QNEs supporting this specification MUST support the combination the "per-flow RMD reservation-based" in combination with the "severe congestion handling by proportional data packet marking" scheme. If the RMD QNEs support more RMD-QOSM schemes, then the operator of that RMD domain MUST preconfigure all the QNE Edge nodes within one domain such that the <SCH> field included in the "PHR Container" (Section 4.1.2) and the "PDR Container" (Section 4.1.3) will always use the same value, such that within one RMD domain, only one of the below described RMD-QOSM schemes is used at a time.
根据第3.2.3节，规定在一个RMD域内只能实施“基于每流RMD预留”和“通过比例数据包标记进行严重拥塞处理”方案。然而，所有支持本规范的RMD QNE必须支持“基于每流RMD预留”与“通过比例数据包标记进行严重拥塞处理”方案的组合。如果RMD QNE支持更多RMD-QOSM方案，则该RMD域的运营商必须预先配置一个域内的所有QNE边缘节点，以便“PHR容器”（第4.1.2节）和“PDR容器”（第4.1.3节）中包含的<SCH>字段始终使用相同的值，以便在一个RMD域内，一次仅使用下述RMD-QOSM方案中的一个。
All QNE nodes located within the RMD domain MUST read and interpret the <SCH> field included in the "PHR Container" before processing all the other <PHR Container> payload fields. Moreover, all QNE Edge nodes located at the boarder of the RMD domain, MUST read and interpret the <SCH> field included in the "PDR container" before processing all the other <PDR Container> payload fields.
在处理所有其他<PHR Container>有效载荷字段之前，位于RMD域内的所有QNE节点必须读取并解释“PHR Container”中包含的<SCH>字段。此外，位于RMD域边界的所有QNE边缘节点必须在处理所有其他<PDR container>有效载荷字段之前读取并解释“PDR container”中包含的<SCH>字段。
This section describes the operation of the RMD-QOSM where an RMD Intra-domain bidirectional reservation operation, see Figure 16 and Section 4.6.2, is either successfully or unsuccessfully accomplished.
本节描述RMD-QOSM的操作，其中RMD域内双向保留操作（见图16和第4.6.2节）成功或未成功完成。
The bidirectional successful reservation is similar to a combination of two unidirectional successful reservations that are accomplished in opposite directions, see Figure 17. The main differences of the bidirectional successful reservation procedure with the combination of two unidirectional successful reservations accomplished in opposite directions are as follows. Note also that the intra-domain and end-to-end QoS-NSLP operational states generated and maintained by the end-to-end RESERVE messages contain, compared to the unidirectional reservation scenario, a different BOUND-SESSION-ID data structure (see Sections 4.3.1, 4.3.2, and 4.3.3). In this scenario, the intra-domain RESERVE message sent by the QNE Ingress node towards the QNE Egress node is denoted in Figure 17 as RESERVE (RMD-QSPEC): "forward". The main differences between the intra-domain RESERVE (RMD-QSPEC): "forward" message used for the bidirectional successful reservation procedure and a RESERVE (RMD-QSPEC) message used for the unidirectional successful reservation are as follows (see the QoS-NSLP-RMF API described in [RFC5974]):
双向成功预订类似于在相反方向上完成的两个单向成功预订的组合，见图17。双向成功预订程序与在相反方向上完成的两个单向成功预订组合的主要区别如下。还请注意，与单向保留场景相比，由端到端保留消息生成和维护的域内和端到端QoS NSLP操作状态包含不同的绑定会话ID数据结构（请参见第4.3.1、4.3.2和4.3.3节）。在此场景中，QNE入口节点向QNE出口节点发送的域内保留消息在图17中表示为保留（RMD-QSPEC）：“转发”。域内保留（RMD-QSPEC）之间的主要区别在于：用于双向成功保留过程的“转发”消息和用于单向成功保留的保留（RMD-QSPEC）消息如下所示（参见[RFC5974]中描述的QoS NSLP RMF API）：
* the <RII> object MUST NOT be included in the message. This is because no RESPONSE message is REQUIRED.
* 消息中不得包含<RII>对象。这是因为不需要响应消息。
* the <B> bit of the PHR container indicates a bidirectional reservation and it MUST be set to "1".
* PHR容器的<B>位表示双向保留，必须将其设置为“1”。
* the PDR container is also included in the RESERVE(RMD-QSPEC): "forward" message. The value of the Parameter ID is "20", i.e., "PDR_Reservation_Request". Note that the response PDR container sent by a QNE Egress to a QNE Ingress node is not carried by an end-to-end RESPONSE message, but it is carried by an intra-domain RESERVE message that is sent by the QNE Egress node towards the QNE Ingress node (denoted in Figure 16 as RESERVE(RMD-QSPEC): "reverse").
* PDR容器也包含在保留（RMD-QSPEC）中：“转发”消息。参数ID的值为“20”，即“PDR\U预订\U请求”。注意，QNE出口发送到QNE入口节点的响应PDR容器不是由端到端响应消息承载的，而是由QNE出口节点发送到QNE入口节点的域内保留消息承载的（在图16中表示为保留（RMD-QSPEC）：“反向”）。
* the <B> PDR bit indicates a bidirectional reservation and is set to "1".
* <B>PDR位表示双向保留，并设置为“1”。
* the <PDR Bandwidth> field specifies the requested bandwidth that has to be used by the QNE Egress node to initiate another intra-domain RESERVE message in the reverse direction.
* <PDR Bandwidth>字段指定QNE出口节点必须使用的请求带宽，以反向启动另一个域内保留消息。
The RESERVE(RMD-QSPEC): "reverse" message is initiated by the QNE Egress node at the moment that the RESERVE(RMD-QSPEC): "forward" message is successfully processed by the QNE Egress node.
保留（RMD-QSPEC）：“反向”消息由QNE出口节点在QNE出口节点成功处理保留（RMD-QSPEC）：“正向”消息时启动。
The main differences between the RESERVE(RMD-QSPEC): "reverse" message used for the bidirectional successful reservation procedure and a RESERVE(RMD-QSPEC) message used for the unidirectional successful reservation are as follows:
RESERVE（RMD-QSPEC）与RESERVE（RMD-QSPEC）之间的主要区别在于：用于双向成功预订过程的“反向”消息与用于单向成功预订的RESERVE（RMD-QSPEC）消息如下：
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
| | | | |
|RESERVE(RMD-QSPEC) | | |
|"forward" | | | |
| | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | | |
| |------------------------------>| |
| | | |------------->|
| | | | |
| | |RESERVE(RMD-QSPEC) |
| RESERVE(RMD-QSPEC) | "reverse" |<-------------|
| "reverse" | |<--------------| |
|<-------------------------------| | |
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
| | | | |
|RESERVE(RMD-QSPEC) | | |
|"forward" | | | |
| | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | | |
| |------------------------------>| |
| | | |------------->|
| | | | |
| | |RESERVE(RMD-QSPEC) |
| RESERVE(RMD-QSPEC) | "reverse" |<-------------|
| "reverse" | |<--------------| |
|<-------------------------------| | |
Figure 17: Intra-domain signaling operation for successful bidirectional reservation
图17：成功双向预约的域内信令操作
* the <RII> object is not included in the message. This is because no RESPONSE message is REQUIRED;
* <RII>对象不包括在消息中。这是因为不需要响应消息；
* the value of the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter is set equal to the value of the <PDR Bandwidth> field included in the RESERVE(RMD-QSPEC): "forward" message that triggered the generation of this RESERVE(RMD-QSPEC): "reverse" message;
* 本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段的值设置为等于保留（RMD-QSPEC）中包含的<PDR带宽>字段的值：“转发”消息触发该保留（RMD-QSPEC）的生成：“反向”消息；
* the <B> bit of the PHR container indicates a bidirectional reservation and is set to "1";
* PHR容器的<B>位表示双向保留，并设置为“1”；
* the PDR container is included into the RESERVE(RMD-QSPEC): "reverse" message. The value of the Parameter ID is "23", i.e., "PDR_Reservation_Report";
* PDR容器包含在保留（RMD-QSPEC）中：“反向”消息。参数ID的值为“23”，即“PDR\U预留报告”；
* the <B> PDR bit indicates a bidirectional reservation and is set to "1".
* <B>PDR位表示双向保留，并设置为“1”。
Figures 18 and 19 show the flow diagrams used in the case of an unsuccessful bidirectional reservation. In Figure 18, the QNE that is not able to support the requested <Peak Data Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> is located in the direction QNE Ingress towards QNE Egress. In Figure 19, the QNE that is not able to support the requested <Peak Data Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> is located in the direction QNE Egress towards QNE Ingress. The main differences between the bidirectional unsuccessful procedure shown in Figure 18 and the bidirectional successful procedure are as follows:
图18和19显示了双向预订失败时使用的流程图。在图18中，无法支持本地RMD-QSPEC<TMOD-1>的请求<峰值数据速率-1（p）>值的QNE位于QNE入口朝向QNE出口的方向。在图19中，无法支持本地RMD-QSPEC<TMOD-1>的请求<峰值数据速率-1（p）>值的QNE位于QNE出口朝向QNE入口的方向。图18所示的双向不成功程序与双向成功程序之间的主要区别如下：
* the QNE node that is not able to reserve resources for a certain request is located in the "forward" path, i.e., the path from the QNE Ingress towards the QNE Egress.
* 无法为特定请求保留资源的QNE节点位于“转发”路径中，即，从QNE入口到QNE出口的路径。
* the QNE node that is not able to support the requested <Peak Data Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> MUST mark the <M> bit, i.e., set to value "1", of the RESERVE(RMD-QSPEC): "forward".
* 无法支持本地RMD-QSPEC<TMOD-1>请求的<Peak Data Rate-1（p）>值的QNE节点必须标记<M>位，即设置为保留（RMD-QSPEC）的值“1”：“向前”。
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
|RESERVE(RMD-QSPEC): | | |
| "forward" | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | M RESERVE(RMD-QSPEC):
| |--------------------------->M "forward-M marked"
| | | M-------------->|
| | RESPONSE(PDR) M |
| | "forward - M marked"M |
|<------------------------------------------------------------|
|RESERVE(RMD-QSPEC, K=0) | M |
|"forward - T tear" | M |
|--------------->| | M |
| RESERVE(RMD-QSPEC, K=1) M |
| | "forward - T tear" M |
| |--------------------------->M |
| | RESERVE(RMD-QSPEC, K=1) |
| | "forward - T tear" |
| | M-------------->|
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
|RESERVE(RMD-QSPEC): | | |
| "forward" | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | M RESERVE(RMD-QSPEC):
| |--------------------------->M "forward-M marked"
| | | M-------------->|
| | RESPONSE(PDR) M |
| | "forward - M marked"M |
|<------------------------------------------------------------|
|RESERVE(RMD-QSPEC, K=0) | M |
|"forward - T tear" | M |
|--------------->| | M |
| RESERVE(RMD-QSPEC, K=1) M |
| | "forward - T tear" M |
| |--------------------------->M |
| | RESERVE(RMD-QSPEC, K=1) |
| | "forward - T tear" |
| | M-------------->|
Figure 18: Intra-domain signaling operation for unsuccessful bidirectional reservation (rejection on path QNE(Ingress) towards QNE(Egress))
图18：不成功双向保留的域内信令操作（路径QNE（入口）到QNE（出口）的拒绝）
The operation for this type of unsuccessful bidirectional reservation is similar to the operation for unsuccessful unidirectional reservation, shown in Figure 9.
这种不成功的双向预约的操作类似于不成功的单向预约的操作，如图9所示。
The main differences between the bidirectional unsuccessful procedure shown in Figure 19 and the in bidirectional successful procedure are as follows:
图19所示的双向不成功程序与双向成功程序之间的主要区别如下：
* the QNE node that is not able to reserve resources for a certain request is located in the "reverse" path, i.e., the path from the QNE Egress towards the QNE Ingress.
* 无法为特定请求保留资源的QNE节点位于“反向”路径中，即从QNE出口到QNE入口的路径。
* the QNE node that is not able to support the requested <Peak Data Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> MUST mark the <M> bit, i.e., set to value "1", the RESERVE(RMD-QSPEC): "reverse".
* 无法支持本地RMD-QSPEC<TMOD-1>请求的<Peak Data Rate-1（p）>值的QNE节点必须标记<M>位，即设置为值“1”，保留（RMD-QSPEC）：“反向”。
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
|RESERVE(RMD-QSPEC) | | |
|"forward" | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | RESERVE(RMD-QSPEC): |
| |-------------------------------->|"forward" |
| | RESERVE(RMD-QSPEC): |------------->|
| | "reverse" | | |
| | RESERVE(RMD-QSPEC) | |
| RESERVE(RMD-QSPEC): M "reverse" |<-------------|
| "reverse - M marked" M<---------------| |
|<--------------------------------M | |
| | M | |
|RESERVE(RMD-QSPEC, K=0): M | |
|"forward - T tear" M | |
|--------------->| RESERVE(RMD-QSPEC, K=0): | |
| | "forward - T tear" | |
| |-------------------------------->| |
| | M |------------->|
| | M RESERVE(RMD-QSPEC, K=0):
| | M "reverse - T tear" |
| | M |<-------------|
| M RESERVE(RMD-QSPEC, K=1) |
| | M "forward - T tear" |
| | M<---------------| |
| RESERVE(RMD-QSPEC, K=1)M | |
| "forward - T tear" M | |
|<--------------------------------M | |
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
|RESERVE(RMD-QSPEC) | | |
|"forward" | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | RESERVE(RMD-QSPEC): |
| |-------------------------------->|"forward" |
| | RESERVE(RMD-QSPEC): |------------->|
| | "reverse" | | |
| | RESERVE(RMD-QSPEC) | |
| RESERVE(RMD-QSPEC): M "reverse" |<-------------|
| "reverse - M marked" M<---------------| |
|<--------------------------------M | |
| | M | |
|RESERVE(RMD-QSPEC, K=0): M | |
|"forward - T tear" M | |
|--------------->| RESERVE(RMD-QSPEC, K=0): | |
| | "forward - T tear" | |
| |-------------------------------->| |
| | M |------------->|
| | M RESERVE(RMD-QSPEC, K=0):
| | M "reverse - T tear" |
| | M |<-------------|
| M RESERVE(RMD-QSPEC, K=1) |
| | M "forward - T tear" |
| | M<---------------| |
| RESERVE(RMD-QSPEC, K=1)M | |
| "forward - T tear" M | |
|<--------------------------------M | |
Figure 19: Intra-domain signaling normal operation for unsuccessful bidirectional reservation (rejection on path QNE(Egress) towards QNE(Ingress)
图19：不成功双向保留的域内信令正常操作（路径QNE（出口）到QNE（入口）的拒绝）
* the QNE Ingress uses the information contained in the received PHR and PDR containers of the RESERVE(RMD-QSPEC): "reverse" and generates a tear intra-domain RESERVE(RMD-QSPEC): "forward - T tear" message. This message carries a "PHR_Release_Request" and "PDR_Release_Request" control information. This message is sent to the QNE Egress node. The QNE Egress node uses the information contained in the "PHR_Release_Request" and the "PDR_Release_Request" control info containers to generate a RESERVE(RMD-QSPEC): "reverse - T tear" message that is sent towards the QNE Ingress node.
* QNE入口使用接收到的保留区（RMD-QSPEC）的PHR和PDR容器中包含的信息：“反向”，并生成一个域内保留区（RMD-QSPEC）：“转发-T撕裂”消息。此消息包含“PHR_释放请求”和“PDR_释放请求”控制信息。此消息被发送到QNE出口节点。QNE出口节点使用“PHR_Release_Request”和“PDR_Release_Request”控制信息容器中包含的信息来生成一个保留（RMD-QSPEC）：“reverse-T tear”消息，该消息被发送到QNE入口节点。
This section describes the operation of the RMD-QOSM where an RMD intra-domain bidirectional refresh reservation operation is accomplished.
本节描述RMD-QOSM的操作，其中RMD域内双向刷新保留操作完成。
The refresh procedure in the case of an RMD reservation-based method follows a scheme similar to the successful reservation procedure, described in Section 4.6.2.1 and depicted in Figure 17, and how the refresh process of the reserved resources is maintained and is similar to the refresh process used for the intra-domain unidirectional reservations (see Section 4.6.1.3).
基于RMD保留方法的刷新程序遵循与成功保留程序类似的方案，如第4.6.2.1节所述，如图17所示，以及如何维护保留资源的刷新过程，并且与用于域内单向保留的刷新过程类似（参见第4.6.1.3节）。
Note that the RMD traffic class refresh periods used by the bound bidirectional sessions MUST be equal in all QNE Edge and QNE Interior nodes.
请注意，绑定双向会话使用的RMD流量类刷新周期在所有QNE边缘和QNE内部节点中必须相等。
The main differences between the RESERVE(RMD-QSPEC): "forward" message used for the bidirectional refresh procedure and a RESERVE(RMD-QSPEC): "forward" message used for the bidirectional successful reservation procedure are as follows:
保留（RMD-QSPEC）和保留（RMD-QSPEC）之间的主要区别如下：用于双向刷新过程的“转发”消息和用于双向成功保留过程的“转发”消息：
* the value of the Parameter ID of the PHR container is "19", i.e., "PHR_Refresh_Update".
* PHR容器的参数ID的值为“19”，即“PHR\u Refresh\u Update”。
* the value of the Parameter ID of the PDR container is "21", i.e., "PDR_Refresh_Request".
* PDR容器的参数ID的值为“21”，即“PDR_刷新_请求”。
The main differences between the RESERVE(RMD-QSPEC): "reverse" message used for the bidirectional refresh procedure and the RESERVE (RMD-QSPEC): "reverse" message used for the bidirectional successful reservation procedure are as follows:
RESERVE（RMD-QSPEC）与RESERVE（RMD-QSPEC）之间的主要区别在于：用于双向刷新过程的“reverse”消息与用于双向成功保留过程的“reverse”消息如下：
* the value of the Parameter ID of the PHR container is "19", i.e., "PHR_Refresh_Update".
* PHR容器的参数ID的值为“19”，即“PHR\u Refresh\u Update”。
* the value of the Parameter ID of the PDR container is "24", i.e., "PDR_Refresh_Report".
* PDR容器的参数ID的值为“24”，即“PDR_刷新_报告”。
4.6.2.3. Modification of Aggregated Intra-Domain QoS-NSLP Operational Reservation States
4.6.2.3. 修改聚合的域内QoS NSLP操作保留状态
This section describes the operation of the RMD-QOSM where RMD intra-domain bidirectional QoS-NSLP aggregated reservation states have to be modified.
本节描述RMD-QOSM的操作，其中必须修改RMD域内双向QoS NSLP聚合保留状态。
In the case when the QNE Edges maintain, for the RMD QoS Model, QoS-NSLP aggregated reservation states and if such an aggregated reservation has to be modified (see Section 4.3.1), then similar procedures to Section 4.6.1.4 are applied. In particular:
在QNE边缘保持的情况下，对于RMD QoS模型，QoS NSLP聚合保留状态，并且如果必须修改此类聚合保留（参见第4.3.1节），则应用与第4.6.1.4节类似的程序。特别地：
* When the modification request requires an increase of the reserved resources, the QNE Ingress node MUST include the corresponding value into the <Peak Data Rate-1 (p)> field local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired>), which is sent together with "PHR_Resource_Request" control information. If a QNE Edge or QNE Interior node is not able to reserve the number of requested resources, then the "PHR_Resource_Request" associated with the local RMD-QSPEC <TMOD-1> parameter MUST be marked. In this situation, the RMD-specific operation for unsuccessful reservation will be applied (see Section 4.6.2.1). Note that the value of the <PDR Bandwidth> parameter, which is sent within a "PDR_Reservation_Request" container, represents the increase of the reserved resources in the "reverse" direction.
* 当修改请求需要增加保留资源时，QNE入口节点必须将相应值包括在RMD-QOSM<QoS Desired>的<Peak Data Rate-1（p）>字段local RMD-QSPEC<TMOD-1>参数中，该参数与“PHR\u Resource\u request”控制信息一起发送。如果QNE边缘或QNE内部节点无法保留请求的资源数量，则必须标记与本地RMD-QSPEC<TMOD-1>参数关联的“PHR_资源_请求”。在这种情况下，将对未成功预订应用RMD特定操作（见第4.6.2.1节）。请注意，<PDR Bandwidth>参数的值（在“PDR_Reservation_Request”容器中发送）表示保留资源在“反向”方向上的增加。
* When the modification request requires a decrease of the reserved resources, the QNE Ingress node MUST include this value into the <Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired>). Subsequently, an RMD release procedure SHOULD be accomplished (see Section 4.6.2.4). Note that the value of the <PDR Bandwidth> parameter, which is sent within a "PDR_Release_Request" container, represents the decrease of the reserved resources in the "reverse" direction.
* 当修改请求需要减少保留资源时，QNE入口节点必须将该值包括在RMD-QOSM<QoS Desired>的本地RMD-QSPEC<TMOD-1>参数的<Peak Data Rate-1（p）>字段中。随后，应完成RMD发布程序（见第4.6.2.4节）。请注意，<PDR Bandwidth>参数的值（在“PDR\u Release\u Request”容器中发送）表示保留资源在“反向”方向上的减少。
This section describes the operation of the RMD-QOSM, where an RMD intra-domain bidirectional reservation release operation is accomplished. The message sequence diagram used in this procedure is similar to the one used by the successful reservation procedures, described in Section 4.6.2.1 and depicted in Figure 17. However, how the release of the reservation is accomplished is similar to the RMD release procedure used for the intra-domain unidirectional reservations (see Section 4.6.1.5 and Figures 18 and 19).
本节描述RMD-QOSM的操作，其中完成RMD域内双向保留释放操作。本程序中使用的消息序列图类似于第4.6.2.1节所述和图17所示的成功预订程序所使用的消息序列图。然而，保留的释放方式与域内单向保留使用的RMD释放程序类似（参见第4.6.1.5节和图18和图19）。
The main differences between the RESERVE (RMD-QSPEC): "forward" message used for the bidirectional release procedure and a RESERVE (RMD-QSPEC): "forward" message used for the bidirectional successful reservation procedure are as follows:
保留（RMD-QSPEC）和保留（RMD-QSPEC）之间的主要区别如下：用于双向释放过程的“转发”消息和用于双向成功保留过程的“转发”消息：
* the value of the Parameter ID of the PHR container is "18", i.e."PHR_Release_Request";
* PHR容器的参数ID值为“18”，即“PHR_Release_Request”；
* the value of the Parameter ID of the PDR container is "22", i.e., "PDR_Release_Request";
* PDR容器的参数ID的值为“22”，即“PDR_Release_Request”；
The main differences between the RESERVE (RMD-QSPEC): "reverse" message used for the bidirectional release procedure and the RESERVE (RMD-QSPEC): "reverse" message used for the bidirectional successful reservation procedure are as follows:
保留（RMD-QSPEC）和保留（RMD-QSPEC）之间的主要区别在于：用于双向释放过程的“反向”消息和用于双向成功保留过程的“反向”消息如下：
* the value of the Parameter ID of the PHR container is "18", i.e., "PHR_Release_Request";
* PHR容器的参数ID的值为“18”，即“PHR_Release_Request”；
* the PDR container is not included in the RESERVE (RMD-QSPEC): "reverse" message.
* PDR容器不包括在保留（RMD-QSPEC）中：“反向”消息。
This section describes the severe congestion handling operation used in combination with RMD intra-domain bidirectional reservation procedures. This severe congestion handling operation is similar to the one described in Section 4.6.1.6.
本节描述与RMD域内双向预约过程结合使用的严重拥塞处理操作。这种严重拥堵处理操作类似于第4.6.1.6节中所述的操作。
4.6.2.5.1. Severe Congestion Handling by the RMD-QOSM Bidirectional Refresh Procedure
4.6.2.5.1. RMD-QOSM双向刷新过程的严重拥塞处理
This procedure is similar to the severe congestion handling procedure described in Section 4.6.1.6.1. The difference is related to how the refresh procedure is accomplished (see Section 4.6.2.2) and how the flows are terminated (see Section 4.6.2.4).
该程序类似于第4.6.1.6.1节中描述的严重拥堵处理程序。差异与刷新过程的完成方式（见第4.6.2.2节）和流的终止方式（见第4.6.2.4节）有关。
4.6.2.5.2. Severe Congestion Handling by Proportional Data Packet Marking
4.6.2.5.2. 按比例数据包标记的严重拥塞处理
This section describes the severe congestion handling by proportional data packet marking when this is combined with an RMD intra-domain bidirectional reservation procedure. Note that the detection and marking/re-marking functionality described in this section and used by Interior nodes, applies to NSIS-aware but also to NSIS-unaware nodes. This means however, that the "not NSIS-aware" Interior nodes MUST be configured such that they can detect the congestion situations and re-mark packets in the same way as the Interior "NSIS-aware" nodes do.
本节描述了当比例数据包标记与RMD域内双向保留过程相结合时，通过比例数据包标记进行的严重拥塞处理。请注意，本节中描述并由内部节点使用的检测和标记/重新标记功能适用于NSIS感知节点，但也适用于NSIS不感知节点。然而，这意味着，必须配置“非NSIS感知”内部节点，以便它们能够检测拥塞情况并以与内部“NSIS感知”节点相同的方式重新标记分组。
This procedure is similar to the severe congestion handling procedure described in Section 4.6.1.6.2. The main difference is related to the location of the severe congested node, i.e., "forward" or "reverse" path. Note that when a severe congestion situation occurs, e.g., on a forward path, and flows are terminated to solve the severe congestion in forward path, then the reserved bandwidth associated
该程序类似于第4.6.1.6.2节中描述的严重拥堵处理程序。主要区别与严重拥塞节点的位置有关，即“正向”或“反向”路径。请注意，当发生严重拥塞情况时，例如，在前向路径上，并且流被终止以解决前向路径中的严重拥塞时，则与此相关的保留带宽
with the terminated bidirectional flows will also be released. Therefore, a careful selection of the flows that have to be terminated SHOULD take place. An example of such a selection is given in Appendix A.5.
随着终止的双向流也将被释放。因此，应仔细选择必须终止的流。附录a.5中给出了此类选择的示例。
Furthermore, a special case of this operation is associated with the severe congestion situation occurring simultaneously on the forward and reverse paths. An example of this operation is given in Appendix A.6.
此外，这种操作的一种特殊情况与在正向和反向路径上同时发生的严重拥塞情况有关。附录A.6中给出了该操作的示例。
Simulation results associated with these procedures can be found in [DiKa08].
与这些程序相关的模拟结果见[DiKa08]。
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
user| | | | |
data| user | | | |
--->| data | user data | |user data |
|--------------->| | S |
| |--------------------------->S (#marked bytes)
| | | S-------------->|
| | | S(#unmarked bytes)
| | | S-------------->|Term
| | | S |flow?
| | NOTIFY (PDR) S |YES
|<------------------------------------------------------------|
|RESERVE(RMD-QSPEC) | S |
|"forward - T tear" | S |
|--------------->| | RESERVE(RMD-QSPEC):|
| |--------------------------->S"forward - T tear"
| | | S-------------->|
| | | RESERVE(RMD-QSPEC): |
| | | "reverse - T tear" |
| RESERVE(RMD-QSPEC): | |<--------------|
|"reverse - T tear" |<-------------S |
|<-----------------------------| S |
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
user| | | | |
data| user | | | |
--->| data | user data | |user data |
|--------------->| | S |
| |--------------------------->S (#marked bytes)
| | | S-------------->|
| | | S(#unmarked bytes)
| | | S-------------->|Term
| | | S |flow?
| | NOTIFY (PDR) S |YES
|<------------------------------------------------------------|
|RESERVE(RMD-QSPEC) | S |
|"forward - T tear" | S |
|--------------->| | RESERVE(RMD-QSPEC):|
| |--------------------------->S"forward - T tear"
| | | S-------------->|
| | | RESERVE(RMD-QSPEC): |
| | | "reverse - T tear" |
| RESERVE(RMD-QSPEC): | |<--------------|
|"reverse - T tear" |<-------------S |
|<-----------------------------| S |
Figure 20: Intra-domain RMD severe congestion handling for bidirectional reservation (congestion on path QNE(Ingress) towards QNE(Egress))
图20：双向预约的域内RMD严重拥塞处理（路径QNE（入口）到QNE（出口）的拥塞）
Figure 20 shows the scenario in which the severely congested node is located in the "forward" path. The QNE Egress node has to generate an end-to-end NOTIFY (PDR) message. In this way, the QNE Ingress will be able to receive the (#marked and #unmarked) that were measured by the QNE Egress node on the congested "forward" path. Note that in this situation, it is assumed that the "reverse" path is not congested.
图20显示了严重拥塞的节点位于“前向”路径的场景。QNE出口节点必须生成端到端通知（PDR）消息。这样，QNE入口将能够接收QNE出口节点在拥挤的“前向”路径上测量的（#标记和#未标记）。注意，在这种情况下，假设“反向”路径不拥挤。
This scenario is very similar to the severe congestion handling scenario described in Section 4.6.1.6.2 and shown in Figure 14. The difference is related to the release procedure, which is accomplished in the same way as described in Section 4.6.2.4.
该场景非常类似于第4.6.1.6.2节中描述的严重拥塞处理场景，如图14所示。差异与放行程序有关，其完成方式与第4.6.2.4节所述相同。
Figure 21 shows the scenario in which the severely congested node is located in the "reverse" path. Note that in this situation, it is assumed that the "forward" path is not congested. The main difference between this scenario and the scenario shown in Figure 20 is that no end-to-end NOTIFY (PDR) message has to be generated by the QNE Egress node.
图21显示了严重拥塞的节点位于“反向”路径的场景。注意，在这种情况下，假设“前进”路径不拥挤。此场景与图20所示场景之间的主要区别在于QNE出口节点不必生成端到端通知（PDR）消息。
This is because now the severe congestion occurs on the "reverse" path and the QNE Ingress node receives the (#marked and #unmarked) user data passing through the severely congested "reverse" path. The QNE Ingress node will be able to calculate the number of flows that have to be terminated or forwarded in a lower priority queue.
这是因为现在严重拥塞发生在“反向”路径上，QNE入口节点接收通过严重拥塞的“反向”路径的（#标记和#未标记）用户数据。QNE入口节点将能够计算必须在较低优先级队列中终止或转发的流的数量。
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
user| | | | |
data| user | | | |
--->| data | user data | |user data |
|--------------->| | | |
| |--------------------------->|user data |user
| | | |-------------->|data
| | | | |--->
| | | user | |<---
| user data | | data |<--------------|
| (#marked bytes)| S<----------| |
|<--------------------------------S | |
| (#unmarked bytes) S | |
Term|<--------------------------------S | |
Flow? | S | |
YES |RESERVE(RMD-QSPEC): S | |
|"forward - T tear" s | |
|--------------->| RESERVE(RMD-QSPEC): | |
| | "forward - T tear" | |
| |--------------------------->| |
| | S |-------------->|
| | S RESERVE(RMD-QSPEC):
| | S "reverse - T tear" |
| RESERVE(RMD-QSPEC) S |<--------------|
| "reverse - T tear" S<----------| |
|<--------------------------------S | |
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
user| | | | |
data| user | | | |
--->| data | user data | |user data |
|--------------->| | | |
| |--------------------------->|user data |user
| | | |-------------->|data
| | | | |--->
| | | user | |<---
| user data | | data |<--------------|
| (#marked bytes)| S<----------| |
|<--------------------------------S | |
| (#unmarked bytes) S | |
Term|<--------------------------------S | |
Flow? | S | |
YES |RESERVE(RMD-QSPEC): S | |
|"forward - T tear" s | |
|--------------->| RESERVE(RMD-QSPEC): | |
| | "forward - T tear" | |
| |--------------------------->| |
| | S |-------------->|
| | S RESERVE(RMD-QSPEC):
| | S "reverse - T tear" |
| RESERVE(RMD-QSPEC) S |<--------------|
| "reverse - T tear" S<----------| |
|<--------------------------------S | |
Figure 21: Intra-domain RMD severe congestion handling for bidirectional reservation (congestion on path QNE(Egress) towards QNE(Ingress))
图21：双向预约的域内RMD严重拥塞处理（路径QNE（出口）到QNE（入口）的拥塞）
For the flows that have to be terminated, a release procedure, see Section 4.6.2.4, is initiated to release the reserved resources on the "forward" and "reverse" paths.
对于必须终止的流，启动释放程序（见第4.6.2.4节），以释放“正向”和“反向”路径上的保留资源。
4.6.2.6. Admission Control Using Congestion Notification Based on Probing
4.6.2.6. 基于探测的拥塞通知接纳控制
This section describes the admission control scheme that uses the congestion notification function based on probing when RMD intra-domain bidirectional reservations are supported.
本节描述在支持RMD域内双向保留时使用基于探测的拥塞通知功能的接纳控制方案。
QNE(Ingress) Interior QNE (int.) Interior QNE(Egress)
NTLP stateful not NSIS aware not NSIS aware not NSIS aware NTLP stateful
user| | | | |
data| | | | |
--->| | user data | |user data |
|-------------------------------------------->S (#marked bytes)
| | | S-------------->|
| | | S(#unmarked bytes)
| | | S-------------->|
| | | S |
| | RESERVE(re-marked DSCP in GIST)):|
| | | S |
|-------------------------------------------->S |
| | | S-------------->|
| | | S |
| | RESPONSE(unsuccessful INFO-SPEC) |
|<------------------------------------------------------------|
| | | S |
QNE(Ingress) Interior QNE (int.) Interior QNE(Egress)
NTLP stateful not NSIS aware not NSIS aware not NSIS aware NTLP stateful
user| | | | |
data| | | | |
--->| | user data | |user data |
|-------------------------------------------->S (#marked bytes)
| | | S-------------->|
| | | S(#unmarked bytes)
| | | S-------------->|
| | | S |
| | RESERVE(re-marked DSCP in GIST)):|
| | | S |
|-------------------------------------------->S |
| | | S-------------->|
| | | S |
| | RESPONSE(unsuccessful INFO-SPEC) |
|<------------------------------------------------------------|
| | | S |
Figure 22: Intra-domain RMD congestion notification based on probing for bidirectional admission control (congestion on path from QNE(Ingress) towards QNE(Egress))
图22：基于双向准入控制探测的域内RMD拥塞通知（从QNE（入口）到QNE（出口）的路径上的拥塞）
This procedure is similar to the congestion notification for admission control procedure described in Section 4.6.1.7. The main difference is related to the location of the severe congested node, i.e., "forward" path (i.e., path between QNE Ingress towards QNE Egress) or "reverse" path (i.e., path between QNE Egress towards QNE Ingress).
该程序类似于第4.6.1.7节中描述的准入控制程序的拥塞通知。主要区别与严重拥塞节点的位置有关，即“前向”路径（即QNE入口到QNE出口之间的路径）或“反向”路径（即QNE出口到QNE入口之间的路径）。
Figure 22 shows the scenario in which the severely congested node is located in the "forward" path. The functionality of providing admission control is the same as that described in Section 4.6.1.7, Figure 15.
图22显示了严重拥塞的节点位于“前向”路径的场景。提供准入控制的功能与第4.6.1.7节图15所述相同。
Figure 23 shows the scenario in which the congested node is located in the "reverse" path. The probe RESERVE message sent in the "forward" direction will not be affected by the severely congested node, while the <DSCP> value in the IP header of any packet of the "reverse" direction flow and also of the GIST message that carries the probe RESERVE message sent in the "reverse" direction will be re-marked by the congested node. The QNE Ingress is, in this way, notified that a congestion occurred in the network, and therefore it is able to refuse the new initiation of the reservation.
图23显示了拥塞节点位于“反向”路径的场景。在“正向”方向发送的探测保留消息不会受到严重拥塞节点的影响，而“反向”方向流的任何数据包的IP报头中的<DSCP>值以及承载在“反向”方向发送的探测保留消息的GIST消息的值将由拥塞节点重新标记。通过这种方式，QNE入口被通知网络中发生了拥塞，因此它能够拒绝新的预约发起。
Note that the "not NSIS-aware" Interior nodes MUST be configured such that they can detect the congestion/severe congestion situations and re-mark packets in the same way as the Interior "NSIS-aware" nodes do.
请注意，“非NSIS感知”内部节点的配置必须确保它们能够检测拥塞/严重拥塞情况，并以与内部“NSIS感知”节点相同的方式重新标记数据包。
QNE(Ingress) Interior QNE (int.) Interior QNE(Egress)
NTLP stateful not NSIS aware NTLP st.less not NSIS aware NTLP stateful
user| | | | |
data| | | | |
--->| | user data | | |
|-------------------------------------------->|user data |user
| | | |-------------->|data
| | | | |--->
| | | | |user
| | | | |data
| | | | |<---
| S | user data | |
| S user data |<--------------------------|
| user data S<---------------| | |
|<---------------S | | |
| user data S | | |
| (#marked bytes)S | | |
|<---------------S | | |
| S RESERVE(unmarked DSCP in GIST)): |
| S | | |
|----------------S------------------------------------------->|
| S RESERVE(re-marked DSCP in GIST) |
| S<-------------------------------------------|
|<---------------S | | |
QNE(Ingress) Interior QNE (int.) Interior QNE(Egress)
NTLP stateful not NSIS aware NTLP st.less not NSIS aware NTLP stateful
user| | | | |
data| | | | |
--->| | user data | | |
|-------------------------------------------->|user data |user
| | | |-------------->|data
| | | | |--->
| | | | |user
| | | | |data
| | | | |<---
| S | user data | |
| S user data |<--------------------------|
| user data S<---------------| | |
|<---------------S | | |
| user data S | | |
| (#marked bytes)S | | |
|<---------------S | | |
| S RESERVE(unmarked DSCP in GIST)): |
| S | | |
|----------------S------------------------------------------->|
| S RESERVE(re-marked DSCP in GIST) |
| S<-------------------------------------------|
|<---------------S | | |
Figure 23: Intra-domain RMD congestion notification for bidirectional admission control (congestion on path QNE(Egress) towards QNE(Ingress))
图23：用于双向准入控制的域内RMD拥塞通知（路径QNE（出口）到QNE（入口）的拥塞）
During the QSPEC processing, additional errors MAY occur. The way in which these additional errors are handled and notified is specified in [RFC5975] and [RFC5974].
在QSPEC处理过程中，可能会发生其他错误。[RFC5975]和[RFC5974]中规定了处理和通知这些额外错误的方式。
A design goal of the RMD-QOSM protocol is to be "lightweight" in terms of the number of exchanged signaling message and the amount of state established at involved signaling nodes (with and without reduced-state operation). A side effect of this design decision is
RMD-QOSM协议的设计目标是在交换的信令消息的数量和在相关信令节点上建立的状态量（有和没有减少的状态操作）方面“轻量级”。此设计决策的一个副作用是
to introduce second-class signaling nodes, namely QNE Interior nodes, that are restricted in their ability to perform QoS signaling actions. Only the QNE Ingress and the QNE Egress nodes are allowed to initiate certain signaling messages.
引入二级信令节点，即QNE内部节点，其执行QoS信令动作的能力受到限制。仅允许QNE入口和QNE出口节点启动某些信令消息。
Moreover, RMD focuses on an intra-domain deployment only.
此外，RMD只关注域内部署。
The above description has the following implications for security:
上述说明对安全性有以下影响：
1) QNE Ingress and QNE Egress nodes require more security and fault protection than QNE Interior nodes because their uncontrolled behavior has larger implications for the overall stability of the network. QNE Ingress and QNE Egress nodes share a security association and utilize GIST security for protection of their signaling messages. Intra-domain signaling messages used for RMD signaling do not use GIST security, and therefore they do not store security associations.
1) QNE入口和QNE出口节点比QNE内部节点需要更多的安全性和故障保护，因为它们不受控制的行为对网络的整体稳定性有更大的影响。QNE入口和QNE出口节点共享安全关联，并利用GIST安全性保护其信令消息。用于RMD信令的域内信令消息不使用GIST安全性，因此它们不存储安全关联。
2) The focus on intra-domain QoS signaling simplifies trust management and reduces overall complexity. See Section 2 of RFC 4081 for a more detailed discussion about the complete set of communication models available for end-to-end QoS signaling protocols. The security of RMD-QOSM does not depend on Interior nodes, and hence the cryptographic protection of intra-domain messages via GIST is not utilized.
2) 对域内QoS信令的关注简化了信任管理并降低了总体复杂性。有关可用于端到端QoS信令协议的完整通信模型集的更详细讨论，请参阅RFC 4081的第2节。RMD-QOSM的安全性不依赖于内部节点，因此不使用通过GIST对域内消息进行加密保护。
It is important to highlight that RMD always uses the message exchange shown in Figure 24 even if there is no end-to-end signaling session. If the RMD-QOSM is triggered based on an end-to-end (E2E) signaling exchange, then the RESERVE message is created by a node outside the RMD domain and will subsequently travel further (e.g., to the data receiver). Such an exchange is shown in Figure 3. As such, an evaluation of an RMD's security always has to be seen as a combination of the two signaling sessions, (1) and (2) of Figure 24. Note that for the E2E message, such as the RESERVE and the RESPONSE message, a single "hop" refers to the communication between the QNE Ingress and the QNE Egress since QNE Interior nodes do not participate in the exchange.
重要的是要强调，RMD始终使用图24所示的消息交换，即使没有端到端信令会话。如果基于端到端（E2E）信令交换触发RMD-QOSM，则保留消息由RMD域之外的节点创建，并且随后将进一步传播（例如，到数据接收器）。这种交换如图3所示。因此，RMD安全性的评估必须始终被视为图24的两个信令会话（1）和（2）的组合。注意，对于E2E消息，例如保留和响应消息，单个“跃点”指的是QNE入口和QNE出口之间的通信，因为QNE内部节点不参与交换。
QNE QNE QNE QNE
Ingress Interior Interior Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| RESERVE (1) | | |
+--------------------------------------------->|
| RESERVE' (2) | | |
+-------------->| | |
| | RESERVE' | |
| +-------------->| |
| | | RESERVE' |
| | +------------->|
| | | RESPONSE' (2)|
|<---------------------------------------------+
| | | RESPONSE (1) |
|<---------------------------------------------+
QNE QNE QNE QNE
Ingress Interior Interior Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| RESERVE (1) | | |
+--------------------------------------------->|
| RESERVE' (2) | | |
+-------------->| | |
| | RESERVE' | |
| +-------------->| |
| | | RESERVE' |
| | +------------->|
| | | RESPONSE' (2)|
|<---------------------------------------------+
| | | RESPONSE (1) |
|<---------------------------------------------+
Figure 24: RMD message exchange
图24:RMD消息交换
Authorizing quality-of-service reservations is accomplished using the Authentication, Authorization, and Accounting (AAA) framework and the functionality is inherited from the underlying NSIS QoS NSLP, see [RFC5974], and not described again in this document. As a technical solution mechanism, the Diameter QoS application [RFC5866] may be used. The end-to-end reservation request arriving at the Ingress node will trigger the authorization procedure with the backend AAA infrastructure. The end-to-end reservation is typically triggered by a human interaction with a software application, such as a voice-over-IP client when making a call. When authorization is successful then no further user initiated QoS authorization check is expected to be performed within the RMD domain for the intra-domain reservation.
使用身份验证、授权和记帐（AAA）框架完成服务质量保留的授权，该功能继承自基础NSIS QoS NSLP，请参见[RFC5974]，本文档不再描述。作为技术解决方案机制，可以使用Diameter QoS应用程序[RFC5866]。到达入口节点的端到端保留请求将触发后端AAA基础设施的授权过程。端到端预约通常由人工与软件应用程序（如IP语音客户端）的交互在拨打电话时触发。当授权成功时，预计不会在RMD域内为域内保留执行进一步的用户发起的QoS授权检查。
In the RMD-QOSM, the Ingress node constructs both end-to-end and intra-domain signaling messages based on the end-to-end message initiated by the sender end node.
在RMD-QOSM中，入口节点基于发送方端节点发起的端到端消息来构造端到端和域内信令消息。
The Interior nodes within the RMD network ignore the end-to-end signaling message, but they process, modify, and forward the intra-domain signaling messages towards the Egress node. In the meantime, resource reservation states are installed, modified, or deleted at each Interior node along the data path according to the content of each intra-domain signaling message. The Edge nodes of an RMD network are critical components that require strong security protection.
RMD网络内的内部节点忽略端到端信令消息，但它们处理、修改域内信令消息并将其转发到出口节点。同时，根据每个域内信令消息的内容，在沿数据路径的每个内部节点处安装、修改或删除资源保留状态。RMD网络的边缘节点是需要强大安全保护的关键组件。
Therefore, they act as security gateways for incoming and outgoing signaling messages. Moreover, a certain degree of trust has to be placed into Interior nodes within the RMD-QOSM network, such that these nodes can perform signaling message processing and take the necessary actions.
因此，它们充当传入和传出信令消息的安全网关。此外，必须将一定程度的信任置于RMD-QOSM网络内的内部节点中，以便这些节点能够执行信令消息处理并采取必要的行动。
With the RMD-QOSM, we assume that the Ingress and the Egress nodes are not controlled by an adversary and the communication between the Ingress and the Egress nodes is secured using standard GIST security, (see Section 6 of [RFC5971]) mechanisms and experiences integrity, replay, and confidentiality protection.
对于RMD-QOSM，我们假设入口和出口节点不受对手控制，并且入口和出口节点之间的通信使用标准GIST安全机制（参见[RFC5971]第6节）进行保护，并经历完整性、重播和机密性保护。
Note that this only affects messages directly addressed by these two nodes and not any other message that needs to be processed by intermediaries. The <SESSION-ID> object of the end-to-end communication is visible, via GIST, to the Interior nodes. In order to define the security threats that are associated with the RMD-QOSM, we consider that an adversary that may be located inside the RMD domain and could drop, delay, duplicate, inject, or modify signaling packets.
请注意，这只影响由这两个节点直接寻址的消息，而不影响需要由中介处理的任何其他消息。端到端通信的<SESSION-ID>对象通过GIST对内部节点可见。为了定义与RMD QOSM相关联的安全威胁，我们考虑可以位于RMD域内的对手，并且可以丢弃、延迟、复制、注入或修改信令分组。
Depending on the location of the adversary, we speak about an on-path adversary or an off-path adversary, see also RFC 4081 [RFC4081].
根据对手的位置，我们谈论的是路径上的对手或非路径上的对手，另请参见RFC 4081[RFC4081]。
The on-path adversary is a node, which supports RMD-QOSM and is able to observe RMD-QOSM signaling message exchanges.
路径上的对手是支持RMD-QOSM并能够观察RMD-QOSM信令消息交换的节点。
1) Dropping signaling messages
1) 丢弃信令消息
An adversary could drop any signaling messages after receiving them. This will cause a failure of reservation request for new sessions or deletion of resource units (bandwidth) for ongoing sessions due to states timeout.
敌方可以在收到任何信号后丢弃它们。这将导致新会话的预订请求失败，或由于状态超时而删除正在进行的会话的资源单元（带宽）。
It may trigger the Ingress node to retransmit the lost signaling messages. In this scenario, the adversary drops selected signaling messages, for example, intra-domain reserve messages. In the RMD-QOSM, the retransmission mechanism can be provided at the Ingress node to make sure that signaling messages can reach the Egress node. However, the retransmissions triggered by the adversary dropping messages may cause certain problems. Therefore, disabling the use of retransmissions in the RMD-QOSM-aware network is recommended, see also Section 4.6.1.1.1.
它可以触发入口节点重新传输丢失的信令消息。在这种情况下，对手丢弃选定的信令消息，例如域内保留消息。在RMD-QOSM中，可以在入口节点处提供重传机制，以确保信令消息能够到达出口节点。然而，由敌方丢弃消息触发的重传可能会导致某些问题。因此，建议禁用RMD QOSM感知网络中的重传，另见第4.6.1.1.1节。
2) Delaying Signaling Messages
2) 延迟信令消息
Any signaling message could be delayed by an adversary. For example, if RESERVE' messages are delayed over the duration of the refresh period, then the resource units (bandwidth) reserved along the nodes for corresponding sessions will be removed. In this situation, the Ingress node does not receive the RESPONSE within a certain period, and considers that the signaling message has failed, which may cause a retransmission of the "failed" message. The Egress node may distinguish between the two messages, i.e., the delayed message and the retransmitted message, and it could get a proper response.
任何信号消息都可能被敌方延迟。例如，如果RESERVE消息在刷新期间延迟，则沿节点为相应会话保留的资源单元（带宽）将被删除。在这种情况下，入口节点在特定时间段内没有接收到响应，并且认为信令消息已经失败，这可能导致重新传输“失败”消息。出口节点可以区分这两个消息，即延迟消息和重发消息，并且可以得到适当的响应。
However, Interior nodes suffer from this retransmission and they may reserve twice the resource units (bandwidth) requested by the Ingress node.
然而，内部节点遭受此重传，并且它们可能保留入口节点请求的两倍资源单元（带宽）。
3) Replaying Signaling Messages
3) 重放信令消息
An adversary may want to replay signaling messages. It first stores the received messages and decides when to replay these messages and at what rate (packets per second).
对手可能想要重播信号消息。它首先存储接收到的消息，并决定何时重播这些消息以及重播速率（每秒数据包数）。
When the RESERVE' message carried an <RII> object, the Egress will reply with a RESPONSE' message towards the Ingress node. The Ingress node can then detect replays by comparing the value of <RII> in the RESPONSE' messages with the stored value.
当RESERVE'消息携带<RII>对象时，出口将向入口节点回复RESPONSE'消息。然后，入口节点可以通过将响应消息中的<RII>值与存储的值进行比较来检测重播。
4) Injecting Signaling Messages
4) 注入信令消息
Similar to the replay-attack scenario, the adversary may store a part of the information carried by signaling messages, for example, the <RSN> object. When the adversary injects signaling messages, it puts the stored information together with its own generated parameters (RMD-QSPEC <TMOD-1> parameter, <RII>, etc.) into the injected messages and then sends them out. Interior nodes will process these messages by default, reserve the requested resource units (bandwidth) and pass them to downstream nodes.
与重放攻击场景类似，对手可以存储信令消息所携带的部分信息，例如<RSN>对象。当敌方注入信令消息时，它将存储的信息连同自己生成的参数（RMD-QSPEC<TMOD-1>参数，<RII>等）一起放入注入的消息中，然后发送出去。默认情况下，内部节点将处理这些消息，保留请求的资源单元（带宽），并将它们传递给下游节点。
It may happen that the resource units (bandwidth) on the Interior nodes are exhausted if these injected messages consume too much bandwidth.
如果这些注入的消息消耗太多带宽，则内部节点上的资源单元（带宽）可能会耗尽。
5) Modifying Signaling Messages
5) 修改信令消息
On-path adversaries are capable of modifying any part of the
signaling message. For example, the adversary can modify the <M>,
<S>, and <O> parameters of the RMD-QSPEC messages. The Egress node
will then use the SESSION-ID and subsequently the <BOUND-SESSION-ID>
On-path adversaries are capable of modifying any part of the
signaling message. For example, the adversary can modify the <M>,
<S>, and <O> parameters of the RMD-QSPEC messages. The Egress node
will then use the SESSION-ID and subsequently the <BOUND-SESSION-ID>
objects to refer to that flow to be terminated or set to lower priority. It is also possible for the adversary to modify the RMD-QSPEC <TMOD-1> parameter and/or <PHB Class> parameter, which could cause a modification of an amount of the requested resource units (bandwidth) changes.
对象引用要终止或设置为较低优先级的流。敌方也可能修改RMD-QSPEC<TMOD-1>参数和/或<PHB Class>参数，这可能导致修改请求的资源单元（带宽）变化量。
In this case, the adversary is not located on-path and it does not participate in the exchange of RMD-QOSM signaling messages, and therefore is unable to eavesdrop signaling messages. Hence, the adversary does not know valid <RII>s, <RSN>s, and <SESSION-ID>s. Hence, the adversary has to generate new parameters and constructs new signaling messages. Since Interior nodes operate in reduced-state mode, injected signaling messages are treated as new once, which causes Interior nodes to allocate additional reservation state.
在这种情况下，对手不位于路径上，并且不参与RMD-QOSM信令消息的交换，因此无法窃听信令消息。因此，对手不知道有效的<RII>s、<RSN>s和<SESSION-ID>s。因此，对手必须生成新的参数并构造新的信令消息。由于内部节点在简化状态模式下工作，因此注入的信令消息被视为新消息，这导致内部节点分配额外的保留状态。
The following security requirements are set as goals for the intra-domain communication, namely:
以下安全要求被设置为域内通信的目标，即：
* Nodes, which are never supposed to participate in the NSIS signaling exchange, must not interfere with QNE Interior nodes. Off-path nodes (off-path with regard to the path taken by a particular signaling message exchange) must not be able to interfere with other on-path signaling nodes.
* 不应参与NSIS信令交换的节点不得干扰QNE内部节点。非路径节点（与特定信令消息交换所采用的路径相关的非路径）不得干扰其他路径上信令节点。
* The actions allowed by a QNE Interior node should be minimal (i.e., only those specified by the RMD-QOSM). For example, only the QNE Ingress and the QNE Egress nodes are allowed to initiate certain signaling messages. QNE Interior nodes are, for example, allowed to modify certain signaling message payloads.
* QNE内部节点允许的操作应最小（即，仅RMD-QOSM指定的操作）。例如，仅允许QNE入口和QNE出口节点启动某些信令消息。例如，QNE内部节点被允许修改某些信令消息有效载荷。
Note that the term "interfere" refers to all sorts of security threats, such as denial-of-service, spoofing, replay, signaling message injection, etc.
请注意，术语“干扰”指各种安全威胁，如拒绝服务、欺骗、重播、信令消息注入等。
An important security mechanism that was built into RMD-QOSM was the ability to tie the end-to-end RESERVE and the RESERVE' messages together using the BOUND-SESSION-ID and to allow the Ingress node to match the RESERVE' with the RESPONSE' by using the <RII>. These mechanisms enable the Edge nodes to detect unexpected signaling messages.
RMD-QOSM中内置的一个重要安全机制是能够使用绑定会话ID将端到端保留和保留消息绑定在一起，并允许入口节点使用<RII>将保留与响应匹配。这些机制使边缘节点能够检测意外的信令消息。
We assume that the RESERVE/RESPONSE is sent with hop-by-hop channel security provided by GIST and protected between the QNE Ingress and the QNE Egress. GIST security mechanisms MUST be used to offer authentication, integrity, and replay protection. Furthermore, encryption MUST be used to prevent an adversary located along the path of the RESERVE message from learning information about the session that can later be used to inject a RESERVE' message.
我们假设保留/响应是通过GIST提供的逐跳信道安全性发送的，并且在QNE入口和QNE出口之间受到保护。GIST安全机制必须用于提供身份验证、完整性和重播保护。此外，必须使用加密来防止位于保留消息路径上的对手了解有关会话的信息，这些信息稍后可用于注入保留消息。
The following messages need to be mapped to each other to make sure that the occurrence of one message is not without the other:
以下消息需要相互映射，以确保一条消息的出现并非没有另一条消息：
a) the RESERVE and the RESERVE' relate to each other at the QNE Egress; and
a) 保护区和保护区在QNE出口处相互关联；和
b) the RESPONSE and the RESERVE relate to each other at the QNE Ingress; and
b) 在QNE入口处，响应和保留相互关联；和
c) the RESERVE' and the RESPONSE' relate to each other. The <RII> is carried in the RESERVE' message and the RESPONSE' message that is generated by the QNE Egress node contains the same <RII> as the RESERVE'. The <RII> can be used by the QNE Ingress to match the RESERVE' with the RESPONSE'. The QNE Egress is able to determine whether the RESERVE' was created by the QNE Ingress node since the intra-domain session, which sent the RESERVE', is bound to an end-to-end session via the <BOUND-SESSION-ID> value included in the intra-domain QoS-NSLP operational state maintained at the QNE Egress.
c) “保留”和“响应”是相互关联的。<RII>在RESERVE'消息中携带，而QNE出口节点生成的响应'消息包含与RESERVE相同的<RII>。QNE入口可以使用<RII>来匹配保留“与响应”。QNE出口能够确定QNE入口节点是否创建了保留，因为发送保留的域内会话通过QNE出口处维护的域内QoS NSLP操作状态中包含的<bound-session-ID>值绑定到端到端会话。
The RESERVE and the RESERVE' message are tied together using the BOUND-SESSION-ID(s) maintained by the intra-domain and end-to-end QoS-NSLP operational states maintained at the QNE Edges (see Sections 4.3.1, 4.3.2, and 4.3.3). Hence, there cannot be a RESERVE' without a corresponding RESERVE. The SESSION-ID can fulfill this purpose quite well if the aim is to provide protection against off-path adversaries that do not see the SESSION-ID carried in the RESERVE and the RESERVE' messages.
使用域内维护的绑定会话ID和QNE边缘维护的端到端QoS NSLP操作状态（参见第4.3.1、4.3.2和4.3.3节），将保留和保留消息绑定在一起。因此，没有相应的储备，就不可能有储备。如果会话ID的目的是提供保护，以防在预备队和预备队的消息中看不到会话ID的非路径对手，则会话ID可以很好地实现这一目的。
If, however, the path changes (due to rerouting or due to mobility), then an adversary could inject RESERVE' messages (with a previously seen SESSION-ID) and could potentially cause harm.
但是，如果路径发生变化（由于重新路由或移动），则敌方可能会注入备用消息（使用以前看到的会话ID），并可能造成伤害。
An off-path adversary can, of course, create RESERVE' messages that cause intermediate nodes to create some state (and cause other actions) but the message would finally hit the QNE Egress node. The QNE Egress node would then be able to determine that there is something going wrong and generate an error message.
当然，非路径对手可以创建保留消息，导致中间节点创建某些状态（并导致其他操作），但该消息最终会命中QNE出口节点。然后，QNE出口节点将能够确定出现了问题并生成错误消息。
The severe congestion handling can be triggered by intermediate nodes (unlike other messages). In many cases, however, intermediate nodes experiencing congestion use refresh messages modify the <S> and <O> parameters of the message. These messages are still initiated by the QNE Ingress node and carry the SESSION-ID. The QNE Egress node will use the SESSION-ID and subsequently the BOUND-SESSION-ID, maintained by the intra-domain QoS-NSLP operational state, to refer to a flow that might be terminated. The aspect of intermediate nodes initiating messages for severe congestion handling is for further study.
严重拥塞处理可由中间节点触发（与其他消息不同）。然而，在许多情况下，遇到拥塞的中间节点使用刷新消息修改消息的<S>和<O>参数。这些消息仍然由QNE入口节点发起并携带会话ID。QNE出口节点将使用会话ID以及随后由域内QoS NSLP操作状态维护的绑定会话ID来引用可能终止的流。中间节点发起严重拥塞处理消息的方面有待进一步研究。
During the refresh procedure, a RESERVE' creates a RESPONSE', see Figure 25. The <RII> is carried in the RESERVE' message and the RESPONSE' message that is generated by the QNE Egress node contains the same <RII> as the RESERVE'.
在刷新过程中，保留“创建响应”，见图25。<RII>在RESERVE'消息中携带，而QNE出口节点生成的响应'消息包含与RESERVE相同的<RII>。
The <RII> can be used by the QNE Ingress to match the RESERVE' with the RESPONSE'.
QNE入口可以使用<RII>来匹配保留“与响应”。
A further aspect is marking of data traffic. Data packets can be modified by an intermediary without any relationship to a signaling session (and a SESSION-ID). The problem appears if an off-path adversary injects spoofed data packets.
另一个方面是数据通信量的标记。数据包可以由中介修改，而与信令会话（和会话ID）没有任何关系。如果非路径对手注入伪造的数据包，问题就会出现。
QNE Ingress QNE Interior QNE Interior QNE Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| REFRESH RESERVE' | |
+-------------->| REFRESH RESERVE' |
| (+RII) +-------------->| REFRESH RESERVE'
| | (+RII) +------------->|
| | | (+RII) |
| | | |
| | | REFRESH |
| | | RESPONSE'|
|<---------------------------------------------+
| | | (+RII) |
QNE Ingress QNE Interior QNE Interior QNE Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| REFRESH RESERVE' | |
+-------------->| REFRESH RESERVE' |
| (+RII) +-------------->| REFRESH RESERVE'
| | (+RII) +------------->|
| | | (+RII) |
| | | |
| | | REFRESH |
| | | RESPONSE'|
|<---------------------------------------------+
| | | (+RII) |
Figure 25: RMD REFRESH message exchange
图25:RMD刷新消息交换
The adversary thereby needs to spoof data packets that relate to the flow identifier of an existing end-to-end reservation that SHOULD be terminated. Therefore, the question arises how an off-path adversary SHOULD create a data packet that matches an existing flow identifier (if a 5-tuple is used). Hence, this might not turn out to be simple for an adversary unless we assume the previously mentioned mobility/rerouting case where the path through the network changes and the set of nodes that are along a path changes over time.
因此，对手需要欺骗与应终止的现有端到端保留的流标识符相关的数据包。因此，问题就产生了，非路径对手应该如何创建与现有流标识符匹配的数据包（如果使用5元组）。因此，这对于对手来说可能并不简单，除非我们假设前面提到的移动/重新路由情况，其中通过网络的路径发生变化，并且沿着路径的节点集随着时间的推移而变化。
This section defines additional codepoint assignments in the QSPEC Parameter ID registry, in accordance with BCP 26 [RFC5226].
根据BCP 26[RFC5226]，本节定义了QSPEC参数ID注册表中的其他代码点分配。
This document specifies the following QSPEC containers in the QSPEC Parameter ID registry created in [RFC5975]:
本文档在[RFC5975]中创建的QSPEC参数ID注册表中指定以下QSPEC容器：
<PHR_Resource_Request> (Section 4.1.2 above, ID=17)
<PHR_Resource_Request> (Section 4.1.2 above, ID=17)
<PHR_Release_Request> (Section 4.1.2 above, ID=18)
<PHR_Release_Request> (Section 4.1.2 above, ID=18)
<PHR_Refresh_Update> (Section 4.1.2 above, ID=19)
<PHR_Refresh_Update> (Section 4.1.2 above, ID=19)
<PDR_Reservation_Request> (Section 4.1.3 above, ID=20)
<PDR_Reservation_Request> (Section 4.1.3 above, ID=20)
<PDR_Refresh_Request> (Section 4.1.3 above, ID=21)
<PDR_Refresh_Request> (Section 4.1.3 above, ID=21)
<PDR_Release_Request> (Section 4.1.3 above, ID=22)
<PDR_Release_Request> (Section 4.1.3 above, ID=22)
<PDR_Reservation_Report> (Section 4.1.3 above, ID=23)
<PDR_Reservation_Report> (Section 4.1.3 above, ID=23)
<PDR_Refresh_Report> (Section 4.1.3 above, ID=24)
<PDR_Refresh_Report> (Section 4.1.3 above, ID=24)
<PDR_Release_Report> (Section 4.1.3 above, ID=25)
<PDR_Release_Report> (Section 4.1.3 above, ID=25)
<PDR_Congestion_Report> (Section 4.1.3 above, ID=26)
<PDR_Congestion_Report> (Section 4.1.3 above, ID=26)
The authors express their acknowledgement to people who have worked on the RMD concept: Z. Turanyi, R. Szabo, G. Pongracz, A. Marquetant, O. Pop, V. Rexhepi, G. Heijenk, D. Partain, M. Jacobsson, S. Oosthoek, P. Wallentin, P. Goering, A. Stienstra, M. de Kogel, M. Zoumaro-Djayoon, M. Swanink, R. Klaver G. Stokkink, J. W. van Houwelingen, D. Dimitrova, T. Sealy, H. Chang, and J. de Waal.
作者对从事RMD概念研究的人员表示感谢：Z.图兰尼、R.萨博、G.庞格拉茨、A.马奎坦、O.波普、V.雷克斯皮、G.海耶克、D.帕坦、M.雅各布森、S.奥斯托克、P.瓦伦廷、P.戈林、A.斯蒂恩斯特拉、M.德科格尔、M.佐马罗·杰扬、M.斯瓦宁克、R.克拉弗·G.斯托金、J.W.范·霍韦林根，迪米特罗娃、T.西利、张学良和J.德瓦尔。
[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月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signaling Transport", RFC 5971, October 2010.
[RFC5971]Schulzrinne，H.和R.Hancock，“要点：通用互联网信令传输”，RFC 59712010年10月。
[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月。
[RFC5975] Ash, G., Bader, A., Kappler C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.
[RFC5975]Ash，G.，Bader，A.，Kappler C.，和D.Oran，“服务质量NSIS信令层协议（NSLP）的QSPEC模板”，RFC 59752010年10月。
[AdCa03] Adler, M., Cai, J.-Y., Shapiro, J. K., Towsley, D., "Estimation of congestion price using probabilistic packet marking", Proc. IEEE INFOCOM, pp. 2068-2078, 2003.
[AdCa03]Adler，M.，Cai，J.-Y.，Shapiro，J.K.，Towsley，D.，“使用概率分组标记估计拥塞价格”，Proc。IEEE INFOCOM，第2068-2078页，2003年。
[AnHa06] Lachlan L. H. Andrew and Stephen V. Hanly, "The Estimation Error of Adaptive Deterministic Packet Marking", 44th Annual Allerton Conference on Communication, Control and Computing, 2006.
[AnHa06]Lachlan L.H.Andrew和Stephen V.Hanly，“自适应确定性数据包标记的估计误差”，第44届Allerton年度通信、控制和计算会议，2006年。
[AtLi01] Athuraliya, S., Li, V. H., Low, S. H., Yin, Q., "REM: active queue management", IEEE Network, vol. 15, pp. 48-53, May/June 2001.
[AtLi01]Athuraliya，S.，Li，V.H.，Low，S.H.，Yin，Q.，“REM：主动队列管理”，IEEE网络，第15卷，第48-53页，2001年5月/6月。
[Chan07] H. Chang, "Security support in RMD-QOSM", Masters thesis, University of Twente, 2007.
硕士学位论文，屯特大学硕士论文，2007。
[CsTa05] Csaszar, A., Takacs, A., Szabo, R., Henk, T., "Resilient Reduced-State Resource Reservation", Journal of Communication and Networks, Vol. 7, No. 4, December 2005.
[CsTa05]Csaszar，A.，Takacs，A.，Szabo，R.，Henk，T.，“弹性减少状态资源保留”，《通信与网络杂志》，第7卷，第4期，2005年12月。
[DiKa08] Dimitrova, D., Karagiannis, G., de Boer, P.-T., "Severe congestion handling approaches in NSIS RMD domains with bi-directional reservations", Journal of Computer Communications, Elsevier, vol. 31, pp. 3153-3162, 2008.
[DiKa08]Dimitrova，D.，Karagiannis，G.，de Boer，P.-T.，“具有双向保留的NSIS RMD域中的严重拥塞处理方法”，计算机通信杂志，Elsevier，第31卷，第3153-3162页，2008年。
[JaSh97] Jamin, S., Shenker, S., Danzig, P., "Comparison of Measurement-based Admission Control Algorithms for Controlled-Load Service", Proceedings IEEE Infocom '97, Kobe, Japan, April 1997.
[JaSh97]Jamin，S.，Shenker，S.，Danzig，P.，“受控负载服务中基于测量的接纳控制算法的比较”，IEEE Infocom'97会议录，日本神户，1997年4月。
[GrTs03] Grossglauser, M., Tse, D.N.C, "A Time-Scale Decomposition Approach to Measurement-Based Admission Control", IEEE/ACM Transactions on Networking, Vol. 11, No. 4, August 2003.
[GrTs03]Grossglauser，M.，Tse，D.N.C.“基于测量的准入控制的时间尺度分解方法”，IEEE/ACM网络交易，第11卷，第4期，2003年8月。
[Part94] C. Partridge, Gigabit Networking, Addison Wesley Publishers (1994).
[Part94]C.帕特里奇，《千兆网络》，艾迪生·韦斯利出版社（1994年）。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]Braden，R.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC 16331994年6月。
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[RFC2215]Shenker，S.和J.Wroclawski，“综合业务网元的一般特征参数”，RFC 2215，1997年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2638] Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999.
[RFC2638]Nichols，K.，Jacobson，V.，和L.Zhang，“互联网的两位区分服务架构”，RFC 2638，1999年7月。
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[RFC2998]Bernet，Y.，Ford，P.，Yavatkar，R.，Baker，F.，Zhang，L.，Speer，M.，Braden，R.，Davie，B.，Wroclawski，J.，和E.Felstaine，“区分服务网络上的综合服务运营框架”，RFC 2998，2000年11月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 3175，2001年9月。
[RFC3726] Brunner, M., Ed., "Requirements for Signaling Protocols", RFC 3726, April 2004.
[RFC3726]Brunner，M.，Ed.，“信令协议的要求”，RFC 3726，2004年4月。
[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月。
[RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
[RFC4127]Le Faucheur，F.，Ed.“区分服务感知MPLS流量工程的俄罗斯玩偶带宽约束模型”，RFC 4127，2005年6月。
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4081]Tschofenig，H.和D.Kroeselberg，“信令（NSIS）下一步的安全威胁”，RFC 40812005年6月。
[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月。
[RFC5866] Sun, D., Ed., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, Ed., "Diameter Quality-of-Service Application", RFC 5866, May 2010.
[RFC5866]Sun，D.，Ed.，McCann，P.，Tschofenig，H.，Tsou，T.，Doria，A.，和G.Zorn，Ed.“直径服务质量应用”，RFC 5866，2010年5月。
[RFC5978] Manner, J., Bless, R., Loughney, J., and E. Davies, Ed., "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010.
[RFC5978]Way，J.，Bless，R.，Loughney，J.，和E.Davies，Ed.，“使用和扩展NSIS协议系列”，RFC 5978，2010年10月。
[RMD1] Westberg, L., et al., "Resource Management in Diffserv (RMD): A Functionality and Performance Behavior Overview", IFIP PfHSN 2002.
[RMD1]Westberg，L.，等人，“区分服务中的资源管理（RMD）：功能和性能行为概述”，IFIP PfHSN 2002。
[RMD2] G. Karagiannis, et al., "RMD - a lightweight application of NSIS" Networks 2004, Vienna, Austria.
[RMD2]G.Karagiannis等人，“RMD-NSIS的轻量级应用”Networks 2004，奥地利维也纳。
[RMD3] Marquetant A., Pop O., Szabo R., Dinnyes G., Turanyi Z., "Novel Enhancements to Load Control - A Soft-State, Lightweight Admission Control Protocol", Proc. of the 2nd Int. Workshop on Quality of Future Internet Services, Coimbra, Portugal, Sept 24-26, 2001, pp. 82-96.
[RMD3]Marquetant A.，Pop O.，Szabo R.，Dinnyes G.，Turanyi Z.，“负载控制的新增强-软状态，轻量级准入控制协议”，Proc。2001年9月24日至26日在葡萄牙科英布拉举行的第二届国际互联网服务质量研讨会，第82-96页。
[RMD4] A. Csaszar et al., "Severe congestion handling with resource management in diffserv on demand", Networking 2002.
[RMD4]A.Csaszar等人，“diffserv on demand中使用资源管理的严重拥塞处理”，网络2002年。
[TaCh99] P. P. Tang, T-Y Charles Tai, "Network Traffic Characterization Using Token Bucket Model", IEEE Infocom 1999, The Conference on Computer Communications, no. 1, March 1999, pp. 51-62.
[TaCh99]Tang，T-Y Charles Tai，“使用令牌桶模型的网络流量表征”，IEEE Infocom 1999，计算机通信会议，第1期，1999年3月，第51-62页。
[ThCo04] Thommes, R. W., Coates, M. J., "Deterministic packet marking for congestion packet estimation" Proc. IEEE Infocom, 2004.
[ThCo04]Thommes，R.W.，Coates，M.J.，“拥塞数据包估计的确定性数据包标记”程序。IEEE信息网，2004年。
A.1. Example of a Re-Marking Operation during Severe Congestion in the Interior Nodes
A.1. 内部节点严重拥塞期间重新标记操作的示例
This appendix describes an example of a re-marking operation during severe congestion in the Interior nodes.
本附录描述了内部节点严重拥塞期间重新标记操作的示例。
Per supported PHB, the Interior node can support the operation states depicted in Figure 26, when the per-flow congestion notification based on probing signaling scheme is used in combination with this severe congestion type. Figure 27 depicts the same functionality when the per-flow congestion notification based on probing scheme is not used in combination with the severe congestion scheme. The description given in this and the following appendices, focuses on the situation where: (1) the "notified DSCP" marking is used in congestion notification state, and (2) the "encoded DSCP" and "affected DSCP" markings are used in severe congestion state. In this case, the "notified DSCP" marking is used during the congestion notification state to mark all packets passing through an Interior node that operates in the congestion notification state. In this way, and in combination with probing, a flow-based ECMP solution can be provided for the congestion notification state. The "encoded DSCP" marking is used to encode and signal the excess rate, measured at Interior nodes, to the Egress nodes. The "affected DSCP" marking is used to mark all packets that are passing through a severe congested node and are not "encoded DSCP" marked.
根据支持的PHB，当基于探测信令方案的每流拥塞通知与这种严重拥塞类型结合使用时，内部节点可以支持图26所示的操作状态。图27描述了基于探测方案的每流拥塞通知未与严重拥塞方案结合使用时的相同功能。本附录和以下附录中给出的描述主要关注以下情况：（1）在拥塞通知状态下使用“通知的DSCP”标记，（2）“编码的DSCP”和“受影响的DSCP”标记在严重拥塞状态下使用。在这种情况下，在拥塞通知状态期间使用“通知的DSCP”标记来标记通过在拥塞通知状态下运行的内部节点的所有分组。通过这种方式，并结合探测，可以为拥塞通知状态提供基于流的ECMP解决方案。“编码的DSCP”标记用于编码并向出口节点发送在内部节点处测量的超额速率信号。“受影响的DSCP”标记用于标记通过严重拥塞节点且未标记“编码的DSCP”的所有数据包。
Another possible situation could be derived in which both congestion notification and severe congestion state use the "encoded DSCP" marking, without using the "notified DSCP" marking. The "affected DSCP" marking is used to mark all packets that pass through an Interior node that is in severe congestion state and are not "encoded DSCP" marked. In addition, the probe packet that is carried by an intra-domain RESERVE message and pass through Interior nodes SHOULD be "encoded DSCP" marked if the Interior node is in congestion notification or severe congestion states. Otherwise, the probe packet will remain unmarked. In this way, an ECMP solution can be provided for both congestion notification and severe congestion states. The"encoded DSCP" packets signal an excess rate that is not only associated with Interior nodes that are in severe congestion state, but also with Interior nodes that are in congestion notification state. The algorithm at the Interior node is similar to the algorithm described in the following appendix sections. However, this method is not described in detail in this example.
另一种可能的情况是，拥塞通知和严重拥塞状态都使用“编码的DSCP”标记，而不使用“通知的DSCP”标记。“受影响的DSCP”标记用于标记通过处于严重拥塞状态且未标记“编码的DSCP”的内部节点的所有数据包。此外，如果内部节点处于拥塞通知或严重拥塞状态，则由域内保留消息携带并通过内部节点的探测包应标记为“编码DSCP”。否则，探测数据包将保持未标记状态。通过这种方式，可以为拥塞通知和严重拥塞状态提供ECMP解决方案。“编码的DSCP”数据包发出超额速率信号，该速率不仅与处于严重拥塞状态的内部节点相关，而且与处于拥塞通知状态的内部节点相关。内部节点的算法类似于以下附录章节中描述的算法。然而，该示例中未详细描述该方法。
---------------------------------------------
| event B |
| V
---------- ------------- ----------
| Normal | event A | Congestion | event B | Severe |
| state |---------->| notification|-------->|congestion|
| | | state | | state |
---------- ------------- ----------
^ ^ | |
| | event C | |
| ----------------------- |
| event D |
------------------------------------------------
---------------------------------------------
| event B |
| V
---------- ------------- ----------
| Normal | event A | Congestion | event B | Severe |
| state |---------->| notification|-------->|congestion|
| | | state | | state |
---------- ------------- ----------
^ ^ | |
| | event C | |
| ----------------------- |
| event D |
------------------------------------------------
Figure 26: States of operation, severe congestion combined with congestion notification based on probing
图26：运行状态、严重拥塞和基于探测的拥塞通知
---------- -------------
| Normal | event B | Severe |
| state |-------------->| congestion |
| | | state |
---------- -------------
^ |
| event E |
---------------------------
---------- -------------
| Normal | event B | Severe |
| state |-------------->| congestion |
| | | state |
---------- -------------
^ |
| event E |
---------------------------
Figure 27: States of operation, severe congestion without congestion notification based on probing
图27：运行状态，严重拥塞，无基于探测的拥塞通知
The terms used in Figures 26 and 27 are:
图26和27中使用的术语为：
Normal state: represents the normal operation conditions of the node, i.e., no congestion.
正常状态：表示节点的正常运行状态，即无拥塞。
Severe congestion state: represents the state in which the Interior node is severely congested related to a certain PHB. It is important to emphasize that one of the targets of the severe congestion state solution to change the severe congestion state behavior directly to the normal state.
严重拥塞状态：表示与某个PHB相关的内部节点严重拥塞的状态。需要强调的是，严重拥塞状态解决方案的目标之一是将严重拥塞状态行为直接改变为正常状态。
Congestion notification: state in which the load is relatively high, close to the level when congestion can occur.
拥塞通知：负载相对较高的状态，接近可能发生拥塞时的水平。
event A: this event occurs when the incoming PHB rate is higher than the "congestion notification detection" threshold and lower than the "severe congestion detection". This threshold is used by the congestion notification based on probing scheme, see Sections 4.6.1.7 and 4.6.2.6.
事件A：当传入PHB速率高于“拥塞通知检测”阈值且低于“严重拥塞检测”时，会发生此事件。该阈值由基于探测方案的拥塞通知使用，见第4.6.1.7节和第4.6.2.6节。
event B: this event occurs when the incoming PHB rate is higher than the "severe congestion detection" threshold.
事件B：当传入PHB速率高于“严重拥塞检测”阈值时，会发生此事件。
event C: this event occurs when the incoming PHB rate is lower than or equal to the "congestion notification detection" threshold.
事件C：当传入PHB速率低于或等于“拥塞通知检测”阈值时，发生此事件。
event D: this event occurs when the incoming PHB rate is lower than or equal to the "severe_congestion_restoration" threshold. It is important to emphasize that this even supports one of the targets of the severe congestion state solution to change the severe congestion state behavior directly to the normal state.
事件D：当传入PHB速率低于或等于“严重拥塞恢复”阈值时，发生此事件。需要强调的是，这甚至支持严重拥塞状态解决方案的一个目标，即将严重拥塞状态行为直接更改为正常状态。
event E: this event occurs when the incoming PHB rate is lower than or equal to the "severe congestion restoration" threshold.
事件E：当传入PHB速率低于或等于“严重拥塞恢复”阈值时，发生此事件。
Note that the "severe congestion detection", "severe congestion restoration" and admission thresholds SHOULD be higher than the "congestion notification detection" threshold, i.e., "severe congestion detection" > "congestion notification detection" and "severe congestion restoration" > "congestion notification detection".
请注意，“严重拥塞检测”、“严重拥塞恢复”和准入阈值应高于“拥塞通知检测”阈值，即“严重拥塞检测”>“拥塞通知检测”和“严重拥塞恢复”>“拥塞通知检测”。
Furthermore, the "severe congestion detection" threshold SHOULD be higher than or equal to the admission threshold that is used by the reservation-based and NSIS measurement-based signaling schemes. "severe congestion detection" >= admission threshold.
此外，“严重拥塞检测”阈值应高于或等于基于保留和基于NSIS测量的信令方案所使用的接纳阈值。“严重拥塞检测”>=接纳阈值。
Moreover, the "severe congestion restoration" threshold SHOULD be lower than or equal to the "severe congestion detection" threshold that is used by the reservation-based and NSIS measurement-based signaling schemes, that is:
此外，“严重拥塞恢复”阈值应低于或等于基于保留和基于NSIS测量的信令方案使用的“严重拥塞检测”阈值，即：
"severe congestion restoration" <= "severe congestion detection"
“严重拥塞恢复”<=“严重拥塞检测”
During severe congestion, the Interior node calculates, per traffic class (PHB), the incoming rate that is above the "severe congestion restoration" threshold, denoted as signaled_overload_rate, in the following way:
在严重拥塞期间，内部节点按照每个通信量等级（PHB）计算高于“严重拥塞恢复”阈值的传入速率，表示为信号_过载_速率，如下所示：
* A severe congested Interior node SHOULD take into account that packets might be dropped. Therefore, before queuing and eventually dropping packets, the Interior node SHOULD count the total number of unmarked and re-marked bytes received by the severe congested node, denote this number as total_received_bytes. Note that there are situations in which more than one Interior node in the same path become severely congested. Therefore, any Interior node located behind a severely congested node MAY receive marked bytes.
* 严重拥塞的内部节点应考虑数据包可能被丢弃。因此，在排队并最终丢弃数据包之前，内部节点应统计严重拥塞节点接收到的未标记和重新标记字节的总数，将该数目表示为接收到的总字节数。请注意，在某些情况下，同一路径中的多个内部节点会变得严重拥挤。因此，位于严重拥塞节点后面的任何内部节点都可能接收标记字节。
When the "severe congestion detection" threshold per PHB is set equal to the maximum capacity allocated to one PHB used by the RMD-QOSM, it means that if the maximum capacity associated to a PHB is fully utilized and a packet belonging to this PHB arrives, then it is assumed that the Interior node will not forward this packet downstream.
当每个PHB的“严重拥塞检测”阈值被设置为等于分配给RMD-QOSM使用的一个PHB的最大容量时，这意味着如果与PHB相关联的最大容量被充分利用并且属于该PHB的分组到达，则假定内部节点将不向下游转发该分组。
In other words, this packet will either be dropped or set to another PHB. Furthermore, this also means that after the severe congestion situation is solved, then the ongoing flows will be able to send their associated packets up to a total rate equal to the maximum capacity associated with the PHB. Therefore, when more than one Interior node located on the same path will be severely congested and when the Interior node receives "encoded DSCP" marked packets, it means that an Interior node located upstream is also severely congested.
换句话说，该数据包将被丢弃或设置为另一个PHB。此外，这还意味着在严重拥塞情况得到解决之后，正在进行的流将能够以等于与PHB相关联的最大容量的总速率发送其相关联的分组。因此，当位于同一路径上的多个内部节点将严重拥塞并且当内部节点接收到“编码的DSCP”标记的分组时，这意味着位于上游的内部节点也严重拥塞。
When the "severe congestion detection" threshold per PHB is set equal to the maximum capacity allocated to one PHB, then this Interior node MUST forward the "encoded DSCP" marked packets and it SHOULD NOT consider these packets during its local re-marking process. In other words, the Egress should see the excess rates encoded by the different severely congested Interior nodes as independent, and therefore, these independent excess rates will be added.
当每个PHB的“严重拥塞检测”阈值设置为等于分配给一个PHB的最大容量时，该内部节点必须转发“编码的DSCP”标记的分组，并且在其本地重新标记过程中不应该考虑这些分组。换句话说，出口应将不同严重拥挤内部节点编码的超额率视为独立的，因此，将添加这些独立超额率。
When the "severe congestion detection" threshold per PHB is not set equal to the maximum capacity allocated to one PHB, this means that after the severe congestion situation is solved, the ongoing flows will not be able to send their associated packets up to a total rate equal to the maximum capacity associated with the PHB, but only up to the "severe_congestion_threshold". When more than one Interior node located on the same communication path is severely congested and when one of these Interior node receives "encoded_DSCP" marked packets, this Interior node SHOULD NOT mark unmarked, i.e., either "original DSCP" or "affected DSCP" or "notified DSCP" encoded packets, up to a rate equal to the difference between the maximum PHB capacity and the "severe congestion threshold", when the incoming "encoded DSCP" marked packets are already able to signal this difference. In this case, the "severe congestion threshold" SHOULD be configured in all Interior nodes, which are located in the RMD domain, and equal to:
当每个PHB的“严重拥塞检测”阈值未设置为等于分配给一个PHB的最大容量时，这意味着在严重拥塞情况得到解决后，正在进行的流将无法以等于与PHB相关联的最大容量的总速率发送其相关包，而只能以最大速率发送“严重\u拥塞\u阈值”。当位于同一通信路径上的多个内部节点严重拥塞且其中一个内部节点接收到“编码的\u DSCP”标记的数据包时，该内部节点不应标记为未标记，即“原始DSCP”或“受影响的DSCP”或“通知的DSCP”“编码数据包，最高速率等于最大PHB容量和“严重拥塞阈值”之间的差值，此时传入的“编码DSCP”标记数据包已经能够发出此差值的信号。在这种情况下，应在位于RMD域中的所有内部节点中配置“严重拥塞阈值”，其等于：
"severe_congestion_threshold" = Maximum PHB capacity - threshold_offset_rate
“严重拥挤\u阈值”=最大PHB容量-阈值\u偏移率
The threshold_offset_rate represents rate and SHOULD have the same value in all Interior nodes.
阈值偏移率表示速率，在所有内部节点中应具有相同的值。
* before queuing and eventually dropping the packets, at the end of each measurement interval of T seconds, calculate the current estimated overloaded rate, say measured_overload_rate, by using the following equation:
* 在排队并最终丢弃数据包之前，在每个测量间隔T秒结束时，使用以下等式计算当前估计的过载率，即测量的过载率：
measured_overload_rate =
=((total_received_bytes)/T)-severe_congestion_restoration)
measured_overload_rate =
=((total_received_bytes)/T)-severe_congestion_restoration)
To provide a reliable estimation of the encoded information, several techniques can be used; see [AtLi01], [AdCa03], [ThCo04], and [AnHa06]. Note that since marking is done in Interior nodes, the decisions are made at Egress nodes, and the termination of flows is performed by Ingress nodes, there is a significant delay until the overload information is learned by the Ingress nodes (see Section 6 of [CsTa05]). The delay consists of the trip time of data packets from the severely congested Interior node to the Egress, the measurement interval, i.e., T, and the trip time of the notification signaling messages from Egress to Ingress. Moreover, until the overload decreases at the severely congested Interior node, an additional trip time from the Ingress node to the severely congested Interior node MUST expire. This is because immediately before receiving the congestion notification, the Ingress MAY have sent out packets in the flows that were selected for termination. That is, a terminated flow MAY contribute to congestion for a time longer that is taken from the Ingress to the Interior node. Without considering the above, Interior nodes would continue marking the packets until the measured utilization falls below the severe congestion restoration threshold. In this way, in the end, more flows will be terminated than necessary, i.e., an overreaction takes place. [CsTa05] provides a solution to this problem, where the Interior nodes use a sliding window memory to keep track of the signaling overload in a couple of previous measurement intervals. At the end of a measurement interval, T, before encoding and signaling the overloaded rate as "encoded DSCP" packets, the actual overload is decreased with the sum of already signaled overload stored in the sliding window memory, since that overload is already being handled in the severe congestion handling control loop. The sliding window memory consists of an integer number of cells, i.e., n = maximum number of cells. Guidelines for configuring the sliding window parameters are given in [CsTa05].
为了提供编码信息的可靠估计，可以使用几种技术；参见[AtLi01]、[AdCa03]、[ThCo04]和[AnHa06]。注意，由于标记是在内部节点中完成的，决策是在出口节点处做出的，并且流的终止是由入口节点执行的，因此在入口节点获知过载信息之前存在明显的延迟（参见[CsTa05]第6节）。延迟包括从严重拥挤的内部节点到出口的数据分组的跳闸时间、测量间隔（即T）以及从出口到入口的通知信令消息的跳闸时间。此外，在严重拥挤的内部节点处过载降低之前，从入口节点到严重拥挤的内部节点的额外跳闸时间必须到期。这是因为在接收拥塞通知之前，入口可能已经在选择终止的流中发送了数据包。也就是说，终止流可能在从入口到内部节点的更长时间内造成拥塞。在不考虑上述情况的情况下，内部节点将继续标记数据包，直到测量的利用率降至严重拥塞恢复阈值以下。通过这种方式，最终将终止比必要更多的流，即发生过度反应。[CsTa05]为该问题提供了一种解决方案，其中内部节点使用滑动窗口存储器来跟踪之前两个测量间隔内的信号过载。在测量间隔T结束时，在将过载率编码并发信号通知为“编码的DSCP”分组之前，实际过载与存储在滑动窗口存储器中的已发信号的过载之和一起减小，因为该过载已经在严重拥塞处理控制环中被处理。滑动窗口存储器由整数个单元组成，即n=最大单元数。[CsTa05]中给出了配置滑动窗口参数的指南。
At the end of each measurement interval, the newest calculated overload is pushed into the memory, and the oldest cell is dropped.
在每个测量间隔结束时，最新计算的过载被推入内存，最旧的单元被丢弃。
If Mi is the overload_rate stored in ith memory cell (i = [1..n]),
then at the end of every measurement interval, the overload rate that
is signaled to the Egress node, i.e., signaled_overload_rate is
calculated as follows:
If Mi is the overload_rate stored in ith memory cell (i = [1..n]),
then at the end of every measurement interval, the overload rate that
is signaled to the Egress node, i.e., signaled_overload_rate is
calculated as follows:
Sum_Mi =0
For i =1 to n
{
Sum_Mi = Sum_Mi + Mi
}
Sum_Mi =0
For i =1 to n
{
Sum_Mi = Sum_Mi + Mi
}
signaled_overload_rate = measured_overload_rate - Sum_Mi,
信号过载率=测量过载率-总和，
where Sum_Mi is calculated as above.
其中，Sum_Mi的计算如上所述。
Next, the sliding memory is updated as follows:
for i = 1..(n-1): Mi <- Mi+1
Mn <- signaled_overload_rate
Next, the sliding memory is updated as follows:
for i = 1..(n-1): Mi <- Mi+1
Mn <- signaled_overload_rate
The bytes that have to be re-marked to satisfy the signaled overload rate: signaled_remarked_bytes, are calculated using the following pseudocode:
必须重新标记以满足信号过载率的字节：信号字节，使用以下伪代码计算：
IF severe_congestion_threshold <> Maximum PHB capacity
THEN
{
IF (incoming_encoded-DSCP_rate <> 0) AND
(incoming_encoded-DSCP_rate =< termination_offset_rate)
THEN
{ signaled_remarked_bytes =
= ((signaled_overload_rate - incoming_encoded-DSCP_rate)*T)/N
}
ELSE IF (incoming_encoded-DSCP_rate > termination_offset_rate)
THEN signaled_remarked_bytes =
= ((signaled_overload_rate - termination_offset_rate)*T)/N
ELSE IF (incoming_encoded-DSCP_rate =0)
THEN signaled_remarked_bytes =
= signaled_overload_rate*T/N
}
ELSE signaled_remarked_bytes = signaled_overload_rate *T/N
IF severe_congestion_threshold <> Maximum PHB capacity
THEN
{
IF (incoming_encoded-DSCP_rate <> 0) AND
(incoming_encoded-DSCP_rate =< termination_offset_rate)
THEN
{ signaled_remarked_bytes =
= ((signaled_overload_rate - incoming_encoded-DSCP_rate)*T)/N
}
ELSE IF (incoming_encoded-DSCP_rate > termination_offset_rate)
THEN signaled_remarked_bytes =
= ((signaled_overload_rate - termination_offset_rate)*T)/N
ELSE IF (incoming_encoded-DSCP_rate =0)
THEN signaled_remarked_bytes =
= signaled_overload_rate*T/N
}
ELSE signaled_remarked_bytes = signaled_overload_rate *T/N
Where the incoming "encoded DSCP" rate is calculated as follows:
其中，传入的“编码DSCP”速率计算如下：
incoming_encoded-DSCP_rate =
= (received number of "encoded_DSCP" during T) * N)/T;
incoming_encoded-DSCP_rate =
= (received number of "encoded_DSCP" during T) * N)/T;
The signal_remarked_bytes also represents the number of the outgoing packets (after the dropping stage) that MUST be re-marked, during each measurement interval T, by a node when operates in severe congestion mode.
信号_字节还表示在每个测量间隔T期间，当节点在严重拥塞模式下运行时，必须由节点重新标记的传出数据包的数量（在丢弃阶段之后）。
Note that, in order to process an overload situation higher than 100% of the maintained severe congestion threshold, all the nodes within the domain MUST be configured and maintain a scaling parameter, e.g., N used in the above equation, which in combination with the marked bytes, e.g., signaled_remarked_bytes, such a high overload situation can be calculated and represented. N can be equal to or higher than 1.
注意，为了处理高于维持的严重拥塞阈值100%的过载情况，必须配置域内的所有节点，并维持一个缩放参数，例如，在上述等式中使用的N，该参数与标记的字节（例如，信号字节）相结合，可以计算和表示这种高过载情况。N可以等于或大于1。
Note that when incoming re-marked bytes are dropped, the operation of the severe congestion algorithm MAY be affected, e.g., the algorithm MAY become, in certain situations, slower. An implementation of the algorithm MAY assure as much as possible that the incoming marked bytes are not dropped. This could for example be accomplished by using different dropping rate thresholds for marked and unmarked bytes.
请注意，当丢弃传入的重新标记字节时，严重拥塞算法的操作可能会受到影响，例如，在某些情况下，算法可能会变慢。该算法的实现可尽可能确保传入的标记字节不会被丢弃。例如，这可以通过对标记字节和未标记字节使用不同的丢弃率阈值来实现。
Note that when the "affected DSCP" marking is used by a node that is congested due to a severe congestion situation, then all the outgoing packets that are not marked (i.e., by using the "encoded DSCP") have to be re-marked using the "affected DSCP" marking.
请注意，当“受影响的DSCP”标记由由于严重拥塞情况而拥塞的节点使用时，则必须使用“受影响的DSCP”标记重新标记所有未标记（即，通过使用“编码的DSCP”）的传出数据包。
The "encoded DSCP" and the "affected DSCP" marked packets (when applied in the whole RMD domain) are propagated to the QNE Edge nodes.
“编码的DSCP”和“受影响的DSCP”标记的分组（当应用于整个RMD域时）被传播到QNE边缘节点。
Furthermore, note that when the congestion notification based on probing is used in combination with severe congestion, then in addition to the possible "encoded DSCP" and "affected DSCP", another DSCP for the re-marking of the same PHB is used (see Section 4.6.1.7). This additional DSCP is denoted in this document as "notified DSCP". When an Interior node operates in the severe congested state (see Figure 27), and receives "notified DSCP" packets, these packets are considered to be unmarked packets (but not "affected DSCP" packets). This means that during severe congestion, also the "notified DSCP" packets can be re-marked and encoded as either "encoded DSCP" or "affected DSCP" packets.
此外，请注意，当基于探测的拥塞通知与严重拥塞结合使用时，除了可能的“编码DSCP”和“受影响的DSCP”外，还使用另一个DSCP重新标记相同的PHB（见第4.6.1.7节）。此附加DSCP在本文件中表示为“通知DSCP”。当内部节点在严重拥塞状态下运行（见图27）并接收到“通知的DSCP”数据包时，这些数据包被视为未标记数据包（但不是“受影响的DSCP”数据包）。这意味着在严重拥塞期间，“通知的DSCP”数据包也可以重新标记并编码为“编码的DSCP”或“受影响的DSCP”数据包。
A.2. Example of a Detailed Severe Congestion Operation in the Egress Nodes
A.2. 出口节点中详细的严重拥塞操作示例
This appendix describes an example of a detailed severe congestion operation in the Egress nodes.
本附录描述了出口节点中详细的严重拥塞操作示例。
The states of operation in Egress nodes are similar to the ones described in Appendix A.1. The definition of the events, see below, is however different than the definition of the events given in Figures 26 and 27:
出口节点的运行状态与附录A.1中所述的状态相似。然而，事件的定义（见下文）与图26和27中给出的事件定义不同：
* event A: when the Egress receives a predefined rate of "notified DSCP" marked bytes/packets, event A is activated (see Sections 4.6.1.7 and A.4). The predefined rate of "notified DSCP" marked bytes is denoted as the congestion notification detection threshold. Note this congestion notification detection threshold can also be zero, meaning that the event A is activated when the Egress node, during an interval T, receives at least one "notified DSCP" packet.
* 事件A：当出口接收到预定义速率的“通知DSCP”标记字节/数据包时，激活事件A（见第4.6.1.7和A.4节）。“通知的DSCP”标记字节的预定义速率表示为拥塞通知检测阈值。注意，该拥塞通知检测阈值也可以为零，这意味着当出口节点在间隔T期间接收到至少一个“通知的DSCP”分组时，事件A被激活。
* event B: this event occurs when the Egress receives packets marked as either "encoded DSCP" or "affected DSCP" (when "affected DSCP" is applied in the whole RMD domain).
* 事件B：当出口接收到标记为“编码的DSCP”或“受影响的DSCP”的数据包时（当“受影响的DSCP”应用于整个RMD域时），发生此事件。
* event C: this event occurs when the rate of incoming "notified DSCP" packets decreases below the congestion notification detection threshold. In the situation that the congestion notification detection threshold is zero, this will mean that event C is activated when the Egress node, during an interval T, does not receive any "notified DSCP" marked packets.
* 事件C：当传入“notified DSCP”数据包的速率降低到拥塞通知检测阈值以下时，会发生此事件。在拥塞通知检测阈值为零的情况下，这将意味着当出口节点在间隔T期间没有接收到任何“通知的DSCP”标记的分组时，事件C被激活。
* event D: this event occurs when the Egress, during an interval T, does not receive packets marked as either "encoded DSCP" or "affected DSCP" (when "affected DSCP" is applied in the whole RMD domain). Note that when "notified DSCP" is applied in the whole RMD domain for the support of congestion notification, this event could cause the following change in operation state.
* 事件D：当出口在间隔T期间未接收标记为“编码的DSCP”或“受影响的DSCP”的数据包时（当“受影响的DSCP”应用于整个RMD域时），发生此事件。请注意，当在整个RMD域中应用“通知的DSCP”以支持拥塞通知时，此事件可能会导致操作状态发生以下变化。
When the Egress, during an interval T, does not receive (1) packets marked as either "encoded DSCP" or "affected DSCP" (when "affected DSCP" is applied in the whole RMD domain) and (2) it does NOT receive "notified DSCP" marked packets, the change in the operation state occurs from the severe congestion state to normal state.
当出口在间隔T期间未接收（1）标记为“编码的DSCP”或“受影响的DSCP”的分组（当“受影响的DSCP”应用于整个RMD域时）和（2）未接收标记为“通知的DSCP”的分组时，操作状态发生从严重拥塞状态到正常状态的变化。
When the Egress, during an interval T, does not receive (1) packets marked as either "encoded DSCP" or "affected DSCP" (when "affected DSCP" is applied in the whole RMD domain) and (2) it does receive "notified DSCP" marked packets, the change in the operation state occurs from the severe congestion state to the congestion notification state.
当出口在间隔T期间没有接收（1）标记为“编码的DSCP”或“受影响的DSCP”的分组（当“受影响的DSCP”应用于整个RMD域时）和（2）它确实接收到标记为“通知的DSCP”的分组时，操作状态发生从严重拥塞状态到拥塞通知状态的变化。
* event E: this event occurs when the Egress, during an interval T, does not receive packets marked as either "encoded DSCP" or "affected DSCP" (when "affected DSCP" is applied in the whole RMD domain).
* 事件E：当出口在间隔T期间未接收标记为“编码的DSCP”或“受影响的DSCP”的数据包时（当“受影响的DSCP”应用于整个RMD域时），发生此事件。
An example of the algorithm for calculation of the number of flows associated with each priority class that have to be terminated is explained by the pseudocode below.
下面的伪代码解释了用于计算与必须终止的每个优先级类别相关联的流的数量的算法的示例。
The Edge nodes are able to support severe congestion handling by: (1) identifying which flows were affected by the severe congestion and (2) selecting and terminating some of these flows such that the quality of service of the remaining flows is recovered.
边缘节点能够通过以下方式支持严重拥塞处理：（1）识别哪些流受到严重拥塞的影响；（2）选择并终止其中一些流，以便恢复其余流的服务质量。
The "encoded DSCP" and the "affected DSCP" marked packets (when applied in the whole RMD domain) are received by the QNE Edge node.
QNE边缘节点接收“编码的DSCP”和“受影响的DSCP”标记的分组（当应用于整个RMD域时）。
The QNE Edge nodes keep per-flow state and therefore they can translate the calculated bandwidth to be terminated, to number of flows. The QNE Egress node records the excess rate and the identity of all the flows, arriving at the QNE Egress node, with "encoded DSCP" and with "affected DSCP" (when applied in the whole RMD domain); only these flows, which are the ones passing through the severely congested Interior node(s), are candidates for termination. The excess rate is calculated by measuring the rate of all the "encoded DSCP" data packets that arrive at the QNE Egress node. The measured excess rate is converted by the Egress node, by multiplying it by the factor N, which was used by the QNE Interior node(s) to encode the overload level.
QNE边缘节点保持每个流的状态，因此它们可以将要终止的计算带宽转换为流的数量。QNE出口节点使用“编码的DSCP”和“受影响的DSCP”（当应用于整个RMD域时）记录到达QNE出口节点的所有流的超额率和身份；只有通过严重拥挤的内部节点的这些流才可能终止。通过测量到达QNE出口节点的所有“编码的DSCP”数据包的速率来计算超额速率。测量的超额率由出口节点通过乘以因子N进行转换，因子N由QNE内部节点用于编码过载水平。
When different priority flows are supported, all the low priority flows that arrived at the Egress node are terminated first. Next, all the medium priority flows are stopped and finally, if necessary, even high priority flows are chosen. Within a priority class both "encoded DSCP" and "affected DSCP" are considered before the mechanism moves to higher priority class. Finally, for each flow that has to be terminated the Egress node, sends a NOTIFY message to the Ingress node, which stops the flow.
当支持不同的优先级流时，首先终止到达出口节点的所有低优先级流。接下来，停止所有中等优先级流，最后，如果需要，甚至选择高优先级流。在优先级级别内，在机制移动到更高优先级级别之前，将同时考虑“编码的DSCP”和“受影响的DSCP”。最后，对于必须终止的每个流，出口节点向入口节点发送通知消息，入口节点停止流。
Below, this algorithm is described in detail.
下面详细描述该算法。
First, when the Egress operates in the severe congestion state, the total amount of re-marked bandwidth associated with the PHB traffic class, say total_congested_bandwidth, is calculated. Note that when the node maintains information about each Ingress/Egress pair aggregate, then the total_congested_bandwidth MUST be calculated per Ingress/Egress pair reservation aggregate. This bandwidth represents the severely congested bandwidth that SHOULD be terminated. The total_congested_bandwidth can be calculated as follows:
首先，当出口在严重拥塞状态下工作时，计算与PHB业务类别相关联的重新标记的带宽总量，即总的拥塞带宽。注意，当节点维护关于每个入口/出口对聚集的信息时，则必须计算每个入口/出口对保留聚集的总拥挤带宽。此带宽表示应终止的严重拥塞带宽。总的_拥塞_带宽可计算如下：
total_congested_bandwidth = N*input_remarked_bytes/T
total_congested_bandwidth = N*input_remarked_bytes/T
Where, input_remarked_bytes represents the number of "encoded DSCP" marked bytes that arrive at the Egress, during one measurement interval T, N is defined as in Sections 4.6.1.6.2.1 and A.1. The term denoted as terminated_bandwidth is a temporal variable representing the total bandwidth that has to be terminated, belonging to the same PHB traffic class. The terminate_flow_bandwidth (priority_class) is the total bandwidth associated with flows of priority class equal to priority_class. The parameter priority_class is an integer fulfilling:
其中，input_表示在一个测量间隔T内到达出口的“编码DSCP”标记字节数，N的定义见第4.6.1.6.2.1和A.1节。表示为终止的_带宽的术语是表示必须终止的总带宽的时间变量，属于相同的PHB业务类别。terminate_flow_bandwidth（priority_class）是与优先级等于优先级的流相关联的总带宽。参数priority_类是一个整数：
0 =< priority_class =< Maximum_priority.
0=<priority\u class=<Maximum\u priority。
The QNE Egress node records the identity of the QNE Ingress node that forwarded each flow, the total_congested_bandwidth and the identity of all the flows, arriving at the QNE Egress node, with "encoded DSCP" and "affected DSCP" (when applied in whole RMD domain). This ensures that only these flows, which are the ones passing through the severely overloaded QNE Interior node(s), are candidates for termination. The selection of the flows to be terminated is described in the pseudocode that is given below, which is realized by the function denoted below as calculate_terminate_flows().
QNE出口节点使用“编码的DSCP”和“受影响的DSCP”（在整个RMD域中应用时）记录转发每个流的QNE入口节点的标识、总的拥塞带宽以及到达QNE出口节点的所有流的标识。这确保只有通过严重过载的QNE内部节点的流才是终止的候选流。下面给出的伪代码中描述了要终止的流的选择，该伪代码由下面表示为calculate_terminate_flows（）的函数实现。
The calculate_terminate_flows() function uses the <terminate_bandwidth_class> value and translates this bandwidth value to number of flows that have to be terminated. Only the "encoded DSCP" flows and "affected DSCP" (when applied in whole RMD domain) flows, which are the ones passing through the severely overloaded Interior node(s), are candidates for termination.
函数的compute_terminate_flows（）使用<terminate_bandwidth_class>值，并将该带宽值转换为必须终止的流的数量。只有“编码的DSCP”流和“受影响的DSCP”（应用于整个RMD域时）流（即通过严重过载的内部节点的流）才是终止的候选。
After the flows to be terminated are selected, the <sum_bandwidth_terminate(priority_class)> value is calculated that is the sum of the bandwidth associated with the flows, belonging to a certain priority class, which will certainly be terminated.
在选择要终止的流之后，计算<sum_bandwidth_terminate（priority_class）>值，该值是与流相关联的带宽之和，属于一定的优先级类别，它肯定会被终止。
The constraint of finding the total number of flows that have to be terminated is that sum_bandwidth_terminate(priority_class), SHOULD be smaller or approximately equal to the variable terminate_bandwidth(priority_class).
查找必须终止的流总数的约束条件是，总带宽（优先级）应小于或近似等于可变终止带宽（优先级）。
terminated_bandwidth = 0;
priority_class = 0;
while terminated_bandwidth < total_congested_bandwidth
{
terminate_bandwidth(priority_class) =
= total_congested_bandwidth - terminated_bandwidth
calculate_terminate_flows(priority_class);
terminated_bandwidth =
= sum_bandwidth_terminate(priority_class) + terminated_bandwidth;
priority_class = priority_class + 1;
}
terminated_bandwidth = 0;
priority_class = 0;
while terminated_bandwidth < total_congested_bandwidth
{
terminate_bandwidth(priority_class) =
= total_congested_bandwidth - terminated_bandwidth
calculate_terminate_flows(priority_class);
terminated_bandwidth =
= sum_bandwidth_terminate(priority_class) + terminated_bandwidth;
priority_class = priority_class + 1;
}
If the Egress node maintains Ingress/Egress pair reservation aggregates, then the above algorithm is performed for each Ingress/Egress pair reservation aggregate.
如果出口节点维护入口/出口对保留聚合，则对每个入口/出口对保留聚合执行上述算法。
Finally, for each flow that has to be terminated, the QNE Egress node sends a NOTIFY message to the QNE Ingress node to terminate the flow.
最后，对于必须终止的每个流，QNE出口节点向QNE入口节点发送通知消息以终止流。
A.3. Example of a Detailed Re-Marking Admission Control (Congestion Notification) Operation in Interior Nodes
A.3. 内部节点中详细的重新标记接纳控制（拥塞通知）操作的示例
This appendix describes an example of a detailed re-marking admission control (congestion notification) operation in Interior nodes. The predefined congestion notification threshold, see Appendix A.1, is set according to, and usually less than, an engineered bandwidth limitation, i.e., admission threshold, e.g., based on a Service Level Agreement or a capacity limitation of specific links.
本附录描述了内部节点中详细的重新标记接纳控制（拥塞通知）操作的示例。预定义的拥塞通知阈值（见附录A.1）根据工程带宽限制设置，通常小于工程带宽限制，即准入阈值，例如，基于服务水平协议或特定链路的容量限制。
The difference between the congestion notification threshold and the engineered bandwidth limitation, i.e., admission threshold, provides an interval where the signaling information on resource limitation is already sent by a node but the actual resource limitation is not reached. This is due to the fact that data packets associated with an admitted session have not yet arrived, which allows the admission control process available at the Egress to interpret the signaling information and reject new calls before reaching congestion.
拥塞通知阈值和工程带宽限制（即，接纳阈值）之间的差异提供了一个间隔，其中节点已经发送了关于资源限制的信令信息，但没有达到实际资源限制。这是由于与已接纳会话相关联的数据分组尚未到达的事实，这使得出口处可用的接纳控制过程能够解释信令信息并在到达拥塞之前拒绝新呼叫。
Note that in the situation when the data rate is higher than the preconfigured congestion notification rate, data packets are also re-marked (see Section 4.6.1.6.2.1). To distinguish between congestion notification and severe congestion, two methods MAY be used (see Appendix A.1):
注意，在数据速率高于预先配置的拥塞通知速率的情况下，数据包也会被重新标记（见第4.6.1.6.2.1节）。为了区分拥塞通知和严重拥塞，可以使用两种方法（见附录A.1）：
* using different <DSCP> values (re-marked <DSCP> values). The re-marked DSCP that is used for this purpose is denoted as "notified DSCP" in this document. When this method is used and when the Interior node is in "congestion notification" state, see Appendix
* 使用不同的<DSCP>值（重新标记<DSCP>值）。用于此目的的重新标记DSCP在本文件中表示为“通知DSCP”。当使用此方法且内部节点处于“拥塞通知”状态时，请参见附录
A.1, then the node SHOULD re-mark all the unmarked bytes passing through the node using the "notified DSCP". Note that this method can only be applied if all nodes in the RMD domain use the "notified" DSCP marking. In this way, probe packets that will pass through the Interior node that operates in congestion notification state are also encoded using the "notified DSCP" marking.
A.1，则节点应使用“通知的DSCP”重新标记通过节点的所有未标记字节。注意，只有当RMD域中的所有节点都使用“通知”DSCP标记时，才能应用此方法。这样，将通过在拥塞通知状态下运行的内部节点的探测数据包也使用“通知的DSCP”标记进行编码。
* Using the "encoded DSCP" marking for congestion notification and severe congestion. This method is not described in detail in this example appendix.
* 使用“编码DSCP”标记进行拥塞通知和严重拥塞。本示例附录中未详细描述此方法。
A.4. Example of a Detailed Admission Control (Congestion Notification) Operation in Egress Nodes
A.4. 出口节点中的详细准入控制（拥塞通知）操作的示例
This appendix describes an example of a detailed admission control (congestion notification) operation in Egress nodes.
本附录描述了出口节点中的详细准入控制（拥塞通知）操作的示例。
The admission control congestion notification procedure can be applied only if the Egress maintains the Ingress/Egress pair aggregate. When the operation state of the Ingress/Egress pair aggregate is the "congestion notification", see Appendix A.2, then the implementation of the algorithm depends on how the congestion notification situation is notified to the Egress. As mentioned in Appendix A.3, two methods are used:
仅当出口保持入口/出口对聚合时，才能应用准入控制拥塞通知过程。当入口/出口对集合的操作状态为“拥塞通知”（见附录A.2）时，算法的实现取决于如何向出口通知拥塞通知情况。如附录A.3所述，使用两种方法：
* using the "notified DSCP". During a measurement interval T, the Egress counts the number of "notified DSCP" marked bytes that belong to the same PHB and are associated with the same Ingress/Egress pair aggregate, say input_notified_bytes. We denote the rate as incoming_notified_rate.
* 使用“通知的DSCP”。在测量间隔T期间，出口统计属于同一PHB且与同一入口/出口对聚合相关联的“通知DSCP”标记字节的数量，例如输入通知字节。我们将速率表示为传入速率。
* using the "encoded DSCP". In this case, during a measurement interval T, the Egress measures the input_notified_bytes by counting the "encoded DSCP" bytes.
* 使用“编码DSCP”。在这种情况下，在测量间隔T期间，出口通过计算“编码的DSCP”字节来测量输入字节。
Below only the detail description of the first method is given.
下面仅给出第一种方法的详细说明。
The incoming congestion_rate can be then calculated as follows:
然后，传入拥塞率可按如下方式计算：
incoming_congestion_rate = input_notified_bytes/T
incoming_congestion_rate = input_notified_bytes/T
If the incoming_congestion_rate is higher than a preconfigured congestion notification threshold, then the communication path between Ingress and Egress is considered to be congested. Note that the pre-congestion notification threshold can be set to "0". In this
如果传入的拥塞速率高于预先配置的拥塞通知阈值，则认为入口和出口之间的通信路径拥塞。请注意，拥塞前通知阈值可以设置为“0”。在这个
case, the Egress node will operate in congestion notification state at the moment that it receives at least one "notified DSCP" encoded packet.
在这种情况下，出口节点将在其接收到至少一个“通知的DSCP”编码分组的时刻在拥塞通知状态下操作。
When the Egress node operates in "congestion notification" state and if the end-to-end RESERVE (probe) arrives at the Egress, then this request SHOULD be rejected. Note that this happens only when the probe packet is either "notified DSCP" or "encoded DSCP" marked. In this way, it is ensured that the end-to-end RESERVE (probe) packet passed through the node that is congested. This feature is very useful when ECMP-based routing is used to detect only flows that are passing through the congested router.
当出口节点在“拥塞通知”状态下运行，并且如果端到端保留（探测）到达出口，则应拒绝该请求。注意，只有当探测数据包被标记为“通知DSCP”或“编码DSCP”时，才会发生这种情况。这样，确保端到端保留（探测）分组通过拥塞的节点。当基于ECMP的路由仅用于检测通过拥塞路由器的流时，此功能非常有用。
If such an Ingress/Egress pair aggregated state is not available when the (probe) RESERVE message arrives at the Egress, then this request is accepted if the DSCP of the packet carrying the RESERVE message is unmarked. Otherwise (if the packet is either "notified DSCP" or "encoded DSCP" marked), it is rejected.
如果当（探测）保留消息到达出口时，这样的入口/出口对聚合状态不可用，则如果承载保留消息的分组的DSCP未标记，则接受该请求。否则（如果数据包被标记为“通知的DSCP”或“编码的DSCP”），它将被拒绝。
A.5. Example of Selecting Bidirectional Flows for Termination during Severe Congestion
A.5. 在严重拥塞期间选择双向流终止的示例
This appendix describes an example of selecting bidirectional flows for termination during severe congestion.
本附录描述了在严重拥塞期间选择双向流终止的示例。
When a severe congestion occurs, e.g., in the forward path, and when the algorithm terminates flows to solve the severe congestion in the forward path, then the reserved bandwidth associated with the terminated bidirectional flows is also released. Therefore, a careful selection of the flows that have to be terminated SHOULD take place. A possible method of selecting the flows belonging to the same priority type passing through the severe congestion point on a unidirectional path can be the following:
当严重拥塞发生时，例如在前向路径中，并且当算法终止流以解决前向路径中的严重拥塞时，则与终止的双向流相关联的保留带宽也被释放。因此，应仔细选择必须终止的流。选择属于通过单向路径上严重拥塞点的相同优先级类型的流的可能方法如下：
* the Egress node SHOULD select, if possible, first unidirectional flows instead of bidirectional flows.
* 如果可能，出口节点应选择第一个单向流，而不是双向流。
* the Egress node SHOULD select, if possible, bidirectional flows that reserved a relatively small amount of resources on the path reversed to the path of congestion.
* 如果可能，出口节点应选择在与拥塞路径相反的路径上保留相对少量资源的双向流。
A.6. Example of a Severe Congestion Solution for Bidirectional Flows Congested Simultaneously on Forward and Reverse Paths
A.6. 在正向和反向路径上同时拥塞的双向流的严重拥塞解决方案示例
This appendix describes an example of a severe congestion solution for bidirectional flows congested simultaneously on forward and reverse paths.
本附录描述了在正向和反向路径上同时拥塞的双向流的严重拥塞解决方案示例。
This scenario describes a solution using the combination of the severe congestion solutions described in Section 4.6.2.5.2. It is considered that the severe congestion occurs simultaneously in forward and reverse directions, which MAY affect the same bidirectional flows.
本场景描述了使用第4.6.2.5.2节所述严重拥堵解决方案组合的解决方案。我们认为，在正向和反向同时发生严重拥塞，这可能会影响相同的双向流。
When the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states, the steps can be the following, see Figure A.3. Consider that the Egress node selects a number of bidirectional flows to be terminated. In this case, the Egress will send, for each bidirectional flow, a NOTIFY message to Ingress. If the Ingress receives these NOTIFY messages and its operational state (associated with reverse path) is in the severe congestion state (see Figures 26 and 27), then the Ingress operates in the following way:
当QNE边缘保持每流域内QoS NSLP操作状态时，步骤如下，见图A.3。考虑出口节点选择要终止的双向流的数量。在这种情况下，出口将针对每个双向流向入口发送通知消息。如果入口接收到这些NOTIFY消息，且其运行状态（与反向路径相关）处于严重拥塞状态（见图26和27），则入口以以下方式运行：
* For each NOTIFY message, the Ingress SHOULD identify the bidirectional flows that have to be terminated.
* 对于每个NOTIFY消息，入口应标识必须终止的双向流。
* The Ingress then calculates the total bandwidth that SHOULD be released in the reverse direction (thus not in forward direction) if the bidirectional flows will be terminated (preempted), say "notify_reverse_bandwidth". This bandwidth can be calculated by the sum of the bandwidth values associated with all the end-to-end sessions that received a (severe congestion) NOTIFY message.
* 如果双向流将被终止（抢占），则入口计算应在反向（因此不在正向）释放的总带宽，例如“通知反向带宽”。该带宽可以通过与接收（严重拥塞）通知消息的所有端到端会话相关联的带宽值之和来计算。
* Furthermore, using the received marked packets (from the reverse path) the Ingress will calculate, using the algorithm used by an Egress and described in Appendix A.2, the total bandwidth that has to be terminated in order to solve the congestion in the reverse path direction, say "marked_reverse_bandwidth".
* 此外，使用接收到的标记分组（来自反向路径），入口将使用出口使用的算法（如附录A.2所述）计算为解决反向路径方向的拥塞而必须终止的总带宽，例如“标记的反向带宽”。
* The Ingress then calculates the bandwidth of the additional flows that have to be terminated, say "additional_reverse_bandwidth", in order to solve the severe congestion in reverse direction, by taking into account:
* 然后，入口计算必须终止的附加流的带宽，例如“附加反向带宽”，以便通过考虑以下因素来解决反向严重拥塞：
** the bandwidth in the reverse direction of the bidirectional flows that were appointed by the Egress (the ones that received a NOTIFY message) to be preempted, i.e., "notify_reverse_bandwidth".
**由出口（接收通知消息的出口）指定要抢占的双向流的反向带宽，即“通知反向带宽”。
** the total amount of bandwidth in the reverse direction that has been calculated by using the received marked packets, i.e., "marked_reverse_bandwidth".
**通过使用接收到的标记数据包计算的反向带宽总量，即“标记反向带宽”。
QNE(Ingress) NE (int.) NE (int.) NE (int.) QNE(Egress)
NTLP stateful NTLP stateful
data| user | | | |
--->| data | #unmarked bytes| | |
|--------------->S #marked bytes | | |
| S--------------------------->| |
| | | |-------------->|data
| | | | |--->
| | | | Term.?
| NOTIFY | | |Yes
|<------------------------------------------------------------|
| | | | |data
| | | user | |<---
| user data | | data |<--------------|
| (#marked bytes)| S<----------| |
|<--------------------------------S | |
| (#unmarked bytes) S | |
Term|<--------------------------------S | |
Flow? | S | |
YES |RESERVE(RMD-QSPEC): S | |
|"forward - T tear" s | |
|--------------->| RESERVE(RMD-QSPEC): | |
| | "forward - T tear" | |
| |--------------------------->| |
| | S |-------------->|
| | S RESERVE(RMD-QSPEC):
| | S "reverse - T tear" |
| RESERVE(RMD-QSPEC) S |<--------------|
| "reverse - T tear" S<----------| |
|<--------------------------------S | |
QNE(Ingress) NE (int.) NE (int.) NE (int.) QNE(Egress)
NTLP stateful NTLP stateful
data| user | | | |
--->| data | #unmarked bytes| | |
|--------------->S #marked bytes | | |
| S--------------------------->| |
| | | |-------------->|data
| | | | |--->
| | | | Term.?
| NOTIFY | | |Yes
|<------------------------------------------------------------|
| | | | |data
| | | user | |<---
| user data | | data |<--------------|
| (#marked bytes)| S<----------| |
|<--------------------------------S | |
| (#unmarked bytes) S | |
Term|<--------------------------------S | |
Flow? | S | |
YES |RESERVE(RMD-QSPEC): S | |
|"forward - T tear" s | |
|--------------->| RESERVE(RMD-QSPEC): | |
| | "forward - T tear" | |
| |--------------------------->| |
| | S |-------------->|
| | S RESERVE(RMD-QSPEC):
| | S "reverse - T tear" |
| RESERVE(RMD-QSPEC) S |<--------------|
| "reverse - T tear" S<----------| |
|<--------------------------------S | |
Figure 28: Intra-domain RMD severe congestion handling for bidirectional reservation (congestion in both forward and reverse direction)
图28：双向预约的域内RMD严重拥塞处理（正向和反向拥塞）
This additional bandwidth can be calculated using the following algorithm:
可使用以下算法计算此额外带宽：
IF ("marked_reverse_bandwidth" > "notify_reverse_bandwidth") THEN "additional_reverse_bandwidth" = = "marked_reverse_bandwidth"- "notify_reverse_bandwidth"; ELSE "additional_reverse_bandwidth" = 0
如果（“标记的\u反向\u带宽”>“通知\u反向\u带宽”），则“额外的\u反向\u带宽”=“标记的\u反向\u带宽”-“通知\u反向\u带宽”；否则“额外反向带宽”=0
* Ingress terminates the flows that experienced a severe congestion in the forward path and received a (severe congestion) NOTIFY message.
* 入口终止在转发路径中经历严重拥塞并收到（严重拥塞）通知消息的流。
* If possible, the Ingress SHOULD terminate unidirectional flows that use the same Egress-Ingress reverse direction communication path to satisfy the release of a total bandwidth up equal to the "additional_reverse_bandwidth", see Appendix A.5.
* 如有可能，入口应终止使用相同出口入口反向通信路径的单向流，以满足总带宽的释放，总带宽上限等于“附加反向带宽”，见附录a.5。
* If the number of REQUIRED unidirectional flows (to satisfy the above issue) is not available, then a number of bidirectional flows that are using the same Egress-Ingress reverse direction communication path MAY be selected for preemption in order to satisfy the release of a total bandwidth equal up to the "additional_reverse_bandwidth". Note that using the guidelines given in Appendix A.5, first the bidirectional flows that reserved a relatively small amount of resources on the path reversed to the path of congestion SHOULD be selected for termination.
* 如果所需单向流的数量（以满足上述问题）不可用，则可以选择使用相同出口-入口反向通信路径的多个双向流进行抢占，以满足等于“附加反向带宽”的总带宽的释放。注意，使用附录A.5中给出的指南，首先应选择在与拥塞路径相反的路径上保留相对少量资源的双向流进行终止。
When the QNE Edges maintain aggregated intra-domain QoS-NSLP operational states, the steps can be the following.
当QNE边缘保持聚合的域内QoS NSLP操作状态时，步骤如下。
* The Egress calculates the bandwidth to be terminated using the same method as described in Section 4.6.1.6.2.2. The Egress includes this bandwidth value in a <PDR Bandwidth> within a "PDR_Congestion_Report" container that is carried by the end-to-end NOTIFY message.
* 出口使用第4.6.1.6.2.2节中描述的相同方法计算要终止的带宽。出口在端到端通知消息携带的“PDR_拥塞_报告”容器内的<PDR带宽>中包括该带宽值。
* The Ingress receives the NOTIFY message and reads the <PDR Bandwidth> value included in the "PDR_Congestion_Report" container. Note that this value is denoted as "notify_reverse_bandwidth" in the situation that the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states, but is calculated differently. The variables "marked_reverse_bandwidth" and "additional_reverse_bandwidth" are calculated using the same steps as explained for the situation that the QNE Edges maintain per-flow intra-domain QoS-NSLP states.
* 入口接收通知消息并读取“PDR\u拥塞报告”容器中包含的<PDR带宽>值。注意，在QNE边缘保持每流域内QoS NSLP操作状态的情况下，该值表示为“notify_reverse_bandwidth”，但计算方式不同。变量“标记的_反向_带宽”和“额外的_反向_带宽”使用与QNE边缘保持每流域内QoS NSLP状态的情况相同的步骤进行计算。
* Regarding the termination of flows that use the same Egress-Ingress reverse direction communication path, the Ingress can follow the same procedures as the situation that the QNE Edges maintain per-flow intra-domain QoS-NSLP operational states.
* 关于使用相同出口-入口反向通信路径的流的终止，入口可以遵循与QNE边缘保持每流域内QoS NSLP操作状态的情况相同的过程。
The RMD-aggregated (reduced-state) reservations maintained by the Interior nodes, can be reduced in the "forward" and "reverse" directions by using the procedure described in Section 4.6.2.3 and including in the <Peak Data Rate-1 (p)> value of the local RMD-QSPEC <TMOD-1> parameter of the RMD-QOSM <QoS Desired> field carried by the forward intra-domain RESERVE
通过使用第4.6.2.3节所述的程序，包括在<峰值数据速率-1（p）中，可以在“正向”和“反向”方向上减少内部节点维护的RMD聚合（简化状态）保留>前向域内保留携带的RMD-QOSM<QoS Desired>字段的本地RMD-QSPEC<TMOD-1>参数的值
the value equal to <notify_reverse_bandwidth> and by including the <additional_reverse_bandwidth> value in the <PDR Bandwidth> parameter within the "PDR_Release_Request" container that is carried by the same intra-domain RESERVE message.
该值等于<notify_reverse_bandwidth>，并通过将<additional_reverse_bandwidth>值包含在同一域内保留消息携带的“PDR_Release_Request”容器中的<PDR bandwidth>参数中。
This appendix describes an example of how preemption handling is supported during admission control.
本附录描述了在准入控制期间如何支持抢占处理的示例。
This section describes the mechanism that can be supported by the QNE Ingress, QNE Interior, and QNE Egress nodes to satisfy preemption during the admission control process.
本节描述QNE入口、QNE内部和QNE出口节点可支持的机制，以满足准入控制过程中的抢占。
This mechanism uses the preemption building blocks specified in [RFC5974].
此机制使用[RFC5974]中指定的抢占构建块。
If a QNE Ingress receives a RESERVE for a session that causes other session(s) to be preempted, for each of these to-be-preempted sessions, then the QNE Ingress follows the following steps:
如果QNE入口接收到导致其他会话被抢占的会话保留，则对于这些会话中的每一个会话，QNE入口遵循以下步骤：
Step_1:
步骤1：
The QNE Ingress MUST send a tearing RESERVE downstream and add a BOUND-SESSION-ID, with <Binding_Code> value equal to "Indicated session caused preemption" that indicates the SESSION-ID of the session that caused the preemption. Furthermore, an <INFO-SPEC> object with error code value equal to "Reservation preempted" has to be included in each of these tearing RESERVE messages.
QNE入口必须向下游发送撕裂保留，并添加绑定会话ID，其<Binding_Code>值等于“指示的会话导致的抢占”，该值指示导致抢占的会话的会话ID。此外，错误代码值等于“Reservation preempted”的<INFO-SPEC>对象必须包含在这些保留消息中。
The selection of which flows have to be preempted can be based on predefined policies. For example, this selection process can be based on the MRI associated with the high and low priority sessions. In particular, the QNE Ingress can select low(er) priority session(s) where their MRI is "close" (especially the target IP) to the one associated with the higher priority session. This means that typically the high priority session and the to-be-preempted lower priority sessions are following the same communication path and are passing through the same QNE Egress node.
必须抢占哪些流的选择可以基于预定义的策略。例如，该选择过程可以基于与高优先级和低优先级会话相关联的MRI。具体而言，QNE入口可以选择低（er）优先级会话，其中其MRI与高优先级会话相关联的会话“接近”（尤其是目标IP）。这意味着通常高优先级会话和待抢占低优先级会话遵循相同的通信路径，并且通过相同的QNE出口节点。
Furthermore, the amount of lower priority sessions that have to be preempted per each high priority session, has to be such that the requested resources by the higher priority session SHOULD be lower or equal than the sum of the reserved resources associated with the lower priority sessions that have to be preempted.
此外，每个高优先级会话必须被抢占的低优先级会话的数量必须使得高优先级会话所请求的资源应低于或等于与必须被抢占的低优先级会话相关联的保留资源的总和。
Step_2:
步骤2：
For each of the sent tearing RESERVE(s) the QNE Ingress will send a NOTIFY message with an <INFO-SPEC> object with error code value equal to "Reservation preempted" towards the QNI.
对于每个已发送的保留，QNE入口将向QNI发送带有<INFO-SPEC>对象的通知消息，该对象的错误代码值等于“保留抢占”。
Step_3:
步骤3：
After sending the preempted (tearing) RESERVE(s), the Ingress QNE will send the (reserving) RESERVE, which caused the preemption, downstream towards the QNE Egress.
在发送抢占（撕裂）保留后，入口QNE将向下游QNE出口发送导致抢占的（保留）保留。
The QNE Interior upon receiving the first (tearing) RESERVE that carries the <BOUND-SESSION-ID> object with <Binding_Code> value equal to "Indicated session caused preemption" and an <INFO-SPEC> object with error code value equal to "Reservation preempted" it considers that this session has to be preempted.
QNE内部在接收到第一个（撕裂）保留时，它携带<bind-SESSION-ID>对象，该对象的<Binding_Code>值等于“指示的会话导致的抢占”，以及<INFO-SPEC>对象的<INFO-SPEC>错误代码值等于“Reservation preempted”，它认为必须抢占该会话。
In this case, the QNE Interior creates a so-called "preemption state", which is identified by the SESSION-ID carried in the preemption-related <BOUND-SESSION-ID> object. Furthermore, this "preemption state" will include the SESSION-ID of the session associated with the (tearing) RESERVE. Subsequently, if additional tearing RESERVE(s) are arriving including the same values of BOUND-SESSION-ID and <INFO-SPEC> objects, then the associated SESSION-IDs of these (tearing) RESERVE message will be included in the already created "preemption state". The QNE will then set a timer, with a value that is high enough to ensure that it will not expire before the (reserving) RESERVE arrives.
在这种情况下，QNE内部创建所谓的“抢占状态”，该状态由抢占相关<BOUND-SESSION-ID>对象中携带的SESSION-ID标识。此外，该“抢占状态”将包括与（撕裂）保留相关联的会话的会话ID。随后，如果到达的附加撕裂保留包括绑定会话ID和<INFO-SPEC>对象的相同值，则这些（撕裂）保留消息的相关会话ID将包括在已创建的“抢占状态”中。然后，QNE将设置一个计时器，其值足够高，以确保在（保留）保留到达之前它不会过期。
Note that when the "preemption state" timer expires, the bandwidth associated with the preempted session(s) will have to be released, following a normal RMD-QOSM bandwidth release procedure. If the QNE Interior node will not receive all the to-be-preempted (tearing) RESERVE messages sent by the QNE Ingress before their associated (reserving) RESERVE message arrives, then the (reserving) RESERVE message will not reserve any resources and this message will be "M" marked (see Section 4.6.1.2). Note that this situation is not a typical situation. Typically, this situation can only occur when at least one of (tearing) the RESERVE messages is dropped due to an error condition.
请注意，当“抢占状态”计时器过期时，必须按照正常的RMD-QOSM带宽释放过程释放与抢占会话相关的带宽。如果QNE内部节点在相关（保留）保留消息到达之前不会接收QNE入口发送的所有待抢占（撕裂）保留消息，则（保留）保留消息将不会保留任何资源，并且该消息将被标记为“M”（参见第4.6.1.2节）。请注意，这种情况并非典型情况。通常，只有当至少一条（撕裂）保留消息由于错误情况而被丢弃时，才会发生这种情况。
Otherwise, if the QNE Interior receives all the to-be-preempted (tearing) RESERVE messages sent by the QNE Ingress, then the QNE Interior will remove the pending resources, and make the new reservation using normal RMD-QOSM bandwidth release and reservation procedures.
否则，如果QNE内部接收到QNE入口发送的所有待抢占（撕裂）保留消息，则QNE内部将删除挂起的资源，并使用正常的RMD-QOSM带宽释放和保留过程进行新的保留。
Similar to the QNE Interior operation, the QNE Egress, upon receiving the first (tearing) RESERVE that carries the <BOUND-SESSION-ID> object with the <Binding_Code> value equal to "Indicated session caused preemption" and an <INFO-SPEC> object with error code value equal to "Reservation preempted", it considers that this session has to be preempted. Similar to the QNE Interior operation the QNE Egress creates a so called "preemption state", which is identified by the SESSION-ID carried in the preemption-related <BOUND-SESSION-ID> object. This "preemption state" will store the same type of information and use the same timer value as specified in Appendix A.7.2.
与QNE内部操作类似，QNE在接收到第一个（撕裂）保留时退出，该保留携带<Binding-SESSION-ID>对象，该对象的<Binding_Code>值等于“指示的会话引起的抢占”，以及<INFO-SPEC>对象的错误代码值等于“Reservation preempted”，它认为该会话必须被抢占。与QNE内部操作类似，QNE出口创建所谓的“抢占状态”，该状态由抢占相关<BOUND-SESSION-ID>对象中携带的SESSION-ID标识。该“抢占状态”将存储相同类型的信息，并使用附录A.7.2中规定的相同定时器值。
Subsequently, if additional tearing RESERVE(s) are arriving including the same values of BOUND-SESSION-ID and <INFO-SPEC> objects, then the associated SESSION-IDs of these (tearing) RESERVE message will be included in the already created "preemption state".
随后，如果到达的附加撕裂保留包括绑定会话ID和<INFO-SPEC>对象的相同值，则这些（撕裂）保留消息的相关会话ID将包括在已创建的“抢占状态”中。
If the (reserving) RESERVE message sent by the QNE Ingress node arrived and is not "M" marked, and if all the to-be-preempted (tearing) RESERVE messages arrived, then the QNE Egress will remove the pending resources and make the new reservation using normal RMD-QOSM procedures.
如果QNE入口节点发送的（保留）保留消息到达且未标记“M”，并且如果所有要抢占（撕裂）的保留消息到达，则QNE出口将删除挂起的资源，并使用正常RMD-QOSM过程进行新的保留。
If the QNE Egress receives an "M" marked RESERVE message, then the QNE Egress will use the normal partial RMD-QOSM procedure to release the partial reserved resources associated with the "M" marked RESERVE (see Section 4.6.1.2).
如果QNE出口接收到标记为“M”的保留消息，则QNE出口将使用正常的部分RMD-QOSM过程来释放与标记为“M”的保留相关联的部分保留资源（参见第4.6.1.2节）。
If the QNE Egress will not receive all the to-be-preempted (tearing) RESERVE messages sent by the QNE Ingress before their associated and not "M" marked (reserving) RESERVE message arrives, then the following steps can be followed:
如果QNE出口在其相关且未标记“M”的（保留）保留消息到达之前，不会接收QNE入口发送的所有待抢占（撕裂）保留消息，则可以遵循以下步骤：
* If the QNE Egress uses an end-to-end QOSM that supports the preemption handling, then the QNE Egress has to calculate and select new lower priority sessions that have to be terminated. How the preempted sessions are selected and signaled to the downstream QNEs is similar to the operation specified in Appendix A.7.1.
* 如果QNE出口使用支持抢占处理的端到端QOSM，则QNE出口必须计算并选择必须终止的新的低优先级会话。抢占会话的选择方式和向下游QNE发送信号的方式与附录A.7.1中规定的操作类似。
* If the QNE Egress does not use an end-to-end QOSM that supports the preemption handling, then the QNE Egress has to reject the requesting (reserving) RESERVE message associated with the high priority session (see Section 4.6.1.2).
* 如果QNE出口不使用支持抢占处理的端到端QOSM，则QNE出口必须拒绝与高优先级会话相关联的请求（保留）保留消息（参见第4.6.1.2节）。
Note that typically, the situation in which the QNE Egress does not receive all the to-be-preempted (tearing) RESERVE messages sent by the QNE Ingress can only occur when at least one of the (tearing) RESERVE messages are dropped due to an error condition.
注意，通常，QNE出口不接收QNE入口发送的所有待抢占（撕裂）保留消息的情况只能在至少一个（撕裂）保留消息由于错误条件而被丢弃时发生。
This appendix describes an example of a retransmission procedure that can be used in the RMD domain.
本附录描述了可在RMD域中使用的重传过程示例。
If the retransmission of intra-domain RESERVE messages within the RMD domain is not disallowed, then all the QNE Interior nodes SHOULD use the functionality described in this section.
如果不允许在RMD域内重新传输域内保留消息，则所有QNE内部节点应使用本节中描述的功能。
In this situation, we enable QNE Interior nodes to maintain a replay cache in which each entry contains the <RSN>, <SESSION-ID> (available via GIST), <REFRESH-PERIOD> (available via the QoS NSLP [RFC5974]), and the last received "PHR Container" <Parameter ID> carried by the RMD-QSPEC for each session [RFC5975]. Thus, this solution uses information carried by <QoS-NSLP> objects [RFC5974] and parameters carried by the RMD-QSPEC "PHR Container". The following phases can be distinguished:
在这种情况下，我们使QNE内部节点能够维护一个重播缓存，其中每个条目都包含<RSN>、<SESSION-ID>（可通过GIST获得）、<REFRESH-PERIOD>（可通过QoS NSLP[RFC5974]获得），以及RMD-QSPEC为每个会话[RFC5975]携带的最后一个接收到的“PHR容器”<Parameter ID>。因此，该解决方案使用<QoS NSLP>对象[RFC5974]携带的信息和RMD-QSPEC“PHR容器”携带的参数。可以区分以下阶段：
Phase 1: Create Replay Cache Entry
阶段1：创建重播缓存项
When an Interior node receives an intra-domain RESERVE message and its cache is empty or there is no matching entry, it reads the <Parameter ID> field of the "PHR Container" of the received message. If the <Parameter ID> is a PHR_RESOURCE_REQUEST, which indicates that the intra-domain RESERVE message is a reservation request, then the QNE Interior node creates a new entry in the cache and copies the <RSN>, <SESSION-ID> and <Parameter ID> to the entry and sets the <REFRESH-PERIOD>.
当内部节点接收到域内保留消息且其缓存为空或没有匹配条目时，它将读取所接收消息的“PHR Container”的<Parameter ID>字段。如果<Parameter ID>是PHR\u RESOURCE\u请求，这表明域内保留消息是保留请求，则QNE内部节点在缓存中创建一个新条目，并将<RSN>、<SESSION-ID>和<Parameter ID>复制到该条目，并设置<REFRESH-PERIOD>。
By using the information stored in the list, the Interior node verifies whether or not the received intra-domain RESERVE message is sent by an adversary. For example, if the <SESSION-ID> and <RSN> of a received intra-domain RESERVE message match the values stored in the list then the Interior node checks the <Parameter ID> part.
通过使用存储在列表中的信息，内部节点验证所接收的域内保留消息是否由对手发送。例如，如果接收到的域内保留消息的<SESSION-ID>和<RSN>与列表中存储的值匹配，则内部节点检查<Parameter ID>部分。
If the <Parameter ID> is different, then:
如果<Parameter ID>不同，则：
Situation D1: <Parameter ID> in its own list is
PHR_RESOURCE_REQUEST, and <Parameter ID> in the message is
PHR_REFRESH_UPDATE;
Situation D1: <Parameter ID> in its own list is
PHR_RESOURCE_REQUEST, and <Parameter ID> in the message is
PHR_REFRESH_UPDATE;
Situation D2: <Parameter ID> in its own list is
PHR_RESOURCE_REQUEST or PHR_REFRESH_UPDATE, and <Parameter ID>
in the message is PHR_RELEASE_REQUEST;
Situation D2: <Parameter ID> in its own list is
PHR_RESOURCE_REQUEST or PHR_REFRESH_UPDATE, and <Parameter ID>
in the message is PHR_RELEASE_REQUEST;
Situation D3: <Parameter ID> in its own list is PHR_REFRESH_UPDATE,
and <Parameter ID> in the message is PHR_RESOURCE_REQUEST;
Situation D3: <Parameter ID> in its own list is PHR_REFRESH_UPDATE,
and <Parameter ID> in the message is PHR_RESOURCE_REQUEST;
For Situation D1, the QNE Interior node processes this message by RMD-QOSM default operation, reserves bandwidth, updates the entry, and passes the message to downstream nodes. For Situation D2, the QNE Interior node processes this message by RMD-QOSM default operation, releases bandwidth, deletes all entries associated with the session and passes the message to downstream nodes. For situation D3, the QNE Interior node does not use/process the local RMD-QSPEC <TMOD-1> parameter carried by the received intra-domain RESERVE message. Furthermore, the <K> flag in the "PHR Container" has to be set such that the local RMD-QSPEC <TMOD-1> parameter carried by the intra-domain RESERVE message is not processed/used by a QNE Interior node.
对于情况D1，QNE内部节点通过RMD-QOSM默认操作处理该消息，保留带宽，更新条目，并将该消息传递给下游节点。对于情况D2，QNE内部节点通过RMD-QOSM默认操作处理该消息，释放带宽，删除与会话相关联的所有条目，并将该消息传递给下游节点。对于情况D3，QNE内部节点不使用/处理接收到的域内保留消息携带的本地RMD-QSPEC<TMOD-1>参数。此外，必须设置“PHR容器”中的<K>标志，以便QNE内部节点不处理/使用域内保留消息携带的本地RMD-QSPEC<TMOD-1>参数。
If the <Parameter ID> is the same, then:
如果<Parameter ID>相同，则：
Situation S1: <Parameter ID> is equal to PHR_RESOURCE_REQUEST;
Situation S2: <Parameter ID> is equal to PHR_REFRESH_UPDATE;
Situation S1: <Parameter ID> is equal to PHR_RESOURCE_REQUEST;
Situation S2: <Parameter ID> is equal to PHR_REFRESH_UPDATE;
For situation S1, the QNE Interior node does not process the intra-domain RESERVE message, but it just passes it to downstream nodes, because it might have been retransmitted by the QNE Ingress node. For situation S2, the QNE Interior node processes the first incoming intra-domain (refresh) RESERVE message within a refresh period and updates the entry and forwards it to the downstream nodes.
对于情况S1，QNE内部节点不处理域内保留消息，但它只是将其传递给下游节点，因为它可能已被QNE入口节点重新传输。对于情况S2，QNE内部节点在刷新周期内处理第一个传入的域内（刷新）保留消息，并更新条目并将其转发给下游节点。
If only <Session-ID> is matched to the list, then the QNE Interior node checks the <RSN>. Here also two situations can be distinguished:
如果只有<Session ID>与列表匹配，则QNE内部节点检查<RSN>。这里还可以区分两种情况：
If a rerouting takes place (see Section 5.2.5.2 in [RFC5974]), the <RSN> in the message will be equal to either <RSN + 2> in the stored list if it is not a tearing RESERVE or <RSN -1> in the stored list if it is a tearing RESERVE:
如果发生重新路由（参见[RFC5974]中的第5.2.5.2节），则消息中的<RSN>将等于存储列表中的<RSN+2>（如果不是撕裂保留），或存储列表中的<RSN-1>（如果是撕裂保留）：
The QNE Interior node will check the <Parameter ID> part;
The QNE Interior node will check the <Parameter ID> part;
If the <RSN> in the message is equal to <RSN + 2> in the stored list and the <Parameter ID> is a PHR_RESOURCE_REQUEST or PHR_REFRESH_UPDATE, then the received intra-domain RESERVE message has to be interpreted and processed as a typical (non-tearing) RESERVE message, which is caused by rerouting, see Section 5.2.5.2 in [RFC5974].
如果消息中的<RSN>等于存储列表中的<RSN+2>，并且<Parameter ID>是PHR_RESOURCE_请求或PHR_REFRESH_UPDATE，则必须将接收到的域内保留消息解释为典型（非撕裂）保留消息，这是由重新路由引起的，请参见[RFC5974]中的第5.2.5.2节。
If the <RSN> in the message is equal to <RSN-1> in the stored list and the <Parameter ID> is a PHR_RELEASE_REQUEST, then the received intra-domain RESERVE message has to be interpreted and processed as a typical (tearing) RESERVE message, which is caused by rerouting (see Section 5.2.5.2 in [RFC5974]).
如果消息中的<RSN>等于存储列表中的<RSN-1>，并且<Parameter ID>是PHR_RELEASE_请求，则必须将接收到的域内保留消息解释为典型（撕裂）保留消息，这是由重新路由引起的（参见[RFC5974]中的第5.2.5.2节）。
If other situations occur than the ones described above, then the QNE Interior node does not use/process the local RMD-QSPEC <TMOD-1> parameter carried by the received intra-domain RESERVE message. Furthermore, the <K> parameter has to be set, see above.
如果出现上述情况以外的其他情况，则QNE内部节点不使用/处理接收到的域内保留消息携带的本地RMD-QSPEC<TMOD-1>参数。此外，必须设置<K>参数，见上文。
Phase 2: Update Replay Cache Entry
阶段2：更新重播缓存项
When a QNE Interior node receives an intra-domain RESERVE message, it retrieves the corresponding entry from the cache and compares the values. If the message is valid, the Interior node will update <Parameter ID> and <REFRESH-PERIOD> in the list entry.
当QNE内部节点接收到域内保留消息时，它从缓存中检索相应的条目并比较值。如果消息有效，内部节点将更新列表条目中的<Parameter ID>和<REFRESH-PERIOD>。
Phase 3: Delete Replay Cache Entry
阶段3：删除重播缓存项
When a QNE Interior node receives an intra-domain (tear) RESERVE message and an entry in the replay cache can be found, then the QNE Interior node will delete this entry after processing the message. Furthermore, the Interior node will delete cache entries, if it did not receive an intra-domain (refresh) RESERVE message during the <REFRESH-PERIOD> period with a <Parameter ID> value equal to PHR_REFRESH_UPDATE.
当QNE内部节点接收到域内（tear）保留消息并且可以在重播缓存中找到条目时，QNE内部节点将在处理该消息后删除该条目。此外，如果内部节点在<refresh-PERIOD>期间没有收到<Parameter ID>值等于PHR_refresh_UPDATE的域内（refresh）RESERVE消息，则内部节点将删除缓存项。
Section 3.4 of [RFC5975] describes an example of how the QSPEC can be Used within QoS-NSLP. Figure 29 illustrates a situation where a QNI and a QNR are using an end-to-end QOSM, denoted in this context as Z-e2e. It is considered that the QNI access network side is a wireless access network built on a generation "X" technology with QoS support as defined by generation "X", while QNR access network is a wired/fixed access network with its own defined QoS support.
[RFC5975]第3.4节描述了QoS NSLP中如何使用QSPEC的示例。图29说明了QNI和QNR使用端到端QOSM的情况，在本文中表示为Z-e2e。据认为，QNI接入网侧是基于第“X”代技术构建的具有第“X”代定义的QoS支持的无线接入网，而QNR接入网是具有其自身定义的QoS支持的有线/固定接入网。
Furthermore, it is considered that the shown QNE Edges are located at the boundary of an RMD domain and that the shown QNE Interior nodes are located inside the RMD domain.
此外，认为所示的QNE边缘位于RMD域的边界处，并且所示的QNE内部节点位于RMD域内。
The QNE Edges are able to run both the Z-e2e QOSM and the RMD-QOSM, while the QNE Interior nodes can only run the RMD-QOSM. The QNI is considered to be a wireless laptop, for example, while the QNR is considered to be a PC.
QNE边缘能够运行Z-e2e QOSM和RMD-QOSM，而QNE内部节点只能运行RMD-QOSM。例如，QNI被认为是无线笔记本电脑，而QNR被认为是个人电脑。
|------| |------| |------| |------|
|Z-e2e |<->|Z-e2e |<------------------------->|Z-e2e |<->|Z-e2e |
| QOSM | | QOSM | | QOSM | | QOSM |
| | |------| |-------| |-------| |------| | |
| NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP |
|Z-e2e | | RMD | | RMD | | RMD | | RMD | | Z-e2e|
| QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM |
|------| |------| |-------| |-------| |------| |------|
-----------------------------------------------------------------
|------| |------| |-------| |-------| |------| |------|
| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |
|------| |------| |-------| |-------| |------| |------|
QNI QNE QNE QNE QNE QNR
(End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End)
|------| |------| |------| |------|
|Z-e2e |<->|Z-e2e |<------------------------->|Z-e2e |<->|Z-e2e |
| QOSM | | QOSM | | QOSM | | QOSM |
| | |------| |-------| |-------| |------| | |
| NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP |
|Z-e2e | | RMD | | RMD | | RMD | | RMD | | Z-e2e|
| QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM |
|------| |------| |-------| |-------| |------| |------|
-----------------------------------------------------------------
|------| |------| |-------| |-------| |------| |------|
| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |
|------| |------| |-------| |-------| |------| |------|
QNI QNE QNE QNE QNE QNR
(End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End)
Figure 29. Example of initiator and local domain QOSM operation
图29。启动器和本地域QOSM操作示例
The QNI sets <QoS Desired> and <QoS Available> QSPEC objects in the initiator QSPEC, and initializes <QoS Available> to <QoS Desired>. In this example, the <Minimum QoS> object is not populated. The QNI populates QSPEC parameters to ensure correct treatment of its traffic in domains down the path. Additionally, to ensure correct treatment further down the path, the QNI includes <PHB Class> in <QoS Desired>. The QNI therefore includes in the QSPEC.
QNI在启动器QSPEC中设置<QoS Desired>和<QoS Available>QSPEC对象，并将<QoS Available>初始化为<QoS Desired>。在此示例中，未填充<Minimum QoS>对象。QNI填充QSPEC参数，以确保正确处理路径中域中的流量。此外，为确保进一步正确治疗，QNI在<QoS Desired>中包括<PHB Class>。因此，QNI包括在QSPEC中。
<QoS Desired> = <TMOD-1> <PHB Class>
<QoS Available> = <TMOD-1> <Path Latency>
<QoS Desired> = <TMOD-1> <PHB Class>
<QoS Available> = <TMOD-1> <Path Latency>
In this example, it is assumed that the <TMOD-1> parameter is used to encode the traffic parameters of a VoIP application that uses RTP and the G.711 Codec, see Appendix B in [RFC5975]. The below text is copied from [RFC5975].
在此示例中，假设<TMOD-1>参数用于对使用RTP和G.711编解码器的VoIP应用程序的流量参数进行编码，参见[RFC5975]中的附录B。以下文本从[RFC5975]复制。
In the simplest case the Minimum Policed Unit m is the sum of the IP-, UDP- and RTP- headers + payload. The IP header in the IPv4 case has a size of 20 octets (40 octets if IPv6 is used). The UDP header has a size of 8 octets and RTP uses a 12 octet header. The
在最简单的情况下，最小策略单位m是IP、UDP和RTP报头+有效负载的总和。IPv4情况下的IP标头大小为20个八位字节（如果使用IPv6，则为40个八位字节）。UDP报头的大小为8个八位字节，RTP报头的大小为12个八位字节。这个
G.711 Codec specifies a bandwidth of 64 kbit/s (8000 octets/s). Assuming RTP transmits voice datagrams every 20 ms, the payload for one datagram is 8000 octets/s * 0.02 s = 160 octets.
G.711编解码器规定带宽为64 kbit/s（8000个八位字节/s）。假设RTP每20毫秒发送一次语音数据报，则一个数据报的有效载荷为8000个八位字节/秒*0.02秒=160个八位字节。
IPv4+UDP+RTP+payload: m=20+8+12+160 octets = 200 octets
IPv6+UDP+RTP+payload: m=40+8+12+160 octets = 220 octets
IPv4+UDP+RTP+payload: m=20+8+12+160 octets = 200 octets
IPv6+UDP+RTP+payload: m=40+8+12+160 octets = 220 octets
The Rate r specifies the amount of octets per second. 50 datagrams are sent per second.
速率r指定每秒的八位字节数。每秒发送50个数据报。
IPv4: r = 50 1/s * m = 10,000 octets/s
IPv6: r = 50 1/s * m = 11,000 octets/s
IPv4: r = 50 1/s * m = 10,000 octets/s
IPv6: r = 50 1/s * m = 11,000 octets/s
The bucket size b specifies the maximum burst. In this example, a burst of 10 packets is used.
桶大小b指定最大爆破。在此示例中，使用10个分组的突发。
IPv4: b = 10 * m = 2000 octets
IPv6: b = 10 * m = 2200 octets
IPv4: b = 10 * m = 2000 octets
IPv6: b = 10 * m = 2200 octets
In our example, we will assume that IPV4 is used and therefore, the <TMOD-1> values will be set as follows:
在我们的示例中，我们将假设使用IPV4，因此，<TMOD-1>值将设置如下：
m = 200 octets r = 10000 octets/s b = 2000 octets
m=200个八位字节r=10000个八位字节/秒b=2000个八位字节
The <Peak Data Rate-1 (p)> and MPS are not specified above, but in our example we will assume:
上面未指定<峰值数据速率-1（p）>和MPS，但在我们的示例中，我们将假设：
p = r = 10000 octets/s
MPS = 220 octets
p = r = 10000 octets/s
MPS = 220 octets
The <PHB Class> is set in such a way that the Expedited Forwarding (EF) PHB is used.
<PHB Class>的设置方式是使用加速转发（EF）PHB。
Since <Path Latency> and <QoS Class> are not vital parameters from the QNI's perspective, it does not raise their <M> flags.
由于从QNI的角度来看，<Path Latency>和<QoS Class>不是重要参数，因此它不会提高它们的<M>标志。
Each QNE, which supports the Z-e2e QOSM on the path, reads and interprets those parameters in the initiator QSPEC.
每个QNE支持路径上的Z-e2e QOSM，读取并解释启动器QSPEC中的这些参数。
When an end-to-end RESERVE message is received at a QNE Ingress node at the RMD domain border, the QNE Ingress can "hide" the initiator end-to-end RESERVE message so that only the QNE Edges process the initiator (end-to-end) RESERVE message, which then bypasses intermediate nodes between the Edges of the domain, and issues its own local RESERVE message (see Section 6). For this new local RESERVE message, the QNE Ingress node generates the local RMD-QSPEC.
当RMD域边界的QNE入口节点接收到端到端保留消息时，QNE入口可以“隐藏”启动器端到端保留消息，以便只有QNE边缘处理启动器（端到端）保留消息，然后绕过域边缘之间的中间节点，并发布自己的本地保留信息（见第6节）。对于这个新的本地保留消息，QNE入口节点生成本地RMD-QSPEC。
The RMD-QSPEC corresponding to the RMD-QOSM is generated based on the original initiator QSPEC according to the procedures described in Section 4.5 of [RFC5974] and in Section 6 of this document. The RMD QNE Ingress maps the <TMOD-1> parameters contained in the original Initiator QSPEC into the equivalent <TMOD-1> parameter representing only the peak bandwidth in the local RMD-QSPEC.
根据[RFC5974]第4.5节和本文件第6节中描述的程序，基于原始启动器QSPEC生成与RMD-QOSM相对应的RMD-QSPEC。RMD QNE入口将原始启动器QSPEC中包含的<TMOD-1>参数映射为仅表示本地RMD-QSPEC中峰值带宽的等效<TMOD-1>参数。
In this example, the initial <TMOD-1> parameters are mapped into the RMD-QSPEC <TMOD-1> parameters as follows.
在此示例中，初始<TMOD-1>参数映射到RMD-QSPEC<TMOD-1>参数，如下所示。
As specified, the RMD-QOSM bandwidth equivalent <TMOD-1> parameter of RMD-QSPEC should have:
按照规定，RMD-QSPEC的RMD-QOSM等效带宽<TMOD-1>参数应具有：
r = p of initial e2e <TMOD-1> parameter
m = large;
b = large;
r = p of initial e2e <TMOD-1> parameter
m = large;
b = large;
For the RMD-QSPEC <TMOD-1> parameter, the following values are calculated:
对于RMD-QSPEC<TMOD-1>参数，计算以下值：
r = p of initial e2e <TMOD-1> parameter = 10000 octets/s
m is set in this example to large as follows:
m = MPS of initial e2e <TMOD-1> parameter = 220 octets
r = p of initial e2e <TMOD-1> parameter = 10000 octets/s
m is set in this example to large as follows:
m = MPS of initial e2e <TMOD-1> parameter = 220 octets
The maximum value of b = 250 gigabytes, but in our example this value is quite large. The b parameter specifies the extent to which the data rate can exceed the sustainable level for short periods of time.
b的最大值为250 GB，但在我们的示例中，该值相当大。b参数指定数据速率在短时间内超过可持续水平的程度。
In order to get a large b, in this example we consider that for a period of certain period of time the data rate can exceed the sustainable level, which in our example is the peak rate (p).
为了得到一个大的B，在这个例子中，我们认为，在一定时间段的数据速率可以超过可持续水平，在我们的例子中是峰值速率（P）。
Thus, in our example, we calculate b as:
因此，在我们的示例中，我们计算b为：
b = p * "period of time"
b=p*“时间段”
For this VoIP example, we can assume that this period of time is 1.5 seconds, see below:
对于此VoIP示例，我们可以假设此时间段为1.5秒，请参见以下内容：
b = 10000 octets/s * 1.5 seconds = 15000 octets
b = 10000 octets/s * 1.5 seconds = 15000 octets
Thus, the local RMD-QSPEC <TMOD-1> values are:
因此，局部RMD-QSPEC<TMOD-1>值为：
r = 10000 octets/s
p = 10000 octets/s
m = 220 octets
b = 15000 octets
MPS = 220 octets
r = 10000 octets/s
p = 10000 octets/s
m = 220 octets
b = 15000 octets
MPS = 220 octets
The bit level format of the RMD-QSPEC is given in Section 4.1. In particular, the Initiator/Local QSPEC bit, i.e., <I> is set to "Local" (i.e., "1") and the <Qspec Proc> is set as follows:
第4.1节给出了RMD-QSPEC的位级格式。具体而言，启动器/本地QSPEC位，即<i>被设置为“本地”（即“1”），并且<QSPEC Proc>被设置如下：
* Message Sequence = 0: Sender initiated * Object combination = 0: <QoS Desired> for RESERVE and <QoS Reserved> for RESPONSE
* 消息序列=0:发送方发起的*对象组合=0:<QoS期望>用于保留，而<QoS保留>用于响应
The <QSPEC Version> used by RMD-QOSM is the default version, i.e., "0", see [RFC5975]. The <QSPEC Type> value used by the RMD-QOSM is specified in [RFC5975] and is equal to: "2".
RMD-QOSM使用的<QSPEC版本>是默认版本，即“0”，请参阅[RFC5975]。[RFC5975]中规定了RMD-QOSM使用的<QSPEC类型>值，该值等于：“2”。
The <Traffic Handling Directives> contains the following fields:
<Traffic Handling Directions>包含以下字段：
<Traffic Handling Directives> = <PHR container> <PDR container>
<Traffic Handling Directives> = <PHR container> <PDR container>
The Per-Hop Reservation container (PHR container) and the Per-Domain Reservation container (PDR container) are specified in Sections 4.1.2 and 4.1.3, respectively. The <PHR container> contains the traffic handling directives for intra-domain communication and reservation. The <PDR container> contains additional traffic handling directives that are needed for edge-to-edge communication. The RMD-QOSM <QoS Desired> and <QoS Reserved>, are specified in Section 4.1.1.
每跳保留容器（PHR容器）和每域保留容器（PDR容器）分别在第4.1.2节和第4.1.3节中规定。<PHR container>包含域内通信和保留的流量处理指令。<PDR container>包含边到边通信所需的附加流量处理指令。第4.1.1节规定了RMD-QOSM<QoS Desired>和<QoS Reserved>。
In RMD-QOSM the <QoS Desired> and <QoS Reserved> objects contain the following parameters:
在RMD-QOSM中，<QoS Desired>和<QoS Reserved>对象包含以下参数：
<QoS Desired> = <TMOD-1> <PHB Class> <Admission Priority>
<QoS Reserved> = <TMOD-1> <PHB Class> <Admission Priority>
<QoS Desired> = <TMOD-1> <PHB Class> <Admission Priority>
<QoS Reserved> = <TMOD-1> <PHB Class> <Admission Priority>
The bit format of the <PHB Class> (see [RFC5975] and Figures 4 and 5) and <Admission Priority> complies to the bit format specified in [RFC5975].
<PHB类>（参见[RFC5975]以及图4和图5）和<Allocation Priority>的位格式符合[RFC5975]中规定的位格式。
In this example, the RMD-QSPEC <TMOD-1> values are the ones that were calculated and given above. Furthermore, the <PHB Class>, represents the EF PHB class. Moreover, in this example the RMD reservation is established without an <Admission Priority> parameter, which is equivalent to a reservation established with an <Admission Priority> whose value is 1.
在本例中，RMD-QSPEC<TMOD-1>值是上面计算和给出的值。此外，<PHB类>，表示EF PHB类。此外，在此示例中，RMD保留是在没有<Admission Priority>参数的情况下建立的，该参数相当于使用值为1的<Admission Priority>建立的保留。
The RMD QNE Egress node updates <QoS Available> on behalf of the entire RMD domain if it can. If it cannot (since the <M> flag is not set for <Path Latency>) it raises the parameter-specific, "not-supported" flag, warning the QNR that the final latency value in <QoS Available> is imprecise.
如果可以，RMD QNE出口节点代表整个RMD域更新<QoS Available>。如果不能（因为未为<Path Latency>设置<M>标志），则会引发特定于参数的“不受支持”标志，警告QNR<QoS Available>中的最终延迟值不精确。
In the "Y" access domain, the initiator QSPEC is processed by the QNR in the similar was as it was processed in the "X" wireless access domain, by the QNI.
在“Y”接入域中，QNR以类似于QNI在“X”无线接入域中处理的方式处理启动器QSPEC。
If the reservation was successful, eventually the RESERVE request arrives at the QNR (otherwise, the QNE at which the reservation failed would have aborted the RESERVE and sent an error RESPONSE back to the QNI). If the <RII> was included in the QoS-NSLP message, the QNR generates a positive RESPONSE with QSPEC objects <QoS Reserved> and <QoS Available>. The parameters appearing in <QoS Reserved> are the same as in <QoS Desired>, with values copied from <QoS Available>. Hence, the QNR includes the following QSPEC objects in the RESPONSE message:
如果保留成功，则保留请求最终到达QNR（否则，保留失败的QNE将中止保留并向QNI发送错误响应）。如果QoS NSLP消息中包含<RII>，则QNR将生成带有QSPEC对象<QoS Reserved>和<QoS Available>的肯定响应。<QoS Reserved>中出现的参数与<QoS required>中的参数相同，其值是从<QoS Available>复制的。因此，QNR在响应消息中包括以下QSPEC对象：
<QoS Reserved> = <TMOD-1> <PHB Class>
<QoS Available> = <TMOD-1> <Path Latency>
<QoS Reserved> = <TMOD-1> <PHB Class>
<QoS Available> = <TMOD-1> <Path Latency>
Contributors
贡献者
Attila Takacs Ericsson Research Ericsson Hungary Ltd. Laborc 1, Budapest, Hungary, H-1037 EMail: Attila.Takacs@ericsson.com
Attila Takacs爱立信研究有限公司爱立信匈牙利有限公司实验室1号，匈牙利布达佩斯，H-1037电子邮件：Attila。Takacs@ericsson.com
Andras Csaszar Ericsson Research Ericsson Hungary Ltd. Laborc 1, Budapest, Hungary, H-1037 EMail: Andras.Csaszar@ericsson.com
Andras Csaszar Ericsson Research Ericsson Hungary Ltd.匈牙利布达佩斯实验室1号，H-1037电子邮件：Andras。Csaszar@ericsson.com
Authors' Addresses
作者地址
Attila Bader Ericsson Research Ericsson Hungary Ltd. Laborc 1, Budapest, Hungary, H-1037 EMail: Attila.Bader@ericsson.com
Attila Bader Ericsson Research Ericsson Hungary Ltd.实验室1，匈牙利布达佩斯，H-1037电子邮件：Attila。Bader@ericsson.com
Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm, Sweden EMail: Lars.Westberg@ericsson.com
Lars Westberg Ericsson Research Torshamnsgatan 23 SE-164 80瑞典斯德哥尔摩电子邮件：Lars。Westberg@ericsson.com
Georgios Karagiannis University of Twente P.O. Box 217 7500 AE Enschede, The Netherlands EMail: g.karagiannis@ewi.utwente.nl
乔治斯卡拉基安尼斯屯特大学邮政信箱217 7500 AE恩斯赫德，荷兰电子邮件：G。karagiannis@ewi.utwente.nl
Cornelia Kappler ck technology concepts Berlin, Germany EMail: cornelia.kappler@cktecc.de
科妮莉亚·卡普勒ck技术概念德国柏林电子邮件：科妮莉亚。kappler@cktecc.de
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.priv.at
Hannes Tschofenig诺基亚西门子网络Linnoitustie 6 Espoo 02600芬兰电子邮件：Hannes。Tschofenig@nsn.comURI:http://www.tschofenig.priv.at
Tom Phelan Sonus Networks 250 Apollo Dr. Chelmsford, MA 01824 USA EMail: tphelan@sonusnet.com
Tom Phelan Sonus Networks 250阿波罗Chelmsford博士，马萨诸塞州01824美国电子邮件：tphelan@sonusnet.com