Internet Engineering Task Force (IETF) G. Ash, Ed.
Request for Comments: 5975 AT&T
Category: Experimental A. Bader, Ed.
ISSN: 2070-1721 Ericsson
C. Kappler, Ed.
ck technology concepts
D. Oran, Ed.
Cisco Systems, Inc.
October 2010
Internet Engineering Task Force (IETF) G. Ash, Ed.
Request for Comments: 5975 AT&T
Category: Experimental A. Bader, Ed.
ISSN: 2070-1721 Ericsson
C. Kappler, Ed.
ck technology concepts
D. Oran, Ed.
Cisco Systems, Inc.
October 2010
QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)
服务质量NSIS信令层协议（NSLP）的QSPEC模板
Abstract
摘要
The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models. The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path.
服务质量（QoS）NSIS信令层协议（NSLP）用于向QoS保留发送信号，它独立于特定的QoS模型（QOSM），如IntServ或Diffserv。相反，所有特定于QOSM的信息都封装在单独的对象QSPEC中。本文件为QSPEC定义了一个模板，包括许多QSPEC参数。QSPEC参数提供了一种可在多个QoSM中重用的公共语言，从而旨在确保QoS NSLP的可扩展性和互操作性。虽然基本协议是QOSM不可知的，但QSPEC对象中可以携带的参数可能与特定模型紧密耦合。发起NSIS信令的节点添加了发起方QSPEC，该发起方QSPEC指示在保留失败的情况下下游节点必须解释的QSPEC参数，从而确保NSIS发起方的意图沿着信令路径被保留。
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/rfc5975.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5975.
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
1.1. Conventions Used in This Document ..........................6
2. Terminology .....................................................6
3. QSPEC Framework .................................................7
3.1. QoS Models .................................................7
3.2. QSPEC Objects ..............................................9
3.3. QSPEC Parameters ..........................................11
3.3.1. Traffic Model Parameter ............................12
3.3.2. Constraints Parameters .............................14
3.3.3. Traffic-Handling Directives ........................16
3.3.4. Traffic Classifiers ................................17
3.4. Example of QSPEC Processing ...............................17
4. QSPEC Processing and Procedures ................................20
4.1. Local QSPEC Definition and Processing .....................20
4.2. Reservation Success/Failure, QSPEC Error Codes,
and INFO-SPEC Notification ................................23
4.2.1. Reservation Failure and Error E Flag ...............24
4.2.2. QSPEC Parameter Not Supported N Flag ...............25
4.2.3. INFO-SPEC Coding of Reservation Outcome ............25
4.2.4. QNE Generation of a RESPONSE Message ...............26
4.2.5. Special Case of Local QSPEC ........................27
4.3. QSPEC Procedures ..........................................27
4.3.1. Two-Way Transactions ...............................28
4.3.2. Three-Way Transactions .............................30
4.3.3. Resource Queries ...................................32
4.3.4. Bidirectional Reservations .........................33
4.3.5. Preemption .........................................33
4.4. QSPEC Extensibility .......................................33
5. QSPEC Functional Specification .................................33
5.1. General QSPEC Formats .....................................33
5.1.1. Common Header Format ...............................34
5.1.2. QSPEC Object Header Format .........................36
5.2. QSPEC Parameter Coding ....................................37
5.2.1. <TMOD-1> Parameter .................................37
5.2.2. <TMOD-2> Parameter .................................38
5.2.3. <Path Latency> Parameter ...........................39
5.2.4. <Path Jitter> Parameter ............................40
5.2.5. <Path PLR> Parameter ...............................41
5.2.6. <Path PER> Parameter ...............................42
5.2.7. <Slack Term> Parameter .............................43
5.2.8. <Preemption Priority> and <Defending Priority>
Parameters .........................................43
5.2.9. <Admission Priority> Parameter .....................44
5.2.10. <RPH Priority> Parameter ..........................45
5.2.11. <Excess Treatment> Parameter ......................46
5.2.12. <PHB Class> Parameter .............................48
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................6
2. Terminology .....................................................6
3. QSPEC Framework .................................................7
3.1. QoS Models .................................................7
3.2. QSPEC Objects ..............................................9
3.3. QSPEC Parameters ..........................................11
3.3.1. Traffic Model Parameter ............................12
3.3.2. Constraints Parameters .............................14
3.3.3. Traffic-Handling Directives ........................16
3.3.4. Traffic Classifiers ................................17
3.4. Example of QSPEC Processing ...............................17
4. QSPEC Processing and Procedures ................................20
4.1. Local QSPEC Definition and Processing .....................20
4.2. Reservation Success/Failure, QSPEC Error Codes,
and INFO-SPEC Notification ................................23
4.2.1. Reservation Failure and Error E Flag ...............24
4.2.2. QSPEC Parameter Not Supported N Flag ...............25
4.2.3. INFO-SPEC Coding of Reservation Outcome ............25
4.2.4. QNE Generation of a RESPONSE Message ...............26
4.2.5. Special Case of Local QSPEC ........................27
4.3. QSPEC Procedures ..........................................27
4.3.1. Two-Way Transactions ...............................28
4.3.2. Three-Way Transactions .............................30
4.3.3. Resource Queries ...................................32
4.3.4. Bidirectional Reservations .........................33
4.3.5. Preemption .........................................33
4.4. QSPEC Extensibility .......................................33
5. QSPEC Functional Specification .................................33
5.1. General QSPEC Formats .....................................33
5.1.1. Common Header Format ...............................34
5.1.2. QSPEC Object Header Format .........................36
5.2. QSPEC Parameter Coding ....................................37
5.2.1. <TMOD-1> Parameter .................................37
5.2.2. <TMOD-2> Parameter .................................38
5.2.3. <Path Latency> Parameter ...........................39
5.2.4. <Path Jitter> Parameter ............................40
5.2.5. <Path PLR> Parameter ...............................41
5.2.6. <Path PER> Parameter ...............................42
5.2.7. <Slack Term> Parameter .............................43
5.2.8. <Preemption Priority> and <Defending Priority>
Parameters .........................................43
5.2.9. <Admission Priority> Parameter .....................44
5.2.10. <RPH Priority> Parameter ..........................45
5.2.11. <Excess Treatment> Parameter ......................46
5.2.12. <PHB Class> Parameter .............................48
5.2.13. <DSTE Class Type> Parameter .......................49
5.2.14. <Y.1541 QoS Class> Parameter ......................50
6. Security Considerations ........................................51
7. IANA Considerations ............................................51
8. Acknowledgements ...............................................55
9. Contributors ...................................................55
10. Normative References ..........................................57
11. Informative References ........................................59
Appendix A. Mapping of QoS Desired, QoS Available, and QoS
Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ .62
Appendix B. Example of TMOD Parameter Encoding ....................62
5.2.13. <DSTE Class Type> Parameter .......................49
5.2.14. <Y.1541 QoS Class> Parameter ......................50
6. Security Considerations ........................................51
7. IANA Considerations ............................................51
8. Acknowledgements ...............................................55
9. Contributors ...................................................55
10. Normative References ..........................................57
11. Informative References ........................................59
Appendix A. Mapping of QoS Desired, QoS Available, and QoS
Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ .62
Appendix B. Example of TMOD Parameter Encoding ....................62
The QoS NSIS signaling layer protocol (NSLP) [RFC5974] is used to signal QoS reservations for a data flow, provide forwarding resources (QoS) for that flow, and establish and maintain state at nodes along the path of the flow. The design of QoS NSLP is conceptually similar to the decoupling between RSVP [RFC2205] and the IntServ architecture [RFC2210], where a distinction is made between the operation of the signaling protocol and the information required for the operation of the Resource Management Function (RMF). [RFC5974] describes the signaling protocol, while this document describes the RMF-related information carried in the QSPEC (QoS Specification) object carried in QoS NSLP messages.
QoS NSIS信令层协议（NSLP）[RFC5974]用于向数据流的QoS保留发送信号，为该流提供转发资源（QoS），并在沿该流路径的节点上建立和维护状态。QoS NSLP的设计在概念上类似于RSVP[RFC2205]和IntServ架构[RFC2210]之间的解耦，其中在信令协议的操作和资源管理功能（RMF）操作所需的信息之间进行了区分。[RFC5974]描述了信令协议，而本文档描述了QoS NSLP消息中的QSPEC（QoS规范）对象中包含的RMF相关信息。
[RFC5974] defines four QoS NSLP messages -- RESERVE, QUERY, RESPONSE, and NOTIFY -- each of which may carry the QSPEC object, while this document describes a template for the QSPEC object. The QSPEC object carries information on traffic descriptions, resources required, resources available, and other information required by the RMF. Therefore, the QSPEC template described in this document is closely tied to QoS NSLP, and the reader should be familiar with [RFC5974] to fully understand this document.
[RFC5974]定义了四个QoS NSLP消息——保留、查询、响应和通知——每个消息都可能携带QSPEC对象，而本文档描述了QSPEC对象的模板。QSPEC对象包含有关交通描述、所需资源、可用资源以及RMF所需的其他信息的信息。因此，本文档中描述的QSPEC模板与QoS NSLP密切相关，读者应熟悉[RFC5974]以充分理解本文档。
A QoS-enabled domain supports a particular QoS model (QOSM), which is a method to achieve QoS for a traffic flow. A QOSM incorporates QoS provisioning methods and a QoS architecture, and defines the behavior of the RMF that reserves resources for each flow, including inputs and outputs. The QoS NSLP protocol is able to signal QoS reservations for different QOSMs, wherein all information specific to a QOSM is encapsulated in the QSPEC object, and only the RMF specific to a given QOSM will need to interpret the QSPEC. Examples of QOSMs are IntServ, Diffserv admission control, and those specified in [CL-QOSM], [RFC5976], and [RFC5977].
支持QoS的域支持特定的QoS模型（QOSM），这是实现业务流QoS的一种方法。QOSM包含QoS供应方法和QoS体系结构，并定义RMF的行为，RMF为每个流保留资源，包括输入和输出。QoS NSLP协议能够向不同QOSM发出QoS保留的信号，其中特定于QOSM的所有信息被封装在QSPEC对象中，并且只有特定于给定QOSM的RMF将需要解释QSPEC。QOSM的示例包括IntServ、Diffserv接纳控制以及[CL-QOSM]、[RFC5976]和[RFC5977]中规定的那些。
QSPEC parameters include, for example:
QSPEC参数包括，例如：
o a mandatory traffic model (TMOD) parameter, o constraints parameters such as path latency and path jitter, o traffic handling directives such as excess treatment, and o traffic classifiers such as PHB class.
o 强制流量模型（TMOD）参数、o约束参数（如路径延迟和路径抖动）、o流量处理指令（如过度处理）和o流量分类器（如PHB类）。
While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models.
虽然基本协议是QOSM不可知的，但QSPEC对象中可以携带的参数可能与特定模型紧密耦合。
QSPEC objects loosely correspond to the TSpec, RSpec, and AdSpec objects specified in RSVP and may contain, respectively, a description of QoS Desired, QoS Reserved, and QoS Available. Going beyond RSVP functionality, the QSPEC also allows indicating a range of acceptable QoS by defining a QSPEC object denoting minimum QoS. Usage of these QSPEC objects is not bound to particular message types, thus allowing for flexibility. A QSPEC object collecting information about available resources may travel in any QoS NSLP message, for example, a QUERY message or a RESERVE message, as defined in [RFC5974]. The QSPEC travels in QoS NSLP messages but is opaque to the QoS NSLP and is only interpreted by the RMF.
QSPEC对象松散地对应于RSVP中指定的TSpec、RSpec和AdSpec对象，并且可能分别包含所需QoS、保留QoS和可用QoS的描述。除了RSVP功能之外，QSPEC还允许通过定义表示最小QoS的QSPEC对象来指示可接受QoS的范围。这些QSPEC对象的使用不绑定到特定的消息类型，因此允许灵活性。如[RFC5974]中所定义，收集可用资源信息的QSPEC对象可以在任何QoS NSLP消息中传输，例如查询消息或保留消息。QSPEC在QoS NSLP消息中传输，但对QoS NSLP不透明，并且仅由RMF解释。
Interoperability between QoS NSIS entities (QNEs) in different domains is enhanced by the definition of a common set of QSPEC parameters. A QoS NSIS initiator (QNI) initiating the QoS NSLP signaling adds an Initiator QSPEC object containing parameters describing the desired QoS, normally based on the QOSM it supports. QSPEC parameters flagged by the QNI must be interpreted by all QNEs in the path, else the reservation fails. In contrast, QSPEC parameters not flagged by the QNI may be skipped if not understood. Additional QSPEC parameters can be defined by informational specification documents, and thereby ensure the extensibility and flexibility of QoS NSLP.
通过定义一组通用的QSPEC参数，不同域中QoS NSIS实体（QNE）之间的互操作性得到增强。发起QoS NSLP信令的QoS NSIS启动器（QNI）添加一个启动器QSPEC对象，该对象包含描述所需QoS的参数，通常基于其支持的QOSM。QNI标记的QSPEC参数必须由路径中的所有QNE解释，否则保留失败。相反，如果不理解，QNI未标记的QSPEC参数可能会被跳过。附加的QSPEC参数可以通过信息规范文档定义，从而确保QoS NSLP的可扩展性和灵活性。
A Local QSPEC can be defined in a local domain with the Initiator QSPEC encapsulated, where the Local QSPEC must be functionally consistent with the Initiator QSPEC in terms of defined source traffic and other constraints. That is, a domain-specific local QSPEC can be defined and processed in a local domain, which could, for example, enable simpler processing by QNEs within the local domain.
可以在本地域中定义本地QSPEC，并封装启动器QSPEC，其中本地QSPEC必须在定义的源流量和其他约束方面与启动器QSPEC功能一致。也就是说，可以在本地域中定义和处理特定于域的本地QSPEC，例如，这可以通过本地域中的QNE实现更简单的处理。
In Section 3.4, an example of QSPEC processing is provided.
在第3.4节中，提供了QSPEC处理的示例。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Initiator QSPEC: The Initiator QSPEC is included in a QoS NSLP message by the QNI/QNR. It travels end-to-end to the QNR/QNI and is never removed.
启动器QSPEC：QNI/QNR将启动器QSPEC包含在QoS NSLP消息中。它端到端地传输到QNR/QNI，并且永远不会被移除。
Local QSPEC: A Local QSPEC is used in a local domain and is domain specific. It encapsulates the Initiator QSPEC and is removed at the egress of the local domain.
本地QSPEC：本地QSPEC用于本地域，并且是特定于域的。它封装了启动器QSPEC，并在本地域的出口处移除。
Minimum QoS: QSPEC object that, together with a description of QoS Desired or QoS Available, allows the QNI to specify a QoS range, i.e., an upper and lower bound. If the QoS Desired cannot be reserved, QNEs are going to decrease the reservation until the minimum QoS is hit. Note that the term "minimum" is used generically, since for some parameters, such as loss rate and latency, what is specified is the maximum acceptable value.
最小QoS：QSPEC对象，与所需QoS或可用QoS的描述一起，允许QNI指定QoS范围，即上限和下限。如果无法保留所需的QoS，QNE将减少保留，直到达到最低QoS。请注意，术语“最小值”一般使用，因为对于某些参数，如丢失率和延迟，指定的是最大可接受值。
QNE: QoS NSIS Entity, a node supporting QoS NSLP.
QNE:QoS NSIS实体，支持QoS NSLP的节点。
QNI: QoS NSIS Initiator, a node initiating QoS NSLP signaling.
QNI:QoS NSIS启动器，发起QoS NSLP信令的节点。
QNR: QoS NSIS Receiver, a node terminating QoS NSLP signaling.
QNR:QoS NSIS接收器，终止QoS NSLP信令的节点。
QoS Available: QSPEC object containing parameters describing the available resources. They are used to collect information along a reservation path.
QoS Available:QSPEC对象，包含描述可用资源的参数。它们用于沿预订路径收集信息。
QoS Desired: QSPEC object containing parameters describing the desired QoS for which the sender requests reservation.
所需QoS：QSPEC对象，包含描述发送方请求保留的所需QoS的参数。
QoS Model (QOSM): a method to achieve QoS for a traffic flow, e.g., IntServ Controlled Load; specifies the subset of QSPEC QoS constraints and traffic handling directives that a QNE implementing that QOSM is capable of supporting and how resources will be managed by the RMF.
QoS模型（QOSM）：一种实现业务流QoS的方法，例如IntServ控制的负载；指定实现QOSM的QNE能够支持的QSPEC QoS约束和流量处理指令的子集，以及RMF将如何管理资源。
QoS Reserved: QSPEC object containing parameters describing the reserved resources and related QoS parameters.
QoS Reserved:QSPEC对象，包含描述保留资源的参数和相关QoS参数。
QSPEC: the object of QoS NSLP that contains all QoS-specific information.
QSPEC：QoS NSLP的对象，包含所有QoS特定信息。
QSPEC parameter: Any parameter appearing in a QSPEC; for example, traffic model (TMOD), path latency, and excess treatment parameters.
QSPEC参数：QSPEC中出现的任何参数；例如，流量模型（TMOD）、路径延迟和过度治疗参数。
QSPEC Object: Main building blocks containing a QSPEC parameter set that is the input or output of an RMF operation.
QSPEC对象：包含QSPEC参数集的主要构建块，该参数集是RMF操作的输入或输出。
QSPEC Type: Identifies a particular QOSM used in the QSPEC
QSPEC类型：标识QSPEC中使用的特定QOSM
Resource Management Function (RMF): Functions that are related to resource management and processing of QSPEC parameters.
资源管理功能（RMF）：与资源管理和QSPEC参数处理相关的功能。
The overall framework for the QoS NSLP is that [RFC5974] defines QoS signaling and semantics, the QSPEC template defines the container and semantics for QoS parameters and objects, and informational specifications define QoS methods and procedures for using QoS signaling and QSPEC parameters/objects within specific QoS deployments. QoS NSLP is a generic QoS signaling protocol that can signal for many QOSMs.
QoS NSLP的总体框架是[RFC5974]定义QoS信令和语义，QSPEC模板定义QoS参数和对象的容器和语义，信息规范定义在特定QoS部署中使用QoS信令和QSPEC参数/对象的QoS方法和过程。QoS NSLP是一种通用的QoS信令协议，可以为许多QoSM发送信号。
A QOSM is a method to achieve QoS for a traffic flow, e.g., IntServ Controlled Load [CL-QOSM], Resource Management with Diffserv [RFC5977], and QoS signaling for Y.1541 QoS classes [RFC5976]. A QOSM specifies a set of QSPEC parameters that describe the QoS desired and how resources will be managed by the RMF. The RMF implements functions that are related to resource management and processes the QSPEC parameters.
QOSM是一种实现业务流QoS的方法，例如，IntServ控制负载[CL-QOSM]、区分服务的资源管理[RFC5977]和Y.1541 QoS类的QoS信令[RFC5976]。QOSM指定一组QSPEC参数，这些参数描述所需的QoS以及RMF将如何管理资源。RMF实现与资源管理相关的功能，并处理QSPEC参数。
QOSMs affect the operation of the RMF in NSIS-capable nodes and the information carried in QSPEC objects. Under some circumstances (e.g., aggregation), they may cause a separate NSLP session to be instantiated by having the RMF as a QNI. QOSM specifications may define RMF triggers that cause the QoS NSLP to run semantics within the underlying QoS NSLP signaling state and messaging processing rules, as defined in Section 5.2 of [RFC5974]. New QoS NSLP message processing rules can only be defined in extensions to QoS NSLP. If a QOSM specification defines triggers that deviate from existing QoS NSLP processing rules, the fallback for QNEs not supporting that QOSM are the QoS NSLP state transition/message processing rules.
QOSMs影响支持NSIS的节点中RMF的操作以及QSPEC对象中携带的信息。在某些情况下（例如聚合），它们可能会通过将RMF作为QNI来实例化单独的NSLP会话。QOSM规范可定义RMF触发器，使QoS NSLP在基础QoS NSLP信令状态和消息处理规则内运行语义，如[RFC5974]第5.2节所定义。新的QoS NSLP消息处理规则只能在QoS NSLP的扩展中定义。如果QOSM规范定义了偏离现有QoS NSLP处理规则的触发器，则不支持该QOSM的QNE的回退是QoS NSLP状态转换/消息处理规则。
The QOSM specification includes how the requested QoS resources will be described and how they will be managed by the RMF. For this purpose, the QOSM specification defines a set of QSPEC parameters it uses to describe the desired QoS and resource control in the RMF, and it may define additional QSPEC parameters.
QOSM规范包括如何描述请求的QoS资源以及RMF如何管理这些资源。为此，QOSM规范定义了一组QSPEC参数，用于描述RMF中所需的QoS和资源控制，并且可以定义附加的QSPEC参数。
When a QoS NSLP message travels through different domains, it may encounter different QOSMs. Since QOSMs use different QSPEC parameters for describing resources, the QSPEC parameters included by the QNI may not be understood in other domains. The QNI therefore can flag those QSPEC parameters it considers vital with the M flag. QSPEC parameters with the M flag set must be interpreted by the downstream QNEs, or the reservation fails. QSPEC parameters without the M flag set should be interpreted by the downstream QNEs, but may be ignored if not understood.
当QoS NSLP消息通过不同的域时，它可能会遇到不同的QoSM。由于qosm使用不同的QSPEC参数来描述资源，QNI包括的QSPEC参数在其他域中可能不被理解。因此，QNI可以使用M标志来标记其认为至关重要的QSPEC参数。设置了M标志的QSPEC参数必须由下游QNE解释，否则保留失败。下游QNE应解释不带M标志集的QSPEC参数，但如果不理解，可忽略。
A QOSM specification SHOULD include the following:
QOSM规范应包括以下内容：
- role of QNEs, e.g., location, frequency, statefulness, etc. - QSPEC definition including QSPEC parameters - QSPEC procedures applicable to this QOSM - QNE processing rules describing how QSPEC information is treated and interpreted in the RMF, e.g., admission control, scheduling, policy control, QoS parameter accumulation (e.g., delay) - at least one bit-level QSPEC example - QSPEC parameter behavior for new QSPEC parameters that the QOSM specification defines - a definition of what happens in case of preemption if the default QNI behavior (teardown preempted reservation) is not followed (see Section 4.3.5)
- QNE的作用，如位置、频率、状态等——QSPEC定义，包括QSPEC参数——适用于本QOSM的QSPEC程序——描述如何在RMF中处理和解释QSPEC信息的QNE处理规则，如准入控制、调度、策略控制、QoS参数累积（如延迟）-至少一个位级QSPEC示例-QOSM规范定义的新QSPEC参数的QSPEC参数行为-未遵循默认QNI行为（拆除抢占保留）时抢占情况的定义（见第4.3.5节）
A QOSM specification MAY include the following:
QOSM规范可包括以下内容：
- definitions of additional QOSM-specific error codes, as discussed in Section 4.2.3 - the QoS-NSLP options a QOSM wants to use, when several options are available for a QOSM (e.g., Local QSPEC to either a) hide the Initiator QSPEC within a local domain message, or b) encapsulate the Initiator QSPEC).
- 其他QOSM特定错误代码的定义，如第4.2.3节-QOSM想要使用的QoS NSLP选项所述，当QOSM有多个选项可用时（例如，本地QSPEC，a）在本地域消息中隐藏启动器QSPEC，或b）封装启动器QSPEC）。
QOSMs are free, subject to IANA registration and review rules, to extend QSPECs by adding parameters of any of the kinds supported by the QSPEC. This includes traffic description parameters, constraint parameters, and traffic handling directives. QOSMs are not permitted, however, to reinterpret or redefine the QSPEC parameters specified in this document. Note that signaling functionality is only defined by the QoS NSLP document [RFC5974] and not by this document or by QOSM specification documents.
QOSMs是免费的，根据IANA注册和审查规则，通过添加QSPEC支持的任何类型的参数来扩展QSPEC。这包括流量描述参数、约束参数和流量处理指令。但是，不允许QOSMs重新解释或重新定义本文件中规定的QSPEC参数。请注意，信令功能仅由QoS NSLP文档[RFC5974]定义，而不是由本文档或QOSM规范文档定义。
The QSPEC is the object of QoS NSLP containing QSPEC objects and parameters. QSPEC objects are the main building blocks of the QSPEC parameter set that is input or output of an RMF operation. QSPEC parameters are the parameters appearing in a QSPEC, which must include the traffic model parameter (TMOD), and may optionally include constraints (e.g., path latency), traffic handling directives (e.g., excess treatment), and traffic classifiers (e.g., PHB class). The RMF implements functions that are related to resource management and processes the QSPEC parameters.
QSPEC是QoS NSLP的对象，包含QSPEC对象和参数。QSPEC对象是作为RMF操作输入或输出的QSPEC参数集的主要构建块。QSPEC参数是出现在QSPEC中的参数，必须包括流量模型参数（TMOD），并且可以选择包括约束（例如，路径延迟）、流量处理指令（例如，过度处理）和流量分类器（例如，PHB类）。RMF实现与资源管理相关的功能，并处理QSPEC参数。
The QSPEC consists of a QSPEC version number and QSPEC objects. IANA assigns a new QSPEC version number when the current version is deprecated or deleted (as required by a specification). Note that a new QSPEC version number is not needed when new QSPEC parameters are specified. Later QSPEC versions MUST be backward compatible with earlier QSPEC versions. That is, a version n+1 device must support QSPEC version n (or earlier). On the other hand, if a QSPEC version n (or earlier) device receives an NSLP message specifying QSPEC version n+1, then the version n device responds with an 'Incompatible QSPEC' error code (0x0f) response, as discussed in Section 4.2.3, allowing the QNE that sent the NSLP message to retry with a lower QSPEC version.
QSPEC由QSPEC版本号和QSPEC对象组成。当当前版本被弃用或删除时（根据规范要求），IANA会分配一个新的QSPEC版本号。请注意，当指定新的QSPEC参数时，不需要新的QSPEC版本号。较新的QSPEC版本必须与较早的QSPEC版本向后兼容。也就是说，版本n+1设备必须支持QSPEC版本n（或更早）。另一方面，如果QSPEC版本n（或更早版本）设备接收到指定QSPEC版本n+1的NSLP消息，则版本n设备以“不兼容QSPEC”错误代码（0x0f）响应响应，如第4.2.3节所述，允许发送NSLP消息的QNE以更低的QSPEC版本重试。
This document provides a template for the QSPEC in order to promote interoperability between QOSMs. Figure 1 illustrates how the QSPEC is composed of up to 4 QSPEC objects, namely QoS Desired, QoS Available, QoS Reserved, and Minimum QoS. Each of these QSPEC objects consists of a number of QSPEC parameters. A given QSPEC may contain only a subset of the QSPEC objects, e.g., QoS Desired. The QSPEC objects QoS Desired, QoS Available, QoS Reserved and Minimum QoS MUST all be supported by QNEs and MAY appear in any QSPEC object carried in any QoS NSLP message (RESERVE, QUERY, RESPONSE, NOTIFY). See [RFC5974] for descriptions of the QoS NSLP RESERVE, QUERY, RESPONSE, and NOTIFY messages.
本文件为QSPEC提供了一个模板，以促进QOSMs之间的互操作性。图1说明了QSPEC如何由多达4个QSPEC对象组成，即所需QoS、可用QoS、保留QoS和最小QoS。这些QSPEC对象中的每一个都由许多QSPEC参数组成。给定的QSPEC可能仅包含QSPEC对象的子集，例如，所需的QoS。QNEs必须支持QSPEC对象所需的QoS、可用的QoS、保留的QoS和最小QoS，并可能出现在QoS NSLP消息（保留、查询、响应、通知）中携带的任何QSPEC对象中。有关QoS NSLP保留、查询、响应和通知消息的说明，请参阅[RFC5974]。
+---------------------------------------+
| QSPEC Objects |
+---------------------------------------+
+---------------------------------------+
| QSPEC Objects |
+---------------------------------------+
\________________ ______________________/
V
+----------+----------+---------+-------+
|QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS|
+----------+----------+---------+-------+
\________________ ______________________/
V
+----------+----------+---------+-------+
|QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS|
+----------+----------+---------+-------+
\____ ____/\___ _____/\___ ____/\__ ___/
V V V V
\____ ____/\___ _____/\___ ____/\__ ___/
V V V V
+-------------+... +-------------+...
|QSPEC Para. 1| |QSPEC Para. n|
+-------------+... +-------------+...
+-------------+... +-------------+...
|QSPEC Para. 1| |QSPEC Para. n|
+-------------+... +-------------+...
Figure 1: Structure of the QSPEC
图1:QSPEC的结构
Use of the 4 QSPEC objects (QoS Desired, QoS Available, QoS Reserved, and Minimum QoS) is described in Section 4.3 for 3 message sequences and 7 object combinations.
第4.3节描述了3个消息序列和7个对象组合的4个QSPEC对象（所需QoS、可用QoS、保留QoS和最小QoS）的使用。
The QoS Desired Object describe the resources the QNI desires to reserve, and hence this is a read-only QSPEC object in that the QSPEC parameters carried in the object may not be overwritten. QoS Desired is always included in a RESERVE message and sometimes included in the QUERY message (see Section 4.3 for details).
QoS所需对象描述QNI希望保留的资源，因此这是一个只读QSPEC对象，因为对象中携带的QSPEC参数可能不会被覆盖。所需的QoS始终包含在保留消息中，有时包含在查询消息中（有关详细信息，请参阅第4.3节）。
As described in Section 4.3, the QoS Available object may travel in a RESERVE message, RESPONSE Message, or QUERY message and may collect information on the resources currently available on the path. In this case, QoS Available is a read-write object, which means the QSPEC parameters contained in QoS Available may be updated, but they cannot be deleted. As such, each QNE MUST inspect all parameters of this QSPEC object, and if resources available to this QNE are less than what a particular parameter says currently, the QNE MUST adapt this parameter accordingly. Hence, when the message arrives at the recipient of the message, <QoS Available> reflects the bottleneck of the resources currently available on a path. It can be used in a QUERY message, for example, to collect the available resources along a data path.
如第4.3节所述，QoS可用对象可在保留消息、响应消息或查询消息中移动，并可收集路径上当前可用资源的信息。在这种情况下，QoS Available是一个读写对象，这意味着QoS Available中包含的QSPEC参数可以更新，但不能删除。因此，每个QNE必须检查此QSPEC对象的所有参数，如果此QNE的可用资源少于当前特定参数所述的资源，则QNE必须相应地调整此参数。因此，当消息到达消息的接收者时，<QoS Available>反映了路径上当前可用资源的瓶颈。例如，可以在查询消息中使用它来收集数据路径上的可用资源。
When QoS Available travels in a RESPONSE message, it in fact just transports the result of a previous measurement performed by a RESERVE or QUERY message back to the initiator. Therefore, in this
当QoS Available在响应消息中传输时，它实际上只是将保留或查询消息执行的先前测量的结果传输回启动器。所以在这个
case, QoS Available is read-only. In one other instance described in Section 4.3.2 (Case 3), QoS Available is sent by the QNI in a RESERVE message as a read-only QSPEC object (see Section 4.3.2 for details).
在这种情况下，可用的QoS是只读的。在第4.3.2节（案例3）中描述的另一个实例中，QNI在保留消息中以只读QSPEC对象的形式发送QoS Available（可用QoS）（详情请参见第4.3.2节）。
The QoS Reserved object reflects the resources that are being reserved. It is a read-only object and is always included in a RESPONSE message if QoS Desired is included in the RESERVE message (see Section 4.3 for details).
QoS保留对象反映正在保留的资源。它是一个只读对象，如果保留消息中包含所需的QoS，则始终包含在响应消息中（有关详细信息，请参阅第4.3节）。
Minimum QoS does not have an equivalent in RSVP. It allows the QNI to define a range of acceptable QoS levels by including both the desired QoS value and the minimum acceptable QoS in the same message. Note that the term "minimum" is used generically, since for some parameters, such as loss rate and latency, what is specified is the maximum acceptable value. It is a read-only object, and may be included in a RESERVE message, RESPONSE message, or QUERY message (see Section 4.3 for details). The desired QoS is included with a QoS Desired and/or a QoS Available QSPEC object seeded to the desired QoS value. The minimum acceptable QoS value MAY be coded in the Minimum QoS QSPEC object. As the message travels towards the QNR, QoS Available is updated by QNEs on the path. If its value drops below the value of Minimum QoS, the reservation fails and is aborted. When this method is employed, the QNR signals back to the QNI the value of QoS Available attained in the end, because the reservation may need to be adapted accordingly (see Section 4.3 for details).
RSVP中没有等效的最低QoS。它允许QNI通过在同一消息中包含所需的QoS值和最小可接受QoS来定义可接受QoS级别的范围。请注意，术语“最小值”一般使用，因为对于某些参数，如丢失率和延迟，指定的是最大可接受值。它是只读对象，可以包含在保留消息、响应消息或查询消息中（有关详细信息，请参阅第4.3节）。所需QoS包括在所需QoS和/或QoS可用QSPEC对象中，该QSPEC对象被播种到所需QoS值。最小可接受QoS值可以编码在最小QoS QSPEC对象中。当消息向QNR传输时，可用QoS由路径上的QNE更新。如果其值低于最小QoS值，则保留将失败并中止。当采用此方法时，QNR向QNI发回最终获得的可用QoS值，因为可能需要相应地调整预留（详情见第4.3节）。
Note that the relationship of QSPEC objects to RSVP objects is covered in Appendix A.
请注意，QSPEC对象与RSVP对象的关系见附录A。
QSPEC parameters provide a common language for building QSPEC objects. This document defines a number of QSPEC parameters; additional parameters may be defined in separate QOSM specification documents. For example, QSPEC parameters are defined in [RFC5976] and [RFC5977].
QSPEC参数为构建QSPEC对象提供了一种通用语言。本文件定义了许多QSPEC参数；其他参数可在单独的QOSM规范文件中定义。例如，[RFC5976]和[RFC5977]中定义了QSPEC参数。
One QSPEC parameter, <TMOD>, is special. It provides a description of the traffic for which resources are reserved. This parameter must be included by the QNI, and it must be interpreted by all QNEs. All other QSPEC parameters are populated by a QNI if they are applicable to the underlying QoS desired. For these QSPEC parameters, the QNI sets the M flag if they must be interpreted by downstream QNEs. If QNEs cannot interpret the parameter, the reservation fails. QSPEC parameters populated by a QNI without the M flag set should be interpreted by downstream QNEs, but may be ignored if not understood.
一个QSPEC参数<TMOD>，是特殊的。它提供了为其保留资源的通信量的描述。该参数必须包含在QNI中，并且必须由所有QNE解释。所有其他QSPEC参数都由QNI填充，如果它们适用于所需的底层QoS。对于这些QSPEC参数，如果必须由下游QNE解释，QNI将设置M标志。如果QNE无法解释参数，则保留失败。由不带M标志集的QNI填充的QSPEC参数应由下游QNE解释，但如果不理解，可以忽略。
In this document, the term 'interpret' means, in relation to RMF processing of QSPEC parameters, that the RMF processes the QSPEC parameter according to the commonly accepted normative procedures specified by references given for each QSPEC parameter. Note that a QNE need only interpret a QSPEC parameter if it is populated in the QSPEC object by the QNI; if not populated in the QSPEC, the QNE does not interpret it of course.
在本文件中，“解释”一词是指，就QSPEC参数的RMF处理而言，RMF根据每个QSPEC参数的参考文献规定的普遍接受的规范程序处理QSPEC参数。请注意，如果QNI在QSPEC对象中填充了QSPEC参数，则QNE只需解释该参数；如果QSPEC中没有填充，QNE当然不会解释它。
Note that when an ingress QNE in a local domain defines a Local QSPEC and encapsulates the Initiator QSPEC, the QNEs in the interior local domain need only process the Local QSPEC and can ignore the Initiator (encapsulated) QSPEC. However, edge QNEs in the local domain indeed must interpret the QSPEC parameters populated in the Initiator QSPEC with the M flag set and should interpret QSPEC parameters populated in the Initiator QSPEC without the M flag set.
注意，当本地域中的入口QNE定义本地QSPEC并封装启动器QSPEC时，内部本地域中的QNE只需要处理本地QSPEC，并且可以忽略启动器（封装）QSPEC。但是，本地域中的边缘QNE确实必须解释在带有M标志集的启动器QSPEC中填充的QSPEC参数，并且应该解释在没有M标志集的启动器QSPEC中填充的QSPEC参数。
As described in the previous section, QoS parameters may be overwritten depending on which QSPEC object and which message they appear in.
如前一节所述，QoS参数可能会被覆盖，具体取决于哪个QSPEC对象以及它们出现在哪个消息中。
The <Traffic Model> (TMOD) parameter is mandatory for the QNI to include in the Initiator QSPEC and mandatory for downstream QNEs to interpret. The traffic description specified by the TMOD parameter is a container consisting of 5 sub-parameters [RFC2212]:
<Traffic Model>（TMOD）参数对于QNI必须包含在启动器QSPEC中，对于下游QNE必须进行解释。TMOD参数指定的流量描述是由5个子参数[RFC2212]组成的容器：
o rate (r) specified in octets per second o bucket size (b) specified in octets o peak rate (p) specified in octets per second o minimum policed unit (m) specified in octets o maximum packet size (MPS) specified in octets
o 以八位字节/秒为单位指定的速率（r）o以八位字节/秒为单位指定的存储桶大小（b）o以八位字节/秒为单位指定的峰值速率（p）o以八位字节为单位指定的最小策略单位（m）o以八位字节为单位指定的最大数据包大小（MPS）
The TMOD parameter takes the form of a token bucket of rate (r) and bucket size (b), plus a peak rate (p), minimum policed unit (m), and maximum packet size (MPS).
TMOD参数的形式为速率（r）和桶大小（b）的令牌桶，加上峰值速率（p）、最小策略单位（m）和最大数据包大小（MPS）。
Both b and r MUST be positive. The rate, r, is measured in octets of IP packets per second, and can range from 1 octet per second to as large as 40 teraoctets per second. The bucket depth, b, is also measured in octets and can range from 1 octet to 250 gigaoctets. The peak rate, p, is measured in octets of IP packets per second and has the same range and suggested representation as the bucket rate.
b和r都必须为正。速率r以每秒IP数据包的八位字节为单位，其范围从每秒1个八位字节到每秒40兆八位字节。铲斗深度b也以八位字节为单位进行测量，范围从1个八位字节到250千兆八位字节。峰值速率p以每秒IP数据包的八位字节为单位，其范围和建议表示形式与桶速率相同。
The peak rate is the maximum rate at which the source and any reshaping (defined below) may inject bursts of traffic into the network. More precisely, it is a requirement that for all time periods the amount of data sent cannot exceed MPS+pT, where MPS is
峰值速率是源和任何重塑（定义如下）可能向网络注入突发流量的最大速率。更准确地说，要求在所有时间段内发送的数据量不得超过MPS+pT，其中MPS为
the maximum packet size and T is the length of the time period. Furthermore, p MUST be greater than or equal to the token bucket rate, r. If the peak rate is unknown or unspecified, then p MUST be set to infinity.
最大数据包大小，T是时间段的长度。此外，p必须大于或等于令牌桶速率r。如果峰值速率未知或未指定，则p必须设置为无穷大。
The minimum policed unit, m, is an integer measured in octets. All IP packets less than size m will be counted, when policed and tested for conformance to the TMOD, as being of size m.
最小策略单位m是以八位字节为单位的整数。当对所有小于大小m的IP数据包进行策略和测试，以确定其是否符合TMOD时，将其统计为大小为m的数据包。
The maximum packet size, MPS, is the biggest packet that will conform to the traffic specification; it is also measured in octets. The flow MUST be rejected if the requested maximum packet size is larger than the MTU of the link. Both m and MPS MUST be positive, and m MUST be less than or equal to MPS.
最大数据包大小MPS是符合流量规范的最大数据包；它也以八位字节为单位。如果请求的最大数据包大小大于链路的MTU，则必须拒绝该流。m和MPS都必须为正，并且m必须小于或等于MPS。
Policing compares arriving traffic against the TMOD parameters at the edge of the network. Traffic is policed to ensure it conforms to the token bucket. Reshaping attempts to restore the (possibly distorted) traffic's shape to conform to the TMOD parameters, and traffic that is in violation of the TMOD is discovered because the reshaping fails and the reshaping buffer overflows.
监控将到达的流量与网络边缘的TMOD参数进行比较。对流量进行策略，以确保其符合令牌桶。整形尝试恢复（可能扭曲的）流量的形状以符合TMOD参数，并且发现违反TMOD的流量，因为整形失败且整形缓冲区溢出。
The token bucket and peak rate parameters require that traffic MUST obey the rule that over all time periods, the amount of data sent cannot exceed MPS+min[pT, rT+b-MPS], where r and b are the token bucket parameters, MPS is the maximum packet size, and T is the length of the time period (note that when p is infinite, this reduces to the standard token bucket requirement). For the purposes of this accounting, links MUST count packets that are smaller than the minimum policing unit as being of size m. Packets that arrive at an element and cause a violation of the MPS + min[pT, rT+b-MPS] bound are considered non-conformant.
令牌桶和峰值速率参数要求流量必须遵守以下规则：在所有时间段内，发送的数据量不得超过MPS+min[pT，rT+b-MPS]，其中r和b是令牌桶参数，MPS是最大数据包大小，T是时间段的长度（请注意，当p为无穷大时，这将降低到标准令牌桶要求）。为了进行此记帐，链路必须将小于最小策略单位的数据包计数为大小为m的数据包。到达元素并导致违反MPS+min[pT，rT+b-MPS]界限的数据包被视为不符合。
All 5 of the sub-parameters MUST be included in the TMOD parameter. The TMOD parameter can be set to describe the traffic source. If, for example, TMOD is set to specify bandwidth only, then set r = peak rate = p, b = large, and m = large. As another example, if TMOD is set for TCP traffic, then set r = average rate, b = large, and p = large.
TMOD参数中必须包含所有5个子参数。可以设置TMOD参数来描述交通源。例如，如果TMOD设置为仅指定带宽，则设置r=峰值速率=p，b=大，m=大。作为另一个示例，如果为TCP流量设置TMOD，则设置r=平均速率，b=大，p=大。
When the 5 TMOD sub-parameters are included in QoS Available, they provide information, for example, about the TMOD resources available along the path followed by a data flow. The value of TMOD at a QNE is an estimate of the TMOD resources the QNE has available for packets following the path up to the next QNE, including its outgoing link, if this link exists. Furthermore, the QNI MUST account for the resources of the ingress link, if this link exists. Computation of
当5个TMOD子参数包含在QoS Available中时，它们提供信息，例如，关于沿着数据流之后的路径可用的TMOD资源。QNE处的TMOD值是QNE对沿着路径到达下一个QNE的数据包可用的TMOD资源的估计，包括其传出链路（如果该链路存在）。此外，如果入口链路存在，QNI必须说明入口链路的资源。计算
the value of this parameter SHOULD take into account all information available to the QNE about the path, taking into consideration administrative and policy controls, as well as physical resources.
此参数的值应考虑QNE可用的有关路径的所有信息，同时考虑管理和策略控制以及物理资源。
The output composed value is the minimum of the QNE's value and the input composed value for r, b, p, and MPS, and the maximum of the QNE's value and the input composed value for m. This quantity, when composed end-to-end, informs the QNR (or QNI in a RESPONSE message) of the minimal TMOD resources along the path from QNI to QNR.
对于r、b、p和MPS，输出合成值是QNE值和输入合成值的最小值，对于m，输出合成值是QNE值和输入合成值的最大值。该数量在端到端合成时，通知QNR（或响应消息中的QNI）从QNI到QNR路径上的最小TMOD资源。
Two TMOD parameters are defined in Section 5, <TMOD-1> and <TMOD-2>, where the second parameter (<TMOD-2>) is specified as could be needed to support some Diffserv applications. For example, it is typically assumed that Diffserv Expedited Forwarding (EF) traffic is shaped at the ingress by a single rate token bucket. Therefore, a single TMOD parameter is sufficient to signal Diffserv EF traffic. However, for Diffserv Assured Forwarding (AF) traffic, two sets of token bucket parameters are needed -- one for the average traffic and one for the burst traffic. [RFC2697] defines a Single Rate Three Color Marker (srTCM), which meters a traffic stream and marks its packets according to three traffic parameters, Committed Information Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be either green, yellow, or red. A packet is marked green if it does not exceed the CBS; yellow if it does exceed the CBS, but not the EBS; and red otherwise. [RFC2697] defines specific procedures using two token buckets that run at the same rate. Therefore, 2 TMOD parameters are sufficient to distinguish among 3 levels of drop precedence. An example is also described in the Appendix to [RFC2597].
第5节<TMOD-1>和<TMOD-2>中定义了两个TMOD参数，其中第二个参数（<TMOD-2>）被指定为支持某些区分服务应用程序所需的参数。例如，通常假设Diffserv加速转发（EF）业务在入口由单速率令牌桶成形。因此，单个TMOD参数足以发出Diffserv EF通信量的信号。然而，对于Diffserv Assured Forwarding（AF）流量，需要两组令牌桶参数——一组用于平均流量，另一组用于突发流量。[RFC2697]定义了一个单速率三色标记（srTCM），该标记根据三个流量参数（提交信息速率（CIR）、提交突发大小（CBS）和多余突发大小（EBS）测量流量流并标记其数据包，即绿色、黄色或红色。如果数据包未超过CBS，则标记为绿色；如果超过CBS，但不超过EBS，则为黄色；而红色则不然。[RFC2697]使用以相同速率运行的两个令牌存储桶定义特定过程。因此，2个TMOD参数足以区分3个丢弃优先级级别。[RFC2597]的附录中还描述了一个示例。
<Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QSPEC parameters describing the desired path latency, path jitter, packet loss ratio, and path packet error ratio, respectively. Since these parameters are cumulative, an individual QNE cannot decide whether the desired path latency, etc., is available, and hence they cannot decide whether a reservation fails. Rather, when these parameters are included in <Desired QoS>, the QNI SHOULD also include corresponding parameters in a QoS Available QSPEC object in order to facilitate collecting this information.
<Path Latency>、<Path Jitter>、<Path PLR>和<Path PER>分别是描述所需路径延迟、路径抖动、分组丢失率和路径分组错误率的QSPEC参数。由于这些参数是累积的，单个QNE无法决定所需的路径延迟等是否可用，因此它们无法决定保留是否失败。相反，当这些参数包括在<期望的QoS>中时，QNI还应该在QoS可用的QSPEC对象中包括相应的参数，以便于收集该信息。
The <Path Latency> parameter accumulates the latency of the packet forwarding process associated with each QNE, where the latency is defined to be the mean packet delay, measured in microseconds, added by each QNE. This delay results from the combination of link propagation delay, packet processing, and queuing. Each QNE MUST add the propagation delay of its outgoing link, if this link exists.
<Path Latency>参数累积与每个QNE相关联的分组转发过程的延迟，其中延迟被定义为每个QNE加上的平均分组延迟（以微秒为单位）。这种延迟是链路传播延迟、数据包处理和排队的综合结果。每个QNE必须添加其传出链路的传播延迟（如果该链路存在）。
Furthermore, the QNI SHOULD add the propagation delay of the ingress link, if this link exists. The composition rule for the <Path Latency> parameter is summation with a clamp of (2^32) - 1 on the maximum value. This quantity, when composed end-to-end, informs the QNR (or QNI in a RESPONSE message) of the minimal packet delay along the path from QNI to QNR. The purpose of this parameter is to provide a minimum path latency for use with services that provide estimates or bounds on additional path delay [RFC2212].
此外，如果入口链路存在，QNI应增加该链路的传播延迟。<Path Latency>参数的组合规则是在最大值上使用（2^32）-1的钳位求和。该数量在端到端合成时，通知QNR（或响应消息中的QNI）从QNI到QNR路径上的最小数据包延迟。此参数的目的是提供最小路径延迟，以便与提供额外路径延迟估计值或边界的服务一起使用[RFC2212]。
The <Path Jitter> parameter accumulates the jitter of the packet forwarding process associated with each QNE, where the jitter is defined to be the nominal jitter, measured in microseconds, added by each QNE. IP packet jitter, or delay variation, is defined in [RFC3393], Section 3.4 (Type-P-One-way-ipdv), and where the [RFC3393] selection function includes the packet with minimum delay such that the distribution is equivalent to 2-point delay variation in [Y.1540]. The suggested evaluation interval is 1 minute. This jitter results from packet-processing limitations, and includes any variable queuing delay that may be present. Each QNE MUST add the jitter of its outgoing link, if this link exists. Furthermore, the QNI SHOULD add the jitter of the ingress link, if this link exists. The composition method for the <Path Jitter> parameter is the combination of several statistics describing the delay variation distribution with a clamp on the maximum value (note that the methods of accumulation and estimation of nominal QNE jitter are specified in clause 8 of [Y.1541]). This quantity, when composed end-to-end, informs the QNR (or QNI in a RESPONSE message) of the nominal packet jitter along the path from QNI to QNR. The purpose of this parameter is to provide a nominal path jitter for use with services that provide estimates or bounds on additional path delay [RFC2212].
<Path Jitter>参数累积与每个QNE相关联的分组转发过程的抖动，其中抖动被定义为每个QNE加上的标称抖动（以微秒为单位）。IP数据包抖动或延迟变化在[RFC3393]第3.4节（类型-P-单向-ipdv）中定义，[RFC3393]选择功能包括具有最小延迟的数据包，使得分布相当于[Y.1540]中的两点延迟变化。建议的评估间隔为1分钟。这种抖动是由数据包处理限制引起的，包括可能存在的任何可变排队延迟。如果存在该链路，每个QNE必须添加其传出链路的抖动。此外，如果存在入口链路，QNI应增加入口链路的抖动。<Path Jitter>参数的合成方法是描述延迟变化分布的几种统计数据与钳制最大值的组合（注意，[Y.1541]第8条规定了累积和估计标称QNE抖动的方法）。该数量在端到端合成时，通知QNR（或响应消息中的QNI）从QNI到QNR路径上的标称数据包抖动。此参数的目的是提供标称路径抖动，用于提供额外路径延迟估计值或边界的服务[RFC2212]。
The <Path PLR> parameter is the unit-less ratio of total lost IP packets to total transmitted IP packets. <Path PLR> accumulates the packet loss ratio (PLR) of the packet-forwarding process associated with each QNE, where the PLR is defined to be the PLR added by each QNE. Each QNE MUST add the PLR of its outgoing link, if this link exists. Furthermore, the QNI MUST add the PLR of the ingress link, if this link exists. The composition rule for the <Path PLR> parameter is summation with a clamp on the maximum value. (This assumes sufficiently low PLR values such that summation error is not significant; however, a more accurate composition function is specified in clause 8 of [Y.1541].) This quantity, when composed end-to-end, informs the QNR (or QNI in a RESPONSE message) of the minimal packet PLR along the path from QNI to QNR.
<Path PLR>参数是丢失的IP数据包总数与传输的IP数据包总数的单位减去比率<Path PLR>累积与每个QNE相关联的分组转发过程的分组丢失率（PLR），其中PLR被定义为每个QNE添加的PLR。每个QNE必须添加其传出链路的PLR（如果该链路存在）。此外，如果入口链路存在，QNI必须添加入口链路的PLR。<Path PLR>参数的合成规则是用钳制最大值求和。（这假设PLR值足够低，因此求和误差不显著；然而，[Y.1541]第8条中规定了更精确的合成函数。）该数量在端到端合成时，通知QNR（或响应消息中的QNI）从QNI到QNR路径上的最小数据包PLR。
Packet error ratio [Y.1540, Y.1541] is the unit-less ratio of total errored IP packet outcomes to the total of successful IP packet transfer outcomes plus errored IP packet outcomes in a population of
数据包错误率[Y.1540，Y.1541]是总错误IP数据包结果与总成功IP数据包传输结果加上总错误IP数据包结果的单位减去比率
interest, with a resolution of at least 10^-9. If lesser resolution is available in a value, the unused digits MUST be set to zero. Note that the number of errored packets observed is directly related to the confidence in the result. The <Path PER> parameter accumulates the packet error ratio (PER) of the packet forwarding process associated with each QNE, where the PER is defined to be the PER added by each QNE. Each QNE MUST add the PER of its outgoing link, if this link exists. Furthermore, the QNI SHOULD add the PER of the ingress link, if this link exists. The composition rule for the <Path PER> parameter is summation with a clamp on the maximum value. (This assumes sufficiently low PER values such that summation error is not significant; however, a more accurate composition function is specified in clause 8 of [Y.1541].) This quantity, when composed end-to-end, informs the QNR (or QNI in a RESPONSE message) of the minimal packet PER along the path from QNI to QNR.
利息，决议至少为10^-9。如果某个值的分辨率较低，则未使用的数字必须设置为零。请注意，观察到的错误数据包的数量与结果的可信度直接相关。<Path PER>参数累积与每个QNE相关联的分组转发过程的分组错误率（PER），其中PER被定义为每个QNE添加的PER。每个QNE必须添加其传出链接的PER（如果存在此链接）。此外，如果存在入口链路，QNI应添加入口链路的PER。<Path PER>参数的组合规则是使用最大值上的钳制求和。（这假设PER值足够低，因此求和误差不显著；然而，[Y.1541]第8条中规定了更精确的合成函数）。当端到端合成时，该数量通知QNR（或响应消息中的QNI）从QNI到QNR路径上的最小PER数据包。
The slack term parameter is the difference between desired delay and delay obtained by using bandwidth reservation, and it is used to reduce the resource reservation for a flow [RFC2212].
slack term参数是期望延迟和通过使用带宽预留获得的延迟之间的差值，用于减少流的资源预留[RFC2212]。
An application MAY like to reserve resources for packets and also specify a specific traffic-handling behavior, such as <Excess Treatment>. In addition, as discussed in Section 3.1, an application MAY like to define RMF triggers that cause the QoS NSLP to run semantics within the underlying QoS NSLP signaling state / messaging processing rules, as defined in Section 5.2 of [RFC5974]. Note, however, that new QoS NSLP message processing rules can only be defined in extensions to the QoS NSLP. As with constraints parameters and other QSPEC parameters, Traffic Handling Directives parameters may be defined in QOSM specifications in order to provide support for QOSM-specific resource management functions. Such QOSM-specific parameters are already defined, for example, in [RFC5976], [RFC5977], and [CL-QOSM]. Generally, a Traffic Handling Directives parameters is expected to be set by the QNI in <QoS Desired>, and to not be included in <QoS Available>. If such a parameter is included in <QoS Available>, QNEs may change their value.
应用程序可能希望为数据包保留资源，并且还指定特定的流量处理行为，例如<过度处理>。此外，如第3.1节所述，应用程序可能希望定义RMF触发器，使QoS NSLP在[RFC5974]第5.2节中定义的基础QoS NSLP信令状态/消息处理规则内运行语义。但是，请注意，新的QoS NSLP消息处理规则只能在QoS NSLP的扩展中定义。与约束参数和其他QSPEC参数一样，可以在QOSM规范中定义流量处理指令参数，以便为QOSM特定的资源管理功能提供支持。例如，在[RFC5976]、[RFC5977]和[CL-QOSM]中已经定义了此类QOSM特定参数。通常，流量处理指令参数预期由QNI在<QoS Desired>中设置，而不包括在<QoS Available>中。如果<QoS Available>中包含此类参数，QNE可能会更改其值。
The <Preemption Priority> parameter is the priority of the new flow compared with the <Defending Priority> of previously admitted flows. Once a flow is admitted, the preemption priority becomes irrelevant. The <Defending Priority> parameter is used to compare with the preemption priority of new flows. For any specific flow, its preemption priority MUST always be less than or equal to the defending priority. <Admission Priority> and <RPH Priority> provide an essential way to differentiate flows for emergency services, Emergency Telecommunications Service (ETS), E911, etc., and assign
<Preemption Priority>参数是新流的优先级，与先前允许的流的<Defension Priority>相比。一旦允许流，抢占优先级就变得无关紧要了。<Defensing Priority>参数用于与新流的抢占优先级进行比较。对于任何特定流，其抢占优先级必须始终小于或等于防御优先级<准入优先级>和<RPH优先级>提供了区分紧急服务、紧急电信服务（ETS）、E911等流量的基本方法，并分配
them a higher admission priority than normal priority flows and best-effort priority flows.
它们的接纳优先级高于正常优先级流和尽力而为优先级流。
The <Excess Treatment> parameter describes how the QNE will process out-of-profile traffic. Excess traffic MAY be dropped, shaped, and/or re-marked.
<Overse Treatment>参数描述QNE将如何处理不符合配置文件的流量。多余的流量可能会被丢弃、成形和/或重新标记。
An application MAY like to reserve resources for packets with a particular Diffserv per-hop behavior (PHB) [RFC2475]. Note that PHB class is normally set by a downstream QNE to tell the QNI how to mark traffic to ensure the treatment that is designated by admission control; however, setting of the parameter by the QNI is not precluded. An application MAY like to reserve resources for packets with a particular QoS class, e.g., Y.1541 QoS class [Y.1541] or Diffserv-aware MPLS traffic engineering (DSTE) class type [RFC3564, RFC4124]. These parameters are useful in various QOSMs, e.g., [RFC5976], [RFC5977], and other QOSMs yet to be defined (e.g., DSTE-QOSM). This is intended to provide guidelines to QOSMs on how to encode these parameters; use of the PHB class parameter is illustrated in the example in the following section.
应用程序可能希望为具有特定区分服务每跳行为（PHB）的数据包保留资源[RFC2475]。请注意，PHB等级通常由下游QNE设置，以告知QNI如何标记交通量，以确保进入控制指定的处理；但是，不排除通过QNI设置参数。应用程序可能希望为具有特定QoS类别的分组保留资源，例如，Y.1541qos类别[Y.1541]或区分服务感知MPLS流量工程（DSTE）类别类型[RFC3564，RFC4124]。这些参数在各种QOSM中非常有用，例如[RFC5976]、[RFC5977]和其他尚未定义的QOSM（例如DSTE-QOSM）。这旨在为QOSMs提供关于如何编码这些参数的指南；PHB类参数的使用在下一节的示例中进行了说明。
This section illustrates the operation and use of the QSPEC within the NSLP. The example configuration in shown in Figure 2.
本节说明了NSLP中QSPEC的操作和使用。中的示例配置如图2所示。
+----------+ /-------\ /--------\ /--------\
| Laptop | | Home | | Cable | | Diffserv |
| Computer |-----| Network |-----| Network |-----| Network |----+
+----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | |
\-------/ \--------/ \--------/ |
|
+-----------------------------------------------+
|
| /--------\ +----------+
| | XG | | Handheld |
+---| Wireless |-----| Device |
| XG QOSM | +----------+
\--------/
+----------+ /-------\ /--------\ /--------\
| Laptop | | Home | | Cable | | Diffserv |
| Computer |-----| Network |-----| Network |-----| Network |----+
+----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | |
\-------/ \--------/ \--------/ |
|
+-----------------------------------------------+
|
| /--------\ +----------+
| | XG | | Handheld |
+---| Wireless |-----| Device |
| XG QOSM | +----------+
\--------/
Figure 2: Example Configuration of QoS-NSLP/QSPEC Operation
图2:QoS NSLP/QSPEC操作的示例配置
In this configuration, a laptop computer and a handheld wireless device are the endpoints for some application that has QoS requirements. Assume initially that the two endpoints are stationary during the application session, later we consider mobile endpoints.
在此配置中，笔记本电脑和手持无线设备是具有QoS要求的某些应用程序的端点。假设最初两个端点在应用会话期间是固定的，稍后我们考虑移动端点。
For this session, the laptop computer is connected to a home network that has no QoS support. The home network is connected to a CableLabs-type cable access network with dynamic QoS (DQOS) support, such as specified in the [DQOS] for cable access networks. That network is connected to a Diffserv core network that uses the Resource Management in Diffserv QoS Model [RFC5977]. On the other side of the Diffserv core is a wireless access network built on generation "X" technology with QoS support as defined by generation "X". And finally, the handheld endpoint is connected to the wireless access network.
对于此会话，笔记本电脑连接到不支持QoS的家庭网络。家庭网络连接到具有动态QoS（DQOS）支持的CableLabs类型的电缆接入网络，如[DQOS]中针对电缆接入网络的规定。该网络连接到使用Diffserv QoS模型[RFC5977]中的资源管理的Diffserv核心网络。Diffserv核心的另一端是基于X代技术构建的无线接入网络，其QoS支持由X代定义。最后，手持终端连接到无线接入网络。
We assume that the laptop is the QNI, and the handheld device is the QNR. The QNI will signal an Initiator QSPEC object to achieve the QoS desired on the path.
我们假设笔记本电脑是QNI，手持设备是QNR。QNI将向启动器QSPEC对象发送信号，以实现路径上所需的QoS。
The QNI sets QoS Desired, QoS Available, and possibly Minimum QoS QSPEC objects in the Initiator QSPEC, and initializes QoS Available to QoS Desired. Each QNE on the path reads and interprets those parameters in the Initiator QSPEC and checks to see if QoS Available resources can be reserved. If not, the QNE reduces the respective parameter values in QoS Available and reserves these values. The minimum parameter values are given in Minimum QoS, if populated; they are zero if Minimum QoS is not included. If one or more parameters in QoS Available fails to satisfy the corresponding minimum values in Minimum QoS, the QNE generates a RESPONSE message to the QNI and the reservation is aborted. Otherwise, the QNR generates a RESPONSE to the QNI with the QoS Available for the reservation. If a QNE cannot reserve QoS Desired resources, the reservation fails.
QNI在启动器QSPEC中设置所需QoS、可用QoS和可能的最小QoS QSPEC对象，并初始化所需QoS的可用QoS。路径上的每个QNE读取并解释启动器QSPEC中的这些参数，并检查QoS可用资源是否可以保留。否则，QNE将减少QoS Available中的各个参数值并保留这些值。最小参数值在最小QoS中给出（如果填充）；如果不包括最低QoS，则它们为零。如果QoS Available中的一个或多个参数未能满足minimum QoS中相应的最小值，则QNE向QNI生成响应消息，并中止保留。否则，QNR生成对QNI的响应，其中QoS可用于预订。如果QNE无法保留所需的QoS资源，则保留失败。
The QNI populates QSPEC parameters to ensure correct treatment of its traffic in domains down the path. Let us assume the QNI wants to achieve QoS guarantees similar to IntServ Controlled Load service, and also is interested in what path latency it can achieve. 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参数，以确保正确处理路径中域中的流量。让我们假设QNI想要实现类似于IntServ控制的负载服务的QoS保证，并且对它能够实现的路径延迟感兴趣。此外，为确保进一步正确治疗，QNI在<QoS Desired>中包括<PHB Class>。因此，QNI包括在QSPEC中
QoS Desired = <TMOD> <PHB Class>
QoS Available = <TMOD> <Path Latency>
QoS Desired = <TMOD> <PHB Class>
QoS Available = <TMOD> <Path Latency>
Since <Path Latency> and <PHB Class> are not vital parameters from the QNI's perspective, it does not raise their M flags.
由于从QNI的角度来看，<Path Latency>和<PHB Class>不是重要参数，因此它不会提高它们的M标志。
There are three possibilities when a RESERVE message is received at a QNE at a domain border; they are described in the example:
当在域边界的QNE处接收到保留消息时，有三种可能性；示例中描述了它们：
- the QNE just leaves the QSPEC as is.
- QNE只是让QSPEC保持原样。
- the QNE can add a Local QSPEC and encapsulate the Initiator QSPEC (see discussion in Section 4.1; this is new in QoS NSLP -- RSVP does not do this).
- QNE可以添加本地QSPEC并封装启动器QSPEC（参见第4.1节中的讨论；这在QoS NSLP中是新的——RSVP不这样做）。
- the QNE can 'hide' the initiator RESERVE message so that only the edge QNE processes the initiator RESERVE message, which then bypasses intermediate nodes between the edges of the domain and issues its own local RESERVE message (see Section 3.3.1 of [RFC5974]). For this new local RESERVE message, the QNE acts as the QNI, and the QSPEC in the domain is an Initiator QSPEC. A similar procedure is also used by RSVP in making aggregate reservations, in which case there is not a new intra-domain (aggregate) RESERVE for each newly arriving inter-domain (per-flow) RESERVE, but the aggregate reservation is updated by the border QNE (or QNI) as need be. This is also how RMD works [RFC5977].
- QNE可以“隐藏”启动器保留消息，以便只有边缘QNE处理启动器保留消息，然后绕过域边缘之间的中间节点并发出自己的本地保留消息（参见[RFC5974]第3.3.1节）。对于这个新的本地保留消息，QNE充当QNI，域中的QSPEC是发起方QSPEC。RSVP在进行聚合保留时也使用类似的程序，在这种情况下，对于每个新到达的域间（每流）保留，没有新的域内（聚合）保留，但聚合保留由边界QNE（或QNI）根据需要更新。这也是RMD的工作原理[RFC5977]。
For example, at the RMD domain, a local RESERVE with its own RMD Initiator 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 [RFC5977]. The ingress QNE to the RMD domain maps the TMOD parameters contained in the original Initiator QSPEC to the equivalent TMOD parameter representing only the peak bandwidth in the Local QSPEC. The local RMD QSPEC for example also needs <PHB Class>, which in this case was provided by the QNI.
例如，在RMD域，根据[RFC5974]第4.5节和[RFC5977]中所述的程序，基于原始启动器QSPEC生成具有与RMD-QOSM相对应的自身RMD启动器QSPEC的本地保留。RMD域的入口QNE将原始启动器QSPEC中包含的TMOD参数映射到仅表示本地QSPEC中的峰值带宽的等效TMOD参数。例如，本地RMD QSPEC也需要<PHB类>，在这种情况下，这是由QNI提供的。
Furthermore, if the node can, at the egress to the RMD domain, it updates QoS Available on behalf of the entire RMD domain. If it cannot (since the M flag is not set for <Path Latency>), it raises the parameter-specific, Not Supported N flag, warning the QNR that the final latency value in QoS Available is imprecise.
此外，如果节点能够在RMD域出口处代表整个RMD域更新可用的QoS。如果不能（因为没有为<Path Latency>设置M标志），则会引发参数特定的、不受支持的N标志，警告QNR可用QoS中的最终延迟值不精确。
In the XG domain, the Initiator QSPEC is translated into a local QSPEC using a similar procedure as described above. The Local QSPEC becomes the current QSPEC used within the XG domain, and the Initiator QSPEC is encapsulated. This saves the QNEs within the XG domain the trouble of re-translating the Initiator QSPEC, and simplifies processing in the local domain. At the egress edge of the XG domain, the translated Local QSPEC is removed, and the Initiator QSPEC returns to the number one position.
在XG域中，使用如上所述的类似过程将启动器QSPEC转换为本地QSPEC。本地QSPEC成为XG域中使用的当前QSPEC，并且启动器QSPEC被封装。这为XG域内的QNE节省了重新转换启动器QSPEC的麻烦，并简化了本地域中的处理。在XG域的出口边缘，平移的本地QSPEC被移除，并且发起方QSPEC返回到第一位置。
If the reservation was successful, eventually the RESERVE request arrives at the QNR (otherwise, the QNE at which the reservation failed aborts the RESERVE and sends 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
如果保留成功，则保留请求最终到达QNR（否则，保留失败的QNE中止保留并向QNI发送错误响应）。如果RII包含在QoS NSLP消息中，QNR将生成一个肯定响应，其中QSPEC对象QoS Reserved和QoS Reserved
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:
可获得的QoS Reserved中出现的参数与QoS Desired中的参数相同，从QoS复制的值可用。因此，QNR在响应中包括以下QSPEC对象：
QoS Reserved = <TMOD> <PHB Class>
QoS Available = <TMOD> <Path Latency>
QoS Reserved = <TMOD> <PHB Class>
QoS Available = <TMOD> <Path Latency>
If the handheld device on the right of Figure 2 is mobile, and moves through different XG wireless networks, then the QoS might change on the path since different XG wireless networks might support different QOSMs. As a result, QoS NSLP/QSPEC processing will have to renegotiate the QoS Available on the path. From a QSPEC perspective, this is like a new reservation on the new section of the path and is basically the same as any other rerouting event -- to the QNEs on the new path, it looks like a new reservation. That is, in this mobile scenario, the new segment may support a different QOSM than the old segment, and the QNI would now signal a new reservation explicitly (or implicitly with the next refreshing RESERVE message) to account for the different QOSM in the XG wireless domain. Further details on rerouting are specified in [RFC5974].
如果图2右侧的手持设备是移动的，并且在不同的XG无线网络中移动，那么路径上的QoS可能会发生变化，因为不同的XG无线网络可能支持不同的QOSMs。因此，QoS NSLP/QSPEC处理必须重新协商路径上可用的QoS。从QSPEC的角度来看，这就像路径新部分上的一个新保留，基本上与任何其他重新路由事件相同——对于新路径上的QNE，它看起来像一个新保留。也就是说，在该移动场景中，新段可能支持与旧段不同的QOSM，并且QNI现在将显式（或隐式地使用下一个刷新保留消息）发出新保留信号，以说明XG无线域中的不同QOSM。[RFC5974]中规定了有关重新路由的更多详细信息。
For bit-level examples of QSPECs, see the documents specifying QOSMs: [CL-QOSM], [RFC5976], and [RFC5977].
有关QSpec的位级示例，请参阅指定QOSMs的文档：[CL-QOSM]、[RFC5976]和[RFC5977]。
Three flags are used in QSPEC processing, the M flag, E flag, and N flag, which are explained in this section. The QNI sets the M flag for each QSPEC parameter it populates that MUST be interpreted by downstream QNEs. If a QNE does not support the parameter, it sets the N flag and fails the reservation. If the QNE supports the parameter but cannot meet the resources requested by the parameter, it sets the E flag and fails the reservation.
QSPEC处理中使用了三个标志：M标志、E标志和N标志，本节对此进行了说明。QNI为其填充的每个必须由下游QNE解释的QSPEC参数设置M标志。如果QNE不支持该参数，它将设置N标志并使保留失败。如果QNE支持该参数，但无法满足该参数请求的资源，则会设置E标志并使保留失败。
If the M flag is not set, the downstream QNE SHOULD interpret the parameter. If the QNE does not support the parameter, it sets the N flag and forwards the reservation. If the QNE supports the parameter but cannot meet the resources requested by the parameter, it sets the E flag and fails the reservation.
如果未设置M标志，则下游QNE应解释该参数。如果QNE不支持该参数，它将设置N标志并转发保留。如果QNE支持该参数，但无法满足该参数请求的资源，则会设置E标志并使保留失败。
A QNE at the edge of a local domain may either a) translate the Initiator QSPEC into a Local QSPEC and encapsulate the Initiator QSPEC in the RESERVE message, or b) 'hide' the Initiator QSPEC through the local domain and reserve resources by generating a new
位于本地域边缘的QNE可以A）将启动器QSPEC转换为本地QSPEC并将启动器QSPEC封装在保留消息中，或者b）通过本地域“隐藏”启动器QSPEC并通过生成新消息来保留资源
RESERVE message through the local domain containing the Local QSPEC. In either case, the Initiator QSPEC parameters are interpreted at the local domain edges.
通过包含本地QSPEC的本地域保留消息。在任何一种情况下，都会在本地域边缘解释启动器QSPEC参数。
A Local QSPEC may allow a simpler control plane in a local domain. The edge nodes in the local domain must interpret the Initiator QSPEC parameters. They can either initiate a parallel session with Local QSPEC or define a Local QSPEC and encapsulate the Initiator QSPEC, as illustrated in Figure 3. The Initiator/Local QSPEC bit identifies whether the QSPEC is an Initiator QSPEC or a Local QSPEC. The QSPEC Type indicates, for example, that the initiator of the local QSPEC uses to a certain QOSM, e.g., CL-QSPEC Type. It may be useful for the QNI to signal a QSPEC Type based on some QOSM (which will necessarily entail populating certain QOSM-related parameters) so that a downstream QNE can chose amongst various QOSM-related processes it might have. That is, the QNI populates the QSPEC Type, e.g., CL-QSPEC Type and sets the Initiator/Local QSPEC bit to 'Initiator'. A local QNE can decide, for whatever reasons, to insert a Local QSPEC Type, e.g., RMD-QSPEC Type, and set the local QSPEC Type = RMD-QSPEC and set the Initiator/Local QSPEC bit to 'Local' (and encapsulate the Initiator QSPEC in the RESERVE or whatever NSLP message).
局部QSPEC允许在局部域中使用更简单的控制平面。本地域中的边缘节点必须解释启动器QSPEC参数。它们可以使用本地QSPEC启动并行会话，也可以定义本地QSPEC并封装启动器QSPEC，如图3所示。启动器/本地QSPEC位标识QSPEC是启动器QSPEC还是本地QSPEC。QSPEC类型指示，例如，本地QSPEC的发起方使用特定QOSM，例如CL-QSPEC类型。QNI基于一些QOSM（这必然需要填充某些QOSM相关参数）向QSPEC类型发送信号可能是有用的，以便下游QNE可以在其可能具有的各种QOSM相关过程中进行选择。也就是说，QNI填充QSPEC类型，例如CL-QSPEC类型，并将启动器/本地QSPEC位设置为“启动器”。本地QNE可以出于任何原因决定插入本地QSPEC类型，例如RMD-QSPEC类型，并将本地QSPEC类型设置为RMD-QSPEC，将启动器/本地QSPEC位设置为“本地”（并将启动器QSPEC封装在保留区或任何NSLP消息中）。
+--------------------------------+\
| QSPEC Type, QSPEC Procedure | \
+--------------------------------+ / Common QSPEC Header
| Init./Local QSPEC bit=Local |/
+================================+\
| Local-QSPEC Parameter 1 | \
+--------------------------------+ \
| .... | Local-QSPEC Parameters
+--------------------------------+ /
| Local-QSPEC Parameter n | /
+--------------------------------+/
| +----------------------------+ |
| | QSPEC Type, QSPEC Procedure| |
| +----------------------------+ |
| | Init./Local QSPEC bit=Init.| |
| +============================+ |
| | | | Encapsulated Initiator QSPEC
| | .... | |
| +----------------------------+ |
+--------------------------------+
+--------------------------------+\
| QSPEC Type, QSPEC Procedure | \
+--------------------------------+ / Common QSPEC Header
| Init./Local QSPEC bit=Local |/
+================================+\
| Local-QSPEC Parameter 1 | \
+--------------------------------+ \
| .... | Local-QSPEC Parameters
+--------------------------------+ /
| Local-QSPEC Parameter n | /
+--------------------------------+/
| +----------------------------+ |
| | QSPEC Type, QSPEC Procedure| |
| +----------------------------+ |
| | Init./Local QSPEC bit=Init.| |
| +============================+ |
| | | | Encapsulated Initiator QSPEC
| | .... | |
| +----------------------------+ |
+--------------------------------+
Figure 3: Defining a Local QSPEC
图3：定义本地QSPEC
Here the QoS-NSLP only sees and passes one QSPEC up to the RMF. Thus, the type of the QSPEC may change within a local domain. Hence:
在这里，QoS NSLP只看到并向RMF传递一个QSPEC。因此，QSPEC的类型可以在本地域内改变。因此：
o the QNI signals its QoS requirements with the Initiator QSPEC,
o QNI向启动器QSPEC发出其QoS要求的信号，
o the ingress edge QNE in the local domain translates the Initiator QSPEC parameters to equivalent parameters in the local QSPEC,
o 本地域中的入口边缘QNE将启动器QSPEC参数转换为本地QSPEC中的等效参数，
o the QNEs in the local domain only interpret the Local QSPEC parameters, and
o 本地域中的QNE仅解释本地QSPEC参数，以及
o the egress QNE in the local domain processes the Local QSPEC and also interprets the QSPEC parameters in the Initiator QSPEC.
o 本地域中的出口QNE处理本地QSPEC，并且还解释启动器QSPEC中的QSPEC参数。
The Local QSPEC MUST be consistent with the Initiator QSPEC. That is, it MUST NOT specify a lower level of resources than specified by the Initiator QSPEC. For example, in RMD the TMOD parameters contained in the original Initiator QSPEC are mapped to the equivalent TMOD parameter representing only the peak bandwidth in the Local QSPEC.
本地QSPEC必须与启动器QSPEC一致。也就是说，它不能指定低于启动器QSPEC指定的资源级别。例如，在RMD中，原始启动器QSPEC中包含的TMOD参数映射到仅表示本地QSPEC中的峰值带宽的等效TMOD参数。
Note that it is possible to use both a) hiding a QSPEC through a local domain by initiating a new RESERVE at the domain edge, and b) defining a Local QSPEC and encapsulating the Initiator QSPEC, as defined above. However, it is not expected that both the hiding and encapsulating functions would be used at the same time for the same flow.
注意，可以使用a）通过在域边缘发起新保留来通过本地域隐藏QSPEC，以及b）定义本地QSPEC并封装启动器QSPEC，如上所述。但是，对于同一个流，不希望同时使用隐藏函数和封装函数。
The support of Local QSPECs is illustrated in Figure 4 for a single flow to show where the Initiator and Local QSPECs are used. The QNI initiates an end-to-end, inter-domain QoS NSLP RESERVE message containing the Initiator QSPEC for the Y.1541 QOSM. As illustrated in Figure 4, the RESERVE message crosses multiple domains supporting different QOSMs. In this illustration, the Initiator QSPEC arrives in a QoS NSLP RESERVE message at the ingress node of the local-QOSM domain. At the ingress edge node of the local-QOSM domain, the end-to-end, inter-domain QoS-NSLP message triggers the generation of a Local QSPEC, and the Initiator QSPEC is encapsulated within the messages signaled through the local domain. The local QSPEC is used for QoS processing in the local-QOSM domain, and the Initiator QSPEC is used for QoS processing outside the local domain.
图4显示了对单个流的本地QSpec的支持，以显示在何处使用启动器和本地QSpec。QNI发起端到端的域间QoS NSLP保留消息，其中包含Y.1541 QOSM的启动器QSPEC。如图4所示，保留消息跨越支持不同QOSMs的多个域。在该图示中，发起方QSPEC在本地QOSM域的入口节点处到达QoS NSLP保留消息。在本地QOSM域的入口边缘节点，端到端、域间QoS NSLP消息触发本地QSPEC的生成，并且启动器QSPEC封装在通过本地域发信号的消息中。本地QSPEC用于本地QOSM域中的QoS处理，而启动器QSPEC用于本地域外的QoS处理。
In this example, the QNI sets <QoS Desired>, <Minimum QoS>, and <QoS
Available> objects to include objectives for the <Path Latency>,
<Path Jitter>, and <Path PER> parameters. The QNE / local domain
sets the cumulative parameters, e.g., <Path Latency>, that can be
achieved in the <QoS Available> object (but not less than specified
in <Minimum QoS>). If the <QoS Available> fails to satisfy one or
In this example, the QNI sets <QoS Desired>, <Minimum QoS>, and <QoS
Available> objects to include objectives for the <Path Latency>,
<Path Jitter>, and <Path PER> parameters. The QNE / local domain
sets the cumulative parameters, e.g., <Path Latency>, that can be
achieved in the <QoS Available> object (but not less than specified
in <Minimum QoS>). If the <QoS Available> fails to satisfy one or
more of the <Minimum QoS> objectives, the QNE / local domain notifies the QNI and the reservation is aborted. If any QNE cannot meet the requirements designated by the Initiator QSPEC to support a QSPEC parameter with the M bit set to zero, the QNE sets the N flag for that parameter to one. Otherwise, the QNR notifies the QNI of the <QoS Available> for the reservation.
更多的<Minimum QoS>目标，QNE/本地域通知QNI并中止保留。如果任何QNE不能满足启动器QSPEC指定的要求，以支持M位设置为零的QSPEC参数，则QNE将该参数的N标志设置为1。否则，QNR将预订的<QoS Available>通知QNI。
|------| |------| |------| |------|
| e2e |<->| e2e |<------------------------->| e2e |<->| e2e |
| QOSM | | QOSM | | QOSM | | QOSM |
| | |------| |-------| |-------| |------| | |
| NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP |
|Y.1541| |local | |local | |local | |local | |Y.1541|
| 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)
|------| |------| |------| |------|
| e2e |<->| e2e |<------------------------->| e2e |<->| e2e |
| QOSM | | QOSM | | QOSM | | QOSM |
| | |------| |-------| |-------| |------| | |
| NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP |
|Y.1541| |local | |local | |local | |local | |Y.1541|
| 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 4: Example of Initiator and Local Domain QOSM Operation
图4：启动器和本地域QOSM操作示例
4.2. Reservation Success/Failure, QSPEC Error Codes, and INFO-SPEC Notification
4.2. 预订成功/失败、QSPEC错误代码和INFO-SPEC通知
A reservation may not be successful for several reasons:
由于以下几个原因，预订可能不成功：
- a reservation may fail because the desired resources are not available. This is a reservation failure condition.
- 由于所需资源不可用，预订可能会失败。这是预订失败的情况。
- a reservation may fail because the QSPEC is erroneous or because of a QNE fault. This is an error condition.
- 由于QSPEC错误或QNE故障，保留可能会失败。这是一个错误条件。
A reservation may be successful even though some parameters could not be interpreted or updated properly:
即使某些参数无法正确解释或更新，保留也可能成功：
- a QSPEC parameter cannot be interpreted because it is an unknown QSPEC parameter type. This is a QSPEC parameter not supported condition. However, the reservation does not fail. The QNI can still decide whether to keep or tear down the reservation depending on the procedures specified by the QNI's QOSM.
- 无法解释QSPEC参数，因为它是未知的QSPEC参数类型。这是不支持的QSPEC参数条件。然而，保留并没有失败。QNI仍然可以根据QNI的QOSM规定的程序决定是否保留或撤销保留。
The following sections provide details on the handling of unsuccessful reservations and reservations where some parameters could not be met, as follows:
以下各节详细介绍了未成功预订和无法满足某些参数的预订的处理，如下所示：
- details on flags used inside the QSPEC to convey information on success or failure of individual parameters. The formats and semantics of all flags are given in Section 5.
- QSPEC内部用于传达单个参数成功或失败信息的标志的详细信息。第5节给出了所有标志的格式和语义。
- the content of the INFO-SPEC [RFC5974], which carries a code indicating the outcome of reservations.
- INFO-SPEC[RFC5974]的内容，其中包含指示保留结果的代码。
- the generation of a RESPONSE message to the QNI containing both QSPEC and INFO-SPEC objects.
- 向QNI生成包含QSPEC和INFO-SPEC对象的响应消息。
Note that when there are routers along the path between the QNI and QNR where QoS cannot be provided, then the QoS-NSLP generic flag BREAK (B) is set. The BREAK flag is discussed in Section 3.3.5 of [RFC5974].
请注意，当QNI和QNR之间的路径上存在无法提供QoS的路由器时，将设置QoS NSLP通用标志中断（B）。[RFC5974]第3.3.5节讨论了中断标志。
The QSPEC parameters each have a 'reservation failure error E flag' to indicate which (if any) parameters could not be satisfied. When a resource cannot be satisfied for a particular parameter, the QNE detecting the problem raises the E flag in this parameter. Note that the TMOD parameter and all QSPEC parameters with the M flag set MUST be examined by the RMF, and all QSPEC parameters with the M flag not set SHOULD be examined by the RMF, and the E flag set to indicate whether the parameter could or could not be satisfied. Additionally, the E flag in the corresponding QSPEC object MUST be raised when a resource cannot be satisfied for this parameter. If the reservation failure problem cannot be located at the parameter level, only the E flag in the QSPEC object is raised.
QSPEC参数各有一个“保留失败错误E标志”，以指示哪些（如果有）参数不能满足要求。当某个资源不能满足某个特定参数的要求时，检测到问题的QNE将在该参数中发出E标志。请注意，TMOD参数和设置了M标志的所有QSPEC参数必须由RMF检查，未设置M标志的所有QSPEC参数应由RMF检查，而设置了E标志的QSPEC参数则表明参数是否可以满足要求。此外，当资源不能满足此参数时，必须在相应的QSPEC对象中引发E标志。如果无法在参数级别找到保留失败问题，则只会引发QSPEC对象中的E标志。
When an RMF cannot interpret the QSPEC because the coding is erroneous, it raises corresponding reservation failure E flags in the QSPEC. Normally, all QSPEC parameters MUST be examined by the RMF, and the erroneous parameters appropriately flagged. In some cases, however, an error condition may occur and the E flag of the error-causing QSPEC parameter is raised (if possible), but the processing of further parameters may be aborted.
当RMF由于编码错误而无法解释QSPEC时，它会在QSPEC中引发相应的保留失败E标志。通常，RMF必须检查所有QSPEC参数，并适当标记错误参数。但是，在某些情况下，可能会出现错误情况，并引发导致错误的QSPEC参数的E标志（如果可能），但可能会中止对其他参数的处理。
Note that if the QSPEC and/or any QSPEC parameter is found to be erroneous, then any QSPEC parameters not satisfied are ignored and the E Flags in the QSPEC object MUST NOT be set for those parameters (unless they are erroneous).
请注意，如果发现QSPEC和/或任何QSPEC参数错误，则忽略任何不满足的QSPEC参数，并且不得为这些参数设置QSPEC对象中的E标志（除非它们是错误的）。
Whether E flags denote reservation failure or error can be determined by the corresponding error code in the INFO-SPEC in QoS NSLP, as discussed below.
E标志是否表示保留失败或错误可以由QoS NSLP中INFO-SPEC中的相应错误代码确定，如下所述。
Each QSPEC parameter has an associated 'Not Supported N flag'. If the Not Supported N flag is set, then at least one QNE along the data transmission path between the QNI and QNR cannot interpret the specified QSPEC parameter. A QNE MUST set the Not Supported N flag if it cannot interpret the QSPEC parameter. If the M flag for the parameter is not set, the message should continue to be forwarded but with the N flag set, and the QNI has the option of tearing down the reservation.
每个QSPEC参数都有一个关联的“不受支持的N标志”。如果设置了不支持的N标志，则QNI和QNR之间的数据传输路径上至少有一个QNE无法解释指定的QSPEC参数。如果QNE无法解释QSPEC参数，则必须设置不受支持的N标志。如果未设置参数的M标志，则应继续转发消息，但应设置N标志，并且QNI可选择取消保留。
If a QNE in the path does not support a QSPEC parameter, e.g., <Path Latency>, and sets the N flag, then downstream QNEs that support the parameter SHOULD still update the parameter, even if the N flag is set. However, the presence of the N flag will indicate that the cumulative value only provides a bound, and the QNI/QNR decides whether or not to accept the reservation with the N flag set.
如果路径中的QNE不支持QSPEC参数，例如，<path Latency>，并设置了N标志，则支持该参数的下游QNE仍应更新该参数，即使设置了N标志。然而，N标志的存在将指示累积值仅提供一个界限，并且QNI/QNR决定是否接受设置了N标志的保留。
As prescribed by [RFC5974], the RESPONSE message always contains the INFO-SPEC with an appropriate 'error' code. It usually also contains a QSPEC with QSPEC objects, as described in Section 4.3 ("QSPEC Procedures"). The RESPONSE message MAY omit the QSPEC in case of a successful reservation.
按照[RFC5974]的规定，响应消息始终包含带有适当“错误”代码的INFO-SPEC。它通常还包含带有QSPEC对象的QSPEC，如第4.3节（“QSPEC程序”）所述。在成功预订的情况下，响应消息可能会忽略QSPEC。
The following guidelines are provided for setting the error codes in the INFO-SPEC, based on the codes provided in Section 5.1.3.6 of [RFC5974]:
根据[RFC5974]第5.1.3.6节中提供的代码，为设置信息规范中的错误代码提供了以下指南：
- NSLP error class 2 (Success) / 0x01 (Reservation Success): This code is set when all QSPEC parameters have been satisfied. In this case, no E Flag is set; however, one or more N flags may be set.
- NSLP错误类别2（成功）/0x01（保留成功）：当满足所有QSPEC参数时设置此代码。在这种情况下，没有设置E标志；然而，可以设置一个或多个N标志。
- NSLP error class 4 (Transient Failure) / 0x07 (Reservation Failure): This code is set when at least one QSPEC parameter could not be satisfied, or when a QSPEC parameter with M flag set could not be interpreted. E flags are set for the parameters that could not be satisfied at each QNE up to the QNE issuing the RESPONSE message. The N flag is set for those parameters that could not be interpreted by at least one QNE. In this case, QNEs receiving the RESPONSE message MUST remove the corresponding reservation.
- NSLP错误类别4（瞬时故障）/0x07（保留故障）：当至少一个QSPEC参数无法满足要求，或者当无法解释设置了M标志的QSPEC参数时，会设置此代码。为在发出响应消息之前的每个QNE上无法满足的参数设置E标志。为至少一个QNE无法解释的参数设置N标志。在这种情况下，接收响应消息的QNE必须删除相应的保留。
- NSLP error class 3 (Protocol Error) / 0x0c (Malformed QSPEC): Some QSPEC parameters had associated errors, E Flags are set for parameters that had errors, and the QNE where the error was found rejects the reservation.
- NSLP错误类别3（协议错误）/0x0c（格式错误的QSPEC）：某些QSPEC参数有相关错误，为有错误的参数设置了E标志，发现错误的QNE拒绝保留。
- NSLP error class 3 (Protocol Error) / 0x0f (Incompatible QSPEC): A higher version QSPEC is signaled and not supported by the QNE.
- NSLP错误类别3（协议错误）/0x0f（不兼容的QSPEC）：发出更高版本的QSPEC信号，QNE不支持。
- NSLP error class 6 (QoS Model Error): QOSM error codes can be defined by QOSM specification documents. A registry is defined in Section 7, IANA Considerations.
- NSLP错误类别6（QoS模型错误）：QOSM错误代码可由QOSM规范文档定义。注册在第7节IANA注意事项中定义。
- Successful Reservation Condition
- 成功预订条件
When a RESERVE message arrives at a QNR and no E Flag is set, the reservation is successful. A RESPONSE message may be generated with INFO-SPEC code 'Reservation Success' as described above and in Section 4.3 ("QSPEC Procedures").
当保留消息到达QNR且未设置E标志时，保留成功。如上文和第4.3节（“QSPEC程序”）所述，可使用信息规范代码“预订成功”生成响应消息。
- Reservation Failure Condition
- 预约失败条件
When a QNE detects that a reservation failure occurs for at least one parameter, the QNE sets the E Flags for the QSPEC parameters and QSPEC object that failed to be satisfied. According to [RFC5974], the QNE behavior depends on whether it is stateful or not. When a stateful QNE determines the reservation failed, it formulates a RESPONSE message that includes an INFO-SPEC with the 'reservation failure' error code and QSPEC object. The QSPEC in the RESPONSE message includes the failed QSPEC parameters marked with the E Flag to clearly identify them.
当QNE检测到至少一个参数发生保留失败时，QNE将为未能满足的QSPEC参数和QSPEC对象设置E标志。根据[RFC5974]，QNE行为取决于它是否有状态。当有状态QNE确定保留失败时，它会生成一条响应消息，其中包含一个带有“保留失败”错误代码和QSPEC对象的INFO-SPEC。响应消息中的QSPEC包括用E标志标记的失败QSPEC参数，以清楚地识别它们。
The default action for a stateless QoS NSLP QNE that detects a reservation failure condition is that it MUST continue to forward the RESERVE message to the next stateful QNE, with the E Flags appropriately set for each QSPEC parameter. The next stateful QNE then formulates the RESPONSE message as described above.
检测保留失败条件的无状态QoS NSLP QNE的默认操作是，它必须继续将保留消息转发到下一个有状态QNE，并为每个QSPEC参数适当设置E标志。然后，下一个有状态的QNE按照上述方式制定响应消息。
- Malformed QSPEC Error Condition
- 格式错误的QSPEC错误条件
When a stateful QNE detects that one or more QSPEC parameters are erroneous, the QNE sets the error code 'malformed QSPEC' in the INFO-SPEC. In this case, the QSPEC object with the E Flags appropriately set for the erroneous parameters is returned within the INFO-SPEC object. The QSPEC object can be truncated or fully included within the INFO-SPEC.
当有状态QNE检测到一个或多个QSPEC参数错误时，QNE将在INFO-SPEC中设置错误代码“格式错误的QSPEC”。在这种情况下，在INFO-SPEC对象中返回具有为错误参数正确设置的E标志的QSPEC对象。QSPEC对象可以被截断或完全包含在INFO-SPEC中。
According to [RFC5974], the QNE behavior depends on whether it is stateful or not. When a stateful QNE determines a malformed QSPEC error condition, it formulates a RESPONSE message that includes an INFO-SPEC with the 'malformed QSPEC' error code and QSPEC object.
根据[RFC5974]，QNE行为取决于它是否有状态。当有状态QNE确定格式不正确的QSPEC错误条件时，它会生成一条响应消息，其中包含一条带有“格式不正确的QSPEC”错误代码和QSPEC对象的信息规范。
The QSPEC in the RESPONSE message includes, if possible, only the erroneous QSPEC parameters and no others. The erroneous QSPEC parameter(s) are marked with the E Flag to clearly identify them. If QSPEC parameters are returned in the INFO-SPEC that are not marked with the E flag, then any values of these parameters are irrelevant and MUST be ignored by the QNI.
如果可能，响应消息中的QSPEC仅包括错误的QSPEC参数，而不包括其他参数。错误的QSPEC参数用E标志标记，以清楚地识别它们。如果在INFO-SPEC中返回的QSPEC参数没有标记E标志，则这些参数的任何值都是无关的，必须被QNI忽略。
The default action for a stateless QoS NSLP QNE that detects a malformed QSPEC error condition is that it MUST continue to forward the RESERVE message to the next stateful QNE, with the E Flags appropriately set for each QSPEC parameter. The next stateful QNE will then act as described in [RFC5974].
检测到格式错误的QSPEC错误条件的无状态QoS NSLP QNE的默认操作是，它必须继续将保留消息转发到下一个有状态QNE，并为每个QSPEC参数适当设置E标志。然后，下一个有状态QNE将按照[RFC5974]中所述进行操作。
A 'malformed QSPEC' error code takes precedence over the 'reservation failure' error code, and therefore the case of reservation failure and QSPEC/RMF error conditions are disjoint, and the same E Flag can be used in both cases without ambiguity.
“格式错误的QSPEC”错误代码优先于“保留失败”错误代码，因此保留失败的情况和QSPEC/RMF错误条件是不相交的，在这两种情况下可以使用相同的E标志，而不会产生歧义。
When an unsuccessful reservation problem occurs inside a local domain where a Local QSPEC is used, only the topmost (local) QSPEC is affected (e.g., E flags are raised, etc.). The encapsulated Initiator QSPEC is untouched. However, when the message (RESPONSE in case of stateful QNEs; RESERVE in case of stateless QNEs) reaches the edge of the local domain, the Local QSPEC is removed. The edge QNE must update the Initiator QSPEC on behalf of the entire domain, reflecting the information received in the Local QSPEC. This update concerns both parameter values and flags. Note that some intelligence is needed in mapping the E flags, etc., from the local QSPEC to the Initiator QSPEC. For example, even if there is no direct match between the parameters in the local and Initiator QSPECs, E flags could still be raised in the latter.
当在使用本地QSPEC的本地域内发生不成功的保留问题时，只会影响最顶层（本地）QSPEC（例如，升起标志等）。封装的启动器QSPEC未被触及。但是，当消息（有状态QNE的响应；无状态QNE的保留）到达本地域的边缘时，本地QSPEC被删除。边缘QNE必须代表整个域更新启动器QSPEC，以反映在本地QSPEC中接收到的信息。此更新涉及参数值和标志。请注意，在将E标志等从本地QSPEC映射到启动器QSPEC时需要一些智能。例如，即使本地和启动器QSPEC中的参数之间没有直接匹配，在后者中仍然可以引发E标志。
While the QSPEC template aims to put minimal restrictions on usage of QSPEC objects, interoperability between QNEs and between QOSMs must be ensured. We therefore give below an exhaustive list of QSPEC object combinations for the message sequences described in QoS NSLP [RFC5974]. A specific QOSM may prescribe that only a subset of the procedures listed below may be used.
虽然QSPEC模板旨在对QSPEC对象的使用施加最小限制，但必须确保QNE之间和QOSMs之间的互操作性。因此，我们在下面给出了QoS NSLP[RFC5974]中描述的消息序列的QSPEC对象组合的详尽列表。特定QOSM可能规定只能使用下列程序的一个子集。
Note that QoS NSLP does not mandate the usage of a RESPONSE message. A positive RESPONSE message will only be generated if the QNE includes an RII (Request Identification Information) in the RESERVE message, and a negative RESPONSE message is always generated in case of an error or failure. Some of the QSPEC procedures below, however, are only meaningful when a RESPONSE message is possible. The QNI SHOULD in these cases include an RII.
请注意，QoS NSLP不强制使用响应消息。只有当QNE在保留消息中包含RII（请求标识信息）时，才会生成肯定响应消息，并且在出现错误或故障时，始终会生成否定响应消息。然而，下面的一些QSPEC过程只有在可能出现响应消息时才有意义。在这些情况下，QNI应包括RII。
Here, the QNI issues a RESERVE message, which may be replied to by a RESPONSE message. The following 3 cases for QSPEC object usage exist:
在这里，QNI发出保留消息，该消息可以通过响应消息进行回复。QSPEC对象使用存在以下3种情况：
MESSAGE | OBJECT | OBJECTS INCLUDED | OBJECTS INCLUDED
SEQUENCE | COMBINATION | IN RESERVE MESSAGE | IN RESPONSE MESSAGE
-----------------------------------------------------------------
0 | 0 | QoS Desired | QoS Reserved
| | |
0 | 1 | QoS Desired | QoS Reserved
| | QoS Available | QoS Available
| | |
0 | 2 | QoS Desired | QoS Reserved
| | QoS Available | QoS Available
| | Minimum QoS |
MESSAGE | OBJECT | OBJECTS INCLUDED | OBJECTS INCLUDED
SEQUENCE | COMBINATION | IN RESERVE MESSAGE | IN RESPONSE MESSAGE
-----------------------------------------------------------------
0 | 0 | QoS Desired | QoS Reserved
| | |
0 | 1 | QoS Desired | QoS Reserved
| | QoS Available | QoS Available
| | |
0 | 2 | QoS Desired | QoS Reserved
| | QoS Available | QoS Available
| | Minimum QoS |
Table 1: Message Sequence 0: Two-Way Transactions Defining Object Combinations 0, 1, and 2
表1：消息序列0：定义对象组合0、1和2的双向事务
Case 1:
案例1：
If only QoS Desired is included in the RESERVE message, the implicit assumption is that exactly these resources must be reserved. If this is not possible, the reservation fails. The parameters in QoS Reserved are copied from the parameters in QoS Desired. If the reservation is successful, the RESPONSE message can be omitted in this case. If a RESPONSE message was requested by a QNE on the path, the QSPEC in the RESPONSE message can be omitted.
如果RESERVE消息中只包含所需的QoS，那么隐含的假设就是必须保留这些资源。如果不可能，则预订失败。保留QoS中的参数是从所需QoS中的参数复制而来的。如果保留成功，在这种情况下可以忽略响应消息。如果路径上的QNE请求了响应消息，则可以忽略响应消息中的QSPEC。
Case 2:
案例2：
When QoS Available is included in the RESERVE message also, some parameters will appear only in QoS Available and not in QoS Desired. It is assumed that the value of these parameters is collected for informational purposes only (e.g., path latency).
当QoS Available（可用QoS）也包含在RESERVE（保留）消息中时，某些参数将仅显示在QoS Available（可用QoS）中，而不显示在QoS Desired（需要QoS）中。假设收集这些参数的值仅用于信息目的（例如，路径延迟）。
However, some parameters in QoS Available can be the same as in QoS Desired. For these parameters, the implicit message is that the QNI would be satisfied by a reservation with lower parameter values than specified in QoS Desired. For these parameters, the QNI seeds the parameter values in QoS Available to those in QoS Desired (except for cumulative parameters such as <Path Latency>).
但是，可用QoS中的某些参数可以与所需QoS中的参数相同。对于这些参数，隐含的消息是，QNI将通过参数值低于所需QoS中指定值的保留来满足。对于这些参数，QNI将QoS中的参数值分配给所需的QoS中的参数值（累积参数除外，如<Path Latency>）。
Each QNE interprets the parameters in QoS Available according to its current capabilities. Reservations in each QNE are hence based on current parameter values in QoS Available (and additionally those parameters that only appear in QoS Desired). The drawback of this approach is that, if the resulting resource reservation becomes gradually smaller towards the QNR, QNEs close to the QNI have an oversized reservation, possibly resulting in unnecessary costs for the user. Of course, in the RESPONSE the QNI learns what the actual reservation is (from the QoS RESERVED object) and can immediately issue a properly sized refreshing RESERVE. The advantage of the approach is that the reservation is performed in half-a-roundtrip time.
每个QNE根据其当前能力解释QoS中可用的参数。因此，每个QNE中的保留基于QoS Available中的当前参数值（以及仅出现在QoS Desired中的那些参数）。这种方法的缺点是，如果产生的资源预留向QNR逐渐变小，则靠近QNI的QNE具有过大的预留，可能导致用户不必要的成本。当然，在响应中，QNI（从QoS保留对象）了解实际保留是什么，并可以立即发出适当大小的刷新保留。这种方法的优点是预订在半个往返时间内完成。
The QSPEC parameter IDs and values included in the QoS Reserved object in the RESPONSE message MUST be the same as those in the QoS Desired object in the RESERVE message. For those QSPEC parameters that were also included in the QoS Available object in the RESERVE message, their value is copied from the QoS Available object (in RESERVE) into the QoS Reserved object (in RESPONSE). For the other QSPEC parameters, the value is copied from the QoS Desired object (the reservation would fail if the corresponding QoS could not be reserved).
响应消息中QoS保留对象中包含的QSPEC参数ID和值必须与保留消息中QoS所需对象中的参数ID和值相同。对于保留消息中QoS可用对象中也包含的那些QSPEC参数，其值将从QoS可用对象（保留中）复制到QoS保留对象（响应中）。对于其他QSPEC参数，从QoS所需对象复制该值（如果无法保留相应的QoS，则保留将失败）。
All parameters in the QoS Available object in the RESPONSE message are copied with their values from the QoS Available object in the RESERVE message (irrespective of whether they have also been copied into the QoS Desired object). Note that the parameters in the QoS Available object can be overwritten in the RESERVE message, whereas they cannot be overwritten in the RESPONSE message.
响应消息中QoS Available对象中的所有参数与它们的值一起从保留消息中的QoS Available对象中复制（无论它们是否也已复制到QoS Desired对象中）。请注意，QoS Available对象中的参数可以在保留消息中覆盖，而不能在响应消息中覆盖。
In this case, the QNI SHOULD request a RESPONSE message since it will otherwise not learn what QoS is available.
在这种情况下，QNI应该请求响应消息，因为否则它将无法了解可用的QoS。
Case 3:
案例3：
This case is handled as case 2, except that the reservation fails when QoS Available becomes less than Minimum QoS for one parameter. If a parameter appears in the QoS Available object but not in the Minimum QoS object, it is assumed that there is no minimum value for this parameter.
此情况与情况2相同，但当可用QoS小于一个参数的最小QoS时，保留失败。如果参数出现在QoS Available对象中，但不出现在Minimum QoS对象中，则假定此参数没有最小值。
Regarding Traffic Handling Directives, the default rule is that all QSPEC parameters that have been included in the RESERVE message by the QNI are also included in the RESPONSE message by the QNR with the value they had when arriving at the QNR. When traveling in the RESPONSE message, all Traffic Handling Directives parameters are read-only. Note that a QOSM specification may define its own Traffic Handling Directives parameters and processing rules.
关于流量处理指令，默认规则是，QNI已包含在保留消息中的所有QSPEC参数也包含在QNR的响应消息中，其值与到达QNR时的值相同。在响应消息中移动时，所有流量处理指令参数都是只读的。请注意，QOSM规范可以定义自己的流量处理指令、参数和处理规则。
Here, the QNR issues a QUERY message that is replied to by the QNI with a RESERVE message if the reservation was successful. The QNR in turn sends a RESPONSE message to the QNI. The following 3 cases for QSPEC object usage exist:
在这里，QNR发出一条查询消息，如果保留成功，QNI将用保留消息回复该消息。QNR依次向QNI发送响应消息。QSPEC对象使用存在以下3种情况：
MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED
SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
-------------------------------------------------------------------
1 |0 |QoS Desired |QoS Desired |QoS Reserved
| | | |
1 |1 |QoS Desired |QoS Desired |QoS Reserved
| |(Minimum QoS) |QoS Available |QoS Available
| | |(Minimum QoS) |
| | | |
1 |2 |QoS Desired |QoS Desired |QoS Reserved
| |QoS Available |QoS Available |
MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED
SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
-------------------------------------------------------------------
1 |0 |QoS Desired |QoS Desired |QoS Reserved
| | | |
1 |1 |QoS Desired |QoS Desired |QoS Reserved
| |(Minimum QoS) |QoS Available |QoS Available
| | |(Minimum QoS) |
| | | |
1 |2 |QoS Desired |QoS Desired |QoS Reserved
| |QoS Available |QoS Available |
Table 2: Message Sequence 1: Three-Way Transactions Defining Object Combinations 0, 1, and 2
表2：消息序列1：定义对象组合0、1和2的三方事务
Cases 1 and 2:
案例1和2：
The idea is that the sender (QNR in this scenario) needs to inform the receiver (QNI in this scenario) about the QoS it desires. To this end, the sender sends a QUERY message to the receiver including a QoS Desired QSPEC object. If the QoS is negotiable, it additionally includes a (possibly zero) Minimum QoS object, as in Case 2.
其思想是发送方（本场景中的QNR）需要通知接收方（本场景中的QNI）它想要的QoS。为此，发送方向接收方发送一个查询消息，其中包括一个QoS期望的QSPEC对象。如果QoS是可协商的，那么它还包括一个（可能为零）最小QoS对象，如案例2所示。
The RESERVE message includes the QoS Available object if the sender signaled that QoS is negotiable (i.e., it included the Minimum QoS object). If the Minimum QoS object received from the sender is included in the QUERY message, the QNI also includes the Minimum QoS object in the RESERVE message.
如果发送方发出QoS可协商的信号（即，它包括最小QoS对象），则保留消息包括QoS可用对象。如果从发送方接收的最小QoS对象包含在查询消息中，则QNI还将最小QoS对象包含在保留消息中。
For a successful reservation, the RESPONSE message in case 1 is optional (as is the QSPEC inside). In case 2, however, the RESPONSE message is necessary in order for the QNI to learn about the QoS available.
对于成功的预订，案例1中的响应消息是可选的（内部的QSPEC也是可选的）。然而，在情况2中，为了让QNI了解可用的QoS，响应消息是必要的。
Case 3:
案例3：
This is the 'RSVP-style' scenario. The sender (QNR in this scenario) issues a QUERY message with a QoS Desired object informing the receiver (QNI in this scenario) about the QoS it desires, as above. It also includes a QoS Available object to collect path properties. Note that here path properties are collected with the QUERY message, whereas in the previous case, 2 path properties were collected in the RESERVE message.
这是“RSVP风格”场景。发送方（本场景中的QNR）发出一条查询消息，其中包含一个QoS所需的对象，通知接收方（本场景中的QNI）其所需的QoS，如上所述。它还包括用于收集路径属性的QoS可用对象。请注意，此处路径属性随查询消息一起收集，而在上一个示例中，在保留消息中收集了2个路径属性。
Some parameters in the QoS Available object may be the same as in the QoS Desired object. For these parameters, the implicit message is that the sender would be satisfied by a reservation with lower parameter values than specified in QoS Desired.
QoS可用对象中的一些参数可能与QoS所需对象中的参数相同。对于这些参数，隐含的消息是，发送方将通过参数值低于所需QoS中指定值的保留来满足。
It is possible for the QoS Available object to contain parameters that do not appear in the QoS Desired object. It is assumed that the value of these parameters is collected for informational purposes only (e.g., path latency). Parameter values in the QoS Available object are seeded according to the sender's capabilities. Each QNE remaps or approximately interprets the parameter values according to its current capabilities.
QoS可用对象可能包含QoS所需对象中未出现的参数。假设收集这些参数的值仅用于信息目的（例如，路径延迟）。QoS Available对象中的参数值根据发送方的能力进行种子设定。每个QNE根据其当前能力重新映射或近似解释参数值。
The receiver (QNI in this scenario) signals the QoS Desired object as follows: For those parameters that appear in both the QoS Available object and QoS Desired object in the QUERY message, it takes the (possibly remapped) QSPEC parameter values from the QoS Available object. For those parameters that only appear in the QoS Desired object, it adopts the parameter values from the QoS Desired object.
接收方（在本场景中为QNI）按如下方式向QoS所需对象发送信号：对于查询消息中出现在QoS可用对象和QoS所需对象中的那些参数，它从QoS可用对象中获取（可能重新映射）QSPEC参数值。对于仅出现在QoS所需对象中的参数，它采用来自QoS所需对象的参数值。
The parameters in the QoS Available QSPEC object in the RESERVE message are copied with their values from the QoS Available QSPEC object in the QUERY message. Note that the parameters in the QoS Available object can be overwritten in the QUERY message, whereas they cannot be overwritten in the RESERVE message.
RESERVE消息中QoS Available QSPEC对象中的参数及其值将从查询消息中的QoS Available QSPEC对象中复制。请注意，QoS Available对象中的参数可以在查询消息中覆盖，而不能在保留消息中覆盖。
The advantage of this model compared to the sender-initiated reservation is that the situation of over-reservation in QNEs close to the QNI (as described above) does not occur. On the other hand, the QUERY message may find, for example, a particular bandwidth is
与发送方发起的预约相比，该模型的优势在于，在靠近QNI（如上所述）的QNE中不会出现过度预约的情况。另一方面，查询消息可以发现，例如，特定带宽是可用的
not available. When the actual reservation is performed, however, the desired bandwidth may meanwhile have become free. That is, the 'RSVP style' may result in a smaller reservation than necessary.
无法使用的。然而，当执行实际预约时，期望带宽可能同时变为空闲。也就是说，“RSVP样式”可能会导致比必要时更小的保留。
The sender includes all QSPEC parameters it cares about in the QUERY message. Parameters that can be overwritten are updated by QNEs as the QUERY message travels towards the receiver. The receiver includes all QSPEC parameters arriving in the QUERY message also in the RESERVE message, with the value they had when arriving at the receiver. Again, QOSM-specific QSPEC parameters and procedures may be defined in QOSM specification documents.
发送方在查询消息中包含它关心的所有QSPEC参数。当查询消息向接收器传送时，QNE会更新可覆盖的参数。接收方包括查询消息中到达的所有QSPEC参数以及保留消息中的所有QSPEC参数，以及它们到达接收方时的值。同样，QOSM特定的QSPEC参数和程序可在QOSM规范文件中定义。
Also in this scenario, the QNI SHOULD request a RESPONSE message since it will otherwise not learn what QoS is available.
同样在这种情况下，QNI应该请求一条响应消息，因为否则它将无法了解什么是可用的QoS。
Regarding Traffic Handling Directives, the default rule is that all QSPEC parameters that have been included in the RESERVE message by the QNI are also included in the RESPONSE message by the QNR with the value they had when arriving at the QNR. When traveling in the RESPONSE message, all Traffic Handling Directives parameters are read-only. Note that a QOSM specification may define its own Traffic Handling Directives parameters and processing rules.
关于流量处理指令，默认规则是，QNI已包含在保留消息中的所有QSPEC参数也包含在QNR的响应消息中，其值与到达QNR时的值相同。在响应消息中移动时，所有流量处理指令参数都是只读的。请注意，QOSM规范可以定义自己的流量处理指令、参数和处理规则。
Here, the QNI issues a QUERY message in order to investigate what resources are currently available. The QNR replies with a RESPONSE message.
在这里，QNI发出一条查询消息，以调查当前可用的资源。QNR以响应消息进行回复。
MESSAGE | OBJECT | OBJECTS INCLUDED | OBJECTS INCLUDED
SEQUENCE | COMBINATION | IN QUERY MESSAGE | IN RESPONSE MESSAGE
-----------------------------------------------------------------
2 | 0 | QoS Available | QoS Available
MESSAGE | OBJECT | OBJECTS INCLUDED | OBJECTS INCLUDED
SEQUENCE | COMBINATION | IN QUERY MESSAGE | IN RESPONSE MESSAGE
-----------------------------------------------------------------
2 | 0 | QoS Available | QoS Available
Table 3: Message Sequence 2: Resource Queries Defining Object Combination 0
表3：消息序列2：定义对象组合0的资源查询
Note that the QoS Available object when traveling in the QUERY message can be overwritten, whereas in the RESPONSE message it cannot be overwritten.
请注意，在查询消息中传输时，QoS可用对象可以被覆盖，而在响应消息中它不能被覆盖。
Regarding Traffic Handling Directives, the default rule is that all QSPEC parameters that have been included in the RESERVE message by the QNI are also included in the RESPONSE message by the QNR with the value they had when arriving at the QNR. When traveling in the RESPONSE message, all Traffic Handling Directives parameters are read-only. Note that a QOSM specification may define its own Traffic Handling Directives parameters and processing rules.
关于流量处理指令，默认规则是，QNI已包含在保留消息中的所有QSPEC参数也包含在QNR的响应消息中，其值与到达QNR时的值相同。在响应消息中移动时，所有流量处理指令参数都是只读的。请注意，QOSM规范可以定义自己的流量处理指令、参数和处理规则。
On a QSPEC level, bidirectional reservations are no different from unidirectional reservations, since QSPECs for different directions never travel in the same message.
在QSPEC级别上，双向预订与单向预订没有什么不同，因为不同方向的QSPEC不会在同一消息中传输。
A flow can be preempted by a QNE based on QNE policy, where a decision to preempt a flow may account for various factors such as, for example, the values of the QSPEC preemption priority and defending priority parameters as described in Section 5.2.8. In this case, the reservation state for this flow is torn down in the QNE, and the QNE sends a NOTIFY message to the QNI, as described in [RFC5974]. The NOTIFY message carries an INFO-SPEC with the error code as described in [RFC5974]. A QOSM specification document may specify whether a NOTIFY message also carries a QSPEC object. The QNI would normally tear down the preempted reservation by sending a RESERVE message with the TEAR flag set using the SII of the preempted reservation. However, the QNI can follow other procedures as specified in its QOSM specification document.
QNE可根据QNE策略抢占流，其中抢占流的决定可考虑各种因素，例如，第5.2.8节所述QSPEC抢占优先级和防御优先级参数的值。在这种情况下，此流的保留状态在QNE中被删除，并且QNE向QNI发送通知消息，如[RFC5974]中所述。NOTIFY消息包含一个带有错误代码的INFO-SPEC，如[RFC5974]所述。QOSM规范文档可以指定NOTIFY消息是否也携带QSPEC对象。QNI通常会通过使用抢占保留的SII发送带有撕裂标志集的保留消息来撕毁抢占保留。但是，QNI可以遵循其QOSM规范文件中规定的其他程序。
Additional QSPEC parameters MAY need to be defined in the future and are defined in separate informational documents. For example, QSPEC parameters are defined in [RFC5977] and [RFC5976].
将来可能需要定义额外的QSPEC参数，并在单独的信息文档中定义。例如，[RFC5977]和[RFC5976]中定义了QSPEC参数。
Guidelines on the technical criteria to be followed in evaluating requests for new codepoint assignments for QSPEC objects and QSPEC parameters are given in Section 7, IANA Considerations.
第7节IANA注意事项中给出了评估QSPEC对象和QSPEC参数的新代码点分配请求时应遵循的技术标准指南。
This section defines the encodings of the QSPEC parameters. We first give the general QSPEC formats and then the formats of the QSPEC objects and parameters.
本节定义QSPEC参数的编码。我们首先给出了一般的QSPEC格式，然后给出了QSPEC对象和参数的格式。
Network octet order ('big-endian') for all 16- and 32-bit integers, as well as 32-bit floating point numbers, is as specified in [RFC4506], [IEEE754], and [NETWORK-OCTET-ORDER].
所有16位和32位整数以及32位浮点数的网络八位字节顺序（“big-endian”）如[RFC4506]、[IEEE754]和[Network-octet-order]中所述。
The format of the QSPEC closely follows that used in GIST [RFC5971] and QoS NSLP [RFC5974]. Every object (and parameter) has the following general format:
QSPEC的格式与GIST[RFC5971]和QoS NSLP[RFC5974]中使用的格式非常相似。每个对象（和参数）具有以下通用格式：
o The overall format is Type-Length-Value (in that order).
o 整体格式为类型长度值（按该顺序）。
o Some parts of the type field are set aside for control flags.
o 类型字段的某些部分被预留用于控制标志。
o Length has the units of 32-bit words, and measures the length of Value. If there is no Value, Length=0. The Object length excludes the header.
o 长度以32位字为单位，测量值的长度。如果没有值，则长度=0。对象长度不包括标题。
o Value is a whole number of 32-bit words. If there is any padding required, the length and location MUST be defined by the object-specific format information; objects that contain variable-length types may need to include additional length subfields to do so.
o 值是32位字的整数。如果需要任何填充，则长度和位置必须由特定于对象的格式信息定义；包含可变长度类型的对象可能需要包含其他长度子字段才能执行此操作。
o Any part of the object used for padding or defined as reserved ("r") MUST be set to 0 on transmission and MUST be ignored on reception.
o 用于填充或定义为保留（“r”）的对象的任何部分在传输时必须设置为0，在接收时必须忽略。
o Empty QSPECs and empty QSPEC Objects MUST NOT be used.
o 不得使用空QSPEC和空QSPEC对象。
o Duplicate objects, duplicate parameters, and/or multiple occurrences of a parameter MUST NOT be used.
o 不得使用重复对象、重复参数和/或参数的多次出现。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common QSPEC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// QSPEC Objects //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common QSPEC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// QSPEC Objects //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Common QSPEC Header is a fixed 4-octet object containing the QSPEC Version, QSPEC Type, an identifier for the QSPEC Procedure (see Section 4.3), and an Initiator/Local QSPEC bit:
公共QSPEC头是一个固定的4-octet对象，包含QSPEC版本、QSPEC类型、QSPEC过程标识符（见第4.3节）和启动器/本地QSPEC位：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|I|QSPECType|r|r| QSPEC Proc. | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|I|QSPECType|r|r| QSPEC Proc. | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers.: Identifies the QSPEC version number. QSPEC Version 0 is assigned by this specification in Section 7 (IANA Considerations).
版本：标识QSPEC版本号。QSPEC版本0由本规范第7节（IANA注意事项）指定。
QSPEC Type: Identifies the particular type of QSPEC, e.g., a QSPEC Type corresponding to a particular QOSM. QSPEC Type 0 (default) is assigned by this specification in Section 7 (IANA Considerations).
QSPEC类型：标识QSPEC的特定类型，例如，对应于特定QOSM的QSPEC类型。QSPEC类型0（默认）由本规范第7节（IANA注意事项）指定。
QSPEC Proc.: Identifies the QSPEC procedure and is composed of two times 4 bits. The first field identifies the Message Sequence; the second field identifies the QSPEC Object Combination used for this particular message sequence:
QSPEC过程：标识QSPEC过程，由2乘以4位组成。第一字段标识消息序列；第二个字段标识用于此特定消息序列的QSPEC对象组合：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Mes.Sq |Obj.Cmb|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Mes.Sq |Obj.Cmb|
+-+-+-+-+-+-+-+-+
The Message Sequence field can attain the following values:
消息序列字段可以达到以下值：
0: Sender-Initiated Reservations 1: Receiver-Initiated Reservations 2: Resource Queries
0:发件人启动的保留1:收件人启动的保留2:资源查询
The Object Combination field can take the values between 1 and 3 indicated in the tables in Section 4.3:
对象组合字段可以取第4.3节表中所示的1到3之间的值：
Message Sequence: 0 Object Combination: 0, 1, 2 Semantic: see Table 1 in Section 4.3.1
消息序列：0对象组合：0、1、2语义：见4.3.1节表1
Message Sequence: 1 Object Combination: 0, 1, 2 Semantic: see Table 2 in Section 4.3.2
消息序列：1对象组合：0、1、2语义：见4.3.2节表2
Message Sequence: 2 Object Combination: 0 Semantic: see Table 3 in Section 4.3.3
消息序列：2对象组合：0语义：见4.3.3节表3
I: Initiator/Local QSPEC bit identifies whether the QSPEC is an initiator QSPEC or a Local QSPEC, and is set to the following values:
I：启动器/本地QSPEC位标识QSPEC是启动器QSPEC还是本地QSPEC，并设置为以下值：
0: Initiator QSPEC 1: Local QSPEC
0:启动器QSPEC 1:本地QSPEC
Length: The total length of the QSPEC (in 32-bit words) excluding the common header
长度：QSPEC的总长度（32位字），不包括公共标头
The QSPEC Objects field is a collection of QSPEC objects (QoS Desired, QoS Available, etc.), which share a common format and each contain several parameters.
QSPEC对象字段是QSPEC对象（所需的QoS、可用的QoS等）的集合，它们共享一个通用格式，每个都包含多个参数。
QSPEC objects share a common header format:
QSPEC对象共享一种通用的头格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Object Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Object Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E Flag: Set if an error occurs on object level
E标志：在对象级别发生错误时设置
Object Type = 0: QoS Desired (parameters cannot be overwritten)
= 1: QoS Available (parameters may be overwritten; see
Section 3.2)
= 2: QoS Reserved (parameters cannot be overwritten)
= 3: Minimum QoS (parameters cannot be overwritten)
Object Type = 0: QoS Desired (parameters cannot be overwritten)
= 1: QoS Available (parameters may be overwritten; see
Section 3.2)
= 2: QoS Reserved (parameters cannot be overwritten)
= 3: Minimum QoS (parameters cannot be overwritten)
The r bits are reserved.
r位是保留的。
Each QSPEC or QSPEC parameter within an object is encoded in the same way in TLV format using a similar parameter header:
对象中的每个QSPEC或QSPEC参数使用类似的参数头以TLV格式以相同的方式编码：
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| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M Flag: When set, indicates the subsequent parameter MUST be interpreted. Otherwise, the parameter can be ignored if not understood.
M标志：设置时，表示必须解释后续参数。否则，如果不理解该参数，则可以忽略该参数。
E Flag: When set, indicates either a) a reservation failure where the QSPEC parameter is not met, or b) an error occurred when this parameter was being interpreted (see Section 4.2.1).
E标志：设置时，表示a）不符合QSPEC参数的保留失败，或b）解释此参数时发生错误（见第4.2.1节）。
N Flag: Not Supported QSPEC parameter flag (see Section 4.2.2).
N标志：不支持QSPEC参数标志（见第4.2.2节）。
Parameter ID: Assigned consecutively to each QSPEC parameter. Parameter IDs are assigned to each QSPEC parameter defined in this document in Sections 5.2 and 7 (IANA Considerations).
参数ID：连续分配给每个QSPEC参数。参数ID分配给本文件第5.2节和第7节（IANA注意事项）中定义的每个QSPEC参数。
Parameters are usually coded individually, for example, the <Excess Treatment> parameter (Section 5.2.11). However, it is also possible to combine several sub-parameters into one parameter field, which is called 'container coding'. This coding is useful if either a) the sub-parameters always occur together (as for example the 5 sub-parameters that jointly make up the TMOD), or b) in order to make coding more efficient when the length of each sub-parameter value is much less than a 32-bit word (as for example described in [RFC5977]) and to avoid header overload. When a container is defined, the Parameter ID and the M, E, and N flags refer to the container. Examples of container parameters are <TMOD> (specified below) and the PHR (Per Hop Reservation) container parameter specified in [RFC5977].
参数通常单独编码，例如<过度治疗>参数（第5.2.11节）。但是，也可以将多个子参数组合成一个参数字段，称为“容器编码”。如果a）子参数总是同时出现（例如，共同构成TMOD的5个子参数），或者b）以便在每个子参数值的长度远小于32位字（例如[RFC5977]中所述）时使编码更有效，并避免报头过载，则该编码是有用的。定义容器时，参数ID和M、E和N标志引用容器。容器参数的示例有<TMOD>（如下指定）和[RFC5977]中指定的PHR（每跳保留）容器参数。
The references in the following sections point to the normative procedures for processing the QSPEC parameters and sub-parameters.
以下章节中的参考文件指出了处理QSPEC参数和子参数的规范程序。
The <TMOD-1> parameter consists of the <r>, <b>, <p>, <m>, and <MPS> sub-parameters [RFC2212], which all must be populated in the <TMOD-1> parameter. Note that a second TMOD QSPEC parameter <TMOD-2> is specified below in Section 5.2.2.
<TMOD-1>参数由<r>、<b>、<p>、<m>和<MPS>子参数[RFC2212]组成，这些子参数都必须填入<TMOD-1>参数中。请注意，第二个TMOD QSPEC参数<TMOD-2>在下文第5.2.2节中规定。
The coding for the <TMOD-1> parameter is as follows:
<TMOD-1>参数的编码如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| 1 |r|r|r|r| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| 1 |r|r|r|r| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <TMOD-1> parameters are represented by three floating point numbers in single-precision IEEE floating point format [IEEE754] followed by two 32-bit integers in network octet order. The first floating point value is the rate (r), the second floating point value is the bucket size (b), the third floating point is the peak rate
<TMOD-1>参数由三个单精度IEEE浮点格式的浮点数[IEEE754]表示，后跟两个网络八位字节顺序的32位整数。第一个浮点值是速率（r），第二个浮点值是桶大小（b），第三个浮点值是峰值速率
(p), the first unsigned integer is the minimum policed unit (m), and the second unsigned integer is the maximum packet size (MPS). The values of r and p are measured in octets per second; b, m, and MPS are measured in octets. When r, b, and p terms are represented as IEEE floating point values, the sign bit MUST be zero (all values MUST be non-negative). Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) are discouraged, except for specifying a peak rate of infinity. Infinity is represented with an exponent of all ones (255), and a sign bit and mantissa of all zeroes.
（p） ，第一个无符号整数是最小策略单位（m），第二个无符号整数是最大数据包大小（MPS）。r和p的值以每秒八位字节为单位测量；b、 m和MPS以八位字节计量。当r、b和p项表示为IEEE浮点值时，符号位必须为零（所有值必须为非负）。禁止指数小于127（即0）。不鼓励指数大于162（即正35），除非指定无穷大的峰值速率。无穷大由一个全1的指数（255）和一个全零的符号位和尾数表示。
A second QSPEC <TMOD-2> parameter is specified as could be needed, for example, to support some Diffserv applications.
第二个QSPEC<TMOD-2>参数被指定为可能需要的参数，例如，用于支持某些区分服务应用程序。
The coding for the <TMOD-2> parameter is as follows:
<TMOD-2>参数的编码如下：
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| 2 |r|r|r|r| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-2 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-2 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-2 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-2 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-2 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 2 |r|r|r|r| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-2 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-2 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-2 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-2 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-2 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <TMOD-2> parameters are represented by three floating point numbers in single-precision IEEE floating point format [IEEE754] followed by two 32-bit integers in network octet order. The first floating point value is the rate (r), the second floating point value is the bucket size (b), the third floating point is the peak rate (p), the first unsigned integer is the minimum policed unit (m), and the second unsigned integer is the maximum packet size (MPS). The values of r and p are measured in octets per second; b, m, and MPS are measured in octets. When r, b, and p terms are represented as IEEE floating point values, the sign bit MUST be zero (all values MUST be non-negative). Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) are
The <TMOD-2> parameters are represented by three floating point numbers in single-precision IEEE floating point format [IEEE754] followed by two 32-bit integers in network octet order. The first floating point value is the rate (r), the second floating point value is the bucket size (b), the third floating point is the peak rate (p), the first unsigned integer is the minimum policed unit (m), and the second unsigned integer is the maximum packet size (MPS). The values of r and p are measured in octets per second; b, m, and MPS are measured in octets. When r, b, and p terms are represented as IEEE floating point values, the sign bit MUST be zero (all values MUST be non-negative). Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) aretranslate error, please retry
discouraged, except for specifying a peak rate of infinity. Infinity is represented with an exponent of all ones (255), and a sign bit and mantissa of all zeroes.
不鼓励，除非指定无穷大的峰值速率。无穷大由一个全1的指数（255）和一个全零的符号位和尾数表示。
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| 3 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Latency (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 3 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Latency (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Latency [RFC2215] is a single 32-bit unsigned integer in network octet order. The intention of the Path Latency parameter is the same as the Minimal Path Latency parameter defined in Section 3.4 of [RFC2215]. The purpose of this parameter is to provide a baseline minimum path latency for use with services that provide estimates or bounds on additional path delay, such as in [RFC2212]. Together with the queuing delay bound offered by [RFC2212] and similar services, this parameter gives the application knowledge of both the minimum and maximum packet delivery delay.
路径延迟[RFC2215]是网络八位字节顺序的单个32位无符号整数。路径延迟参数的意图与[RFC2215]第3.4节中定义的最小路径延迟参数相同。此参数的目的是提供基线最小路径延迟，以便与提供额外路径延迟估计值或边界的服务一起使用，如[RFC2212]。连同[RFC2212]和类似服务提供的排队延迟边界，该参数提供了应用程序关于最小和最大数据包交付延迟的知识。
The composition rule for the <Path Latency> parameter is summation
with a clamp of (2^32) - 1 on the maximum value. The latencies are
average values reported in units of one microsecond. A system with
resolution less than one microsecond MUST set unused digits to zero.
An individual QNE can add a latency value between 1 and 2^28
(somewhat over two minutes), and the total latency added across all
QNEs can range as high as (2^32)-2. If the sum of the different
elements delays exceeds (2^32)-2, the end-to-end cumulative delay
SHOULD be reported as indeterminate = (2^32)-1. A QNE that cannot
accurately predict the latency of packets it is processing MUST raise
the Not Supported N flag and either leave the value of Path Latency
as is, or add its best estimate of its lower bound. A raised not-
supported flag indicates the value of Path Latency is a lower bound
of the real Path Latency. The distinguished value (2^32)-1 is taken
to mean indeterminate latency because the composition function limits
the composed sum to this value; it indicates the range of the
composition calculation was exceeded.
The composition rule for the <Path Latency> parameter is summation
with a clamp of (2^32) - 1 on the maximum value. The latencies are
average values reported in units of one microsecond. A system with
resolution less than one microsecond MUST set unused digits to zero.
An individual QNE can add a latency value between 1 and 2^28
(somewhat over two minutes), and the total latency added across all
QNEs can range as high as (2^32)-2. If the sum of the different
elements delays exceeds (2^32)-2, the end-to-end cumulative delay
SHOULD be reported as indeterminate = (2^32)-1. A QNE that cannot
accurately predict the latency of packets it is processing MUST raise
the Not Supported N flag and either leave the value of Path Latency
as is, or add its best estimate of its lower bound. A raised not-
supported flag indicates the value of Path Latency is a lower bound
of the real Path Latency. The distinguished value (2^32)-1 is taken
to mean indeterminate latency because the composition function limits
the composed sum to this value; it indicates the range of the
composition calculation was exceeded.
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| 4 |r|r|r|r| 4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Jitter STAT1(variance) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT2(99.9%-ile) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT3(minimum Latency) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT4(Reserved) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 4 |r|r|r|r| 4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Jitter STAT1(variance) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT2(99.9%-ile) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT3(minimum Latency) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT4(Reserved) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Jitter is a set of four 32-bit unsigned integers in network octet order [RFC3393, Y.1540, Y.1541]. As noted in Section 3.3.2, the Path Jitter parameter is called "IP Delay Variation" in [RFC3393]. The Path Jitter parameter is the combination of four statistics describing the Jitter distribution with a clamp of (2^32) - 1 on the maximum of each value. The jitter STATs are reported in units of one microsecond. A system with resolution less than one microsecond MUST set unused digits to zero. An individual QNE can add jitter values between 1 and 2^28 (somewhat over two minutes), and the total jitter computed across all QNEs can range as high as (2^32)-2. If the combination of the different element values exceeds (2^32)-2, the end-to-end cumulative jitter SHOULD be reported as indeterminate. A QNE that cannot accurately predict the jitter of packets it is processing MUST raise the not-supported flag and either leave the value of Path Jitter as is, or add its best estimate of its STAT values. A raised not-supported flag indicates the value of Path Jitter is a lower bound of the real Path Jitter. The distinguished value (2^32)-1 is taken to mean indeterminate jitter. A QNE that cannot accurately predict the jitter of packets it is processing SHOULD set its local Path Jitter parameter to this value. Because the composition function limits the total to this value, receipt of this value at a network element or application indicates that the true Path Jitter is not known. This MAY happen because one or more network elements could not supply a value or because the range of the composition calculation was exceeded.
路径抖动是一组网络八位字节顺序的四个32位无符号整数[RFC3393，Y.1540，Y.1541]。如第3.3.2节所述，路径抖动参数在[RFC3393]中称为“IP延迟变化”。路径抖动参数是描述抖动分布的四个统计数据的组合，每个值的最大值的钳位为（2^32）-1。抖动统计数据以一微秒为单位报告。分辨率小于1微秒的系统必须将未使用的数字设置为零。单个QNE可以添加介于1和2^28之间的抖动值（大约超过两分钟），并且在所有QNE上计算的总抖动范围可以高达（2^32）-2。如果不同元素值的组合超过（2^32）-2，则端到端累积抖动应报告为不确定。无法准确预测其正在处理的数据包抖动的QNE必须升起不受支持标志，或者保持路径抖动值不变，或者添加其STAT值的最佳估计值。升起的不支持标志表示路径抖动的值是实际路径抖动的下限。可分辨值（2^32）-1表示不确定抖动。无法准确预测正在处理的数据包抖动的QNE应将其本地路径抖动参数设置为此值。由于合成函数将总和限制为该值，因此在网络元件或应用程序处接收该值表示真实路径抖动未知。这可能是因为一个或多个网络元素无法提供值，或者因为超出了成分计算的范围。
NOTE: The Jitter composition function makes use of the <Path Latency> parameter. Composition functions for loss, latency, and jitter may be found in [Y.1541]. Development continues on methods to combine jitter values to estimate the value of the complete path, and additional statistics may be needed to support new methods (the methods are standardized in [RFC5481] and [COMPOSITION]).
注意：抖动合成函数使用<Path Latency>参数。损失、延迟和抖动的合成函数可在[Y.1541]中找到。继续开发结合抖动值的方法来估计完整路径的值，可能需要额外的统计数据来支持新方法（这些方法在[RFC5481]和[COMPOSITION]中标准化）。
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| 5 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Loss Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 5 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Loss Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path PLR is a single 32-bit single precision IEEE floating point number in network octet order [Y.1541]. As defined in [Y.1540], Path PLR is the ratio of total lost IP packets to total transmitted IP packets. An evaluation interval of 1 minute is suggested in [Y.1541], in which the number of losses observed is directly related to the confidence in the result. The composition rule for the <Path PLR> parameter is summation with a clamp of 10^-1 on the maximum value. The PLRs are reported in units of 10^-11. A system with resolution less than 10^-11 MUST set unused digits to zero. An individual QNE adds its local PLR value (up to a maximum of 10^-2) to the total Path PLR value (up to a maximum of 10^-1) , where the acceptability of the total Path PLR value added across all QNEs is determined based on the QOSM being used. The maximum limit of 10^-2 on a QNE's local PLR value and the maximum limit (clamp value) of 10^-1 on the accumulated end-to-end Path PLR value are used to preserve the accuracy of the simple additive accumulation function specified and to avoid more complex accumulation functions. Furthermore, if these maximums are exceeded, then the path would likely not meet the QoS objectives. If the sum of the different elements' values exceeds 10^-1, the end-to-end cumulative PLR SHOULD be reported as indeterminate. A QNE that cannot accurately predict the PLR of packets it is processing MUST raise the not-supported flag and either leave the value of Path PLR as is, or add its best estimate of its lower bound. A raised not-supported flag indicates the value of Path PLR is a lower bound of the real Path PLR. The distinguished value 10^-1 is taken to mean indeterminate PLR. A QNE that cannot accurately predict the PLR of packets it is processing SHOULD set its local path PLR parameter to this value. Because the composition function limits the composed sum to this value, receipt of this value at a network element or application indicates that the true path PLR is not known. This MAY happen because one or more network elements could not supply a value or because the range of the composition calculation was exceeded.
路径PLR是一个32位单精度IEEE浮点数，按网络八位字节顺序[Y.1541]。如[Y.1540]中所定义，路径PLR是总丢失IP数据包与总传输IP数据包的比率。[Y.1541]中建议的评估间隔为1分钟，其中观察到的损失数量与结果的置信度直接相关。<Path PLR>参数的合成规则是在最大值上用10^-1的钳位求和。PLR以10^-11为单位进行报告。分辨率小于10^-11的系统必须将未使用的数字设置为零。单个QNE将其本地PLR值（最多10^-2）添加到总路径PLR值（最多10^-1），其中基于所使用的QOSM确定在所有QNE上添加的总路径PLR值的可接受性。QNE局部PLR值的最大限值为10^-2，累积端到端路径PLR值的最大限值（钳位值）为10^-1，用于保持规定的简单相加累积函数的准确性，并避免更复杂的累积函数。此外，如果超过这些最大值，则路径可能无法满足QoS目标。如果不同元素值之和超过10^-1，则端到端累积PLR应报告为不确定。无法准确预测其正在处理的数据包的PLR的QNE必须升起不支持标志，并保持路径PLR的值不变，或添加其下限的最佳估计值。升起的不支持标志表示路径PLR的值是实际路径PLR的下限。可分辨值10^-1表示不确定PLR。无法准确预测正在处理的数据包的PLR的QNE应将其本地路径PLR参数设置为此值。由于合成函数将合成和限制为该值，因此在网络元件或应用程序处接收该值表示真实路径PLR未知。这可能是因为一个或多个网络元素无法提供值，或者因为超出了成分计算的范围。
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| 6 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Error Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 6 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Error Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path PER is a single 32-bit single precision IEEE floating point number in network octet order [Y.1541]. As defined in [Y.1540], Path PER is the ratio of total errored IP packets to the total of successful IP Packets plus errored IP packets, in which the number of errored packets observed is directly related to the confidence in the result. The composition rule for the <Path PER> parameter is summation with a clamp of 10^-1 on the maximum value. The PERs are reported in units of 10^-11. A system with resolution less than 10^-11 MUST set unused digits to zero. An individual QNE adds its local PER value (up to a maximum of 10^-2) to the total Path PER value (up to a maximum of 10^-1) , where the acceptability of the total Path PER value added across all QNEs is determined based on the QOSM being used. The maximum limit of 10^-2 on a QNE's local PER value and the maximum limit (clamp value) of 10^-1 on the accumulated end-to-end Path PER value are used to preserve the accuracy of the simple additive accumulation function specified and to avoid more complex accumulation functions. Furthermore, if these maximums are exceeded, then the path would likely not meet the QoS objectives. If the sum of the different elements' values exceeds 10^-1, the end-to-end cumulative PER SHOULD be reported as indeterminate. A QNE that cannot accurately predict the PER of packets it is processing MUST raise the Not Supported N flag and either leave the value of Path PER as is, or add its best estimate of its lower bound. A raised Not Supported N flag indicates the value of Path PER is a lower bound of the real Path PER. The distinguished value 10^-1 is taken to mean indeterminate PER. A QNE that cannot accurately predict the PER of packets it is processing SHOULD set its local path PER parameter to this value. Because the composition function limits the composed sum to this value, receipt of this value at a network element or application indicates that the true path PER is not known. This MAY happen because one or more network elements could not supply a value or because the range of the composition calculation was exceeded.
PER路径是一个32位单精度IEEE浮点数，按网络八位字节顺序[Y.1541]。如[Y.1540]中所定义，Path PER是错误IP数据包总数与成功IP数据包总数加上错误IP数据包的比率，其中观察到的错误数据包数量与结果的可信度直接相关。<Path PER>参数的组合规则是在最大值上使用10^-1的钳位求和。PER以10^-11为单位进行报告。分辨率小于10^-11的系统必须将未使用的数字设置为零。单个QNE将其本地PER值（最多10^-2）添加到总路径PER值（最多10^-1），其中基于所使用的QOSM确定在所有QNE中添加的总路径PER值的可接受性。QNE局部每值的最大限值为10^-2，累积端到端路径每值的最大限值（钳位值）为10^-1，用于保持指定的简单相加累积函数的准确性，并避免更复杂的累积函数。此外，如果超过这些最大值，则路径可能无法满足QoS目标。如果不同元素的值之和超过10^-1，则端到端累积PER应报告为不确定。无法准确预测其正在处理的数据包的PER的QNE必须提升不受支持的N标志，或者保持Path PER的值不变，或者添加其下限的最佳估计值。raised Not SUPPORED N标志表示路径PER的值是实际路径PER的下限。可分辨值10^-1表示每分钟不确定。无法准确预测正在处理的数据包的PER的QNE应将其本地路径PER参数设置为此值。由于合成函数将合成和限制为该值，因此在网元或应用程序上接收到该值表示不知道PER的真实路径。这可能是因为一个或多个网络元素无法提供值，或者因为超出了成分计算的范围。
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| 7 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slack Term (S) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 7 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slack Term (S) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Slack term S MUST be nonnegative and is measured in microseconds [RFC2212]. The Slack term, S, is represented as a 32-bit unsigned integer. Its value can range from 0 to (2^32)-1 microseconds.
松弛项S必须为非负，并以微秒为单位进行测量[RFC2212]。松弛项S表示为32位无符号整数。其值的范围为0到（2^32）-1微秒。
The coding for the <Preemption Priority> and <Defending Priority> sub-parameters is as follows [RFC3181]:
<抢占优先级>和<防御优先级>子参数的编码如下[RFC3181]：
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| 8 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption Priority | Defending Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 8 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption Priority | Defending Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preemption Priority: The priority of the new flow compared with the defending priority of previously admitted flows. Higher values represent higher priority.
抢占优先级：新流的优先级与先前允许的流的防御优先级相比。值越高表示优先级越高。
Defending Priority: Once a flow is admitted, the preemption priority becomes irrelevant. Instead, its defending priority is used to compare with the preemption priority of new flows.
防御优先级：一旦允许流，抢占优先级就变得无关紧要。相反，它的防御优先级用于与新流的抢占优先级进行比较。
As specified in [RFC3181], <Preemption Priority> and <Defending Priority> are 16-bit integer values, and both MUST be populated if the parameter is used.
如[RFC3181]所述，<Preemption Priority>和<detection Priority>是16位整数值，如果使用参数，则必须填充这两个整数值。
The coding for the <Admission Priority> parameter is as follows:
<Admission Priority>参数的编码如下：
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| 9 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.2171 Adm Pri.|Admis. Priority| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 9 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.2171 Adm Pri.|Admis. Priority| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Two fields are provided for the <Admission Priority> parameter and are populated according to the following rules.
为<准入优先级>参数提供了两个字段，并根据以下规则填充。
<Y.2171 Admission Priority> values are globally significant on an end-to-end basis. High priority flows, normal priority flows, and best-effort priority flows can have access to resources depending on their admission priority value, as described in [Y.2171], as follows:
<Y.2171准入优先级>值在端到端基础上具有全局意义。高优先级流、正常优先级流和尽力而为优先级流可以根据其准入优先级值访问资源，如[Y.2171]中所述，如下所示：
<Y.2171 Admission Priority>:
<Y.2171入学优先级>：
0 - best-effort priority flow 1 - normal priority flow 2 - high priority flow
0-尽力而为优先级流1-正常优先级流2-高优先级流
If the QNI signals <Y.2171 Admission Priority>, it populates both the <Y.2171 Admission Priority> and <Admission Priority> fields with the same value. Downstream QNEs MUST NOT change the value in the <Y.2171 Admission Priority> field so that end-to-end consistency is maintained and MUST treat the flow priority according to the value populated. A QNE in a local domain MAY reset a different value of <Admission Priority> in a Local QSPEC, but (as specified in Section 4.1) the Local QSPEC MUST be consistent with the Initiator QSPEC. That is, the local domain MUST specify an <Admission Priority> in the Local QSPEC that is functionally equivalent to the <Y.2171 Admission Priority> specified by the QNI in the Initiator QSPEC.
如果QNI信号<Y.2171准入优先级>，则它用相同的值填充<Y.2171准入优先级>和<准入优先级>字段。下游QNE不得更改<Y.2171准入优先级>字段中的值，以保持端到端一致性，并且必须根据填充的值处理流量优先级。本地域中的QNE可在本地QSPEC中重置不同的<准入优先级>，但（如第4.1节所规定）本地QSPEC必须与启动器QSPEC一致。也就是说，本地域必须在本地QSPEC中指定一个功能等同于QNI在启动器QSPEC中指定的<Y.2171准入优先级>。
If the QNI signals admission priority according to [EMERGENCY-RSVP], it populates a locally significant value in the <Admission Priority> field and places all ones in the <Y.2171 Admission Priority> field. In this case, the functional significance of the <Admission Priority> value is specified by the local network administrator. Higher values indicate higher priority. Downstream QNEs and RSVP nodes MAY reset the <Admission Priority> value according to the local rules specified by the local network administrator, but MUST NOT reset the value of the <Y.2171 Admission Priority> field.
如果QNI根据[EMERGENCY-RSVP]发出准入优先级信号，它会在<Acquisition priority>字段中填充一个本地有效值，并将所有值放置在<Y.2171 Acquisition priority>字段中。在这种情况下，<准入优先级>值的功能重要性由本地网络管理员指定。值越高表示优先级越高。下游QNE和RSVP节点可以根据本地网络管理员指定的本地规则重置<allocation Priority>值，但不得重置<Y.2171 allocation Priority>字段的值。
A reservation without an <Y.2171 Admission Priority> parameter MUST be treated as a reservation with an <Y.2171 Admission Priority> = 1.
没有<Y.2171准入优先级>参数的预订必须视为<Y.2171准入优先级>=1的预订。
The coding for the <RPH Priority> parameter is as follows:
<RPH优先级>参数的编码如下：
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| 10 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPH Namespace | RPH Priority | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 10 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPH Namespace | RPH Priority | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[RFC4412] defines a resource priority header (RPH) with parameters "RPH Namespace" and "RPH Priority", and if populated is applicable only to flows with high admission priority. A registry is created in [RFC4412] and extended in [EMERG-RSVP] for IANA to assign the RPH priority parameter. In the extended registry, "Namespace Numerical Values" are assigned by IANA to RPH Namespaces and "Priority Numerical Values" are assigned to the RPH Priority.
[RFC4412]使用参数“RPH名称空间”和“RPH优先级”定义资源优先级头（RPH），如果填充，则仅适用于具有高准入优先级的流。[RFC4412]中创建了一个注册表，并在[EMERG-RSVP]中进行了扩展，以便IANA分配RPH优先级参数。在扩展注册表中，“名称空间数值”由IANA分配给RPH名称空间，“优先级数值”分配给RPH优先级。
Note that the <Admission Priority> parameter MAY be used in combination with the <RPH Priority> parameter, which depends on the supported QOSM. Furthermore, if more than one RPH namespace is supported by a QOSM, then the QOSM MUST specify how the mapping between the priorities belonging to the different RPH namespaces are mapped to each other.
请注意，<Admission Priority>参数可与<RPH Priority>参数结合使用，这取决于支持的QOSM。此外，如果QOSM支持多个RPH命名空间，则QOSM必须指定属于不同RPH命名空间的优先级之间的映射如何相互映射。
Note also that additional work is needed to communicate these flow priority values to bearer-level network elements [VERTICAL-INTERFACE].
还要注意，需要额外的工作来将这些流优先级值传送到承载级网络元件[垂直接口]。
For the 4 priority parameters, the following cases are permissible (procedures specified in references):
对于4个优先级参数，允许以下情况（参考文件中规定的程序）：
1 parameter: <Admission Priority> [Y.2171]
2 parameters: <Admission Priority>, <RPH Priority> [RFC4412]
2 parameters: <Preemption Priority>, <Defending Priority> [RFC3181]
3 parameters: <Preemption Priority>, <Defending Priority>,
<Admission Priority> [3GPP-1, 3GPP-2, 3GPP-3]
4 parameters: <Preemption Priority>, <Defending Priority>,
<Admission Priority>, <RPH Priority> [3GPP-1, 3GPP-2,
3GPP-3]
1 parameter: <Admission Priority> [Y.2171]
2 parameters: <Admission Priority>, <RPH Priority> [RFC4412]
2 parameters: <Preemption Priority>, <Defending Priority> [RFC3181]
3 parameters: <Preemption Priority>, <Defending Priority>,
<Admission Priority> [3GPP-1, 3GPP-2, 3GPP-3]
4 parameters: <Preemption Priority>, <Defending Priority>,
<Admission Priority>, <RPH Priority> [3GPP-1, 3GPP-2,
3GPP-3]
It is permissible to have <Admission Priority> without <RPH Priority>, but not permissible to have <RPH Priority> without <Admission Priority>. (Alternatively, <RPH Priority> is ignored in instances without <Admission Priority>.)
允许在没有<RPH优先级>的情况下拥有<准入优先级>，但不允许在没有<RPH优先级>的情况下拥有<RPH优先级>。（或者，在没有<准入优先级>的情况下，<RPH优先级>被忽略）
Functionality similar to enhanced Multi-Level Precedence and Preemption service (eMLPP; as defined in [3GPP-1, 3GPP-2]) specifies use of <Admission Priority> corresponding to the 'queuing allowed' part of eMLPP, as well as <Preemption/Defending Priority> corresponding to the 'preemption capable' and 'may be preempted' parts of eMLPP.
类似于增强型多级优先和抢占服务（eMLPP；如[3GPP-1，3GPP-2]中所定义）的功能规定了与eMLPP的“允许排队”部分相对应的<准入优先级>的使用，以及与eMLPP的“可抢占”和“可抢占”部分相对应的<抢占/防御优先级>。
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| 11 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Trtmnt |Re-mark Val| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 11 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Trtmnt |Re-mark Val| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Excess Treatment: Indicates how the QNE SHOULD process out-of-profile traffic, that is, traffic not covered by the <TMOD> parameter. The Excess Treatment Parameter is set by the QNI. Allowed values are as follows:
过度处理：指示QNE应如何处理配置文件外的流量，即<TMOD>参数未涵盖的流量。过量处理参数由QNI设置。允许值如下所示：
0: drop 1: shape 2: re-mark 3: no metering or policing is permitted
0:下降1:形状2:重新标记3:不允许计量或监控
If no Excess Treatment Parameter is specified, the default is that there are no guarantees to excess traffic, i.e., a QNE can do whatever it finds suitable.
如果未指定超额处理参数，则默认情况下不保证超额流量，即QNE可以执行其认为合适的任何操作。
When excess treatment is set to 'drop', all marked traffic MUST be dropped by the QNE/RMF.
当过量处理设置为“下降”时，QNE/RMF必须下降所有标记的流量。
When excess treatment is set to 'shape', it is expected that the QoS Desired object carries a TMOD parameter, and excess traffic is shaped to this TMOD. The bucket size in the TMOD parameter for excess traffic specifies the queuing behavior, and when the shaping causes unbounded queue growth at the shaper, any traffic in excess of the TMOD for excess traffic SHOULD be dropped. If excess treatment is set to 'shape' and no TMOD parameter is given, the E flag is set for the parameter and the reservation fails. If
当过量处理设置为“shape”时，期望QoS所需对象携带TMOD参数，并且过量流量被塑造为该TMOD。过量流量的TMOD参数中的bucket size指定排队行为，当整形导致整形器中的队列无限增长时，任何超过过量流量TMOD的流量都应丢弃。如果过度处理设置为“shape”，且未给出TMOD参数，则为参数设置E标志，保留失败。如果
excess treatment is set to 'shape' and two TMOD parameters are specified, then the QOSM specification dictates how excess traffic should be shaped in that case.
超额处理设置为“形状”，并指定了两个TMOD参数，然后QOSM规范规定了在这种情况下应如何塑造超额流量。
When excess treatment is set to 're-mark', the Excess Treatment Parameter MUST carry the re-mark value, and the re-mark values and procedures MUST be specified in the QOSM specification document. For example, packets may be re-marked to pertain to a particular QoS class (Diffserv Code Point (DSCP) value). In the latter case, re-marking relates to a Diffserv model where packets arrive marked as belonging to a certain QoS class / DSCP, and when they are identified as excess, they should then be re-marked to a different QoS Class (DSCP value) indicated in the 'Re-mark Value', as follows:
当过度治疗设置为“重新标记”时，过度治疗参数必须带有重新标记值，并且必须在QOSM规范文件中指定重新标记值和程序。例如，可以将分组重新标记为属于特定QoS类（区分服务码点（DSCP）值）。在后一种情况下，重新标记与Diffserv模型有关，其中数据包到达时被标记为属于某个QoS类别/DSCP，并且当它们被标识为多余时，应将其重新标记为“重新标记值”中指示的不同QoS类别（DSCP值），如下所示：
Re-mark Value (6 bits): indicates DSCP value [RFC2474] to re-mark packets to when identified as excess
重新标记值（6位）：当识别为多余时，指示要重新标记数据包的DSCP值[RFC2474]
If 'no metering or policing is permitted' is signaled, the QNE should accept the Excess Treatment Parameter set by the sender with special care so that excess traffic should not cause a problem. To request the Null Meter [RFC3290] is especially strong, and should be used with caution.
如果发出“不允许计量或监控”的信号，QNE应特别小心地接受发送方设置的过量处理参数，以便过量流量不会造成问题。要求零位计[RFC3290]的强度特别大，应谨慎使用。
A NULL metering application [RFC2997] would not include the traffic profile, and conceptually it should be possible to support this with the QSPEC. A QSPEC without a traffic profile is not excluded by the current specification. However, note that the traffic profile is important even in those cases when the excess treatment is not specified, e.g., in negotiating bandwidth for the best-effort aggregate. However, a "NULL Service QOSM" would need to be specified where the desired QNE Behavior and the corresponding QSPEC format are described.
空计量应用程序[RFC2997]不包括流量配置文件，从概念上讲，QSPEC应该可以支持这一点。当前规范不排除没有流量配置文件的QSPEC。然而，请注意，即使在未指定过度处理的情况下，例如，在为尽力而为的聚合协商带宽时，流量分布也很重要。但是，如果描述了所需的QNE行为和相应的QSPEC格式，则需要指定“空服务QOSM”。
As an example behavior for a NULL metering, in the properly configured Diffserv router, the resources are shared between the aggregates by the scheduling disciplines. Thus, if the incoming rate increases, it will influence the state of a queue within that aggregate, while all the other aggregates will be provided sufficient bandwidth resources. NULL metering is useful for best-effort and signaling data, where there is no need to meter and police this data as it will be policed implicitly by the allocated bandwidth and, possibly, active queue management mechanism.
作为空计量的示例行为，在正确配置的Diffserv路由器中，资源由调度规程在聚合之间共享。因此，如果传入速率增加，它将影响该聚合内队列的状态，而所有其他聚合将被提供足够的带宽资源。空计量对于尽力而为和信令数据非常有用，因为它将由分配的带宽和活动队列管理机制隐式地进行管理，因此无需计量和管理此数据。
The coding for the <PHB Class> parameter is as follows [RFC3140]:
<PHB Class>参数的编码如下[RFC3140]：
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| 12 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB Field | (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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| 12 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB Field | (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The above encoding is consistent with [RFC3140], and the following four figures show four possible formats based on the value of the PHB Field.
上述编码与[RFC3140]一致，以下四幅图显示了基于PHB字段值的四种可能格式。
Single PHB:
单个PHB：
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 0 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 0 0|
+---+---+---+---+---+---+---+---+
Set of PHBs:
一套PHB：
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 1 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 1 0|
+---+---+---+---+---+---+---+---+
PHBs not defined by standards action, i.e., experimental or local use PHBs as allowed by [RFC2474]. In this case, an arbitrary 12-bit PHB identification code, assigned by the IANA, is placed left-justified in the 16-bit field. Bit 15 is set to 1, and bit 14 is zero for a single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero.
标准行动中未定义PHB，即[RFC2474]允许的实验或本地使用PHB。在这种情况下，IANA分配的任意12位PHB识别码将左对齐放置在16位字段中。对于单个PHB，位15设置为1，对于一组PHB，位14为0或1。第12位和第13位为零。
Single non-standard PHB (experimental or local):
单个非标准PHB（实验或本地）：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB ID CODE |0 0 0 1|
+---+---+---+---+---+---+---+---+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB ID CODE |0 0 0 1|
+---+---+---+---+---+---+---+---+
Set of non-standard PHBs (experimental or local):
一套非标准PHB（实验或本地）：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB ID CODE |0 0 1 1|
+---+---+---+---+---+---+---+---+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB ID CODE |0 0 1 1|
+---+---+---+---+---+---+---+---+
Bits 12 and 13 are reserved either for expansion of the PHB identification code, or for other use, at some point in the future.
位12和13保留用于PHB标识码的扩展，或用于将来某个时候的其他用途。
In both cases, when a single PHBID is used to identify a set of PHBs (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB Scheduling Class (i.e., use of PHBs from the set MUST NOT cause intra-microflow traffic reordering when different PHBs from the set are applied to traffic in the same microflow). The set of AF1x PHBs [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that do not constitute a PHB Scheduling Class can be identified by using more than one PHBID.
在这两种情况下，当使用单个PHBID识别一组PHB（即，位14设置为1）时，该组PHB必须构成PHB调度类（即，当同一微流中的不同PHB应用于同一微流中的流量时，使用该组PHB不得导致微流内流量重新排序）。AF1x PHB集合[RFC2597]是PHB调度类的一个示例。可以通过使用多个PHBID来识别不构成PHB调度类的PHB集。
The registries needed to use RFC 3140 already exist; see [DSCP-REGISTRY] and [PHBID-CODES-REGISTRY]. Hence, no new registry needs to be created for this purpose.
使用RFC 3140所需的登记册已经存在；请参阅[DSCP-REGISTRY]和[PHBID-CODES-REGISTRY]。因此，不需要为此目的创建新的注册表。
A description of the semantic of the parameter values can be found in [RFC4124]. The coding for the <DSTE Class Type> parameter is as follows:
有关参数值语义的说明，请参见[RFC4124]。<DSTE Class Type>参数的编码如下：
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| 13 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DSTE Cls. Type | (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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| 13 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DSTE Cls. Type | (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
DSTE Class Type: Indicates the DSTE class type. Values currently allowed are 0, 1, 2, 3, 4, 5, 6, and 7.
DSTE类类型：表示DSTE类类型。当前允许的值为0、1、2、3、4、5、6和7。
The coding for the <Y.1541 QoS Class> parameter [Y.1541] is as follows:
<Y.1541 QoS Class>参数[Y.1541]的编码如下：
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| 14 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.1541 QoS Cls.| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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| 14 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.1541 QoS Cls.| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently allowed are 0, 1, 2, 3, 4, 5, 6, and 7.
Y.1541 QoS等级：表示Y.1541 QoS等级。当前允许的值为0、1、2、3、4、5、6和7。
Class 0: Real-time, highly interactive applications, sensitive to jitter. Mean delay <= 100 ms, delay variation <= 50 ms, and loss ratio <= 10^-3. Application examples include VoIP and video teleconference.
0类：实时、高度交互的应用程序，对抖动敏感。平均延迟<=100ms，延迟变化<=50ms，损失率<=10^-3。应用示例包括VoIP和视频电话会议。
Class 1: Real-time, interactive applications, sensitive to jitter. Mean delay <= 400 ms, delay variation <= 50 ms, and loss ratio <= 10^-3. Application examples include VoIP and video teleconference.
第1类：实时、交互式应用程序，对抖动敏感。平均延迟<=400ms，延迟变化<=50ms，损失率<=10^-3。应用示例包括VoIP和视频电话会议。
Class 2: Highly interactive transaction data. Mean delay <= 100 ms, delay variation is unspecified, loss ratio <= 10^-3. Application examples include signaling.
类别2：高度交互的事务数据。平均延迟<=100ms，未指定延迟变化，损失率<=10^-3。应用示例包括信令。
Class 3: Interactive transaction data. Mean delay <= 400 ms, delay variation is unspecified, loss ratio <= 10^-3. Application examples include signaling.
类别3：交互式交易数据。平均延迟<=400ms，未指定延迟变化，损失率<=10^-3。应用示例包括信令。
Class 4: Low Loss Only applications. Mean delay <= 1 s, delay variation is unspecified, loss ratio <= 10^-3. Application examples include short transactions, bulk data, and video streaming.
第4类：仅低损耗应用。平均延迟<=1s，延迟变化未指定，损失率<=10^-3。应用程序示例包括短事务、批量数据和视频流。
Class 5: Unspecified applications with unspecified mean delay, delay variation, and loss ratio. Application examples include traditional applications of default IP networks.
第5类：未指定平均延迟、延迟变化和损失率的未指定应用。应用程序示例包括默认IP网络的传统应用程序。
Class 6: Applications that are highly sensitive to loss. Mean delay <= 100 ms, delay variation <= 50 ms, and loss ratio <= 10^-5. Application examples include television transport, high-capacity TCP transfers, and Time-Division Multiplexing (TDM) circuit emulation.
第6类：对丢失高度敏感的应用程序。平均延迟<=100ms，延迟变化<=50ms，损失率<=10^-5。应用实例包括电视传输、大容量TCP传输和时分复用（TDM）电路仿真。
Class 7: Applications that are highly sensitive to loss. Mean delay <= 400 ms, delay variation <= 50 ms, and loss ratio <= 10^-5. Application examples include television transport, high-capacity TCP transfers, and TDM circuit emulation.
类别7：对丢失高度敏感的应用程序。平均延迟<=400ms，延迟变化<=50ms，损失率<=10^-5。应用实例包括电视传输、大容量TCP传输和TDM电路仿真。
QSPEC security is directly tied to QoS NSLP security, and the QoS NSLP document [RFC5974] has a very detailed security discussion in Section 7. All the considerations detailed in Section 7 of [RFC5974] apply to QSPEC.
QSPEC安全性与QoS NSLP安全性直接相关，QoS NSLP文档[RFC5974]在第7节中有非常详细的安全性讨论。[RFC5974]第7节中详述的所有注意事项适用于QSPEC。
The priority parameter raises possibilities for theft-of-service attacks because users could claim an emergency priority for their flows without real need, thereby effectively preventing serious emergency calls to get through. Several options exist for countering such attacks, for example:
priority参数增加了服务盗窃攻击的可能性，因为用户可以在没有实际需要的情况下为其流申请紧急优先级，从而有效防止严重的紧急呼叫接通。有几种方法可用于对付此类攻击，例如：
- only some user groups (e.g., the police) are authorized to set the emergency priority bit
- 只有一些用户组（例如警察）有权设置紧急优先级位
- any user is authorized to employ the emergency priority bit for particular destination addresses (e.g., police)
- 任何用户都有权为特定目的地地址（如警察）使用紧急优先级位
This section defines the registries and initial codepoint assignments for the QSPEC template, in accordance with BCP 26, RFC 5226 [RFC5226]. It also defines the procedural requirements to be followed by IANA in allocating new codepoints.
本节根据BCP 26、RFC 5226[RFC5226]定义了QSPEC模板的注册和初始代码点分配。它还定义了IANA在分配新代码点时应遵循的程序要求。
This specification creates the following registries with the structures as defined below:
本规范创建具有以下定义结构的以下注册表：
Object Types (12 bits): The following values are allocated as specified in Section 5: 0: QoS Desired 1: QoS Available 2: QoS Reserved 3: Minimum QoS
对象类型（12位）：按照第5节的规定分配以下值：0:QoS期望值1:QoS可用值2:QoS保留值3:Minimum QoS
Further values are as follows: 4-63: Unassigned 64-67: Private/Experimental Use 68-4095: Reserved (Note: 'Reserved' just means 'do not give these out'.) The registration procedure is Specification Required.
进一步的值如下：4-63：未分配64-67：私人/实验用途68-4095：保留（注：“保留”仅表示“不要给出这些”。）注册程序是必需的。
QSPEC Version (4 bits): The following value is allocated by this specification: 0: Version 0 QSPEC Further values are as follows: 1-15: Unassigned The registration procedure is Specification Required. (A specification is required to depreciate, delete, or modify QSPEC versions.)
QSPEC版本（4位）：以下值由本规范分配：0:版本0 QSPEC其他值如下：1-15:未分配注册程序是规范要求的。（折旧、删除或修改QSPEC版本需要规范。）
QSPEC Type (5 bits): The following values are allocated by this specification: 0: Default 1: Y.1541-QOSM [RFC5976] 2: RMD-QOSM [RFC5977] Further values are as follows: 3-12: Unassigned 13-16: Local/Experimental Use 17-31: Reserved The registration procedure is Specification Required.
QSPEC类型（5位）：以下值由本规范分配：0：默认值1:Y.1541-QOSM[RFC5976]2:RMD-QOSM[RFC5977]其他值如下：3-12：未分配13-16：本地/实验使用17-31：保留注册程序是规范要求的。
QSPEC Procedure (8 bits): The QSPEC Procedure object consists of the Message Sequence parameter (4 bits) and the Object Combination parameter (4 bits), as discussed in Section 4.3. Message Sequences 0 (Two-Way Transactions), 1 (Three-Way Transactions), and 2 (Resource Queries) are explained in Sections 4.3.1, 4.3.2, and 4.3.3, respectively. Tables 1, 2, and 3 in Section 4.3 assign the Object Combination Number to Message Sequences 0, 1, and 2, respectively. The values assigned by this specification for the Message Sequence parameter and the Object Combination parameter are summarized here:
QSPEC过程（8位）：QSPEC过程对象由消息序列参数（4位）和对象组合参数（4位）组成，如第4.3节所述。第4.3.1、4.3.2和4.3.3节分别解释了消息序列0（双向事务）、1（三向事务）和2（资源查询）。第4.3节中的表1、2和3分别将对象组合号分配给消息序列0、1和2。本规范为消息序列参数和对象组合参数指定的值汇总如下：
MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED
SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
-------------------------------------------------------------------
0 |0 |N/A |QoS Desired |QoS Reserved
| | | |
0 |1 |N/A |QoS Desired |QoS Reserved
| |N/A |QoS Available |QoS Available
| | | |
0 |2 |N/A |QoS Desired |QoS Reserved
| |N/A |QoS Available |QoS Available
| |N/A |Minimum QoS |
| | | |
1 |0 |QoS Desired |QoS Desired |QoS Reserved
| | | |
1 |1 |QoS Desired |QoS Desired |QoS Reserved
| |(Minimum QoS) |QoS Available |QoS Available
| | |(Minimum QoS) |
| | | |
1 |2 |QoS Desired |QoS Desired |QoS Reserved
| |QoS Available |QoS Available |
| | | |
2 |0 |QoS Available |N/A |QoS Available
MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED
SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE
-------------------------------------------------------------------
0 |0 |N/A |QoS Desired |QoS Reserved
| | | |
0 |1 |N/A |QoS Desired |QoS Reserved
| |N/A |QoS Available |QoS Available
| | | |
0 |2 |N/A |QoS Desired |QoS Reserved
| |N/A |QoS Available |QoS Available
| |N/A |Minimum QoS |
| | | |
1 |0 |QoS Desired |QoS Desired |QoS Reserved
| | | |
1 |1 |QoS Desired |QoS Desired |QoS Reserved
| |(Minimum QoS) |QoS Available |QoS Available
| | |(Minimum QoS) |
| | | |
1 |2 |QoS Desired |QoS Desired |QoS Reserved
| |QoS Available |QoS Available |
| | | |
2 |0 |QoS Available |N/A |QoS Available
Further values of the Message Sequence parameter (4 bits) are as follows: 3-15: Unassigned
消息序列参数（4位）的其他值如下：3-15：未分配
Further values of the Object Combination parameter (4 bits) are as follows:
对象组合参数（4位）的其他值如下所示：
Message | Object
Sequence | Combination
---------------------------
0 | 3-15: Unassigned
1 | 3-15: Unassigned
2 | 1-15: Unassigned
3-15 | 0-15: Unassigned
Message | Object
Sequence | Combination
---------------------------
0 | 3-15: Unassigned
1 | 3-15: Unassigned
2 | 1-15: Unassigned
3-15 | 0-15: Unassigned
The registration procedure is Specification Required. (A specification is required to depreciate, delete, or modify QSPEC Procedures.)
注册程序是必需的。（折旧、删除或修改QSPEC程序需要规范。）
QoS Model Error Code (8 bits): QoS Model Error Codes may be defined for NSLP error class 6 (QoS Model Error), as described in Section 6.4 of [RFC5974]. Values are as follows: 0-63: Unassigned 64-67: Private/Experimental Use
QoS模型错误代码（8位）：可以为NSLP错误类别6（QoS模型错误）定义QoS模型错误代码，如[RFC5974]第6.4节所述。数值如下：0-63：未分配64-67：私人/实验用途
68-255: Reserved The registration procedure is Specification Required. (A specification is required to depreciate, delete, or modify QoS Model Error Codes.)
68-255：保留要求的注册程序。（降低、删除或修改QoS模型错误代码需要规范。）
Parameter ID (12 bits): The following values are allocated by this specification: 1-14: assigned as specified in Section 5.2: 1: <TMOD-1> 2: <TMOD-2> 3: <Path Latency> 4: <Path Jitter> 5: <Path PLR> 6: <Path PER> 7: <Slack Term> 8: <Preemption Priority> and <Defending Priority> 9: <Admission Priority> 10: <RPH Priority> 11: <Excess Treatment> 12: <PHB Class> 13: <DSTE Class Type> 14: <Y.1541 QoS Class> Further values are as follows: 15-255: Unassigned 256-259: Private/Experimental Use 260-4095: Reserved The registration procedure is Specification Required. (A specification is required to depreciate, delete, or modify Parameter IDs.)
参数ID（12位）：以下值由本规范分配：1-14：按照第5.2节的规定分配：1:<TMOD-1>2:<TMOD-2>3:<Path Latency>4:<Path Jitter>5:<Path PLR>6:<Path PER>7:<Slack Term>8:<Preemption Priority>和<detection Priority>9:<Admission Priority>10:<RPH Priority>11:<over Treatment>12:<PHB Class>13:<DSTE类别类型>14:<Y.1541 QoS类别>其他值如下：15-255:未分配256-259:专用/实验用途260-4095:保留注册程序是必需的。（折旧、删除或修改参数ID需要规范。）
Y.2171 Admission Priority Parameter (8 bits): The following values are allocated by this specification: 0-2: assigned as specified in Section 5.2.9: 0: best-effort priority flow 1: normal priority flow 2: high priority flow Further values are as follows: 3-63: Unassigned 64-255: Reserved The registration procedure is Specification Required.
Y.2171准入优先级参数（8位）：本规范分配以下值：0-2：按照第5.2.9节的规定分配：0：尽力而为优先级流1：正常优先级流2：高优先级流其他值如下：3-63：未分配64-255：保留注册程序是规范要求的。
RPH Namespace Parameter (16 bits): Note that [RFC4412] creates a registry for RPH Namespace and Priority values already (see Section 12.6 of [RFC4412]), and an extension to this registry is created in [EMERG-RSVP], which will also be used for the QSPEC RPH parameter. In the extended registry, "Namespace Numerical Values" are assigned by IANA to RPH Namespaces, and
RPH名称空间参数（16位）：请注意，[RFC4412]已经为RPH名称空间和优先级值创建了一个注册表（请参见[RFC4412]的第12.6节），并且在[EMERG-RSVP]中创建了该注册表的扩展，该扩展也将用于QSPEC RPH参数。在扩展注册表中，“名称空间数值”由IANA分配给RPH名称空间，以及
"Priority Numerical Values" are assigned to the RPH Priority. There are no additional IANA requirements made by this specification for the RPH Namespace Parameter.
“优先级数值”分配给RPH优先级。本规范对RPH名称空间参数没有其他IANA要求。
Excess Treatment Parameter (8 bits): The following values are allocated by this specification: 0-3: assigned as specified in Section 5.2.11: 0: drop 1: shape 2: re-mark 3: no metering or policing is permitted Further values are as follows: 4-63: Unassigned 64-255: Reserved The registration procedure is Specification Required.
过量处理参数（8位）：以下值由本规范分配：0-3：按照第5.2.11节的规定分配：0：下降1：形状2：重新标记3：不允许计量或监管。其他值如下：4-63：未分配64-255：保留。要求注册程序。
Y.1541 QoS Class Parameter (8 bits): The following values are allocated by this specification: 0-7: assigned as specified in Section 5.2.14: 0: Y.1541 QoS Class 0 1: Y.1541 QoS Class 1 2: Y.1541 QoS Class 2 3: Y.1541 QoS Class 3 4: Y.1541 QoS Class 4 5: Y.1541 QoS Class 5 6: Y.1541 QoS Class 6 7: Y.1541 QoS Class 7 Further values are as follows: 8-63: Unassigned 64-255: Reserved The registration procedure is Specification Required.
Y.1541 QoS类参数（8位）：本规范分配了以下值：0-7：按照第5.2.14节的规定分配：0:Y.1541 QoS等级01:Y.1541 QoS等级12:Y.1541 QoS等级23:Y.1541 QoS等级34:Y.1541 QoS等级45:Y.1541 QoS等级56:Y.1541 QoS等级67:Y.1541 QoS等级7其他值如下：8-63：未分配64-255：保留注册程序是必需的。
The authors would like to thank (in alphabetical order) David Black, Ken Carlberg, Anna Charny, Christian Dickman, Adrian Farrel, Ruediger Geib, Matthias Friedrich, Xiaoming Fu, Janet Gunn, Robert Hancock, Chris Lang, Jukka Manner, Martin Stiemerling, An Nguyen, Tom Phelan, James Polk, Alexander Sayenko, John Rosenberg, Hannes Tschofenig, and Sven van den Bosch for their very helpful suggestions.
作者要感谢（按字母顺序排列）大卫·布莱克、肯·卡尔伯格、安娜·查尼、克里斯蒂安·迪克曼、阿德里安·法雷尔、鲁迪格·盖布、马蒂亚斯·弗里德里希、傅晓明、珍妮特·冈恩、罗伯特·汉考克、克里斯·朗、朱卡·韦德、马丁·斯蒂梅林、安·阮、汤姆·费兰、詹姆斯·波尔克、亚历山大·萨耶恩科、约翰·罗森伯格、汉内斯·茨霍芬尼、，以及斯文·范登·博世的非常有益的建议。
This document is the result of the NSIS Working Group effort. In addition to the authors/editors listed in Section 12, the following people contributed to the document:
本文件是NSIS工作组努力的结果。除第12节中列出的作者/编辑外，以下人员也参与了该文件：
Roland Bless Institute of Telematics, Karlsruhe Institute of Technology (KIT) Zirkel 2, Building 20.20 P.O. Box 6980 Karlsruhe 76049 Germany Phone: +49 721 608 6413 EMail: bless@kit.edu URI: http://tm.kit.edu/~bless
罗兰·布莱斯远程通信研究所，卡尔斯鲁厄理工学院（KIT）Zirkel 2号楼20.20信箱6980卡尔斯鲁厄76049德国电话：+49 721 608 6413电子邮件：bless@kit.eduURI:http://tm.kit.edu/~z~上帝保佑
Chuck Dvorak AT&T Room 2A37 180 Park Avenue, Building 2 Florham Park, NJ 07932 Phone: +1 973-236-6700 Fax: +1 973-236-7453 EMail: cdvorak@research.att.com
查克·德沃夏克美国电话电报公司2A37室新泽西州弗洛勒姆公园2号楼公园大道180号07932电话：+1 973-236-6700传真：+1 973-236-7453电子邮件：cdvorak@research.att.com
Yacine El Mghazli Alcatel Route de Nozay 91460 Marcoussis cedex FRANCE Phone: +33 1 69 63 41 87 EMail: yacine.el_mghazli@alcatel.fr
Yacine El Mghazli Alcatel Nozay路线91460 Marcoussis cedex FRANCE电话：+33 1 69 63 41 87电子邮件：Yacine.El_mghazli@alcatel.fr
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
Andrew McDonald Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK EMail: andrew.mcdonald@roke.co.uk
Andrew McDonald Siemens/Roke Manor Research Roke Manor Research Ltd.Romsey，Hants SO51 0ZN英国电子邮件：Andrew。mcdonald@roke.co.uk
Al Morton AT&T Room D3-3C06 200 S. Laurel Avenue Middletown, NJ 07748 Phone: +1 732 420-1571 Fax: +1 732 368-1192 EMail: acmorton@att.com
艾尔·莫顿电话电报公司D3-3C06室，新泽西州米德尔顿市劳雷尔大道200号，邮编07748电话：+1 732 420-1571传真：+1 732 368-1192电子邮件：acmorton@att.com
Bernd Schloer University of Goettingen EMail: bschloer@cs.uni-goettingen.de
贝尔恩德-施洛尔大学GoeTigEN电子邮件：bschloer@cs.uni-戈廷根
Percy Tarapore AT&T Room D1-33 200 S. Laurel Avenue Middletown, NJ 07748 Phone: +1 732 420-4172 EMail: tarapore@.att.com
珀西·塔拉波尔美国电话电报公司D1-33室，新泽西州米德尔顿市劳雷尔大道200号，邮编07748电话：+1732 420-4172电子邮件：tarapore@.att.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
[3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; enhanced Multi Level Precedence and Preemption service (eMLPP) - Stage 1 (Release 7).
[3GPP-1]3GPP TS 22.067 V7.0.0（2006-03）技术规范，第三代合作伙伴项目；技术规范组服务和系统方面；增强型多级优先和抢占服务（eMLPP）-第1阶段（第7版）。
[3GPP-2] 3GPP TS 23.067 V7.1.0 (2006-03) Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Core Network; enhanced Multi-Level Precedence and Preemption service (eMLPP) - Stage 2 (Release 7).
[3GPP-2]3GPP TS 23.067 V7.1.0（2006-03）技术规范，第三代合作伙伴项目；技术规范组核心网；增强型多级优先和抢占服务（eMLPP）-第2阶段（第7版）。
[3GPP-3] 3GPP TS 24.067 V6.0.0 (2004-12) Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Core Network; enhanced Multi-Level Precedence and Preemption service (eMLPP) - Stage 3 (Release 6).
[3GPP-3]3GPP TS 24.067 V6.0.0（2004-12）技术规范，第三代合作伙伴项目；技术规范组核心网；增强型多级优先和抢占服务（eMLPP）-第3阶段（第6版）。
[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月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212]Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[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月。
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[RFC3140]Black，D.，Brim，S.，Carpenter，B.，和F.Le Faucheur，“每跳行为识别码”，RFC 31402001年6月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181]Herzog，S.，“信号抢占优先权政策要素”，RFC 31812001年10月。
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[RFC4124]Le Faucheur，F.，编辑，“支持区分服务感知MPLS流量工程的协议扩展”，RFC 41242005年6月。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4412]Schulzrinne，H.和J.Polk，“会话启动协议（SIP）的通信资源优先级”，RFC 4412，2006年2月。
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006.
[RFC4506]艾斯勒，M.，编辑，“XDR：外部数据表示标准”，STD 67，RFC 4506，2006年5月。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling 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月。
[Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services", February 2006.
[Y.1541]ITU-T建议Y.1541，“基于IP的服务的网络性能目标”，2006年2月。
[Y.2171] ITU-T Recommendation Y.2171, "Admission Control Priority Levels in Next Generation Networks", September 2006.
[Y.2171]ITU-T建议Y.2171，“下一代网络中的准入控制优先级”，2006年9月。
[COMPOSITION] Morton, A. and E. Stephan, "Spacial Composition of Metrics", Work in Progress, July 2010.
[组成]Morton，A.和E.Stephan，“度量的空间组成”，正在进行的工作，2010年7月。
[DQOS] CableLabs, "PacketCable Dynamic Quality of Service Specification", CableLabs Specification PKT-SP-DQOS-I12-050812, August 2005.
[DQOS]CableLabs，“PacketCable动态服务质量规范”，CableLabs规范PKT-SP-DQOS-I12-050812，2005年8月。
[EMERG-RSVP] Le Faucheur, F., Polk, J., and K. Carlberg, "Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority", Work in Progress, March 2010.
[EMERG-RSVP]Le Faucheur，F.，Polk，J.，和K.Carlberg，“资源预留协议（RSVP）对准入优先权的扩展”，正在进行的工作，2010年3月。
[G.711] ITU-T Recommendation G.711, "Pulse code modulation (PCM) of voice frequencies", November 1988.
[G.711]ITU-T建议G.711，“语音频率的脉冲编码调制（PCM）”，1988年11月。
[IEEE754] Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, August 1985.
[IEEE754]电气和电子工程师协会，“二进制浮点运算的IEEE标准”，ANSI/IEEE标准754-1985，1985年8月。
[CL-QOSM] Kappler, C., "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Work in Progress, April 2010.
[CL-QOSM]Kappler，C.“使用NSIS发送IntServ控制负载服务的QoS模型”，正在进行的工作，2010年4月。
[DSCP-REGISTRY] IANA, "Differentiated Services Field Codepoints", http://www.iana.org.
[DSCP-REGISTRY]IANA，“差异化服务领域代码点”，http://www.iana.org.
[NETWORK-OCTET-ORDER] Wikipedia, "Endianness", http://en.wikipedia.org/wiki/Endianness.
[NETWORK-OCTET-ORDER]维基百科，“Endianness”，http://en.wikipedia.org/wiki/Endianness.
[PHBID-CODES-REGISTRY] IANA, "Per Hop Behavior Identification Codes", http://www.iana.org.
[PHBID-CODES-REGISTRY]IANA，“每跳行为识别码”，http://www.iana.org.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1701]Hanks，S.，Li，T.，Farinaci，D.，和P.Traina，“通用路由封装（GRE）”，RFC 17011994年10月。
[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994.
[RFC1702]Hanks，S.，Li，T.，Farinaci，D.，和P.Traina，“IPv4网络上的通用路由封装”，RFC 1702，1994年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004]Perkins，C.，“IP内的最小封装”，RFC 2004，1996年10月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[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月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保付PHB集团”，RFC 25971999年6月。
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.translate error, please retry
[RFC2997] Bernet, Y., Smith, A., and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
[RFC2997]Bernet，Y.，Smith，A.，和B.Davie，“空服务类型的规范”，RFC 2997，2000年11月。
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002.
[RFC3290]Bernet，Y.，Blake，S.，Grossman，D.，和A.Smith，“区分服务路由器的非正式管理模型”，RFC 32902002年5月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393]Demichelis，C.和P.Chimento，“IP性能度量的IP数据包延迟变化度量（IPPM）”，RFC 3393，2002年11月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[RFC3564]Le Faucheur，F.和W.Lai，“支持区分服务的MPLS流量工程的要求”，RFC 3564，2003年7月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
[RFC4301]Kent，S.和K.Seo，“网络安全体系结构”
Internet Protocol", RFC 4301, December 2005.
互联网协议”，RFC 4301，2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[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月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481]Morton，A.和B.Claise，“数据包延迟变化适用性声明”，RFC 54812009年3月。
[RFC5976] Ash, G., Morton, A., Dolly, M., Tarapore, P., Dvorak, C., and Y. El Mghazli, "Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes", RFC 5976, October 2010.
[RFC5976]Ash，G.，Morton，A.，Dolly，M.，Tarapore，P.，Dvorak，C.，和Y.El-Mghazli，“Y.1541-QOSM：使用Y.1541服务质量等级的网络模型”，RFC 59762010年10月。
[RFC5977] Bader, A., Westberg, L., Karagiannis, G., Kappler, C, and T. Phelan, "RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv", RFC 5977, October 2010.
[RFC5977]Bader，A.，Westberg，L.，Karagiannis，G.，Kappler，C和T.Phelan，“RMD-QOSM：区分服务中资源管理的NSIS服务质量模型”，RFC 5977，2010年10月。
[VERTICAL-INTERFACE] Dolly, M., Tarapore, P., and S. Sayers, "Discussion on Associating of Control Signaling Messages with Media Priority Levels", T1S1.7 and PRQC, October 2004.
[垂直接口]Dolly，M.，Tarapore，P.，和S.Sayers，“关于控制信令消息与媒体优先级关联的讨论”，T1S1.7和PRQC，2004年10月。
[Y.1540] ITU-T Recommendation Y.1540, "Internet Protocol Data Communication Service - IP Packet Transfer and Availability Performance Parameters", December 2002.
[Y.1540]ITU-T建议Y.1540，“互联网协议数据通信服务-IP数据包传输和可用性性能参数”，2002年12月。
Appendix A. Mapping of QoS Desired, QoS Available, and QoS Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ
附录A.NSI的期望QoS、可用QoS和保留QoS映射到RSVP IntServ的AdSpec、TSpec和RSpec
The union of QoS Desired, QoS Available, and QoS Reserved can provide all functionality of the objects specified in RSVP IntServ; however, it is difficult to provide an exact mapping.
期望的QoS、可用的QoS和保留的QoS的结合可以提供RSVP IntServ中指定的对象的所有功能；然而，很难提供精确的映射。
In RSVP, the Sender TSpec specifies the traffic an application is going to send (e.g., TMOD). The AdSpec can collect path characteristics (e.g., delay). Both are issued by the sender. The receiver sends the FlowSpec that includes a Receiver TSpec describing the resources reserved using the same parameters as the Sender TSpec, as well as an RSpec that provides additional IntServ QoS Model specific parameters, e.g., Rate and Slack.
在RSVP中，发送方TSpec指定应用程序将要发送的通信量（例如TMOD）。AdSpec可以收集路径特性（例如延迟）。两者都是由发送方发出的。接收器发送FlowSpec，该FlowSpec包括一个接收器TSpec，该接收器TSpec描述使用与发送器TSpec相同的参数保留的资源，以及一个RSpec，该RSpec提供额外的IntServ QoS模型特定参数，例如速率和松弛度。
The RSVP TSpec, AdSpec, and RSpec are tailored to the receiver-initiated signaling employed by RSVP and the IntServ QoS Model. For example, to the knowledge of the authors, it is not possible for the sender to specify a desired maximum delay except implicitly and mutably by seeding the AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in the receiver-issued RSVP RESERVE message. For this reason, our discussion at this point leads us to a slightly different mapping of necessary functionality to objects, which should result in more flexible signaling models.
RSVP TSpec、AdSpec和RSpec根据RSVP和IntServ QoS模型采用的接收器启动信令进行定制。例如，据作者所知，发送方不可能指定期望的最大延迟，除非通过相应地播种AdSpec来隐式地和可变地指定。同样，RSpec仅在接收方发出的RSVP RESERVE消息中有意义地发送。出于这个原因，我们在这一点上的讨论导致我们对必要功能到对象的映射略有不同，这将导致更灵活的信令模型。
In an example VoIP application that uses RTP [RFC3550] and the G.711 Codec [G.711], the TMOD-1 parameter could be set as follows:
在使用RTP[RFC3550]和G.711编解码器[G.711]的示例VoIP应用程序中，TMOD-1参数可设置如下：
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 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.
在最简单的情况下，最小策略单元m是IP、UDP和RTP头+有效负载的总和。IPv4情况下的IP标头大小为20个八位字节（如果使用IPv6，则为40个八位字节）。UDP报头的大小为8个八位字节，RTP使用12个八位字节的报头。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
A number of extra headers (e.g., for encapsulation) may be included in the datagram. A non-exhaustive list is given below. For additional headers, m, r, and b have to be set accordingly.
数据报中可以包括许多额外的报头（例如，用于封装）。下文列出了一份非详尽的清单。对于其他标头，必须相应地设置m、r和b。
Protocol Header Size
--------------------------+------------
GRE [RFC1701] | 8 octets
GREIP4 [RFC1702] | 4-8 octets
IP4INIP4 [RFC2003] | 20 octets
MINENC [RFC2004] | 8-12 octets
IP6GEN [RFC2473] | 40 octets
IP6INIP4 [RFC4213] | 20 octets
IPsec [RFC4301, RFC4303] | variable
--------------------------+------------
Protocol Header Size
--------------------------+------------
GRE [RFC1701] | 8 octets
GREIP4 [RFC1702] | 4-8 octets
IP4INIP4 [RFC2003] | 20 octets
MINENC [RFC2004] | 8-12 octets
IP6GEN [RFC2473] | 40 octets
IP6INIP4 [RFC4213] | 20 octets
IPsec [RFC4301, RFC4303] | variable
--------------------------+------------
Authors' Addresses
作者地址
Gerald Ash (Editor) AT&T EMail: gash5107@yahoo.com
杰拉尔德·阿什（编辑）AT&T电子邮件：gash5107@yahoo.com
Attila Bader (Editor) Traffic Lab Ericsson Research Ericsson Hungary Ltd. Laborc u. 1 H-1037 Budapest Hungary EMail: Attila.Bader@ericsson.com
Attila Bader（编辑）交通实验室爱立信研究爱立信匈牙利有限公司。1 H-1037布达佩斯匈牙利电子邮件：Attila。Bader@ericsson.com
Cornelia Kappler (Editor) ck technology concepts Berlin, Germany EMail: cornelia.kappler@cktecc.de
科妮莉亚·卡普勒（编辑）ck技术概念德国柏林电子邮件：科妮莉亚。kappler@cktecc.de
David R. Oran (Editor) Cisco Systems, Inc. 7 Ladyslipper Lane Acton, MA 01720, USA EMail: oran@cisco.com
David R.Oran（编辑）Cisco Systems，Inc.7 Ladyslipper Lane Acton，马萨诸塞州01720，美国电子邮件：oran@cisco.com